AI議事録ツールtl;dvで18万件の会議データが流出|今日やるべき3つの確認
代表取締役 上坂大地郎

結論: AI議事録ツール「tl;dv」のデータベースにテナント分離の設定漏れがあり、認証済みユーザーなら誰でも他社・他者の会議メタデータにアクセスできる状態でした。セキュリティ研究者は181,874件の会議記録と84,312ユーザーの情報が露出していたと報告しています。ただし、tl;dv側は「アクセスできたのはメタデータのみで、録画・文字起こし・AIノートは含まれない」と反論しており、両者の主張には開きがあります。
この記事の要点:
- tl;dvのFirestoreデータベースにテナント分離ルールが欠落し、181,874件の会議メタデータが露出していたとセキュリティ研究者が報告(bobdahacker、2026年8月4日公開)
- 影響範囲は35,003のメールドメインに及び、三井倉庫・東京大学を含む日本の組織や23カ国の政府機関のデータも含まれていた
- tl;dvは「メタデータのみの露出で、録画・文字起こしへのアクセスはなかった」と反論し、修正完了とAbicomによる検証済みを主張(2026年8月5日公開、8月13日更新)
対象読者: リモート会議でAI議事録ツールを使っているエンジニアやチームリーダー、クライアント先でSaaSツールの選定・導入に関わる方
読了後にできること: 自分のチームが使っているAI議事録ツールについて、「会議データがどこに保存され、誰がアクセスできる設定になっているか」を具体的に確認できるようになります
僕自身、8名のSES会社でClaude Codeを全社導入し、AI秘書のFRIDAYに日常業務を任せています。クライアントとの会議にもAIツールを使う場面がある以上、「自分のツールは大丈夫か」は他人事ではありませんでした。この記事では、tl;dvで何が起きたのかを事実ベースで整理し、AI議事録ツール全般で今日確認すべきポイントまで踏み込みます。
18万件の会議メタデータが露出していた
2026年8月4日、セキュリティ研究者のbobdahackerが自身のブログで、AI議事録ツール「tl;dv」の脆弱性を公開しました。
tl;dvはZoom・Google Meet・Microsoft Teamsに対応したAI議事録サービスで、会議の録画・文字起こし・要約を自動で行います。研究者が発見したのは、このサービスが使うGoogle Cloud Firestoreデータベースにテナント分離のセキュリティルールが欠落していた問題です。
研究者の報告した数字
項目 | 数値 |
|---|---|
露出した会議記録 | 181,874件 |
影響ユーザー数 | 84,312人 |
影響メールドメイン数 | 35,003ドメイン |
常時録画中のライブ会議 | 約1,000件 |
ピーク月の録画件数(2025年7月) | 43,209件 |
研究者によれば、tl;dvの認証済みアカウントを持つ誰もが、自分が参加していない他組織の会議メタデータを自由にクエリできる状態でした。
tl;dvの反論——「メタデータのみ」
tl;dvは2026年8月5日に公式ブログで反論を公開しています(8月13日に最終更新)。同社の主張は以下の通りです。
- アクセスできたのは「会議のメタデータ(会議ID・カンファレンスID・参加者メールアドレスなど)」のみ
- パスワード・録画・文字起こし・AIノート・アカウント情報・請求データにはアクセスできなかった
- 文字起こしやノートにアクセスできたのは、ユーザーが明示的に「公開」設定にした会議のみ
- ライブ会議への参加については、「見慣れない名前でのリクエストに対し、主催者が手動で許可する必要があった」と限定
つまり、露出した情報の範囲について研究者とtl;dvの主張に開きがあります。研究者は「他アカウントの会議記録にアクセスできた」と報告し、tl;dvは「メタデータのみで、コンテンツ本体は含まれない」と主張しています。第三者による独立検証は執筆時点で確認できていません。
Firestoreのテナント分離——何が壊れていたのか
専門用語が出たので、かみ砕きます。
Firestoreは、Googleが提供するクラウドデータベースサービスです。Webアプリやモバイルアプリのバックエンドとして広く使われており、tl;dvもこの上に構築されています。
Firestoreの特徴は、ユーザーのブラウザからデータベースに直接アクセスできる設計です。通常のWebアプリはサーバーを経由してデータベースにアクセスしますが、Firestoreではブラウザ→データベースの直接通信が可能です。
そのため、アクセス制御はFirestoreのセキュリティルールで行います。「ユーザーAは自分の組織のデータだけ読み書きできる」というルールを設定し、他の組織のデータにはアクセスできないようにする——これがテナント分離です。
たとえるなら、オフィスビルの各フロアに鍵がかかっている状態がテナント分離です。今回の問題は、フロアの鍵が全部開いたままだったようなもので、ビルの入館証(=tl;dvのアカウント)を持っていれば、どのフロアの会議室にも入れる状態でした。
この種の設定ミスはFirestoreに限った話ではありません。npmサプライチェーンワームの事例でも触れたように、依存するインフラの設定不備が広範な影響を及ぼすパターンは繰り返し起きています。
影響を受けた組織——23カ国の政府機関と日本企業
研究者の報告によれば、露出したドメインには以下が含まれていました。
日本関連
組織 | 会議数(研究者報告) |
|---|---|
三井倉庫(4拠点) | 484件 |
三井不動産 | 報告あり(件数不明) |
東京大学 | 報告あり(件数不明) |
その他の主要組織
- 23カ国の政府機関: 米国・日本・ブラジル・ウクライナ・マレーシア・カタール・イスラエルなど
- 教育機関: カリフォルニア大学バークレー校、コロンビア国立大学
- 企業: HubSpot、Confluent、Mekari
.govドメインの存在は、政府機関の会議にもAI議事録ツールが使われている実態を示しています。これはAIエージェントの承認を人間が3分の1見逃す研究が指摘した「AIツールへの過信」とも通じる問題です。
報告から6ヶ月——修正に至るまでの経緯
日付 | 出来事 |
|---|---|
2026年1月28日 | 研究者がLinkedIn経由でtl;dvに報告。CTO宛メールも送付 |
1月29〜30日 | tl;dv側のRaphael氏が「対応する」と回答。脆弱性は未修正 |
2〜3月 | 研究者が複数回フォローアップ。CTOからの返答なし |
7月22日 | 研究者が最終フォローアップ。研究者の報告では未修正 |
8月4日 | 研究者がブログで脆弱性を公開 |
8月5日 | tl;dvが公式ブログで反論を公開 |
8月13日 | tl;dvのブログが最終更新。修正完了とAbicomの検証済みを主張 |
食い違うタイムライン
研究者は「7月末時点でまだ修正されていなかった」と報告しています。一方tl;dvの主張は以下の3点です。
- 独立したペネトレーションテスト会社Abicomが修正を検証済みで、署名入り証明書を発行した
- 研究者が発見したものとAbicomが発見したものは「別の攻撃ベクトル」であり、2つ目は発見から24時間以内に修正した
- Firebaseからの完全移行を進める(ただし具体的なスケジュールは未公表)
確認できている事実と、判断を保留すべき点
この事案で注意すべきは、研究者とtl;dvの主張が複数の点で食い違っていることです。
確認済みの事実
- tl;dvのFirestoreにテナント分離の不備があった(両者が認めている)
- 研究者が2026年1月28日に報告した(研究者のブログに記録あり)
- tl;dvが8月5日に公式回答を公開した(同社ブログで確認可能)
- 独立ペンテスト会社Abicomが検証に関与した(tl;dvの主張。Abicom側の公開声明は未確認)
主張が割れている点
論点 | 研究者の主張 | tl;dvの主張 |
|---|---|---|
露出範囲 | 会議記録全体 | メタデータのみ |
修正時期 | 7月末時点で未修正 | 修正済み・Abicom検証済み |
録画・文字起こし | アクセス可能だった | 公開設定の会議のみ |
第三者の独立検証は執筆時点で確認できていません。 どちらの主張が正確かを判定する材料は不十分です。
AI議事録ツールを使うなら今日確認すべき3つのポイント
tl;dvの事案にかかわらず、AI議事録ツール全般で確認すべき点があります。
1. 会議データの保存先とアクセス制御を確認する
AI議事録ツールは、録画・文字起こし・要約データをクラウドに保存します。確認すべきは以下の3点です。
- データの保存先: どのクラウドサービス(AWS/GCP/Azure)のどのリージョンに保存されるか
- アクセス制御: 同じ組織内でも「誰がどの会議のデータにアクセスできるか」が設定できるか。デフォルトで全社員に全会議が見える設定になっていないか
- データ削除: 退職者のデータや不要な会議データの削除が、管理者の操作で可能か
特にクライアント先の会議を録画する場合、クライアントの情報セキュリティポリシーとの整合性を事前に確認する必要があります。
2. 「公開」設定を棚卸しする
tl;dvの事案でtl;dv側が「公開設定の会議のみアクセスできた」と主張しているように、意図せず「公開」になっている会議がないかは定期的に確認すべきです。
- リンクを知っていれば誰でもアクセスできる「リンク共有」がデフォルトになっていないか
- 過去の会議で、一時的に共有したまま戻し忘れている設定がないか
- チームの新メンバーが追加されたとき、過去の全会議データにまでアクセスできる設計になっていないか
3. ツール選定時にセキュリティ開示の姿勢を評価する
今回の事案では、研究者の報告に対するtl;dvの初動対応が議論になっています。ツールを選ぶ際に確認したいのは、以下の点です。
- 脆弱性報告の窓口が公開されているか(セキュリティページ、bug bountyプログラムの有無)
- 過去のインシデント対応の実績があるか(透明性のある対応をしているか)
- SOC 2 Type IIやISO 27001などの第三者認証を取得しているか
これはAtlassian Rovo脆弱性の事例でも指摘した、AIツールのセキュリティ評価を導入前に行うという考え方と同じです。AI議事録ツールもその対象に含まれます。
AI議事録ツールとの付き合い方
AI議事録ツールは、会議の生産性を上げる実用的なツールです。ただし、会議の中身——参加者・議題・発言内容——は企業にとって機密性の高い情報です。
今回の事案が示しているのは、ツールの利便性と引き換えに会議データをどこに預けているかを意識しないまま使い続けるリスクです。Otter.aiの同意なし録音をめぐる集団訴訟(2025年)や、Fireflies.aiの生体データ収集訴訟など、AI議事録ツールのセキュリティ・プライバシー問題はtl;dvに限った話ではありません。
この記事に実測値はなく、公式発表と研究者の報告に準拠した調査報告です。ツール選定や設定確認の具体的な手順については、OpenAI評価AIのHugging Face侵害の記事もあわせて参照してください。
参考・出典
- tl;dv (Too Lazy; Didn't Validate): 181,874 Meetings Left Wide Open(https://bobdahacker.com/blog/tldv-hack) — bobdahacker(参照日: 2026-08-17)。脆弱性の技術詳細・影響範囲・タイムラインの一次情報【一次】
- Our thoughts on the darkreading.com article(https://tldv.io/blog/our-thoughts-on-the-darkreading-com-article/) — tl;dv公式ブログ(参照日: 2026-08-17)。tl;dv側の反論・修正経緯・Abicom検証の主張【一次】
- AI Notetaker Lets Hackers Spy on Government, Corporate Video Calls(https://www.darkreading.com/application-security/ai-notetaker-spy-government-corporate-video-calls) — Dark Reading(参照日: 2026-08-17)。インシデントの第三者報道
- tl;dv Security Breach: What It Means for Anyone Using or Building an AI Notetaker(https://www.happyscribe.com/blog/tldv-security-breach) — Happy Scribe(参照日: 2026-08-17)。AI議事録ツール業界への影響分析
- Inside the tl;dv Flaw That Exposed Live Government and Corporate Meetings(https://blog.netizen.net/2026/08/04/inside-the-tldv-flaw-that-exposed-live-government-and-corporate-meetings/) — Netizen(参照日: 2026-08-17)。政府機関への影響の詳細報道
- Are AI Meeting Assistants Safe? 2026 Privacy Risks Exposed(https://meetily.ai/blog/ai-meeting-assistants-safe-privacy-risks) — Meetily(参照日: 2026-08-17)。AI議事録ツール全般のセキュリティリスク分析