コンテンツにスキップ

プロンプトのバージョン管理とデプロイ戦略#

Techniques #versioning #prompt #deployment updated 2026-04-13 4 min read

プロンプトはコード同様にバージョン管理の対象。Git で管理するだけでは不十分で、評価・差分・ロールバックの仕組みが要る。

バージョン管理の基本構造#

flowchart TD
    V1[v1.0 初版] --> V11[v1.1 改善]
    V11 --> V12[v1.2 微調整]
    V12 --> V13[v1.3 バグ修正]
    V13 --> V2[v2.0 大幅改訂]

    V1 -.評価.-> E[評価セット]
    V11 -.評価.-> E
    V12 -.評価.-> E
    V13 -.評価.-> E
    V2 -.評価.-> E

やるべきこと#

1. ファイル分離

プロンプトをコードから分離し、専用のディレクトリに置く。

prompts/
  chat/
    v1/
      system.md
      few_shot_1.md
    v2/
      system.md
    active.md  →  v2/system.md のシンボリックリンク

2. 意味のあるバージョン番号

セマンティックバージョニングを準用する。

  • Patch: 誤字修正・言い回し調整（挙動がほぼ変わらない）
  • Minor: 新機能や few-shot 追加（互換性あり）
  • Major: 構造変更（互換性なし、再評価必須）

3. 評価セットを紐付ける

各バージョンで評価セットを実行してスコアを残す。バージョンごとに履歴が追える。

v1.0 → score: 72
v1.1 → score: 78（+6）
v1.2 → score: 76（-2）← 回帰、注意
v1.3 → score: 81（+5）

4. 差分をレビュー

プロンプト変更はコードレビューと同じ扱いにする。Pull Request で差分を見て、変更理由を説明する。

5. ロールバック手段

新バージョンで問題が出たら、すぐに前バージョンに戻せる手段を用意する。

デプロイ戦略#

flowchart LR
    D[Dev 環境<br/>v2.0 を試す] --> ST[Staging<br/>評価セット実行]
    ST --> C[Canary 10%]
    C --> R{メトリクス OK?}
    R -->|はい| F[100% 展開]
    R -->|いいえ| RB[ロールバック]
  • Dev: 新バージョンを試す、小規模評価
  • Staging: 完全な評価セットを流す、合格ラインを確認
  • Canary: 10% のユーザーに新バージョンを配信、メトリクス監視
  • Full: 問題なければ 100% へ

アンチパターン#

1. プロンプトをコードに直書き

response = openai.complete(
  "あなたはアシスタントです。以下の質問に..."  # ← ハードコード
)

バージョン管理できない。必ずファイルに分離する。

2. バージョンを付けない

何を変えたか追跡できない。評価スコアとの紐付けができない。

3. 評価なしで本番投入

「改善したつもり」で回帰しているケースがある。評価セットで確認しない限り進めない。

4. ロールバック手段なし

ダメだったときに戻せないと、事故のダメージが長引く。

チェックリスト#

  • [ ] プロンプトがファイルに分離されている
  • [ ] バージョン番号が付いている
  • [ ] 各バージョンで評価セットスコアが残る
  • [ ] 変更は PR レビューを経ている
  • [ ] ロールバック手順が文書化されている
  • [ ] Canary デプロイで本番検証している

メタデータとして残すべき情報#

# プロンプト v2.1
- 作成日: 2026-04-14
- 作成者: xxx
- 変更理由: few-shot を 3 件から 5 件に増やし、エッジケース対応
- 評価スコア: 83（前: 78、+5）
- 前バージョン: v2.0

まとめ#

プロンプトはコードと同じくバージョン管理・評価・デプロイの 3 点を仕組み化する。場当たり的な変更を許すと、改善が再現できなくなる。

関連エントリ#