Notion情報漏洩を防ぐ共有設計｜ゲスト・Web公開・子ページを棚卸しする

Notionの情報漏洩は、Notionそのものが危険だから起きるというより、共有範囲を広げたあとに棚卸ししないことで起きます。

外部ゲストを招待する。社内の一部にページを共有する。Notion SitesでWeb公開する。リンクドビューでデータベースを見せる。提案書PDFを添付する。

どれも実務では必要です。ただし、経路が増えるほど「今、誰が、どこまで見えるのか」が分かりにくくなります。

よくある失敗は、次のようなものです。

• 公開ページの下に社内メモや下書きを置いたままにする
• 外部ゲストの削除日を決めずに招待する
• リレーション先DBやリンクドビューの見え方を確認しない
• 添付PDF、画像、コメント内の個人情報を見落とす
• 退職者や案件終了後の共有ページを棚卸ししない

Notion情報漏洩対策は、共有を禁止することではなく、誰に何をいつまで見せるかを台帳化し、不要になった経路を閉じる運用です。

この記事では、Notion情報漏洩を防ぐ共有設計について、公式情報を確認しながら、操作説明だけでなく業務で壊れにくい棚卸し運用まで整理します。

Notion権限設定の基本はこちら
Notion編集権限の設定方法はこちら
Notionセキュリティの基本はこちら

先に見るべき共有経路

Notionで情報漏洩を防ぐなら、最初に見るのは暗号化設定ではなく、実際に情報が外へ出る経路です。

優先度	見る場所	事故になりやすい状態
1	Web公開ページ	公開ページの下に社内メモやDB内ページがある
2	外部ゲスト	案件終了後もゲストが残っている
3	一般アクセス	Anyone on the web with link が残っている
4	関連DB・リンクドビュー	元DBや関連ページから別情報が見える
5	添付・コメント	PDF、画像、社内コメントに個人情報や原価が残る

この5つを先に潰すだけでも、Notionの情報漏洩リスクはかなり下がります。

公式情報で確認する前提

この記事では、主に次の公式情報を前提にしています。

• Notion公式ヘルプ：Sharing & permissions settings
• Notion公式ヘルプ：Public pages and web publishing
• Notion公式：Security

公式ヘルプは機能仕様を確認する入口です。一方で、会社で使う場合は、誰が見るか、誰が更新するか、いつ止めるか、どこを正式記録にするかまで自社ルールへ落とす必要があります。

特にこの記事で押さえる仕様は、次の3つです。

公式情報で見ること	実務での意味
ページ共有には個別共有、一般アクセス、権限レベル、継承権限がある	ページ単体だけでなく、親ページ、チームスペース、一般アクセスを同時に見る
Notionは広いアクセス権限を優先する	個別には閲覧だけでも、別経路で編集権限が付くことがある
Notion Sitesでは子ページやDB内ページ、メタデータが関係する	公開ページの下層、リンクドビュー、関連DB、作成者情報を公開前に確認する

Notion側の暗号化や管理機能は重要です。ただし、現場で起きる情報漏洩の多くは、製品の暗号化よりも、共有範囲、外部ゲスト、公開ページ、添付、退職者対応の管理不足から起きます。

漏洩が起きる典型パターン

最初に見るのは、操作手順ではなく失敗の起点です。

漏洩経路	起きる見落とし	先に決めること
外部ゲスト	案件終了後もアクセスが残る	招待時に終了予定日を持たせる
Web公開	子ページ、DB内ページ、メタデータを見落とす	公開専用ページへ切り出す
一般アクセス	「リンクを知る人だけ」のつもりで広く見える	Anyone on the web with link を台帳化する
親ページ	親の共有権限を子ページが引き継ぐ	共有前に下層をたどる
関連DB	リレーション先やリンクドビューから別情報が見える	元DBの権限と表示項目を確認する
添付・コメント	PDF、画像、社内メモ、原価メモが残る	本文以外も共有前チェックに入れる
退職・異動	メンバー削除だけで関連共有を見ない	退職時チェックにNotion共有を含める

この段階では、誰が悪いかを探す必要はありません。Notionは自由にページ、DB、リンク、外部共有を増やせるため、責任者と終了条件がないまま情報だけが増えやすいからです。

まずは、影響が大きいページから順に、共有範囲、関連DB、添付、外部連携、更新担当を見ます。

共有範囲の確認

共有範囲は、Share メニューに表示される相手だけを見ても足りません。

Notion公式ヘルプでは、ページには個別招待、チームスペース、一般アクセス、権限レベル、継承権限など複数の見え方があると説明されています。また、別経路で広い権限が付いている場合、その広いアクセスが効く点にも注意が必要です。

実務では、次の順番で確認します。

確認順	見る場所	判断すること
1	ページの置き場所	プライベート、チームスペース、共有ページのどこにあるか
2	個別共有	メンバー、グループ、ゲストに何の権限があるか
3	一般アクセス	ワークスペース全体、Webリンク共有、Web公開が付いていないか
4	親ページ	親ページの共有から見えていないか
5	子ページ	下層ページに社内メモや顧客情報がないか
6	関連DB	リレーション先やリンクドビューから見える情報がないか
7	添付・コメント	PDF、画像、社内コメントに機密情報がないか

特に危ないのは、「個別には閲覧権限しか渡していないが、親ページやチームスペースで広い権限が付いている」状態です。

Notionの共有確認では、相手ごとの権限だけでなく、ページがどの経路から見えるかを確認します。

ゲストと退職者の棚卸し

外部ゲストには、最初から編集権限を渡さず、閲覧またはコメントから始めます。

項目	見ること
閲覧	提案書、仕様、公開前資料を見せる
コメント	レビュー、差し戻し、確認依頼を受ける
編集	共同作業が必要なページだけに限定する
終了処理	案件終了日や契約終了日にゲストを削除する

外部共有で特に危ないのは、見せたいページの下に社内メモや関連DBが残っている状態です。共有前に子ページ、添付、コメント、リンクドDBを確認します。

外部ゲスト管理では、次の項目を台帳に残します。

台帳項目	例
ゲスト名・会社名	田中さん / 外部制作会社
共有ページ	顧客レビュー用ページ、提案書ページ
権限	閲覧、コメント、編集
共有理由	レビュー、共同作業、納品確認
終了予定日	契約終了日、納品日、イベント終了日
削除確認日	実際にゲスト権限を外した日

退職者対応も同じです。メンバー権限を外すだけでなく、その人が管理していた外部ゲスト招待、共有ページ、公開ページ、連携アカウントまで確認します。

Web公開の注意

Web公開は、社内共有やゲスト共有とは性質が違います。URLを知る人だけでなく、設定次第で検索、複製、子ページ、DB内ページ、メタデータまで関係します。

項目	見ること
公開してよい	FAQ、採用、イベント告知、公開資料
分けるべき	顧客進捗、社内議事録、契約、原価
公開前確認	子ページ、DB、検索、複製、メタデータ
公開後確認	更新日、終了日、問い合わせ導線

Notion公式のWeb公開ヘルプでは、Notion Siteを公開するとWeb上の誰でも閲覧でき、子ページもデフォルトで公開されると説明されています。また、ページにデータベースが含まれている場合、閲覧者がビューを切り替えたり、DB内ページを開いたりできることがあります。さらに、公開ページやWebリンク共有では、ページに貢献したNotionユーザーの名前、プロフィール写真、メールアドレスがメタデータに含まれる可能性があると説明されています。

NotionでWebに出すページは、社内ページのコピーではなく、公開専用ページとして作ります。公開ページの下には、公開してよい子ページだけを置きます。

公開前には、次の4点を確認します。

公開前チェック	見ること
子ページ	下層に社内下書き、顧客メモ、契約情報がないか
データベース	DB内ページ、ビュー切替、関連DBが見えないか
メタデータ	作成者、編集者、メールアドレスなどが出てもよいか
公開停止	Unpublish だけでなく、一般アクセスのWebリンク共有も外したか

子ページとDB関連の確認

Notionでは、見えているページだけで判断すると漏れます。子ページ、リンクドビュー、リレーション先、埋め込み先を確認します。

項目	見ること
子ページ	親ページ共有で下層まで見えないか
リンクドビュー	元DBのどの項目が見えるか
リレーション	関連先ページに機密情報がないか
ロールアップ	集計値から見せたくない数字が推測されないか
添付	PDFや画像に個人情報がないか
コメント	社内メモや原価情報が残っていないか

共有前には、外部から見せるページを開き、そこからクリックできる範囲を実際にたどります。

リレーションやリンクドビューを使っているDBでは、表示プロパティを隠しただけで安心しない方がよいです。元DBやDB内ページへのアクセス経路が残る場合、想定より広く情報が見えることがあります。

添付ファイルとコメント

添付やPDFは、ページ本文より見落とされやすい情報源です。

項目	見ること
営業資料	最新版、承認済み、外部共有可否を確認
契約書	Notionではなく正式保管先を持つ
個人情報	共有範囲と保存期間を限定
マニュアル	更新日と責任者を明記
古い版	残す理由がなければ削除またはアーカイブ

Notion上で見えることと、正式な保管・版管理ができていることは別です。重要資料はNotionを参照場所にし、原本はDriveなどで管理します。

コメントも同じです。本文は外部向けに整っていても、コメントに社内向けの判断、原価、交渉メモ、個人情報が残っていることがあります。外部共有やWeb公開の前には、本文、添付、コメントを別々に確認します。

管理者が見る月次チェック

棚卸しは、全部を毎回見るのではなく、リスクが高い順に見ます。

タイミング	見る対象
毎月	外部ゲスト、Web公開ページ、重要DB
四半期	チームスペース、管理者権限、API連携
案件終了時	顧客共有ページ、外部編集者、添付資料
退職・異動時	メンバー権限、ゲスト権限、連携アカウント

小さな会社でも、外部共有と公開ページだけは月1回確認した方がよいです。共有が残ったままでも、日常業務では気づきにくいからです。

月次チェックでは、次のビューを作ると運用しやすくなります。

ビュー名	条件
外部ゲスト確認	ゲストあり、削除予定日が今月以前
Web公開確認	Web公開あり、最終確認日が30日以上前
重要DB確認	顧客、契約、個人情報、金額を含むDB
退職・契約終了確認	関係者の終了日が入力済み、削除確認日が空欄

このビューを毎月見るだけでも、Notionの共有事故はかなり減らせます。

業務で使う管理表

実務で使うなら、ページやDBそのものとは別に、共有管理表を持ちます。

プロパティ	型	用途
ページ名	タイトル	管理対象のページやDB
共有区分	セレクト	社内、外部ゲスト、Web公開、Webリンク共有
機密区分	セレクト	一般、顧客情報、個人情報、契約、金額
責任者	ユーザー	共有判断と削除判断を持つ人
関連DB・添付あり	チェックボックス	追加確認が必要なページを抽出する
削除予定日	日付	ゲスト削除、公開停止、連携停止の予定
最終確認日	日付	棚卸しした日
削除確認日	日付	実際にゲスト削除や公開停止を確認した日

管理表は、最初から全ページを対象にしなくて構いません。まずは重要DB、外部共有ページ、公開ページ、外部連携だけで十分です。

最初に作るべきものは、共有ページ一覧です。ページ名、共有相手、権限、子ページ有無、関連DB、削除予定日を1つのDBにして、月次で確認します。

よくある質問

Notion自体が危険ということですか

そうではありません。問題になりやすいのは、共有範囲、外部ゲスト、Web公開、添付、コメントを運用で見ていない状態です。Notion側の安全性と、自社の共有設計は分けて考えます。

Web公開を止めれば安全ですか

Web公開をUnpublishしても、一般アクセスのWebリンク共有、外部ゲスト、子ページ、関連DB、外部リンクが残ることがあります。公開停止後も、別アカウントや外部ブラウザで確認します。

毎月すべてのページを確認する必要がありますか

最初から全ページを見る必要はありません。重要DB、外部共有ページ、Web公開ページ、API連携から始める方が現実的です。

専用システムへ移す判断

Notionで始める価値は大きいですが、すべてをNotionで抱える必要はありません。

次の条件が増えてきたら、Notionだけで運用するより、Google Drive、kintone、CRM、問い合わせ管理、ワークフロー、会計ソフト、独自システムなどへ分ける判断をします。

• 権限を行単位や項目単位で厳密に分けたい
• 更新履歴、承認履歴、監査ログが必要
• 外部連携が止まると業務影響が大きい
• 個人情報、契約、会計、顧客対応など正式記録を扱う
• 月次の棚卸しでは追いつかない件数になっている

Notionは、業務の入口、ナレッジ、軽いDB、レビュー画面としては強いです。

一方で、正式記録や厳密な権限制御が必要な領域は、Notionの外に出した方が運用が安定します。

まとめ

Notion情報漏洩を防ぐ共有設計では、機能を使えるかどうかより、業務でどこまで任せるかを決めることが重要です。

Notion情報漏洩対策は、共有を禁止することではなく、誰に何をいつまで見せるかを台帳化し、不要になった経路を閉じる運用です。

最初は小さく作り、共有範囲、更新責任、確認方法、停止条件を決めます。

そのうえで、月次の棚卸しやレビューで不要なページ、権限、連携、埋め込みを整理します。

Notionは柔軟なツールです。だからこそ、業務で使うなら、自由に増やす前に、守るべき情報、任せる担当、Notion外へ出す領域を分けておくことが重要です。