Notion AIのチャット記録流出の恐れから考える｜AI SaaSの「委託先の委託先」をどう管理するか

はじめに
何が起きたのか
なぜこうしたことが起きるのか
発注側コンサルタントならどう考えるか
まとめ
参考

はじめに

2026年11月、米Notion Labsは、Notion AIの処理を委託していた米Fireworks AIへの不正アクセスにより、Notion AIのチャット記録の一部が外部に流出した恐れがあると公表しました。11月11日以降、国内でもNotionを業務で使う企業から「取引先の担当者名や打ち合わせの内容が含まれていた可能性がある」とする発表が相次いでいます。

今回のポイントは、Notion本体が侵入されたわけではないことです。利用企業から見ると、契約相手（Notion）のさらに先にある「AI処理の委託先」で事故が起きました。生成AIを組み込んだSaaSが当たり前になった今、多くの会社が同じ構造の上で業務をしています。

この記事では、事案の概要を整理したうえで、なぜこうしたことが起きるのか、そして発注側のIT部門やDX担当者が、AI SaaSを安心して使い続けるためにどんな仕組みを持っておくべきかを、コンサルタントの視点で考えます。

何が起きたのか

Notionの公式アドバイザリと、国内企業の発表・報道を整理すると、概要は次のとおりです（2026年11月12日時点）。

発表：Notion Labsが2026年11月10日付でセキュリティアドバイザリを公開（ITmediaは11月9日〈現地時間〉の発表と報道）
原因：Notion AIの処理の一部を委託していたFireworks AIの環境に、第三者が不正アクセスした
対象：Notion AIの利用状況を分析する機能「Insights」の処理に使われたチャット記録（利用者の入力文とAIの応答）の一部。Notionは、影響を受けた可能性があるのは全ワークスペースの1％未満で、ページやデータベースなど他の機能のデータは対象外と説明
経緯：11月2日にFireworksからNotionへ通知があり、当初はテスト用データと判断。11月3日までにNotionがFireworksとの接続を遮断。その後、顧客データが含まれていたことが判明し、11月9日から影響を受けた顧客への連絡を開始
国内の影響：LRM、SecureNavi、フェイガーが11月11日に、ワンキャリアが11月12日に第一報を公表。取引先の担当者名、問い合わせや打ち合わせの内容などが含まれていた可能性があるとしています。各社とも、第三者による取得の有無や範囲は確定していないとしています
Notionの呼びかけ：対象データは「流出したものとして扱う」こと、該当期間にパスワードやAPIキーなどをNotion AIに入力していた場合は変更・再発行すること。11月11日には、影響を受けたメッセージ内で見つかったNotion APIキーを失効させたと公表

注目したいのは、Notionのヘルプページにある説明です。FireworksはNotionに対し、契約でゼロデータ保持（処理後にデータを残さないこと）を約束していましたが、調査の結果、Notionが利用していたエンドポイントではデータが保持されていたことが分かったとしています。Notionは今後、重要なベンダーに監査を行い、データ最小化の取り組みが守られているかを検証するとしています。

なぜこうしたことが起きるのか

この事案は特殊な事故ではなく、AI SaaSの構造そのものから生まれるリスクだと考えています。

AI機能は「見えない委託先」を増やす

従来のSaaSでも、クラウド基盤などの再委託先は存在しました。しかし生成AI機能は、モデルの推論、分析、学習実験などで外部のAI事業者を使うことが多く、データが渡る先が一気に増えます。しかも、AI機能はアップデートで後から追加されることが多いため、契約時にはなかったデータの流れが、利用企業の知らないうちに生まれます。

「入力した内容」は管理対象から漏れやすい

多くの会社は、ファイルやデータベースの持ち出しは管理していても、AIへの入力文は「会話」として軽く扱いがちです。実際には、会議メモの要約や問い合わせの下書きなどで、取引先名や個人名、条件、時にはAPIキーまでが入力されます。今回の国内各社の発表を見ても、漏えいの恐れがある情報は「業務で普通に入力していた内容」でした。

契約の約束と実際の運用はずれることがある

ゼロデータ保持を契約で約束していても、実際の設定がそうなっていなかった――今回明らかになったのはこの点です。発注側から見れば、契約書の条文だけでは安全は担保されないことを示しています。

発注側コンサルタントならどう考えるか

ここからが本題です。「AIに機密情報を入れないようにしましょう」という注意喚起だけでは、業務でAIを使う以上、防ぎきれません。私なら、次の5つの仕組みを整えることを勧めます。

1. AI SaaSを「データの流れ」で棚卸しする

まず、社内で使っているSaaSのうち、AI機能を持つものを洗い出し、「入力したデータがどこへ送られ、どこに、どれくらい残るのか」を一覧にします。ポイントは、契約相手だけでなく、AI処理の委託先（サブプロセッサ）まで書き出すことです。多くのSaaS事業者はサブプロセッサの一覧を公開しているので、それを読むだけでも見え方が変わります。

あわせて、AI機能がアップデートで追加・変更されたときに、情報システム部門が気づける仕組み（リリースノートとサブプロセッサ一覧の変更通知の購読、担当者の決定）も用意しておきます。

2. 入力データの区分ルールを「AI込み」で作り直す

情報の取り扱い区分（公開・社内限・機密など）に、「AI機能への入力可否」を明記します。たとえば「取引先との打ち合わせ内容はAIの要約までは可、認証情報は不可」のように、具体的な業務の場面で判断できる粒度にすることが大切です。ここは、生成AIへの個人情報アップロードが問題になったパナソニックグループの事案の記事でも整理したとおり、「禁止」だけのルールは現場で守られにくいため、「使ってよい範囲」を先に示すほうが機能します。

特にAPIキーやパスワードは、AIに限らず「チャットやメモに貼らない」ことを技術的にも防ぎます。シークレット管理ツールの利用を徹底し、貼り付けを検知する仕組みがあれば併用します。

3. 契約・選定では「約束」と「確かめ方」をセットにする

AI SaaSの選定や契約更新では、次の項目を確認事項として定型化しておくことを勧めます。

入力データとAIの出力を、どの委託先に、どの目的で渡すか（推論・分析・学習の区別）
データ保持の期間と、ゼロデータ保持が適用される機能・されない機能の範囲
サブプロセッサの追加・変更時の事前通知と、異議を述べる手段
委託先で事故が起きたときの通知期限と、影響データを利用企業が確認できる手段
第三者認証や監査報告書など、約束が守られていることを確かめる方法

今回、Notionは影響を受けたデータを利用企業がワークスペース内で確認・ダウンロードできる仕組みを用意しました。こうした「事故時に自社の影響範囲を自分で確かめられるか」は、選定時に聞いておくべき重要な観点です。

4. 管理者設定で「使う機能」を絞る

AI機能は、初期設定で有効になっているものも少なくありません。管理者が、業務で使う機能だけを有効にし、分析・改善目的のデータ提供などは必要性を判断してから有効化する運用にします。エンタープライズ向けプランでしか制御できない設定もあるため、プラン選定の段階で「どこまで管理者が制御できるか」を比較しておくと、後から慌てずに済みます。

5. 委託先事故の初動手順を決めておく

今回、国内各社はNotionからの通知を受けて第一報を出しました。自社が同じ立場になったときに備え、次の手順を事前に決めておきます。

1. 通知を受ける窓口（管理者アカウントの通知先を個人ではなく共有アドレスにする）

2. 影響データの確認担当と、個人情報・取引先情報が含まれるかの判定基準

3. 認証情報の変更・失効の手順

4. 取引先や本人への連絡、個人情報保護委員会への報告要否の判断者

「自社のシステムではないから」と初動が遅れることが、最も避けたい事態です。

まとめ

今回のNotion AIの事案は、利用企業から直接は見えない「AI処理の委託先」で事故が起き、業務で入力した会話の内容が流出した恐れがあるというものでした。そして、契約で約束されていたゼロデータ保持が実際には守られていなかったという点は、AI SaaSを使うすべての会社にとって重い教訓です。

発注側にできることは、AIの利用をやめることではなく、データの流れを把握し、入力のルールを具体化し、約束を確かめる手段を契約に組み込み、事故時の初動を決めておくことです。まずは自社で使っているAI SaaSの「サブプロセッサ一覧」を一度読んでみるところから始めてみてください。

参考

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。