RQ-044 突合 (Synthesis): LLM プロンプトライフサイクル管理 — Claude / Gemini / GPT 3 モデル比較・bizlp 採択方針

位置付け: Claude / Gemini Deep Research / GPT-4o の RQ-044 3 回答を論点ごとに突き合わせ、bizlp 文脈での ADR 起草方針を整理する。

本ファイルは「ADR 起案準備資料」。正式採択判断は Decision Pipeline 経由で新規 ADR として行う。

• 突合対象: RQ-044_result_claude.md / RQ-044_result_gemini.md / RQ-044_result_gpt.md
• 起票日: 2026-05-15

0. TL;DR

• 3 モデル完全一致の核心: プロンプトは SE artifact / 6 段階状態遷移 / SemVer の MAJOR-MINOR-PATCH 定義 / Type 1（本番）のみ SemVer 適用 / Git + Promptfoo + GHA が最小ツール構成 / eval gate を PR 必須化 / LLM-as-Judge はマルチサンプル + 位置スワップ + ルーブリック
• 最大の対立点（bizlp ADR の主論点）:
  • Claude: 同一リポ（monorepo）推奨 — atomic 変更・コード同期が最優先
  • Gemini: Polyrepo 必須 — 業務委託アクセス制御 + Cloudflare KV 動的ロードが不可欠
  • GPT: モノレポ先行 → 要件に応じて Polyrepo 移行（段階的アプローチ）
• bizlp 採択方針（要約）:
  1. リポジトリ: Monorepo 内 prompts/ — 現状 1 人法人でアクセス制御不要。Jr. 参加・業務委託発生時に Polyrepo 移行を評価
  2. ランタイム: Cloudflare KV でプロンプト文字列を管理 — アプリ再デプロイ不要のロールバックを実現（Gemini の核心提案を取り込み）
  3. Observability: Langfuse Hobby（無料）→ 2 名体制で Core $29/月（GPT 推奨・$50 制約内）
  4. meta.yaml: GPT の prompt.meta.yaml スキーマ（最も詳細）を採用
• 次工程: 本 synthesis を Decision Pipeline に投入 → プロンプトライフサイクル管理 ADR として正式起案

1. 完全一致部分（採用根拠）

3 モデルが独立に到達した一致点は、bizlp 採択根拠の中で最も強い。

1.1 「プロンプト = SE artifact」という前提（3 者一致）

→ bizlp ADR 採択: プロンプトはコードと同様に git 管理・レビュー・バージョニング・eval を義務化する。

1.2 状態遷移モデル（3 者実質一致）

3 者の差は「Staging を明示するか」「Experimental と Review を分けるか」程度で、本質的に eval gate を通過した後に Production に遷移する 6 段階モデルでは一致。

→ bizlp ADR 採択（統合案）:

draft → experiment → candidate → production → deprecated → archived

1.3 Semantic Versioning の定義（3 者一致）

Claude 独自追加：「eval で合格率が静的閾値を下回ったら PATCH でも MAJOR 扱いを強制」→ bizlp ADR に採用（プロンプトの非決定性を考慮した安全弁）。閾値はベースライン比の相対判定ではなく、プロンプトごとに meta.yaml の eval_pass_threshold フィールドに固定値（例: 0.85）を定義する static 方式を採用。

→ bizlp ADR 採択: Type 1（本番）のみ SemVer 適用。Type 3（調査用）は YYYYMMDD-topic 命名で十分。

1.4 ツールコア構成（3 者一致）

→ bizlp ADR 採択: Git + Promptfoo + GHA を必須コアとし、SaaS は無料枠のみ許容。

1.5 LLM-as-Judge 設計（3 者一致）

GPT 独自追加：「pairwise judge の非推移性（A>B・B>C だが A>C とは限らない）」(arXiv:2502.14074) → bizlp ADR に採用（judge 評価を絶対順位として扱わない注記）。

2. 対立・差異点と bizlp 向け採択方針

2.1 【最重要対立】Monorepo vs Polyrepo

これが本 ADR の核心的な判断事項。

各モデルの主張

bizlp 固有コンテキスト評価

現状（2026-05 時点）:
  - 実働: 代表取締役 1 名（PdM = 開発者 = 意思決定者）
  - Jr. 参加: D-180 以降（2026-11 目安）
  - 業務委託アクセス制御要件: 現状なし（将来発生可能性あり）
  - スタック: Cloudflare Workers + GAS + LangGraph TS
  - 既存: PropertiesService Feature Flag 機構あり

採択方針: GPT の段階的アプローチ + Gemini の Cloudflare KV 動的ロードを組み合わせる

1. Phase 1（現在〜Jr. 参加前）: Monorepo 内 prompts/ ディレクトリ

   • アクセス制御不要のため Monorepo の「Atomic 変更」「同期崩れゼロ」のメリットを享受
   • ただし Gemini 提案の Cloudflare KV 動的ロードは Phase 1 から実装（再デプロイ不要ロールバックは現時点でも価値大）

2. Phase 2（Jr. 参加後 / 業務委託要件発生時）: Polyrepo 移行を評価

   • bizlp-prompts リポジトリに分離 + KV デプロイパイプライン継続
   • 移行トリガー: 「外部業務委託者に prompt のみ編集させる要件が発生した時点」

KV と Monorepo は並立する（Gemini 提案の本質）:

Monorepo（git source of truth）
  └── prompts/production/gate0/v1.1.0.md
          ↓ CI/CD（GHA）でマージ後自動プッシュ
Cloudflare KV（ランタイムキャッシュ）
  └── bizlp:prompts:gate0:active → "v1.1.0"
  └── bizlp:prompts:gate0:v1.0.0 → "<prompt text>"
  └── bizlp:prompts:gate0:v1.1.0 → "<prompt text>"
          ↓ Workers が KV から動的ロード
Cloudflare Workers（アプリ再デプロイ不要）

2.2 Observability / 第 2 ツール層

採択方針: Langfuse（GPT 推奨）を採用

• Langfuse は prompt 管理・observability・A/B testing が統合（Braintrust は eval 特化で prompt 管理が薄い）
• Hobby 無料枠で開始 → 2 名体制で Core $29/月（月 $50 制約内）
• GitHub Integration で git に push すると Langfuse に自動同期できる（公式対応）
• Agenta OSS は自前ホスト運用コストが発生するため 1 人法人には不向き

2.3 prompt.meta.yaml スキーマ

GPT が最も詳細なスキーマを提示。Claude は meta.yaml に言及あるが項目定義が緩め。Gemini はスキーマ未定義。

採択方針: GPT の prompt.meta.yaml スキーマをベースに bizlp 向けに調整

# prompt.meta.yaml（Type 1 必須、Type 2 推奨）
id: gate0-policy-screen          # 一意識別子（kebab-case）
owner: [email protected]
status: production               # draft | experiment | candidate | production | deprecated | archived
semver: 1.1.0
model_family: claude-sonnet      # major family 固定（マイナーバージョンは prompt 本文に記載）
model_pin: claude-sonnet-4-6     # 具体的 pin（Prompt Drift 対策）
inputs:
  - name: application_json
    type: string
    description: ADR 申請 JSON
output_schema: ../schemas/gate0_output.json
eval_suite: ../../prompts-eval/datasets/gate0-policy-screen/golden.jsonl
eval_pass_threshold: 0.85          # static 方式（個別設定）: この合格率を下回ったら merge block / MAJOR 強制
kv_key: bizlp:prompts:gate0-policy-screen  # Cloudflare KV キー名
deprecation_at: null             # deprecated 状態に入った日付（ISO 8601）

全体床値は .promptpolicy.yaml（リポジトリルート）で定義：

# .promptpolicy.yaml
global_min_threshold: 0.70  # 全 Type 1 プロンプトに適用される絶対下限
                             # 個別 eval_pass_threshold はこの値以上でなければならない

2.4 Bradley-Terry モデルと A/B 統計

Gemini のみが明示的に推奨（Elo レーティング相当の統計的強度評価）。Claude と GPT は power analysis・paired bootstrap を推奨。

採択方針: bizlp のトラフィック規模では offline eval 優先、Bradley-Terry は将来検討

• bizlp の本番トラフィック（ADR 審査: 推測 1 日数件〜数十件）では統計的有意差を出すのに数ヶ月かかる
• Offline eval（golden set 50-200 件）が主、本番 A/B は補助（3 者共通の現実認識）
• Bradley-Terry の計算実装コストに対してメリットが現時点では薄い → プロンプト数 20 本超・本番 A/B トラフィックが 1 日 100 件超の段階で再評価

3. 論文・知見のユニーク貢献

各モデルが独自に提示した重要知見をまとめる。

3.1 Claude 独自の知見

3.2 Gemini 独自の知見

3.3 GPT 独自の知見

4. bizlp ADR 起草のための決定事項整理

ADR として確定すべき判断を以下に整理する（Decision Pipeline 投入前の自己整理）。

4.1 確定できる事項（3 者合意 + bizlp 文脈で迷いなし）

4.2 Phase 1 で決定・Phase 2 で再評価する事項

4.3 ADR 本体で定義すべき bizlp 固有の項目

• Gate 0-4 それぞれのプロンプト名・KV キー名の命名規約（例: bizlp:prompts:gate{N}:{name}:active）
• GAS 側と Cloudflare KV の役割分担（D16 採択: git = source of truth、KV = ランタイムキャッシュ。GAS 側 LLM 呼び出し発生時は UrlFetchApp 経由で KV 参照）✅ 方針確定
• モデル更新通知時のアクション（Anthropic release note 購読 → workflow_dispatch で全 Type 1 regression を即時実行）
• 週次 regression cron のスケジュール（D17 採択: 毎週月曜 0:00 JST、golden.jsonl 20 件以上充実後に有効化）✅ 方針確定
• golden.jsonl の構造仕様（input / expected / metadata / slice_tags フィールド定義）
• LangGraph ノードの eval 境界（D15 採択: PR 時 = ノード単体 eval、週次 cron = E2E eval の 2 層構成）✅ 方針確定
• eval_pass_threshold の個別値設定ガイド（Gate 重要度別の推奨閾値レンジ。例: Gate 0 ≥ 0.90 / Gate 3 ≥ 0.75）
• .promptpolicy.yaml のスキーマ定義（D4 採択: global_min_threshold = 0.70）✅ 方針確定

5. 推奨ディレクトリ構成（統合案）

bizlp/                                  # 既存モノリポ内
├── prompts/
│   ├── production/                     # Type 1: 本番 LLM パイプライン
│   │   ├── gate0-policy-screen/
│   │   │   ├── v1.0.0.md              # Immutable（内容変更禁止）
│   │   │   ├── v1.1.0.md
│   │   │   └── prompt.meta.yaml       # id / owner / status / semver / model_pin 等
│   │   └── gate1-xxx/
│   ├── agents/                         # Type 2: Claude Code 向けテンプレート
│   │   ├── spec_creator_v1.14.md
│   │   └── ...
│   ├── research/                       # Type 3: 使い捨て調査（日付+タイトル命名）
│   │   ├── 2026-04-12_deep_research_xxx.md
│   │   └── ...
│   └── shared/                         # 複数システム再利用（コピペ禁止）
│       └── account_classification_prefix.md
├── prompts-eval/                        # Eval datasets & evaluators
│   ├── datasets/
│   │   └── gate0-policy-screen/
│   │       └── golden.jsonl            # 最低 20 件
│   ├── schemas/
│   │   └── gate0_output.json           # JSON Schema
│   └── evaluators/
│       └── gate0-policy-screen.ts      # Promptfoo config or custom TS eval
├── .github/workflows/
│   ├── prompt_eval.yml                 # PR 時: lint → unit eval（static 閾値 block）→ cost check
│   └── prompt_regression_cron.yml     # 週次（月曜 0:00 JST）: 全 Type 1 E2E eval → 閾値割れで Issue 起票
├── .promptpolicy.yaml                  # global_min_threshold: 0.70
└── .gitignore
    └── prompts/generated/              # Type 4: 生成中間物（バージョニング不要）

6. 参考文献（3 モデル横断で重要度が高いもの）

3 モデル共通引用（最高信頼度）

• Gu et al. (2024). "A Survey on LLM-as-a-Judge." arXiv:2411.15594
• Schroeder & Wood-Doughty (2024). "Can You Trust LLM Judgments?" arXiv:2412.12509
• Semantic Versioning 2.0.0. https://semver.org/

2 モデル以上が引用

• OpenAI. "Evaluation best practices." https://developers.openai.com/api/docs/guides/evaluation-best-practices
• Braintrust. "Best prompt versioning tools 2025." https://www.braintrust.dev/articles/best-prompt-versioning-tools-2025
• LangSmith. "Manage prompts." https://docs.langchain.com/langsmith/manage-prompts

各モデルの独自重要文献

Claude 独自:

• Ma et al. (2023). arXiv:2311.11123 — プロンプト × モデルバージョン回帰テスト
• SPEAR (2025). arXiv:2508.05012 — prompts as first-class citizens（CIDR 2026）
• Soumik (2026). arXiv:2604.23178 — スタイルバイアス 0.76-0.92

Gemini 独自:

• arXiv:2406.06608 — 微細摂動で 30% 変動
• arXiv:2506.10095 — SBERT による prompt drift 検知
• HAPO (arXiv:2601.02683) — 最適化のジレンマへの対処

GPT 独自:

• Chen et al. (2026). arXiv:2503.02400 — Promptware Engineering（最重要新論文）
• Liang et al. (2025). arXiv:2409.12447 — Prompts Are Programs Too
• Xu et al. (2025). arXiv:2502.14074 — LLM-as-Judge の非推移性

7. 次工程

1. 本 synthesis を Decision Pipeline（ADR Quality Review Gate 0-4）に投入

   • Gate 0: Policy Alignment（既存 ADR との整合）
   • Gate 1: Context Quality（RQ-044 根拠の充足性確認）
   • Gate 2: Option Analysis（Monorepo vs Polyrepo の費用対効果算定）
   • Gate 3: Consequence Analysis（KV 動的ロード実装の工数見積もり）
   • Gate 4: Human Review（代表取締役による Phase 1/2 トリガー条件の最終確認）

2. ADR 仮題（案）: 「LLM プロンプトのライフサイクル管理ポリシー — Tier 別 SemVer + Cloudflare KV 動的ロード + Promptfoo eval CI の採択」

3. ADR 番号: 起草前に docs/adr/ の連番を確認して採番（grep "^# ADR-" docs/adr/*.md | tail -5 で確認）