← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0007type: adrstatus: accepted
pagemode: Standard (内容から推定・旧 README 一覧より移設)kruchten: Executivescope: productimplementation_status: Done (Gemini OCR 運用中、ADR-0008 で Vertex…business: mas
型付き辺: 出 2 / 入 1
関連: ADR-0009 ADR-0008 部分修正された: ADR-0008全体は INDEX →

ADR-0007: Gemini APIを領収書解析に使用する判断

  • Status: Accepted (旧形式「## ステータス: 採用済み」より転記)
  • Mode: Standard (内容から推定・旧 README 一覧より移設)
  • Kruchten Type: Executive
  • Scope: product
  • Implementation Status: Done (Gemini OCR 運用中、ADR-0008 で Vertex AI 集約検討中)

Kruchten Type は ADR-0031 (2026-05-13) で遡及追加。分類根拠は ADR-0031 §決定セクションおよび docs/adr/README.md の Kruchten 3 分類ガイドを参照。 Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。

ステータス: 採用済み

コンテキスト

PDF領収書から情報を抽出し構造化データに変換する必要があった。以下の選択肢があった:

  • 案A: OCR専用サービス（Google Vision API / Document AI等）で文字認識後、ルールベースで抽出
  • 案B: LLM API（Google Gemini）でPDFを直接解析し、構造化データに変換

GAS環境から呼び出し可能であることが前提条件。

決定

案B を採用する。 Google Gemini APIを使用してPDF領収書を構造化データに変換する。

理由

  1. GAS環境との親和性が高い（Google系APIのため認証・呼び出しが容易）
  2. 非定形フォーマットの領収書にも柔軟に対応でき、テンプレートごとのパーサー開発が不要
  3. プロンプトで抽出ルールを調整可能なため、要件変更時のコード改修が最小限
  4. Vision APIはOCR結果のみで、項目の意味解釈（税区分判定等）には追加ロジックが必要

結果・影響

  • ポジティブ: 非定形フォーマットの柔軟な解析。プロンプト調整で抽出ルール変更可能。Google系APIとの統合が容易
  • ネガティブ: API応答の非決定性（同じPDFで異なる結果の可能性）。コスト変動リスク。レート制限への対処が必要
  • 技術的負債: 解析精度の検証が手動であり、回帰テスト（既知PDFの期待値比較）の仕組みが未整備

補足決定: Gemini / Claude ハイブリッド戦略（2026-04-15 追記）

コンテキスト

MAS-147（請求書OCR→INV起票）、MAS-150（ドキュメント読込→AIルーティング→20番台自動起票）、MAS-157（写真OCR）等の将来案件で、ドキュメントの複雑さに応じて最適な AI モデルを選択する必要が出てきた。

比較評価

観点Gemini (Flash)Claude (Sonnet)
定型的な領収書・CC明細の読取◎ 十分な精度◎ やや上だがオーバースペック
複雑なドキュメント（契約書・多ページ請求書）△ レイアウト崩れに弱い◎ 推論力が活きる
構造化出力（JSON）の安定性○ たまに形式崩れ◎ 指示通りに安定
「読み取り→判断」の複合タスク△ 抽出は得意だが判断は弱い◎ MAS-150 Mode B のルーティング判定に適する
コスト◎ 圧倒的に安い△ Flash の数倍
速度◎ 速い○ やや遅い
GAS との統合◎ Drive ファイル参照を直接渡せる△ UrlFetchApp + Base64 エンコードが必要

決定

Gemini をメインに据え、複雑なドキュメントや判定精度が必要な場面で Claude にフォールバックするハイブリッド構成を採用する。

ユースケース採用モデル理由
領収書PDF読取（502_receipt_reader.js 既存）Gemini Flash現行稼働中。精度十分。コスト最小
写真OCR（MAS-157）Gemini FlashMIMEタイプ拡張のみ。Gemini は画像入力対応済み
カード明細マッチング（MAS-146）（AI不要）ルールベースマッチングで十分
請求書PDF→INV起票（MAS-147）Gemini Flash → Claude フォールバック単純な請求書は Gemini、多ページ・複雑レイアウトは Claude
ドキュメント→20番台ルーティング（MAS-150 Mode B）Claude「どのタブに起票すべきか」の判定は推論力が必要
OCR精度強化（MAS-180）Gemini + Claude 併用Gemini で一次抽出→信頼度低の場合に Claude で再抽出

実装方針

  • 502_receipt_reader.js の callGeminiForReceipt_() は変更しない（Gemini メイン維持）
  • Claude API 呼び出し用の共通ヘルパー callClaudeApi_() を 000_infra/004_utils.js に追加
  • API キーは Env.claudeApiKey() で取得（スクリプトプロパティ CLAUDE_API_KEY）
  • フォールバック判定基準: Gemini の応答で JSON パースに失敗 or 必須フィールドが空欄の場合に Claude で再試行

2026-04-20 追補: 本番の AI API 呼び出し先は Vertex AI (GCP) に集約する方針に変更。上記の callClaudeApi_() 実装および 502_receipt_reader.js の Gemini 呼び出しは、いずれも Vertex AI 経由の実装に置き換わる。詳細は ADR-0008: 本番 AI API を Vertex AI に集約 を参照。

Confirmation (準拠確認 / Fitness Function)

本セクションは ADR-0036 (Accepted 2026-05-14) で遡及追加された。ADR-0031 パターン (業界標準準拠メタデータ後付け = 誤字修正範疇) に準拠する遡及で本文の意思決定内容は不変。

  • 検証手段: N/A — 要マッピング更新 (ADR-0036 遡及時点で未定義、月次レビューで確定)
  • 実行頻度: —
  • 違反時の対応: —