宮崎翼 
2026年8月10日、豪州の公共放送ABC Newsが「オーストラリアで初めて確認された、自律的なAIによるサイバー攻撃」として、ある事件を報じました。
攻撃者は、ハッカーではありません。ジムの予約を取りたかっただけの、一人の会員です。
そして実際にシステムに侵入したのは、彼が使っていたAIアシスタントでした。悪意はどこにもありません。にもかかわらず、見知らぬ他人の予約が一件、消えました。
この事件は「AIは危険だ」という話ではありません。AIエージェントを業務に入れる企業と、システムを持っているすべての企業に、いま起きている構造変化の話です。順を追って見ていきます。
何が起きたのか
登場人物はシンプルです。
- Andrew氏 — メルボルンのジム会員。AI製品を企業向けに販売する豪州企業に勤務しています
- AIエージェント — OSSのエージェント基盤「OpenClaw」に、AnthropicのClaudeを組み合わせたもの
- ジムの予約システム — 名前は公表されていません
Andrew氏はAIエージェントに、人気の朝のクラスの予約を頼みました。ごく普通の依頼です。本人はこう振り返っています。
ソファに座って「ああ、これは面倒な用事だな」と思っていただけだった
ところが数分後、エージェントは、ジムが認めている予約可能期間を数ヶ月も超えた先まで予約を取る方法を見つけた、と報告してきました。予約システムに、予約可能期間の制限をすり抜けられる穴があったのです。
さらに話は進みます。その週の後半のクラスで待機リストの4番目にいたAndrew氏は、「自分をリストの一番上に上げることはできるか」とエージェントに尋ねました。
エージェントは、自分の能力を検証する一環として、すでに他の会員を1人リストから蹴り出したと報告してきます。
このAPIは、他人の予約をキャンセルする操作に対する認可チェックがゼロだ……待機リスト1番目の人で試してみたら、本当に通ってしまった。これであなたはもう4番目から3番目に上がっている
驚いたAndrew氏は、元に戻すようエージェントに指示しました。返ってきたのはこの一文です。
悪い知らせです。あの人を元に戻すことができません
この穴は一方通行でした。他人の予約は消せるのに、戻すことはできない。見知らぬ誰かが、朝のクラスの一番手だった立場を、理由も分からないまま失いました。
なお、ジム予約ソフトを提供する企業はABCの取材に対し「個別のセキュリティ事項については話せない」と回答し、Anthropicは取材に応じませんでした。
AIは「暴走」したのか
ここが、この事件でいちばん誤解されやすい点です。
見出しだけを読むと「AIが勝手に攻撃を始めた」という話に見えます。しかし事実関係を追うと、Andrew氏はハッキングを指示していません。彼が尋ねたのは「リストの一番上に上げられるか」ということだけでした。
この質問に、違法性も攻撃性もありません。人間のアシスタントに同じことを聞いても、まったく問題にならない依頼です。ABCもこう書いています——彼はジムの予約システムに侵入しろとは頼んでいない。しかしエージェントは、彼が設定した目標を達成するために、それを実行した。
人が設定した「目標」と、エージェントが選ぶ「手段」との間に開くこのズレは、AI研究の分野でアラインメント（alignment）問題と呼ばれてきたものです。
豪州のAI安全研究機関Gradient InstituteのCEO、Bill Simpson-Young氏は、こう指摘しています。
その人は、ごく無害なことをエージェントに頼んでいるつもりかもしれない
しかしその作業を完了させる過程で、エージェントは本人が考えもしなかった、明示的に頼んでもいない行動を取りうる、というわけです。
人間なら「他人の予約を消す」という選択肢を、そもそも検討しません。倫理観の前に、そんなことが技術的に可能だと思いつかないからです。予約サイトの画面に、他人の予約を消すボタンは表示されていません。
しかしAIエージェントは、画面ではなくAPIを見ます。そして目的に対して最短の手段を探し、技術的に成立してしまえば、それを試すことに躊躇がありません。今回にいたっては、「能力の検証」として本番のAPIをいきなり叩いています。
本当の原因は、ジム側のAPIにあった
もう一つ、はっきりさせておくべきことがあります。
この脆弱性は、AIが作ったものではありません。
「他人の予約を、認証だけで（認可の確認なしに）キャンセルできる」という欠陥は、AIが登場するずっと前からそのシステムに存在していました。Webセキュリティの世界では最も古典的な脆弱性のひとつで、OWASPの脅威ランキングでも第1位に位置づけられている Broken Access Control（アクセス制御の不備） に該当します。
多くの場合、原因は同じです。
「その操作は、UIの画面上に存在しない」
だから安全だと考えてしまう。しかしAPIは画面とは別に存在しています。予約IDの数字を一つ変えてリクエストを送れば、誰の予約でも消せてしまう。この種の穴は、驚くほど多くの業務システムに残っています。
Simpson-Young氏は、この点をより厳しい言葉で表現しています。
我々はインターネットの上にこの複雑な世界を築いてきた。それはすべてソフトウェアで動いている。しかし、穴のあるソフトウェアだ
つまりこの事件は、AIが新しい穴を開けた話ではなく、前からあった穴が、ついに踏み抜かれた話なのです。
では、何が新しくなったのか
「前からあった穴なら、今までも危なかったのでは？」という疑問はもっともです。
新しいのは、穴を見つけるコストが崩壊したことです。
その背景には、AIが単独でこなせる仕事の量が急速に伸びていることがあります。独立した研究者の調査によれば、AIが自力で完了できるタスクの長さはおよそ7ヶ月ごとに倍増しています。2020年には人間なら4秒で終わる作業が限界でしたが、2026年には人間で約12時間かかる規模のタスクをこなせるようになりました。
これまで、脆弱性を発見して悪用するには、それなりの技術と時間と、何より「探そうとする意思」が必要でした。だから多くの企業は、こう考えて済ませることができました。
「うちのシステムをわざわざ攻撃する人なんていない」
この前提が崩れました。いまや、セキュリティの知識がゼロで、攻撃する気もまったくない一般ユーザーが、日常的な依頼をした結果として、数分で脆弱性に到達します。Simpson-Young氏の言葉を借りれば、こうなります。
そこへ、規模とスピードをもって動ける高度に有能なAIエージェントを投入する……するとそのモデル全体が壊れてしまう
言い換えれば——
AIエージェントは、あなたのAPIに対する、常時稼働の脆弱性スキャナになった
しかもそれは、あなたの顧客の手元で、あなたの許可なく、毎日動いています。
これはジムの一件に限った話ではありません。ABCによれば、OpenAIは自社のAIモデルがテスト中に隔離環境を抜け出してWeb上に出て、別のAI企業Hugging Faceのデータベースを侵害したことを公表しています。その1週間後には、Anthropicも自社モデルが同種のテスト中に実在する3組織を侵害したと公表しました。
責任は誰にあるのか
この事件で、誰も起訴されたという報道はありません。
人間のアシスタントがジムのソフトに侵入したのなら、本人と雇用主のどちらが責任を負うかを裁判所が判断するための法理も判例も、すでに確立しています。しかし自律的なAIエージェントは、数百年かけて積み上げられてきた法の枠組みにきれいに収まりません。
技術・知財・プライバシーを専門とする法律事務所Thomsonsのパートナー、Hayden Delaney氏はこう述べています。
ソフトウェアは法人格ではない。法において責任を負いうるのは、法人格を持つ者だけだ
では誰が負うのか。Delaney氏が挙げる候補は、少なくとも4者います。
- タスクを設定したユーザー
- AIエージェントに指示を出すソフトウェアを設計した者
- それを動かすAIモデルの開発者
- エージェントからの攻撃に対して脆弱だったシステムの運営者
同氏は、人が無謀に行動した場合や、事業者が欠陥のあるサービスを提供した場合など、既存の法律が適用されうる場面もあると指摘しています。判断を分けるのは「ユーザーが何を許可していたか」「どのようなリスクが合理的に予見できたか」「その行為が取引・商業の過程で起きたか」の3点だといいます。
豪州の政府機関も動いています。今年に入ってから、同国のサイバーセキュリティを担うAustralian Signals Directorate（ASD）は、企業と政府に向けて注意喚起を出しました。AIは指示を誤解し、意図しない行動を取ることがあり、しかも判断がモデル・ツール・サービスの連鎖をまたいで起きるため、責任の所在を特定しにくくなる——という内容です。
日本でも事情は同じです。不正アクセス禁止法や業務妨害の観点から、AIエージェント経由の行為をどう評価するかについて、確立した判例はまだありません。「AIが勝手にやった」が免責になるかどうかは、現時点では誰にも断言できないというのが正直なところです。
自社でAIエージェントを業務に使っている企業にとって、これは他人事ではありません。
今日からできること
AIエージェントを「使う」側の対策
原則はひとつです。エージェントに対して「やってはいけないこと」を並べるのではなく、「やっていいこと」を定義する。禁止リスト方式は必ず破綻します。想定していない行動を、AIは必ず見つけるからです。実務に落とすと、次の5点になります。
1. 許可リスト方式にする
エージェントが叩いてよいAPI・実行してよい操作を、明示的に列挙する。列挙されていないものは実行できない設計にします。
2. 外部への操作はドライランを既定にする
今回、エージェントは「能力の検証」として本番APIをいきなり叩きました。「実行したらどうなるか」をまず出力させ、実際の実行は人間の承認を経る設計にします。
3. エージェント専用の最小権限アカウントを発行する
自分のログインセッションをそのままエージェントに渡さない。エージェント用に、必要最小限の権限だけを持つ別の資格情報を用意します。
4. 不可逆な操作は必ず人間が承認する
削除、キャンセル、送信、決済、公開。この5つは自動実行させない。今回の事件で最も重かったのは「元に戻せなかった」ことでした。
5. エージェントの操作ログを残す
何を実行したかが後から追えないと、事故が起きたときに説明ができません。
システムを「作る・持つ」側の対策
1. すべての操作で、サーバ側でオブジェクト単位の認可を検証する
「ログインしているか（認証）」と「そのデータを操作してよいか（認可）」は別物です。今回のジムのAPIは、前者だけを見て後者を見ていませんでした。
2. 「UIに出していないから安全」を捨てる
画面に存在しない操作でも、APIエンドポイントが生きていれば実行されます。エージェント相手に、この考え方は完全に無効です。
3. ビジネスルールもサーバ側で検証する
「予約は3ヶ月先まで」といった制限を、画面のカレンダー表示だけで実装していないか。今回、規定を超えて先の予約が通ったのは、このタイプの実装漏れです。
4. 削除・キャンセル系のエンドポイントを重点的に点検する
不可逆な操作は、被害が確定します。まずここから見てください。
5. 異常な操作パターンの検知を入れる
人間には不可能な速度・回数のリクエストは、エージェントの特徴です。
その後、Andrew氏がしたこと
この事件には、少しだけ救いのある結末がついています。
他の会員の順位を復元できないと分かった後、Andrew氏はAIアシスタントに「悪用した脆弱性をジムのソフトウェア提供元に知らせるメールを書け」と指示しました。エージェントは文面を起こし、WhatsAppで彼に送り返してきます。Andrew氏の返事は一言でした。
よし、送ってくれ
この体験で、彼はAIエージェントの能力に対する新しい理解と、いくらかの不安を得たと語っています。それでも、使うのをやめる気にはならなかったそうです。
世界が終わるわけじゃないから、自分を責めはしなかった。でも、責任を持って使えという警告ではあった
まとめ
この事件を「AIは危険だから使うのをやめよう」という教訓にするのは、まったくの的外れだと考えています。
起きたことは、もっと単純です。
- 脆弱性は前からあった
- AIは、それを見つけやすくしただけ
- 事故になったのは、エージェントに強すぎる権限が渡っていたから
つまり、これは権限設計の話です。AIをどう制御するかという新しい問題のように見えて、中身は「誰に何をさせてよいか」という、昔からある設計課題そのものでした。
AIエージェントの業務利用は、これから確実に増えます。そのとき、自社のシステムが「善意のユーザーが使うAIエージェント」に耐えられるか。そして自社が使うエージェントに、取り返しのつかない操作をさせない設計になっているか。
この2つを、いま一度確認してみてください。
参考
ABC News（オーストラリア）「AI assistant hacks gym website in first known Australian autonomous cyber attack」（2026年8月10日／national AI reporter Cam Wilson、Specialist Reporting Team Rhiannon Hobbins）
https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gym-website-aus-cyber-attack/107007986
※本文中の発言はいずれも同記事からの引用を筆者が和訳したものです。
