はじめに：AIの「なんとなく良さそう」が引き起こす本番環境のトラブル
近年、ChatGPTをはじめとする大規模言語モデル（LLM）を自社のサービスや業務システムに組み込む取り組みが急速に進んでいます。画面上でプロンプト（AIへの指示文）を入力し、思い通りの素晴らしい回答が返ってきたとき、「これは使える！」と感動した経験がある方も多いのではないでしょうか。
しかし、ここに大きな落とし穴が存在します。手元の数回のテストで「うまく動いた」ように見えても、いざ本番環境（プロダクション）へ投入した途端、予想もしなかったトラブルに見舞われるケースが後を絶ちません。
- ユーザーの入力パターンが変わると、突然ちぐはぐな回答を出力する
- 以前は正しく動作していたプロンプトを少し修正したら、別の機能が動かなくなった
- 想定外の長文を出力しはじめ、APIの利用コストが跳ね上がった
生成AI（LLM）は従来のソフトウェアのように「入力に対して常に100%同じ出力を返す」わけではありません。曖昧さや確率的な挙動を含むため、感覚に頼ったテストだけで本番公開するのは極めて危険です。
では、プロンプトの作成や改善を意味する「プロンプトエンジニアリング」を、どのようにして評価・運用し、安全に本番環境へ届ければよいのでしょうか？
本記事では、エンジニアのプラットフォームとして世界中で利用されているGitHubが公開した事例をもとに、LLMを本番導入する前に行うべき「プロンプトエンジニアリングの導入・設計・評価（Evaluation）ガイド」を分かりやすく解説します。
なぜ本番前のLLM評価（Evaluation）が必要なのか？
AIを用いた新機能を開発する際、多くの人が「どのようなプロンプトを書けば賢い回答が得られるか」に注目します。もちろん、プロンプトの工夫（プロンプトエンジニアリング）は欠かせません。しかし、プロンプトを変えたことによる結果の「良し悪し」を客観的に測定できなければ、改善しているのか改悪しているのかすら判断できません。
GitHubの「シークレットスキャン」事例に学ぶ
GitHubでは、ソースコードの中に誤って含まれてしまったパスワードやAPIキー（これらをまとめて「機密情報」や「シークレット」と呼びます）を自動で検出する「シークレットスキャン」という機能を扱っています。
この機能にLLMを応用する場合、以下のような極めて高い精度と信頼性が求められます。
- 見落としの防止: 機密情報が漏れているのに検出できないと、重大なセキュリティ事故につながる。
- 誤警告の防止: 普通の無害なコードを「機密情報だ！」と間違えて警告しすぎると、開発者の作業を邪魔してしまい、使われなくなってしまう。
手作業で数件のコードを試すだけでは、数万行、数百万行の多様なプログラムコードに対してAIが正しく判定できるかは分かりません。だからこそ、プロンプトを修正するたびに「全体の精度が向上したか」を定量的（数字）に測定する評価（Evaluation）の仕組みが必要欠かせないとなるのです。
プロンプトエンジニアリングとは、単に「上手な指示文を書くテクニック」にとどまりません。「適切なプロンプトを設計し、それを正しく評価し、継続的に改善する一連のプロセス」全体を指すものとして捉える必要があります。
実務で使える！プロンプトエンジニアリングの導入と評価の4つのステップ
それでは、実際に実務でLLMやプロンプトエンジニアリングを導入・設計・評価するための具体的なステップを解説します。
ステップ1: テスト用の「正解データセット（Ground Truth）」を作る
評価の第一歩は、「入力」と「理想的な出力（正解）」のペアを集めたテストデータセットを作成することです。
開発チーム内で「こういう質問や入力が来るだろう」という代表的なパターンを50〜100件程度用意します。シークレットスキャンの例であれば、「実際に機密情報が含まれるコード」と「機密情報っぽく見えるけれど安全なコード」の両方をバランスよく収集します。
この正解データセットが存在して初めて、プロンプトを変更した際に「正解率が上がったか・下がったか」を比較できるようになります。
ステップ2: 評価指標（メトリクス）を定義する
次に、AIの回答をどうやって点数化するかを決めます。専門用語を使わずに表現すると、主に次の2つの視点（指標）で評価を行います。
- 誤警告の少なさ（適合率/Precision）: AIが「危険だ」と判定したもののうち、本当に危険だった割合。この数値が高いほど、無駄なオオカミ少年的な警告が減ります。
- 見落としの少なさ（再現率/Recall）: 本来見つけるべき危険なデータのうち、AIが漏らさず検出できた割合。この数値が高いほど、見落としによる漏洩リスクが減ります。
システムの種類によって、どちらを優先すべきかは異なります。セキュリティ機能であれば「見落としの少なさ」を最重視すべきですし、ユーザー向けのおすすめ提案機能であれば「的外れな提案をしない（誤警告の少なさ）」を優先することもあります。
ステップ3: プロンプトエンジニアリングの設計と実験
正解データと評価指標が揃ったら、本格的なプロンプト設計に入ります。プロンプトエンジニアリングでは、以下のような要素を意識して指示文を組み立てます。
- 役割の定義（System Prompt）: 「あなたはセキュリティの専門家です」など、AIの立ち位置を明確にする。
- コンテキスト（背景情報）の提供: 判定に必要な追加情報やルールをあらかじめ与えておく。
- 出力形式の指定: 「判定結果（SAFEまたはDANGER）と、その理由をJSON形式で出力してください」のように、プログラムで扱いやすい形式を強制する。
- 少数の例示（Few-shot Prompting）: 正解・不正解の具体例をプロンプト内に2〜3個含めることで、AIの回答精度を劇的に向上させる。
プロンプトを書き換えたら、ステップ1で準備したデータセット全体に対して一括で処理を実行し、ステップ2の指標でスコアを測定します。
ステップ4: 自動評価パイプラインの構築（CI/CDへの組み込み）
プロンプトの評価を手動で行うのは時間がかかり、継続できません。通常のプログラムコードのテストと同じように、プロンプトの変更を検知して自動で評価を実行する仕組み（自動評価パイプライン）を構築します。
コードを変更してGitHubなどに送信（プッシュ）した際、自動的に評価プログラムが走り、「今回のプロンプト変更により、見落とし率は0%を維持しているが、誤警告が3%減少した」といったレポートが自動生成される状態を目指します。これにより、安心して本番環境へプロンプトをリリースできるようになります。
運用・設計における注意点とハマりやすい落とし穴
LLMの評価システムを運用するにあたり、現場で直面しやすい注意点や壁についても把握しておきましょう。
1. AIの「揺らぎ（非決定性）」への対処
LLMは同じプロンプトを与えても、毎回わずかに異なる出力を返す性質を持っています。そのため、1回のテスト結果だけで一喜一憂するのは危険です。 評価を行う際は、同じテストを複数回実行して平均値を算出するか、モデルのランダム性を抑える設定（Temperatureパラメータを0に近づけるなど）を検討してください。
2. 「出力フォーマット崩れ」の評価
本番システムでLLMを利用する場合、AIの回答をそのまま画面に表示するだけでなく、プログラムで解析して次の処理へ渡すケースが多くあります（JSON形式など）。 どれほど内容が正しくても、フォーマットが崩れてプログラムがエラーを起こしてしまっては意味がありません。「回答の内容が正しいか」だけでなく、「期待通りの形式で出力されているか」も評価項目に含める必要があります。
3. コストと処理速度（レイテンシ）のトレーディング
高い精度を求めようとしてプロンプトを長く複雑にしたり、高性能な大型モデルを採用したりすると、APIの呼び出し費用が高額になり、回答が返ってくるまでの待ち時間も長くなります。 実務においては、「精度の高さ」だけでなく「実行コスト」や「レスポンス速度」も含めた総合的な評価を行い、サービスとして許容できるバランスを見極めることが欠かせません。
4. 未確認事項・前提条件の取り扱い
なお、今回参照したGitHub Blogの一次情報では、LLMの評価手法や概念的なプロセスについての知見が共有されていますが、GitHub内部で実際に使用されているモデルの具体的な名称や、シークレットスキャンにおける評価自動化ツールのコード全容など、詳細な内部仕様のすべてが明記されているわけではありません（※これらは未確認事項となります）。導入時は自社のシステム環境や利用規約に合わせた設計を行ってください。
まとめ：プロンプトエンジニアリングは「書いて終わり」ではなく「評価して育てる」もの
プロンプトエンジニアリングというと、魔法のような「言葉選び」によってAIから最高の回答を引き出すテクニックのように思われがちです。しかし、実務やプロダクト開発におけるプロンプトエンジニアリングの本質は、**「客観的なデータに基づいてプロンプトの性能を測定し、エンジニアリング（工学）の手法で改善し続けること」**にあります。
最後に、本記事のポイントを振り返ります。
- 感触で判断しない: 手元の数回のテストではなく、定量的な評価（メトリクス）で比較する。
- 正解データセットを作る: 代表的な入力と理想の回答ペアを準備し、テストの基準にする。
- 評価を自動化する: プロンプトの修正が既存の挙動を壊していないか、継続的に自動テストを行う。
- 全体のバランスを見る: 精度だけでなく、出力フォーマットの安定性、コスト、応答速度も評価対象とする。
LLMを本番環境へ安全に導入するためには、しっかりとした「評価の仕組み」という土台が欠かせません。これから生成AIを使ったサービス開発や業務改善に取り組む方は、ぜひプロンプトの作成と同時に「どうやって評価するか」の設計から始めてみてください。
参考資料
- How to evaluate LLMs before production - The GitHub Blog https://github.blog/ai-and-ml/llms/how-to-evaluate-llms-before-production/