画像の文字起こし：中の文字を取り出して、先へ進む
ビルドが落ちます。エラーはスタックトレース40行、しかも表示されているのはコピーできない端末——リモートコンソール、 持ち出し制限のかかったVM、同僚がチャットに貼ったスクリーンショット。読むことはできます。選択だけができません。 そしてJavaのパッケージパスを手で打ち直す作業は、タイプミスの製造工程です。
このページはそのためにあります。スクリーンショットをアップロードすれば、写っている文字が認識され、 検索窓にもアシスタントにもIssueにも貼り付けられるプレーンテキストとして返ってきます。ファイルの説明文ではなく、 ピクセルに対する本物のOCRです。JPG、JPEG、PNG、GIF、BMP、TIFF、TIF、WebPに対応しています。無料、登録不要、 1ファイル50MBまで、こちら側には何も保存しません。要するに画像の文字起こしを最も素直な形にしたもの—— 画像を入れて、言葉が出てくる。それだけです。
スクリーンショットの文字起こしから検索窓までの往復
スクリーンショットから文字を取り出したい理由でいちばん多いのは、その文字をテキストしか受け付けない場所へ 入れたいから、というものです。検索エンジンは画像を受け取ってくれません。Issueトラッカーの検索も、ログ基盤も、 例外を貼って「これは何ですか」と尋ねる入力欄も同じです。
つまり流れはこうです。スクショを撮る、変換する、貼る。10秒です。そして差ははっきり出ます。例外クラス名と行番号を そのまま渡されたアシスタントは具体的に答えますが、ふわっと言い換えたものを渡されたアシスタントは 一般的なチェックリストを返してきます。エラーダイアログ、CIの出力、データベースのメッセージ、クラッシュレポート—— どれも同じです。画面に文字として出ていたのに選択できなかったものは、この方法で回収できます。
テキストとMarkdown、どちらを選ぶか（正直な答え）
たいていのサイトは、ここで大げさな違いをでっち上げます。実際はもっと地味です。単純な画像——段落のスクリーンショット、 ターミナルの窓、メモ書き——であれば、テキストとMarkdownの結果は実質的に同じになります。認識された文字は行として 返ってくるだけで、散文のかたまりにはMarkdownが付け足せる構造がそもそも隠れていません。どちらを選んでも失うものはありません。
効いてくるのは、写っているものに形があるときです。表、フォーム、見出しのある文書ページ。その並びを運べるのはMarkdownで、 平坦なテキストは空白で匂わせることしかできません。そういう画像には 画像をMarkdownに変換のほうが向いています。 それ以外——そして「それ以外」がスクリーンショットの大半です——はプレーンテキストのほうがきれいな成果物です。 スクリプトにも、インデックスにも、diffにも、構文用の記号を落とす前処理なしで渡せます。
ページ上部の形式切り替えは2つを行き来しますが、すでに選んだファイルはそのまま引き継がれます。両方試すのに必要な アップロードは1回で、2回ではありません。
地味に効く、日々の用途
- ターミナルとログの出力。スクロールバックが残っていないセッションのコマンド出力や、 ローテーションで消える前に撮っておいたログ画面。テキストにしてしまえば、grepもdiffも質問もできます。
- チャットやメールのスクリーンショット。テキストではなく画像で転送されてくる会話—— 現実にはこちらのほうが多数派です。一度変換すれば、引用できて検索できるものになります。
- 看板、ラベル、パッケージ。製造番号のプレート、配線ラベル、製品仕様のパネルを撮った写真。 打ち直すのは面倒でも、変換なら一瞬です。
- 手書きのメモ。試す価値はありますが、期待値は現実的に。楷書に近い書き方ならかなり読めますし、 崩した字は苦手です。結果は必ず原本と突き合わせてください。
- 見えているのにコピーできないコード。動画の1フレーム、スライド、コピー禁止の文書に載った断片。 テキストとして取り出してから、 GitHubリポジトリをテキストにしたものや GitLabプロジェクトと組み合わせれば、 アシスタントに断片とコードベースを同時に見せられます。
- Webサイトを撮ったスクリーンショット全般。これはやめたほうがいい習慣です。 Web2Txtならページを直接取得してリンクも保てますし、 保存済みのページならHTMLをMarkdownに変換が 扱えます。ピクセルを読ませるより、元のソースに戻るほうが常に勝ちます。
認識が働く場所と、働かない場所
知っておくべき失敗パターンは、たった1つのルールで全部説明がつきます。OCRが対象にするのはアップロードした画像ファイルであって、 他のファイルの中に埋まった画像ではありません。大きな入れ物に同乗している画像は素通りされます。変換ツールが読んでいるのは 入れ物のほうだからです。
- スキャンPDFは何も返しません。画像だけのPDFには文字が入っておらず、OCRはPDFという包装を突き抜けて ピクセルまでは届きません。直すのは手前の工程です。Acrobat、macOSのプレビュー、最近のPDFリーダーのほとんどで 「テキストを認識」を実行して検索可能なPDFにしてから、 PDFをテキストにまたは PDFをMarkdownに変換を使ってください。 スキャン文書の正しい置き場所はそちらです。
- ZIPの中の画像は一覧に出るだけで、読まれません。アーカイブの変換で得られるのはファイル名だけです。 文書のフォルダならZIPをテキストにが適任ですが、 画像は展開して1枚ずつアップロードしてください。
- Word、PowerPoint、RTF、EPUB、メールに埋め込まれた画像も読まれません。出力には画像のプレースホルダーとして 現れます。スクリーンショットを貼り集めたDOCXを WordをMarkdownに変換で処理すると、 周りの本文だけが出てきて、画像のあった場所が穴になります。画像は書き出してから、ここで変換してください。
この1行を覚えておけば、無駄なアップロードは一度もしなくて済みます。画像を読ませたいなら、画像そのものを渡す。
数をこなす、そして機械に食わせる
出力の行き先が人間でないなら、選ぶべき形式はプレーンテキストです。大量の画像から起こしたテキストは素直に連結でき、 予想どおりにチャンク分割でき、書式のノイズをベクトルへ持ち込まずに埋め込めます。スクリーンショットの山に検索インデックスを 張るときや、写真に撮った資料を後から引ける形にするときに、まさに必要な性質です。
現実的な進め方は1枚ずつのアップロードです。アーカイブの中身は読まれないので、一括処理ではなくループを前提に計画してください。 ここで出力の下のトークンカウンターが役に立ちます。1回の変換が実際どれだけのコストになるかが、複数ページを1つの プロンプトに積み始める前や、チャンク戦略の予算を決める前に分かります。文書と画像が混在するコーパスなら、 File2Txtが対応形式すべてを1か所で扱いますし、 ローカルフォルダ変換ならプロジェクトのテキスト側を まとめて1回で平坦化できます。
認識側に楽をさせる
精度は画像の品質にきれいに連動します。どんな設定をいじるよりも、次のいくつかの習慣のほうが結果を変えます。
- 画面を写真に撮るのではなく、スクリーンショットを撮ってください。映り込みも、角度も、ブレも、 ディスプレイのモアレもなくなります。
- ほしい文字の範囲でぴったり切り抜いてください。1文字あたりのピクセル数がすべてですし、頼んでもいないUIの 装飾が出力に紛れ込むのも防げます。
- 向きを正しく、できるだけ正面から。傾いた行は、まっすぐな行より読み取りが難しくなります。
- 難しい条件は避けられるかぎり避けてください。低解像度のキャプチャ、写真の上に載った文字、筆記体や装飾書体、 半分影に入っているもの。うまくいくこともありますが、誤りが集中するのはここです。
- 大事なものは目視で確認を。参照番号の数字が1つ誤読されても声は上がりませんし、後で高くつきます。 出力に5秒目を通せば気づけます。
よくある質問
JPG画像をテキストに変換するには？
上の変換ツールに画像をドロップしてください。実際のピクセルに対してOCRが走り、認識された言葉が選択・検索・貼り付けのできるプレーンテキストとして返ってきます。無料、登録不要、1枚50MBまで。文字どおり、画像を入れて言葉が出てくるだけで、インストールするものは何もありません。
PNGなど他の画像形式でも使えますか？
使えます。JPG、JPEG、PNG、GIF、BMP、TIFF、TIF、WebPすべて対応しています。スクリーンショットの多くはPNGで保存されますが、これはOCRにとって最良の条件です。スクリーンショットは紙を撮った写真ではなく、レンダリングされた文字そのものなので、カメラのブレも、紙の反りも、照明のムラも相手にしなくて済みます。
手書きのメモも読めますか？
苦手です。基本的には読めないものと考えてください。OCRモデルの学習データは圧倒的に活字であり、崩した字や急いで書いた文字からは、もっともらしく見えて、こちらが確認しようとも思わない箇所だけが間違っている出力が出てきます。罫線のある紙に楷書で丁寧に書かれたものなら通ることもあります。それ以外は原本との突き合わせが必須で、たいていは打ち直したほうが早く済みます。
スクリーンショットの文字起こしで別の文字になってしまうのはなぜ？
ほぼ必ず解像度です。似た形を見分けるにはおおむね300DPI相当が必要で、それを下回ると欧文ではrnがmに潰れ、日本語では日と曰、長音記号のーと漢数字の一が入れ替わります。全角と半角の取り違えも同じ理由で起きます。もう少し寄って撮り直すか、縮小せずウィンドウの原寸でキャプチャし直せば、大半は解決します。
文書のページを撮った写真からもテキストを取れますか？
取れますし、思われているよりうまくいきます。ただし先にページを平らにしてください。カメラは斜めからではなく紙と平行に構え、文字の上に影が落ちない均一な光を当て、画面いっぱいにページを収めます。台形にゆがんだ写真や影のかかった写真は行がまるごと落ちますし、そのときOCRはエラーを出しません。
変換した画像はどこかに保存されますか？
されません。認識のために送られ、処理され、テキストを返した時点で破棄されます。保管も、学習への利用も、インデックス化もしません。アカウントとも結び付きませんし、こちら側に控えも残りません。
ここにあるその他のツール
画像は対応する13形式のうちの1つで、どれも File2Txtから扱えます。画像に限らない 一般論のほうが読みたければ、 LLM向けに文書を整える方法のガイド にもう少し長い記事があります。
Repo2Txtを開発・運営しているのは v12hero、 プライバシー最優先のネイティブアプリとWebアプリを作る独立系デベロッパーです。