最終更新: 2026/06/22 18:56
commonid: adr-0042-parallel-review-notestype: how-tostatus: active

ADR-0042 Parallel Review — LLM プロンプトのライフサイクル管理ポリシーを採択する

  • 対象 ADR: ADR-0042
  • レビュー日時: 2026-05-15
  • レビューモデル: Gemini / Claude / o3（Decision Pipeline 並列レビューノード）
  • スコア: 44 / 50（Standard モード合格）

Gemini

強み (Strength)

git を唯一の source of truth とし、CI が本番プロンプトを Cloudflare KV に自動プッシュするアーキテクチャを採用する。

GitOps ベースの管理と KV の動的ロードを組み合わせることで、監査要件を満たしつつ迅速なロールバックを実現できる優れた設計です。

懸念 (Concern)

GAS 側 LLM 呼び出しが発生した場合は UrlFetchApp 経由で同一 KV を参照する

GAS の UrlFetchApp による外部 API 呼び出しは同期処理であり、KV 取得のレイテンシが GAS の 6 分間実行時間制限を圧迫するリスクがあります。GAS 側でのインメモリキャッシュ等の工夫が必要です。 → ADR-0042 で対処済み: CacheService（TTL 60 秒）併用を明記。

ロールバックはポインタ書き換えのみで完了（目標 5 分以内）。

Cloudflare KV は結果整合性モデルのため、エッジへの伝播に最大 60 秒程度かかる場合があり、切り替え直後に新旧プロンプトの挙動が混在する状態が発生する点に注意が必要です。 → ADR-0042 で対処済み: 5 分の時間予算内訳（検知 1 分 / 判断 1 分 / 伝播 60 秒 / 確認 1 分）を表で明示。

提案 (Suggestion)

eval_suite: # golden.jsonl への相対パス（最低 20 件）

テストデータに本番の機密情報や個人情報が混入するリスクがあるため、データマスキングのルールや PII スキャンの仕組みを CI に組み込むことを推奨します。 → ADR-0042 で対処済み: CI に PII スキャンステップを追加する旨を明記。

git と KV の 2 箇所に「正本」と「キャッシュ」が存在することを全員が理解していないと、KV を直接手動編集してしまうリスクがある。

緊急時の手動ロールバック（KV 直接編集）を許容するかどうかを明記し、手動変更が行われた場合に Git 側へ状態を同期・通知するリカバリ手順を定義すると運用がより安全になります。 → 未対処: 運用ガイドで補完予定。

Claude

強み (Strength)

KV Active Pointer パターンにより本番障害時のロールバックが 5 分以内で完了する

Active Pointer による即時切り替え設計は単純かつ実効性が高く、MTTR 5 分という KPI と整合している点が良い。

Type | 対象 | 管理レベル（4 Tier 分類）

プロンプトを 4 Tier に分類し管理レベルを差別化したことで、Type 2/3 への過剰投資を避ける論理的根拠が明確になっている。

懸念 (Concern)

eval CI が flaky になった場合（LLM 非決定性・ネットワーク断）の誤 merge block を防ぐため、CI 失敗時は --retries 2 で再実行し、2 回連続失敗のみ block 扱いとする

単純な 2 回リトライでは LLM の非決定性に起因する偽陰性/偽陽性を統計的に解消できない可能性が高い。閾値判定に温度 0 固定・複数サンプル平均・シード固定などの具体策が記述されておらず、flaky 対策として論理的に弱い。 → ADR-0042 で対処済み: temperature: 0 固定 + 3 サンプル多数決判定を追加。

ロールバックはポインタ書き換えのみで完了（目標 5 分以内）

KV のエッジ伝播遅延（最大 60 秒程度のグローバル整合性遅延）や、ロールバック判断・実行者の検知から操作までの人的時間が考慮されておらず「5 分以内」の根拠が薄い。検知→判断→実行の各工程の時間予算を明示すべき。 → ADR-0042 で対処済み: 時間予算内訳を表で明示。

GAS 側 LLM 呼び出しが発生した場合は UrlFetchApp 経由で同一 KV を参照する

GAS の UrlFetchApp は 6 分実行制限・日次クォータ・キャッシュ不可など制約があり、KV 直参照だと毎回外部 API コールが発生してレイテンシ/クォータを圧迫する。CacheService 併用や fallback 戦略が未定義で運用リスクが残る。 → ADR-0042 で対処済み: CacheService（TTL 60 秒）を明記。

再評価トリガー 3: Cloudflare KV コスト（現在 $5/月〜）が他サービス合計で $50 を超えた場合 → PropertiesService への統合を評価

PropertiesService は 500KB/9KB 上限・GAS 専用であり、Workers から参照できないため代替案として技術的妥当性が低い。撤退先の現実性が乏しく、トリガー発火時に実行不能となるリスクがある。 → ADR-0042 で対処済み: 案 A 後退または Upstash Redis への移行に修正。

案 A: Monorepo + Promptfoo + GHA のみ（アプリ同梱）

案 A の「ドリフト検知が手動」という評価軸は案 C も週次 cron に依存しており、cron を案 A に追加できない理由が明示されていない。比較軸の公平性に疑問が残る。 → 未対処: 案 A でも cron は追加できるが「アプリ再デプロイなしのロールバック不可」が本質的差分。次回改訂で補足予定。

提案 (Suggestion)

PATCH | 表現修正・誤字・同世代モデル差し替え | eval 閾値を下回ったら MAJOR に昇格（強制）

閾値割れ時に PATCH→MAJOR 強制昇格というルールは SemVer のセマンティクス（破壊的変更）と論理的に一致しない。「閾値割れ時はマージブロック」と「バージョン昇格」を分離した方が運用上明確になる。 → ADR-0042 で対処済み: merge block と手動 MAJOR 昇格を分離。

Review After: 2026-11-11（Jr. 参加 D-180 時点）

Review After までに約 6 ヶ月あり、その間に golden.jsonl が 20 件/プロンプト揃わなければ週次 cron も MTTR 検証も実施できない。中間マイルストーン（例: 初回 golden 整備完了日、初回ロールバック演習日）を追加すると論理的整合性が高まる。 → ADR-0042 で対処済み: D+60（golden 整備）/ D+90（ロールバック演習）を追加。

KV と git の乖離検知は CI の kv:get vs git show 差分チェックで毎週実施する

乖離が検知された場合の復旧フロー（git 正本での KV 強制上書きか、手動調査か）が未定義。検知後のアクション手順を明記すると運用ガイドとして完結する。 → 未対処: 運用ガイドで補完予定。

Phase 2（業務委託要件発生時）の Polyrepo 移行パスを保持

移行パスの「具体的にどのディレクトリ構造を維持すれば Polyrepo 化が容易か」を一文補足すると、将来の判断コストが下がり ADR の論理的一貫性が強化される。 → 未対処: 次回改訂で補足予定。

o3

強み (Strength)

プロンプト分類（Tier）

用途別に管理レベルを明示し Scope Creep を防いでいる点は体系的で優れている。

SemVer ルール（Type 1 のみ）

破壊的変更と軽微修正を機械的に区別できるため、ロールバックと互換性判断が容易になる。

ビジネス KPI（完了条件）

MTTR・Drift 検知時間など観測可能な指標で完了条件を定義しており検証容易性が高い。

懸念 (Concern)

月予算 $50 以内（SaaS 費用）

SaaS 料金だけを計上しており、Promptfoo や Drift 監視で発生する LLM API 従量課金が含まれていないため予算超過リスクが高い。 → ADR-0042 で対処済み: LLM API 従量課金を含む試算（$1 未満/月）を追記。

ロールバックはポインタ書き換えのみで完了（目標 5 分以内）

Cloudflare KV はリージョン間で Eventually Consistent であり、GAS キャッシュも介在するため 5 分保証は過度に楽観的。 → ADR-0042 で対処済み: 時間予算内訳を表で明示、混在期間を許容する設計と明記。

Cloudflare KV のプロビジョニングと CI パイプライン構築が初期工数として発生する（AI 支援あり: 2-3 日 / 手作業: 5-7 日）

メタデータ lint、権限設定、監査ログまで含めると数日では収まらない可能性が高く、スケジュール遅延を招きうる。 → 未対処: 工数見積もりは保守的に見直すべき指摘として記録。

--retries 2 で再実行し、2 回連続失敗のみ block 扱い

LLM 非決定性由来の flakiness 対策としては弱く、偶発的通過や品質劣化の見逃しが残る。 → ADR-0042 で対処済み: temperature: 0 + 3 サンプル多数決を追加。

KV Active Pointer パターン

ポインタ更新中の並行リクエストが旧新混在するレース条件が検討されておらず、出力一貫性が保証できない。 → ADR-0042 で部分対処: 混在期間（最大 60 秒）を許容する設計と明記。Atomic Swap 戦略は過剰設計と判断し採用しない。

提案 (Suggestion)

予算全体

CI/cron で想定される総トークン数×単価を算出し、$50 以内に収まるか試算とモニタリング手段を追加すると予算面の実現性が高まる。 → ADR-0042 で対処済み: LLM API 費用試算（$1 未満/月）を追記。

eval 2 層構成

週次だけでなく 1 日 1 回の軽量 Smoke Test を追加すると Drift 検知までのラグを縮められる。 → 未対処: 現状 1 名体制では運用コスト過剰と判断。Jr. 参加後に再評価。

Cloudflare KV デプロイ（Active Pointer パターン）

ポインタ書き換え時は Versioned Key → Rename などの Atomic Swap 戦略を採用し、整合性と In-Flight Request の安全性を確保すると良い。 → 未対処（意図的）: Gate 審査の冪等性を前提に混在期間を許容する設計を選択。

3 モデル共通の懸念事項

懸念GeminiClaudeo3対処状況
KV Eventually Consistent で「5 分以内」が楽観的✓✓✓ADR-0042 で対処済み
GAS の UrlFetchApp / KV 直参照のレイテンシ・クォータリスク✓✓—ADR-0042 で対処済み
--retries 2 では LLM 非決定性の flaky 対策として不十分—✓✓ADR-0042 で対処済み

未対処事項（次回改訂候補）

  1. 緊急時の KV 手動ロールバック手順・Git 同期フロー → 運用ガイドで補完
  2. KV 乖離検知後の復旧フロー（強制上書き or 手動調査）→ 運用ガイドで補完
  3. 案 A との比較軸（cron 追加可否）の補足説明
  4. Polyrepo 移行時の推奨ディレクトリ構造の一文補足
  5. 初期工数見積もりの保守的見直し（メタデータ lint・権限設定・監査ログを含める）
  6. 日次軽量 Smoke Test の追加（Jr. 参加後に再評価）