顧客情報を扱うAIエージェントに、過去の判断に引きずられないよう履歴の一部を削除させます。処理が完了したという回答を受け取り、次の業務へ進めたとしても、後の質問でその情報が再び現れたらどうなるでしょうか。企業が必要としているのは、指示を出した記録だけではありません。指示どおりの状態になったと確認できる証拠です。

英国・北アイルランドのクイーンズ大学ベルファスト（QUB）が提供する論考は、この問題をAIエージェントの信頼性をめぐる出発点に据えています。複数のエージェントを統括役のオーケストレーターが管理し、リスク評価や顧客分析、マッチングなどを進める仕組みでは、判断に使う履歴の管理が欠かせません。過去の情報が同じ結論へ誘導し続けることを避けるため、履歴の影響を取り除くチェックポイントを設ける考え方が示されています。



問題は、そのチェックポイントを通過した事実だけで、情報が利用できなくなったと断定できるかという点です。QUBは、削除されたはずの情報を後続の指示で引き出す「コンテキスト回復攻撃」を懸念しています。これは、モデルが学習済みの知識をすべて消去できるかという話とは区別する必要があります。業務中に渡した情報がどこに残り、どの経路から再び参照されるかという、システム全体の管理の問題も含むためです。

企業の設計に置き換えると、会話から情報を外すこと、保存先から削除すること、別のエージェントから参照できなくすることは、それぞれ確認すべき対象が異なります。「忘れてください」という指示への応答だけで処理を完結させず、何を削除対象とし、どの状態をもって完了とするかを決める必要があるでしょう。信頼の議論は、この具体的な確認から始まります。

ゼロトラストは、相手が社内にいる、以前に認証した、といった理由だけでアクセスを信用せず、その都度必要な確認を行う考え方です。AIエージェント同士のやり取りにも、この考え方を適用できます。ただし、確認の仕組みを置けば信頼の問題が消えるわけではありません。QUBが問いかけているのは、確認を担う構成要素そのものを、どのように信頼するかという問題です。

論考で取り上げられているPEPは、Policy Enforcement Pointの略で、アクセス制御などの方針を実際の通信や操作に適用する部分を指します。たとえば、あるエージェントが顧客情報を取得してよいかを判断した結果に従い、アクセスを許可したり遮断したりします。この仕組みには、方針が適切であり、適用処理も正しく動作するという前提が必要です。



QUBは、単一の実施主体にあらゆるエージェント間のやり取りを任せ、規模の拡大にも対応できると期待することに疑問を示しています。この指摘は、PEPという機能自体が不要だという意味ではありません。特定の実装や共有基盤に制御を集中させたとき、その停止や侵害がどこまで波及するかを評価する必要があるという問題提起として読めます。

導入側が確認したいのは、製品説明にゼロトラストという言葉があるかどうかよりも、どの要求を、どの情報に基づいて検証しているかです。権限の変更が反映されるまでの間や、検証サービスに接続できない場合の動作も対象になります。通常時の許可と拒否だけを見ていては、障害時に業務を止めるのか、一定の操作を続けるのかという設計判断が見えません。信頼を完全に取り除くという抽象的な目標より、残っている前提を具体的に把握するほうが、企業の判断につながります。

QUBは、エージェントによるオーケストレーションを用いた内部実験で、認証解除攻撃を実行する速さが2〜3秒にまで達し得たと報告しています。認証解除攻撃は、接続している機器などを認証済みの状態から外し、通信を妨げる攻撃を指します。ここで注目したいのは数字の小ささだけではありません。人が通知を読み、状況を判断して対応するまでに、処理が進んでしまう可能性です。

ただし、この数値をあらゆる環境に共通する攻撃速度として扱うことはできません。提示された説明からは、実験環境、測定の開始点と終了点、試行回数などを確認できません。システム全体の侵害が必ず2〜3秒で完了するという結果でもなく、企業がそのまま自社の対応時間の基準に使うには情報が不足しています。実験は、攻撃の自動化によって対応の余裕が狭まる可能性を示すものとして受け止めるのが適切でしょう。



この問題から導ける実務上の示唆は、検知後の判断を速めるだけでなく、被害が広がる前に作用する制約を考えることです。たとえば、エージェントが利用できる操作の範囲や、異常を検知した際に停止できる単位を設計する方法が考えられます。これらはQUBの実験で効果が実証された対策ではなく、短い反応時間を前提にした設計上の検討事項です。

未知の脆弱性を悪用するゼロデイ攻撃についても、同じ視点が必要です。既知の攻撃を防げることと、想定外の障害が起きても事業を継続できることは、評価する対象が異なります。共有する認証基盤やネットワークが使えなくなった際に、どの業務が止まり、どこまで影響を切り離せるのかを確認したいところです。復旧策が用意されていても、その実行に必要な基盤まで失われれば、想定した手順では動けないかもしれません。

複数のエージェントが同じ目的に向かっていても、常に同じ情報を同じタイミングで受け取るとは限りません。あるエージェントが処理を続ける間に、別のエージェントには新しい指示や権限変更が届くことも考えられます。QUBが扱う「非同期の自律性」は、こうした時間差を含む環境で、各主体がどのような前提で動いたのかを追跡する問題につながります。

ここでは、情報の内容だけでなく、その情報がいつ有効だったかも重要になります。説明のために、ある担当エージェントが取得した情報を、別のエージェントが後から利用する場面を考えます。その間に利用許可が取り消されていた場合、最初の取得記録だけでは後続の利用を正当化できません。個々の操作が単独では自然に見えても、連携全体として指示の変更を反映できているかは別に確かめる必要があります。



QUBは、追跡可能性を支える手段として、AIの構成要素を管理するAI部品表や、分散型台帳技術の活用を挙げています。AI部品表は、利用するモデルや関連する構成要素を把握するための管理情報として理解できます。分散型台帳は、記録の共有や改変の検知を支える選択肢です。ただし、記録を後から変えにくくすることと、記録された判断が正しいことは同義ではありません。何を記録するか、必要な情報が抜けていないかという設計は残ります。

もう一つの論点は、ある業務で適切に振る舞ったエージェントが、別の情報源や接続先でも同様に動くとは限らない点です。QUBはこれを「水平的な異常」という概念で取り上げ、識別方法などを今後の課題としています。企業の評価でも、単一の成功例から利用範囲を広げるのではなく、接続するシステムや扱う情報が変わったときの動作を確かめる必要があるでしょう。信頼の適用範囲を明示しなければ、限定的な評価結果だけが独り歩きしかねません。

自然言語で要望を伝え、AIにコードの生成や修正を任せる「バイブコーディング」は、QUBがリスクを考える例の一つです。論考では、信頼性を確認していない組織外の主体へコードベース全体を渡すことが、複数の領域にまたがる脆弱性の問題につながり得ると警告しています。これは、AIを使った開発全般で情報漏えいが起きるという断定ではありません。利用先やデータの扱いを確認しないまま、業務資産へのアクセスを広げることへの懸念です。

AIエージェントが別のエージェントを呼び出す環境では、直接契約したサービスだけを見れば済むとは限りません。QUBは、代理として動くエージェントを含め、関係する主体を追跡する必要性を指摘しています。処理を委ねるたびに、誰がどの情報へ接触し、どの結果を次の処理へ渡したかが見えにくくなれば、問題発生後に調べる対象も増えるでしょう。



このため、導入効果を評価する際には、作業時間の短縮だけでなく、停止や調査にかかる負担も検討する必要があります。QUBは、統制が弱い環境での短期的な便益に対し、障害後の回復コストが十分に解明されていないとしています。エージェントの誤動作が取引先や別の処理へ波及した場合、最初のエージェントを止めるだけでは対応が終わらない可能性があります。

日本企業で検討するなら、一つの業務を選び、入力から外部委託、結果の保存までの経路を描く方法が役立つと考えられます。その経路に沿って、処理の停止、資格情報の無効化、影響を受けた出力の特定ができるかを確認します。外部サービスの信頼性評価と、自社側で影響を把握できることは、両方が必要です。導入の速さを測るときに復旧の範囲も併せて示せれば、経営側は便益と負担を同じ業務単位で判断しやすくなります。

QUBの研究グループは、Cyber AI Hubという研究・産業連携の取り組みで、企業のエージェント活用や商用化に関わっています。その中で重視しているのは、導入規模、業務の流れにまたがる異常検知、攻撃を受け得る箇所の継続的な評価などです。定められた仕事を複数のエージェントに分担させる仕組みと、自律性の高いエージェントの仕組みの違いも、検討対象に挙げています。

実装面では、ログによる活動管理や、失効したトークンを管理する仕組みが紹介されています。トークンはサービスへのアクセスに使う資格情報で、失効管理は、その再利用などによる不正な操作を抑えるための要素になります。ただし、失効を記録したことと、関係するすべての処理で利用不能になったことは別の確認事項です。導入側は、管理機能の有無に加え、変更がどの範囲へ反映されるかを見たいところです。



QUBは、形式検証や、攻撃的な入力に対するモデルの頑健性も論点に挙げています。形式検証は、定義した仕様や条件に照らして性質を確かめる手法です。保証が得られる場合でも、その対象や前提を読む必要があります。モデル単体への評価から、外部ツールや権限管理を含む業務全体の安全性までが自動的に保証されるわけではありません。

企業が着手する具体的な一歩としては、導入予定の業務から「この顧客情報を今後使わない」といった指示を一つ選び、その指示が実行された証拠を最後までたどる方法が考えられます。どの主体が受け取り、どの保存先や後続処理へ反映され、反映できなかった場合に誰が判断するのかを確認します。情報を見落とした場合と、受け取った指示を守らなかった場合では、調べるべき原因も異なります。この区別を記録から説明できるかを、本番移行の判断材料にしてはいかがでしょうか。

Zero-Trust Agentic AI Architecture（IEEE Spectrum）

クイーンズ大学ベルファストが提供する論考です。実験に関する報告、研究上の問題提起、企業導入に向けた考察を区別して紹介しています。