プロンプトのバージョン管理ベストプラクティス（実例付き）

プロンプトは「書いて終わり」ではなく、改善を繰り返す 生きたコード です。バージョン管理しないと、3 ヶ月後に「先月のプロンプトに戻したい」と言われて誰も対応できない、ということが起きます。

なぜ Git だけでは不便か

エンジニアは「Git で管理すれば良い」と考えがちですが、非エンジニアを巻き込んだ運用には次の壁があります。

• 非エンジニアが触れない: 営業・人事は Git を使わない
• メタデータが入らない: どのモデルで動作確認したか、評価指標は何点だったか
• 検索性が低い: 「経費精算用プロンプト」を探すのが大変
• A/B テスト連動なし: 評価結果と紐付かない

プロンプト管理ツール（PrompTune など）か、または Notion / スプレッドシートで補助する必要があります。

バージョニングの 4 原則

1. 意味のある粒度

「コミット」する単位を揃えます。

良い粒度	悪い粒度
評価軸を 1 つ追加	1 文字の typo 修正だけ
出力フォーマットを変更	30 個の変更を 1 コミット
トーンを敬語→丁寧語に変更	何を変えたか書かれていない

「変更理由が 1 行で書ける」を目安にすると粒度が揃います。

2. セマンティックなタグ付け

v1、v2 では何が変わったか分かりません。意味のある名前を付けます。

• support-reply-v3-shorten （3 版目、短文化）
• voc-classify-v2-7categories （2 版目、7 分類化）
• meeting-summary-v1-baseline （初版）

タグから 何を変えたか が読み取れるようにします。

3. メタデータを残す

各バージョンに次のメタデータを残します。

項目	例
変更理由	「敬語が硬すぎるとの指摘があり、丁寧語ベースに変更」
動作確認モデル	Claude Sonnet 4.6
評価指標	トーン適合度 4.2/5.0（n=30）
関連リンク	評価データ、Slack 議論 URL

これがあると、3 ヶ月後の自分や、新しく入ってきたメンバーが判断できます。

4. ロールバック容易性

「前のバージョンに戻したい」が 数分で完結する 状態にします。

• バージョン履歴の一覧が見える
• ワンクリックで過去版を呼び出せる
• 過去版の評価結果も一緒に見える

これが不便だと、改善のチャレンジが減ります。

命名規則の例

組織で運用する場合、命名規則を最初に決めます。

[業務領域]-[タスク]-[バージョン]-[変更内容]

例:
- sales-meeting-summary-v3-add-bant
- cs-reply-tone-v5-shorten
- hr-1on1-extract-v2-add-career
- legal-contract-review-v4-update-2026

業務領域（sales/cs/hr/legal）、タスク、バージョン番号、変更内容の 4 要素があると検索しやすいです。

チーム運用の流れ

編集フロー

1. 提案: 改善案をドラフトとして作成
2. 評価: A/B テストで効果検証
3. レビュー: チームでレビュー（コードレビュー相当）
4. マージ: 本番プロンプトに昇格
5. モニタリング: 1 週間ほど出力品質を観察

ロール分担

• プロンプトオーナー: 業務領域ごとに 1 名
• 編集者: 提案を作成する人（誰でも）
• レビュア: マージ判断する人（プロンプトオーナー）

非エンジニアでも参加できるフローにすることで、プロンプトが組織の資産になります。

バージョン管理の副産物

きちんとバージョン管理すると、次のような 副産物が得られます。

• 改善履歴の知見化: 「あの時こう変えてうまくいった」がドキュメント化
• 新人オンボの教材: バージョン履歴自体が教育素材になる
• AI 活用 ROI の証拠: 改善経緯を経営に説明できる

PrompTune で運用する

PrompTune は非エンジニアでも使えるプロンプト管理 UI を提供し、バージョン履歴・タグ・実行ログを一元管理できます。料金プラン の Pro / Team プランで本格運用できます。