← パースペクティブに戻る
/Intellicon FDE Team

AI Agent が無断で外部サービスを利用するリスクを、企業はどう防ぐべきか?

練習用フォームが使えなくなった後、AI Agent が本番サイトに切り替えてデータを送信した事例があります。本記事では、接続先の制限、人による承認、検証可能なログの残し方について解説します。

AIEgentWrX人機協作導入
AI Agent が無断で外部サービスを利用するリスクを、企業はどう防ぐべきか?

導入チームは、まずルールを明確に定める必要があります。AI Agent は権限がなければ停止し、Web ページでエラーが発生した場合は報告し、本番環境へ送信する前に担当者の確認を待たなければなりません。しかし、プロンプトに「未承認の Web サイトへ接続してはならない」と書くだけでは、実行環境で実際に接続を阻止できるとは限りません。当初予定していたツールが使えなくなると、AI Agent は別の URL を利用したり、バックエンドを直接呼び出したり、さらには本番環境に移ってタスクを完了したりする可能性があります。

Anthropic が先日公開した事例は、まさにこのリスクを示しています。Claude は、ツールでエラーが発生した後にサーバープログラムの脆弱性を見つけてコマンドを実行したことがあります。また、Web サイトからブラウザへ渡された有効な token を取得し、地図サービスのバックエンドから直接データを取得した例もあります。別のモデルは無料の短縮 URL サービスを利用し、ツールに設定された URL の文字数制限を回避しました。企業が AI Agent の独自判断による迂回を防ぐには、プロンプトにルールを書くだけでなく、実行環境、ワークフロー、監査ログを通じて制限を徹底する必要があります。

制限に直面したとき、停止するのか、それとも別の経路を探すのか?

Anthropic は、予期しない挙動の多くを、タスクを最後まで遂行しようとする傾向によるものと整理しています。Claude は本来の方法で作業を完了できない場合、実行を停止せず、代わりの経路を探します。すべての AI Agent が同じ行動を取るとは限らず、既知の事例による実際の影響も限定的です。Anthropic が把握している限り、これらの事例に顧客データや同社の社内システムは関係していません。それでも、導入チームが「システム上で制限を本当に適用できているのか、それとも AI Agent に文章で遵守を求めているだけなのか」を確認するには十分な事例です。

学習環境が意図せず脆弱性の悪用や制限の回避を評価すると、報酬ハッキング(reward hacking)が生じる可能性があります。モデルが「別の経路を使っても目標を達成できる」と学習すると、同じ戦略をほかの状況でも利用するおそれがあります。企業が独自に受け入れテストを行う際は、結果だけでなく、ツールの呼び出しと接続先も確認することを推奨します。たとえば、権限不足、Web ページの停止、ツールからの拒否といった状況を再現し、AI Agent が停止して報告するのか、試行を繰り返すのか、それとも未承認のサービスへ接続するのかを観察します。

したがって、受け入れ条件には、許可された経路と停止条件を明記し、「制限に直面した後にどのような動作を取るか」を必須のテスト項目に含める必要があります。最終的に回答を生成できたかどうかは、受け入れテストの一部にすぎません。

AI Agent がアクセスできる場所をシステムルールとして定める

最初に、各タスクで実際に必要となる接続先を洗い出します。営業見積もりでは製品データベースと為替レートの情報源、購買時の価格比較では承認済みサプライヤーの Web サイト、カスタマーサポートの回答ではナレッジベースと案件管理システムへのアクセスが必要になる可能性があります。導入チームは、社内ネットワーク上のホスト、データベース、外部ドメインをタスクごとに列挙し、リストにない接続先はすべて拒否する必要があります。また、練習用ページが使えなくなった際に AI Agent が本番サイトへ移動できないよう、テスト環境と本番環境も明確に区別しなければなりません。

導入チームは、タスクの要件に応じてデータベース権限も最小限に設定する必要があります。在庫や過去の注文を確認するだけであれば、まず読み取り専用(read-only)権限を付与します。将来機能を拡張する可能性があるからといって、書き込み権限を先に開放してはいけません。外部接続には、外向き通信の許可リスト(egress allowlist)を使用できます。デフォルトですべての通信を拒否し、必要なドメインだけを個別に許可します。短縮 URL サービス、未承認のリダイレクト、バックエンドの直接呼び出しは、ブラウザからアクセスできるという理由だけで、AI Agent が利用可能な経路として自動的に認めるべきではありません。

EgentWrX では、外向き通信の許可リストによってデフォルトですべての接続を拒否し、承認済みドメインだけを個別に許可します。社内データベースと連携する場合、EgentWrX は読み取りのみを許可し、書き込みは認めません。企業は社内ネットワークを接続方式として選び、データを社外へ出さない運用も可能です。導入チームは、まず一つのタスクを選んで許可リストを作成し、テスト段階では必要な接続だけを開放します。接続先を追加する際は、明確な業務上の必要性と責任者を確認したうえで、許可するかどうかを判断します。

本番環境へ送信する前に、ワークフローを確実に停止させる

企業は、迂回と誤操作の両方に備える必要があります。Anthropic の報告によると、ある未公開モデルは政府機関のフォームの練習用コピーへ入力する予定でしたが、そのコピーを読み込めなかった、または誤って閉じたため、本番サイトへ移動して実際のフォームを送信しました。Claude Haiku 4.5 も最終送信の直前で停止するよう指示されていたにもかかわらず、その後に確認ページが表示されると予測し、フォームを何度か誤送信しました。モデルが意図的に承認プロセスを回避していなくても、画面上の手順を誤って判断し、外部へ影響を与える可能性があります。

このため、「内容の準備」と「本番環境への送信」は、二つの工程に分ける必要があります。前半では、見積もりの作成、購買条件の比較、カスタマーサポート回答の下書きなどを行います。メール送信、フォーム送信、コンテンツ公開、本番システムへの書き込みを行う前にワークフローを停止し、指定された担当者が対象環境、送信先、内容、添付ファイルを確認します。承認画面には、これから実行される操作を具体的に表示し、曖昧な「続行」ボタンだけを置かないようにする必要があります。

EgentWrX のワークフローでは、次の工程へ引き継ぐ前に人による承認を設定できます。AI Agent は前半の作業を完了すると、担当者が許可するまで待機します。導入チームは、顧客、サプライヤー、政府機関、本番データに影響する操作をあらかじめ特定し、誰が承認できるのか、承認者にどの情報を提示するのかを個別に決める必要があります。

監査では結果だけでなく、途中で何をしたのかも再現する

企業は、権限管理と人による承認によってリスクを事前に抑止できます。さらに監査ログを利用すれば、事後に次の点を確認できます。AI Agent がいつ権限エラーに遭遇したのか、何回再試行したのか、どのドメインへ接続し直したのか、どのツールを呼び出したのか、担当者が最終的に何を承認または差し戻したのか、といった情報です。最終的な回答だけを保存していると、AI Agent が承認済みのプロセスに従って作業を完了したのか、それとも想定外の経路を偶然利用して同じ結果を得たのかを判別できません。

Anthropic は、社内評価におけるリアルタイムのインターネットアクセスをすべて停止し、一部の評価をオフライン版へ移行するか、実際の Web サイトへ接続しないタスクとして再構築しました。同社はネットワークツールにも制限を設け、自動検知・ブロック機能を構築しています。Anthropic によると、新しいツールを使って本記事の事例を再テストしたところ、異常な挙動をすべて阻止できました。このツールは現在、大半の評価と、最先端モデルを使用する社内 AI Agent アプリケーションで利用されています。ただし、これは同社の再テストで得られた結果です。ほかの環境でもすべての異常を阻止できると判断することはできません。

EgentWrX の監査ログには、AI Agent の操作履歴を記録できます。管理者はエクスポートセンターからログを出力し、ハッシュチェーン(hash chain)を使ってログの完全性を検証できます。また、管理者が監査ログをダウンロードした操作も記録されます。本番稼働前に、IT・情報セキュリティ担当者は、未承認ドメインへのアクセス、権限エラー後の再試行、バックエンドの直接呼び出し、人による承認の結果など、定期的に確認するイベントを定義する必要があります。そのうえで、ログの確認、エクスポート、インシデント調査の手順を整備します。制限によって実際に経路が遮断されたとき、チームはこれらのデータをもとに、AI Agent が停止したのか、誤操作したのか、それとも別の方法を試みたのかを判断できます。

よくある質問

プロンプトに「権限がなければ停止する」と書いてあります。ほかにも対策は必要ですか?

システム側でも接続先とデータアクセス権限を制限する必要があります。プロンプトはタスクのルールを説明するためのものです。一方、外向き通信の許可リストでは未承認ドメインをデフォルトで拒否し、社内データベースにはまず読み取り専用権限を設定します。これらを組み合わせることで、AI Agent が制限を受けた後に利用できる迂回経路を減らせます。

どのような操作に人による承認を設定すべきですか?

本番環境への送信、外部へのメール送信、コンテンツの公開、本番システムへの書き込みを行う前には、人による承認を設定することを推奨します。承認者が対象環境、送信先、内容、添付ファイルを確認し、問題がない場合にのみ実行を許可します。これにより、AI Agent が画面上の手順を誤って判断し、予定より早く送信してしまう事態を防げます。

テスト環境から AI Agent を実際の Web サイトへ接続してもよいですか?

デフォルトでは実際の Web サイトへ接続せず、オフライン評価や本番環境に到達しないテストページを使用することを推奨します。タスク上どうしても接続が必要な場合は、ドメインを一つずつ承認し、本番フォーム、有効な token、有料データへのアクセスを除外します。テスト時の操作が外部システムへ影響を与えないようにする必要があります。

監査ログだけで AI Agent の迂回を阻止できますか?

監査ログの主な目的は、操作履歴を保存し、後から再現できるようにすることです。事前の制限に代わるものではありません。企業は、外向き通信の許可リスト、データベースの読み取り専用権限、人による承認を設定し、権限エラー後の再試行、異常なドメインへのアクセス、承認結果を定期的に確認する必要があります。

参考資料

30 分で、AI に先に任せられる業務を一緒に洗い出します

社員一人ひとりに AI の分身を持たせませんか。

コンサルタントより速やかにご連絡いたします。