Notionの「データベース・リレーションの制限数」を突破する：多段アーキテクチャ設計と大規模データ管理の裏技
エンジニアリング組織が拡大し、プロダクトの複雑性が増すにつれて、Notionは単なる「議事録置き場」から、開発バックログ、ロードマップ、インフラ構成図、OKR、そしてナレッジベースが有機的に絡み合う「全社的ミドルウェア」へと昇華する。
しかし、ここで多くのアーキテクトがNotionの物理的な限界に直面する。
「データベースのリレーション数が多すぎて、クエリのレイテンシが耐えられない」
「プロパティの肥大化により、APIレスポンスがタイムアウトする」
「ページを開くだけで数秒のフリーズが発生する」
公式ドキュメントの表面的な使い方をなぞるだけでは、数万件規模のレコードを持つエンタープライズ環境のNotionワークスペースは確実に崩壊する。
本稿では、Notionの内部アーキテクチャとクエリ評価のメカニズムを解剖し、「リレーションの制限」を物理的・論理的に突破する多段アーキテクチャ設計、およびNotion APIとCLIを駆使した完全自動化の極意を、現場の修羅場をくぐり抜けてきたアーキテクトの視点から授けよう。
—
1. Notionのデータベース設計におけるリレーションの限界とパフォーマンス低下のメカニズム
1.1 リレーションの裏側にある「分散グラフDB」の悲劇
Notionのデータベースは、リレーショナルデータベース（RDB）の厳密なスキーマを持たず、実態としては高度に抽象化された分散ドキュメントストア／グラフデータベースに近い挙動をする。
リレーション（Relation）プロパティを張るということは、Notionのストレージ層において「双方向のエッジ（Edge）」を生成することを意味する。
- 1つのデータベースから別のデータベースへ数千件のリレーションが結ばれると、Notionのフロントエンド・クライアント（ReactベースのSPA）は、画面描画時（SSR / CSR）にそれらの関連ノードを動的にフェッチしようとする。
- 結果として、N+1問題の極致のようなクエリ爆発がクライアント側、あるいはAPI層で発生する。
1.2 パフォーマンス劣化を引き起こす3つのボトルネック
1. プロパティ肥大化によるペイロードの増大: 1つのデータベースに何十個ものリレーションやロールアップ（Rollup）を詰め込むと、Notion APIで取得するJSONのサイズが肥大化し、ネットワークI/Oのボトルネックになる。
2. 同期処理によるUIのブロック: Notionはリアルタイム共同編集を担保するため、リレーションの変更時に依存関係にあるロールアップや数式（Formula）をリアクティブに再計算する。これがメインスレッドを圧迫し、ベロシティの低下を招く。
3. API Rate Limitの直撃: 外部CI/CDパイプラインや自動化スクリプトからリレーションを辿ってデータを更新しようとすると、あっさり `429 Too Many Requests` に叩き落とされる。
この限界を突破するためには、RDBの設計手法である「正規化と非正規化のトレードオフ管理」および「データウェアハウス（DWH）的な階層化」をNotion上でエミュレートする必要がある。
—
2. 中間データベースとアーカイブ層を挟んだ多段アーキテクチャ（Multi-Tier Architecture）
モノリシックなデータベース設計（すべてのプロジェクト、タスク、チケット、PRが1つの巨大なDBで直結されている状態）を即座に廃止せよ。
我々が実装すべきは、「3層多段アーキテクチャ（3-Tier Database Architecture）」である。
[ Tier 03: アクティブ・オペレーション層 ] (日々のスクラムボード・タスク管理)
│ (非同期バッチ / APIによる昇格)
[ Tier 02: 中間サマリー・集約層 ] (プロジェクト・エピック単位の中間DB)
│ (定期アーカイブ)
[ Tier 01: コールド・アーカイブ層 ] (過去の全完了データ・ログ)
アーキテクチャの役割と設計思想
- Tier 03（オペレーション層）: 開発者が日常的に触るデータベース。リレーションは最小限（親エピックへの1本のみ）に絞り込み、プロパティ数を極限まで削ることで、UIの高速描画とAPIの応答速度を担保する。
- Tier 02（中間サマリー層 / 中間DB）: 複数のオペレーション層を束ねる「ハブ」となるデータベース。例えば、月次や四半期ごとのプロジェクト、あるいはマイクロサービスごとの境界づけられたコンテキスト（Bounded Context）ごとに設置する。これにより、全タスクDBと全プロジェクトDBの直接的な多対多（M:N）リレーションを回避し、結合度（Coupling）を下げる。
- Tier 01（アーカイブ層）: 完了したタスクや古いログを退避させる不変（Immutable）なデータベース。ここにリレーションは不要であり、純粋なテキストやセレクトプロパティとしてスナップショットを保存する。
—
3. 実践：エンタープライズ向けデータ構造とメンテナンス自動化スクリプト
ここからは、実際にこの多段アーキテクチャを構築し、データ移行や整合性担保を完全自動化するための実践コードを提示する。
手動でのリレーション張り替えはヒューマンエラーの温床であり、エンジニアリングの怠慢である。すべてをコード化（Infrastructure as Data）せよ。
3.1 Notion API (JavaScript / TypeScript) を用いた「中間DBを介した自動リレーション同期」スクリプト
以下のTypeScriptコードは、Tier 03（タスクDB）でステータスが「Done」になったレコードを検出し、自動的にTier 02（中間プロジェクトDB）へサマリーをアグリゲートしつつ、リレーションの付け替えを行うエージェントのコアロジックである。
import { Client } from “@notionhq/client”;
// Notionクライアントの初期化（インテグレーション・トークンを使用）
const notion = new Client({ auth: process.env.NOTION_API_KEY });
const TIER_3_TASK_DB_ID = process.env.TIER_3_TASK_DB_ID!;
const TIER_2_PROJECT_DB_ID = process.env.TIER_2_PROJECT_DB_ID!;
interface TaskPage {
pageId: string;
title: string;
status: string;
projectId: string; // Tier 2 への参照ID
}
/
- 完了したタスクを検出し、多段アーキテクチャの整合性を保つための同期処理
/
async function syncCompletedTasksToMiddleTier() {
try {
// 1. Tier 3から「Done」かつ「未同期」のタスクをフェッチ
const response = await notion.databases.query({
database_id: TIER_3_TASK_DB_ID,
filter: {
and: [
{
property: “Status”,
status: { equals: “Done” },
},
{
property: “ArchivedToMiddle”,
checkbox: { equals: false },
},
],
},
});
console.log(`[Sync Engine] Found ${response.results.length} tasks to process.`);
for (const page of response.results) {
const typedPage = page as any;
const pageId = typedPage.id;
const title = typedPage.properties[“Name”]?.title[0]?.plain_text || “Untitled”;
const parentProject = typedPage.properties[“Project”]?.relation;
if (!parentProject || parentProject.length === 0) {
console.warn(`[Warning] Task ${pageId} (${title}) has no parent project relation. Skipping.`);
continue;
}
const tier2ProjectId = parentProject[0].id;
// 2. Tier 2 (中間DB) 側のロールアップやカウンターを更新するためのトランザクション処理
// ここでは中間DBに対して完了タスクの集計プロパティをインクリメントする
await updateMiddleTierAggregate(tier2ProjectId, pageId);
// 3. Tier 3側のフラグを更新し、次回以降のクエリ対象外（またはアーカイブ層へ移行）にする
await notion.pages.update({
page_id: pageId,
properties: {
ArchivedToMiddle: {
checkbox: true,
},
},
});
console.log(`[Success] Synced task: ${title} -> Tier 2 Project: ${tier2ProjectId}`);
// Notion APIのレートリミット（3 requests/sec）を遵守するためのスロットリング
await new Promise((resolve) => setTimeout(resolve, 350));
}
} catch (error) {
console.error(“[Fatal Error] Failed to execute sync pipeline:”, error);
process.exit(1);
}
}
async function updateMiddleTierAggregate(tier2ProjectId: string, completedTaskId: string) {
// 現在のTier 2プロジェクトページを取得
const projectPage = await notion.pages.retrieve({ page_id: tier2ProjectId }) as any;
const currentRelations = projectPage.properties[“Completed Tasks”]?.relation || [];
// 既存のリレーション配列に新しい完了タスクを追加（多段リレーションの結線）
await notion.pages.update({
page_id: tier2ProjectId,
properties: {
“Completed Tasks”: {
relation: […currentRelations, { id: completedTaskId }],
},
},
});
}
// 実行エントリーポイント
syncCompletedTasksToMiddleTier();
—
4. メンテナンス性とパフォーマンスを極限まで高める運用ルール（DevOps Guidelines）
システムやスクリプトがいかに優れていても、現場のオペレーター（人間）がルールを破れば、データベースは再び腐敗する。組織的スケールに耐えうる「不変の鉄則」を定義する。
Ⅰ. 「直接リレーション」の禁止令（No Direct Cross-Boundary Relations）
- ルール: 異なるドメイン（例：「プロダクト開発DB」と「マーケティング施策DB」）の間で、直接M:Nのリレーションを張ることを厳禁とする。
- 理由: 結合度が高まりすぎると、片側のスキーマ変更やプロパティ削除が全社規模のデグレを引き起こす。
- 回避策: 共通の「インテグレーション・ハブDB（中間層）」を1つ挟み、そこに集約させること。
Ⅱ. プロパティ数のガバナンス（Property Budget Enforcement）
- ルール: 1つのデータベースあたりのプロパティ数は「最大25個」をハードリミットとする。
- 理由: プロパティが30個を超えたあたりから、Notionの内部キャッシュ効率が低下し、APIレスポンスタイムが幾何級数的に悪化する。
- 回避策: 詳細なメタデータやログは、ページ本文（Blocks）のマークダウン構造に流し込み、検索（Query）が必要な最小限のキーのみをプロパティとして露出させる。
Ⅲ. 定期的なガベージコレクション（GC）とコールドストレージ移行
- ルール: 最終更新日（Last Edited Time）から90日以上経過した「Done」ステータスのタスクは、自動スクリプトによってTier 01（アーカイブ層）へ物理移動（またはプロパティの凍結）を行う。
- 理由: アクティブなデータベースのレコード数を数千件以内に維持することで、Notionのインデックススキャンを常に高速な状態に保つ。
—
5. 結び：ツールを従わせる者だけが、真のベロシティを手に入れる
Notionは、単なる「便利なメモ帳」ではない。使い方を誤れば情報のサイロを生み出す諸刃の剣であり、アーキテクチャを極めれば、開発組織の認知負荷（Cognitive Load）を劇的に軽減する最強のナレッジOSとなる。
リレーションの制限にぶつかったとき、UIの機能追加を呪うのではなく、自身のデータモデリングの未熟さを疑い、多段アーキテクチャと自動化パイプラインをコードで実装せよ。
ツールに言い訳するな。エンジニアリングの力で、Notionの限界を骨の髄までハッキングし尽くせ。