確率的な課題
従来のソフトウェアは予測可能です。入力Aに関数Bを適用すれば、常に出力Cになります。この決定論（determinism）により、エンジニアは堅牢なテストを開発できます。一方で生成AIは確率的（stochastic）で予測不可能です。同じプロンプトでも、月曜日と火曜日で結果が異なることがあります。これは、エンジニアが知り、愛している従来のユニットテストを壊してしまいます。
エンタープライズ対応のAIを出荷するには、今日通っても、顧客が製品を使ったときに失敗する「雰囲気チェック（vibe checks）」に頼るわけにはいきません。プロダクトを作る側は、新しいインフラストラクチャ層を導入する必要があります。それがAI Evaluation Stackです。
このフレームワークは、リスクの高い業界で、フォーチュン500のエンタープライズ顧客向けにAIプロダクトを出荷してきた、私の豊富な経験に基づいています。そこでは「幻覚（hallucination）」は笑い話ではありません。重大なコンプライアンス上のリスクです。
AI評価パラダイムの定義
従来のソフトウェアテストは2値のアサーション（pass/fail）です。AI評価の中には2値のassertを使うものもありますが、多くはグラデーション（連続的な評価）で評価します。評価（eval）は単一のスクリプトではありません。厳密なコード構文から、繊細なセマンティック（意味）チェックまでを含む、アサーションの構造化されたパイプラインであり、AIシステムが意図した機能を果たしているかを検証します。
評価チェックの分類体系
堅牢で費用対効果の高いパイプラインを構築するには、アサーションを2つの明確なアーキテクチャ層に分ける必要があります。
レイヤー1：決定論的アサーション
本番環境でのAI障害のうち、驚くほど大きな割合を占めるのは、意味的な「幻覚」ではありません。基本的な構文エラーやルーティング失敗です。決定論的アサーションは、パイプラインの最初のゲートとして機能し、従来のコードや正規表現（regex）を使って構造的な完全性を検証します。
「応答が『役に立つ』かどうか」を問うのではなく、このアサーションは厳密で2値の質問をします。
モデルは正しいJSONのキー/値スキーマを生成したか？
必要な引数を伴って、正しいツール呼び出しを実行したか？
正しいGUIDまたはメールアドレスを、正常にスロットフィルできたか？
// 例：レイヤー1 決定論的ツール呼び出しアサーション
{
"test_scenario": "ユーザーはアカウントを調べるよう求める",
"assertion_type": "schema_validation",
"expected_action": "APIを呼び出す：get_customer_record",
"actual_ai_output": "お客様を見つけました。",
"eval_result": "FAIL - AIが必要なAPIペイロードの代わりに会話文を幻覚的に生成した。"
}
上の例では、モデルが必要なツール呼び出しペイロードではなく会話文を生成したため、テストは即座に失敗しました。
アーキテクチャ上、決定論的アサーションはスタックの最初の層であり、「fail-fast（即時に失敗）」という計算コストの低い原則に基づいて動作しなければなりません。下流のAPIが特定のスキーマを要求する場合、形式の崩れたJSON文字列は致命的なエラーです。この層で評価を即座に失敗させることで、エンジニアリングチームは（レイヤー2の）高コストなセマンティックチェックを引き起こすのを防ぎ、（レイヤー3の）貴重な人手によるレビュー時間を無駄にしないようにできます。
レイヤー2：モデルベースのアサーション
決定論的アサーションが通過したとき、パイプラインは意味の質を評価する必要があります。自然言語は流動的なため、従来のコードでは「応答が『役に立つ』か」や「『共感的』か」を簡単にアサートできません。そこで、モデルベースの評価、一般に「LLM-as-a-Judge」または「LLM-Judge」と呼ばれる手法が導入されます。
非決定論的なシステムを別の非決定論的システムの評価に使うのは直感に反するように見えますが、ニュアンスが必要なユースケースに対しては非常に強力なアーキテクチャパターンです。「応答が『実行可能（actionable）』か」や「『礼儀正しい』か」を検証する信頼できる正規表現を書くことは、ほぼ不可能です。人間のレビュアーはこのニュアンスに長けていますが、数万件ものCI/CDテストケースを評価するところまでスケールしません。したがって、LLM-as-a-Judgeは、人間の見分けを代替するスケーラブルな代理（proxy）になります。
モデルベースのアサーションに必要な3つの重要な入力
ただし、モデルベースのアサーションが信頼できるデータを生み出すのは、LLM-as-a-Judgeに3つの重要な入力が与えられている場合に限られます。
最先端の推論モデル： 審査（Judge）は、本番モデルよりも優れた推論能力を持っていなければなりません。レイテンシのために、より小さく高速なモデルでアプリを動かしているなら、審査側も最前線の推論モデルにして、人間レベルの見分けに近づける必要があります。
厳格な評価ルーブリック： 「この回答はどれくらい良いか評価して（Rate how good this answer is）」のような曖昧な評価プロンプトは、ノイズの多い確率的（stochastic）な評価を生みます。頑健なルーブリックでは、失敗と成功のグラデーション（段階）を明確に定義します。（たとえば「有用性（Helpfulness）」のルーブリックでは、スコア1を無関係な拒否、スコア2をプロンプトには答えているが実行可能な手順が欠けている状態、スコア3を文脈の範囲内で厳密に実行可能な次のステップを提示している状態、のように定義すべきです。）
正解（ゴールデン出力）： ルーブリックがルールを提供しますが、人間が事前検証した「期待される回答（expected answer）」が答え合わせ（answer key）として機能します。LLM-Judgeが、本番モデルの出力を検証済みのGolden Outputと比較できる場合、スコアリングの信頼性は劇的に高まります。
アーキテクチャ：オフラインとオンラインのパイプライン
堅牢な評価アーキテクチャには、2つの補完的なパイプラインが必要です。オンラインのパイプラインはデプロイ後のテレメトリを監視します。一方、オフラインのパイプラインは、確率的モデルを安全に評価するために必要な、基礎となるベースラインと決定論的な制約を提供します。
オフライン評価パイプライン
オフラインパイプラインの主な目的は回帰テストです。つまり、本番環境に出す前に失敗、ドリフト、レイテンシを特定します。ゲート（起点）となるオフライン評価スイートなしでエンタープライズLLMの機能をデプロイするのは、アーキテクチャ上のアンチパターンです。未コンパイルのコードをメインブランチにマージするのと同等だからです。
プロセス
1. ゴールデンデータセットの選定
オフラインのライフサイクルは、「ゴールデンデータセット（golden dataset）」の選定から始まります。これは、AIの全運用エンベロープを表す200〜500件のテストケースを収めた、静的でバージョン管理されたリポジトリです。各ケースでは、正確な入力ペイロードと、期待される「ゴールデン出力（golden output）」（正解となるグラウンドトゥルース）をペアにします。
重要なのは、このデータセットが、想定される現実のトラフィック分布を反映している必要があることです。ほとんどのケースは標準的な「ハッピーパス（happy-path）」のやり取りをカバーしますが、エンジニアは体系的にエッジケース、脱獄（jailbreaks）、および敵対的な入力を取り入れなければなりません。ストレス下での「拒否能力（refusal capabilities）」を評価することは、厳格なコンプライアンス要件として残ります。
テストケースペイロードの例（標準的なツール使用）：
入力： 「来週火曜日の午前10時に、クライアントへ30分間のフォローアップ会議を予約してください。」
期待される出力（ゴールデン）： システムは、正しいJSONペイロードでschedule_meetingツールを正常に呼び出します：{"duration_minutes": 30, "day": "Tuesday", "time": "10 AM", "attendee": "client_email"}。
何百ものエッジケースを手作業で個別に選別するのは面倒ですが、専門特化したLLM を使って、多様な TSV/CSV のテスト用ペイロードを生成する合成データ生成パイプラインによって、このプロセスを加速できます。とはいえ、AI が生成したテストケースに全面的に依存すると、データ汚染やバイアスのリスクが生じます。この段階ではヒューマン・イン・ザ・ループ（HITL）アーキテクチャが必須です。ドメインの専門家が合成データセットを手作業でレビューし、編集し、検証して、それがリポジトリにコミットされる前に、現実のユーザーの意図や企業ポリシーを正確に反映していることを確認しなければなりません。
2. 評価基準の定義
データセットが整備されたら、エンジニアは、モデル出力ごとに複合スコアを算出するための評価基準を設計する必要があります。堅牢なアーキテクチャは、レイヤー1（決定論的）とレイヤー2（モデルベース）のアサートのハイブリッドに対して、重み付きポイントを割り当てることで実現します。
AIエージェントが「メールを送信する」ツールを実行すると考えてください。評価フレームワークは、次のような10点満点の採点システムを用いるかもしれません：
レイヤー1：決定論的アサート（6点）： エージェントは正しいツールを呼び出しましたか？（2点）。有効なJSONオブジェクトを生成しましたか？（2点）。JSONは期待されるスキーマに厳密に準拠していますか？（2点）。
レイヤー2：モデルベースのアサート（4点）：（注：意味論的なルーブリックは、利用ケースごとに非常に具体的である必要があります。）件名行はユーザーの意図を反映していますか？（1点）。メール本文は幻覚なしで期待される出力と一致していますか？（1点）。CC/BCCフィールドは正確に活用されていますか？（1点）。適切な優先度フラグが推論されていますか？（1点）。
LLM-Judge がこれらの点数を与えた理由を理解するには、エンジニアは各スコアの根拠を judge に提示するようプロンプトする必要があります。これは失敗のデバッグに不可欠です。
合格閾値とショートサーキット（短絡）ロジック
この例では、8/10 の合格閾値は、成功には8点が必要であることを意味します。重要なのは、評価パイプラインが厳密なショートサーキット評価（fail-fastロジック）を強制する必要があることです。モデルが、たとえば不正なJSONスキーマの生成など、いずれかの決定論的アサートに失敗した場合、システムは直ちにテストケース全体を失敗（0/10）にしなければなりません。基盤となるAPI呼び出しが構造的に壊れているのに、メールの意味論的な「丁寧さ」を評価するために高価なLLM-Judge を呼び出しても、アーキテクチャ上の価値はまったくありません。
3. パイプラインの実行とシグナルの集約
任意の評価インフラストラクチャを用いて、システムはオフラインのパイプラインを実行します。通常これは、プルリクエスト中にブロッキングのCI/CDステップとして統合されます。このインフラはゴールデンデータセットを反復し、各テストペイロードを本番モデルに投入して出力を取得し、その出力に対して定義されたアサートを実行します。
各出力は合格閾値に照らして採点されます。バッチ実行が完了すると、結果は全体の合格率に集約されます。エンタープライズ品質のアプリケーションでは、ベースラインの合格率は通常 95%, を超える必要があり、厳格なコンプライアンスや高リスク領域では 99% 以上へスケールさせます。
4. 評価、反復、アラインメント
集約された失敗データに基づき、エンジニアリングチームは失敗したテストケースについて根本原因分析を行います。この評価は、コアコンポーネントへの反復的な更新を導きます。たとえばシステムプロンプトの改善、ツール説明の変更、知識ソースの拡充、あるいは（temperature や top-p のような）ハイパーパラメータの調整などです。95%の合格率に到達した後でも、継続的な最適化はベストプラクティスとして維持されます。
重要なのは、システムのいかなる変更でも完全な回帰テストが必要だという点です。LLMは本質的に非決定論的であるため、特定の1つのエッジケースを直す目的の更新が、他の領域での想定外の劣化を引き起こし得ます。更新によって品質が向上した一方で回帰が導入されていないことを検証するために、オフラインのパイプライン全体を再実行しなければなりません。
オンライン評価パイプライン
オフラインのパイプラインが厳格なデプロイ前の門番として機能する一方で、オンラインのパイプラインはデプロイ後のテレメトリシステムです。目的は現実世界の振る舞いを監視し、創発するエッジケースを捉え、モデルのドリフトを定量化することです。アーキテクトは、5つの異なるカテゴリのテレメトリを取得できるようアプリケーションを計測しなければなりません：
1. 明示的なユーザーシグナル
モデルの性能を示す、直接的で決定論的なフィードバック：
サムズアップ/ダウン： 不釣り合いに強いネガティブフィードバックは、システム劣化の最も即時の主要指標です。これにより、直ちにエンジニアリングによる調査へと導かれます。
アプリ内の記述どおりのフィードバック： 書かれたコメントを体系的に解析することで、新しい失敗モードが特定でき、それをオフラインの「ゴールデンデータセット」に統合するためにフィードバックへ戻せます。
2. 暗黙的な行動シグナル
行動テレメトリは、ユーザーが明示的なフィードバックをせずに諦めてしまったような「静かな失敗」を明らかにします：
再生成およびリトライの率： リトライが高頻度で発生する場合、最初の出力がユーザーの意図を解決できなかったことを示します。
お詫び率： ヒューリスティックなトリガー（「すみません」）をプログラム的にスキャンすることで、能力の低下やツールルーティングの不具合を検知できます。
拒否率： 拒否率が不自然に高い（「それはできません」）場合、過度に調整された安全性フィルタが、無害なユーザーの問い合わせを拒否していることを示します。
3. 本番の決定論的アサート（同期）
決定論的なコードチェックはミリ秒で実行されるため、チームはレイヤー1のオフラインアサート（スキーマ整合、ツールの妥当性）をシームレスに再利用し、本番トラフィックの100%を同期的に評価できます。これらの合格/不合格率を即時にログに記録することで、不正な出力の異常な急増（スパイク）を検知できます。これは、静かなモデルドリフトやプロバイダ側のAPI変更を最も早く知らせる警告サインです。
4. 本番 LLM-as-a-Judge（非同期）
厳格なデータプライバシー契約（DPA）が許可する場合、ユーザー入力のログを取れるため、モデルベースのアサートを導入できます。アーキテクチャ上、本番のLLM-Judge はクリティカルパス上で同期実行してはなりません。そうするとレイテンシと計算コストが倍増します。代わりに、バックグラウンドで LLM-Judge を動かし、毎日のセッションの一部（5%）を非同期にサンプリングして、オフラインのルーブリックに基づいて出力を採点し、継続的な品質ダッシュボードを生成します。
フィードバックループの設計（「フライホイール」）
評価パイプラインは「一度設定して放置する」インフラではありません。継続的なアップデートがなければ、ユーザー行動が変化したり、顧客が新しい利用ケースを見つけたりすることで、静的なデータセットは「腐食（rot）」（概念ドリフト）に悩まされます。
例えば、人事（HR）チャットボットが、給与計算の標準的な質問に対してオフラインの合格率99%を誇っているとします。しかし、企業が突然新しいストック・エクイティ計画を発表した場合、ユーザーはすぐにベスティング（権利確定）スケジュールについてAIに質問し始めます。この領域は、オフライン評価には完全に欠けています。
システムを時間とともにより賢くするには、生産環境のテレメトリを掘り起こして継続的な改善につなげる、クローズドループのフィードバックを設計しなければなりません。
継続的改善のワークフロー：
記録： ユーザーが明示的なネガティブシグナル（「サムズダウン」）または本番での暗黙的な行動フラグをトリガーする。
トリアージ： 対象のセッションログが自動的にフラグ付けされ、人のレビューのために振り分けられる。
根本原因分析： ドメインの専門家が失敗を調査し、ギャップを特定し、同様の要求に成功して対応できるようにAIシステムを更新する。
データセット拡張： 新規のユーザー入力は、修正された期待出力と対でオフラインのゴールデンデータセットに追記され、さらにいくつかの合成バリエーションとともに追加される。
回帰テスト: この新たに発見されたエッジケースに対して、モデルは今後のすべての実行において継続的に再評価されます。
本番環境のログを監視せず、データセットを更新しないまま評価パイプラインを構築することは、本質的に不十分です。ユーザーは予測できません。古いデータで評価すると、危険な錯覚が生まれます。オフラインでの通過率が高いことで、急速に悪化する実世界での体験が隠れてしまうのです。
結論: 新しい「完了（definition of done）」の定義
生成AIの時代において、機能や製品は「コードがコンパイルされ、プロンプトが首尾一貫した応答を返す」だけでは、もはや「完了」とは言えません。厳密で自動化された評価パイプラインが導入され、安定していること — そして、モデルが厳選されたゴールデンデータセットと、新たに発見された本番のエッジケースの両方に対して一貫して合格すること — それらを満たしたときに、はじめて完了です。
このガイドは、その現実を構築するための包括的な設計図をあなたに提供してきました。オフラインの回帰パイプラインの設計からオンラインのテレメトリまで、継続的なフィードバックのための仕組み、そしてエンタープライズにおけるアンチパターンの回避まで、これでAIシステムをより高い確信をもって導入するための土台が整いました。
あとは、あなたの番です。エンジニアリング、プロダクト、法務の各チームとこのフレームワークを共有し、組織内のAI品質に関する統一された部門横断の標準を確立してください。モデルが本番で劣化しているかどうかを当て推量するのをやめ、計測を始めましょう。
Derah OnuorahはMicrosoftのシニア・プロダクトマネージャーです。
