← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0022type: adrstatus: accepted
pagemode: Standardkruchten: Existence/Executivescope: platformimplementation_status: Done (Policy Alignment ノード実装済、本日も使用)proposed_at: 2026-05-12 20:41approved_at: 2026-05-12 21:00business: drp
型付き辺: 出 4 / 入 0
細分化する: ADR-0019 関連: ADR-0010 ADR-0023 ADR-0049全体は INDEX →

ADR-0022: Decision Pipeline へのPolicy Alignmentノード追加（プラットフォーム/テナント層分離）

  • Status: Accepted
  • Mode: Standard
  • Kruchten Type: Existence/Executive
  • Scope: platform
  • Implementation Status: Done (Policy Alignment ノード実装済、本日も使用)
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-12 20:41
  • 承認日時 (JST): 2026-05-12 21:00

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 レビューで確定)。

コンテキスト

本 ADR は、実装前起案版が一度削除された経緯を踏まえ、実装知見 (直列実行確定・撤退条件の定量化・監視指標の具体化) を統合して新規起案する。

Decision Pipeline（ADR-0019）は汎用的なADR品質評価（Scoring / Parallel Review）を提供するが、「bizlpとして受容できるリスクか」「ADR-0010の番号体系と整合するか」「監査要件を満たすか」といった会社固有の判断軸が評価されない。現状の痛みとして、月次5〜10件のADR審査のうち過去に2件が「スコア合格・人間レビューで却下」となっており、却下理由は「GASのLockService 30秒タイムアウト時のUXが未定義」「監査ログへのPII混入リスクが無視された」など会社固有の判断軸であった。

他社展開を想定すると、会社固有判断をプラットフォームに混入させることはできない。そこで、parallel_review（汎用評価）の後段に会社固有方針ファイル（company_policy.md）または COMPANY_POLICY 環境変数で評価する policy_alignment ノードを直列追加し、プラットフォーム層とテナント層を分離する設計が必要となった。

決定

parallel_review の後に policy_alignment ノードを直列追加し、会社固有方針ファイル（company_policy.md）または COMPANY_POLICY 環境変数で評価する。実装は Claude Opus を用いるテナント層ノードとして src/nodes/policy_alignment.ts に配置し、src/company_policy.md にbizlpデフォルトポリシー（ADR-0010番号体系準拠・監査要件・1人法人運用コスト・可逆性）を定義する。state.ts に policyAlignmentDetail フィールドを追加し、graph.ts では parallel_review → policy_alignment → slug の順に組み込み、webhook.ts で PR body に Policy Alignment セクションを出力する。多テナント対応は COMPANY_POLICY env の差し替えのみで実現する（現在は単一テナント・同時実行なし）。

検討した代替案 (Alternatives Considered)

  • 案 A: parallel_review内に会社固有評価軸を統合する — 概要: 既存のparallel_reviewプロンプトにbizlp固有判断軸を追記する。不採用理由: プラットフォームコードに会社固有ロジックが混入し、他社展開時にコード分岐が必要となる。関心の分離・多テナント拡張性の評価軸で不適格。
  • 案 B: policy_alignment を parallel_review と並列実行する — 概要: レイテンシ削減のため並列化する。不採用理由: parallel_review の評価結果を踏まえた整合性判定（例：スコア合格でも会社固有却下）ができず、評価の論理的順序が崩れる。直列実行確定はこの設計判断による。ただし合計レイテンシが10分に近づいた場合は再検討する。
  • 案 C: KV/R2 にテナント別ポリシーを保存 — 概要: env変数ではなくストレージから読み込む。不採用理由: 現状単一テナント・同時実行なしの規模では過剰設計。他社展開3社以上の時点で別 ADR (ADR-0024 以降の予定) として起案する。

影響 (Consequences)

  • 正の影響:
    • プラットフォームコードを一切変更せずテナント固有評価を追加でき、関心の分離が達成される
    • 他社展開時は COMPANY_POLICY env の差し替えのみで対応可能
    • PR body に Policy Alignment 結果が可視化され、起案者・将来のJrエンジニアが company_policy.md を読むだけで判断軸を把握可能
    • ノード削除のみで元の状態に戻せる高い可逆性
  • 負の影響:
    • レイテンシ +15〜30秒（全体パイプラインの10〜15%増）
    • LLM追加コスト：Claude Opus 入力$0.04〜0.05 + 出力$0.04〜0.06 = 約$0.08〜0.11/回、月5〜10回で $0.40〜$1.10/月
    • 月次レビュー工数：policy_alignment起因の却下フラグ確認 15分/月
    • 変更ファイル：src/nodes/policy_alignment.ts（新規）、src/company_policy.md（新規）、src/state.ts、src/graph.ts、src/nodes/webhook.ts
  • リスク:
    1. policy陳腐化リスク: company_policy.md が実態と乖離するとLLMの評価精度が低下する。監視：ADR却下理由を月次でレビューし、「policy_alignmentの指摘と人間判断が5件中2件以上乖離」したら改訂
    2. env変数管理ミス: COMPANY_POLICY env 未設定時にbizlpデフォルトが適用されるフェイルセーフ動作。他社展開時のリスクに対しwrangler.tomlにデフォルト値設定を明記する
    3. LLM評価のぶれ: 「結論反転（PASS↔FAIL相当）が2件以上」検知時にtemperature=0.0→0.1 に調整して再評価
    4. Claude Opusのtemperature非対応: LiteLLM config.prod.yaml の supported_openai_params から temperature を除外済み。新モデル移行時に再確認
    5. 直列実行によるタイムアウト: 合計レイテンシが10分に近づいたら parallel_review と並列化を再検討
    6. 長期リスク: company_policy.md が12ヶ月更新されないと誤判定確率が上昇（四半期4件/四半期以下を合格基準とする）／他社展開3社以上で KV/R2 移行が必要（別 ADR 起案、ADR-0024 以降の予定）／Claude Opus新バージョン移行時の supported_openai_params 確認ルールを CLAUDE.md に追記

完了条件（検証可能・期限付き）

  1. 2026-05-15まで: 本ADRをパイプラインに通し、PR bodyにPolicy Alignmentセクションが出力されることをブラウザで確認
  2. 2026-05-20まで: company_policy.md の判断基準6項目すべてについて、policyAlignmentDetail に言及があることをJSON差分で確認
  3. 2026-06-01まで: ADR 3件以上を通過させ、「不正確な指摘（指摘内容が company_policy.md の記載と矛盾）」が5件中3件を超えないことを確認。合格基準：3件/5件以下
  4. 2026-06-30まで: COMPANY_POLICY env を差し替えた状態でパイプラインを実行し、テナント固有の評価内容が出力されることを確認

撤退条件 (Rollback Plan)

撤退条件: 不正確な指摘が3件/5件を超え、company_policy.md 改訂後も改善しない場合。

撤退手順:

  1. graph.ts から policy_alignment ノードとエッジを削除（2行変更）
  2. webhook.ts から policyAlignmentSection を削除
  3. state.ts の policyAlignmentDetail フィールドを残置（デフォルト空文字で無害）

所要時間: 30分以内 再導入コスト: company_policy.md と policy_alignment.ts は保持するため、再導入は1時間以内

Review After:

  • 2026-08-01（3ヶ月後）: 精度・コスト・運用負荷を総合評価。問題なければ正式採用を宣言
  • 2026-11-01（Jr.エンジニア入社1ヶ月後）: オンボーディングへの影響を評価

Confirmation (準拠確認 / Fitness Function)

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

  • 検証手段: Pipeline Gate 2 (consistency) + LiteLLM ログ集計
  • 実行頻度: PR ごと
  • 違反時の対応: 自動 fail

参照 (References)

  • 関連 ADR:
    • 準拠: ADR-0019（Decision Pipeline）、ADR-0010（番号体系）
    • 将来起案予定: KV/R2 へのテナントポリシー移行 (他社展開 3 社以上の時点で起案、ADR-0024 以降を想定)
    • 背景注記: 本 ADR の前身となる「Policy Alignment ノード追加・実装前起案版」は ADR-0022 として一度起案されたが Proposed 状態で削除済 (実装知見統合のため再起案 = 本 ADR)。Supersede 宣言は不要 (旧ファイル不在)。
  • 関連 PR/Issue: （要追記）
  • 外部資料:
    • src/nodes/policy_alignment.ts
    • src/company_policy.md
    • LiteLLM config.prod.yaml（supported_openai_params 設定）
    • wrangler.toml（COMPANY_POLICY env デフォルト値）
    • CLAUDE.md（モデル移行時の supported_openai_params 確認ルール追記予定）