会議AIのセキュリティ | 「Bot型は危険」の誤解と情シスが確認すべき選定基準

目次

2026年8月、会議を自動で文字起こしするサービス tl;dv で大規模な情報漏えいが報じられた。セキュリティ研究者の開示によれば、181,874件の会議データと84,312ユーザーの情報が他組織からも閲覧可能な状態で、日本を含む23か国の政府・企業の会議が対象に含まれていたとされる。

この事案を機に、ソーシャル上では「海外のサービスだから危険だ」「会議に参加するBot型だから危険だ」という2つの見方が広がった。しかし、どちらも事案の本質を正しく捉えていない。本記事では、情シス・CISOの視点から実際に起きたことを整理し、確認すべき選定基準を示す。結論を先に述べれば、リスクの所在は録画方式や所在地ではなく、対話データの基盤をどう設計し統制しているかにある。

#Q. tl;dvの事案で実際に何が起きたのですか？

セキュリティ研究者の開示によれば、原因はデータベース（Firestore）の会議データにテナント分離が欠落していたことにある。テナント分離とは、複数の顧客企業のデータを相互に参照できないよう分離する設計を指す。この分離が欠けていたため、認証済みの任意の利用者が、本来アクセス権のない他組織の会議まで検索・閲覧できる状態になっていた。

影響は181,874件の会議、84,312ユーザー、35,003のメールドメインに及んだとされる。録画中のライブ会議に第三者が参加できた例も報告されている。研究者は、開示から6か月以上にわたり修正されなかったと指摘している（Dark Readingも報じている）。tl;dv自身も公式ブログで、2件のインシデントに共通していたFirebaseを技術スタックから完全に削除すると表明した。

つまり原因は録画方式や運営元の所在地ではなく、データベースのテナント分離（アクセス制御）の欠落にある。この一点を押さえないと、次に述べる2つの誤解に足を取られてしまう。

#Q. 広がった「2つの誤解」はなぜ的外れなのですか？

#誤解①「海外のサービスだから危険」

今回の原因は、サービスの所在地ではなくバックエンドの設計不備である。同じテナント分離の欠落は国内サービスでも起こり得るし、逆に海外にも堅牢に設計されたサービスはある。運営元の所在地で危険を判定するのは、論点のすり替えだ。

ただし、これはデータレジデンシー（保存・処理リージョン）を無視してよいという意味ではない。会議データがどの国で保存・処理されるかは、データ主権の観点で別途正当な選定基準になる。所在地は「危険の有無」ではなく「データの置き場所」の論点として扱うのが正しい。

#誤解②「Bot型サービスだから危険」

原因は録画方式ではなく、データ基盤のアクセス制御である。録画方式の種類にかかわらず、バックエンドのテナント分離が欠ければ同じ事態が起こる。これはBot型だけの問題ではない。

ただし、録画方式が完全に無関係というわけでもない。会議メタデータが露出すると、会議ボットを装った参加申請を主催者が承認し、第三者が会議に入るという二次的な連鎖が成立し得る。そのため録画方式の透明性と承認運用は、別の観点として確認する価値がある。

会議AIが安全かどうかを分けるのは、運営元の所在地や録画方式の種類ではない。データ基盤のアクセス制御とテナント分離である。この視点に立てば、確認すべき基準は自ずと定まる。

#Q. 情シス・CISOが確認すべき選定基準は何ですか？

会議AI・商談AIを評価する際は、次の5つを確認することを推奨する。いずれも「録画方式の種類」より上位の、データ基盤とガバナンスに関わる基準である。

#テナント分離・アクセス制御

最重要の基準である。今回の事案がまさにここで起きた。会議・商談データは個人情報と業務機密が同じファイルに混在するため、テナント境界を越えたアクセスが起きた瞬間に影響が広範囲に及ぶ。認証済みユーザーが他組織のデータを参照できないよう、分離とアクセス制御がどう設計されているかを確認したい。

#データレジデンシー

会議データとメタデータが、どの国・リージョンで保存・処理されるかを確認する。外部の解析サービスやSDKを経由する構成では、ベンダー自身の所在地とは別に、データが第三国を経由する場合がある。金融・官公庁など、データの国内保持が要件となる業種では特に重要だ。

#第三者認証

セキュリティ体制を自社だけで検証するのは難しい。ISO/IEC 27001:2022 のような第三者認証は、情報セキュリティマネジメントが外部監査を通じて評価されていることの目安になる。認証の有無に加え、取得している版が最新かどうかも見ておきたい。

#録画方式の透明性と同意

会議の相手に録音・録画が通知され、同意を取得できるメカニズムがあるかを確認する。相手に一切通知されないデスクトップ音声キャプチャのような方式は、同意取得の観点でリスクが高い。前述の「ボットを装った参加」への耐性という意味でも、方式の透明性は評価対象になる。

#委託先監督責任

見落とされがちだが重要な観点だ。利用しているツール（委託先）で漏えいが起きても、個人情報保護法上の報告・本人通知義務は委託元である利用企業自身に発動し得る。対象となる本人の数が一定規模を超えると報告義務の要件を満たすため、ツール選定は自社のコンプライアンス責任の一部として評価する必要がある。

#Q. aileadはこれらの基準にどう応えますか？

aileadは、会議や商談の対話データを安全に統合・構造化し、AIエージェントが業務を自動で動かすためのエンタープライズ基盤（対話データAIプラットフォーム）である。今回の事案が示すとおり、会議AIの安全性は録画方式ではなくデータ基盤の設計で決まる。aileadはこの基盤を次のように設計している。

• テナント分離: マルチテナント環境におけるテナント分離を自社で設計・実装している。
• データレジデンシー: 対話データは国内データセンターで保管する。
• 外部依存のない自社基盤: 会議への自動参加（Bot）を含む対話データの取得基盤まで、外部サービスに依存せずすべて自社で設計・実装している。
• 第三者認証と継続的な診断: ISO/IEC 27001:2022 を取得している。加えて、第三者のセキュリティ専門機関による脆弱性診断を継続的に受診し、指摘事項に対応している。
• 委託先監督責任への対応: 利用企業がコンプライアンス責任を果たせるよう、安全管理措置に関する情報を提供する。
• 構造化とアクセス統制: Salesforce連携（カスタムオブジェクト対応）を含め、対話データを構造化したうえで利用範囲を管理する。

会議AIのセキュリティを評価するときは、話題性や録画方式の議論に流されず、対話データの基盤をどう設計し統制しているかを見てほしい。対話データのガバナンスをより広い枠組みで整理したい場合は、対話データガバナンス｜AIエージェント時代の5原則と実装手順も参照されたい。

自社の要件に照らして会議AI・商談AIのセキュリティを確認したい場合は、資料請求またはデモから相談できる。

---

出典: セキュリティ研究者による脆弱性開示（bobdahacker.com）、Dark Readingの報道、tl;dv公式ブログの声明、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」（ppc.go.jp）。数値・経緯は各開示・報道の記載に基づく。