Notionシステム研究所 > Notionリンクドデータベースの使い方|同じDBを別ページで安全に見せる

Notionリンクドデータベースの使い方|同じDBを別ページで安全に見せる

2026年6月5日

15分で読めます

Notionリンクドデータベースの使い方を、元DBとの違い、編集影響、フィルター、ビュー、権限、チーム用ダッシュボードでの設計例まで整理します。

Notion
リンクドデータベース
リンクドビュー
データベース
ダッシュボード
権限設計
助手
助手

Notionのリンクドデータベースは、同じDBを別ページに表示できる機能ですよね。元のDBをコピーするのとは違いますか。

博士
博士

そこを間違えると危ない。リンクドデータベースはコピーではなく、同じデータを別の場所から見るための入口じゃ。見え方は変えられるが、行の中身を編集すれば元DBにも反映される。

Notionのリンクドデータベースは、業務用のNotionでかなり重要な機能です。

タスクDBをチームホームに表示する。プロジェクトページに、その案件のタスクだけを表示する。会議ページに、確認待ちと期限超過だけを表示する。営業ページに、担当顧客だけを表示する。

このように、同じDBを別ページで目的別に見せられるのがリンクドデータベースです。

Notion公式ガイドでも、リンクドデータベースは同じデータベース内容を複数ページに表示し、会議メモにチームタスクの絞り込みビューを入れたり、担当タスクのダッシュボードを作ったりする用途で説明されています。

Notion公式ガイド:Using linked databases

ただし、リンクドデータベースは便利な一方で、誤解されやすい機能でもあります。

  • 元DBを複製したつもりで編集し、全体のデータを書き換えてしまう
  • 部署別ページにリンクドDBを置いたが、フィルター条件が曖昧で他部署の情報も見える
  • 会議用ビューと入力用ビューが混ざり、誰がどこを更新するか分からない
  • 外部共有ページにリンクドDBを置いたが、元DBの権限設計が不十分
  • ビューのフィルターや並べ替えを誰かが変えて、チーム全員が混乱する

リンクドデータベースは、DBを増やす機能ではなく、同じDBを業務目的ごとに安全に見せる機能 として使うべきです。

この記事では、Notionリンクドデータベースの使い方を、元DBとの違い、作成手順、フィルター、ダッシュボードでの使い方、権限、チーム運用の設計例まで整理します。

Notionの元DBを部署別ビュー、会議用ビュー、個人用ビュー、外部共有用ビューへリンクドDBで分ける構成図

先に結論:リンクドDBは「同じデータの別画面」

Notionリンクドデータベースは、元DBを別ページに表示する仕組みです。

コピーではありません。

同じデータを、別のページで、別のフィルターや並べ替え、表示形式で見せるための機能です。

項目 元DB リンクドデータベース
データの本体 ここにある 元DBと同じデータを参照する
ページ内容の編集 元DBに反映される 元DBに反映される
プロパティ値の編集 元DBに反映される 元DBに反映される
フィルター ビューごとに設定 リンク先ページごとに設定できる
並べ替え ビューごとに設定 リンク先ページごとに設定できる
表示目的 管理、設計、全体確認 ダッシュボード、会議、担当者別確認

Notion公式ガイドでは、リンクドデータベースで行ったデータ変更は元のDBにも反映される一方、フィルターやビューはリンク先の表示に適用できると説明されています。

ここが実務上のポイントです。

リンクドDBで変えてよいのは、主に「見せ方」です。

タスク名、担当者、期限、ステータスなどの中身を変えれば、元DBの同じタスクも変わります。

元DBとリンクドDBの違い

Notionを業務システムとして使うなら、まず元DBを決めます。

たとえば、タスク管理なら「タスクDB」が元DBです。

この元DBに、すべてのタスクを集めます。

そのうえで、リンクドDBを使って別ページに必要な切り口だけを出します。

ページ 表示するリンクドDB フィルター例
チームホーム 今日の未完了タスク ステータスが完了以外、期限が今日以前
個人ページ 自分のタスク 担当者が自分
プロジェクトページ この案件のタスク 関連プロジェクトがこのページ
会議ページ 確認待ち・期限超過 ステータスが確認待ち、または期限切れ
管理者ページ 全体の滞留 担当者未設定、期限未入力、期限超過

元DBを複数作ると、あとで管理が崩れます。

たとえば、営業部タスクDB、開発部タスクDB、管理部タスクDBを別々に作ると、会社全体の未完了タスクを見られません。

部署ごとに見せたいだけなら、元DBは1つにして、リンクドDBで部署別ビューを作る方が安定します。

別DBを作るべきなのは、データの意味や管理責任が違う時です。見え方を変えたいだけなら、リンクドDBで分けます。

Notionデータベースの作り方

リンクドDBでできること

リンクドデータベースでできることは、主に「表示を変えること」です。

できること 業務での使い方
フィルター 自分のタスク、期限超過、特定案件だけを表示
並べ替え 期限が近い順、更新日が新しい順に並べる
ビュー形式の変更 テーブル、ボード、カレンダー、リストで見せる
表示プロパティの調整 会議で必要な担当者、期限、状態だけを出す
複数ページへの配置 ホーム、会議ページ、案件ページに同じDBを出す

Notion公式ヘルプでは、ビューごとに表示形式、プロパティ、フィルター、並べ替え、グループ化を調整できると説明されています。

Notion公式ヘルプ:Views, filters, sorts & groups

この考え方をリンクドDBに使うと、同じタスクDBでも次のように使い分けられます。

ビュー名 形式 見る人 目的
自分の未完了 リスト 各担当者 今日やることを見る
期限超過 テーブル マネージャー 遅れている作業を拾う
確認待ち ボード 確認者 承認やレビュー待ちを処理する
今週の会議用 テーブル チーム 期限、担当、状態を更新する
月次棚卸し テーブル 管理者 古いタスクや未設定を整理する

ビューを増やす時は、必ず「見る人」と「見るタイミング」をセットで決めます。

使う場面が決まっていないリンクドDBは、増やさない方がよいです。

作成手順

リンクドデータベースを作る流れは単純です。

  1. 表示先のページを開く
  2. /linked またはデータベースのリンク作成操作から、リンクしたいDBを選ぶ
  3. 既存ビューをコピーするか、新しいビューを作る
  4. フィルター、並べ替え、表示プロパティを調整する
  5. ビュー名を業務目的に合わせて付ける

ただし、業務利用では、操作手順よりも設計順の方が重要です。

先に次の項目を決めます。

決めること
元DB タスクDB、案件DB、議事録DB、顧客DB
表示先ページ チームホーム、会議ページ、案件ページ
見る人 担当者、確認者、マネージャー、外部パートナー
見るタイミング 毎朝、週次会議、月次確認
触ってよい項目 ステータス、期限、担当者、確認コメント
触らせない項目 権限、原価、評価、内部メモ

この順番を飛ばしてリンクドDBを置くと、「便利そうなビュー」が増えます。

便利そうなビューは、最初は使われます。

しかし、誰がいつ見るかが決まっていないと、数週間で古くなります。

フィルター・並べ替え・ビューの設計

リンクドDBで最も大事なのは、フィルター設計です。

元DBをそのまま別ページに置くだけなら、リンクドDBの意味は薄いです。

目的に合わせて、必要な行だけを見せます。

目的 フィルター例 表示プロパティ
自分の作業を見る 担当者が自分、完了以外 タスク名、期限、状態、関連案件
会議で遅れを見る 期限が今日以前、完了以外 担当者、期限、遅延理由、次回確認日
確認待ちを見る ステータスが確認待ち 確認者、依頼者、確認期限
案件別に見る 関連案件がこの案件 状態、担当者、完了条件
外部共有する 公開可がチェック済み 概要、期限、依頼内容、回答状態

並べ替えも重要です。

会議用なら、期限が近い順、確認待ちが上、担当者別などにします。

入力用なら、作成日が新しい順や未入力項目が上に来る並びにします。

見せるプロパティも絞ります。

全部の列を出すと、誰も見なくなります。

ビュー 出すべきプロパティ 隠すべきプロパティ
担当者用 期限、状態、関連案件、完了条件 管理メモ、原価、内部評価
会議用 担当者、期限、状態、遅延理由 詳細ログ、添付、細かいタグ
管理者用 未設定項目、最終更新日、責任者 なし。ただし表示順を整理
外部共有用 共有してよい概要、依頼事項 社内メモ、原価、他社情報

Notionビューの使い分け

ダッシュボードでの使い方

リンクドDBが最も役に立つのは、ダッシュボードです。

チームホームや会議ページに、元DBから必要なビューだけを集めます。

ダッシュボード 置くリンクドDB 目的
チームホーム 今日の未完了、期限超過、確認待ち 毎朝の確認
プロジェクトページ 関連タスク、関連議事録、決定事項 案件ごとの進行管理
会議ページ 今週の期限、確認待ち、未処理決定事項 会議中に更新する
管理者ページ 担当未設定、期限未入力、長期滞留 運用品質を見る
外部共有ページ 顧客確認事項、共有用タスク 社外と必要な範囲だけ共有する

Notionダッシュボードは、リンク集ではなく、業務で見る順番を固定するページです。

Notionダッシュボードの作り方

たとえば会議ページなら、次の順番でリンクドDBを並べます。

順番 ビュー 会議で決めること
1 期限超過 期限を変更するか、担当を変えるか
2 確認待ち 確認者が承認するか、差し戻すか
3 今週期限 先に手を打つべきものがあるか
4 未処理決定事項 タスク化されていない決定があるか
5 次回確認 次の会議で見る項目を残す

リンクドDBは、見るだけで終わらせない方がよいです。

会議中にステータス、期限、担当者、確認コメントを更新する。

そこまで決めると、ダッシュボードが実際の業務システムになります。

権限と編集影響の注意

リンクドDBで最も注意すべきなのは、権限と編集影響です。

リンクドDB上でページの中身やプロパティ値を編集すると、元DBにも反映されます。

そのため、誰にどこまで編集させるかを決めておく必要があります。

Notion公式のデータベース基本ヘルプでは、Can edit content 権限を持つユーザーはDB内のページやプロパティ値を編集できる一方、元DBのプロパティやビュー、フィルター、並べ替えは変更できないと説明されています。ただし、リンクドDB側ではビューやフィルターを編集できる場合があるため、チーム運用では注意が必要です。

Notion公式ヘルプ:データベースの基本

また、共有と権限のヘルプでは、Notionはユーザーに与えられた最も広いアクセス権を尊重する考え方が説明されています。

Notion公式ヘルプ:Sharing & permissions

リンクドDBを使う時は、次のように分けます。

役割 できること できない方がよいこと
担当者 自分のタスクの状態更新、コメント追加 ビュー条件の変更、全体DBの構造変更
確認者 確認待ちの承認、差し戻し 外部共有設定の変更
管理者 元DBのプロパティ、ビュー、権限設計 日々の細かいタスク更新を抱え込む
外部パートナー 共有対象の確認、必要なコメント 社内メモ、他案件、原価情報の閲覧

外部共有ページにリンクドDBを置く場合は、特に慎重に確認します。

フィルターで見えないようにしているだけでは、権限設計として十分とは限りません。

社外に見せる情報は、共有専用DBや共有専用プロパティを用意する方が安全です。

Notion権限設定の考え方

重複DBを作ってしまう失敗

リンクドDBを使わないチームでよくある失敗は、同じ意味のDBをいくつも作ることです。

失敗 起きること 直し方
部署ごとにタスクDBを作る 全社の未完了が見えない タスクDBを1つにし、部署別リンクドDBを作る
案件ページごとにタスク表を作る 担当者の全タスクが集計できない タスクDBに案件リレーションを持たせる
会議ごとに確認事項表を作る 決定事項が散らばる 決定事項DBを作り、会議別にリンク表示する
顧客ページごとに対応履歴を作る 対応履歴の横断検索ができない 対応履歴DBを作り、顧客別にリンク表示する

別DBを作るべきか、リンクドDBでよいかは、次で判断します。

判断基準 リンクドDBでよい 別DBにする
データの意味 同じタスク、同じ案件 顧客、請求、契約など意味が違う
プロパティ ほぼ同じ 必要項目が大きく違う
権限 同じ元DBの中で制御できる 閲覧範囲を完全に分けたい
集計 全体で集計したい 集計対象が別
外部連携 同じDBから連携したい 別システムのマスタに合わせる

Notionでは、見え方の違いをDB分割で解決しない方がよいです。

見え方の違いはリンクドDBとビューで解決します。

データの意味や権限が違う時だけ、別DBに分けます。

チーム運用の設計例

小規模チームでリンクドDBを使うなら、最初は次の構成で十分です。

元DB リンクドDB 表示先
タスクDB 自分の未完了 チームホーム、個人ページ
タスクDB 期限超過 会議ページ、管理者ページ
タスクDB 確認待ち 確認者ページ、会議ページ
プロジェクトDB 進行中案件 チームホーム
議事録DB 最新議事録 会議ページ、案件ページ
決定事項DB 未処理決定事項 会議ページ

各リンクドDBには、次の運用メモを付けます。

項目
見る人 チーム全員、確認者、管理者
見るタイミング 毎朝、週次会議、月末
更新する項目 ステータス、期限、担当者、確認コメント
消してよい条件 使われていない、重複している、見ても行動が起きない

Notion AIを使う場合も、リンクドDBは役に立ちます。

ただし、AIに任せるのは下書きや要約までです。

AIに任せてよい 人が確認する
議事録からタスク候補を抜き出す タスクとして登録するか
長いページを要約する 共有してよい内容か
滞留タスクを一覧化する 期限や担当をどう直すか
関連ページを探す 正しいプロジェクトに紐づけるか

リンクドDBは、AIが出した候補を人が確認する画面としても使えます。

「AI抽出タスク候補」「レビュー待ちナレッジ」「未確認決定事項」のようなビューを作ると、人の確認が必要なものだけを拾いやすくなります。

まとめ

Notionリンクドデータベースは、元DBをコピーする機能ではありません。

同じDBを、別ページで、別のフィルターやビューとして見せる機能です。

そのため、タスク、案件、議事録、顧客対応のような業務DBでは、元DBをむやみに増やさず、リンクドDBで目的別に見せる設計が重要です。

リンクドDBを作る時は、先に元DB、表示先ページ、見る人、見るタイミング、編集してよい項目、権限範囲を決めます。

フィルターや並べ替えは、見た目ではなく業務行動に合わせます。

そして、外部共有や社内権限では、リンクドDB上の編集が元DBに反映されることを前提に、見せる情報と編集できる情報を分けます。

リンクドデータベースは、Notionを単なるページ集ではなく、小さな業務システムとして使うための基本部品です。

同じDBを安全に使い回せるようになると、チームホーム、会議ページ、案件ページ、個人ページがつながり、情報の重複と確認漏れを減らせます。

Notionシステム設計支援

Notionデータベースを業務ダッシュボードとして設計します

同じDBを複数ページに出すだけでなく、フィルター、権限、更新責任、外部共有の範囲まで含めて運用に合わせます。

著者
守高 成悟
守高 成悟

代表取締役 CEO

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

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

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

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

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

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

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