AI議事録ツール「tl;dv」、Firestoreの設定不備で18万件超の会議情報が公開進行中の通話への無断参加も研究者と企業側の説明は対立|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年08月12日更新日時: 2026年08月12日

AI会議アシスタント「tl;dv」を提供するtl;dv社は2026年8月5日、セキュリティ研究者による指摘とDarkReadingの報道を受け、自社の技術スタックにおける脆弱性について公式見解を公表しました。研究者側は、認証済みの利用者であれば誰でも、全テナントをまたいで会議記録を閲覧でき、進行中の通話にも無断で参加できる状態だったと報告し、2026年1月の報告から6カ月間対応がなかったと主張しています。一方tl;dv社は、これは1つではなく2つの独立した脆弱性であり、それぞれ適切な期間内に修正したと説明しており、両者の説明には食い違いが残っています。

この記事のサマリー

セキュリティ研究者BobDaHacker氏は、tl;dvのバックエンドで使用されているGoogle Firebase（Firestore）の「meetings」コレクションに、テナント間の分離（アクセス制御）が設定されていなかったと報告しています。
研究者によると、認証済みの利用者であれば誰でも、全アカウントを横断して会議記録を照会でき、作成者のメールアドレス、会議ID（Google MeetやMicrosoft Teamsの参加リンク）、録画状況、タイムスタンプなどが取得可能でした。録画中のステータスにある会議については、その会議IDがそのまま進行中の通話への参加リンクとして機能していたとされています。
DarkReadingの報道によると、この問題は2026年1月28日に最初に報告されたのち、7月まで複数回のフォローアップが行われましたが、修正されないまま2026年8月4日の記事公開時点でも露呈が続いていたとされています。
tl;dv社は8月5日の公式見解で、これを「1つの脆弱性が6カ月間未修正だった」とする主張に反論し、独立系ペネトレーションテスト業者Abicomの検証を経て、実際には2つの異なる攻撃経路（ベクトル）だったと説明しています。最初の脆弱性は数カ月前に修正・検証済みで、今回はこれとは別の新たな攻撃経路が見つかり、発見から24時間以内に対処したとしています。
tl;dv社は、露呈した情報は会議メタデータ（会議識別子、会議ID、参加者のメールアドレス・ドメイン）に限定され、パスワード・録画データ・文字起こし・AI生成メモ・アカウントや請求情報へのアクセスはなかったとしています。
2つのインシデントに共通していたのがFirebaseだったとして、tl;dv社は自社の技術スタックからFirebaseを完全に削除する対応を取るとしています。

整理表

項目	研究者・DarkReadingの説明	tl;dv社の公式説明
脆弱性の数	1つの脆弱性が長期間放置	独立した2つの攻撃経路
最初の報告日	2026年1月28日	「年初」に独立ペネトレーションテストと研究者からの報告で特定
修正までの期間	8月4日の記事公開時点でも露呈継続	最初の脆弱性は数カ月前に修正・検証済み、2件目は発見から24時間以内に対処
露呈した情報の範囲	会議作成者のメール、会議ID、プロバイダー、録画状況、タイムスタンプ（181,874件の会議、84,312人のユーザー、35,003ドメインに影響）	会議識別子・会議ID・参加者のメール／ドメインという「メタデータ」に厳密に限定
進行中の通話への参加可否	録画中の会議IDを使い、無断でライブ通話へ参加可能だったと報告	一部のケースで、主催者の手動承認を経て会議URLを入手できる経路があったとし、この経路は既に完全に遮断したと説明
対応	修正の遅さ、コミュニケーション不足を指摘	Abicomによる検証、Firebaseの完全撤去、開示プロセスの改善を表明

何が起きたか——研究者側の説明

セキュリティ研究者のBobDaHacker氏がまとめた技術的な報告によると、tl;dvの利用者は、サインイン時にJWT（JSON Web Token）で認証され、これがFirebaseのトークンと交換される仕組みになっていました。このトークンを使うと、tl;dvのバックエンドで稼働するFirestoreデータベース（Cloud Firestore）に対して、クライアント側から直接クエリを実行できる状態だったとされています。

研究者によると、ユーザー・文字起こし・チャット・録画・メモ・チーム情報など、ほとんどのコレクションでは、アカウントや組織の境界（テナント分離）が適切に機能していましたが、「meetings」コレクションだけはこの例外だったとしています。

認証済みの利用者であれば、自分のアカウントに関係なく、プラットフォーム上の全アカウントを横断して会議記録を照会でき、各会議記録からは、作成者のメールアドレス、会議ID（Google MeetまたはMicrosoft Teamsの参加リンクとして機能）、利用している会議プロバイダー、録画状況、タイムスタンプが取得できたと報告されています。特に、録画中のステータスにある会議については、この会議IDがそのまま進行中の通話への参加リンクとして機能しており、コレクションをリアルタイムで監視すれば、録画が始まった会議を見つけ、そのIDを使って無断で参加することができたとされています。

DarkReadingの報道によると、研究者は2026年1月28日にこの問題を最初にtl;dvへ報告し、その後7月まで複数回のフォローアップを行いましたが、8月4日の記事公開時点でも状況は改善されておらず、DarkReading自身も公開前にtl;dvへ連絡を試みたものの、返答が得られなかったとしています。研究者の調査では、影響を受けた会議は181,874件、ユーザー数は84,312人、ドメイン数は35,003件に上るとされ、政府機関や大学、大手企業を含む幅広い組織が対象に含まれていたと報告されています。

tl;dv社の反論

tl;dv社のCTO、アラン・ベタレル氏は2026年8月5日、公式ブログでこの報道への見解を発表しました。

同社は、独立系ペネトレーションテスト業者Abicomによる定期評価と、ある独立系セキュリティ研究者からの責任ある情報開示を通じて、年初に会議メタデータへのアクセスに関する脆弱性が特定されたことを認めています。同社によれば、この最初の脆弱性は是正措置ののちAbicomによる正式な検証を経て、数カ月前に修正が完了していたとしています。

その後、同じ技術スタック部分に関連する、新たに発見された別の攻撃経路が判明したとし、tl;dv社は「単一の脆弱性が6カ月間未修正のままだった」という主張は事実と異なり、Abicomがこれら2つを正式に異なる攻撃ベクトルであると確認したと説明しています。同社は、問題を発見した際には直ちに対応するという方針のもと、発見から24時間以内にこの新たな経路を封じ込めたとしています。

情報の範囲については、露呈したデータは会議識別子・会議ID・参加者のメールアドレスとドメインという「メタデータ」に厳密に限定されており、パスワード・録画データ・文字起こし・AIが生成したメモ・アカウントや請求に関するデータへのアクセスはなかった、またこれらの情報はそもそも該当するインフラ部分には保存されていないと説明しています。

進行中の通話への参加可否については、tl;dv社は2つのケースを区別して説明しています。1つは、利用者が明示的に「公開」を選択した会議（オプトイン設定、デフォルトはオフ）に限り、公開済みの会議IDを使ってその議事録・AIメモを検索できたというもので、この場合でも通常の閲覧・検索画面には表示されず、技術に精通した第三者によるプログラム的な操作が必要だったとしています。もう1つは、ごく一部のケースで、利用者が不慣れな名前を使い、主催者による手動承認を経て会議URLを入手し、ライブルームに参加できていたというもので、同社はこの経路について緊急の対策として完全に遮断したとしています。

2つのインシデントに共通していたのがFirebaseだったとして、tl;dv社は今後同様の脆弱性が発生するリスクを排除するため、自社の技術スタックからFirebaseを完全に撤去するとしています。また、Abicomによる両インシデントの対応手順・是正措置を確認した署名入り証明書を、顧客・見込み客の要望に応じて提供するとしています。

なお、ベタレル氏は、研究者から年初に最初の連絡を受けた後、継続的に状況を報告すべきだったとして、コミュニケーション上の齟齬について個人的に責任を負うと述べており、今後は脆弱性の開示・対応プロセスを改善するとしています。

疑似インシデント：Tabiq 運営のリクリエ、クラウドストレージ設定不備で約100万人超の本人確認写真やパスポートなどの画像情報露出

業界に共通する「公開設定」をめぐる課題

tl;dv社は今回の見解の中で、この問題をより広い文脈に位置づけています。同社によれば、ここ数カ月、AI・SaaS製品全般で、公開共有設定に関連する同様の事例が明らかになっているとし、Anthropicが検索エンジンを通じてClaudeおよびそのMCPエコシステム全体で公開状態が露呈していたアーティファクトに対処した事例、LovableやZoomが、ユーザーが設定した公開設定によって想定より広範囲に情報が公開されてしまった事例に対処してきたことを挙げています。

このうちAnthropicの事例については、当サイトでもClaudeのチャットがグーグルなどの検索エンジン経由で漏洩-日本語チャットも発見で詳しく解説しています。tl;dv社は、「公開」という言葉が利用者によって異なる意味を持ちうる以上、公開設定を選択する際のユーザー体験（UX）において、その結果を明確に伝える必要があるとし、自社製品での改善を検討しているとしています。

情報システム部門が確認すべき対策ポイント

自社でtl;dvを含むAI議事録・会議記録ツールを利用している場合、過去に録画・記録した会議の会議IDや関連リンクについて、外部から推測・取得された形跡がないか、可能な範囲で確認することをおすすめします。
SaaS・AIツールを導入する際、バックエンドで使用しているデータベース・認証基盤（Firebase／Firestore等）のアクセス制御が、テナント（顧客組織）ごとに適切に分離されているかを、契約前のセキュリティ確認事項に含めることを検討してください。
「公開」「共有」といった設定項目について、自社が利用する各種SaaSツールでどこまでの範囲が公開されるのかを、あらためて確認してください。オプトイン設定であっても、想定より広い範囲に公開されてしまう設計上の落とし穴がある場合があります。
セキュリティ研究者からの脆弱性報告を受け付ける窓口を設けている場合、報告から対応・修正・報告者への継続的なフィードバックまでのプロセスが機能しているかを点検してください。今回の事案でも、対応の遅さやコミュニケーション不足が、問題の一つとして指摘されています。
ベンダーが公表する脆弱性の説明と、発見者・報道機関による説明が食い違う場合、双方の主張を踏まえたうえで、自社への実際の影響範囲を独自に評価する慎重な姿勢が必要です。