Notion AI情報漏洩の確認と対処：Fireworks経由の流出とキー失効手順

Notionは2026年11月12日、Notion AIの処理を委託していたFireworks AIへの不正アクセスにより、ワークスペースの1%未満でNotion AIのチャット履歴が外部に取得された可能性があると公表しました。チャット履歴に含まれるのは、入力と出力の全文です。本記事では、Notionを使う企業の管理者が知りたい「何が漏れたか」「自社は対象か」「何をすればよいか」に公式の告知で先に答えます。後半では、取得したCSVから認証情報を機械的に洗い出すコマンドと、AI機能を外部の推論基盤へ出す開発者が今回の事案から確かめるべき設計上の点を示します。

まとめ：Notion AI情報漏洩で分かっている事実と管理者・開発者が今週やること

分かっている事実は次のとおりです。流出の可能性があるのは、Insights機能の分類処理のためにFireworksへ送られていたNotion AIのチャット履歴です。Notion自身のシステムへの侵入ではありません。影響を受けた大多数のワークスペースでは、チャット本文に作成者やワークスペースを示す情報が付いておらず、ツール呼び出しの結果も含まれていないとNotionは説明しています。

管理者がやることは2つに絞れます。Notionから連絡が来ていれば、Security incident reviewで影響データのCSVを取得し、パスワードやAPIキーが入力されていないかを洗い出して失効させることです。連絡が無ければ、現時点で対応は不要とされています。AI機能を自社サービスに組み込んでいる開発者は、委託先がプロンプトを保存しない約束（ZDR）が、履歴を保存する機能にまで及んでいるかを契約と実装の両方で確かめてください。

流出したデータの範囲｜チャット履歴・Insights・LEAPの3つの経路と対象外の機能

Insightsの分類処理とオープンウェイトモデル提供に使われていたFireworks

Notionのセキュリティ勧告によると、NotionがFireworksを使っていた用途は2つです。1つは管理者向けにAIの使われ方を分析するInsights機能の分類処理、もう1つはオープンウェイトモデルを提供するための推論基盤です。Insightsでは、保存されたリクエストとレスポンスがFireworksへ送られていました。

Insightsは、Notion AIの設定画面から管理者が使う機能です。自社でInsightsを開いていたかどうかと対象になるかどうかの関係は、告知に書かれていません。対象かどうかはNotionからの連絡で判断します。

AI Meeting Notesは対象外｜チャットに貼った場合だけ影響する条件

Notionのヘルプは、AI Meeting Notesの音声・文字起こし・要約は影響を受けていないとしています。ただし、議事録の本文をNotion AIのチャットに貼って要約させた場合は、その入力がチャット履歴として対象に入ります。ページやデータベースなど、ワークスペースのほかのデータは影響を受けていません。

例外がもう1つあります。早期アクセスのLEAPプログラムの参加者が任意で提供したデータは、Fireworks上でタスク特化型モデルの学習実験に使われていました。LEAPに参加した組織は、チャット以外の提供データも対象に入りうると考えて確認してください。

チューリングが公表した10月5日〜24日の入力という国内の実例

国内では自動運転開発のチューリングが11月12日に公表しています。11月10日にNotion Labsから連絡を受け、対象は10月5日から10月24日までに従業員がNotion AIに入力した内容と回答の一部でした。同社は自社システムへの不正アクセスではないこと、現時点で悪用は確認されていないことを明記しています。

この期間はチューリングのデータについての記載で、Notion全体の対象期間ではありません。Notionの告知には期間の記載が無いため、自社の対象期間はCSVの中身で確かめることになります。

11月2日の通知から12日のAPIキー報告までの経緯とFireworks側の侵入

合成テストデータと判断した11月2日から影響データ確定の11月8日まで

Notionの勧告にある経緯は次のとおりです。最初の判断を一度覆している点に注意が要ります。

1. 11月2日夜：Fireworksが少量のデータへの不正アクセスを通知。Notionは合成テストデータで顧客データは含まれないと判断
2. 11月3日午前：NotionがFireworksとの接続を切断し、双方向の通信を停止
3. 11月4日：Fireworks上のNotionのデータをすべて削除
4. 11月6日：Fireworksが顧客データにも到達した可能性を通知し、Notionが調査を再開
5. 11月8日：Fireworksが影響データセットを確定
6. 11月9日：Notionが影響を受けた顧客に連絡
7. 11月11日：影響データ内で見つかったNotion APIキーを失効
8. 11月12日：影響データ内で見つかった他社サービスのAPIキーを各社に報告

11月11日の失効は利用者側にも作業を生みます。Notion APIのトークンをチャットに貼っていた場合、そのトークンを使う連携は止まっています。Notion APIの連携やNotion MCPの接続が急に認証エラーになったら、トークンを再発行して設定し直してください。

評価ジョブの環境変数と開発用マシンを狙われたFireworksの2つの告知

Fireworksは10月の告知で、10月6日に内部の認証情報の不正使用を特定したと公表しました。評価ジョブで使う環境変数、つまりシークレットとして保存されたAPIキーやトークンが一部の顧客アカウントで取得された可能性があるという内容です。

11月9日更新の続報では、10月23日に開発用マシンを置いていた外部クラウド事業者でインシデントが起き、10月24日に第三者がそのマシンで不正なワークロードを実行して追加の顧客データに影響したと説明しています。目的はLLMの利用枠を盗んで転売する金銭目的の集団との関連が示唆されています。Notionのデータがどの段階で取得されたかは、両社とも明記していません。

Security incident reviewで影響メンバーと流出本文のCSVを取得

オーナーが取れる2種類のCSVとドメイン認証済みかで変わる範囲

確認はデスクトップのブラウザで最新版のNotionを開き、サイドバーの?からSecurity incident reviewを選びます。モバイルアプリでは使えません。オーナーが取れるデータは、組織のドメインを認証済みかどうかで次のように分かれます。

影響メンバー一覧はDownload affected membersから取得します。本文CSVのファイル名はaffected_content.csv、注記付きはaffected_content_annotated.csvです。注記付き本文CSVでは、本文CSVの列に__metadata・__analysisの2列が加わります。__analysis列は、会話ごとに機密情報を含む可能性を示す目印です。__metadata列のスレッドIDなどは分析のためにNotionが付けた情報で、流出したものではありません。ドメイン認証をしていない組織では、オーナーは影響を受けたメンバーの一覧までしか取れず、本文は各メンバーが自分の分を確認します。

影響メンバー本人にデータを確認させるリンクの配布と閲覧の取り消し

オーナーはCopy linkで、影響を受けたメンバーが自分のデータを確認するためのリンクを作れます。メンバーが自分のCSVを取得できるのも、同じ画面です。ドメイン認証済みの組織では、オーナーがRemove access to affected contentでメンバーの閲覧を取り消せます。取り消してもデータは消えず、チャット履歴や保持設定も変わりません。

CSVには流出した本文がそのまま入っています。取得した端末とフォルダを限定し、確認が終わったら削除する運用を先に決めてから取得してください。

gitleaksでaffected_content.csv内の認証情報を検出し失効する手順

既定ルールにNotionトークンを含むgitleaksでCSVを走査するコマンド

影響を受けた行が数百を超えると、目視でキーを探すのは現実的ではありません。gitleaksのdirコマンドは、Gitリポジトリでないフォルダやファイルもそのまま走査できます。既定ルールには2026年11月時点で222件の検出規則があり、ntn_で始まるNotion APIトークン、AWSのアクセスキー、GitHubの個人用トークン、OpenAIのAPIキー、Slackのボットトークンが含まれます。

# CSVを1つのフォルダにまとめる
mkdir notion_incident
mv affected_content*.csv notion_incident/

# 既定ルールで走査し、値を伏せた結果をJSONに保存する
gitleaks dir notion_incident -v --redact -f json -r gitleaks_report.json

--redactを付けると、画面とレポートに秘密の値そのものが出ません。終了コードは検出なしで0、検出ありまたはエラーで1です。導入方法と設定ファイルの書き方はgitleaksの使い方と設定にまとめています。

パターンに当たらない社内パスワードを語で拾うPythonの補助スクリプト

gitleaksは形の決まったキーには強い一方、社内システムのパスワードのように形が決まっていない値は拾えません。次のスクリプトは、gitleaksの結果を種類別に数えたうえで、本文に「パスワード」などの語を含む行の番号だけを出します。値そのものは出力しません。

import csv
import json
import re
from collections import Counter

# gitleaks の結果を種類別に数え、失効の担当を割り振る材料にする
with open("gitleaks_report.json", encoding="utf-8") as f:
    findings = json.load(f)
print(Counter(x["RuleID"] for x in findings))
for x in findings:
    print(x["RuleID"], x["File"], "line", x["StartLine"])

# 形の決まらない認証情報を語で拾う（値は出さず行番号だけ出す）
words = re.compile(r"パスワード|password|passwd|token|トークン|秘密鍵|PRIVATE KEY", re.I)
csv.field_size_limit(10_000_000)
with open("notion_incident/affected_content.csv", encoding="utf-8-sig", newline="") as f:
    for i, row in enumerate(csv.DictReader(f), start=2):
        m = words.search(row.get("text", ""))
        if m:
            print("check line", i, row.get("message_role"), m.group(0))

語で拾った行は誤検知を含むので、人が開いて判断します。csv.field_size_limitを広げているのは、長いチャットの本文が既定の上限を超えて読み込みに失敗するのを防ぐためです。

CSV内で見つかったキーは発行元で失効させ再発行して差し替える順番

見つかったキーは、発行元の管理画面で失効させてから再発行し、使っているアプリの設定を差し替えます。順番を逆にして新しいキーを先に配ると、古いキーが有効なまま残る期間が延びます。Notionは11月11日にNotion APIキーを失効済みで、11月12日に他社のキーを各社へ報告していますが、報告を受けた各社が失効させたとは限りません。自社で失効を確認してください。

失効後は、発行元のアクセスログで10月以降に心当たりのない読み取りやダウンロードが無いかを確かめます。Fireworksが自社の顧客に勧めているのも、同じログの確認です。発行から失効までを仕組みで回す方法はAPIキー管理の実装で解説しています。

チャットに顧客の個人データが入っていた場合の漏えい等報告の対象判断

CSVの本文に顧客や取引先の個人データが含まれていた場合、個人情報保護法の漏えい等報告の対象に当たるかを判断する必要があります。委託先で起きた事案でも、個人データを取り扱う事業者として判断が求められる点は同じです。判断の基準と速報・確報の期限は個人情報保護委員会の資料と、当社の報告義務の解説で確かめてください。

AI機能を外部の推論基盤に出す開発者が確かめる再委託先とZDRの範囲

契約上のZDRの約束が保存型の機能に及ばなかったという今回の構造

今回の事案で開発者が押さえるべき点は、Notionのヘルプにあるゼロデータ保持（ZDR）の説明です。エンタープライズプランのZDRは、応答を生成するために外部のモデル提供者へ送るAPIリクエストに適用されます。チャット履歴やInsightsのように、機能を提供するために保存が前提のデータは対象外です。

さらにNotionは、FireworksがNotionの利用について契約上ZDRを約束していたにもかかわらず、使っていたエンドポイントからデータが保持されていたと書いています。契約書のZDRの一文だけでは、実際に保存されないことの保証になりません。OpenAIの場合の適用範囲はOpenAI ZDRで残るデータで整理しています。

外部基盤の評価ジョブにシークレットを渡さないという委託先側の教訓

Fireworks側の入口は、評価ジョブに渡していた環境変数でした。自社でAIの評価や学習のジョブを外部基盤で動かす場合、そのジョブに本番のAPIキーを環境変数で渡していないかを確かめてください。渡すなら、権限をそのジョブに必要な範囲に絞った専用のキーにし、ジョブの終了後に失効させます。

委託先に送ったデータがさらに別の事業者に渡る構造は、利用者からは見えません。委託先の一覧と保持期間を契約で開示させる方法は、委託先管理の監督義務とチェックリストが参考になります。

Notion AIを止めるべき組織と入力ルールの見直しで続けてよい組織

影響の連絡が無くInsightsを使っていないなら止める理由は無い

Notionは連絡の無い組織を対象外としており、Fireworksとの接続も切っています。Notion AIの利用を全面的に止めても、今回流出した可能性のあるデータは戻りません。止めるより先に、AIのチャットに認証情報と顧客の個人データを貼らないという入力ルールを全社に出し直すほうが効果があります。入力ルールの作り方は生成AIの情報漏洩の経路と入力ルールで扱っています。

顧客の個人データを日常的にチャットで扱う業務は外部AIの外に出す

反対に、問い合わせ対応や採用でAIのチャットに顧客や応募者の個人データを日常的に貼っている業務は、Notion AIに限らず外部のAIサービスに載せる運用をやめるべきです。今回のように、サービス提供者が問題なくても委託先で漏れる経路が残ります。個人データを扱う業務にAIを使うなら、保存先と保持期間を自社で決められる構成で作り直すのが筋です。社内ルールの整備から専用環境の構築までは、当社の生成AI導入支援で相談を受けています。

よくある質問

Notion AIの情報漏洩について、管理者や開発者から出やすい質問に答えます。

Notionから連絡が来ていなければ何もしなくてよいですか？

Notionは、影響を受けた組織には直接連絡し、連絡が無ければ現時点で対応は不要としています。ただし調査は続いており、対象が広がる可能性は残ります。オーナーのメールアドレスが退職者のものになっていると連絡を受け取れないため、オーナーの連絡先が有効かだけは確かめておくと安心です。

Notionのページやデータベースの中身も流出しましたか？

Notionは、ワークスペースのほかのデータは影響を受けていないと説明しています。対象はInsightsで使われたNotion AIのチャット履歴です。ただし、ページの内容をチャットに貼って質問した場合は、その貼った部分がチャットの入力として対象に入ります。

Notionのパスワードを変える必要はありますか？

Notionのログイン情報が流出したとは書かれていません。変える必要があるのは、チャットに貼ったパスワード、APIキー、その他の認証情報です。CSVを確認して該当するものが見つかれば、発行元で失効させてください。

ドメイン認証をしていないと本文を確認できないのですか？

オーナーが本文のCSVを一括で取れるのは、ドメイン認証済みの組織だけです。認証していない組織では、オーナーは影響を受けたメンバーの一覧を取得し、各メンバーに自分の分を確認してもらいます。メンバーはSecurity incident reviewから自分のCSVを取得できます。

チューリングのように自社でも公表する必要がありますか？

公表は義務ではありませんが、流出した本文に顧客や取引先の個人データが含まれていれば、個人情報保護委員会への報告と本人への通知が必要になる場合があります。まずCSVの中身を確認し、個人データの有無と件数を把握してから判断してください。

関連記事

• 生成AIの情報漏洩：事例と5つの経路、入力ルールと法人プランの選び方【2026年11月版】：AIサービス全般で起きる漏えいの経路と入力ルール
• OpenAI ZDRとは：ゼロデータ保持で残るデータとPSPの設定手順【2026年10月】：ZDRを掛けても残るデータの範囲
• APIキー管理とは？発行・保管・失効とローテーションの実装を解説：見つかったキーを失効させる仕組み
• 委託先管理とは？個人情報保護法25条の監督義務とチェックリスト・契約条項の実務：再委託先まで含めた監督の方法
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：漏れたトークンを悪用されにくくする実装