最終更新: 2026/06/22 19:15
commonid: rq-008-i-03-matching-design-meta-prompttype: promptstatus: active
pagejtbd: JTBD-001rq: RQ-008

MAS-306 メタプロンプト: MAS-147 請求書 PDF → INV 自動起票 マッチング設計

用途: MAS-147 (請求書 PDF OCR + INV 自動起票 + 予算マッチング) の設計を Gemini Deep Think に検討させるためのメタプロンプト。2 段階構成 (v1 設計検討 → v2 Document AI 前提で再検討) を統合。

作成日: 2026-04-21 関連: MAS-147 開発仕様書 / MAS-306 結果

背景

bizlp-gas-accounting は Google Apps Script (GAS) + Google スプレッドシートをベースとした中小企業向け管理会計 ERP。MAS-147 は「顧客から受領した請求書 PDF を OCR で読取り、既存の予算マスタ (20 番台タブ) と突合して 32 タブの INV を自動起票する」機能を実装する案件。

MAS-147 の立ち位置

  • Top 15 優先着手バックログの上位案件 (AP 買掛管理の最大ボトルネック解消)
  • MAS-157 (写真 OCR・実装済) の OCR 基盤を拡張
  • ADR-0007「Gemini API を領収書解析に使用」の方針を踏襲
  • 類似案件: MAS-150 (証憑取込→20 番台マスタ自動起票)、MAS-171 (CC 明細 N:1 合算マッチ)

既存実装資産

  • 500_import/502_receipt_reader.js に callGeminiForReceipt_() 実装済
  • 領収書 OCR の PDF/画像処理パイプラインが確立
  • feat/MAS-147-invoice-ocr-auto-posting ブランチに v1 ベースの基礎実装が凍結中

v1 プロンプト (Gemini 単独 OCR 前提)

対象論点 (5 項目)

  1. マッチングアルゴリズム

    • 予算マスタ (20 番台) の取引先名・金額・期間と、OCR 抽出結果の突合方式
    • 完全一致 → 取引先一致 + 金額一致 → 取引先一致 + 金額近似 → 新規予算登録推奨
    • ファジーマッチング粒度 (取引先名の表記揺れ許容範囲)

  2. 確信度スコアリング

    • OCR 抽出値の確信度をどう判定するか
    • 自動起票 vs Human-in-the-Loop 確認の分岐閾値

  3. T 番号の扱い

    • インボイス適格請求書の T 番号 (T+13桁) を抽出・照合する設計
    • 12_mst_partner / 32_wrk_invoice にカラム追加が必要か

  4. エッジケースの処理

    • 多ページ PDF / 軽減税率混在 / 通貨違い / 複数請求書 1 PDF / ゼロ金額等

  5. Human-in-the-Loop UX

    • 自動起票候補の承認画面設計
    • オーバーライド (修正) 操作のフロー

出力フォーマット指示

  • 各論点について「推奨案」「懸念点」「根拠」の構造で回答
  • GAS の実装制約 (6 分実行時間制限・スプレッドシート行数上限・UrlFetchApp サイズ制限) を必ず織り込む
  • 既存コード資産 (502_receipt_reader.js / BudgetRepository 等) との整合性を意識

v2 プロンプト (Document AI + Gemini ハイブリッド前提で再検討)

変更理由

v1 の回答を受けて、「Gemini 単独での OCR は税法上 1 円のズレも許されない金額・T 番号の確定的抽出に向かない」という評価に至った。Google Cloud Document AI (プロダクション級の Invoice Parser) と Gemini を組み合わせたハイブリッド方式を前提に再検討する。

追加要件

  1. 責務分離 (Fact vs Reasoning)

    • Document AI = 税法上の確定値 (T 番号・金額・日付・明細行座標) を決定的に抽出
    • Gemini = 請求タイプ推論 (定額/従量等) や真のベンダー推定など意味的処理のみ

  2. Document AI 標準エンティティのマッピング

    • supplier_name / supplier_tax_id / invoice_id / invoice_date / due_date / currency / total_amount / net_amount / total_tax_amount / line_items / tax_details 等を WRK_INVC の各列にどう対応させるか
    • Gemini 推論項目 (trueVendorName / billingType / invoiceStructure / mainServiceSummary) の設計

  3. 確信度スコアの数値計算式

    • DocAI の各フィールド confidence (0.0〜1.0) を基準にした複合スコア
    • HIGH/MEDIUM/LOW 閾値の具体数値
    • 即死ルール (通貨が JPY 以外・金額 confidence < 0.80 等)

  4. 1:N 分割マッチの再評価

    • DocAI の line_items は物理座標ベースでハルシネーションがないため、v1 で見送った「1 請求書 → 複数予算」の分割マッチを実装可能か

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

    • 処理済み PDF の月次サブフォルダ自動生成
    • 電帳法準拠リネーム (YYYYMMDD_取引先名_税込金額_docNumber.pdf)
    • MAS-152 (電帳法リネーム) との責務分担

  6. コスト対効果試算

    • 月間 100 通想定で v1 vs v2 のコスト差 (API 料金 + HitL 工数)
    • ROI の具体数値

  7. 採否判断マトリクス

    • 月間処理件数 (30 枚 / 200 枚 / 1000 枚) に応じた v1 / v2 / Cloud Run 移行の判断基準

  8. GAS 実装制約への対応

    • OAuth スコープ崩壊 (失敗パターン #26) 回避: https://www.googleapis.com/auth/cloud-platform を既存全スコープと完全列挙
    • 50MB レスポンス制限回避: fieldMask=entities,text で画像・座標を除外

出力フォーマット指示

  • 設計仕様書形式で出力 (11 セクション想定):

    1. エグゼクティブサマリ
    2. v1 からの継承 / 変更 / 廃止マトリクス
    3. DocAI 標準エンティティ → WRK_INVC 完全対応表
    4. 確信度スコア統合設計 (計算式含む)
    5. line_items を使った 1:N 分割マッチの可否判定
    6. フォルダ分離・リネーム運用設計 (MAS-152 統合)
    7. コスト対効果試算 (月間 100 通想定)
    8. GAS 実装制約と対応策 (失敗パターン #26 対応含む)
    9. 推奨実装ロードマップ (4 Step 構成)
    10. 想定リスクと緩和策
    11. 採否判断マトリクス

  • そのまま docs/dev/dev_mas-147_invoice_ocr_auto_posting.md の v2 版のベースとして使えるレベルの具体性で記述

使い方

1 段階方式 (直接 Gemini に投入)

本メタプロンプトをそのまま Gemini Deep Think に投入し、回答を RQ-008_I-03_matching_design_result.md に保存する。

2 段階方式 (メタプロンプト → Deep Research プロンプト)

必要に応じて Gemini Pro に「このメタプロンプトを元に Deep Research 向けの詳細プロンプトを設計してください」と依頼し、出力を RQ-008_I-03_matching_design_prompt.md として保存してから Deep Research に投入する。

結果の保管

  • RQ-008_I-03_matching_design_result.md に回答全文を保存
  • dev_mas-147_invoice_ocr_auto_posting.md (v2) の執筆材料として使用
  • TODO_future.md の MAS-147 行のステータス更新と合わせて活用

変更履歴

日付変更内容
2026-04-21初版作成 (v1 設計検討 + v2 DocAI ハイブリッド再検討の 2 段階プロンプトを統合)