【実務・中級編】Notionの「データベース・リレーションの制限数」を突破する：多段アーキテクチャ設計と大規模データ管理の裏技 – プロジェクト・ナレッジ管理活用バイブル

Notionの限界を突破する：1万レコード超を高速化する「多段リレーション・アーキテクチャ」と大規模データ管理の極意

「Notionは便利だが、スケールすると劇的に重くなる」
「タスクやプロジェクトが増えるにつれて、ページの読み込みに数秒待たされるようになった」

あなたも、開発チームのドキュメントやタスクをNotionで一元管理しようとして、この「パフォーマンスの壁」にぶち当たったことはないだろうか。

Notionは優れたノーコードツールでありながら、その内部構造はリレーショナルデータベース（RDB）やグラフデータベースに近い挙動を示す。特に「リレーション（Relation）」と「ロールアップ（Rollup）」、そして新しくなった「Formula（関数） 2.0」の多用は、データ量に対して指数関数的な計算負荷をブラウザとサーバーに強いる。

本稿では、一般的な解説書には絶対に載っていない、数万レコード規模のエンタープライズ環境でも破綻しない「多段リレーション・アーキテクチャ」の設計理論と、Notion APIを用いた自動非正規化（デノーマライズ）による限界突破の具体策を解説する。

チームのベロシティを停滞させる「重いNotion」を、一瞬で「爆速のナレッジエンジン」へと変貌させよう。

—

1. なぜNotionは重くなるのか？リレーション限界のメカニズム

Notionのパフォーマンスが低下する最大の原因は、「クライアントサイドでの動的オブジェクトグラフの構築」にある。

[Notion API/Backend]
│ (巨大なJSONペイロード: すべてのリレーション先メタデータを含む)
▼
[ブラウザ / Notionアプリ]
│ ── 1. JSONのパース
│ ── 2. リレーションツリーの走査（依存関係の解決）
│ ── 3. Formula 2.0 / Rollupの動的再計算
▼
[DOMレンダリング] ── 画面がカクつく・フリーズする

パフォーマンス低下を引き起こす3大要因

1. JSONペイロードの肥大化とN+1問題の疑似発生
リレーションが設定されたデータベース（DB）のビューを開く際、Notionは関連するページのIDだけでなく、そのプロパティ情報の一部も同時にフェッチする。1つのタスクDB（1万件）がプロジェクトDB（100件）と結びついている場合、ビューを描画するために裏側で膨大な依存関係ツリー（Object Graph）がメモリ上に展開される。
2. RollupとFormula 2.0の評価コスト
リレーション先の値を参照する「Rollup」や「Formula 2.0」は、ページが表示されるたびにブラウザ（クライアントサイド）のJavaScriptスレッドで動的に計算される。リレーション数が数千を超えると、この計算処理がメインスレッドを占有し、スクロールの引っかかりや入力遅延を引き起こす。
3. 双方向リレーションの罠
Notionでリレーションを作成すると、デフォルトで双方向にリレーションプロパティが作成される（例：「タスク」↔「プロジェクト」）。これは、片方のDBを更新した際、もう片方のDBのインデックスも強制的に再構築されることを意味する。書き込み頻度が高い大規模プロジェクトでは、これがAPIのロック競合や同期遅延の引き金となる。

—

2. 限界を突破する「多段リレーション・アーキテクチャ」

この物理的限界を突破するために我々が採用すべきなのが、RDBの設計思想を取り入れた「多段リレーション・アーキテクチャ（Multi-Tier Relation Architecture）」である。

アーキテクチャ概要図

┌─────────────────────────────────────────────────────────┐
│ Projects DB (親: 100件) │
└───────────────────────────┬─────────────────────────────┘
│ (1:N)
▼
┌─────────────────────────────────────────────────────────┐
│ Milestones DB (中間: 500件) │
└───────────────────────────┬─────────────────────────────┘
│ (1:N)
▼
┌─────────────────────────────────────────────────────────┐
│ Hot Tasks DB (子・アクティブ: 1,000件) │
└───────────────────────────┬─────────────────────────────┘
│
[バッチ処理で自動移行 (非正規化・静的化)]
│
▼
┌─────────────────────────────────────────────────────────┐
│ Cold Archive DB (アーカイブ: 50,000件) │
└─────────────────────────────────────────────────────────┘

設計のコア極意

1. 中間データベース（Junction/Milestone DB）の挟み込み
「プロジェクト」と「タスク」を直接結ぶのではなく、中間に「マイルストーン」や「スプリント」といった中間DBを挟む。これにより、1つの親プロジェクトに数千のタスクが直接ぶら下がるのを防ぎ、1ノードあたりの最大リレーション数を100以下に抑え込む。
2. Hot / Cold データベース分離（超重要）
現在進行形のタスクのみを格納する「Hot Tasks DB」と、完了したタスクを退避させる「Cold Archive DB」を完全に分離する。
3. 静的化（デノーマライズ）バッチの実行
Cold Archive DBにデータを移行する際、リレーションを維持したまま移動させると負荷が変わらない。そのため、リレーションプロパティを「プレーンテキスト」や「URL」に変換（非正規化）してリレーションを切断する。これにより、過去ログの検索性を担保しつつ、依存関係グラフを完全にリセットする。

—

3. 実践：エンタープライズ向けデータ構造と自動化スクリプト

それでは、実際にこの多段アーキテクチャを運用するための構成定義と、自動化スクリプトのプロトタイプを構築しよう。

3.1. アーキテクチャ構成定義（YAMLベストプラクティス）

プロジェクトのスキーマ設計をGit管理し、チームで共有するための設定ファイル構成例だ。

notion-schema-manifest.yml
version: “2024-04”
metadata:
environment: production
project: “Core Platform Engineering”

databases:
projects:
name: “🎯 Projects”
sharding_key: “status”
properties:
Name: { type: “title” }
Status: { type: “select”, options: [“Backlog”, “In Progress”, “Completed”] }

milestones:
name: “📍 Milestones”
properties:
Name: { type: “title” }
Project:
type: “relation”
relation_to: “Projects”
single_property: true # パフォーマンス向上のため双方向をオフに設計

tasks_hot:
name: “🔥 Tasks (Active)”
description: “現在進行中、および直近2スプリント以内のタスクのみを保持（上限1000件推奨）”
properties:
Name: { type: “title” }
Status: { type: “status” }
Milestone:
type: “relation”
relation_to: “Milestones”
single_property: false # 双方向（進捗ロールアップ用）

tasks_cold_archive:
name: “❄️ Tasks (Archive)”
description: “完了タスクの静的退避先。リレーションはテキストに非正規化済み”
properties:
Name: { type: “title” }
ArchivedAt: { type: “date” }
LegacyProjectName: { type: “rich_text” } # リレーションではなくテキストで保持！
LegacyMilestoneName: { type: “rich_text” }
OriginalPageURL: { type: “url” }

3.2. 自動非正規化・アーカイブスクリプト (Node.js + TypeScript)

以下は、`Tasks (Active)` DBで「Done（完了）」ステータスになってから30日が経過したタスクを自動で検出し、リレーションをテキストに変換した上で `Tasks (Archive)` DBに退避させ、元のHotタスクを削除（またはアーカイブ）する、実戦的なスクリプトである。

// archive-runner.ts
import { Client } from “@notionhq/client”;
import as dotenv from “dotenv”;

dotenv.config();

const notion = new Client({ auth: process.env.NOTION_API_KEY });

const HOT_DB_ID = process.env.NOTION_HOT_DB_ID!;
const COLD_DB_ID = process.env.NOTION_COLD_DB_ID!;

async function archiveOldTasks() {
console.log(“🚀 アーカイブバッチ処理を開始します…”);

// 1. 完了した古いタスクをHot DBからクエリ
const response = await notion.databases.query({
database_id: HOT_DB_ID,
filter: {
and: [
{
property: “Status”,
status: {
equals: “Done”
}
}
// 必要に応じて「更新日時が30日前」などの条件を追加
]
}
});

for (const page of response.results) {
if (!(“properties” in page)) continue;

const titleProperty = page.properties[“Name”];
const taskName = titleProperty.type === “title” ? titleProperty.title[0]?.plain_text : “Untitled”;

console.log(`📦 移行対象タスク検出: ${taskName}`);

// — 【極限の知見】リレーション先データの解決（非正規化） —
// ロールアップやリレーションを直接移すのではなく、名前をテキストとして解決する
const milestoneRelation = page.properties[“Milestone”];
let milestoneText = “None”;

if (milestoneRelation && milestoneRelation.type === “relation” && milestoneRelation.relation.length > 0) {
const targetPageId = milestoneRelation.relation[0].id;
try {
const targetPage = await notion.pages.retrieve({ page_id: targetPageId });
if (“properties” in targetPage) {
const mTitle = targetPage.properties[“Name”];
if (mTitle && mTitle.type === “title”) {
milestoneText = mTitle.title[0]?.plain_text || “Untitled Milestone”;
}
}
} catch (err) {
console.error(`Failed to fetch milestone relation: ${targetPageId}`, err);
}
}

// 2. Cold DB（アーカイブ用）に新規ページを作成（リレーションではなくリッチテキストとして保存）
await notion.pages.create({
parent: { database_id: COLD_DB_ID },
properties: {
“Name”: {
title: [{ text: { content: `[ARCHIVED] ${taskName}` } }]
},
“LegacyMilestoneName”: {
rich_text: [{ text: { content: milestoneText } }]
},
“OriginalPageURL”: {
url: page.url
},
“ArchivedAt”: {
date: { start: new Date().toISOString().split(‘T’)[0] }
}
}
});

// 3. 元のHot DBのタスクをアーカイブ（ゴミ箱移動、または物理削除）
await notion.pages.update({
page_id: page.id,
archived: true
});

console.log(`✅ アーカイブ完了 & 元ページ削除: ${taskName}`);
}

console.log(“🏁 バッチ処理が正常に終了しました。”);
}

archiveOldTasks().catch(console.error);

—

4. 開発スピードを極限まで高めるNotionハック

設計が美しくても、日々のオペレーションが遅ければ意味がない。ここでは、テックリードとしてチーム全体に叩き込みたい「爆速オペレーション技術」を共有する。

4.1. 開発中に絶対に使うべき爆速ショートカット

マウスに手を伸ばしている時間は無駄だ。チームの全エンジニアに以下のショートカットを暗記させよう。

4.2. 導入必須の神Google Chrome拡張機能

Notionの標準機能に不満があるなら、拡張機能で補強する。

1. Notion Boost

機能: 画面右側に目次（Outline）を常時表示し、かつ「ページトップへ戻るボタン」を追加する。
効果: 1万字を超えるシステム要件定義書（PRD）のナビゲーションが劇的に快適になる。

2. Save to Notion

機能: Web上の技術記事やGitHubのIssueを、あらかじめ設定したテンプレートに従って、Notion DBへ1クリックでスクラップする。
効果: 技術調査（R&D）のナレッジ共有効率が5倍に跳ね上がる。

4.3. チーム開発で役立つ「設定の共有化・ガバナンスルール」

Notionの自由度はカオスを生む。ベロシティを落とさないための統治ルール（ガバナンス）を明文化しよう。

データベースのロック（Database Lock）の義務化

プロパティの追加・削除は、テックリードまたは権限者のみが行う。不用意なプロパティの追加は、API連携の破損や不要なリレーション計算を誘発するため、通常時は必ず「データベースをロック」しておくこと。

Formula 2.0の共通ライブラリ化

複雑な数式（進捗率の計算やスプリント残日数の割り出しなど）は、個々のメンバーに作らせず、共有ドキュメントに「Formulaスニペット」としてアセット化してコピーして使わせる。

「パーソナルビュー」の徹底

全体共有のビューで直接フィルタを変更させない。各自が作業する際は、必ず自分用の「プライベートビュー」を作成するか、`ユーザー` フィルターを「自分」に設定した共通テンプレートビューを使用させる。これにより、ビューの競合と描画遅延を防ぐ。

—

5. まとめ

Notionは単なる「おしゃれなメモ帳」ではない。その本質は、極めて柔軟なWebデータベースプラットフォームである。

スケールに伴う速度低下は、ツールの限界ではなく、データ構造の設計ミス（アンチパターン）に起因することがほとんどだ。本日紹介した「多段リレーション・アーキテクチャ」と「Cold DBへの自動非正規化」を導入すれば、チームのドキュメンテーションとプロジェクト管理は、かつてない速度で回り始める。

ツールをハックし、設計でねじ伏せる。それこそが、最強の開発チームを率いるテックリードの役割である。今すぐワークスペースの再設計に取りかかろう。