【Notionデータベース】作り方5ステップ｜ビュー活用術

約 20 分で読めます

Notionデータベースは、性質の同じページを集め、プロパティで属性を付け、ビューで見せ方を切り替える仕組みです。本記事は作成手順からプロパティ設計、ビュー活用、権限管理、料金まで通しで解説します。

1. Notionデータベースとは ｜ 3つの構成要素を1分で理解する

Notionデータベースとは、性質の同じページをひとつの入れ物にまとめ、「プロパティ」でステータス・担当者・期日といった絞り込み可能な項目を付け、「ビュー」でテーブル・ボード・カレンダーなど別々の見え方に切り替えられる機能です。表計算ソフトの表に似ていますが、1行が1ページとして開き、その中に議事録も資料も添付できる点が決定的に違います。

普通のページとの違いは一文で言えます。普通のページは「書いた内容がそこに残るだけ」、データベースは「書いた内容に属性が付き、後から並べ替え・絞り込み・集計ができる」。同じ100件の情報でも、前者は探す手間が増え続け、後者は増えるほど価値が出ます。

データベースには2つの置き方がある

ひとつは既存ページの中に埋め込む「インラインデータベース」、もうひとつは1ページまるごとがデータベースになる「フルページデータベース」です。どちらを選ぶかで後の運用が変わるため、次の章で比較表を用意しました。

プロパティが「使えるかどうか」を決める

プロパティは各ページに付ける属性です。テキスト、数値、日付、セレクト、ステータス、人物、ファイル、URL、数式、リレーションなどがあり、ここを設計しないままデータを溜めると、ただのメモの山になります。逆に言えば、タスクの定義が曖昧なままプロパティを増やしても、誰も埋めません。設計の順番は「管理したい問い」→「プロパティ」です。

ビューは同じデータの見せ方を切り替える仕組み

ひとつのデータを、人や目的ごとに違う形で見せられるのがビューです。よく使われるレイアウトは次の8種類です（提供状況は更新されるため、最新は公式ヘルプで確認してください）。

• テーブル：全項目を一覧で確認する。編集作業の基本形
• ボード：ステータス別にカードを並べる。進行中／完了の流れを見る
• カレンダー：日付プロパティを月次で表示。締切の偏りが見える
• タイムライン：期間を横棒で表示。簡易的なガントチャートになる
• リスト：情報量を絞ってタイトル中心に表示。読み物の索引向き
• ギャラリー：カバー画像付きカード表示。デザイン案や資料の棚に
• チャート：件数や合計をグラフ化。集計結果を見せる
• フォーム：外部の人がデータを送信できる入力画面を作る。問い合わせや申請の受付に使う

2. データベースの作り方 ｜ 5ステップで最初の1つを完成させる

手順は5つです。上から順に進めれば、10分ほどで実用に耐えるものができます。

ステップ1：置き場所を決める。 「営業部」「プロジェクトA」のような親ページを先に作り、その配下に置きます。トップ階層に直接作ると、数が増えたときサイドバーが崩壊します。

ステップ2：追加する。 ページ本文で /database と入力し、「データベース – インライン」か「データベース – フルページ」を選びます。インラインは、説明文や運用ルールと同じページに表を置けるのが利点です。フルページは1ページ全体が表になり、サイドバーから直接開けます。

ステップ3：タイトル列の命名ルールを決める。 最初の列（タイトル）は後から型を変えられません。「【案件名】内容」のような書式を最初に決め、表の上に1行メモとして残しておくと、他のメンバーが迷いません。

ステップ4：プロパティを追加する。 表の右端の「＋」から追加します。詳細は次章で扱います。

ステップ5：ビューを作って共有する。 左上のビュー名の横から追加します。自分用と共有用を分けるのがコツです。

作成そのものは簡単ですが、実務で効いてくるのは「置き場所」と「命名ルール」です。ここを決めずに増やすと、半年後に同じ内容のデータベースが3つ並ぶことになります。まだワークスペースを持っていない場合は、Notionのフリープランで試しながら設計を固めるのが確実です。

インラインとフルページはどう選ぶか

判断の目安はシンプルです。そのデータだけで完結するならフルページ、前後に説明が必要ならインライン。プロジェクト憲章や要件定義の文書中に課題一覧を置くようなケースは、インラインが自然です。

Notion AIで構成案を一気に出す

ゼロから列を考えるのが面倒なときは、Notion AIにデータベースの作成を依頼する方法があります。「顧客の商談状況を追う表を作って」と伝えると、列構成の案とサンプル行をまとめて生成してくれます。そのまま使うのではなく、不要な列を削るための叩き台として使うのが実用的です。AIの提案は列が多めに出る傾向があるため、削る前提で眺めるとちょうど良くなります。

3. プロパティ設計 ｜ 絞り込める・集計できる表にする

プロパティは種類が多く、最初は迷います。まず押さえるべきものを整理します。

プロジェクト管理データベースの列設計

プロジェクトのタスクを追う表を想定して、最小構成を考えてみます。必要なのは5つだけです。

1. タイトル：動詞で終わる形にする（「請求書テンプレートを改訂する」）
2. 担当者（ユーザー）：空欄を許さない。担当が決まらないタスクは着手できません
3. ステータス：未着手／進行中／レビュー中／完了の4段階
4. 期日（日付）：単日ではなく期間で入れると、後でタイムラインに載せられます
5. 優先度（セレクト）：高／中／低の3つ。5段階にすると誰も真ん中以外を選ばなくなります

この5列を守り、「6列目を足したくなったら、その列で何を判断するのか」を必ず自問します。判断に使わない列は、入力コストだけが増えます。工数管理まで踏み込むなら、ここに「見積時間」「実績時間」の数値プロパティを足し、数式で差分を出す構成が扱いやすくなります。

リレーションとロールアップで階層をつなぐ

Notionの真価が出るのはここからです。「プロジェクト」データベースと「タスク」データベースを別々に作り、タスク側にリレーションプロパティでプロジェクトを紐づけます。すると、プロジェクト側にロールアップを置くだけで、関連タスクの件数・完了数・合計工数を自動で表示できます。

この構造はWBS設計の考え方とそのまま重なります。大分類をプロジェクト、その下を成果物、さらに下をタスクとして3段にすることもできますが、段数を増やすほど表示が重くなります。最初は2段で運用し、足りないと分かってから増やすのが安全です。

4. ビューの使い分け ｜ 同じデータを人ごとの見え方に変える

ビューは何個作っても、元のデータはひとつです。ここを理解すると運用設計が一気に楽になります。

テーブルビュー：入力と棚卸しの拠点

全プロパティを横に並べて確認できるため、月次の棚卸しや一括入力に向きます。列の表示／非表示を切り替えられるので、「入力用テーブル」と「確認用テーブル」を2つ持っておくと、画面が散らかりません。

ボードビュー：流れの詰まりが目に見える

ステータスプロパティでグループ化すると、カードが列に並びます。10人規模のコンテンツ制作チームが「企画→執筆→レビュー→公開」の4列で運用する場面を想定すると、レビュー列にカードが溜まっている状態が一目で分かります。詰まっている工程が見えれば、進捗共有の会議で「誰が遅れているか」ではなく「どの工程が詰まっているか」を議題にできます。

カレンダーとタイムライン：日程を扱う

カレンダービューは日付プロパティを月次表示にします。締切が特定週に集中していることは、テーブルでは気づけません。タイムラインビューは開始日と終了日を横棒で表示し、簡易的なガントチャートになります。タイムラインビューは全プランで利用可能です（フリープランで2名以上が使う場合はブロック数制限に注意）。マイルストーンを1日の期間として登録し、色分けして並べると、節目と作業の関係が読み取れるようになります。より本格的な日程のタイムラインを引く場合も、まずはここから始めるのが現実的です。

絞り込み・並べ替え・グループ化

3つ揃えて初めて実用になります。よく使う設定は次の通りです。

• 担当者が自分の絞り込み：メンバー全員が同じビューで自分の担当だけを見られます
• ステータスが完了以外の絞り込み：終わったものを画面から消し、残作業だけを表示します
• 期日で昇順並べ替え：一番近い締切が常に最上部に来ます
• 担当者でグループ化：負荷の偏りが可視化され、工程管理の調整材料になります

5. 共有と権限管理 ｜ 誤操作と情報の散在を防ぐ

チームで使い始めると、必ず「誰かが列を消した」「ビューの絞り込みが勝手に変わっていた」という事故が起きます。防ぐ手段は2つです。

コンテンツ編集権限を使う

データベースには「コンテンツ編集権限」というレベルがあります。各ページの中身は編集できる一方で、プロパティの追加・削除やビューの変更はできないという設定です。運用の中心メンバー以外はこのレベルにしておくと、構造を守りながら入力してもらえます。

ビューをロックする

ビューのメニューから「ビューをロック」を選ぶと、絞り込みや並べ替えの設定が固定されます。共有用の「全社向けダッシュボード」は必ずロックし、個人の作業用ビューは自由にしておく、という切り分けが定着しやすい形です。

データソースとリンクドデータベース

ここは混同しやすい概念です。データソースが実体のデータ、データベースはそれを表示する枠、と捉えると整理できます。そして「リンクドデータベース」は、既存のデータソースを別の場所に呼び出して表示する機能です。

たとえば15人の運用チームを想定します。タスクは全社共通のひとつのデータソースに集約し、各部署のページには自部署分だけを絞り込んだリンクドデータベースを置く。すると、部署ごとに表を作り直す必要がなく、それでいて各部署は自分たちの画面だけを見られます。データが二重管理にならないので、ステークホルダーへの報告時に数字が食い違う事態も避けられます。

6. オートメーション ｜ 繰り返しの連絡と更新を手放す

データベースオートメーションは、「特定の条件が起きたら、決めた動作を実行する」仕組みです。設定できる範囲はプランによって異なるため、利用条件は公式サイトの最新情報を確認してください。

代表的なトリガーは、ページが追加されたとき、プロパティが特定の値に変わったとき、日付プロパティが到来したときの3つです。アクション側は、別プロパティの編集、ページの追加、Slack通知、メール送信などが選べます。

実際に効果が出やすい設定を挙げます。ステータスが「レビュー中」に変わったら、レビュー担当者をメンションしてSlackに通知する。これだけで「レビュー依頼のチャットを書く」という作業が消え、依頼漏れによる停滞もなくなります。もうひとつは、ステータスが「完了」になったら完了日プロパティに当日の日付を入れる設定です。人力では必ず入力漏れが起きる項目なので、自動化する価値が高い部分です。

7. すぐ真似できる3構成 ｜ プロジェクト・タスク・議事録

ゼロから設計せず、既存のテンプレートを複製して自分たちの言葉に直すほうが速く進みます。

プロジェクト管理データベース

列は「プロジェクト名／責任者／ステータス／開始日〜終了日／関連タスク（リレーション）／完了率（ロールアップ）」。5〜30人規模で、同時に3件以上のプロジェクトが動くチーム向けです。導入手順は、まず進行中の案件を全部1行ずつ入力し、次にタスクデータベースを作って紐づける、の2段階で進めます。

タスク追跡データベース

列は「タスク名／担当者／ステータス／優先度／期日／所属プロジェクト」。ビューは「自分の担当（絞り込み）」「今週締切（絞り込み）」「ボード（ステータス別）」の3つを用意します。個人でも使えるので、まず自分ひとりで1週間回してから、チームに展開すると抵抗が少なくなります。

議事録・ナレッジベース

列は「会議名／日付／参加者／決定事項／関連プロジェクト」。議事録の中で発生した宿題は、タスクデータベースへリレーションで飛ばします。議事録の文章の中にタスクが埋もれる問題が、これで解決します。

なお、この構造はプロジェクト管理以外にも応用できます。コンテンツ制作のカレンダー、社内マニュアルのナレッジベース、採用候補者の管理など、「同じ形式の情報が増え続けるもの」はすべてデータベース化の対象です。Notionのテンプレートを複製して始める場合も、まず列を削るところから手を付けると、自分たちに合う形になります。

8. 料金プラン ｜ 無料版はどこまで使えるのか

データベース機能そのものはフリープランでも使えます。制限がかかるのは主に共有・容量・履歴の部分です。

日本から契約する場合、料金は米ドル建てで請求されるため、実際の支払額はカード会社の為替レートと海外事務手数料が上乗せされます。1ドル150円前後で換算すると、1ユーザーあたりプラスで月1,500円前後、ビジネスで月3,000円前後が目安です。10人のチームなら、プラスで年間18万円前後の予算感になります。為替で上下する数字なので、稟議に出す際は「US$表示額×人数」を基準に、円換算は概算として添える形が安全です。

フリープランは、メンバーが2名以上になるとブロック数に制限がかかる点に注意が必要です。個人や2名程度で試す段階なら十分ですが、チーム全体で本格運用するならプラス以上が現実的な選択になります。年間プランなら最大20%お得になる設定も用意されています。エンタープライズは価格非公開で、要問い合わせです。

判断の目安はこうなります。ひとりで設計を試す段階はフリー、5〜20人で資料を添付しながら回すならプラス、部署をまたいで履歴やAI機能まで使うならビジネス。（Notionのフリープランはクレジットカードなしで始められるので、列設計を試す用途なら課金前に十分検証できます）

9. 規模が大きくなったら ｜ 他ツールとの併用を検討する

Notionは「ドキュメントとデータを同じ場所に置ける」点が最大の強みですが、人数が増えると別の課題が出ます。誰がいつ何を更新したかの追跡、複数プロジェクトを横断した負荷の可視化、細かい権限の出し分け。このあたりは専用のプロジェクト管理ツールのほうが素直に解決できます。

選び方は人数よりも「何が一番つらいか」で決まります。ドキュメントとタスクが別ツールに散らばっていることが最大の不満ならNotionで統合するのが正解です。一方、プロジェクトが複数並走していて全体の進み具合が誰にも見えていないなら、monday.comのようにダッシュボードで横断表示できるツールのほうが早く効きます。有料機能もプロプランの無料トライアルで試せるので（期間は公式サイトで確認）、実データを入れて比べてから決められます。開発チームでスプリントを回すならClickUpも選択肢に入ります。

なお、併用も十分あり得ます。仕様書・議事録・ナレッジはNotion、進捗の管理は専用ツール、という分担は多くのチームで機能します。その場合は、SMARTな目標設定で決めた指標をどちらのツールに置くかだけ、先に決めておいてください。指標の置き場所が二重になると、数字の食い違いが始まります。

まとめ

Notionデータベースを実務で回すために、押さえるべき点を整理します。

• 構成は3つだけ：ページ（1行＝1ページ）、プロパティ（属性）、ビュー（見せ方）。この関係が分かれば応用は効きます
• 列は5つから始める：タイトル・担当者・ステータス・期日・優先度。判断に使わない列は足さない
• ビューは目的別に分ける：入力はテーブル、進行確認はボード、日程はカレンダーとタイムライン
• 構造を守る仕組みを入れる：コンテンツ編集権限とビューのロックで、誤操作による崩壊を防ぐ
• 重くなる前に手を打つ：リレーションは2段まで、ビューには必ず絞り込みをかける

次の一手は具体的です。この記事の第3章に挙げた5列だけのタスクデータベースを、今抱えている案件で1つ作ってください。既存のExcel管理表があるなら、その列をそのままプロパティに置き換え、不要な列をこの機会に捨てます。そのうえでボードビューを1つ追加すれば、今日から進捗が見える状態になります。テンプレートから複製すれば列の設計を考える時間も省けるので、まずは動くものを作ってから調整するのが最短ルートです。

よくある質問

Notionのデータベースとは何ですか？

性質の同じページをひとつにまとめた集合体です。各ページにプロパティ（ステータス、担当者、期日など）を付けることで絞り込みや並べ替えができ、同じデータをテーブル・ボード・カレンダーなど複数のビューで表示できます。普通のページとの違いは、情報が増えるほど整理しやすくなる点にあります。

NotionでDatabaseを作るにはどうすればいいですか？

ページ本文で /database と入力し、「インライン」か「フルページ」を選ぶだけで作成できます。その後、右端の「＋」からプロパティを追加し、左上からビューを追加します。作業自体は数分ですが、置き場所とタイトル列の命名ルールを先に決めておくと、後の管理が大きく楽になります。

Notionのデータベースが重いのはなぜですか？

主な原因は4つです。数式プロパティが多すぎる、リレーションとロールアップの階層が深い、ギャラリービューに大きな画像を大量に載せている、1つのビューに全件を絞り込みなしで表示している。対策としては、ビューに必ず絞り込みをかけて表示件数を減らす、完了案件をアーカイブ用データベースへ移す、ロールアップの段数を2段までに抑える、この3つが効果的です。

無料版のNotionでもデータベースは使えますか？

使えます。データベース機能そのものに制限はなく、タイムラインビューも全プランで利用可能です。ただしファイルアップロードは最大5MB、ページ履歴は7日、外部ゲストは10名、チャート作成は1件までという制限があり、メンバーが2名以上の場合はブロック数にも制限がかかります。

データベースと普通のページは何が違いますか？

普通のページは書いた内容がその場に残るだけですが、データベースは各ページに属性が付き、後から絞り込み・並べ替え・集計ができます。10件程度なら差は出ませんが、100件を超えたあたりから探す時間に決定的な差が生まれます。繰り返し発生する種類の情報は、最初からデータベースにしておくのが得策です。

インラインとフルページはどう選べばいいですか？

そのデータだけで完結し、サイドバーから直接開きたいものはフルページ。運用ルールや説明文と一緒に見せたいものはインラインです。プロジェクト憲章の中に置く課題一覧のように、文脈とセットで読ませたい表はインラインが自然です。迷ったらインラインで作り、単独で使う頻度が高くなったらフルページに切り出す運用でも問題ありません。

Notionをやめてしまう人がいるのはなぜですか？

多くは「作り込みすぎて運用が続かない」ことが原因です。プロパティを増やしすぎて入力が負担になる、データベースが増えすぎてどこに何があるか分からなくなる、といったパターンが典型的です。対策は、列を5つに絞る、データベースの新規作成は責任者の承認制にする、四半期ごとに使われていないビューを削除する。この3つを最初のルールにしておくと、破綻しにくくなります。