Notionデータベースの作り方｜業務で使えるプロパティ・ビュー設計

Notionデータベースを作る操作は、難しくありません。

新しいページを作り、テーブルを選ぶ。列を追加し、プロパティの種類を選ぶ。ボード、カレンダー、ギャラリー、タイムラインなどのビューを追加する。フィルターや並べ替えを設定する。

Notion公式ヘルプにも、データベースの作成手順、プロパティ、ビュー、フィルター、並べ替えの基本がまとまっています。

Notion公式ヘルプ：データベースの作成

ただし、実務で問題になるのは「Notionで表を作れるか」ではありません。

問題になるのは、次のような状態です。

• 1行に案件、タスク、メモ、会議内容が混ざっている
• 列を増やしすぎて、誰も入力しなくなる
• ステータス、タグ、優先度の使い分けが曖昧
• 同じ内容のDBが複数でき、どれが正しいか分からない
• 担当者別、確認待ち、期限超過などのビューがない
• 外部共有ページに、社内用プロパティまで見えてしまう
• Notion AIで作ったDBを、そのまま正式運用にしてしまう
• 数が増えた時に重くなり、Excelやkintoneへ移す判断が遅れる

Notionデータベースは、表ではなく、小さな業務システムとして設計する と考える方が安定します。

この記事では、Notionデータベースの作り方を、操作手順だけでなく、1行の意味、プロパティ、ビュー、権限、レビュー運用、Excelやkintoneへ分ける判断まで含めて整理します。

先に結論：作る前に1行の意味を決める

Notionデータベースで最初に決めるべきなのは、プロパティではありません。

最初に決めるべきなのは、1行が何を表すかです。

作りたいもの	1行の意味	よくない混ぜ方
案件管理	1行 = 1案件	案件行の中にタスクや議事録を直接書く
タスク管理	1行 = 1タスク	1行に複数人分の作業をまとめる
議事録	1行 = 1会議	会議ごとのページにタスクを埋めたままにする
日報	1行 = 1人の1日分	週報、相談、タスクを同じ行に混ぜる
ナレッジ	1行 = 1手順、1FAQ、1ルール	雑多なメモ置き場にする
顧客管理	1行 = 1社または1担当者	顧客、商談、請求を同じDBにする

1行の意味が決まると、プロパティも自然に決まります。

たとえば、タスクDBなら担当者、期限、ステータス、確認者、完了条件が必要です。

議事録DBなら会議日、参加者、関連プロジェクト、決定事項、対応事項候補が必要です。

逆に、1行の意味が曖昧なままプロパティを増やすと、DBはすぐに壊れます。

曖昧なDB	起きること
「プロジェクト・タスク管理DB」	案件行とタスク行が混ざり、担当者別ビューが作れない
「メモDB」	議事録、ナレッジ、アイデアが混ざり、検索頼みになる
「顧客・商談DB」	会社情報と商談進捗が混ざり、履歴が追いにくい
「日報・週報DB」	日次入力と週次レビューが混ざり、集計しにくい

Notionデータベースは、先に行の単位を決める。

その後にプロパティ、ビュー、権限、運用を決める。

この順番を守るだけで、かなり崩れにくくなります。

シンプルテーブルとDBの違い

Notionには、表のように情報を並べる方法が複数あります。

簡単な表で十分なものもあれば、データベースにした方がよいものもあります。

使い方	向いている場面	注意点
シンプルな表	比較表、料金表、チェックリスト、単発の整理	フィルター、ビュー、リレーションには向かない
データベース	案件、タスク、議事録、日報、ナレッジなど継続管理する情報	1行の意味とプロパティ設計が必要
リンクドビュー	同じDBを別ページやダッシュボードで見せる	元DBの権限と編集影響に注意
外部ツール	請求、契約、承認、顧客マスタ、厳密な履歴管理	Notionを入口や説明ページに留める

Notion公式ヘルプでは、データベースの各アイテムは独自のNotionページとして開け、プロパティや中身のコンテンツを編集できると説明されています。

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

この特徴が、Notionデータベースの強みです。

1行が単なる表の行ではなく、1つのページになる。

そのため、タスクの詳細、議事録本文、案件の背景、ナレッジの手順などを行の中に持てます。

一方で、何でもページに書けるため、情報が散らばりやすいのもNotionの弱点です。

DBにすべきか迷ったら、次の基準で判断します。

質問	DBにするべきか
同じ種類の情報が10件以上増えそうか	増えるならDB向き
担当者、期限、状態などで絞り込みたいか	絞り込みたいならDB向き
ボード、カレンダー、一覧など複数の見方が必要か	必要ならDB向き
他のDBとリレーションしたいか	つなぎたいならDB向き
1回だけ整理できればよいか	それならシンプルな表でよい

DBにする業務としない業務

Notionデータベースは便利ですが、すべての業務をNotionでDB化する必要はありません。

Notionに向いているのは、文書、タスク、会議、軽い管理が近い業務です。

Notion DBに向く	理由
案件管理	概要、タスク、議事録、資料を近くに置ける
タスク管理	担当者、期限、ステータス、確認待ちで見られる
議事録	会議本文と対応事項を同じページで扱える
日報	入力、確認、週報化、困りごとの抽出がしやすい
ナレッジ	手順、FAQ、社内ルールをタグや部署で整理できる
採用候補者の軽い管理	面談メモ、状態、担当者を一覧化できる

プロジェクト管理で使うDBの分け方は、別記事で詳しく整理しています。

Notionプロジェクト管理の作り方

一方で、次の業務はNotionだけで完結させない方がよいです。

分けた方がよい業務	理由
請求、入金、会計	正式な帳簿、証憑、権限、監査が必要
契約管理	承認履歴、版管理、締結状況の正確性が必要
顧客マスタ	重複排除、外部連携、権限、変更履歴が重要
厳密な承認フロー	誰がいつ承認したかの履歴が必要
大量の外部ユーザー入力	フォーム、ポータル、CRMの方が安全
複雑な工程管理	Jira、Backlog、Asana、kintoneなどが向く場合がある

Notionは、業務の形を早く作り、チームで試すには強いです。

ただし、正式な台帳、会計、契約、承認、個人情報、監査ログまでNotionに寄せすぎると危険です。

Notionで始める業務と、最初から別システムに分ける業務を決めることもDB設計の一部 です。

最小プロパティの設計

Notionデータベースを作る時は、最初からプロパティを増やしすぎない方がよいです。

おすすめは、最小セットから始めることです。

案件DB

プロパティ	型	目的
案件名	タイトル	1案件を識別する
状態	ステータス	未着手、進行中、確認待ち、保留、完了を分ける
責任者	ユーザー	最終責任者を決める
期限	日付	放置と遅れを見つける
関連タスク	リレーション	タスクDBとつなぐ
関連議事録	リレーション	会議の文脈とつなぐ
次回確認日	日付	レビュー対象を拾う

タスクDB

プロパティ	型	目的
タスク名	タイトル	作業内容を具体的に書く
関連案件	リレーション	どの案件の作業か分ける
担当者	ユーザー	実行責任を持つ人
確認者	ユーザー	完了判定する人
期限	日付	遅れを見つける
ステータス	ステータス	未着手、進行中、確認待ち、保留、完了を分ける
完了条件	テキスト	何をもって終わりか決める

議事録DB

プロパティ	型	目的
会議名	タイトル	会議を識別する
会議日	日付	時系列で探す
関連案件	リレーション	案件と紐づける
参加者	ユーザー	誰が参加したか残す
決定事項あり	チェックボックス	後から判断を拾う
対応事項あり	チェックボックス	タスク化漏れを拾う
確認状態	ステータス	下書き、確認待ち、確定を分ける

プロパティ設計で大事なのは、入力しやすさとレビューしやすさの両方です。

入力する人にとっては、項目が少ない方がよいです。

見る人にとっては、担当者、期限、状態、確認者、次回確認日がないと判断できません。

最初は「毎日入力する項目」と「会議で見る項目」だけに絞ります。

テーブル・ボード・カレンダー・ギャラリーの使い分け

Notionデータベースは、同じデータを複数のビューで表示できます。

Jicooの記事でも、テーブル、ボード、タイムライン、カレンダー、リスト、ギャラリー、チャート、ダッシュボードなど、用途別のビューが整理されています。

Jicoo：Notionデータベースの使い方

ただし、ビューは増やせばよいわけではありません。

ビューは、見る人と目的で決めます。

ビュー	向いている用途	業務での使い方
テーブル	入力、一覧確認、項目の整備	管理者がDBを整える
ボード	ステータス別の進捗確認	タスクを未着手、進行中、確認待ちで見る
カレンダー	日付で見る情報	期限、会議日、公開日を見る
タイムライン	期間と工程を見る	案件、制作、開発の大まかな工程を見る
リスト	シンプルに読む情報	議事録、ナレッジ、FAQを見る
ギャラリー	画像や資料を見せる情報	デザイン案、資料、ポートフォリオを見る

おすすめは、最初にテーブルビューを作り、必要に応じてボード、カレンダー、リストを足すことです。

業務	最初に作るビュー
タスク管理	テーブル、自分のタスク、確認待ち、期限超過
案件管理	テーブル、進行中ボード、期限順、週次レビュー
議事録	リスト、会議日順、未確認、関連案件別
日報	カレンダー、未確認、部署別、困りごと
ナレッジ	リスト、カテゴリ別、更新待ち

ビューは見た目の切り替えではなく、誰が何を判断するかを分けるために作る と考えると、Notion DBは業務に合いやすくなります。

フィルターと並べ替え

Notionデータベースを業務で使うなら、フィルターと並べ替えは必須です。

全件表示のテーブルだけでは、使う人が毎回探すことになります。

公式ヘルプでも、プロパティによるフィルターや並べ替えを使って、条件に合うページを表示できると説明されています。

Notion公式ヘルプ：データの絞り込みと並べ替え

最初に作るべきフィルターは、次のようなものです。

ビュー名	フィルター	並べ替え
自分の未完了	担当者が自分、ステータスが完了以外	期限が近い順
期限超過	期限が今日より前、ステータスが完了以外	期限が古い順
確認待ち	ステータスが確認待ち	確認者、期限順
今週の会議	会議日が今週	会議日が近い順
未確認議事録	確認状態が確認待ち	会議日が新しい順
更新待ちナレッジ	最終更新日が一定期間前	最終更新日が古い順

フィルターは、業務の滞留を見つけるために使います。

見たい情報を探すためではなく、見落とすと困る情報を自動で前に出すために使います。

権限とビュー編集の注意

Notionデータベースは、共有しやすい反面、見せすぎの事故も起きやすいです。

特に、リンクドビューやダッシュボードにDBを置く場合は、元DBの権限を確認します。

共有先	見せてよいもの	見せない方がよいもの
全メンバー	自分のタスク、共通ナレッジ、公開議事録	人事、評価、原価、契約
マネージャー	期限超過、確認待ち、未確認日報	不要な個人メモ
外部パートナー	共有対象案件、確認依頼、公開ナレッジ	社内議事録、社内日報、原価
顧客	進捗概要、提出物、確認依頼	内部コメント、他社案件、作業メモ

ビューの編集権限も決めておきます。

誰でもビューを追加、削除、フィルター変更できる状態にすると、チームで見る基準が崩れます。

権限	任せる人
DB構造の変更	管理者、業務責任者
ビューの追加と削除	管理者、チームリーダー
行の追加と更新	担当者、確認者
外部共有	責任者のみ

Notionは柔軟なので、現場がすぐ直せます。

その柔軟さは強みですが、業務DBでは「誰が構造を変えてよいか」を決めないと、同じDBがすぐに別物になります。

運用が崩れる失敗例

Notionデータベースは、作った直後より、1か月後に差が出ます。

よくある失敗は次の通りです。

失敗	原因	直し方
入力されない	プロパティが多すぎる	必須項目を減らし、会議で見る項目だけ残す
ステータスが古い	更新タイミングがない	朝会や週次レビューで更新する
同じDBが増える	複製で始めすぎる	元DBを1つにし、リンクドビューで見せる
タスクが消える	議事録本文に埋もれる	対応事項をタスクDBへ切り出す
確認待ちが止まる	確認者ビューがない	確認待ちビューを責任者が見る
外部共有が怖い	社内用と外部用が混ざる	共有専用ビューや専用DBを分ける
重くなる	全件、画像、ギャラリーを載せすぎる	表示件数、プロパティ、ビュー数を絞る

運用を保つには、DBごとに次の4点を決めます。

決めること	例
入力する人	担当者、議事録担当、上長
確認する人	確認者、責任者、管理者
見るタイミング	毎朝、会議直後、週次レビュー
消す基準	使われないビュー、重複プロパティ、古いテンプレート

Notion AIを使う場合も、同じです。

Notion公式ヘルプでは、Notion AIで新しいデータベースを作成できる一方、既存DBの編集やDBテンプレート作成などには制約があると説明されています。

Notion公式ヘルプ：Notion AIでデータベースを作成する

AIは、DBのたたき台やプロパティ案を出すには便利です。

ただし、正式なプロパティ、権限、入力ルール、外部共有範囲は人が確認します。

kintoneやExcelへ移す判断

Notionデータベースは、業務の形を早く作るには向いています。

しかし、すべてのDBをNotionに残す必要はありません。

次の状態になったら、Excel、Googleスプレッドシート、kintone、CRM、プロジェクト管理ツールへの分離を検討します。

状態	移行先の候補
数式や集計が複雑になり、表計算が中心になった	Excel、Googleスプレッドシート
承認、通知、権限、履歴管理が重要になった	kintone
顧客、商談、メール履歴とつなぎたい	CRM
開発タスク、障害、リリース管理が中心になった	Jira、Backlog、GitHub Issues
顧客や外部ユーザーが入力する	フォーム、ポータル、専用Webアプリ
請求、契約、会計に関わる	freee、クラウドサイン、基幹システム

Notionは、業務DBの設計を試す場所としては強いです。

1行の意味、プロパティ、ビュー、確認フローをNotionで固める。

その後、正式な権限、履歴、外部入力、集計が必要になった部分だけを専用ツールへ移す。

この順番なら、最初から重いシステムを作るより速く、現場の理解も揃いやすいです。

まとめ

Notionデータベースは、テーブルを作って列を増やすだけならすぐに始められます。

しかし、業務で使うなら、最初に1行の意味を決めます。

案件DBなら1行は1案件。タスクDBなら1行は1タスク。議事録DBなら1行は1会議。ここが曖昧だと、プロパティやビューを増やしても運用は崩れます。

次に、最小プロパティを決めます。担当者、期限、状態、確認者、関連DB、次回確認日など、会議や日次作業で本当に見る項目だけに絞ります。

ビューは、テーブル、ボード、カレンダー、リスト、ギャラリーを見た目で選ぶのではなく、誰が何を判断するかで分けます。

そして、権限、更新責任、レビュータイミング、外部ツールへ分ける基準まで決めます。

Notionデータベースは、表ではありません。

案件、タスク、議事録、日報、ナレッジを小さな業務システムとして動かすための設計単位です。