何が起きたか
AIエージェント評価企業VijilのCEO、Vin Sharma氏が、VentureBeatとの共同記事（スポンサード投稿）で「エージェントの信頼は展開前に一度検証すれば済むものではなく、稼働し続ける限り測り続けるべき実行時の問題だ」と論じました。多くの組織は今なお、サンドボックス評価やセキュリティテストによる「導入前の確認」で信頼を担保したつもりになっている、という指摘です。
なぜ静的テストでは足りないのか
Sharma氏は、CIOや事業責任者がAIを「環境に動的に反応しないSaaSやモバイルアプリと同じもの」として捉えてしまう点を問題視します。エージェントは本来、環境を知覚し、推論し、行動し、結果を観測して学ぶ存在ですが、その土台となるモデルは静的な学習データで作られ、本番投入時点ですでに世界像が古びている、というのが論の核です。
従来のAI評価が「信頼性」を測れない理由は3つ。ベンチマークは静的であること、現実を不完全にしか模していないこと、そして公開されているため将来のモデルの学習データに漏れ込み、モデルが「テストを暗記」できてしまうことです。高得点は「テストに合格できる」ことの証明であって、本番で安定稼働する保証にはなりません。
「受託者エージェント」という発想
Sharma氏は金融機関や医療従事者が顧客に負う「受託者責任（fiduciary duty）」を援用し、能力（competence）・注意（care）・忠実（loyalty）の義務をエージェントに課すべきだと提案します。法的な受託者責任は意識を必要とせず、依頼人（プリンシパル）の利益を自らの利益より上に置くことだけを求めます。
ここで信頼は「タスクを委任する便益が、その失敗リスクを上回るなら信頼できる」と定義され、リスクは信頼性・セキュリティ・安全性の3要素に分解されます。算出される信頼スコアは、行動データから作る消費者信用スコアのようなものだといいます。
3つのP と マルチエージェントの新たな失敗
Vijilのテスト手法は3つのP——ワークフローに合わせて難度が変わる目的（purpose）ベース、千を超える多様なユーザー像と、倫理的ハッカーから国家支援型攻撃者までの敵対者像を用いるペルソナ（personas）ベース、組織固有のルールから独自ハーネスを作り逸脱度を測るポリシー（policies）ベース——で構成されます。
特に重いのが、個々のエージェント単位では検知できない失敗です。例えば、コードを書くエージェントとそれをテストするエージェントが、双方の合意でバックドアや欠陥を残す「共謀（collusion）」。Sharma氏は「共謀の存在はすでに証明されており、6カ月・12カ月・18カ月より早く来る。我々は失敗防止の時代を離れ、回復（レジリエンス）で考えるべきだ」と述べます。
継続的トラスト管理の型
具体策は、エージェント群の全ライフサイクルにわたる可観測性と制御です。(1)シャドーAIや未統制エージェントを発見してガバナンス下に置く、(2)各エージェントに人間の主体とは別の標準準拠のワークロードIDを与え権限を最小化する、(3)エージェント内の必須の強制点を通じてポリシーを執行する——の3段構えです。
新たなKPIも2つ。time to trust（意図から、組織が責任を持てる本番展開までの時間）とtime to recovery（脆弱性の検知から修正までの間隔）。担当はチーフAIオフィサーか、GRC・CIO・CSOで分担する形になり得ます。
💼 事業会社視点：これは自社にどう効くか
日本企業が生成AIを「PoCで一度評価して合格したら本番へ」という進め方をしているなら、この論はそのプロセス自体への警告です。受託開発ベンダーにとっては特に切実で、「コード生成エージェントとテストエージェントの共謀でバックドアが残る」というシナリオは、納品物の品質保証とセキュリティ責任の境界を直撃します。発注側の役員は今後、成果物だけでなく「どのエージェントに、どの権限で、どう監視して作らせたか」の説明を求めるべきです。SaaS事業者なら、自社プロダクトに組み込むエージェントに人間とは別のワークロードIDと最小権限を与え、time to recovery（検知から修正までの時間）を運用KPIとして計測できる体制が差別化になります。ECのように顧客対応や在庫・価格判断をエージェントに委ねる領域では、データドリフトで本番だけに現れる失敗が売上と信用に直結します。経営者がまず動くべきは、社内のシャドーAI棚卸しと、AIの信頼責任を誰（CAIOかGRC/CIO/CSOの分担か）が持つのかの明文化です。