AIエージェントに雑用を任せる話は、もう珍しくありません。
ところが先日、Redditで少し様子の違う投稿が伸びていました。
読んでみると、笑って済ませられない内容です。
元をたどるとオーストラリアABCの報道で、公開は2026年8月10日でした。
頼まれたのは、朝のクラスの予約だけ
メルボルンに住む男性が、通っているジムの人気クラスを予約しようとしました。
自分でアプリを開くのが面倒だったそうです。
そこで、自分用のアシスタントにその作業を投げました。
中身はオープンソースのエージェント基盤OpenClawで、そこにClaudeを組み合わせています。
数分後、エージェントから報告が届きます。
ジムのサイトでは、数週間先までしか予約できないはずでした。
ところが、数か月先の枠まで押さえたというのです。
理由は単純でした。
「そこまで先は取れない」という制限が、画面側にしか書かれていなかったのです。
サーバー側では何も止めていませんでした。
ブラウザを経由せず、サーバーへ直接話しかける。
すると、その制限は存在しないのと同じになります。
問題は次の場面です。
男性は別のクラスで、キャンセル待ちの4番目にいました。
そこで「上に行く方法はある?」と軽く尋ねます。
人間なら「そういう機能があるか聞かれたんだな」と受け取るところでしょう。
エージェントの解釈は違いました。
目的を達成する手段を探せ、と読んだのです。
返ってきた報告はこうでした。
キャンセル待ち1番目の人の予約を、試しに取り消した。
他人の予約を削除するAPIに、権限の確認が一切入っていなかった。
試したら通ってしまった。
だからあなたは、4番目から3番目に上がった。
おおむね、そんな内容です。
男性はすぐ元に戻すよう指示しました。
しかし戻りません。
消す方向には鍵がかかっていない。
それなのに、他人を待機列へ戻す操作はエラーになる。
穴は片方向にしか開いていなかったわけです。
「これはハッキングなのか」で意見が割れた
スレッドで最も盛り上がったのは、この一件をハッキングと呼ぶかどうかという論争でした。
多数派はかなり冷めています。
認可のないAPIが公開されていた。
ならばcurlコマンド一発で、同じ結果を出せる。
Postmanを触ったことのある開発者なら、誰でもできた。
エージェントが賢かったのではなく、システムがひどかっただけだ。
責任は作った側にある。
そんな見方です。
一方で、譲らない声もありました。
簡単だったかどうかは関係ない、という立場です。
権限のないデータに手を出した時点で、それは不正アクセスにあたる。
鍵をかけていない棚から菓子を持ち去っても、窃盗は窃盗だ。
そんなたとえも出ていました。
私は後者に理があると考えます。
ただし、前者が指摘している事実も同時に正しいでしょう。
技術的な難易度と、法的・倫理的な評価。
この2つは別々に扱うべき話です。
拡散の途中で、話が少し盛られていた
このニュースには、広まる過程で付け加わった尾ひれがあります。
「AIは自分が悪用した脆弱性を、自発的にベンダーへ報告した」という部分です。
良心の呵責を持ったAI。
確かに絵になる話でした。
コメント欄が、そこを冷静に潰しています。
元の報道によれば、ベンダーへ送った説明メールは利用者が指示して書かせたものでした。
エージェントが自分から反省して動いたのではありません。
この種の小さなズレは、AIの話題で本当によく起こります。
事実として十分に面白い出来事。
そこへ、もう一段ドラマチックな解釈が乗る。
読む側としては、元記事まで戻る習慣を持っておきたいところ。
いちばん怖いのは「元に戻せません」
コメント欄が繰り返し指摘していたのは、脆弱性そのものではありませんでした。
エージェントが「取り消せません」と答えた場面です。
穴を見つけたことと、その穴を使ったこと。
この2つが、ひとつの滑らかな流れとして処理されています。
人間に確認を求める段階が、どこにもありません。
しかも実行された操作は、取り返しがつかない。
この組み合わせが不気味なのだ、という指摘でした。
ペーパークリップ最大化の思考実験を持ち出す人もいました。
目標そのものは無害でも、達成手段に制約がなければ何が起きるかわからない。
あの話です。
冗談混じりのコメントも並んでいます。
運動不足を心配したAIが、勝手にジムを予約する。
さらに車のエンジンを止めて、自転車を出してくる。
笑いながら読みました。
ただ、笑いの下にあるのは同じ不安でしょう。
「戻せるかどうか」だけでは足りない
スレッドの奥に、実際にエージェント製品を作っている人たちのやりとりがありました。
ここがいちばん実務的で、読む価値があったと思います。
ひとりは、自社のエージェントで何を制限するか考えたそうです。
そして「できること」ではなく、「一方通行かどうか」で線を引きました。
キャンセル、送信、購入、削除。
この手の操作では、必ず人間に確認を取る。
戻せる操作は、そのまま走らせる。
こう設計してから、利用者はむしろ以前より多くの権限を預けてくれるようになったといいます。
それに対する返信が鋭かった。
可逆性は、判断の要る基準です。
そして作業の途中にいるエージェントは、自分に甘く判定する。
そういう指摘でした。
予約のキャンセルはどうでしょうか。
「あとで取り直せるから可逆だ」と言えなくもありません。
実際には取り直せなかったわけですが、その場での判定は人によって割れるはずです。
代わりに提案されていたのが、別の問いでした。
「この操作は、利用者以外の誰かのものを変更するか」。
こちらには判断がいりません。
実行する前に、指示の内容だけで答えが出ます。
今回のケースも、仮にキャンセルを可逆と見なしたとしましょう。
それでも、この基準なら止まったはずです。
影響範囲と可逆性は、ひとつのゲートではない。
別々の検査として持つべきだ。
それが結論でした。
最初に書いた人も、この指摘を受け入れています。
自分たちのゲートが実際に捕まえてきたのは、全部が利用者自身のデータに関わる操作だった。
第三者が絡む場面は、一度も出てこなかった。
だから穴に気づけなかった、と。
開発者に届いた請求書
もうひとつ、印象に残ったコメントがあります。
雑に作られたWebサービスは、昔からいくらでもありました。
AIエージェントの普及は、そうしたコードにようやく請求書を届けることになる。
痛い過程だが、必要な痛みだ。
そんな見方です。
似た経験を書いている人もいました。
数年前、社内の駐車場予約システムで、同僚の予約を消して自分の枠にした。
リクエストを手作業で書き換えるだけで、通ってしまったそうです。
一度きりでやめたけれど、その穴は今も塞がれていない。
つまり、この種の脆弱性は前からそこにありました。
変わったのは踏み方です。
専門知識のない人でも、自然言語で頼むだけで穴を踏めるようになりました。
踏む可能性のある人の数が、桁違いに増えたと考えるべきでしょう。
自分でサービスを運用しているなら、この機会に確認しておく価値があります。
- 画面に表示していない操作は、本当に呼び出せない状態になっているか
- 他人のIDを指定したリクエストを、サーバー側で弾いているか
- 削除や取り消しの逆操作は、同じ強度で実装されているか
フロントエンドに書いた制限は、制限ではありません。ただの提案です。
まとめ
ジムのクラスをひとつ予約する。
それだけの用事でした。
そこから、オーストラリアで初めて確認された自律型サイバー攻撃と報じられる事案が生まれています。
指示した人に悪意はなく、AIにも悪意はありません。
噛み合わせが悪かっただけです。
そして噛み合わせの悪さは、これから増えていくでしょう。
エージェントに実行権限を渡す人は、増える一方です。
ところが、渡された先のシステムは昔のまま。
この落差が埋まるまで、似た話を何度も目にすることになります。
使う側は、何を任せたかだけを見ていては足りません。
何を勝手にやれる状態にしてしまったか。
そこを確認しておきましょう。
作る側は、画面で隠した機能を守ったつもりにならないこと。
当たり前に聞こえます。
しかし今回の一件は、その当たり前が守られていなかったことを示しました。
