Notionリレーションの使い方｜DB同士をつないで業務情報を迷子にしない設計

Notionのリレーションは、複数のデータベースをつなげるためのプロパティです。

たとえば、プロジェクトDBとタスクDBをつなげると、各タスクがどのプロジェクトに属するかを見られます。議事録DBと顧客DBをつなげると、顧客ごとの会議履歴を追えます。

Notion公式ヘルプでも、リレーションを使うと複数のデータベースからアイテムを関連付けられ、顧客管理、購入アイテム、議事録、タスク、プロジェクトなどをつなげられると説明されています。

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

ただし、実務で問題になるのは「リレーションを設定できるか」ではありません。

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

• DBを分ける前にリレーションを増やしてしまう
• 案件、タスク、議事録、顧客、日報がどこでつながるべきか決まっていない
• 双方向リレーションでプロパティが増え、画面が読みにくくなる
• ロールアップで数字は出るが、何を判断する数字か分からない
• 関連ページを選ぶ手入力が重く、誰も更新しなくなる
• 社外共有ページに、社内DBへのリレーションが見えてしまう
• 自己参照リレーションや依存関係を使いすぎて、構造が理解できなくなる

Notionリレーションは、DB同士をなんとなくつなぐ機能ではなく、業務上の関係を表す設計 として扱う方が安定します。

この記事では、Notionリレーションの使い方を、設定手順だけでなく、どのDBを分けるべきか、双方向表示、ロールアップ、プロジェクト・タスク・議事録の設計例、自己参照、増やしすぎの失敗まで含めて整理します。

リレーションはDB同士の業務関係を表す

Notionリレーションは、別々のDBを関連付けるプロパティです。

ただし、単に「リンクを貼る機能」と考えると設計を間違えます。

リレーションは、業務上の関係をDBに表すために使います。

関係	リレーション例	見たいこと
プロジェクトとタスク	タスクDB → プロジェクトDB	このタスクはどの案件の作業か
プロジェクトと議事録	議事録DB → プロジェクトDB	この案件でどんな会議があったか
顧客と案件	案件DB → 顧客DB	この顧客にどの案件があるか
議事録とタスク	タスクDB → 議事録DB	このタスクはどの会議から生まれたか
ナレッジと問い合わせ	問い合わせDB → ナレッジDB	どの手順を案内したか
親タスクと子タスク	タスクDB → タスクDB	どのタスクの下位作業か

リレーションを考える前に、まずDBを分けます。

DBの1行の意味が曖昧だと、リレーションも曖昧になります。

Notionデータベースの作り方

たとえば「プロジェクト・タスク管理DB」のように、案件行とタスク行が同じDBに混ざっていると、リレーション以前に管理単位が崩れます。

プロジェクトはプロジェクトDB、タスクはタスクDB、議事録は議事録DBに分けます。

そのうえで、必要な関係だけをリレーションにします。

リレーションを使うべきケース

Notionリレーションは便利ですが、すべてをリレーションにする必要はありません。

使うべきなのは、次の条件を満たすときです。

条件	例
同じ情報を複数ページで参照したい	プロジェクトから関連タスクを見る
集計したい	プロジェクトごとの完了タスク数を出す
履歴を残したい	顧客ごとの議事録を残す
発生元を追いたい	会議から生まれたタスクを追う
ビューで絞りたい	顧客別、案件別、会議別に表示する

逆に、リレーションにしない方がよいものもあります。

リレーションにしない方がよい	理由
一度しか参照しない情報	テキストで十分
選択肢が固定で少ない分類	セレクトやマルチセレクトでよい
入力者が毎回探すのに時間がかかるもの	更新されなくなる
権限が違う社内外情報	外部共有事故につながる
厳密なマスタ管理が必要な情報	kintoneやCRMに分けた方がよい場合がある

リレーションは、データを整えるためのものです。

入力者の負担を増やしてまで作るものではありません。

リレーションは「つなげられるから作る」のではなく、「つながっていないと業務判断できない時」に作る のが基本です。

設定手順

Notionでリレーションを設定する流れは、公式ヘルプやTEMPの記事でも整理されています。

TEMP：Notionのリレーション・ロールアップとは？

手順は大きく次の通りです。

手順	やること
1	関連付けたいDBを2つ用意する
2	片方のDBでプロパティを追加する
3	プロパティ種別でリレーションを選ぶ
4	接続先のDBを選ぶ
5	双方向表示にするか決める
6	リレーション名を業務用語に変える
7	必要なら表示プロパティを絞る

たとえば、タスクDBからプロジェクトDBを参照するなら、タスクDBに「関連プロジェクト」というリレーションプロパティを作ります。

DB	プロパティ名	接続先
タスクDB	関連プロジェクト	プロジェクトDB
議事録DB	関連プロジェクト	プロジェクトDB
タスクDB	関連議事録	議事録DB
案件DB	関連顧客	顧客DB

プロパティ名は、Notionの機能名ではなく業務用語にします。

「Relation」「関連」ではなく、「関連プロジェクト」「関連議事録」「顧客」「発生元会議」のように、何をつなぐのか分かる名前にします。

双方向リレーションの見せ方

Notionのリレーションは、接続先DBにも対応するプロパティを表示できます。

公式ヘルプでは、リレーションは初期状態では一方向で作成され、必要に応じて接続先DBにも対応するリレーションを作れると説明されています。

双方向リレーションは便利です。

タスク側から関連プロジェクトを見られ、プロジェクト側から関連タスクも見られるからです。

ただし、何でも双方向表示にすると、DBの画面がプロパティだらけになります。

関係	双方向表示するか	理由
プロジェクト ↔ タスク	表示する	プロジェクト側で関連タスクを見たい
プロジェクト ↔ 議事録	表示する	案件ごとの会議履歴を見たい
顧客 ↔ 議事録	表示する	顧客ごとの接点履歴を見たい
タスク ↔ 議事録	条件付き	タスク発生元を追うなら表示
ナレッジ ↔ 問い合わせ	条件付き	問い合わせ分析に使うなら表示
担当者DB ↔ タスクDB	慎重に	ユーザープロパティで足りることが多い

双方向表示を使う時は、接続先に出るプロパティ名も分かりやすくします。

接続元	接続先に表示する名前
タスクDBの関連プロジェクト	関連タスク
議事録DBの関連プロジェクト	関連議事録
案件DBの関連顧客	関連案件
タスクDBの関連議事録	会議から生まれたタスク

見せる方向は、会議やレビューで使うかどうかで決めます。

プロジェクト会議で「この案件のタスク」を見るなら双方向表示します。

使わないなら、表示しない方がDBが軽くなります。

ロールアップとの違い

リレーションは、DB同士をつなぐ機能です。

ロールアップは、リレーションでつながった先の情報を集計・表示する機能です。

Notion Workflowの記事でも、リレーションとロールアップの違いを「つなぐ機能」と「集計する機能」として整理しています。

Notion Workflow：リレーション・ロールアップ使い方ガイド

業務でよく使う組み合わせは次の通りです。

見たい情報	リレーション	ロールアップ
プロジェクトごとのタスク数	プロジェクトDB ↔ タスクDB	関連タスクの件数
完了タスク数	プロジェクトDB ↔ タスクDB	ステータスが完了の件数
最終議事録日	プロジェクトDB ↔ 議事録DB	会議日の最大値
顧客ごとの未完了案件	顧客DB ↔ 案件DB	状態が完了以外の件数
日報の未確認数	メンバーDB ↔ 日報DB	確認状態が未確認の件数

ロールアップは便利ですが、数字を出すだけでは意味がありません。

「何を判断するための数字か」を決めます。

ロールアップ指標	判断すること
関連タスク数	タスクが切り出されているか
完了率	プロジェクト全体の進み具合
期限超過数	マネージャーが介入すべきか
最終議事録日	会議や確認が止まっていないか
未確認日報数	上長確認が滞っていないか

ロールアップは数字を飾るためではなく、次に見るビューや会議での判断につなげるために使う と考えます。

プロジェクト・タスク・議事録の設計例

実務で最初に作りやすいのは、プロジェクトDB、タスクDB、議事録DBの3つです。

プロジェクト管理全体の設計は、別記事で詳しく整理しています。

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

ここでは、リレーションだけに絞って見ます。

DB	主要リレーション	目的
プロジェクトDB	関連タスク、関連議事録、関連顧客	案件単位で情報を集める
タスクDB	関連プロジェクト、発生元議事録	作業と背景をつなぐ
議事録DB	関連プロジェクト、関連タスク	会議から作業へつなぐ
顧客DB	関連案件、関連議事録	顧客単位で履歴を見る

この設計にすると、次のようなビューが作れます。

ビュー	元DB	フィルター
案件別タスク	タスクDB	関連プロジェクトが対象案件
会議から生まれたタスク	タスクDB	発生元議事録が空でない
顧客別議事録	議事録DB	関連顧客が対象顧客
今週レビューする案件	プロジェクトDB	関連タスクに期限超過あり
未処理決定事項	議事録DB	対応タスク未作成

大事なのは、議事録本文にタスクを埋めたままにしないことです。

会議で出た対応事項は、タスクDBへ切り出し、発生元議事録と関連プロジェクトをリレーションします。

そうすると、プロジェクト側からも、会議側からも、タスク側からも背景を追えます。

自己参照リレーションの使い所

自己参照リレーションは、同じDB内のページ同士をつなぐリレーションです。

公式ヘルプでも、タスクDBでタスク同士を関連付けたい場合などに、現在操作しているDB自体をリレーション先に選べると説明されています。

使い所はあります。

ただし、使いすぎると構造が見えにくくなります。

自己参照の使い方	向いている場面
親タスク・子タスク	大きな作業を小さく分ける
ブロッカー	このタスクが終わらないと次が進まない
関連ナレッジ	似た手順や補足ページをつなぐ
前提タスク	依存関係を軽く表す
関連問い合わせ	同じ原因の問い合わせをまとめる

自己参照を使う時は、目的を1つに絞ります。

同じタスクDBに「親タスク」「関連タスク」「ブロッカー」「前提タスク」を全部作ると、入力者はどこに何を入れるべきか迷います。

最初は、親子関係だけにする。

必要になったら、依存関係やブロッカーを追加する。

この順番が安全です。

リレーションを増やしすぎる失敗

Notionリレーションは、増やしすぎると運用が重くなります。

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

失敗	起きること	対策
何でもリレーションにする	入力項目が多すぎる	会議やレビューで使う関係だけ残す
双方向表示を全部ONにする	DBがプロパティだらけになる	接続先で本当に見るものだけ表示
リレーション名が曖昧	何を選ぶべきか迷う	関連プロジェクト、発生元議事録など業務名にする
ロールアップを増やしすぎる	数字はあるが判断に使われない	週次レビューで見る指標だけ残す
外部共有DBとつなぐ	社内情報が見える危険がある	共有専用DBや共有専用ビューを分ける
手入力が重い	更新されなくなる	テンプレート、フィルター付きビュー、入力ルールを使う

リレーションは、月1回棚卸しします。

棚卸し観点	判断
使われていないリレーション	削除する
空欄が多いリレーション	本当に必要か見直す
手入力が重いリレーション	自動化や入力ビューを検討する
似たリレーションが複数ある	統合する
外部共有に危ないリレーション	非表示、分離、別DB化する

特に外部共有ページでは注意が必要です。

ページ本文は見せてもよいが、リレーション先の社内議事録、原価、契約、日報は見せてはいけないケースがあります。

リレーションは便利な分、情報のつながりも外に出やすくなります。

kintoneへ移す判断

Notionリレーションで業務DBをつなぐと、かなりの管理ができます。

ただし、リレーションが増えてきたら、Notionだけで続けるべきかを見直します。

次の状態になったら、kintone、CRM、Jira、Backlog、専用Webアプリなどへの分離を検討します。

状態	Notionで続けにくい理由
顧客マスタ、案件、請求、契約が複雑につながる	正式な権限、履歴、重複排除が必要
承認フローがある	誰がいつ承認したかの履歴が必要
外部ユーザーが入力する	入力フォーム、権限、通知が重要
リレーションが多く、入力が重い	現場が更新しなくなる
集計や帳票が必要	Notionのビューだけでは足りない
監査ログや厳密な履歴が必要	専用DBや業務アプリが必要

Notionは、業務の関係を早く可視化するには向いています。

プロジェクト、タスク、議事録、顧客、日報の関係をNotionで試す。

そのうえで、正式な台帳、承認、請求、外部入力、監査が必要な部分をkintoneやCRMへ移す。

この順番なら、最初から大きなシステムを作るより、現場の業務構造をつかみやすくなります。

まとめ

Notionリレーションは、DB同士をつなぐ強力な機能です。

しかし、つなげられるものを全部つなぐと、DBはすぐに重くなります。

まず、DBを分けます。プロジェクトDB、タスクDB、議事録DB、顧客DB、日報DBのように、1行の意味が違うものを分けます。

次に、業務上必要な関係だけをリレーションにします。

プロジェクトとタスク、議事録とタスク、顧客と案件のように、会議やレビューで実際に見る関係を優先します。

双方向表示は、接続先DBでも本当に見る時だけ使います。

ロールアップは、数字を飾るためではなく、期限超過、完了率、最終議事録日、未確認数など、次の判断につながる指標だけに絞ります。

Notionリレーションは、情報を迷子にしないための設計です。

業務DB同士の関係を明確にし、見るビュー、更新する人、外部ツールへ移す基準まで決めて使うと、Notionは単なるメモツールではなく、小さな業務システムになります。