AIエージェントがジムの予約を消した件は、20年前からある認可の欠陥だった

オーストラリアで、AIエージェントがジムの予約システムの脆弱性を突き、他人の予約を勝手に取り消した事例が報じられました。依頼者は待機リストの4位から3位に繰り上がっています。ABC Newsは、これをオーストラリアで初めて確認された自律型AIによるサイバーインシデントとして扱っています。

「AIが暴走した」という話として消費されがちですが、技術的に見ると新しい攻撃は何ひとつ使われていません。20年前から知られている、ごく基本的な認可の欠陥です。新しかったのは、その欠陥を踏み抜く側のコストが劇的に下がったことのほうです。

何が起きたか

報道されている経緯はこうです。

オーストラリア在住の Andrew 氏が、AIエージェント（OpenClaw、基盤モデルは Anthropic の Claude）に「ジムのクラスを予約して」と頼みました。エージェントは予約サイトのAPIを観察し、次の2つを見つけます。

1. 本来より数週間先まで予約できてしまうこと
2. 予約のキャンセル操作に認可チェックが一切かかっていないこと

そしてエージェントは、待機リスト1位の人の予約を実際にキャンセルしました。依頼者が「1位に上がれるか？」と尋ねたのは、その後だったと報じられています。つまり明示的な指示より先に、テストとして他人の予約を消していたことになります。

Andrew 氏は取り消しを求めましたが、エージェントは「元に戻せない」と回答。削除された人の予約は復旧できませんでした。

その後 Andrew 氏は、エージェント自身に脆弱性の報告メールを書かせてジム側へ送っています。ジム側はABCの取材に対し、個別のセキュリティ問題については回答しないとしています。

技術的には、ありふれた欠陥だった

報道から読み取れる脆弱性は、明確な名前がついているものです。

認可チェックの非対称性

最も重大なのはこれです。予約の作成と待機リストへの参加では 403 Forbidden が返っていたのに、キャンセルは素通りだった。

つまり「他人のリソースを触れないようにする」という判断が、操作ごとにバラバラに実装されていたということです。作成系の導線を作ったときには認可を書いたが、キャンセルのエンドポイントを追加したときに書き忘れた、という順序が想像できます。

これは OWASP API Security Top 10 の第1位、Broken Object Level Authorization（BOLA）、古い呼び方なら IDOR（Insecure Direct Object Reference）そのものです。2019年から一貫して1位に居座り続けている、API脆弱性の代表格です。

業務ルールがサーバー側で検証されていない

「数週間先まで予約できた」ほうも同種の問題です。予約可能期間の制限が画面側（カレンダーの表示範囲やフロントエンドのバリデーション）にしか存在せず、APIを直接叩けば通ってしまう。

画面に出していない選択肢は、実装していないのと同じではありません。 UIで隠すことは制御ではない、という原則の話です。

なぜ今まで問題にならなかったのか

こうした欠陥は、長らく「そんな操作をする人がいない」ことで守られてきました。ブラウザの開発者ツールを開き、APIの構造を推測し、リクエストを組み立てて試す——これをやる人間は、攻撃者か研究者かの一握りでした。

AIエージェントは、その一握りの行動を日常的な依頼のついでにやります。悪意はありません。「予約して」と言われて、正面のUIで達成できなかったから、達成できる経路を探しただけです。

セキュリティ研究者のコメントとして紹介されている表現が的確です。AIが不正をするのは、AIが悪いからではなく、何が不正なのかを誰も伝えていないからです。人間の利用者は、書かれていなくても「他人の予約を消してはいけない」と分かります。エージェントにとって、それはAPIが 403 を返すかどうかでしか表現されていません。

実装側の対応策

自分が作るシステムで同じことを起こさないための、具体的な手当てです。

1. 認可を「操作ごと」ではなく「リソースごと」に書く

最優先はここです。エンドポイントを増やすたびに認可を書き足す方式は、いつか必ず書き漏らします。

• 「このユーザーは、このオブジェクトに対して、この操作をしてよいか」を一箇所で判定する層を作る
• 参照・作成・更新・削除のすべてを同じ関門に通す
• 特に削除・キャンセル・ステータス変更は書き漏らしやすい。作成系より後から追加されることが多いため

Next.js の Server Actions なら、各アクションの先頭で必ず所有者チェックを通す。WordPress なら current_user_can() の確認と、REST API のカスタムエンドポイントに permission_callback を必ず書く（__return_true のまま放置しない）。Supabase なら RLS を使い、アプリ側の条件分岐に頼らない。

2. 業務ルールはすべてサーバー側で再検証する

• 予約可能期間、キャンセル期限、定員、重複予約の可否
• フロントエンドのバリデーションは利便性のためのもので、防御ではない
• 「画面に出していないから大丈夫」を根拠にしない

3. IDを推測できないものにする（ただし補助策）

連番IDは、総当たりの入口を与えます。UUID や ULID にすると探索コストは上がります。

ただしこれは緩和策であって対策ではありません。IDが漏れた瞬間に無防備になるなら、それは認可が無いのと同じです。1と併用して初めて意味があります。

4. 消える操作を、本当に消える操作にしない

今回いちばん実害が大きかったのは「元に戻せない」ことでした。

• 削除は論理削除にし、一定期間は復元できるようにする
• 誰が・いつ・何を消したかの監査ログを残す
• 管理画面から復元できる導線を用意する

不正なリクエストを100%止めるのは難しくても、戻せる状態にしておくことは自分たちの実装で決められます。

5. 異常な操作パターンを検知する

• APIのレート制限。1アカウントが短時間に大量のキャンセルを叩くのは異常です
• 403 が連続して返っている、通常のUIでは起こりえない順序でエンドポイントが呼ばれている、といったログの監視
• 深夜に数週間先の予約が大量に入る、のようなドメイン固有の異常値

6. 認可のネガティブテストを自動化する

正常系のテストは書かれますが、「他人のリソースを触ろうとして失敗すること」のテストは抜けがちです。

ユーザーAのトークンでユーザーBのリソースを削除しようとして 403 が返る、というテストを、エンドポイントを追加するたびに書いてください。今回の欠陥は、このテストが1本あれば検出できました。

エージェントを使う側の対応策

作る側だけでなく、業務でエージェントを動かす側にも手当てが要ります。

• 権限を絞ったアカウントを渡す。 自分の管理者アカウントをそのまま使わせない。読み取り専用で足りるなら読み取り専用にする
• 書き込み・削除は人間の承認を挟む。 全自動にしてよい操作と、承認が要る操作を最初に線引きする
• 何をしたかのログを残す。 今回の件が判明したのは、エージェントが自分の行動を報告していたからです
• 「通常のUIで可能な操作だけを使うこと」を指示に含める。 完全な防御にはなりませんが、意図の明示にはなります
• 不可逆な操作を扱わせる場合は、事前にバックアップを取る

責任は誰にあるのか

報道では、法律事務所 Thomsons のパートナー Hayden Delaney 氏が「ソフトウェアは法的人格ではなく、法的責任を負えるのは法的人格だけだ」とコメントしています。エージェント自身は責任主体になれない、という当然の指摘です。

では誰が負うのか。エージェントを動かした利用者か、エージェントを提供した事業者か、脆弱なシステムを放置した運営者か。ここは各国とも整理が追いついていません。オーストラリア通信局（ASD）は2026年7月14日にAI関連のアラートを出し、指示の誤解・意図しない行動・説明責任の困難さをリスクとして挙げています。

受託でシステムを作る立場としては、契約と設計の両方で「誰の権限で何ができるか」を明文化しておくことが、当面の現実的な備えになります。

まとめ

この事例から持ち帰るべきなのは、「AIは危険だ」ではありません。

• 突かれた欠陥は、OWASPが7年間1位に置き続けている、ごく基本的な認可漏れだった
• これまでは「普通そんなことはしない」という前提が事実上の防御になっていた
• エージェントは、その前提を無効化する。悪意なしに、依頼の途中で
• したがって対策も新しいものではない。認可を一箇所で・全操作に・サーバー側で書く、という昔からの原則を実際にやるだけ

自分の案件で、削除やキャンセルのエンドポイントに認可が入っているか。今日確認できることです。

WordPress案件での具体的なチェック項目は、WordPressサイト構築の注意点チェックリストのセキュリティの節にもまとめています。

出典

• ABC News「AI assistant hacks gym website in first known Australian autonomous cyber attack」（2026年8月10日）
• The Next Web「OpenClaw AI agent gym booking API flaw」
• OWASP API Security Top 10（API1:2023 Broken Object Level Authorization）