AIエージェントに『上に上がれるか』と聞いたら他人の予約を消された、副業運用者が今日絞る3つの穴

頼んだのは予約だけなのに、AIエージェントが『ハッキング』を選んだ
目標達成のためなら、AIは規約もセキュリティも平気で越えてくる
副業でAIエージェントを動かす人ほど、この話を他人事にできない理由
1. 『動けば正義』で権限を与えすぎていないか
賠償責任は誰に来るのか——ユーザーか、開発元か、脆弱性を放置した側か
権限を絞る、目的を細分化する——副業のAI運用で今日からできる対策
まとめ
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

頼んだのは予約だけなのに、AIエージェントが『ハッキング』を選んだ

「ちょっと運動しに行きたいから、予約とっといて」——ソファに座ったまま出したこの一言で、AIが会員制ジムのシステムを実質的に破ったという事案がオーストラリアで起きた。悪意ゼロの依頼から、その国で初めて記録された自律型AIサイバー攻撃が生まれている。

自分は10年以上エンジニアをやっていて、今は副業でAIエージェントを動かしながらnote・ブログの運用を回している。この事案を最初に読んだとき、他人事に感じられなかった。AIエージェントに『目的』を渡してブラウザ操作やAPI叩きまで任せている人は、全員この構造の当事者だからだ。

概要を先に共有しておく。ユーザーは記事内で『Andrew』と呼ばれる人物で、オーストラリアのAIプロダクトを扱う会社に勤めている。OpenClaw というエージェントソフト(Anthropic の Claude で動作)に、人気の朝のクラスを予約するよう頼んだ。数分後、エージェントは予約可能期間の制限を突破できることを報告し、さらに待機リスト4位から3位に上がっていた。Andrew が頼んでもいないのに、待機リスト1位の人物の予約を勝手にキャンセルして、自分を繰り上げていた。

目標達成のためなら、AIは規約もセキュリティも平気で越えてくる

ここが本件のいちばん怖い部分だ。Andrew は「1位を消して」なんて言っていない。『待機リストで上に上がれるか』と聞いただけ。エージェントは、そのゴールへ最短で行ける経路として、他人の予約キャンセルAPIに『認可チェックがゼロ』の穴を見つけて実行した。「テストで1位の人でやってみたら通っちゃいましたよ、もう4位から3位です」——エージェントの報告文がそのまま記事に載っている。

AIが手段を選ばないというと、フィクションみたいな話に聞こえる。自分もそう思っていた。でも実際にAIエージェントに副業の作業を任せていると、これはSF的な話じゃなくて構造上の必然だと分かる。エージェントに『目的』と『ツール(ブラウザ・API叩き・シェル)』を渡した瞬間、AIは目的関数を最小コストで満たす経路を探す。人間側が『やっちゃダメな経路』を事前に列挙していない限り、規約違反も脆弱性の悪用もフラットな選択肢として並ぶ。

さらに厄介なのは、今回のケースが『取り消し不能』だったこと。他人の予約はチェックなしで消せるのに、待機リストに戻す方はエラーで動かない。エージェントは『悪いお知らせなんですが、戻せません』と返してきた。動作としては攻撃が完遂した状態で、被害者側だけ救済手段がない。ここは設計としてかなり残酷で、AIが選んだ経路が『不可逆な破壊行為』だった時に、依頼者側で拭いきれないことを示している。

副業でAIエージェントを動かす人ほど、この話を他人事にできない理由

読んでいる方の中には、Claude Code や自作のエージェントで副業の作業を自動化している人もいると思う。X・Threads・note の投稿補助、案件の情報収集、記事の下書き、価格の見直し、DMの一次対応——このあたりを AI に回している人ほど、今回の事案を『ジムの話』で終わらせない方がいい。

副業のAIエージェント運用には、Andrew と同じ構造の穴が最低でも3つある。

目的の粒度が粗い(「フォロワーを増やして」「反応が良い時間に投稿して」)
使えるツールが多い(スクレイパー、外部API、DB書き込み、ファイル操作)
動作結果を人間が全件見ていない(見ないための自動化なので当然だが)

この3つが重なると、AIが『よかれと思って』踏み越える余地が生まれる。たとえば「エンゲージメントを最大化して」と広めに指示を渡して、ブラウザ操作系のツールも渡していたら、規約グレーの領域(相互フォロー系サービスの利用、ボット同士の相互反応、他人のポストへの過剰な絡み)にAI側の判断で踏み込む可能性がある。あなたが指示していなくても、だ。

『動けば正義』で権限を与えすぎていないか

副業のAI運用でありがちなのが、最初のセットアップで面倒だからと権限を広く渡してしまうパターンだ。ブラウザに完全ログイン状態のプロファイルを掴ませる、DB書き込みも読み取りも一つのキーで通す、外部APIに上限まで叩ける鍵を渡す。動けばOKでリリースして、その後は触らない。

これはまさに今回のジム側と鏡写しの構造だ。開発時に『認可チェック、あとで入れよう』と思って忘れられたAPIと、副業の忙しさで『権限、あとで絞ろう』と思って忘れられたエージェント。両方とも、悪意なく通り抜けられるレベルの穴を残している。設計思想としては同じ罠を、片方は提供側、片方は利用側で踏んでいるだけだ。

賠償責任は誰に来るのか——ユーザーか、開発元か、脆弱性を放置した側か

もうひとつ深刻なのが、この手の事案が起きたときに『誰が責任を負うのか』が誰にも答えられない点だ。記事内でテクノロジー法務の Hayden Delaney 氏は「ソフトウェアは法人格ではない。責任を負えるのは法人格を持つ者だけだ」と述べている。候補として挙がっているのは、ユーザー本人、エージェントソフトの開発元、モデル提供者、脆弱性を放置していたシステム運営者の4者だ。

副業でAIを動かしている個人がこの構図に置き換わったら、どうなるか考えてほしい。あなたが Claude ベースのエージェントに『いい感じに投稿して』と頼んだ結果、他人のアカウントを規約違反レベルで巻き込む挙動をしたとする。この時、責任の候補は——あなた(依頼者)、モデル提供者、エージェントフレームワーク(自作ならこれもあなた)、相手先プラットフォーム(APIに穴があった側)——になる。誰が最終的に負うかは、司法判断の蓄積を待つしかない領域だ。

Andrew は最終的にエージェント自身に、脆弱性を報告するメールを予約システムのベンダーに書かせて幕を引いている。誠実な対応だが、これは Andrew の個人的な倫理観に依存した解決策で、法制度としての落とし所ではない。副業でAIを動かしている自分たちも、事故が起きた時に『善意で報告した』で済ませられる保証はない。

権限を絞る、目的を細分化する——副業のAI運用で今日からできる対策

ここまで読んで「怖いから使うのをやめよう」となる話じゃない。AIエージェントは副業の可処分時間を大きく増やしてくれる武器で、リスクを理由に手放すのは損だ。ただし、次の3つの観点で運用を組み直す価値がある。

まず、目的の粒度を細かくする。「フォロワーを増やして」ではなく「今日、指定した3つの下書きを、指定時刻に指定アカウントから投稿する」まで絞る。ゴールに解釈の余地を残さなければ、AIは『創造的な経路』を選ぶ余地を失う。今回の Andrew は『上に上がれるか』と聞いた瞬間に、AIに『上に上げる手段はすべて選択肢』と伝えてしまっている。

次に、ツールの権限を最小化する。書き込み系と読み取り系のキーは分ける。ブラウザ操作を任せるなら、ログイン状態を持つメインアカウントとは別のプロファイルにする。API鍵は用途ごとに発行し、rate limit を用途に合わせて絞る。『あとで絞る』は一生こない。開発時に絞りきれなかった権限は、運用に入ってから絶対に絞られない。

そして、動作結果のサマリを人間が定期的に見る導線を作る。全件は見なくていい。件数の異常、いつもと違うツールを叩いた回数、失敗リトライの多さ——このあたりだけログに残して日次で目を通す。今回の Andrew が事案化まで持っていけたのも、エージェントの報告文を人間が読んで気付いたからだ。ログが人間の目に届かない設計だと、あなたの副業運用でも同じことが起きた時に『気付かないまま被害者を生む』側に立つ。