Decision Pipeline Test Cases

⚠️ Status: Retired (Dify Phase, 2026-05-08, ADR-0019) LangGraph 版テスト: node drp/test-tc.mjs で TC-01〜07 を全自動実行 (OpenAI API 直接呼び出し、LiteLLM / Docker 不要)。

Phase 1 のプロンプト検証用テストケース集（Dify 版 — 退役済）。LangGraph 版では同等のテストケースを test.sh で実行する。

使い方

1. Dify のチャット UI で各ケースの Input をコピペ
2. Expected (Triage) と実際の出力を比較
3. ズレが出た場合は prompts/01_triage.md または prompts/02_scoring.md を改訂し、バージョンを上げる
4. 結果は Result Log セクションに追記

TC-01: 自明なバグ修正（対象外を確認）

Input:

README の typo を修正したい（「会計」が「会經」になっている）

Expected (Triage):

• is_adr_worthy: false
• reason に「typo 修正は判断要素を含まない」旨

TC-02: UI 微調整（対象外を確認）

Input:

ヘッダーの背景色を白からライトグレーに変えてコントラストを下げたい。デザインシステムの secondary 系内の変更。

Expected (Triage):

• is_adr_worthy: false

TC-03: ライブラリ選択（Light を確認）

Input:

GAS 内の日付フォーマット処理に dayjs ではなく Luxon を使いたい。理由はタイムゾーン処理のバグが少ないと感じるから。

Expected (Triage):

• is_adr_worthy: true
• mode: "Light"

Expected (Scoring on minimal draft):

• 不合格（35 点未満想定）
• 弱い項目: 2_alternatives / 3_decision_criteria / 8_cost_estimate

TC-04: マスタスキーマ拡張（Standard を確認）

Input:

11_mst_account に「税効果科目フラグ」列を追加したい。法人税申告書作成のフェーズで税効果会計の対象科目を抽出する必要が出てきたため。

Expected (Triage):

• is_adr_worthy: true
• mode: "Standard"

TC-05: 仕訳ロジック緩和（Critical を確認）

Input:

Action B のバリデーションで「決済日 < INV 発生日」を弾いているが、前払い扱いの請求書については通したい。具体的には支払期限が発生日より前のケース。

Expected (Triage):

• is_adr_worthy: true
• mode: "Critical"
• 過去 ADR の整合性確認が必要な旨が reason に出る（ボーナス）

TC-06: 雑な起案ドラフト（不合格を確認）

Input (ADR Draft):

# ADR-0099: ADR ストアに DynamoDB を採用

## 背景
ADR をテキストファイルで管理しているが管理が大変になってきた。

## 決定
DynamoDB を使う。サーバレスでスケールするので良いと思う。

## 結果
うまく管理できるようになる。

Expected (Scoring, mode=Standard):

• total < 25
• pass: false
• weakest_items に 2_alternatives 3_decision_criteria 6_operational_pitfalls 7_rollback_strategy 9_completion_criteria 10_long_term_impact のうち複数

TC-07: 高品質な起案ドラフト（合格を確認）

Input (ADR Draft):

# ADR-0042: 領収書 OCR を Gemini 2.0 から Claude Haiku 4.5 へ移行

Status: Proposed
Decision Owner: 代表取締役
Review After: 2026-11-04
Mode: Critical

## 背景
2026 年 3 月時点で領収書 OCR 月次処理量が 1,200 件/月、Gemini 2.0 利用料 約 $18/月、誤読率 4.7%（社内サンプル 250 件で測定）。誤読のうち 60% が手書き混在領収書で、再入力工数は月 8 時間に達している。

## 決定
領収書 OCR 経路を Gemini 2.0 から Claude Haiku 4.5 へ切り替える。`mas/500_import/502_receipt_reader.js` の API クライアント部のみ差し替え、データ契約 (`Contracts.Receipt`) は変更しない。

## 代替案
1. **Gemini 2.5 Flash へアップグレード**: 既存実装変更最小だが、社内ベンチで誤読率 3.8%、改善幅が限定的。却下。
2. **Vertex AI Document AI**: 精度は最高だが、月額固定費 $300〜 + GCP 認証統合コストで ROI が成立しない。却下。
3. **(採用) Claude Haiku 4.5**: 社内ベンチで誤読率 1.9%、料金 約 $14/月、既存 Anthropic SDK 流用可。

## 判断基準
- 精度（誤読率）: 重み 50%
- ランニングコスト: 重み 25%
- 実装/移行工数: 重み 25%

## 過去 ADR 整合性
- ADR-0021「外部 AI API 利用方針」と整合（Anthropic 系を主軸とする方針に合致）
- ADR-0033「OCR コンポーネントの抽象化」が前提となるため Supersede ではなく拡張

## 影響範囲
- ファイル: `mas/500_import/502_receipt_reader.js`, `mas/appsscript.json`（依存追加）
- データ: 既存読取結果との互換性を保つため Contracts は不変
- ステークホルダー: 経理オペ（読取後の確認 UI は不変）

## 運用上の罠
- 旧 OCR が読めていた特定フォーマット（JR 領収書の縦書き）が Claude で精度劣化する可能性あり。切替前に該当 50 件で並行検証する
- API レート制限（Tier 上限）を超える可能性。月初にバッチ集中する運用を分散実行に変更する
- 監視: `503_ocr_metrics.js` を新設し、誤読率を週次で 91_fs_bs シートにログする

## ロールバック
- 環境変数 `OCR_PROVIDER` で `gemini` / `claude` を切替可能にする
- 切替後 4 週間は両方の API キーを保持。誤読率が 2.5% を超えたら自動で `gemini` に戻す監視ジョブを併設

## コスト試算
- 初期実装: 3 人日（API クライアント差替・並行検証・監視追加）
- 運用: $14/月（Gemini より $4 削減）
- 移行コスト: 並行検証期間 2 週間で $32 の重複費用

## 完了条件
- [ ] 並行検証期間 2 週間で誤読率 < 2.5% を達成
- [ ] 経理オペからの再入力工数報告が月 4 時間未満
- [ ] 監視ジョブが週次でログ出力されている

## 長期的影響
- Anthropic 価格改定リスク: Review After 2026-11-04 で再評価
- 将来 Claude Sonnet/Opus への切替も同経路で可能（マルチモデルルーティングは ADR-0044 で別途）

Expected (Scoring, mode=Critical):

• total >= 45
• pass: true
• feedback_for_user は称賛 + 軽微な改善余地（あれば）

TC-08: ボーダーライン（38〜42 点想定）

Input:

# ADR: 月次バッチを GAS から Cloud Run へ移行

## 背景
月次の財務諸表バッチが 6 分タイムアウト寸前まで膨らんでいる。

## 決定
Cloud Run に移行する。GAS のままでは限界。

## 代替案
- GAS のままバッチ分割: 分割境界の設計が複雑になりそうなので却下。
- BigQuery Scheduled Query: SQL で書けるロジックではないため却下。

## 判断基準
- 実行時間制限の余裕
- コスト

## 影響範囲
- 600_report 配下の月次集計
- GitHub Actions のデプロイフロー

## ロールバック
GAS 版を残しておけば戻せる。

## コスト
工数 7 人日、Cloud Run は月 $5 程度の見込み。

## 完了条件
全社月次バッチが安定して 10 分以内に完走すること。

Expected (Scoring, mode=Standard):

• total が 35〜42 点付近
• weakest_items に 6_operational_pitfalls または 10_long_term_impact

Phase 1 実測 (2026-05-07):

• total: 14（期待値外）
• 原因: 入力ドラフトに「過去 ADR」「運用罠」「長期影響」の 3 項目が完全欠落しており、ルーブリック「0 = 完全欠落」適用で 0 点が 3 項目発生
• 判断: ルーブリック方針 A（厳格維持）を採用したため、期待値側を見直すことが妥当
• v0.3 で「真のボーダーライン」入力（全項目を最低限埋めた浅いドラフト）を新規 TC として追加検討

Result Log

各テストケースを実行した結果を以下に追記する。