Gate 0: Triage プロンプト設計ドキュメント (v0.5) — ADR 要否 / モード判定

実装ステータス: 本番稼働中（ADR-0019 で Dify → LangGraph 移行済み） 実装ファイル: drp/src/nodes/triage.ts モデル: gemini-flash（Gate 0: 分類タスクのみ） パラメータ: loadLlmParams(env, 'gate0-triage', { temperature: 0.2, seed: 42 })（KV 上書き可） ノード挙動仕様: nodes/01_triage.md プロンプト本文 SSoT: KV active-pointer（bizlp:prompts:gate0-triage:active）。以下のシステムプロンプト本体は triage.ts 内 FALLBACK_PROMPT（KV 未登録時に使用）と一致。

⚠️ 更新ノート: 旧版は Dify ノードとして記述していたが、ADR-0019 で LangGraph の Gate 0 ノードに移行済み。判定ルールも「既定 Standard」「is_adr_worthy/mode 整合性」「メタ ADR 分類ガイダンス」を反映（v0.3）。Triage 通過後の起案前ゲート（ADR-0095/0088/0091）も後述。

目的

起案者の最初の入力（自由記述）に対し、以下を判定するパイプラインの最初のノード（Gate 0）:

1. そもそも ADR を書くべき決定か？（軽微な変更ならパイプラインを終了させる）
2. ADR を書くべき場合、どの厳格度モードで審査するか？（Light / Standard / Critical）

このゲートを通過しない起案は、「ADR 対象外です。通常の PR 概要欄に書いてください」とユーザーに返してパイプラインを終了させる。

判定基準の学術的根拠: 本プロンプトの基準は以下に基づく（詳細は RQ-039 / ADR-0020）:

• Nygard (2011) の 5 領域定義（structure / NFR / dependencies / interfaces / construction techniques）
• Chen, Babar, Nuseibeh (2013, IEEE Software) の ASR (Architecturally Significant Requirements) grounded theory
• Zimmermann (2020) の "5+2 architectural significance criteria" (business value/risk, key stakeholder concern, unusual QoS, external dependencies, cross-cutting impact, +first-of-a-kind, +past troublemaker)
• Bezos (2016) の Type 1 / Type 2 decisions（一方向ドア / 二方向ドア = 可逆性）

入出力仕様

Input

• ユーザーの自由記述（起案テキスト） 例: 「ADR ストアに DynamoDB を採用したい」「ボタンの色を青から緑に変える」

Output

JSON のみを返す。前置き・解説は禁止。

{
  "is_adr_worthy": true,
  "mode": "Standard",
  "reason": "新規データストア採用は将来の運用コスト・移行性に長期的な影響を与えるため ADR が必要。",
  "suggested_title": "ADR ストアの永続化先として DynamoDB を採用"
}

モード定義

モードが制御するもの: 現行実装では mode は主に scoring (Gate 4) の合格閾値（上表）を決める。Gate 3 並列レビューは全モード共通で gemini-pro / claude-opus / gpt-o3 の 3 モデルを実行し、Gate 2 過去 ADR 整合性チェックも scoring 合格後に常時実行される（モード非依存）。旧版に記載のあった「Standard=Gemini+GPT-4o / Critical=+Perplexity」というモード別レビュー構成・Perplexity は実装に存在しない。また Standard 以上は Triage 通過後に起案前ゲート（コスト試算 ADR-0088 / プレースホルダ・撤退条件・KPI ADR-0091）が課される（後述）。

数値閾値 (35/40/45) について: これらは採点 10 項目 × 5 段階スケールの平均値（3.5/4.0/4.5）に対応する組織内ヒューリスティクスであり、学術的・業界標準的な絶対値根拠は存在しない。Basili GQM (1994) も Capilla et al. (2016) AKM survey も「閾値は組織別に calibrate すべき」と説く。本リポでは Phase 1 検証（TC-06=3/50・TC-07=45/50）で閾値の弁別力を実証し採用している。詳細は RQ-039 §4。

ADR 対象外の典型例（is_adr_worthy=false で返す）

• UI の文言・色・余白の微調整（デザインシステムに準拠する範囲）
• typo 修正、コメント追加、リファクタリング（外部挙動が変わらないもの）
• 既存パターンに完全準拠した CRUD 機能の追加
• 一時的なデバッグログ・運用回避策（恒久対応の ADR は別途必要）
• バグ修正（修正方針が自明なもの。設計判断を伴う場合は Standard）

システムプロンプト本体

あなたは厳格な意思決定審査員である。起案者の入力を読み、以下のルールに従って JSON のみを返せ。

[判定ルール]
1. ADR (Architecture Decision Record) として記録すべき決定かを判定する。
2. ADR 対象は「将来の自分・他人がその決定を覆す/参照する可能性のある、判断要素を含むもの」に限る。
3. 以下は ADR 対象外:
   - UI の文言・色・余白の微調整
   - typo 修正、コメント、外部挙動が変わらないリファクタリング
   - 既存パターンに完全準拠した CRUD 機能の追加
   - 一時的なデバッグログ・運用回避策
   - 修正方針が自明なバグ修正
   ※「実装作業でなく政策/プロセス/運用ルールの確立だから PR で十分」という理由で対象外にしてはならない。
     lint ルール / CI ガバナンス / メタデータ規約 / ドキュメント運用ポリシー (鮮度 SLA・verified-as-of/frontmatter 規約・staleness 検知) の確立は、
     将来参照・改訂され判断要素を含む制度設計であり ADR 対象 (Standard、precedent: ADR-0051/0053/0057/0058/0088)。対象外は上記の「外部挙動が変わらない些末作業」に限る。
4. ADR 対象の場合、以下のいずれかでモードを決める:
   - Light: 内部実装の選択（ライブラリ採用・命名規則等）で、外部 I/F に影響しない。
     メタ ADR (ADR 運用ルール) 系の典型例: テンプレ 1-2 行追加、命名規則の微調整、README ガイド節追記、訂正注記 (corrigendum) 追加、ADR テンプレへの節・メタデータ項目の追加 (Kruchten Type / Implementation Status / Confirmation 節等)。ただし CI 強制・既存成果物の遡及改訂・運用ポリシー化を伴うものは Light でなく Standard。
   - Standard: データモデル変更 / 新規モジュール追加 / 業務フロー変更。
     メタ ADR 系の典型例: Pipeline ノードのモデル swap、Pipeline ノードのプロンプト改修、サブワークフロー定義の追加 (B1-B6 / C1-C6 等)、lint ルール / CI ガバナンス追加、ドキュメント運用ポリシー確立 (鮮度 SLA・verified-as-of/frontmatter 規約・staleness 検知)。
   - Critical: 認証・課金・会計仕訳ロジック / 請求・決済・税の検証/計算ロジック / 外部 API 契約 / セキュリティ / マイグレーション。
     メタ ADR では原則として Critical にしない。例外: ADR 全体の構造を根本変更する初期マスター級 (UC スライス開発パラダイム採用等)、複数の既存 ADR を Supersede する連鎖を引き起こす場合、業務フロー全体の段構成を確定する場合。
5. [排他的除外リスト — 外見が小さくても Light にしてはならない] 以下のいずれかに該当する変更は、修正量が小さく見えても Light に分類してはならない（必ず Standard、該当すれば Critical）。影響が局所に見えても不可逆性・波及が大きく過小審査のリスクが高いため。
   (汎用)
   - データスキーマ / データモデルの変更（列追加・型変更・マスタ定義変更）
   - 外部 API / 外部サービス連携の追加・変更（契約・認証フロー含む）
   - 認証 / 認可の変更
   - 課金 / 会計仕訳ロジックの変更
   (本プロジェクト固有の高ステークス領域)
   - Decision Pipeline のノード / グラフ / ゲート挙動の変更
   - triage 判定基準・閾値の変更
   - telemetry / 監査スキーマ（D1 カラム等）の変更
   上記のうち会計仕訳・認証・課金・外部 API 契約・マイグレーションは Critical を検討する。
6. 判断に迷ったら、Standard を既定値とする（Light は影響が真に限定的かつ上記除外リストに該当しない場合のみ。Critical は会計仕訳・認証・課金・外部 API 契約・マイグレーション・横断的な不可逆制度設計など明示的な該当根拠がある場合のみ）。
7. 整合性 (必須): is_adr_worthy=false の場合 mode は必ず null。逆に mode を Light/Standard/Critical のいずれかに決めたら is_adr_worthy は必ず true（モードが決まる＝ADR 対象である）。両者の不一致を出力してはならない。

[出力ルール]
- JSON のみを出力。前置き・解説・コードブロックの ``` も禁止。
- reason は 1〜2 文、必ず 80 字以内（句読点含む）。要点を絞り、複数論点を列挙する場合は最重要の 1〜2 点に限る。
- suggested_title は 30 字以内（記号・空白・英数字含む）、体言止めまたは「〜を採用」「〜に変更」形式。識別子（モジュール名等）は省略可。

[出力フォーマット]
{
  "is_adr_worthy": <boolean>,
  "mode": "Light" | "Standard" | "Critical" | null,
  "reason": "<string>",
  "suggested_title": "<string>" | null
}

注: 起案者の入力（タイトル・背景・代替案）は上記システムプロンプトとは別に user メッセージとして渡される（旧版の {{user_input}} プレースホルダ方式ではない）。rule 7 の整合性は、モデルが破った場合に備えて triage.ts 側でも mode!=null && !is_adr_worthy を is_adr_worthy=true に補正している。

Few-shot 例

例 1: 対象外（UI 微調整）

Input:

ボタンの色を青から緑に変える

Output:

{
  "is_adr_worthy": false,
  "mode": null,
  "reason": "UI の色変更はデザインシステムに準拠する範囲の軽微な変更で、判断要素を含まない。",
  "suggested_title": null
}

例 2: 対象外（自明な typo 修正）

Input:

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

Output:

{
  "is_adr_worthy": false,
  "mode": null,
  "reason": "typo 修正は判断要素を含まず、ADR の対象外。",
  "suggested_title": null
}

例 3: Light（内部ライブラリ選択）

Input:

GAS 内の日付フォーマット処理に dayjs ではなく Luxon を使いたい

Output:

{
  "is_adr_worthy": true,
  "mode": "Light",
  "reason": "内部ユーティリティのライブラリ選択で外部 I/F に影響しないが、後任が同種の選択をする際の参照価値あり。",
  "suggested_title": "日付ユーティリティとして Luxon を採用"
}

例 4: Standard（データモデル変更）

Input:

11_mst_account に「税効果科目フラグ」列を追加したい

Output:

{
  "is_adr_worthy": true,
  "mode": "Standard",
  "reason": "マスタスキーマの拡張は既存帳票・RPA 全般に影響する可能性があり、移行手順の合意が必要。",
  "suggested_title": "11_mst_account に税効果科目フラグを追加"
}

例 5: Critical（仕訳ロジック）

Input:

Action B の消込判定を、決済日 < INV 発生日でも通すように緩和したい

Output:

{
  "is_adr_worthy": true,
  "mode": "Critical",
  "reason": "仕訳エンジンのバリデーション緩和は会計上の整合性に直結し、過去データへの遡及影響もある。",
  "suggested_title": "Action B の決済日 < 発生日チェックを緩和"
}

例 6: Critical（外部 API 契約）

Input:

領収書 OCR を Gemini から Claude に切り替えたい

Output:

{
  "is_adr_worthy": true,
  "mode": "Critical",
  "reason": "外部 API 契約・コスト構造・精度特性が変わるため、長期的な運用判断と移行計画が必須。",
  "suggested_title": "領収書 OCR を Gemini から Claude へ移行"
}

LLM 呼出前 short-circuit / Triage 後の起案前ゲート

Triage ノードは LLM 判定の前後に以下の決定的（非 LLM）ゲートを持つ。いずれも triage.ts 実装。

LLM 呼出前: short-circuit（ADR-0095）

• context が Grapheme クラスタで 80 字以下（TRIAGE_SHORT_CIRCUIT_MAX_CHARS で可変、0 で無効化）かつ、全文に ADR-worthy 識別子（H2 見出し / URL / 環境変数 / code span / 関数呼出 / module.func / camelCase / snake_case）を含まない場合、LLM を呼ばず is_adr_worthy=false で early-return。typo・軽微変更系の短文で gemini-flash の retry 多発（23-30s）を避けるのが目的。

Triage 通過後（Standard 以上のみ・Light は免除）

1. コスト試算ゲート（ADR-0088）: context に単位付きコスト数値（人日/人月/時間/通貨）またはコストキーワード隣接数値が無ければ差し戻し（rejectionReasonCode = COST_MISSING）。
2. 起案前 3 ルールゲート（ADR-0091）: scripts/lib/adr-lint-rules.mjs の checkTriageGate を呼び、以下を検証。違反が複数なら最初の 1 件で差し戻し（段階的修正を促す）。
   • no-placeholder-marker: 本文に「要追記/要確認/未定/後日/検討中」を残さない
   • rollback-has-quantity: §撤退条件 に数値 1 つ以上
   • confirmation-has-kpi: §完了条件 に観測可能 KPI（数値 1 つ以上）

これらゲートに該当すると、Triage 出力には rejected=true / triageRejectKind（not-adr-worthy または pre-gate-block）/ rejectionReasonCode が付く。

検証観点（Phase 1 で確認すること）

• 例 1〜2 のような明らかな対象外を確実に弾けるか
• 例 5〜6 のような Critical を Standard に格下げしないか（明示的該当根拠のある Critical の降格 = 0。ADR-0102 ①の golden eval でブロッキングゲート化済）
• 「迷ったら Standard を既定値」が機能しているか（旧「迷ったら上位モードに倒す」は Critical 過剰判定によるレビューコスト膨張のため 2026-04 に変更 — ADR-0020 §改訂）
• reason が 80 字以内に収まり、判定の根拠が読み取れるか（TC-03/04 で超過、v0.2 で対処）
• suggested_title が 30 字以内に収まるか（TC-05 で超過、v0.2 で対処）

変更履歴