Notionシステム研究所 > Notionセキュリティの基本|権限・公開設定・外部連携を安全に運用する

Notionセキュリティの基本|権限・公開設定・外部連携を安全に運用する

2026年6月6日

14分で読めます

Notionセキュリティを、製品側の安全性、共有権限、ゲスト、Web公開、API連携、バックアップ、最初に見るべき管理項目に分けて整理します。

Notion
セキュリティ
権限設定
共有
API連携
バックアップ
助手
助手

会社でNotionを使いたいです。セキュリティ面では何を見ればよいですか。

博士
博士

Notion側の安全性と、自社の運用で守る部分を分けて考える必要がある。暗号化だけでなく、権限、ゲスト、Web公開、外部連携、バックアップを月次で見ることだ。

Notionのセキュリティを考えるとき、「Notionは安全か」という一問にしてしまうと判断を誤ります。

見るべきなのは、Notion側が提供している安全性と、自社が運用で守るべき範囲の分界です。

Notion公式のセキュリティページでは、送信中・保存中・処理中のデータ保護、最小権限、セキュアな開発、管理者向けの制御、SAML SSO、SCIM、監査ログなどが説明されています。これは製品側の土台です。

一方で、実務で問題になりやすいのは次のような運用です。

  • 外部ゲストを招待したまま削除しない
  • Web公開ページの下に社内メモや顧客情報を置く
  • 全員にフルアクセスや編集権限を渡す
  • API連携のトークンを誰が管理しているか分からない
  • 重要DBをNotionだけに置き、エクスポートや原本保管を決めていない
  • 退職者や外部パートナーのアクセス確認が月次運用に入っていない

Notionセキュリティは、製品の安全性だけでなく、権限、公開設定、外部連携、バックアップ、退職者対応を自社の業務ルールとして管理することです。

この記事では、Notionセキュリティの基本を、公式情報を確認しながら、会社利用で見るべき権限、ゲスト、Web公開、API連携、バックアップ、管理者チェックリスト、専用システムへ移す判断まで整理します。

Notion情報漏洩を防ぐ共有設計はこちら
Notion権限設定の基本はこちら
Notionバックアップの考え方はこちら

Notionセキュリティを、製品側機能、自社運用、外部連携、バックアップ、移行判断に分ける構成図

最初に見るセキュリティ項目

Notionセキュリティで最初に見るべきなのは、専門的な設定一覧ではなく、日常運用で事故につながる場所です。

優先度 項目 見ること
1 外部ゲスト 誰が、どのページに、いつまでアクセスできるか
2 Web公開・Webリンク共有 公開してよいページだけが外に出ているか
3 フルアクセス・編集権限 DB構造や共有範囲を変えられる人が多すぎないか
4 API連携・トークン 対象DB、管理者、停止手順が分かるか
5 バックアップ・原本 契約、会計、個人情報をNotionだけに置いていないか

SAML、SCIM、監査ログの前に、この5つが整理されていないと、現場の共有事故は止まりません。

公式情報で確認する前提

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

Notion公式のセキュリティページでは、セキュリティ、プライバシー、コンプライアンス、AIガバナンス、信頼性が整理されています。また、Enterprise向けにはSAML SSO、SCIM、監査ログ、細かな権限制御、ゲスト管理などの管理機能が説明されています。

ただし、小さな会社や部門利用で最初に効くのは、高度な認証設定よりも日常の共有設計です。

まず、次の2つを分けます。

見る領域 主な内容 自社でやること
Notion側の安全性 インフラ、暗号化、製品管理機能、コンプライアンス 公式情報、契約プラン、管理機能を確認する
自社の運用 誰に何を見せるか、いつ消すか、連携を誰が管理するか 権限台帳、ゲスト棚卸し、公開ページ確認を運用する

Notionのセキュリティ確認では、公式の信頼性情報を読むだけでは足りません。自社でどのページを誰に見せ、どの情報をNotion外に置くかまで決める必要があります。

Notion側の安全性と社内運用を分ける

Notion側が提供する安全性は、業務運用を自動で安全にしてくれるものではありません。

たとえば、Notionに管理者機能や権限設定があっても、全員にフルアクセスを付ければ、編集事故や共有事故は起きます。Web公開機能があっても、公開専用ページを作らなければ、下層ページやデータベースの見え方を見落とします。

実務では、次のように責任を分けると判断しやすくなります。

領域 Notion側 自社側
インフラ クラウド基盤、暗号化、可用性、監視 公式ステータスと契約条件を確認する
認証 SSO、SCIM、管理者設定などの機能 使うプラン、管理者、退職者削除を決める
権限 ページ、チームスペース、ゲスト、一般アクセス 共有範囲、責任者、削除予定日を台帳化する
Web公開 Notion Sites、公開設定、検索、複製設定 公開してよい情報だけを切り出す
API連携 接続、能力、コンテンツアクセス、認証方式 トークン管理者、対象DB、停止手順を決める
バックアップ サービス側の冗長化、復旧体制 エクスポート、原本保管、復元テストを決める

Notionを会社で使うなら、「Notionが安全か」ではなく「Notionで扱ってよい情報と、Notion外に置く情報を分けているか」を見ます。

権限とチームスペース

最も重要なのは権限です。

Notion公式ヘルプでは、ページ共有、チームスペース、ゲスト、一般アクセス、権限レベル、継承権限、広いアクセスが優先される考え方が説明されています。

特に見るべきなのは、次の5つです。

項目 見ること
ページの置き場所 Private、Shared、チームスペース、公開ページのどこにあるか
一般アクセス Only people invited、Everyone at workspace、Anyone on the web with link
権限レベル フルアクセス、編集、コンテンツ編集、コメント、閲覧
継承権限 親ページやチームスペースから広い権限が来ていないか
広い権限の優先 個別に制限しても、別経路で広い権限がないか

小さな会社でありがちな失敗は、社内共有を楽にするために全員へ広い権限を渡すことです。

最初は便利ですが、人数が増えると次の事故が起きます。

  • 誰でも重要DBのプロパティを変えられる
  • 会議用ビューや期限ビューが消える
  • 顧客別ページがワークスペース全体から検索できる
  • 外部ゲストに見せるページの親ページが広く共有されている
  • 共有範囲を変えた責任者が分からない

業務DBでは、DB構造を変える人、内容を更新する人、コメントだけする人、閲覧する人を分けます。

Notion編集権限の設定方法はこちら

ゲストとWeb公開

情報漏洩対策で最初に棚卸しするのは、外部ゲストとWeb公開です。

理由は単純です。社内メンバーの権限は日常的に見えやすい一方、外部ゲストや公開ページは、一度作ると放置されやすいからです。

対象 事故例 管理する項目
外部ゲスト 案件終了後も顧客ページが見える 招待理由、権限、終了予定日、削除確認日
Web公開 社内メモや子ページまで公開される 公開対象、子ページ、DB内ページ、検索、複製
Webリンク共有 URLを知る人だけのつもりで広く残る 一般アクセス、リンク期限、共有元
顧客レビュー コメントに社内向け情報が残る 本文、コメント、添付、関連DB

Notion公式ヘルプでは、一般アクセスとして Anyone on the web with link を選べること、リンクの有効期限設定、Enterpriseで公開リンクや公開サイトを無効化できる設定などが説明されています。この記事では、この一般アクセス経路をWebリンク共有として扱います。

ただし、現実の運用では、機能の有無より台帳が重要です。

外部共有ページには、次のプロパティを持たせます。

プロパティ 用途
共有区分 社内、外部ゲスト、Web公開、Webリンク共有
機密区分 一般、顧客情報、個人情報、契約、金額
共有相手 会社名、担当者、ゲストメール
権限 閲覧、コメント、編集、フルアクセス
責任者 共有判断と削除判断を持つ人
終了予定日 案件終了日、イベント終了日、契約終了日
最終確認日 月次で確認した日
削除確認日 実際に共有解除した日

Notionの外部共有は、禁止するより管理する方が現実的です。顧客レビュー、外注制作、採用、イベント運営では外部共有が必要だからです。

その代わり、終了予定日と削除確認日を持たせます。

API連携とトークン

Notionセキュリティでは、外部連携も見落とせません。

Notion公式APIドキュメントでは、Notion connectionは外部ツールや自動化スクリプトとワークスペースを接続する仕組みで、接続ごとに認証情報と権限があると説明されています。また、内部接続、公開接続、個人アクセストークンがあり、それぞれ認証方式とアクセス範囲が違います。

実務では、次の表で管理します。

連携 使いどころ 注意点
内部接続 社内の自動化、通知、ダッシュボード 静的APIトークンの保管、対象ページの限定
公開接続 外部アプリ、複数ワークスペース向けサービス OAuthでユーザーがページを選ぶ、審査や停止手順
個人アクセストークン 信頼できる個人のスクリプト、CLI作業 作成者の権限に依存、退職時の停止が必要

危ないのは、APIトークンを「一度作って終わり」にすることです。

Notion API連携では、次の項目を台帳に残します。

項目 見ること
連携名 何のための接続か
管理者 誰がトークンやOAuth設定を管理するか
対象DB どのページ、DBにアクセスできるか
能力 読み取り、更新、挿入、コメントなど
保管場所 トークンをどこに安全に保管しているか
停止条件 使わなくなった時、退職時、障害時にどう止めるか
最終確認日 接続が今も必要かを確認した日

便利な連携ほど、アクセス範囲が広がりがちです。

たとえば、案件DB、顧客DB、議事録DBをまとめて連携すると、自動化は楽になります。しかし、外部サービス側の障害、トークン漏洩、退職者の管理漏れが起きたときの影響も大きくなります。

連携は、必要なDBだけに絞り、責任者と停止手順を決めてから使います。

バックアップとエクスポート

セキュリティは漏洩対策だけではありません。消失、誤削除、退職、障害、移行への備えも含みます。

Notion公式のセキュリティページでは、高可用性、冗長化、バックアッププログラム、災害復旧や事業継続のテスト、ステータスページなどが説明されています。

これはサービス側の信頼性です。

一方で、自社の業務としては、何をNotion外に残すかを決める必要があります。

情報 Notionでよい使い方 Notion外で持つべきもの
ナレッジ 手順書、FAQ、議事録の参照 重要規程、契約上の正式版
タスク 進捗、担当、期限、コメント 監査が必要な承認履歴
顧客情報 軽いメモ、商談前後の作業管理 CRM、契約、個人情報の正式管理
添付資料 作業用リンク、レビュー用資料 Drive等の原本、版管理、保管期限
会計・契約 参照用メモ、リンク集 会計ソフト、契約管理、電子帳簿保存対応

バックアップは、エクスポートの有無だけでは不十分です。

次の4点を決めます。

項目 決めること
対象 どのDB、ページ、添付、コメントを守るか
頻度 月次、四半期、案件終了時など
形式 Markdown、CSV、PDF、HTML、原本ファイル
復元 誰が、どこに、どの手順で戻すか

重要DBは、エクスポートしたことがあるだけでは足りません。復元したときに業務で使える形になるかを一度確認します。

管理者チェックリスト

Notionセキュリティの月次チェックは、広く薄く見るより、事故につながる場所を絞ります。

頻度 見る対象 判断
毎月 外部ゲスト、Web公開、Webリンク共有 まだ必要か、終了予定日を過ぎていないか
毎月 重要DBのフルアクセス DB構造変更者が多すぎないか
毎月 API連携 対象DBとトークン管理者が明確か
四半期 チームスペース Default、Open、Closed、Privateの使い分けが適切か
四半期 管理者権限 owner、membership admin、teamspace ownerが妥当か
退職時 メンバー、ゲスト、API、公開ページ アカウント削除だけでなく関連共有を外したか

最初から完璧な統制を作る必要はありません。

まずは、次の3つだけでも作る価値があります。

  • 外部共有ページ一覧
  • Web公開ページ一覧
  • API連携一覧

この3つがあれば、Notionのセキュリティ運用はかなり見えやすくなります。

専用システムへ移す判断

Notionは、業務の整理、軽いDB、ナレッジ管理、レビュー画面として非常に便利です。

ただし、次の条件が増えてきたら、Notionだけで抱え込まない方がよいです。

  • 行単位、項目単位、顧客単位で厳密な権限制御が必要
  • 監査ログ、承認履歴、変更履歴が業務要件になる
  • 個人情報、契約、会計、請求など正式記録を扱う
  • 外部連携が止まると業務が止まる
  • 月次棚卸しでは共有経路を追いきれない
  • 管理者が不在でも継続運用できる必要がある

この場合は、Notionを入口や補助画面として使い、正式記録はkintone、CRM、会計ソフト、契約管理、問い合わせ管理、独自システムなどへ分けます。

Notionで全部やることが安全とは限りません。

むしろ、情報の性質ごとに置き場所を分けた方が、安全で運用しやすくなります。

よくある質問

小さな会社でもSSOやSCIMが必要ですか

最初から必須とは限りません。まずは外部ゲスト、Web公開、フルアクセス、API連携、退職者対応を台帳化します。人数や権限が増え、管理者だけでは追えなくなった段階でSSOやSCIMを検討します。

Notionだけで契約や個人情報を管理してよいですか

参照用のメモやタスク管理には使えますが、正式記録、監査、保管期限、厳密な権限制御が必要な情報は、契約管理、Drive、CRM、会計ソフトなどへ分ける方が安全です。

最初に作るべき管理表は何ですか

外部共有ページ一覧、Web公開ページ一覧、API連携一覧の3つです。最初から全ページを管理しようとするより、外に出る経路を先に押さえます。

まとめ

Notionセキュリティの基本は、Notion側の安全性と自社の運用責任を分けることです。

Notion公式のセキュリティ、権限、APIの情報を確認したうえで、会社側では権限、ゲスト、Web公開、外部連携、バックアップ、退職者対応を管理します。

特に重要なのは、外部共有ページ、Web公開ページ、API連携、重要DBを台帳化することです。

Notionは柔軟だからこそ、便利に広げる前に、誰が見てよいか、誰が編集してよいか、どの情報をNotion外に置くかを決めておく必要があります。

小さく始めるなら、外部共有、Web公開、API連携の3つを月次で見るだけでも十分です。そこから、重要DB、バックアップ、専用システムへの切り分けへ広げていくと、Notionを業務で安全に使いやすくなります。

Notionシステム設計支援

Notionを業務システムとして安全に使う設計を支援します

小さな会社のNotion運用に合わせて、管理者チェック、共有台帳、API連携管理、Notion外に出す領域まで設計します。

著者
守高 成悟
守高 成悟

代表取締役 CEO

千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。

運営会社
株式会社ビットライト
株式会社ビットライト

顧客が本当に必要だった価値を、実装する。

現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援しています。

コーポレートサイトを見る
Notion設計相談

議事録・タスク・ナレッジの運用設計を相談できます

Notionで始める範囲、権限、通知、別システムへ切り出す条件まで整理します。