TL;DR:大量スキャンPDFを検索できるようにするだけなら、OCR(画像内の文字をコンピューターが読めるテキストに変換するツール)一本で足りる。コードを書きたくなければデスクトップPDFソフトを使う。無料でファイルを手元に置いておきたければOCRmyPDF。ページ数が多くクラウドにアップロードできるならクラウドOCRで1,000ページあたり約1.5ドル。各ページの内容を把握して分類・整理もしたいなら、AI転写を加えて2つの結果を相互照合する。今回の600ページ超で追加した従量費は約7ドルで、もともと支払っているAIサブスクリプションと人件費は含まない。受け取った原始スキャンには一切手を加えていない。

夕方6時過ぎ、90 MBのPDFをダウンロードした。600ページ超の英語紙文書のスキャンで、各ページは画像だけだ。PDF内でどの言葉を検索してもヒットしない。ファイルにはページ番号インデックスが添付されていて、どのページがどの文書に当たるかが一覧されていた。

最初は内容をテキストに変換するだけのつもりだった。夜9時過ぎ、もう一歩進めてコード付きのアーカイブに整理し、同僚に渡せる形にしようと決めた。深夜0時過ぎには、80件超の独立した全文検索可能なPDF、各PDFに対応するWordテキストファイル(検索・コピー用で原本としては使えない)、最上位に総目次のExcelと使い方の説明書が揃っていた。

大量スキャンPDFの処理はよくあるニーズなので、この経験を選択ガイドとしてまとめた。求める結果ごとにルートを選べる構成にし、各ルートに手順・費用・制約を記した。今回の実際の経緯は第4ルートに佐証として置いている。逐次操作マニュアルではなく、今回書いたコードも公開していない。

作業の大部分はClaudeが担った。コードを書いたのも、ファイルの組み立てと検証を実行したのもClaudeだ。私はスコープの決定と判断を担い、クラウドアカウントも自分で開設した。アカウントキーを使うステップは自分のPCで実行した。コードを書けない人も同じ分担で進められる。この記事の選択表・転写ルール・公式ドキュメントのリンクをコードを書けるAIエージェント(PC上でコードを書いて実行できるAI、例えばClaudeやCodexなど)に渡して進めてもらえばよい。ただし、AIエージェントが読み込んだファイルの内容はそのAIサービスに送信される点に注意が必要だ。機密文書の扱いは後述する。

求める結果はどれか。まずルートを選ぶ

自分に問う点は2つ。検索できればよいのか、それとも分類・整理も必要か。ファイルをクラウドにアップロードできるか。

求める結果手順コードが必要かファイルがクラウドに行くか費用実測済みか
第1ルート検索できればよいデスクトップPDFソフトの文字認識機能不要基本不要(各ソフトの説明に従う)ソフトのサブスクリプションまたはライセンス費未実測
第2ルート検索できればよい、無料でファイルを手元に置くOCRmyPDF(内部エンジンはTesseract)ターミナルを開いてツールをインストールしてコマンドを打つ必要あり不要無料Tesseractを実測済み
第3ルート検索できればよい、ページ数が多くクラウドにアップロードできるクラウドOCR必要、またはAIエージェントに依頼必要1,000ページあたり約US$1.50Azureを実測済み
第4ルート各ページの内容を読み取り、分類・整理も必要AIページ単位転写とOCRを組み合わせてコードでファイルを組み立て必要、またはAIエージェントに依頼必要、かつ2社のクラウドを使用今回は1,000ページあたり約US$11今回の手順

アップロード前に確認する3つの問い:ファイルにマイナンバー・カルテ・未公開の事業データなどが含まれていないか。会社の規定やデータの所有者がアップロードを許可しているか。そのサービスがデータをどのくらいの期間保存するか、学習に使うか、早期削除できるか。どれか一つでも答えが出なければアップロードは保留し、第2ルートか、確実に自分のPC上だけで処理するデスクトップソフトを使う。AIエージェントに依頼する場合、エージェントが読み取ったファイルの内容・画面・エラーメッセージもそのAIサービスに送信される。機密文書は自分でコマンドを実行し、AIエージェントにファイルを開かせないこと。

どのルートを選んでも、まず元のファイルをコピーし、すべての処理はコピーに対して行う。次に最も難しい5ページを先に試す。表が含まれているページ、手書きのページ、向きが変わっているページ、小さい文字が多いページを選ぶ。試した後に検索で何語か調べ、原画像と照合して品質が許容できることを確認してから全ページ処理する。

第1ルート:検索できればよい、コードを書きたくない場合。デスクトップPDFソフトを使う

PDFを開き、ソフトの文字認識(OCR)機能を実行して保存すれば、検索可能なPDFが得られる。

Adobe Acrobat Proを例に取る(無料のAcrobat Readerにはこの機能がない)。スキャンPDFのコピーを開き、All tools(すべてのツール)→ Scan & OCR → Recognize Text → In This File の順にクリックして Recognize Text を押す。出力タイプの設定があれば Searchable Image (Exact) を選ぶ。これは元の画像の上にテキストを重ねるもので、画像は変わらない。Editable Text and Images はスキャン画像を再組版したテキストに置き換え、Searchable Image も画像を再サンプリングする。処理後は「別名で保存」で新しいファイル名(例:「元ファイル名_検索可能.pdf」)で保存し、元のファイルを上書きしないこと。上記は英語UIの名称で、日本語UIでは「スキャン」「テキスト認識」に関連する項目を探す。Adobe の日本語解説ページのタイトルは〈スキャンしたドキュメントのテキストを認識する〉だ。ABBYY FineReader PDFなど他のソフトにも同様の機能がある。

このルートは今回実測していない。手順はAdobeのヘルプページと2件の大学図書館チュートリアル(操作手順・出力タイプ)をもとに整理した。バージョンによってメニューが異なる場合があり、料金もプランや地域によって異なる。

第2ルート:無料でファイルを手元に置く場合。OCRmyPDFを使う

OCRmyPDF は無料のオープンソースツールで、コマンド一行でPDF全体に文字レイヤーを付与でき、ファイルは外部に出ない。使うのは「ターミナル」、つまりPCにコマンドを入力するウィンドウだ。Macなら「アプリケーション」内の「ユーティリティ」フォルダにある。Spotlightで「ターミナル」と検索しても開ける。

MacではまずHomebrew公式サイト(brew.sh)の手順に従ってHomebrewをインストールし(Mac向けにこの種のツールを管理するプログラム)、ターミナルで順に実行する。

brew install ocrmypdf
ocrmypdf --version

2行目にバージョン番号が表示されればインストール完了だ。英語以外の言語を認識させる場合は brew install tesseract-lang も実行する。

次に作業フォルダを作ってPDFのコピーを入れる。ターミナルに cd と半角スペースを入力し、そのフォルダをターミナルウィンドウにドラッグしてEnterを押せばそのフォルダに移動できる。その後に実行するコマンドは以下だ。

ocrmypdf -l eng input.pdf output.pdf

input.pdf は自分のファイル名に置き換える。ファイル名にスペースがあればダブルクォートで囲む(例:"スキャン ファイル.pdf")。output.pdf は文字レイヤーを付与した新しいファイルで、元ファイルは上書きされない。日本語は eng を jpn に、英日混在は eng+jpn にする(コードはOCRmyPDFの言語説明とTesseractの言語コード表を参照)。処理後に新しいファイルで何語か検索して確認する。

ページが裏返っていたり横向きだったり傾いていたりする場合は、-l eng の後に --rotate-pages(縦横正位)と --deskew(傾き補正)を追加できる。これらのオプションは新しいファイルのページの見た目を変えるため、元の見た目を保ちたければ使わない。Windowsのインストール手順は公式インストール説明を参照し、ocrmypdf --version が実行できる状態まで進める。その他のオプションは公式サンプル集を見る。

OCRmyPDFが既定で使うエンジンはTesseractだ。今回はOCRmyPDFを経由せずTesseractを直接呼び出した。品質については第4ルートの比較を参照してほしい。大部分のページは問題なく読めるが、難しいページは精度が落ちる。

選択肢として、未実測だが:Macを使っている人は AppleOCRプラグイン も試せる。macOS内蔵の文字認識を使うものだ。Pythonのパッケージマネージャーpipでインストールする(pip install ocrmypdf-appleocr、Python 3.11以上が必要)。明示的に指定する場合はコマンドに --ocr-engine appleocr を追加する(OCRmyPDF 17以上が必要)。インストールしなくても前述のOCRmyPDFは動く。試したければ数ページで検証してから判断すること。

第3ルート:ページ数が多くクラウドにアップロードできる場合。クラウドOCRを使う

Microsoft Azure・AWS・Google3社のクラウドOCRはいずれも1,000ページあたりUS$1.50の定価だ。3社のうち検索可能なPDFを直接返してくれるのはAzureだけで、今回もこれを使った。注意点として、Azureの公式データ説明には学習に使うかどうかが記載されていない(後述の「各社のデータポリシー」を参照)。冒頭の基準に従い、機密文書を扱う場合はMicrosoftまたは自社に確認してから使うか、ローカルのルートを選ぶこと。以下は2026年10月時点の公式情報だ。

サービス費用無料枠検索可能PDF実測済みか
Azure AI Document Intelligence のReadモデル1,000ページあたりUS$1.50(料金ページ、価格API)無料プラン(F0)は1回の分析で最初の2ページのみ直接返却、追加費用なし実測済み
AWS Textract1,000ページあたりUS$1.50新規ユーザーに最初の3か月、月1,000ページ自分でコードを接続する必要あり、公式ブログにサンプルあり未実測
Google Document AI1,000ページあたりUS$1.50料金表の第1ティア(0〜1,000)が無料と記載。月単位か一度限りかは不明公式ツールボックスでhOCR形式に変換可能、その後さらにツールを繋いでPDFにする必要あり未実測

Azureを使う手順:

  1. 従量課金のAzureアカウントを開設する。無料トライアルが使えるとは限らない。私のアカウントは対象外だった。
  2. Document Intelligenceリソースを作成し、有料のS0プランを選ぶ。無料プランは最初の2ページしか処理しない。
  3. リソースページで「エンドポイント」と「キー」を確認する。エンドポイントはこのサービスのURLで、キーはパスワードに相当する文字列だ。コードには両方が必要になる。キーの役割はクレジットカード番号に近い。コードに直接書き込まない、他人に渡さない、AIのチャットウィンドウに貼り付けない。
  4. コードを書ける人またはAIエージェントに公式ドキュメントをもとに小さなプログラムを作ってもらう。要件:Readモデル(prebuilt-read)を使う、APIバージョンは2024-11-30、分析送信時に output=pdf を付ける、送信後に数秒おきに結果を確認し、完了したらPDFのダウンロードURLを呼び出す。プログラムは実行時にキーの入力を促すか、ターミナルで自分が設定した環境変数から読み込む形にする。キーは画面に表示しない、ファイルに保存しない。まず5ページで試してダウンロードしたPDFで検索し、文字レイヤーがあることを確認してから全体を送信する。
  5. 予算アラートを設定し、一定の割合に達したら通知を受け取るようにする。アラートは既定ではメール通知で、それ自体がサービスを停止したり課金を止めたりはしない(公式説明)。

アカウント開設で2か所詰まった。私のアカウントは別の組織から招待を受けたことがあり、ログイン時に相手の「ディレクトリ」(Microsoftの呼び方)に入ってしまい、そこで多要素認証の設定を求められた。SMSの確認コードは届いたが登録でエラーになった。自分のアカウントが属するディレクトリを明示的に指定してログインし直したところ、正常に使えるようになった。ポイントは自分のディレクトリでログインしていることを確認することだ。多要素認証はアカウント保護のためのもので、自分のアカウントにも設定しておくことを勧める。もう一か所は請求ページの金額に「$」しか表示されず通貨が明記されていないことで、最初の請求が入るまで通貨を確認できなかった。画面上の「$」が米ドルとは限らない。気になる場合は全量送信前に請求通貨を確認しておくこと。

今回の600ページ超は、サーバー側の処理がわずか37秒、定価換算で約US$0.95だった。時間がかかったのはむしろファイル転送で、結果ファイルが92 MBあり、ダウンロード速度が毎秒200〜300 KB程度しか出ず、このペースだと6分前後かかる計算だ。ターミナルが全く動かず、止まったのかと思った。このサービスはそのまま残してある。後から新しいスキャンが届いても、同じコードを再実行するだけでよい。

第4ルート:内容を読み取り、分類・整理も必要な場合。AIページ単位転写を加える

AIに各ページを元のまま文字に起こしてもらい、分類と整理に使う。OCRは検索用。2つの結果をページごとに突き合わせ、人が確認すべきページを抽出する。これが今回の手順で、以下に実際の経緯を記す。

このスキャンの状態

各ページが1枚の画像で、ほぼすべてモノクロ、カラーは5ページのみ。タイプされた本文・表の数字・チェックボックスははっきり読める。難しいのは別の部分だ。横向きの内容を縦にスキャンしたページが3枚あり、90度回転しないと読めない。余白に手書きの星印と疑問符がある。一部のページはヘッダーが切れていて日付も欠けている。写真と図表はモノクロスキャンでハーフトーンのドットになっている。

添付のインデックスは出発点だが、そのインデックス自体に軽微なミスがある可能性が注記されていた。ページごとに照合した結果、書簡の日付が1件誤記されていた。文書の境界が1ページずれているケースが2件。空白ページ扱いになっていた2枚は手書きの仕切りページだった。不完全と注記されていた文書は、照合の結果、完全だった。

用途も先に決めていた。内部での閲覧・検索・出典確認に使い、外部に正式書類として提出しない。

なぜ2つに分けて処理するのか

「各ページの内容を読み取ること」と「PDFを検索可能にすること」は求める出力が異なり、得意なツールも違う。

1つ目はAIページ単位転写だ。各ページの画像を大規模言語モデル(Claude・ChatGPTのような画像を読んでテキストを生成できるAI)に渡し、元のまま構造を保ったテキストに起こしてもらう。表は表のまま、チェックボックスはチェックの有無を忠実に記録し、蛍光ペンや手書きも明示する。読めない文字や自信のない箇所も記録する。このテキストを分類・コード付けに使い、Wordテキスト版も作る。制約は、各文字がページ上のどこにあるかを把握していないため、PDFに重ねて検索・選択できる形にはできないことだ。

2つ目はOCRの文字レイヤーだ。OCRは各文字のページ上の位置を記録し、画像の上に不可視の文字を重ねる。これが「文字レイヤー」で、普段は見えないが検索やコピーの際に機能する。制約は内容を理解しないことで、フォーム・手書き・向きの変わったページはしばしば文字化けする。

2つの結果には3つ目の用途もある。相互チェックだ。2つのツールは仕組みが異なるため、エラーが出る箇所も通常異なる。ページごとに突き合わせることで、一致しないページが人の確認が必要なページとして浮かび上がる。

転写ルールをどう決めたか

最も難しい5ページを先に試した。表紙、蛍光ペンのあるページ、チェックボックスだらけのフォーム、太字・斜体が混在する問答ページ、90度回転した表だ。目視で照合したところ、切れたヘッダーの日付が1か所だけ読み取れなかったのみで、全600ページ超を送信した。AIへの指示の要点は5つだ。

  • 元のまま一字一句変えずに転写する。誤字もそのまま写し、修正・要約・翻訳・補完をしない。
  • 見出し・リスト・表の構造を保持する。
  • チェックボックス・蛍光ペン・手書き・署名は決まった記法で明示する。
  • ヘッダー・印鑑・ページ番号も元の位置に合わせて転写する。
  • 読めない箇所は「読み取り不可」と記し、自信のない文字は最も可能性の高い読み方の後に疑問符を付ける。

後で分かるように、これらの記法が人の確認が必要な箇所を正確に指し示すことになった。

完全な英語プロンプト 自分でコードを書く人向け(クリックして展開)
Transcribe this scanned page into GitHub-flavored Markdown, verbatim.

Rules:
- Reproduce every printed word exactly as it appears, including typos, numbering, units, dates and punctuation. Do not correct, summarize, translate, reorder or add anything.
- Keep the structure: headings, numbered and bulleted lists, indentation levels, and tables (use Markdown tables). For complex forms, write one "Field label: value" line per field in reading order.
- Keep emphasis: **bold**, *italic*, <u>underline</u>.
- Checkboxes: [x] for checked, [ ] for unchecked.
- Highlighter marks: wrap the highlighted text in ==double equals==. Handwritten ticks or marks in margins: [handwritten mark].
- Handwriting: transcribe it if legible and prefix it with [handwritten]. Signatures: [signature].
- Fax headers, stamps, page numbers, headers and footers: include them on their own lines, in place.
- Illegible text: [illegible]. A word you are unsure of: write your best reading followed by [?].
- If the page is blank or nearly blank, output exactly: [blank page]
- Output only the transcription. No preface, no comments, no code fences.

画像は長辺2,500ピクセル以内に縮小し、グレースケールのJPEGに変換してから送信することでページあたりの費用を抑える。取り消し線は指示に含めていないが、モデルがGitHub Markdownの記法で自動的に記録した。

実際にかかった費用は?

追加の従量費は約US$7で、そのうち約US$6がAIページ単位転写に使った分だ。換算すると1,000ページあたり約US$9.6、1ページあたり約1セント。クラウドOCRは1,000ページあたりUS$1.50。

ステップツール使用量と所要時間費用
AIページ単位転写Claude Sonnet 5.5、バッチ送信(急がない場合に使う、半額)600ページ超を6バッチに分けて送信、5分以内にすべて返却約US$6.04
検索可能文字レイヤー(第1版)Tesseract(無料のオープンソースOCRエンジン)AIのクラウド作業環境上で約36分ソフトは無料
ページ向き検出PaddleOCRの向き判定モデル(無料のオープンソース)約4分ソフトは無料
検索可能文字レイヤー(第2版)AzureのReadモデル、検索可能PDFを直接返却90 MBをアップロード、サーバー側処理37秒定価約US$0.95、請求は入金待ち

この7ドルは2社のクラウドサービスへの従量課金のみで、もともと支払っているAIサブスクリプション(コード作成・ファイル組み立て・検証を担ったClaude、レビューを担ったCodexとAntigravity)と人件費は含まない。このようなサブスクリプションがない場合やコードを書いてもらう場合は別途算定が必要だ。無料のオープンソースツールも、インストールやコマンド実行ができる人間が必要だ。

転写はトークン単位で課金される。トークンはAIがテキストと画像の使用量を計算する単位で、ページ数や文字数とは対応しない。Sonnet 5.5バッチの単価は入力100万トークンあたりUS$1、出力100万トークンあたりUS$5(公式料金)。今回の入力は3,189,072トークン、出力は569,843トークンで、1ページあたり平均約5,000と約900だった。換算すると1,000ページあたり約US$9.6だ。ページ上の文字が多いほど、画像が精細なほど費用は上がる。自分のファイルの費用を見積もるには5ページを試してページ数をかけるのが最も確実だ。公式によるとバッチはほとんどの場合1時間以内に完了し、24時間以内に処理されなかったリクエストは期限切れとなり課金されない。今回は5分以内にすべて返ってきた。

📊 主な数値

  • AIページ単位転写:1,000ページあたり約US$9.6(1ページあたり約1セント)。600ページ超で約US$6.04(Claude Sonnet 5.5バッチ)
  • クラウドOCR:1,000ページあたりUS$1.50。600ページ超で約US$0.95、サーバー側処理37秒
  • 無料OCR:Tesseractはソフト無料、約36分(PDFを画像に変換する時間を含む)
  • 所要時間:ダウンロードから第2版完成まで約6時間。AIエージェントがコードを担当。初めて作業する人の工数は別途見積もりが必要

6時間はおおまかに4つのフェーズに分かれる。5ページの試験実行と照合が約45分。全ページ転写とページごとの突き合わせが約45分。アーカイブとして整理することを決めた後の第1版が約1時間10分。クラウドアカウントの開設・クラウドOCRの実行・第2版の完成が約1時間半。その間に別の作業をしていた時間も含む。

無料のTesseractとクラウドOCRはどのくらい違うか

中央値で見るとほぼ同じだが、最も状態の悪いページで見ると大きく差が出る。

AI転写を照合基準として、2つのOCRが読み取った文字のうち転写と一致した割合をClaudeが算定した。連続した本文があるページのみ、557ページが対象だ。

Tesseract(無料)Azure Read(クラウド)
一致率(中央値)98.0%99.5%
一致しない文字が1割を超えるページ数663
相手より2ポイント以上一致率が高いページ数0185

中央値の差は1.5ポイントに過ぎない。Tesseractは一致しない文字が1割を超えるページが66あり、クラウドOCRに換えると3ページになった。2ポイント以上差があった185ページはすべてクラウド側が上回っていた。

この割合が測っているのは2つのツール間の一致度だ。照合基準のAI転写自体にもエラーがあり得るため、原画像に戻って確認すべきページを特定するための指標であり、正確率として扱えない。また、これは英語タイプ文書1バッチの結果に過ぎない。日本語・縦書き・大量の手書きを含む文書では結果が全く異なる可能性がある。

4コマ漫画:AI転写を照合基準として、2つのOCRが読み取った文字のうち転写と一致した割合をClaudeが算定した。連続した本文があるページのみ、557ページが対象だ。一致率(中央値):Tesseract(無料)98.0%、Azure Read(クラウド)99.5%。中央値の差は1.5ポイントに過ぎない。Tesseractは一致しない文字が1割を超えるページが66あり、クラウドOCRに換えると3ページになった。この割合が測っているのは2つのツール間の一致度だ。正確率として扱えない。これは英語タイプ文書1バッチの結果に過ぎない。中央値で見るとほぼ同じだが、最も状態の悪いページで見ると大きく差が出る。

処理時間は、2コアCPUのクラウド作業環境上でTesseractが画像変換と認識を合わせて約36分、クラウドOCRがサーバー側で37秒だった。

2つの結果をどう使って相互チェックするか

ページごとに突き合わせ、一致しないページを1ページずつ確認する。今回は双方が相手の問題を拾い上げた。

OCRが転写のエラーを捕捉した。 転写完了後、Claudeが無料OCRの全文を別途読み込んで2つをページごとに照合した。転写がヘッダー1行だけになっているページで、OCRはページ全体の本文を読み取っていた。AIがそのページ全体を取りこぼしていたにもかかわらず、バッチの結果は成功と表示されていた。このページは後から原画像を見ながら転写し直した。転写だけを見ていればこの種のエラーは見つけにくい。

転写もOCRの問題を捕捉した。 手書きフォームが2ページあり、無料OCRは文字化けした文字列を返したが、転写は各欄の手書き内容をきちんと記録していた。Tesseractの一致率が最も低い66ページを特定できたのも、転写を物差しにしたからだ。

転写が自ら自信のない箇所を示した。 転写が2か所で不確かさを示した。1か所は標準コードの末尾1桁が読み取れなかった箇所で、もう1か所は読み取り不可と記した箇所だ。1か所目はクラウドOCRが完全なコードを読み取り、信頼スコアは0.948(OCRが自分の読み取りに持つ確信度、最大値は1)だった。原画像を拡大して確認し、正しいことを確かめた。2か所目は原画像を拡大すると変更追跡の注釈番号で、同じ文書の後半に続く番号と連番になっていることが分かった。

向き検出はあくまで手がかりにすぎない。 オープンソースの向き判定モデルが7ページを正位でないと指摘したが、実際にそうだったのは3ページで、残り4ページはモデル自体の確信度が低く、確認するとすべて誤検出だった。クラウドOCRが角度ありと報告したページにも、文字が斜めに書かれているだけのページが2枚含まれていた。指摘されたページはすべて目で確認してから回転するかどうか判断する。

アーカイブに整理するにあたって決めたルール

作業を始める前にルールを決める。

  • コード体系:各バッチをその文書の日付で始め、バッチ内の連番はそのバッチのリストに従う。リストにあるがスキャンで見つからなかった文書もコードを仮押さえする。今回は約2割のコードが仮押さえだ。後から文書が届いても番号が繋がり、既存の番号も崩れない。
  • 原件を変えない:受け取った原始スキャンは独立したフォルダに入れ、一切手を加えない。整理後のPDFは元の画像をそのまま使い、再圧縮しない。追加する要素はすべて画像の外に置く。各ページ下部に付けた細い帯にコードを印字し、元の画像には触れない。横向きのページはその向きのまま組み込む。
  • フォルダを分ける:PDF・Wordテキスト版・原始スキャンをそれぞれ別のフォルダに置き、ファイルを開き間違えないようにする。
  • テキスト版の立場を明示する:WordファイルはPDF内の文字を検索・コピーしやすくするためのもので、エラーが含まれる可能性がある。各ファイルの冒頭に「引用はPDFまたは原始スキャンを基準とする」と必ず記載する。
  • 総目次:Excelで作成し、文書リスト・各ページの文字照合スコア・見つからなかった文書と欠けているページ・元のインデックスとの相違点、そして各ファイルの「チェックサム」(SHA-256ハッシュ値、ファイルが転送後に変わっていないことを確認するため)を収録する。

ルールを決めてまだ作業を始める前に、別の2つのAIツール(OpenAIのCodex、GoogleのAntigravity)にそれぞれ問題点を洗い出してもらった。互いに相手の意見を知らない状態でそれぞれ十数項目を指摘した。上記のルールの大部分はこのレビューを経て決定または修正したものだ。Codexはインデックス内の書簡の日付誤記も発見した。原件上の3か所の日付はすべて一致しており、インデックスの誤記だった。バッチの順番はこれを受けて修正した。Codexが示した事実の指摘はすべて原件に戻って照合してから採用した。手順は以前書いた記事「CodexにClaudeの誤りを指摘させるが、言われた通りにはしない」と同じだ。

納品前に何を検証するか

他者に渡す場合や長期保存する場合は、少なくとも以下を確認する。

  • 各ページの帰属が確定していること。どの文書に属するか、仕切りページか、重複した画像かをページごとに照合する。
  • 整理後PDFの画像が元ファイルと完全に一致すること。
  • 各ページで文字が検索できること。数ページで不可視のテキストを赤字で重ねて表示し、位置が正しいか確認する。向きが変わったページは必ず確認する。
  • ファイルリストに各ファイルのチェックサムを添付し、相手のPCに届いた後に再計算して一致することを確認する。圧縮ファイルにMacの隠しファイルを含めない。

これらの確認はすべてClaudeが書いたコードで実行した。自分だけが検索に使う場合は数ページを原画像と照合するだけで十分だ。検証プログラム自体もエラーを出すことがある。今回も誤報が1件あった。確認が失敗したときは、測る道具と測られるものの両方を調べること。

より安いAI転写や無料のオープンソースモデルはあるか

ある。ただし品質は別途検証が必要だ。以下は2026年10月時点の公式単価で、実測はSonnetのみだ。

選択肢公式単価(バッチ)1,000ページあたりの費用(Sonnetのみ実測、他は粗算)備考
Claude Sonnet 5.5入力100万トークンUS$1、出力US$5約US$9.6(実測)今回使用
Claude Haiku 5.5入力100万トークンUS$0.05、出力US$0.25粗算約US$0.5Sonnetの20分の1の単価。未実測、先に試してから切り替えること
Claude Opus 5.5入力100万トークンUS$2、出力US$10粗算約US$19Sonnetの2倍の単価。未実測
Gemini 3.1 Flash-Lite入力100万トークンUS$0.125、出力US$0.75粗算約US$0.8未実測。Googleの告知では早ければ2027年5月7日に提供終了
Gemini 3.5 Flash-Lite入力100万トークンUS$0.15、出力US$1.25粗算約US$1.3Googleが3.1 Flash-Liteの後継として推奨、未実測
Gemini 3.8 Flash入力100万トークンUS$0.375、出力US$1.875粗算約US$2、2027年以降は約US$42027年1月から単価が倍になる、バッチ価格も同様。未実測
Mistral OCR 41,000ページUS$4、バッチUS$2US$2〜4文書OCR専用、2026年6月リリース。未実測

粗算の前提:1ページの出力テキスト量が今回と同程度の約900トークン。Claudeの入力は今回の1ページあたり約5,000トークンを使用。GeminiのPDF処理は1ページあたり既定で560トークンとし、プロンプト約350トークンを加算。Geminiで思考モードを有効にした場合、思考トークンも出力として課金される(Gemini料金ページ)。表の数値には含めていない。

単価の高低は品質を示さない。安いモデルが文字を取りこぼすか、勝手に補うかは、自分のファイルで試してみるしかない。最も難しい5ページを2つのモデルに同時に投げ、原画像と1文字ずつ照合して、全体にどちらを使うか決めること。

オープンソースのAI認識モデル(olmOCR-2・PaddleOCR-VLなど)はライセンス料がかからないが、GPU(グラフィックカード)が必要か、自分のPCでのセットアップに時間がかかる。今年7月に古いスキャンを対象にした評価記事があり、最高スコアのモデルでも検査項目の半数に満たない合格率だった。さらにその評価では、レターヘッドや印鑑を省略した転写に高得点を与える評価基準が含まれており、元のまま保存したい場合は詳細を確認する必要がある(原文)。ランキングはあくまで手がかりとして見ること。

クラウドにアップロードする前に、各社のデータポリシーはどうなっているか

冒頭の3つの問いについて、今回使った2社の公式の記述は以下の通りだ。

  • Azure AI Document Intelligence:送信した文書と分析結果は分析完了後24時間保存され、その後自動削除される。APIを呼び出して早期削除することもできる(公式説明)。学習に使うかどうかはこのページに記載がない。
  • Claude API:ビジネス用途の入力と出力は既定でモデルの学習に使用しない(プライバシーセンター)。バックエンドでは30日以内に削除されるが、例外がある(保存期間の説明)。早期削除できるかどうかはこの2ページに記載がない。バッチ処理を使う場合、バッチ処理のドキュメントには、リクエストと結果は最長29日間保存され、処理後にAPIでバッチを削除できるとある。ただし、削除でデータがすぐに消えるかどうかは書かれていない。

調べる中でもう1点確認した。AWSのAIサービスは顧客のコンテンツを保存してサービス改善のために使う場合があり、用途にはモデルの学習が含まれる。また使用リージョン外のデータセンターに保存される場合もある。Textractはこのリストにあるため、AWS OrganizationsのAIサービスオプトアウトポリシーで無効化が必要だ。公式ページに記載のない部分はまだ確認できていないということであり、安全を意味しない。

今回の経験を踏まえた推奨の手順

振り返ると、2つのステップを省けた。

  • 第1版のTesseract文字レイヤーは1時間半後にクラウドOCRで置き換えられ、第1版は外部に渡すこともなく削除した。ファイルをクラウドに上げられる場合は最初からクラウドOCRを使えば、ファイルの組み立てと検証を1ラウンド省ける。
  • クラウドOCR自体がページの角度を報告する。これを使えば独立した向き判定モデルは不要になり、角度が報告されたページを目で確認するだけでよい。

推奨する手順:まず最も難しい5ページを試し、転写に使うモデルを決める(安い方から試す)。文字レイヤーはクラウドOCRに任せる(ファイルを外に出せなければOCRmyPDF)。2つの結果をページごとに突き合わせて人の確認が必要なページを抽出する。その後にファイルの組み立てと検証を行う。

受け取った原始スキャンには一切手を加えていない

受け取った原始スキャンはアーカイブの独立したフォルダに入れ、そのままにしてある。整理後の各PDFは元の画像をそのまま使い、再圧縮していない。追加した要素はすべて画像の外にある。各ページ下部の細い帯にコードを印字し、ブックマークを付けた。各PDFに対応するWordテキストファイル、最上位の総目次には欠けているページと元のインデックスとの相違点を記載した。

どのルートを選んでも、元のファイルは必ず別に保存し、すべての処理はコピーに対して行うこと。OCRmyPDFの縦横正位や傾き補正のオプションはページの見た目を変えるため、出力の画像が元ファイルと同一とは限らない。次のスキャンが届いたら、同じコード体系で番号を続け、同じコードを再実行する。ツールの実装に関する記録は「創造と構築 → ツールと実装」にまとめている。