請求書・契約書をAIで自動読取｜OCR×LLM自動化の実装と導入判断

請求書や契約書をAIで自動読取する仕組みは、「OCRで紙・PDFを読み取り、LLMで項目を構造化し、人手レビューで例外を拾う」という3層構成で作るのが2026年時点の実務的な解です。OCR単体では帳票のレイアウト揺れや手書きに弱く、LLM単体では座標を持たない長文契約書の抽出が不安定になります。両者を組み合わせ、さらに「人手で直す導線」を最初から設計に織り込むことで、初めて本番の経理・法務業務に乗せられる精度に到達します。

この記事では、Google Document AIやAzure AI Document Intelligenceといった一次情報に基づく実装パターン、精度を決める例外処理とレビュー設計、そして内製と外注をどう判断するかまでを、手を動かす解像度で整理します。

結論：OCR単体でもLLM単体でもなく「OCR×LLM×人手レビュー」の3層で作る

書類業務の自動化で本番運用に乗るのは、OCR・LLM・人手レビューを役割分担させた3層構成です。理由は、それぞれが補う弱点が明確に異なるからです。

• OCR層：紙・PDF・画像から文字と座標（バウンディングボックス）を取り出す。レイアウトのある帳票では座標情報が抽出精度を支える。
• LLM層：OCRが出した生テキストや表構造から、「請求金額」「支払期日」「契約期間」などの意味的な項目を構造化（JSON化）する。表記揺れや言い回しの違いをLLMが吸収する。
• 人手レビュー層：信頼度スコアが低い項目だけを人がチェックし、修正結果を学習データやプロンプト改善に還流する。

請求書のような定型帳票は、Document AIの請求書専用パーサのように「OCR＋抽出」が一体化したプリビルドモデルで完結することも多いです。一方、契約書のような非定型・長文は、OCRで全文テキスト化したうえでLLMに「どの条項から何を読むか」を任せる構成が向きます。書類の定型度で構成を変えるのが設計の起点になります。

書類タイプ	定型度	推奨構成	主な難所
請求書・領収書	高（項目が決まっている）	プリビルド抽出モデル or OCR＋LLM	レイアウト揺れ・明細行の対応付け
注文書・納品書	中	OCR＋LLM（プロンプト設計）	フォーマットがベンダーごとに違う
契約書	低（長文・非定型）	OCR全文化＋LLM（条項抽出）	該当条項の特定・解釈の一貫性
手書き帳票	低	高精度OCR＋LLM＋レビュー必須	文字認識そのものの精度

OCRエンジンの選び方：クラウドAPIか、ローカルか

OCRエンジンは「精度・対応書類・データの外部送信可否」で選びます。結論として、クラウドのドキュメントAIサービスは精度と開発速度で優位ですが、機密性の高い契約書を外部に出せない場合はローカルOCRを選ぶ、という判断軸になります。

主要なクラウドサービスの料金は以下の通りです（2026年6月時点・各社公式料金ページより。為替・改定で変動するため発注前に必ず公式を確認してください）。

サービス	OCR（テキスト化）	請求書など定型抽出	カスタム抽出
Google Document AI	$1.50 / 1,000ページ（Enterprise Document OCR）	$0.10 / 10ページ（Invoice Parser）	$30 / 1,000ページ（Custom Extractor）
Azure AI Document Intelligence	$1.50 / 1,000ページ（Read）	$10 / 1,000ページ（プリビルドInvoice）	$30 / 1,000ページ（Custom Extraction）

出典：Google Cloud Document AI 料金／Azure AI Document Intelligence 料金

クラウドサービスを選ぶときの注意点を補足します。Google Document AIのカスタムプロセッサは、抽出単価とは別にデプロイ済みバージョンのホスティング料金が時間課金（$0.05/時、1バージョン年間約$438）で発生します。Azureも従量課金に加えてストレージや連携基盤の費用がかかります。API単価だけで見積もると本番コストを2〜3割見誤るのが定石なので、運用時の固定費まで含めて試算してください。

機密性の制約でクラウドに出せない場合は、Tesseractなどのローカルエンジンや、自前環境で動かせるOCRモデルを使い、抽出側のLLMもローカルLLM（社内環境構築）に寄せる構成になります。精度と運用負荷のトレードオフが大きくなるため、ここは内製・外注の判断が分かれやすいポイントです。

LLMで構造化する実装：必ず「型」を固定する

LLMによる項目抽出で本番品質を出す鍵は、出力スキーマ（JSONの型）を固定し、LLMに「自由作文させない」ことです。理由は、自由形式で返させると、フィールド名のブレや欠損、余計な解説文の混入が起き、後続処理が壊れるからです。

Geminiの構造化出力（response schema）を使うと、出力をJSONスキーマに強制できます。請求書からの抽出を例にした最小実装は以下の通りです（@google/genai SDK、2026年時点の構造化出力API）。

import { GoogleGenAI, Type } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const invoiceSchema = {
  type: Type.OBJECT,
  properties: {
    issuer: { type: Type.STRING },          // 請求元
    invoiceNumber: { type: Type.STRING },   // 請求書番号
    issueDate: { type: Type.STRING },       // 発行日 YYYY-MM-DD
    dueDate: { type: Type.STRING },         // 支払期日 YYYY-MM-DD
    totalAmount: { type: Type.NUMBER },     // 税込合計
    taxAmount: { type: Type.NUMBER },       // 消費税額
    lineItems: {
      type: Type.ARRAY,
      items: {
        type: Type.OBJECT,
        properties: {
          name: { type: Type.STRING },
          quantity: { type: Type.NUMBER },
          unitPrice: { type: Type.NUMBER },
        },
      },
    },
  },
  required: ["issuer", "totalAmount", "dueDate"],
};

const result = await ai.models.generateContent({
  model: "gemini-2.5-flash",
  contents: [
    { text: "次のOCR結果から請求書項目を抽出してください。読み取れない値はnullにし、推測で埋めないでください。" },
    { text: ocrText },
  ],
  config: {
    responseMimeType: "application/json",
    responseSchema: invoiceSchema,
    temperature: 0, // 抽出タスクは決定性を上げる
  },
});

const invoice = JSON.parse(result.text);

実装上の勘所は3つあります。第一に**temperature: 0 で出力のブレを抑えます。抽出は創造性が不要なタスクなので、決定性を最優先にします。第二に「読み取れない値はnullにし、推測で埋めない」とプロンプトで明示します。LLMは空欄を嫌って“それらしい値”を捏造しがちで、これが経理データでは致命的なミスになります。第三に、PDF画像を直接マルチモーダルで渡す方法もありますが、OCRでテキスト化してから渡すほうが座標起因の取りこぼしを減らせる**ケースが多く、特に明細行の対応付けで効きます。

契約書のような長文は、全文をそのまま渡すとトークンが膨らみ精度も落ちます。「対象条項を見出しで特定 → 該当チャンクだけをLLMに渡す」という前処理（RAG的な絞り込み）を入れると、抽出の安定性とコストの両方が改善します。

精度を決めるのは「例外処理」と「信頼度スコア」

自動読取の実運用での精度は、正常系のモデル精度ではなく、例外をどう拾うかで決まります。理由は、本番の書類は必ず「想定外」を含むからです。回転・傾き・かすれ、複数ページにまたがる明細、外貨・税率違い、そもそも請求書でないファイルの混入——これらを「自動で全部正解させる」のは非現実的です。

そこで設計に組み込むべきが信頼度スコアによる振り分けです。Document AIなどの抽出APIは項目ごとに信頼度（confidence）を返すため、これを使って自動確定とレビュー行きを分けます。

type ExtractedField = { value: string | number | null; confidence: number };

function routeForReview(fields: Record<string, ExtractedField>) {
  const REVIEW_THRESHOLD = 0.85; // 業務の許容誤りに応じて調整
  const needsReview: string[] = [];

  for (const [key, field] of Object.entries(fields)) {
    // 必須項目が空、または信頼度が閾値未満ならレビューへ
    if (field.value === null || field.confidence < REVIEW_THRESHOLD) {
      needsReview.push(key);
    }
  }
  // 金額の整合チェック（合計≠明細合計などのビジネスルール）
  // ここで弾いたものもレビュー対象にする

  return { autoApprove: needsReview.length === 0, needsReview };
}

信頼度スコアに加えて、ビジネスルールによる検算を必ず併用します。「明細の合計と税込合計が一致するか」「支払期日が発行日より後か」「取引先マスタに存在する請求元か」といったルールベースのチェックは、LLMの確信度が高くても起きる論理矛盾を捕まえます。AIの確信度とドメインルールの二段構えにすることで、見逃しを大きく減らせます。

閾値は「業務がどこまで誤りを許容できるか」で決めます。経理の支払処理なら閾値を高くしてレビュー率を上げ、社内の文書整理ならやや緩めて自動化率を上げる、という調整です。閾値は固定値ではなく運用しながら最適点を探すパラメータだと捉えるのが実務的です。

人手レビューを「設計の一部」として組み込む

人手レビューは自動化の失敗ではなく、自動化を成立させる必須コンポーネントです。理由は、レビューを通じて「どこで間違えたか」が蓄積され、それがプロンプト改善やルール追加、（カスタムモデルなら）再学習データになるからです。レビューを後付けの“尻拭い”にすると、精度がいつまでも頭打ちになります。

実務で機能するレビューフローは次の形です。

1. 自動確定／レビュー必須を信頼度とルールで振り分ける（前節）。
2. レビュー画面は原本（OCR画像）と抽出値を並べて表示し、該当箇所をハイライトする。人が「どこを見て直すか」を迷わない導線が、レビュー速度を決める。
3. 修正は差分として記録し、「どの項目が・どんなパターンで・どれくらい間違うか」を集計できるようにする。
4. 集計結果をプロンプト・ルール・閾値の改善に還流する。よく間違う項目には専用の指示やバリデーションを足す。

この「レビュー → 計測 → 改善」のループを回せる設計になっているかどうかが、PoCで終わるか本番運用に乗るかの分かれ目です。導入初期はレビュー率が高くても問題ありません。レビュー率が運用とともに下がっていく仕組みがあることが重要で、初期精度の絶対値より改善の傾きを見るべきです。

内製と外注の判断軸：どこで自社開発が詰まるか

内製で進めるか外注するかは、「コア業務ロジックは内製、精度を出す土台は知見のある相手に任せる」という切り分けが現実的です。理由は、書類自動化で詰まるのは“APIを叩く部分”ではなく、その手前と後ろにある設計だからです。

自社開発が止まりやすいのは、典型的に次の3点です。

• 例外処理の網羅：正常系は早く動くが、現場の“変な書類”に対応し始めると工数が膨らむ。どこまで自動化し、どこから人に渡すかの線引きに知見が要る。
• 精度の出し方：プロンプト設計、スキーマ定義、信頼度の閾値設計、ビジネスルール検算の組み合わせは、経験差が精度に直結する。試行錯誤のコストが読めない。
• 本番運用への耐久設計：レビュー基盤、監査ログ、書類のバージョン管理、料金の固定費コントロールまで含めると、PoCと本番の間に大きな隔たりがある。

判断の目安を整理すると次の通りです。

状況	向いている進め方
定型帳票・少量・社内文書整理	プリビルドモデルで内製スモールスタート
経理・法務など誤りが許されない基幹業務	例外処理・レビュー設計に知見のある相手と組む
機密書類でクラウド不可・ローカルLLM必須	環境構築の難度が高く、外部支援の検討価値が大きい
PoCは動いたが本番で精度・運用が頭打ち	設計の見直し（外部レビュー含む）が効く局面

書類業務の自動化は、「OCRとLLMをつなぐ」こと自体は難しくありません。難しいのは、現場の例外を吸収しながら人手レビューを減らし続ける運用設計を、自社の業務に合わせて作り込むことです。PoCで動いたコードがそのまま基幹業務に乗らないのはこの差によるもので、内製で精度や運用が頭打ちになったときは、設計レベルでの見直しが投資対効果の高い打ち手になります。自社の書類タイプ・件数・許容誤りを起点に、どこまで自動化しどこを人に残すかという線引きから設計を組み直すことが、自動読取を実務に乗せる近道です。