会議の録画と文字起こしをAIに任せるツールが増えました。導入している、または検討している会社や店に関わる報告が出ています。AI議事録ツール tl;dv で、18万件を超える会議の情報が、他の利用者から見える状態だったとセキュリティ研究者が報告しました。以下の経緯と数字は、この発見者側のレポートによります（tl;dv 側の公式な発表は、本稿の時点で確認できていません）。
何が見えていたか
レポートが挙げる規模は、会議記録 181,874件、ユーザー 84,312人、35,003ドメイン。23カ国の政府機関、複数の大学、企業の会議が含まれ、マレーシア教育省の157名参加の会議や、ブラジル政府の環境保全の会議が例に挙がっています。さらに1,000件以上は共有リンクが公開設定になっていて、715人分のメールアドレスが露出していました。
会議の録画と文字起こしは、性質として「社外に出せない話」の塊です。人事、価格、未発表の計画。議事録ツールに渡すデータは、その会社のいちばん濃い部分になります。
原因は高度な攻撃ではなく、1箇所の設定漏れ
レポートが指摘する原因は、Firestore（Google のデータベースサービス）のテナント分離——顧客ごとにデータを仕切る設定——が、会議のコレクションだけ欠けていたことです。ログインした利用者なら誰でも、全顧客の会議メタデータを列挙できました。
ここで目を引くのは、壊れていた場所より、壊れていなかった場所です。レポートによると、ユーザー・チャット・文字起こしなど他のコレクションは正しく403（アクセス拒否）を返していました。つまり作りが全部悪かったのではありません。1箇所だけ抜けていて、抜けを見つける監査が無かった。設定は個別には正しく書けても、「全部に書けているか」は別の仕事です。
おまけのような発見もあります。社内向けのワールドカップ予想アプリに認証が無く、従業員19名のメールアドレスが見えていました。本番でない・社内向けだ、という理由で認証を省いた場所は、こうして表に出ます。
6カ月の放置。バッジと対応は別物
レポートの時系列はこうです。2026年1月28日に発見者が CEO へ連絡し、CTO にもメール。3月まで複数回のフォローアップに返答なし。7月22日に「未解決」と再度指摘。この記事が Hacker News に載った時点で、報告から6カ月が経っていました。
tl;dv は SOC 2 や GDPR 準拠、AES-256 暗号化を掲げ、脆弱性の報告窓口には「24時間以内に対応」と書いていたそうです。ここから引ける教訓は1つで、認証バッジは設計時点の宣言であって、事故が起きたときの動き方を保証しない。バッジを取る作業と、深夜の報告メールに人が反応する体制は、別の投資です。
会議を渡す前に見るもの
議事録ツールに限らず、濃いデータを預ける SaaS を選ぶときの確認は3つに絞れます。
- 報告への対応履歴を検索する — 「サービス名 + vulnerability」「サービス名 + disclosure」で、過去に報告を受けたときに何日で直したかを見る。バッジの一覧より、この履歴のほうが運用の実測に近い
- 共有リンクの既定設定を確認する — 今回、1,000件以上が公開設定でした。ツールの問題と利用者の設定の問題は重なって起きます。既定が「リンクを知っていれば誰でも見られる」になっていないか
- 渡す範囲を自分で絞る — 全会議の自動録画をやめて、対象を選ぶ。漏れたときの被害は、預けた量に比例します
濃いデータを預ける相手を、機能と価格だけで選ばない。地味な結論ですが、18万件という数字は「自分の会議もその中にあり得た」と読むのがいちばん正確だと思います。