Notionリレーションを自動追加する方法｜テンプレート・フィルター・APIの使い分け

Notionで業務DBを作ると、すぐに出てくる要望があります。

「新しいタスクを作った時に、関連プロジェクトを自動で入れたい」

「会議メモを作ったら、定例会議や顧客のリレーションを自動で入れたい」

「日付や担当部署に応じて、対応するDBページを自動で紐づけたい」

Notionのリレーションは、別々のデータベースをつなぐプロパティです。公式ヘルプでも、タスク、プロジェクト、顧客、会議メモなど複数DBのページを関連付けられる機能として説明されています。

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

ただし、リレーションの自動追加は、単純なオンオフ機能ではありません。

Notion内だけで済むケースもあります。

外部自動化が必要なケースもあります。

そもそも自動化しない方がよいケースもあります。

Notionリレーションの自動追加は、「入力をゼロにする機能」ではなく、「どの作成経路なら正しい親情報を持たせられるか」の設計 として考える必要があります。

この記事では、Notionリレーションを自動追加する方法を、DBテンプレート、フィルター付きリンクドDB、グループ表示、ボタン、データベースオートメーション、API・Makeの使い分けに分けて整理します。

先に結論：完全自動化できるケースとできないケース

Notionリレーションの自動追加は、目的別に分けて考えると判断しやすくなります。

やりたいこと	向いている方法	判断
毎回同じ親ページに紐づける	DBテンプレート	Notion内でよい
特定プロジェクト画面からタスクを作る	フィルター付きリンクドDB	Notion内でよい
ステータスや部署で分類しながら作る	グループ表示・フィルター	Notion内でよい場合が多い
ボタンを押して関連タスクを作る	データベースボタン	固定条件ならよい
条件に合う別DBページを探して紐づける	API・Make	外部自動化を検討
日付、担当者、金額など複数条件で付け替える	API・Make	Notion内だけだと不安定
重要な顧客・請求・契約情報を正確に紐づける	kintoneやCRMも検討	Notionだけに閉じない

たとえば、プロジェクトページ内に「このプロジェクトのタスク」というリンクドDBを置き、プロジェクトでフィルターしておくと、そのビューから新規タスクを作る運用にできます。

これは実務ではかなり有効です。

一方で、「タスク名にA社と入っていたらA社顧客DBへ自動でリレーション」「日付が今月なら今月の月次ページへ自動でリレーション」のような処理は、Notion内の設定だけでは設計が難しくなります。

この場合は、Make、Zapier、Notion API、社内スクリプトなどを使うか、そもそもNotionではなく業務アプリ側で台帳管理するかを検討します。

リレーションそのものの設計は、先にこちらの記事で整理しています。

Notionリレーションの使い方

DBテンプレートで初期リレーションを入れる

一番シンプルなのは、DBテンプレートにリレーションの初期値を入れておく方法です。

たとえば、毎週同じ定例会議の議事録を作るなら、議事録DBのテンプレートに「関連会議」「関連プロジェクト」「会議種別」などを入れておけます。

用途	テンプレートに入れるリレーション
週次定例の議事録	関連プロジェクト、会議種別
採用面談メモ	関連採用ポジション
月次レビュー	関連部門、関連月次ページ
顧客定例会	関連顧客、関連案件
社内FAQ登録	関連カテゴリ、関連マニュアル

Notion公式のデータベーステンプレートヘルプでは、DBテンプレートの作成、編集、繰り返しテンプレートが説明されています。

Notion公式ヘルプ：データベーステンプレート

DBテンプレートの使い方は別記事でも整理しています。

Notionデータベーステンプレートの作り方

ただし、テンプレートにリレーションを入れる場合は注意が必要です。

テンプレートに入れたリレーションは、基本的に「固定の相手」を初期値にする用途に向きます。

プロジェクトAのテンプレートならプロジェクトAに紐づく。

定例会議Aのテンプレートなら定例会議Aに紐づく。

このようなケースです。

向いている	向いていない
親ページが固定	作成時に親ページを探して変えたい
定例業務	都度条件が変わる業務
同じ部署、同じ顧客、同じ会議	顧客や案件が毎回変わる
作成者がテンプレートを選べる	作成者が判断できない

テンプレートにリレーションを入れすぎると、作成されたページが誤った親ページに紐づくことがあります。

特に、テンプレートをコピーして別案件にも使う時は危険です。

DBテンプレートは「固定の親を入れる」には向いていますが、「作成内容に応じて相手を探す」用途には向きません。

フィルター付きリンクドDBから新規作成する

実務で一番使いやすいのは、フィルター付きリンクドDBから新規作成する方法です。

たとえば、プロジェクトページにタスクDBのリンクドビューを置きます。

そのビューを「関連プロジェクトがこのプロジェクト」でフィルターします。

そのビューから新しいタスクを作ると、作成時点でプロジェクトとの関係を持たせやすくなります。

Notion Thingsの記事でも、フィルターされたビューやグループ化されたビューからページを作ることで、DBアイテム間のリンクを半自動的に作る考え方が紹介されています。

Notion Things：Force link between two database items automatically

この方法は、Notionを業務システムとして使う時にかなり実用的です。

画面	置くリンクドDB	フィルター
プロジェクトページ	タスクDB	関連プロジェクトが現在のプロジェクト
顧客ページ	議事録DB	関連顧客が現在の顧客
部署ページ	日報DB	関連部署が現在の部署
採用ポジションページ	面談DB	関連ポジションが現在のポジション
月次ページ	レビューDB	対象月が現在の月次ページ

ポイントは、入力者に「親を選ばせない」ことです。

プロジェクトAのページを開いて、その中のタスク一覧からタスクを作る。

顧客Bのページを開いて、その中の議事録一覧から議事録を作る。

この導線にすれば、入力者は自然に正しい親の文脈で作成できます。

ただし、この方法にも注意点があります。

注意点	対策
フィルター条件を壊すと自動入力されない	ビュー編集権限を絞る
複雑なフィルターでは期待通りに入らないことがある	作成後チェック用ビューを作る
別ページから作ると親が入らない	作成導線を決める
複数リレーションを同時に入れると混乱する	最初は親1つに絞る
フィルターの意味が分からない	ビュー名を業務用語にする

ビュー名も重要です。

「タスクDB」ではなく、「この案件のタスク」「この顧客の議事録」「この部署の日報」のように、どの文脈で作るビューか分かる名前にします。

グループ表示で選ばせる

もう一つの方法は、グループ表示を使うことです。

タスクDBを「関連プロジェクト」でグループ化します。

入力者は、対象プロジェクトのグループ内で新規タスクを作ります。

この方法は、複数の親を一覧で見ながら作る時に使えます。

グループ化する項目	向いているDB
関連プロジェクト	タスクDB
関連顧客	議事録DB
関連部署	日報DB
関連カテゴリ	FAQ DB
関連月次ページ	レビューDB

フィルター付きリンクドDBは、特定ページの中で作る時に向いています。

グループ表示は、一つのDB画面で複数の親を見ながら作る時に向いています。

方法	向いている場面
フィルター付きビュー	プロジェクトページや顧客ページ内で作る
グループ表示	タスクDB全体を見ながら親別に作る

ただし、グループ表示も万能ではありません。

入力者が別のグループにドラッグした場合、リレーションや分類が変わることがあります。

これは便利でもあり、事故にもなります。

業務で使うなら、どのグループを誰が動かしてよいかを決めます。

ボタンとDBオートメーションの使い所

Notionには、ボタンやデータベースオートメーションもあります。

公式ヘルプでは、ボタンでページ追加、ページ編集、確認表示、外部リンクを開くなどのアクションを設定できると説明されています。

Notion公式ヘルプ：ボタン

また、データベースオートメーションでは、ページの追加やプロパティ変更をきっかけに、ページのプロパティ編集やページ追加などの処理を実行できます。

Notion公式ヘルプ：データベースオートメーション

リレーション自動追加で使いやすいのは、次のようなケースです。

やりたいこと	方法
プロジェクトページから標準タスクをまとめて作る	ボタンでタスクページを作成
ステータスが「開始」になったら初期タスクを作る	DBオートメーション
議事録ページから決定事項DBへ行を作る	ボタン
月次レビューDBに定型チェック項目を作る	ボタン・テンプレート
入力漏れチェック用のページを作る	オートメーション

ただし、ここでも条件は分けて考えます。

固定の親に紐づけるなら、Notion内のボタンやテンプレートでかなり対応できます。

一方で、複数条件から相手ページを検索して、自動で正しいリレーションを入れる処理は複雑になります。

たとえば、次のような処理です。

複雑になりやすい処理	理由
顧客名から顧客DBを検索して紐づける	同名、表記ゆれ、未登録がある
日付から対象月ページを探す	月次ページの作成漏れがある
担当者から部署DBを紐づける	異動や兼務がある
案件コードから案件DBを探す	コード体系の管理が必要
金額や状態で請求DBとつなぐ	正確性と監査が必要

ここまで来たら、Notion内で無理に作り込むより、APIや業務アプリを検討した方がよいです。

API・Makeで自動化するケース

Notion APIを使うと、ページの作成やプロパティ更新を外部から行えます。

公式APIドキュメントでも、ページプロパティとしてリレーション型を扱う仕様が説明されています。

Notion API：Relation property value

MakeやZapierのようなノーコード自動化ツールを使えば、Googleフォーム、Slack、Gmail、カレンダー、スプレッドシートなどを起点にNotionページを作ることもできます。

APIやMakeを検討するのは、次のような時です。

起点	自動化例
Googleフォーム	問い合わせ内容から顧客DB・案件DBへ紐づける
Slack	特定投稿からタスクDBへ登録し、プロジェクトに紐づける
Googleカレンダー	会議予定から議事録DBを作り、顧客や案件に紐づける
CRM	顧客IDをもとにNotionの営業メモへ紐づける
kintone	案件コードをもとにNotion側の議事録やタスクへ紐づける

ただし、API化すると設計責任が増えます。

「自動で入る」ことより、「間違って入らない」ことが重要になります。

設計項目	決めること
キー	顧客名ではなく顧客IDや案件コードを使うか
重複	同じ条件のページが複数あったらどうするか
未登録	紐づけ先がなければ作るか、エラーにするか
権限	API連携にどこまでアクセスを許すか
ログ	いつ、何を、どのページに紐づけたか残すか
例外処理	失敗時に誰へ通知するか

APIやMakeは、入力の手間を減らせます。

しかし、表記ゆれや重複を放置したまま自動化すると、Notion内に間違ったリレーションが大量に作られます。

API自動化は、Notionの操作を置き換える前に、キー、重複、未登録、権限、ログを設計してから使う のが安全です。

親子タスクの設計例

よくある例として、親子タスクを考えます。

やりたいことは、プロジェクトページから標準タスクを作った時に、すべてのタスクへ関連プロジェクトを入れることです。

これはNotion内で始めやすいパターンです。

構成	内容
プロジェクトDB	案件や施策を1行で管理
タスクDB	実作業を1行で管理
関連プロジェクト	タスクDBからプロジェクトDBへのリレーション
プロジェクトページ内ビュー	関連プロジェクトでフィルターしたタスクDB
標準タスクボタン	初期タスクをまとめて追加

作成導線は次のようにします。

手順	内容
1	プロジェクトページを開く
2	ページ内の「この案件のタスク」ビューを見る
3	そのビューから新規タスクを作る
4	必要ならボタンで標準タスクを追加する
5	「関連プロジェクトが空」のチェックビューで漏れを見る

この設計の強みは、入力者が親プロジェクトを探さなくてよいことです。

プロジェクトページの中でタスクを作るから、文脈が明確です。

一方で、タスクDB全体の画面から直接タスクを作ると、関連プロジェクトが空になる可能性があります。

そのため、チェック用ビューを必ず作ります。

チェックビュー	条件
関連プロジェクト未設定	関連プロジェクトが空
発生元議事録未設定	発生元議事録が空、かつ会議由来
期限未設定	期限が空、かつ状態が未着手以外
担当者未設定	担当者が空

自動化で完璧にするのではなく、漏れを見つけるビューを用意します。

この方が、実務では壊れにくいです。

定例会議・議事録の設計例

もう一つ、議事録DBの例です。

定例会議の議事録は、リレーション自動追加と相性がよいです。

親が固定されやすいからです。

DB	役割
会議DB	会議種別や定例会議を管理
議事録DB	1回ごとの議事録を管理
タスクDB	議事録から生まれたタスクを管理
決定事項DB	決定事項を管理

議事録DBのテンプレートに、関連会議、関連プロジェクト、参加者、議題テンプレートを入れます。

定例会議ページ内に「この会議の議事録」ビューを置きます。

そのビューから議事録を作れば、関連会議を入れ忘れにくくなります。

議事録からタスクを切り出す場合は、タスクDBに「発生元議事録」と「関連プロジェクト」を持たせます。

タスクDBプロパティ	目的
発生元議事録	どの会議で発生したか
関連プロジェクト	どの案件の作業か
担当者	誰がやるか
期限	いつまでにやるか
確認者	完了確認する人
状態	未着手、進行中、確認待ち、完了

議事録記事でも、会議後にタスクが消えない設計を整理しています。

Notion議事録の作り方

自動化しない方がよいリレーション

すべてのリレーションを自動化すべきではありません。

自動化しない方がよいものもあります。

自動化しない方がよいもの	理由
顧客マスタとの紐づけ	表記ゆれ、同名、統廃合がある
請求・契約との紐づけ	間違えると影響が大きい
監査や承認に関わるリレーション	誰が判断したか残す必要がある
社外共有ページのリレーション	情報漏洩につながる
判断が必要なカテゴリ	自動分類の誤りが起きやすい

Notionは、柔軟に情報をつなぐには向いています。

しかし、正式な台帳や承認フローには限界があります。

次のような場合は、Notionだけで完結させず、kintone、CRM、SFA、会計システムなどとの役割分担を考えます。

状態	判断
顧客IDや案件コードが正式に必要	Notion外のマスタ管理を検討
承認履歴が必要	ワークフロー機能があるツールを検討
請求や契約に影響する	会計・契約システムを正にする
社外入力が多い	フォームや業務アプリ側で受ける
エラー時の責任が重い	ログと権限を持つ仕組みにする

自動化は、便利さのためだけに入れるものではありません。

業務上の責任が重い情報ほど、人の確認を残します。

入力事故を防ぐチェック項目

最後に、Notionリレーション自動追加を導入する前のチェック項目を整理します。

チェック	見ること
作成導線	どの画面から新規ページを作るか
親情報	どのリレーションが自動で入るべきか
固定か変動か	毎回同じ親か、条件で変わるか
入力者	誰が作るか、判断できるか
編集権限	ビューやフィルターを誰が変えられるか
チェックビュー	自動入力漏れを見つけられるか
例外処理	紐づけ先がない時にどうするか
外部共有	リレーション先が見えて問題ないか
棚卸し	使われていないリレーションを消せるか

特に重要なのは、作成導線です。

「どこから作っても自動で正しく紐づく」状態をNotionだけで作ろうとすると、設計が複雑になります。

まずは、作成導線を絞ります。

プロジェクトタスクは、プロジェクトページ内のビューから作る。

顧客議事録は、顧客ページ内のビューから作る。

定例会議の議事録は、会議DBのテンプレートから作る。

このように、入力する場所を固定した方が安定します。

まとめ

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

しかし、リレーションの自動追加は、単純に「自動で入れたい」と考えるだけでは失敗します。

固定の親に紐づけるなら、DBテンプレートが向いています。

特定プロジェクトや顧客の画面から作るなら、フィルター付きリンクドDBが向いています。

複数の親を見ながら作るなら、グループ表示が使えます。

標準タスクや定型ページを作るなら、ボタンやデータベースオートメーションが使えます。

一方で、条件に合うページを検索し、表記ゆれや重複を考慮して正しい相手へ紐づけるなら、APIやMakeを検討します。

顧客、請求、契約、承認のように正確性が重要な情報は、Notionだけに閉じず、kintoneやCRMなどの業務アプリと役割分担します。

Notionリレーションの自動追加で大切なのは、入力を完全になくすことではありません。

正しい画面から作れば、正しい親情報が入る。

漏れたものはチェックビューで見つかる。

責任が重いものは人が確認する。

このバランスで設計すると、Notionは現場が更新し続けられる小さな業務システムになります。