はじめに
皆さんお久しぶりです。
ABEJAでNotionの布教をし続けている齋藤です。
こちらは ABEJAアドベントカレンダー2025 の16日目の記事です。
引き続き弊社メンバーが面白い記事をどんどん投稿予定なので、是非チェックしてみてください❤️
目次
導入
Notionはここ四半期でとても大きなリリースを複数実施しています。
2025年9月18日には、Notionというツールの転換期と言っても過言ではない、Notion AIを再構築した「エージェント」機能を代表とする「Notion 3.0：エージェント」がリリースされました。
さらに、先月(2025年11月17日)にはNotion 3.1と題して、この「エージェント」がよりパワーアップし、わざわざ入力欄にデータを入れずとも、開いているページのコンテキストを読み取って解析するだけでなく、Notion カレンダーやSlackのメッセージ、Googleカレンダーの予定といったNotionと連携している各種サービス等の外部サービス内のコンテンツも同様に解析や検索することができるようになりました。
今回ご紹介する「データベースの行単位のアクセス権限」は、そんな華々しいリリースの中、ひっそり(?)*1とリリースされています。
この「データベースの行単位のアクセス権限」では、データベース内の特定のレコード(ページ)に対して、プロパティによる閲覧・コメント・編集権限をコントロールすることができるようになります。
この機能は、きちんと整備することで、管理すべき情報の権限が異なるチーム間の情報共有やプロジェクト管理において革命を起こす機能です。
早速詳しく見ていきましょう！
新機能: ページレベルのアクセス制御
機能概要
⚠️ 利用上の注意
この機能は、ビジネスプランまたはエンタープライズプランでのみご利用いただけます。
前章の導入で紹介したとおり、この「ページレベルのアクセス権限」とは、データベース内の各レコード(ページ)に対して、ユーザータイプのプロパティに基づいて、そのプロパティに指定したアカウントに対して各種アクセス権を設定できる機能です。
後ほどより詳細な利用場面を紹介しますが、簡単な利用方法はコチラのとおりです。
| 利用方法 | 具体例 |
|---|---|
| 特定メンバーだけへの権限付与 | 複数のロールが混在するプロジェクトでもロールごとのタスクの閲覧・コメント・編集権限を管理可能 社員は編集できるがアルバイト等は呉操作しないように閲覧権限だけ付与 |
| 部署ごとに閲覧範囲を制限 | 財務情報を特定メンバーにだけ共有 採用候補者の状況を担当部署のメンバーにのみ共有 |
これらで付与した権限はデータベース上の各種ビューだけではなく、ビューとして、データベースを参照している要素(以下、データベースビュー)にも反映されます！！
つまり、複数のページで同じデータを共有する際にも、一貫した権限制御が可能となります。
 データソースのデータベースへの権限が必要になる |
 意図しない権限付与を避けることができる |
| ※ 画像内のアイコンはGeminiによる生成およびkeynoteの図形を組み合わせて生成してしています |
では早速、この機能の利用方法を確認してみましょう！
利用方法 (4ステップで簡単設定)
さっそく使い方を解説します。
- 対象のデータベースに「ユーザー」種別のプロパティを追加
- このユーザータイプのプロパティに指定されたユーザーやグループに対して権限の付与を実施
- 下記の注意点にあるとおり、作業はデータベースで実施
- 共有設定にアクセス
- データベース上部の 「共有」 ボタンをクリック
- 新しいルールを作成
- 「新しいルールを追加」 をクリック
- 対象を指定：「1」で作成したユーザー種別のプロパティや「作成者」を選択
- アクセスレベルを選ぶ：閲覧、コメント、編集から選択
- ルールを保存
- 「ルールを作成」 をクリックして完了！
下記画像は、「閲覧権限あり」「コメント権限あり」「編集権限あり」という３つのユーザープロパティを持つデータベースでページごとのアクセス権を付与する場合の設定画面です。
注意点：設定の落とし穴に注意！
機能は便利ですが、以下のポイントに気をつけてください：
⚠️ 01: 元のデータベースを選択する必要があります
「共有」設定にて、「新しいルールを追加」ボタンがない場合はデータベースではない可能性が高いので、ご注意ください。
⚠️ 02: 権限の優先順位
ユーザーが複数のルールに当てはまる場合
最も高い権限（例：フルアクセス）が優先されます。
例えば、チーム全体に「閲覧権限」を設定している状態で
個人に「編集権限」を付与すると、その人は編集権限*2が適用されます。
設定後に必ず権限を確認しましょう！
⚠️ 03: データベースビューの活用
データベースへのアクセス権がないユーザーでも
「データベースビュー」と「ページレベルでのアクセス権」が共有されていれば
該当のページ(レコード)にアクセスできます。
逆に言うと「データベース本体」と「データベースビュー」のどちらか片方にしか
権限がない場合はアクセスできないのでご注意ください。
例えば、外部委託チームにタスクを割り当てた際*3
データベースビューへのアクセス権を付与することで、そのタスクだけを安全に編集させることができます。
⚠️ 04: 通知の設定
プロパティでメンションされたユーザーには自動通知が届きますが
グループには通知されません。
グループに連絡が必要な場合は、手動でメンションを追加しましょう。
利用例
一般的な利用シーン: ITチケット管理データベースの場合
「担当者」プロパティで権限を設定すると、各メンバーは自分のチケットだけを編集可能に。
他の人のチケットを誤って変更するミスを防ぐことができます！
コチラの利用方法として、下記のデータベースを用いてご紹介します。
テーブルビュー
このデータベースでは「担当者」と「閲覧ユーザー」という2つのユーザープロパティを定義しており、この2つのプロパティに対して閲覧権限の設定を適用します。
具体的には、「担当者」は実際に作業をするので、チケット(ページ)の編集権限を付与し、
「閲覧ユーザー」には名称のとおり、閲覧権限のみ付与します。
上記の画像のとおりに設定すると、組み合わせ次第で複雑な権限管理が可能になります。
最初の画像に上記のページごとのアクセス権の付与を実施した場合、どのような権限が付与されているのかわかるように枠を可視化した画像は下記のとおりです。
しれっと、ユーザーのところにNotionのグループを指定していますが、ユーザープロパティはグループも選択でき、このページごとのアクセス制御でもグループ単位で付与することができます。 なので、すべてのメンバーが所属するグループや、人事関連の個人情報を扱うグループ、経理周りの機密性の高い情報を扱うグループや役員等のインサイダー周りに関連するグループなど、役割や権限に応じたグループを作成・管理していれば、困ることなくこの機能を活用し始めることができます。
例えば、実際にこのデータベースを参照しているデータベースビューを業務委託メンバー(Group/業務委託)がアクセスすると、下記のように表示されるようになります。
 |
 |
このようにデータベースにページごとのアクセス権を付与することで、リンクするデータベースビューもそのアクセス権が適用され、データベース自体のアクセス権を渡さない限り、不要なページへのアクセス権を間違って付与する危険が減ります。
また、同じデータベースを参照しているデータベースビューなら、同様の権限を引き継いだまま共有することができます。
応用した利用シーン: 採用プロセス管理データベースの場合
採用担当者が自分の担当候補者の情報だけを見られるように設定可能。
機密情報の漏洩リスクを防ぎつつ、スムーズな選考を実現できます。
コチラの利用方法として、下記の構成のデータベースを用いてご紹介します。
| 名称 | タイプ | 利用用途 |
|---|---|---|
| 候補者名 | ページ名 (テキスト固定) |
|
| ID | ID | |
| 採用担当者 | ユーザー | |
| 関係者 | ユーザー | リファラルの場合は紹介者 参加プロジェクトのPMなどを指定 |
| ステータス | ステータス | |
| 採用種別 | マルチセレクト | |
| viewUser | ユーザー | 閲覧権限を付与するユーザー |
| commentUser | ユーザー | コメント権限を付与するユーザー |
| editUser | ユーザー | マルチセレクト |
| 技術試験実施 | ボタン | 技術試験を実施する場合のステータスに変更し 試験管となる「関係者」に変更権限を付与 |
実際にサンプルとなるデータをNotionエージェントに生成してもらいました(生成の指示は下記)
## 背景
このデータベースはNotionの「ページ毎のアクセス権」の付与を紹介するためのデータベースで、採用のフローを参考にしています。
## 指示
1. 各項目が満遍なく選考メンバー等のチケットが設定されるように40件ほどレコードを生成して
2. 候補者名は7割日本人、2割アジア・東南アジア系、残りが欧米系の名前を適当に生成して登録すること
作成したデータベースのボードビュー(いわゆるカンバン)は下記のとおりです*4。
グループ化した採用カンバン*5
「応用した利用シーン」と題しましたが、このページレベルのアクセス制限の最大の特徴でありメリットは「データベースのプロパティにてアクセス権限を操作できること」にあります。
具体的に言うと、データベースの「オートメーション」機能や「ボタンプロパティ」、ページ要素の「ボタン」によるアクセス権の付与などが可能になります。
次に実際にオートメーションを設定することでどのようなことができるのか、イメージと設定方法をお合わせてご紹介します。
データベースボタンを活用する場合
機能紹介この機能は、データベースのプロパティとして指定できるボタンで、編集権限以上を持つユーザーが実行できるボタンを作成することができます。
プロパティ選択時の表示 データベースボタンの詳細
このボタンはトリガーはボタンクリックしか選べません。
しかし、データベースボタンの大きなメリットは、簡単に該当のページのプロパティを設定したり変更したりすることができる点です。
設定できるアクション概要
- プロパティを編集
- 実行されたレコード(ページ)のプロパティを変更
- ページを追加
- Notionデータベースを指定して、ページを追加(利用するテンプレートも指定可能)
- ページを編集
- 指定のデータベースの内、条件に当てはまるページすべてに対して、該当ページのプロパティを変更
- 通知を送信
- 指定のメンバーに対してNotionのサイドメニューにある「受信トレイ」に通知を送信
- メールを送信
- Gmailと連携し、指定のメンバーから、メールを送信
- ※ 1件づつしか送れないから気をつけよう
- Webhookを送信
- 任意のAPIにリクエストを送信できる
- カスタムヘッダーを指定できるので、認証情報とかを指定できるけれど、編集権限があるメンバーはクレデンシャル情報が見れてしまうから気をつけて
- プロパティの情報をコンテンツに含めることができる
- 確認を表示
- 実行前に「YES」「NO」の確認画面を出す機能
- 実はめっちゃ便利
- ページ、フォームまたはURLを開く
- 任意のNotionのページやフォームを指定の方法(サイドピーク、ポップアップ、フルページ)で開く
- 最初のアクションの場合は別の任意のページを指定可能
- Slack通知を送信
- 接続しているSlackへ通知を飛ばせる
- 言わずもがな、とても便利
- 変数を定義
- あまり活用されていないイメージだが、複数のアクションがある時、マジで便利
- 例) 同一の計算処理があるときにまとめることで無駄な計算をせず、処理の中身もわかりやすくできる
- 使わない場合
- プロパティAを複雑な処理で計算
- プロパティAの計算の途中で算出された値を使って別の計算
- 使った場合
- 変数を定義(共通の処理結果をここで定義)
- 「1」を使ってプロパティAを計算
- 「1」を使ってプロパティBを計算
利用例採用判断のため、技術テストを実施したいのでを設定する
- ステータスを「技術テスト」に変更
- 参画予定の「関係者」に編集権限を付与
- つまりeditUserに「関係者」を追加
実際のデータベースボタンの設定内容
ボタンを活用する場合
機能紹介この機能は、コンテンツ内でボタンを作成できる機能です。
ボタンの詳細
ボタンの仕様に関しては公式のDocumentが最強ですので、ぜひ確認してみてください
www.notion.com
ボタンでデータベースのプロパティを操作したい場合
ボタンはページ内に作成されるため、「作成されたページ」自体のプロパティを変更する設定をページ作成後に付与することはできますが、いちいち対象のページを指定しなければならないので、とても(いや、かなり)面倒です。
そこで、活躍するのがデータベースのテンプレート機能です。
あまり知られていませんが、このテンプレート機能の時だけ使える「↗ このページ」が、絶大な効果をもたらします。 「採用担当、自分がやります」ボタン on データベーステンプレート
読んで字のごとく、「このページ」つまり「このテンプレートを使って作成されたページ」を指定できます。
この指定方法を使えば、データベース内のページあるある「プロパティがめちゃくちゃ多くなってすごく見づらくなる問題」を回避することができます。
データベースオートメーションを活用する場合
機能紹介この機能は、データベースに対してあるトリガーとなるアクションを実行すると、設定したアクションを実行する機能です。
上記で説明した2つの「ボタン」をより拡張性高く設定されているのがこの機能で、開始トリガーも設定可能になっています
データベースのオートメーションの詳細
コチラの機能もやはり公式のDocumentが最強です😀
データベースオートメーションとページごとのアクセス制御
正直、このデータベースオートメーションが今回紹介しているページレベルのアクセス制御と相性が良すぎると思っています。
というのも、データベースオートメーションの場合、プロパティ変更をトリガーにできるため、ボードビューの中で採用フローが進んだ場合、トリガーとして必要なメンバーへのアクセス権を付与することができます。
データベースオートメーションの設定例
一つのデータベースで複数のアクセス権を管理できるイメージ 上記のように、オートメーションを設定したうえで、ボードビューによるタスクの進捗管理をすることで、必要なステータスに変更されたタイミングで、必要なメンバーへのそのタスク情報へのアクセス権を付与および剥奪をシームレスに実施できるようになります。
しかも、アクセス権が付与されたタイミングでSlackやメールなどの通知をデータベースオートメーション上で実施すれば、部署をまたいだ連携漏れなどのリスクを抑えることができます。
おまけ
メンバーをオートメーションで付与するときの関数
プロパティ内の項目を指定context("トリガーページ").prop("採用担当者")
特定のグループを指定[@Group/情シス]
同じ権限に複数種類のメンバーを追加concat(
[@Group/情シス],
context("トリガーページ").prop("採用担当者")
)
最後に一言
「ページレベルのアクセス権限」は、チームでの情報管理を安全かつ柔軟にする強力な機能です。
今後、Notionのエージェント機能と組み合わせることで、さらに高度な自動化が期待されます。
この機能は、チームの情報管理を「安全かつ柔軟」に進化させる重要な一歩ですので、まだ導入していない方は、ぜひ利用してみてください！We Are Hiring!
ABEJAは、テクノロジーの社会実装に取り組んでいます。 技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください！ （新卒の方やインターンシップのエントリーもお待ちしております！）
careers.abejainc.com特に下記ポジションの募集を強化しています！ぜひ御覧ください！
