プロンプトバージョニング

ストーリー

田

田中VPoE

「プロンプトの評価とA/Bテストを学んだ。ところで、改善したプロンプトの変更履歴はどう管理する？」

あなた

「コードならGitで管理しますが、プロンプトも同じように管理するんですか？」

あ

田

田中VPoE

「その通り。プロンプトはコードと同じインフラだ。バージョン管理、変更履歴、ロールバック。これらがなければ本番運用はできない。」

あなた

「プロンプトが壊れたときに前のバージョンに戻せないと怖いですね。」

あ

田

田中VPoE

「まさにそうだ。プロンプトのライフサイクル管理を見ていこう。」

なぜプロンプトバージョニングが必要か

理由	説明
再現性の確保	過去の出力を再現するために、使用したプロンプトを特定できる必要がある
ロールバック	改善が裏目に出た場合、即座に前のバージョンに戻せる
監査・コンプライアンス	いつ、誰が、何を変更したかの記録が必要
チーム協業	複数人でプロンプトを管理する場合、変更の競合を防ぐ

バージョニング体系

セマンティックバージョニング

プロンプトにもセマンティックバージョニング（SemVer）を適用する。

v[MAJOR].[MINOR].[PATCH]

MAJOR: 出力形式や動作が大幅に変わる変更
  例: JSON出力からMarkdown出力に変更
  例: ペルソナの根本的な変更

MINOR: 後方互換性のある機能追加・改善
  例: 新しいチェック観点の追加
  例: Few-shot例の追加

PATCH: バグ修正、文言の微調整
  例: 誤字の修正
  例: 表現の微修正

バージョン管理の例

prompt-chat-support/
├── v1.0.0.md  # 初期リリース
├── v1.0.1.md  # 誤字修正
├── v1.1.0.md  # エスカレーション基準追加
├── v1.2.0.md  # Few-shot例追加
├── v2.0.0.md  # 出力形式を変更（Breaking Change）
└── CHANGELOG.md

変更履歴（CHANGELOG）

# CHANGELOG - チャットサポートプロンプト

## [v2.0.0] - 2026-03-05
### Breaking Changes
- 出力形式をプレーンテキストからJSON形式に変更
- パーサーの更新が必要

### Added
- 回答の確信度フィールドを追加

## [v1.2.0] - 2026-02-20
### Added
- 返品手続きのFew-shot例を3件追加
- 配送遅延の対応パターンを追加

### Changed
- 回答の文字数上限を200文字→150文字に変更

## [v1.1.0] - 2026-02-10
### Added
- クレーム対応のエスカレーション基準を追加
- 感情分析による自動エスカレーション機能

## [v1.0.1] - 2026-02-05
### Fixed
- ペルソナ定義の誤字を修正
- 禁止事項の表現を明確化

## [v1.0.0] - 2026-02-01
### Initial Release
- 基本的なカスタマーサポートプロンプト
- ペルソナ定義、制約設計、コンテキスト管理を含む

Gitでの管理

ディレクトリ構造

prompts/
├── chat-support/
│   ├── system-prompt.md
│   ├── test-cases.json
│   └── evaluation-results/
│       ├── v1.0.0-results.json
│       └── v1.1.0-results.json
├── code-review/
│   ├── system-prompt.md
│   └── test-cases.json
└── README.md

コミットメッセージ規約

prompt(chat-support): v1.2.0 - Few-shot例を追加

- 返品手続きの例を3件追加
- 配送遅延の対応パターンを追加
- 回答文字数上限を200→150文字に変更

A/Bテスト結果:
- 正確性: 78% → 91% (+13pt)
- ハルシネーション率: 12% → 2% (-10pt)

ロールバック戦略

即時ロールバック

本番環境でプロンプトv2.0.0に問題が発見された場合:

1. アラート検知（正確性が閾値を下回る）
2. 自動ロールバック: v1.2.0に切り替え
3. インシデントレポート作成
4. v2.0.0の問題分析と修正

設定例:
{
  "prompt_id": "chat-support",
  "active_version": "v2.0.0",
  "rollback_version": "v1.2.0",
  "rollback_trigger": {
    "accuracy_threshold": 0.70,
    "safety_failure_count": 1,
    "evaluation_window": "1h"
  }
}

段階的ロールアウト

新バージョンのデプロイ戦略:

Day 1: 5%のトラフィックに新バージョンを適用
  → 評価指標を監視

Day 2: 問題なければ25%に拡大
  → 評価指標を監視

Day 3: 問題なければ50%に拡大
  → 評価指標を監視

Day 4: 問題なければ100%に拡大
  → 旧バージョンをロールバック候補として保持

プロンプトのメタデータ

各プロンプトバージョンに以下のメタデータを付与する。

# prompt-metadata.yaml
prompt_id: chat-support
version: "2.0.0"
created_at: "2026-03-05"
author: "tanaka-vpoe"
model: "claude-3.5-sonnet"
temperature: 0.3
max_tokens: 500

evaluation:
  accuracy: 0.91
  consistency: 0.88
  safety_pass_rate: 1.0
  avg_cost_per_request: 0.045

dependencies:
  - product-database: "v3.0"
  - term-dictionary: "v1.2"

tags:
  - production
  - customer-support
  - japanese

チーム運用のベストプラクティス

プラクティス	説明
プルリクエスト必須	プロンプトの変更は必ずレビューを経る
テスト必須	変更前にテストスイートを実行
評価結果の記録	A/Bテスト結果をコミットに含める
ロールバック計画	全てのデプロイにロールバック手順を用意
定期レビュー	月1回、プロンプトの品質と最新性を確認

まとめ

項目	ポイント
バージョニング	SemVerでMAJOR.MINOR.PATCHを管理
変更履歴	CHANGELOGで変更内容と理由を記録
ロールバック	閾値ベースの自動ロールバックと段階的ロールアウト
メタデータ	バージョン、評価結果、依存関係を記録

チェックリスト

プロンプトのセマンティックバージョニングを適用できる
CHANGELOGを適切に記述できる
Gitでプロンプトを管理する方法を理解した
ロールバック戦略を設計できる
メタデータの付与方法を把握した

次のステップへ

次は「コスト最適化」として、トークン削減やモデル選択の戦略を学ぼう。

推定読了時間: 30分