Notion AIの情報流出懸念を受け、最初に確認したいのは、自分が使うワークスペースへの通知と、対象となった対話の中身です。
すべての利用者が一斉にパスワードを変える段階ではなく、影響を受けた情報に応じて対応を選ぶ必要があります。
議事録の整理やメールの下書きにAIを使うと、短い会話にも取引先の名前や未公開の計画が入り込みます。
会話の記録だけであっても、仕事や生活への影響は小さいとは限りません。
この記事では2026年11月13日に確認した公式資料と国内企業の告知をもとに、判明している事実、事業者の説明、利用者向けの判断材料を分けて解説します。
調査は続いているため、個別の対象範囲はNotionからの案内を優先してください。
Notionが説明しているのは、AI処理の委託先であるFireworks AIに関係するセキュリティインシデントです。
Notion自身のシステムが侵入されたという説明ではありません。
同社は、AI利用状況を分析するInsightsなどのためにFireworksを利用していました。
Notion側の経緯では、11月3日までに接続を遮断し、その後に受け取った追加データの確認で顧客のチャット記録が含まれると分かりました。
影響先への連絡は11月9日に行ったとしています。日付は同社の公表表記によるもので、国内企業の受信日と一致するとは限りません。
11月13日掲載の続報では、対象メッセージ内で見つかった外部サービスのAPIキーについて、発行元へ11月12日に報告したとも説明しています。
現状を読む際は、発覚時の短いニュースだけで判断せず、追加の対処が案内されていないか確認する必要があります。
出典：Notionセキュリティ情報
https://www.notion.com/en-gb/security/advisories/security-incident-involving-a-third-party-ai-vendor
Fireworksは、研究開発用マシンを置く外部クラウド事業者の事故を経て、10月24日に開発マシンへの不正アクセスがあったと説明しています。
外部専門家Unit 42の協力で調査し、認証情報の交換、ネットワークの分離、アクセス管理などを強化したとしています。
一方、標準でZDRを適用するInferenceなどへの影響は確認していないというのが同社の11月9日時点の説明です。
これはFireworks全体の調査結果であり、Notion利用者の個別データが無関係だったことを示すものではありません。
両社の説明は対象サービスや処理経路をそろえて読む必要があります。
出典：Fireworks AI公式続報
https://fireworks.ai/security/bulletins/october-2026-security-incident-update
LRMは、Notion AIに入力した文章とAIの応答文の一部について、流出の可能性があると公表しました。
同社が説明を受けた範囲では、Notion内のその他のページ、データベース、添付ファイルは本件の対象外です。
ただし、ページの内容を会話に貼り付けていた場合、その文章は対話の一部になります。
「元の資料が対象外」という説明から、「資料の内容も一切含まれない」とまでは判断できません。
ファイル名だけを見るのではなく、AIへ何を渡したかを確かめる必要があります。
国内企業の告知は、自分の使い方に近い影響を考える材料になります。
ただし、各社で対象期間やデータを確認している段階であり、ある会社の対象期間をNotion全利用者へ広げることはできません。
出典：日経リサーチ、LRM、弥生の公式告知
https://www.nikkei-r.co.jp/news/information/20261112
https://www.lrm.jp/info/news/info_20261111/
https://www.yayoi-kk.co.jp/yss/info/detail.20261113-3/
日経リサーチは、顧客の会社名や担当者氏名、打ち合わせ内容などが含まれる可能性を挙げています。
企業との対応履歴を要約させる場面なら、こうした固有名詞が会話に残ることは十分に考えられます。
ここから導けるのは、情報の危険度をラベルの有無だけで評価しない方がよい、という判断です。
ユーザーを識別する情報が別項目として付いていなくても、文章に「A社のB様との契約更新」とあれば、関係者や取引を推測する手掛かりになります。
これは説明のための仮例で、実際に流出した文章ではありません。
また、弥生は顧客向け本番環境と社内Notionを分離しており、提供サービスへの影響はないと説明しています。
利用企業の名前が公表されたことと、その会社の顧客サービス全体が侵害されたことも区別してください。
Notionの一般的な説明では、顧客データは初期設定でモデルの学習に使われません。
ただし、学習利用の制限と、処理・保存の条件は異なります。
回答をつくるために外部へ送る処理や、会話を後から見返すための保存まで、同じ一文で禁止されるわけではありません。
同社の現行のセキュリティ説明では、保持条件はプランやモデルによって異なり、Enterpriseでも例外となるモデルは初期状態で無効にする仕組みが案内されています。
契約名だけで全経路の保存条件を判断せず、使うモデルや機能の設定まで見る必要があります。
出典：Notion AIのセキュリティ・プライバシー方針
https://www.notion.com/help/notion-ai-security-practices
今回の続報では、二つの問題が説明されています。
Notionは、履歴やInsightsのように記録の保持を必要とする機能を、EnterpriseのZDRの対象外としています。
それとは別に、Fireworks側には非保持の契約があったものの、利用したエンドポイントで保存されていたことが分かったと説明しました。
つまり、機能自体に保存が必要だったことと、委託先で契約どおりに扱われていたかは、別々に検討すべき論点です。
「もともとZDRの対象外だから問題はない」とも、「ZDR契約はどの処理にも適用される」とも言い切れません。
利用者が確認すべきなのは、どのデータを、何の目的で、どの会社へ送り、いつ消す契約だったかです。
AIの導入審査でも、この処理ごとの確認が欠けると、サービス全体への安心感と実際の運用にずれが生じます。
出典：Notion公式FAQ、ITmediaによる続報
https://www.notion.com/ja/help/security-incident-involving-a-third-party-ai-vendor
https://www.itmedia.co.jp/aiplus/article/2611/13/2000003172/
Notionの日本語ヘルプでは、本人にもワークスペースオーナーにも連絡がなければ、現時点で影響は確認されておらず、対応は不要と案内しています。
ただし調査は継続中です。
会社のアカウントでは、自分の受信箱だけを見て対象外と判断しないようにしましょう。
対象となったオーナー向けには、デスクトップブラウザーでサイドバーの「?」から「セキュリティーインシデントレビュー」へ進む手順が示されています。
メンバーは管理者から案内を受け、自分の対象データを確認する流れです。内容の閲覧には権限やドメイン検証の条件もあります。
確認画面が見当たらない場合は、対象かどうか、使うワークスペース、アカウントの権限をオーナーへ確認してください。
通知メールを装ったリンクへ認証情報を入力せず、普段のNotionへのログイン経路から開く方が確実です。
出典：Notion日本語ヘルプ・対象データの確認手順
https://www.notion.com/ja/help/security-incident-involving-a-third-party-ai-vendor
以下は、対象データを確認した後の対応を整理した編集上の目安です。
個別通知の指定があれば、そちらを優先します。
APIキーは、知っている人がサービスを操作できる鍵です。
チャット履歴から文字列を消しても、外部でコピーされていれば利用を止められません。
対象となったキーを発行元で失効し、必要に応じて新しいキーへ切り替える対応が必要です。
業務システムで使うキーは、変更によって処理が止まる場合もあります。
担当者と連携して失効・再発行・設定変更を進め、利用履歴や課金も確認してください。
緊急の失効が必要かは、キーの権限と不審な利用の有無で判断します。
Notionは、対象データを流出したものとして扱うよう勧めています。
調査の確定を待つ間も、有効な認証情報が見つかった場合は防御を進める、という考え方です。
対象データには、顧客の情報や別の従業員の発言が含まれる場合があります。
確認用ファイルを共有チャットへ添付したり、別のAIへ丸ごと送って分類させたりすると、さらに情報を渡す先が増えます。
社内では閲覧する人と保管場所を絞り、報告時には実際のパスワードやキーを貼らず、情報の種類と対応状況を記録する方法が適しています。
個人情報の種類別に対処を整理したい場合は、AITTの「個人情報漏えい対処ガイド」も利用できます。
関連：個人情報漏えい対処ガイド
https://www.ai-toptier.com/personal-information-leak-checklist
今回の件だけでNotionの全機能を一律に停止すべきだとは判断できません。
一方、委託先との接続を止めたことだけで、過去の情報への影響が解消したともいえません。
これからの入力と、すでに対象になった記録への対応を分けて進める必要があります。
当面の利用範囲を決めるなら、公開済み文章の推敲と、顧客名を含む商談記録の要約を同じ扱いにしないことから始められます。
前者を続けながら、後者は契約と管理者の確認が済むまで控える、といった判断です。
これは編集上の提案であり、Notionがすべての利用者に求める措置ではありません。
名前だけを記号へ変える方法にも限界があります。
商品名、金額、地域、取引時期などを組み合わせれば、相手が分かる場合があるからです。
入力前には「この固有情報がなくても依頼は成立するか」を確かめ、必要な範囲へ減らしてください。
別のAIへ移れば問題がすべてなくなるわけではありません。
比較するなら、保存期間、学習利用、委託先、削除方法、管理者の制御、事故時の通知を同じ基準で確認すると、機能の多さ以外の違いが見えてきます。
個人で使う場合も、仕事用アカウントと私用アカウントを分けるだけで機密性が保証されるわけではありません。
会社の利用規定に沿い、顧客や同僚の情報を私用AIへ移さないことが前提になります。
業務での再開判断は、対象情報への対処が済んだか、利用する機能の保持条件を説明できるか、異常時に止める担当が決まっているかを確認して進めるのが現実的です。
新しい機能を増やす前に、いま渡している情報の範囲を把握しておくと、その後の判断も速くなります。
対象の通知がある人は、公式画面で記録を確認し、使える認証情報が含まれていれば変更・失効を優先してください。
通知がない人は、ワークスペースオーナーへの確認と公式続報の把握が出発点になります。
今後AIへ何を任せるかは、文章を上手に整理できるかに加え、その情報をどこへ渡し、どれだけ残すかで決める必要があります。
契約上の言葉と実際の処理を対応させて確認することが、仕事でAIを使い続けるための判断軸です。
.webp){kind=logo}
