AI エージェントのデモから本番環境へ：自動テストと評価に関する発表

InfoQ ホームページ

プレゼンテーション一覧

AI エージェントのデモから本番環境へ：自動テストと評価

プレゼンテーションを見る

再生時間:

ダウンロード

48:20

/presentations/ai-agent-testing-evaluation/en/slides/slide-1787636878526.jpg)

概要

Zhou Yu は、なぜ AI エージェントがデモ段階で停滞してしまうのかを解説し、シミュレーション駆動型のテストがコンプライアンスと信頼性のボトルネックをどう解決するかを共有します。コロンビア大学と Arklex AI がどのように合成されたユーザーペルソナや軌道エントロピーを活用し、自動化された CI/CD パイプラインを通じて多段階の対話を処理するエージェントを評価しているか、また本番環境での自己学習ワークフローをどうスケーリングしているかなどについて学びます。これにより、デプロイ前にエッジケースを検出し、実運用での信頼性を高めることが可能になります。

登壇者紹介

Zhou (Jo) Yu はコロンビア大学のコンピュータサイエンス教授であり、Arklex.ai の創設者です。また、コロンビア大学 DAPlab の共同ディレクターも務めています。彼女の研究成果は主要な自然言語処理（NLP）カンファレンスで複数の最優秀論文賞を受賞しており、2018 年にはフォーブスの「30 Under 30」リストにも選出されました。

コンファレンスについて

QCon AI は、これらのワークロードを安全にスケールさせるために必要なエンジニアリング分野に特化した、実践者主導のイベントです。本番環境で同業他社が採用しているアーキテクチャのプレイブックや障害指標への直接アクセスを提供します。

INFOQ EVENTS

2026 年 9 月 17 日（午後 1 時 EDT）

PR の向こう側：エージェント型ソフトウェアデリバリーの新たなコントロールプレーン

登壇：モヒット・スーマン氏（Harness スタッフプロダクトマネージャー）

2026 年 10 月 8 日（午後 12 時 EDT）

AI が開発を加速させる時代、CI パイプラインは追いつけるか？

登壇：エリック・メタジ氏（Datadog ソフトウェアデリバリープロダクトマーケティングマネージャー）、ロヒン・チャンドラ氏（Datadog CI/CD 最適化プロダクトマネージャー）

トランスクリプト

周宇氏： 今日は、シミュレーション駆動型 AI エージェントのテストと改善についてお話しします。少し背景を説明しましょう。私は Arklex AI の共同創設者であり、コロンビア大学の教授でもあります。AI 分野には長く携わっており、教授としてのキャリアは9年になります。オープンソースモデルを用いた事前学習や事後学習などにも取り組んできました。

私が特に重視しているのは、これらのモデルが実際にどのようにして本番環境に導入されるか、そして人々の生活を変えるような実務でその能力をどう活用できるかという点です。最近のレビューなどで見られるように、現在、エージェントの約95% はデモ段階で止まったままです。確かに遊び心があり、見ていて面白い素晴らしいデモですが、実際の価値を生み出し、長年経験してきたプロセスの中で真の変化をもたらすには至っていません。

今日は、私の研究室やスタートアップで取り組んできたいくつかのアプリケーションについてお話しします。私のスタートアップは、特にシミュレーションに関する研究室の研究をスピンオフしたものです。

会話型/チャットベースのエージェント

AI エージェントには多様な種類が存在します。本稿ではまず、一般的に「対話型エージェント」や「チャットベースのエージェント」と呼ばれるタイプについて解説します。

これは単に入力をテキストとして受け取り、出力もテキストとするだけではありません。実際には、アクションの実行やツールの活用も含まれます。こうしたエージェントは、エンドユーザーとの間で複数回にわたる対話が行われる点に大きな関心が寄せられています。

ここでは、その中でも特に「消費者向けエージェント」の一種であるショッピングエージェントについて取り上げます。この種のエージェントはすでに実用化されており、例えば Walmart では 1 年以上運用されています。Walmart のアプリを開くと、黄色いドットで描かれた笑顔のようなアイコンが表示されますが、これは「Sparky」と呼ばれています。Amazon も同様の機能を持つ「Rufus」を提供しており、これらのショッピングエージェントはあらゆる EC プラットフォームで高い人気を博しています。

ここでは、Sparky を基盤に構築されたアプリケーションの一つを実演します。製品ページを見ると、その製品に関する事前生成された質問と回答のペアが表示されますが、これらは必ずしもユーザーが知りたい内容とは限りません。

実際には、非常に具体的な自然言語で質問することができます。例えば、「掃除機のサイズはどれくらいですか？」といった製品の特定の側面について尋ねることも可能です。これが一般的な Q&A（クエスチョン・アンド・アンサー）の形です。

最近では、製品レビューカードを統合してスクロール表示できるようにするなど、ツールとの連携も強化されています。さらに「文脈理解」機能も備わっており、別の質問をしても、「掃除機」という文脈内での質問であると認識します。在庫管理システムとも接続可能で、推奨商品の提示なども行えます。

製品カードへの視覚化も可能です。このカードをクリックすれば、より多くの操作が行えます。ユーザーはこれらのエージェントとさまざまなプロセスを通じて対話でき、能動的な質問をしたり、エージェントからの提案に対して応答したりできます。

現在、エージェントはかつての単純なチャットボットとは一線を画しています。異なるツールやユーザーデータとの連携により、物理的な店舗で販売担当者が顧客と接する際のような、より豊かで自然な体験を提供できるようになっています。これはその一例に過ぎません。

Demo - Voice Agent

また、現在「ボイスエージェント」と呼ばれる存在が多数登場していることも確認できます。

顧客: こんにちは。クレジットカードに興味があります。私のライフスタイルに合ったものを探しています。

エージェント: もちろんです、喜んでお手伝いします。普段どのような支出をされているか、あるいはご希望の機能はありますか？

顧客: 外食やフードデリバリーをよく利用します。特に Uber Eats です。オンラインショッピングも頻繁で、Amazon をよく使います。旅行の予約も Occasionally 行います。ポイント還元が柔軟に使えるものが理想です。

エージェント: ご共有いただきありがとうございます。そのお話を伺うと、「Emerald Preferred Card」をお勧めいたします。お客様の利用習慣にぴったり合っています。Uber Eats と DoorDash では3倍のポイント、iChase Travel を通じた旅行予約では5倍ポイントが貯まります。年間$50 のホテルクレジットや、DashPass の無料1年特典も付いています。さらに、旅行利用時に最大$750 相当の60,000 ポイント Welcome Bonus もご用意しています。

顧客: いいですね。Welcome Points はどのように還元できるのでしょうか？

エージェント: ポイントは非常に柔軟に活用できます。旅行、キャッシュバック、請求書クレジット、Amazon での購入などにご利用可能です。お申し込みを進めましょうか？

顧客: はい、お願いします。手続きもサポートいただけますか？

エージェント: もちろんです。今すぐSMS で安全なリンクを送信しました。手順に従って進めてください。何かご不明点があれば、いつでもお手伝いいたします。

顧客: 素晴らしいです。ありがとうございます。

エージェント: よかったら、3〜7営業日以内に結果をお知らせします。新しいカードをぜひお楽しみください。

Zhou Yu: これが最初の対話です。次に、2回目の対話を確認しましょう。

エージェント： 緊急のご連絡です。お客様の「Emerald Preferred Card」が承認されました。おめでとうございます。

顧客： ありがとうございます。先ほどいくつかのメリットについてお話しいたしましたが、旅行報酬の詳細を忘れてしまいました。もう一度教えていただけますか？

エージェント： もちろんです。iChase Travel を通じて予約された旅行には5倍のポイントが付与されます。さらに、毎年50ドルのホテル利用クレジットも付与されます。

顧客： 分かりました。年会費はいくらでしたっけ？

エージェント： 95ドルです。ただし、750ドル相当のウェルカムボーナスで年会費を簡単に回収できます。報酬は柔軟に利用可能です。現金、ギフトカード、Amazon、または旅行への交換などにご利用いただけます。

顧客： すばらしいですね。では、今すぐカードを発行できますか？

エージェント： 問題ありません。セキュリティ保護された発行リンクをSMSで送信しました。何かご不明な点がございましたら、いつでもお知らせください。

顧客： はい、分かりました。発行が完了しました。

エージェント： よかったです。報酬や DashPass についてご質問がある場合は、いつでもテキストメッセージまたはお電話ください。特典をお楽しみください。

顧客： ありがとうございます、Jordan さん。

エージェント： どういたしまして。素晴らしい一日をお過ごしください。

周宇： これは実際にはデモであり、まだ本番環境では稼働していません。最大の理由の一つは、このデモが非常に高度なものである点にあります。音声とテキストの両方の対話が可能ですが、金融のような規制が厳しい分野では、こうした先進技術を導入するのは極めて困難です。特に個人データや推薦機能、データベースへの書き込みを伴うアクションが含まれる場合、その難易度はさらに高まります。

例えば、規制によりクレジットカード発行には本人によるリンククリックでの明確な承認が必要とされています。金融業界や多くの他の産業において、消費者向けサービスは完璧ではありません。依然として、クレジットカード発行を促すハガキが大量に送られ、紙の無駄が発生しています。しかし、こうした情報フローを活用すれば、実務書類のやり取りではなく、多くのプロセスを自動化できるはずです。

では、なぜこれらのシステムはまだ本番導入されていないのでしょうか？一部はリスクが比較的低いECサイトなどで既に導入されていますが、金融や医療といった分野では状況はさらに複雑化しています。最大のボトルネックはコンプライアンス（法令遵守）の側面にあります。

コンプライアンスに合格するためには、まず「評価をどう行うか」「モデルチェックはどのように実施するか」という質問が投げかけられます。従来の機械学習の文脈では、私たちは長年にわたりこの課題に取り組んできました。具体的には、ベンチマークを作成するのが一般的です。

例えば、クエリと回答のペアを用いたベンチマークでは、単発の評価（single-turn evaluation）が行われます。ユーザーからの単一の問い合わせ（例：「現在の残高はいくらですか？」）に対して、標準化された回答が用意されます。この場合、回答は SQL クエリのような単純な形式で定義されることが多いです。

こうしたクエリと回答のペアを多数集めて静的なベンチマークを作成し、その上でモデルを実行します。「95%」「99%」といった数値が得られれば、それをコンプライアンスチームに報告できます。また、入力データ、モデルの出力結果、そして正解（ground truth）となる参照回答を含むデータセットも提供可能です。これにより、評価プロセスを透明化し、検証が可能になります。

通常、モデル検証チームはこのような手順で作業を進めます。その後、コンプライアンスの確認が行われるのが一般的です。

しかし現在、AI エージェントは多段階の対話（マルチターン）を行うため、ユーザーが前の質問に関連する新たな問いを投げかけるケースが増えています。この「文脈参照」の問題を解決するのは非常に難しく、エージェントが従来の回答と異なる内容を述べた場合、ユーザーがどう反応するかを予測することも困難です。

こうした状況から、単発の対話（シングルターン）を対象とした評価手法はもはや通用しません。静的なベンチマークを用いた評価も限界を迎えています。

さらに深刻なのは、ツール呼び出しの結果が常に変動する点です。例えば、口座残高は1分ごとに異なる可能性があります。常に一定の値を示す「正解（ゴールデン・トゥルース）」を想定した静的な数値では対応できません。

また、エージェントが実際に所定のアクションを実行しているかどうかも確認する必要があります。例えば、商品返品処理が行われたかどうかを検証し、本当に返品が完了したのかを確認することが求められます。

製品が返品されたというエージェントの発言だけを頼りにしてはいけません。背後にあるデータベースや環境も確認し、アクションが正しく実行されたか、あるいはユーザーの意図が本当に満たされたかを検証する必要があります。これにより、多ターン型や多ステップ型のエージェントの評価は、以前よりもはるかに困難になっています。

では現在、これらのシステムをどのように評価しているのでしょうか。一般的な手法としては、チャットシステムにフックを仕掛けます。例えばショッピング用エージェントのようなチャットエージェントを構築したら、シンプルな Web サービスとして公開し、友人や同僚、プロダクトマネージャーなどにテストを依頼します。「このエージェントを作りましたので、ぜひテストしてください」と声をかけるのです。

彼らはエージェントとチャットを行い、発見したすべてのエラーを報告してきます。

報告されたエラーが見つかったら、それらをどうクラスタリングし、どのエラーが共通の根本原因を持つのかを特定して注釈をつける必要があります。その結果に基づいて修正を行い、再度デプロイします。

しかし、エージェントが変更されるため、以前収集した評価データはもう使えません。新しいデータが必要になります。そこで私は再び友人たちに協力を依頼し、「もう一度テストしてくれませんか」と頼みます。このプロセスは非常に手作業が多く、人々があなたのエージェントをテストするために費やす時間は膨大なものです。

さらに悪いことに、これらのテスト担当者は実際のユーザーではありません。彼らはアイデアを検証しているだけで、あたかもユーザーであるかのように振る舞っているに過ぎません。そのため、彼らのユーザー意図は現実的ではありません。もし技術者ばかりの友人がテストを行う場合、彼らは技術者が考えるような事柄しか検証しません。

そのため、テストのカバレッジは往々にして不十分になります。多くの場合、「これだけ何回も手動テストを繰り返したのだから、デプロイしても大丈夫だろう」と思いますが、実際にデプロイしてみると、ユーザーは開発者の視点では想像もしなかったような別の話題や行動を示すことがわかります。

そこで問われるのは、より体系的で多段階（マルチターン）なテスト管理方法はないかということです。異なる思考を持つ人々、特にユーザーに近い発想を持つ人々が、ドメイン知識をテストプロセスに組み込むことで、より反復的な開発を実現できるような良い方法はないでしょうか。

ソリューション：合成ユーザー

私たちが研究室で取り組んでいることの核心は、この「魔法」を別の「魔法」で打ち破れるかという点です。具体的には、AI エージェントを活用してユーザーのシミュレーションを構築し、これらのエージェントを自動的に実行可能にするかどうかです。

例えば、エージェント A をユーザー A に、エージェント B をユーザー B、そしてエージェント C をユーザー C として定義します。こうすることで、多様なユーザー間の補間（インターポレーション）を作成でき、実際のユーザーケースにおける潜在的な分布を十分にカバーすることが可能になります。各ユーザーごとに管理を行い、それぞれを反復可能なイテレーションのための「ゴールドデータセット」として活用できます。

つまり、シミュレートされたユーザー（これもまた AI エージェントの一種です）と、ショッピングエージェントのような製品側のアージェントが相互に作用し合うことで、実際のプロダクション環境で見られるようなトランザジエクト（経路や軌跡）を生成できるのです。

これにより、エラーを早期に発見し、評価プロセスを迅速に開始できます。この手法の利点は、ユーザーエージェントをある程度制約できる点にあります。そうすれば、エージェントの異なる機能やコンポーネントをテスト対象として選定しやすくなります。結果的に、複数の種類のユーザーエージェントを同時に起動して、スケーラブルなテストを実施することが可能になります。必要な時にいつでも起動できます。

従来のように友人をグループモードに固定して「私のエージェントをテストしてほしい」と頼む必要はありません。比較的容易にデプロイでき、これは単なるエージェントエンドポイントです。この API を通じてシミュレートされたユーザーエンドポイントと対話するだけで済みます。これにより、シミュレーションデータの軌道（トラジェクトリ）を生成し、多くのテスト作業を自動化できます。最終的には、重要な手動テストのみを実行すればよいのです。

Solution: Arklex AI Simulator Demo

これらのツールの活用例をご紹介します。エンジニアがユーザーシミュレーションの自動化を行えるよう設計されたオープンソースのリポジトリ「ArkSim」があります。これを使えば、製品マネージャーに指摘される前にエラーを発見し、修正してより高品質なバージョンをリリースできます。以下にプロセスの様子を動画で示します。

直後に具体例を示します。まず、エージェントの機能リストと、ユーザー目標を生成するためにエージェントがアクセスできる知識を定義してください。これらを組み合わせることで、次のパートで会話シミュレーションに使用するシナリオが完成します。

例えば、GED 試験（米国高校卒業資格に相当するもの）用の Q&A エージェントをテストする場合、シミュレートするユーザーの学歴を「高校卒業未満」に設定できます。エージェントの機能は、「何ができるか」を記述して準備し、知識ファイルには企業概要、事業内容、および FAQ や Web サイトの内容などエージェントが参照できる情報を追加してください。

さらに、生成時の会話数や、各ペルソナあたりの会話数といった設定も可能です。これらのシナリオを用意した後、CI パイプラインの残りの 2 つのパートを実行すれば、エージェントのシミュレーションと評価を開始できます。

これにより、テスト対象のシナリオを固定して制御することが可能になります。以下に、私のエージェントのコードベースを示します。

私は現在、エージェントにいくつかの変更を加え、プッシュする準備ができています。変更をプッシュすると、CI パイプラインが新しいコードでエージェントのビルドを開始し、新しいエージェントを搭載したシミュレータのビルドもトリガーされます。まず、このビルド内で新しいエージェントを起動します。その後、そのエージェントとの会話をシミュレーションする処理が始まります。

引数を通じて、設定ディレクトリや会話数、ターン数を上書きして、シミュレーションのカスタマイズが可能です。続いて、これらの模擬会話に対する評価が行われ、問題点の特定がなされます。

会話スコアに対して閾値を設定することで、ビルドの成否を判定できます。また、より詳細な評価レポートも提供しており、有用性（helpfulness）、一貫性（coherence）、冗長性（verbosity）、関連性（relevance）、忠実度（faithfulness）の 5 つの次元におけるスコアを確認することができます。

また、エージェントの動作におけるエラーもまとめました。これらは「明確化を求めなかった」「繰り返した」「ユーザーの要求に従わなかった」「誤った情報を提供した」「具体的な情報が不足していた」の 5 つのカテゴリに分類されます。以下に具体例を示します。このエラーは「明確化を求めなかった」カテゴリに該当します。ここではエラーの説明と、推奨される修正策を紹介しています。

会話詳細を開くと、より具体的なユーザーの目的や、その会話におけるエージェントの動作スコア、シミュレーションされたユーザープロファイル、そして目標達成スコアの根拠を確認できます。例えば、この会話ではエージェントがユーザーの問い合わせに正しく対応したため、目標達成スコアは 1 となっています。

さらに詳細な分析として、各ターンでのエージェントの動作エラーをハイライト表示しています。レポート下部までスクロールすると、すべてのシミュレーションされた会話と評価結果を一覧で確認できます。

Arklex エージェント準備ツールを CI パイプラインに統合することで、開発者は手動テストにかかる時間を大幅に削減でき、デプロイや本番環境への展開に向けたエージェントの readiness（準備度）を早期に把握できるようになります。

オープンソースを利用したい場合は、「Arklex AI ArkSimulation」と検索すれば、リポジトリが見つかります。

High-Level Architecture

ユーザーシミュレーションの入力をどう定義するかは、非常に重要なポイントです。これは設計するエージェントのプロセスに依存します。例えば、ショッピングエージェントを想定する場合、ユーザーの属性は人口統計学的な情報になります。予算意識が高いのか、それとも気にしないのかといった特徴が該当します。

これらのエントリーポイントは通常、プロダクトマネージャーや運用担当者が制御します。そして、この情報を基にユーザープロフィールを作成するのが一般的です。

次に重要なのが「ユーザーゴール」です。これはユーザーが達成したいこと、あるいは「ユーザー意図」とも呼ばれるものです。ユーザーの意図は、エージェントの能力によって形成されます。利用可能なツールや、エージェントが完遂できるサブゴールを組み合わせることで、多様なゴールを構築することが可能になります。

3 つ目のコンポーネントは「文脈情報」と呼んでいます。製品に関連するドキュメントや、ユーザーが達成したい目標に関する情報など、状況に応じて必要な情報がこれに該当します。

この 3 つのコンポーネントはそれぞれ独立した値として設定可能であり、組み合わせを切り替えることで多様なシナリオを網羅的にカバーできます。これらを組み合わせたものを「個別シナリオ」と呼びます。各個別シナリオは、1 つのユーザーシミュレーションに対応すると考えてください。

こうして構築されたシナリオ群を時系列で管理し、CI/CD パイプラインに連携させることができます。エージェントの更新が行われるたびに、事前に特定した重要なシナリオに基づいてシミュレーションを実行します。これは、実際のユーザーがどのように行動するかを模倣するプロセスです。

シミュレーションを実行すると、先ほどデモでお見せした通り、会話データが生成されます。

AI エージェントは、異なるツールを呼び出すことで、ユーザーが与えられたペルソナや過去の会話履歴（例：保有する連絡先情報など）に基づいて目標を達成します。これは、シミュレートされたユーザーと製品エージェントがリアルなユーザーテストのように相互作用している状態です。

私たちは、ユーザーに対してさまざまな API ツール呼び出しを提供しています。また、シミュレートされたユーザーは GUI 操作も実行できます。ウェブページの異なる箇所をクリックするなどして、エンドユーザーが実際にどのように行動するかを忠実に再現します。

例えば、前述の通り Walmart Sparky アプリでは複数の製品カードが表示されます。エンドユーザーがどの製品カードをクリックするかをシミュレーションすることで、カードを開いた際にエラーが発生していないかなどを確認できます。このように、AI エージェントを活用して、ほぼリアルなユーザー体験に近いテスト環境を構築することが可能です。

これらの会話を生成した後、最も重要なのは「会話内にどのようなエラーが含まれているかを見つけること」です。これを「評価（evaluation）」と呼びます。

一般的な評価では、「大規模言語モデルを審査員として使う（LLM as a judge）」手法が広く採用されています。これは、大規模言語モデルの内部能力を活用できる点で非常に有用です。しかし、最も重要なのは、評価が実際のタスクに根ざしている必要があるという点です。

単に「大規模言語モデルはあなたのアプリケーションやドキュメント、カスタマーサービスの知識をすべて知っている」と仮定してエラーを検出することはできません。シミュレーションベースの評価の利点は、シナリオが明確であることです。これにより、評価をより細かく（fine-grained）検証することが可能になります。

例えば、私のシミュレーションのゴールは「20 歳の女性がドレスを購入し、返品したい」という設定です。この場合、タスク完了の評価は、「実際に商品が返品されたか？」という点で自動的に検証できます。

「この対応は、特定のビジネス原則に則って行われたのか？」という問いには、自動ルールを用いて自動的に検証し、正しいプロセスを経て最終目標が達成されたかどうかを確認できます。ただし、タスクの完了だけをゴールにするわけではありません。エージェントが本当に期待した通りの行動を取っているかを判断するために、ターンごとの評価指標を複数設計することも可能です。

例えば、「有用性」のような指標は、一部のケースで有効です。「エラーを起こさないこと」よりも「より有益な回答を提供すること」を重視したい場合などです。この有用性を踏まえて、文脈や具体例を豊富に含んだ LLM-as-judge（LLM による評価者）を特別に設計できます。

また、「ブランドボイスの遵守」といった指標も設定可能です。ブランドボイスは企業によって大きく異なりますが、通常は自然言語でその特徴を記述します。課題となるのは、大規模言語モデルが理解できるよう、明確な「良い例（ポジティブ）」と「悪い例（ネガティブ）」を用意して、学習のきっかけを与える必要がある点です。

通常、エージェント構築時にデータが不足している場合、こうした事例を見つけるのは非常に困難です。シミュレーションを活用すれば、会話のやり取りを再現でき、専門家に生成された会話を検証してもらい、「これは実際には難しいネガティブ事例だ」と判断させ、LLM-as-judge（LLM を評価者とする手法）の評価プロセスに組み込むことができます。シミュレーションは、私たちが一般的に「合成データ」と呼ぶものを大量に提供し、より実証的なアプローチで評価基盤を構築するのを支援します。また、最終的に実際のユーザーがどのように相互作用するか、本番環境への展開前にどのような会話が行われるべきかといった洞察も得られます。

エージェントの課題を特定する

ショッピングエージェントの一例をご紹介します。例えば、このユーザーシミュレーター（合成ユーザー）は「注文状況を確認したい」と発言します。

ユーザーをシミュレートする際、通常はユーザープロファイルを与えます。EC サイトでは、エージェントのツール適用能力を検証するために、多様な種類のユーザープロファイルを準備するのが一般的です。

例えば、現在のこの特定のユーザーにはプロファイルに2件の注文が登録されています。そのため、エージェントは「最近の注文が2件ありますね。注文1299号は配送完了済みで、現在も在庫に含まれています。注文1300号はまだ配送処理待ちです。どちらの注文を確認されますか？」と返答し、確認を促します。

これはより複雑な状況の一例であり、テスト実施時にこうしたシナリオが適切に機能していることを確実にする必要があります。その後、合成ユーザーは自身の目標とプロファイルに基づき、「注文1300号はいつ出荷されますか？」と質問します。

エージェントは、あなたが行うすべての操作を再現し、「注文 1300 はまだ発送待ちです」と伝えるでしょう。これは、商品がまだ出荷されていないことを意味します。

この時点で、合成ユーザーとして、私たちがこれまで収集した多くのデータや提示されるシナリオに基づき、どのような行動をとるでしょうか？ここでは「シアトルへの到着予定日はいつですか？」と問いかけます。エージェントはもう一度試み、より詳細な情報や自身のプロファイルを提供して情報を引き出そうとします。

しかし、テスト中のエージェントからは、「申し訳ありませんが、該当する注文の詳細を持っていません」という回答が返ってきます。推定日をお伝えできない状況です。

この文脈とユーザーのプロファイルを踏まえた合成ユーザーは、次に「カスタマーサービスのメールアドレスを教えてください」と尋ねるでしょう。

これは、現実的なユーザーが通常どのように発言するかを示した例です。実際には、異なる感情タイプを持つ複数のユーザーをシミュレーションすることも行います。

エージェントは「申し訳ありませんが、〜についてはお答えできません」といった応答を行います。このように複雑な状況において、エージェントのエラーを検出します。その上で目標に基づき、「ユーザーの要望が満たされなかった」ことを把握し、ユーザーの反応から、エージェントが直面した潜在的な課題を特定できます。

例えば、ここでは「配送情報のアクセスに失敗している」というエラーが見られます。これは、配送情報へのアクセス機能に問題が生じている可能性を示唆しています。また、「カスタマーサービスのメールアドレスが見つからない」といったケースも考えられます。これらは、RAG パイプラインやベクトルデータベース内の情報不足が原因である場合や、カスタマーサービスに関する複数の情報が混在してエージェントを混乱させた結果かもしれません。

テスト、つまり評価を行う目的は、単に評価をするためだけではありません。問題を見つけ出し、次のラウンドでエージェントをどのように改善すべきかを明らかにするために行うものです。

模擬インタラクションの品質を評価する

ここで、次の話題に移る前に、どう改善すべきかについてお話ししましょう。ユーザーシミュレーション自体の評価方法についても触れたいと思います。

先ほど、ユーザーシミュレーションがどのように動作するかを示しました。もちろん、このシミュレーションを数値化し、具体的な指標で評価したいと考えています。では、優れたユーザーシミュレーションはどのような基準を満たすべきでしょうか？

AI エージェントを開発する際、最適化の目的はタスク完了率の向上です。つまり、エージェントの生産性を高め、より正確にタスクを完遂させることです。

しかし、ユーザーシミュレーション（ユーザーエージェント）の最適化はこれとは異なります。ここでは「カバレッジ」の拡大が重要になります。具体的には、多様なツール呼び出しや実行経路を網羅できる能力です。つまり、エージェントが持つ多様な動作パターンを幅広くカバーできることが求められます。

これは「ツール呼び出し分布エントロピー」と呼ばれる指標です。また、エージェントが一つのツール呼び出しから別のツール呼び出しへどのように遷移するかを確認したく、「ツール呼び出し遷移エントロピー」も最大化したいと考えています。

もちろん、最終的には「軌道距離（trajectory distance）」も重要です。すべての潜在的な実行経路が互いに近くなりすぎないよう、十分に離れていることを保証する必要があります。例えば、商品を返品する際、常に同じ手順を踏むだけでは不十分です。すぐに返品処理が行われるような単調なシナリオでは、テストのカバレッジが不足してしまいます。

異なるユーザーが、異なるタイミングでさまざまな商品を購入し、一部は返品され、一部は返品されないといった多様なシナリオをシミュレーションする必要があります。このような複雑さと網羅性を確保することで、より包括的なシミュレーション環境を実現できます。

もちろん、2 番目の部分であり最も重要なのが「リアリズム」です。単にエージェントエラーを誘発するために敵対的な行動を取るユーザーエージェントを作成するだけでは不十分です。重要なのは、それらが攻撃者としてエージェントを騙して悪行を行わせるだけでなく、同時に実際のユーザーの振る舞いも再現することです。

つまり、ターゲットは「悪いことをさせようとするハッカー」だけではありません。「実際に問題を抱え、現実のユーザーと同じように行動する人々」である必要があります。これを実現するために、さまざまな最適化手法を利用できます。例えば、収集したシナリオ内の実データに近い分布を維持しつつ、プロファイルや目標に合致する報酬関数を設計する方法があります。

そして 3 つ目のポイントは、こうしたシミュレーションベースのテストを常時実行してもコストが高くなりすぎないようにすることです。

例えば、毎回 10,000 件の会話をシミュレーションすると、CI/CD パイプラインを回すたびに数千ドルのコストがかかり、これは理想的ではありません。そこで私たちが目指したのは、最小限のシナリオで最大の網羅性を確保することです。これにより、より効率的に実行でき、負担となるコストを大幅に削減できます。

そして最後に、最も重要な下流の評価指標として注目しているのが「エージェントの失敗特定」です。これは要するに、特定の製品エージェントにおいてどれほどのエラーを検出できるかという問いです。例えば、Walmart Sparky エージェントのような製品エージェントをブラックボックスとして扱い、異なるバージョンのユーザーエージェントを試してみます。

私たちは、さまざまな失敗を引き起こすような十分な網羅性を持つシミュレーションを実現し、実際のユーザーが遭遇する前にこれらのエラーを見つけ出すことを目指しています。結局のところ、これこそが NVIDIA が評価する他の 3 つの指標よりも最も重要な評価基準なのです。

エージェントのパフォーマンス評価（LLM-as-judges：シナリオ継続）

最後に、ユーザーシミュレーターがあらゆる指標で高いスコアを出していることを確認できたら、次は製品エージェントの評価指標をどう設定するかを検討します。前述した通り、カスタマーサービスの場合などは、自社の製品目標に即した評価基準を定義することが重要です。

「顧客ニーズの完了」は、通常 0 から 1 の値で表され、正規化して比較可能です。また、「効率性」も無視できません。顧客の時間を無駄にしてはいけません。

さらに、特定のインタラクションにおいては、Go-to-market エージェントとしての役割が問われることもあります。例えば、「当社のメルマガリストに登録してください」といった行動を促す場合、エージェントがユーザーに何を働きかけようとしているかという「呼びかけ（Call to Action）」の達成度も重要な評価項目となります。

ユースケースに応じて、エージェントの最終的な評価指標は異なります。シミュレーション結果から自動的にこれらの指標を導き出し、追加の設計コストを削減することも可能です。

最後に、これらのシミュレーションを経てエージェントを本番環境にデプロイすると、大量の生産ログが生成されます。シミュレーションは決して完璧ではありません。例えば自動運転車において、毎日新たなコーナーケースが見つかるように、本番環境のエージェントでも同様のことが起こります。道路に新しい障害物が現れるからです。

実際のデプロイにおいても、ユーザー分布は常に変化し続けます。EC 販売エージェントの例を挙げれば、新しい祝日キャンペーンやプロモーションに関する新方針が導入されるたびに、ユーザーの行動パターンも以前とは異なるものになります。したがって、シミュレーションを時間とともに更新し、現実のユーザー分布に近づけていくことが極めて重要です。

私たちが行っているのは、本番ログを取得し、既存のシミュレーション会話と比較して、両者の分布における差異を要約することです。これにより、見落としがちだった部分をカバーする追加的なシナリオを作成することが可能になります。

ユーザーの属性、ゴール、文脈などこれまでカバーしきれなかった項目を拡張することで、CI/CD パイプラインにおける「ゴールデンシナリオ」を進化させることが可能です。これにより、エージェントが常に最新の状態に保たれるよう継続的に改善できます。

例えば、一般消費者向けエージェントに取り組んだ経験がある方ならお分かりいただけるでしょう。変化する唯一の要素はユーザー自身です。運用チームにとって、エージェントの維持管理は多大な労力を要します。そのため、ユーザーシミュレーションを最適化し、その成果をエンジニアリングパイプライン全体に反映させる仕組みを持つことが、デプロイ後のエージェント保守コストを長期的に削減する最も効果的な手段となります。

企業向けで実証済みの ROI

私たちはさまざまな企業と協力してきました。その一例が、教育業界最大手のピアソン社です。

ピアソン社は、学生がカスタマーサービスや教育相談をタイムリーに受けられるよう、特に力を入れています。しかし課題は、生徒が多様な言語を話す点にあります。同社は 200 カ国以上で事業を展開しており、国ごとに異なるテストポリシーや購入ポリシーが存在します。

各サブモジュールに対して厳格なテストを行わずにリリースすることはできません。これが彼らの最大の課題の一つです。そこで私たちは、本番環境への展開前に、より厳密な検証が行えるようシミュレーションを提供しました。

過去 2 年間、同社と協力する中で、エージェントは初期データ分析に基づき、自動化されたシミュレーション最適化のループを通じて、継続的に改善されています。

私たちが特に重視しているもう一つの点は、継続学習の実現です。どのようにすれば、このプロセスを人間の介入に頼らない自動化された「フライングホイール（回転する車輪）」として機能させられるでしょうか？

従来の手法では、本番環境のログからデータを分析し、手動でバグを見つけ、深刻度の高い順に優先順位をつけて、いつどの工程で修正するかをエンジニアリングパイプラインとして設計する必要がありました。私たちは、この属人的な作業フローを脱却することを目指しています。

AI エージェントを設計する際、しばしば共通する構成要素がいくつか見られます。例えば、エージェントのフローや、各段階で利用可能なツールの選定などが挙げられます。また、プロンプトも重要な要素です。これらは、AI を活用して最適化できる主要なポイントです。

具体例を見てみましょう。まずは改善前のケースです。これはカスタマーサポート用のエージェントですが、こうしたエージェントの構築にあまり慣れていない場合、提供されるフローは非常に単純なものになりがちです。例えば、「ユーザー詳細を取得する」というツール呼び出しが必要になった際、意図（インテント）が「注文を返却する」であると判断されます。ユーザーが「注文を返品したい」と発言すると、システムはその意図を検知し、「注文を返却する」というツール呼び出しを実行します。

実際には、返却可能な注文が存在しないことが判明し、「申し訳ありませんが、返却対象となるものはありません」という応答になります。その結果、ユーザーは混乱し、会話自体が失敗に終わってしまいます。

この事態の根本原因は、商品がまだ出荷されていないことにあります。未着品の状態では「キャンセル」は可能ですが、「返品」は実行できません。しかし、ユーザー自身はその事情を正確には把握していません。「注文が届いていないので返したい」という表現をするのは、彼らが通常そう伝えるからに過ぎません。

このような特定のコーナーケース（例外状況）は、常にシステムから漏れ出します。実際に発見される事象の中で最適化すべき真のポイントは、ユーザーが「注文を返品したい」と発言した際、内部でそのリクエストがエラーとして処理されないよう、自動的に「キャンセル」プロセスへフォールバックさせる仕組みを導入することです。これにより、購入済みだが未出荷の商品に対する適切な対応が可能になります。

そうして、自然な結論に至るはずです。フローは左側の例のように硬直的であってはなりません。右側のように拡張可能なものであるべきです。

こうしたエッジケースをテストできることが、最適化の第一歩となります。現在、ユーザーシミュレーションを用いてこれらのエッジケースを見つけ出し、エラーを引き起こさせることで、プロンプトやユーザーフローの改善点を提案する仕組みが考えられます。もちろん、学習によって改善することも可能です。ユーザーシミュレーションで生成した合成データに基づき、より小さなモデルをファインチューニングすることで、成功事例に焦点を当てつつ失敗事例にはペナルティを与えることができます。これにより、エンドユーザー向けの顧客対応エージェントにおいて大量のトラフィックを処理する際にも、効率的で軽量なモデルを提供できるようになります。

ワークフローエージェントにもシミュレーションは必要か？

これまで、私たちは主に双方向の対話を行う顧客サービスエージェントについて議論してきました。しかし、自然言語での入出力を必ずしも必要としない「ワークフロー型エージェント」も存在します。

例えば、住宅ローンの審査（mortgage underwriting）がその典型です。住宅ローンを申請した経験がある方ならご存知の通り、多くの書類の提出が必要となります。同時に、審査担当者が処理を進められるよう、各種フォームへの記入も求められます。

審査担当者の主な目的は、これらの書類間に矛盾がないかを確認することです。提出される資料は多岐にわたり、PDF 形式のものや、原本を紛失したために画像として提出されたものもあります。また、すでに記入済みのフォームや、信用履歴などから抽出された非構造化テキストも含まれます。

このように、入力データには多種多様なモダリティ（形式）が混在しており、これが大きな課題となっています。

私たちは、成果物を得るための正式なワークフローを構築しようとしています。具体的には、「この人物にリスクがある場合、そのリスクを解消するために追加情報の提供が必要か」を判断するプロセスです。

これまでこうした不整合の発見は、主に人的な手作業によって行われてきました。しかし、これは多様なモダリティを通じて長大な文書を読み込む AI にとって大きな機会となります。

最大の課題の一つは、これらのエージェントを訓練するためのデータが不足している点です。なぜなら、対象となるデータはすべて個人情報であり、PII（個人識別情報）の制限に縛られているからです。たとい社内の生産チームであっても、共有することはできません。これが大きな問題となり、ボトルネックを生んでいます。

このため、シミュレーションは単なるテストのためだけでなく、訓練目的にも活用できます。例えば、ある一人のユーザーを起点として、その人物自身と整合性のある属性を手動で付与し、合成データを作成することが可能です。

例えば、ある個人の社会保険番号（SIN）や雇用主情報などに基づき、AI を活用して住宅ローン申請に必要な書類を人手で入力することも可能です。これにより、ユーザーの状況と整合性のある給与明細や銀行残高証明書などの合成データを生成できます。

さらに重要なのは、与信審査ルールにおける「隅っこのケース（コーナースケーズ）」を意図的に作り出すことです。与信審査の手引き書を読み込み、審査担当者の頭の中に想定されるあらゆる例外ケースを抽出します。これらの事例を用いて合成データを作成することで、潜在的なすべてのコーナーケースを網羅したカバレッジを実現できます。

例えば、T4 用紙（給与所得者源泉徴収票）のような書類も作成可能です。また、現実的な行動に似た障害や不具合も生成できます。具体的には、書類のページが欠落しているように誤って結合したり、書類が傾いたり歪んだり、ぼやけたり、照明が悪い状態にしたりといったバリエーションを生成できます。これこそが AI の得意とするところです。

これらのパイプラインを活用すれば、合成ユーザーのカバレッジを多様な形で生成可能です。重要なのは、ユーザーの発言内容だけでなく、メタデータや書類情報など全体像を含めることです。こうして、現実のユーザーに代わる完璧なデジタルツインを作成できます。これらは実在するユーザーではなく、異なる借入者のあらゆるコーナーケースを網羅しようとする合成ユーザーです。

このようにして、与信審査プロセスの自動化を実現することが可能になります。

自己学習型エージェント

今日お話しするのは、現在進行形で進んでいる「ユーザーシミュレーション」や「ツールシミュレーション」の活用についてです。これらは単なるテストのためだけでなく、システムの改善にも不可欠な役割を果たします。

まず重要なのは、実際のユーザーがどのように行動するかを理解することです。本番環境への展開前には、その振る舞いを正確に把握することはできません。そこで、シミュレーションを代理として用いることで、より高度な施策を実行する前に改善を行うことが可能になります。

その後、本番環境で実際にユーザーが行ったアクションに基づいて、さらに反復改良を重ねることができます。具体的には、メモリの構造やツールの構成、プロンプトの設計などを最適化し、エージェントの品質を向上させるのです。このようにして、自動化または半自動化的なアプローチを通じて、多角的にエージェントのパフォーマンスを引き上げることが実現できます。

質疑応答

参加者1: エージェントシミュレーションの限界について伺いたいです。例えば、通話すべきではない幼児が電話をかけて拒絶される様子や、認知症の高齢者が同じ内容を繰り返し忘れるような状況を、正確にシミュレートすることは可能でしょうか？

周宇氏：既存のデータを活用してシミュレーションを行う際、実際のオペレーターが持つ事前知識やドメイン知識を付与することで、さまざまなユーザープロファイルや意図、さらにコーナーケースを再現したシナリオを構築できます。最も重要なのは、このシミュレーションを実行し、実際の行動軌跡（トラジェクトリー）がどうなるかを確認することです。その後、専門家がそれらを検証し、「実際に同じ現象が起きているか」を確認します。例えばカスタマーサービス担当者であれば、その記録を読み込み、自然言語によるフィードバックを提供することで、シミュレーションをより完璧なものへと反復改善していくことができます。

参加者2氏：評価は、検証しやすい事象を中心に実施すべきです。例えば、「注文がキャンセルされたか、履行されたか」といった明確な指標についてどう扱うべきでしょうか？一方で、ユーザーに「製品を説明してほしい」「2つの製品を比較してほしい」など、定義が曖昧な目標に対してはどう対応すればよいのでしょうか？

Zhou Yu: ユーザーにとってゴールの達成が明確に定義されているシナリオもあれば、より曖昧なケースもあります。例えば、製品を返品する手続きは具体的な完了条件がありますが、特定の製品の推奨を求めるような場合は「ソフト」な目標となります。推薦結果は通常、ユーザーのプロファイルにも依存します。

同時に、ユーザー自身が過去の履歴にアクセスできる仕組みを提供しているため、モデルは過去の行動データに基づいて評価を行います。つまり、「このエージェントが推奨した製品に対して、ユーザーはどう反応するか？」をシミュレーションし、その反応に応じて「推薦を受け入れるか」「拒否するか」を判断します。もしユーザーが推薦を受け入れたなら、それはエージェントの性能が高いことを意味します。逆に推薦を拒否された場合は、エージェントの最適化余地があるということになります。

参加者 3: 異なる能力を持つモデルを訓練する際、特定の背景や文脈を持つ人物、あるいは持たない人物をシミュレーションする場合、新規にモデルを訓練するのか、既存のモデルの上にオーバーレイを適用するだけなのか。また、これらのモデルが単なる風刺的な caricature（誇張された描写）や、最も奇抜で特徴的な行動の一部だけを抽出した例ではなく、正確な表現になっていることをどう保証するのか。

Zhou Yu: シミュレーションは通常、2 つのシナリオに分類されます。1 つ目は「コールドスタート」で、データが全くない状態です。もう 1 つは「ウォームスタート」で、実際にタスクを処理した人間の生産現場から得られたデータが存在する状態です。

ウォームスタートの場合、リアルなユーザーの分布にあらゆる側面で合致するシミュレーションを実行することは明白です。しかし、最も難しいのは常にコールドスタートです。この場合、我々ができることは限られており、過去の実際の経験を持つ専門家のドメイン知識を引き出すことしかありません。

そこで専門家へのインタビューを実施し、シナリオがどのようなものになるのかを特定しようとします。これらのインタビューデータを基に初期のシミュレーションシナリオを作成します。その後、シミュレーションを実行し、専門家がフィードバックを与えて最善の形で反復改良を行います。そしてデプロイを行い、実際のデータを得た後にさらに精緻化を図ります。

詳細は transcript 付きのプレゼンテーションはこちら