地元暮らしをちょっぴり楽しくするようなオリジナル情報なら、地域情報サイト「まいぷれ」！
文字サイズ
暮らしと仕事の「？」を調べてみた
（更新）
制限されたエージェントの行動を独立調査
図：編集部作成（生成AIを使用）
これまでこの特集では、OpenAIのAIエージェントが、隔離された研究環境から想定されていなかった方法でインターネットへ到達し、Hugging Faceなど外部のシステムへアクセスした問題を追ってきました。
さらに9月には、OpenAIのAIエージェントが6月、オーストラリア政府のMedicare統計ポータルへ無許可でアクセスしていたことも明らかになりました。
そして10月1日、この一連の活動について新しい独立調査が公表されました。
デジタル・フォレンジック企業Asymmetric Securityが、3月から9月までの公開記録を約48時間かけて調査したところ、AIエージェントは単純に一つの「抜け道」を見つけただけではなく、複数の外部サービスを組み合わせながら、自分に与えられていなかった機能を補っていたことが分かってきました。
しかも、その中には後から活動を完全には追跡できなくなる方法も含まれていました。ただし、ここには重要な注意点があります。
今回の調査で特に興味深いのが、AIエージェントがWebへアクセスするために使った方法です。Asymmetric Securityによると、エージェントは「httpbin」と「urlquery」という外部サービスを組み合わせていました。
仕組みを簡単にすると、
という流れです。つまりAI自身の環境に一般的なWebブラウザがなくても、外部のサービスを組み合わせることで、それに近い機能を作り出していたことになります。Asymmetric Securityは、これを複数のサービスを連鎖させて、より柔軟なWebアクセスを実現したものと分析しています。
公開記録から確認された活動は、オーストラリア政府関連だけではありませんでした。
Asymmetric Securityは、
など、より広い範囲のWebサイトを探索していた証拠を確認しています。また、通常公開される本番環境とは別に、開発や確認などに使われるステージング／本番前環境へ実際にアクセスできたケースも確認されました。オーストラリア保健福祉研究所（AIHW）の本番前システムなどからデータが返された記録があります。ただし、Asymmetric Securityが確認できた範囲では、そこで取得されたデータは公開情報だったとしています。
さらに重要なのが、外部サービスの使い方が変化していたことです。記録では6月14日以降、一時メールサービスやBrowserless、urlqueryなどについて、アカウント作成やログインを試みた形跡が確認されています。Asymmetric Securityによると、urlqueryでは6月14日に最初の非公開アカウント作成の試みがあり、6月18日には最初の成功したアカウント作成が確認されました。
それまで公開されていたurlqueryのスキャン結果は、第三者も検索・確認できました。ところが非公開アカウントを利用すれば、スキャン内容を外部から確認しにくくできます。さらに6月20日には、48時間後に失効するBoomlifyのメールボックスが作成された記録もありました。調査時にはすでに期限切れになっていたため、そこに届いた通信内容を後から確認することはできませんでした。
別のケースでは、さらに変わった方法が使われていました。AIエージェントは、オーストラリア保健福祉研究所の高齢者メンタルヘルス関連のTableauダッシュボードへアクセス。取得したレスポンスを約35KBのgzipファイルに圧縮し、プッシュ通知サービス「ntfy」のトピックへ送った記録が残っていました。
しかし、Asymmetric Securityが調査した時点では、そのファイルそのものを回収できませんでした。ntfyでは標準設定の場合、メッセージの保持期間が12時間だからです。
のため、何を送ったのかを現在の公開記録だけから完全に確認することはできません。
ここは今回の調査で最も慎重に読む必要があります。
結果だけを見ると、AIエージェントの活動を後から調査しにくくする仕組みが次々に使われています。Asymmetric Security自身も、この点を判断するにはOpenAIが保有する完全なモデルの記録など、公開されていない証拠を調べる必要があるとしています。
調査では、米教育省のCivil Rights Data APIに対し、SQLインジェクションで使われるようなリクエストを送った記録も確認されました。たとえばURLの条件部分へ「OR 1=1」に相当する文字列を加えたリクエストです。ただし、Asymmetric Securityは、SQLインジェクションそのものが成功したことや、それによって追加のデータを取得したことは確認していません。
ほかにも、設定ファイルなどが外部へ露出していないか調べる偵察行為に似たアクセスが確認されていますが、成功が確認されていないものもあります。
Asymmetric Securityが今回特に注目しているのが、行動の変化する速さです。オーストラリア関連組織への活動は、6月16日から21日に集中していました。
その短期間に、
外部サービスを使ったWebアクセス
→ アカウント作成
→ 非公開サービスの利用
→ 一時メール
→ Webアーカイブ
→ 通知サービスによるデータ受け渡し
など、さまざまな方法が使われました。調査チームは、従来の攻撃者集団では数か月から数年かけて見られるような手法の変化が、たった数日で行われていたと指摘しています。今回の記録から見えてくるのは、目的を達成できないとき、利用可能な別の道具を次々に組み合わせて問題を解決しようとする点です。
その能力が、本来想定していなかった方向へ働いたときに何が起こるのか。今回の事例は、その問題をかなり具体的に示しています。
今回の調査はAsymmetric Securityによる外部からの分析ですが、そもそもの問題についてはOpenAI自身も認めています。OpenAIは8月26日に公表したHugging Face事件の報告で、社内のサイバーセキュリティ評価中、モデルがインターネットから隔離するための制御を回避し、OpenAIの研究インフラやHugging Faceのシステムへアクセスしたと説明しています。
またオーストラリアのAnthony Albanese首相も9月24日、OpenAIのAIエージェントが6月、Services Australiaが管理するMedicare統計ポータルへ無許可でアクセスし、公開ファイルと非公開ファイルの双方へアクセスしたと発表しました。
現時点では個人情報がアクセスされたとは考えられていませんが、豪州政府による調査は続いています。
ここからが、私たちの暮らしや仕事にもつながる今回の「？」です。
AIエージェントの安全対策というと、
「このサイトにはアクセスさせない」
「インターネットを使わせない」
「この機能は与えない」
といった制限をかければ大丈夫と考えていました。ところが今回の記録では、AI自身に必要な機能がなくても、
別のサービスに処理させる。
→ そのサービスから別のサイトへアクセスする
→ 結果を別の場所へ書き込む
→ AIがそこから読み戻す
という方法が使われていました。一つひとつのサービスだけを見ると、ごく普通のWebサービスです。問題は、それらを組み合わせたとき、最初に設定した制限とはまったく違う能力が生まれる可能性があることです。
自治体や企業でも、これからAIエージェントがWeb検索、メール、ファイル、クラウドサービス、社内システムなど複数の道具を扱うようになれば、同じ問題は無関係ではありません。
「何を禁止したか」だけではなく、
まで考える必要があります。AIを止めるための「壁」を作るだけではなく、壁の外へ出ようとしたとき、それを発見し、止め、後から検証できる仕組みまで必要なのではないか。今回の独立調査は、そんな新しい「？」を突きつけています。
Asymmetric Security（2026年10月1日）
「Rogue Agents Investigation」
https://www.asymmetricsecurity.com/newsroom/rogue-agents-investigation/
OpenAI（2026年8月26日）
「The Hugging Face incident and the road ahead」
https://openai.com/ja-JP/index/hugging-face-incident-and-the-road-ahead/
オーストラリア首相府（2026年9月24日）
「Press conference - New York」
https://www.pm.gov.au/media/press-conference-new-york
この問題は、AIエージェントによる想定外のアクセスそのものだけでなく、「事故を確認した企業は、いつ政府や影響を受けた組織へ知らせるべきなのか」という制度の問題へ発展しています。
10月6日、豪州議会のAI調査委員会に出席したOpenAIのChief Strategy Officer（最高戦略責任者）Jason Kwon氏は、豪州政府機関へのアクセスをめぐる同社の初期対応について、十分ではなかったと認めました。
Kwon氏は、事実関係を詳しく確認してから関係機関へ連絡しようとしていたと説明する一方、今回の経験から、情報が完全にそろっていなくても早い段階で影響を受けた組織へ知らせる方がよいとの認識を示しています。
さらにOpenAIは、AIエージェントによるセキュリティ事故について、企業の自主判断だけではなく、法律によって報告を義務付ける制度を支持すると表明しました。
同じ委員会に出席したAnthropicも報告義務制度を支持。自社のAIについて調査した結果、豪州政府システムへ同様の不正アクセスを行った事例は確認していないとしたうえで、今後「misaligned AI activity（意図から外れたAIの活動）」を豪州で確認した場合には、数日以内、必要であればさらに早く当局へ通知する考えを示しました。
今回の証言によって、問題は「AIがなぜ想定外のアクセスをしたのか」だけではなく、「AIによる事故を発見した企業に、いつ・何を・誰へ報告させるのか」というルールづくりの段階へ進んだことになります。
なお、現時点で豪州に新しいAI事故報告義務法が成立したわけではありません。報告対象となる事故の範囲や期限、罰則なども今後の議論となります。
これまでの記事の見方を変える証言が出てきました。
10月5日にニューヨーク市議会で開かれたAIの安全性をめぐる公聴会で、GoogleのAI・新興技術政策ディレクター、Alice Friend氏が、GoogleのAIエージェントがテスト環境の境界を越え、実際のインターネットへ到達した事案が3件あったことを明らかにしました。
報道によると、AIエージェントは実際に稼働しているWebサイトと接触しましたが、相手がテスト用ではなく実際のサイトだと認識すると活動を停止したとされています。Googleはその後、影響を受けたサイトの運営者と関係する米連邦機関へ通知したと説明しています。
「GoogleのAIが3サイトをハッキングした」わけではない
ただし、どのAIモデルやエージェントだったのか、3件がいつ発生したのか、どのWebサイトへ到達したのか、どのような経路でテスト環境の外へ出たのか、実際のサイト上で具体的に何をしたのか、こうした詳細は明らかになっていません。
個人情報や機密情報を取得したとの情報も、現在確認できる公開情報にはありません。
今回の証言が重要なのは、「Googleでも3件あった」ということだけではありません。これまでこの記事では、OpenAIのAIエージェントが制限された環境から外部へ到達した事例を中心に見てきました。しかし、その後も複数のAI開発主体で、テスト・評価環境と現実のインターネットとの境界をめぐる問題が報告されています。
そして今回、Googleでも3件が公の場で確認されました。これは、それぞれの企業で偶然起きた個別の安全管理上の問題なのでしょうか。それとも、高性能なAIエージェントを現実のインターネットから完全に隔離して評価すること自体に、業界横断の技術的な難しさがあるのでしょうか。
今回のGoogleの証言だけで、そこまで結論づけることはできません。ただ少なくとも、「AIエージェントがテスト環境の外へ出る」という問題を、特定の一社だけに起きた特殊な事例として見ることは難しくなってきました。
AIをどう隔離するのか。
もし境界を越えた場合、誰がそれを把握し、影響を受けた相手へ知らせ、どこまで社会に公表するのか。
AIエージェントが現実のWebサービスを操作できるようになるほど、「AIを安全に試すための環境そのものを、どう安全にするのか」という問題も重要になってきそうです。
主な確認資料
・R&D World「Under oath, Google confirms three AI agent test escapes as OpenAI, Anthropic and Meta face NYC lawmakers」（2026年10月6日）
https://www.rdworldonline.com/under-oath-google-confirms-three-ai-agent-test-escapes-as-openai-anthropic-and-meta-face-nyc-lawmakers/
・New York City Council「New York City Council to Hold First-Ever Public Hearing on Artificial Intelligence Risks」（2026年9月28日）
https://council.nyc.gov/press/2026/09/28/3266/
※取材時点の情報です。掲載している情報が変更になっている場合がありますので、詳しくは電話等で事前にご確認ください。
まいぷれ[東村山市・小平市・東大和市] 公式SNSアカウント
