Notion編集権限の設定方法｜DB構造とページ編集を分けて事故を防ぐ

Notionの編集権限は、単に「書き換えられるかどうか」の設定ではありません。

ページ本文を編集できる人。コメントだけできる人。データベースの中身だけ更新できる人。プロパティやビューまで変えられる人。共有範囲まで変えられる人。

ここを分けないと、業務DBはすぐに壊れます。

Notion公式ヘルプでは、ページ上部の共有メニューから人を招待し、相手ごとに権限レベルを割り当てられると説明されています。また、権限レベルとして Full access、Can edit、データベースページで使える Can edit content、Can comment、Can view が説明されています。

Notion公式ヘルプ：Sharing & permissions settings

実務でよくある失敗は、次のような状態です。

• 担当者がステータスを変えるだけのつもりで、DBのプロパティ名を変更してしまう
• 誰かがビューのフィルターを変え、会議用ビューや期限切れビューが崩れる
• 外部ゲストに編集権限を渡し、社内用コメントや原価メモまで触れる状態になる
• レビュー担当に編集権限を渡し、確認コメントではなく本文が直接書き換わる
• フルアクセス が多すぎて、誰が共有範囲を変えたか分からなくなる
• 担当者別に見せるつもりのDBで、別経路から広い権限が付いている

Notionを会社で使うなら、編集権限は「便利にする設定」ではなく「DBを壊さないための設計」です。

Notion編集権限は、誰に書かせるかではなく、誰が本文、DB内ページ、プロパティ、ビュー、共有範囲を変えてよいかを分ける業務ルール として設計する必要があります。

この記事では、Notion編集権限の設定方法を、編集権限で起きる事故、権限レベルの違い、DB構造変更とコンテンツ編集の分け方、担当者と確認者の権限、外部ゲストに付ける権限、編集前チェックリスト、月次棚卸しまで整理します。

Notion権限設定の全体像はこちら

先に結論：DB構造と中身の編集を分ける

Notion編集権限で最初に分けるべきなのは、DB構造と中身です。

変更対象	例	触ってよい人
DB構造	プロパティ、ビュー、フィルター、並び替え、テンプレート	DB管理者、業務責任者
DB内ページ	タスク本文、議事録本文、案件メモ	担当者、編集者
プロパティ値	ステータス、期限、担当者、カテゴリ	担当者、確認者
コメント	レビュー、差し戻し、確認依頼	確認者、顧客、外部パートナー
共有範囲	メンバー追加、ゲスト追加、Web公開	ページ責任者、管理者

担当者に必要なのは、ほとんどの場合「DBの中身を更新する権限」です。

一方で、DB構造を変えられる人は少数でよいです。

ステータスの選択肢、期限のプロパティ、担当者プロパティ、ビューのフィルター、テンプレートは、業務ルールそのものです。

ここを全員が自由に変えられると、タスクDB、案件DB、議事録DBはすぐに使いにくくなります。

編集権限で起きる事故

Notionの編集権限事故は、悪意よりも「善意の修正」で起きます。

事故	起きる理由	影響
ステータスが増える	担当者が自分用の状態を追加する	集計やビューが崩れる
期限ビューが消える	ビューを整理したつもりで削除する	期限切れタスクが見えない
プロパティ名が変わる	分かりやすく直したつもり	自動化や説明文とずれる
外部共有ページが広がる	共有範囲を便利に広げる	情報漏洩につながる
本文が上書きされる	コメントのつもりで本文を直す	レビュー履歴が残らない
リンクドビューが変わる	自分の見やすさでフィルターを変える	他の人の運用に影響する

特に危ないのは、タスクDBや案件DBです。

担当者は日々更新する必要がありますが、DB構造まで触る必要はありません。

「更新してほしい」と「設計を変えてよい」は別です。

この2つを分けるだけで、Notionの運用はかなり安定します。

権限レベルの違い

Notionの共有と権限設定では、相手ごとに権限レベルを選べます。

実務では、次のように使い分けます。

権限	できることの考え方	向いている相手
フルアクセス	内容編集に加えて、共有範囲も管理できる	ページ責任者、管理者
編集可能	ページ内容を編集できるが、共有管理は任せない	社内編集者、運用担当
コンテンツ編集可能	DB内ページやプロパティ値を編集できるが、DB構造は変えられない	タスク担当者、入力担当者
コメント可能	コメントだけできる	確認者、顧客、レビュー担当
閲覧可能	読むだけ	参考資料の閲覧者、外部閲覧者

公式ヘルプでは、Can edit content はデータベースページでのみ使える権限で、DB内ページの作成や編集、プロパティ値の編集はできる一方、データベースのプロパティ、ビュー、並び替え、フィルターなどの構造は変更できないと説明されています。

ここが重要です。

Notionを業務DBとして使うなら、担当者には 編集可能 よりも、必要に応じて コンテンツ編集可能 を検討します。

ただし、画面やプラン、DBの作り方によって選べる権限や機能は変わるため、実際の共有メニューで確認してください。

編集可能とコンテンツ編集可能の違い

検索で迷いやすいのは、編集可能 と コンテンツ編集可能 の違いです。

権限	向いている操作	注意点
編集可能	ページ本文の編集、構成変更、共同編集	DB構造やビューまで変わる可能性があるため、対象者を絞る
コンテンツ編集可能	DB内ページの作成、プロパティ値の更新、担当者による進捗更新	DBページで使う権限。プロパティやビューを守りたいときに検討する

タスクDB、案件DB、問い合わせDBのように「行は更新してほしいが、項目やビューは変えさせたくない」場合は、コンテンツ編集可能を先に検討します。

DB構造変更とコンテンツ編集を分ける

業務DBでは、次のように役割を分けます。

役割	主な操作	権限の目安
DB管理者	プロパティ、ビュー、テンプレート、権限を管理	フルアクセス、編集可能
業務責任者	ステータス定義、項目追加、運用ルール変更を承認	フルアクセス、編集可能
担当者	自分のタスクや案件を更新	コンテンツ編集可能
確認者	コメント、差し戻し、承認コメント	コメント可能
外部ゲスト	確認、レビュー、限定的な入力	閲覧、コメント、必要最小限の編集

タスクDBなら、担当者はステータス、期限、コメント、提出物リンクを更新できれば十分なことが多いです。

案件DBなら、担当者は進捗、次アクション、メモを更新します。

一方で、売上見込、契約区分、請求ステータス、原価、優先度、ビュー設計は、責任者が管理する方が安全です。

DB	担当者が編集してよい	管理者だけが編集する
タスクDB	ステータス、期限、作業メモ	ステータス選択肢、ビュー、テンプレート
案件DB	次アクション、商談メモ、進捗	売上、原価、契約区分、請求項目
議事録DB	議題、議事録本文、担当タスク	会議種別、決定事項DBとのリレーション
問い合わせDB	対応状況、担当者、返信メモ	分類、優先度、自動化条件
採用DB	面談メモ、候補者ステータス	評価項目、個人情報の表示範囲

DBは、ただの表ではありません。

業務の状態、責任、通知、集計に使う土台です。

構造変更は「便利だから変える」ではなく、責任者が確認してから変えるものにします。

担当者と確認者の権限

担当者と確認者は、権限を分けます。

立場	目的	権限の目安
作業担当者	自分のタスクを更新する	コンテンツ編集可能、または編集可能
確認者	内容にコメントし、差し戻す	コメント可能
承認者	最終判断を残す	コメント可能、必要なら編集可能
DB管理者	項目やビューを守る	フルアクセス、編集可能

確認者に編集権限を渡すと、レビューコメントではなく本文が直接直されることがあります。

それが悪いわけではありませんが、承認履歴や差し戻し理由を残したい業務では、コメント権限の方が向きます。

たとえば、マニュアルDBなら次のように分けます。

操作	権限
手順本文を作る	編集可能
内容を確認してコメントする	コメント可能
公開ステータスを変更する	管理者または責任者だけ
プロパティやビューを変える	DB管理者だけ

Notionは共同編集がしやすい反面、誰でも直せる状態にすると、確認プロセスが曖昧になります。

「編集」と「確認」は分けます。

外部ゲストに付ける権限

外部ゲストには、最小権限から付けます。

用途	推奨権限	理由
提案書を見せる	閲覧可能	内容を変える必要がない
顧客レビュー	コメント可能	本文を変えずに指摘を残せる
納品物確認	コメント可能、閲覧可能	承認や差し戻しを残しやすい
業務委託の作業ページ	編集可能、またはコンテンツ編集可能	作業範囲を限定できる場合のみ
外部パートナーのタスク更新	コンテンツ編集可能を検討	DB構造を守りながら更新させる

外部ゲストにフルアクセスを付けるのは、原則として避けます。

フルアクセスは、ページの共有範囲を変えられるためです。

外部に編集してもらう場合は、外部共有用ページや外部共有用DBを分けます。

社内タスクDBそのものを見せるのではなく、外部に必要な情報だけを抽出したページを作る方が安全です。

編集前チェックリスト

誰かに編集権限を付ける前に、次を確認します。

チェック	見ること
編集目的	本文編集、DB更新、コメント、承認のどれか
編集範囲	ページ単体か、DB全体か、担当行だけか
DB構造	プロパティやビューまで触らせる必要があるか
外部共有	外部ゲストに見せてよい情報だけか
子ページ	下層に社内メモや機密情報がないか
関連DB	リレーション先から情報が見えないか
自動化	権限変更で通知やWebhookに影響しないか
期限	一時的な編集権限ならいつ戻すか
オーナー	誰が権限を棚卸しするか

特に、期限付きの編集権限は台帳に残します。

「今週だけ外部ライターに編集権限を渡す」「納品まで顧客にコメント権限を渡す」のような運用は、終了時に戻さないと権限が残ります。

月次棚卸し

編集権限は、月に1回棚卸しします。

見るべき対象は、次の通りです。

対象	確認すること
フルアクセス	必要な責任者だけに付いているか
編集可能	本当に本文編集が必要な人か
コンテンツ編集可能	担当者が必要なDBだけに付いているか
コメント可能	確認者や顧客に適切か
外部ゲスト	契約終了や納品後も残っていないか
重要DB	プロパティ、ビュー、テンプレートを変えられる人は誰か
リンクドビュー	広い権限が別ページから入っていないか

公式ヘルプでは、Notionはユーザーに与えられた中で最も広いアクセスを尊重すると説明されています。

つまり、ある場所で閲覧だけにしたつもりでも、別の共有設定でフルアクセスが付いていれば、広い権限が効きます。

棚卸しでは、1ページだけではなく、チームスペース、親ページ、リンクドビュー、関連DB、ゲスト招待をまとめて確認します。

よくある質問

全員を編集可能にしてもよいですか

小さなチームでも、重要DBでは避けた方が安全です。全員が本文やビューを直せると、ステータス、期限、フィルター、テンプレートが崩れやすくなります。担当者にはDB内ページやプロパティ値の更新を任せ、DB構造は責任者が管理します。

外部ゲストに編集権限を渡してもよいですか

必要な場合はありますが、外部共有用ページや外部共有用DBに限定します。社内タスクDBや案件DBそのものを見せると、関連DB、コメント、添付、子ページまで確認対象が広がります。

DB構造を守るには何を見ればよいですか

プロパティ、ビュー、フィルター、テンプレート、共有範囲を変えられる人を確認します。特にフルアクセスと編集可能が多いDBは、月次で棚卸しします。

まとめ

Notion編集権限は、全員に編集可能を付ければよいものではありません。

業務で使うなら、DB構造と中身の更新を分ける必要があります。

• フルアクセスは、共有範囲まで管理できるため責任者に絞る
• 編集可能は、本文を編集する社内メンバーに付ける
• コンテンツ編集可能は、DB内ページやプロパティ値を更新する担当者に向く
• コメント可能は、レビュー、確認、顧客フィードバックに向く
• 外部ゲストには、閲覧またはコメントから始める
• DB構造、プロパティ、ビュー、テンプレートは少数の管理者が守る
• 権限は月次で棚卸しし、広い権限が別経路から入っていないか確認する

Notionの編集権限は、作業を止めるための制限ではありません。

必要な人が必要な範囲だけ更新でき、DB構造と共有範囲は壊れない。

その状態を作るための設計です。