Notionデータベース結合の考え方｜リレーション・ロールアップ・リンクドビューの使い分け

Notionで「データベースを結合したい」と思う場面はよくあります。

たとえば、次のような相談です。

• 部署ごとに分かれたタスクDBを1つにしたい
• 案件DBとタスクDBをまとめて一覧で見たい
• 議事録から生まれたタスクを、タスクDBに反映したい
• 顧客DB、案件DB、請求DBをつないで見たい
• 複数DBの数字をまとめて集計したい
• 別々に作ってしまったNotionテンプレートを統合したい

ただし、NotionにはSQLのJOINのように、複数テーブルを条件で結合して1つの仮想表にする機能がある、と考えると設計を間違えます。

Notion公式ヘルプでは、リレーションを使うと複数のデータベースからアイテムを関連付けられ、ロールアップで関連先の情報を表示・集計できると説明されています。

Notion公式ヘルプ：リレーションとロールアップ

また、複数のデータソースをまとめて表示したい場合は、リンクドデータベースやリンクドビューの考え方も関係します。

NorthSand：複数のデータベースを1つのリンクドデータベースにまとめる

NotionAppsの記事でも、NotionでDBを組み合わせる方法として、リレーション、ロールアップ、リンクドデータベース、タグ、数式、CSVエクスポートなど複数の選択肢が整理されています。

NotionApps：How to Combine Databases in Notion

つまり、重要なのは「結合する方法」ではありません。

重要なのは、結合したい理由を業務構造から分解することです。

Notionデータベース結合は、表を無理に1つにする作業ではなく、同じDBにすべき情報、リレーションでつなぐ情報、見るだけでよい情報、外部DBへ出す情報を分ける設計 として考える方が安定します。

この記事では、Notionデータベース結合の考え方を、同じDBにすべきケース、リレーションでつなぐケース、ロールアップで集計するケース、リンクドビューで並べるケース、CSV・Sheets・kintoneへ移すケース、プロパティ不一致、結合で壊れる失敗例まで整理します。

先に結論：結合より設計判断が重要

Notionでデータベースを結合したい時は、最初に次の表で判断します。

やりたいこと	選ぶ方法	例
同じ種類のレコードをまとめたい	同じDBに統合する	部署別タスクDBを全社タスクDBにする
別種類のレコードをつなぎたい	リレーション	案件DBとタスクDBをつなぐ
関連先の件数や日付を見たい	ロールアップ	案件ごとの未完了タスク数を出す
1つの画面で並べて見たい	リンクドビュー	会議ページにタスクDBと議事録DBを並べる
集計や同期が重い	Sheets、kintone、DBへ移す	売上集計、請求、厳密なマスタ管理
過去データを一時的にまとめたい	CSVエクスポート・インポート	テンプレート移行、重複整理

「結合」と一言で言っても、実際には目的が違います。

検索者の言う結合	実際に必要なこと
2つのタスク表を結合したい	同じタスクDBに統合する
案件とタスクを結合したい	案件DBとタスクDBをリレーションでつなぐ
顧客ごとの売上を見たい	顧客DBと売上DBをつなぎ、ロールアップする
会議ページで全部見たい	複数のリンクドビューを並べる
Excelのように表を結合したい	NotionではなくSheetsやDBを使う

結合前に見るべきポイントは、レコードの意味です。

1行が同じ意味なら、同じDBにまとめます。

1行の意味が違うなら、DBは分けてリレーションでつなぎます。

見る場所を1つにしたいだけなら、リンクドビューで十分です。

集計や同期が主目的なら、Notionの外に出す判断も必要です。

同じDBにすべきケース

まず、本当に同じDBに統合すべきケースです。

これは、複数のDBの1行が同じ意味を持つ場合です。

分かれているDB	統合先	判断
営業部タスクDB、制作部タスクDB	全社タスクDB	同じタスクなので統合しやすい
A案件の議事録DB、B案件の議事録DB	議事録DB	会議記録として同じ単位なら統合
部署別の日報DB	日報DB	入力項目が同じなら統合
テンプレートごとに分かれた問い合わせDB	問い合わせDB	受付項目を揃えれば統合できる

同じDBにする時は、プロパティを揃えます。

必要なプロパティ	役割
種別	タスク、議事録、問い合わせなどの分類
部署	どの部署のレコードか
関連プロジェクト	案件やプロジェクトとの接続
担当者	誰が処理するか
状態	未着手、進行中、確認待ち、完了
期限	いつまでに処理するか
作成日・更新日	履歴確認

部署別DBを統合する場合は、「部署」をプロパティにします。

案件別DBを統合する場合は、「関連プロジェクト」をリレーションにします。

テンプレート別DBを統合する場合は、「種別」をプロパティにします。

統合してよいか迷ったら、次の質問をします。

質問	Yesなら
1行の意味は同じか	同じDB候補
必須項目はほぼ同じか	同じDB候補
同じステータスで管理できるか	同じDB候補
同じレビュー会議で見るか	同じDB候補

逆に、1行の意味が違うものを同じDBにすると壊れます。

たとえば、案件とタスクを同じDBに入れると、「案件の期限」と「タスクの期限」が混ざります。

議事録とタスクを同じDBに入れると、「会議日」と「作業期限」が混ざります。

同じDBにするのは、1行の意味が同じ時だけです。

リレーションでつなぐケース

別種類のデータをつなぎたい場合は、DBを結合するのではなく、リレーションを使います。

リレーションは、DB同士の業務関係を表すプロパティです。

Notionリレーションの使い方

よくある設計は次の通りです。

接続元DB	リレーション先DB	目的
タスクDB	プロジェクトDB	タスクがどの案件に属するか分かる
議事録DB	プロジェクトDB	案件ごとの会議履歴を追える
タスクDB	議事録DB	どの会議から生まれたタスクか分かる
案件DB	顧客DB	顧客ごとの案件を見られる
請求DB	顧客DB	顧客ごとの請求履歴を見られる

リレーションを使うべきなのは、1行の意味が違う場合です。

まとめたいもの	同じDBにしない理由	使う方法
案件とタスク	案件は仕事の単位、タスクは作業の単位	リレーション
顧客と案件	顧客は取引先、案件は活動単位	リレーション
議事録とタスク	議事録は記録、タスクは実行項目	リレーション
メンバーと日報	メンバーは人、日報は記録	リレーションまたはユーザープロパティ

リレーション設計で大事なのは、入力負担です。

すべてのDBを相互に関連付けると、入力者は毎回たくさんの関連ページを選ぶことになります。

増やしすぎたリレーション	起きる問題
タスクに顧客、案件、議事録、契約、見積、請求を全部つける	入力が重くなる
議事録に全参加者、全案件、全タスクを手入力する	更新されなくなる
顧客DBに社内メモや請求まで直結する	権限管理が難しくなる

リレーションは、会議やレビューで実際に見る関係だけに絞ります。

ロールアップで集計するケース

リレーションでつないだ後に、関連先の件数、日付、金額、状態を見たい場合はロールアップを使います。

ロールアップは、関連DBの情報を集計・表示する機能です。

Notionロールアップの使い方

たとえば、プロジェクトDBでタスクDBの状況を見たい場合です。

プロジェクトDBで見たい項目	元になるDB	ロールアップ
関連タスク数	タスクDB	件数
未完了タスク数	タスクDB	状態が完了以外の件数
期限超過数	タスクDB	期限が過去、状態が完了以外
最終議事録日	議事録DB	会議日の最大値
最新更新日	タスクDB	更新日の最大値

ロールアップを使う時は、数字の使い道を決めます。

数字	判断
未完了タスク数	まだ作業が残っているか
期限超過数	マネージャーが介入すべきか
最終議事録日	会議や確認が止まっていないか
確認待ち件数	レビューが詰まっていないか
見積合計	案件規模を見積もれるか

ロールアップは、結合表の代わりにはなりません。

あくまで、関連先の値を親DBに持ってくる仕組みです。

細かい集計、複雑な条件、時系列分析、売上集計をNotion内だけでやろうとすると、重くなりやすいです。

会議で見る数値ならNotion。

会計、請求、売上分析、厳密な集計なら外部ツール。

この線引きが必要です。

リンクドビューで並べるケース

「結合したい」と言いながら、実際には1つのページで並べて見たいだけの場合があります。

この場合は、DBを統合しなくてもリンクドビューで足ります。

Notionリンクドデータベースの使い方

Notionリンクドビューの使い方

たとえば、プロジェクトページに次のビューを置きます。

ページ	置くリンクドビュー	フィルター
プロジェクトページ	この案件のタスク	関連プロジェクトがこの案件
プロジェクトページ	この案件の議事録	関連プロジェクトがこの案件
プロジェクトページ	この案件の決定事項	関連プロジェクトがこの案件
顧客ページ	この顧客の案件	関連顧客がこの顧客
顧客ページ	この顧客の未完了対応	関連顧客がこの顧客、状態が完了以外

この方法なら、DBの構造は分けたまま、見る場所だけを1つにできます。

リンクドビューで十分なケースは次の通りです。

状況	理由
DBの1行の意味が違う	無理に統合しない方がよい
同じ画面で確認したいだけ	ビューを並べればよい
元DBを別部署が管理している	所有者を分けたまま見せられる
会議用の画面を作りたい	会議に必要なビューだけ置ける

リンクドビューで注意すべきなのは、権限です。

リンクドビューを置いたページを共有しても、元DBの権限がなければ見えないことがあります。

逆に、元DBが見える人には、リンクドビュー上の編集が元DBに反映されます。

見るだけの画面なのか、編集してよい画面なのかを分けます。

CSV・Sheets・kintoneへ移すケース

Notionで結合や集計をしようとして、限界が見えるケースもあります。

次のような場合は、Notionだけで頑張らない方がよいです。

状況	Notionで起きる問題	移し先
売上・請求・入金を厳密に管理したい	権限、集計、監査が弱い	freee、kintone、会計システム
大量データを集計したい	ページ表示や集計が重くなる	Sheets、DB、BI
複数システムと同期したい	手動更新や重複が増える	kintone、RDB、iPaaS
マスタ管理が必要	表記揺れや重複が残る	kintone、CRM
複雑な条件で抽出したい	Notionのビュー条件だけでは足りない	Sheets、SQL、BI

Notionは、業務の入口としては強いです。

議事録、タスク、案件メモ、レビュー画面、ナレッジには向いています。

一方で、厳密な台帳、会計、請求、在庫、承認フロー、監査証跡には限界があります。

Notionで結合できるかではなく、Notionで持つべき情報かどうかを先に決める ことが重要です。

Notionに置くべき情報は、チームが毎日見て更新する業務情報です。

外に出すべき情報は、正確性、履歴、権限、集計、連携が重い業務データです。

プロパティ不一致の扱い

複数DBを統合する時に一番困るのは、プロパティ不一致です。

たとえば、部署ごとにタスクDBが分かれているとします。

営業タスクDB	制作タスクDB
顧客名	案件名
担当営業	担当者
提案期限	納品期限
フェーズ	ステータス
商談メモ	作業メモ

このまま結合すると、似た意味の項目が増えます。

ありがちな失敗	起きること
顧客名と案件名を別列で残す	入力者がどちらを使うか迷う
フェーズとステータスを両方残す	ビュー条件が複雑になる
期限列を複数残す	どれが正式期限か分からない
担当営業と担当者を両方残す	担当者別ビューが壊れる

統合前に、プロパティ対応表を作ります。

統合後のプロパティ	旧DBの列	方針
関連顧客	顧客名	顧客DBへのリレーションにする
関連プロジェクト	案件名	プロジェクトDBへのリレーションにする
担当者	担当営業、担当者	ユーザープロパティに統一
期限	提案期限、納品期限	タスクの期限として統一
状態	フェーズ、ステータス	ステータス値を整理
メモ	商談メモ、作業メモ	本文またはテキストに寄せる

統合後のDBでは、まずビューを少なくします。

最初に作るビュー	目的
すべて	管理者確認用
自分の未完了	作業者用
期限切れ	管理者用
確認待ち	レビュー用
入力不備	移行漏れ確認用

いきなり部署別、担当者別、顧客別、案件別を大量に作ると、移行直後に崩れます。

最初は、入力不備を見つけるビューを作る方が大事です。

結合で壊れる失敗例

Notionのデータベース結合でよくある失敗は、次の通りです。

失敗	起きること	対策
1行の意味が違うDBを統合する	プロパティが増えすぎる	DBを分けてリレーションにする
同じ意味の列を複数残す	ビュー条件が壊れる	プロパティ対応表を作る
全部をリレーションでつなぐ	入力が重くなる	会議で見る関係だけ残す
ロールアップを増やしすぎる	DBが読みにくくなる	判断に使う数字だけ残す
リンクドビューで全件表示する	ページが重くなる	フィルターを必ず入れる
外部共有ページに社内DBを置く	情報漏洩リスクが出る	共有専用DBまたは表示列を分ける
Notionで厳密な台帳を作る	集計・権限・監査が弱い	kintoneや会計システムへ移す

特に危険なのは、「一覧で見たいから全部1つにする」です。

一覧で見たいだけなら、リンクドビューで見ればよいです。

同じ意味のデータをまとめたいなら、同じDBにします。

別種類のデータをつなぎたいなら、リレーションにします。

数値を親DBで見たいなら、ロールアップにします。

集計や同期が重いなら、Notionの外に出します。

この判断を先にしないと、結合後に次の問題が出ます。

• どの列に入力すればよいか分からない
• 似たビューが増えすぎる
• 関連ページを選ぶのが面倒で更新されない
• 会議で見る数字が信用されない
• 外部共有時に見せてはいけない列が出る
• 結局ExcelやSheetsに戻る

まとめ

Notionデータベース結合は、表を無理に1つにする作業ではありません。

まず、結合したい理由を分解します。

同じ種類のレコードをまとめたいなら、同じDBに統合します。

別種類のレコードをつなぎたいなら、リレーションを使います。

関連先の件数や日付を見たいなら、ロールアップを使います。

同じ画面で並べて見たいだけなら、リンクドビューを使います。

厳密な集計、同期、台帳管理が必要なら、Sheets、kintone、会計システム、DBへ移します。

Notionで大事なのは、できるだけ多くの情報を1つに集めることではありません。

1行の意味、入力者、確認者、会議での使い道、権限、外部連携を揃えることです。

結合前に、同じDBにするもの、リレーションでつなぐもの、リンクドビューで見るだけのもの、外に出すものを分けます。

この判断ができると、Notionは散らかったメモやテンプレートの集合ではなく、業務情報を迷子にしない小さなシステムになります。