n8n × Notion テンプレート複製方式でひとまとまりのDB群を丸ごと横展開する——手作業1時間以上の自動セットアップを1分に短縮した設計と実装

2026年4月17日

NotionのDB群を複製してクライアントごと・プロジェクトごとに横展開したい——そんな課題をお持ちなら、この「テンプレート複製方式」が突破口になるかもしれません。手作業で1時間以上かかり、しかもヒューマンエラーが生じがちだった作業を、たった1分で自動セットアップ可能にする方法の全貌を公開します。

手動セットアップの限界——デモ環境を都度用意するコストが積み重なった

MIMIRは、n8n・Notion・LLMを組み合わせたAI自動化システムです。コンテンツ生成から顧客管理まで、各クライアントの業務をワークフローで一気通貫に自動化します。

このシステムの核心は「プロジェクトやクライアントごとに専用のNotionデータベース群を持てる」設計にあります。1クライアントあたり20以上のNotionデータベース（DB）を用意し、それらが連携することで自動化ワークフロー全体が動きます。

以前はデモや試用の依頼があるたびに、専用環境を一から用意する必要があり、最初の数社は手動でセットアップしていました。テンプレート化済みのDB群をNotionのUI上で複製した上で、DB名をひとつひとつ手で変更し、マスターテーブルにDB IDを手動登録していた——これで1社あたり1時間以上かかります。3社、4社のうちはまだ許容範囲でした。しかし何社も繰り返していく中で、新規オンボーディングやデモ提供のたびにエンジニアが大きく拘束される状況が明確なボトルネックとして浮上しました。

新規クライアントの導入リードタイムが長くなる
デモ環境の用意を含めセットアップ担当者の工数が圧迫され、他業務に支障が出る
手順が属人化しており、ミスが生じても検出が遅れる

「このままではスケールできない」——その課題認識が、n8n × Notion による自動セットアップの設計へと駆り立てました。

MIMIRが各クライアントに用意するデータベース群とは何か

なぜ大量のDBが必要なのか。MIMIRの自動化ワークフローは多様なデータを正確に管理・参照することで成立しており、DB群は大きく4カテゴリに分類されます。基本機能だけで20以上、オプションも含めると30を超えるDB数になります。

また、自社用の領域に加えて、自社の顧客向けの領域を追加することができるので、プロジェクト単位や顧客単位での管理・共有が可能な設計になっています。デモや試用の依頼があった際には、この設計によってデモ用の領域をすばやくセットアップして提供しています。

用語メモ：リレーションとは、NotionのDBどうしを「参照」で紐付ける機能です。たとえば記事DBのレコードからペルソナDBの特定ペルソナを参照することで、「このコンテンツは誰向けか」を自動で引き出せます。

各DBはそれぞれ単独で動くのではなく、リレーションによって網の目のように連携しています。この連携構造こそが、後述するAPI制約の核心的な問題にもなります。

自動セットアップを試みて最初にぶつかった壁——Notion APIの制約

「DB作成をAPIで自動化すればいい」——最初はそう考えました。しかし調査を進めると、すぐに根本的な制約にぶつかります。

Notion Public APIには `duplicate_page`（ページ複製）エンドポイントが存在しないのです。

POST /v1/databases でDBを個別に作ることは技術的に可能です。しかしここに第二の壁があります。DBを個別に新規作成した場合、リレーションの再配線が極めて困難になります。新規作成したDBには新しいIDが発行されるため、「記事DBのペルソナDBプロパティは、新しく作ったこのクライアント専用のペルソナDBのIDを参照せよ」という再配線を全DB分実施する必要があります。なお、NotionのエクスポートSamp;インポート機能を用いた場合も同様に、リレーションの再配線問題は解消されません。

特に深刻なのがintra-tree relation（ツリー内リレーション：同一Notionページ配下にあるDB間の紐付け）の問題です。大量のDB × 複数リレーション分の再配線をAPIで実装しようとすると、コードの複雑さが爆発的に増大し、実装コストは手動作業を大幅に超えてしまいます。手作業と比較すれば自動処理のほうがコストは低いものの、大量のDBを扱う分API利用料が膨らむのは事実であり、それも考慮が必要です。

「AIとAPIですべてを解決しよう」という前提そのものを疑い直す必要がありました。

テンプレート複製方式——Notionの仕様を逆手に取った設計

制約を突破したキーアイデアは、「APIで解決できないなら、Notionの仕組みに任せる」という発想の転換です。

Notionには、ページを複製したとき同一ページ内のDB間リレーションを自動的に再配線する仕様があります。つまり完成済みのテンプレートページをNotionのUI（またはMCP経由）で複製するだけで、大量のDBとリレーションが丸ごと再現されます。

この設計のメリットは明確です。

リレーション問題をNotionに委ねられる：APIで解決不可能だった再配線を、Notionの複製機能が肩代わりする
n8nは「後処理」に専念できる：タイトル変更・初期データ投入・通知処理だけを担当すればよい
テンプレートを更新すれば全クライアントの雛形に反映される：DB構成の変更はテンプレートページの修正だけで完結

自動セットアップワークフローが約1分でやること——7ステップの処理フロー

複製後にn8nの自動セットアップWFがwebhook経由で起動し、以下の7ステップを約1分で処理します（APIレスポンスや対象DBの状態により変動する場合があります）。

STEP

rootブロック取得とDB IDの収集

複製されたページのrootブロック（各セクション）を取得し、子ブロックを再帰的にトラバース（走査）してすべてのDB IDを収集します。このIDリストが後続処理の「地図」になります。

STEP

DBタイトル正規化

「記事DB（テンプレート）」のようなテンプレート用タイトルを「記事DB（新クライアント名）」に書き換えます。全DB分を一括処理します。

STEP

MAPPINGテーブルによるフィールド対応

MAPPINGテーブルを参照し、「DBタイトル → クライアント設定DBの対応フィールド名」を解決します。このテーブルがあることで、後続処理が汎用的なコードで動きます。

STEP

クライアント設定DB行の作成

各DB ID、slack_channel_id、strategy_doc_id をすべてのフィールドに書き込んだレコードをクライアント設定DBに作成します。クライアント設定DBはワークフロー全体の「設定ハブ」として機能します。

STEP

メンバーDB・ペルソナDB行の作成

クライアント専用のメンバーDB初期レコードと、ペルソナDBの初期ペルソナ行を作成します。ワークフロー起動直後から使える状態にします。

STEP

機能フラグDB初期レコード作成

機能のON/OFFを制御する機能フラグDBに、スケジュール設定付きの初期レコードを投入します。どの自動化機能を有効化するかの初期状態が定義されます。

STEP

Slack DM通知

セットアップ完了をSlack DMで通知します。新クライアントのクライアント設定DB IDや主要DB IDが含まれるため、担当者はすぐに次のステップへ進めます。

1時間以上かかっていた手作業が、この7ステップで約1分に収まります（E2Eテスト：全DBマッピング完了、unmapped 0件）。

実装でハマった4つのポイントと、その解決策

① n8n Code nodeで fetch() が使えない問題

Code nodeはtask runner環境で実行されるため、標準の fetch() が使えません。

解決策： this.helpers.httpRequest を使用します。ただし通常の関数宣言だと this コンテキストが失われるため、アロー関数で記述して this 参照を保持する必要があります。

② Synology Docker環境でのlocalhost問題

Synology（シノロジー）：NAS製品のメーカー。Dockerでn8nをセルフホストできるため、オンプレミス運用に利用されることがあります。

Synology上のDockerでn8nをホストしている場合、localhost がパブリックIPアドレスに解決されてしまうケースがあります。

解決策： localhost の代わりに 127.0.0.1 を明示的に指定します。

③ Credential管理の簡素化——CRUD操作をwebhookに委譲

Notion APIのクレデンシャル（認証情報）を各ノードで管理すると、更新時の修正箇所が増え保守コストが上がります。

解決策： Notion APIへのCRUD操作（作成・読み取り・更新・削除）を担うwebhookエンドポイントを別途用意し、自動セットアップWFからはそのwebhookを呼び出す構成にします。クレデンシャル管理が一箇所に集約されます。

④ MAPPINGテーブルの保守漏れによる障害

新機能向けのDBをテンプレートページに追加した際、MAPPINGテーブルの更新を失念し、新規クライアントのセットアップが途中で失敗しました。

解決策と運用ルール：機能追加等でDBを増やした場合には、必ずテンプレートページにも反映させ、MAPPINGテーブルを同時に更新するルールとして明文化します。チェックリスト化してレビューに組み込むことを推奨します。

Slackから起動するUIフロー——ボタン一押しで全自動セットアップが走る

エンジニア以外のオペレーターでも新規クライアント・プロジェクトを追加できるよう、Slack上にUIを用意しています。コストや処理時間・操作性の面でまだ最適解には至っていないのですが、現在は①NotionのUI上でDBを複製→②ボタン押下→③フォームで詳細入力、というステップで自動化できるようになっています。Notion APIに複製できる機能が正式実装されれば、さらに大幅に簡略化できると考えています。

重要な設計ポイントはfire-and-forget方式です。Slackのタイムアウト制限（3秒）を回避しつつ、完了通知はSlack DM経由で届くため、操作者はボタンを押した後は待つだけです。テンプレート複製とSlackのボタン操作だけで新規クライアント追加が完結し、技術的な知識がなくても運用できる体制が整います。

まとめ——「ツールの制約はツールの外で解決する」という設計原則

本実装で得た最大の教訓は、ツールの制約をそのツール内で無理に解決しようとしないことです。

n8nはAPIで確実に処理できる「後処理」に専念し、Notionはリレーション再配線という「UIでしかできないこと」を担い、Slackは「人がトリガーを引く接点」として機能する——役割を明確に分離したことが、大量のDBを扱うAPIコストを抑えつつ、確実性を高める結果につながっています。DB群の横展開・スケーラビリティに課題を感じているエンジニアやDX担当者の方に、この設計が一つの参考になれば幸いです。

MIMIRシステムの導入検討、n8n × Notionを活用した業務自動化の設計・実装に関するご相談はお気軽にどうぞ。

参考資料

WHO WROTE

Shinpei Okada COO / AIエンジニア

地方テレビ局、歯科コンサル、中堅SIerを経て独立。ダイヤルアップ接続の時代にHTMLに魅せられ、なんだかんだ10年以上WEB制作に関わり続けている。近年はNotionとn8nを軸にしたワークフロー構築に注力。生活しているだけでユーザーの哲学や日々の情報を抽出・蓄積し、AIによるデータ活用が可能になるシステム「MIMIR」の開発に取り組んでいます。