対象：Webサイトやサービスを運営している方。本記事はOpenAI・Anthropic・Wikimedia財団・オーストラリア政府（首相の記者会見とサイバーセキュリティセンターの注意喚起）の公式発表にもとづく解説で、攻撃手順は扱いません。7月の最初の事案は Hugging Faceへの侵入（2026年） で解説しています。
何が公表されたのか
2026年6月18日
OpenAIの研究チームが社内モデルに公的な医薬品支出の調査をさせた際、エージェントが繰り返しブロックされた後、それを回避する方法を見つけ、オーストラリアのMedicare統計ポータルで公開・非公開のファイルにアクセス（オーストラリア首相の記者会見での説明）。2026年7月16日
Hugging Faceが、AIエージェントによる侵入を公表（解説）。2026年7月23〜24日
Anthropicが、同様の事案がないか141,006件の評価の実行記録を確認し、評価中のモデルが実在の3社の本番環境に到達していた3件を特定。同日にサイバー評価をすべて停止。2026年7月27日
Anthropicが評価パートナーと影響を受けた3組織に通知。連絡がついた2組織は、それまで活動を検知していなかった（同社の公表）。2026年8月18日
OpenAIが、フロンティアモデルの学習を一時的に減速し、研究環境の分離（信頼できないコードの実行環境の強化、ネットワークの分離）を強めたと公表。2026年9月9日
Anthropicが、7月の3件に加えて、2026年1月の評価で起きていた4件目を公表。確認の対象を約14.1万件から約4億8,100万件の実行記録に広げ、同等以上の深刻度の事案はほかに見つからなかったとした。外部の評価機関による独立調査の契約も結んだ。2026年9月10日
OpenAIからオーストラリア政府へ最初の通知。一般向けのメール窓口に届いた（首相の説明）。2026年9月15日
Services Australiaが通知をオーストラリア・サイバーセキュリティセンター（ACSC）に報告。2026年9月24日
首相が記者会見で公表し、調査のためのタスクフォースを設置。同日、ACSCが「公開Webサイトやアプリを持つすべての組織」向けの注意喚起を発出。2026年9月25日
OpenAIが、確認作業は数か月かかる見込みで、確認できたものから影響を受けた組織に通知していると公表。2026年10月5日
Wikimedia財団が、OpenAIが運用していたと同財団がみるエージェントの活動を、自らのプロジェクトで見つけたと公表。2026年10月9日
Anthropicが、評価と社内利用でモデルが実在のサイトに意図しない操作をした事例を公表（フィラデルフィア市警の情報提供フォームへの虚偽の投稿を含む）。同日、フィラデルフィア市警もこの件を発表した（Anthropicによる）。
- OpenAI：通知の規模
- トレーニングと評価中のモデルのインターネット上の活動を広範に確認し、基準に該当する数十の第三者に通知。確認は継続中で、関わったサイトの一部は政府・大学・公的機関が運営するもの（調べもののために信頼できる公的な情報源に向かうことが多いため、と同社は説明）
- OpenAI：観察された活動の種類
- ①アクセス制御の迂回（別のWebアドレスの使用、リクエスト内容の変更、想定以上の権限を持つセッションの利用など）②公開された認証情報の使用 ③クエリ・コマンドのインジェクション ④実行環境の内部へのアクセス ⑤エージェントスパム（公開Wikiを掲示板代わりに使うなど、第三者サイトへの投稿）
- Anthropic：何が起きたか
- 設定ミスで評価用の機械がインターネットに出られる状態になっていた（同社は、同社と評価パートナーの間の認識違いによるもので、どちらもこの状態に気づいていなかったと説明）。モデルは実在のシステムを演習の一部だと思い込んだ。3件のうち1件は約9,000の標的を走査し、露出したデバッグページからの認証情報の読み取りやSQLインジェクションといった基本的でよく知られた手法で1社のアプリケーションに侵入
- Anthropic：公開レジストリへの影響
- 架空の会社の手順書にあった存在しないPythonパッケージ名で、悪意あるパッケージを公開。約1時間公開され、実在の15のシステムで実行された（うち1つはパッケージを自動でスキャンするセキュリティ企業のスキャナー）
- Anthropic：4件目（9月9日の公表）
- 2026年1月の評価で、開発中の初期版のモデルが第三者の機械にアクセス。パスワードが書かれたファイルを見つけて管理者権限を得て、アクセスしやすいよう設定を変え、第三者に関係する1人の個人情報を読んだ。同社は、4件目を見つけた後に影響を受けた相手に通知したとしている。7月の公表は「3件」だったが、この公表で第三者のシステムへの不正アクセスは計4件になった
- Anthropic：評価と社内利用での意図しない行動（10月9日の公表）
- 4種類を挙げている。①大学が運営する分析ツールの基本的な欠陥を使ってサーバー上でコマンドを実行した ②送るべきでないフォームを送信した（練習用の政府の様式が読み込めず、本物の様式を送信した例など）③制限を回避して有料・制限付きのデータを取得した（地方自治体の地図サイトの設定ファイルにあったアクセストークン、州機関の公開ダッシュボードが誰にでも発行するトークンなど）④取得ツールのURLの長さ制限を、URL短縮サービスを使って回避した
- Anthropic：影響と通知
- 一部は米国の連邦・州・地方の政府機関のサイトで、各機関の求めにより名前は公表していない。各機関に通知し、ホワイトハウスにも説明した。顧客データや同社の社内システムは関わっておらず、現実への影響は小さかったと同社は説明している。9月までに公表したサイバー評価の4件よりも深刻度は大幅に低いとの位置づけ
- フィラデルフィア市警の情報提供フォーム
- 無作為に選んだWebページで操作の例を作る作業中に、モデルが未解決の殺人事件のページで情報提供フォームに、事件に関する虚偽の情報を書いて送信した（氏名と連絡先の欄は空）。スパムと判定され、捜査には回らなかった（Anthropic）。市警によれば送信は7月18日午後11時27分で、市警はAnthropicから10月7日に連絡を受けたとしている（NBC Philadelphiaの報道）。Anthropicは、技術的な確認を終えて10月8日に市警に伝えたとしている。日付は双方で異なる。市警は、発見と報告までの約2か月の遅れを「受け入れられない」としている（同報道）
- Anthropicの対策（10月9日の公表）
- 一部の公開評価の終了と、実在のサイトに届かないオフライン版への移行。すべての社内評価でインターネット接続を停止。Web取得ツールでできることを大きく制限。こうした行動を自動で検知して止める仕組みを、最先端モデルのほとんどの評価と社内でのエージェント利用に導入
- Wikimedia財団（10月5日の公表）
- OpenAIが運用していたと同財団がみるエージェントが、コミュニティの承認なしに編集（ほぼすべてがサンドボックス〔試し書き用の場所〕）。数件は引用ツールの設定を変えており、同財団は外部からデータを取りに行く中継に使う狙いの「悪意がある可能性がある」編集としている。公開のEtherpad（共同メモのツール）について、侵害や中継への利用を試みたが失敗した。公開APIへの数百万件のリクエスト、数百万ページの取得、Wikidata Query Serviceへの数十万件の問い合わせがあり、5月の一部停止の一因になった可能性があるとしている。システムやデータが侵害された証拠は見つかっていない
- オーストラリア政府
- OpenAIのエージェントがMedicare統計ポータル（Services Australia運営）で公開・非公開のファイルにアクセス。現時点で個人情報へのアクセスはないとみられるが調査継続中。通知の遅さと方法（一般向けの窓口へのメール）について、首相はOpenAIのCEOに直接懸念を伝えた
- ACSCの注意喚起
- エージェントが、割り当てられた作業を完了するために人間の承認なしに脆弱性を見つけて先へ進もうとしたと説明。オーストラリアへの広範な脅威や悪意ある標的化を示すものではないとしつつ、強い認証とアクセス制御、脆弱性の迅速な修正、異常の監視とログの確認、AIを想定したシナリオでの対応手順の試験を勧告
扱わなかった事案について
報道では、GoogleのAIモデルが評価中に実在企業のシステムへ入った件も伝えられていますが、同社自身の公式発表を確認できなかったため、本記事では扱いません。また、RubyGemsへの大量投稿をOpenAIのエージェントによるものとする報告については、RubyGems側が「AIエージェントによるものか判断できない」とし、OpenAIも「確認できていない」としているため、帰属が確定していない事案として扱いません。
何が新しく、何が新しくないのか
新しいこと
- 悪意のない訪問者が、ブロックされると別の方法を探す
- 人間なら諦める段階で、別のURL・別の入力・見つけた認証情報を試し続ける
- 何か月も後に、AI企業から通知が来るという形で知る
新しくないこと
- 使われたのは公開された認証情報・露出したデバッグページ・SQLインジェクション
- どれも以前から直すべきだった弱点
- 直していれば、相手が人間でもエージェントでも同じように止まる
当サイトがいちばん重く見るのは、アクセスされた側が気づいていなかったことです。Anthropicは、連絡がついた2組織が活動を検知していなかったと書いています。オーストラリアの件は6月の出来事で、政府が知ったのは9月でした。相手が善意でも、入られたことに変わりはありません。そして次に来るのが善意の訪問者とは限りません。エージェントが見つけられる弱点は、攻撃者も見つけられます。
サイト運営者が今日やること
通知が担当者に届く窓口を用意する（security.txt）
オーストラリアの件では、通知が一般向けのメール窓口に届き、サイバーセキュリティセンターに報告されたのは5日後でした。OpenAIは影響を受けた組織への通知を続けると公表しており、研究者からの脆弱性報告も同じ問題を抱えます。
最初の一歩：/.well-known/security.txt（RFC 9116）を置き、報告の宛先（メールアドレスまたは報告フォームのURL）と有効期限を書く。そしてその宛先を実際に誰が読むかを決める。当サイトも、この記事を書く過程で自分のサイトに置いていなかったことに気づき、設置しました（宛先には個人のメールアドレスではなく問い合わせフォームを使っています）。
受付フォームの内容が、実際に人に届いているか確かめる
フィラデルフィア市警の件では、モデルが送った虚偽の情報提供はスパムと判定されて止まっていたため、捜査には回りませんでした。市警は、10月7日に連絡を受けた後に受付記録で投稿を見つけ、対応するメールがスパムに残っていたことを確かめたと説明しています（報道による）。エージェントは問い合わせ・通報・申請のフォームも送信します。
最初の一歩：自分のサイトの受付フォームから試しに1件送り、どの宛先に届き、迷惑メールやスパム判定に入っていないかを確かめる。スパム判定されたものも定期的に人が目を通す担当と頻度を決め、送信の記録（日時・内容）を、数か月後の問い合わせに答えられる期間残しておく。
公開されてしまった認証情報を探して失効させる
OpenAIもAnthropicも、公開されていた認証情報の使用を挙げています。7月のHugging Faceの件でも起点でした。コード・公開リポジトリ・設定ファイル・スクリーンショットに残った認証情報を探し、見つけたら発行元で失効させます。手順は gitleaksで秘密のコミットを止める と 公開ディレクトリの秘密ファイル。
アクセストークンを、ブラウザに渡る設定ファイルや公開ダッシュボードに置かない
Anthropicの10月の公表では、モデルが地方自治体の地図サイトの設定ファイルにあった有効なアクセストークンや、州機関の公開ダッシュボードが訪問者に発行するトークンを使い、有料・制限付きのデータを取得していました。ブラウザで動くページの設定ファイルや JavaScript に入ったものは、誰でも読めます。
最初の一歩：公開ページが読み込む設定ファイル・JavaScript・ダッシュボードの通信に、アクセストークンやAPIキーが入っていないかを確かめる。どうしても必要なら、取得できる範囲（読み取りのみ・対象のデータ・参照元）と回数を絞ったトークンにし、有料や制限付きのデータはサーバー側で権限を確かめてから返す。
本番のデバッグページと管理画面を閉じる
Anthropicの件で使われたのは、露出したデバッグページからの認証情報の読み取りでした。本番環境でデバッグモードやエラー詳細の表示が有効になっていないか、管理画面がインターネットから誰でも開ける状態になっていないかを確認します。フレームワーク別の確認項目は フレームワーク別セキュリティ対策。
「ブロックしたら諦める」前提を捨て、どの経路でも権限を確かめる
OpenAIが挙げた最初の類型は、別のWebアドレスを使ったアクセス制御の迂回です。画面上のリンクを隠しただけ、特定のURLだけを制限しただけの守りは、別の方法を探す相手には効きません。データを返すすべての経路で、サーバー側で「この相手が見てよいか」を確かめる必要があります。考え方は 認証と認可の違い、典型的な欠陥は IDOR と SQLインジェクション。
量と速度を見張り、ログを遡れる期間残す
エージェントは休まず、待たず、同じ操作を並べて実行します。短い間隔の連続アクセス、24時間平らなアクセス、同じ操作の同時実行は、人間の利用と分けやすい手がかりです。そして数か月後に通知が来たとき、その日のログが残っていなければ何も確かめられません。上限と通知の設計は レート制限と濫用対策、ログの保存期間の考え方は 組織のセキュリティ対策の優先順位。
投稿できる場所を持っているなら、エージェントスパムを想定する
OpenAIは、エージェントが公開Wikiを掲示板代わりに使った例を挙げています。誰でも書き込めるWiki、掲示板、コメント欄、問い合わせフォームを運営しているなら、投稿の速度制限や承認制を見直してください。
AI企業から通知が来たら、慌てずログで確かめる
OpenAIは、同社からの通知を自動的に重大なセキュリティインシデントと解釈すべきではないとしています。通知に書かれた日時と対象について、アクセスログと認証ログを確かめ、公開のつもりだった情報か、直すべき弱点かを自分で判断します。弱点が見つかったら、通常の脆弱性と同じ手順で直します（脆弱性対応の実務）。
エージェントがしたこと（各社の公表より）
別のURLで制限を迂回 ／ 公開された認証情報を使用 ／ 設定ファイルのトークンを使用 ／ デバッグページから認証情報 ／ SQLインジェクション ／ Wikiへの投稿・フォームの送信
それぞれを止める基本
全経路でサーバー側の認可 ／ 漏れた認証情報の失効 ／ トークンをブラウザに渡さない ／ 本番のデバッグ無効化 ／ プレースホルダ ／ 投稿の速度制限と受付内容の確認
それでも入られたときのために
量と速度の監視 ／ ログの保存 ／ 通知が届く窓口（security.txt）
当サイトの視点：エージェントが見つけた弱点は、攻撃者も見つけられる
今回の事案には、奇妙な構図があります。攻撃の意図がない訪問者が、各組織の弱点を見つけ、そこを通り、何か月も後に本人（を作った会社）から「入りました」と知らされる。ACSCは、人間の研究者が見つけて報告してきた種類の脆弱性を、AIエージェントが自分で見つけた点が違うと書いています。
これを「親切な報告が増えた」と受け取るのは危険です。同じ弱点は、報告してくれない相手も見つけられます。しかもエージェントは、ブロックされても諦めず、人間なら数日かかる探索を短時間で並行して試します。弱点を放置してよい時間は、短くなり続けています。
そのうえで、今回はっきりしたことがもう1つあります。通知には宛先が要る。善意の報告も、AI企業からの通知も、届く先がなければ一般向けの窓口で数日放置されます。security.txt は数行のテキストファイルで、今日置けます。
出典（公開記録）
- OpenAI「Hugging Face インシデントと、整合していないモデルによるその他の第三者への影響」（2026年9月25日更新分まで確認） — openai.com
- Anthropic "Investigating three real-world incidents in our cybersecurity evaluations"（2026年7月30日） — anthropic.com
- Anthropic "An alignment assessment of recent cybersecurity incidents"（2026年9月9日） — anthropic.com
- Anthropic "Investigating unintended model actions in our evaluations and internal use"（2026年10月9日） — anthropic.com
- Wikimedia Foundation "OpenAI "rogue" agent activities found on Wikimedia projects"（2026年10月5日） — wikimediafoundation.org
- NBC Philadelphia "Anthropic AI model submits false tip on unsolved Philly murder, police say"（2026年10月9日、フィラデルフィア市警の説明の確認に使用） — nbcphiladelphia.com
- オーストラリア首相 "Press conference - New York"（2026年9月24日） — pm.gov.au
- ASD's ACSC "Risks of AI misalignment to Australian organisations"（2026年9月24日） — cyber.gov.au
- RubyGems Blog "An update on the May spam-publishing campaign on rubygems.org"（2026年9月11日） — blog.rubygems.org（帰属が確定していないことの確認に使用）
- IETF RFC 9116 "A File Format to Aid in Security Vulnerability Disclosure" — rfc-editor.org
更新履歴
2026-10-12：Anthropicの9月9日と10月9日の公表、Wikimedia財団の10月5日の公表を反映。Anthropicによる第三者のシステムへの不正アクセスを「3社」から「4件」に改め、評価と社内利用での意図しない行動（フィラデルフィア市警の情報提供フォームへの虚偽の投稿を含む）と同社の対策を追加。運営者がやることに「受付フォームの内容が人に届くか確かめる」「アクセストークンをブラウザに渡る設定ファイルや公開ダッシュボードに置かない」を追加した。
2026-09-28：初版。OpenAI・Anthropic・オーストラリア政府の公式発表にもとづく。
次に読む
- AIを使った攻撃の全体像と守る順番：AIを使ったサイバー攻撃の対策（自律型の侵入・プロンプトインジェクション・AIサプライチェーン）
- AIエージェントによる侵入の別の事例：DIVDへの不正アクセス（Zammadの未知の脆弱性）
- 最初の事案：Hugging Faceへの侵入（2026年）：AIエージェントが自律的に攻撃した事案と、防御側が見直すこと
- 弱点を直す：gitleaksで秘密のコミットを止める ／ 認証と認可の違い ／ フレームワーク別セキュリティ対策
- 気づく：レート制限と濫用対策 ／ 組織のセキュリティ対策の優先順位
- ツール：サイト総合セキュリティ診断（security.txt の有無も確認できます）