Notionシステム研究所 > Notionゲストの使い方|社外共有で料金と権限事故を防ぐ
2026年6月6日
•約14分で読めます
Notionゲストの使い方を、メンバーとの違い、招待手順、権限レベル、子ページとDBの見え方、社外共有チェックリスト、プロジェクト終了時の棚卸しまで整理します。
Notionで社外の人をゲスト招待したいです。メンバーにしなければ安全ですか。
ゲストはワークスペース全体ではなく、共有されたページを中心に使う権限じゃ。ただし、子ページ、DB、編集権限、契約終了時の削除まで見ないと安全とは言えない。
Notionのゲストは、顧客、業務委託先、制作パートナー、採用候補者など、ワークスペース外の相手に特定ページを共有するときに使います。
Notion公式ガイドでは、ゲストは会社や組織の外部の個人で、ページごとにワークスペースへ招待されると説明されています。
Notion公式ガイド:誰をワークスペースのメンバーとし、誰をゲストにするべきか
別の公式ガイドでも、メンバーはチームと共有されているページにアクセスでき、ゲストは共有された特定ページにのみアクセスできると整理されています。
ただし、ゲストは「社外の人を無料で入れられる便利機能」とだけ考えると危険です。
よくある失敗は、次のような状態です。
Notionゲストは、料金だけで判断するものではありません。
誰に、どのページを、どの権限で、いつまで見せるかを決めて使うものです。
Notionゲストは、社外の人をワークスペースに入れる機能ではなく、外部共同作業者に必要なページだけを最小権限で共有し、終了時に外すための運用ルール として設計するのが安全です。
この記事では、Notionゲストとは何か、メンバーとの違い、ゲスト招待の手順、権限レベルの選び方、子ページとDBの見え方、社外共有チェックリスト、プロジェクト終了時の棚卸し、ゲストでは足りないケースまで整理します。
Notionゲストは、社外の相手に必要なページだけを共有したいときに使います。
最初に、次のように分けます。
| 相手 | ゲストが向くか | 理由 |
|---|---|---|
| 顧客 | 向く | 提案書、確認ページ、納品物など特定ページだけで足りる |
| 業務委託先 | 場合による | 特定案件だけならゲスト、複数領域を継続するならメンバー検討 |
| 制作パートナー | 場合による | 顧客共有ページや制作確認だけならゲスト |
| 採用候補者 | 向く | 課題、案内、面談資料など限定ページで足りる |
| 社員、長期常駐者 | メンバー寄り | 社内Wiki、チームスペース、複数DBへの継続アクセスが必要 |
ゲストに向くのは、共有範囲がはっきりしている相手です。
たとえば、顧客にプロジェクトの確認ページだけを見せる、業務委託先に特定案件の作業ページだけを見せる、採用候補者に選考案内だけを見せるようなケースです。
一方で、毎日社内Wikiを見て、複数チームのDBを使い、チームスペースに入る必要がある人は、ゲストでは無理があります。
Notion公式ガイドでは、メンバーはワークスペース内の多くのコンテンツにアクセスするユーザー、ゲストは特定プロジェクトでの共同作業者として説明されています。
実務上の違いは、次の通りです。
| 項目 | メンバー | ゲスト |
|---|---|---|
| 主な対象 | 社員、長期協力者 | 顧客、業務委託先、外部パートナー |
| アクセス範囲 | ワークスペース内の広い範囲 | 招待されたページと関連範囲 |
| チームスペース | 所属できる | 基本的に参加させない |
| グループ管理 | グループに入れられる | ゲストはグループに含めない |
| ページ作成 | アクセス範囲内で作成できる | 共有ページ配下の作成に限定される |
| 料金 | 有料プランではメンバーごとに課金 | ゲストは無料だがプラン上限がある |
| 運用責任 | 社内のアカウント管理 | 共有ページと終了時削除の管理 |
2026年6月7日確認時点のNotion公式料金ページでは、外部ゲストは組織外の共同作業者として説明され、Freeプランは外部ゲスト10名、Plus、Business、Enterpriseは無制限ゲストと表示されています。
ただし、ゲスト数や料金条件は変更される可能性があります。
実際に運用を決めるときは、契約中のプラン画面と公式料金ページを確認してください。
ゲストを使う判断基準は、料金だけではありません。
| 判断軸 | ゲストでよい | メンバーを検討 |
|---|---|---|
| 期間 | 短期、案件単位 | 継続、常時利用 |
| 範囲 | 1ページ、1案件 | 複数チーム、複数DB |
| 情報 | 顧客向け、共同作業用 | 社内Wiki、社内タスク、全社情報 |
| 管理 | ページ単位で十分 | グループ、チームスペース管理が必要 |
| 終了 | 契約終了時に外せる | 社内アカウントとして管理する |
ゲストは「社外の人を安く入れる方法」ではなく、「社外の人に限定ページだけ見せる方法」です。
ゲスト招待の操作自体はシンプルです。
Notion公式ガイドでは、共有したいページで共有メニューを開き、招待する相手のメールアドレスを入力し、アクセスレベルを選んで招待すると説明されています。
基本手順は次の通りです。
| 手順 | 操作 |
|---|---|
| 1 | ゲストに共有したいページを開く |
| 2 | 右上の共有メニューを開く |
| 3 | 相手のメールアドレスを入力する |
| 4 | 権限レベルを選ぶ |
| 5 | 招待前にゲストとして追加されるか確認する |
| 6 | 招待を送る |
| 7 | ゲストがアクセスできるページを確認する |
ここで重要なのは、招待操作の前にページ構成を見ることです。
共有したいページだけを見るのではなく、その下にある子ページ、埋め込み、リンクドビュー、添付ファイル、関連DBまで確認します。
招待後に気づくより、招待前に分ける方が簡単です。
ゲストに渡す権限は、最小権限から考えます。
| 権限 | 向いている用途 | 注意点 |
|---|---|---|
| 閲覧 | 提案書、納品物、案内資料を見せる | コメントや編集はできない |
| コメント | 顧客レビュー、原稿確認、面談資料へのフィードバック | 本文やDBを直接変更できない |
| 編集 | 共同作業、入力依頼、外部ライターの作業ページ | 編集範囲と完了条件を決める |
| フルアクセス | 共同オーナーに近い運用 | 社外ゲストには原則慎重に扱う |
顧客に確認してもらうだけなら、コメントで足ります。
業務委託先に作業してもらう場合も、いきなり広い編集権限を渡さず、作業ページや入力欄を限定します。
DBを直接編集してもらう場合は、次を決めます。
| 決めること | 例 |
|---|---|
| 入力できる行 | 自分の担当タスクだけ |
| 編集してよい項目 | ステータス、コメント、提出物リンク |
| 触らない項目 | 見積、原価、社内判断、優先度 |
| 完了条件 | レビュー待ちに変更、コメントを残す |
| 確認者 | 社内担当者、PM、責任者 |
外部ゲストに見せるDBと、社内用DBを同じにすると事故が起きやすくなります。
外部に見せる情報だけを抽出したページ、または外部共有用DBを分ける方が安全です。
ゲスト共有で最も見落としやすいのが、子ページです。
Notion公式ガイドでは、ゲストをページに招待すると、ゲストは招待されたページのサブページも閲覧できるようになると説明されています。
必要に応じてサブページの設定を調整して、アクセスを制限します。
共有前に確認するのは、次です。
| 確認箇所 | 事故の例 | 対策 |
|---|---|---|
| 子ページ | 顧客共有ページの下に社内議事録がある | 社内ページを別階層へ移す |
| DBビュー | 外部ページから社内タスクDBが見える | 外部共有用ビューではなく別DBも検討 |
| リレーション | 顧客ページから社内案件DBへつながる | 関連先の表示範囲を確認する |
| 添付ファイル | 社内見積や契約ドラフトが添付されている | ファイル置き場を分ける |
| コメント | 社内向けコメントが残っている | コメントも共有対象として確認する |
ビューで隠しただけの情報は、権限設計としては弱いです。
外部ゲストに見せたくない情報は、同じページや同じDBに置かない方が安全です。
特に、顧客共有ページの下に社内管理ページを作らないでください。
階層として分かりやすくても、共有範囲としては危険です。
ゲスト招待前に、次のチェックリストを使います。
| 順番 | チェック | 確認内容 |
|---|---|---|
| 1 | 共有目的 | 閲覧、コメント、共同編集のどれか |
| 2 | 共有相手 | 顧客、業務委託先、パートナー、候補者のどれか |
| 3 | 共有ページ | 見せるページが1つにまとまっているか |
| 4 | 子ページ | 下層に社内情報がないか |
| 5 | DB | 社内タスク、原価、採用評価、顧客情報が混ざっていないか |
| 6 | 権限 | 閲覧、コメント、編集のどれが必要か |
| 7 | ファイル | 添付ファイルや埋め込みが見えてよいか |
| 8 | 共有台帳 | 共有相手、権限、棚卸し日を記録したか |
| 9 | 終了条件 | 契約終了、納品完了、選考終了時に削除するか |
社外共有のチェックは、毎回ゼロから考えるものではありません。
顧客共有ページ、業務委託共有ページ、採用候補者ページのテンプレートを作り、そこにチェック項目を入れておくと運用しやすくなります。
ゲスト共有を会社で使うなら、共有台帳DBを作ります。
Notion公式ガイドでは、設定のメンバーセクションにゲスト用タブがあり、各ゲストがアクセスできるページを確認できると説明されています。
この公式の管理画面とは別に、業務上の目的、契約終了日、棚卸し日を管理する台帳を持つと、実務では追いやすくなります。
共有台帳DBには、次の項目を置きます。
| プロパティ | 型 | 用途 |
|---|---|---|
| 共有名 | タイトル | 顧客名、案件名、共有ページ名 |
| ゲスト | テキスト | 氏名、会社名、メールアドレス |
| 共有ページ | URL | NotionページURL |
| 共有目的 | セレクト | レビュー、共同作業、納品確認、採用 |
| 権限 | セレクト | 閲覧、コメント、編集 |
| 情報区分 | セレクト | 顧客共有、社外秘、公開可、機密 |
| オーナー | ユーザー | 社内責任者 |
| 開始日 | 日付 | 招待日 |
| 棚卸し日 | 日付 | 次回確認日 |
| 終了条件 | テキスト | 契約終了、納品完了、選考終了 |
| 状態 | ステータス | 申請中、共有中、削除待ち、停止済み |
この台帳があると、次のような確認ができます。
ゲスト共有は、招待した日より、外す日を忘れやすいです。
共有台帳は、終了時の削除を忘れないために作ります。
ゲストは、プロジェクト終了時に必ず棚卸しします。
公式ヘルプでも、ゲスト数にはプランごとの上限があるため、アクセスが不要になったゲストは削除するよう案内されています。
棚卸しのタイミングは、次の通りです。
| タイミング | やること |
|---|---|
| 納品完了 | 顧客共有ページを閲覧だけにする、または共有停止 |
| 契約終了 | 業務委託先、パートナーのゲスト権限を削除 |
| 選考終了 | 採用候補者の共有ページを停止 |
| 月次 | すべての外部ゲストを確認 |
| 担当交代 | オーナーと共有目的を見直す |
削除前には、必要な記録を残します。
| 残すもの | 理由 |
|---|---|
| 最終納品物 | 後から確認するため |
| 合意事項 | 言った言わないを避けるため |
| 確認コメント | レビュー履歴として残すため |
| 削除日 | いつアクセスを止めたか分かるようにするため |
Notionページそのものを残すか、PDFやDriveに保管するかは、案件の種類で決めます。
ただし、ゲストアクセスは残し続けない方が安全です。
ゲストは便利ですが、すべての社外協力者に向くわけではありません。
次のような場合は、メンバー、別ワークスペース、専用システムを検討します。
| 状態 | ゲストでは足りない理由 | 代替 |
|---|---|---|
| 複数部署の情報を日常的に使う | 招待ページ単位では管理が複雑 | メンバー、制限付きメンバー |
| 長期常駐で社内Wikiを使う | 毎回ページ共有すると漏れやすい | メンバー |
| 顧客が大量に入力する | Notionゲストの入力管理が重い | フォーム、顧客ポータル |
| 承認履歴が必要 | Notionだけでは監査要件が弱い | kintone、ワークフロー、専用アプリ |
| 個人情報や評価情報を扱う | 閲覧範囲と保存期間が厳しい | 専用システム、厳格な権限管理 |
Notionは、社外共有の入口としては便利です。
しかし、外部ユーザーが大量に入力する業務、厳密な承認が必要な業務、監査や個人情報管理が重要な業務は、Notionだけに閉じ込めない方がよいです。
Notionには、共有資料、進行状況、確認依頼、手順を置き、正式な処理は専用システムへ分ける設計が現実的です。
Notionゲストは、社外の人と共同作業するために便利です。
ただし、ゲストを安全に使うには、招待手順だけでなく、共有範囲と終了時の運用まで決める必要があります。
ゲスト招待は、共有ボタンを押して終わりではありません。
誰に、どのページを、どの権限で、いつまで見せるのか。
そこまで決めて初めて、Notionゲストは社外共有の安全な仕組みになります。
千葉県出身。10歳の頃からプログラミングを始め、ゲーム、Webサイト、ロボット、スマホアプリなどを制作。大阪大学基礎工学部情報科学科で情報工学と統計学を学び、大学時代はAIを研究。大学在学中にWeb広告代理店でのインターンや人材系Webサービスの立ち上げを経験し、卒業後はフリーランスエンジニアとしてGISシステム、データ基盤構築、Webシステムの開発に従事。10年以上のWebアプリ開発・データ分析経験を基に、2023年9月に株式会社ビットライトを設立し、現場業務の仕組み化からデータ基盤構築、データ活用支援までを一気通貫で支援。