こんにちは、株式会社TIMEWELLの濱本です。
AI議事録サービスの脆弱性が公開されました。18万件を超える会議レコードが、他社のユーザーからも見える状態にあった、という内容です。
数字が大きいので「またずさんな会社が」と読まれがちなのですが、報告書を読むと、実はそういう話ではありませんでした。**同じシステムの中で、10ある入れ物のうち9つは正しく守られていたのです。**抜けていたのは1つだけ。
そして、この「1つだけ取りこぼす」という失敗の形は、うちも含めてマルチテナント構成のサービスを作っている会社すべてに、構造として内在しています。他人事にできる話ではないので、順を追って書きます。
技術者向けの記事にはしません。SaaSを導入する側の方が、ベンダーに何を聞けばいいのかが分かる形を目指します。
まず、何が起きたのか
セキュリティリサーチャーのBobDaHacker氏が2026年8月4日に公開した報告によると、AI議事録サービスtl;dvで、会議のメタデータを保管しているデータベース上の1つの入れ物に、テナント間のアクセス制御が設定されていませんでした1。
結果として、ログインしたユーザーであれば、プラットフォーム上の他社の会議レコードも読める状態にあったとされています。規模は181,874件の会議レコード、84,312人のユーザー、35,003のメールドメイン。23カ国の政府機関、複数の大学、多数の企業の会議が含まれていたと報告されています1。
見えていた項目は、会議の作成者のメールアドレス、録画のステータス、タイムスタンプ、そして会議IDです。この会議IDというのが厄介で、Google MeetやTeamsの「その会議に入るための番号」でした。リサーチャーは実証として、招待を受けていない他人のライブ会議に実際に2件入っています。1件はマレーシア教育省の157名規模の会議、もう1件は米国の大学発スタートアップの21名の会議で、画面共有が行われていたとされています1。
報告は2026年1月28日に行われました。公開時点で6ヶ月が経過しています1。なお公開後、tl;dv側は報告後まもなく解消したとする趣旨のコメントを出しており、リサーチャーは6ヶ月後も再現したと反論しています。**事実関係にはこの食い違いが残っています。**本記事はどちらが正しいかを裁定するものではありません。見ておきたいのは、なぜこの穴が生まれたのかという構造のほうです。
「マルチテナント」を、マンションで考える
用語をひとつだけ説明させてください。
マルチテナントとは、1つのシステムを複数の会社で共同利用する仕組みのことです。マンションを思い浮かべてください。建物もエレベーターも配管も共用ですが、各社は自分の部屋だけを使います。この「部屋の仕切り」に相当するのがテナント分離です。
SaaSがなぜ安いのかというと、この共用によってコストを分け合っているからです。1社ごとにサーバーを建てるより、はるかに効率がいい。ですのでマルチテナント自体は悪ではなく、むしろ現代のクラウドサービスの前提です。
ただし、安全性がこの「仕切り」ひとつに乗ることになります。仕切りが1箇所抜ければ、隣の部屋が見えます。今回起きたのは、まさにそれです。
自社のAI活用が今どの段階にあるかを整理したい方は、AI活用レベル診断で現在地を確認しておくと、この先の話を自社に当てはめやすくなります。
9つは守れていて、1つだけ抜けた
ここがこの事件の核心です。
リサーチャーの記述によれば、同じシステム上のユーザー、チャット、文字起こし、クリップ、録画、動画、メモ、チーム、組織という9つの入れ物は、すべて正しくアクセスを拒否していました1。動画そのものも、会話の文字起こしも守られていたのです。
守られていなかったのは、会議メタデータの1つだけでした。
つまり「セキュリティを軽視していた会社が、当然のように全部を開けっぱなしにしていた」話ではありません。分離という設計思想を持ち、9割方は正しく実装できていた組織が、1つだけ取りこぼした話です。
私はここに、かえって怖さを感じました。9割できていて事故が起きるなら、ほとんどの会社が同じ位置にいるからです。
ついでに、もう一段の教訓があります。抜けていたのが「動画本体」ではなく「メタデータ」だった点です。メタデータは本体じゃないから重要度が低い、という感覚は多くの現場にあります。でも今回、そのメタデータの中には会議IDが入っていました。中身ではなく、中身に入るための鍵が置いてあったわけです。
機密度を「本体データか、付随情報か」で分けると、この罠を必ず踏みます。判断すべきは、そこに何が書いてあるかではなく、そのデータで何ができてしまうかです。会議ID、招待リンク、共有トークン、推測できるファイルパス。どれも単体では中身を持ちませんが、鍵として機能します。
なぜ穴は「あとから」開くのか
最初の設計では分離できていたはずのものが、改修を重ねるうちに穴が開く。これは怠慢ではなく、いくつかの力学が働いた結果として起きます。3つに絞って書きます。
ひとつめ。「書いた場所だけ閉じる」方式になっていること。
守りのルールを、データの入れ物ごとに1つずつ書いていく方式をとると、その防御は「明示的に閉じた場所だけが閉じている」状態になります。新しい入れ物が増えたとき、何も書かなければ、それは開いています。
これは開発が速い組織ほど不利になる構造です。入れ物が増えるペースが、防御を書くペースを上回っていくからです。正しい形は逆で、まず全体で「原則すべて拒否」を宣言し、明示的に許可したものだけを通す。そうすると新しい入れ物は、誰も何もしなくても閉じた状態から始まります。この一点の設計差が、5年10年運用したときの結果を決定的に分けます。
ふたつめ。機能改修が「境界をまたぐ正当な理由」を作り続けること。
サービスが成熟すると、必ずこういう要望が来ます。全社横断で検索したい。管理者向けに全体の利用状況ダッシュボードがほしい。一括エクスポート機能を。似た事例をレコメンドしたい。クエリが遅いので集計テーブルを作りたい。
**どれも正当なビジネス要求です。**そしてどれも、テナントの境界をまたぐ実装を要求します。悪意も手抜きもなく、境界に穴が開く理由が積み上がっていく。特に危ないのが、速度改善のための集計テーブルやキャッシュです。元のデータには会社を識別する印が付いていても、そこから派生した集計データで印が落ちる事故は非常に多い。境界は「最初に作った場所」ではなく、データが複製・変形されるすべての場所で維持されなければなりません。
みっつめ。作るのが速くなった分、面が増え続けること。
今回の報告には、おまけがついています。tl;dvの社内向けワールドカップ予想アプリのAPIが認証なしで、自社従業員19名の氏名と会社メールアドレスが取得できる状態にあった、というものです1。社内向け、遊び、一時的。そういう位置づけで作られたものが本番ドメインの配下に置かれ、実在する攻撃面になっていました。
生成AIによって、この種の「気軽に作られた面」を作るコストが劇的に下がりました。**作るのが速くなったぶん、閉じるのも自動でなければ追いつきません。**だから、ひとつめの話に戻ります。
そして、この種の穴は認証バッジでは捕まりません。
こうしたサービスのセキュリティページには、たいてい各種の認証や暗号化のバッジが並んでいます。それらは嘘ではありません。ただ、今回の露出は、正規に認証されたセッションから、データベースが「許可されたリクエスト」として応答した結果です。
- 第三者認証が証明するのはプロセスの存在であって、すべての入れ物・すべての新機能における実装の正しさではありません
- 保存時の暗号化が守るのは復号鍵を持たない相手であって、認可の判定を誤った相手ではありません
「認証を取っているから安全」は成立しません。認証は下限を保証するもので、上限を保証するものではないと考えるのが正確です。
なお、当社は自社が取得していない認証を製品説明に書かない方針を採っています。ここは書ける会社ほど強調したくなるところなので、あえて明記しておきます。
AIを足すと、漏れ方が変わります
ここからが、AIを扱う私たちにとっての本題です。
**AI機能は、本質的に「横断」を欲しがります。**検索の索引はテナントをまたいで作ったほうが精度も効率も上がる。ナレッジグラフはノード同士をつなぐことに価値がある。「似た事例」「過去の類似案件」を出す機能は、境界を越えたときに最も有用になる。埋め込みや要約やキャッシュといった中間処理は、元データの構造を落として別の形で保存します。
つまり**AI機能の追加は、さきほどの「境界をまたぐ正当な理由」を、最も強い形で持ち込みます。**しかも中間生成物が増えるぶん、会社を識別する印が落ちる箇所も増えます。
そして、露出したときの被害の性質が変わります。
従来のテナント分離事故は「他社のデータが検索できてしまう」でした。AIを挟むと、**他社のデータがモデルに渡る文脈に混入し、モデルが能動的にそれを語り出します。**攻撃者が探索する必要すらありません。普通のユーザーが普通に質問しただけで、他社の情報が回答に混ざる。
検出も難しくなります。アクセスログには「正常な質問」しか残らないからです。
ですのでAI機能を持つマルチテナントSaaSでは、次が必須要件になると考えています。索引そのものをテナント単位で分ける（少なくとも検索の前に区切る。あとから絞る方式は、上位の候補を他社データに食われた時点で品質劣化と情報漏えいの両方を起こします）。埋め込み・要約・キャッシュ・中間生成物のすべてに識別の印を持たせ、消えていないことをテストする。モデルへ渡す直前の文脈に対して、テナントの整合性を検査する層を置く。
社内データをAIに渡すときの一般的な注意点はLLMベンダーへの直接データ提供が招く危機にも書きました。
預ける側が確認できること
最後に、導入を検討する立場で何を聞けばいいかを3つ挙げます。技術者でなくても聞けるものにしました。
ひとつめ。「新しく機能を追加したとき、その機能は既定で閉じていますか、開いていますか」。この質問に即答できる会社は、原則拒否の設計になっています。「都度ルールを書いています」という答えなら、さきほどの力学が働く構造です。良し悪しではなく、事実として押さえておく。
ふたつめ。「テナントをまたげないことを、自動テストで確認していますか」。A社の権限でB社のデータを取りに行き、拒否されることを機械的に確かめる仕組みがあるか。人手のテストは、新しい機能が増えたときに「テストを書き忘れる」という同じ失敗を繰り返します。
みっつめ。「脆弱性の報告を受けてから塞ぐまで、平均どのくらいですか」。今回いちばん重かったのは、技術的な設定ミスそのものではなく、報告を受けたあとの時間でした。設定ミスは起きます。どれだけ優秀なチームでも、長く運用すれば1つくらいは取りこぼす。セキュリティの成熟度は脆弱性の有無では測れません。測れるのは、知らされてから塞ぐまでの時間です。
私たちがZEROCKを国内のAWSサーバーで運用し、誰がどのナレッジに触れられるかを統制する設計にしているのも、この線引きを製品の内側に持っておきたいからです。会議も、社内文書も、審査のプロセスも、これから加速度的にAIサービスへ預けられていきます。そのとき預ける側が問うべきは「どんな認証を持っているか」ではなく、「境界が既定で閉じているか」と「問題を知らされたとき、何時間で動くか」だと思っています。
自社のナレッジをどう預けるかについて具体的に相談したい方は、個別相談からご連絡ください。
Footnotes
-
セキュリティリサーチャー BobDaHacker 氏による公開レポート（2026年8月4日公開）。tl;dv が利用する Firestore の
meetingsコレクションにテナント間のアクセス制御が設定されておらず、認証済みユーザーであればプラットフォーム上の会議レコードにアクセスできる状態にあったこと、規模が181,874件の会議レコード・84,312ユーザー・35,003メールドメインであること、露出フィールドに作成者のメールアドレス・会議ID（Google Meet または Teams の入室可能な会議ID）・プロバイダー情報・録画ステータス・タイムスタンプが含まれること、userschatstranscriptsclipsrecordingsvideosnotesteamsorganizationsの各コレクションは正しく403を返していたこと、実証としてマレーシア教育省の157名規模の会議および米国の大学発スタートアップの21名規模の会議へ招待なしで入室したこと、報告が2026年1月28日であり公開時点で未修正であったとされること、社内向けアプリworldcup.tldv.ioの/api/entities/Playerが認証なしで自社従業員19名の氏名と会社メールアドレスを含むデータを返す状態にあったことは、いずれも同レポートによる。https://bobdahacker.com/blog/tldv-hack ／ 公開後、tl;dv 側は報告後まもなく解消したとする趣旨のコメントを出しており、リサーチャーは6ヶ月後も再現したと反論している。事実関係にはこの相違が残っており、本記事はいずれが正確かの判定を行わない。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6
