>
>
公開日
Notionの情報漏えいとFireworks AIの侵害について、公式告知を軸に経緯と影響範囲を整理します。承認済みSaaSでもAI処理の委託先から入力内容が漏れるリスクを解説し、通知の有無に応じた初動、機能別の処理先・保存先の確認、利用部署と管理者を特定する台帳まで具体化します。
Notionの情報漏えいとFireworksの関係とは
Notionの情報漏えいは、Notion自身のシステムへの侵害ではありません。AI処理を委託していたFireworks AIの侵害によって、AIの利用傾向を分析するInsights機能用のNotion AIチャット記録が流出した事案です。Notionは公式のセキュリティ告知で、影響を受けたのはワークスペースの1%未満と説明しています。対象読者は、法人でNotionを管理する情報システム部門の担当者・管理者です。承認済みSaaSでも、AI機能の委託先まで含めた影響判断が論点になります。
本記事のポイント
流出したのは、Insights機能用のNotion AIチャット記録です。Notionは、ほかの機能への影響はないと説明しています。
侵害されたのはFireworks側の環境であり、Notion自身のシステムへの侵害とは区別します。
Notionは、通知を受けていない利用者は現時点で対応不要としています。通知を受けた企業は、対象データを露出したものとして扱います。
管理上の論点は、SaaSの契約先だけでなく、AI機能単位で処理の委託先を把握することです。
この記事で確認したこと（確認日: 2026年11月10日）：Notionのセキュリティ告知（2026年11月10日更新）と、Fireworksの初報・続報の本文を確認し、両社が公表した範囲を整理しました。両社とも調査は継続中としており、今後の更新で内容が変わる可能性があります。
自社で利用を承認しているという理由だけで、委託先の事故を調査対象から外さないようにします。以降は、両社の告知と対応の時系列を起点に、自社への影響を判断する材料を整理します。
▲ NotionとFireworks AIの委託関係およびインシデントによるデータ露出経路の構成図です。
両社の告知と対応の時系列
Fireworksの初報・続報とNotion側の対応は、同じ時系列に並べても、告知で関連が明記された範囲に限って結び付けます。検知日、侵害の発生日、公表日、Notionへの通知日は、それぞれ意味が異なります。
以下は、両社の告知に記載された日付と内容を、発信者ごとに分けた年表です。Fireworksの日付は米国太平洋時間です。
日付 | 発信者 | 告知に記載された内容 |
|---|---|---|
2026年10月6日 | Fireworks | 社内認証情報の不正使用を伴うセキュリティインシデントを特定し、同日に封じ込めを開始。一部顧客の評価ジョブで使う環境変数（APIキーやトークンを含む）が取得された |
2026年10月9日 | Fireworks | 影響を確認した顧客に通知し、初報を公表 |
2026年10月23日 | Fireworks（続報の記載） | 研究開発用マシンを置いていた外部クラウド事業者で、セキュリティインシデントが発生 |
2026年10月24日 | Fireworks（続報の記載） | 不正な第三者が、外部クラウド事業者の侵害を利用して開発マシンに到達し、不正な処理を実行。Fireworksは同日に検知し、是正措置を実施 |
2026年11月2日夜 | Notion | Fireworksから、少量のデータに不正アクセスがあったと連絡を受ける。調査の結果、対象はNotion AIの合成テストデータで、顧客データは含まれないと判断 |
2026年11月3日朝まで | Notion | 念のためFireworksとの接続を切り、Fireworks上のデータをすべて削除し、通信を停止 |
2026年11月6日 | Notion | Fireworksから、顧客データにアクセスされた可能性があると通知を受け、社内調査を再開 |
2026年11月8日 | Notion | Fireworksが新たなデータセットを確認。分析の結果、Insights機能用のNotion AIチャット記録が含まれていた |
2026年11月9日 | Fireworks | 続報を公表。アカウント情報と請求情報への影響、一部のアカウントではシークレット、データセット、未完成のモデルへの影響を説明 |
Fireworks側の日付は、Fireworksの初報とFireworksの続報に基づきます。Notion側の日付は、Notionのセキュリティ告知に基づきます。Notionは、Insights機能を停止し、Fireworks経由のオープンウェイトモデルの提供もやめたと説明していますが、それぞれの実施日は告知に書かれていません。
最初の連絡では「顧客データは含まれない」という判断でしたが、4日後に結論が変わりました。委託先からの第一報だけで影響なしと確定させず、続報を受けて判断を更新できるようにしておきます。
日付の近さだけで、Notionの流出をFireworksの初報・続報のどちらかに割り当てないことが、この年表の読み方です。両社の告知は、Notionのチャット記録の流出がFireworksのどの事象に対応するかを明記していません。事故記録に転記する場合も、発信者と日付の種類を一組で残し、対応関係を確認できない項目は未確認のまま分けて管理します。
流出データの性質と公表されていない範囲
Notion AIのチャット記録の流出と、アカウントへの不正アクセスは別の事象として扱います。また、書き手を示すラベルがないことと、チャット本文に機密情報が含まれないことも同じ意味ではありません。
Notion側の影響範囲
Notionのセキュリティ告知によると、流出したのはInsights機能のために使われていたNotion AIのチャット記録で、影響を受けたのはワークスペースの1%未満です。NotionはFireworksを二つの用途で使っていました。Insights機能のための分類処理と、オープンウェイトモデルを提供するための推論基盤です。
Notionは、影響を受けたワークスペースの大多数では、チャット記録が「帰属先を特定できない」形式だったと説明しています。書き手やワークスペースを示すラベルが付いておらず、ツール呼び出しの結果も含まれていないという意味です。ただし、これは記録に付いた識別情報についての説明であり、チャット本文そのものの安全性を保証する説明ではありません。本文に業務上の機密情報が記されていれば、内容に応じた評価が必要になります。「匿名化されているから無害」と判断することは避けます。
Fireworks側の公表範囲
Fireworks側で影響を受けたデータの種類を、そのままNotionの流出項目に置き換えることはできません。Fireworksは続報で、影響を受けた社内アプリケーションからアクセスできた情報として、リソースのメタデータ、請求情報、一部顧客の未完成のモデルウェイトとデータセットを挙げています。カード番号は保存しておらず、影響はないとしています。Inference、Training SDK、Nexusでは影響を検出していないとも説明しています。
初報の時点では、一部顧客の評価ジョブで使う環境変数（シークレットとして保存されたAPIキーやトークンを含む）が取得されたと説明していました。これらはFireworksの顧客に関する説明であり、Notionのアカウント情報や請求情報が流出した根拠にはなりません。
公表されていない範囲
2026年11月10日時点で、両社の告知には次の情報が書かれていません。
対象となったチャットの件数と期間
Notionの流出が、Fireworksの初報・続報のどちらの事象に対応するか
Fireworksで影響を受けたアカウントの数と、外部クラウド事業者の名称
社内の影響整理では、次の順で記録すると、判明事項と推測を分離できます。
Notionの対象データと、Fireworks側の対象データを別欄に記載します。
識別ラベルの有無と、本文に含まれる情報の機密性を分けて評価します。
根拠がある項目だけを確定欄に入れ、対応関係が不明な項目は未確認欄に残します。
通知の有無に応じた企業の初動
Notionはセキュリティ告知で、通知を受けていない利用者は現時点で対応不要と説明しています。影響を受けた顧客には、対象データを露出したものとして扱うことと、機密情報やパスワード、APIキーをNotion AIに貼り付けていた場合は再発行することを勧めています。対象の顧客は、メールで届く手順に沿って、影響を受けたデータをワークスペース内で確認できます。以下は、この方針を踏まえた通知の有無と入力内容に基づく企業側の運用案です。
通知を受けた企業では、対象データが露出した前提で社内の事故対応を開始する運用とします。ただし、対象ワークスペースに通知があったことと、社内のすべての情報が漏えいしたことは区別し、通知に記載された範囲を起点に調べます。
通知の保存と対象ワークスペースの特定：受信した通知を保存し、対象の名称や識別情報、通知に記載された対象範囲を対応記録に残します。
対応責任者への共有：情報システム部門や情報セキュリティ部門など、社内の事故対応責任者へ共有し、調査担当と判断を承認する責任者を決めます。
対象データと秘密情報の照合：通知の対象範囲と、利用部署が入力した内容、自社の秘密情報管理記録を突き合わせます。入力内容が不明なら照合担当を決め、調査中として管理します。
該当する認証情報の再発行：対象の入力にパスワードやAPIキーを貼り付けていた場合は、Notionの推奨に沿って、その認証情報を再発行・更新し、旧情報を無効化します。
判断と対応の記録：対象と判断した根拠、実施内容、未解決事項を残し、責任者が完了条件を満たしたか判定します。
ここでは、文書としての機密情報と、認証に使う秘密情報を分けます。契約内容や社内資料などの機密情報は、露出したものとして社内の事故対応手順で扱います。一方、パスワードやAPIキーは不正利用を防ぐために更新する対象です。認証情報を更新しても、すでに外部へ出た文書の内容を取り消すことはできません。
通知がない場合は、本件だけを理由に全認証情報の一律再発行や全社的な利用停止を行う運用にはしません。ただし、通知の有無が不明な状態を「通知なし」と同一視しない扱いにします。契約窓口と管理者の受信状況を調べ、通知対象と判明すれば上記の対応へ移ります。
通知状況 | 入力内容 | 担当部署 | 直近の対応 | 完了条件 |
|---|---|---|---|---|
通知あり | パスワード・APIキー | 情シス・認証情報の管理部署 | 該当情報の再発行と旧情報の無効化 | 更新・無効化と判断根拠の記録 |
通知あり | 機密文書 | 情報管理部署・利用部署 | 露出を前提とする事故対応 | 社内手順に沿った対応と責任者承認 |
通知あり | 特定できない | 事故対応責任者が指定する照合担当 | 対象範囲と秘密情報管理記録の照合 | 対象の判定、または残る不明点と扱いの承認 |
通知の有無が不明 | 未判定 | 契約窓口・管理者 | 受信状況と対象範囲の調査 | 通知状況の確定と担当への引き継ぎ |
通知なしと確認 | 本件の対象は未確認 | 契約窓口・管理者 | 一律再発行・全社停止は行わず確認結果を保存 | 確認先・結果の記録 |
入力内容を特定できない場合も、根拠なく「漏えいなし」で処理しません。調査できた範囲と残る不明点を分けて記録すれば、追加の通知を受けた際にも判断を更新できます。
▲ インシデント通知の有無とチャットへの入力内容に応じた情シスの初動判断フローです。
自社SaaSのAI機能別に把握する処理先と保存先
SaaSの利用承認だけでは、AI機能ごとの処理先・保存先まで把握したことにはならないため、入力を許可する範囲も機能単位で判断します。同じサービス内でも、利用傾向の分析と回答生成を一括りにせず、それぞれのデータ経路を確認する設計にします。
サブプロセッサーとは、サービス提供に伴ってデータ処理を再委託される事業者です。推論とは、モデルが入力から出力を生成する処理を指します。AI処理事業者の名称だけでなく、何の目的で処理し、誰が保存するのかを分けて記録します。
機能とデータ経路の対応
確認シートはAI機能ごとに作成し、公開情報で埋められる項目と、契約資料・提供元への照会で補う項目を区別します。
Notionはセキュリティ告知で、FireworksをAI利用分析機能「Insights」の分類処理と、オープンウェイトモデルを提供する推論基盤の二つの用途で使っていたと説明しています。この用途の違いを起点に、利用傾向を分類する処理とモデルが回答を生成する処理を別行にし、一方の保存条件を他方へ当てはめない運用にします。
記録項目 | 公開情報からの記録 | 契約資料・照会での補完 |
|---|---|---|
対象AI機能 | 機能名と対象プラン | 自社契約での対象範囲 |
利用目的 | 分類・推論などの用途 | 入力後の処理目的の範囲 |
送信するデータ | 公開された送信対象 | 本文・添付・付随情報の範囲 |
AI処理事業者 | 委託先一覧にある名称 | 対象機能と事業者の対応 |
保存主体 | 保存を担う事業者の記載 | 処理主体と保存主体の違い |
保存期間 | 公表された保持規定 | 機能別・契約別の適用条件 |
削除条件 | 公開された削除方針 | 削除の起点と例外条件 |
変更通知の窓口 | 公開された通知方法 | 契約上の通知先と社内受信担当 |
公開資料に記載がある内容だけを転記し、記載のない欄は「未確認」とします。委託先一覧に社名があるだけで、全機能の処理先や保存先が判明した扱いにはしません。
Notionの公式AIセキュリティ案内では、フリー・プラス・ビジネスプランのAIプロバイダーによる顧客データ保持は30日間またはそれ以下で、その後に削除すると説明しています。これは一般的な保持規定です。この日数から今回の流出対象期間や委託先の保存期間を逆算してはいけません。
確認結果に応じた入力範囲の判断
判断するのは製品の優劣ではなく、自社がその機能へ入力してよいデータの範囲です。
確認結果 | 自社の運用判断 |
|---|---|
機能別の経路と保存条件が自社の入力基準を満たす | 条件を満たしたデータ区分に限って入力を認めます。 |
処理先が分からない | 承認済みの非機密データに入力を限定し、不足項目を提供元へ照会します。 |
保存条件が入力基準を満たさない、または確認できない | その条件に関係するデータ区分の入力を認めず、条件が確定した段階で再判断します。 |
保存条件や委託先を詳細に管理するほど、資料の差し替えや確認シートの更新作業も発生します。記録には根拠資料と確認日を添え、処理先の変更通知を受けた場合は、影響する機能と許可データ区分だけを再評価する設計にします。サービス全体の承認を毎回やり直すのではなく、変更箇所に対応する入力制限を更新します。
影響判断を誤らせる失敗パターン
本件では、公表範囲を超えた安心判断と被害の拡大解釈のどちらも対応を誤らせます。影響割合、データの帰属性、通知の把握状況を分けて判断します。
影響割合による過小評価
全体の影響割合は、自社が対象外である根拠にはなりません。Notionはセキュリティ告知で、影響を受けたのはワークスペースの1%未満と説明しています。これは全体の影響規模であり、自社の通知対象判定の代わりにはなりません。
データ形式による安全視
書き手との紐づけがないことと、本文に機密情報がないことは別です。Notionは、影響を受けたワークスペースの大多数では、チャット記録に書き手やワークスペースを示すラベルが付いていなかったと説明しています。この形式だけで安全視せず、通知対象データに自社の機密情報の入力が含まれるなら内容別の影響評価へ進み、入力内容が不明なら調査対象として残します。
通知未達と対象外の混同
通知を把握していない状態は、対象外の確定とは異なります。管理者の退職や共有受信箱の担当不在による見落としは、実在企業の事例ではなく、予防すべき一般的な運用パターンです。受信記録に通知があれば対象範囲を整理し、見つからなければ対象外とせず、管理者宛ての受信経路まで調査を広げます。
社内報告でも、確認した事実と推測を次のように分けます。
誤った判断・表現 | 修正方針 |
|---|---|
「Notionが侵害された」と一括りにします | 侵害された環境とNotionのデータへの影響を分けて記載します |
今回の流出を委託先の特定の事象と推測で結び付けます | 両社の告知で確認できる関係に記述を限定します |
他社にも被害があると断定します | 自社の通知内容から他社の被害を推定しません |
利用部署・管理者・通知先を結び付けるSaaS台帳
事故通知を実際の対応につなぐには、サービス名だけでなく、ワークスペース、利用部署、管理者、通知先を対応付けたSaaS台帳が必要です。前章の処理先・保存先シートが「データがどこへ渡るか」を管理するのに対し、この台帳は「通知を誰に渡すか」を管理します。
連絡体制を整理する場合は、1ワークスペースにつき1行を設け、SaaS名とワークスペース識別情報の組み合わせを両表の共通キーにします。ワークスペースは、サービス内で利用者や情報をまとめる単位です。表示名だけに頼らず、識別情報には管理画面で確認できるIDなどを記録すると、同名の環境を区別する手掛かりになります。
以下は空欄のまま転記できる台帳テンプレートです。アカウント一覧や対応履歴は別の管理先に置く場合も、参照先を残して台帳からたどれる形にします。
SaaS名 | ワークスペース識別情報 | 利用部署 | 利用アカウントの参照先 | 主管理者・代替担当者 | 契約窓口 | セキュリティ通知先 | 最終更新日 | 前章の機能別シートへの参照 | 対応履歴への参照 |
|---|---|---|---|---|---|---|---|---|---|
事故通知を受信した場合は、次の順で照合します。SaaS提供元やその委託先名義の通知でも、サービス名だけで自社の対象環境を決め付けない運用にします。
通知に記載されたワークスペース識別情報を台帳と照合します。一致しなければ、契約窓口と既存の利用記録から照合する担当者を割り当て、対象未確定として扱います。
一致した行から主管理者と利用部署を特定します。主管理者に連絡がつかなければ、代替担当者へ引き継ぎます。
管理者から社内の対応責任者へ、通知原文と該当する機能別シートの参照先を渡します。
対応履歴に受信日時、担当者、判断内容、実施事項を残し、その記録を台帳の該当行に関連付けます。
利用中のSaaSとアカウント、管理者を把握する手段として、マネーフォワード AdminaなどのSaaS管理サービスを使う方法もあります。ただし、チャット内容やAPIキーの漏えいを検知するものではありません。通知先の更新や事故対応の記録は、社内で担当を決めて運用します。
台帳を作っても、管理者変更が反映されなければ必要な相手に通知が届きません。管理者交代・利用終了・通知先変更があった場合は、変更を扱う担当者が該当行と最終更新日を更新するルールにします。台帳にはパスワードやAPIキーそのものを保存せず、利用アカウントも一覧の参照先で管理します。
▲ 事故通知を受信した際にSaaS台帳を活用して対応を引き継ぐ照合手順です。
まとめ
明日からの一歩は、自社で使っているワークスペースと通知経路を一行の台帳で結び付ける作業です。
承認済みSaaSでも、AI処理の委託先から入力内容が流出することがあります。本件はNotion自身のシステムへの侵害ではなく、委託先のFireworks AIの侵害によって、Insights機能用のNotion AIチャット記録が流出した事案です（Notionのセキュリティ告知）。
Notionを利用しているなら、「ワークスペース名｜利用部署｜管理者｜通知先」を一行に記入します。全社停止や製品導入を一律の結論にせず、通知対象と判明した場合は、本記事の初動表へ進みます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
