最終更新: 2026/06/22 18:56
commonid: drp-node-08-policy-alignmenttype: specstatus: active

08. Policy Alignment Node (テナント層)

TL;DR（このノードは何をする・専門語ゼロ）: 前段までの関門が「一般論として良い決定か」を見るのに対し、このノードは「この会社にとって良い決定か」を、自社が定めた判断の優先順位とリスクの線引きに照らして評価する。汎用の AI レビューでは拾えない自社ならではの事情を当てて、方針からの逸脱の見落としを防ぐ。ここも合否は決めず差し戻しもせず、評価結果を変更提案の本文に書き添えるだけで、判断は人間に残す。

実装: drp/src/nodes/policy_alignment.ts プロンプト: KV policy-alignment 経由 (loadPrompt、未設定時はノード内 FALLBACK_PROMPT 定数 / ADR-0085・PR #1090) 会社固有方針: ノード内 BIZLP_POLICY 定数 / 多テナント時は env.COMPANY_POLICY で上書き テスト: なし

1. 役割と位置づけ

プラットフォーム層 (Scoring / Parallel Review) が「良い ADR か」を汎用基準で評価するのに対し、本ノード (policy alignment〔policy alignment＝自社の意思決定方針との適合評価〕) は「この会社にとって良い決定か」を 会社固有の意思決定方針 に照らして評価する。

  • 解決する課題: 同じ ADR でも「bizlp の判断軸 (ADR-010 整合性最重要 / 監査要件最重要 / 1 人法人運用コスト / Jr 受け入れ容易性 / Reversibility)」では評価が変わる。汎用 LLM レビューでは拾えない「自社固有の文脈」を機械的に当てる。
  • 設計思想: 情報提供型 (差戻しなし)。policyAlignmentDetail を生成して webhook で PR 本文に追記。レビュアーが「自社方針逸脱の見落とし」を防ぐ補助情報。
  • 多テナント展開時: env.COMPANY_POLICY を設定すれば BIZLP_POLICY を上書きできる構造 (会社別のポリシー文書を Workers Secrets 等で注入)。

2. フロー図

flowchart LR
    PR[parallel_review] --> PA[policy_alignment]
    PA --> SL[slug]

3. トリガー条件

条件挙動
parallel_review から無条件必ず実行

差戻しなしのため consistency 同等の前段ゲートを通った全 ADR で実行される。

4. 入力 (State)

State フィールド用途
adrBody評価対象 ADR 本文

外部入力:

  • env.COMPANY_POLICY があればそれを使用、なければ BIZLP_POLICY (ノード内ハードコード)

5. 処理ロジック

1. policy = env.COMPANY_POLICY ?? BIZLP_POLICY
   systemPrompt = loadPrompt(env, 'policy-alignment', FALLBACK_PROMPT)   // KV 経由・未設定時 FALLBACK_PROMPT
2. loadLlmParams(env, 'gate2-consistency', { temperature: 0.4, seed: 42 }) → createLlm(env, MODELS.reviewClaude='claude-opus', params.temperature)  // KV キーは gate2-consistency を流用・実効値は KV 優先
3. user msg: "【会社固有方針】\n{policy}\n\n【ADR ドラフト】\n{adrBody}"
4. invoke → JSON 抽出 → PolicyAlignmentResult
5. policyAlignmentDetail に summary_md のみ格納 (priority_alignment / unaccepted_risks 等の詳細は破棄)

評価 4 項目:

キー内容
priority_alignment判断優先順位 1〜6 それぞれの aligned (boolean) + comment
accepted_risksADR が受容しているリスクで「受容するリスク」と合致するもの
unaccepted_risksADR が受容しているリスクで「受容しないリスク」に抵触するもの
tech_constraint_violations技術制約への抵触
summary_mdPR 本文転記用 Markdown サマリー

BIZLP_POLICY の判断優先順位 (重み順):

  1. ADR-010 整合性 (最重要): 数値プレフィックス命名規約・既存 580+ PR への破壊的変更不可
  2. 監査要件適合度 (最重要): hash chain 等で改ざん検知・追跡可能性を技術的担保
  3. 1 人法人の運用コスト (高): 管理オーバーヘッドが実装時間を上回らないこと
  4. 既存メモリ整合性 (中): ADR-018 (Markdown 維持・GitHub Issues 移行保留) との連続性
  5. Jr 受け入れ容易性 (中): 2026-10 入社予定 Jr 1 名が引き継げる設計か
  6. Reversibility (中): 段階的移行・ロールバック手順が定義されているか

受容するリスク: 自分の裁量で技術的に回収できる / 影響が自分だけに留まる / CI や四半期レビューで検知できる 受容しないリスク: 外部ツールロックイン / 監査トレーサビリティ欠如 / ADR-010・ADR-018 核心非互換 / 複数評価者前提 / 「全体設計が正しい」前提への依存

6. LLM 設定

項目値根拠
モデルclaude-opus (MODELS.reviewClaude)方針文書 + ADR 本文の文脈理解・矛盾検出
temperatureKV gate2-consistency params (fallback 0.4)判定の揺らぎ抑制。KV キーは consistency を流用・実効値は KV 優先
コスト目安0.10〜0.30 USD / 起案
レイテンシ10〜30 秒

7. 副作用

なし。LLM 呼出のみ。

8. 出力 (State)

{ policyAlignmentDetail: string }  // summary_md (PR 本文転記用 Markdown)

webhook ノードが PR 本文に ## Policy Alignment（自社方針適合評価） セクションとして転記する (webhook.ts 内 policyAlignmentSection)。

priority_alignment / accepted_risks / unaccepted_risks / tech_constraint_violations の詳細は state に保存せず破棄 (summary_md に集約済の前提)。

9. 分岐 (次ノード)

.addEdge('policy_alignment', 'slug')

無条件で slug へ。

10. エラー時の挙動

  • JSON parse 失敗: safeParseLlmJson<PolicyAlignmentResult>() が空 summary_md フォールバックを返し通過する (例外を投げない / ADR-0081・PR #1087)。LLM 呼出自体の失敗は例外スロー。
  • 空 summary_md: そのまま state に格納 → PR 本文の Policy Alignment セクションが空欄になるが PR 自体は作成される
  • env.COMPANY_POLICY の型不整合: (env as unknown as Record<string, string>) でキャストしているため型エラーは出ないが、object など想定外型なら ?? でフォールバック → BIZLP_POLICY 使用

11. 既知の弱点・運用注意

  • README 未記載: 本ノードは README.md / phase3 設計メモで言及されていない (実装が後追いで追加)。仕様書 (本ファイル) が初の公式ドキュメント。
  • プロンプト lifecycle: system prompt は KV policy-alignment で管理 (loadPrompt、未設定時 FALLBACK_PROMPT / ADR-0085・PR #1090)。一方 BIZLP_POLICY 会社方針定数は依然ハードコードで KV 管理外 → 多テナント化時に整理が必要。
  • judgement の浅さリスク: 6 項目の優先順位を機械的に当てるだけで、ADR の文脈深さによっては「形式的には適合だが実質逸脱」を見逃す可能性。Parallel Review (Gate 3) と相補的に機能する前提。
  • 方針更新時のメンテ: BIZLP_POLICY を変更するには policy_alignment.ts を編集 + デプロイが必要。会社方針の rev 管理 (ADR ベース) と乖離するリスク → 将来は KV / Worker Secrets 化が望ましい。
  • コスト累積: parallel_review 直後に claude-opus を追加実行。Pipeline 全体コストの 10〜15% を占める。
  • multi-tenant の現実: 現状 bizlp 専用。env.COMPANY_POLICY 経由の上書き機構は将来拡張のプレースホルダ。

12. テストケース

なし。情報提供型のため pass/fail なし。

将来の検証案: 既存 ADR (例: ADR-018 = GitHub Issues 移行保留) を Pipeline に通し、policy_alignment が ADR-018 との整合性を正しく判定できるかの retroactive validation。

13. 過去の設計判断ログ

日時変更経緯
(実装日不明)初期実装parallel_review (汎用) と分離して「自社方針整合」を独立評価する設計
(設計時)多テナント対応の env.COMPANY_POLICY 機構bizlp 以外への展開を見据えた抽象化
(設計時)reviewClaude モデルキー流用専用キーを増やさず Parallel Review と同モデルプール

14. 関連リンク

  • 前ノード: 07_parallel_review.md
  • 次ノード: 09_slug.md
  • 関連 ADR:
    • ADR-010 — 数値プレフィックス命名規約 (BIZLP_POLICY 最優先項目)
    • ADR-018 — Markdown 維持 / Issues 保留 (BIZLP_POLICY 整合対象)
    • ADR-0081 — safeParseLlmJson<T>() で JSON parse 堅牢化 (PR #1087)
    • ADR-0085 — loadPrompt(env, 'policy-alignment', FALLBACK_PROMPT) で KV 経由読込 (PR #1090)

実装更新 (2026-05-28)

  • JSON parse 堅牢化 (ADR-0081 / PR #1087): policy_alignment.ts の JSON.parse を safeParseLlmJson<PolicyAlignmentResult>() に置換
  • SYSTEM_PROMPT を FALLBACK_PROMPT にリネーム + loadPrompt(env, 'policy-alignment', FALLBACK_PROMPT) に切替 (PR #1090)
  • ChatOpenAI インスタンスに maxRetries=3 (exponential backoff) を付与