【ITニュース解説】Your customer's agent is untrusted by definition

近年、AI（人工知能）技術の進化により、ユーザーが自ら選んだAIエージェントを使って様々なサービスを利用したいというニーズが高まっている。これは、従来のサービス提供者が開発したAIアシスタントを利用するだけでなく、ユーザー自身が持つAIエージェントに、外部のサービスと連携させて自分のタスクを処理させたいという要望を指す。この動きは、システム開発の現場において、セキュリティとコンプライアンス（法令遵守）の考え方に大きな変化を促している。

これまでのAI関連のシステム設計では、多くの場合、サービス提供者側がAIモデルを構築し、その振る舞いや安全性を管理することを前提としていた。例えば、AIに不適切な行動をさせないための指示（システムプロンプト）を設定したり、出力される情報にフィルターをかけたり、特定の状況での拒否反応を細かく調整したりするなど、AIそのものを制御するための様々なツールが使われてきた。しかし、ユーザーが自分のAIエージェントをサービスに接続する場合、この前提は根本から崩れる。

なぜなら、ユーザーが持ち込むAIエージェントの「中身」は、サービス提供者からは全く見えないからである。どの種類のAIモデルを使っているのか、そのバージョンは何か、どのような指示を与えられているのか、他のどのようなシステムと連携しているのか、さらにはAIの背後にいる人物が本当に名乗っている通りの人物であるのか、といった情報は一切分からない。明日には全く異なるモデルに切り替わっている可能性すらある。このような状況下では、ユーザーのAIエージェントが生成する出力は、本質的に「信頼できない入力」として扱わざるを得なくなる。これまでのシステム設計では、この「信頼できない入力」という考え方は特定のチームのデザイン方針に過ぎなかったが、ユーザーエージェントが当たり前になる世界では、これは避けられない現実となる。

もしAIモデルそのものを制御できないのであれば、次に制御すべきは、そのAIエージェントがシステム内で「何にアクセスできるか」「何を実行できるか」という範囲になる。つまり、問題意識は「どうすればAIエージェントを安全に振る舞わせられるか？」から、「このAIエージェントは、どのような条件下で、どのような操作を許可されているのか？ そして、その操作の記録はどのように残るのか？」へとシフトする。

具体的なシステム設計の例として、外部のAIエージェントを受け入れるワークショップ管理ソフトウェアのケースを見てみよう。このシステムは自社でAIを提供せず、ワークショップが自前のAIエージェント（AIアシスタント）を接続する仕組みを採用している。ここでは、AIエージェントの制御に関して、六つの重要な要素が設計されている。

第一に、「スコープ付きID」である。これは、AIエージェントがシステムに接続する際に使う認証情報（トークン）が、どのワークショップによって発行され、どの程度の権限を持つのか、有効期限はいつまでか、そしていつでも無効にできるか、を明確にする。

第二に、「宣言されたアクション」である。これは、AIエージェントが実行を許可されている具体的な機能や操作のリストを指す。例えば、顧客情報の閲覧、予約の登録、見積書の作成など、数十種類以上の細かなアクションが定義され、アクセスレベルによって許可される範囲が異なる。

第三に、「禁止された動詞」である。これは、AIエージェントが「絶対に実行してはならない」操作を明示的に指定する。例えば、顧客への直接的な連絡、支払いの記録や返金、最終的な承認、顧客や車両、作業指示書などの重要なデータの削除といった操作は、エージェントには決して許可されない。

第四に、「人間の承認」である。これは、AIエージェントが実行しようとする操作の一部について、必ず人間の最終確認や承認を必要とする仕組みである。例えば、エージェントが見積書の草案を作成しても、最終的に顧客へ送信する際には必ず人間が内容を確認し、承認しなければならない。

第五に、「データ境界」である。これは、AIエージェントがアクセスできるデータの範囲を制限する。例えば、製品の原価情報や仕入れ先に関する機密性の高い情報は、特定の高いアクセス権限がなければエージェントから隠され、見ることができないようになっている。

第六に、「記録」である。これは、AIエージェントがシステムに対して実行した、あるいは実行しようとして拒否されたすべての操作について、その詳細な履歴をすべて記録に残すことである。これにより、何か問題が発生した際に、AIエージェントがどのようなアクションを取ろうとしたのかを追跡できるようになる。

これらの制御は、ユーザーのAIエージェントがどのAIモデルを使っているかに関わらず機能する。しかし、この設計にはコストも伴う。これは特定の製品ドメインに合わせて、一つ一つのアクションや前提条件、承認プロセスを手作業で設計し、実装する必要があるため、他の企業が顧客エージェントを受け入れる際にも同様の作業が求められることになる。

さらに、「記録」に関しては、一見すると十分な制御に見えるが、実はまだ課題がある。サービス提供者側が記録し、保管し、場合によっては編集できてしまうログは、提供者側にとっての証拠にはなるものの、顧客や規制当局が「このログが完全で、かつ改ざんされていないことを、提供者の言葉を信じる以外にどうやって確認できるのか？」という問いには答えられない。顧客のAIエージェントによって何らかの損害が生じた場合、その原因や責任の所在を巡って争いになった際、自社が管理するデータベースのログだけでは、提供者自身が運営者でありながら監査者も兼ねる形となり、客観的な証拠としては不十分となる可能性がある。

この問題の解決には、第三者が独自に検証できるような記録の仕組みが必要となる。例えば、ブロックチェーン技術のように、行われた決定が連鎖的に記録され、その削除や編集が検出可能であり、署名されたチェックポイントによって誰でもオフラインで確認できるような仕組みである。もし顧客自身が署名キーを保持していれば、サービス提供者を信頼することなく、記録の正当性を検証できるようになる。承認された操作だけでなく、拒否されたリクエストも同様に記録されるべきである。紛争時には、ブロックされたリクエストこそが最も重要な事実となることが多いからだ。

このような新しいセキュリティ要件は、特に規制の厳しい金融分野で最初に顕在化すると予想されている。例えば、ラテンアメリカの金融業界では、オープンファイナンスの進展により、顧客の同意があれば、規制された第三者が顧客の口座から支払いを開始することがすでに一般化している。しかし、顧客のAIエージェントは、登録も認定もされておらず、その振る舞いを予測することもできない新たな第三者である。もし未知のAIエージェントが誤って送金したり、不正な請求を行ったりすれば、金融機関は大きなインシデントに直面し、規制当局からの厳しい追及を受けることになるだろう。「なぜ私のアシスタントがあなたのアプリで支払いができないのか？」という顧客からの要望に対し、十分なセキュリティ設計がないまま対応してしまうと、数ヶ月後には「あの時、一体何が起こったのか？」というコンプライアンス上の問いに答えられなくなり、最終的にはサービスを閉鎖せざるを得なくなる事態を招きかねない。

これまでに述べた六つの制御要素は、どの業界や製品においても共通して適用できるパターンを持っている。異なるのは、具体的にどのようなアクションが存在し、それぞれに何が必要で、どの操作に人間の承認が必要か、そして何が制限の対象となるかという中身だけである。このことは、これらのルールを、個々のコードの断片としてではなく、「宣言（declaration）」という形で定義すべきだという強いヒントを与えている。

ルールを宣言として記述すれば、実際にシステムが稼働する前に、コンプライアンス部門によるレビューが可能となり、ルールに対するバージョン管理も行えるため、変更点も明確に追跡できる。自社のAIアシスタント、顧客のAIエージェント、あるいは通常のAPIクライアントのいずれから行われる書き込み操作であっても、すべてが同じ「宣言されたルール」という決定的なゲートを通過するようになる。AIはあくまで提案を行うだけで、最終的な判断は契約（宣言されたルール）によって下され、その実行はシステムが強制する。そして、ルールがバージョン管理されているため、行われた決定がどのバージョンのルールに基づいてなされたかを明確に記録できる。

このようなアプローチは、AIエージェントが契約によって宣言された範囲内でしか書き込み操作を行えず、そのゲートでのすべての判断（拒否を含む）が、どのバージョンの契約によって決定されたかが連鎖的に記録され、署名されたチェックポイントによってオフラインでも検証可能となるランタイム環境の構築を目指している。顧客が署名キーを保持することで、サービス提供者を信頼せずに検証できる仕組みも視野に入れられている。