本番のプロンプトは、ソフトウェアの振る舞いの一部です。プロンプト管理とは、そのように扱う規律のことです。どのバージョンが動いているか、誰がいつ・なぜ変更したか、テストされたか、どうやって元に戻すかを把握します。この実践は PromptOps と呼ばれることもあります。
解決する問題
- ダッシュボードでプロンプトが編集され、先週どうなっていたか誰も言えない。
- 同じプロンプトが 4 つのサービスにコピーされ、そのうち 3 つが古い。
- 言い回しの小さな変更でトークンコストが倍になり、請求書で初めて気づく。
- モデルのアップグレードで振る舞いが変わるが、どう変わったかを示すテストがない。
- API キーがプロンプトファイルに貼り付けられ、コミットされる。
プロンプトをファイルとして保存する
各プロンプトを、それを使うコードの隣で、バージョン管理下の専用ファイルに置きます。
prompts/
support-reply.md
ticket-classify.md
summarize-incident.md
ファイルなら、履歴、差分、レビュー、blame、ロールバックが標準で手に入ります。名前付き変数を持つプレーンテキストか Markdown ファイルで十分です。
## Task
Classify the support ticket as billing, bug, or feature request.
## Output format
Return only the label.
## Input
<ticket>
{{ticket}}
</ticket>
複数の関数に散らばった文字列連結でプロンプトを組み立てるのは避けましょう。誰もプロンプト全体を一か所で読めないなら、誰もレビューできません。
テンプレートとデータを分ける
プロンプトテンプレートは、固定の指示と名前付き変数でできています。この二つを分けておきます。
- 変数は明示する。 名前のないフォーマットの穴ではなく、
{{ticket}}のようにします。 - 各変数に区切りを付ける。 タグで囲み、挿入されたテキストが指示として読まれないようにします。
- レンダリングは一か所で行う。 1 つの関数がテンプレートを埋め、入力をエスケープし、使ったテンプレートのバージョンを記録します。
すべての変更をバージョン管理する
コミットをバージョンとして使う。 すべての変更には、作成者、日付、理由を説明するメッセージがあります。
重要な組み合わせを記録する。 振る舞いはプロンプトとモデルに依存します。リクエストごとにプロンプトのバージョンとモデルの識別子の両方をログに残し、出力を、それを生んだものまで遡れるようにします。
重要なプロンプトには変更履歴を書く。 変更ごとに 1 行：何を、なぜ、テスト結果への影響。
リリースにタグを付ける。 プロンプトをデプロイしたらタグを付けます。そうすれば、ロールバックは既知の操作になります。
プロンプトの変更をコードの変更と同じようにレビューする
プロンプトの差分にも、きちんとしたレビューが必要です。レビュアーは次を確認します。
- 変更は既存の指示と矛盾していないか。
- 制約や出力形式など、何かが削除されていないか。
- トークン数は動いたか、それは許容できるか。
- この変更が直そうとしている振る舞いのテストがあるか。
自動チェックが、人が見る前にこれらの多くに答えます。プロンプトテストゲートは、プロンプトファイルが最低品質スコアを下回る、トークン予算を超える、または重大な指摘を含むとき、ビルドを失敗させます。設定はリポジトリに置きます。
{
"include": ["prompts/**/*.md"],
"model": "gpt-4.1",
"minScore": 70,
"maxTokens": 2000,
"failOn": "critical"
}
チェックは決定的でオフラインで動くため、CI に API キーは不要で、不安定な失敗も起きません。
リリース前にテストする
静的チェックは、プロンプトが健全であることを確認します。出力のテストセットは、それが今も正しく振る舞うことを確認します。プロンプトが変わったときは両方を、モデルのバージョンが変わったときは出力テストを再実行します。プロンプトのテストと評価を参照してください。
段階的に展開する
実際のトラフィックがあるプロンプトでは：
- シャドウ。 新しいバージョンを古いものと並行して実行し、ユーザーには見せずに出力を比較します。
- カナリア。 トラフィックの一部を新しいバージョンに送り、エラー率、形式の妥当性、ユーザーのシグナルを観察します。
- 昇格またはロールバック。 数字で判断します。
新しいバージョンが実績を示すまで、前のバージョンをデプロイ可能な状態に保ちます。
本番で監視する
プロンプトのバージョンごとに追跡するもの：
- 入出力のトークン数とコスト。
- 遅延。
- 検証に失敗した応答の割合。
- 拒否とフォールバック。
- 収集している場合は、ユーザーのフィードバック。
何をログに残すかに注意してください。プロンプトと出力には、個人データや秘密情報が含まれることがあります。既定ではメタデータをログに残し、内容は保存前にマスクします。プロンプト内の PII とシークレットの検出を参照してください。
秘密情報をプロンプトに入れない
プロンプトファイルは、読まれ、比較され、共有され、第三者に送られます。認証情報を入れてはいけません。秘密情報は、モデルの文脈ではなくアプリケーションを通してツールに渡します。CI のスキャナーが事故を捕まえます。プロンプトセキュリティスキャナーは、認証情報が検出されるとビルドを失敗させます。
所有者と再利用
- 各プロンプトに所有者を置く。 変更を決め、質問に答える人です。
- コピーではなくライブラリで共有する。 単一の情報源を、必要な場所でインポートします。
- 契約を文書化する。 どんな変数を取り、何を返し、何を前提とするか。
- 古いプロンプトは廃止する。 使われていないプロンプトも、次にそれを見つけた人にコピーされます。
選別され、テスト済みの出発点が役立ちます。PromptFlowEngine のテンプレートは、ビルドごとに警告なしの高いスコアが保たれています。
専用ツールかプレーンなファイルか
プロンプト管理プラットフォームは、ビジュアルエディター、実験の追跡、エンジニア以外のアクセスを加えます。エンジニアリング以外の多くの人がプロンプトを編集する場合は、導入する価値があります。ほとんどのチームでは、git のファイルと自動チェックで、運用する新しいものなしに必要なものが揃います。どちらを選んでも、要件は同じです。信頼できる唯一の情報源、履歴、レビュー、テスト、ロールバックです。
出発点のチェックリスト
- すべての本番プロンプトがバージョン管理下のファイルになっている。
- 変数に名前が付き、区切られている。
- プロンプトのバージョンとモデルが、リクエストごとにログに残る。
- すべてのプルリクエストで静的チェックが走る。
- プロンプトまたはモデルが変わると走るテストセットがある。
- トークン予算が設定され、強制されている。
- プロンプトファイルに秘密情報がなく、自動で確認されている。
- 文書化されたロールバックの手順がある。