ADR-0066: Decision Pipeline /chat/start を async (Queues + DO) アーキテクチャに変更し Cloudflare 524 timeout を解放

• Status: Accepted
• Mode: Critical
• Scope: platform
• Kruchten Type: Existence/Executive
• Implementation Status: Done (PR #980, #988, #989, #990)
• 起案者: [email protected]
• 起案日時 (JST): 2026-05-23 01:52
• 承認日時 (JST): 2026-05-23 02:30 (Pipeline 通常 flow v3 Critical 48/50 通過)
• Review After: 2026-08-23 (3 ヶ月), 2026-11-23 (6 ヶ月), 2027-05-23 (1 年)
• Deciders: [email protected] (単独)

決定の早わかり（Y-statement）

本節は ADR-0140 の方針で遡及追加された本文の要約で、新しい意味は加えていない (意思決定内容は不変)。「文脈で問題に直面し、対抗案でなくこの案を選び、目的のため代償を受け入れる」と読む。詳細はコンテキスト以降の本文に展開する。

• 文脈: Decision Pipeline の /chat/start は完全同期 endpoint。Gate 0-4 の全 LLM 呼び出しを直列で完走するまで HTTP response を返さない。Cloudflare edge proxy には 100s の hard timeout がある。
• 問題: 長尺 draft で HTTP 524 error が発生する。ADR-0062 v2 (306 行) で実際に発生し、圧縮回避に ~20min/件の手戻りが生じた。Gate 4 N=5 Self-Consistency や Multi-vendor scoring も実装不能になる。
• 問題点と課題（直せる原因 → 発生を止めるためにやること）:
  • 同期実行のため処理合計 100-200s が 100s timeout に収まらない → 実行を background へ移し、応答を即時返す async polling 化を行う。
  • 圧縮戦略は情報量削減で score 低下リスクがあり常用不能 → 長尺 draft をそのまま審査できる実行基盤を用意する。
• 前提（解決を課題に立てない与件）:
  • Cloudflare Workers Paid plan ($5/月) への upgrade を許容する。
  • ADR-0019 LangGraph 基盤・ADR-0052 retroactive validation・ADR-0064 CI route との整合を保つ。
• 決定（対応策）: sync 維持 (X1) や Free plan 維持の DO polling (X3) でなく、Cloudflare Queues + Durable Object hybrid の async polling アーキテクチャを選び、Workers Paid plan へ upgrade する。Producer Worker が sessionId を即時返却し、Client は GET /chat/status/:sessionId で polling する。feature flag (?async=true) で段階導入する。
• 目的: Cloudflare 100s edge timeout 制約を解放する。長尺 draft の audit と Gate 4 N=5 / Multi-vendor scoring を実装可能にする。
• 代償: Workers Paid plan 課金 ($5/月)。Queues + DO の学習コスト ~3-5h、Web UI / chat-terminal 改修 ~5-10h、テスト追加 ~3-5h を受け入れる。
• 詳細は本文の影響・撤退条件セクションを参照のこと

1. コンテキスト

1.1 背景

Decision Pipeline (LangGraph TS on Cloudflare Workers / ADR-0019) の /chat/start は 完全同期 endpoint。Gate 0-4 全 8+ LLM 呼び出しを直列で完走するまで HTTP response を返さず、Cloudflare edge proxy の 100s timeout (plan 不問の hard limit) を超過すると HTTP 524 error を返す。

1.2 現状 (Current State / As-Is)

• 実例: ADR-0062 dev-spec-lint v2 (306 行) で 524 確実発生 (2026-05-22 22 時頃の本日初事象)、v3 (175 行) 圧縮で回避
• 同症状を予見し ADR-0063 / 0064 は最初から v3 圧縮版投入で予防的回避
• Pipeline 構造 (buildGraph() in src/graph.ts): triage → socratic → body_generation → scoring → consistency → parallel_review → policy_alignment → slug → numbering の 9 node 直列
• 重 node: body_generation (30-60s) + scoring (30-60s) + parallel_review (~30-60s 並列) + 他 = 合計 100-200s 想定、長尺 draft で確実に 100s 超過

1.3 課題 (Problem)

痛みの定量化 (実測 n=1 + proxy):

• 実測 n=1: ADR-0062 v2 (306 行) で 524 timeout 発生、v3 圧縮で迂回。compress 工数 ~15min + 再 audit 工数 ~5min = ~20min/件の手戻り
• proxy 推定: 圧縮戦略は常用不能 (情報量削減で score 低下リスク)、長尺 draft (>200 行) 必要時 524 確実
• 将来の機能制約:
  • ADR-0056 で proposed の Gate 4 N=5 Self-Consistency: 現状 N=1 で実装、N=5 は 524 確実で 実装不能
  • Phase B: Multi-vendor scoring (Gate 4 を Claude + Gemini + GPT 3 vendor 並列) は +20-30% Gate 4 時間で 524 リスク増
  • Phase C: N=5 × 3 vendor = 15 scores 取得不能
• 再評価: Self-Consistency / Multi-vendor 採点品質向上を諦めるか、本 ADR で async polling 化するかの選択

1.4 制約・要件 (Constraints & Requirements)

• Cloudflare Workers plan: 当面 Free (現状)、必要なら Paid ($5/月 = ~[MASKED:AMOUNT]/月) へ upgrade 許容。Architecture 設計は Paid plan 機能 (Queues / Workflow API / DO 1M req/day) 前提で OK
• 既存 Durable Object (SOCRATIC_SESSIONS) パターンの learning を活用
• Web UI (chat.html) との互換性維持 (UI 側は async 対応に改修必要)
• ADR-0019 LangGraph 基盤 / ADR-0052 retroactive validation / ADR-0064 CI route との整合

1.5 目標 (Goals / To-Be)

/chat/start を async (Queues + DO) polling アーキテクチャに変更し、Cloudflare 100s edge timeout 制約を解放。長尺 draft / Gate 4 N=5 / Multi-vendor scoring 等の重い検証を実装可能化。Workers Paid plan 移行も併せて検討。

2. 決定

/chat/start を Cloudflare Queues + Durable Object hybrid の async polling アーキテクチャに変更し、Workers Paid plan ($5/月) へ upgrade する。Producer Worker が sessionId を即時返却し、Consumer Worker が Queues 経由で background で LangGraph を実行、Client は GET /chat/status/:sessionId で polling する。feature flag (?async=true) で段階導入し、6 ヶ月後に default 切替。

2.1 Async Architecture: Cloudflare Queues + DO Hybrid

[Client (Web UI / CI)]
    │ POST /chat/start  (draft + options)
    ▼
[Producer Worker (Hono)]
    │ sessionId 生成
    │ DO に initial state 保存 (status: 'queued')
    │ Cloudflare Queues に message enqueue
    │ 即時 {sessionId, status:'queued'} 返却 (HTTP 200, < 1s)
    ▼
[Consumer Worker (新規)]
    │ Queue から message 取得 (background 実行、Worker wall time 制約から独立)
    │ LangGraph buildGraph() を invoke
    │ 各 Gate 完了時に DO state を update
    │ retry: Queues 組み込み機能 (失敗時 DLQ へ)
    ▼
[Client polling]
    │ GET /chat/status/:sessionId (3s 間隔、exponential backoff)
    │ response: {status: 'queued'|'running'|'complete'|'error', gate_progress, result?}

2.2 主要変更

• Cloudflare Queues 導入 (wrangler.toml [[queues.producers]] / [[queues.consumers]]): background dispatch + retry + DLQ
• Workers Paid plan upgrade ($5/月、Free 100k req/day → 10M req/月 + Queues 解放)
• 新規 DO PIPELINE_SESSIONS: session state 管理 (status + gate_progress + result)
• 新規 endpoint GET /chat/status/:sessionId: polling
• 既存 endpoint 改修 POST /chat/start: sync graph.invoke → Queues 経由 async dispatch
• 既存 Web UI 改修 (chat.html): polling loop + UX (gate 進捗 spinner)

2.3 段階実装

• Phase A0: Workers Paid plan upgrade + Queues namespace 作成 (~30min + 課金確定)
• Phase A1: DO + Queues binding 設計 (~3-5h)
• Phase A2: Producer/Consumer Worker 実装 + GET /chat/status/:id (~5-7h)
• Phase A3: Web UI polling loop (~2-3h)
• Phase A4: ADR-0064 CI route の polling step 追加 (~1-2h)
• Phase A5 (将来別 ADR): Gate 4 N=5 復活 / Multi-vendor scoring 実装

3. 判断基準 (Decision Drivers)

ADR-0050 / ADR-0054 / ADR-0058 と同 Q42 5 軸 + WSM + K.O. (Suhr 1999 CBA 準拠)。Critical Mode のため K.O. 厳格化。

3.1 評価軸

K.O. criterion: Must 軸 (#reliable / #suitable) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

採択首位 = Queues + DO (Paid plan 採用)。

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

• 採用案 (Queues + DO hybrid, Paid plan): Cloudflare native pattern、retry/DLQ built-in、N=5 / Multi-vendor 解放
• X1: sync 維持 (現状) — 不採用理由: K.O. (#reliable=1, #suitable=1、524 確実、機能不在継続)
• X2: Cloudflare Cron Triggers のみ — 不採用理由: K.O. (cron 構文制約で trigger event 柔軟性低)
• X3: Async polling on DO (Free plan 維持) — 不採用理由: K.O. 通過 + 次点 (0.731)。Free 制約撤回で X3 を不採用、Queues 採用。Queues の retry/DLQ + batch + SDK 完成度で勝る
• X4: SSE streaming 化 — 不採用理由: 同期内で進捗送信、100s 制約は変わらず内側で閉じる必要、N=5 / 並列 vendor 実装制約残

5. 影響 (Consequences)

5.1 正の影響 (Good)

• 524 timeout 制約完全解放: 長尺 draft (200-500+ 行) audit 可能
• ADR-0056 Gate 4 N=5 Self-Consistency 復活: 信頼区間取得、rubric overfit 検出
• Phase B Multi-vendor scoring 解放: same-model bias 解消の基盤
• Queues retry/DLQ で reliability 向上: 一時的 LLM API 失敗で自動 retry
• 回帰テスト基盤強化 (ADR-0064 CI route 連携): GitHub Actions schedule で N 回実行 + batch 可能
• Web UI UX 改善: gate 進捗 spinner で「動いている感」可視化

5.2 負の影響 (Bad)

• Workers Paid plan 課金 ($5/月 = ~[MASKED:AMOUNT]/月、年 ~[MASKED:AMOUNT])
• Queues + DO 設計学習コスト: Cloudflare Queues SDK 学習 ~3-5h
• 既存 Web UI / chat-terminal の改修 (~5-10h)
• 既存 ADR-0052 retroactive validation banner との互換性確認 (~1h)
• テスト追加 (~3-5h): Queues consumer + polling sequence 検証

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

影響範囲:

• 改修対象:
  • drp/src/index.ts (/chat/start Producer 化 + 新 /chat/status/:id)
  • 新規 drp/src/queues/pipeline_consumer.ts (~100-150 行)
  • 新規 drp/src/durable_objects/PipelineSessionsDO.ts (~100-150 行)
  • drp/wrangler.toml (Queues binding + DO binding + plan upgrade)
  • drp/public/chat.html (polling loop UI)
  • .github/workflows/drp-trigger.yml (ADR-0064 採択時、polling step 追加)
• 検証対象: 既存 7 件 audit (ADR-0058〜0064) を新 endpoint で再現確認
• 波及: Pipeline 全 trigger 経路。AI Agent 影響なし
• Decider: 代表取締役 (単独) / レビュアー: re-run regression 結果 / 将来 stakeholder: Jr (2026-10) + Pipeline 利用者全員

運用上の罠:

監視 metric + alert 閾値 + 確認手順 (後任向け運用ガイド):

DLQ 蓄積時の対応手順:

1. Queues dashboard → pipeline-queue-dlq → Messages を取得
2. 各 message の error_type で分類 (LLM API timeout / Worker crash / DO state 破損)
3. 1 hour 以内に発生 5 件以上なら §6.2 (A) feature flag off + 原因調査
4. 修正後 wrangler queues consumer pipeline-queue-dlq retry --batch-size 10 で再投入

6. 撤退条件 (Rollback Plan)

6.1 撤退判断指標

• 3 ヶ月後 (2026-08-23): 524 0 件達成、polling 成功率 ≥ 95%、DLQ 件数 < 1%
• 6 ヶ月後 (2026-11-23): Queues 使用量 / Workers Paid 月額 妥当性確認
• 撤退判断: polling 失敗率 > 10% 常態化 / DLQ 蓄積過剰 → revert
• Sunk cost シナリオ (ROI 弱を補強する条件付き撤退):
  • 12 ヶ月以内に Phase B (Multi-vendor scoring) ADR 採択なし: 本 ADR の「戦略価値」根拠が崩れる (時間 / 金額 ROI 共に net negative のため、Phase B/C の早期実現が ROI 正当化の鍵)。Phase B ADR 起案を 2026-11-23 までに開始、2027-02-23 までに採択判定 → 未達なら §6.2 (B) revert を 本 ADR Status: Accepted → Superseded に格上げ検討
  • 24 ヶ月以内に Phase C (N=5 Self-Consistency) ADR 採択なし: long-term ROI 根拠も弱体化、Workers Paid $5/月 × 24 ヶ月 = ~¥18,000 の sunk cost が「scoring 精度向上」という当初目的に未到達。§6.2 (C) Free 戻しを検討
  • Cloudflare Queues API 大幅変更 / pricing 倍増 (>$10/月): 本 ADR の前提崩壊、緊急 ADR 起案で再選定 (Workflow API / 別 vendor)
• 1 年後 (2027-05-23): Phase B (Multi-vendor) / Phase C (N=5) ADR 採択状況、本 ADR 基盤価値再評価

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

• 撤退コスト合計: A: ~10min / B: ~2h / C: ~4h
• データ復旧: DO state は揮発性 (24h 保存後自動削除)、Queues は in-flight message のみ DLQ 経由で確認可能

6.5 Confirmation (準拠確認 / Fitness Function)

• 検証 1 (機械): POST /chat/start response time < 1s、GET /chat/status で完了取得を E2E test
• 検証 2 (機械): 既存 7 件 audit を新 endpoint で再実行し score が ±2 pt 内に収束 (regression test)
• 検証 3 (機械): 長尺 draft (400+ 行) で 524 0 件 + DLQ 0 件確認 (本 ADR 自身を fixture として活用可)
• 実行頻度: PR ごとの E2E test + 月次 regression test
• 違反時対応: §6.2 (A) feature flag off で sync に戻す → 原因調査

7. コスト試算

7.1 時間コスト

• Phase A0-A4 初期実装: ~12-18h、レビューバッファ +30% で 16-24h
• 継続運用 (12 ヶ月): Queues 監視 20min/月 = 4h/年 + polling logic 改修 ~30min × 2-3 件/年 = ~1-1.5h/年 = **5-6h/年**

7.2 Cloudflare 課金

• Workers Paid plan: $5/月 = [MASKED:AMOUNT]/月 = **[MASKED:AMOUNT]/年**
• Queues 利用: 100M operations/月 無料枠 (audit ~5-10 件/月 × ~20 ops/audit = 100-200 ops/月、上限の 0.0002%)
• DO 利用: Paid plan で 1M req/day、polling 込みで月 ~2000 req → 上限内余裕

7.3 LLM コスト

• 1 audit あたり ~[MASKED:AMOUNT] (ADR-0064 §7.2 同) は変化なし
• 将来 Phase B (Multi-vendor) で +50-80% / Phase C (N=5) で +400% は別 ADR で議論

7.4 ROI

• 短期 ROI (時間): 524 圧縮工数削減 ~3.3h/年 - 継続 5-6h/年 = net -2-3h/年 (時間 ROI 弱、初期投資回収せず)
• 短期 ROI (金額): Paid plan ~[MASKED:AMOUNT]/年 vs LLM コスト削減なし = net cost +[MASKED:AMOUNT]/年
• 戦略価値で正当化: Phase B/C 解放で scoring 精度向上の 基盤投資、定量 ROI 弱、定性価値高
• 長期 ROI 観点: Jr 入社 (2026-10) 後の audit 頻度増 + 同等以上の事故防止で価値顕在化、5 年で本 ADR 採択判断は妥当

8. 検証可能な完了条件

9. 過去決定との関係

10. Review After / 負債化リスク

• Review After:
  • 3 ヶ月後 (2026-08-23): 524 0 件 / polling 成功率 95% / DLQ < 1% 確認、Workers Paid plan 妥当性
  • 6 ヶ月後 (2026-11-23): Queues 使用量 / Phase B Multi-vendor ADR 起案準備
  • 1 年後 (2027-05-23): Phase B/C 採択状況、本 ADR 基盤価値再評価
• リスク 1: Workers Paid 月額 $5 が事業成長で過小に → Standard ($25/月) 等への upgrade ADR 起案
• リスク 2: Cloudflare Queues API 変更 / Cloudflare Workflow API stable 化で migration 必要 → §6.2 (B) 経由で再選定
• リスク 3: DO state 破損事故 → state を KV にも duplicate 保存 (冗長性)、撤退条件発火
• 将来統合候補: Phase B Multi-vendor scoring ADR / Phase C N=5 Self-Consistency 復活 ADR (本 ADR 採択後に両方起案可能化)

参照 (References)

• 関連 ADR: ADR-0019 / ADR-0042 / ADR-0050 / ADR-0052 / ADR-0056 / ADR-0064
• 既存 script: drp/src/index.ts (/chat/start 同期実装) / src/graph.ts (buildGraph() 全 9 node sync) / src/durable_objects/SocraticSessionDO.ts (DO パターン先行例)
• 既存 doc: docs/adr/0019-drp-migration.md / docs/adr/0056-decision-pipeline-llm-temp-sampling-stage-hybrid-strategy.md (Gate 4 N=5 採用済) / docs/adr/0064-extend-decision-pipeline-trigger-from-web-ui-to-ci.md
• 将来統合: Phase B Multi-vendor scoring ADR / Phase C N=5 復活 ADR (本 ADR が前提)
• 本日の実害事例: ADR-0062 v2 524 timeout (2026-05-22 22 時頃) + ADR-0063/0064 で v3/v2 圧縮による予防的回避
• 関連 PR/Issue: PR #940 (本 ADR 起案、Pipeline auto-PR、Proposed merge), 本 audit PR (Accepted 化)

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

本セクションは Decision Pipeline (LangGraph TS on Cloudflare Workers) で本 ADR 草案を通常 flow (retroactive=false) で Critical mode 審査した結果のログ。v2 (218 行) は Free plan 前提で 設計が次点、v3 (218 行、Paid 許容に変更) で 48/50 で Critical 閾値 45/50 + Standard 閾値 40 双方クリア。自己言及の皮肉: 本 ADR は 524 timeout 解放を目的とし、その制約を回避するため v3 (218 行) で投入 → 通過で問題の存在を audit プロセス自身が実証。ADR-0056 §8 / ADR-0058 §11 / ADR-0057 §8 / ADR-0059 §11 / ADR-0060 §8 / ADR-0061 §8 / ADR-0062 §8 / ADR-0063 §8 / ADR-0064 §11 で確立した §audit history パターンの 第十適用例。デフォルトでは折りたたまれており、▶ をクリックで展開する。

Status 遷移

• v1 (構想) → v2 (218 行 Free plan 前提) → v3 (218 行 Paid plan 許容) → Pipeline 通常 flow 48/50 通過 → auto-PR #940 生成 (Proposed)
• 本 PR で Status: Proposed → Accepted に更新、改善余地 2 件 (§5.4 監視 metric + §6.1 sunk cost) を同時反映