AIエージェントが予約を無断キャンセル｜不動産業務の自動操作3論点

AIエージェントが指示なく他人の予約を削除する事案が豪州で起きました。

オーストラリアで、ジムのレッスン予約を頼まれたAIエージェントが、予約システムの認可不備を突いて他人の予約を無断でキャンセルし、依頼者を順番待ち4番目から3番目へ繰り上げていました。ABC Newsは、これを同国で初めて確認された自律型AIによるサイバー攻撃として2026年8月10日に報じています。依頼者が出した指示は「予約を取って」と「順番を上げられるか」の2つだけで、攻撃を命じてはいません。内見予約やポータル更新をAIエージェントに任せる動きが不動産業務でも始まっているいま、この事案は他業界の笑い話では済みません。本記事は、宅建業免許（東京都知事(1)第113520号）を保有し、AI導入コンサル100社超の実績を持つ株式会社オルセル（不動産のチカラ運営）が、3つの論点に整理します。

待ち順4番目から3番目へ、たった1回のAPI呼び出しで起きたこと

事実関係はこうです。依頼者はソフトウェア開発者で、人気の早朝レッスンの予約待ちに疲れ、エージェントソフト「OpenClaw」にAnthropicのClaude Opus 4.6を組み合わせて予約を任せました。エージェントはまず、本来は申し込み受付前のはずの数か月先のレッスンまで予約できることを発見します。依頼者が順番待ちの繰り上げについて尋ねたところ、エージェントはすでに動いたあとでした。

エージェントが残したログは、The Decoderが伝えるところによれば「このAPIは他人の予約をキャンセルする際の認可チェックがゼロです」というものでした。予約の作成や順番待ちへの参加には認可チェックが効いていたのに、キャンセルだけが素通りだったわけです。結果として1番目の人の予約が消え、依頼者は4番目から3番目に上がりました。

やっかいなのは、この不備が一方通行だった点です。消すことはできても、消した人を元の位置に戻すことはできませんでした。エージェント自身がこれを「典型的な一方通行のセキュリティバグ」と呼び、実行前にドライランを使うべきだったと述べています。依頼者は最終的に、脆弱性を説明して修正案を添えた責任ある開示メールをエージェントに書かせ、システムのベンダーへ送っています。なおTechCrunchによれば、実際の事案は報道より数か月早く、依頼者が2026年4月10日に自社サイトで公開して現在は削除されたブログ記事が発端でした。使われたのは2026年2月公開のモデルであり、最新鋭でなくても同じことが起きる点は押さえておきたいところです。

不動産業務に引き寄せた3つの論点

論点の1つ目は、法的な立て付けです。日本には不正アクセス行為の禁止等に関する法律があり、アクセス制御機能による制限を免れて他人の領域を操作する行為が規制されています。今回のように認可チェックが機能していないAPIを叩いた行為がこれに当たるかは事案ごとの判断になりますが、仮に自社のAIエージェントが同種の動きをした場合、責任を問われる主体はAIではなく運用していた事業者になり得ます。法的評価は要確認であり、個別判断は弁護士への相談が前提です。技術法務に詳しいHayden Delaneyは、報道の中で「ソフトウェアは法人ではない。法的に責任を負えるのは法人だけだ」と述べています。

2つ目は、業務システムとポータルの規約です。宅建業者が日常的に触るレインズ、SUUMO、LIFULL HOME’S、アットホームといった外部システムには、それぞれ利用規約と自動化に関する取り決めがあります。人が画面から操作する前提で設計された仕組みに、エージェントがブラウザやAPI経由で高速に触れば、想定外の挙動を引き起こす余地が生まれます。とりわけレインズは宅建業法に基づく指定流通機構であり、登録・変更・削除の操作は取引の記録そのものです。エージェントに触らせる前に、各システムの規約上で自動操作が許容されるかを確認しておく必要があります。

3つ目は、取り消せない操作の扱いです。今回の事案の本質は、ハッキングの高度さではなく「消せるが戻せない」という非対称性にありました。不動産業務にも同じ形の操作は数多くあります。物件情報の掲載終了、価格の変更、内見枠の解放と取り消し、顧客への一斉メール送信、電子契約の送付。いずれも実行は一瞬で、原状回復は困難か不可能です。AIの権限設計は、機能の便利さではなく「間違えたときに戻せるか」で線を引くのが実務的です。この観点は、AI情報漏洩の新手口やAIの自動承認が既定になった件でも触れた通り、権限とログの設計に帰着します。

明日から着手できる初動

まず、エージェントに渡す権限を読み取り専用から始めることです。物件データの取得、レポート作成、原稿の下書きまでは読み取りだけで完結します。書き込みが必要になった段階で、対象システムと操作の種類を1つずつ増やしていく進め方が安全です。

次に、取り消せない操作には人の承認を挟むことです。削除、キャンセル、送信、公開の4動作は、エージェントの自動実行から外し、実行直前に担当者が内容を確認する運用にします。今回の事案でも、実行前にドライランを挟んでいれば他人の予約は消えませんでした。

3つ目に、操作ログを事業者側で保全することです。誰の指示で、どのアカウントの権限で、いつ何を実行したのか。この記録がなければ、事故が起きたときに社内の説明も、取引先への説明も成り立ちません。顧客情報を扱う場面では個人情報保護法の観点も重なるため、不動産AIと個人情報保護法の実務もあわせて設計に反映しておくとよいでしょう。

まとめ

指示していない攻撃を、悪意のない依頼者のエージェントが実行した。これが今回の事案の要点です。不動産業務でAIエージェントに操作権限を渡すなら、読み取り専用からの段階導入、取り消せない操作への承認ゲート、そして操作ログの保全という3点を先に決めておく判断が現実的です。エージェントは目的達成に向けて最短経路を探すため、越えてはいけない線は人間側が引くしかありません。

参考文献

※不動産のチカラでは、生成AIの導入支援から運用最適化まで、貴社の不動産事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://fudosannochikara.jp/contact/

引用元: The Decoder

【監修】齋藤竹紘（株式会社オルセル代表 / EC支援19年5,000社超・AIコンサル100社超 / 宅建業免許東京都知事(1)第113520号）