MAS-180: AI-OCR連携による証憑自動起票

概要

本仕様書は TODO_future.md §5.1 No.11「MAS-180 OCR 精度強化」（docs/_internal/TODO_future.md L437）の実装仕様である。

目的

証憑画像（PDF／JPEG／PNG）から Gemini API（500_import/502_receipt_reader.js L10-14 の RECEIPT_GEMINI_PROMPT_）で抽出した OCR 結果を、信頼度判定を経て InvoiceRepository.append()（200_data/202_repository.js L185-207）経由で 32_wrk_invoice に自動起票するパイプラインを新設する。低信頼度レコードは新規シート 36_wrk_ocr_queue（システムキー WRK_OCRQ）に「要確認」ステータスで蓄積し、人間がレビュー・修正したうえで手動メニューから起票する Human-in-the-Loop（HitL） 設計とする。これにより現行 importReceiptPdfs()（L22-185）が 35_wrk_receipt への転記で止まっている情報フローを、INV 起票まで直結させ、手動 INV 作成工数を削減する。

現在のコード

現行の証憑 OCR 取込（500_import/502_receipt_reader.js）の主要関数と責務範囲は以下のとおり。Phase 1 で ls 500_import/ にて 501_cc_importer.js / 502_bank_importer.js / 502_receipt_reader.js / 504_invoice_importer.js の 4 ファイル実在を確認済み。502 番が重複しているが、本案件の拡張対象は 502_receipt_reader.js（領収書/請求書 PDF）である。

出力先は 35_wrk_receipt（WRK_RCPT スキーマ：100_config/101_sys_config.js L898 で定義）のみで、Gemini の抽出結果は以下のフィールドで保持される：管理ID（RCP_NNNN）／処理日時／証憑種別／取引先名（Utils.normalizePartnerName() 適用済）／🏢住所／税込金額_決済／税抜金額_決済／消費税額_決済／源泉税額／T番号／帳票番号／発行日／発生日(P/L計上日)／決済日_実績／決済手段／摘要／ファイル名／証跡リンク。

本案件の課題: 35_wrk_receipt は「読み取ったデータの置き場」に留まり、INV 起票は人手でトリガされる（transferReceiptToAdhoc 等の別メニュー経由）。OCR 結果の信頼度判定ロジックも未実装で、金額不整合（税抜＋消費税 ≠ 税込）や取引先マスタ未ヒットの判別も手動目視に依存している。

修正方針

本案件では 502_receipt_reader.js を拡張する形で、OCR → 信頼度判定 → 自動/確認キュー振り分け → INV 起票 の 3 Step を実装する。既存 importReceiptPdfs() は変更せず、新規関数を追加する方式で後方互換性を保つ。

Step 1: 36_wrk_ocr_queue シートの新設（確認キュー基盤）

対象ファイル: 100_config/101_sys_config.js（DDL）／000_infra/002_constants.js（定数）

1. 100_config/101_sys_config.js の setupAllSchemas() に WRK_OCRQ スキーマを追加

   • schemas オブジェクト（L826-901）に以下のキーを追加：

     'WRK_OCRQ': { headers: [...], color: "#38761d" }
     

   • ヘッダー構成は「エッジケース」セクションの「36_wrk_ocr_queue の列構成」に準拠（18 列）。
   • 01_sys_config への登録：L820-823 の if (!existKeys.includes('WRK_CARD')) confSheet.appendRow(...) パターンに倣い、WRK_OCRQ キーを appendRow(['WRK_OCRQ', '', '36_wrk_ocr_queue', 'AI-OCR確認キュー']) で追加。

2. 000_infra/002_constants.js の ID_PREFIX_MAP（L93-112）にエントリ追加

   • 既存の { pattern: '16_wrk_master', prefix: 'REQ_', digit: 4, isDate: true } パターンに倣い、以下を追加：

     { pattern: '36_wrk_ocr_queue', prefix: 'OCQ_', digit: 4, isDate: true }
     

   • これにより Utils.getIdPrefixConfig('36_wrk_ocr_queue')（004_utils.js L482-487）が OCQ_YYYYMMDD_NNNN 形式の ID を発番できる。

3. Constants.SHEET_DEFAULTS（L73-87）にエントリ追加

   • 既存 L85 { pattern: '32_wrk_invoice', defaults: { '請求ステータス': '未処理', '収支区分': '支出', '通貨': 'JPY', '申請種別': '請求書受領(AP)' } } のオブジェクト型（{ pattern, defaults } 形式。prefix は ID 発番用で必須ではない）に倣い、以下を追加：

     { pattern: '36_wrk_ocr_queue', defaults: { 'ステータス': '要確認' } }
     

   • 失敗パターン #18（MAS-003）の教訓: SHEET_DEFAULTS は 3 要素配列ではなくオブジェクト配列である。必ず Read で確認してから追加すること。

4. Constants.MENU_DEFINITION（L206-324）への起票メニュー追加（Step 3 で詳述）

注: 36_wrk_bank_import（既存・WRK_BANK_IMPORT スキーマ、L822）とシート番号が重複するが、36_wrk_bank_import は銀行 CSV 取込専用で既に使用中のため、本案件のシートは物理名を 36_wrk_ocr_queue とする（両方とも 36_wrk_* 系で CSV/OCR 取込系の共通カテゴリ）。Utils の getSheetByKey 経由で参照するため物理名衝突のみが問題となるが、数値の重複自体は既存の 502_ 番号重複（502_bank_importer.js と 502_receipt_reader.js）と同様に許容されている運用。

Step 2: OCR パイプライン関数の実装

対象ファイル: 500_import/502_receipt_reader.js（既存関数は一切変更せず、末尾に関数追加）

処理フロー

  [Drive フォルダの PDF/画像]
           │
           ▼
  ┌─────────────────────────────┐
  │ (1) LockService.waitLock(30000) │ ← 排他制御。失敗時は Toast で終了
  └─────────────────────────────┘
           │
           ▼
  ┌─────────────────────────────┐
  │ (2) MD5 ハッシュ計算          │
  │     Utilities.computeDigest(   │
  │       Utilities.DigestAlgorithm│
  │         .MD5,                  │
  │       blob.getBytes()          │
  │     )                          │
  │     → 既に 36_wrk_ocr_queue に │
  │       ある → スキップ          │
  └─────────────────────────────┘
           │
           ▼
  ┌─────────────────────────────┐
  │ (3) Gemini API 呼び出し       │
  │     callGeminiForReceipt_() を│
  │     再利用（既存関数）         │
  │     N-40 分岐は自動で効く      │
  │     複数ページは「最終ページの  │
  │     合計金額のみ」指定          │
  └─────────────────────────────┘
           │
           ▼
  ┌─────────────────────────────┐
  │ (4) 正規化                    │
  │     Utils.normalizePartnerName()│
  │     Utils.aiSuggestAccount()   │
  └─────────────────────────────┘
           │
           ▼
  ┌─────────────────────────────┐
  │ (5) 信頼度判定                 │
  │  必須: T 番号・取引先・金額・日│
  │        付・科目名 が全て存在   │
  │  金額整合: 税抜 + 税 = 税込    │
  │  マスタ: 取引先名が MST_PART に│
  │          ヒット                │
  └─────────────────────────────┘
           │
      ┌────┴────┐
      │         │
      ▼         ▼
  [高信頼度]  [低信頼度]
      │         │
      ▼         ▼
  InvoiceRepo   36_wrk_ocr_queue
  .append([dto]) に要確認で登録
      │             │
      ▼             ▼
  36_wrk_ocr_queue  Toast で人間に確認依頼
  に起票済で記録

実装詳細

• 新規公開関数: importReceiptPdfsAutoPosting()（メニュー起点）。importReceiptPdfs() は温存。
• LockService:
  • var lock = LockService.getScriptLock(); try { lock.waitLock(30000); } catch(e) { SpreadsheetApp.getActive().toast('他の処理実行中のため中断', 'AI-OCR', 5); return; }
  • finally { lock.releaseLock(); } を必ず付ける。
• MD5 ハッシュ:
  • var blob = file.getBlob(); var md5 = Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, blob.getBytes()).map(function(b) { return ('0' + (b & 0xFF).toString(16)).slice(-2); }).join('');
  • 重複判定は 36_wrk_ocr_queue の ファイルMD5 列を全件読み取り、一致時は Utils.logInfo('importReceiptPdfsAutoPosting', '処理済みスキップ: ' + fileName) でログ出力してスキップ。
• Gemini 呼び出し: 既存 callGeminiForReceipt_(apiKey, base64, fileName)（L194）を再利用。MAS-216 の Vertex 分岐（Env.gcpProjectId() が設定済なら自動委譲・L196-198）もそのまま効く。
• 正規化:
  • 取引先名: Utils.normalizePartnerName(extracted.vendor)（004_utils.js L657-680）。12_mst_partner の 略称 列または 取引先名_正式 列に一致すれば略称を返し、未ヒットなら generateLogicalAbbr() で論理略称を生成。
  • 科目名: Utils.aiSuggestAccount(extracted.description + ' ' + extracted.vendor)（004_utils.js L467-475）で推論。該当なしなら空文字。
• 信頼度判定:
  • 「高信頼度」の条件（すべて真）：
    1. 必須フィールド（totalAmount / accrualDate / 正規化後取引先名 / invoiceNumber が T + 13 桁の形式 / aiSuggestAccount が科目名を返す）がすべて充足
    2. 金額整合性：Math.abs((extracted.subtotal + extracted.tax) - extracted.totalAmount) <= 1（1 円誤差まで許容）
    3. 推論科目が 11_mst_account に登録済み（AccountRepository.findAsMap()（202_repository.js L323-341）で照合）
  • 「低信頼度」：上記いずれか不充足
• InvoiceDTO への設定値（Phase 1 で 000_infra/003_contracts.js L40-67 / 100_config/101_sys_config.js L847 / 000_infra/002_constants.js L85 を裏取り確定）：

• 起票後処理: 36_wrk_ocr_queue に ステータス: 起票済 / 起票済INV_ID: <払い出された INV_ID> を書き込む。INV_ID は appendDtosToSheet_ 戻り値経由では取得できないため、InvoiceRepository.findAll() の末尾行から取り直すか、既存 appendDtosToSheet_ のパターン踏襲で事前に ID を採番して DTO に詰める（推奨: 既存 importReceiptPdfs 方式の「シート最終行から最大連番取得 → padStart で整形」を踏襲）。

Step 3: 確認キューからの手動起票メニュー追加

対象ファイル: 000_infra/002_constants.js（メニュー定義）／500_import/502_receipt_reader.js（ハンドラ関数）

1. メニュー追加: Constants.MENU_DEFINITION（L206-324）の 📋 サイドバー: 🔍 消込・マッチング カテゴリ（L268-280、既存の領収書 OCR 3 項目と同カテゴリ）に以下 2 項目を追加：

   { label: '🤖 AI-OCR 自動起票 (Drive)', funcName: 'importReceiptPdfsAutoPosting', description: 'Drive の PDF/画像を Gemini OCR で読み取り、32_wrk_invoice に自動起票（低信頼度は 36_wrk_ocr_queue）' },
   { label: '✅ 確認キューから INV 起票', funcName: 'postApprovedOcrQueueRows', description: '36_wrk_ocr_queue の選択行（ステータス=修正済）を 32_wrk_invoice に起票' },
   

   造語禁止（失敗パターン #20）：onOpen()（101_sys_config.js L323-350）は Constants.MENU_DEFINITION を動的ループするだけなので、メニュー実体は 002_constants.js 側。既存 { label: '📄 領収書PDF読込 (Drive)', funcName: 'importReceiptPdfs' }（L274）を参考に文字列を命名。

2. ハンドラ関数 postApprovedOcrQueueRows():

   • 選択範囲の行番号を SpreadsheetApp.getActiveSheet().getActiveRange() で取得。
   • 選択行のシート名が 36_wrk_ocr_queue でなければエラー表示して終了。
   • 選択行を ステータス === '修正済' のみで絞り込み、各行を InvoiceDTO に詰め替えて InvoiceRepository.append(dtos) を呼ぶ。
   • 成功時は当該行の ステータス を 起票済・起票済INV_ID に払い出された INV_ID を書き込み、Toast で件数通知。
   • バリデーション: 税抜 + 税 ≠ 税込 なら起票を拒否してエラー表示（低信頼度判定と同一基準）。

影響範囲

注意事項

1. 科目マスタ未登録の aiSuggestAccount 結果は自動起票禁止：InvoiceRepository.append()（L185-207）は 科目名 をキーに AccountRepository.findAsMap() を引いて 諸表区分・大分類 を自動付与する（L192-199）。未登録科目だとマップヒットせず諸表区分・大分類が空のまま書き込まれ、後続の P/L・B/S マート集計で抜け落ちる。自動起票ルートでは AccountRepository.findAsMap()[科目名] が存在する場合のみ高信頼度扱いとする。未登録なら低信頼度として確認キュー送り。
2. 36_wrk_ocr_queue は DDL 管理の新規シート。スキーマ追加後は dev で 📋 サイドバー: 🔧 開発・設定 → DDL 全更新 (Full) を実行して作成する必要がある。既存 Full DDL 経由で作成されるので、手動作成は不要。
3. Utilities.computeDigest() の引数型: Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, bytes) の bytes は byte[]。DriveApp.getFileById(id).getBlob().getBytes() で取得する。String を渡すと Invalid argument になる。
4. LockService.getScriptLock().waitLock(30000) は 30 秒タイムアウト。取得失敗時は Error を throw するので try/catch で捕捉し、Toast で通知して即 return。finally で releaseLock() を必ず呼ぶ（内部例外でのロックリーク防止）。
5. 申請種別 の実格納値は "請求書受領(AP)"（日本語表記）：CLAUDE.md は「APL_xxx で統一」としているが、実データは InvoiceDTO コメント（003_contracts.js L46）・Constants.SHEET_DEFAULTS L85・WRK_INVC DDL L847 すべてで "請求書受領(AP)" の日本語表記となっている。本案件は実データに合わせて日本語表記で設定する（DDL 定義値と格納実データの乖離はないと判断）。CLAUDE.md の APL_xxx 記述は将来の正規化方針（別案件）と解釈。
6. 複数ページ PDF の合算処理：現行 RECEIPT_GEMINI_PROMPT_（L10-14）は「ページごとに 1 つの JSON オブジェクトを返す」指示だが、本案件の自動起票ルートでは最終ページ（=合計金額が記載された請求書の末尾）のみを 1 件として扱うプロンプトを別途用意する（既存プロンプト定数は一字一句変更しないので、新規パイプライン用は別定数として定義）。中間ページの小計を誤採用するリスクを排除する。
7. 冪等性キー：36_wrk_ocr_queue.ファイルMD5 列を一意制約として運用。同一ファイルの再実行は MD5 一致で即スキップ（Utils.logInfo に「処理済みスキップ」出力）。35_wrk_receipt 側の ファイル名 による重複判定とは独立。
8. 35_wrk_receipt への書き込み連携は行わない：本案件のパイプラインは 36_wrk_ocr_queue と 32_wrk_invoice のみを操作する。既存 35_wrk_receipt は importReceiptPdfs 専用のまま維持し、二重書き込みは避ける。35_wrk_receipt 経由の消込ルート（importReceiptStatement・applyReceiptSettlement）とは責務を分ける。

エッジケース

信頼度判定と処理振分けテーブル

36_wrk_ocr_queue の列構成（DDL スキーマと完全一致）

Human-in-the-Loop フロー

1. 高信頼度（条件：必須フィールド全充足 + 金額誤差 ≤ 1 円 + 科目名が 11_mst_account 登録済） → InvoiceRepository.append() で自動起票 → 同時に 36_wrk_ocr_queue に ステータス: 起票済・起票済INV_ID を書き込み（監査ログ兼用）。
2. 低信頼度（上記以外） → 36_wrk_ocr_queue に ステータス: 要確認・エラー内容: <具体的な理由> で登録 → Toast で件数通知。
3. 人間が確認キューを修正 → 誤読箇所をシート上で直接編集 → ステータス を 修正済 に手動変更。
4. 確認キュー起票メニュー実行 → Step 3 の postApprovedOcrQueueRows() が選択範囲のうち 修正済 行のみを InvoiceRepository.append() 経由で起票 → ステータス: 起票済・起票済INV_ID を更新。
5. エラー行の運用 → ステータス: エラー の行はデータ修正後に 修正済 に変更 → 4 へ。修正不能なら手動で 有効フラグ=FALSE 相当（本シートでは ステータス: エラー 固定）で運用。

実データ検証

実装前に以下を MCP または GAS ログで確認すること（失敗パターン #18-#20・DDL 定義値 vs 実データ乖離対策）：

1. 12_mst_partner シート：
   • 略称 / 取引先名_正式 / 有効フラグ 列の列名が Utils.normalizePartnerName()（004_utils.js L665-676）で参照する '略称' / '取引先名_正式' / '有効フラグ' と完全一致するか確認。DDL L828 には 略称_4文字 / 取引先名_正式 / 略称 / 銀行摘要名 / UI用取引先名 の複数略称列が存在するため、normalizePartnerName が参照するのは 略称（略称_4文字 ではない）点を確認する。
2. 11_mst_account シート：
   • Utils.aiSuggestAccount() が返す全 account 値（Constants.ACCOUNT_RULES：002_constants.js L117-136）が 11_mst_account.科目名 に登録されているか確認。対象：新聞図書費 / 旅費交通費 / 交際費 / 通信費 / 支払手数料 / 消耗品費 / 地代家賃 / 水道光熱費 / 売上高 / 売上原価 / 租税公課 / 資本金 / 長期借入金 / 現金及び預金 / 預り金 / 法定福利費 / 給料手当 / 役員報酬。未登録があれば事前に D-01〜D-03 科目マスタ追加 マイグレーションメニュー（migrationD01D03）で追加する。
   • 各科目の 諸表区分 / 大分類 / 有効フラグ を確認（AccountRepository.findAsMap() が 有効フラグ=FALSE をスキップ・202_repository.js L329-330）。
3. 32_wrk_invoice シート：
   • 既存データで 申請種別 列に格納されている実値を確認。"請求書受領(AP)" が実データと DDL 定義（SHEET_DEFAULTS L85）の両方で一致していることを目視確認。他の申請種別値（経費申請(EX) 等）が混在している場合、本案件の AI-OCR は「請求書受領(AP)」固定で起票する方針を確定させる。
4. 01_sys_config シート：
   • 既存の WRK_ORDR / WRK_INVC / WRK_BANK / WRK_RCPT / WRK_BANK_IMPORT 等の登録行を確認し、WRK_OCRQ 追加時の列構成（論理キー / シート ID / シート名 / 説明）を他エントリと揃える。
5. Gemini API キー / GCP プロジェクト ID：
   • dev 環境で Env.geminiApiKey() と Env.gcpProjectId() が設定済みかを確認。未設定時の挙動（MAS-216 並行稼働で gcpProjectId() 空なら AI Studio 直叩きにフォールバック）が自動起票でも期待どおりか動作検証する。

関連ドキュメント

人間が検討すべき事項

TODO_future.md MAS-180 行（L437）から転記:

• Gemini API の利用料・レート制限。自動起票では OCR 呼出回数が増えるため上限超過リスクあり。MAS-216 で Vertex 移行時は別コスト体系。
• プロンプトチューニングの工数。本案件の「最終ページの合計金額のみ返す」プロンプトと既存「ページごと 1 JSON」プロンプトの 2 系統併存による保守負荷。

本調査で追加判明した事項:

1. 確認キュー 36_wrk_ocr_queue のレビュー UI 設計：シート直接編集（本案件のデフォルト）／サイドバー UI（MAS-161 連携）／Google Form の 3 案。シート直接編集は最小工数だが、T 番号・金額のバリデーションを onEdit で組み込むか検討要（MAS-128 承認ワークフロー参照）。
2. 証憑ファイルの保存先フォルダ管理：Env.receiptFolderId()（001_env.js）の運用方針。自動起票は既存フォルダと統合か、専用フォルダを分離するか。MAS-152（電帳法リネーム）と統合時のフォルダ構造（processed/YYYY-MM/ 型）との整合。
3. インボイス番号（T 番号）の連携：32_wrk_invoice.税区分 は現状 "課税" / "非課税" / "対象外" の 3 値だが、T 番号の有無で「適格請求書」判定を 42_trn_journal.税区分コード に連携するか。MAS-114（インボイス検証）との連携スコープ。
4. 処理済みハッシュの永続化先：本案件は 36_wrk_ocr_queue.ファイルMD5 列を唯一ソースとするが、シートが肥大化するため 03_sys_params or 99_cache_* シートへのキャッシュ化も将来検討。MAS-133（年度跨ぎアーカイブ）との整合。
5. 自動起票ルートと既存 35_wrk_receipt ルートの責務分離：importReceiptPdfs は 35_wrk_receipt 経由の消込ルート、本案件は 32_wrk_invoice 経由の INV 起票ルート。両方が同一 Drive フォルダを処理する場合の重複実行制御（MD5 の相互参照要否）は、将来パイプライン統合時に判断。
6. 申請種別 の APL_xxx 正規化案件との切り分け：CLAUDE.md は APL_xxx コード統一を将来方針として記述しているが、本案件は現行実データ "請求書受領(AP)" に合わせる。別案件として APL_xxx マイグレーションが立ち上がる場合、本案件の固定値もその時点で移行する。
7. MAS-203（AI プロンプトライブラリの版管理）との連携：本案件で追加する「最終ページ合計のみ返せ」プロンプトを RECEIPT_GEMINI_PROMPT_ とは別定数とするが、MAS-203 実装時には外部管理（シート or docs/prompts/）に移行する前提で、ファイル内定数として命名規則 RECEIPT_AUTO_POSTING_GEMINI_PROMPT_V1_ 等で版管理の余地を残す。
8. 低信頼度キューの自動レビュー強化：現状は単純な必須フィールド充足＋金額整合＋マスタ照合の 3 条件だが、将来的には Gemini の confidence スコア取得（プロンプト側で要求）や Document AI 併用（MAS-147 v2 参照）への拡張余地。

実装プロンプト（Claude Code 用）

あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者です。
案件 MAS-180「AI-OCR連携による証憑自動起票」を以下の Step に分けて実装してください。

## 実行前タスク
- `500_import/502_receipt_reader.js` L22-185 の `importReceiptPdfs()`、L194-269 の `callGeminiForReceipt_()`、L278-323 の `parseGeminiReceiptText_()`、L416-521 の `callGeminiForReceiptOnVertex_()` を Read で確認（既存関数は変更しない）
- `100_config/101_sys_config.js` L323-350 の `onOpen()`（`Constants.MENU_DEFINITION` を動的ループする構造）、L820-823 の `01_sys_config` `appendRow` 登録パターン、L826-901 の `schemas` オブジェクト定義パターンを Read で確認（メニュー実体は `000_infra/002_constants.js` 側）
- `000_infra/002_constants.js` L73-87 の `SHEET_DEFAULTS`（オブジェクト配列 `{ pattern, prefix?, defaults, _dynamic? }`）、L93-112 の `ID_PREFIX_MAP`（`{ pattern, prefix, digit, isDate }`）、L206-324 の `MENU_DEFINITION`（特に L268-280 の「📋 サイドバー: 🔍 消込・マッチング」カテゴリ）を Read で確認してからエントリを追加する（失敗パターン #18・#20 参照）
- `000_infra/003_contracts.js` L40-67 の `InvoiceDTO` 全フィールド定義を Read で確認
- `200_data/202_repository.js` L149-207 の `InvoiceRepository.append()` 内部処理（`AccountRepository.findAsMap()` で科目マスタから `諸表区分`・`大分類` を自動付与、`PJ名` 未指定時に `'指定なし_共通費など'` をデフォルト）、L304-341 の `AccountRepository.findAsMap()` を Read で確認
- `000_infra/004_utils.js` L467-475 の `aiSuggestAccount(text)`、L657-680 の `normalizePartnerName(rawName)`、L482-487 の `getIdPrefixConfig(sheetName)` を Read で確認
- `32_wrk_invoice` の `申請種別` 列の実データ値を GAS ログ（または MCP で実シート値）で確認し、`"請求書受領(AP)"` が実データでも DDL 定義でも一致していることを確定させる

## 修正対象ファイル
- `500_import/502_receipt_reader.js`（末尾に関数追加のみ。既存関数は一切変更しない）
- `100_config/101_sys_config.js`（`setupAllSchemas()` 内の `schemas` オブジェクトに `WRK_OCRQ` キーを追加、同関数内の `01_sys_config` 登録ブロックに `appendRow` を追加。それ以外は変更しない）
- `000_infra/002_constants.js`（`SHEET_DEFAULTS` / `ID_PREFIX_MAP` / `MENU_DEFINITION` の 3 配列への追記のみ）

## Step 1: 36_wrk_ocr_queue シートの新設
- `101_sys_config.js` L820-823 パターンに倣い `01_sys_config` へ `WRK_OCRQ` システムキーを登録: `if (!existKeys.includes('WRK_OCRQ')) confSheet.appendRow(['WRK_OCRQ', '', '36_wrk_ocr_queue', 'AI-OCR確認キュー']);`
- `101_sys_config.js` L826-901 の `schemas` オブジェクトに `'WRK_OCRQ': { headers: [...], color: "#38761d" }` を追加。列構成は仕様書「`36_wrk_ocr_queue` の列構成」に従う（18 列：OCQ_ID / ステータス / 元ファイル名 / ファイルMD5 / 信頼度スコア / OCR生データ_JSON / 取引先名_OCR生値 / 取引先名_正規化後 / 発生日_OCR / 税抜金額_OCR / 消費税額_OCR / 税込金額_OCR / インボイス番号_OCR / 科目名_推論 / 起票済INV_ID / エラー内容 / 起票日時 / 起票者）
- `002_constants.js` L93-112 の `ID_PREFIX_MAP` に `{ pattern: '36_wrk_ocr_queue', prefix: 'OCQ_', digit: 4, isDate: true }` を追加
- `002_constants.js` L73-87 の `SHEET_DEFAULTS` に `{ pattern: '36_wrk_ocr_queue', defaults: { 'ステータス': '要確認' } }` を追加（L85 `32_wrk_invoice` エントリと同じ `{ pattern, defaults }` オブジェクト型）
- DDL を dev で実行して `36_wrk_ocr_queue` シートが 18 列で作成されることを確認

## Step 2: OCR パイプライン関数の実装
- `502_receipt_reader.js` の末尾に以下の関数を追加（既存関数は一切変更しない）:
  - `importReceiptPdfsAutoPosting()` — メニュー起点
  - 内部ヘルパー: `computeFileMd5_(blob)` / `isOcrQueueDuplicate_(md5)` / `evaluateConfidence_(extracted, normalizedVendor, suggestedAcct, accountMap)` / `buildInvoiceDtoFromOcr_(extracted, normalizedVendor, suggestedAcct, driveLink)` / `appendToOcrQueue_(sheet, ocqId, row)`
- `LockService.getScriptLock().waitLock(30000)` で排他制御。`try/catch` で捕捉し `SpreadsheetApp.getActive().toast('他の処理実行中のため中断', 'AI-OCR', 5)` で終了。`finally { lock.releaseLock(); }` を必ず付ける
- MD5 計算: `Utilities.computeDigest(Utilities.DigestAlgorithm.MD5, blob.getBytes())` の戻り値 `byte[]` を 16 進文字列化（既存 `35_wrk_receipt` 処理にはない新規ヘルパー）
- 重複判定: `36_wrk_ocr_queue.ファイルMD5` 列の全件読み取り → 一致時は `Utils.logInfo('importReceiptPdfsAutoPosting', '処理済みスキップ: ' + fileName)` でログしてスキップ
- Gemini 呼び出し: 既存 `callGeminiForReceipt_(apiKey, base64, fileName)` を再利用（MAS-216 の Vertex 分岐が自動で効く）。ただし本自動起票ルートでは「最終ページの合計金額のみを 1 件で返す」新規プロンプト（例: `RECEIPT_AUTO_POSTING_GEMINI_PROMPT_V1_`）を別定数として定義し、既存 `callGeminiForReceipt_` を呼び出す前に引数で差し替える形にはせず、**新規内部関数 `callGeminiForAutoPosting_(apiKey, base64, fileName)` を別途実装**する（既存関数の一字一句不変を担保）。実装は `callGeminiForReceipt_` を参考に、プロンプト部分のみ差し替え・Backoff ロジックは同一ロジックで複製
- 正規化: `Utils.normalizePartnerName(extracted.vendor)` / `Utils.aiSuggestAccount((extracted.description || '') + ' ' + (extracted.vendor || ''))`
- 信頼度判定「高」: (1) `totalAmount > 0` かつ `subtotal > 0` かつ `tax >= 0`、(2) `accrualDate` が YYYY-MM-DD 形式、(3) `invoiceNumber` が `/^T\d{13}$/` に一致、(4) `normalizedVendor` が空でない、(5) `suggestedAcct` が空でなくかつ `AccountRepository.findAsMap()[suggestedAcct]` が存在、(6) `Math.abs((subtotal + tax) - totalAmount) <= 1`
- 高信頼度 → `buildInvoiceDtoFromOcr_` で `InvoiceDTO` を構築し `InvoiceRepository.append([dto])` で起票。同時に `36_wrk_ocr_queue` へ `ステータス: 起票済`・`起票済INV_ID: <新 INV_ID>` で記録
- 低信頼度 → `36_wrk_ocr_queue` へ `ステータス: 要確認`・`エラー内容: <具体理由>` で登録
- `InvoiceDTO` の `申請種別` は文字列リテラル `"請求書受領(AP)"` を直接指定する（`SHEET_DEFAULTS` のデフォルトに依存しない。明示指定で将来のデフォルト変更にも堅牢）

## Step 3: 確認キューからの手動起票メニュー追加
- `002_constants.js` L268-280 の「📋 サイドバー: 🔍 消込・マッチング」カテゴリの `items` 配列末尾（既存 `importReceiptPdfs` / `importReceiptStatement` / `applyReceiptSettlement` の後）に以下 2 項目を追加:
  - `{ label: '🤖 AI-OCR 自動起票 (Drive)', funcName: 'importReceiptPdfsAutoPosting', description: 'Drive の PDF/画像を Gemini OCR で読み取り、32_wrk_invoice に自動起票（低信頼度は 36_wrk_ocr_queue）' }`
  - `{ label: '✅ 確認キューから INV 起票', funcName: 'postApprovedOcrQueueRows', description: '36_wrk_ocr_queue の選択行（ステータス=修正済）を 32_wrk_invoice に起票' }`
- `502_receipt_reader.js` の末尾に `postApprovedOcrQueueRows()` を追加:
  - `SpreadsheetApp.getActiveSheet().getName()` が `36_wrk_ocr_queue` でなければ `ui.alert('シート違い', '36_wrk_ocr_queue シートで実行してください', ...)` で終了
  - `SpreadsheetApp.getActiveRange()` の行範囲を取得し、`ステータス === '修正済'` のみを対象化
  - 各行から `InvoiceDTO` を構築し、金額整合性（`税抜 + 税 = 税込`）を再検証。不整合は起票拒否しエラー表示
  - `InvoiceRepository.append(dtos)` で起票 → 当該行の `ステータス` を `起票済`・`起票済INV_ID` に新 INV_ID を書き込み
  - Toast で件数（起票成功・スキップ・エラーの内訳）通知

## 制約
- 既存の `importReceiptPdfs` / `callGeminiForReceipt_` / `parseGeminiReceiptText_` / `postProcessReceiptData_` / `callGeminiForReceiptOnVertex_` は**一字一句変更しない**（MAS-216 並行稼働の既存挙動を守るため）
- `RECEIPT_GEMINI_PROMPT_` 定数（L10-14）は変更禁止。本案件用のプロンプトは別定数 `RECEIPT_AUTO_POSTING_GEMINI_PROMPT_V1_` として追加
- `501_cc_importer.js` / `502_bank_importer.js` / `504_invoice_importer.js` は変更対象外
- 科目名には必ず `AccountRepository.findAsMap()[name]` が存在するものだけを渡す。未登録科目の自動起票は禁止（低信頼度で確認キュー送り）
- `SHEET_DEFAULTS` と `ID_PREFIX_MAP` の型は必ず Read で確認してから追加する（#18 失敗パターン参照）
- `MENU_DEFINITION` に追加するメニュー文字列・カテゴリ名は既存エントリ（L274 `'📄 領収書PDF読込 (Drive)'` 等）の表記を参照し造語しない（#20 失敗パターン参照）
- `onOpen()` 本体（`101_sys_config.js` L323-350）は変更しない。メニュー実体の更新は `MENU_DEFINITION` 側のみ

## エッジケース
仕様書「エッジケース」セクションのテーブルに従って実装すること。特に以下を必ず実装する:
- 金額不整合（`|税抜 + 税 - 税込| > 1`）→ 自動起票せず `36_wrk_ocr_queue` に `要確認` で登録
- 同一ファイル MD5 一致 → 即スキップ + ログ出力
- `LockService.waitLock` タイムアウト → Toast 通知して終了・キュー登録なし
- T 番号未検出（`/^T\d{13}$/` 不一致）→ 低信頼度扱い
- 科目推論結果が `11_mst_account` 未登録 → 低信頼度扱い
- `36_wrk_ocr_queue` シート未作成 → `getSheetByKey` が null → `setupAllSchemas` 実行を促すアラート

## 実データ検証
実装前に仕様書「実データ検証」セクションの 5 項目を MCP または GAS ログで全て確認すること。
特に以下 2 点は自動起票の失敗を未然に防ぐため必須:
- `Utils.aiSuggestAccount` が返す全 18 科目（`Constants.ACCOUNT_RULES` L117-136）が `11_mst_account` に登録済みか（未登録があれば `migrationD01D03` で追加）
- `32_wrk_invoice.申請種別` 列に `"請求書受領(AP)"` の実データが存在し、DDL 定義と一致していること

## 動作確認
1. `npm run push:dev` でデプロイ
2. `📋 サイドバー: 🔧 開発・設定 → DDL 全更新 (Full)` を実行し `36_wrk_ocr_queue` が 18 列で作成されることを確認
3. `01_sys_config` に `WRK_OCRQ` 行が追加されていることを確認
4. dev の `Env.receiptFolderId()` 配下にテスト証憑（以下 4 パターン）を投入:
   - A: 鮮明な請求書（T 番号あり・金額整合・科目推論可能）
   - B: 不鮮明な請求書（T 番号なし）
   - C: 金額不整合（`subtotal + tax ≠ totalAmount`）
   - D: A と同一ファイル（再実行による MD5 一致テスト）
5. `🤖 AI-OCR 自動起票 (Drive)` メニューを実行
6. 期待結果:
   - A: `32_wrk_invoice` に 1 行追加（`諸表区分`・`大分類` が科目マスタから自動付与、`申請種別=請求書受領(AP)`）、`36_wrk_ocr_queue` に `ステータス: 起票済`・`起票済INV_ID` が記録
   - B: `36_wrk_ocr_queue` に `ステータス: 要確認`・`エラー内容: T 番号形式不正`、`32_wrk_invoice` 無変化
   - C: `36_wrk_ocr_queue` に `ステータス: 要確認`・`エラー内容: 金額不整合`、`32_wrk_invoice` 無変化
   - D: ログに `処理済みスキップ: <fileName>`、`36_wrk_ocr_queue` 行追加なし
7. B の行の誤読項目を手動修正 → `ステータス` を `修正済` に変更 → 該当行を選択
8. `✅ 確認キューから INV 起票` メニューを実行 → `32_wrk_invoice` に 1 行追加、`36_wrk_ocr_queue` の `ステータス: 起票済`・`起票済INV_ID` が更新されることを確認
9. `LockService` 動作確認: 2 タブで同時にメニュー実行 → 後発側が `他の処理実行中のため中断` の Toast で終了することを確認
10. `901_test_runner.js` に MAS-180 の結合テストケース（高信頼度自動起票・低信頼度キュー登録・MD5 重複スキップ・確認キュー起票）を追加して実行

### 拡張思考の使用状況
| フェーズ | 拡張思考 | 備考 |
|---------|---------|------|
| Phase 1（調査・設計） | あり | ファイル名（`502_receipt_reader.js` と `502_bank_importer.js` の重複解消）・`申請種別` 実データ値確認・`36_wrk_ocr_queue` 列構成確定に使用 |
| Phase 2（実装） | 最小限 | Phase 1 で確定した内容の実装に徹する |

推奨実行モデル

変更履歴

仕様書作成プロンプト（再現性・監査性のため必ず記録）

<instruction>
【タイムアウト回避・実行原則（v1.7・必ず遵守すること）】
1. **拡張思考の使い分け**: Phase 1（設計・調査）では拡張思考をフル活用し、ファイル名・行番号・固有名詞（関数名/シート名/列名）を完全に確定させる。Phase 2（清書）では各 Step 内の拡張思考を最小限に抑え、Phase 1 で確定した内容の書き下しに徹する。出力途中で再考しない。
2. **テキスト報告の禁止**: 「〜を作成します」等の text のみで tool_use なしに turn を終了しない。説明は 1 文以内。直ちに tool を呼ぶ。
3. **4-5 分割の Write/Edit 実行**: Step 2-1(骨格 ~20行) / 2-2(概要〜注意事項 ~300行) / 2-3a(エッジケース〜人間検討事項 ~200行) / 2-3b(実装プロンプト〜変更履歴 ~250行) / 2-4(<details>プロンプト全文記録) に分割。1 回の Write/Edit は 300 行以内を目安にする。
4. **各 Step で何を書くかを具体指示**: 設計判断は Phase 1 で完全に確定させ、Phase 2 では判断を持ち込まない。

======================================================================
あなたはGAS会計システム(bizlp-gas-accounting)のシニア開発者兼仕様書ライターです。
案件 N-04「AI-OCR連携による証憑自動起票」の開発仕様書を作成してください。
作成完了後は `docs/_config.json` の `nav` 配列の適切なセクションに必ず追記してください。

---

## Phase 1: 実行前タスク（テキスト報告禁止。即座にツール実行）

**Grep は「どこにあるか」の発見まで。「どう書くか」の判断は必ず Read で裏取りすること（失敗パターン #18-#20 の直接対策）。推測した瞬間に手を止めて Read する。**

### 1-A: 案件定義の読み込み

- `docs/_internal/TODO_future.md` を検索し、`MAS-180` の「案件名」「概要」「期待される効果」「人間が検討すべき事項」を取得する。

### 1-B: プロジェクト規約の読み込み

- `CLAUDE.md` を Read し、コーディング規約・ファイル番号体系・マイグレーション運用ガイドライン（800_ops/ への配置ルール、冪等性要件）・`申請種別コード（APL_xxx）`の仕様を把握する。

### 1-C: 既存仕様書テンプレートの読み込み

- `docs/_internal/dev_spec_prompt_template.md` の「Phase 2: 仕様書の作成」セクション構成と「実装プロンプトのフォーマット」を Read し、出力する仕様書がこの構成に完全準拠するようにする。
- `docs/dev/` 配下から外部連携・インポート系の既存仕様書を 1 件 Grep で探して Read し、フォーマットを把握する。

### 1-D: 関連コードの調査（以下を全て Read/Bash で裏取りすること）

**① 既存 OCR ファイルの特定（ファイル名確定が最優先）**

```bash
ls 500_import/

# MAS-180: AI-OCR連携による証憑自動起票
## 概要
## 目的
## 現在のコード
## 修正方針
## 影響範囲
## 注意事項
## エッジケース
## 実データ検証
## 関連ドキュメント
## 人間が検討すべき事項
## 実装プロンプト（Claude Code 用）
## 推奨実行モデル
## 変更履歴
## 仕様書作成プロンプト（再現性・監査性のため必ず記録）

<details><summary>展開して表示</summary>

（この <instruction> プロンプトの全文をそのまま貼り付ける）

</details>

{ "file": "dev/dev_mas-180_ai_ocr_enhancement.md", "title": "E.6.X MAS-180 AI-OCR連携による証憑自動起票" }

</details>