AI議事録18万件が開かれていた — 書き起こすボットに預けた信頼のコスト

AI会議録画サービスに会話を委ねるのは、利便性を買う取引なのか、それとも組織のもっとも機微な瞬間を自分たちの制御外に預ける行為なのか。tl;dvで18万件を超える会議がアクセス制御なしに開かれ、その扉が6か月にわたって閉じられなかったという事実は、この取引の請求書がどこへ届くのかを示している。

導入

2026年初頭、あるセキュリティ研究者(ブログbobdahacker)がAI会議録画・要約サービスtl;dvのバックエンドを覗いた。tl;dvはGoogle Meet・Zoom・Teamsに接続して通話を録画し、発話を書き起こし、要約まで生成するサービスで、ユーザーは200万人を超えるとされる。研究者が見つけたものは単純だった。無料プランのアカウントが一つあれば、自分のものではない他人の会議記録をアカウントの境界を越えて照会できたのである。露出の規模は会議記録181,874件、ユニークユーザー84,312人、メールドメイン35,003個だった(出典: bobdahacker)。そしてこの扉は、研究者が発見して通報したあとも6か月にわたって閉じられなかった。営業商談、採用面接、人事評価、そして23か国の政府部門の会議まで — 組織がもっとも慎重に扱う会話が、一つのベンダーのデータベースの一コレクションに集まり、そのコレクションの錠だけがかかっていなかった。本稿では、何がどう開かれていたのか(事実)と、なぜこの種の事故が繰り返され、我々が何を錯覚しているのか(分析)を分けて見ていく。

何が開かれていたのか: 議事録18万件と「入れてしまう」部屋

まず脆弱性の性質を正確に押さえよう。これは一般にIDOR(不適切なオブジェクト参照)と呼ばれるアクセス制御欠陥の一種である。tl;dvはバックエンドにFirebase/Firestoreを用いており、データを収めるいくつものコレクションのうち、ユーザー(users)・トランスクリプト(transcripts)・録画(recordings)コレクションにはテナント分離(tenant isolation)のルールが適切にかかっていた。問題は会議(meetings)コレクションだった。この一コレクションだけ分離ルールが欠けており、gw.tldv.io/v1/users/firebase/tokenから発行されたFirebaseトークンを持つ認証ユーザーであれば、誰でも他アカウントの会議レコードを照会できた(出典: bobdahacker)。つまり認証そのものが無かったのではなく、認証済みユーザーを自分のデータに閉じ込める境界が、このコレクションにだけ無かった。塀はあるのに、一軒の門だけが開け放たれていたようなものだ。

照会できたのは一覧だけではない。各レコードには会議作成者のメールアドレス、録画状態とタイムスタンプ、そして決定的にカンファレンスIDが含まれていた。このカンファレンスIDは、実際に参加可能なGoogle Meet・Teamsの部屋のアドレスだった。研究者によれば、任意の瞬間に1,000件以上の会議がリアルタイムで録画されており、それらの部屋のIDがそのまま露出していた。研究者はこれを「ボットを使う攻撃者なら、1,000件のライブ通話に同時に入り込める」と記している(出典: bobdahacker)。これは事後に漏れた記録の問題ではなく、いま進行中の会話に見知らぬ者が歩き込めるという、リアルタイムの侵入の問題である。実際に研究者は概念実証として、参加者157人を超えるマレーシア教育省の会議と、参加者21人規模の米大学スタートアップ企画セッションに入ってみたと明かしている。

規模の感覚のために、いくつか数字を追加しておく。公開(public)と表示された会議1,000件以上は、トランスクリプトと録画内容まで露出し、そうした公開会議の招待対象メール715個が228のドメインにまたがって現れた。研究者は27,334個の会議IDを収集し、そのうちどれが公開録画かを識別した。録画量は2025年7月の一か月で43,209件のピークをつけ、もっとも混雑する時間帯である水曜午後2時(UTC)には7,804件が同時に進行していた(出典: bobdahacker)。露出した会議には、ブラジル・コロンビア・ペルー・ウクライナ・フィリピン・メキシコ・米国・カタール・マレーシア・日本・イスラエルなど23か国の政府会議が含まれていた。HNの議論で、ある参加者がこの国名リストをそのまま引用し、ウクライナ政府の会議がロシアに露出している可能性を半ば冗談として指摘したのも、この名簿ゆえだった。

さらに枝葉がもう一つあった。tl;dvが社内用に作ったFIFAワールドカップ予測アプリ(worldcup.tldv.io)のAPIエンドポイントが認証なしに開かれており、従業員19名の実名と会社メール、事実上の全従業員名簿が現れた(出典: bobdahacker)。規模は小さいが、シグナルは明確だ。アクセス制御を漏らしたのは一か所ではないということ、すなわちこれが一回きりのミスではなく習慣に近いということである。

なぜこの種のことが繰り返されるのか: 便利な既定値と壊れたアクセス制御

アクセス制御の欠陥は新しい病ではない。OWASPが挙げるWeb脆弱性の第1位がまさに「壊れたアクセス制御(Broken Access Control)」であり、その中でIDOR類 — 自分の識別子を他人の識別子に置き換えると他人のデータが付いて出てくる欠陥 — は、もっともありふれ、もっとも退屈なミスである。退屈だという点が肝心だ。この種の欠陥は精巧な攻撃技術からではなく、開発者が「このユーザーはこのレコードを見る権限があるか」という問いを一か所で漏らしたときに生じる。HNの議論で、あるセキュリティ実務者は「クロステナント分離は自分が点検するときに真っ先に確認する項目の一つなのに、こんな基本的なことができていないのを見るたびに驚く」と記した。錠を新たに発明する必要はない。すべての扉に同じ錠をかける規律の問題なのである。

その規律はなぜ崩れるのか。一つの構造的原因は、ツールの既定値である。HNでは複数の参加者がFirebase/Firestoreを名指しした。プラットフォームそのものを責めるのではなく、「始めるのが簡単(easy to start)」を前面に押し出したマーケティングと、「既定で安全(secure by default)」ではない設計との間のギャップを指摘するものだ。ある参加者は「同じことが繰り返し起きるなら、それは偶然ではなく選択だ」として、Firebaseが安全を既定に置くよりも、始めやすさを選んだと突いた。別の者は「このツールを安全に使うには知識と経験が要るのに、マーケティングはそれが不要だと言う」と付け加えた。いくつものコレクションのうち一つだけルールが欠けていたというこの事故の形そのものが、ルールを明示的に一つずつかけねばならないシステムで、人が一つを忘れる典型的な失敗である。

もう一つの原因は、作り方そのものをめぐる論争だ。HNでは、このバックエンドをAIが書いたのではないかという推測と、それへの反論が交わされた。一方は、昨今の最新モデルであれば認証なしの実装をそのまま吐き出すことはなく、リリース前の点検でこの種の明白な問題は弾かれるはずだと述べ、他方は「最新モデル(SOTA)」という盾が7秒ごとに変わりながら何でも弁護するのに使われる、と冷笑した。興味深い折衷案も出た。すでに杜撰なコードベースの上でモデルを走らせれば、モデルは既存の「慣例」に合わせてさらに杜撰なコードを喜んで書き出すということ、そしてどちらであれコードに一度レビューを回していればこの問題は捕まえられたはずだという指摘である。AIが犯人か否かはさておき、レビューという手続きが抜けていたという結論は同じだ。

しかしこの事件でもっとも重い構造的問題は、コードではなく設定(configuration)の問題、より正確には集中(concentration)の問題である。AIノートテイカーは本質的に、組織でもっとも機微な会話を一か所に集める装置だ。営業交渉の手の内、採用面接の評価、人事評価の面談、取締役会の議論 — かつてなら各自の頭の中と散らばったメモに残ったものが、いまや書き起こすボットを経て一つのベンダーのストレージへ流れ込む。利便性の対価として、我々はリスクを一点に凝縮する。その一点のアクセス制御が崩れた瞬間、散らばっていれば決して一度に漏れなかったものが、18万件単位で一挙に漏れる。HNで、ディープフェイク音声フィッシング会社を運営するという参加者は、このリスクを実務の観点から突いた。顧客はいつも「攻撃者がいったい我々の従業員の声をどこで手に入れるのか」と反問するが、まさにこの種の漏洩がその答えだというのだ。会議録画は声・名前・文脈を一つの束として提供し、それは標的型詐欺の完璧な原料になる。利便性とプライバシーのトレードオフは抽象ではなく、漏れた音声クリップがそのまま武器になるという具体的な損益なのである。

沈黙した6か月: 開示(disclosure)とベンダーの責任

脆弱性そのものと同じくらいこの事件を注目させたのは、開示(disclosure)の過程である。研究者は2026年1月28日、tl;dv側に欠陥を通報した。tl;dvのセキュリティ案内には「セキュリティ問題を見つけたらprivacy@tldv.ioに知らせてほしい、セキュリティチームが24時間以内に応答する」という一行が記されていた(出典: bobdahacker)。現実はその約束と違った。CEOのRaphael Allstadtは通報を受け「ありがとう、CTOに報告してほしい、すぐに見る」と答えたが、当のCTOはついに応答しなかった。2月19日の「対応中だ、少し時間が要る」という返答が最後に近く、3月と7月まで欠陥はそのまま生きていた。発見から6か月が過ぎても、扉は閉じられなかった。

この点でHNの議論は、二つの鋭い論争に分かれた。第一はベンダーの怠慢についてである。「これほど致命的な問題なら、6時間でもなく6か月放置するとは何事か、大きな赤い停止ボタンを押すべき事案だ」という激した反応が多かった。CEOが認識しながら動かなかったという点で、経営陣の失敗は個々の開発者のミスとは異なる重みを持つという指摘も出た。第二は開示の倫理である。研究者が露出した顧客名(政府部門など)を公開したことが、かえって顧客を危険にさらしたのではないかという批判に対し、多数は逆に答えた。顧客を危険にさらしたのは公開した研究者ではなく、6か月放置した会社であり、すでにこの欠陥を知って静かに悪用している別の者がいるかもしれない、というのだ。ある参加者は「顧客を責めるのは、ディーゼル車を買ったのはお前のせいだとフォルクスワーゲンが言うようなものだ」と反論した。信頼に足る規制機関が即時のサービス停止を命じられない現実で、公開的な恥さらしが事実上唯一の是正のてこだという冷静な診断もあった。

法的な論点も興味深かった。「6か月も直さなかったのだから、好きなだけ掻き集めてもいいのではないか」という半ば冗談に対して、複数が、それは依然として犯罪でありうると線を引いた。データが容易にアクセスできるという事実が、そのデータを「公開データ」にするわけではないというのだ。ある参加者は「物がネジで固定されていないからといって、持ち去ってよいわけではない」と喩え、別の者は米国のCFAAが「権限なく、または許可されたアクセス範囲を越えてコンピュータにアクセスする行為」を禁じる点を思い起こさせた。アクセスが技術的に容易だったという事実は、免責の理由にはならない。

実務者に残る示唆は明確だ。AIノートテイカーを導入するとは、便利なツールを点けることではなく、組織のもっとも機微な会話を処理するデータプロセッサを一つ、信頼の連鎖に加えることである。であれば、ベンダー実査(due diligence)の問いは「要約がどれほど正確か」から「テナント分離をどう検証しているか、脆弱性報告に実際に何時間で応答するか、録画・トランスクリプトの保存と破棄の方針は何か」へと移らねばならない。24時間応答を約束した会社が6か月沈黙したというこの事件は、ベンダーのセキュリティ文言を契約書ではなくマーケティングとして読むべきだという高価な教訓を残す。HNである参加者は、いっそローカル(オンデバイス)のノートテイカーだけがこの問題の根本解だと述べつつ、ただしローカルで話者分離(diarization)と発話者識別が十分に良い製品をまだ見つけられていないと吐露した。利便性をローカルへ取り戻す道は、まだ狭い。

結論

リードの問いへ戻ろう。AI会議録画に会話を委ねるのは、利便性の購入なのか、リスクの預け入れなのか。tl;dvの事件は、それが同時にその両方であることを示している。我々は書き起こしと要約という利便性を買いながら、組織のもっとも機微な瞬間を一つのベンダーの一つのデータベースに凝縮して預ける。その凝縮は、ベンダーがすべての扉に同じ錠をかける規律を守るときにのみ安全だ。一つのコレクションの分離ルールが欠けた瞬間、散らばっていれば決して一度に漏れなかった18万件が、認証ユーザーひとりの前に開く。そしてその扉を閉じるのに6か月かかるなら、問題はコード一行ではなく、その会社が信頼を扱うやり方の全体である。

だから本稿が残したいのは、特定のサービスへの糾弾ではなく、一つの点検の習慣だ。いまあなたの組織が使う書き起こすボットは、あなたが制御できない場所に何をどれだけ集めているのか。そのベンダーはテナント分離を検証しているか、報告に何時間で答えるか、録画をいつ消すか。次の会議で「録画を開始します」という通知が出るとき、我々が実際に押して承認するのは利便性だけではない。その場で交わされたすべての言葉が誰かの未払いの請求書として積み上がらない、という検証されていない信頼である。その信頼の値はいくらであり、請求書はいま誰の前に置かれているのか。


出典: