METHOD · JUN · 11 · 2026

プロンプトのバージョン管理：ほとんどのチームが省略するデプロイ手順

コードをバージョン管理する。モデルをバージョン管理する。しかしプロンプトがconfigファイル内の文字列として存在している場合、AIシステムは本番環境でアラートもロールバック手段もなく、静かに動作を変えてしまう。その解決策を示す。

5 MIN READ

プロンプトは変数ではない。モデルの重みファイルやサービスバイナリと同様に、デプロイ可能なアーティファクトだ。ほとんどのチームはそう扱っていない。そのギャップこそが、本番環境でのサイレント障害が潜む場所だ。

プロンプトのバージョン管理が実際に意味すること

プロンプトをバージョン管理するとは、三つのことを意味する。

コンテンツハッシュ。 すべてのユニークなプロンプト文字列に決定論的な識別子を付与する。文字列が変われば、ハッシュが変わる。曖昧さはない。
テストスイート。 プロンプトのバージョンを本番環境に昇格させる前に、固定のevalパック――期待される出力範囲または分類を持つ入力セット――に対して実行する。
ロールバック手段。 昇格したバージョンが出力品質を低下させた場合、5分以内にパイプラインを以前のハッシュに固定し直せる。

三つすべてが揃っていなければ、configファイル内の文字列に過ぎない。編集してシップしても、何かが変わったという記録は残らない。

この手順を省略したチームで起きる一連の流れを示す。

開発者がプロンプトを編集する――指示を絞り込むか、トーンを調整するか――そしてより大きなconfig更新の一部として変更をプッシュする。バージョンのバンプなし。evalの実行なし。システムは技術的に動作している。アラートは発火しない。

出力の分布が変化する。以前は120ワードだったメールが180ワードになる。以前は確信度の修飾語を含んでいた要約が含まなくなる。曖昧な入力に対して以前はnullを返していた抽出フィールドが、推測値を返すようになる。

4日間、誰も気づかない。そして下流のプロセスがnullを期待していたのに文字列を受け取り、失敗し始める。あるいはヒューマンレビュアーがトーンの変化を指摘する。あるいは顧客がクレームを入れる。

デバッグセッションは「何が変わったのか？」という問いから始まる。答えは「誰も知らない、なぜならプロンプトがバージョン管理されていなかったから」だ。

これは仮定の話ではない。本番AIパイプラインにおけるサイレントリグレッションの最も一般的なクラスだ。システムは動いている。ログにエラーは出ていない。動作が間違っている。

修正は複雑ではない。巧妙さではなく、規律が必要だ。

すべてのプロンプトをconfigファイルから取り出し、レジストリに移す――キーがプロンプトコンテンツのハッシュで、値がプロンプト文字列とメタデータ（作成者、日付、リンクされたパイプラインステージ、昇格ステータス）であるシンプルなキーバリューストアだ。

レジストリは既存のデータベース内のテーブルで構わない。専用サービスである必要はない。重要なのは、ハッシュが真実の源であり、文字列ではないということだ。

言語モデルを呼び出すすべてのパイプラインステージは、名前やインライン文字列ではなく、ハッシュでプロンプトを参照すべきだ。configエントリは次のようになる。

stage: summarize_lead_notes
prompt_hash: a3f9c2d1
model: gpt-4o

ステージが実行されると、ハッシュでプロンプトを取得する。ハッシュがレジストリに存在しない場合、ステージはモデルを呼び出す前に大きな音を立てて失敗する。これが正しい障害モード――静かで遅いのではなく、大きな音で早い。

新しいプロンプトハッシュをproductionとしてマークする前に、evalパックを通過しなければならない。evalパックは固定のテストケースセットだ：入力、期待される出力または出力プロパティ、合否の閾値。

リード要約プロンプトのevalパックには次のものが含まれるかもしれない。

新しいハッシュがすべての閾値を通過すれば、昇格できる。いずれかの閾値で失敗すれば、ステージングに留まる。開発者はどのテストケースがなぜ失敗したかを正確に確認できる。

これはコードに対して実行するのと同じゲートだ。作業量が増えるわけではない――異なるアーティファクトタイプに適用される同じ規律だ。

バージョン管理されたプロンプトレジストリが整備されると：

これらはいずれも新しいインフラプラットフォームを必要としない。データベーステーブル、ハッシュ関数、規律ある昇格ゲートがあれば始められる。

プロンプトのバージョン管理は、本番規律の一層だ。evalパック（合格の定義を決める）、自律性ティアの決定（失敗した出力が下流の状態にどれだけ影響できるかを決める）、グレースフルデグラデーションパターン（モデル呼び出し自体が失敗したときの対処を扱う）と組み合わさる。

本番AIパイプラインを構築または監査していて、現在のセットアップのどこにギャップがあるかを知りたい場合、短い会話で最もリスクの高い2〜3点を特定するのに十分なことが多い。