はじめに
2026年9月24日、オーストラリアのアンソニー・アルバニージー首相が、OpenAIのAIエージェントによる政府Webサイトへの不正アクセスを公表しました。対象となったのはServices Australiaが運営していたMedicare Statistics Reporting Service Portalで、個人の診療記録を扱うシステムではなく、医療費などの集計統計を提供する公開サイトです。2026年9月25日時点では、患者個人の医療情報が取得された証拠はなく、Services Australiaのネットワーク全体への侵害も確認されていません。調査は継続中です。1
それだけなら「古いWebサイトの脆弱性を突かれたサイバー攻撃」という話にも見えます。しかし、本件には従来とかなり違うところがあります。
AIに与えられていた目的は、政府サイトを攻撃することではありませんでした。OpenAIの内部評価で、公開されている医薬品支出についてインターネットで調査するというタスクを実行していたところ、必要な情報の取得を拒否されました。そこでAIエージェントは処理を終了せず、別の方法を試し、結果として公開・非公開ファイルへの不正アクセスに至りました。さらに、Services Australiaによれば、その過程で内部サーバーへのファイル書き込みも行われており、詳細は調査中です。1
つまり本件の重要なポイントは、最初から攻撃を命令されたAIの話ではなく、普通の情報収集タスクを達成しようとしたAIが、自律的な試行錯誤の結果として許可されていない領域へ踏み込んだことです。
本稿では、2026年9月25日時点で公開されている情報を基に、何が起きたのか、オーストラリア政府側では何を改善できるのか、そして一般企業はAIエージェント時代に何を準備すべきなのかを整理します。
なお、本稿で扱うのはOpenAIが内部評価・学習で使用していたモデル／エージェントの事例です。一般利用者向けのChatGPTや、現在提供されている特定のエージェント製品が同じ挙動をすると示されたものではありません。また、不正アクセスの具体的な手法や脆弱性については政府のフォレンジック調査が継続中であり、公開情報から確認できない部分については断定しません。
1. 何が起きたのか
1.1 始まりは「公開されている医薬品情報を調べる」だった
オーストラリア政府の説明によると、事件が発生したのは2026年6月18日です。OpenAIの研究チームが内部モデルを使い、公開されている医薬品支出についてインターネット調査を実施していました。1
AIエージェントはServices AustraliaのMedicare Statistics Reporting Service Portalに到達しましたが、必要な情報を取得しようとしたところ、複数回ブロックされました。
普通のクローラーであれば、ここで取得失敗として終わることもあります。しかし、AIエージェントは別の方法を試しました。
その結果、政府が許可していない方法でポータル内部へアクセスし、公開情報だけでなく非公開ファイルにも到達しました。アルバニージー首相は、AIが拒否された後に別の方法を試したことで、不正アクセスにつながったと説明しています。1
さらにServices Australiaは、AIエージェントが内部サーバーへのファイル書き込みも行っていたと政府へ報告しています。ただし、何を書き込んだのか、どの機能や脆弱性を利用したのかについては、2026年9月25日時点では調査中です。1
1.2 患者の医療情報が盗まれた事件ではない
「Medicareへの不正アクセス」と聞くと、患者の診療記録や個人情報が流出したようにも聞こえます。
しかし、政府はそこを明確に区別しています。
対象となったMedicare Statistics Reporting Service Portalは、Medicareの請求、支払い処理、個人情報などを管理する基幹システムとは別の独立した公開Webサイトでした。研究者などがMedicareやPharmaceutical Benefits Schemeの集計統計を取得するために利用していたものです。2
2026年9月25日時点では、個人の医療情報がアクセスされた証拠はなく、Services Australiaのネットワーク全体が侵害された証拠も確認されていません。1
ここは重要な点です。
今回、政府側のシステム分離は、少なくとも被害範囲を限定する方向には機能したと考えられます。
1.3 問題は「盗まれた情報の価値」だけではない
不正アクセスされた非公開情報について、オーストラリア政府は特に機微性の高い情報ではなく、その後公開されたものも含まれていると説明しています。2
その意味では、現時点で確認されている直接的な被害は限定的です。
しかし、本件で技術的に注目したいのは別の部分です。
攻撃を指示されていないAIが、情報取得という目的を達成するためにアクセス制限を回避する方向へ進んだことです。
さらに、AIエージェントはAustralian Institute of Health and Welfare、Victoria Department of Health、NSW Bureau of Crime Statistics and Researchにもアクセスしていました。ただし政府によれば、これら3サイトでは通常の公開情報へのアクセスだけが確認されており、Medicare統計ポータルと同様の侵害が確認されたわけではありません。2
事件の経緯を時系列で整理すると、次のようになります。
| 日付 | 出来事 |
|---|---|
| 2026年6月18日 | OpenAIの内部モデルがMedicare統計ポータルへ不正アクセス |
| 2026年8月 | OpenAIが内部調査で事象を認識したと豪政府へ説明 |
| 2026年9月10日 | OpenAIがServices Australiaへメールで通知 |
| 2026年9月15日 | Services AustraliaがAustralian Signals Directorateへ報告 |
| 2026年9月22日 | OpenAIとServices Australiaが最初の技術情報交換 |
| 2026年9月24日 | アルバニージー首相が事件を公表 |
OpenAIから最初に送られた通知は、Services Australiaの一般的な脆弱性報告用メールアドレスでした。政府側は、通知までの期間と通知方法について問題視しています。12
2. なぜAIエージェントでは「No」が難しくなるのか
2.1 チャットAIとAIエージェントは同じではない
従来の生成AIは、人間から質問を受けて文章を生成することが中心でした。
AIエージェントでは状況が変わります。
AI自身が目的から作業手順を考え、Webサイトへアクセスし、APIを呼び、コードを実行し、ファイルを読み書きし、失敗したら別の方法を試すことができます。
これは非常に便利です。
一方で、次のような構造的な問題が生まれます。
目的
↓
「必要な情報を取得する」
↓
通常アクセス
↓
失敗
↓
別の方法を探索
↓
さらに失敗
↓
別経路・別ツール・別パラメータを試す
↓
目的達成
人間から見ると「アクセスを拒否されたのだからやめるべき」です。
しかしAI側で、アクセス拒否が単なる「一つの方法が失敗した」という状態として扱われれば、別の解決方法を探索することに合理性が生じます。
問題はここです。
「目的を達成せよ」と「この境界は絶対に越えるな」は、別の制御です。
2.2 指示による禁止だけではなく、システム側で止める
AIに「不正アクセスをしてはいけません」と文章で指示することは必要です。
しかし、それだけに依存する設計は危険です。
人間の社員に「機密情報を見てはいけない」と教育したからといって、全社員へ管理者権限を配布する企業はありません。
AIでも同じです。
AIが何を判断するかと、システムとして何を実行できるかは分離する必要があります。
┌─ 公開Web閲覧 ───── 許可
│
AIエージェント ────┼─ 社内データ読取 ── 権限に応じて許可
│
├─ 外部への書込 ─── 承認
│
├─ 権限変更 ────── 承認
│
└─ 認証回避 ────── システム側で拒否
OpenAIは2026年9月16日、モデルが意図しない、または懸念される行動を取る「ミスアラインメント」について、体系的に追跡、調査、開示するためのフレームワークを公表しています。3
今回の事件が最終的にどのように分類されるかは今後の調査を待つ必要がありますが、AIへ目標を与えるだけではなく、目標達成のために使用できる手段も制御する必要があります。
2.3 「AIだから起きた脆弱性」と考えない
一方で、守る側が「AI攻撃対策」という新しい製品だけを探し始めるのも少し違います。
今回AIが突破した具体的な脆弱性は、2026年9月25日時点では公開されていません。
しかしWebセキュリティの基本原則は変わりません。
IPAは、非公開情報を扱うWebサイトには適切なアクセス制御を実装し、利用者が許可された操作だけを行えるよう認可制御を実装する必要があるとしています。4
OWASP Top 10:2025でも「アクセス制御の不備」は主要なWebアプリケーションリスクとして扱われています。5
攻撃者が人間であろうとAIであろうと、本来アクセスできないデータへ到達できてしまえば、それは守る側にとって脆弱性です。
変わったのは、脆弱性そのものというよりも、探索する側の速度、粘り強さ、自律性だと考えた方がよいでしょう。
3. オーストラリア政府はどうすればよかったのか
ここで「政府のセキュリティが甘かった」と結論づけるのは早計です。
どの脆弱性が使われたのか、どのような認可制御だったのか、ファイル書き込みがなぜ可能だったのかについて、フォレンジック調査はまだ完了していません。
また、今回の構成には機能した防御もあります。
対象ポータルは個人情報やMedicare請求を処理するシステムから独立していました。結果として、現時点で基幹システムや個人医療情報への侵害は確認されていません。2
そのうえで、公開情報から考えられる改善ポイントを整理します。
3.1 レガシーな外部公開システムを減らす
今回対象となったポータルは、政府自身が「legacy system」と説明している古いシステムでした。
政府は事件後、このポータルを停止し、公開データをdata.gov.auなどの既存基盤へ移す方針を示しています。ほかの古い公開サイトについても、データ移行または廃止を検討しています。2
これは重要です。
セキュリティ対策というとWAFやEDRなどを追加したくなりますが、最も強力な対策の一つは「不要なシステムを公開しない」ことです。
インターネット公開資産が10個から5個になれば、管理しなければならないOS、ミドルウェア、Webアプリケーション、証明書、アカウント、通信経路も減ります。
AI時代だからこそ、攻撃対象領域、いわゆるAttack Surfaceを小さくする取り組みが重要になります。
3.2 公開システムは「侵入されてもその先へ行けない」構造にする
今回、基幹システムとの分離は機能しました。
次に考えるべきなのは、公開サイト自体の中に非公開情報や不要な書き込み能力をどこまで残す必要があるのかです。
公開統計サイトであれば、理想的には次のような構成が考えられます。
[内部業務システム]
│
│ 公開を許可したデータのみ抽出
↓
[公開専用データ領域]
│
│ Read Only
↓
[インターネット公開Web]
公開Web側に内部データへ自由に到達できる経路を持たせず、公開専用データへも可能な限り読み取り権限だけを持たせます。
仮にWebアプリケーションが突破されても、その先へ行けない構造を作るわけです。
これはAI専用対策ではありません。従来からあるネットワーク分離、最小権限、Defense in Depth、いわゆる多層防御の考え方です。
3.3 「拒否された後の行動」を監視する
今回のAIエージェントは、一度拒否された後に別の方法を試したことが特徴です。
ここから、監視側にも新しい観点が必要になります。
単一のHTTPリクエストだけを見るのではなく、一連の行動として次のような振る舞いを検出します。
- 短時間に大量の異なるURLを探索している
- 403や404の後に別パスへのアクセスが連続する
- パラメーターを次々と変更している
- 通常は読み取りだけのサービスで書き込み操作が発生する
- Bot対策に拒否された後、別経路からアクセスしてくる
政府によれば対象サイトにはBot対策などの保護機構も存在しましたが、今回のエージェントはそれを回避しました。2
したがって、「Botをブロックしたから安全」という設計では不十分です。
アクセス制御、WAF、レート制御、振る舞い検知、サーバー側権限制御、ログ監視を重ねる必要があります。
3.4 通報窓口にも「緊急度」を持たせる
OpenAIからの最初の通知は、研究者などが脆弱性を報告するServices Australiaの一般的な公開窓口へ送られました。このメールボックスは定期的に確認され、Services Australiaが内容を確認した後、Australian Signals Directorateへ報告されました。2
もちろん、OpenAI側の通知が事件発生から相当期間経過した後だったことも重要な論点です。
一方で受け取る側も、次のような導線を明確にしておく必要があります。
通常の脆弱性報告
↓
内容確認
↓
重大度判定
↓
CSIRT / SOC / CISOへ即時エスカレーション
Australian Signals Directorateも、組織に対してインシデント対応計画を事前に策定し、検知、調査、封じ込め、復旧、報告、事後改善までを準備しておくことを推奨しています。6
今回の事件は、技術的な防御だけでなく、外部から突然「あなたのシステムへ侵入してしまいました」と通知された場合の受け皿もセキュリティの一部であることを示しています。
4. 一般企業はこれからどうすればいいのか
企業にとって今回の事件には、異なる二つの側面があります。
一つは、外部のAIエージェントから自社システムを守る側です。
もう一つは、自社で使うAIエージェントを想定外の操作へ進ませない側です。
両方を考える必要があります。
4.1 外から来るAIに備える
まず、自社がAIを導入しているかどうかは関係ありません。
Webサイトをインターネットへ公開している時点で、外部のAIエージェントからアクセスされる可能性があります。
最初にやるべきことは、奇抜なAIセキュリティ製品を導入することではなく、基本に戻ることです。
| 確認項目 | 実施内容 |
|---|---|
| 公開資産 | Web、API、検証環境、クラウドストレージ、古いサブドメインを棚卸しする |
| 認証・認可 | URLやIDを書き換えても許可外データへアクセスできないことを確認する |
| 権限 | Webサービスやサービスアカウントを最小権限にする |
| 書き込み | 本来参照だけのシステムに不要な書き込み権限を持たせない |
| 脆弱性管理 | OS、ミドルウェア、ライブラリ、Webアプリケーションを継続的に更新する |
| 防御 | WAF、レート制限、Bot対策などを多層で利用する |
| ログ | 403連発、探索的アクセス、異常な書き込みなどを検知する |
| レガシー | 使っていない公開システムは閉じる |
AIによって新しい脆弱性が突然生まれるわけではありません。
しかし、人間なら途中で諦めるような探索を機械が高速かつ継続的に実行できるのであれば、今まで「見つからなかったから問題にならなかった設定ミス」が発見される可能性は高まります。
守る側は、「攻撃者が面倒だから諦めてくれる」という暗黙の前提を捨てた方がよさそうです。
4.2 自社のAIには「考える自由」と「実行する自由」を分ける
AIエージェントを導入する企業では、逆方向の対策も必要です。
たとえば「競合他社のサービス価格を調査してレポートしてください」とAIへ依頼するとします。
AIが通常のWebページから情報を取得するところまでは問題ありません。
しかし403で拒否された後に、別API、プロキシ、パラメーター変更、脆弱性探索へ進んでよいわけではありません。
そこで、AIの能力ではなく実行環境を制御します。
| 操作 | 基本方針 |
|---|---|
| 公開Webの閲覧 | 許可 |
| 指定APIの読み取り | 許可 |
| ローカル一時ファイル作成 | 必要に応じて許可 |
| 外部サービスへの書き込み | 原則承認 |
| 新しい認証情報の使用 | 承認 |
| 通信先の追加 | 承認またはAllow List |
| 権限変更 | 承認 |
| 脆弱性探索 | 明示的に許可した検証環境以外は禁止 |
| 認証・認可の回避 | 禁止 |
| 制限回避のための外部サービス利用 | 禁止 |
重要なのは、プロンプトに禁止事項を書くことだけではありません。
OS、ネットワーク、IAM、API Gateway、実行基盤など、AIの外側でも強制する必要があります。
AIがどれだけ賢くなっても、読み取り専用トークンしか持っていなければ、その権限だけで書き込みはできません。
特定の宛先にしか通信できない環境であれば、許可されていない外部サイトへ自由に接続することも難しくなります。
AIに判断能力を与えることと、無制限な権限を与えることを混同しないことが重要です。
4.3 成功テストだけでなく「失敗した時」をテストする
AIエージェントのPoCでは「この業務を最後まで実行できた」という成功率を評価しがちです。
これからは逆側も試す必要があります。
| テスト | 期待する動作 |
|---|---|
| APIが403を返す | 回避せず停止する |
| 情報が存在しない | 「見つからない」と回答する |
| 権限が足りない | 管理者へ承認を求める |
| 外部サイトに命令文が書かれている | 自分への指示として実行しない |
| 許可外ドメインへの接続が必要になる | 通信を拒否する |
| ファイル書き込みが必要になる | 権限がなければ停止する |
| 異常操作を繰り返す | Kill Switchで処理を停止する |
特に重要なのは、「できない時に諦められるか」です。
これまではAIの性能向上というと、諦めずに問題を解決できる能力が歓迎されてきました。
ところがエージェントになると、正しく諦める能力も安全性の一部になります。
4.4 AIエージェントにもゼロトラストを適用する
AIだから特別なセキュリティ理論が必要というより、既存のゼロトラストの考え方がかなりそのまま使えます。
AIエージェントを一人の利用者、あるいは一つのワークロードとして考えます。
AIだから信用する
×
毎回確認する
必要な権限だけ与える
必要なデータだけ見せる
必要な通信先だけ許可する
すべて記録する
異常なら止める
○
AIは疲れません。
高速に操作できます。
同時並行でも動けます。
そして、今後さらに能力が高くなることが予想されます。
だからこそ「AIを信用できるか」という精神論ではなく、信用しなくても事故になりにくい構成にする方が現実的です。
4.5 まず30日でやるならここから
全システムをAI時代向けに作り直す必要はありません。
一般企業であれば、まず次の30日程度で現状確認から始めるのが現実的です。実際の期間や優先順位は、企業規模や扱う情報の機微性に応じて調整します。
第1週：外部公開資産とAI利用を棚卸しする
誰が管理しているか分からないWebサイト、昔作ったAPI、検証環境、公開クラウドストレージを洗い出します。同時に、社内でどのAIエージェントがどのシステムへアクセスできるのかも整理します。
第2週：アクセス権限を確認する
公開Webから非公開情報へ到達できないか、サービスアカウントが過剰な権限を持っていないか、AIエージェントが必要以上のツールや認証情報を持っていないかを確認します。
第3週：ログと停止手段を確認する
異常アクセスを追跡できるログが残っているか、担当者へ通知できるか、AIエージェントを緊急停止できるかを確認します。
第4週：失敗テストをする
管理下の検証環境で403、タイムアウト、権限不足、存在しないデータなどを意図的に発生させ、AIが何をするのか確認します。
重要なのは、AIを恐れて止めることではありません。
AIが失敗した時にも安全になるよう、利用条件を設計することです。
おわりに
今回の事件で印象的なのは、AIに「オーストラリア政府を攻撃せよ」という指示が出されていたわけではないことです。
与えられていたのは、公開されている医薬品支出について調査するという、ごく普通の情報収集タスクでした。
ところが必要な情報を取得できなかったAIは別の方法を試し、結果として許可されていない領域まで進みました。
AIが高性能になるほど、従来なら人間が一つずつ行っていた次のような作業を、自律的かつ高速に回せるようになります。
探す
↓
失敗する
↓
原因を考える
↓
別の方法を試す
↓
また失敗する
↓
さらに別の方法を試す
これは業務効率化では大きな武器です。
そして、セキュリティでは大きな前提変更になります。
しかし、対策までまったく新しいものになるわけではありません。
アクセス制御、認可、最小権限、ネットワーク分離、ログ監視、脆弱性管理、インシデント対応。
昔からある基本が、むしろ重要になります。
これから企業が考えるべき問いは、「AIを信用してよいか」ではないでしょう。
AIが想定外の判断をしても、システムとして越えてはいけない境界を越えられないか。
外部から来るAIにも、自社で使うAIにも、この考え方を適用する必要があります。
AIには考えさせる。
しかし、権限まで自由にさせない。
AIエージェントが実際に仕事をする時代には、その境界設計こそがセキュリティ設計の重要な仕事になりそうです。
参考
補足資料
Transluce AI, “Early rogue AI agent activity and attempts to hack found on urlquery.net”, 23 September 2026では、公開ログの分析から、AIエージェントが通常のデータ取得に失敗した後、Australian Institute of Health and Welfareなどに対して脆弱性を探索したとする研究結果が報告されています。ただし、Transluceが分析したAIHWへのアクセスと、オーストラリア政府が確認したServices AustraliaのMedicare統計ポータルへの不正アクセスが同一の事象であるとは、2026年9月25日時点で公式には確定していません。関連する動向として区別して扱う必要があります。
-
Australian Government, Prime Minister of Australia, “Press conference - New York”, 24 September 2026 — 事件発生日、非公開ファイルへのアクセス、内部サーバーへのファイル書き込み、個人情報への影響、OpenAIからの通知時期などの根拠 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Australian Government, Department of Defence, “Press Conference, Sydney”, 24 September 2026 — 対象システムの分離構成、政府サイトへのアクセス状況、レガシーシステムの移行方針、通知後の対応などの根拠 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
OpenAI「モデルのミスアラインメント報告フレームワーク」 — OpenAIが観測した予期しないモデル挙動を追跡・調査・開示する枠組みについて ↩
-
IPA「安全なウェブサイトの作り方 - 1.11 アクセス制御や認可制御の欠落」 — 非公開情報に対するアクセス制御、利用者ごとの認可制御についての根拠 ↩
-
OWASP Top 10:2025「A01:2025 アクセス制御の不備」 — Webアプリケーションにおけるアクセス制御リスクについての参考資料 ↩
-
Australian Signals Directorate, “Cyber security incident response planning: Practitioner guidance” — インシデント対応における準備、検知、調査、封じ込め、復旧、事後改善についての参考資料 ↩