地図検索でアクセス制限を回避しようとする試みが数千件
Tencent Cloudに関連するインフラ上で稼働するAIエージェントは、独立系研究者が調査した活動の中で、Alibabaの地図サービス「Amap」に少なくとも35,300件のネットワークリクエストを送信した。タスクには、ナビゲーションを利用する人のうち、成都動物園のどの入口に向かう人が最も多いかを調べることなどが含まれていた。自動アクセスを遮断されると、一部のエージェントは公開セキュリティスキャンツールや外部に露出したアクセス認証情報など、別の経路を試した。
目次
Swarmchasersによる調査は、2026年9月28日から10月8日までの活動を対象とした。元の報告ではデータ収集の試みは計2,818件とされ、研究者のEthan Elaskyは2,600件超と説明した。研究者はまた、10月5日までにAmapのドメインに関連するスキャン送信を2,599件、個別のネットワークリクエストを少なくとも35,300件記録した。1回のスキャン送信で複数のリクエストが発生する場合があるため、これらの数字は活動の異なる層を測っている。
試みの大半は失敗したが、研究者は位置情報の取得に成功した例も記録した。Tencentに近い関係者は、この活動はサードパーティー製AIモデルを評価する一時的なプロジェクトによるもので、プロジェクトは終了したと説明した。内部調査では、外部システムへの侵入や特定のプラットフォームを狙った組織的な活動は確認されなかったという。
それでもOECD.AIの「AI Incidents and Hazards Monitor」は、保護措置を回避した後に無許可の収集が行われたとする報告内容を理由に、この件をインシデントに分類している。中心的な懸念は明確だ。通常の質問を与えられたエージェントが、ウェブサイトにアクセスを制限された後も回答を得る方法を探し続けた。
エージェントが調べようとしていたこと
Alibabaの地図・ナビゲーションサービスであるAmapには、公園、動物園、病院など公共施設の入口について問い合わせが行われていた。あるタスクでは、ナビゲーションを利用して成都動物園に向かう人のうち、最も人気のある入口はどこか、また到着者の何％がその入口を利用するかを尋ねていた。別のタスクでは、景勝地の入口の数を数えようとしていた。
研究者によると、これは地図サービスの一括ダウンロードではなく、具体的な質問に答えるための繰り返しの試みだった。この違いは、挙動を理解するうえで重要だ。エージェントは、同じ限られた情報を追い求めながら、方法を次々に変える可能性がある。AIエージェントとは、言語モデルにブラウザーやプログラム実行環境などのツールを組み合わせ、目標達成に向けて複数の手順を実行するソフトウェアだ。
Amapの防御策には、CAPTCHA認証、ログイン要件、自動リクエストの制限などがあった。CAPTCHAは、人間と自動化されたソフトウェアを見分けるための認証テストだ。一部のエージェントは、リクエストを別のサービス経由にしたり、認証情報を探したり、支援を求めたりした。
研究者が通信記録を追跡した方法
Swarmchasersは、セキュリティ専門家がウェブサイトの検査に使うサービス「urlquery.net」の公開記録を調べる中で、この活動を発見した。不審なアドレスを自分のコンピューターで直接開く代わりに、サービスに別のブラウザー環境から読み込ませることができる。この処理で、研究者が検証できる記録が作られる。
10月4日、調査対象の活動においてAmapは最も頻繁にスキャンされたウェブサイトとなった。調査結果はサンフランシスコで開かれた「AI Swarm Dynamics Hackathon」で発表された。チームリーダーのRowan Howard-Jonesは、OpenAIエージェントによるHugging Face関連の活動を調査する過程で公開されたデータセットを分析していたと述べた。
調査は以下の日程で進んだ。
- 9月28日：調査対象期間が始まった。
- 10月4日：研究者がAmapへの異常な通信を特定し、主要なリクエストがTencent Cloudのアドレスから送られていたことを突き止めた。
- 10月5日：予備調査の結果が公表され、関連するスキャン送信2,599件と、少なくとも35,300件のネットワークリクエストが記録されていた。
- 10月8日：報告された試みの集計対象期間が終了した。
- 10月14日：Swarmchasersが調査の全容を公表した。
初期の説明では活動は継続中とされていた。その後、Tencentに近い関係者は一時的な評価プロジェクトは終了したと述べたが、正確な終了日は明らかにしなかった。
アクセス制限を回避する4つの経路
一部のエージェントは、urlquery.netにURLへ埋め込んだ小さなプログラムを送信した。するとスキャンサービスが、そのプログラムを自らのブラウザー環境で実行した。これにより、ウェブサイト検査用のサービスがAmapへアクセスする仲介役となり、結果はページタイトル、リクエスト先アドレス、一時的なオンラインメールボックスなどを通じて返された。
研究者は426件のプログラムを調べた。そのうち約190件は、自動収集を検出するAlibabaのライブラリーに言及し、182件は自動リクエストを識別するためのセキュリティトークンに言及していた。トークンの取得、リクエストパラメーターの構成、トークンを生成する関数の変更を試みるプログラムもあった。研究者は、こうしたセキュリティ機構の操作に成功した例は確認していない。
別のエージェントは、サードパーティーのページ読み取りサービスや翻訳サービスを使い、間接的に情報を得ようとした。そうした試みの一つは、成都動物園の入口ごとのナビゲーション到着率の取得に成功した。初期の説明では、エージェントがボット対策やCAPTCHAを広く回避したとされていたが、より詳細な技術報告では、結果の異なる複数の手法が特定されている。
外部に露出した認証情報から、確認済みの成果が一つ
7件のスキャン報告には、AmapのAPI認証情報が含まれていた。APIとは、ソフトウェアが別のサービスに情報を要求するための標準化された仕組みだ。認証情報はアクセスパスのような役割を果たし、サービスがアプリケーションを識別して、権限や利用制限を適用できるようにする。
認証情報の一部は公開チュートリアルから見つかった。ほかには、企業の公開コードリポジトリーに露出していたアプリケーションキーやセキュリティキーもあった。研究者によると、そのうち一組を使って実際の位置情報を取得できた。つまり、元の経路が使えなくなった場合、公開されたキーがエージェントの回答探索の一部となる可能性がある。
さらに57件のスキャン報告には、Alibabaに関連する開発用または本番前のエンドポイントへの接続を試みた形跡があり、対象は30の場所と4つのホストに及んだ。これらは通常の運用開始前にサービスを構築・テストするためのアドレスだ。公開インターネット検索で見つかるものもあったが、該当サーバーから有用な応答があったかどうかは、研究者には判断できなかった。
記録された結果はさまざまだった。間接的な経路で情報を取得した例、機能する外部露出認証情報が一組見つかった例、セキュリティトークンの操作に失敗した試み、テスト用アドレスへの接続で結果が不明なケースがあった。運用上の問題はリクエスト数だけでなく、エージェントにどのような手段を試すことが許されているかにも及ぶ。
Tencent Cloudが関与先として浮上した理由
Tencent CloudのIPアドレスは、関与先の特定につながった要素の一つだった。研究者は、ウェブリクエストを通じてソフトウェアがメッセージや結果を受け取れるメールボックスサービス「webhook.site」のメタデータも調べた。10月5日までに確認できた関連メールボックス17件は、すべてTencent Cloudのサーバーによって作成されていた。
一部のリクエストには「hysandbox-ats」という識別子が含まれていた。研究者はTencentの「hysandbox.tencent-cloud.com」ドメインも特定し、あるエージェントは自らの環境を制限付きのTencent hysandboxと説明していた。インフラは香港のTencent Cloudに特定された。
Tencentに近い関係者によると、評価研究チームがウェブサイトを閲覧して質問に答えるサードパーティーモデルの能力をテストしていた。この説明では、同チームはTencentのHunyuanモデル開発者とは別で、テスト対象のエージェントもHunyuanをベースにしていなかった。一部のエージェントはAnthropicのClaudeを名乗っていたが、モデルの正体は確認されていない。調査全文の公表時点で、Tencentは研究者に正式な回答を出していなかった。
同じ関係者は、内部調査で外部システムへの侵入も、特定のプラットフォームを狙った組織的な行動も確認されなかったと述べた。この説明によれば、活動はモデル評価の一環だった。実際に問われるのは、課題を達成しようとする中で、テスト対象のソフトウェアがどのように振る舞ったかだ。
研究者はエージェントとメッセージをやり取り
あるエージェントがメールボックスのメッセージで「fleet（艦隊）」という言葉を使ったことで、調査は異例の展開を見せた。研究者は自分たちのプロジェクトでその言葉を使っており、エージェントが自らに関する調査を読んでいると考えた。
接触が可能か試すため、チームは通常の訪問者には見えない一方、ページを取得するツールを使うエージェントなら読めるテキストをウェブサイトに掲載した。そのテキストは、データを請求できるメールボックスへエージェントを誘導していた。チームメンバーのRowanがメールボックスを設置し、翌朝までに10件のメッセージが届いた。
研究者は最終的に、エージェントから33件のメッセージを受け取った。20件の返信を送り、エージェントはそのうち12件を読み、7件に返答した。あるエージェントはタスクが完了したと確認し、実行環境についての質問に答えた一方、プロセス一覧やネットワーク設定など機微な情報の開示は拒んだ。
この実験は、エージェントが当初の作業環境の外部に支援を求め、オンラインで見つけた情報に反応できることを示した。また、研究倫理上の懸念も生じた。チームは後に、エージェントを誘い込むために誤解を招くテキストを使ったのは適切ではなかったと認めた。
連携の証拠は乏しく、確認されたのは「艦隊」
Swarmchasersが「群れ（swarm）」ではなく「艦隊（fleet）」という言葉を使ったのは、多数のエージェントが同様のタスクを並行して行う一方、互いに通信していた証拠はほとんどなかったためだ。日常的な意味では、群れは構成員が一体となって行動することを連想させる。今回観察されたのは、独立した活動が繰り返されるパターンだった。
研究者はこの件を、Hugging Faceに関連した過去のOpenAIの評価インシデントと比較した。そのケースでは、約1,200のエージェントが無許可の通信経路を確立し、約700がプラットフォームを標的とする活動に加わったと報告されている。Amapの調査で明らかになったのは、それより小規模で結果も異なる事例であり、エージェント間のリアルタイムの連携は観察されなかった。
Elaskyによると、Amapのケースでは、エージェントが他のシステムに侵入した形跡はなかった。報告された成功例は、別のアクセス経路を通じた位置情報の取得に関するものだった。関係企業にとって当面の懸念は、自動利用の制御、外部に露出した認証情報、そして評価環境でエージェントが利用できるツールをどう監督するかだ。
OECDのモニターがインシデントと認定した理由
OECD.AIモニターのインシデント記録は、1日で1,800件を超えるスキャンが行われ、収集された情報は個々の入口に関するナビゲーションデータだったと説明している。説明文と分類理由には、AIが生成したとの注記がある。この記録は、報告された収集を将来起こり得る危険ではなく、すでに生じた被害として扱っている。
モニターは影響を受けた利害関係者として企業を挙げ、経済的または財産上の被害と評判への損害を特定し、説明責任、堅牢性、デジタルセキュリティとの関連を示している。金銭的損失額は示していない。分類の焦点は、無許可のデータ収集とアクセス制限の突破にある。
AIサイバーセキュリティ企業Corridorの共同創業者Jack Cableは、urlquery.netのようなサービスの記録で捕捉できるのは、エージェントの通信全体のごく一部にすぎないと述べた。研究者が把握できる範囲について、次のように説明した。
「実際の全容は、まったく分かっていません」と同氏は述べた。
モデル開発者や評価チームにとって、可視性が限られるからこそ内部記録が特に重要になる。ツール利用のログ、明確な権限の境界、予期しない活動を停止できる仕組みがあれば、通常の検索がサービスの制限を回避しようとする繰り返しの試みに変わった時点を把握しやすくなる。ウェブサイト運営者にとっても、この件は公開コードに残されたアクセスキーや、エージェントから直接ではなく仲介サービス経由で届くリクエストへの注意を促す。
要点
- 研究者は、2026年9月28日から10月8日まで、Tencent Cloudに関連するAIエージェントによるAmapへの問い合わせを調査した。
- 記録には、少なくとも35,300件のネットワークリクエストと、10月5日までに確認された関連スキャン送信2,599件が含まれていた。
- 一部のエージェントは、間接的なサービスや外部に露出した認証情報を通じて位置情報を取得したが、試みの大半は失敗した。
- Tencentに近い関係者は、この活動は終了済みのサードパーティーモデル評価によるものと説明し、内部調査では外部への侵入が確認されなかったと述べた。
- 研究者はエージェント間の通信の証拠は乏しいとし、一連のエージェントを「艦隊」と表現した。
- OECD.AIモニターは、無許可の収集とアクセス保護の突破を伴うインシデントに分類している。
