こんにちは、パレイド技術部の橘です。
前回 (第 2 回) で「中古マニュアルは手に入る」「スマホ撮影でも OCR に足りる画質が出る」と 書きました。
今回はその先、撮った写真を構造化テキストに起こす工程を実装します。 比較対象は macOS と iOS に標準で載っている文字認識 (Live Text / Vision framework)、 本命は Claude Vision です。
撮影だけは紙でやる
40年経過した印刷物なので、スキャナは使いません。机にマニュアルを開いて、iPhone でページごとに撮影でOK。 本書は中綴じではなく単ページずつ独立しているので、見開きで悩む工程はそもそも無い。 116 ページのうち、必要な範囲だけを順に撮っていきます。
iPhone の標準「カメラ」アプリで十分です。多少斜めから撮っても、最近の iOS は 書類認識で台形補正を自動でかけてくれるし、軽い影や光ムラも認識側で吸収してくれます。 連載者の手元では、特別な撮影台も照明も用意せず、机上で普通に撮るだけで、印字 p.51 の 本文 (8〜10pt 相当) はくっきり残りました。専用スキャナを引っ張り出す必要はない、 というのが今の OCR を取り巻く前提です。
なお、有志がWebサイトとしてまとめておられる情報や、リスクの観点からNGですが、既にスキャン済みのデータなどもGoogleで簡単に入手は可能です。AIに相談すると簡単にそうしたソースを見つけてきますが、利用に関しては注意事項もあわせて相談することをお勧めします。
macOS の文字認識を試す
macOS には Live Text (画像内のテキストを認識する標準機能) があります。プレビュー.app で
撮った JPEG を開き、テキスト選択ツールで全選択 → コピー、で本文が取り出せます。
バッチ処理したいなら、Shortcuts.app の「画像からテキストを抽出する」アクションを使い、
フォルダ単位で shortcuts run "OCR Folder" から流せます。
精度はそこそこ出ます。前回触れた Tesseract 系の従来 OCR のような派手な化けはほぼなく、 本文の日本語はかなり正確に取れる。とくに 1980 年代の印刷物に対しても、ベタな段落部分は 驚くほど読める。
ただし、Family BASIC のマニュアルで使い物になるかは別問題でした。実例を出します。 算術演算子の表が載っているページを Live Text に通すと、こうなります。
算術演算子
記号 意味 例
+ 加算 A+B
- 減算 A-B
* 乗算 A*B
/ 除算 A/B
^ べき乗 A^B…のように、文字は正確に抽出できますが、表は表として整っては出ません。実際には記号と意味の対応がずれ、列が混ざり、 コード例の B'1111...' が B' 1111 ' のようにスペース混じりになります。 カーソルキー記号 ←→↑↓ は記号として認識されないか、- > に化ける。 表組みや等幅コードリストの 構造はゼロから自分で組み直すことになる。
ここまでは Vision.framework を直接叩いても同じです。VNRecognizeTextRequest で
recognitionLanguages = ["ja-JP", "en-US"] を指定し、recognitionLevel = .accurate に
しても、認識される文字単位の精度は上がるが、ページの構造を保ったまま出してくれる
わけではない。Live Text も Vision framework も、出力はベタテキスト 1 本だけです。
つまり Apple の標準 OCR は「写真からテキストを抜く」までで止まっていて、 「このページは演算子の表だから、表として返してほしい」という指示を受け取る口がない。
Claude Vision に切り替える
そこで本命の Claude Vision です。同じ撮影画像を、構造ヒント付きのプロンプトと一緒に 投入します。
このページは Family BASIC マニュアル V2.1、印字 p.51。
内容は「演算子」の解説で、算術演算子の表 + 例文 + 関係演算子の表。
以下のスキーマで Markdown に起こせ:
{ entry, syntax, args, example, manual_quote, source }
特殊記号の扱い:
- `←` `→` `↑` `↓` はカーソルキー
- `B'1111...'` は 2 進数表記の凡例 (注釈なので無視可)
- `&H` は 16 進数接頭辞
引用は必要最小限。manual_quote には 1〜2 行のみ抜粋。返ってくる Markdown は、表は表として、コード例はコードブロックとして、注釈は注釈として
分かれた形になっています。← → も「カーソルキー」と文脈解釈されて落ちない。
字単位ではなくページ単位で意味を見ているので、構造を保ったまま出てきます。
精度自体も、本文の日本語については Live Text と並ぶ水準。差が出るのは 「表」「コード例」「特殊記号」のような、構造を必要とする部分です。
自動化まで含めると差は広がる
Live Text / Vision framework もスクリプトから呼べます。ただし、出力は素のテキスト 1 本で、 その先に「表を再構築する」「コードと注釈を仕分ける」「YAML スキーマに落とす」工程が 人力で残ります。1 ページあたり 30 分の後処理が、結局かかる。
Claude Vision は API から叩けるので、「撮影画像 → 構造化 Markdown → YAML スキーマ」を
一本のスクリプトでパイプにできる。連載者の手元では、撮影フォルダを監視して新規画像が
増えると自動で API に投げ、pages/v21-pNNN.md に落とすところまでを 50 行ほどのコードで
組んでいます。Live Text 経由だと、ここに表組み復元用の中間スクリプトが必要になるので、
コード量と分岐がだいぶ増える。
ローカル動作・無料という Live Text の利点はもちろんあります。しかし今回の用途
(レトロ言語のマニュアルを LLM 向けに構造化する) では、構造保持と自動化を両取りできる
Claude Vision の方が、総作業時間で見て勝ちです。
寄与度タグ付け — 全部やる必要はない
116 ページすべてを起こす必要はありません。本資料の目的は「LLM がコードを書くために 必要な情報の供給」なので、ハード接続説明・保証書・冒頭の挨拶などはスキップして問題ありません。
最初に全ページに「寄与度: 高 / 中 / 低 / 不要」タグを付ける page-index.md を
作成し、その後の撮影と OCR を「高」優先で進めました。結果、実処理対象は約 54 ページに圧縮。
これでも 1 ページあたり 30 分のレビュー込みで 27 時間。意外と現実的なボリュームです。
次回
これで起こすワークフローは固まりました。が、実際に書き起こしていると マニュアル原本には書かれていない事実 が次々と顔を出します。 「LET は使えない」「単項マイナスは動く」「DIM で配列はクリアされる」など。 次回は、その「マニュアル外の事実」をリファレンスにどう組み込むかの話です。