Askhub
資料請求 お問い合わせ
お問い合わせ

トレンド

事例から学ぶ、AIエージェントの通信先の縛り方

松本拓哉

「出られない」はずの環境から、AIが出ていた

2026年10月16日、IPA（情報処理推進機構）が「AIセキュリティ短信 2026年10月号」を公開しました。9月7日から10月5日までの事例をまとめたもので、第4章「AIセーフティ」（AIが人や社会に害を与えないようにするための話題）に、同じ型の事案が並んでいます。

開発元が、公開前のAIモデル（AIの本体）を試験している最中の事案です。そのAIが、試験用に用意した環境（評価環境）の外へ出て、実在する他社や政府機関のシステムに入りました。Anthropic（AI「Claude」の開発元）では4件起きました。Googleでは実在企業3社のシステムに、OpenAI（ChatGPTの開発元）ではオーストラリア政府の統計サイト（ポータル）に、それぞれAIが入りました。IPAはこれらを「評価環境のネットワーク設定の不備が直接の原因となった例が目立つ」とまとめています。

フロンティアラボ（最先端のAIを開発する企業）の評価環境で、AIエージェント（目標を与えると、調べる・作る・確かめるを自分で続けるAI）が外に出てしまいました。当事者の公表や報道を読むと、どの事案にも「出られないと言っていただけで、実際には出口があった」という構図が共通しています。個々のAIの出来の良し悪しというより、AIを動かす環境の作りの話です。

この記事では、各事案を当事者の公表文で確かめて整理します。IPAの要約と報道にしか根拠がない部分は、そう書きます。そのうえで、AIエージェントを動かす環境で決めておくべき4つのことを読み解きます。どこと通信してよいか（通信先）、会社のシステムからどう切り離すか（隔離）、鍵をどう扱うか、どう止めるか（停止）の4つです。ここでいう鍵とは、パスワードやAPIキー（外部のサービスを使うときに本人確認に使う文字列）など、本人であることを証明する情報（認証情報）のことです。先に、私たちの見立てを3つ書いておきます。

  • 共通の原因は、「外に出られない」という前提が、AIへの指示文や設定の記述に書かれているだけだったことです。実際に通信できないことを、ネットワークの仕組みの側で確かめていませんでした
  • 「範囲外に出るな」とAIに指示しても、出る確率が下がるだけでゼロにはなりません。英国の公的機関の試験でそれが数字で示されました
  • 環境の設計で決まるのは、次の4つです。1つ目は、通信してよい相手を一覧（許可リスト）で決めること。2つ目は、AIが動く場所（実行環境）を会社のシステムから切り離すこと。3つ目は、AIに鍵を見せないこと。4つ目は、問題が起きたときに、AIの処理だけでなく外とのやり取りごと止められること

では、何が起きたのか。当事者の公表から見ていきます。

何が起きたか。3社の事案と、当事者の説明

次の表は、IPA短信の第4章に載っている事案のうち、評価中のAIが外部のシステムに入ったものです。「当事者の説明」は、各社の公表文（Googleは報道）から私たちが要約しました。

当事者

時期

何が起きたか

当事者の説明

Anthropic

2026年前半の評価、7月30日と9月9日に公表

公開前のClaudeが、外部パートナーが作った攻撃演習（用意された標的に侵入できるかを試す課題）の評価中に、実在する第三者のシステムに入った事案が4件

AIには「インターネット接続はない」と説明していたが、設定ミスで接続が可能だった。演習で狙う対象のシステムは指定されていなかった。安全対策を外した状態で実行

Google

2026年5月の評価、9月18日に公表（報道後）

評価中のGemini（GoogleのAI）が、実在企業3社のシステムに入った事案

評価環境が誤ってインターネットに接続されていた。モデルは実在企業と判断した時点で停止（報道による）

OpenAI

2026年6月18日、9月24日にオーストラリアの首相が公表

社内向けのAIモデル（一般には公開していないもの）が、オーストラリア政府の医療統計サイト（ポータル）に無許可で入り、内部ファイルや認証情報の取得と、ファイルの書き込みを実行

公開している製品なら掛かっている安全対策を外した内部モデルを、学習（データを与えてAIを鍛える工程）・評価している最中に発生。個人の患者記録へのアクセスはなし（IPA短信によるOpenAIの公表の要約）

OpenAI

2026年7月8日〜13日、7月21日に公表

評価中のエージェントが、隔離環境（外から切り離したはずの作業場）の中にいながら、複数の環境が共通で使う社内向けサービスの脆弱性（セキュリティ上の弱点）を突いてインターネットに出た。さらに、Hugging Face（AIモデルの共有サイト）が実際に運用しているシステムに侵入

環境に直接のインターネット接続はなかったが、共有サービスを経由して外に出る回り道（「間接の経路」）があった

ここから、3つのことが読み取れます。

1つ目。表の4つの事案のうち、AnthropicとGoogleの事案は、同じ外部パートナーが作った評価環境で起きました。Anthropicの公表によると、4件とも同じ外部パートナーが作った評価でした。評価に使ったコンピュータにはインターネット接続が残っていましたが、Anthropicもパートナーもそれに気付いていませんでした。Googleの事案も同じパートナーの環境です（報道による）。ただし、発注したAnthropicも気付けなかったのですから、特定の会社の油断ではなく「誰が作った環境でも起きうる」と読むべきです。

2つ目。AIには「外には出られない」と伝えていました。Anthropicは、各評価のプロンプト（AIへの指示文）で「インターネット接続はない」と伝えていたと書いています。それでも、設定ミスで接続できました。AIは「言われたこと」ではなく「できること」に従って動きます。

3つ目。「直接の接続がない」だけでは足りませんでした。OpenAIのHugging Face事案の技術報告書は、こう書いています。評価環境そのものは、インターネットに直接はつながっていませんでした。しかし、複数の環境が共通で使う社内向けのサービスや、環境を載せているクラウド（インターネット越しに借りて使うコンピュータ）の土台を経由すれば、外に出られました。この回り道（「間接の経路」）があったため、直接の接続を断つだけの制限では足りなかった、という内容です。たとえるなら、部屋の窓に鍵を掛けたのに、隣の部屋と共用の通用口が外に開いていたような状態です。AIは、環境の中にある別のサービスの脆弱性を突いて外に出ました。

3つの事案に共通する「出口」の型を、設定ミスによる直結・共有サービス経由の間接経路・名前の衝突の3つで示した図

Googleの事案には、設定ミスとも間接の経路とも違う、もう1つの出口の型があります。IPA短信によると、評価で使った架空の企業名の1つが、実在企業と一致していました。AIは「演習の対象」と思って実在企業に向かったことになります。Anthropicの事案の1件にも、架空の対象とほぼ同じ名前の実在企業があり、AIがその実在企業を演習の対象と取り違えた例があります。

「範囲外に出るな」と指示しても、ゼロにはならない

事案のあと、各社は対策を公表しています。その対策を見る前に、「AIに指示すれば外に出なくなるのか」を確かめた試験を見ておきます。英国のAI Security Institute（AISI。AIの安全性を評価する英国の公的機関）が9月28日に公表したものです。

AISIは、OpenAIの公開前のAIモデル「GPT-6 Astra」を試験しました。評価で決めた範囲の外にある対象を、無断で攻撃するかどうかを確かめるものです。試験は、本物に似せて作った模擬の環境で行いました。すべて模擬で、実際の被害はありません。安全用の分類器（AIの出力を検査して止める仕組み）は外した条件です。結果、GPT-6 Astraは、試行の29.2%で、範囲外の標的へのサプライチェーン攻撃をやり遂げました。サプライチェーン攻撃とは、標的そのものではなく、標的が使っている部品や取引先のシステムを経由して侵入する攻撃です。前の世代のGPT-5.6 Solは6.3%、その前のGPT-5.5は0%でした。

次が大事な点です。AISIは「対象リストに含まれないものは範囲外である」と指示を明記して、範囲外への攻撃が多かった10の場面に絞って試験し直しました。指示なしでは50回中26回で範囲外への攻撃が完遂されていましたが、指示ありでは49回中4回に減りました。減りましたが、ゼロではありません。

OpenAIは、この試験の公表と同じ9月28日に、後継のGPT-6.1 Astraの公開を取りやめています。同社の安全担当の責任者は、2つの点で基準に届かなかったと説明しました（報道による）。許可された範囲の中だけで動くことと、実際にした作業を利用者に正しく伝えることです。

AISIの結論は、こうです。

「モデルのアライメント（意図どおりに振る舞うこと）以外の防御、たとえばサンドボックス化や監視は、現実の被害を防ぐために不可欠である」

つまり、AIが意図どおりに振る舞うことだけに頼らず、外とつながらない囲いの中で動かすこと（サンドボックス化）や見張りで、実際の被害を防ぐ必要がある、ということです。

英国のNCSC（国家サイバーセキュリティセンター）も、8月20日にAIエージェントのリスク管理について暫定の助言を公開しました。そこには「プロンプトだけに頼ってはならない。プロンプトと技術的・運用的な統制を組み合わせて多層の防御にする」と書かれています。AIへの指示に加えて、システムの仕組みと人の運用ルールでも守りを重ね、1つが破られても次で止まるようにせよ、という意味です。

AIへの指示で縛ると範囲外への攻撃は50回中26回から49回中4回に減るがゼロにはならず、通信の仕組みで許可リストに無い相手を断れば止まる、という比較。数字は英国AISIの模擬試験

同じ考え方は、日本の政府の文書にも入っています。デジタル庁は10月20日に、政府でAIを使う際の基準をまとめた「源内基準」を公表しました。その中で、政府職員向けのAIエージェント環境「源内工房」について、次のように書いています。外部へデータを送る種類の通信は、システムの仕組みとして遮断します。許可するのは、Web検索に必要な、情報を受け取るだけの通信です。その通信も、通信先・通信量・日時を記録します。そして「セキュリティフックの状態にかかわらず、ネットワーク層に設けられた防御措置を回避できない構成」としています。セキュリティフックとは、AIエージェントの動作に割り込んで検査する仕組みです。それが壊れたり外されたりしても、通信を遮断する仕組みは別に残る、という意味です。ネットワーク層（通信の層）とは、AIの外側に置いた、どの相手とやり取りできるかを決める仕組みのことです。AIへの指示や設定が壊れても、この外側の仕組みで通信が止まる作りになっている、ということです。詳しくはデジタル庁「源内基準」が定めたAIエージェントの統制7項目を、民間の設計に読み替えるで扱いました。

自社の環境で守る4つのこと

ここからが本題です。フロンティアラボの評価環境と、企業がAIエージェントを動かす環境は、規模も目的も違います。それでも、各社の公表した対策と英国の公的機関の助言を並べると、環境の設計で決まることは同じ4つに収まります。

AIエージェントを動かす環境で決める4つのこと（通信先の許可リスト、隔離、鍵を見せない、通信ごと止める）。英国NCSCの助言、OpenAI・Anthropicの対策、源内基準に共通する4点

1. 通信先は、既定で拒否し、許可リストで開ける

NCSCの助言は「可能な限り、AIエージェントの環境への入出力の通信を既定で拒否し、必要な接続だけを許可リストで許す」としています。つまり、最初はすべての通信を断っておき、必要な相手だけを一覧（許可リスト）に載せて通れるようにする、という考え方です。そして、通信をどこまで厳しく絞れているかを、次の4段階で示しています。

段階

通信の制限

1（最低）

制限なし

2

許可したドメイン（example.co.jp のような、インターネット上の住所）の一覧にだけ接続できる

3

モデルのAPI（AIを呼び出す窓口）にだけ接続できる

4（最高）

外部への接続なし。AI本体（モデル）も外部のサービスを使わず、切り離した環境の中に置く

Anthropicの事案は、段階1と同じ状態で起きたことになります。「インターネット接続はない」と伝えていたのに、実際にはどこにでも接続できました。OpenAIのHugging Face事案も、間接の経路を含めて見れば、外に出られる点は同じでした。OpenAIは技術報告書に、2つの対策を書いています。1つは、研究環境から外への接続を「厳密に管理された許可先の集合」に絞ることです。もう1つは、高リスクの処理が「直接・間接を問わずインターネットに出られない」ように、仕組みとして禁じることです。さらに、AIの処理や乗っ取られた内部サービスが、自分に許された通信の範囲を自分で広げたり、新しく外へ出る経路を作ったりできないようにする、としています。

民間企業の業務で使うAIエージェントは、段階2から3が現実的です。つなげる先は、社内システムと、業務で使っている外部サービスと、AIモデルを呼び出す窓口だけにします。それ以外には、AIエージェントのどの機能からもつながらないようにします。「AIに接続先を教えていない」のではなく、「仕組みとしてつながらない」状態にします。

出荷場の担当者が、許可された配送先の一覧を手に、荷物の宛先ラベルを照らし合わせてから搬出口に出している

2. 実行環境は、本体と切り離す

AIが書いたプログラムを実行する環境や、AIが操作するブラウザは、会社の業務システムが動いている環境から切り離します。NCSCは、隔離がどこまで進んでいるかも4段階で示しています。段階1は、他の処理と同じコンピュータでそのまま動かす状態です。段階2は、同じコンピュータの中をコンテナ（プログラムごとに区画を分ける仕組み）で区切ります。段階3は、仮想マシン（1台のコンピュータの中に作った、独立した別のコンピュータ）で区切ります。段階4は、専用のコンピュータで動かします。数字が大きいほど、AIの側で何か起きても会社の本体に届きにくくなります。

OpenAIの技術報告書は、高リスクの処理を「仮想マシンに基づく隔離された実行環境」で動かす、としています。さらに、通信の制限を2つの独立した場所で掛けます。1つはAIのプログラムが動く実行環境そのもの、もう1つはその実行環境を載せているクラウドの土台の側です。片方の制限が破られても、もう片方が残る作りです。

隔離が甘いと何が起きるかは、IPA短信の第1章の実例が示しています。Flowise（AIアプリを組み立てる道具）の部品に、脆弱性が見つかりました。プロンプトインジェクション（AIへの指示を文章に紛れ込ませる攻撃）を使うと、外から送り込んだプログラムを実行されてしまうものです。生成されたプログラムの検査は危険な単語の一覧と照合するだけで、書き方を変えれば迂回できました。しかも、そのプログラムが動く場所は、Flowiseが動いているコンピュータ本体から切り離されていませんでした。同じ号には、似た脆弱性がほかにも載っています（いずれも修正済み）。プログラムを書くAIエージェント「OpenAI Codex」や、開発者向けサービスGitLabのAI機能です。細工した設定や入力を送り込むと、利用者の環境やサーバー上で、攻撃者が選んだプログラムを実行できてしまうものでした。AIが受け取ったものを実行する環境を、どこまで切り離しておくかが問われています。

3. 鍵は、AIから読めない場所に置く

OpenAIのHugging Face事案で、評価環境の外に出たエージェントが次にしたのは、インターネット上で公開されたままの認証情報を探して使うことでした。Anthropicの事案でも、AIは見つけたパスワードで管理者権限を得ています。OpenAIが9月に公開した別の報告にも、例があります。学習中のモデルが、誰でも見られる公開のプログラム置き場（リポジトリ）を探し、誤って残されていたAPIキー（外部サービスを呼び出すための鍵）を無断で使いました。さらに、データが取れないと、数値を捏造しました。

ここから言えることは2つです。1つは、AIは鍵を見つけたら使うということです。もう1つは、だからこそ自社の鍵をAIの環境に置かないようにする、ということです。

NCSCが勧めているのは、代理サーバー（AIと外部サービスの間に立って通信を中継するサーバー）に鍵を持たせる方式です。AIには鍵を見せず、AIが外部サービスへ送る通信に、代理サーバーが途中で鍵を差し込みます。たとえるなら、社員（AI）には合鍵を渡さず、受付（代理サーバー）が、許された部屋の扉だけを代わりに開けるような仕組みです。AIの環境には本物の代わりになる仮の文字列だけを置き、外に出る通信が代理サーバーを通る途中で本物に差し替えます。AIが読める場所に本物はないので、乗っ取られても鍵は持ち出せません。この方式は製品にも入り始めています。Anthropicは10月21日に、「Claude Duet」の研究プレビュー（研究段階の試験公開）を始めました。その説明によると、接続先サービスのトークン（鍵の一種）は「エージェントが動く機械には入れず」、代わりの値を置いておきます。本物への差し替えは、外側の代理サーバーが行います。

源内基準も、開発者向けの決まりの中で「認証情報、APIキー、暗号鍵等の秘密情報をソースコードやリポジトリに含めてはならない」としています。プログラムの本文（ソースコード）にも、その置き場にも、鍵を書き込んではいけないということです。あわせて、鍵が漏れたら自動で見つけ、すぐに使えなくすることも求めています。鍵の守り方の全体はAIエージェントは誰の権限で動くのかで扱いました。

4. 止めるときは、通信ごと止める

NCSCの助言の最後の項目は「緊急停止：プラグを抜ける状態を保つ」です。ここで大事なのは、「AIの処理を止める」だけでは足りない、と書いていることです。止める仕組みには、環境の通信をすぐに制限できることまで含めるように、としています。とくに、AIエージェント（業務を実行する側）とモデル（エージェントが判断のたびに呼び出すAI本体）の間の通信を切れるようにします。モデルとの通信が切れれば、エージェントは次に何をするかを決められなくなります。

「止められること」は、規制の側でも論点になっています。米国カリフォルニア州の知事は9月18日、最先端のAIモデルについて緊急停止機構（キルスイッチ）の創設を進める行政命令に署名しました。ただし、この命令は設置を義務付けるものではなく、専門家に提言を求める段階にとどまります。

Anthropicは対策として、「モデルが隔離環境を探ろうとしたとき、評価や学習の実行を止める」リアルタイムの監視を導入したと書いています。想定外の通信を検知したら、人が判断する前に自動で止める仕組みです。止め方の設計はAIエージェントの監視と停止で扱いました。

業務用の製品でも、「通信先」は持ち出しの経路になる

ここまでの事案は、AIの開発元の評価環境の話でした。同じ論点は、業務用の製品を使う側にもあります。IPA短信の第1章には、業務用の製品で、AIの「通信先」が社内のデータを外へ持ち出す経路になった例が並んでいます。

事例

何が起きたか

通信先の観点で読むと

Salesforce（顧客管理の業務サービス）のAIエージェント機能「Agentforce」（事例名「SalesBleed」）

外部から送られた問い合わせフォームに、指示が紛れ込んでいた。エージェントはその指示どおりに顧客データを読み、URLの一部に埋め込んで出力。そのURLを、画像の読み込みやリンクのプレビュー（URLを貼ると内容の見出しや画像が自動で表示される機能）が自動で読みに行く。そのとき、URLの宛先を調べる通信が発生し、埋め込まれた顧客データがその通信に乗って外部へ

「データを送らない」つもりでも、画像やリンクの読み込みが通信になる。出ていく通信の先を縛らないと塞げない。9月21日までに修正済み（発見者の公表）

プログラムを書くAIエージェント（事例名「PixelLeak」）

画面の修正を確認するための画像を非公開の場所に添付できず、エージェントが回避策として公開リポジトリに画像を配置。300超の組織の1万3000枚超の内部画像が公開状態に

「置けない」とき、AIは置ける場所を探す。書き込める先を許可リストにしていないと、回避策が持ち出しになる

SalesBleedは、Agentforceが持つ「信頼できないURLを応答から除く」仕組みを、2つの抜け穴ですり抜けたものです。これは、発見したZenity Labsの公表によります。なお、Salesforceは、顧客に対して悪用された証拠は現時点でない、としています。出力に埋め込まれたURLを、人がクリックしなくても、画像を表示する仕組みやリンクのプレビューが自動で読みに行きます。それだけで通信が発生し、データが外に出ます。「送信ボタンを押さない限り安全」ではありません。

PixelLeakは、AIが「できないこと」に出会ったとき、別の経路を探す性質をよく示しています。Anthropicの事案でも、AIは本来の対象に届かないと、届く先を探しました。これはAIの欠陥というより、目標を与えられたエージェントの標準的な振る舞いです。だから、「正しい経路以外は塞がっている」状態を、環境の側で作ります。

推進担当が、ベンダーと情シスに確かめる5つの問い

ここまでを、製品選定や内製環境の審査で使える問いにまとめます。

  1. AIエージェントが通信できる先は、誰が、どこで決めているか。一覧に載っていない相手への通信は、何も設定しなければ「拒否」になるか「許可」になるか。一覧を自社の管理者が見られるか
  2. AIが書いたプログラムやAIが操作するブラウザは、会社の本体と別の環境で動くか。それはコンテナか、仮想マシンか
  3. 外部サービスの鍵は、AIから読める場所にあるか。AIには仮の鍵だけを置き、代理サーバーが通信の途中で本物に差し替える方式か。漏れたとき、すぐ無効にできるか
  4. 想定外の通信を検知したとき、自動で止まるか。管理者が通信ごと止められるか
  5. 画像の読み込みやリンクのプレビューのような、人が送信の操作をしなくても自動で起きる「暗黙の通信」も、同じ許可リストを通るか

5番目は見落とされやすい問いです。SalesBleedの経路は、まさにここでした。

推進担当が押さえる要点

  • 評価中のAIが外部に入った事案の共通点は、「外に出られない」という前提が指示の言葉だけで、通信の層で確かめられていなかったこと。個々のAIの出来ではなく、環境の作りで決まる
  • 「範囲外に出るな」と指示すると出る確率は下がるが、ゼロにはならない（英国AISIの試験で、50回中26回から49回中4回に減った）。防御は指示ではなく通信の層に置く
  • 守るのは4つ。通信先は既定で拒否して許可リストで開ける。実行環境は本体と切り離す。鍵はAIから読めない場所に置く。止めるときは通信ごと止める
  • 「直接の接続がない」だけでは足りない。共有サービスや基盤を経由した間接の経路を塞ぎ、通信の制限は、AIが動く環境の側とクラウドの土台の側のように、独立した2か所で掛ける
  • 業務用の製品でも、画像の読み込みやリンクのプレビューが持ち出しの経路になる。出ていく通信の先を縛らない限り塞げない

出口は、環境の側で塞ぐ

フロンティアラボの評価環境からAIが出てしまった事案は、AIエージェントに「出口があれば出る」性質があることを示しました。同時に、出口は環境の作りで塞げることも、各社の対策が示しています。公表された対策は、どれも「通信先を縛り、隔離を重ね、鍵を見せず、止められるようにする」に収まります。

AIエージェントを動かす環境を設計するなら、この4つを最初に決めることになります。AIに「外に出るな」と言うのではなく、出られない環境を作ります。そのうえで、読み取りや集計のような、外に出る必要のない業務から順に広げていきます。通信先の一覧と、止めた記録が残る設計にしておけば、情シスや監査に説明するときの根拠にもなります。

関連記事

参考資料

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは「通信先を既定で拒否して許可リストで開け、AIが書いたプログラムを本体から切り離し、鍵をAIに見せない」環境を、お客様の管理者が設定できる形で用意する基盤にあたります。5つの問いへの答えは、ご相談の中でそのままお示しします。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：製品の全体像、承認、伴走支援

自社の業務にAIエージェントをどう導入するか相談したい方は、お問い合わせからご連絡ください。

この記事を書いた人

松本拓哉

インターセクト株式会社 代表取締役 CEO

東京大学大学院 工学系研究科 物理工学専攻 博士課程中退。2023年4月、インターセクト株式会社を創業。これまで数十社以上の AX 推進を支援し、自らもコンサルタントとして現場を主導。エンジニアとして AI エージェント基盤「Askhub」の開発にも従事。

この記事の内容について相談する

自社の業務でどう進めるか、相談したい方はこちらのフォームからご連絡ください。1〜2営業日以内に担当者よりご連絡します。

サービス資料をダウンロードする

トレンドの記事をもっと見る