Gate 4: Scoring プロンプト設計ドキュメント (v0.2) — 50 点満点 品質スコアリング

実装ステータス: 本番稼働中 実装ファイル: drp/src/nodes/scoring.ts モデル: claude-opus（createLlmWithEffort で reasoning_effort=state.scoringEffort、既定 max。temperature はログ上 1.0） パラメータ: loadLlmParams(env, 'gate4-scoring', { temperature: 1.0, sampling_n: 1 }) / 閾値は loadThresholds（bizlp:prompts:gate4-scoring:thresholds、fallback {Light:35, Standard:40, Critical:45}） ノード挙動仕様: nodes/04_scoring.md プロンプト本文 SSoT: KV active-pointer（bizlp:prompts:gate4-scoring:active）。以下のシステムプロンプト本体は scoring.ts 内 FALLBACK_PROMPT と一致。

⚠️ v0.1 からの変更: 入力は「Socratic 問診を経た起案ドラフト」ではなく body_generation で生成された ADR 本文（state.adrBody）（Gate 4 は body 生成後）。差戻しは rejected フラグで表現（問診ループは存在しない）。Self-Consistency サンプリング（sampling_n、ADR-0056）を追記（v0.2）。

目的

body_generation で生成された ADR 本文（state.adrBody）に対し、10 項目 × 5 点 = 50 点満点 で品質を採点する。

• Light モード閾値: 35 / 50
• Standard モード閾値: 40 / 50
• Critical モード閾値: 45 / 50

閾値未満の場合、rejected=true と rejectionMsg（feedback_for_user）を返し PR 化を許さない。起案者は AI と壁打ちして品質を高め再投入する（問診ノードへのループ差し戻しは存在しない）。

採点 10 項目

各項目を以下の 5 段階で採点する:

入出力仕様

Input

• ADR 本文 state.adrBody（body_generation の出力、Markdown）
• モード state.triageMode（Light / Standard / Critical）

注: グラフ順序は body_generation → scoring → cross_validation → consistency のため、scoring 時点では過去 ADR 整合性チェック結果は未確定（整合性は Gate 2 が後段で実施）。user メッセージは mode: {mode}\nadr_draft:\n{adrBody} の形で渡される。

Output

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

{
  "scores": {
    "1_problem_definition":     { "score": 4, "comment": "現状の痛みは明確だが、影響している案件数の数値がない。" },
    "2_alternatives":           { "score": 2, "comment": "代替案は1つのみ。SQL ベースや既存スプレッドシート流用案の検討が欠けている。" },
    "3_decision_criteria":      { "score": 3, "comment": "コストには言及があるが、保守性・移行性の評価軸が示されていない。" },
    "4_past_adr_consistency":   { "score": 5, "comment": "ADR-0003 との関係を Supersede として明示している。" },
    "5_impact_scope":           { "score": 4, "comment": "影響モジュールは列挙されているが、外部システム側への通知が漏れている。" },
    "6_operational_pitfalls":   { "score": 2, "comment": "監視ポイントの記載なし。後任がハマりそうな箇所が想像で補えない。" },
    "7_rollback_strategy":      { "score": 3, "comment": "撤回手順はあるがデータ復旧の具体性が薄い。" },
    "8_cost_estimate":          { "score": 4, "comment": "初期工数 5 人日と試算済み。運用コストの月次概算もある。" },
    "9_completion_criteria":    { "score": 3, "comment": "成功条件はあるが観測可能な指標になっていない（『うまく動くこと』では不十分）。" },
    "10_long_term_impact":      { "score": 3, "comment": "Review After は設定済みだが、半年後に再評価する具体的トリガーが書かれていない。" }
  },
  "total": 33,
  "mode": "Standard",
  "threshold": 40,
  "pass": false,
  "weakest_items": ["2_alternatives", "6_operational_pitfalls"],
  "feedback_for_user": "代替案が 1 つしか検討されておらず、運用上の罠の検証が不足しています。最低 2 つの代替案を、それぞれの却下理由と共に追加してください。また、本機能の監視・アラート設計についても言及が必要です。",
  "score_summary_md": "| 採点項目 | 点数 | コメント |\n|------|------|------|\n| 問題定義 | 4 | ... |\n| 代替案 | 2 | ... |\n..."
}

システムプロンプト本体

あなたは厳格な意思決定審査員である。提示された ADR ドラフトを 10 項目 × 5 点 = 50 点満点で採点せよ。

[採点ルール]
1. 各項目を 0〜5 点で採点する。「書かれていない」「一般論」「検証されていない」は容赦なく減点する。
2. 厳しさの基準: 「この記述だけを読んだ後任が、起案者の意図と判断根拠を再現できるか」を問う。
3. 採用案を支持するバイアスを排除し、起案者にとって都合の悪い指摘も明確に書く。
4. 採点項目:
   1_problem_definition:    問題定義の明確さ（現状の痛みの具体性・数値）
   2_alternatives:          代替案の網羅性（最低 2 案 + 却下理由）
   3_decision_criteria:     判断基準の明示（評価軸）
   4_past_adr_consistency:  過去決定との整合性（参照 / Supersede / Conflict）
   5_impact_scope:          影響範囲の特定（ファイル / モジュール / データ / ステークホルダー）
   6_operational_pitfalls:  運用上の罠の検証（後任がハマる箇所・監視ポイント）
   7_rollback_strategy:     失敗時のロールバック性（撤回手順・データ復旧）
   8_cost_estimate:         コスト試算（時間 / 金銭、粗くても数値）
   9_completion_criteria:   検証可能な完了条件（観測可能な指標）
   10_long_term_impact:     長期的影響（半年後の負債化リスク・Review After）
5. mode に応じた閾値:
   Light:    35 / 50
   Standard: 40 / 50
   Critical: 45 / 50
6. weakest_items は最低点の項目キーをすべて挙げる（同点複数あり）。
7. feedback_for_user は不合格時は「何を追加すべきか」を具体的に 150 字以内で指示する。合格時は「合格点ですが、〇〇は改善余地あり」と注意喚起する。

[出力ルール]
- JSON のみを出力。前置き・解説・コードブロックの ``` も禁止。
- score_summary_md は Markdown の表形式で、列見出しは「| 採点項目 | 点数 | コメント |」とし、採点項目名は日本語（例: 問題定義、代替案）で記述する。PR にそのまま貼れる形にする。

mode / adr_draft は上記システムプロンプトとは別に user メッセージ（mode: {mode}\nadr_draft:\n{adrBody}）として渡される。

モデル・Self-Consistency サンプリング

• モデル: claude-opus。createLlmWithEffort(env, MODELS.scoring, state.scoringEffort) で呼ぶ（reasoning_effort 既定 max、Adaptive Thinking 有効）。
• Self-Consistency（ADR-0056）: sampling_n（KV gate4-scoring:params、fallback 1）。
  • N=1: 単一サンプルの total と pass をそのまま返す（後方互換）。
  • N>1: Promise.allSettled で N サンプルを並列実行 → 各 total の平均/標準偏差を集計し、pass の多数決（majorityPass）で判定。代表 sample は平均に最も近い total のものを採用。成功数が過半数未満なら単一サンプル fallback。scoringSamples / scoringMean / scoringStdDev を State に保存。
• 閾値: loadThresholds で KV bizlp:prompts:gate4-scoring:thresholds から取得（fallback {Light:35, Standard:40, Critical:45}）。mode は state.triageMode（既定 Standard）。

採点の Anti-Pattern（減点トリガー）

採点時に以下を見つけたら積極的に減点する:

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

• 雑なドラフト（Anti-Pattern 多数含む）が 30 点未満で確実に不合格になるか
• 質の高いドラフトが 45 点以上に届くか
• feedback_for_user が「次に何を書けばいいか」を起案者にとって具体的に指示できているか
• mode による閾値切替が正しく動作するか
• weakest_items が複数あるとき正しく配列で返るか

変更履歴