プロンプトも本番コードだ——AIエージェント時代の『プロンプト・リグレッションテスト』という設計

「動いているから大丈夫」が一番危ない瞬間

「検証してください」を削った翌日、私たちは主要な3つのタスクで応答を確認し、問題ないと判断しました。速くなった、正確さも変わらない、これで移行完了だと思っていました。

正直に言えば、見落としていたのは「主要な3つ」以外のタスクです。件の見積もりプロンプトは、月に数回しか使われない周辺タスクの1つでした。普段は誰も気に留めていない処理だったからこそ、壊れたことに気づくのが遅れました。

恥ずかしながら、削った一文と見積もりの端数処理を結びつけて考えたことは一度もありませんでした。プロンプトの変更は、変更した箇所だけでなく、そのプロンプトが担うすべてのタスクに影響します。しかもコードと違って、プロンプトが「壊れた」状態はエラーを吐きません。もっともらしい、しかし間違った答えを返すだけです。

プロンプトは本番コードなのに、なぜテストされないのか

このセクションで言いたいことは、プロンプトとコードの間にある「規律の非対称性」です。

コードを1行変更すれば、CI が単体テストを走らせ、失敗すればマージがブロックされます。ところがプロンプトを1行変更しても、多くの現場では「動かして確認」以上のことをしていません。ある記事は、この問題を「プロンプトは本番動作なのに、コードに適用されるあらゆる安全柵の外にある」と表現しています(Testing LLM Prompts Like Code)。これは私たちの実感とも完全に一致します。

理由は明確です。プロンプトの変更は「思いつき」で行われることが多く、Gitでコミットされていても、テストスイートと紐づいていないケースがほとんどです。Claude Opus 5のような新しいモデルへの移行では、この非対称性が一気に表面化します。1つのモデル向けに最適化した数十行のプロンプトを、まとめて書き換える機会が生まれるからです。

リグレッションテストの三層構造をプロンプトに応用する

ソフトウェアのリグレッションテストには、単体・統合・E2Eという三層構造があります。ある日本語記事は、この三層をLLM時代のテストにそのまま応用できると指摘しています(LLMだからこそのリグレッションテストのすすめ)。

私たちの実務に置き換えると、こうなります。単体テストは「このプロンプト単体で、この入力に対してこの出力が返るか」。統合テストは「このプロンプトが呼び出す外部ツールやRAGの検索結果まで含めて正しく機能するか」。E2Eテストは「ユーザーが実際に使う画面から入力し、期待通りの成果物が生成されるか」です。

この記事が興味深いのは、「テストは実装とズレた瞬間に失敗する」という一点を、ドキュメントとの違いとして強調していることです。ドキュメントには解釈の余地がありますが、テストコードは「入力Aに対して出力Bが返る」という曖昧さのない定義になります。プロンプトの仕様書を別途整備する余力がない現場ほど、この考え方は効きます。

ゴールデンセット(テストケース)の作り方

リグレッションテストの土台は、正解付きのテストケース、いわゆる「ゴールデンセット」です。ここで完璧を目指すと、いつまでも着手できません。

promptfooというOSSツールを使ったCI/CD統合の解説記事は、「まずは最も問題を起こしやすいプロンプトについて、10個のテストケースを書くところから始めよ」と勧めています(Testing LLM Prompts Like Code)。これは私たちの感覚とも一致していて、全プロンプトを一斉にテスト化しようとすると、最初の一歩が重すぎて止まってしまいます。

具体的には、プロンプト・入力データ・期待するアサーション(検証条件)をYAML形式で宣言します。同記事が示す例では、「A300プリンタの印字速度」という質問に対して、正確な値(80ppm)を含み、誤った値(100ppm)を含まないことを検証しています。この「間違った値が混ざっていないか」という否定側の検証は、見落とされがちですが実務では非常に効きます。

私たちがある需要予測システムの発注判断プロンプトで最初に着手したのも、まさにこの「よく事故が起きるプロンプト」でした。全プロンプトの一斉テスト化ではなく、過去に修正が集中したプロンプトから優先順位をつけています。

決定論的アサーションと、モデルに採点させるアサーション

すべての出力を厳密一致で検証できるわけではありません。ここで押さえておきたいのが、アサーション(検証条件)には2つの種類があるという整理です(Testing LLM Prompts Like Code)。

決定論的アサーションは、文字列の一致(contains、regex)、フォーマット検証(is-json)、コストや応答時間の上限(cost、latency)など、速くて安くて安定していますが、表現の揺れには弱い検証です。もう一方のモデル採点アサーションは、llm-rubric(採点基準に沿った評価)やfactuality(事実性の評価)のように、別のモデルに採点させる方式で、表現の揺れに強い一方、遅く・コストがかかり・結果が毎回同じとは限りません。

誤解のないように言えば、どちらか一方を選ぶ話ではありません。数値やフォーマットのように答えが1つに決まるものは決定論的アサーションで、文章の質やトーンのように幅があるものはモデル採点アサーションで検証する、という使い分けが実務的です。

閾値をどう決めるか——完全一致を求めるとビルドが壊れる

ここで多くのチームがつまずくのが、合格ラインの設定です。モデル採点アサーションは非決定論的なので、満点の合格を要求すると、プロンプトを一切変更していなくてもビルドが不安定になります。ある記事は95%を一つの目安として示しています(Testing LLM Prompts Like Code)。

一方で、閾値は一律に決められるものでもありません。QA領域を扱う別の記事は、「小さな数値の変化は、ある領域では許容できても、別の領域では危険になりうる」と指摘しています(Prompt Regression Testing Guide)。発注金額を扱うプロンプトと、社内向けの雑談要約プロンプトとでは、許容できる誤差がまったく違います。

私たちの現場では、金額や発注数量に関わるプロンプトは決定論的アサーションを中心に厳密に、文章生成系のプロンプトはモデル採点アサーションで緩やかに、という使い分けをしています。全プロンプトに同じ閾値を当てはめると、厳しすぎて開発が止まるか、緩すぎて事故を見逃すかのどちらかになります。

CI/CDに組み込む——マージを止める仕組み

テストケースを書いただけでは、次にプロンプトを変更した人がそれを実行するとは限りません。ここで重要なのが、CI/CDへの統合です。

promptfooはGitHub Actionとして提供されており、プルリクエスト上で変更前後の出力を比較表示できます(Testing LLM Prompts Like Code)。合格率が閾値を下回れば、マージそのものをブロックできます。

Claude Codeを使った開発現場向けの提案では、少し違うアプローチも紹介されています。AIエージェントの応答が終わるタイミング(Stop hook)で自動的にテストを実行し、失敗したら作業完了をブロックする、という仕組みです(LLMだからこそのリグレッションテストのすすめ)。この記事では、修正のループ回数に上限(5回)を設け、それを超えたら人間に相談するという制約も置かれていました。AIに直させ続けるのではなく、どこかで人間に戻す設計です。

私たちの現場でも、AIエージェントに直させ続けて時間だけが溶けていく場面を何度か見てきました。「直らなければ人間に相談する」という降参ラインをあらかじめ引いておくのは、地味ですが効果の大きい工夫だと感じています。

Git管理か、専用LLMOpsツールか

テストケースやプロンプト自体を、どこでバージョン管理するかも論点です。ある整理では、2026年時点の潮流として「シンプルなGit管理から、プロンプト管理専用のLLMOpsツールへの移行」が進んでいるとされ、LangfuseやLangSmithといったツールが、バージョン管理・A/Bテスト・デバッグ機能を統合した選択肢として挙げられています(System Promptのバージョン管理)。

ただし同じ記事は、Git管理にも「無料で既存のCI/CDにそのまま統合できる」という利点があると認めています。専用ツールは修正・実験のスピードが上がる一方、新しい依存を1つ増やすことにもなります。

私たちの結論は、開発段階ではGit、本番運用ではLLMOpsツールというハイブリッドが現実的だという立場です。移行のたびに全プロンプトをツールに載せ替えるのは負担が大きく、まずは事故が多いプロンプトから専用ツールに移す方が、着手のハードルが下がります。

テストコード化できない領域への対応

すべてがテストコードに落とし込めるわけではありません。文言のトーンやブランドらしさは、正解を1つに決められない領域です。

ここで参考になるのが、「テストコード化できない項目は、確認チェックリストに変換する」という発想です(LLMだからこそのリグレッションテストのすすめ)。AIの作業終了時に確認項目を突きつけ、素通りを防ぎます。正解が書けない場合は、変更前後の「差分」を検出して記録し、その差分を許容するかどうかは人間が判断する、というやり方も紹介されていました。ビジュアル面であれば、スクリーンショットのピクセル単位の差分比較(ビジュアルリグレッションテスト)という手法もあります。

私たちがコラム記事のレビュー工程で使っている仕組みも、この発想に近いものです。文字数や引用密度のような数値は自動でチェックしますが、「AI-Pathらしい語り口になっているか」は最終的に人間が読んで判断します。テストコード化と人間の確認は、対立する選択肢ではなく、役割分担です。

私たちがOpus5移行で実際にやったことを、テストとして振り返る

前回の記事で、私たちは「まず1つのクライアント分のプロンプト集を1日で書き直し、動作を確認してから他のクライアントへ横展開する」という進め方を紹介しました。振り返ると、これは簡易的なリグレッションテストを、意識せずに実践していたのだと思います。

ただし正直に言えば、当時の「動作確認」は、主要なタスクを目視で確認する程度にとどまっていました。冒頭の見積もりプロンプトの事故は、まさにこの「主要なタスクだけ確認して、周辺タスクを見落とす」という穴から起きています。

今回改めて仕組み化するなら、各クライアントのプロンプト集について、過去にトラブルが起きたタスクから優先的に10件程度のテストケースを用意し、モデル移行のたびにそのテストケースだけは欠かさず実行する、という運用にします。全件を毎回テストするのではなく、事故の起きやすい箇所に絞ることで、着手のハードルを現実的な水準に保てます。

まず何から始めるべきか

いきなり全社のプロンプト資産をテスト化しようとすると、まず間違いなく挫折します。私たちが勧めるのは、次の順番です。

1つ目は、過去にトラブルが起きた、あるいは修正が集中したプロンプトを1つ選ぶこと。2つ目は、そのプロンプトについて10件程度のテストケースを書き、決定論的に検証できる項目とモデル採点が必要な項目を仕分けること。3つ目は、そのテストをモデル移行やプロンプト変更のたびに欠かさず実行するというルールを、チームで最初に1つだけ決めることです。

閾値の見直しやCI/CDへの本格統合は、この最初の1件がうまく回ってから広げれば十分です。ある記事も、四半期ごとの見直しを一つの目安として挙げています(Prompt Regression Testing Guide)。私たちの経験でも、最初から完璧な体制を目指すより、事故の多い1箇所から着手したチームの方が、定着までが早いと感じています。

私たちの見解

プロンプトのリグレッションテストという発想は、「AIは壁打ち相手であり、判断は人間がする」という私たちの基本姿勢と、実はまっすぐにつながっています。テストケースの合否を決めるのはAIですが、その合否基準(何を許容し、何を許容しないか)を決めるのは、最後まで人間の役割だからです。

モデルが新しくなるたびにプロンプトを書き直すのは、これからも避けられません。だとすれば、書き直すたびに「何が変わって、何が変わらなかったか」を確認できる仕組みを持っておくかどうかが、事故の起きやすさを大きく左右します。プロンプトを「思いつきで直すもの」から「テストして直すもの」に変える。地味な話ですが、AIエージェントが本番業務に深く入り込むほど、この地味な仕組みの有無が効いてくる、というのが私たちの実感です。

よくある質問

Q. 全てのプロンプトにリグレッションテストを用意する必要がありますか。 A. いいえ。まずは過去にトラブルが起きた、あるいは修正が集中したプロンプトから着手することをお勧めします。全件を最初から対象にすると、着手のハードルが上がりすぎます。

Q. promptfooのような専用ツールを導入しないとリグレッションテストはできませんか。 A. できます。Git管理下のYAMLファイルと、シェルスクリプトによる合格率判定だけでも最低限の仕組みは作れます。専用ツールは、テストケースの数が増えて手作業での管理が辛くなってから検討しても遅くありません。

Q. モデル採点アサーションはどの程度信頼できますか。 A. 非決定論的なので、完全一致は求めるべきではありません。95%前後を一つの目安に、業務インパクトの大きさに応じて閾値を調整することをお勧めします。

Q. AIエージェント(サブエージェントへの委任やツール呼び出し)を含むプロンプトもテストできますか。 A. できますが、最終的な応答だけでなく、途中の計画・ツール選択・呼び出し結果まで含めて検証する必要があります。最終出力だけを見ていると、途中の工程で起きた劣化を見逃す可能性があります。

Q. 社内に専門のエンジニアがいない場合でも導入できますか。 A. 最初の一歩(頻繁に問題が起きるプロンプトについて10件のテストケースを書く)であれば、専門知識がなくても着手できます。ただし決定論的アサーションとモデル採点アサーションの使い分けは、一度エンジニアと一緒に整理しておくと以降が楽になります。

まず試すなら

1. 過去にトラブルが起きた、あるいは修正が集中したプロンプトを1つ選ぶ。 全件からではなく、事故の多い箇所から着手します。
2. そのプロンプトについて10件程度のテストケースを書き、期待する出力を明文化する。 「間違った値が混ざっていないか」という否定側の検証も忘れずに入れます。
3. モデル移行やプロンプト変更のたびに、そのテストだけは欠かさず実行するというルールをチームで1つ決める。 全体への展開は、この1件が回ってから考えます。

自社のプロンプト資産にどれだけ「見えないリスク」が眠っているか、把握できていない企業は多くいらっしゃいます。私たちは無償の業務プロセス診断(BPR)を実施しており、AIエージェントへの指示設計とテスト体制を含めた現状の棚卸しをお手伝いしています。まずは無償の業務診断で、どこにリスクが眠っているかを明らかにしませんか。

Claude Opus 5への移行そのものについては、関連記事: Claude Opus 5で「検証して」が逆効果に もあわせてご覧ください。

参考リンク

• LLMだからこそのリグレッションテストのすすめ テストが仕様書になる（Zenn）
• Testing LLM prompts like code: regression evals in CI/CD with promptfoo（Medium）
• 【LLMプロダクト/AIエージェント】LLMアプリケーションにおけるSystem Promptのバージョン管理（Zenn）
• Prompt Regression Testing: Version Prompts Without Breaking QA（QASkills）