投入プロンプト: MAS-306 メタプロンプト 投入日: 2026-04-21 使用モデル: Gemini Deep Think (v2 再検討版) 関連: dev_mas-147 開発仕様書 (v2)

回答全文 (v2 設計仕様書)

MAS-147 請求書 OCR・マッチング機能 設計仕様書 (v2: Document AI + Gemini ハイブリッド)

1. エグゼクティブサマリ

v2 アーキテクチャの核心は「事実抽出（Fact）と意味推論（Reasoning）の責務分離」です。税法上 1 円のブレも許されない「T 番号」「金額」「日付」「明細行座標」は Google Cloud Document AI に確定的に抽出させ、Gemini は「請求タイプ（定額/従量等）の推論」や「真のベンダー推定」といった文脈処理のみに特化させます。この組み合わせにより、誤マッチによるデータ汚染リスクをゼロに抑えつつ、自動確定（Auto-Link）率の最大化と人間確認（HitL）工数の極限までの削減を実現します。

2. v1 からの継承 / 変更 / 廃止

3. Document AI 標準エンティティ → WRK_INVC 完全対応表

4. 確信度スコア統合設計

複合スコア計算式:

const amtConf = docAi.total_amount.confidence;
const vndConf = docAi.supplier_tax_id ? docAi.supplier_tax_id.confidence : docAi.supplier_name.confidence;
const baseFactConf = Math.min(amtConf, vndConf); // 最弱リンク
const geminiConf = geminiOutput.confidenceScore; // Gemini 推論スコア (0.0-1.0)
const finalScore = (baseFactConf * 0.8) + (geminiConf * 0.2);

閾値とアクション:

• HIGH (0.85 以上): Auto-Link (自動紐付)。T 番号・金額一致でバックグラウンド処理。
• MEDIUM (0.60 〜 0.84): HitL (保留)。T 番号欠損等。サイドバーで人間が 1 クリック承認。
• LOW (0.60 未満): OCR エラー警告。手動補正を促す。

※ total_amount.confidence < 0.80 または currency != JPY の場合は強制的に LOW に落とす 即死ルール を適用。

5. line_items を使った 1:N 分割マッチの可否判定

DocAI の line_items は物理座標に基づくため、ハルシネーションのない決定的データとして 1:N 消込（Pass 4）に活用可能です。

• 照合方式: GAS の 000_infra/004_utils.js に N-gram Jaccard 係数 または Levenshtein 距離 を実装し、line_item.description と 予算マスタの 品目名 の類似度（例: 70% 以上）でファジーマッチ。
• 失敗対策: SUM(line_items.amount) != total_amount となる場合（割引・送料の分離等）、1:N 探索を放棄し BUNDLE_SVC 扱いとして HitL (手動分割) へフォールバック。

6. フォルダ分離・リネーム運用設計 (MAS-152 統合)

• フォルダ階層: 02_processed/請求書/YYYY-MM/ （フラットな大フォルダは API タイムアウトの原因となるため月次サブフォルダ必須）。システム実行日ベースで動的生成。
• 命名規則: YYYYMMDD_取引先名_税込金額_docNumber.pdf （電帳法検索要件担保）。同名衝突時は _(1) を付与。
• 保留/エラー管理: HitL 未承認ファイルは無期限保留。抽出失敗時は _UNKNOWN_ プレフィックスを付与し、HitL 補正後に再リネーム。
• 電帳法対応: 02_processed/ の権限を「閲覧者」に絞り、システム以外からの編集・削除を不可とする（MAS-201 連携）。

7. コスト対効果試算 (月間 100 通想定)

• v1 (Gemini 単独): 月額 ~$1.0。ハルシネーション懸念により HitL 確認率が高く（約 60 件）、確認工数は 月 60 分（約 3,000 円相当）。
• v2 (ハイブリッド): 月額 ~$2.0 (DocAI + Gemini)。T 番号と金額の確定的抽出により Auto-Link 率が 85% 超へ向上。HitL は約 15 件となり、確認工数は 月 7.5 分（約 375 円相当）。
• 結論: 月額わずか数百円の追加 API コストで、経営者の「PDF を凝視して金額を再確認する時間」が 50 分以上削減され、ROI は圧倒的にプラス。

8. GAS 実装制約と対応策

• OAuth スコープ崩壊 (失敗パターン #26) の防止: Document AI 呼び出しに必要な https://www.googleapis.com/auth/cloud-platform を appsscript.json に追記する際、必ず「プロジェクト設定」に表示されている 現在の全スコープをコピーして配列に完全記述 すること（部分追加すると Spreadsheet 等の権限が全焼失する）。
• 50MB レスポンス制限回避: UrlFetchApp 時の URL に ?fieldMask=entities,text を付与し、Base64 画像やポリゴン座標を除外する。

9. 推奨実装ロードマップ (v2 版)

• Step 1 (W1): DocAI インフラ & OAuth 権限設定 - GCP 設定、安全なスコープ更新、通信テスト。
• Step 2 (W1): 物理ファイル・ルーティング基盤 - 階層フォルダ移動とリネームロジックの実装。
• Step 3 (W2): ハイブリッド抽出パイプライン構築 - DocAI パース → Gemini メタ推論 → 統合 JSON 生成。
• Step 4 (W3-W4): マッチングエンジン ＆ HitL サイドバー実装 - 複合スコア計算、Pass 0〜2 の Auto-Link 開通、未承認候補のサイドバー UI 開発と 1:N サジェストの組み込み。

10. 想定リスクと緩和策

• 多ページ PDF によるタイムアウト: 3 ページ以上の場合、最初の 2 ページのみを DocAI に送信する前処理を挟む（総額・サマリは先頭に集中するため）。
• 外貨（ドル等）の誤読: currency != JPY なら強制的に LOW スコアとし、HitL に警告を出す。
• 手書き領収書の精度低下: docType 判定で確信度が低い場合は、Gemini への画像直接入力 (v1 方式) へフォールバックさせる。

11. 採否判断マトリクス

• 初期 (〜30 枚/月): Gemini 単独 (v1) を推奨。コスト最安、全件目視でも負担小。
• 成長期 (30〜200 枚/月): DocAI + Gemini (v2) を推奨。AWS 等の 1:N 明細分割消込に対応し、経理の目視工数破綻を防ぐ。
• 成熟期 (1,000 枚〜/月): Cloud Run への移行。GAS と DriveApp の API 制約を超えるためバックエンド刷新が必要。

仕様書への反映方針

本回答を元に、docs/dev/dev_mas-147_invoice_ocr_auto_posting.md を v2 として全面改訂する。主要反映ポイント:

1. 責務分離 (Fact vs Reasoning): DocAI = 税法確定値、Gemini = 意味推論
2. T 番号カラム必須: 12_mst_partner / 32_wrk_invoice 両方
3. 多段 Pass (0〜6) マッチング: T 番号 → 取引先完全一致 → N:1 合算 → 1:N 分割 (格上げ) → ファジー → 新規
4. 複合確信度スコア: baseFactConf × 0.8 + geminiConf × 0.2、HIGH/MEDIUM/LOW (0.85/0.60) + 即死ルール
5. HitL サイドバー UI: PDF プレビュー + 候補提示 + 承認/オーバーライド
6. フォルダ分離・リネーム (MAS-152 統合): 02_processed/請求書/YYYY-MM/ + 電帳法リネーム
7. 非同期キュー: 1 バッチ 1〜2 件 (DocAI 処理時間増のため縮小)
8. 採否判断マトリクス: 30 枚未満 = v1 / 30〜200 枚 = v2 / 1000 枚〜 = Cloud Run

変更履歴