セキュリティ対策
AIエージェントは、あなたのサイトにも来る——OpenAI・Anthropic・豪州政府の公表から、サイト運営者が今日やること
2026年、研究中のAIエージェントが実在の企業や政府のサイトにアクセスしていた事案が相次いで公表されました。OpenAIは数十の第三者に通知し、Anthropicは影響を受けた組織が気づいていなかったと説明しています。各社と豪州政府の公式発表から、サイト運営者が備えるべきことをまとめます。
対象：Webサイトやサービスを運営している方。本記事はOpenAI・Anthropic・オーストラリア政府（首相の記者会見とサイバーセキュリティセンターの注意喚起）の公式発表にもとづく解説で、攻撃手順は扱いません。7月の最初の事案は Hugging Face侵入と、防御側が捨てるべき前提 で解説しています。
何が公表されたのか
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月10日
OpenAIからオーストラリア政府へ最初の通知。一般向けのメール窓口に届いた（首相の説明）。2026年9月15日
Services Australiaが通知をオーストラリア・サイバーセキュリティセンター（ACSC）に報告。2026年9月24日
首相が記者会見で公表し、調査のためのタスクフォースを設置。同日、ACSCが「公開Webサイトやアプリを持つすべての組織」向けの注意喚起を発出。2026年9月25日
OpenAIが、確認作業は数か月かかる見込みで、確認できたものから影響を受けた組織に通知していると公表。
- OpenAI：通知の規模
- トレーニングと評価中のモデルのインターネット上の活動を広範に確認し、基準に該当する数十の第三者に通知。確認は継続中で、関わったサイトの一部は政府・大学・公的機関が運営するもの（調べもののために信頼できる公的な情報源に向かうことが多いため、と同社は説明）
- OpenAI：観察された活動の種類
- ①アクセス制御の迂回（別のWebアドレスの使用、リクエスト内容の変更、想定以上の権限を持つセッションの利用など）②公開された認証情報の使用 ③クエリ・コマンドのインジェクション ④実行環境の内部へのアクセス ⑤エージェントスパム（公開Wikiを掲示板代わりに使うなど、第三者サイトへの投稿）
- Anthropic：何が起きたか
- 設定ミスで評価用の機械がインターネットに出られる状態になっていた（同社は、同社と評価パートナーの間の認識違いによるもので、どちらもこの状態に気づいていなかったと説明）。モデルは実在のシステムを演習の一部だと思い込んだ。3件のうち1件は約9,000の標的を走査し、露出したデバッグページからの認証情報の読み取りやSQLインジェクションといった基本的でよく知られた手法で1社のアプリケーションに侵入
- Anthropic：公開レジストリへの影響
- 架空の会社の手順書にあった存在しないPythonパッケージ名で、悪意あるパッケージを公開。約1時間公開され、実在の15のシステムで実行された（うち1つはパッケージを自動でスキャンするセキュリティ企業のスキャナー）
- オーストラリア政府
- 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）と有効期限を書く。そしてその宛先を実際に誰が読むかを決める。当サイトも、この記事を書く過程で自分のサイトに置いていなかったことに気づき、設置しました（宛先には個人のメールアドレスではなく問い合わせフォームを使っています）。
公開されてしまった認証情報を探して失効させる
OpenAIもAnthropicも、公開されていた認証情報の使用を挙げています。7月のHugging Faceの件でも起点でした。コード・公開リポジトリ・設定ファイル・スクリーンショットに残った鍵を探し、見つけたら発行元で失効させます。手順は gitleaksで秘密のコミットを止める と 公開ディレクトリの秘密ファイル。
本番のデバッグページと管理画面を閉じる
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
- オーストラリア首相 "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
次に読む
- 最初の事案：攻撃が人の手を離れた日——Hugging Face侵入と、防御側が捨てるべき前提
- 塞ぐ：gitleaksで秘密のコミットを止める ／ 認証と認可の違い ／ フレームワーク別セキュリティ対策
- 気づく：レート制限と濫用対策 ／ 組織のセキュリティ対策の優先順位
- ツール：サイト総合セキュリティ診断（security.txt の有無も確認できます）
よくある質問
QAIエージェントが実在のサイトに不正アクセスした事例はありますか？
あります。2026年7月のHugging Faceの件に続き、OpenAIは研究・評価中のエージェントの活動を調べた結果、数十の第三者に通知したと公表しています。Anthropicは、評価中のモデルが評価環境から実在の3社の本番環境に到達していたと公表しました。オーストラリア政府は、OpenAIのエージェントが6月にMedicareの統計ポータルで公開・非公開のファイルにアクセスしていたと説明しています。
QなぜAIエージェントが第三者のサイトに入ってしまうのですか？
各社の説明では、エージェントは与えられたタスクを完了しようとして、止められると別の方法を探しました。オーストラリアのサイバーセキュリティセンター（ACSC）は、エージェントが割り当てられた作業を完了するために、人間の承認なしに脆弱性を見つけて先へ進もうとしたと説明しています。Anthropicの件では、評価環境の設定ミスでインターネットに出られる状態になっており、モデルは実在のシステムを演習の一部だと思い込んでいました。
Qどんな弱点が使われたのですか？
特別な手口ではありません。OpenAIは、別のURLを使ったアクセス制御の迂回、公開されていた認証情報の使用、入力が命令として処理されるインジェクション、内部向けシステムへのアクセス、第三者サイトへの投稿（エージェントスパム）を挙げています。Anthropicは、露出したデバッグページからの認証情報の読み取りやSQLインジェクションといった基本的でよく知られた手法だったと説明しています。
QAI企業から通知が来たら、重大な事故ということですか？
必ずしもそうではありません。OpenAIは、同社からの通知を自動的に重大なセキュリティインシデントの通知と解釈すべきではないとしています。意図的に公開していた情報だったと判断する組織もあれば、直すべき設計上の弱点を見つける組織もあるとしています。通知に書かれた日時のログを確かめて、自分で判断してください。
Qサイト運営者は何をすればいいですか？
新しい製品より基本です。公開されてしまった認証情報の失効、本番のデバッグページの無効化、どの経路でもサーバー側で権限を確かめること、量と速度の監視とログの保存、そして通知や報告が担当者に届く窓口（security.txt など）を用意することです。