n8nからNotionへ調査メモを保存するには、共有したデータソースとプロパティ型をそろえ、まず1件を保存して読み戻すところから始めます。接続テストが通るだけでは、目的の台帳へ正しく書けることまで確認できません。
作成後はpage_idと安定したメモキーを保持し、更新前に親データソースとキーを照合してください。変更する項目だけを送り、保存した値をもう一度取得して確かめましょう。
本稿は、自分が管理する試験台帳へ短いメモを保存する手順です。手動実行でもNotionには実際に書き込まれるため、本番台帳と分けた領域を使ってください。
台帳のデータソースと、1件のメモのページを分ける
主例では、Notionのデータソース内にページを作り、タイトル・資料URL・要約などをプロパティへ保存します。ページ本文へ文章を追加する操作とは別なので、先に「何を台帳で管理したいか」を決めましょう。
例えば、資料ごとに「名前・URL・要約・確認日」を持たせたいなら、データソース内のページが向いています。自由な文章だけを親ページの下へ置きたい場合は、PageやBlockの目的に合う操作を確認してください。通常ページを親にして、台帳用の任意プロパティをそのまま送ることはできません。
要約をプロパティへ保存するのか、長い本文をブロックへ追加するのかも分けておきましょう。後者の追記を繰り返すと、同じ文章が積み重なる場合があります。本稿の主例は、短い要約をプロパティに保存する手順です。
次に確認したいこと：Google Sheetsの行を読み書きする方法
行・列・対象タブで管理したい人は、Sheets側の認証、行の識別、更新後の読み戻しを確認できます。NotionのデータソースやページIDを、Sheetsの行番号へ置き換えて説明することはしません。
n8n本体・ノード・Notion APIの版を分ける
この手順の対象は、NotionノードのtypeVersion 3と、Notion API 2026-03-11の組合せです。公式n8n 2.45.5のソースでは既定ノード版が3ですが、旧版1・2・2.1・2.2も併存します。
つまり、本体を更新しても既存ワークフローのノードが同じ版になったとは限りません。利用中ノードの版を確認し、画面にData Sourceがない場合は旧操作・旧IDとの違いを先に調べてください。database_idの欄へdata_source_idを無理に入れる方法では解決しないため、試験コピーで移行の可否を確かめましょう。
Notion APIでdatabaseとdata sourceが分かれたのは2025-09-03版で、主例が使用するAPI版そのものとは異なります。手順を合わせるために、既存台帳へ不用意に複数データソースを追加する必要はありません。
接続の能力と、共有する対象をそろえる
接続には「誰として認証するか」「何の操作を許すか」「どの内容へアクセスできるか」という別々の条件があります。Notionへ自分がログインできても、API接続が同じ範囲を読めるとは限りません。
- 試験台帳に使う内部接続を用意する
Notionの開発者向け接続管理で、本人のワークスペース用の内部接続を確認しましょう。主例に必要なRead content・Insert content・Update contentを、読取・作成・更新へ対応させてください。
- 秘密値はn8nのCredentialへ登録する
Notionの内部接続トークンを、n8nのNotion API CredentialにあるInternal Integration Secretへ設定します。通常データの欄、画像、実行結果へトークンを書き込まないようにしましょう。
- Notion側で試験対象へ接続を追加する
対象ページや台帳のメニューからConnectionsを開き、使う接続を選んでください。操作能力の設定だけで共有したつもりにならず、対象とその配下のどこまでアクセスが及ぶかも確かめます。
- n8nでCredentialと保存先を選ぶ
NotionノードにそのCredentialを指定しましょう。認証確認が通っても、まだ作成・更新は実行せず、次の読取でデータソースを特定してください。
読めることと、作成・更新できることを別々に確かめる
Data SourceのSearchで候補を見つけたら、取得したIDを使ってGetし、名前とプロパティの構成を照合しましょう。画面上のリンクドビューの見た目だけで書込先を決めず、共有した正本のデータソースを特定してください。
DatabaseのGetは容器の確認、Data SourceのGetは台帳の型の確認、Database PageのGetは1件のメモの確認に使います。この3つのIDを交換して使うことはできません。
認証確認が成功しても特定対象の読取に失敗するなら、共有範囲・ID・操作能力を確認してください。404などで取得できないことを、対象が存在しない証拠にはできません。読取先と型が合うまで、書込は進めないようにしましょう。
あわせて読む：n8nの認証情報を設定・管理する方法とOAuth2
Credentialの作成・更新・共有や、認証情報を安全に引き継ぐ方法を整理できます。本稿の「Notionの共有先と操作能力」の確認に加え、接続管理そのものに迷ったときの読み先です。
入力項目をNotionのプロパティ型へ対応させる
名前が似ているだけでは対応完了ではありません。取得したスキーマの表示名・ID・型に合わせ、各入力をどのプロパティへ保存するか決めましょう。
| 入力 | 仮の保存先と型 | 説明用の値 |
|---|---|---|
| title | Name / title | 試験メモ |
| memo_key | MemoKey / rich_text | research-test-001 |
| source_url | Source / url | https://example.com/source |
| summary | Summary / rich_text | 短い調査要点 |
| checked_at | Checked / date | 2026-10-30 |
| status | Status / select | 未確認 |
これは架空の入力と列名です。実際には取得したスキーマを優先し、数式やrollupなどNotionが計算する値を、普通の文字列で上書きしないでください。
主例のCreateでは、Title欄の値が保存先のtitle型へ対応します。追加プロパティにはMemoKey・Source・Summary・Checked・Statusを型に合わせて指定し、同じタイトル項目を二重指定しないようにしましょう。列名がStatusでも、この作例はselect型で、Notionのstatus型と同じ意味ではありません。
空欄・日付・selectには保存の意図を持たせる
更新しない項目は送信から外すことが基本です。省略と、明示的に空にする指定は別の操作なので、入力が空だからといって既存値が残るとは考えないでください。
避けたい更新例
Summaryを変えたいだけなのに、CheckedやStatusも空のまま更新項目へ残す方法です。空入力がnullへ変換される型では、保持したかった値まで消す原因になります。
目的に合わせた更新例
Summaryだけを更新項目へ指定し、CheckedとStatusは送信対象から外しましょう。消す必要がある項目だけ、型に合う空値を使う別の試験として確かめてください。
日付は「日付だけ」か「時刻とオフセットまで含む値」かを決め、使い方をそろえます。主例のCheckedは日付のみで、時刻を勝手に追加しない設計です。selectは未確認・確認済などの選択肢を先に用意し、表記違いの選択肢を自動で増やす運用にはしないでください。
rich_textや複数選択などの配列値も、更新が自動追記になるとは限りません。送る値が置換なのか、残す要素を含めた値なのかを確かめてから扱いましょう。
あわせて読む：n8nのExpressionとEdit Fieldsでデータを整える
前のノードから値を参照し、Notionへ渡す項目名・型・残す情報を整えたいときに役立ちます。Notion側のプロパティ型との一致は、本稿の対応表で引き続き確認してください。
1件作成してpage_idを保持し、保存先を読み戻す
最小の試験は、同じメモキーの既存ページを検索し、正常に検索できて0件の場合にだけ、型がそろった入力1件をDatabase PageのCreateへ渡す流れです。作成後は返ったIDでGetします。成功と表示されたかだけでなく、正しい台帳へ正しい値が入ったかを確認しましょう。
- 入力と対象を1件に限定する
上の仮メモのように、秘密情報を含まない短い入力を用意してください。試験データソースのIDとスキーマを再確認し、自動処理が作成に反応する設定も先に把握しましょう。
- 同じメモキーの既存ページを検索する
同じデータソースをDatabase PageのGet Manyで検索し、MemoKeyのrich_textがresearch-test-001と完全一致する条件を指定してください。正常な検索の完了を確認し、0件の場合だけ次のCreateへ進みます。1件・複数件・エラーなら作成を止め、後の結果別表で照合してください。
- Database PageのCreateを設定する
Notionノード3のData Sourceに確認済みの対象を指定しましょう。Titleと型付きプロパティを対応させ、不要な本文追加やテンプレート適用を重ねずに1件で試してください。
- 返ったpage_idとメモキーを控える
Createの応答から作成ページのIDを取り出します。data_source_idと混ぜず、memo_keyとの対応を保持しましょう。
- 同じIDでGetして照合する
Database PageのGetで作成ページを取得してください。親データソース・MemoKey・タイトル・保存値を照合し、違いがあれば後続更新を止めます。
親や型を確認するときは、必要な情報を失う出力の簡略化にも注意しましょう。Simplifyを使用して確認項目が見えない場合は、簡略化していない応答等で親とプロパティを確認してください。画面上で同名メモが見つかったというだけでは、今作成したページを特定したことにはなりません。
更新前に、ページの親と安定キーを照合する
次に更新するのは、保持したpage_idの同じページです。Getの結果で想定する親データソースとMemoKeyが一致し、自分が更新してよい対象であることを確かめてください。
更新の説明用例
research-test-001のSummaryを「追記した調査要点」へ変える場面を考えます。更新対象はSummaryだけにし、同じpage_idで要約が変わる一方、Source・Checked・Statusは変わらないことを読み戻して確かめましょう。
タイトル一致や検索先頭だけで更新先を選ばないでください。親やキーが違う、候補が複数ある、別の人が新しい内容へ編集している場合は、書き込まずに差分を確認しましょう。
Database PageのUpdateは、指定ページのプロパティ更新です。親の移動やページ本文の全置換まで一度に行う操作とは分けてください。更新前の値は、誤りが見つかったときに何を戻せるかを判断する材料です。
再実行では、同じメモキーの0件・1件・複数件を分ける
同じ入力をもう一度流すとき、毎回Createを通すだけではページが増えます。保存先でMemoKeyを照合し、既存の1件を更新するか、新規作成するかを分けましょう。
| 検索結果 | 次に行うこと | 進める条件 |
|---|---|---|
| 正常に検索できて0件 | 新規作成の候補にする | 正しいデータソース・キー条件で検索が完了している |
| 1件 | 取得したpage_idで対象確認後、必要項目だけ更新 | 親・MemoKey・所有範囲が一致し、他者の編集と競合しない |
| 複数件 | 書込を止め、正しい管理対象を確認 | 先頭の1件を勝手に選ばない |
| エラー・取得途中・保存結果不明 | 新規作成へ流さず、取得や保存済み状態を調べる | 未取得を0件に変換しない |
検索にはDatabase PageのGet Manyを使い、MemoKeyのrich_textがresearch-test-001と完全一致する条件を設定してください。主例の小さな試験台帳では、絞り込みを確認したうえでReturn Allを有効にし、一致する結果を取得します。
Limitを1にした結果だけでは、1件しか存在しないとは判定できません。途中までの一覧、エラーや不完全な結果を、正常な0件・1件へ読み替えないでください。大きな台帳では無制限取得へ広げず、ページ分割・APIの取得制約と必要な判定方法を先に設計しましょう。
このrich_textのキーに、一意制約や原子的なupsertがあるわけではありません。二つの実行が同時に「0件」と判断すれば、それぞれ作成する競合が起こり得るため、主例は入力1件・直列の試験に限定してください。並列運用の排他や保存の厳密な一度だけ処理は、別の設計が必要です。
検索0件と、取得できなかった状態を混ぜない
検索が0件だと、ノードから後段へ渡るitemがなくなる構成があります。Always Output Data等で空の出力を維持する場合も、空のplaceholderは実ページ1件ではありません。
元のメモ入力は検索前のノードに保持し、実ページIDの件数と別に管理しましょう。空itemが1個あることと、Notionに一致ページが1件あることを区別してください。接続エラーを継続扱いにして、0件の経路へ流す方法も避けます。
作成の応答が返らなかったときも、未保存とは決められません。Notionの書込503でadditional_data.committed_resource_idが返る場合は、そのIDで取得して確認してください。retry_guidanceに再送しない指示があれば従い、IDや指示がない場合もメモキーと現在の保存状態を照合してから判断しましょう。
試験を完了する前の確認点
- 作成したページの親データソース・MemoKey・値が意図と一致
- page_idとメモキーの対応を保持
- 更新は同じページの指定項目だけが変わり、他の値は保持
- 検索0件・複数件・未取得・保存応答不明を別に判定
- 同じ入力の直列再実行で、同じメモが増えないことを確認
あわせて読む：n8nの重複除去｜比較キーと履歴の使い分け
入力item同士の重複や、過去実行との比較で何を同じと扱うかを整理できます。Notionに既存するページの確認と、n8n内の重複除外を取り違えずに組み合わせたいときに役立つ記事です。
あわせて読む：n8nのIF・Switch・Filterの違いと条件分岐の作り方
0件・1件・複数件・エラーの経路を分け、未一致のデータを止める設計を確認できます。検索件数の定義とNotionの対象照合は、本稿の条件を保ったまま設定してください。
エラーと誤更新は、再送する前に切り分ける
エラーごとに直す場所と再試行の安全性が異なります。特にCreateの応答不明は、単にもう一度実行する前に保存済みかを確認しましょう。
| 応答・症状 | 先に確認すること | 次の行動 |
|---|---|---|
| 401 | Credentialの有効性と設定先 | 認証設定を直してから再試験 |
| 403 | 操作能力・対象共有・ワークスペース制限とエラー本文 | 示された制限を解消し、待つだけの再試行はしない |
| 400 | プロパティ型、値、ID、API版 | 不一致を直し、短い入力で再試験 |
| 429 | additional_data.rate_limit_reason | public_api_request_blockedなら再試行せず、管理者やNotion窓口へ確認 |
| その他の429・一時過負荷529 | Retry-Afterと、他の処理も含めた送信量 | 指定時間以上待ち、回数上限を設けて再試行 |
| 書込503・タイムアウト | 保存済みの状態、retry_guidance、作成ID等の追加情報 | Createを無条件に再送しない。取得して結果を照合 |
Notionの制限は、接続・ワークスペース・プラン・エンドポイントの条件で異なります。「どの環境でも毎秒3件」と固定せず、応答のRetry-Afterや追加情報を優先してください。エラーを記録するときは、トークンや私的なページ内容を除き、対象操作・時刻・状態・必要な手掛かりに絞りましょう。
実行停止と、Notionの内容を戻す操作を分ける
n8nのワークフローを止めたり旧版へ戻したりしても、すでにNotionへ保存した内容は自動で取り消されません。誤対象への書込に気づいたら、新しい書込を止め、作成したID・更新前の値・他者の編集を確認してください。
更新前の値を保持できている項目なら、現在の値との競合を確認して、その項目だけ戻す方法を検討します。新しく作った試験ページを整理する場合も、対象確認後の別操作として扱いましょう。ノード3のPageのArchiveはAPI 2026-03-11でin_trashを使うため、旧archivedの例を混ぜないでください。
整理用操作をCreateの直後へ自動追加する必要はありません。試験後は書込ノードを止め、保持したIDと前値の記録から、戻せた内容と残る影響を確認しましょう。
未対応の操作だけHTTP Requestへ分ける
主例の読取・作成・更新を組込Notionノードで実現できるなら、まずその対応operationを使います。旧ノードにData Sourceがない場合は、試験コピーでノード版の移行を確認し、それでも不足する操作だけHTTP Requestを検討してください。
直接APIを呼ぶ際は、HTTPメソッド・URL・入力に加え、Notion-Versionとdata_source_id等の親の意味をそろえましょう。認証はCredentialへ分け、トークンをヘッダー欄へ直書きしないでください。参照したn8nのCredential実装は既存のNotion-Versionを尊重し、未指定時だけ旧版の値を補うため、組込ノードと同じAPI版になると思い込まないことも必要です。
あわせて読む：n8nのHTTP RequestでAPIを呼ぶには
組込ノードにない操作を使うとき、メソッド・URL・認証・応答を一組で決める方法を確認できます。HTTPを使うこと自体を目的にせず、Notion側のAPI版と型の条件を明示して利用しましょう。
次に確認したいこと：n8nの運用費と設置基盤を選ぶ条件
処理量や管理負担から費用・Cloud・VPSを別に検討したい人向けの確認事項です。Notionへの1件保存のために、契約変更やVPS購入を必須にするものではありません。
まとめ｜対象と型を合わせ、1件の保存・更新・再実行を確かめる
n8nとNotionの連携では、接続の共有範囲とRead・Insert・Updateをそろえ、対象データソースの型に合う値を保存します。作成後のpage_idとメモキーを保持し、更新前の親・キー確認と保存後の読み戻しまで行ってください。
まずは試験台帳と短いメモ1件を決め、読取→作成→同じIDの更新→同じ入力の再実行、という順で期待結果を書きましょう。作成は1件、更新は同じページ、再実行しても同じメモが増えない状態を目標に、小さく確認する流れです。
保存量を増やす前に対象と型を合わせるほうが、誤更新の手掛かりを追いやすくなります。接続成功やノードの緑表示だけで終えず、「どこに何が残ったか」を確認点にする進め方が妥当です。
次に確認したいこと：ブログ制作のどの工程を人に残すか
調査メモを保存した後、記事制作の流れや確認担当まで広げたいときは、工程全体と人の確認箇所を整理できます。保存の成功を自動執筆・自動公開の成功と同一視せず、工程ごとの人の判断を整理しましょう。