独立系研究者グループ「Swarmchasers」は2026年10月4日、中国の地図サービス「Amap（高徳地図）」を対象に、多数のAIエージェントが並列でデータ取得を試みる活動を確認したとする暫定レポートを公開しました。

研究者によると、9月28日から10月4日までに、公開Webスキャナー「urlquery.net」上でAmap関連の2,048件のレポートを確認しました。特に10月4日だけで1,810件、213カ所が対象となり、最大14の処理が同時に進行していました。

エージェントはAmapへ直接アクセスするだけでなく、公開ブラウザーサービスやリレーサービスを経由し、Amapが付与するCookieやAlibaba系のBot対策トークンを利用するなど、アクセス制御を回避しようとする挙動を示していました。

一部では動物園や公園などについて、利用者がどの入口へ向かう割合が高いかを示すデータの取得にも成功しています。

ただし、研究者が集計したHTTP 2xx応答にはCAPTCHAページも含まれます。AmapのBot対策を常に突破できたことを示すものではありません。

また、エージェントが利用したWebhookの作成元や外向き通信はTencent CloudのIPアドレスから確認されていますが、運営主体や利用モデルをTencentまたはHunyuanと断定できる証拠はありません。

Amapを巡回するAIエージェント群のサマリー

• Swarmchasersが2026年10月4日、Amapを対象とするAIエージェント群の調査結果を公開
• 9月28日～10月4日にAmap関連2,048件のurlqueryレポートを確認
• 10月4日だけで1,810件、213カ所を対象
• 研究者は428件のエージェント生成プログラムを確認
• 同時に最大14の処理が稼働
• 公園、博物館、動物園、病院などの「どの入口へ利用者が向かうか」という比率データを探索
• urlquery.netをブラウザー代わりに利用
• CookieやAlibaba系Bot対策トークンを利用するプログラムを確認
• microlink、r.jina.ai、httpbin系サービスなど複数の外部サービスを経由
• 読み取り可能だったWebhookの大半がTencent Cloud上から作成
• エージェント自身の外向き通信もTencent Cloud香港リージョンから確認
• 一部通信でhysandbox-atsと名付けられたプロキシを確認
• 211件に「claude」のラベルが付いていたが、研究者はClaudeではない可能性が高いと評価
• コード特徴分析ではTencent Hy4、Zhipu GLMなどの類似度が高かった
• 運営主体、モデル、学習・評価ジョブの名称は確認されていない
• エージェント同士が通信・協調する「swarm」の証拠も確認されていない

10月4日だけで1,810件、213カ所を巡回

Swarmchasersによると、Amapを対象とする活動は9月28日に本格化しました。

研究者がurlquery.net上で確認した件数は次の通りです。

10月4日には4～8の処理が並列で動く時間帯が多く、ピーク時には14の処理が同時に実行されました。

最も多い1時間では51カ所が対象になっています。

研究者は、複数のAIが協力して1つの目的を達成する「swarm」ではなく、同種のタスクを多数のエージェントが並行して処理する「agent fleet」と表現しています。

目的は「どの入口を利用者が選ぶか」のデータ取得

今回確認されたエージェント群は、Amap上の公園、動物園、博物館、病院などについて、利用者がどの入口へナビゲーションしているかを示す比率データを探索していました。

研究者が確認した取得結果には、成都動物園について、

• North Gate：71%
• East Gate：23%
• Southeast Gate：6%

といった入口別の割合が含まれていました。

別の施設でも、正門、地下駐車場、東門など複数入口の割合が取得されています。

研究者は最終的に少なくとも5カ所で入口比率の読み取りを確認しています。

なぜこのデータを大量に取得していたのかは特定されていません。

行動パターンからは、特定地点ごとに独立したタスクを繰り返す評価ジョブやタスク生成処理の可能性があるとしていますが、学習用ロールアウトとの区別はできないと説明しています。

urlquery.netを「外部ブラウザー」として利用

今回の活動で特徴的なのが、AIエージェントが自分の実行環境からAmapへ直接アクセスするだけではなく、第三者が運営する公開サービスを経由していた点です。

確認された経路には、

• urlquery.net
• microlink
• r.jina.ai
• httpbin／httpbun系サービス
• Baidu Translate
• Webhookサービス

などがあります。

urlquery.netは、本来Webサイトを解析し、リクエストやスクリプト、通信先などを調査するための公開スキャナーです。

AIエージェントはURLや自ら生成したWebページをurlqueryへ投入し、urlquery側のブラウザーに対象ページを読み込ませ、その結果を取得していました。

自分自身のネットワークから接続できない場合でも、「ブラウザー機能を持つ第三者サービス」を外部ツールとして利用する動作です。

AmapのBot対策トークンやCookieを利用

研究者は、少なくとも8本のプログラムがAmapのスキャン中にブラウザーへ設定されたCookieを読み取り、その値を結果とともに外部のInboxやエコーサービスへ送信していたことを確認しました。

また、多くのプログラムがAlibabaのBot対策で使われる、

• bx-ua
• bx_et
• UMID

などのトークンを生成し、Amapへのアクセスに利用していました。

別のケースでは、ブラウザー自動化サービスを使ってAmapの通信を観測し、API呼び出し時に利用されるヘッダー情報を取得する挙動も確認されています。

Amapの公式利用規約では、Webクローラーやスクレイピングツールを利用したデータ取得や、IP代理、UA偽装などによってセキュリティ保護機構を回避する行為を禁止しています。

「Bot対策を完全突破」とは確認されていない

今回の研究について、「AIエージェントがAmapのBot対策を突破した」とだけ表現すると実態より強くなります。

研究者の広い集計では2,479件の投稿のうち、最大1,600件でHTTP 2xxとレスポンス本文を確認しています。

ただし、この数にはCAPTCHAページも含まれています。

つまり、

「HTTP 200が返った」

「目的のAmapデータを取得できた」

ではありません。

一部地点では実際に入口比率の取得まで成功していますが、すべての試行が成功したわけではなく、Bot対策を恒常的・全面的に無効化したことも確認されていません。

今回確認されたのは、エージェントが複数の迂回経路やブラウザーサービス、Cookie、Bot対策用トークンなどを組み合わせながら、目的データを取得できる方法を反復探索していた点です。

公開されていたAPIキーも試行

10月4日に確認された4つのプログラムでは、Amap JavaScript APIのキーが利用されていました。

研究者によると、確認できたキーは盗まれた秘密鍵ではなく、

• Amap公式のデモ
• Amapの座標取得ツール
• 過去のブログテンプレート

などで公開されていたものが含まれていました。

別の1組についても、対応するセキュリティコードが公開Gitリポジトリ上に存在していました。

Amap公式のWeb Service APIでは、開発者アカウントを作成し、API Keyを取得して利用する仕組みです。

APIキーをブラウザー向けコードへ含めるサービスでは、キー自体がクライアント側から確認できる場合があります。

そのため、APIキー単体を「秘密であること」だけに依存してアクセス制御を設計するのではなく、

• オリジン制限
• APIごとの権限制限
• リクエスト量の制御
• 異常利用検知
• キーのローテーション

などを組み合わせる必要があります。

Tencent Cloud上から実行された痕跡

研究者は、エージェントが結果送信に利用していたWebhookサービスの作成記録を調査しました。

10月4～5日に読み取り可能だったAmap関連Inboxのうち、16件中15件がTencent Cloudのネットワーク（AS132203）から作成されていました。

さらに、PythonやcurlでWebhookへ直接到達した9件のリクエストも、すべてTencent Cloudの香港リージョンから発信されていました。

これらの通信には、

hysandbox-ats

という名称を含むViaヘッダーが付いていました。

研究者はApache Traffic Serverを使ったプロキシとみています。

ただし、Viaヘッダーの名称は運営者側が任意に設定でき、Tencent Cloudは一般利用者も利用できます。

そのため、

「Tencent Cloudから通信している」

「Tencent自身が運営している」

とは判断できません。

「hysandbox」からHunyuanとの関係を推測、ただし確定せず

研究者はhysandbox-atsの「HY」がTencentのAIモデルブランド「Hunyuan」を示している可能性を指摘しています。

また、Tencentが*.hysandbox.tencent-cloud.comの証明書を保有していることも確認しました。

一方で、hysandboxという名称について公開ドキュメントは確認されていません。

研究者はTencent Cloudが公開しているAgent Sandboxも検証していますが、公開サービスから発生した通信では今回のhysandbox-atsと同じ特徴は確認できなかったとしています。

そのため、今回観測された環境をTencentの公開Agent Sandboxと同一視することもできません。

調査レポート自身も、

• 利用モデルを示す記録がない
• 学習ジョブや評価ジョブの名称がない
• Via名称は自己申告
• Tencent Cloudは第三者も利用できる

ことを限界として明記しています。

「claude」ラベルはAnthropic Claudeを意味しない

今回確認されたレポートのうち211件には、「claude」という文字列が付いていました。

しかし、研究者はコード生成時の特徴を複数モデルと比較し、Claudeが生成した可能性は低いと分析しています。

比較した特徴には、

• <!DOCTYPE>の大文字・小文字
• HTMLを1行で出力する頻度
• 文字n-gram
• モデル自身の名称をタグへ入れる傾向

などがあります。

Naive Bayesによる分類では、

• Tencent Hy4：28%
• Zhipu GLM：26%
• Tencent Hy3：21%
• Qwen：17%
• Claude：0%

という結果でした。

ただし、このモデル判定も確定的なものではありません。

研究者自身が、サンプル数が小さく、モデルの自己申告はプロンプトや言語によって変化すると注意しています。

実際、Tencent Hy3にモデル名を尋ねる検証では、36回中29回で自分をClaudeと回答しました。

つまり、AIが出力した「私はClaudeです」という情報や、タスク名に付けられたモデル名だけで実際の基盤モデルを帰属することはできません。

エージェント同士が協調する「swarm」ではない

研究者は今回の活動について、AIエージェント同士が情報を共有し、協力して一つの目的を達成していた証拠は見つけていません。

確認された範囲では、

• 他エージェントのInboxを読み取らない
• ある処理の結果を別エージェントが再利用しない
• エージェント間を結ぶ共有通信チャネルがない
• 同期した方法変更がない

という状態でした。

一部コードのコピーは確認されていますが、それらはurlquery上で公開された後に別の処理から再利用されており、内部のエージェント間通信を示すものではありません。

そのため研究者は「swarm」ではなく「fleet」と呼んでいます。

失敗すると別の外部サービスを探すAIエージェント

今回の調査から見えるのは、AIエージェントが特定のアクセス方法に固定されていない点です。

直接アクセスで目的を達成できない場合、

• 公開Webスキャナー
• ブラウザー自動化サービス
• Webコンテンツ変換サービス
• 翻訳サービス
• 公開Webhook
• AIモデルを備えた第三者サービス

など、別経路を試しています。

10月6日には、Computer Use機能を提供する無料の公開AIサービスを経由し、Amapのデータを取得したケースも確認されました。

これは「AIエージェントのネットワークアクセスを1つの接続先だけ制御すればよい」と考えることが難しくなることを示しています。

企業でAIエージェントを導入する場合も、AIエージェントのセキュリティでは、モデルへの指示だけでなく、利用できるブラウザー、外部API、ネットワーク、ファイル、ツールの権限を制御する必要があります。

外部サービス側にも「AIエージェント対策」が必要に

Webサービス側では、従来のBot対策が、

• 送信元IP
• User-Agent
• Cookie
• JavaScript実行
• CAPTCHA

などを組み合わせて自動アクセスを判定してきました。

AIエージェントが外部ブラウザーや公開プロキシ、Computer Useサービスを利用すると、実際にWebサイトへ接続してくるのはエージェント自身のIPアドレスではなく、第三者サービスのブラウザーになる場合があります。

そのため、単純なIPブロックだけでは、

「大量アクセスを発生させている主体」

と

「実際のHTTPリクエストを送っている主体」

が一致しないケースが増えます。

APIやWebサービスを運営する企業では、

• 単一IPではなくアカウント・セッション単位で異常を検知する
• 短時間に多数の異なる地点・オブジェクトを取得する挙動を検知する
• 公開APIキーに利用元制限を設定する
• リクエストごとに認可を確認する
• API利用量・速度へ上限を設ける
• Bot対策トークンの再利用や異常発行を監視する
• サーバー側で大量データ取得を検知する

といった対策も確認対象になります。

今回の調査で確定していないこと

今回のレポートは暫定版で、研究者自身も複数の限界を明記しています。

現時点で確定していないのは、

• エージェント群の運営主体
• Tencent自身が運用していたか
• 実際に利用されたLLM
• Hunyuanが使用されたか
• 学習、評価、データ収集のどの用途だったか
• 取得したAmapデータがその後何に使われたか

です。

「中国のAI企業がAmapへ攻撃を行った」「TencentのHunyuanがAmapを突破した」と断定できる状態ではありません。

確認されているのは、Tencent Cloud上の実行環境とみられるインフラから多数のAIエージェント型処理が動き、Amapの公開ページやAPIを対象に、複数経路を試しながら目的データの取得を試みていたことです。

出典

• We found a Chinese agent fleet – Swarmchasers
• 高德地图开放平台服务协议 – Amap
• Web Service Overview – Amap
• Tencent Cloud Agent Development Platform Release Notes – Tencent Cloud