AIを組み込んだ業務システムの開発で、意外と軽く扱われがちなのがプロンプト（生成AIに与える指示文）です。コードは当然のようにバージョン管理されるのに、プロンプトは管理画面のテキストエリアに直接書かれていたり、ソースコードの中に文字列として埋め込まれたまま誰がいつ変えたか分からなくなっていたり、ということが起こります。
しかしAIシステムにおいて、出力品質の大半を左右するのはプロンプトです。つまりプロンプトは「設定値」ではなく、コードと同格の資産として扱うべきものです。この記事では、プロンプトを変更履歴つきで管理し、品質が落ちたときに安全に元へ戻せる仕組みの作り方を、中小企業の現場で実行可能な範囲に絞って解説します。
なぜプロンプトは「いつの間にか壊れる」のか
プロンプトが劣化する経路は、だいたい次の3つに集約されます。
- その場しのぎの追記が積み上がる：「この聞き方だと答えてくれない」という個別クレームに対し、条件分岐のような注意書きを足していく。半年後には矛盾した指示が同居している
- モデルの更新で挙動が変わる：利用しているAPIのモデルがバージョンアップされ、従来うまく動いていた指示の効き方が変わる
- 変更者と検証者が分離していない：担当者が本番環境で直接書き換え、自分が試した入力だけで「直った」と判断してしまう
いずれも共通するのは、「前の状態に戻す手段がない」という点です。コードであればGitの履歴から1コマンドで戻せますが、管理画面に直書きしたプロンプトは、上書きした瞬間に前のバージョンが消えます。たとえば次のような場面です。問い合わせ分類の精度が落ちたという報告があり、原因が1週間前のプロンプト修正だと推測できても、修正前の文面が残っていないため元に戻すこともできない。こうなると原因の切り分け自体が不可能になります。
プロンプトをコードとして扱う三つの原則
難しい仕組みは要りません。まず次の3点を守るだけで、状況は大きく変わります。
| 原則 | 内容 | やらないとどうなるか |
|---|---|---|
| 外部化 | プロンプトをソースコードやDBのレコードに埋め込まず、独立したファイル（テキスト・YAML・JSONなど）として切り出す | 変更のたびにアプリ全体のデプロイが必要になるか、逆に履歴なしで書き換えられてしまう |
| 版管理 | プロンプトファイルをGitなどのバージョン管理システムに入れ、変更理由をコミットメッセージに残す | 誰が何のために変えたか追えず、差し戻し判断ができない |
| 検証 | 変更前後で同じ入力セットを流し、出力の変化を比較してからリリースする | 特定ケースだけ直り、他が壊れる「もぐら叩き」になる |
ここで言うGitとは、ファイルの変更履歴を記録し、任意の時点に戻せるようにするバージョン管理ツールです。ソフトウェア開発では事実上の標準で、GitHubやGitLabといったホスティングサービスと組み合わせて使われます。プロンプトはただのテキストですから、Gitとの相性は非常に良いのです。
プロンプトファイルの設計 — 何を分離し、何を残すか
外部化するとき、1つの巨大なテキストファイルにすると結局メンテナンス不能になります。役割ごとに分けるのが基本です。
- システムプロンプト：AIの役割・口調・禁止事項といった、案件を通じて変わらない土台の指示
- タスクテンプレート：「要約する」「分類する」など処理ごとの指示。変数の差し込み口（プレースホルダ）を持たせる
- 少数事例（few-shot例）：望ましい入出力のサンプル。精度への影響が大きく、変更頻度も高いので独立させる
- 出力スキーマ：JSON形式などで返させたいときの構造定義
加えて、ファイルの先頭にメタ情報を持たせておくと運用が楽になります。バージョン番号、対象モデル名、最終更新日、関連する評価セットのIDなどです。対象モデル名を明記しておくのは特に重要で、モデルを乗り換えたときに「このプロンプトはどのモデル向けにチューニングされたものか」が分からなくなる事故を防げます。
バージョン番号の付け方
セマンティックバージョニング（1.2.3のような3桁表記）の考え方を借りると整理しやすくなります。
| 桁 | 上げるタイミング |
|---|---|
| メジャー | 出力形式が変わる、役割定義を作り直すなど、呼び出し側の修正が必要な変更 |
| マイナー | 指示の追加・few-shot例の追加など、互換性を保った機能追加 |
| パッチ | 誤字修正、言い回しの微調整 |
差し戻しを支える「評価セット」の作り方
戻せる仕組みの本体は、実はバージョン管理ではなく評価セットです。評価セットとは、入力と「期待される出力の条件」をセットにしたテストデータ群のこと。これがないと、変更が改善なのか改悪なのかを判定できません。
中小企業が現実的に始めるなら、次の規模感から始めるとよいでしょう。
- 代表ケースを20〜50件集める：実際の業務データから、典型例・境界例・過去に失敗した例をバランス良く選ぶ
- 判定基準を言語化する：「必ずJSONで返る」「禁止ワードを含まない」のような機械判定できる条件と、「要点が3つ以上含まれる」のような人の目視条件を分ける
- 変更のたびに一括実行する：スクリプトで全件を流し、結果を表形式で前バージョンと並べる
完全自動の採点にこだわる必要はありません。機械判定できる部分（形式・禁止表現・必須項目の有無）だけ自動化し、残りは差分が出た件だけ人が見る、という半自動でも十分実用になります。重要なのは「変更前と同じ条件で比べた記録が残る」ことです。
なお、評価セットに実際の顧客データや個人情報を含める場合は、取り扱いに注意が必要です。個人情報の保護に関する法律（個人情報保護法）や、個人情報保護委員会が公表しているガイドライン類を確認し、必要に応じて匿名化・仮名化してから利用してください。外部のAIサービスにデータを送る構成では、利用規約上の学習利用の有無もあわせて確認対象になります。
実装で詰まりやすい箇所
1. プロンプト変更の反映タイミング
ファイル外部化をすると、「変更したのに本番に反映されない」という問い合わせが必ず来ます。起動時に一度だけ読み込むキャッシュ設計が原因であることが多く、設定の再読込エンドポイントを用意するか、管理画面から明示的にリロードできる導線を作っておくと混乱が減ります。
2. 非エンジニアが編集できない問題
Gitでの管理は堅牢ですが、業務部門の担当者には敷居が高い。現実的な折衷案は、管理画面から編集させつつ、保存のたびに履歴レコードを必ず作る方式です。編集者・日時・変更前文面・変更理由を1レコードとして残し、一覧から任意の版へワンクリックで戻せるようにします。Gitほど強力ではありませんが、「戻せる」という最重要要件は満たせます。
3. モデル更新への追随
主要なAIサービスでは、モデルに日付入りのバージョン識別子が割り当てられていることが多く、固定指定もできます。本番環境ではバージョンを固定し、更新は評価セットを流して確認してから切り替えるのが安全です。常に最新を自動参照する設定は、ある朝突然出力が変わるリスクを抱えます。
4. 差し戻し後の「なぜ戻したか」が消える
戻す操作そのものも記録対象です。「v1.4で分類精度が落ちたためv1.3へ戻した」という理由を残さないと、数か月後に同じ変更を誰かが再び行います。
まとめ
プロンプト管理の要点を整理します。
- プロンプトはコードと同格の資産であり、埋め込みではなく外部ファイルとして分離する
- 変更は必ず履歴に残す。Gitが使えれば理想だが、管理画面＋履歴テーブルでも「戻せる」要件は満たせる
- 差し戻しの判断を支えるのは評価セット。20〜50件の代表ケースから始めれば十分機能する
- モデルのバージョンは本番で固定し、更新は検証を経てから切り替える
- 戻した理由も記録し、同じ失敗の反復を防ぐ
これらは高価なツールを必要としません。最初の一歩は「いま本番で動いているプロンプトを全文コピーして、日付をつけて保存する」ことです。その一手間があるだけで、次にAIの挙動がおかしくなったとき、原因の切り分けにかかる時間が大きく変わります。AIシステムの受注開発をご検討の際は、こうした運用設計まで含めてご相談ください。