ADR-0064: Decision Pipeline trigger 経路を Web UI から CI (GitHub Actions) にも拡張

• Status: Accepted
• Mode: Standard
• Scope: platform
• Kruchten Type: Existence/Executive
• Implementation Status: Partial (workflow_dispatch + POST /runs endpoint 実装済 — PR #990, #1079。schedule trigger は撤退条件達成後に段階開放予定)
• 起案者: [email protected]
• 起案日時 (JST): 2026-05-23 00:05
• 承認日時 (JST): 2026-05-23 00:20 (Pipeline 通常 flow v2 49/50 通過)
• Review After: 2026-08-23 (3 ヶ月), 2026-11-23 (6 ヶ月), 2027-05-23 (1 年)
• Deciders: [email protected] (単独)

1. コンテキスト

1.1 背景

Decision Pipeline (LangGraph TS on Cloudflare Workers / ADR-0019) の trigger は現状 Hono Web UI のみ (form を埋めて submit)。POST /drafts で KV staging は可能だが、そこから Gate 0-4 を回す trigger は Web UI でしか発火できない。

1.2 現状 (Current State / As-Is)

1. 自動化シナリオで Pipeline 不可 — git push event / cron / 別 service からの起案フローで Pipeline を回せない
2. KV 投入 → Pipeline 実行の二段階手作業 — 投入は CLI 自動化可だが、Pipeline 実行は別人間が Web UI を開いて trigger する必要がある
3. 再実行・回帰テストが困難 — 同じ draft を CI 上で N 回回して結果のばらつきを観測する作業ができない (ADR-pipeline-temperature-strategy の Self-Consistency 検証と直接関連)
4. Web UI のみが SPOF — Hono UI の障害時に Pipeline 全停止

1.3 課題

痛みの定量化 (proxy 実測 + 再評価):

• proxy 実測 (n=本セッション): 本日 2026-05-22 で audit 6 件実行、各 Web UI での chat/start + create-pr 手動 click を経由。1 audit あたり ~3-5min の UI 操作工数 (chat session ロード + Mode 選択 + 結果共有 + create-pr クリック)

• 集計データ実体 (n=6 内訳):

  #	ADR	Web UI 経由工数 (推定)
  1	ADR-0059 (R5)	~5min
  2	ADR-0060 (memory)	~4min
  3	ADR-0061 (handover)	~5min
  4	ADR-0062 (dev-spec, v2 524 経験)	~10min (v2 timeout + v3 再投入)
  5	ADR-0063 (prompt-lint)	~5min
  6	(本 ADR)	~5min
  合計		~34min/6 audits ≈ 5.7min/audit

• 集計手順: chat UI session log + git push 時刻から逆算

• 信頼区間: ±20% (4.5-7min/audit)

• 将来予測: Jr 入社後 (2026-10) audit 頻度 ~2-4 件/月想定 → ~20-30min/月の手動 UI 工数 (CI 自動化で 0min 化可能)

• 再評価: Jr 入社後 2 ヶ月 (2026-12) で実測 n≥10 audits に置換

2026-05-21 セッションでのユーザー問い: 「Web UI ではなく CI から実行できるようにしても入力・処理・出力は全く同じになるか?」 → Pipeline 本体 (LangGraph StateGraph) は HTTP endpoint なので、同じ endpoint を叩けば同じ動作 (追加実装ではなく既存 endpoint を呼ぶだけで実現可能)。

1.4 制約・要件

• 既存 Cloudflare Workers Basic 認証 (Web UI 共通) を再利用、credentials 数を増やさない
• Pipeline 本体 (LangGraph StateGraph) は不変、trigger 経路追加のみ
• doc 行数 ≤500 (本 ADR 250 行想定で余裕)
• ADR-0019 (LangGraph 基盤) との整合、ADR-0042 (prompt lifecycle) に trigger_source を渡す

1.5 目標

GitHub Actions workflow_dispatch + (将来 schedule / repository_dispatch) で Decision Pipeline を trigger 可能な CI route を追加。自動化シナリオ対応 + Web UI SPOF 解消 + 回帰テスト基盤確立。

2. 決定

GitHub Actions workflow (.github/workflows/drp-trigger.yml) を新設し、Cloudflare Workers 側に POST /runs endpoint を追加して既存 Pipeline 本体 (LangGraph StateGraph) を CI から trigger 可能にする。初期は workflow_dispatch のみ開放、schedule / repository_dispatch は撤退条件達成後に段階開放する。認証情報は GitHub Secrets に Web UI 共通の Basic 認証 credentials を配置し、credentials 数を増やさない。

2.1 GitHub Actions workflow 新設

.github/workflows/drp-trigger.yml:

on:
  workflow_dispatch:
    inputs:
      draft_id: { required: true }
      mode_override: { type: choice, options: ["", "Light", "Standard", "Critical"] }
      dry_run: { type: boolean, default: false }
jobs:
  trigger:
    steps:
      - run: |
          curl -X POST "https://decision-pipeline.t-saitoh.workers.dev/runs" \
            -u "${AUTH_USER}:${AUTH_PASSWORD}" \
            -d '{"draft_id": "...", "mode_override": "...", "dry_run": ..., "trigger_source": "github-actions"}'

2.2 Pipeline 側エンドポイント追加

POST /runs 新設: KV から draft_id を読み込み → Gate 0-4 を順次実行、{run_id, status, gate_results, pr_url?} 返却。

2.3 認証情報の管理

GitHub Secrets に DECISION_PIPELINE_AUTH_USER / _PASSWORD 設定 (Web UI と同 credentials、漏洩経路は増えるが credentials は不増)。

2.4 トリガー方法 3 種 (段階的開放)

3. 判断基準 (Decision Drivers)

ADR-0050 / ADR-0054 / ADR-0058 と同 Q42 5 軸 + WSM + K.O. (Suhr 1999 CBA 準拠)。

3.1 評価軸

K.O. criterion: Must 軸の score < 3 は不採用。

3.2 評価軸 × 案スコア表

採択首位 = workflow_dispatch CI route。

4. 検討した代替案 (Alternatives Considered)

• 採用案 (CI route 追加、workflow_dispatch): 既存 endpoint 再利用、認証情報不増、自動化対応
• X1: Web UI のみ継続 — K.O. (#operable=2, #suitable=1、SPOF + 自動化不可)
• X2: CLI tool 新設: CI から呼べても結局 GitHub Secrets 経由、二重実装 (加重和 0.554、採択 0.980 に劣後)
• X3: CI 専用 endpoint (認証独立) — K.O. (#suitable=2、Web UI と CI で実装分岐、本 ADR 原則違反)
• X4: Cloudflare Cron Triggers のみ: トリガー条件が cron 構文のみで柔軟性低、手動実行や event 受信に劣る (加重和 0.585)

5. 影響 (Consequences)

5.1 正の影響 (Good)

• 自動化シナリオ対応: KV 投入 → Pipeline 実行が CI 内完結 (~5min/audit 手動工数を 0 に)
• 回帰テスト基盤: schedule trigger で golden draft 群を毎週回し、Pipeline 挙動劣化を検出 (ADR-pipeline-temperature-strategy + ADR-0042 golden.jsonl と統合)
• Self-Consistency 自動化: Gate 4 N=5 sampling を CI 並列実行 (将来 Pipeline async polling ADR と並ぶ、N=5 復活の代替経路)
• Web UI 障害時の代替経路 (SPOF 解消): Hono UI が落ちても CI から Pipeline 実行可
• 監査証跡強化: GitHub Actions ログに trigger 履歴、trigger_source: github-actions flag で Web UI と識別

5.2 負の影響 (Bad)

• CI 暴走リスク: 誤って大量 workflow_dispatch 発火で LLM コスト爆発 (初期は手動 dispatch のみで抑制)
• 認証情報の GitHub Secrets 配置: Cloudflare Basic 認証の漏洩経路追加 (credentials 自体は Web UI と共通)
• Pipeline /runs endpoint 新規実装: LangGraph TS / Hono に handler 追加 (~2-4h)

5.3 中立・トレードオフ (Neutral / Trade-offs)

影響範囲:

• 改修対象: .github/workflows/drp-trigger.yml 新規 (50 行)、Cloudflare Workers (src/index.ts) に POST /runs handler 追加 (30-50 行)、GitHub Secrets に credentials 2 件追加
• 検証対象: decision-pipeline.t-saitoh.workers.dev/runs endpoint + workflow_dispatch UI 経由実行
• 波及: Pipeline 本体 (LangGraph) は不変、Web UI も不変、新規 endpoint 追加のみ。AI Agent (Claude / Gemini / GPT) への影響なし
• Decider: 代表取締役 (単独) / レビュアー: GitHub Actions 実行ログ + sub workspace audit / 将来 stakeholder: Jr (2026-10) — CI 経由 audit が onboarding 容易化

運用上の罠:

6. 撤退条件 (Rollback Plan)

6.1 撤退判断指標

• 3 ヶ月後 (2026-08-22): CI 経由 trigger 件数 / LLM コスト寄与を測定。Web UI 経由の 30% 超なら schedule trigger 開放を検討
• 6 ヶ月後 (2026-11-22): GitHub Actions の queue 待ち時間が常態化 (>5 分) なら Cloudflare Cron Triggers (X4) への部分移行検討
• CI 暴走発生時: 1 度でも CI 経由で意図しない大量 trigger 発火したら、workflow_dispatch 以外を即時無効化 + credentials rotation
• LLM コスト月次予算超過: §7.2 試算で月次予算上限 ¥10,000/月 を超えたら workflow_dispatch 一時無効化 (1 audit ~¥245、暴走時 ~¥24,500/日 想定、上限突破で alarming)
• 1 年後 (2027-05-22): Pipeline 全 trigger 経路 (Web UI / CI / repository_dispatch) の使用比率に応じて優劣再評価

6.2 ロールバック手順 (3 段階)

• (A) workflow 無効化のみ: .github/workflows/drp-trigger.yml の on: を workflow_dispatch: から null に変更、Web UI のみに戻す (~5min)
• (B) endpoint 削除 + workflow 削除: Cloudflare Workers の /runs handler を revert (30min) + workflow ファイル削除 + Secrets 削除 (10min)
• (C) 全廃 + credentials rotation: (B) 同 + Cloudflare Basic 認証の credentials 全 rotation (Web UI 含む影響大、~1h)
• 撤退コスト合計: A: ~5min / B: ~40min / C: ~1.5h

6.3 Review After / 負債化リスク

• Review After:
  • 3 ヶ月後 (2026-08-22): CI 経由比率評価 / schedule 開放判断 / CI 暴走 0 件確認
  • 6 ヶ月後 (2026-11-22): GitHub Actions queue 待ち時間 / Jr 入社後の CI 経由 onboarding 評価
  • 1 年後 (2027-05-22): trigger 経路 3 種 (Web UI / CI / repository_dispatch) 使用比率の再評価
• リスク 1: CI 暴走 (誤発火 / loop 化) で LLM コスト爆発 → 6.2 (A) 即時無効化 + 撤退条件発火
• リスク 2: GitHub Actions API 変更 (workflow_dispatch schema 変更等) で workflow が動作不能 → actionlint で検出 + 月次 review
• リスク 3: Cloudflare Workers 側 /runs endpoint の rate limit 超過 → Durable Object counter で IP 別制限、撤退条件で workflow_dispatch 同時実行数制限
• 将来統合候補: Pipeline async polling ADR (D 案、別途起案検討中) と本 ADR の trigger route は 補完関係。async polling は execution arch 変更、本 ADR は trigger 経路追加。両 ADR 採択で完全自動化 + 高精度 Pipeline 完成。

6.5 Confirmation (準拠確認 / Fitness Function)

• 検証 1 (機械): actionlint で .github/workflows/drp-trigger.yml 構文検証、毎 PR
• 検証 2 (機械): Pipeline /runs の request schema 検証 (draft_id 必須 / trigger_source 値域) を Worker 側 unit test
• 検証 3 (手動): 月次 gh run list --workflow=drp-trigger.yml で想定外 trigger 件数監視
• 違反時対応: 想定外 trigger 検出時は workflow_dispatch 一時無効化、原因調査後に再有効化

7. コスト試算

7.1 時間コスト (人件費)

• 初期実装: workflow 作成 1h + Cloudflare Workers /runs handler ~2-4h + Secrets 設定 ~15min + 動作確認 ~30min = **4-6h**、レビューバッファ +30% で 5-8h
• 継続運用 (12 ヶ月): 月次 trigger 件数監視 10min/月 = ~2h/年 + workflow 仕様変更時の同期 ~30min × 1-2 件/年 = ~0.5-1h/年 = **2.5-3h/年**
• 削減: Web UI 経由 audit 工数 5min/audit × Jr 入社後 2-4 audits/月 = ~10-20min/月 = **2-4h/年**

7.2 LLM コスト (JPY 試算)

Pipeline 1 audit あたりの LLM API 消費量 (Gate 0-4 + body_generation + slug + numbering):

(USD 1 = JPY 150 想定、Anthropic / Google Vertex / OpenAI 公開価格 2026-05 時点)

月次想定コスト:

• 通常運用 (Jr 入社後 audit 2-4 件/月): ~¥490-980/月
• 撤退条件 §6.1 閾値 (Web UI 30% 超で schedule 開放) 達成後: schedule trigger 追加で audit 件数 ~5-10 件/月 → ~¥1,225-2,450/月
• CI 暴走時の上限想定: workflow_dispatch 同時実行制限 1 + GitHub Actions monthly 10M requests 無料枠内で、最悪 1 日 100 audit 暴走 = ~¥24,500/日 → 月次予算上限 ¥10,000/月 超過で workflow_dispatch 一時無効化を撤退判断指標として追加

7.3 ROI

• 時間 ROI: (5-8h 初期) ÷ (2-4h/年 削減 - 2.5-3h/年 継続) = net -0.5 to +1.5h/年、短期 ROI 不確実
• 金銭 ROI: 削減なし (元々 Web UI 経由でも LLM コストは発生)、CI 経由の追加コストはゼロ (audit 件数次第)
• 戦略価値で正当化: Self-Consistency 自動化 + SPOF 解消 + 回帰テスト基盤 (定性価値高、定量 ROI 弱)
• 長期価値: Pipeline async polling ADR と並ぶ「精度向上の基盤」(本 ADR は trigger 経路追加、async polling は execution arch 変更で完全相補)

8. 検証可能な完了条件

9. 過去決定との関係 + namespace 分離

参照 (References)

• 関連 ADR: ADR-0019 / ADR-0042 / ADR-0050 / ADR-0052 / ADR-0058〜0063 / ADR-pipeline-temperature-strategy / Pipeline async polling ADR (検討中)
• 関連 PR/Issue: PR #880 (DOC-OPS-05、Pipeline CI 化議論発端) / PR #882 (handover §Step 5 派生 4 ADR draft) / PR #883 (temperature strategy 並行 draft)
• 外部資料:
  • 既存 doc: .github/workflows/ (本 ADR で新規追加先) / drp/src/index.ts (Pipeline endpoint 追加先)
  • memory: 本日 audit 6 件 Web UI 経由実行 (proxy 実測 n=6)
  • 将来統合候補: Pipeline async polling ADR (Critical Mode 検討中、execution arch 変更で 524 timeout 解放)

11. 参照: Pipeline 審査履歴 (2026-05-23 実行時, 通常 flow)

本セクションは Decision Pipeline (LangGraph TS on Cloudflare Workers) で本 ADR 草案を通常 flow (retroactive=false) で審査した結果のログ。v1 (150 行) は audit 未実行、v2 (198 行) 投入 → 49/50 で Standard 閾値 40 + Critical 閾値 45 双方クリア。ADR-0056 §8 / ADR-0058 §11 / ADR-0057 §8 / ADR-0059 §11 / ADR-0060 §8 / ADR-0061 §8 / ADR-0062 §8 / ADR-0063 §8 で確立した §audit history パターンの 第九適用例 (本日 audit 通過 7 件目)。デフォルトでは折りたたまれており、▶ をクリックで展開する。

Status 遷移

• v1 起案 (2026-05-22 KV 投入) → audit 未実行 (Phase 3 改善判定で v2 直接 POST)
• v2 投入 (198 行、524 安全域内) → Pipeline 通常 flow 49/50 通過 → auto-PR #936 生成 (Proposed)
• 本 PR で Status: Proposed → Accepted に更新、改善余地 1 件 (§7 LLM コスト + §6.1 予算閾値) を同時反映