アプリとAPIにつなぐPDF・文書自動化

PDF、フォーム、スクリーンショット、添付ファイルは、プロダクトの外側に残りがちです。誰かが読み、値をコピーし、例外を確認し、アプリ、スプレッドシート、CRM、バックエンドへ入力しています。

そのため文書自動化は、最初のソフトウェアスプリントに向いています。入力が見えやすく、出力を確認しやすく、結果をアプリやAPIへ渡せるからです。抽象的な「AI戦略」案件と異なり、文書自動化にはBefore/Afterが明確にあります。置き換える手作業は、すでに人件費として帳簿に乗っているからです。

最初のバージョンで行うこと

最初からすべての文書種別を扱う必要はありません。件数が多い受付経路に絞るべきです。

• PDF、フォーム、メール、アップロードファイルを読み取る
• 名前、日付、ID、金額、メモ、分類ラベルを抽出する
• 各抽出項目の根拠を表示する
• 信頼度が低い値を人の確認へ回す
• 承認済みレコードをCSV、スプレッドシート、API、DB、キューへ渡す

これにより、危険な完全自動化を避けながら実務で役立つ仕組みにできます。

最初のスプリントで動くリファレンス構成:

受信経路: メール添付 / S3アップロード / SFTP / Webフォーム
  → ファイルストレージ(S3、GCS、Azure Blob)に原本保存
  → 形式振り分け:
      デジタルPDF → pdfplumber / pdf.js / Apache Tika
      スキャンPDF・画像 → OCR(Azure Document Intelligence、AWS Textract、
                              Google Document AI、Tesseract+layout-parser)
      Office文書 → unoconv / docx2txt
  → レイアウト情報付きテキスト+トークンごとのバウンディングボックス
  → 厳格なJSON Schema(Pydantic / Zod)でLLM抽出:
      {
        invoice_number, issue_date, due_date,
        supplier_name, supplier_tax_id,
        total_amount, currency,
        line_items: [...],
        confidence_per_field, evidence_bbox_per_field
      }
  → 検証ルール(合計=明細合計、日付の妥当性、IDの正規表現)
  → 信頼度ルーティング: 高 → 自動承認キュー
                        中 → フィールド事前入力済みのレビュー画面
                        低 → AIヒント付きの手入力
  → 承認時に記録システムへ書込(会計API、CRM、社内DB)
                + 下流ワーカー向けにメッセージキューへイベント発行

後で効いてくる2つの設計ルール:

1. 各フィールドの「根拠」を保存する。 バウンディングボックス、ページ番号、生のOCRスニペット。これがないと監査・異議対応が不可能になります。あれば、レビュー画面でモデルが読んだ箇所を正確にハイライトできます。
2. 抽出は「データ」であって「テキスト」ではない。 モデルはスキーマ検証済みの構造化JSONを返します。検証失敗の出力は訂正プロンプトで再試行し、それでも失敗なら手動レビューへ。下流で自由形式の文章をパースしない。

測るべき指標

削減時間、手戻り削減、レビュー後の抽出精度、追加確認なしで進められるレコード数を測ります。

初日から追う具体的な指標:

• フィールド単位の Precision/Recall。 文書単位ではなく。文書単位90%でも、重要フィールドの再現率が30%という事態は普通に起こる。ラベル付きホールドアウト50〜200件で計算。
• 自動承認率。 すべての信頼度・検証しきい値を通過し、人手編集なしで進んだ割合。請求書系で最初のスプリント時に50〜70%が現実的。それより高い場合は、しきい値が緩いか、対象が狭すぎる可能性。
• 1文書あたり所要時間。 中央値とP95。手作業ベースラインと比較。
• フィールド別レビュアー上書き率。 次にプロンプト/モデルを改善すべきフィールドを特定できる。
• 1文書あたりコスト。 OCR + モデルトークン + レビュアー分単価。規模が出れば手作業の1/5〜1/20が一般的だが、暗黙ではなく明示的に計算すること。

数字に説得力があれば、次の投資はプロダクト連携、権限、監視、顧客向けワークフローへ進められます。

PoCに向いている理由

入力が繰り返しで、出力を確認しやすく、業務責任者が手作業コストを理解していることが多いため、文書自動化は数週間でソフトウェアの証拠を作りやすいテーマです。

さらに、永続的な資産が残ります。スキーマ、抽出プロンプト、検証ルール、レビューUIはPoC後も使い続けられます。文書自動化は自然に拡張します。今月は請求書、来月は発注書、翌四半期は契約書。それぞれが同じパイプラインに新しいスキーマと新しいプロンプトを足すだけで動きます。この複利的な性質こそ、「変革」を売り込まずに小さな最初のスプリントが複数年DXプログラムの起点になり得る理由です。