【ITニュース解説】Fresh Context Is Not Enough: An Agent Action Needs a Valid Chain Back to Its Decision

AIエージェント、つまり自動的にタスクを実行するプログラムの信頼性を確保することは、これからのシステム開発において非常に重要な課題となる。多くの人は、エージェントが常に最新の情報を参照していれば、うまく連携して動くと考えがちだが、実際にはそれだけでは不十分であることが明らかになってきている。エージェントがある行動を起こすとき、その行動が最初に決定された根拠、つまり「なぜその行動が必要と判断されたのか」という正当性の連鎖が、今も有効であるかを厳密に確認する必要があるのだ。

最近の研究では、この一般的な考え方に疑問を投げかけるいくつかの課題が指摘された。一つ目は、「新鮮な情報と古い計画」の問題である。エージェントが最新のデータを受け取っていたとしても、そのデータに基づいて立てられた計画自体は、過去の古いデータに基づいている場合がある。例えば、あるエージェントが「要件r3」という情報に基づいて「計画P3」を立てたとしよう。その後、システム内の要件が「r4」に更新され、エージェントはこの最新情報「r4」を正しく認識している。しかし、エージェントは依然として古い「計画P3」を実行しようとすることがある。エージェントの「記憶」は最新でも、「計画」が古いままになってしまうのだ。この問題を解決するために、「PlanFence（プランフェンス）」というプロトコルが提案されている。これは、計画が実行される前に、その計画が依存している特定のデータ（公開記録）だけをチェックし、もし関連するデータが変更されていれば、計画を再評価したり、実行を一時停止したりするという仕組みだ。CRMのメモが変更されても、調達の決定には影響しないかもしれないが、ベンダー承認に利用したプライバシー評価の有効期限が切れていれば、調達は無効になる可能性がある。このように、すべての情報を再検証するのではなく、関連する依存関係だけを効率的に確認する点が重要となる。

二つ目の課題は、「現在の情報が必ずしも正しいとは限らない」という問題だ。エージェントは、検索エンジンやコードインタープリターなどの「ツール」から得た情報を、自動的に「権威ある証拠」として過度に信頼してしまう傾向がある。研究では、意図的に改ざんされたツールの出力をエージェントが約3分の1以上の確率で採用してしまうことが示された。さらに興味深いのは、エージェントの内部的な思考プロセスでは矛盾に気づき、正しい答えを導き出しているにもかかわらず、最終的な行動として改ざんされたツール結果を採用してしまうケースも見られたことだ。これは、エージェントが問題に気づくための情報を持っていても、その問題をどのように解決するかという明確なルールがシステムにないことを示唆している。「ツールがXという情報を返した」という事実と、「Xが信頼できる正しい証拠である」という事実は、全く異なるものと考える必要がある。情報の「鮮度」と「信頼性（権威性）」は別々の性質なのだ。

三つ目の課題は、「行動を起こすための権限」がエージェントの直接管理する範囲の外にある場合があることだ。エージェントが自分の作業空間にあるすべての情報にアクセスできたとしても、実際に何かを公開したり、承認したり、変更したりする最終的な権限は、別の専門的なシステムやサービス（例えば、権限を管理するデータベースや承認システム）に存在する。単にエージェントに権限情報を「見せる」だけでは不十分で、実際にアクションを実行する際には、その権限が有効であるかを厳密にチェックする仕組み（ガード）が不可欠だということが示されている。

これらの課題は、エージェントの行動を信頼性高く制御するためには、複数の異なる側面を分離して考える必要があることを意味している。具体的には、「今どのような情報が利用できるか」「その情報に基づいてどのような決定が下されるべきか」「既存の計画が今も正当なものか」「このエージェントがその行動を実行する権限を現在持っているか」という四つの問いを、それぞれ独立した層として扱うことが求められる。単一のAIモデルがこれらすべての問いに対する最終的な判断を下すべきではない。

実際、私たちの生活に密着した分野では、この分離の考え方がすでにインフラとして構築され始めている。例えば、VisaやMastercardといった決済サービスを提供する企業は、エージェントの身元確認や、特定の取引を行うための委任された権限を、決済システムの一部として扱おうとしている。これは、支払い能力があるエージェントが必ずしもビジネス上の承認を持っているとは限らないし、その逆もまた然りである、という重要な区別を明確にする動きだ。また、SalesforceやRed Hatのような大手IT企業も、エージェントを発見し、その身元とポリシーを確立し、ライフサイクルを管理し、行動を評価し、結果を監視し、コストを制御するための「AIコントロールプレーン」と呼ばれる独立したプラットフォームを構築している。これは、エージェントの統制や管理が、単なる機能の一つではなく、専門のインフラ市場として発展していることを示している。

このような背景から、エージェントシステムを設計する際には、役割を明確に分離したアーキテクチャが推奨される。情報の「取得」、それに基づく「組織的な判断」、その判断を元にした「計画の策定」、そして計画を実行するための「実行時の承認」、最後に「実際の実行」というプロセスをそれぞれの層で担当させるのだ。ツールのセキュリティに関するポリシーはツールの実行に近い場所で、支払いの上限額は決済システムの中で、エージェントの身元確認は身元管理システムの中で、といった具合に、それぞれのルールを最も適切な場所で管理すべきである。これらのルールを全て「組織の判断」という単一の層に詰め込むべきではない。

「組織的な判断」の層が担当するのは、利用可能な証拠と、組織があらかじめ定めた基準やポリシーに基づいて、最終的な「決定（disposition）」を下すことである。例えば、「プライバシー評価が期限切れ」「年間支出が42,000ドル」「セキュリティ状況は合格」といった証拠から、「レビューが必要」という判断を下すといった具合だ。この決定結果が、後続の計画の依存関係の一つとなる。そして、実行時の承認は、この判断とは別に、独立して行われる。

最も難しい課題は、このように分離された「決定」と、そこから派生する「行動」とをしっかりと紐付けることだ。ある決定が「承認された」という結果を出し、それに基づいてエージェントが購入計画を作成した場合、その計画には「どのポリシーのどのバージョンがこの決定を生んだのか」「どの証拠が重要だったのか」「どの証拠源が権威あるものだったのか」「いつこの決定が評価されたのか」「この決定がどの行動を正当化するために下されたのか」といった情報が、実行前に検証可能な形で含まれているべきである。実行時には、すべてのプロセスを最初からやり直すのではなく、この行動を無効にする可能性のある特定の依存関係のみをチェックすれば良い。これは前述のPlanFenceの考え方を、組織の意思決定の領域に適用したものと考えることができる。

人間が関与するレビュープロセスも、単に一時的な「ポップアップ表示」としてではなく、永続的な「ワークフローの状態」として扱うべきである。つまり、「レビューが必要」という判断が下された場合、それはレビューアイテムとして永続的に記録され、関連する証拠や決定までの道のりも保存され、権限を持つ人間によるアクションが完了するまで待機するような仕組みが望ましい。

さらに、エージェントシステムの「評価」自体も、多層的に考える必要がある。モデルが正しいツール呼び出しを発しても、システムインターフェースや解析の不具合でそれが「消えて」しまい、評価結果には「ツールが使われなかった」と誤って記録されることがある。これは、モデルの評価、インターフェースの検証、実行軌跡の整合性、そしてベンチマーク自体の整合性といった複数の層が正しく機能して初めて、評価結果が意味を持つことを示している。

最終的に、エージェントシステムが直面する次の大きな信頼性の問題は、単に「エージェントが十分な情報を記憶しているか」という問いではなく、あらゆる重要な行動が、「その行動を今この瞬間に正当化する、具体的な証拠、方針、権限、そして決定は何か」という、より深い問いに答えられるかどうかにある。単に最新の状況だけを見るだけでは、もはや十分ではないのだ。