※本記事は、YouTube動画「AAAI26-Trustworthy Agentic AI Workshop」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=Fsq6itq4GPk でご覧いただけます。本記事では、動画内で行われた6件の講演内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性、また自動書き起こしに基づく人名・所属等の表記に不正確な点が含まれる可能性がありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
本ワークショップは、AAAI 2026 Workshop on Trust and Control in Agentic AIとして開催されたものです。本ワークショップは、研究・産業・政策の各分野を代表する識者を招き、このアジェンダを形作ることを目的としています。エージェント型システムにおけるアライメント・頑健性・検証可能性の原理と実践を前進させる貢献を募っており、その対象はコアとなるアルゴリズムから、評価手法、制度的枠組み、ガバナンスにまで及びます。分野横断的な対話を促進し、新たな協働を生み出すことで、本ワークショップはエージェント型AIを責任ある形で、かつ大規模に展開していくための道筋を描き、その恩恵が広く公平に行き渡ることを目指しています。
以下、本記事で取り上げた6件の講演の登壇者をご紹介します。
講演①(性能予測に関するご講演) プロンプトプログラムの性能予測をベイズ的アプローチで数値化する研究についてご講演いただきました。登壇者のお名前は動画内では明示されておりません。
講演②(ヘルスケアと知識グラフに関するご講演) 大学に所属される教授の方にご登壇いただき、ヘルスケア領域における知識グラフを活用したエージェントの研究についてご紹介いただきました。登壇者のお名前は動画内では明示されておりません。
講演③(産業界の視点によるご講演) Tencent Security(テンセントセキュリティ)にご所属の方にご登壇いただき、産業界における信頼できるエージェントアーキテクチャの実践についてご紹介いただきました。動画内での登壇者のお名前は自動書き起こしの精度により明確でないため、正確な氏名については動画本編をご確認ください。
講演④(TrustRAGに関するご講演) ユニバーシティ・カレッジ・ロンドン(UCL)所属の博士課程1年生の方にご登壇いただき、RAGシステムの頑健性・信頼性を高める研究「TrustRAG」についてご紹介いただきました。動画内ではGuo氏として紹介されています。
講演⑤(FedAgentに関するご講演) フェデレーテッド・エージェント強化学習のフレームワーク「FedAgent」についてご紹介いただきました。登壇者のお名前は動画内では明示されておりません。
講演⑥(旅行計画エージェントに関するご講演) 南京大学のLangaグループにご所属の方にご登壇いただき、旅行計画ドメインにおける信頼できるエージェントの研究についてご紹介いただきました。動画内ではJin Sha氏として紹介されています。
正確な情報については、オリジナルの動画をご確認いただけますと幸いです。
1. コインを投げるように性能を測る ― プロンプトの信頼性をベイズで数値化する
1.1 プログラムは信じられるか、プロンプトは信じられるか
私たちがエージェントのようなシステムを構築する際、多くのタスクを委任してしまいたくなります。委任したほうが開発は圧倒的に楽になるからです。しかし、委任には大きな落とし穴があります。それは、実際に本番環境へデプロイする前に、そのシステムが安全に動作するかどうかを確認する良い手段がないという点です。これを考えるために、私は伝統的なプログラミングと、私たちが「プロンプティング」と呼ぶものを比較したいと思います。伝統的なプログラミングはテストによってかなり高い信頼性を持たせることができますが、その代わり非常に狭いタスクにしか対応できません。一方でプロンプティングは非常に汎用的で表現力に富んでいますが、一般に信頼性が低いという特徴があります。プロンプトがうまく動くデモを一度見せただけで、上司が「これは素晴らしい、すぐ本番に入れよう」と言ってしまい、その後すべてがおかしくなってしまう、というのはよくある話です。
そこで私が今日お話ししたいのは、「プログラムは信頼できるが、プロンプトはそこまで信頼できない」というこの直感を、どうすれば定量化し、数値に落とし込めるかということです。まず申し上げておきたいのは、プロンプトについて100%の信頼性を達成することは、いまだ未解決の問題であるということです。ある論文では、横軸にタスクの難易度を取り、難しいタスクを右側、簡単なタスクを左側に配置しています。強力なモデルとされるGPT-4であっても、難しいタスクではあまりうまくいかず、かといって簡単なタスクで100%の成功率になるわけでもありません。つまり、プロンプトをプログラムとして書くという行為には、本番環境で「60%の確率でしか動かない」としても、それが事前に正確にわかっているのであれば、必ずしも悪いことではないという性質があるのです。アプリケーションによっては100%の精度は不要な場合もあるからです。ただし重要なのは、デプロイする前にその数値をあらかじめ把握しておくことです。
これを形式的に述べると、「性能予測問題」と呼べるものになります。入力として、私たちが解こうとしているタスクのインスタンスをいくつか観測します。そして、プログラムFがあります。これは記号的プログラムであっても、プロンプトプログラムであっても構いません。私たちが知りたいのは、このプログラムを本番環境で将来のインスタンスに対して実行したときに、実際にどれくらいの性能が出るかという「グラウンドトゥルースの性能」です。たとえば、あるプログラムをデプロイして1000件のインスタンスに対して実行し、900件正解したとすれば、それは0.9の性能を持つということになります。私たちがやりたいのは、実際にデプロイするというリスクを冒すことなく、この0.9という数値を事前に予測することです。つまり、非常に少数の観測されたタスクインスタンスから学習して、そのプログラムの性能についての「信念」を与えたいのです。たとえば、「平均的にはおそらく70%くらいの性能だが、100%でもなければ0%でもないだろう」というような形です。プログラムといくつかの観測インスタンスを入力し、性能予測についての信念の分布を出力すること、そして実際にデプロイしたときにその予測がグラウンドトゥルースと一致しているかどうかを検証すること、これが私たちの目指すところです。
分布として考えることには多くの利点があります。分布の平均値を予測値として使うこともできますし、「この分布の質量のほとんどは0.4から0.8の間にある」というように信頼度を示すこともできます。さらに、「この信頼区間をもっと狭めて確信を高めたいなら、あといくつのインスタンスをテストすればよいか」という将来的な問いにも答えられます。これらはすべて、分布を持つことの良い性質です。
そこで、私たちは極めてシンプルなモデルを採用しました。関連文献を確認したところ、誰もまだこの発想を実践していないようでしたが、非常にシンプルな考え方です。それは、プログラムをコインとして扱うというものです。例が一つやってきてプログラムをそのインスタンスに対して実行するたびに、正解するか不正解になるかのどちらかになります。つまり、プログラムをコインだと考え、各インスタンスをそのコインの一回の試行として捉えるのです。私たちが推定したいのは、長期的に見たときにこのコインの表が出る確率、すなわちこのプログラムが多数の異なるインスタンスに対して実行されたときの平均的な性能です。Pythonコードを書いて5つのテストケースに対してチェックしたとき、「このPythonコインは素晴らしい、永遠にうまく動くだろう」と言えるのは、たとえば配列の長さ10までのソートを行うソートアルゴリズムを書いた場合、他のすべてのソート問題に対しても確率1で真になるだろうと確信できるからです。これがまさに、私たちが行おうとしている推定の本質です。性能予測を、単にコインの確率を推定する問題に還元しているのです。
タスクからインスタンスを取り出し、プログラムをそのインスタンスに対して実行することで観測を得ます。インスタンスには正解となるグラウンドトゥルースが存在します。たとえば数列をソートする場合、入力xに対する正解の配列yが存在するので、それを照合できます。このプログラムをこのインスタンスに対して実行することは、コインを一回投げることに相当します。私たちがこのフリップから推定したいのは、本番環境において、このタスクの分布からサンプリングされる多数のタスクに対してどのような結果になるかという、まさにグラウンドトゥルースの値です。プロンプトが60%の確率で動作するのであれば、コインを何度も投げているようなもので、成功した回数を数えれば、うまくいけばそれも60%に近づくはずです。この単純なモデルの下では、プログラムを1つの例に対してテストすることは、一種のベルヌーイ確率変数として捉えられ、プログラムの真の性能について何らかのグラウンドトゥルースが存在するという前提のもと、たとえば「0.8のコインだ」「1.0のコインだ」というものを推定しようとしていることになります。コインを5回投げて3回成功、2回失敗したとすると、このコインモデルにおいては、成功回数と失敗回数だけが必要な観測情報になります。この単純化されたモデルにおいては、成功と失敗の回数こそが、観測すべき唯一の重要な情報だからです。
こうした観測、つまり5つの例のうち3回成功し2回失敗したという結果から、実際の性能について何が言えるでしょうか。単純に考えれば、3回成功2回失敗なのだからおよそ60%だろう、と言うこともできます。しかし、その60%という数字がどれほど確からしいのか、それこそが私たちが答えたい問いです。実際に基本的な方程式を書き下してみると、コインを投げた観測、つまりテストケースの実行結果を条件とした、コインについての私の信念の事後分布は、二項分布に比例することがわかります。ただし唯一足りないのは事前分布(prior)です。
ここで重要なのは、正しい事前分布さえあれば、コインがどのように振る舞うかについて非常に良い推定を与えられるという点です。事前分布さえわかっていれば尤度はすでにわかっているので、あとはPythonプログラムに対する良い事前分布、そしてプロンプトプログラムに対する良い事前分布をどう得るか、という話になります。ここでまず、記号的プログラムとは何かを定義しておきます。簡単に言えば、Pythonのようなものだと考えていただいて構いません。より形式的な意味論で言えば、実行意味論を数ページのPDFに曖昧さなく書き下せるような、形式システムを持つプログラムのことです。一方、プロンプトプログラムとは、基本的にLLMに対して与えられるタスクであり、何らかのトークン列が返ってきて、それを答えとして使うものです。私たちが関心を持つプロンプトプログラムは、グラウンドトゥルースの答えが存在するタスクに限られます。つまり、きれいな絵を生成させたり創作的な文章を書かせたりすることではなく、「画像の中の時計は5時を指しているかどうか」というような、正解か不正解かがはっきりしているタスクを対象にしています。
ここで一つ興味深い問いが生じます。それは、LLMにコードを生成させる場合はどうなのか、という点です。プロンプト的な部分と記号的な部分の両方があるように思えるからです。この判断のポイントは、「将来の入力に対して何が委任されているか」を問うことにあります。コードを生成させて、それを本番環境で何千回も実行するような場合、そのコード自体は本番環境での汎化を担っているため、これは記号的プログラムとみなします。一方で、プロンプト自体が大量の数学の問題を本番環境で解くような場合には、汎化を担っているのはプロンプトそのものなので、これはプロンプトプログラムとみなします。つまり、何が委任されているかによって、記号的プログラムかプロンプトプログラムかが分類されるということです。
1.2 「白か黒」の記号プログラムと「グラデーション」のプロンプト
それでは、いよいよ本題である、事前分布をどう得るかという話に入ります。理想を言えば、これまでに書かれたすべてのプログラムを集めてきて、それぞれが本来解くべきタスクに対して実行し、実際の性能を記録すればよいでしょう。これを全部集めれば、それがPythonプログラムに対する事前分布になります。同様に、これまでに書かれたすべてのプロンプトを集めて、それぞれの本番環境における真の性能を取得すれば、それがプロンプトプログラムに対する事前分布になります。もちろん、すべてのPythonプログラムやすべてのプロンプトにアクセスすることは不可能です。そこで私たちが行ったのは、十分な規模のプログラム集合をプロキシとして用いるというシンプルなアプローチです。これは事前分布として完全に正確なものにはなりませんが、そこから得られる教訓は非常に価値があると考えています。
具体的には、Pythonのコード生成タスク、その一部は「帰納的プログラミング」と呼ばれる領域から、タスクの集合を選びました。これらのタスクには、プロンプトで解くことも記号的プログラムで解くこともどちらも十分に合理的であるという性質があり、かつ各タスクについて非常に多くのインスタンスにアクセスできるという性質もあります。インスタンスが多ければ、真の性能について正確な数値を得ることができます。もし3つしかインスタンスがなければ、性能は0か、3分の1か、3分の2かしか言えなくなってしまうからです。私たちはこうして600個のインスタンスを持つタスクなどを多数用意しました。たとえば正規表現のタスクであれば、正規表現を書いて解くこともできますし(これは記号的プログラムとしてカウントされます)、プロンプトで解くこともできます。私たちは、あるタスク仕様に対して記号的プログラムによる解法とプロンプトプログラムによる解法の両方を書き、それぞれについて非常に多くのインスタンスに対する性能を測定しました。あるプロンプトは80%の確率で動作する、ある記号的プログラムは100%の確率で動作する、というように、特定のタスクに対する特定の記号的プログラムとプロンプトプログラムそれぞれについての点推定を得て、こうした数値を多数集めて事前分布として並べました。横軸に性能、縦軸にその性能を持つプログラムの数を取ったグラフです。
ここが本日の話の核心となるスライドです。私たちが検討したタスクについて、記号的プログラムの性能事前分布と、プロンプトプログラムの性能事前分布を並べてみると、非常に興味深い性質が見えてきます。記号的プログラムは、完全に正しいか、バグを抱えているかのどちらかになるという性質を持っています。70%だけ正しくて30%間違っているということは記号的プログラムにはめったに起こらず、右側の「完全に正しい」か、あるいは完全にクラッシュしてしまうかのどちらかに偏っています。一方、プロンプトプログラムについては、より確率的なシステムに期待される通りの性質、つまり時には正しく時には間違うという性質を持っており、分布ははるかに広く分散しています。
この違いが性能予測にどのような影響を与えるかを見てみましょう。この事前分布があり、あるプログラムが3つのテストケースすべてに合格したという観測が得られたとします。すると尤度関数は中央のグラフのような形になります。事後更新、つまり事前分布に尤度更新を単純に掛け合わせると、事後分布は次のような形になります。記号的プログラムの場合、3つのテストケースに合格したという事後分布を見ると、それはほぼ永遠に正しく動作し続けるだろうという結果になります。なぜなら、この尤度によって、左側にある「間違っているプログラム」の可能性が排除されるからです。これはまさに、記号的プログラムが3つのテストケースに合格すれば、それが永遠に動作し続けるだろうと確信できるという私たちの直感を、定量的に裏付けるものです。しかし、私たちが収集した事前分布のもとでは、プロンプトプログラムについてはこれが成り立ちません。たとえ3つのテストケースに合格したとしても、それは中央にある「完璧ではないが運良く成功したプログラム」のいずれかである可能性があります。この事後分布は、プログラムが本当に100%の性能を持つかどうかを教えてはくれず、単に「100%である可能性のほうが高い」と示すだけで、依然としてコーナーケースが多数残っているのです。これは、少数のテストケースだけでプロンプトプログラムを評価しようとすると、いかに誤った確信を持ってしまうかを根本的に示しています。この傾向は事後分布のエントロピーを見ても同様で、例の数を増やしていったとき、プロンプトプログラムは分布を狭めて確信を得ることが非常に難しいのに対し、記号的プログラムはこの双峰的な分布のおかげでずっと容易に確信を得られることがわかります。
ここから得られる結論は、記号的プログラムとプロンプトプログラムの事前分布は大きく異なるということ、そして可能な限り記号的プログラムを使うべきだということです。記号的プログラムのほうがはるかに信頼性が高く予測可能だからです。とはいえ、プロンプトプログラムは非常に有用です。そうでなければ、そもそも私たちはプロンプトを書いていないでしょう。あらゆるタスクをこなせる単一のPythonプログラムは存在しませんが、将来的にはタスクを受け取って解決する単一のプロンプトが登場するかもしれません。そのくらいプロンプトは有用なのです。それでも、少数の例からプロンプトの性能を予測しようとすることは、依然として非常に良い問題だと考えています。
そこで私たちが提案する解決策についてお話しします。プロンプトプログラムの事前分布はエントロピーが高く、このままでは予測にあまり役立ちません。そこで私たちが目指したのは、この事前分布をよりシャープな分布に変えて、実際に良い予測ができるようにすることです。そのためにどうやってより良い事前分布を得るか。発想は非常にシンプルで、手元にあるタスクにより近い、より焦点を絞った事前分布を作れないか、というものです。私たちのアルゴリズムは極めて単純です。入力は先ほどと同じで、プロンプトプログラムと観測されたタスクです。行うことは、これらの観測されたタスクから、事前に収集しておいたコーパスを参照し、類似したタスクを検索することです。そして、それぞれの類似タスクとプロンプトプログラムについて、コーパスから類似のプロンプトプログラムを検索します。私たちの類似性の定義は興味深いもので、タスクについてはテキスト埋め込み空間上での類似性、つまりRAGで一般的に行われる手法を用いています。一方でプロンプトプログラム同士の類似性の定義はより特徴的で、二つのプロンプトプログラムが「類似している」とは、検索されたタスクの部分集合のうち似た割合を解けるかどうかという、純粋に性能に基づく類似性です。つまり、GPT-5であろうがGPT-4であろうが関係なく、検索されたタスクのうち相対的に同じような割合を解けるのであれば、プロンプトプログラムとして見た場合にこの二つは非常によく似ていると考えるのです。
これを1つの例に適用した結果をお見せします。緑の棒がグラウンドトゥルースの性能で、私たちのアプローチによる事後分布が青い線、その平均を取った推定値が赤い線です。緑の棒に対して、私たちの推定がより近いことがわかります。一方、事前分布を用いない、いわば無情報な事前分布に基づくベータ分布を使った場合には、グラウンドトゥルースから大きく外れてしまいます。また、非常に良いベイズ的性質として、例の数が32個程度になってくると事前分布の効果が徐々に薄れていき、純粋に尤度に基づく事後分布に近づいていくことも確認できました。この結果、事前分布を用いないベースラインのアプローチと私たちのアプローチが、その領域で一致していく様子も見られます。さらに大きなコーパスに対する汎化性能についても検証しました。平均性能をグラウンドトゥルースに対して予測させたところ、私たちのアプローチのほうが誤差が小さく、また「グラウンドトゥルースの性能が私たちの確率分布のもとでどれだけ確からしいか」という指標においても、より高い値が得られました。
このアルゴリズムの非常に興味深い性質として、もしコーパスの中にきわめて似通ったタスクが存在する場合、そうしたタスクや類似のプロンプトプログラムを検索することで一種の「カンニング」を学習してしまい、非常に良い性能を示せてしまうという点があります。これは以前に見たことがあるからにすぎません。私たちが期待しているのはまさにこの性質で、コーパスが大きくなればなるほど、類似の状況を検索できるようになり、こうした予測がうまくいくようになるということです。これはネアレストネイバーのような、非常に可愛らしいノンパラメトリックモデルだと言えます。逆に、このアルゴリズムがうまく機能しないのは、プログラムが記号的プログラムのように振る舞い始めるときです。強力なLLMモデルの場合、ほぼ常に正解してしまうため、コイン投げとして扱うこのアルゴリズムはあまり効果を発揮しません。これは今後も継続的に取り組むべき課題だと考えています。
質疑応答では、いくつか興味深いやり取りがありました。ある質問者からは、プログラムであれば変数置換を用いるが、プロンプトプログラムの場合はそれがなく、ユーザー入力そのものが事実上の変数のように扱われるのではないか、ユーザー入力が常に変化し続ける状況にどう対処するのか、という質問がありました。これに対して私は、私たちが想定しているのは「開発者」の役割、つまり何らかのエージェント的ワークフローを開発し、そのワークフローは一定に保たれたまま本番環境でずっと動き続ける、という状況であるとお答えしました。ユーザーが問題を変えながら二つのタスクに適用し、それを忘れてまた別のものを書く、というようなケースはカバーしていません。私たちが想定しているのは、たとえばある企業がカスタマーサポート担当者を全員解雇し、代わりにエージェントに任せることにした場合に、その仕組みが40%の確率でうまく機能する、というようなタスクです。この手法であれば、「およそ40%です」という答えを提供できます。
また別の質問者からは、ワークフローのプランニングにこの推定手法を活用すれば、より良いワークフローを発見する助けになるのではないか、という質問がありました。これに対しては、この推定はシステムの評価を助けるものであり、それ自体がより良いシステムを作ることには直結しない、と説明しました。既存のシステムを定量化することと、より良いシステムを構築することの間には違いがあり、今回の研究はあくまで既存システムの定量化についてのものだという趣旨です。またベイズ的な部分についても、ベータ分布をベルヌーイ分布の共役事前分布として用いているだけの、非常に単純なものであると補足しました。ただ、この研究で私が最も気に入っている点は、同じ観測結果、同じ尤度であっても、事前にどのような信念を持っているかによって、プログラムの良し悪しについての結論が大きく変わってくるという点です。もし企業のような立場であれば、こうした事前分布を裏側であらかじめ構築しておくことには大きな意味があります。ユーザーが新しいワークフローを開いたときに、コーパスから類似のワークフローを検索し、「これに類似したワークフローは過去に100件ほどあり、あなたの関心のあるドメインではおよそ50%の性能でした」というように、予測性能を顧客に提示できるからです。これはサービス提供者が顧客に対して定量的な情報を提供するための、一つの有効な手段になると考えています。
2. 断片化するカルテ、統合される知恵 ― ヘルスケアAIが挑む信頼の壁
2.1 データも知識も足りない ― 医療現場のリアルな壁
私の発表は、前のご講演ほど詳細なものではありませんが、私たちがこれまで数年間取り組んできたヘルスケア向けAI、特に最近構築しているエージェント関連のフレームワークについて、いくつかの知見をお伝えできればと思います。ヘルスケア領域には、さまざまなAI技術を試す上で、より豊かで複雑なシナリオが存在していると感じています。これは単なる機械学習の問題ではなく、多くの場合、医師のようなドメインの専門家と直接データに向き合いながら取り組む必要のある問題です。
ヘルスケアにおいて比較的研究が進んでいないデータとして、電子健康記録、すなわちEHRが挙げられます。このデータは最近になってようやく利用しやすくなってきており、特にアメリカでは、NIHが複数の病院や大学病院にまたがる、より大規模なデータセットの収集に多大な労力を注いでいます。しかし、それでもこのデータは依然として断片化しています。複数の病院からデータを取得したとしても、それぞれ異なるフォーマットを持っていることが多く、たとえばEpicのような、より標準化された電子健康記録システムを米国が採用しつつある現在でも、医師によって使う用語や表現が異なっているのが実情です。これは非常に大きな課題であり、多くの誤りやデータ品質の問題も存在します。さらに、電子化された健康記録であっても、実際にはPDFや画像フォーマットのままであることも珍しくありません。医師が今でも手書きでメモを取ることがあるのは、そのほうが速いと感じられているためです。
これに加えて、いわゆる「相互運用性の欠如」という問題もあります。異なる病院、異なる診療科、異なる医師が同じ患者を診ていても、フォーマットや用語がそれぞれ異なるため、このデータを統合して包括的な分析を行うことが難しいのです。さらに、縦断的なデータが非常に限られているという課題もあります。患者はさまざまな病院に通いますが、その際に異なる携帯電話番号やメールアドレスで登録することも多く、異なる病院やクリニックに行くたびに別々の情報として扱われてしまい、規模を拡大しようとする際に多くの課題に直面します。ですので、私はこれをまず「データの問題」として捉えるべきだと考えています。標準的なベンチマークタスクが用意されていて、そこに機械学習モデルを投入するだけで済むような領域ではなく、まずデータそのものと向き合うところから始める必要があるということです。
もう一つの課題はモデルに関するものです。こちらについては簡潔にお話しします。大規模言語モデルやその他の機械学習モデルに、医学的・臨床的な知識を獲得させる必要がありますが、これがヘルスケアにおいては難しいのです。文献から得られる一般的な医学知識だけでなく、非常に難しい疾患のサブタイプについての知識も必要になります。多くの人が糖尿病や高血圧のような疾患を抱えていますが、単一の疾患が常に合併症を伴うわけではなく、同じ疾患を持つ患者であっても異なる合併症を持つことがあります。同じ疾患であっても、異なるメカニズムによって引き起こされ、異なる治療法で対応すべき場合があります。これは、単一のモデルで多くの異なるケースに対応しようとする基盤モデルの原則という観点からも、非常に難しい問題です。多くの人はAIや大規模モデルを使って、平均的な人間によるサービスを代替したいと考えていますが、これはヘルスケアにとっては十分ではありません。人間がすでにできること、やりたいと思っていることを単に模倣するだけでは不十分で、大規模なデータと大規模なAIシステムを持っているからこそ、人間ができる範囲を超えることを目指すべきだと考えています。希少疾患も非常に難しい対象であり、包括的な推論が必要になります。私自身の研究の多くは、異なるリスク因子や異なる医学的概念どうしの相互作用、相互関係の研究に焦点を当ててきましたが、これは通常、患者データのマルチモダリティに由来するものであり、それがまた新しいモデルにとっての新たな課題をもたらしています。
ヘルスケアでは検証も非常に困難です。私たちには、診断のような二次的なグラウンドトゥルースデータは多く存在しますが、新しい治療法を生成しようとする場合には、いわゆる臨床試験というものが必要になります。これは、同じような状況にある二人の人間に対して、AIベースの手法と非AIベースの手法をそれぞれ適用し、因果的に有効な治療法を導き出す必要があるということであり、ヘルスケアにおいてこれがいかに困難であるかは想像に難くありません。さらに、精密医療を実現しようとすると、非常に複雑な患者データから導き出す必要がありますが、その際には特定の患者一人のデータだけでなく、関連する多くの他の患者のデータにもアクセスする必要が出てきます。それは自然とプライバシーの問題につながります。より良い医療を実現するにはより多くのデータが必要になりますが、それは同時に、より多くの人間のプライバシーに関わる機微な情報を露出させることを意味します。一般的なレコメンドシステムや商用システムであれば、機微な情報を取り除くこともできますが、ヘルスケアの場合、その情報を取り除いてしまうとデータの有用性が失われてしまうのです。
2.2 知識グラフという処方箋 ― エージェントが紡ぐヘルスケアの知恵
こうしたデータとモデルに関する数多くの課題にどう対処するか。私たちが取り組んできたのが、いわゆる「エージェントベースのデータ・知識エコシステム」と呼べるものです。基本的な発想は、まずモデルをエージェントとして活用し、データ収集からデータ統合まで、これほど複雑な患者データの前処理を助けてもらうというものです。もちろん、今日ではプライバシーやハルシネーションへの懸念も大きいため、モデルがどれだけ信頼できるかという点にも取り組んでいます。こうすることで、データ収集やデータ統合を医師が行う際に役立つ、信頼できる効果的なエージェントを開発できるようになります。データが揃った後は、大規模言語モデルや大規模マルチモダリティモデルを用いて、データを統一し、そこから統一された知識を生成します。私自身の研究はこれまで長年、グラフデータや知識グラフを扱ってきており、知識グラフは知識を統一するために利用する構造の一つですが、私たちはより一般的なタイプの知識ベースにも取り組んでいます。これは必ずしも伝統的な知識グラフである必要はなく、重要なのは、エージェントや言語モデルが理解できる形で、より多くの知識を集約していくという発想です。こうしてデータをこの種の知識ベースに集約していけば、そのナレッジベースを用いてポストトレーニングやRAG、ファインチューニングを行うことができ、特に構造化されたプロンプトや構造化された推論ガイダンスを考慮する場合には、大規模言語モデルの性能を逆に向上させる機会が生まれます。この一連の研究が現在、私たちの研究室における主要な方向性の一つであり、幸いにもアメリカの主要な研究助成機関や私たちの大学、そしていくつかの産業パートナーから支援を受けています。
ここからは、いわゆる「エージェント的データパイプライン」を構築するために私たちが行っている、より詳細な事例をいくつかご紹介します。データ収集とデータ統合を行うために、大規模言語モデルや大規模マルチモダリティモデルを活用しています。まずデータ収集についてです。近年、病院ではこうしたサービスの構築が進んでおり、レコーダーやスクリーニングツールのようなものを導入して、医師がより良いメモを書けるよう支援したり、患者との音声・会話を自動的にテキストへ変換したりしています。これによって、扱うべき追加のテキストデータが大量に得られます。また、患者データは他にも複雑なモダリティを持っています。EHR上の数値データのようなものだけでなく、より複雑なものとして、臨床検査のテキストに加え、医療画像や、時には分子レベルの遺伝子検査なども存在します。ですので、私たちは自然にマルチモダリティのデータを扱うことになります。私たちは、こうしたマルチモダリティ専用の大規模モデル、いわゆるMMLや波形基盤モデル、遺伝子基盤モデルのようなものを数多く構築、あるいは活用してきました。特定のモダリティ専用の基盤モデルを大規模言語モデルと整合させる研究は数多く行われており、対照学習や強化学習を用いて埋め込み空間を整合させる手法もありますが、私たち自身はそうした整合を一から行うのではなく、こうした既存のモデルを活用しています。私たちの目標は、これらのモデルが特定の種類の医療データに対してどのように機能するかを研究することです。たとえば、一般的な画像モデルがあれば、それが医療画像に対してどう機能するかを研究しますし、一般的な時系列基盤モデルがあれば、それがECGやPPGといった生理学的波形に対してどう機能するかを研究します。
その次のステップとして、こうした基盤モデルをエンコーダとして用い、患者データの埋め込みを計算します。通常、こうした埋め込みをもとに大規模言語モデルをファインチューニングし、この埋め込みを新しいトークンとして言語モデルに挿入して理解させようとする手法が一般的です。しかし問題は、大規模言語モデルをファインチューニングすること自体がそもそも難しいというだけでなく、それによって元の言語モデルが持つ能力の一部を壊してしまいやすいという点にあります。計算コストが高いだけでなく、モデルの能力を損ないやすいのです。そこで私たちがここで行っているアプローチはこれとは異なり、異なるモダリティの埋め込みを、新しいノードや新しいエンティティとして私たちの知識グラフに追加するというものです。これらのものは必ずしもテキストで記述される必要はありません。もちろん、マルチモダリティモデルを使って、特殊な波形パターンや特殊な遺伝的バイオマーカーといったものについてテキストを生成することもできますが、それに加えて、そのエンティティの埋め込みを知識グラフの新しいノードとしてそのまま追加することもできます。新しい患者が来た際には、同様のモダリティのデータを抽出し、同じ基盤モデルを使って埋め込みを生成すれば、知識グラフ内のそのエンティティを検索できます。そして一度そのエンティティが検索できれば、同じようなグラフベースの推論や、プロンプトエンジニアリングのようなものを適用でき、基本的には推論の質や、少なくとも他のモダリティのデータとの整合性における事実性を向上させることができます。これが、私たちが今まさに構築しているもの、つまり大規模言語モデルを直接ファインチューニングする代わりに、異なるモダリティのデータを知識グラフに追加していくというアプローチです。
こうした知識グラフ、いわば私たちの知識ベースを持った上で、次に取り組んでいるのは大きく二つの問いです。一つは、既存の知識グラフをより包括的にし、異なる種類の知識、異なるモダリティの知識をカバーするように拡張できるか、という問いです。もう一つは、知識グラフを改善できるかどうかにかかわらず、既存の知識グラフを用いて、エージェントを改善するためのより良い推論手法や、より良いポストトレーニング的な技術を開発できるか、という問いです。まず一つ目として、私たちは「ユニバーサル知識グラフ」と呼べるものを提案しました。その発想は、すべてのエンティティを一片のテキストで記述し、関係性も一片のテキストで記述するというものです。つまり、標準化のプロセス、すなわちオントロジーのような非常に静的なスキーマを作成するという煩雑な作業を省略し、その代わりにLLMエージェントを用いて自動的に知識グラフを構築するのです。もちろんこれによっていくらかの誤りが生じることは想像に難くありませんが、私たちの狙いは、知識グラフをより包括的にし、かつ言語モデルによって理解可能なものにすることにあります。この方法ではいくらかの誤りが生じますが、その後の推論段階において、他の推論メカニズムや不確実性ベースのメカニズムを用いてそれらに対処できると考えています。重要な問題は、知識グラフをより包括的にすることであり、それこそが、実際のアプリケーションで知識グラフを活用する上でのボトルネックになっているからです。
そして推論の問題として、どうすれば知識の品質を改善し、あるいは保証できるかという課題があります。私たちは、知識グラフに対するより信頼性の高い因果推論や因果発見、また記号的なルールや記号的推論を用いたロジカルルール学習といった研究に取り組んでおり、知識の品質を継続的に改善する研究を進めています。ここで私たちが取った一つの特徴的なアプローチは、こうしたタスクに大規模言語モデルを活用することでした。ここで最近私たちが開発した二つのフレームワークの例をご紹介します。一つ目は、大規模言語モデル、たとえばGPTのようなものを使って、知識グラフ上のルール学習を支援するものです。ルール学習とは基本的に、知識グラフの中で頻繁に共起するルールヘッドとルールボディを見つけるというものです。従来の手法では、こうした共起の統計をカウントし、より信頼性の高い推論を得るために多くのサンプリングを行いますが、この方法には多くのサンプルが必要な上、統計的なカウントベースの手法は、扱っている変数の意味を理解していないという課題があります。そこで私たちが行ったのは、ルールのインスタンスの数を単純にカウントする代わりに、大規模言語モデルが「正しい」と判断したインスタンスの数をカウントするという手法です。こうすることで言語モデルを推論プロセスに組み込み、単にインスタンス数を直接カウントするのではなく、より意味的に検証可能なインスタンスをカウントすることになります。これによって必要なサンプル数を大幅に削減でき、また大規模言語モデルが蓄積してきた世界知識を反映したルールを導き出せるようになります。実際に、最近開発された同種のアルゴリズムと比較したところ、私たちの手法は同じAPIコストでより多くのルールを発見でき、しかもそのルールの正確性もより高いという結果が得られました。
ルールや因果構造を発見した後、つまり比較的信頼性が高く包括的な知識ベースを得た後に、それをどう使って大規模言語モデルを改善できるかという点についても、他のさまざまな技術に取り組んできました。これには、いわゆる「構造化知識」を用いてファインチューニングや推論時の推論プロセス、検証を改善するという、コミュニティ全体で取り組まれている多くの研究があります。基本的な考え方として、私はこれをいくつかのタイプに分類しています。一つはファインチューニングで、知識グラフからパスや部分グラフのような推論の道筋を生成し、それを用いて大規模言語モデルのファインチューニングを行うという研究が数多く存在します。これによって言語モデルは、構造化データの中のルールに基づいて推論することを学習します。私たちのユニバーサル知識グラフも、比較的緩い構造ではありますが、同様にパスを見つけたり、そこでのマルチホップ推論を行ったりすることができます。二つ目は、構築した知識グラフを別のRAGの情報源として使うというものです。私たちにはいくつかの研究があり、たとえば大規模言語モデルに対して患者のEHRの特徴を多数与えて、その患者が特定のリスクを発症するかどうかを予測させようとすると、言語モデルはすべての特徴と結果との間の相関関係を見つけようとする傾向があり、往々にして陽性の答えを出してしまいます。これはモデルが慎重でありたい、偽陰性を減らしたいと考えているためですが、それでは実質的に使い物にならない予測になってしまいます。そこで私たちが行っているのは、私たちのユニバーサル知識グラフを使って、より関連性の高い特徴を実際に見つけ出し、その関連する特徴だけを最終的な推論のために言語モデルに与えるという方法です。こうすることで、精度を改善し、偽陽性を大幅に減らしながらも、同時に偽陰性については同程度の水準を維持できることを示しました。これによってシステムがはるかに実用的なものになります。
最後にもう一つ、検証についてです。知識ベースや知識グラフを使って、多くの合成的な質問を生成し、それを用いてさまざまな大規模モデル、さまざまなプラットフォームによって開発された異なるモデルを検証することもできます。また別のアプローチとして、たとえば質問応答のようなアルゴリズムを持っている場合、そのアルゴリズム自体が言語モデルであるかどうかにかかわらず、大規模言語モデルを使って回答に対する事後的な解釈を行うこともできます。具体的には、モデルに対して、回答をどのように分解すれば知識グラフの中で検証可能な原子的な主張へと落とし込めるかをプロンプトで指示します。もし知識グラフが十分なカバレッジを持っていれば、正しい原子的な主張のほとんどを検証できるはずであり、これらの主張が検証されれば、それは回答全体がどれだけ妥当であるかについての、一種の近似的な検証、代理指標になります。私たちは実際に、この知識グラフベースの検証を人間による検証と比較し、両者の間にかなり強い相関があることを見出しました。これは、この事後的な検証が有望なアプローチであることを示していると考えています。この論文は昨年の初め頃に発表されたものです。
最後のスライドとして、これは生成AIによって作られた画像と、生成AIによって作られたテキストです。私たちには多くのことができると考えており、AIにもそれを実現してほしいと願っています。多くの人々が、ヘルスケア向けのより良いAIを構築することによって恩恵を受けられることを願っています。私からは以上です。ご質問や、あるいは今後の共同研究についてのご提案を歓迎します。付け加えると、私たちはKDDカンファレンスで新しい論文トラックを運営しています。もしヘルスケアにご関心があれば、これはまさに私たちが重視したいトピックの一つですし、AIを用いた学際的な研究といったテーマの論文も歓迎しています。締め切りが近づいていますので、ぜひご検討ください。
質疑応答では、まず知識ベースの活用方法について、事後検証だけでなく、事前学習や継続事前学習の段階でも活用する材料があるのかという質問がありました。これに対しては、もちろん知識グラフのデータを使ったファインチューニングや継続的な事前学習は可能であり、一般に公開されている知識グラフの多くは、すでに現在の多くのモデルの事前学習に活用されているだろうという理解を示しました。ただし、もし私たちが新たに構築した知識グラフに対して、独自の検証手法を用いてエンリッチメントを行えば、それはさらに役立つ可能性があると付け加えました。また、以前の研究として、知識グラフやソーシャルネットワークのようなグラフから有用なパスや部分グラフを抽出し、それを用いて大規模モデルのファインチューニングを行う研究にも触れました。
さらに、このワークショップのテーマである「エージェントAIをどう信頼し、どう制御するか」という観点から、ヘルスケアという領域は特に慎重な配慮が必要な分野であるとして、研究者や学生への助言を求める質問もありました。これに対しては、ヘルスケアがなぜこれほど挑戦的な領域なのかという点について触れつつ、一般的な領域でもエージェントや生成AIをどう活用すべきかという問いに答えるのは容易ではない中で、ヘルスケアにおいてはこの問題がさらに難しく、より深刻なものになるとお答えしました。同時に、ヘルスケアには未開拓の状況や課題が非常に多く残されているとも述べました。もし信頼性の高い、頼りになるAI技術を持っているのであれば、ヘルスケアはそれを試すべき非常に重要な領域になるはずであり、実際、過去に多くの基礎的なAI技術やコンピュータサイエンスの技術は、生物医学研究に取り組む人々によって開発されてきたという歴史があることにも言及しました。こうした、より困難な状況こそが、私たちをより良いAIの開発へと駆り立てていくのだと考えています。
3. エージェントに国境警備を ― 産業界が築く多層防御アーキテクチャ
3.1 憲法・見張り番・懐疑の目 ― 自己反省だけでは足りない理由
私はテンセントセキュリティの者です。本日は、私たちの研究およびエンジニアリングの実践を通じて、信頼できるエージェントをどう構築していくかについてご紹介したいと思います。今回お話しする内容は「アライメントからアイソレーションまで」というテーマで、モジュール化された観点からエージェントのアーキテクチャを構築していく取り組みです。まず本日カバーする内容の全体像をお示しします。最初に、なぜ今、信頼できるエージェントがこれまで以上に重要になっているのかという背景をお話しし、そこからアライメントとオーディティングという私たちの技術面での取り組みに入ります。ユーザー側を守るためのガーディアン、そしてエージェントの実行をより安全にする方法についてお話しし、最後に、こうしたエージェントをより堅牢でモデルとして信頼できるものにしていくための、私たちの継続的な改善サイクルについてもお伝えし、最後に全体のまとめをいたします。
まず産業界の動向、学術研究、そして私たち自身のインテリジェント・ペネトレーションテストの実践から見えてきたのは、セキュリティ分野における根本的な変化です。労働集約的で人間中心のフレームワークから、自律的なフレームワークへと移行しつつあります。AIの技術が進化するにつれて、単一のセマンティックな理解から、自律的な判断・裁定へと移行しているのです。これは、単発の対話から、複雑なループへの移行を意味しており、これこそが高度に自律的なエージェントの真の出現を示しています。この課題を説明するために、あるエビデンスをご紹介します。適切にアーキテクチャされたエージェントは、自律的にウェブコンポーネントを探索し、脆弱性を特定し、自律的にリクエストを実行して機密データを盗み出すことができるということが確認されています。これを放置すれば、本番環境に壊滅的な影響を及ぼしかねません。さらに、最近の研究では敵対的攻撃のリスクも指摘されています。たとえば、一見無害に見える画像の中に、人間にもシステムにも見えない形で悪意のあるプロンプトを埋め込むことができるのです。こうした偽装されたホストは、エージェントを欺いて、自らの意思に反する行動を取らせ、価値あるものを盗み出させることが可能になります。
つまり、こうした脆弱性はもはや孤立した問題ではありません。ユーザープロンプトの初期段階から、コアの処理過程、トレーニング、行動、そして下流のモデルに至るまで、自律的エージェントのライフサイクル全体にリスクが埋め込まれているのです。自律性というものは、もはや単なる機能の一つではなく、ミッションクリティカルな制約そのものになっています。真に自律的なエージェントを構築する上での根本的な課題は、単なる能力やアライメントの問題にとどまりません。アライメント技術は有望ではありますが、エージェントの行動が価値観や法的な境界の中に留まり続けることを保証する必要があります。「聞こえないものは聞けない」、つまり見えていないリスクには対処できないのです。そこで本日は、私たちが実際に展開している、モジュール化された多層防御についてお話しします。
私たちの最初の防御ラインは、規制そのものから始まります。単にタスクの説明を与えるのではなく、すべてのタスクセットの冒頭で、形式化されたエージェントの規範をシステムプロンプトの中に注入します。これは、いわば価値観のロックのようなものだとお考えください。たとえば、単に「タスクを実行せよ」と指示するのではなく、有害なコンテンツの生成禁止や、データ最小化の厳格な遵守といった、明示的な禁止事項を定義します。これは、その後に続くすべての自律的な行動に対する道徳的な指針として機能します。
第二の防御は、入力側での意図の検出です。ユーザーのプロンプトがエージェント本体に触れる前に、複雑なジェイルブレイクや間接的な誘導といった敵対的な意図を検出するようエージェントに求めます。悪意ある意図を無害化し、エージェントの内部状態が最初から汚染されないよう保護するパラメータを設けています。最後に、リスクの高い環境向けには、生成された計画に対して二重チェックを行う仕組み、すなわち自己反省による整合性確認を実装しています。計画が生成されると、エージェントは強制的に事後の監査ループに入り、あらかじめ定義されたチェックリストと照合しながら自らの行動を精査します。この計画は認可された機密データに関与していないかを自らに問い、違反が検出された場合には、エージェントは軌道を修正するか、人間の介入をエスカレーションしなければなりません。この仕組みは標準的なシナリオにおいては信頼性を高めることができますが、それでもエージェントに文脈を与えるだけのものです。しかしここで一つ、恐ろしい問いが浮かび上がります。もしエージェント自体、たとえばエージェントの中の言語モデルがすでに侵害されている、いわばバックドアを仕込まれているとしたら、この仕組みをそれでも信頼できるのでしょうか。この限界こそが、私たちを次の防御層へと導くことになりました。
センチネルエージェントに単独で依存するアーキテクチャには、根本的な弱点があります。もしエンジンがすでにプロンプトによって突破されている場合、あるいはこのホストが深く汚染されている場合、内省のメカニズム自体もまた汚染されてしまい、自らの不正な行動を「妥当である」と検証してしまう可能性があります。これはある種のエコーチェンバー効果です。これを打破するためには、単純なチェックから懐疑へと、私たちの哲学そのものを転換しなければなりません。自己反省とは異なり、セカンダリの検証は完全に独立したエンティティとして行われます。プライマリエージェントとメモリも文脈も共有せず、まったく異なる基盤モデル、いわばセキュリティ専用のライブラリモデルの上で動作します。これによって、たとえプライマリエージェントが軽微なウイルスのようなものに感染していたとしても、センチネルは無事のまま保たれることが保証されます。
ここでの核心的な違いは、その判断ロジックにあります。プライマリエージェントが計画を提出する際、センチネルはそれを理解しようとしたり、共感しようとしたりはしません。代わりに、常に懐疑的な姿勢を取ります。たとえば、プライマリエージェントが「この処理を最適化するためにこのスクリプトを実行する」とだけ述べたとしても、センチネルは「攻撃者はこのスクリプトを悪用してデータベースを削除したり、シェルを乗っ取ったりできないか」と問いかけます。つまり、計画は証明されるまでは有罪である、という前提に立つのです。これによって真の職務分離が実現します。プライマリエージェントは効率のために最適化を行い、センチネルはセキュリティのために最適化を行います。たとえプライマリエージェントが完全に汚染されていたとしても、センチネルが独立性を保っている限り、実行に対する制御の鎖は保たれます。これは単なる監視ではなく、いわばデジタル版のチェック・アンド・バランスなのです。
3.2 データを守る砦、実行環境を封じる檻
ここまで、規制とオーディティングを通じてエージェントの行動をどう整合させるかについてお話ししてきました。しかし、どれほど完璧に振る舞うエージェントであっても、その行動は情報に基づいて行われます。ここで、エージェントのライフサイクルにおけるもう一つの重要な次元、すなわちユーザーのプライバシーの話に入ります。ユーザーのプライバシーを守るために、私たちはデータ分類と脱識別化のシステムを提案しています。これはユーザープライバシーフレームワークの礎石です。なぜこれが必要なのでしょうか。それは、私たちが伝統的なソフトウェアとは異なる世界を目の当たりにしているからです。従来はデータは構造化されたデータベースの中に、あるいは特定のカラムの中に整理されて格納されていましたが、エージェントの世界では、データは液状で構造を持たず、ユーザープロンプトやチャット履歴、文書、そしてメタデータが、コンテキストウィンドウの中に深く絡み合っています。ここで「全か無か」というアプローチは通用しません。もしすべてを暗号化してしまえば、エージェントは遅く鈍くなってしまいますし、逆に何も暗号化しなければ、すべてが露出してしまいます。そこでこのDCDシステムは、異なる種類のデータを分類し、それぞれ異なる保護モデルを個別に適用するよう設計されています。たとえば隣人の名前と天気情報が同じコンテキストウィンドウの中に現れたとしても、それぞれまったく異なるセキュリティプロトコルで扱われなければなりません。レベル3の機密データとレベル1の公開情報を正確に区別できて初めて、アライメントされた知能を損なうことなく差分プライバシー処理を実装できるのです。
これを実現するために、私たちのシステムはデータを同時に処理するハイブリッドなデュアルエンジンアーキテクチャを採用しています。まずルールベースエンジンです。これは長年蓄積されてきた専門的なセキュリティのヒューリスティクスを統合しており、決定論的で、高い並行処理要求にも対応できます。二つ目はAIベースのエンジンです。こちらは言語モデルの力を活用して、ルールでは捉えきれない微妙なニュアンスや高リスクなパターンを識別します。この組み合わせによって、伝統的なセキュリティが持つ堅牢性と、現代的なAIが持つ適応性の両方を確保しています。
このDCDシステムを信頼できるエージェントに適用する際、まずインバウンドセキュリティに適用します。これは入力段階における重要な脆弱性に対応するものです。ユーザーは利便性を求めるあまり、エージェントとのやり取りの中で意図せずに機微な情報を露出してしまうことがよくあります。もしそのデータがクレジットカード番号や患者IDのようなものであった場合、それがそのままエージェントのコンテキストウィンドウに流れ込んだり、さらに悪いことに長期記憶として保存されたりすれば、重大なコンプライアンス上のリスクを招きます。これを防ぐために、私たちのDCDシステムはファイアウォールとして機能し、エージェントへの入力、ツールへの入力、そして他のサブエージェントへの入力を含む、あらゆる入力を検査・スキャンします。医療関連の識別情報のような高リスクなデータを検知すると、直ちに動的な削減や正規化の処理を実行します。たとえば、クレジットカード番号をそのままエージェントに渡す代わりに、システムは特定の桁を汎用的なクレジットカードトークンに置き換えます。ここで重要なのは、単に主要なパラメータをマスキングするのではなく、トークン化という技術を用いている点です。これによってデータの意味そのものは保持され、エージェントはそのエンティティが何であるかを理解し続けることができます。エージェントはそのデータの「宿題」は理解できても、意味のない生の数値そのものにはアクセスできないのです。これによって、ユーザーだけでなくエージェント自身も保護されることになります。
次にお話しするのは、より難しいフロンティアであるアウトバウンドセキュリティです。ここで私たちが直面する主要なリスクは、悪意あるツール出力です。典型的なシナリオとして、エージェントが侵害されてユーザーのプロファイルをデータベースに問い合わせるよう仕向けられるケースを考えてみましょう。データベースには、無害なユーザーの嗜好情報から非常に機微な情報まで、多岐にわたるデータが含まれていることがよくあります。そこで私たちのDCDエンジンは、ツールのレスポンス段階に介入し、動的なフィルターとして機能します。まず、特定のデータレベルに基づいて差分保護操作を適用します。レベル3の機密データ、たとえば電話番号のようなものにはパーティングを適用し、レベル3のトップシークレットデータ、たとえばAPIキーやパスワードのようなものにはプレースホルダーによる管理を行います。これによって重要なセキュリティ境界を確保できます。エージェントはロジックを処理するために必要な情報だけを見ることができ、知りたいと望むかもしれない情報のすべてにはアクセスできない、という状態を実現するのです。
こうして、アライメントによってエージェントの「心」を、パーティングによってその「状態」を守ってきましたが、次にエージェントが動作する環境の基盤そのものを検証する必要があります。リアルタイムの応答を実現するために、高性能なモデルはクラウドネイティブな環境に強く依存しています。私たちは大規模なGPUクラスタについてはクラウドサービスプロバイダーに、そしてChatGPTやGeminiのような強力なクローズドソースモデルについてはモデルベンダーに大きく依存しています。さらに、より高い知能を実現するために、私たちはエージェントに広範な権限を付与しています。データベース、ファイルシステムといった重要な外部ツールとエージェントを統合し、中でも最も強力でありながら最もリスクの高いものが、任意のコード実行です。しかし、このインフラは根本的な信頼の課題を生み出しており、ユーザーは重要な問いを投げかけています。一つ目は、クラウドプロバイダー自体は信頼できるのか、彼らは秘密裏に私たちのデータを使って次世代モデルを訓練していないか、という問いです。二つ目は、エージェントのカーネルは安全か、大規模言語モデルは個人ファイルの削除を防げるほど堅牢か、という問いです。三つ目は、サンドボックスのセキュリティです。もしエージェントがハルシネーションやインジェクションによって悪意あるコードを実行してしまえば、ホストOSが侵害されたり、データベースの情報が盗まれたりするのではないか、という問いです。
この根本的なユーザーの信頼のギャップを埋めるために、単なる「約束」に頼ることはできません。私たちは検証可能なガーディアンをアーキテクチャとして構築する必要があると考え、二層のインフラ防御を提案しています。まず、クラウドの信頼性の問題に対応するために、プライバシー保護型のクラウドコンピューティングを導入しました。私たちの目標は、クラウドのモデルを「ブラックボックス」から「透明で検証可能なもの」へと変えることであり、これによって基盤モデルの信頼性を大幅に高めることができます。次に、実行時の安全性の問題に対応するために、多層的なセキュリティサンドボックスを提供しています。これによって、エージェントの意図や自動化の度合いにかかわらず、その振る舞いは確実に封じ込められ、ホスト環境からアイソレートされることが保証されます。プライバシー保護型のクラウドコンピューティングは、盲目的な信頼から検証可能な信頼への移行を象徴しています。私たちは、ステートレスであり、かつ透明性のあるコンピューティングモデルにコミットしています。
まずステートレスコンピューティングです。私たちは機密コンピューティング内でのデータ処理を提案しており、セキュリティシリコン上で動作します。このシステムはガーディアンとして設計されており、ハードウェアのルート・オブ・トラストからBIOS、ホットウェア、そしてソフトウェアスタック全体に至るまで、タスクが停止した時点で個人データが一切残らないよう、スタック全体を強化しています。これは暗号学的に保証されたものです。二つ目は、厳格なエンドツーエンド暗号化です。データが伝送中であっても、そして最も重要な計算中であっても、暗号化された状態を保ちます。従来のクラウドセキュリティでは処理中にデータを平文にすることが多いのに対し、私たちのアーキテクチャは計算中であっても暗号化のメカニズムをそのまま維持します。データフローは、途切れることのない暗号化トンネルの中を流れ続けるのです。三つ目、そして最も重要なのが、透明な検証可能性です。私たちの考えでは、信頼は単なる約束ではなく、暗号学的な証明に基づくべきものです。そこで私たちはリモートアテステーションのプロトコルを導入しました。これによって、ユーザーのデバイスはコードの署名や鍵を暗号学的に検証できるようになります。もし署名が公開された基準と一致しない場合、デバイスは単純に接続を拒否します。これによって、セキュリティの形は「ブラックボックス」から「開かれたもの」へと変わります。
エージェントがコードを書き、ツールを実行できる時代において、実行の隔離はもはや基本的な防御策です。私たちは、ネットワーク、実行、ユーザー権限、そしてデータ次元にまたがる多層的なセキュリティサンドボックスをアーキテクチャとして構築しています。ここでの核心的な哲学は、遮断と最小化です。まずネットワーク層では、デフォルトで非必須の接続を遮断し、リバースシェルやデータ破壊を防ぎます。次に実行時には、プラグインベースのコード実行を利用した独立したマルチユーザー環境を強制し、すべてのエージェントタスクは、厳格に制限された権限のもとで、隔離されたコンテナ内で起動されます。これは単なる理論上のテストではありません。私たちの基盤モデルの実運用テストにおいて、このボックスは実際に高い耐性を示しており、1日あたり8,550件にも及ぶ悪意あるコード実行の試みを日常的に阻止しています。高強度のレッドチーム対ブルーチームの演習や日常運用の中で、このインフラからビジネスアプリケーションに至るまでの防護が、私たちの最終防衛ラインとして機能してきたことが実証されています。
3.3 見える化から自己進化へ ― SAFERフレームワークが描く未来
ここまで、セキュリティ、ガーディアン、アライメント、プライバシー、そしてインフラについてお話ししてきましたが、いよいよ最後の段階、自律型エージェントの文脈において最も重要な評価についてお話しします。私たちは評価のあり方そのものを見直す必要があります。それは単にあるタスクの成功か失敗かを記録するだけの、静的な視点にとどまるものであってはなりません。実際には、評価はいわば「進化のエンジン」であり、フィードバックループを閉じる責任を担っています。これは、三つの要素からなる連続的なサイクルを伴います。すなわち、リアルタイムで何が起きているかを見るランタイムモニタリング、なぜそれが起きたのかを理解するための構造的な評価、そしてそこから得られた知見を用いてエージェントの継続的な改善を推進する、継続的な進化です。
ここで基本となる考え方は、「見えないものは導けない」ということです。自律型エージェントの安定性を確保するために、私たちはプラットフォームの実行ライフサイクル全体を計装しています。このプラットフォームは、重要な次元にわたって粒度の細かい洞察を提供します。一つ目の次元はプロセスモニタリングです。私たちは単なる成功か失敗かをはるかに超えて、プロセス全体を監視します。このプラットフォームは、エージェントの行動の軌跡におけるあらゆるステップを自動的にトレースし、その内部の思考連鎖、個々のツール呼び出し、そしてログからレスポンスまでを記録します。私たちは行動の背後にある「なぜ」を捉えているのです。二つ目の次元はツールの利用状況です。どのAPIが呼び出されたか、パラメータは規約に準拠しているか、サーバーが500エラーを返していないかを確認します。これによって、統合における異常、たとえばタイムアウトやハルシネーションによるパラメータの問題が深刻化する前に、即座に捉えることができます。最後の次元はモデル自体のパフォーマンスモニタリングであり、バイタルサインをリアルタイムでチェックします。トークン消費量やレイテンシといった重要な指標を監視することで、基盤となるモデルが健全で応答性を保っていることを確認します。このフレームワークによって、私たちはエージェントの状況を可視化でき、受動的なロギングから能動的な防御へと移行し、エージェントを常に意図した軌道の上に保つことができるようになります。
私たちの能力は、単なる到達点ではなく、あくまで通過点にすぎません。私たちの最終的な目標は、自律的な自己進化です。現在は人間参加型のモデルに依存していますが、自律的な改善のための基盤を築いている最中です。それはまず、事後分析から始まります。私たちは専門のエージェントアノテーションプラットフォームを構築しており、あらゆる単一の実行トレースを、単なるログとしてではなく、価値あるデータ資産として扱います。私たちは、こうした一過性の行動を、ユーザー自身に帰属する価値あるデータベースへと変換しています。その次に来るのがハイブリッドアノテーションです。私たちは協調的なモデルを用いて、まず高度なモデルにトラジェクトリログの初期スコアリングを行わせ、ノイズを洗い出します。そのうえで、人間の専門家がいくつかの一般的なケースや複雑なロジックを見直します。このプロセスによって、正しい行動とはどのようなものかというグラウンドトゥルースが検証されます。こうして自動化されたトレースをもとに、正確にプロンプトの問題なのか、能力のギャップなのかを特定し、それに応じてコンポーネントを最適化することができます。これによって強力なデータフローが生まれます。エージェントが整合されればされるほど、蓄積されるトラジェクトリが増え、それが蓄積されるほど学習が速くなり、最終的にエージェントはあらゆるやり取りを通じて、より賢く、より堅牢に、そしてより安全になっていくのです。
結論として、コミュニティはすでに、自律型エージェントが古典的な反応ループ、すなわち入力・計画・実行・観測というループの上で動作するということを確立しています。私たちにとって、これは単なる計算プロセスではありません。このループの一つ一つのステップを守るための、継続的なリスクマネジメントの連続なのです。私たちの信頼アーキテクチャ全体を、SAFERというフレームワークにまとめました。Sは標準化(Standardization)を表し、入力段階において、エージェントの憲法を通じた厳格な行動境界を確立することを意味します。Aは監査(Audit)のためのリーズニングを表し、自己反省のエコーチェンバーを打破するための独立したセンチネルエージェントを展開することを意味します。Fは要塞化(Fortification)を表し、観測と行動に対して、匿名化、暗号化、そしてアイソレーションを通じた保護を構築することを意味します。Eは評価(Evaluation)を表し、あらゆるトレースをチェックするためのライフサイクル全体のモニタリングと、エージェントの性能を評価し品質を検証するためのハイブリッドアノテーションプラットフォームを実装することを意味します。そしてRは改善(Refinement)を表し、最終的にこのループを閉じて、ユーザーがこのデータを用いてエージェントを継続的に最適化し、進化させられるようにすることを意味します。このSAFERフレームワークは、私たちがセキュリティエンジニアとして、自律性の時代における根本的な信念として掲げているものであり、プロンプト、モデル、そして環境という三つの側面を貫くものです。私たちの使命は、信頼できるものを構築することにあります。
今後を見据えると、コミュニティにとって三つの重要なフロンティアがあると考えています。一つ目は、確率的なセキュリティから、数学的なセキュリティへの移行です。エージェントのロジックに対して、自動化され、証明可能な形式手法を探求していくことです。二つ目は、経験的な能力から、検証可能な信頼性への移行です。今日、私たちはエージェントの学習モデルがどんどん強力になっていると感じていますが、時にはなぜそうなるのかを説明できないことがあります。三つ目は、自律性がもたらす新たな依存関係への対応です。私たちは「火をもって火を制す」必要があり、エージェントを守るためのエージェント型セキュリティを構築していく必要があります。技術というものはまさに諸刃の剣です。もし私たちが今日、堅固で安全な基盤を築くことができれば、この信頼という言葉を私たちのエージェントに、そして未来へと引き継いでいくことができるはずです。本日は以上です。ご清聴ありがとうございました。
質疑応答では、まずエンドツーエンド暗号化プロトコルについて、Luma AIとProtonが実装している同様の手法との違いを問う質問がありました。この点については後日改めて回答すると述べるにとどまりました。次に、安全規範、すなわち「エージェントの憲法」に用いるデータをどのように決定・作成したのか、またどの程度あれば十分と言えるのかという質問がありました。これに対しては、現在の規範はいくつかのルールや規制、倫理的制約から要約されたものであり、あらかじめこれらのルールを定義してシステムプロンプトに埋め込んでいると説明しました。現時点では言語モデルがシステムプロンプトを厳密に遵守できることを前提としていますが、今まさにモデルのファインチューニングにも取り組んでいるところであると付け加えました。
さらに、こうしたガードがエージェントアプリケーションの精度や成功率にどの程度の悪影響を及ぼすのか、具体的な数値はあるのかという質問もありました。これについては、現時点では性能への影響を定量化するには至っておらず、システムはまだ本番運用の中でテストを続けている段階であり、実際に見つかった課題ごとに、メモリ管理やレンダリング、行動生成の各コンポーネントを段階的に最適化している最中であると説明しました。最後に、このSAFERフレームワーク自体が本質的にマルチエージェント、あるいはマルチLLM的な枠組みであり、「LLMを使ってLLMをより安全にする」というアプローチなのではないか、という指摘もありました。これについては、その通りであると認めた上で、言語モデルの包括的な理解能力への依存を前提として、ヒューリスティックなルールベースのシステムから、より意味理解に基づくシステムへとアーキテクチャを移行させてきた経緯を説明し、攻撃・防御や監視といったセキュリティのシナリオにより適したモデルを育てるためのトレーニングにも取り組んでいると述べました。言語モデルが完全に信頼できるとは考えていませんが、それをより信頼できるものにしていく必要があるという考えを最後に共有しました。
4. 毒された知識を見抜く ― TrustRAGが挑むRAG汚染攻撃
4.1 RAGはこうして毒される ― PoisonedRAG攻撃の手口
私はユニバーシティ・カレッジ・ロンドンの博士課程1年生です。本日は、私たちの論文であるTrustRAGについてお話しします。タイトルは「RAGシステムにおける頑健性と信頼性の強化」です。まず、RAGに関するサーベイ論文をもとに、背景をご説明します。この論文の著者は、RAGシステムを大きく三つの部分に分けています。一つ目はインデキシングです。これは、生の入力、つまり生のテキストや文書をチャンクに分割し、それぞれのチャンクを埋め込みにエンコードして、最終的にその埋め込みをベクトルデータベースに格納する部分です。二つ目は検索です。RAGシステムはユーザーからクエリを受け取った後、意味的な類似性に基づいて、上位k件の最も類似した関連文書を検索します。そして三つ目は生成です。RAGシステムはユーザーのクエリと関連文書を合わせて大規模言語モデルに入力し、最終的な回答を生成します。これがRAGシステムの全体像であり、エンドツーエンドで大規模モデルの事実性と能力を向上させることを目的としていますが、同時にRAGシステムの安全性・セキュリティ・プライバシーについての懸念も指摘されています。ご興味のある方は、こうした議論の詳細に触れている複数の関連リンクをご参照いただければと思います。
こうしたRAGの安全性に関する議論に触発され、研究者たちはRAGに対する攻撃フレームワークを提案しました。それがPoisonedRAGと呼ばれるものです。この攻撃では、まず攻撃者が標的となる質問、たとえば「OpenAIのCEOは誰か」というような質問を設定し、それに対応する望ましくない標的の答え、たとえば「Tim Cook」というような答えを設定します。攻撃者はこの質問と答えのペアをPoisonedRAGに入力し、PoisonedRAGは「Tim Cookは2024年からOpenAIのCEOである」といった内容を含む悪意のあるテキストを生成します。このテキストはWikipediaのデータベースやローカルのデータベースに注入され、RAGシステムがこの悪意のあるテキストを検索してしまうと、大規模言語モデルはこの偽の情報に基づいて誤った回答を生成してしまいます。
この攻撃の背後にあるメカニズムについて、三つのステップに分けて説明します。まず一つ目のステップでは、攻撃者は「Tim CookがOpenAIのCEOである」といった、標的とする回答を含む文を生成します。そのうえで、攻撃者は大規模言語モデルを活用して、それをより長い段落として生成します。二つ目のステップでは、この文Xを初期化し、検索システムによって実際に検索されるように最適化する必要があります。なぜなら、もし悪意のあるテキストとクリーンな文書との間の意味的な距離が離れすぎていれば、そもそも検索されないからです。そのため攻撃者は、この類似度を最適化する必要があります。そして三つ目のステップでは、攻撃者は大規模言語モデルが望ましい標的の回答を生成する確率を高めようとします。ここで用いられる攻撃手法は、非常に有名なジェイルブレイク攻撃であるGCG、すなわちグリーディ・コーディネート・グラディエント攻撃に似たものです。さらにこの最適化は、元の文と摂動を加えた後の文との間の意味的な距離を一定に保つよう制約された数式のもとで行われます。
続いて、RAGに対する防御手法についてもご紹介します。RobustRAGは、RAG防御における最も早期の研究の一つです。この論文における防御メカニズムは、集約、あるいは「マジョリティボート」とも呼ばれる仕組みで、キーワード集約とデコーディング集約という二つのメカニズムを用いています。キーワード集約はブラックボックスのモデルとホワイトボックスのモデルの両方で機能しますが、デコーディング集約はホワイトボックスの大規模モデルでのみ機能します。これは、勾配や次のトークンを生成するための出力ロジットにアクセスする必要があるためです。しかし、この種の防御手法は、比較的クリーンでノイズの少ない環境でしか機能しないという限界があります。実際、悪意のある文書の数がクリーンな文書の数を上回ると、このシステムは機能しなくなってしまうことが確認されています。
4.2 二段構えの解毒剤 ― クリーン検索と競合解消
そこで私たちは、TrustRAGという手法を提案しました。私たちのTrustRAGは二つのステージから構成されています。第一のステージはクリーン検索です。ここでの素朴な発想は、上位k件のチャンクの中に含まれる悪意ある文書の数を減らせないか、というものです。攻撃の目的に基づいて生成された悪意のある文書は、同じ目標、たとえば「OpenAIのCEOはTim Cookである」という目標を共有しているため、自然とクラスタ状に集まりやすいという性質があります。実際に私たちが行った予備的な実験では、二種類の分析、すなわちコサイン類似度スコアとROUGEスコアに基づいたペアワイズ比較を行いました。その結果、悪意のある文書グループの中には大きな重なりが見られ、悪意のあるグループにおけるコサイン類似度は0.9を超え、ROUGEスコアも0.33を超えることがわかりました。これは他の二つのグループとは明確に異なる性質です。コサイン類似度は意味的な観点からの類似性を、ROUGEスコアは表層的な観点からの類似性をそれぞれ表しています。
この第一ステージの性能評価には、二つの指標を用いました。一つ目はF1スコアで、これは毒された文書を検出する性能を測るものです。二つ目はクリーン保持率(CR)で、これはフィルタリング後にクリーンなサンプルが保持される割合を評価するものです。毒された文書の割合を0%から100%まで変化させた実験結果を示す表を見ていただくと、あらゆるシナリオ、あらゆるデータセットにおいて、SimCSEが最も良い性能を示すことがわかります。そこで私たちは、第一ステージの埋め込み手法としてSimCSEを採用することにしました。
第二のステージは競合解消です。ここでは、ほとんどの悪意ある文書が第一ステージですでにフィルタリングされていることを前提としています。そのうえで、大規模モデル自体が持つ内部知識を活用することで、私たちのフレームワークをさらに強化できます。大規模モデルはインターネット上の膨大なコーパスで事前学習されており、その過程で本質的な常識やパラメトリックな知識を獲得しています。これに着想を得て、私たちは三つの先行研究(それぞれ参照文献として示しています)を参考に、大規模モデルの内部知識を活用した知識統合を行い、簡潔な結論を導き出します。そして最終ステージでは、自己評価のメカニズムを実装し、大規模モデル自身に、内部知識に依拠すべきか、あるいは検索された外部知識に依拠すべきかを判断させます。
この表は私たちの全体的な結果を示すもので、Llama、GPT、そしてもう一つの大規模モデルの合計三種類のモデルを用い、RobustRAG、Instruct、そしてもう一つの強力なベースラインという三種類の強力な比較手法と、HotpotQA、Natural Questions、MS MARCOという三種類のデータセットにわたって比較を行いました。攻撃手法についても、プロンプトインジェクション攻撃、PoisonedRAG攻撃、そして敵対的デコーディング攻撃という三種類を用いています。この表からわかる通り、私たちのフレームワークはあらゆるシナリオにおいて最先端の性能を達成しています。ここで特に重要な点として、一般に防御手法はクリーンな環境において精度や情報を損なってしまうことが多いのですが、私たちの手法はクリーンな環境においても精度を維持できているという点です。これはこの表の3列目に示されている通りです。また、私たちのフレームワークの各コンポーネントを検証するための包括的なアブレーション実験も行っており、毒された文書の割合を0%から100%まで変化させたさまざまな設定についても検証しています。詳細については論文をご覧ください。
最後に、今後の課題についてお話しします。一つ目は、内部知識を使うべきか使うべきでないかを判断するメカニズムを設計できないか、という点です。現在の論文では、単純に内部知識を私たちのコンテキストにそのまま入力し、大規模モデルに最終的な回答を生成させているにすぎません。今後はエントロピーに基づくメカニズムを用いて、内部知識を使うかどうかを制御できるかもしれません。エントロピーは大規模モデル自身の不確実性を反映するものだからです。二つ目は、TrustRAGを、ツールを活用する拡張型の大規模モデルにおける悪意のあるツールへの防御にも適用できないか、という点です。これは、本日ここにいる多くの発表者が言及されているように、多くの大規模モデルによるエージェントが、低リスクなタスクをこなすためにツールを活用しているためです。そして三つ目は、これをファクトチェックのシナリオにも適用できないか、という点です。ファクトチェックのシステムは、インターネット上のニュースを活用して回答を生成するという点で、RAGシステムと類似した構造を持っているためです。以上が私からの発表内容です。ご清聴ありがとうございました。
5. データを渡さず賢くなる ― FedAgentが実証する連合学習の可能性
5.1 秘密を明かさず学ぶエージェント ― FedAgentの仕組みと実験場
本日は、私の同僚との共同研究であるフェデレーテッド・エージェント強化学習のフレームワーク、FedAgentについてご紹介します。私たちが研究しているのは、ユーザーのプライベートなデータを共有することなく、強力なエージェントをどのように協調的に学習させられるか、という問題です。AIエージェントは今や、ウェブベースのシステムから、仮想環境あるいは物理環境で展開される組み込み型エージェントに至るまで、幅広く展開されており、意思決定・行動・環境との継続的なやり取りを行っています。そのため、実世界のデータから学習することの重要性はますます高まっています。現代のAIエージェントの学習は、典型的にはクローズドループの構造を持ち、エージェントは状態を観測し、行動を取り、フィードバックを受け取ります。しかし、このプロセスは通常、大量のユーザーとのやり取りデータ、たとえばタスクのクエリや行動の軌跡といったものへの中央集権的なアクセスに依存しており、こうしたデータはしばしばプライバシーの観点から機微なものです。したがって、ここで重要な問いが生まれます。それは、データを中央集権化することなく、ユーザーのデータプライバシーを保護しながらエージェントを学習させることはできるのか、という問いです。データを中央集権化することは効果的ではありますが、実世界のアプリケーションにおいてはしばしば受け入れがたいものだからです。
FedAgentは、分散されたクライアント全体にわたって協調的な機械学習を可能にすることで、この課題に取り組みます。各クライアントはデータをローカルに保持し、各通信ラウンドではモデルの更新のみが共有されます。サーバーは現在のグローバルモデルを選ばれたクライアントに送信し、各クライアントはそれぞれ自身のプライベートなデータを用いてローカルで学習を行い、更新されたモデルを返送します。サーバーはこれらのクライアントの更新を、典型的には平均化することによって集約し、新しいグローバルモデルを生成します。この更新されたモデルは、次のラウンドのために再び配布されます。これは標準的なフェデレーテッドラーニングのパイプラインに従うものです。しかし、従来のフェデレーテッド強化学習が、しばしば低次元の状態とシンプルなタスク、そして単純な環境とのやり取りを前提としているのに対し、FedAgentは自然言語による状態空間・行動空間の上で動作し、多様なタスク形式と複雑で多段階のやり取りを扱う点が異なります。
このような追加された複雑さを踏まえると、重要な問いが浮かび上がります。それは、こうした現実的な、言語ベースのエージェントタスクに適用した場合でも、フェデレーテッドラーニングは依然として有効なのか、という問いです。まず理論的な観点から、私たちはFedAgentが、標準的な滑らかさの条件とPL条件(Polyak-Łojasiewicz条件)のもとで、最適解の近傍へと収束することを示しました。そして実証的な観点からは、フェデレーテッド・エージェント強化学習の有効性を研究するために特別に設計した、分散型のエージェント学習環境であるFedAgentGymを導入しました。このFedAgentGymは、異なるファミリーや異なる規模の複数の大規模モデルによるエージェント、たとえば複数サイズのチャットモデルやその他のモデルをサポートしており、実世界のシナリオに焦点を当てた環境、たとえばWebShopやAirbnb(空港を含むシナリオ)を対象としています。これらのシナリオでは、データプライバシーが非常に重要であり、かつタスクには強力な推論能力と多段階のやり取りが求められます。
FedAgentGymを用いることで、私たちは分散環境における重要な設定、たとえばクライアントあたりのサンプル数、ラウンドあたりの参加クライアント数、そしてローカルの学習ステップ数といったものを検証し、体系的な分析を可能にしています。また私たちは、フェデレーテッド・エージェント学習において自然に生じる、三つの現実的なクライアント異質性の形態をモデル化しました。すなわち、クライアントごとにタスクの選好が異なる「選好異質性」、クライアントごとにタスクのサンプリングスコアが異なる「カバレッジ異質性」、そしてクライアントごとにタスクの難易度が異なる「難易度異質性」の三つです。こうした異質性は、フェデレーテッド・エージェント学習のパラダイムにおいて自然に発生するものであり、学習ダイナミクスに大きな影響を与える可能性があるため、これらを検討することは不可欠です。ここで重要な問いは、こうした各形態の異質性がFedAgentに与える影響を、どのように制御可能な形で研究できるかということです。
そこで私たちは、三種類のクライアントデータ分割戦略を提案し、これによって異質性が学習に与える影響を、それぞれ切り分けて検証できるようにしました。まず選好分割は、単一のパラメータであるオメガを用いて、他の要素を固定したままクライアントごとのタスク選好を制御するものです。このプロットが示すように、オメガを大きくしていくと、クライアント間のタスク分布がより均一になっていく様子が確認できます。これによって選好の異質性を単独で切り分けて検証することが可能になります。次にカバレッジ分割は、ベータ分布に基づいており、パラメータCによってクライアントのタスクカバレッジがどれだけ偏っているか、あるいは狭いかを制御します。Cを変化させることで、非常に偏った状態からほぼ均一なタスクカバレッジの状態まで移行させることができ、カバレッジの異質性についての制御実験を可能にします。そして難易度分割は、タスクを成功率によって分離し、同様にベータ分布のもとで割り当て、C´というパラメータによって制御されます。この図は、C´が成功率の分布をクライアント間でどのように制御できるかを示しています。
5.2 バラバラでも辿り着く ― 異質性を乗り越える3つの発見
こうしたFedAgentGymの設定に基づいて、私たちはいくつかの研究課題を設定しました。一つ目の研究課題は、FedAgentは中央集権型のエージェント学習と比較して遜色ないのか、というものです。私たちはFedAgentと中央集権型学習を、複数の環境にわたって直接比較しました。その結果、FedAgentは、生のクライアントデータに一切アクセスすることなく、中央集権型学習に匹敵する性能を達成できることがわかりました。また同時に、ローカルのみでの学習を一貫して上回ることも確認されました。これは、協調的な学習がもたらす効果を実証するものです。学習のダイナミクス自体は中央集権型手法とフェデレーテッド手法とで異なるものの、最終的には同様の成功率へと収束することが確認されました。したがって、一つ目の重要な発見(テイクアウェイ)は、FedAgentが中央集権型のエージェント学習に匹敵し、ローカルのみの学習を大幅に上回るということです。
二つ目の研究課題は、異なる分散環境の設定がどのような影響を与えるのか、というものです。私たちは、さまざまな分散設定に対してFedAgentがどれほど敏感であるかを分析しました。その結果、FedAgentはクライアントあたりのサンプル数に対しては比較的鈍感である一方で、ラウンドあたりの参加クライアント数に対してはより敏感であり、特にAirbnbのシナリオにおいてその傾向が顕著であることがわかりました。また、FedAgentはローカルのエポック数に対しても敏感であることが確認されました。したがって、二つ目の重要な発見は、最適な分散設定は環境に依存するものであり、一律にすべてに当てはまる万能の設定は存在しないということです。
三つ目の研究課題は、異なる異質性の課題がどのような影響を与えるのか、というものです。私たちは、異なる異質性のレベルが学習の結果にどのように影響するかを研究しました。緑の線は高い異質性を、青の線は低い異質性を示していますが、いずれの場合においても、FedAgentは最終的には異質性の設定にかかわらず、類似した成功率へと収束していくことが観察されました。したがって、三つ目の重要な発見は、FedAgentはエージェント特有の異質性に対して頑健であり、これが実世界のフェデレーテッド・エージェントシステムにとって実用的なものであることを示しているということです。ご清聴ありがとうございました。
6. 予算1000ドルの壁 ― AI旅行プランナーはなぜ約束を守れないのか
6.1 「近未来の定番アプリ」に潜む制約充足の落とし穴
私は南京大学のLangaグループから参りました。本日は、私たちの研究「信頼できるエージェントへのギャップを埋める(Mind the Gap to Trustworthy Agents)」について、特に旅行計画というドメインに焦点を当ててご紹介します。まず、旅行アプリケーションにおけるエージェント型AIの現状について概観することから始めたいと思います。私たちが確認したところ、Googleをはじめとする大手プレイヤーや、Deep Researchのようなリサーチ系のサービス、そしてTrip.comのような旅行専門企業が、それぞれ独自のエージェント型旅行プランナーを構築しており、業界全体としても旅行計画は次世代AIにとって典型的なアプリケーションであり、格好の実験場であるというコンセンサスが形成されています。典型的なエージェント型旅行プランナーでは、ユーザーが自然言語で旅行の要件を提示し、エージェント型の旅行プランナーはPOI(Point of Interest、観光スポット等の情報)を収集した上で、最終的にユーザーの要件を満たす旅行プランを作成しようとします。
旅行計画における制約の指定には、三つのレベルがあると私たちは考えています。まず一つ目は、プランナーが有効な情報を提供する必要があるというレベルです。たとえばフライトが実在し、有効なものでなければならない、というものです。二つ目は、プランナーがユーザーの意図を理解する必要があるというレベルです。たとえば「セントーサ島をシンプルに訪れたい」あるいは「地元の料理を試してみたい」といった要望を理解することです。そして最も難しいのが三つ目、制約の遵守というレベルです。たとえば「予算を1000ドル以下に抑えたい」というような要求をユーザーが示した場合です。現在の研究では、GPTのような最新のモデルであっても、複雑な制約充足を伴う旅行計画においては依然として性能が低く、成功率がほぼ0%に近い水準にとどまるということが明らかにされています。
私たちの研究は、この問題に体系的に取り組むフレームワークを提供するものです。まず、旅行計画のベンチマークの全体像を概観し、この領域における主要な課題を特定しました。そのうえで、旅行計画全体をより細かいモジュールへと分解し、それぞれのモジュールにどのような課題があるのかを明らかにするという、詳細なモジュール別の分析を行いました。具体的には、私たちは旅行計画全体を、まず「制約抽出」、つまり旅行プランナーがユーザーの訪問したい場所やその他の制約を理解し特定する必要がある部分と、次に「情報統合」、つまりエージェント型システムがフライト検索やホテル検索といったツール機能を呼び出して、適切なPOI情報を収集する必要がある部分と、そして「制約下の推論」、つまりPOI情報が与えられた上でエージェント型システムがユーザーの要件を満たす最終的な旅行プランを生成する部分の、三つに分解しました。
まず、既存の旅行計画ベンチマークの全体像を見ていきます。私たちはこれらを三つの観点から比較しました。一つ目は粒度の観点です。初期のベンチマークは日単位のスケジュールに焦点を当てていましたが、China TravelやCrafting Trip 2025のような最近の旅行計画ベンチマークは、詳細な場所や時刻を伴うイベントレベルの粒度に焦点を当てています。ここで見えてきた課題は、詳細な旅行プランに焦点を当てたイベントレベルのベンチマークに移行するにつれて、入力・出力それぞれのトークン数が大幅に増加していくという点です。実際、入力トークン数は600行にも達することがあり、これは現在の多くのモデルの入力ウィンドウの上限を超えてしまう水準です。二つ目の観点は情報統合です。従来のベンチマークがコンテキスト内の静的な情報に基づいていたのに対し、最近のいわゆるCH(China Travel系)ベンチマークは、ツールを用いた動的な情報のやり取りに焦点を当てており、40から50ステップにも及ぶツールとのインタラクションを伴います。これによって、新しいシステムはツールの実行やハルシネーションの管理といった課題にしばしば直面することになります。三つ目、そして最も難しいのがユーザーデータに関する観点です。2024年当時の典型的な旅行計画ベンチマークは、コストや観光地・ホテルの好みといった、テンプレート化された静的なデータに焦点を当てていました。しかし最近の旅行計画ベンチマークは、より関心をオープンワールドの指示へと移しています。つまり、ユーザーは単に予算を伝えるだけでなく、「初日の予算」というように、構成的な言語空間の中に埋め込まれた形で自分の要望を表現するようになっているのです。こうした構成的な目標空間は、エージェント型システムがユーザーの要求を正確に理解する上で大きな課題をもたらし、結果として性能の低下につながっています。
6.2 ニューロと記号の二人三脚 ― 制約を守り切るハイブリッド解法
ここから、モジュール別の分析についてお話しします。まず、制約抽出におけるギャップについてです。これは私たちが提供した中でも最も難しい部分であることがわかりました。左側の図が示すように、テンプレート化されたデータにおいては、GPT-5やDeepSeekのようなモデルがほぼ完璧な制約抽出を達成できることが確認できました。これは、これらのモデルが旅行の要件を十分に理解できることを意味しています。しかし、オープンワールドの指示、すなわち構成的な旅行要件を伴う指示に移行すると、性能に大きな低下が見られました。GPTやDeepSeekのようなモデルでも、制約理解においてはおよそ65%程度の性能しか達成できませんでした。つまり、大規模言語モデルはテンプレート化された要件に従うことは得意である一方、実際の人間の要求から生じる、未知の構成的な要件に対しては依然として苦戦しているということです。
二つ目は情報統合のギャップです。私たちは小規模な実験を行い、正解の制約が与えられた場合に、エージェント型システムがその特定の要件を満たすPOIを実際に抽出できるかどうかを評価しました。左側の図が示すように、選定されたPOIの数は、グラウンドトゥルースのPOI数よりも明らかに少ない結果となりました。これは、システムが保守的な傾向を持つことを意味していますが、それでもすべての制約を十分に特定しきれないという課題を抱えていることも示しています。つまり、選定されたPOIが依然として制約の指定を十分に満たせていない、という低い一致率が見られたのです。三つ目は、日単位の計画生成における粒度の問題です。たとえ正解の制約が与えられていたとしても、ワンパー・ビューのような大規模な推論モデルであっても、旅行計画において約10%程度の合格率しか達成できないことがわかりました。この発見は、たとえより大規模な推論モデルであっても、与えられた旅行制約のもとでの推論を行うことは依然として非常に困難であるということを明らかにしています。
それでは、どのようにしてこの課題を解決し、エージェント型システムが制約充足を達成できるようにするのか。私たちは、ニューロシンボリック・エージェントという方向性が有効であると考えています。ご存知の通り、ニューラルネットワークは精密な理解に長けており、記号的推論は制約充足に長けています。そこで私たちは、エージェント型システム全体の中に記号的な制約表現を組み込みました。具体的には、制約抽出の部分において、構成的な旅行要件を表現するために記号的な表現を用います。そして制約下での推論の部分では、記号的なソルバーを用いて、確実に制約を満たすプランを生成します。さらに情報統合の部分では、大規模言語モデルに制約を注入することで、制約を意識したメモリ管理を実現しています。
より具体的に言うと、私たちは、直接的なソルバーとしてではなく、いわば「トランスレーター」として大規模言語モデルを用いています。すなわち、自然言語で表現された旅行要件を、旅行特有の概念をコーディングした記号的な表現、いわばプログラムのようなインスタンス表現へと変換するのです。この表現空間では、たとえば「初日の夕食の予算を管理したい」といった構成的な言語空間上の要件も、すべて同じ表現空間の中で表現することができます。そのうえで、大規模言語モデルを用いて、この記号的な制約表現をSMT(充足可能性モジュロ理論)のコードへと変換し、SMTソルバーのようなソルバーを用いて最終的なプランを生成します。これによって、予算や時間といった制約の充足を保証することができます。もしこれら三つのソルバーが、現在保持しているPOIメモリのもとで有効なプランを生成できない場合、それはより多くのPOI情報を収集する必要があることを意味します。この段階では、私たちはツール呼び出しを用いてより多くのPOIを収集し、その情報を望ましい制約に紐づけて、正確なメモリ管理を実現し、与えられた制約のもとで選定されるPOIの精度を向上させています。
この結果として、私たちのニューロシンボリック・エージェントシステムは、合成データにおいて60%、オープンワールドの人間によるデータにおいて37%という成功率を達成しました。これは、従来のニューロシンボリックでないエージェントと比較して、大幅な改善を示すものです。最後に、私たちの体系的な評価から浮かび上がった、信頼できるエージェントにとっての重要なギャップについてまとめます。まず一つ目に主張したいのは、旅行計画は信頼性と制約充足を研究する上で優れたドメインであるということです。なぜなら、旅行計画には市場価値と学術的な挑戦の両方があるからです。二つ目に主張したいのは、ニューロシンボリック・エージェントが有望なアプローチであるということです。これは、ニューラルネットワークが持つ利点と、記号的推論が持つ利点を組み合わせることができるからです。具体的には、言語による指示に対する理解を向上させるために大規模言語モデルを用い、制約充足の質を向上させるために記号的推論の部分を用いることができます。そして三つ目に主張したいのは、この分野においてオープンワールドのベンチマークが非常に重要であるということです。たとえば、大規模かつ実際の人間の要求に対して形式検証を伴うChina Travelのようなベンチマークは、私たちのコミュニティに実世界の課題をもたらしてくれるものです。ご清聴ありがとうございました。
7. 栄誉の瞬間 ― ワークショップアワード授賞式
7.1 最優秀論文から口頭発表賞まで、輝いた研究たち
本日の発表セッションはこれにて終了となりますが、続きまして、私たちのワークショップ「エージェントAIをどう信頼し、どう制御するか」の表彰式に移らせていただきます。まず初めに、質の高い論文をご投稿くださったすべての著者の皆様、そして丁寧かつ洞察に満ちたコメントをくださったすべての査読者・委員会メンバーの皆様に、心より御礼申し上げます。
それでは早速、賞の授与に移りたいと思います。まず、ASA/ASUセンター・フォー・フロンティアAIリサーチのセンターディレクターを務める教授に壇上にお越しいただき、著者の皆様へ賞を授与していただきます。全部で三つの賞をご用意しております。まず一つ目、ベストペーパー賞は、論文「Federated Agent Reinforcement Learning(フェデレーテッド・エージェント強化学習)」に贈られます。おめでとうございます。二つ目、優秀論文賞は、論文「Mind the Gap to Trustworthy Agents(信頼できるエージェントへのギャップを埋める)」に贈られます。おめでとうございます。そして三つ目、応用論文賞は、論文「Reflection-driven Control for Trustworthy Agents(信頼できるエージェントのための反省駆動型制御)」に贈られます。おめでとうございます。
続きまして、発表賞の授与に移らせていただきます。ここで、名誉ゲストとしてお越しいただいているテンセントAIクラウドのDr. Leinをお迎えし、発表者の皆様へ賞を授与していただきたいと思います。まず、第一回口頭発表賞は、感度最小化によるブラックボックス最適化についてご発表いただいたPSMの発表、Jose氏に贈られます。おめでとうございます。二つ目、第二回優秀発表賞は、行動木における軽量かつ忠実な視覚的条件トラッキングについてご発表いただいたSeamoon氏に贈られます。おめでとうございます。三つ目、第三回優秀発表賞は、Webエージェントにおける分散プライバシー制御を扱った「エージェントフロー・エージェンシー」のご発表について、Hen氏に贈られます。おめでとうございます。
続いて、第四の発表賞は、真実性と頑健性・信頼性を扱った、メッセージ生成の頑健性と信頼性についてのご発表に贈られます。おめでとうございます。そして第五の発表賞は、先ほどベストペーパー賞にも選ばれた「Federated Agent Reinforcement Learning(フェデレーテッド・エージェント強化学習)」の発表に贈られます。おめでとうございます。皆様、あらためて受賞おめでとうございます。
Dr. Leinには、賞の授与にご協力いただき誠にありがとうございました。以上をもちまして、本日のワークショップの全プログラムを終了とさせていただきます。この後はポスターセッションとなりますので、ぜひ会場外に設置されているポスターボードの方へお運びいただければと思います。いくつかのポスターが展示されておりますので、お時間の許す限りご覧いただければ幸いです。本日は一日、誠にありがとうございました。
