AI実装録 / プロンプト管理と回帰
プロンプト管理と回帰 — 静かな品質劣化を防ぐ
最終更新: 2026年7月4日
生成 AI を業務に組み込むうえで、プロンプトの取扱いは設定ファイルよりも「コード」に近い判断が必要になります。 プロンプトを微修正するたびに出力の性格は変わり、履歴を残さないと後から追跡することは困難です。
本稿では、プロンプトのバージョン管理と、モデル更新・仕様変更に対する回帰検証を、どのように組み合わせて運用するかについて論じます。
本稿が対象とする AI 利用シーン
AI の使い方によって、プロンプト管理に求められる負荷は大きく異なります。当社では、業務における AI 利用を次の 5 つに分けて整理しています。
| シーン | プロンプトの性格 | 管理負荷 |
|---|---|---|
| A. 定型・大量・自動処理 | 一つのテンプレを繰り返し実行し、入力だけが変わる | 重い |
| B. 対話型アシスタント | System prompt は安定、ユーザ入力が大きく変動する | 中 |
| C. エージェント・多段処理 | 段ごとにプロンプトが独立し、ツール定義や統合が絡む | 重い |
| D. 一回きり生成 | 使い捨ての生成物で、集計的な影響を持たない | 軽い |
| E. 監修型（人間主導 + AI 補助） | 人間の判断が主体で、プロンプトは補助的な位置 | 軽〜中 |
本稿は A 型（同系統の処理を大量に自動化するシーン）を対象とします。 A 型では、同じテンプレが繰り返し実行されるため、テンプレの微修正がすべての出力に伝播します。したがって、版管理と回帰検証の重要性が突出します。B〜E 型については、それぞれ管理の形が異なり、稿を改めて扱います。
プロンプトを「コード」として扱う
プロンプトを .env や JSON の設定値と同列に扱うと、変更が誰にも見えないまま本番に流れる状態が生まれます。 この状態では、出力の性格が変わった際に、原因の切り分けが極めて困難になります。
当社では、プロンプトを Git で版管理し、変更の意図はコミットメッセージまたは判断ログに残すことを基本にしています。 あわせて、モデル ID の切替も「無害な小変更」としては扱いません。 同一モデルであってもマイナーバージョンの更新で出力の傾向が変わることは珍しくなく、プロンプトの改訂と同格の管理対象として扱う必要があります。
版管理すべき五つの要素
プロンプト運用においては、次の五つの要素を独立に版管理する設計を採ります。
- プロンプト本文：テンプレート化し、外部ファイル（例:
prompts/street.md）として切り出します。 - モデル ID と生成パラメータ：モデル名、temperature、max_tokens、許可ツールなどをコード側で定義します。
- Few-shot 例と情報源：ハードコードせず、参照可能なファイルとして保持します。
- 出力スキーマとバリデータ：JSON Schema や TypeScript の型定義、必須フィールドの検証ロジックを併置します。
- 自己検証チェックリスト：プロンプト末尾に組み込む「出力前に自ら点検する」項目群を明文化します。
五要素のいずれか一つでも変われば出力の性格は変わりうるため、変更管理は要素単位で追跡できる状態にします。
回帰検証の三構成
プロンプトや周辺要素を変更した際、または本番モデルを更新する際は、以下の三構成で回帰検証を行います。
- 代表サンプル集：業務で発生しうる入力を、典型例に加えて例外・過去に失敗した事例を含めて 30〜50 件 用意します。少なすぎると変化を検出できず、多すぎると運用負荷で回らなくなります。
- 合格基準：スキーマ一致、必須フィールドの充足、禁則語彙の非出現、字数範囲、出典の妥当性など、機械的に判定できる項目を先に置きます。人間の判定はその外側に絞ります。
- 判定の記録：どのバージョンで何件が合格したか、判定者は誰か、次はいつ再実施するかを記録します。CI に組み込まなくても、月次で一度、判断ログと紐付けて残す形でも機能します。
当社が運営する京都の街コンテンツ配信基盤では、Wikipedia と京都市公式情報を情報源として、通り単位の構造化 JSON を LLM で編纂しています。 編纂結果は観光客と京都在住者の双方に届く説明文となるため、地の文の register に次の制約を置いています。
- 標準語の敬体で書く：京都弁を模して書くと、ステレオタイプ化した「観光ガイド調」の register になり、在住者に違和感を与えるためです。京都弁は引用文としてのみ許容します。
- 主観形容詞を避ける：「美しい」「賑わう」「有名な」等の評価的表現は、公式情報源への忠実さと相反するためです。
- 推測情報を載せない：情報源に確証がない年号や事実は、空欄に倒します。
これらの意図はプロンプト本文の冒頭で説明していますが、モデルは長いプロンプトの冒頭指示を部分的に無視することがあります。そこでプロンプト末尾に 8 項目の自己検証チェックリスト を組み込み、生成前に LLM 自身に点検させます。主な項目は次のとおりです。
- 京都弁の語尾を地の文で使っていない（「やね」「どす」「はる」等が一つもない）
- 主観形容詞を地の文で使っていない（「美しい」「賑わう」「有名な」等）
- 歴史情報は時系列順で 8 件以内、年に推測がない
- 出典 URL とライセンス表記（CC BY-SA 4.0 等）が sources に含まれる
- 出力の最初が
{、最後が}、前置きの説明文を含まない
同じ項目は生成後のバリデータでも機械的に走らせ、人間の目視は月次で 5〜10 件のサンプリングに留めます。 この二重化により、モデル更新やプロンプト改訂の影響を早期に検出できる状態を維持しています。
モデル更新への備え
モデル ID の入れ替え、すなわち同じプロンプトを新しいモデルで動かす行為は、プロンプトを一切触っていなくても出力の性格を変えます。 既存の版で通っていた自己検証項目が新モデルでは崩れることがあり、逆に新モデルで初めて安定する項目もあります。
当社では、モデル切替を予定した時点で回帰サンプル集を実行し、合格しなければ切替を保留する運用にしています。 またモデル更新の際は、切替日時、旧モデル ID、新モデル ID、差分の要点を判断ログとして残します。
既存プロンプトの表現を少し変えて即本番に反映するパターンは、短期的には動くように見えます。 しかし複数回繰り返すと、次のいずれかが起きます。
- 過去の出力と新しい出力の性格が微妙に違うが、原因を辿れない
- モデル更新のタイミングで出力品質が急変し、どのプロンプトのどの版が起点か特定できない
- 別の担当者が同じプロンプトを触った際に、以前の意図を知らずに元の表現へ戻してしまう
回帰検証がない状態でこれを繰り返すと、品質劣化は静かに進行します。 誤りが業務側で顕在化してから追跡を始めても、原因の特定は困難です。
まとめ
プロンプトを設定値として扱うと、AI の品質は静かに変わり、原因は残りません。 プロンプトを「コード」として扱い、五要素を独立に版管理し、代表サンプル集で回帰検証する仕組みが、業務側が品質に責任を持つための前提となります。
特にモデル更新は無害ではありません。プロンプトの改訂と同等の慎重さで扱い、切替判断の記録を残すことを推奨します。 本稿の姿勢は 評価と品質 および AI 開発・運用ポリシー 第 4 項（人間による判断）と一体として設計しています。