Masaru’s Eye | APIを破るのは、ハッカーではなく顧客のエージェントかも——スタートアップが点検すべき3つの場所

Public Domain Image by W.carter via Wikimedia Commons

メルボルンに住むAndrewという男性が、自分のAIアシスタントにジムの人気クラスの予約を頼んだ。エージェントは予約ソフトの脆弱性を見つけ、ジムが許可している期間より数ヶ月も先まで予約を取った。そして、彼がキャンセル待ちの順位を上げられないかと聞くと、エージェントは頼まれてもいないのに、待機列の1番目にいた人物の予約を削除した。

同じ月、ドイツのAI議事録サービス「tl;dv」のデータベースが、18万件を超える会議レコードを誰でも一覧できる状態だったことが公表された。セキュリティ研究者が最初に通報したのは1月28日。公表されたのは、その半年後だった。

この2つは別々の事件だが、同じ場所を指している。後回しにされる場所は、大きく3つある。予約APIの認可チェック、データベースのアクセスルール、セキュリティ通報の受け口。どれもコンバージョンにも売上にも直結しないため、あらゆるスタートアップが合理的に後回しにしてきた領域である。そこが、外部から入られる最初の一手になり始めている。

「4番目から3番目に移動しました」

事件の詳細はABC Newsが報じ、オーストラリアで初めて確認された自律型AIによるサイバー攻撃と位置づけられた。Andrew氏は企業向けAI製品を扱うオーストラリア企業に勤めており、OpenClaw上で Anthropic の Claude を動かしていた。

技術的な核心は退屈なほど単純だ。予約とキャンセル待ちのAPIには権限チェックがあり、認可されていないリクエストには403（閲覧禁止の応答コード）を返していた。ところがキャンセル用のエンドポイントにだけ、その保護がなかった。誰でも他人の予約を消せる状態だったのである。エージェントはそれを見つけ、試し、成功したことを淡々と報告した。

ここで注意したいのは、エージェントが高度な攻撃技術を使ったわけではない、という点だ。やったことは、公開されているAPIを順に叩いて、返ってくるレスポンスの違いを観察しただけである。人間のセキュリティ研究者なら30分でやる作業を、指示されないまま、目的達成の副産物としてやってのけた。

ジムの予約ソフトのベンダーは、ABCの取材に対して個別のセキュリティ事項は議論しないと答えた。Anthropic はコメントしなかった。被害を受けた会員は名乗り出ておらず、警察への被害届も出ていない。

1つ目の場所、予約APIの認可チェックから見ていく。この種の認可の抜けは、いまに始まったものではない。オブジェクトレベルの認可不備（他人のIDを指定すると、他人のデータを読み書きできてしまう欠陥）は、Webアプリケーションの脆弱性としては古典に属する。ジムの予約システムに穴があったこと自体は、業界の誰も驚かない。

変わったのは、その穴を探しに来る主体の数と性質だ。これまで、小規模な予約システムの穴は事実上「誰も探しに来ないから安全」という状態で放置されてきた。攻撃者にとって、地方のジムの予約枠を奪うために脆弱性を探す労力は割に合わない。攻撃者側の経済合理性が、そのまま防御として機能していたのである。限られたリソースを配分する判断として、これは正しかった。

エージェントはこの前提を壊す。攻撃コストがほぼゼロになると、標的の価値が低くても探索は起きる。しかも探索を始めるのは敵ではなく、自分のために予約を取ろうとしている自社の顧客だ。悪意がないから隠す必要もなく、通報される可能性も低い。穴は見つかったまま、放置される。

かつてのbotとの違いも押さえておく必要がある。転売botは単一タスク特化で、脆い。買い占めるという一つの動作をひたすら繰り返すので、振る舞いのパターンが読める。対してエージェントは、目的だけを与えられて達成経路を自分で探索する。403が返ってきたら別のエンドポイントを試し、レート制限に当たったら間隔を空ける。振る舞いの規則性を手がかりに弾くという防御の前提そのものが揺らぐ。

もう一つの後回し──18万件の会議レコード

2つ目の場所は、データベースのアクセスルールである。ドイツ発のAIミーティングアシスタント「tl;dv」の件は、攻撃者がエージェントかどうかとは無関係だが、同じ領域の話である。研究者bobdahacker氏の公開レポートによれば、tl;dv のサインアップ認証を通すと Firestore（Google のクラウドデータベース。クライアントから直接読み書きする設計のため、アクセスルールがセキュリティ境界そのものになる）にクエリを投げられるトークンが手に入り、meetings コレクションにテナント分離が設定されていなかった。

ユーザー、チャット、文字起こし、録画、ノート、組織といった他のコレクションはすべて正しく403を返す。meetings だけが抜けていた。そこには35,003ドメインにまたがる84,312ユーザーの、181,874件の会議レコードがあった。23カ国の政府ドメインが含まれ、日本からも、東京大学、三井倉庫、三井不動産、HubSpot、Confluent、AnyMind Group といった名前が並ぶ。

レコードには conference ID が含まれる。これは Google Meet や Microsoft Teams の会議室に入るためのリンクそのものだ。そして常時およそ1,000件が「録画中」ステータスで並んでいた。bobdahacker氏は実証として、マレーシア教育省が157人を集めて開催中の会議に入室し、次にアメリカの大学生21人がスタートアップのプロトタイプを画面共有している通話に入った。どちらも、外部の人間が入ったことに誰も気づかなかった。Dark Reading が8月4日に報じた時点でも、この状態は続いていた。

tl;dv 側は反論を公表している。露出したのはメタデータに限られ、パスワード、録画、文字起こし、AIノート、請求データにはアクセスできなかった。会議内容を読めたのは、ユーザーが明示的に公開設定にしたものだけで、公開共有は初期設定でオフになっている、と。この主張は事実として妥当だと思われるし、併記されるべきだ。それでも、生きた会議室の鍵が配られていたことと、通報から半年間その状態が続いたことは動かない。

tl;dv のセキュリティページには SOC 2、GDPR（一般データ保護規則）、EU AI Act（ヨーロッパ人工知能法）への準拠が掲げられている。この件を受け、SOC 2 は無意味だという反応がネット上で広がった。SOC 2 が監査するのはプロセスと文書で、アクセス制御に関する方針が定められ、レビューの手続きが存在し、記録が残っていることを確認する。データベースの特定コレクションに、他コレクションと同じルールが適用されているかどうかは監査対象外だ。

日本のスタートアップにとって、この区別は営業の現場で効いてくる。エンタープライズの調達で ISMS や SOC 2 の有無を問われることは増えている。取ること自体は正しい投資だ。ただし、バッジは「この会社は安全である」ことを意味しないし、顧客側もそう理解しているとは限らない。バッジを持つ側は、その差分を自分で埋める責任を負っている。

3つ目の場所は、セキュリティ通報の受け口である。研究者からの通報にどう応答するかという運用は、日本の実務者にとりわけ届きにくい。tl;dv の件でCEOは数分で反応し、CTOに引き継いだところで止まった。悪意ではなく、単に誰の担当でもなくなったのだろう。security@ アドレス宛のメールが誰のメールボックスにも届かない会社は、日本にも相当あるはずだ。これは組織設計の問題である。

エージェントの攻撃能力が誇張ではないことは、AIラボ自身の動きからも読める。

OpenAI は8月7日、開発中のモデル「Astra」について、内部評価の結果を受けて一部の作業を停止したと発表した。同社の Preparedness Framework における「クリティカル」なサイバー能力の水準に達している可能性を否定できない、というのが理由だ。この水準は、人間の介在なしに、堅牢に防御された実世界のシステムに対してゼロデイ脆弱性を発見し、実際に攻撃を遂行できる能力を指す。この区分が発動したのは初めてで、OpenAI は政権に対して自発的に遅延の方針を伝えたとされる。

イギリスのAI Security Institute も8月上旬、サイバー演習環境でのテスト結果を公表している。WIRED の報道によれば、安全機能の一部を意図的に無効化した条件下で、122回の実行のうち19回、モデルがインターネット上で自律的かつ無許可の行動を取った。最も深刻な事例では、GitHub のオープンソースプロジェクトに悪意あるコードを挿入しようとしていた。

日本の予約インフラは大丈夫か

日本は予約SaaSが異様に厚い国である。飲食だけでも TableCheck、トレタ、ebica、レストランボード、ぐるなび台帳が並び、そこに美容室、クリニック、フィットネス、レンタルスペース、習い事の予約サービスが加わる。人口あたりの予約システムの密度で言えば、世界でも高い部類に入るだろう。

前史もある。2018年、イープラスは同社のチケット購入サイトへの一般先着販売時のアクセスのうち、9割超がbotだったと公表した。振る舞い検知型のツールを導入するまで、CAPTCHAは自動解析で突破され、レート制限は閾値を探られて回避されていた。翌2019年6月にはチケット不正転売禁止法が施行されている。日本のチケット業界は、技術と法律の両方でbotと7年戦ってきた。その蓄積は、エージェント相手にそのままは効かない。

実は、（倫理的にも正しい）割り込み自体は、日本ではすでにビジネスとして成立している。一部の予約サービスでは、行列のできる店で、客が手数料を払えば待ち行列をスキップできる仕組みを提供している。

エージェントを使えば無料で同じ効用が得られるなら、そちらに流れる圧力は構造的に存在する。予約枠が希少で、かつ先着順で配分されているサービスは、すべてこの圧力の下にある。一つ目の場所、予約APIの認可チェックを実際に点検するなら、見るべき箇所はそう多くない。予約、変更、キャンセルの各エンドポイントで、リソースの所有者チェックが個別に実装されているか。IDが連番になっていないか。予約可能期間の上限をフロントエンドだけで制御していないか。いずれも、外部の目が入ればすぐ露出する。

そのうえで正直に書いておくと、これは完全に塞げる種類の問題ではない。エージェントは正規のユーザーアカウントで、正規のAPIを、想定より丁寧に使っているだけだからだ。異常検知で弾こうとすれば、熱心なユーザーも巻き添えになる。エージェント経由のアクセスを一律に拒否する道もあるが、数年後にそれは顧客を捨てる判断になっているかもしれない。

オーストラリアの事件で、法的責任を負う者はいまのところ誰もいない。Andrew氏は攻撃を指示していないし、OpenClaw はオープンソースで、誰でもダウンロードできるし、Anthropic はモデルを提供しただけだ。ジムのベンダーには脆弱性があったが、脆弱性があること自体は違法ではない。

日本に目を転じると、不正アクセス禁止法の適用が問題になる。同法は識別符号を無断で入力する行為やセキュリティホールを攻撃する行為を禁じているが、正規に取得した自分のアカウントで、公開されているAPIを叩いた場合にどう評価されるかは不明だ。故意の要件をエージェントの挙動にどう当てはめるかも整理されていない。この点は法律家の見解を仰ぐべき領域だろう。

事業者側から見ると、法的な決着を待つ意味は薄い。責任の所在が曖昧なまま、実害だけが自社に落ちてくる構図だからだ。順番待ちを飛ばされた会員に説明するのは、法律家でもモデル提供者でもなく、予約システムを運営している会社である。

ロンドン発のテック番組「European Technology Network」の8月11日回では、出演者らが予約プラットフォーム向けのエージェント対策レイヤーが新しいカテゴリとして立ち上がると予測していた。ジムやレストラン、チケット、コンサートといった成熟度の低い予約システムが、エージェントが増えるにつれ業界の最も手薄な標的になる（soft underbelly）という見立てだ。エージェントを排除するのではなく、正規のエージェントを識別し、権限を与え、行動を記録する——認証と認可の再設計の仕組みなら、ビジネスとしての可能性もあるだろう。

そして、一つはっきりしているのは、後回しにできる時間が短くなったということだ。予約APIの認可チェックも、データベースのアクセスルールも、セキュリティ通報の受け口も、コンバージョンには効かない。3つとも、事故が起きるまで誰の成果にもならない場所である。経営サイドにはモチベが働かないまま、事故が起きたときのコストだけが上がっていく。Andrew氏の招いた事件の後の、ジム、ジムの予約ベンダー、Anthropic の無反応ぶりは、この問題の性質をよく表している。