Notion データベース入門｜基本と作り方

Notionのデータベースは表計算の代用品というより、1行ごとに本文を持てるページの集合として見ると、一気に理解が進みます。
私自身も、行を開いた瞬間にページ本文が現れて腑に落ちてから、設計で迷う場面がぐっと減りました。
この記事では、データベースの基本を30分でつかみたい初心者に向けて、プロパティとビューの考え方、テーブル・ボード・カレンダーの違い、プロジェクトDBとタスクDBをつなぐリレーションとロールアップの最小構成までを順に整理します。
あわせて、Notion公式のデータベースの基本や2025年以降の更新を踏まえ、UI刷新、権限、APIまわりの新情報にも触れながら、古い解説をそのまま信じるとどこでズレるのかも明確にしていきます。

Notionデータベースとは何か

Notionのページとデータベースの関係

Notionのデータベースは、説明されている通り、ページの集合です。
ここを表や台帳としてだけ捉えると、途中で考え方が噛み合わなくなります。
データベースの中に並んでいる1件1件は、単なるセルの集まりではなく、それぞれが独立したNotionページとして存在しています。

そのため、データベースには表計算ソフトと似ている部分と、まったく違う部分があります。
似ているのは、列にあたるプロパティを追加して、ステータス、期限、担当者のような属性で整理できることです。
違うのは、各行の奥に本文があり、そこへ会議メモ、手順、画像、チェックリストまで入れられることです。
タスク管理なら「タスク名」と「期限」だけで終わらず、そのタスクのページ内に作業メモや関連リンクを蓄積できます。

図でイメージすると、外側にデータベースという箱があり、その中にページが何枚も入っている状態です。
テーブルで見れば行として並び、ボードで見ればカードになり、カレンダーで見れば日付の位置に配置されますが、実体はどれも同じページです。
さらにNotionでは、ページそのものを別のページの中に置けます。
親ページの中に子ページを入れる感覚で情報をネストできるので、データベースの1件も、通常ページも、同じ「ページ」という土台でつながっています。

データベースの置き方には、独立したページとして作るフルページと、既存ページの本文中に埋め込むインラインがあります。
置き場所が違うだけで、どちらもデータベースとして扱えます。

データベースとは – Notion (ノーション)ヘルプセンター

データベースは、ページの管理と整理に役立つNotionの中核的機能です。ここでは、データベースの概要と、データベースの活用によりワークスペースがどのようにレベルアップできるかについて説明します 🗄

www.notion.com

1行=1ページを体験する

初心者がNotionのデータベースを理解するうえで、いちばん腑に落ちやすいのは「1行を開く」瞬間です。
テーブル上では1行のレコードに見えていても、タイトルをクリックすると右側のサイドピーク、あるいは中央の全面表示でページが開きます。
そこでチェックリストや段落を普通に書けるのを見て、表ではなくページを管理していたのだと実感するはずです。
私も最初にここで驚きました。
行の裏側に、いつものNotionページがそのまま入っていたからです。

たとえば「記事制作」というデータベースを考えると、一覧では「タイトル」「公開日」「担当者」「進行状況」だけが見えます。
しかし1行を開くと、そのページ本文に構成案、参考メモ、見出しの草案、確認事項まで書き込めます。
見た目はテーブルでも、実際には「属性付きのページを一覧化している」と捉えたほうが現実に近いです。

この構造を図解的に言えば、横一列の行がそのまま一枚のページの表紙になっているイメージです。
表紙にはタイトルと主要なプロパティが並び、開くと中身の本文がある、という二層構造です。
だからNotionのデータベースでは、一覧性と文書性が同居します。
単なる管理表ではなく、台帳とノートが一体化している感覚です。

ビューは見え方で元データは同じ

データベースを理解するときに、もうひとつ外せないのがビューの考え方です。
Notionでは同じデータベースをテーブル、ボード、カレンダー、リスト、タイムライン、ギャラリー、チャートなど複数のビューで表示できます。
追加されるUIは時期によって変わりますが、ポイントは数ではなく、見え方を変えても元データは同じということです。

たとえばタスクを同じデータベースで管理している場合、テーブルでは入力と一括編集がしやすく、ボードでは「未着手」「進行中」「完了」の流れが見え、カレンダーでは締切の偏りが見えます。
ここで別々のデータを持っているわけではありません。
ひとつのタスクの期限をテーブルで変えれば、カレンダーにもその変更が反映されます。
ステータスをボードで動かせば、テーブルの列も同じ値に変わります。

この仕組みを知ると、ビューを「用途別の窓」として使えるようになります。
入力はテーブル、進捗確認はボード、公開予定の把握はカレンダー、というように役割を分けても、管理対象はひとつです。
リンクドビューを使えば、別ページに同じ元データを表示しながら、部署別や担当別にフィルターした見せ方もできます。
複製しているのではなく、同じデータを別の角度から見ているだけなので、運用が散らかりにくくなります。

初心者の段階では、まず「プロパティがデータの属性」「ビューが見せ方」という二つを分けて理解すると混乱が減ります。
テーブルを作ったあとにボードへ切り替えても、別物を作り直しているのではありません。
ページの集合としてのデータベースが先にあり、その上に見え方が何枚も重なっている、という順番で捉えるとNotionらしい構造がつかめます。

データベースの基本 – Notion (ノーション)ヘルプセンター

Notionのデータベースは、ページの集合体です。この記事では、データベースの基本的な構造と、さまざまなメニューやオプション、データベース内のページの作成・編集について解説します

www.notion.com

まず覚えたい3要素：プロパティ・ビュー・フィルター

プロパティの型と役割を最小限で覚える

Notionのデータベースでは、各ページ（行）にどんな属性を持たせるかを決めるのがプロパティです。
前のセクションで触れた通り、行そのものはページで、プロパティはそのページを一覧管理するための見出しや条件になります。
考え方としては、本文に書く情報と一覧で比較したい情報を分けると迷いません。

最初に覚えるなら、次の型だけで十分です。
タイトルは各ページの名前で、データベースの軸になります。
ステータスは「未着手」「進行中」「完了」のような進み具合を持たせる型です。
日付は期限や公開予定日、人は担当者、選択は優先度や媒体種別のように1つ選ぶ属性、チェックボックスは完了確認、数式は期限までの日数や進捗判定の補助に向いています。
こうしたプロパティ値を使って整理・絞り込み・並べ替えができる前提で説明されています。

初心者の段階では、プロパティを増やすことよりも役割を分けることのほうが効きます。
たとえばタスクDBなら、タイトルに作業名、ステータスに進捗、日付に期限、人に担当者を入れるだけで、一覧としての意味が一気に立ちます。
反対に「背景」「議論メモ」「決定理由」まで列で持とうとすると、テーブルが横に広がるだけでなく、1件ごとの文脈が読みにくくなります。
そういう情報はページ本文側に置くほうが、あとで開いたときの流れが自然です。

2025-07-10のNotion 2.52以降は、UI上でもプロパティ追加まわりが整理され、「+プロパティ」という表記が前に出ています。
古い解説だと列メニューの呼び方が違うことがありますが、今の画面では「+プロパティ」から必要な型を足していく理解で問題ありません。
最初のDBでは、タイトル、ステータス、日付、人の4つを先に置いて、足りない属性だけ後から増やす流れのほうが設計が崩れません。

慣れるまでは、プロパティの選び方に正解を求めすぎなくて大丈夫です。
実際に使ってみると、「優先度」は選択で足りるのに、「担当」は選択ではなく人にしておくとメンバーで絞り込みやすい、といった違いが見えてきます。
型は見た目ではなく、あとで何をしたいかで決めるものだと捉えると整理しやすくなります。

データベースのプロパティ – Notion (ノーション)ヘルプセンター

データベースプロパティは、期限やタスク担当者、関連URL、最終更新日時のタイムスタンプなど、あらゆる種類のコンテキストをデータベースアイテムに追加します。追加したプロパティの値に基づいて、データのフィルタリングや並べ替え、検索も可能です。

www.notion.com

ビュー比較表

ビューは、同じデータベースをどの形で見るかを切り替える仕組みです。
ここで押さえたいのは、ビューを変えても元データは変わらないという点です。
テーブルで入力したステータスはボードにも反映されますし、カレンダーで動かした日付はテーブル側にもそのまま出ます。
複製した別表ではなく、1つのデータベースを別の角度から見ているだけです。
既存DBを別ページに出すリンクドビューでも、この前提は同じです。

実際に触ると、この感覚は想像以上に大きいです。
ビューメニューでグループ化を切り替えた瞬間、同じDBなのに別物のように仕事が進む場面があります。
担当者ごとに見ると割り振りの偏りが見え、ステータスごとに見ると停滞が見えます。
それでも元データは1つのままなので、管理台帳が増えていかないところがNotionらしいところです。

初心者が最初に使うことの多い3ビューを並べると、向き不向きは次のように整理できます。

テーブルは、まず1件ずつ情報を入れていく段階で相性が良いビューです。
列が見えているので、どの属性が埋まっていて、どこが空かを把握しやすくなります。
ボードは、ステータスや担当者ごとにカードを並べたいときに効きます。
タスク管理で「未着手」「進行中」「完了」を横並びにすると、どこに作業がたまっているかがすぐ見えます。
カレンダーは、日付を中心に考える仕事に向きます。
記事公開日、締切、面談予定のように、順番より日付が優先されるデータならこちらのほうが把握しやすくなります。

ビューは用途ごとに選ぶものとして整理されています。初心者なら、まずテーブルで元データを整え、その後にボードかカレンダーを足す順番が扱いやすい構成です。

When to use each type of database view

Teams often have data sets that need to be sliced many ways — whether it’s a shared company roadmap or list of project t

www.notion.com

フィルター/並べ替え/グループ化の違い

この違いは、実際の画面操作で見るとつかみやすいのが利点です。
ボードビューでグループ化を担当者に変えると、同じタスクDBでも「進捗管理の板」から「人ごとの作業棚」に見え方が切り替わります。
一方で、並べ替えを期限昇順にしてもグループの枠組み自体は変わりません。
フィルターを「未完了のみ」にすると、棚の中から対象だけが残ります。
つまり、何を見せるか、どの順番で見せるか、どの単位で束ねるかを別々に操作しているわけです。

Notion 2.52では、こうした操作もプロパティメニューやビューメニューから触りやすくなっています。
以前の解説より切り替え場所が見つけやすくなっているので、今のUIでは「ビューを選ぶ」「必要ならフィルター・並べ替え・グループ化を足す」という順番で考えると混乱が減ります。

Notionデータベースの作り方

方法A：新規ページからフルページDB

最初の1つを作るなら、新規ページからフルページのデータベースを立ち上げる流れがいちばん把握しやすいのが利点です。
サイドバーで新規ページを作成し、ページの種類としてデータベースを選ぶと、独立した1ページまるごとのDBが開きます。
ここで名前を付け、必要ならページ上部のアイコンも設定すると、そのDBがワークスペースの中で何を管理する場所なのかが一目で伝わります。
たとえばタスク管理案件一覧記事台帳のように、用途をそのままDB名にすると後で迷いません。

作成直後の画面では、1列目にタイトル用の列が置かれています。
これは各行の名前であり、同時に各行のページ名でもあります。
前述の通り、NotionのDBは単なる表ではなくページの集合なので、この列がある状態が出発点です。
行を追加して「○月企画」「見積もり送付」「取材候補」と入れれば、その1件ずつを個別ページとして開けます。

初心者の段階では、最初から列を増やしすぎないほうが流れをつかみやすくなります。
まずはタイトル列だけで1、2件入れてみて、次にステータスや期限のような必要最低限のプロパティを足す順番だと、何が元データで何が見た目の設定なのかが崩れません。
DBはページのコレクションとして説明されており、この理解のまま作り始めると後の操作がつながります。

方法B： でインラインDB

既存ページの本文中に表を差し込みたいなら、インラインDBのほうが合います。
任意のページでスラッシュコマンドを開き、「/database」や「/table」と入力すると、ページ本文の中にそのままDBを挿入できます。
議事録、プロジェクト概要、チームのダッシュボードなど、文章と一覧を同じ場所に置きたい場面で便利です。

たとえば会議ページの上半分に議題と決定事項を書き、その下にアクション管理用のテーブルを置くと、本文とタスクが切り離されません。
私自身、同じタスクDBでもフルページに置くと専用画面として頭を切り替えやすく、インラインだと議事録の本文と並べたまま文脈を保てるところに価値を感じています。
会議中に決まった宿題をその場で行に追加できるので、「あとで別ページに転記する」手間が発生しません。

インラインで作った場合も、DBとしての中身はフルページと同じです。
1列目にはタイトルプロパティがあり、各行をページとして開けます。
見た目が本文中に埋め込まれているだけで、表のように見える部分の裏側ではページが並んでいる構造です。
ここを理解しておくと、「インラインは簡易版」という誤解を避けられます。

テンプレート/AIでひな形を作る

白紙から作るだけが入口ではありません。
よくある用途ならテンプレートを使って、列やビューが入った状態から始める方法もあります。
Notionにはテンプレートライブラリがあり、タスク管理、プロジェクト管理、コンテンツ計画のような定番の形を流用できます。
自分で列名を考える前に完成形を見られるので、「どんな項目を持たせると回るのか」がつかみやすくなります。

Notion AIを使って下書きを整える流れもあります。
散らばったメモを表の形にまとめたいとき、ゼロから列を設計する負担を軽くできます。
おおまかなドラフト作成や表化の支援が機能として示されています。

ただし、テンプレートやAIで作ったひな形は、そのまま完成品として固定するより、実際の運用に合わせて列を削るほうが収まりが良い場面が多いです。
最初から項目が多いと入力の重心がぼやけるため、まずはタイトル列があり、必要なプロパティが数個並んでいる状態に整えるほうが、使い始めの手が止まりません。

Notion AIを使って可能性を広げる

人工知能とは何か、またこのテクノロジーの現段階での機能や限界について説明します。

www.notion.com

フルページ vs インラインの使い分け

両者の違いは、機能差というより置き場所と視線の流れにあります。
フルページはDBそのものが主役になる配置で、基幹のタスク台帳や案件管理のように、一覧を中心に操作したい場面と相性が合います。
画面全体を使って並べ替え、フィルター、ビュー切り替えを行えるので、「今日はこのDBを触る」という作業の入口になります。

一方のインラインは、文章の流れの中にDBを差し込む形です。
会議メモの下にアクション一覧を置く、プロジェクトの説明文の横に進行表を置く、週報ページに今週のタスクだけを見せる、といった使い方に向きます。
本文の文脈を読んだまま表に触れるため、「何のための一覧か」が画面から消えません。
図で整理するなら、フルページは独立した管理画面、インラインは記事やメモの一部として埋め込む管理ブロックというイメージです。

用途ごとに分けると、基幹DBはフルページで持ち、必要な場所ではインラインやリンクドビューで見せる設計が自然です。
元データを1つに保ちながら、見せる場所だけ変える考え方です。
運用を始めた後に混乱しにくいのはこの形で、設計の中心と利用シーンの切り分けができます。

初回作成の時点では、どちらを選んでも成功条件は同じです。
名前が付いていて、1列目にタイトルがあり、1件以上の行を追加できること。
この状態まで作れれば、次はプロパティを足して自分の仕事に合わせる段階へ進めます。

基本的な使い方：タスク管理データベースを作る

最小プロパティ設計

最初のタスク管理DBは、列を増やすより先に「この1件をどう判別するか」だけを決めると形が安定します。
タイトルは既定で入っているので、そのままタスク名に使います。
追加するのはステータス、期限、担当者の3つで十分です。
たとえばタイトルに「見積もり送付」「取材日程の確定」「記事初稿の確認」と入れ、ステータスは「To Do」「In Progress」「Done」、期限は日付、担当者は人のプロパティにしておくと、仕事の流れがひと目で読めます。

この段階で優先したいのは、入力の迷いをなくすことです。
列が多いと「優先度も必要か」「タグも入れるべきか」と止まりやすくなりますが、最初は誰が、いつまでに、今どこまで進んでいるかが見えれば回り始めます。
プロパティは用途に応じて追加・調整できる前提で扱われています。
最初から完成形を狙うより、まず4項目で動かして、足りない列だけ後で足すほうが運用に合います。

実際に私が初心者向けに説明するときも、最初の画面にはこの4つしか置きません。
タスク管理でつまずく場面の多くは、情報不足ではなく設計過多です。
タイトル、ステータス、期限、担当者だけにすると、1件追加するたびに「これは何の仕事で、誰が持っていて、締切はいつか」が自然に揃います。

レコード入力とページ本文の活用

テーブル→ボード→カレンダーの3ビューを作る

入力の起点として最初に作るのはテーブルビューです。
ここではタスクを追加し、列を埋め、全件を一覧で確認します。
表示列が多いと視線が散るので、作成日時のような今は使わない列が見えているなら非表示にして、タイトル、ステータス、期限、担当者だけ残すと密度が整います。
並べ替えは期限が近い順にしておくと、何から触るか判断しやすくなります。
こうした表示設定は保存できるので、毎回整え直す必要がありません。
次に同じ元データからボードビューを作り、ステータスでグループ化します。
列見出しが「To Do」「In Progress」「Done」になる形です。
ここまで来ると、テーブルでは列の値として見えていたステータスが、作業の流れそのものとして見えてきます。
実際、ボード上でカードを「To Do」から「In Progress」へ、さらに「Done」へドラッグすると、テーブルに戻ったときにもステータス列の値が即座に変わっています。
この一貫性を体感すると、元データは1つで、ビューは見え方だけを分けているというNotion流の考え方が腹に落ちます。

日付軸でも見たいなら、今度はカレンダービューを追加して期限プロパティを割り当てます。
すると、同じ5件のタスクが日付の位置に配置され、締切の偏りや空白の日が見えてきます。
テーブルでは一覧、ボードでは進捗、カレンダーでは期日というように、見ている対象は同じでも、頭に入ってくる情報の種類が変わります。
ビューごとに把握しやすい情報が異なることが整理されています。

カレンダーでは期限未設定のタスクが表面に出にくい点にも触れておきたいところです。
テーブルでは空欄として見えていたレコードが、カレンダーでは存在感を失います。
だからこそ、締切を軸に見たい運用では、期限だけは早めに入れる意味があります。
ここでも「ビューが違うだけで元データは同じ」という前提を持っていると、何をどの画面で確認したいのかを言葉にしやすくなります。

表示/非表示・並べ替えの保存Tips

ビューを切り替えられるようになると、次に効いてくるのが表示設定の保存です。
テーブルを入力用として使うなら、本文の作業に直接関係しない列は隠し、期限順や担当者順の並べ替えを保存しておくと、開いた瞬間に「今日見るべき並び」になっています。
毎回列幅や並び順を触っていると、それだけで一覧の信頼感が薄れます。

ボードでも同じで、見せたい軸を一つに絞ると列の意味がはっきりします。
ステータスで進捗を見るビューなのに、担当者や期限まで一度に詰め込むと、カードの情報量が増えすぎて流れが読みにくくなります。
進捗を動かす場所として割り切ると、ドラッグ操作の価値が前に出ます。
テーブルは入力と編集、ボードは進捗更新、カレンダーは締切確認という役割分担にしておくと、同じDBを見ていても迷いません。

この保存設定を触っていると、表示とデータを分けて考える感覚も育ちます。
列を隠しても情報が消えるわけではなく、並べ替えてもレコードそのものが変わるわけでもありません。
変わるのは見え方だけです。
タスク管理DBの基礎は、まさにこの整理にあります。
1つの元データを、入力しやすい形、進捗を追いやすい形、締切を見渡せる形に切り替えて使う。
その流れがつかめると、次にフィルターやリンクドビューへ進んでも混乱しません。

活用術：リンクドビュー・リレーション・ロールアップ

ここで触れておきたいのが、既存のデータベースを別ページに呼び出して使うリンクドビューです。
考え方の軸はシンプルで、プロパティは各アイテムの属性を持たせるもの、ビューはそのデータの見え方を変えるものです。
タスク名、担当者、期限、ステータスといった値はプロパティに入り、テーブル、ボード、カレンダーのような表示形式や、どの行だけ見せるかはビュー側で調整します。

リンクドビューの便利さは、同じ元データを用途別に切り分けられるところにあります。
たとえば基幹のタスクDBは1つだけ持ちつつ、会議ページには「今週が期限のタスク」だけを出し、部署ページには「部署Aの案件」だけを出す、といった見せ分けができます。
ここで変わっているのは表示条件であって、元データそのものではありません。
前述のビュー切り替えと同じく。

このとき区別しておくと迷いにくいのが、フィルター・並べ替え・グループ化は役割が違うという点です。
フィルターは「どの行を表示するか」を決めます。
並べ替えは「表示する順番」を変えます。
グループ化は「どの軸でまとまりを作るか」を決めます。
たとえば「担当=自分」で絞るのはフィルター、「期限が近い順」に並べるのは並べ替え、「ステータスごと」に列分けするのはグループ化です。
似た操作に見えても、触っているレイヤーが違います。

私自身、部署ごとのダッシュボードページに、担当者が自分のものだけ見えるリンクドビューを置く運用をよく使います。
同じタスクDBを見ていても、そのページでは自分が今日動かすものだけが並ぶので、巨大な一覧を開く感覚ではなく、自分専用の窓を開く感覚に近くなります。
全体DBを壊さず、見る人ごとの入口だけ変えられるのがリンクドビューの強みです。

データベースは複数の表示方法を持てる前提で説明されています。
初心者の段階では、まず元のDBを1つ決め、その後にリンクドビューで「会議用」「自分用」「期限確認用」と窓口を増やす流れにすると、設計が散らばりません。

プロジェクトDB↔タスクDBをリレーションで接続

リンクドビューが「同じDBを別の角度で見る」機能だとすると、リレーションは「別々のDB同士をつなぐ」機能です。
ここで使うのがリレーションプロパティで、タスクDBの各行に「どのプロジェクトに属するタスクか」を持たせます。
プロパティの一種なので、役割としては担当者や期限と同じく、その行に属性を追加している感覚です。
ただし値の中身がテキストではなく、別DBのページを参照する点が特徴です。

初心者が最初に組むなら、1対多の形がいちばん把握しやすいのが利点です。
つまり、1つのプロジェクトに複数のタスクが紐づく設計です。
最小手順で作るなら、まずプロジェクトDBを用意してプロジェクト名のページを並べ、次にタスクDB側にリレーションプロパティを追加して接続先をプロジェクトDBに指定します。
これで各タスクに「Webサイト改修」「採用広報」などの親プロジェクトを選べるようになります。
逆方向のプロパティも自動で作られるので、プロジェクトDBの各ページから関連タスク一覧を見返せます。

この接続があると、タスクを単独のToDoとして扱う段階から一歩進んで、「どの仕事の束に属しているか」で管理できるようになります。
たとえばタスク名が「初稿作成」だけだと複数案件で重複しがちですが、リレーションでプロジェクトがつながっていれば文脈が失われません。
行を開いたときのページ本文に詳細を持たせる前提とも相性がよく、一覧では軽く、詳細では深く扱えます。

ロールアップで件数・最短期限を集計

リレーションでDB同士がつながると、次に使いたくなるのがロールアップです。
これは、接続先DBの値を集計して見せるプロパティです。
役割としては「参照と集計」で、単なる表示列ではありません。
タスクDBとプロジェクトDBがつながっていれば、プロジェクトDB側に「関連タスク数」「未完了タスク数」「最短期限」といった集計列を持たせられます。

実務で効果が見えやすいのは、プロジェクトDBに「未完了数」と「最短期限」を置くパターンです。
まずタスクDBにはステータスと期限が入っている前提にします。
そのうえでプロジェクトDBにロールアップを追加し、リレーション先のタスクを集めて、ステータスや期限を参照します。
未完了数なら、完了以外のタスクだけを数える形です。
最短期限なら、関連タスクの中でいちばん早い日付を拾います。
こうしておくと、プロジェクト一覧を見ただけで「この案件は未完了が残っているか」「いちばん近い締切はいつか」がわかります。
タスクDBを毎回開いて探しにいかなくて済むので、一覧の意味が変わります。
単なる名前の並びではなく、進行中の圧力が上に浮いてくる感覚です。
私も、案件数が増えてきた段階でこの列を置くようになってから、優先順位の判断をプロジェクト単位で付けやすくなりました。

別DBから値を引いて集計する仕組みが整理されています。
初心者のうちは、ロールアップで何でも可視化しようとせず、まずは件数と日付に絞ると構造が崩れません。
数、最短日、チェック状態の集計だけでも、DB同士をつなぐ意味は十分に体感できます。

リンクドビューと複製の違いは初心者が混同しやすい判断材料になります。
見た目だけ追うとどちらも「同じような表がもう1つできた」ように見えますが、実体は異なります。
リンクドビューは同じDBを参照しているため、片方でタスク名やステータスを変えればもう片方にも反映されます。
一方で複製は新しい独立DBとして切り出されることがあるため、片方を編集してももう片方は変わりません。

初心者が混同しやすいのが、リンクドビューと複製です。
見た目だけ追うと、どちらも「同じような表がもう1つできた」ように見えますが、実体は違います。
リンクドビューは同じDBを参照しているので、片方でタスク名やステータスを変えれば、もう片方にもその変更が反映されます。
一方で複製は、新しい独立DBとして切り出されることがあります。
この場合、見た目が似ていても中身は別物です。

この差を理解していないと、「部署ページの一覧だけ直したつもりが全体DBも変わった」「逆に、複製したほうは更新されず古いまま残った」といった混乱が起こります。
用途別に見せ分けたいだけなら、基本はリンクドビューです。
元データを共有したまま、フィルターで表示対象を変え、並べ替えで順番を整え、必要ならグループ化で見出しを作る。
この流れなら、データは1つに保たれます。

複製を使う場面があるとしても、それは元DBとは別に運用したいときです。
たとえば検証用に構造を試したい、元の運用と切り離して新しい設計を作りたい、といったケースです。
普段の業務ダッシュボードでは、複製よりリンクドビューのほうが筋が通ります。
元データを増やすのではなく、入口を増やす発想です。

この整理ができると、プロパティ、ビュー、リレーション、ロールアップの位置づけもつながって見えてきます。
プロパティは1件ごとの属性、ビューは見え方の切り替え、リレーションはDB同士の接続、ロールアップは接続先の集計です。
最初に触る機能としては少し発展的ですが、この4つの役割を分けて考えられると、NotionのDB設計が一気に素直になります。

リレーションとロールアップ – Notion (ノーション)ヘルプセンター

2つのデータベースの情報を一度に見たいこともありますよね。Notionデータベースのリレーション形式のプロパティを活用すれば、複数のデータベースからのアイテムを関連付けて様々な表現をすることができます 🛠

www.notion.com

2025-2026の最新アップデートで変わった点

Notion 2.52のDB UI刷新ポイント

Notionのデータベース解説は、2024年以前の記事だと画面の前提がもう少し古いことがあります。
差が出やすいのが、2025年7月10日に公開された2025年7月10日 – Notion 2.52：すべてがデータベース以降の見え方です。
この更新ではデータベース周りのUIが整理され、作成導線やプロパティ追加の入口、ビューの扱いが一段わかりやすくなりました。

初心者にとって効くのは、+プロパティの導線が前に出てきたことです。
以前は、列を足す操作と「どの型で持たせるか」の判断が少し離れて見えやすく、最初の設計で止まりやすい場面がありました。
今のUIだと、列を増やす操作から型の選択までが自然につながるので、初回設計で「これはステータスにするのか、セレクトにするのか、日付にするのか」と迷って手が止まる場面が減ります。
実際に触っていても、+プロパティから考え始める流れが素直で、最初の“型選びの迷い”が前より薄くなった感触があります。

この刷新で押さえておきたいのは、データベースが従来より「表を作る機能」ではなく、「情報をページとして持ちながら、見え方を切り替える基盤」として前面に出てきたことです。
既に触れたテーブル、ボード、カレンダーの考え方自体が変わったわけではありませんが、UI上の配置が整理されたことで、ビュー追加とプロパティ設計の関係を把握しやすくなっています。
古い画面キャプチャのまま学ぶと、現行UIではボタン位置や名称が異なるため、操作で迷う場面が出ます。

2025年7月10日 – Notion 2.52：すべてがデータベース

Notion 2.52：すべてがデータベース

www.notion.com

Feedビューの位置づけ

Feedビューも、古い解説との差が出る判断材料になります。
これは一覧を表として詰めて見るというより、1件ごとの内容を流し見しながら判断したいときに向く見せ方です。
従来のテーブルは入力と編集、ボードは進捗の流れ、カレンダーは日付軸の確認に強みがありましたが、Feedは「中身の気配を見ながら選ぶ」ためのビューとして置くと収まりがいいです。

たとえば、記事ネタ、会議メモ、顧客接点の記録、採用候補のメモのように、タイトルだけでは判断しにくいデータでは、Feedの価値が出ます。
本文断片や主要プロパティが並ぶことで、1件ずつページを開かなくても取捨選択できます。
逆に、締切管理やステータス更新のように、列単位で素早く編集したい場面ではテーブルのほうが向いています。
つまりFeedは既存ビューの代替というより、一覧の中に「読む」体験を持ち込む追加選択肢です。

権限の拡張

近年、権限の粒度化に関する話題が増えています。
ただし、細かな仕様や導入方法は製品のリリースノートやヘルプで随時更新されます。
実際の設定や表現（例:権限名やスコープ）は Notion の公式リリースノートやヘルプページで最新情報を確認してください。
本節では、一般的に想定される運用上の影響と、受付台帳や申請一覧など「作成のみを許可したい」ケースでの設計例を紹介します。

開発者向け：multi-sourceとdata_source_id

利用者目線ではUI刷新の話に見えても、開発者目線では「1つのDBらしく見えるものの裏側の識別子」が変わってくる、という理解が近いです。
既存の連携コードがデータベースを単一ソース前提で扱っていると、取得・更新・同期の設計を見直す箇所が出てきます。
とくに外部ツール連携や社内自動化でIDを直書きしているケースでは、この変更を前提に読む必要があります。

一般ユーザーが日常操作で直接触る部分ではありませんが、社内でZapierや自作スクリプト、独自アプリ連携を使っているチームでは無関係ではありません。
画面上は同じDBに見えていても、APIではデータソースの扱いが軸になる場面が増えたため、2025年後半以降の技術記事を読むときは、database_idだけで完結する説明か、data_source_idまで踏み込んでいるかで鮮度が見分けやすくなります。

よくある失敗と対処法

最小プロパティから始める設計

初心者が最初につまずきやすいのは、作り始めの段階でプロパティを盛り込みすぎることです。
Notionは選択肢が多いぶん、優先度、工数、見積時間、タグ、関連案件、メモ、参考URLまで一気に並べたくなりますが、列が増えるほど「どこに何を入れるか」を毎回判断する必要が出ます。
入力が止まる原因は、機能不足より設計過多であることのほうが多いです。

実際には、最初の1本はタイトル、ステータス、期限、担当者の4つで足ります。
タスク管理ならこの組み合わせだけで、「何をするか」「今どこまで進んでいるか」「いつまでか」「誰が持つか」が見えます。
ここに不足を感じたときだけ、次の1列を足すほうが運用は安定します。
たとえば、あとから「優先度がないと朝の並べ替えができない」と気づいたら優先度を追加する、という順番です。
このやり方だと、不要な列が残りにくくなります。
Notion公式のデータベースのプロパティを見ると、プロパティは後から増減も表示調整もできます。
最初から完成形を作るより、まず入力が続く形を作って、実際の運用で不足分だけ補うほうが失敗が少なくなります。
リレーションやロールアップも便利ですが、慣れる前から組み込むと「何を直接入力して、何が参照値なのか」が曖昧になり、かえって迷いが増えます。

ビューの命名と整理ルール

次に起きやすいのが、ビューを増やしすぎて自分でも使い分けがわからなくなる状態です。
テーブル、ボード、カレンダー、Feedと切り替えられるので、用途ごとにどんどん増やせますが、名前が「新しいビュー」「テーブル 2」「確認用」のままだと、数日後には意味を思い出すところから始まります。

ここでは命名規則を先に決めると崩れにくくなります。
たとえば「担当別_田中」「週次_今週」「予定_公開カレンダー」のように、誰向けで、何を見るビューなのかを名前に含めるだけで、開く理由が明確になります。
Notionの各データベースビューの使い分けで整理されている通り、ビューはデータそのものを増やす機能ではなく、同じ元データの見え方を変える仕組みです。
役割が似たビューを複数持つと、見た目だけ違って中身は同じという状態になり、切り替えの手間だけが残ります。

整理の基準も単純で構いません。
フィルター条件がほぼ同じ、表示プロパティの差が小さい、開く頻度が低い、この3つのどれかに当てはまるなら統合候補です。
逆に、入力用のテーブル、進捗確認用のボード、締切確認用のカレンダーのように役割がはっきり分かれているビューは残す価値があります。
ビュー数そのものより、「その画面を開いた瞬間に目的が言えるか」で判断すると迷いません。

リンクドビューと複製を混同するのも、この段階で起きがちな失敗です。
リンクドビューは既存データベースを別ページで見せているだけなので、元データは共有されています。
一方で複製は別物です。
見た目が似ていても、片方を編集したらもう片方も変わるのかどうかで性質が違います。
私は新しいページで一覧を作ったとき、URLに含まれる database_id を見て、元と同じIDかを確認する癖をつけています。
同じならリンクドビュー、違うなら別データとして扱う、という切り分けです。

重いときの対処

データベースが重く感じるとき、まず疑うべきは行数そのものより表示量です。とくにテーブルで多くの列を常時表示していると、一覧の意味以上に情報を抱え込みがちです。

私自身、1000件規模になったタスクDBでは、表示列を半分にするだけで体感が軽くなる場面を何度も見ています。
そこで最初にやるのは、不要な表示プロパティの断捨離です。
入力時に本当に見る列だけ残し、説明文、長文メモ、補助タグ、集計用の項目は隠します。
列を減らすと視線の移動も減るので、軽さだけでなく編集のテンポも戻ります。

古いページを一覧から外すのも効きます。
完了済みや過去案件を全部同じビューに載せたままだと、現在進行の作業を見る画面としては密度が高すぎます。
Created timeを使って一定期間より前のページを除外する、完了済みだけ別ビューに分ける、といった整理で現役データの面積を絞れます。
基幹DBをひとつに保ちつつ、日常運用ではリンクドデータベースを使って「今週分だけ」「未完了だけ」を見せる構成にすると、元データを分断せずに軽さを取り戻せます。

Optimize database load times & performance – Notion Help Center

Here’s how to make sure your databases are always feeling quick and snappy 🏃🏼

www.notion.com

エクスポート/再インポートの落とし穴

CSVを書き出して整形し、あとから再インポートする運用では、リレーションがそのまま戻ると思い込むと詰まりやすくなります。
ここで引っかかるのが、リレーション先がCSV上ではURL文字列のような形になっても、再インポート時に自動で元のリレーションとして再構築されない点です。
タスクDBとプロジェクトDBをつないでいたつもりでも、戻した後はただのテキスト列になっていることがあります。

回避策は、再リンク前提でキーを持っておくことです。
たとえばプロジェクト側に一意の管理番号や短い識別キーを置き、タスク側にもそのキーを保持しておけば、再インポート後に対応関係を追いやすくなります。
ページURLだけを頼りにすると、人が見て照合しにくく、修復に時間がかかります。
リレーションを多用するDBほど、「戻すときにどうつなぎ直すか」を設計段階で持っておくと事故が減ります。

この種の再構築作業では、リンクドビューと複製の取り違えも絡みます。
別ページに見えていても同じ元DBを参照しているだけなら、CSVを介さずビュー設計で済んだ話だった、ということもあります。
逆に本当に別DBへ移したいのにリンクドビューだと思い込んで作業すると、想定外に元データを動かしてしまいます。
エクスポート前後で「同じデータを別の見せ方で使いたいのか」「別データとして持ちたいのか」を切り分けるだけで、手戻りは減ります。

料金や権限まわりも、古い解説のまま理解すると噛み合わないことがあります。
プラン体系はNotionのPricingで4段階ですが、無料・有料の差分や権限の粒度は更新が続いています。
行レベル権限や作成権限の扱いを含め、この領域は最新ヘルプに合わせて読む前提で捉えると、CSV運用や共有設計とのズレが少なくなります。

まとめ

最初は用途を1つに絞り、プロパティとビューだけで回すところまで進めるのが近道です。
私もまず1つのDBに3つのビューを作ったところで、Notionデータベースの芯が一気に見えました。
そこまで到達できれば、次はタスクDBとプロジェクトDBをリレーションでつなぐ順番で無理なく広げられます。
導入前はNotionの料金がFree・Plus・Business・Enterpriseの4段階であることを押さえつつ、差分はNotionの『Pricing』で最新表示を見て判断しておくと迷いません。

今日やることチェックリスト

空のタスクDBを1つ作り、タイトル・ステータス・期限の3プロパティを追加します。
続いてテーブル、ボード、カレンダーの3ビューを作り、同じデータが見え方だけ変わる感覚を確認してください。
そこまで再現できたら、慣れた段階でプロジェクトDBを別に作り、リレーションとロールアップの接続まで試せば本記事の到達点に届きます。