「あちらを立てればこちらが立たず」
LLM（大規模言語モデル）を使ったチャットボットや対話AIの開発において、これほど痛感する言葉はありません。
特定のユーザー発話パターンに対する回答精度を上げようとプロンプトを調整したら、今まで完璧に答えていた別の質問に対して、突然不自然な回答をするようになってしまった——。いわゆる「デグレ（リグレッション）」です。
対話フローの設計やAIエージェントの開発現場では、この「モグラ叩き」のような状況によく遭遇します。多くの現場では、スプレッドシートに想定される質問と回答のペアをずらりと並べ、プロンプトを修正するたびに担当者が一つひとつ目視で確認しているのが実情ではないでしょうか。
しかし、論理的に考えれば「これは人間がやるべき仕事ではない」と気づくはずです。
Web開発の世界では当たり前の「自動テスト」や「CI/CD（継続的インテグレーション/デリバリー）」が、なぜかプロンプトエンジニアリングの文脈では置き去りにされがちです。LLMの出力が確率的で曖昧だからでしょうか？ いいえ、ツールと設計思想さえあれば、LLMの挙動もコードと同じようにテストし、管理することができます。
今回は、開発者体験（DX）に優れたテストツール「Promptfoo」を活用し、プロンプトの品質保証を「職人芸」から「エンジニアリング」へと昇華させ、ユーザーテストと改善のサイクルを効率的に回す方法について解説します。
なぜ、プロンプトエンジニアリングに「自動テスト」が不可欠なのか
プロンプトエンジニアリングは、しばしば「魔法の呪文」を探す作業のように語られます。しかし、ビジネスで運用する以上、それは再現性のある「工学」でなければなりません。感覚的な調整ではなく、エンジニアリングとしての品質保証が求められるフェーズに来ています。
LLM開発における「修正の副作用」とデグレのリスク
従来のソフトウェア開発における単体テスト（Unit Test）は、入力Aに対して必ず出力Bが返ってくることを保証します。しかし、LLMは「非決定的」なシステムです。同じプロンプト、同じ入力であっても、モデルのバージョンアップやわずかなパラメータの違い、あるいは単なる確率の揺らぎによって出力が変わることがあります。
さらに厄介なのが、プロンプトの修正が及ぼす影響範囲の予測不可能性です。「口調を少し丁寧に」という指示を追加しただけで、JSON形式の出力フォーマットが崩れたり、特定の推論タスクでの精度が低下したりすることがあります。これがプロンプト開発における「バタフライエフェクト」です。
手動テストだけに頼っていると、こうした副作用（デグレ）を見落としたまま本番環境にリリースしてしまうリスクが常に付きまといます。そして、ユーザーからのクレームで初めて不具合に気づくという、エンジニアとして最も避けたい事態を招きかねません。
目視確認の限界と「評価疲れ」のコスト
スプレッドシートでの管理には限界があります。テストケースが10個や20個なら目視でもなんとかなるでしょう。しかし、本番運用に耐えうる品質を担保するには、数百、数千のケースが必要です。
人間が数百行のテキストを読み、以前の回答と比較して「良くなったか悪くなったか」を判定するのは、精神的にも時間的にも莫大なコストがかかります。これを「評価疲れ」と呼びます。疲れてくると判定基準がブレ始め、テスト自体の信頼性が揺らぎます。
また、エンジニアの時間単価を考えても、単純な目視確認に時間を割くのはROI（投資対効果）が悪すぎます。対話フローの改善や、より高度な対話設計といった創造的な課題解決に時間を使うべきです。
Promptfooが選ばれる理由：開発者体験（DX）重視の設計
そこで注目されているのが「Promptfoo」です。世の中には様々なLLM評価ツールがありますが、Promptfooが選ばれる理由の一つとして、徹底して「エンジニアフレンドリー」な点が挙げられます。
- CLIベース: ターミナルからコマンド一発で実行でき、結果もコマンドラインやローカルサーバーですぐに確認できます。GUIツールを行き来する必要がなく、開発のリズムを崩しません。
- Configuration as Code: テストケースや設定をYAMLやJSONファイルで記述します。これにより、プロンプトやテスト設定をソースコードと同様にGitで管理でき、変更履歴の追跡が容易になります。Gitの最新機能による履歴管理とも相性が良く、チーム開発でのコンフリクト解消もスムーズです。
- CI/CD統合: GitHub Actionsなどのパイプラインに容易に組み込めます。特に、GitHub Actionsの最新環境ではホストランナーのコストパフォーマンスが大幅に改善されており、プルリクエストごとの自動テスト（回帰テスト）を低コストで回せるようになっています。コードレビュー時には、プロンプトの変更がテスト結果にどう影響したかを定量的に確認してからマージする、堅牢なフローを構築可能です。
GUIポチポチ系のツールとは異なり、既存の開発ワークフローに自然に溶け込む点が、AIエンジニアにとって非常に扱いやすいのです。
Step 1: 最小構成で「最初のテスト」を走らせる
「テスト自動化」と聞くと、複雑な環境構築を想像して身構えてしまうかもしれません。ですが、Promptfooの導入は驚くほどシンプルです。まずは手元のローカル環境で、最小構成のテストを動かしてみましょう。小さな成功体験を早く得ることが、継続的な品質向上の第一歩です。
インストールから初期化（init）まで
PromptfooはNode.js環境で動作します。npmやnpxを使ってコマンド一発でセットアップできるのが魅力です。適当な作業用ディレクトリを作成し、以下のコマンドを実行してください。
mkdir prompt-test-demo
cd prompt-test-demo
npx promptfoo@latest init
コマンドを実行すると、対話形式でいくつかの質問（使用するプロバイダーやテストファイルの形式など）をされます。初めての場合は、基本的にデフォルトの選択肢（Enterキー）を選んで進めて問題ありません。完了すると、ディレクトリに promptfooconfig.yaml という設定ファイルが生成されます。
シンプルな設定ファイル（yaml）の構造理解
生成された promptfooconfig.yaml をエディタで開いてみましょう。構成は非常にシンプルで、主に3つの要素で成り立っています。この3つさえ押さえれば、基本的なテストは回せます。
- prompts: テストしたいプロンプト（またはそのファイルパス）
- providers: 使用するLLM（OpenAI, Anthropic, Googleなど）
- tests: テストデータ（入力変数と期待する結果）
以下は、簡単な「日本語から英語への翻訳ボット」をテストする最小構成の例です。
重要: AIモデルの進化は非常に速く、利用可能なモデルIDは頻繁に変更されます。以下の例ではOpenAIのモデルを指定していますが、実際には公式ドキュメントで最新のモデルIDを確認して設定してください。古いモデルID（例: ChatGPT初期版など）は廃止されている場合があるため注意が必要です。
# promptfooconfig.yaml
prompts:
- "あなたはプロの翻訳家です。次の日本語を英語に翻訳してください：{{input}}"
providers:
# 注意: モデルIDは変動します。最新のID（例: ChatGPT, ChatGPT等）を
# PromptfooまたはOpenAIの公式ドキュメントで確認して記述してください。
- id: openai:ChatGPT
config:
temperature: 0
tests:
- vars:
input: "こんにちは、元気ですか？"
assert:
- type: contains
value: "Hello"
- vars:
input: "このリンゴは美味しいです。"
assert:
- type: icontains
value: "apple"
この例では、{{input}} という変数をプロンプトに埋め込み、tests セクションで具体的な値を流し込んでいます。そして assert で「出力に特定の単語が含まれているか」をチェックしています。このように、期待値を明確に定義することが、対話型AIの品質管理における重要なエンジニアリングプロセスとなります。
CLIでの実行と結果ビューアの確認
設定ができたら、テストを実行します。なお、OpenAIなどのAPIキーは環境変数として設定しておく必要があります。
# APIキーを設定（Mac/Linuxの場合）
export OPENAI_API_KEY=sk-...
# テストを実行
npx promptfoo eval
実行が完了すると、ターミナルに簡易的な結果が表示されます。これだけでも成否は分かりますが、Promptfooの真骨頂はブラウザベースのビューアにあります。以下のコマンドを実行してみてください。
npx promptfoo view
ブラウザが立ち上がり、表形式でテスト結果が表示されます。どの入力に対して、どのモデルがどう回答し、テストにパスしたか（Pass）失敗したか（Fail）が一目瞭然です。
この「緑（成功）と赤（失敗）の可視化」こそが、品質管理のスタートラインです。修正のたびにこのコマンドを叩くだけで、以前の挙動が壊れていないか（リグレッションしていないか）を瞬時に確認できる安心感は、一度味わうと手放せなくなります。
Step 2: 「なんとなく」を排除するアサーション（評価基準）の設計
ツールが動いたら、次は「どう評価するか」という設計の話です。ここが最も重要で、エンジニアの腕の見せ所ですね。単なる文字列一致だけでは、柔軟なLLMの回答を正しく評価できません。
Promptfooには多彩なアサーション（評価ロジック）が用意されています。用途に合わせて使い分けることで、「なんとなく良い感じ」という定性的な評価を、定量的なスコアに変換できます。
決定論的評価：contains, regexによるキーワードチェック
最も基本的かつ低コストな評価です。出力に特定のキーワードが含まれているか、あるいは特定の正規表現にマッチするかを確認します。
- type: contains: 指定した文字列が含まれているか。
- type: regex: 正規表現にマッチするか（例：電話番号の形式、JSONフォーマットなど）。
これらは計算コストがほぼゼロで高速ですが、LLMが「Hello」の代わりに「Hi」と答えただけでテストが落ちてしまう脆さがあります。フォーマットの遵守確認などに向いています。
assert:
- type: regex
value: "^\\{.*\\}$\" # JSON形式で始まって終わっているか
意味論的評価：similarによるベクトル類似度判定
「言葉は違うが、意味は同じ」というケースを救うのが、Embedding（埋め込みベクトル）を用いた類似度判定です。
- type: similar: 期待する回答（正解データ）と、実際の回答のベクトル類似度（Cosine Similarity）を計算し、閾値を超えているかを判定します。
tests:
- vars:
input: "キャンセル料はかかりますか？"
assert:
- type: similar
value: "はい、前日までのキャンセルであれば無料ですが、当日は100%の料金を頂戴します。"
threshold: 0.8 # 類似度が0.8以上なら合格
これにより、表現の揺らぎを許容しつつ、意図が合っているかを自動判定できます。RAG（検索拡張生成）などの回答精度評価で非常に有効です。
LLMによる評価：model-graded-closedqaでAIに採点させる
さらに高度な評価として、「LLMにLLMを評価させる（LLM-as-a-Judge）」方法があります。人間が採点基準（Rubric）を与え、AIに採点を行わせます。
Promptfooでは llm-rubric や model-graded-closedqa といったタイプを使用します。
assert:
- type: llm-rubric
value: "回答は丁寧な敬語を使用しており、かつユーザーに共感を示していること。"
この設定を行うと、評価用モデル（通常はChatGPTの最新モデルやClaudeの最新モデルなどの高性能LLM）が回答を読み、「丁寧な敬語か？」「共感があるか？」を判定し、Pass/Failを決めてくれます。
特に最近のLLMは推論能力（Reasoning）が大幅に強化されており、複雑な文脈理解や論理的な採点が可能になっています。Promptfooの設定では、評価を行うモデル（Judgeモデル）を明示的に指定できるため、評価タスクには推論に特化した最新の上位モデルを割り当てるのが一般的です。
コストと時間はかかりますが、人間の感覚に最も近い評価が可能になります。クリティカルなユースケースにはこのLLM評価を適用し、それ以外は類似度判定で済ませるというハイブリッドな構成を採用するケースが多いですね。
Step 3: 開発フローに組み込むための実践的テクニック
ローカル環境でのテスト運用が軌道に乗ったら、次はチーム開発のワークフローに組み込んでいきましょう。ここからが「DevOps」ならぬ「LLMOps」の真骨頂です。開発の効率性と品質を両立させるための、より実践的な構成をご紹介します。
外部ファイル参照によるプロンプトとテストデータの管理
設定ファイルである promptfooconfig.yaml にすべてのプロンプトやテストケースを直接記述すると、ファイルが肥大化し、可読性が著しく低下します。実務では、以下のように外部ファイルを参照する形での分割管理が必須です。
# promptfooconfig.yaml
# プロンプトファイルとテストケースを分離して参照
prompts: [file://prompts/chat_v1.txt]
providers: [openai:chatgpt-latest] # ※プロジェクトで採用するモデルIDを指定
tests: file://tests/customer_support_cases.yaml
このように記述することで、プロンプトファイル（prompts/chat_v1.txt）のみを修正してテストを実行するというサイクルがスムーズになります。Git上でもプロンプトの変更差分が明確になり、コードレビューの効率が格段に向上します。
Matrix機能を使った複数モデル・複数パラメータの一括比較
「ChatGPTの最新モデルは高性能だがコストが高い。軽量版モデルで同等の精度が出せないか？」
「Claudeの最新モデルと比較して、日本語のニュアンスはどう変わるか？」
「Temperature（創造性の度合い）を下げたらハルシネーションは減るか？」
こうした検証も、Promptfooなら設定ファイルを少し調整するだけで一括実行できます。特に最近では、GitHub Copilotなどの開発支援ツールでも、OpenAIのモデルだけでなくClaudeやGeminiなど多種多様なモデルを選択できるようになっています。開発環境で利用しているモデルと、プロダクション環境で利用予定のモデルの挙動差異を確認する上でも、この比較機能は強力な武器になります。
providers:
# 複数のモデルやパラメータを並列で検証
- id: openai:chatgpt-latest
label: "High-Accuracy Model"
- id: openai:chatgpt-mini
label: "Cost-Effective Model"
- id: anthropic:claude-latest
label: "Claude Model"
config:
temperature: 0.5
複数のプロバイダーを列挙すれば、同じテストケースを全モデルで並列実行し、結果を横並びで比較可能です。
また、最新のLLMトレンドとして、推論プロセスを強化した「思考モード」を持つモデルや、ヘルスケア等の特定領域に特化した機能が登場しています。これらは従来のモデルとは応答特性が大きく異なる場合があるため、Matrix機能を使って「従来のプロンプトが新モデルでも意図通り機能するか」を回帰テストすることは非常に重要です。コスト削減のためのモデル選定や、新モデル登場時の移行検証において、Promptfooは不可欠なツールと言えるでしょう。
CI/CDパイプラインでの回帰テスト自動化イメージ
最終的なゴールは、CI/CD（継続的インテグレーション/継続的デリバリー）への統合です。GitHub ActionsなどのワークフローにPromptfooを組み込むことで、プルリクエストが作成されるたびに自動でテストが走り、品質低下（デグレ）があればマージをブロックする体制を構築できます。
GitHub Actionsの環境も進化しており、ホストランナーのコストパフォーマンス向上や、より高速な実行環境の整備が進んでいます。これにより、以前はコストや時間の面で敬遠されがちだった「CIでのLLMテスト実行」が、より現実的な選択肢となっています。
一般的な運用フローは以下のようになります。
- エンジニアがプロンプトを修正し、ブランチをプッシュ。
- GitHub Actions等のCIツールが起動し、
npx promptfoo evalを実行。 - テスト結果のサマリ（Pass率や失敗したケース）をPRのコメントに自動投稿。
- もしPass率が基準値を下回っていたら、アラートを出してマージを阻止。
また、Promptfooには promptfoo share というコマンドがあり、実行結果を一時的なURLで共有することも可能です（セキュリティポリシーに応じた利用が必要ですが）。これにより、非エンジニアのQA担当者やPMがブラウザで結果を確認し、承認を行うといったフローも実現できます。
よくある落とし穴とトラブルシューティング
夢のような自動化ですが、運用すると直面する現実的な課題もあります。事前に対策を知っておきましょう。
APIコストの急増を防ぐためのキャッシュ戦略
テストを自動化すると、実行回数が飛躍的に増えます。特にLLMに評価を行わせる「LLM-as-a-Judge」形式を多用すると、API利用料が無視できない金額になります。
Promptfooはデフォルトでキャッシュ機能を持っています。一度実行したプロンプトと結果のペアはローカルにキャッシュされ、変更がない限り再利用されます。これにより、無駄なAPIコールを防げます。
また、開発フェーズに応じてモデルを使い分けるのも有効な戦略です。
例えば、日常的なテスト実行にはAPIコストの低い軽量モデル（ChatGPTの軽量版やClaudeの高速モデルなど）を使用し、リリース前の最終確認や複雑な推論が必要なケースでのみ、推論能力が強化された最新モデルに切り替えるよう設定ファイルを構成します。特に最近のトレンドとして、旧世代のモデルよりもコストパフォーマンスに優れた最新の軽量モデルが登場しており、これらを活用することで品質担保とコストのバランスを最適化できます。
「評価揺れ」への対処法
「テストコードは変えていないのに、昨日パスしたテストが今日落ちた」。これはLLM開発において避けて通れない現象です。
これを防ぐために、プロバイダーの設定で temperature を 0 に近づけ、決定論的な挙動に寄せることが基本です。しかし、それでも生成結果の揺らぎは完全にはゼロになりません。
評価を行う側のLLM（Judgeモデル）自体も揺らぐことがあります。対策としては、以下の方法が挙げられます。
- 評価プロンプトの厳密化: 評価基準（Rubric）を具体的に記述し、解釈の余地を減らす。
- 思考プロセスの活用: Judgeモデルにいきなり点数を出させるのではなく、評価理由を考えさせてから採点させる（Chain of Thought等の手法）。ChatGPTの最新モデルなど、思考モード（Thinking Mode）を備えたモデルをJudgeとして採用することで、より論理的で安定した評価が期待できます。
- 試行の平均化: 数回の評価を行って平均を取る設計を検討する。
とはいえ、まずは「100%の完全な再現性は求めない」という割り切りも必要です。閾値（Threshold）を厳しくしすぎないのが、テスト運用を継続させるコツです。
機密情報の取り扱いと環境変数
業務で使用する場合、テストデータに実際の顧客データ（PII）を含めないよう厳重に注意してください。テストデータは必ずダミーデータや合成データ（Synthetic Data）を使用しましょう。
また、APIキーなどの機密情報は絶対にリポジトリにコミットしてはいけません。.env ファイルを使用し、.gitignore に追加する基本動作を徹底してください。
CI/CD環境では、GitHub Secretsなどのシークレット管理機能を利用して安全に運用しましょう。GitHub Actionsなどのプラットフォームでは、ランナーコストの最適化が進んでおり、CIでのテスト実行がより身近になっていますが、その分、自動化ワークフロー内でのキー管理やアクセス権限の設定には細心の注意が必要です。
まとめ：テスト自動化で「攻め」のプロンプト開発を
プロンプトエンジニアリングにおけるテスト自動化は、単なる「バグ潰し」ではありません。それは、エンジニアが安心して改善に挑戦するための「命綱」です。
テストという安全ネットがあるからこそ、私たちは大胆なプロンプトの書き換えや、新しいモデルへの乗り換えに挑戦できます。デグレを恐れて現状維持に甘んじるのではなく、常に品質を向上させ続けるサイクルを回せるようになるのです。
本記事のポイント:
- 脱・目視評価: Promptfooで定性評価を定量化し、評価コストを削減。
- アサーション設計: 文字列一致だけでなく、類似度やLLM（思考モード対応モデル等）による評価を組み合わせて多角的に品質を担保。
- CI/CD統合: 開発フローにテストを組み込み、デグレを未然に防ぐ仕組みを構築。
もし、開発現場が日々のプロンプト調整と手動テストに疲弊しているなら、今こそエンジニアリングの力で解決する時です。
品質への自信が、プロダクトへの信頼を生み出し、最終的にはユーザーにとって価値のある自然で効果的なAIサービスの提供に繋がります。
コメント