核心内容の要約
AIエージェントがチャットツールから実際のビジネス操作（CRMデータの更新、返金処理、コードのデプロイなど）へと進化するにつれて、そのエラーは単なる「でたらめ」では済まされない。システム自体にエラーメッセージが表示されない場合でも、誤って航空券を予約したり、顧客情報を間違えたり、返金処理を忘れたりすることで実際の損失が発生する可能性がある。そのため、GoogleやMicrosoft、Grafanaなどのプラットフォームではエージェントに対する「品質検査機能」を導入している。これには、可観測性（エージェントの操作全体を記録する機能）と評価（結果が正しいかどうかを判断する機能が組み合わされており、エラーの発見から修正・最適化までのサイクルが形成されている。これにより、企業はビジネスプロセスを明確にし、特定のプラットフォームに縛られることなく運用できる。
一、エージェントが本当に重要な仕事をするようになったのに、なぜ突然品質検査が必要なのか？
以前はエージェントは単にチャットを行うだけで、ユーザーはすぐに誤りを訂正できた。しかし今ではデータを変更したり、お金を使ったり、メールを送信したりする権限があり、その結果が実際のビジネスに影響を与える。例えば航空券の予約時にシステムは「成功」と表示されても（技術的には問題なし）、実際には翌日の便に予約されたり、搭乗者情報が間違っていたりすることがある。さらに厄介なのは、モデルのアップデートやヒント文言の変更、新しいツールの導入によってエージェントの動作が微妙に変わり、今日は問題なくても次週にはエラーが発生する可能性があることだ。
従来の監視システムでは「システムがダウンしたかどうか」（インターフェースの遅延やCPU使用率など）しか確認できず、「ビジネス処理が正しく行われたかどうか」は把握できなかった。AnthropicのClaude Codeの例が典型的で、ユーザーはエージェントの性能が低下したと感じるが、実際にはモデル自体に問題はなく、デフォルトの推論強度の設定やコンテキスト処理のバグ、ヒント文言の最適化がプログラミング品質に悪影響を与えていた。これらの隠れた問題は従来の監視システムでは発見できなかった。
二、評価（Eval）と可観測性（Observability）：一つは正誤を判断し、もう一つはプロセスをチェックする
これら二つはよく混同されるが、その役割は全く異なる：
- 可観測性：「何が起こったのか」を記録する。ユーザーがどのような要求をしたか、エージェントがどのツールを使用したか、パラメータは何を設定したか、各ステップにどれだけ時間がかかったか、どのデータが変更されたかなどを記録する。まるでエージェントに「ドライブレコーダー」を装着したようなもので、問題が発生した際にはその原因を調べることができる（モデルの理解ミスか、ツールのパラメータ設定の誤りかなど）。
- 評価：「この処理が正しかったかどうか」を判断する。返金が実際に行われたか？問い合わせが適切に処理されたか？コードがテストに合格したか？機密情報が漏洩していないかなどを確認する。例えばエージェントが「返金が完了しました」と言っても、評価機能は実際の支払いシステムの状態を確認する。
Microsoftは次のように説明している：「可観測性は何が起こったかを記録し、評価はそれが正しかったかどうかを判断し、最適化は次に何を変更すべきかを決定する。トレースがなければエラーの根本原因を見つけることはできない。トレースがあっても、どの処理が問題だったのか、単なる迂回路だったのかを区別することは難しい。」
三、品質検査機能は単に画面を追加するだけではない。サイクルを形成する必要がある
品質検査機能を構築するには、単に監視画面を追加するだけでは不十分で、「問題の発見→問題の解決→再発防止」というサイクルを形成する必要がある：
1. トレースの記録：エージェントが何かを行うたびに、その全過程を記録する（どのツールを使用したか、どのデータベースフィールドを変更したかなど）。
2. 失敗の特定：トレースからビジネス上のエラーを見つけ出す（誤って航空券を予約したり、本人確認を忘れたりするなど）。
3. テスト用データの作成：これらの実際の失敗例を匿名化して、エージェントのテスト用データに変換する（次回「明日の上海行きの航空券を予約」という要求があった場合には、自動的に日付や搭乗者情報をチェックする）。
4. システムの修正：エラーに基づいてシステムを改善する（ヒント文言の調整や権限チェックの追加など）し、その後テスト用データで再度確認する。
5. 小規模なリリース：まず一部のユーザーに試験的に機能を提供し、新たな問題が発生しないかを観察する。
評価方法も組み合わせて使用する必要がある。ルール（注文が正しく生成されたか、金額が正しいかなど）はスクリプトでチェックし、開放的な判断（カスタマーサービスの対応が適切かなど）はLLM（大規模言語モデル）を使用する。高リスクなケース（金銭や権限に関わるもの）は必ず人の目で確認する。これにより効率的かつ信頼性が高まる。
四、品質検査機能は企業に「何が正しいのか」を明確にさせる
多くの企業は「カスタマーサービスをより役立たせる」「営業担当者が顧客を理解すること」などと言うが、これらのあいまいな要求はエージェントには理解できない。品質検査機能を構築する際には、これらの要求を確認可能なルールに変換する必要がある：
- 「カスタマーサービスをより役立たせる」とは、ユーザーの問題が解決された場合に限るか、単に安心させるだけでいいのか？いつ人の手を借りるべきか？
- 「営業担当者が顧客を理解する」とは、A顧客の情報をB顧客のCRMに誤って入力しないようにすること。
- 「レポートの品質を高める」とは、重要な結論には信頼できる根拠が必要で、適当な内容ではない。
これらのルールはビジネスの詳細に隠されており（金融機関のコンプライアンス要件やeコマースのアフターサービス基準など）、積み重ねることで企業の重要な資産になる。大手企業はこれらのルールを実装するために競争しており（Googleは自社のエージェントプラットフォームに組み込もうとし、MicrosoftはFoundryに収録しようとしている）。特定のプラットフォームに縛られないために、企業はOpenTelemetryなどのオープンな標準を使用してトレースを記録する傾向がある。これにより、モデルやプラットフォームを変更しても自社のノウハウを保持できる。
最後：エージェントの競争の変化
以前はAIの「賢さ」が競われていたが、今では「信頼性」が競われている。行動が可視化され、結果が確認可能で、エラーが修正できるようになった。エージェントに永遠に間違いを犯さないことを求めるのではなく、何を止めるべきか、何を尋ねるべきかを知らせ、システムがその行動を記録し、エラーを次回のテスト用データに変えることが重要だ。エージェントは本当に重要な仕事を始めており、品質検査機能はそれらが企業の核心的なプロセスに組み込まれるための「入場券」となっている。