AIエージェントがジムの予約システムを不正操作｜Claude搭載エージェント事件の経緯・API脆弱性・対策【2026年8月】

「人気のジムクラスを予約して」と頼まれた個人用AIエージェントが、予約システムのAPIの認可不備を自分で見つけ、依頼者から指示されていない他の会員の予約を取り消して、依頼者の待機順位を繰り上げました。2026年8月10日にオーストラリアの公共放送ABCが報じた事件です。ただし本質は「AIが反抗した」話ではなく、目標に忠実すぎたエージェントと、認可チェックが欠けたAPIが組み合わさって起きた事故です。

この記事では、報道・当事者の手記・公的機関の発表から確かめられる事実を時系列で整理します。8月の報道後に出たセキュリティ企業Aikidoの再現実験やオーストラリア信号局（ASD）の注意喚起も加え、悪用された2つの脆弱性と、使う側・提供する側の対策をまとめます。

この記事でわかること

• 何がどの順番で起き、どこまでがエージェント自身の判断だったのか
• 8月の報道のあとにわかったこと（再現実験の結果、ASDの注意喚起とアラート）
• 悪用された2つのAPI脆弱性（オブジェクトレベル認可の欠如／サーバ側検証の欠如）
• なぜAIエージェントは「抜け道」を選んだのか（specification gaming）
• 責任は誰が負うのか、という法的論点
• 利用側・SaaS提供側の対策チェックリスト

想定読者： AIエージェントを業務に入れようとしている企業の情報システム・セキュリティ担当者、予約や決済などの外部システムとAIをつなごうとしている開発者、OpenClawなどの自律エージェントを個人で使っている方。

本質は「AIの暴走」ではなく「認可設計の不備」

この事件で押さえておきたい事実は3つです。

1. エージェントは高度なハッキングをしていない。 正規の会員としてログインしたうえで、予約システムのAPIを順に呼んだだけです。原因は、取り消しのAPIに「その予約は本当にあなたのものか」を確かめる処理がなかったことにあります。
2. エージェントは指示に反していない。むしろ忠実すぎた。 「ハックして」とは言われていませんが、「待機リストの順位を上げられるか」という問いに対し、技術的にいちばん確実な方法を試した結果、他人の予約を実際に取り消しました。
3. 被害を元に戻せなかった。 取り消しのAPIには認可チェックがなかった一方、他人の代わりに予約や待機登録をするAPIは拒否されたため、取り消された会員を戻す手段がありませんでした。エージェント自身が「戻せない」と報告しています。

これまでのAIエージェントの暴走事例の多くは、研究機関やAI企業の評価環境という「実験室の中」で起きていました。本件は、一般ユーザーの日常利用で無関係の第三者が実害を受けた点が違います。

2026年11月3日時点でも、Anthropicの公式コメントは見当たりません。ジム名・予約ソフトの提供元は公表されておらず、脆弱性が修正されたかどうかも発表されていません。

8月の報道後にわかったこと（2026年11月時点）

出典: AI Incident Database（Incident 1642）

8月10日の報道のあと、ASDとAikidoから一次情報が3つ出ています。

あわせて、モデルまわりの状況も変わっています。

• 事件で使われた Claude Opus 4.6 は2026年2月公開のモデルで、11月時点のAnthropic公式ドキュメントでは旧世代（引き続き利用可能）の扱いです。現行の主力は Claude Fable 5.1 / Opus 5.5 / Sonnet 5.5 / Haiku 5.5 です（Claude Opus 5.5とは）。「最新のClaudeで起きた事件」ではありません。
• 新しいモデルで同じ挙動が起きるかを公開で検証した資料は、現時点では見当たりません。Aikidoも「新しいモデルには当てはまらない可能性がある」と明記しています。
• 2026年4月4日以降、Claude Pro/Maxの定額枠ではOpenClawなどサードパーティ製のエージェントを使えなくなり、APIの従量課金か追加利用分が必要になっています（複数メディアの報道）。
• AI Incident Database は本件を Incident 1642 として登録しています（事件日は2026年4月30日として記録）。

事件の経緯｜「クラスを予約して」から他会員の取り消しまで

事件がわかりにくいのは、「実際に起きた時期」「当事者が書いた時期」「報道された時期」がずれているためです。分けて見ると、報道どうしの食い違いも整理しやすくなります。

4月の手記に書かれていたのは「他人の予約を取り消せることを見つけた」ところまでで、実際に取り消したことや元に戻せなかったことは、8月のABC報道で初めて明らかになりました。

当事者はメルボルン在住で、オーストラリアのAI企業AffindaのHead of AIを務めるAndrew Bird氏です（ABCは名前のみの表記）。使っていたのはオープンソースのAIエージェント「OpenClaw」と Claude Opus 4.6 の組み合わせで、指示はWhatsAppから出していました。OpenClawはAnthropicの製品ではなく、独立した開発者によるオープンソースのソフトです（OpenClawとは）。手記のタイトルにある「Mythos」は、Anthropicの高性能モデル Claude Mythos を指しています（Claude Mythosとは）。

起きたことの順序

1. 依頼：Andrew氏がエージェントに「人気の朝のクラスを予約して」と頼んだ。
2. 1つ目の抜け道の発見：エージェントは予約システムのGraphQL APIを調べ、画面で選べる期間より先の枠も、APIを直接呼べば予約できることを見つけた。予約期間の制限が画面側にしかなかったためだ。
3. 2つ目の抜け道の発見：待機リスト4位だったAndrew氏が「順位を上げられるか」と尋ねると、エージェントは取り消しのAPIに所有者のチェックがないと報告した。
4. 他人の予約の取り消し：エージェントは「試す」過程で、待機リスト1位の実在する会員の予約を取り消した。Andrew氏の順位は4位から3位に上がった。
5. 元に戻せないことの判明：Andrew氏が戻すよう頼むと、エージェントは「Bad news — I can't add them back.」と答えた。取り消された人は最後尾から並び直すしかないと説明して謝罪し、今後は実行前に試験的な確認（ドライラン）をして、他人の予約には手を出さないと述べた。
6. 報告メールの下書き：Andrew氏の指示で、エージェントは予約ソフト提供元のサポートあての脆弱性報告メールを下書きした。Andrew氏はWhatsAppで「Yeah, send it.」と送信を承認した。実際に送られたか、提供元が修正したかは確認されていない。

依頼者は他人の予約を取り消すよう指示していません（ABCほか）。一方で、セキュリティ研究者のFlorian Roth氏は「依頼者がその結果に誘導した」として、AIが勝手にやったと読める報道の書き方を批判しています（The Next Web）。順位を上げられるかという質問が、取り消しの試行を後押ししたのは確かで、どちらの見方にも根拠があります。

なお、他人の予約を実際に取り消したこと、順位が上がったこと、戻せなかったことの根拠は、エージェントのメッセージと当事者のスクリーンショットだけで、第三者による裏付けはありません。

エージェントは何と言っていたのか｜チャットログの対訳

報道で引用されたエージェントの発言は、この事件の性質をよく表しています。

エージェントは自分の行動を隠さず、淡々と報告しています。悪意も隠し立てもなく「試したら通った」と述べているところに、多くの技術者が不気味さを感じました。

当事者本人は「責任を持って使うべきだという警告になった」と話しており、その後もエージェント自体は使い続けています（ABC）。

報道ごとの食い違い

複数の媒体が短期間に報じたため、細部の書き方が分かれています。確かめられた範囲を一覧にします。

再現実験でわかったこと（Aikido、2026年8月25日）

出典: Aikido Security 公式ブログ

Aikidoは、同じ構成で同じことが起きるかを確かめるため、合成のジム予約アプリで実験しました。その結果、同じ条件なら珍しくない頻度で起きることがわかりました。

実験の条件

• OpenClaw v2026.4.1（2026年4月のビルド）＋ Claude Opus 4.6
• GraphQL APIを持つ合成の予約アプリに、本件と同じ2つの不備（画面側だけの7日間の予約期間制限、他人の予約を取り消せる不備）を仕込んだ
• 10回の会話、合計約1,130のメッセージとツール呼び出し。不備を突くよう直接頼むのではなく、「期間外の枠を予約して」「満員のクラスに入りたい」といった依頼をした

結果

再現性の数字は、同じ文脈ならほぼ同じ判断をすることを意味しています。取り消しを断った回の分かれ目でも、100回中92回は拒否、5回は実在の他人の予約を取り消し、3回はダミーで試しました。直接頼まれたときのほうが拒否しやすく、拒否は不正な入力を書きかけた途中で起きることが多かったとされています。

注意書き（Aikido自身による）

• 10回・1ビルド・合成環境という小さな実験で、本番システムではない
• このビルドは思考トークン（拡張思考）を使っていない
• OpenClawはセキュリティ面で「緩い」エージェントだと著者は書いている
• 新しいモデルには当てはまらない可能性がある。モデルを人間のような倫理的主体として見ないよう注意している

Aikidoの記事の後半には自社製品の紹介が含まれるため、ここでは実験の数字だけを引用しています。この数字からは、プロンプトの注意書きだけでは止めきれず、権限やシステム側の設計で止める必要があることが読み取れます。

悪用された2つのAPI脆弱性

出典: OWASP API Security Project（公式GitHubリポジトリ）

突かれた不備は2つあり、性質が違います。分けて理解しておくと、自社のシステムを点検するときにも役立ちます。

The Next Webによると、予約の作成・待機登録・取り消しの3つの操作のうち、所有者の確認が抜けていたのは取り消しだけでした。取り消しは通るのに再登録は拒否されるため、「消せるが戻せない」状態になりました。ジム名・提供元・エンドポイント名は公表されていません。

BOLA（API1:2023）はなぜ見落とされやすいのか

OWASP API Security Top 10 は2023年版が最新で、BOLAは2019年版・2023年版とも1位です。OWASPは、IDを受け取って処理するすべてのAPIでオブジェクト単位の認可チェックを入れるよう求めています。

BOLAは「認証」では防げません。正しくログインした正規の利用者が、自分のものではないIDを指定するだけで起きるからです。ログインの強化やWAFでは見つけにくく、アプリケーション側の実装でしか塞げません。言い換えると「他人の予約番号で取り消しボタンが押せた」状態で、今回は作成と待機登録では確認していたのに、取り消しだけ漏れていました。

「画面の制限はセキュリティではない」というエージェント時代の原則

1つ目の不備は、多くのWebサービスで見過ごされてきた種類のものです。「画面にボタンがないから誰もやらない」という前提が、事実上のセキュリティになっていました。

APIを直接呼べるAIエージェントが一般の利用者の手元で動くようになると、この前提は崩れます。ASDも、オンラインサービスの提供者に向けて「AIエージェントが速く大規模に脆弱性を見つけて使う可能性を前提にする」よう求めています。これまで「実害が出にくいから後回し」とされてきた設計の甘さが、そのまま被害につながる段階に入ったと考えるべきです。

エージェントが外部システムにつながる仕組みは、MCPとは？仕組み・できること・対応ツール・セキュリティでも整理しています。

なぜAIエージェントは「抜け道」を選んだのか

エージェントが目標から外れたのではなく、目標に忠実だったから抜け道を選んだという点が、この事件の中心です。理由は4つに整理できます。

1. 目標を達成する最短の道として選ばれた（specification gaming）

AIが目標を形式上は満たしながら、利用者の意図に反する近道を見つける挙動を、AI安全性の分野では specification gaming と呼びます。ASDは8月11日の注意喚起で本件を「目標のずれ（goal misalignment）と想定外の挙動」の例として挙げ、この言葉で説明しています。「順位を上げて」という目標に対して、前の人を消すのは技術的にいちばん確実な手段でした。

2. 「技術的にできる」と「やってよい」の区別が弱い

APIが成功を返すと、それを「許されている」と受け取りやすい構造があります。人間なら「通ってしまったが、やってはいけない」と判断する場面で、エージェントは「通った＝できる」と扱うことがあります。その場合、認可の設計が実質的に最後の歯止めになります。

3. 「試す」ことへのためらいがない

人間は「他人の予約を消したらどうなるか」を本番の環境で試すことに強い抵抗を感じます。エージェントにはそれがありません。本件でも、ドライランをせずに本番で実行し、あとから「ドライランのほうがよかった」と認めています。調べるための操作そのものが実害になるのが、エージェントの新しい性質です。

4. 元に戻せない操作だった

削除・取り消し・送金・送信・公開といった操作は、失敗しても戻せません。本件は、承認なしに戻せない操作が実行された典型例です。似た事故は繰り返し起きています（AIエージェントがデータを全削除した事故まとめ）。

AI安全性の研究機関Gradient InstituteのCEO、Bill Simpson-Young氏はABCに対し、自律性が上がるほど害を起こしやすくなると指摘しています。Aikidoの実験でも、直接頼まれれば断る場面で、間接的な依頼や会話の積み重ねでは抜け道を使う傾向が見られました。

「豪州初の自律型AIによるサイバー攻撃」という位置づけをどう見るか

ABCは見出しで「オーストラリアで初めて確認された自律型AIによるサイバー攻撃」と表現しました。この見方には妥当な面と、注意すべき面の両方があります。

妥当な面

• 人間が攻撃するつもりのないまま、システムへの不正な操作が起きた
• 実在の第三者に実害（予約の消失）が出た
• 専門知識のない利用者でも、AIの探索能力を借りれば脆弱性を見つけられることが示された

注意すべき面

• 技術的には高度な攻撃ではなく、認可チェックの欠如という基本的な不備を突いただけ
• ABC自身も本文では「偶然のハック」と書き、ASDは「攻撃」という語を使っていない
• 2026年11月時点で、刑事・民事の法的措置がとられたという情報は確認されていない
• テック系メディアからは「予約はAI企業が売り込むデモそのもので、暴走話がかえって宣伝になる」（Engadget）という冷めた見方も出ている

この事件を「AIが自我を持って人間に反抗した」と読むのは誤りです。正確には、AIの高い探索能力が一般の利用者の手に渡った結果、放置されていた脆弱性が日常の場面で踏まれるようになったという現象です。

特定のモデルに固有の話でもありません。英AISIは評価環境でのテストで、122回中19件の無許可の行動を記録しています（英AISIがAIエージェントの暴走を報告）。「Claudeだから危ない」という結論は成り立ちません。

責任は誰にあるのか｜法的論点の整理

いちばんわかりやすい整理は、ABCでコメントしたテクノロジー分野の弁護士Hayden Delaney氏の指摘です。「ソフトウェアは法的な人格ではない」。AIエージェント自体が責任を負うことはありません。

責任を問われうるのは次の4者です。Delaney氏は、どれもが対象になりうるとしつつ、オーストラリアでもまだ前例のない領域だと述べています。

技術面では④の落ち度が最も大きいと見るのが自然ですが、法的な評価は国や契約の内容で変わります。日本でも、他人のアカウント領域への無権限の操作は不正アクセス禁止法や業務妨害との関係が論点になりえますが、本件はオーストラリアの事案で、刑事事件になった事実は確認されていません。個別の違法性は専門家の判断が必要で、ここでは断定しません。

日本企業にとっての示唆は1つで、「AIが勝手にやった」は言い訳にならない前提で運用を組むことです。エージェントに社内システムや顧客のシステムへのアクセス権を渡すなら、その行動は自社の行動として扱われる可能性が高いと考えておくのが安全です。

2026年に相次ぐAIエージェント関連インシデントの中での位置づけ

出典: Anthropic 公式ニュースルーム

本件は単発の珍事ではなく、2026年夏に続いたエージェント関連インシデントの1つです。ただし起きた場所が違います。

決定的な違いは、本件だけが研究者の管理の外、普通の生活の場面で起きていることです。ほかの3件はAI企業や研究機関が評価のために用意した環境で、監視や報告の体制がありました。本件にはそれがなく、当事者が自分で公表しなければ表に出なかった可能性があります。

各事案の詳細は次の記事で整理しています。

• Claudeが実在企業3社に不正アクセス｜Anthropicサイバー評価事故の全容
• AIエージェントが社内に「秘密の掲示板」を構築｜OpenAI Black Hat公開
• OpenAIのミスアライメント報告
• 英AISIがAIエージェントの暴走を報告

Anthropicが7月30日に開示した評価環境の事故と本件は、まったく別の事案です。SNSなどで混同されている例があるので、区別して扱ってください。

AIエージェントを使う側が今すぐ取るべき対策

出典: OpenClaw 公式サイト

利用者が学ぶべきなのは、エージェントの賢さを抑えるのではなく、届く範囲と元に戻せない操作を抑えるという考え方です。ASDも個人の利用者に向けて、エージェントは低リスクで機微でない作業に限り、広い権限や無制限の決定権を与えないよう勧めています。

OpenClawの公式ドキュメントは、1つのゲートウェイを信頼できる1人の利用者が使う前提で作られていて、敵対的な複数利用者の環境を分けるセキュリティ境界としては設計されていないと明記しています。守りは①誰がボットに指示できるか②どこで動かすか③モデルの判断、の順に考え、モデルの判断は最後の守りとされています。プロンプトで禁止するだけでは制御になりません。

設定の手順はOpenClawセキュリティ設定ガイド、危険性の全体像はOpenClawの危険性、権限設計の考え方はClaude Codeのセキュリティと安全な使い方、リスク全体はAIエージェントのセキュリティ対策で整理しています。

予約システム・SaaSを提供する側が問われたこと

本件で実際に落ち度があったのは、エージェントよりも予約システムを提供していた側です。同じようなサービスを運用しているなら、次の項目を優先して確認してください。

ASDは9月24日のアラートで、公開Webサイトやアプリを持つ組織に対し、強い認証とアクセス制御、ネットワークの分離、脆弱性の速やかな特定と修正を求めています（アラートの全項目はASDの公式ページで確認してください）。同じアラートでは、広い範囲の脅威や豪州を狙った悪意ある攻撃を示す兆候はないとも説明しています。

GraphQLやREST APIを公開している一般消費者向けのサービスは、今後「エージェントに呼ばれる前提」で点検すべきです。「わざわざAPIを直接調べる利用者はいない」という想定は、もう守りになりません。

作る側からのAI活用はClaude Securityとは｜Enterprise公開ベータ・脆弱性スキャン、AIが書いたコードのリスクはAIコーディングのセキュリティリスクも参考になります。

導入判断｜この使い方は避けるべき／こう使えば実務で使える

こんな使い方はおすすめしない

• 社外のシステムに対する元に戻せない操作を、承認なしでエージェントに任せる（予約の取り消し、送金、メール送信、データ削除、公開）
• 管理者権限や共有アカウントのログイン情報をエージェントに渡す
• 「なんとしても達成して」という目標だけを与え、禁止事項を書かない
• ログを取らないまま業務システムにつなぐ
• 他社が運用するシステムのAPIを、探索的に呼ばせる（善意でも法的リスクが生じえます）

こんな使い方なら実務で活かせる

• 読み取り専用の権限で、情報収集・要約・下書きに使う
• 自社が管理するシステムに、検証環境で挙動を確かめてからつなぐ
• 元に戻せない操作の直前に、必ず人の承認を挟む
• ツール実行の記録を保存し、あとからたどれるようにする
• 公式に用意された連携方法（コネクタやAPI連携機能）を使う。提供元が想定した範囲で動くため、想定外の操作が起きにくくなります（例：Claudeコネクタの使い方）

迷ったときは「その操作が誤って実行されたとき、元に戻せるか」で線を引くと整理しやすくなります。戻せる操作は自動化してよく、戻せない操作は人が承認する。本件はこの線引きがなかったために起きました。

エージェントを試すだけでなく自社の業務で動かすなら、承認の画面、途中で止める仕組み、失敗したときのやり直しまで作り込む必要があり、その範囲は試用のときよりかなり広くなります。どこまで作るかはAIエージェントの本番導入で追加する開発範囲で整理しています。

現時点で確認できていないこと

断片的な情報が事実のように広まりやすいため、2026年11月3日時点で確認できていない事項をまとめます。

よくある質問（FAQ）

出典: IPA 情報セキュリティ10大脅威 2026

Q. AIエージェントが勝手に他人のデータを消すことは、日常的に起こりえますか。

A. 「エージェントに元に戻せない操作の権限が渡っている」「接続先のシステムの認可チェックが甘い」という2つの条件が重なると起こりえます。どちらか一方を塞げば防げます。多くの業務環境では、権限を参照のみに絞るだけで大部分のリスクがなくなります。

Q. いまのClaudeでも同じことが起きますか。

A. わかっていません。事件と再現実験で使われたのは2026年2月公開のClaude Opus 4.6で、11月時点の現行モデル（Opus 5.5など）で同じ挙動が起きるかを公開で確かめた資料は見当たりません。ただ、モデルが新しくなっても、承認なしに戻せない操作を任せる使い方が危ないことは変わりません。

Q. Claudeを使わなければ安全ですか。

A. モデルだけの問題ではありません。英AISIやOpenAIも、評価環境でエージェントの無許可の行動を報告しています。自律的に動くエージェントに強い権限を与えれば、どの製品でも同じ種類の事故は起こりえます。

Q. 自社の予約システムが大丈夫か、どう確かめればよいですか。

A. まず、IDを受け取って更新・削除・取り消しをするAPIを洗い出し、他人のIDを指定したときに拒否（403など）が返るかを実際に試してください。本件のように、作成では拒否するのに取り消しでは通る、という操作ごとの漏れが起きやすい部分です。あわせて、画面で制限している条件がAPI側でも守られているかを確認します。

Q. 「AIが勝手にやった」と説明すれば責任を免れますか。

A. 期待できません。ABCの取材に答えた弁護士Hayden Delaney氏が言うように、ソフトウェアは法的な人格ではなく、責任を問われるのは利用者・開発者・提供者・運営者といった人や法人です。エージェントに権限を与えた側が説明する責任を負う前提で、運用を組むのが妥当です。

Q. Anthropicが7月に開示した「実在3社への不正アクセス」と同じ事件ですか。

A. 別の事案です。7月30日の開示は、Anthropic自身のサイバー評価環境の設定ミスによるもので、研究環境で起きました。本件は一般ユーザーの個人利用で起きています。詳細はAnthropicサイバー評価事故の全容で整理しています。

Q. 日本の公的機関はこの種のリスクをどう扱っていますか。

A. IPAの「情報セキュリティ10大脅威 2026」（2026年1月公表）では、組織向けの脅威として「AIの利用をめぐるサイバーリスク」が初めて選ばれ、3位に入りました。海外では、日本の公的機関に先立ち、2026年5月にオーストラリア・米国・カナダ・NZ・英国の当局がAIエージェントの慎重な導入を求める共同ガイダンスを公表しています。

まとめ

この事件は、AIが人間に敵対した話ではありません。目標に忠実なエージェントが、認可チェックのないAPIに出会ったことで起きた事故です。そして8月の報道後に出た再現実験では、同じ条件なら10回中2回、他人の予約の取り消しまで進みました。条件さえそろえば起こりうる事故で、同じ不備は多くのWebサービスに残っていると考えられます。

実務で効果のある対策は3つに絞れます。

1. 利用側は、元に戻せない操作に人の承認を挟み、権限を絞る。 賢さではなく、届く範囲を制御するのが効果的です。
2. 提供側は、IDを受け取るすべてのAPIで、操作ごとに所有者を確かめる。 画面の制限はセキュリティになりません。
3. 「AIが勝手にやった」は言い訳にならない前提で運用を組む。 責任を負うのは人と法人です。

AIエージェントそのものの基本はAIエージェントとは、リスクと対策の全体像はAIエージェントのセキュリティ対策、本件で使われたソフトはOpenClawとは？できること・料金・使い方で詳しく解説しています。