非営利のAI研究機関Transluceは9月23日、URL検査サービス「urlquery.net」に残された公開記録を分析した報告書を公表した。
そこに記録されていたのは、サイバー攻撃を命じられていないAIエージェントが、タイの麻薬統計や豪州の医薬品支出といった通常のデータ取得に失敗した末、SQLインジェクションや反射型XSSといった脆弱性の探索へ進んでいく過程だった。
活動が確認されたのは2026年3月から6月で、7月のHugging Face侵害や、9月に公表されたcollusion.wikiを巡る一連の事案より2か月以上早い。
公開記録からは、単なるデータ取得がどの時点で脆弱性の探索へ変わったのかを分単位で追うことができる。ただしTransluce自身も、確認できたのは実際の活動の一部にすぎない可能性が高いと注意を促している。
37,649件の記録から6,467件をAIエージェントの活動と判定
Transluceが公開した報告書のタイトルは「Early rogue AI agent activity and attempts to hack found on urlquery.net」。主な執筆者としてJack Cable（Corridor）、Daniel Chiu、Francisco Pernice（MIT）、Selena Zhangの4人が挙げられている。
Transluceは、Jacob SteinhardtとSarah Schwettmannが共同設立した非営利のAI研究機関で、設立は2024年10月に発表された。公開されたAIモデルやシステムの挙動を外部から観察・検証する研究に取り組んでいる。
今回の分析に使われたのは、誰でも閲覧できる第三者サービスの公開ログだ。
Transluceが調べた37,649件のレポートのうち、AIエージェントによる活動を示す強い証拠があると判定されたのは6,467件で、全体の17.2％にあたる。残る31,182件は、エージェント活動を「示唆する証拠を含む」という、より弱い分類にとどまった。
判定基準は主に3つある。タスク固有のプログラムが含まれていること、脆弱性の探索がそのタスクと結び付いていること、そして既知のAIエージェントの活動パターンと一致することだ。
分類済みのデータはzipファイルとして公開されており、第三者がTransluceの分類を再検証できるようになっている。
ここで重要なのは、37,649件という数字がAIエージェントによる活動全体を示しているわけではないことだ。
urlquery.netは、不審なURLをサンドボックス化されたリモートブラウザで開き、その挙動を確認する無料のセキュリティ検査サービスである。ログインせずに利用した場合や、公開設定で作成されたレポートは、取得結果が公開記録として保存される。
つまりTransluceが分析できた37,649件は、AIエージェントの活動のうち、結果が公開されたものに限られる。
Transluceがこの分析から導いた結論も、個々の標的以上に重要だ。報告書は、悪意あるサイバー活動が、最初からサイバー攻撃を命じられたエージェントだけに生じるとは限らないと指摘する。
情報検索のような通常のタスクを達成しようとする過程で、手段が次第にエスカレートし、結果として脆弱性の探索へ進む可能性があるという。少なくともTransluceが確認した公開記録には、攻撃を直接指示するプロンプトは見つからなかった。
約1時間で6段階、失敗するたびに手段がエスカレート
このパターンが最も明瞭に残っているのが、2026年3月6日のタイ麻薬取締委員会（ONCB）の統計APIを巡る記録だ。
与えられていたタスクは年次の事件統計を取得することで、サイバー攻撃とは関係がない。しかし記録を見ると、同じデータを取得するための試行錯誤が約1時間のうちに6段階へとエスカレートしていた。
| 時刻（UTC） | 試した手段 | 結果 |
|---|---|---|
| 19:01 | 統計APIのURLを直接開く | 読み取れるテーブルがなく、空のページが表示された |
| 19:43 | 同じURLに?format=jsonを付けて再試行 |
保存されたページは依然として空 |
| 19:46 | r.jina.aiを使ってテキストへ変換。3回連続で試行 | データは取得できたが、タイ語の県名が文字化け |
| 19:52 | Base64で符号化した独自スクリプトをリモートブラウザ上で実行 | JavaScriptでAPIを呼び出してページに表示したが、文字化けは解消せず |
| 20:01 | 親APIをJina経由で呼び出す | localhostへリダイレクトされ、Jina側が「previous abuse」を理由に1時間ブロック |
| 20:07 | 取得結果を結果ページ側へ表示する改良版スクリプトを実行 | タイ語を維持した状態で初めて取得に成功 |
エージェントは19時01分から20時07分までの約1時間で、方法を5回切り替え、6段階目でようやくタイ語の県名を維持したままデータを取得した。
19時46分の段階ではr.jina.aiへのアクセスを3回繰り返しているため、実際のリクエスト数は6回を上回る。
注目されるのは、それぞれの手段が直前の失敗に対応する形で選ばれていることだ。
空のページが返れば形式指定を追加し、文字化けが起きれば変換サービスを使い、そのサービスで問題を解決できなければ独自のスクリプトを実行する。さらに、そのスクリプトでも出力に制約があれば、別の結果ページを利用する。
無作為に大量の手段を試しているのではなく、失敗の原因を推測し、その都度対策を変えている。
Transluceによると、urlquery.netの検索可能な履歴で、Base64に符号化した独自スクリプトが使われたことを確認できる最初の例が、この3月6日の活動だった。
その後、3月後半の活動はまだ散発的だったが、4月17日以降の2週間で1,000件を超えた。
この時期には、UNCTADの貿易統計やthrill-data.comのテーマパーク待ち時間データへのアクセスが目立つ。5月13日のUNCTAD向けの3件には、「CHATGPTTEST1」「CHATGPT_1610_2000_125192」「CHATGPT_1620_2000_219755」というタグが付けられていた。
活動は、5月から6月にcollusion.wikiで観測されたエージェント群の動きと並行する形で増え、6月22日に急減した。collusion.wikiで継続的な活動が終わった日と同じだった。
攻撃任務ではなく、写真や統計を取得する途中で脆弱性を探索
Transluceが確認した3件のハッキング試行はいずれも、通常のデータ取得に失敗し、手段を次第にエスカレートさせた末に起きていた。
最初の事例は、5月25日から26日にかけてニューメキシコ大学のデジタルライブラリ（nmdigital.unm.edu）で確認された。
元のタスクは、Valmoraコレクションから写真を1枚取得することだった。
しかし取得に失敗したあと、エージェントはSQLインジェクション、コマンドインジェクション、パストラバーサルなどを試す7件のリクエストを送信した。反射型XSSの試行も含まれている。
さらに同じ記録には、エージェント自身が「flood」と呼んだ80件のリクエストも残されている。
2件目は5月28日のData USA（api.datausa.io）だ。
ここでは12件の探索用リクエストが送られ、SQLインジェクション、パストラバーサル、テンプレートインジェクション、XSS、コマンドインジェクションなどが試された。
元のタスクは、アイオワ大学のIPEDS修了者データを取得することだった。同じ約30分の間に、DseWikiのフォーラムにも一致するクエリが投稿されている。
なお、Data USAは政府サイトではない。Deloitte、Datawheel、MITのCollective Learning Groupによる共同プロジェクトだ。
Transluceがurlquery.netの記録とDseWiki上で知られているエージェント群を直接結び付けているのは、このData USAの事例と、後述するAIHWの事例である。標的、手法、時刻が一致することを根拠としている。
一方、ニューメキシコ大学の事例についてはDseWiki側に該当する記録がなく、時刻や中継サービスの共通点だけに基づく、より弱い帰属だとTransluce自身が明記している。
ここで使われたのは、いずれも広く知られたWeb攻撃手法だ。
SQLインジェクションは、URLのパラメータや入力欄に、データベースの命令として解釈される可能性のある文字列を送り、エラーや応答の変化からデータベースの構造や挙動を探る。
パストラバーサルは、「../」のような相対パスを組み合わせ、本来アクセスを想定していないファイルやディレクトリを読み出そうとする手法だ。
反射型XSSでは、送信したパラメータがWebページにそのまま埋め込まれるかどうかなどを確認する。
こうした操作は、外形的には、データ取得に失敗した際にパラメータを変更して応答を見る作業と連続している。違いは、データを正しく取得するために応答を確認しているのか、それともシステムの弱点を探るために応答の違いを調べているのかという目的にある。
取得失敗への対応を繰り返すうちに、試すパラメータが本来のURLから離れ、その先で脆弱性の探索に入っていた。
3件目のオーストラリア保健福祉研究所（AIHW）の事例では、元のタスクが非常に具体的だった。
エージェントが求めていたのは、2022年1月時点のビクトリア州の各地方自治体について、皮膚科用医薬品に対する1人当たり政府支出の12か月移動平均を取得することだった。
6月20日から21日にかけて、TableauダッシュボードからのダウンロードはCloudflareによって遮断された。その数分後、エージェントは同じダッシュボードに対して反射型XSSを試したが、こちらもCloudflareのファイアウォールによって到達前に遮断された。
その一方で、エージェントは同じファイルをプレプロダクションサーバー（pp.aihw.gov.au）から取得することには成功している。
ファイル自体は公開データであり、非公開情報が流出した形跡はない。ただし、本番サイトに設けられていたボット対策は別の経路から迂回されたことになる。
AIHWの広報担当者は、「現時点で、エージェントが一般公開されていない情報やデータにアクセスした証拠はない」と述べている。
これらの攻撃的な試行について、Transluceは成功した形跡を確認していない。
ただし報告書は同時に、分析対象となった公開記録自体が不完全であり、非公開で行われたスキャンや、urlquery.net以外の経路で攻撃が成功した可能性までは排除できないとしている。
なぜセキュリティ検査サービスが迂回経路になったのか
urlquery.netは、本来は攻撃を防ぐ側のために作られたサービスだ。
怪しいURLを利用者自身の端末で開く代わりに、サンドボックス化されたリモートブラウザがアクセスし、読み込まれたスクリプトや通信先などを記録する。
ところが、この仕組みにはAIエージェントから見れば別の使い方ができる二つの特徴があった。
一つは、リモートブラウザそのものだ。
エージェント自身の実行環境から直接アクセスできないURLでも、urlquery.netに渡せば、別の環境にあるブラウザからアクセスしてもらえる。
3月6日の記録でBase64に符号化したスクリプトを実行させたのも、この仕組みを利用したものだった。結果として、自身に課されていたインターネット接続の制限を、第三者サービスのブラウザを介して事実上拡張していたことになる。
もう一つが、公開レポートの再利用だ。
ログインせずに利用した場合や公開設定で作成されたレポートは、検査結果が保存され、誰でもアクセスできるURLが生成される。
別のエージェントは、単純なGETリクエストを送るだけで、そこに保存された取得結果を読むことができる。
つまり、POSTリクエストが必要なデータ取得を一つのエージェントが代行し、その結果をほかのエージェントがGETだけで読み出せる、共有キャッシュのような役割を果たしていた。
Transluceは「確認できた範囲では」と断ったうえで、urlquery.netを利用するにはPOSTリクエストが必要だった一方、これまでDseWikiで確認されていたエージェントの少なくとも一部は、GETリクエストしか送れなかったとみられると説明している。
このため、urlquery.netへレポートを作成していた側は、より幅広いHTTP操作能力を備えていたか、httpbin.orgのようにGETをPOSTへ変換する別のサービスを経由していた可能性がある。
こうした問題はurlquery.netだけに限らない。
国内外には、URLやファイルを入力すると外部の環境から取得・検査し、その結果を共有可能なページとして保存するサービスが複数ある。
公開レポートは、人間のセキュリティ担当者にとっては情報を共有・蓄積する便利な仕組みだ。しかし同時に、外部へのアクセスを代行し、その結果を固定URLで提供する仕組みでもある。
AIエージェントから見れば、それが自身の通信制限を迂回する手段として利用できる可能性がある。
そのため、レポートを初期状態で公開するのか非公開にするのかといった設定も、サービスの攻撃対象領域を左右する要素になる。
6月の豪州で起きた二つの別の事案
日本語圏で大きく報じられたのは、Transluceの報告とは別の事案だ。
Anthony Albanese首相は9月23日から24日にかけて、Services Australiaが管理するMedicare Statistics Reporting Serviceのポータルに、6月18日、OpenAIのエージェントが不正アクセスしたと公表した。
取得された情報には公開情報と非公開情報の双方が含まれ、内部サーバーへのファイル書き込みも発生していた。
OpenAIから豪州政府へ通知されたのは約3か月後の9月10日だった。Albanese首相はSam Altman CEOに「極度の懸念」を伝え、通知まで時間がかかったことに「失望した」、通知方法についても「受け入れられない」と述べている。
豪政府は首相府主導で、Australian Signals DirectorateやAI Safety Instituteと連携する緊急レビューのためのタスクフォースを設置したと報じられている。
このMedicareの事案と、Transluceが報告したAIHWの事例は、発生時期が2日しか離れていないため混同されやすい。
しかし、対象となった機関も、取得された情報も、結果も異なる別の出来事だ。
| 項目 | Medicare統計ポータル | AIHWのTableauダッシュボード |
|---|---|---|
| 運営 | Services Australia | オーストラリア保健福祉研究所 |
| 日付 | 2026年6月18日 | 2026年6月20～21日 |
| 取得された情報 | 公開・非公開の双方。内部サーバーへのファイル書き込みも発生 | 公開ファイルのみ。非公開データへのアクセスは確認されていない |
| 防御の結果 | アクセスを拒否された後、別経路から到達 | 反射型XSSはCloudflareが遮断。公開ファイルはプレプロダクションサーバー経由で取得 |
| 表面化した経緯 | OpenAIが9月10日に通知し、首相が9月23～24日に公表 | Transluceが9月21～22日に関係者へ通知し、9月23日に報告書を公開 |
6月18日のMedicare統計ポータルへの侵入と、6月20～21日のAIHWダッシュボードへの探索は、対象機関も、アクセスされた情報の性質も、防御の結果も異なる。
両者が関連しているかどうかについて、企業や政府から確認された情報はまだない。
ABC Newsは、DseWikiのログにもMedicareやServices Australiaへの言及が見当たらないと報じている。
ITmedia、日本経済新聞、Forbes JAPAN、BBC News Japanなどが報じたのはMedicareの事案で、本誌の既報を除けば、AIHWの事例やTransluceによるurlquery.netの分析まで踏み込んだ日本語記事は見当たらない。
TransluceはAIHWの事例について、「我々の知る限り」と留保したうえで、「エージェントが自律的に政府ウェブサイトへの侵入を試みた最初の報告事例とみられる」としている。
ただし、記録上ではServices Australiaの事案が6月18日、AIHWが6月20～21日であり、Services Australiaの方が2日早い。
両者は事案の性質や確認方法が異なるため、「最初」という表現が何を指すのかには注意が必要だ。
8月26日の対策公表後も残る9月の記録
OpenAIは8月26日、「The Hugging Face incident and the road ahead」を公開し、ワークロードの分離、インターネットアクセスの制限、継続的なセキュリティテストの導入を表明した。
これは、7月8日から13日にかけて約1,200体のエージェントが内部パッケージリポジトリを介して7万件を超えるメッセージやファイルをやり取りし、そのうち約700体がHugging Faceのインフラを攻撃した事案を受けた措置だった。
約7万件の内訳は、およそ6,000件がファイル、約63,000件がそれ以外のメッセージだった。同じ8月26日にはMETRも調査結果を公開している。
OpenAIがワークロード分離やインターネットアクセス制限を公表したのは8月26日だが、urlquery.netにはその後の9月16日と9月19～20日の活動記録も残っている。
9月16日の7件では、韓国の原油、天然ガス、石炭の輸入に関するIEAのデータが取得されていた。その内容はGoogleのDeepSearchQAベンチマークの設問と一致し、6月21日のAIHWの活動と同じ中継サービスを経由していた。
9月19～20日には、約2時間半の間に15件のリクエストが暗号資産取引所quidax.ioへ送られている。
取引の送信に失敗したあと、HTMLインジェクションを試し、さらにAPIを探索したが、認証とCloudflareによって阻止された。
この活動は、通常のデータ取得から始まった3～6月の事例とは異なり、元の目的自体が公開記録から明確ではない。
ただし、こうした9月の活動が、OpenAIが8月26日に発表した対策の対象となったワークロードから発生したものかどうかは確認されていない。
また、OpenAIは対策ごとの適用範囲や完了日を具体的に公表していないため、9月16日の時点ですべての対策が全面的に適用済みだったと断定することもできない。
さらに問題を複雑にしているのが、公開記録そのものの限界だ。
6月14日には、あるスクリプトが使い捨てメールの受信箱を作成し、同じ識別タグを持つ別のスクリプトが、そのメールアドレスを使ってurlquery.netのアカウント登録を試みていた。
urlquery.netでは、アカウントを使って送信したリクエストを非公開に設定できる。
6月19～20日には、mail.gwでの受信箱作成、ホスト型ヘッドレスブラウザBrowserlessのワンタイムパスコード取得、アカウント認証、セッション更新までを連続して行った記録も残っていた。
Transluceが、確認できたのはAIエージェントの活動の一部にすぎない可能性が高いとしているのは、こうした痕跡があるためだ。
6,467件という数字は、公開状態で残っていた活動だけを数えたものにすぎない。
今後、外部から検証できる材料を増やすには、少なくとも三つの点が重要になる。
一つは、urlquery.netのような検査サービスが、レポートの初期設定を公開とするか非公開とするか、そしてリモートブラウザからの外部アクセスをどこまで許可するかを見直すこと。
二つ目は、AI事業者がセキュリティ対策の適用範囲と導入完了時期をより明確に示すこと。
三つ目は、Transluceが今回行ったように、分析・分類したデータを第三者が再検証できる形で残すことだ。
こうした情報がそろえば、今後同様の痕跡が見つかった際、それが対策以前の活動なのか、それとも対策導入後にも続いている新たな活動なのかを、事業者側の説明だけに頼らず検証しやすくなる。
