本番プロンプトのバージョン管理｜変更で壊さない運用の始め方
「AIの回答が、なんか前より雑になった気がする」——そう言われて調べてみたら、先週、別の人がプロンプトの一文を消していた。しかもそのプロンプトは、コードの奥に文字列としてじかに書き込まれていて、いつ・誰が・なぜ直したのか、どこにも残っていない。
本番でAI機能を動かし始めると、こういう「プロンプトを直したら、思わぬ所の出力が崩れた」という事故が、じわじわ増えてきます。これは、あなたのチームの注意が足りないからではありません。プロンプトが、コードのあちこちに文字列として散らばったままだと、変更の影響が見えず、履歴も残らず、誰も安心して触れなくなる——管理する場所がない、ただそれだけの問題です。
この記事では、プロンプトを「壊さずに直していける状態」にするための、最小の運用を一緒に整理します。大げさな基盤は要りません。今の仕組みのまま、今日から一歩だけ始められる形にします。
結論：本番プロンプトを壊さない運用は、①コードからプロンプトを外に切り出す（ハードコードをやめ、1か所にまとめる）→ ②バージョンと変更履歴を残す（Gitなどで「いつ・誰が・なぜ変えたか」を追える）→ ③本番に出す前に、旧版と新版を同じ入力で見比べる（代表的な入力を数本、固定して回す）→ ④出力の品質を継続して見る（崩れに気づけるログを残す）、の4つで十分です。ポイントは、プロンプトを「コードの一部」ではなく「変えると挙動が変わる大事な設定」として扱うこと。設定なら、履歴を残し、変更前に確認するのは当たり前ですよね。その当たり前を、プロンプトにも持ち込むだけです。
いきなり専用ツールを入れる必要はありません。まずは「プロンプトを1か所に集める」の一歩から。散らばったものを1つにまとめるだけで、驚くほど見通しが良くなります。今日は、その集め方から順番に見ていきましょう。
なぜ、プロンプトの変更でシステムが壊れるのか
まず、なぜ壊れるのかを整理しておくと、対策が腑に落ちます。理由は、だいたい次の3つです。
1. プロンプトが「見えない場所」に埋まっている コードの中に長い文字列としてじかに書かれていると、それが「AIの挙動を決める大事な指示」だと気づきにくい。ちょっとした言い回しの修正のつもりが、実は出力の形を左右する一文だった、ということが起きます。
2. 変えた影響が、離れた所に出る プロンプトは、1文字の違いで出力の傾向が変わることがあります。「箇条書きで」を「簡潔に」に変えただけで、後段でJSONを組み立てている処理が、想定した形をもらえなくなる。直した場所と、壊れる場所が離れているので、原因にたどり着くのに時間がかかります。
3. 履歴が残らないので、戻せない・比べられない 「前はうまくいっていたのに」と思っても、前のプロンプトがどこにも残っていなければ、元に戻すこともできません。何が変わったのか比べようもなく、勘で直すしかなくなります。
この3つは、どれも「プロンプトを、ただのコードの一部として扱っている」ことから来ています。逆に言えば、プロンプトを独立した管理対象に格上げするだけで、多くが防げます。次から、その具体的な手順を見ていきます。
手順1：プロンプトをコードから切り出して、1か所に集める
最初の一歩は、散らばったプロンプトを、コードの外の1か所にまとめることです。ここが土台になります。
やり方はシンプルです。コードの中に直接書かれている指示文を、専用のファイル（たとえば prompts/ フォルダのテキストや設定ファイル）に移し、コードからは「そのファイルを読み込んで使う」形にします。プログラムのロジックと、AIへの指示を、はっきり分けるわけです。
これだけで、次の3つが手に入ります。
- 一覧できる：今どんなプロンプトが本番で動いているか、フォルダを開けば見渡せる。
- 触る人が分かる：「ここを直せばプロンプトが変わる」と決まっているので、いじる場所に迷わない。
- 非エンジニアも読める：企画やレビュー担当が、コードを読まずに指示文だけ確認できる。
いきなり全部を移さなくて大丈夫です。まず、いちばん重要な機能のプロンプト1本だけを外に出してみる。それだけでも「散らばっている状態」から一歩抜けられます。可変部分（ユーザー入力や日付など）は、後から差し込む「穴あき」の形にしておくと、使い回しがきいて管理が楽になります。
手順2：バージョンと変更履歴を残す
切り出せたら、次は「いつ・誰が・なぜ変えたか」を残すことです。
いちばん手軽なのは、プロンプトのファイルをGitなどのバージョン管理に載せること。すでにコードを管理しているなら、同じ仕組みにプロンプトを含めるだけです。変更のたびにコミットメッセージへ「なぜ直したか」を一言残す習慣にすると、後から差分（diff）で「この日、この理由で、この一文を変えた」と追えるようになります。
余力があれば、プロンプトの先頭にコメントで版数と更新日を書いておくと、もっと分かりやすくなります。
# 問い合わせ分類プロンプト
# v3 / 2026-07-01 / 「その他」への振り分けが多すぎたため判定基準を追記
# 変更時は必ず手順3の見比べを通すこと
あなたはカスタマーサポートの一次受付です。
次の問い合わせを、以下のカテゴリのいずれか1つに分類してください。
...大事なのは、完璧な管理台帳を作ることではありません。「戻せる」「比べられる」状態を確保すること。この2つさえあれば、変更で失敗しても、落ち着いて一つ前に戻せます。戻せる安心感があると、プロンプトを改善する手も動かしやすくなります。
手順3：本番に出す前に、旧版と新版を同じ入力で見比べる
ここが、壊さない運用のいちばんの肝です。プロンプトを変えたら、変える前と後を、同じ入力で並べて確かめる。
やることは難しくありません。まず、代表的な入力を数本、固定で用意します。「よくある問い合わせ」「うまく処理できていた例」「過去に事故った例」を3〜5本。これをテスト用のセットとして取っておきます。
プロンプトを直したら、この同じ入力を旧版と新版の両方に通し、出力を並べて見比べます。見るポイントは3つ。
- 良くしたかった所が、ちゃんと良くなったか
- これまでうまくいっていた所が、崩れていないか（ここが見落としがち）
- 後段の処理が期待する形（JSONや決まった書式）が、保たれているか
「直したい所」だけを見て満足すると、別の所が静かに壊れる——これが、冒頭の「雑になった」事故の正体です。AIの出力は、1か所を良くしようとすると別の所に影響が出ることがあるので、変えていないつもりの所こそ確認する。最初は手作業の目視で構いません。数本を並べて見るだけでも、崩れの大半は出す前に気づけます。
出力が日によってブレる場合は、この見比べに加えて、構造化出力（JSON）を安定させる工夫や、出力が崩れたときのフォールバック設計も合わせて考えておくと安心です。
手順4：本番に出したあとも、品質を見続ける
出す前の確認をすり抜ける崩れも、残念ながらゼロにはできません。だから、出したあとに気づける目も用意しておきます。
大がかりな監視は要りません。まずは、AIの入力と出力を、あとで振り返れる形でログに残すこと。「いつ、どのプロンプト（版数）で、どんな入力に、どんな出力を返したか」が残っていれば、「先週から様子がおかしい」と言われたときに、原因のプロンプト変更までたどり着けます。
余力が出てきたら、「空の回答が返った」「決まった書式から外れた」といった分かりやすい異常の割合を数えるだけでも、崩れの兆しに早く気づけます。この「出したあとに測る」考え方は、AI機能の効果をログと指標で測る話とつながっています。プロンプトの版数をログに含めておくと、「どの版から悪くなったか」がはっきりして、切り分けが一気に楽になります。
プロンプト運用チェックリスト
本番でAI機能を動かしているなら、一度この観点で見直してみてください。全部を今日やる必要はありません。上から順に、できる所からで十分です。
切り出しと集約：
- プロンプトがコードの中にじかに書かれていないか
- プロンプトが1か所（専用フォルダ・ファイル）にまとまっているか
- 可変部分（入力・日付など）が、後から差し込む形になっているか
バージョンと履歴：
- プロンプトがGitなどで履歴管理されているか
- 「なぜ変えたか」が変更のたびに一言残っているか
- いざというとき、一つ前の版にすぐ戻せるか
出す前の確認：
- 代表的な入力（うまくいく例・過去に事故った例）が数本、固定で用意してあるか
- プロンプトを変えたら、旧版と新版を同じ入力で見比べているか
- 「直した所」だけでなく「変えていないつもりの所」も確認しているか
- 後段が期待する書式（JSONなど）が保たれているか見ているか
出したあとの監視：
- AIの入力・出力を、あとで振り返れる形でログに残しているか
- ログに、使ったプロンプトの版数が含まれているか
明日からやること（小さく始める3つ）
いきなり全部を整えようとすると重いので、まずこの3つから。
- いちばん重要な機能のプロンプト1本を、コードの外に切り出す：フォルダに1ファイル置くだけ。「散らばっている」から「1か所にある」へ、まず一歩。
- そのファイルをGitに載せ、先頭に版数と更新日をコメントで書く：これで「いつ・なぜ変えたか」が残り、戻せるようになります。
- 代表的な入力を3本だけ、テキストに書き留めておく：次にプロンプトを直すとき、この3本を旧版・新版に通して見比べる。出す前の事故が、ぐっと減ります。
この3つだけでも、「誰かがいつの間にか直して、どこかが壊れる」状態から、「変更を、落ち着いて確かめてから出せる」状態へ変わっていきます。
最後に
本番のプロンプトを触るのが少し怖いのは、あなたが慎重だからです。そしてその慎重さは、AIを実務に載せるうえで、いちばん大事な資質です。「変えたら何かが壊れるかも」と身構えられている時点で、あなたはもう、壊さない運用の入口に立っています。
一度に完璧な管理基盤を作らなくて大丈夫です。今日ひとつ、「大事なプロンプトを1本、コードの外に出す」だけ試してみる。そこに履歴と、数本の見比べを足していけば、プロンプトはもう「怖くて触れないもの」ではなく、「安心して育てていけるもの」に変わります。一歩ずつでいきましょう。