← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0069type: adrstatus: accepted
pagemode: Standardkruchten: Existence/Executivescope: platformimplementation_status: In Progress (PRproposed_at: 2026-05-25 14:27approved_at: 2026-05-25 15:00 (Pipeline 通常 flow v2 …deciders: [email protected] (単独)business: meta
型付き辺: 出 6 / 入 1
関連: ADR-0019 ADR-0050 ADR-0068 ADR-0066 ADR-0078 ADR-0079 宿題回答された: ADR-0147全体は INDEX →

ADR-0069: docs 単源 RAG chatbot を Cloudflare Workers + Vectorize で MVP 構築 (Phase R1)

  • Status: Accepted
  • Mode: Standard
  • Scope: platform
  • Kruchten Type: Existence/Executive
  • Implementation Status: In Progress (PR #962 base + PR #964 改良 — Phase R1 主要 deliverable 完成: scripts/docs-vectorize.mjs ingestion / chat widget UI / /chat-docs endpoint / 認証不要 + IP rate limit。実装で発見した 3 改善も適用済: keyword + vector ハイブリッド検索 / 閲覧中ページ優先注入 / embedding model を bge-base-en-v1.5 → bge-m3 多言語対応に変更。Phase R1 残: fixture 10 query での citation 精度評価 + Implementation Status: Done 化)
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-25 14:27
  • 承認日時 (JST): 2026-05-25 15:00 (Pipeline 通常 flow v2 Standard 47/50 通過)
  • Review After: 2026-08-25 (3 ヶ月), 2026-11-25 (6 ヶ月), 2027-05-25 (1 年)
  • Deciders: [email protected] (単独)

1. コンテキスト

1.1 背景

docs site の ADR / 設計 doc は 技術用語 + bizlp 内部文脈の組み合わせ で記述されており、新規参加者 (Jr 入社 2026-10, 業務委託パートナー) は専門知識不足 + bizlp 文脈不在で読解コストが高い。docs / ADR を読みながら 「ADR-0066 で Paid plan が必要な理由は?」「phantom dependency って bizlp ではどう使われる?」 のような質問に 対話で即座に回答 できる仕組みが欲しい。

1.2 現状 (Current State / As-Is)

  • docs site (Cloudflare Pages) は 静的 HTML のみ、対話的検索/質問機能なし
  • 読み手は手動で Cmd+F 検索 + 関連 ADR を辿る → context switch コスト高
  • 外部 Claude/ChatGPT で paste 質問は可能だが、毎回 doc 添付要 + bizlp 文脈なし
  • docs/architecture/glossary.md (SSoT) と並行起案中の glossary tooltip ADR で用語の hover 表示は提供予定だが、深い質問 (例: 経緯/根拠/関連 ADR の組合せ) には不十分

1.3 課題

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

  • proxy 実測 (n=1 session, 本日 2026-05-25): 代表取締役から「これって何?」型質問が 1 session で 5-10 件、各 ~30-60s 対話 = ~5-10min/session の認知 overhead
  • n=1 限界自認: Jr 入社前は読み手 = 代表取締役 + 私の 2 名のみで実測機会が限定、proxy 1 session は客観性に欠ける。Jr 入社後 (2026-12) に n≥10 session 実測で信頼区間 ±40% → ±20% に補正、将来予測 ×3 も Jr + 業務委託参画後の実測で再評価 (※ §10 Review After 6 ヶ月時の trigger)
  • 集計手順 (再現可能化): chat session log の「これって何/わかった/理解できた」発話を grep → 用語遭遇数を proxy
  • 信頼区間: ±40% (3-14 件/session)
  • 将来予測: Jr 入社 (2026-10) + 業務委託参画増で読み手数 ×3、月次 ~30-60 件質問 = ~30-60min 認知 overhead 累積
  • 再評価: Jr 入社後 2 ヶ月 (2026-12) で実測 n≥10 session に置換

現状の機能的不在:

  • ADR の 「採択経緯」「過去 ADR との関連」「実装影響」 に答える機構なし
  • glossary tooltip (並行 ADR) は単語レベル、ADR 跨ぎの統合質問には不適

1.4 制約・要件

  • Cloudflare Workers Paid plan (ADR-0066 で承認済) を再利用、追加課金なし方針
  • LiteLLM Gateway (3 vendor) (既存) を LLM 推論に再利用
  • Cloudflare Vectorize (Workers Paid 機能、Free tier 内) を embeddings 保存に使用
  • Phase R1 (本 ADR): docs 単源のみ、~530 .md を index、シンプル MVP
  • Phase R2 (将来別 ADR): 多源 (ADR + memory + commit log) 拡張可能なアーキテクチャ前提
  • 比較可能性: 単源 R1 → 多源 R2 移行時の 回答品質改善量を定量計測

1.5 目標

docs site (/chat-docs 新 endpoint + chat widget) で docs 単源 RAG を MVP 動作させ、ADR-0066 で承認済 Cloudflare Workers Paid + LiteLLM Gateway を再利用。Phase R2 (多源 RAG) への段階拡張パスを設計上担保、R1 vs R2 の回答品質を比較可能化。

2. 決定

docs site に docs 単源 RAG chatbot (Phase R1) を Cloudflare Workers + Vectorize + LiteLLM Gateway で MVP 構築する。新規 POST /chat-docs endpoint を drp に同居させ、scripts/docs-vectorize.mjs で ~530 .md を ingestion、Workers AI (@cf/baai/bge-base-en-v1.5) で embedding、Vectorize namespace bizlp-docs で top-K 検索、Claude Haiku/Sonnet で回答生成、citation + source link 付きで返却する。Phase R2/R3 (多源 RAG) への段階拡張パスを設計上担保し、定量条件 (§10) で R2 起案を判断する。

2.1 アーキテクチャ (Cloudflare native, 既存インフラ再利用)

[Reader (docs site)]
    │ chat widget で質問入力 ("phantom dependency って何?")
    ▼
[Cloudflare Worker (新規 /chat-docs endpoint、drp に同居)]
    │ 1. Query → embedding (Workers AI: @cf/baai/bge-base-en-v1.5、無料枠内)
    │ 2. Cloudflare Vectorize で top-K (5-10) doc chunks 検索
    │ 3. context + bizlp 規約 (CLAUDE.md / glossary.md 抜粋) を system prompt に追加
    │ 4. LiteLLM Gateway → Claude Haiku/Sonnet で回答生成
    │ 5. citation 抽出 + source link 付き response 返却
    ▼
[Reader] 回答 + 元 doc link (e.g., "詳細は [ADR-0066 §1.3](...) 参照")

2.2 主要変更

  • 新規 endpoint POST /chat-docs (drp に同居、~3-5h)
  • 新規 script scripts/docs-vectorize.mjs (~50-80 行、docs → embeddings ingestion + Vectorize 投入)
  • 新規 Vectorize namespace bizlp-docs (5-10K vectors 想定、Free 100M vector 上限の 0.01%)
  • docs site UI (templates/page.html + CSS + minimal JS): floating chat button + chat panel
  • Build pipeline 拡張 (scripts/docs-build.mjs): build 後に docs-vectorize.mjs を呼ぶ post-build hook

2.3 Phase R1 vs R2 vs R3 (本 ADR は R1 のみスコープ)

Phase対象 source工数ADR
R1 (本 ADR)docs/**/*.md 単源 (~530 件)~10-18h本 ADR
R2 (将来別 ADR)+ ADR + memory + glossary+10-15h別途起案
R3 (将来別 ADR)+ commit log + PR discussion + source code+15-20h別途起案

2.4 R1 → R2 移行条件 (定量)

本 ADR §10 で明示:

  • R1 で 3 ヶ月運用後、「docs 単源で答えられなかった質問」が月 10 件超 → R2 起案
  • R1 の回答精度 (人間評価) < 70% → R2 起案
  • R1 の citation 精度 (源 doc が実際の根拠) < 80% → R2 起案

3. 判断基準 (Decision Drivers)

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

3.1 評価軸

#軸重要度 (係数)案件特有の解釈
1#suitable[Must] (×2.0)docs 質問に bizlp 文脈で回答できるか、既存インフラ再利用度
2#operable[Must] (×2.0)単一 vendor 運用、追加課金最小、ADR-0066 既課金分内
3#flexible[High] (×1.0)R2/R3 (多源 RAG) への段階拡張容易性
4#reliable[High] (×1.0)実装範囲が小さく bug 余地が小、retrieval 精度
5#efficient[Medium] (×0.5)build 時間 / response time / LLM コスト

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

3.2 評価軸 × 案スコア表

軸係数採択 (Cloudflare RAG 自前)X1 外部 SaaSX2 多源 R2 直接X3 何もしないX4 OpenAI Embeddings 専用
#suitable [Must]×2.05 (既存 Workers Paid + LiteLLM + Vectorize 再利用)3 (vendor lock-in、bizlp 文脈は手動)4 (より高機能だが R1 飛ばし)1 (機能不在)3 (OpenAI 専用課金、Vectorize 使えず)
#operable [Must]×2.05 (1 vendor、ADR-0066 既課金分内)3 ($50-150/月 課金)3 (実装複雑)5 (運用ゼロ)4
#flexible High×1.05 (R2/R3 へ段階拡張容易)2 (SaaS 機能の枠)5 (最初から多源)13
#reliable High×1.04 (Vectorize 学習コスト中)4 (managed)3 (実装範囲大で bug 余地)5 (no change)4
#efficient Medium×0.54 (build 時間増 ~5-10s)5 (build 無変化)3 (実装大)54
加重和 (正規化)0.9620.5660.6420.3960.547
K.O. 通過 (Must ≥3)✓✓✓❌ (#suitable=1)✓

採択首位 = Cloudflare RAG 自前 (Phase R1)。

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

  • 採用案 (R1: docs 単源 RAG on Cloudflare): 既存インフラ再利用、~10-18h MVP、R2/R3 段階拡張可能
  • X1: 外部 SaaS (Mendable / kapa.ai / Inkeep): ~3-5h で導入だが $50-150/月 + bizlp 文脈は API 経由で手動アップ必要、vendor lock-in — 不採用理由: 継続課金 + bizlp 文脈の手動運用負荷
  • X2: 多源 R2 を直接実装: 機能的に理想だが ~40-60h で R1 効果検証なし、bizlp 1 人開発の YAGNI 違反 — 不採用理由: 効果未検証のまま大規模実装
  • X3: 何もしない (現状維持) — K.O. (#suitable=1、認知 overhead 累積継続、Jr 入社後の onboarding コスト爆発)
  • X4: OpenAI Embeddings 専用 (Cloudflare 不使用): text-embedding-3-small は性能良いが追加 OpenAI API 課金、Vectorize 既存承認分使えず、#suitable=3 — 不採用理由: 既存承認インフラを活用できない

5. 影響 (Consequences)

5.1 正の影響 (Good)

  • 認知 overhead 削減: 月次 ~30-60min/Jr → ~5-10min、自走力向上
  • bizlp 文脈即時参照: docs/ADR/glossary 統合で「ADR-0066 で Paid 必要な理由」等を即回答
  • R2/R3 への段階拡張基盤: 多源 RAG 移行時にも本 R1 infrastructure 流用可能
  • 既存 Workers Paid 投資の活用: ADR-0066 で承認済の $5/月内で完結

5.2 負の影響 (Bad)

  • 初期実装コスト ~10-18h (B1 ingestion + B2 endpoint + B3 widget + B4 citation)
  • 継続運用: docs 変更で re-embedding (~5-10s build time 増 + Vectorize update API)
  • glossary tooltip ADR (並行起案中) との重複懸念: tooltip は単語、chatbot は対話、機能重複なし。両者は補完関係 (用語表面は tooltip、深い質問は chatbot)
  • LLM コスト微増: 1 query ~[MASKED:AMOUNT]-3 (Claude Haiku、embedding は無料 Workers AI)

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

影響範囲:

  • 改修対象:
    • 新規 drp/src/routes/chat_docs.ts (~80-120 行、endpoint logic)
    • 新規 scripts/docs-vectorize.mjs (~50-80 行、ingestion)
    • scripts/docs-build.mjs (post-build hook 追加、+10-20 行)
    • templates/page.html + CSS + JS (chat widget、+50-80 行)
    • drp/wrangler.toml (Vectorize binding 追加、+5 行)
  • 検証対象: 既存 ~530 .md を index 化、5-10 fixture query で動作確認
  • 波及:
    • AI Agent (Claude / Gemini / GPT) への影響なし (LiteLLM 経由統合済)
    • Cloudflare Vectorize Free tier 内余裕 (530 doc × ~10 chunks = ~5300 vectors << 100M 上限)
    • 既存 Pipeline (audit 機能) と独立 (/chat-docs は別 endpoint)
  • Decider: 代表取締役 (単独) / レビュアー: 5-10 fixture query で精度評価 / 将来 stakeholder: Jr (2026-10) + 業務委託

運用上の罠:

罠対処
Vectorize の embedding model 変更時に全 re-index 必要model version 固定 (@cf/baai/bge-base-en-v1.5 v1.0)、変更は別 ADR
chunk size 不適切で retrieval 精度低下initial: 800-1200 tokens/chunk (semantic boundary 優先、段落境界で分割) + 3 ヶ月後 A/B split test (chunk 500 vs 1000 vs 1500 で fixture 10 query の citation 精度比較、最良値に切替)。予防策: query→retrieved chunk の関連度スコアを log し relevance < 0.7 を月次集計、閾値超過で chunk size 調整発火
LLM が citation を捏造 (hallucination)予防策 3 重防御: (1) system prompt で「context 外の知識は使わず '分かりません' を返す」厳格化、(2) citation を context chunk の doc path に機械的に固定 (LLM が新規 URL を生成不能化、テンプレ強制)、(3) 出力後 post-process で citation の doc path が ingestion 対象に実在するか check、不在なら "ERROR" 表示

監視 dashboard / 自動 alerting (具体):

Metric監視対象Alert 閾値通知先
rag.retrieval.relevance_score_p50top-K chunk の関連度中央値< 0.7 sustained で chunk size 調整 triggerDiscord webhook (将来) + 月次 review
rag.citation.fake_ratecitation で実在しない doc path を生成した回数> 1% で revert (§6.2 A)Cloudflare dashboard + Discord
rag.query.daily_count日次 query 数> 100/day で rate limit 強化検討Cloudflare Pages dashboard URL: https://dash.cloudflare.com/9cf2013076a1accc0bac13e389ca3293/workers-and-pages
rag.llm.cost_monthly_jpy月次 LLM 課金> ¥5,000/月 で rate limit 強化、> ¥10,000/月 で revertLiteLLM ログ集計 + 月次 review
rag.response_time_p95response 時間 p95> 8s sustained で perf reviewCloudflare Pages analytics
大量 query で LLM コスト爆発rate limit (IP 別 10 query/min)、月次予算上限 [MASKED:AMOUNT] 設定、超過で alarming
docs 更新 → Vectorize 反映遅延で stale 回答build pipeline で post-build に re-embedding 強制 (docs:build:full)
sensitive な内容を user query が引き出す riskbizlp.local.md / .env / secrets は ingestion 対象外 (allowlist 方式)

コスト試算 (時間 / 課金 / ROI):

  • 初期実装: ~10-18h、レビューバッファ +30% で 13-23h
  • 継続運用 (12 ヶ月): Vectorize 監視 ~10min/月 + chunk/prompt tuning ~30min/月 = ~8h/年
  • Workers Paid: ADR-0066 既課金分内 (追加なし、$5/月)
  • Vectorize: Free tier 100M vectors / 50M queries (現状想定 ~5K vectors + ~300 query/月、上限の 0.005%)
  • Workers AI (embedding): Free tier 10K req/day (Vectorize 経由なら追加課金なし)
  • LLM: 1 query [MASKED:AMOUNT]-3、月次 30-60 query × [MASKED:AMOUNT] = **[MASKED:AMOUNT]-120/月**、暴走時上限 [MASKED:AMOUNT]/月で rate limit 自動発動
  • ROI: 削減 ~6-12h/年 − 継続 8h/年 = net -2 to +4h/年 (短期 ROI 弱)、回収 3-12 年 (時間)、金銭は長期実質負担なし
  • 戦略価値: bizlp 文脈即時アクセス + Jr 自走力 + R2/R3 への基盤投資で定性価値高、定量 ROI 弱を許容

6. 撤退条件 (Rollback Plan)

6.1 撤退判断指標

  • 3 ヶ月後 (2026-08-25): query 件数 < 10/月 → 「需要不在」と判断、§6.2 (A) feature flag off
  • 6 ヶ月後 (2026-11-25): 回答精度 (人間評価 fixture 10 query) < 50% → §6.2 (B) revert
  • 月次 LLM コスト > [MASKED:AMOUNT]/月 → rate limit 強化 or revert
  • Sunk cost シナリオ: 12 ヶ月以内に Phase R2 (多源 RAG) ADR 起案なし → R1 単独運用継続判断、または Status: Superseded by 外部 SaaS

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

段階対象具体手順所要時間
(A)chat widget hiddentemplates/page.html の widget を CSS で display: none~5min
(B)endpoint 削除 + Vectorize namespace 削除/chat-docs revert + wrangler vectorize delete bizlp-docs~30min
(C)全廃(B) + scripts/docs-vectorize.mjs 削除 + post-build hook 削除 + JS widget revert~1h

6.5 Confirmation (準拠確認 / Fitness Function)

  • 検証 1 (機械): 5-10 fixture query (e.g., "ADR-0066 で Paid が必要な理由は?") で citation 精度 ≥ 80% (源 doc が実際の根拠か人間評価)
    • 実行頻度: 初回リリース時 + 3 ヶ月毎 (Review After 連動)
    • 違反時対応: §6.2 (A) widget hidden → 原因調査 (chunk size / system prompt / embedding model 等の調整)
  • 検証 2 (機械): npm run docs:build:full で post-build re-embedding が成功 (build 時間 < 30s 維持)
    • 実行頻度: docs build 毎 (CI)
    • 違反時対応: build failure → 該当 PR ブロック、ingestion script 修正
  • 検証 3 (手動 + AI dry-run): Cloudflare Pages preview で chat widget 動作確認、5 query × 3 vendor で回答比較
    • 実行頻度: リリース時 + 月次 spot check
    • 違反時対応: vendor 切替 (LiteLLM routing 変更) or §6.2 (A)

7. 検証可能な完了条件

#観測指標目標値測定
1scripts/docs-vectorize.mjs 全 ~530 .md ingestion 成功100%exit code 0
2POST /chat-docs response time< 5s (Vectorize search ~100ms + LLM ~3-4s)curl benchmark
3fixture 10 query で citation 精度≥ 80%2 人独立評価 (代表取締役 + Jr or 代表取締役 + AI agent), disagreement < 10% で正規化
4Cloudflare Pages preview で chat widget 動作視覚確認 5 query手動
5Vectorize 使用量< 1% Free tierdashboard
6月次 LLM コスト< [MASKED:AMOUNT]/月LiteLLM ログ
7R1 → R2 移行判断 (3 ヶ月後)「答えられない質問 > 10/月」or 精度 < 70% で R2 起案query log 集計

Fixture 10 query 具体内容 (初回リリース時 + 3 ヶ月毎評価で使用)

#Query期待 citation 元 doc評価観点
1ADR-0066 で Workers Paid plan が必要な理由は?docs/adr/0066-...md §1.4直接 ADR ref
2phantom dependency とは何か?docs/architecture/glossary.md §7glossary ref
3Pipeline 524 timeout はどう発生する?docs/adr/0066-...md §1.2 / docs/adr/0062-...md §11複数 ADR 横断
4Walking Skeleton 4 要素とは?docs/adr/0028-...md 採用方針単一 ADR ref
5bizlp の monorepo 採用方針は?docs/adr/0067-...md §2直接 ADR ref
6Pipeline で Critical Mode の閾値は?docs/_internal/05_how-to/operator_guide_langgraph.md §5 / docs/adr/0020-...mdhow-to + ADR
7adr-lint の rule 一覧は?docs/_internal/05_how-to/adr-lint_rules.mdhow-to ref
8INV と STL の違いは?docs/architecture/glossary.md §1glossary ref (会計 domain)
9退役済の operator_guide は?docs/_internal/05_how-to/operator_guide.md (status: deprecated)status filter 動作確認
10RAG と多源 RAG の違いは?docs/adr/0069-...md §2.3 (本 ADR 自身を fixture に使用)self-ref + meta

評価者基準:

  • 2 名独立評価: 代表取締役 + 別 AI Agent (Claude or Gemini を Pipeline 経由で同 fixture を採点)
  • disagreement < 10%: 2 名の評価差が 10 pt 以上の場合は再評価
  • citation 精度 = (期待元 doc を正しく cite した数 / 10) × 100%

8. 過去決定との関係

ADR関係整合性
ADR-0066 (Pipeline async, Workers Paid 承認)Confirms (Workers Paid plan + LiteLLM 既存インフラ再利用)$5/月 既課金分内
ADR-0019 (LangGraph 基盤)補完 (/chat-docs は別 endpoint、Pipeline と独立)影響なし
本日並行 ADR (glossary tooltip 自動付与)補完並立 (tooltip は単語、chatbot は対話、機能重複なし)互いに引き立て合う
ADR-0050 (Q42 MCDA)Confirms本 ADR §3 で適用
将来 ADR (Phase R2: 多源 RAG)Refines (本 R1 が基盤)本 ADR §10 で R2 移行条件明示

10. Review After / 負債化リスク

  • Review After:
    • 3 ヶ月後 (2026-08-25): query 件数 / 精度 / LLM コスト評価、R2 起案判断
    • 6 ヶ月後 (2026-11-25): Jr 入社直前、回答精度 (人間評価) 50% threshold 評価
    • 1 年後 (2027-05-25): R1 vs R2 比較データ (R2 採択時)、Status 評価
  • リスク 1: docs 更新で Vectorize 反映漏れ → stale 回答 → build pipeline で強制 re-embedding
  • リスク 2: Cloudflare Vectorize API 変更 / pricing 倍増 → 別 vector DB (Pinecone 等) 移行 ADR
  • リスク 3: LLM コスト爆発 → rate limit + 月次予算上限 [MASKED:AMOUNT] で防御
  • R1 → R2 移行条件 (定量):
    • 月 10 件超「docs 単源で答えられない質問」
    • 回答精度 (人間評価) < 70%
    • citation 精度 < 80%
    • いずれか達成で Phase R2 ADR 起案

参照 (References)

  • 関連 ADR: ADR-0066 (Workers Paid 承認、再利用) / ADR-0019 (LangGraph 基盤) / ADR-0050 (Q42 MCDA) / 並行 ADR (glossary tooltip 自動付与) / 将来 ADR (Phase R2 多源 RAG, Phase R3 完全多源 + agent)
  • 関連 PR/Issue: -
  • 既存インフラ: drp/ (Workers + LiteLLM 統合済) / Workers Paid plan (ADR-0066 承認) / Cloudflare Vectorize (Workers Paid 含む、未使用)
  • 対象 source: docs/**/*.md (~530 件、docs/architecture/glossary.md 含む)
  • 本日要望起点: 代表取締役 2026-05-25「ADR の内容が専門知識 + bizlp 文脈なしには分かりにくい、質問用 chatbot が欲しい」
  • 外部資料: Suhr 1999 CBA criterion / arc42 Q42 / Cloudflare Vectorize docs / Workers AI @cf/baai/bge-base-en-v1.5

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

本セクションは Decision Pipeline (LangGraph TS on Cloudflare Workers) で本 ADR 草案を通常 flow (retroactive=false) で審査した結果のログ。v2 (221 行) で 47/50 (Standard 閾値 40 + 7 pt 余裕、Critical 閾値 45 も超過) 通過。§audit history パターンの 第十二適用例。デフォルトでは折りたたまれており、▶ をクリックで展開する。

📋 Pipeline 審査履歴 全 Gate 結果 (合格 Score 47 / 50) — クリックで展開

Gate 0-4 結果

  • Gate 0 Triage: needsAdr=true / triageMode=Standard
  • Gate 1 Socratic: pass=true (追加質問 0 件)
  • Gate 2 Consistency: PASS (ADR-0066/0019/0050 + 並行 ADR-0068 補完並立)
  • Gate 3 Parallel Review: 3 vendor 出力は §改善余地 に要約
  • Gate 4 Scoring: 47 / 50
#採点項目点数コメント
1問題定義4n=1 session proxy + 信頼区間 ±40% で根拠弱く、将来予測 ×3 も推測ベース。限界自覚と再評価計画 (n≥10@2026-12) はあり (本 PR で §1.3 に n=1 限界自認 + 将来予測 ×3 も Jr 後再評価明示)
2代替案54 案 + 採用案、却下理由明示、スコア表で加重和まで定量比較
3判断基準5Q42 5 軸 + 係数 + K.O. criterion + 案件特有解釈、Suhr 1999 CBA 準拠
4過去 ADR 整合性5ADR-0066/0019/0050 + 並行/将来 ADR まで関係性 (Confirms/補完/Refines) を表で明示
5影響範囲5改修対象がファイル + 行数まで明示、Decider / レビュアー / 将来 stakeholder も記載
6運用上の罠46 罠 + 対処表は充実だが「chunk size → 3 ヶ月で評価」等は対処というより観察。alerting 設定の具体 (閾値・通知先) も浅い (本 PR で chunk size A/B split test + alerting metric table 5 件 + 通知先 (Discord webhook / Cloudflare dashboard URL) 追記)
7ロールバック53 段階 + 所要時間明示、Sunk cost シナリオも記載
8コスト試算5時間 (13-23h) + 金銭 (¥60-120/月) + ROI 計算、短期 ROI 弱を明示し戦略価値で許容判断
9完了条件47 項目観測可能だが、citation 精度の「人間評価」評価者基準が未定義、fixture 5-10 query の具体内容も未提示で再現性に難 (本 PR で fixture 10 query 具体例 table + 2 名独立評価 + disagreement < 10% 正規化基準を §7 に追記)
10長期影響5Review After 3 段階 (3/6/12 ヶ月) + リスク 3 件 + R2 移行条件 (10件/月・精度70%/80%) 定量化

合計: 47 / 50 (Standard 閾値 40 → PASS, Critical 閾値 45 → PASS)

改善余地 (本 PR で反映済)

#指摘反映先効果
1n=1 proxy + 信頼区間 ±40% 弱、将来予測 ×3 推測§1.3 に n=1 限界自認 + Jr 後 (2026-12) n≥10 で ±40% → ±20% 補正計画、将来予測 ×3 も Jr + 業務委託参画後の実測で再評価明示問題定義 4/5 → 5/5 見込
2chunk size「3 ヶ月で評価」は対処というより観察、alerting 浅い§5.4 罠 table に chunk size A/B split test (500 vs 1000 vs 1500) + relevance score 月次監視 + hallucination 3 重防御 (system prompt + citation 機械固定 + post-process validation) + alerting metric table 5 件 (relevance_score_p50 / fake_rate / daily_count / cost_monthly_jpy / response_time_p95) + 通知先 (Discord webhook / Cloudflare dashboard URL) を追加運用罠 4/5 → 5/5 見込
3citation 精度評価者基準未定義、fixture 5-10 query 具体内容未提示§7 に fixture 10 query 具体例 table (ADR-0066/glossary/Walking Skeleton/monorepo/INV-STL 等の評価観点別) + 評価者基準 (2 名独立評価、代表取締役 + AI Agent、disagreement < 10% で正規化) を追記完了条件 4/5 → 5/5 見込

改善効果見込: 47/50 → 50/50 達成可能性。

Status 遷移

  • v2 投入 (221 行) → Pipeline 通常 flow 47/50 通過 → auto-PR #956 生成 (Proposed)
  • 本 PR で Status: Proposed → Accepted に更新、改善余地 3 件 (§1.3 信頼区間 + §5.4 chunk size 予防策 + §7 fixture 10 query) を同時反映