n8nとNotionを連携する方法｜ノード設定と失敗から再開できるフロー

n8nでは、外部サービスから取った情報を整形し、Notionへ作成・更新する処理をノードでつなげられます。NotionノードにはページやDB行を扱う操作があり、足りない操作はHTTP RequestノードからAPIを呼ぶ方法もあります。n8n公式：Notionノード

この記事では、1件の入力を受け取り、同じ外部IDがあれば更新、なければ作成するフローを作ります。特に、検索結果が0件のときと、途中で失敗したときにどう動かすかを確認します。

NotionノードとHTTP Requestを使い分ける

Notionノードは、認証情報を共通化し、画面からプロパティを対応付けたい場合に便利です。HTTP Requestは、APIバージョンやレスポンスの形を明示して扱いたい場合に使います。

処理	今回使うノード	選ぶ理由
手動で起動	Manual Trigger	外部サービスをつなぐ前に確認する
入力データを作る	Edit Fields	1件の架空データで分岐を試す
外部IDを検索	HTTP Request	0件でも結果の配列を含むレスポンスを受け取る
件数で分ける	Switch	0件、1件、複数件を分ける
作成・更新	Notion	列の対応を画面で確認する
例外を止める	Stop And Error	重複等を成功扱いにしない

n8nのバージョンによってNotionノードの表示や対応操作が異なるため、インストール済みの版で確認してください。古いノードのDatabase ID入力と、現行APIのData Source IDを混同しないことも大切です。

認証情報を登録し、検証用DBへアクセスを与える

Notionに検証用DBを作り、「名前」をタイトル、「外部ID」をテキスト、「受付区分」をテキストとして追加します。内部コネクションに必要な読み取り・作成・更新権限を設定し、対象DBへのアクセスを与えます。

n8nではNotion用のCredentialを作成し、認証情報を登録します。ノードの本文やEdit Fieldsへトークンを置かず、Credentialを参照させます。内部コネクションとOAuthの設定方法は公式ガイドにまとまっています。n8n公式：Notionの認証

本番の受付DBをいきなり使わず、まず検証用DBが選択できるか、1ページ読めるかを確かめます。

1件の架空データを作る

Manual Triggerの後にEdit Fieldsを置き、ノード名を「入力を整形」にします。次の3つを文字列として設定します。

{
  "external_id": "demo-request-001",
  "title": "導入説明の相談",
  "category": "資料請求"
}

最初は1回に1件だけ流します。複数件の配列やループまで同時に加えると、どの入力がどの検索結果に対応したのかを追いにくくなるためです。

HTTP Requestで外部IDを検索する

次にHTTP Requestを設定します。認証はPredefined Credential TypeからNotionを選び、先ほどのCredentialを使います。接続先は次の形式です。

POST https://api.notion.com/v1/data_sources/{データソースID}/query

Notion-Version ヘッダーは 2026-03-11、Bodyの形式はJSONにします。最初の動作確認では、次の固定値を送ります。

{
  "filter": {
    "property": "外部ID",
    "rich_text": { "equals": "demo-request-001" }
  },
  "page_size": 2
}

page_size を2にするのは、0件・1件・複数件を見分けるためです。全件集計をする検索なら、別途ページ分割への対応が必要です。Notion API：データソースの検索

HTTP Requestは、レスポンス本文をJSONとして扱い、ヘッダーやステータスを追加する設定はこの例ではオフにします。検索結果は results 配列へ入ります。0件でも results: [] を含むオブジェクトが返るため、次の分岐へ進められます。

固定値で確認できたら、equals の値を「入力を整形」の external_id を参照する式に置き換えます。n8nの式では、たとえば {{ $('入力を整形').item.json.external_id }} のように前段ノードの値を参照できます。

0件なら作成、1件なら更新、複数件なら停止する

Switchで {{ $json.results.length }} を評価し、次の3経路へ分けます。

検索件数	接続する処理	主な入力
0	NotionのDatabase Page → Create	名前、外部ID、受付区分
1	NotionのDatabase Page → Update	results[0].id と更新する列
2以上	Stop And Error	同じ外部IDが複数あることを記録

作成・更新ノードの列には「入力を整形」の値を参照させます。検索後の $json はNotionのレスポンスなので、$json.title と書いても元の入力の件名は取れません。

更新側では名前と受付区分だけを変更し、Notionで担当者が書いた本文や対応メモは対象外にします。作成先を選べない場合は、権限に加えて、使用中のNotionノードがそのデータソースを扱えるかも確認します。必要なら作成・更新もHTTP Requestへ統一します。

NotionのGet Manyノードで検索する構成に変える場合は、0件時に後続ノードが動くかを確認してください。出力アイテムが0件なら下流へ進まない構成もあります。Always Output Dataを使う場合も、空のアイテムを「既存1件」と数えず、ページIDの有無で判定します。

AI分類を追加するなら、Notionへ書く前に値を検査する

基本の3経路が動いたら、問い合わせ本文から「資料請求」「導入相談」「その他」を選ぶAI処理を追加できます。配置する場所は、入力を整えた後、Notionへ書き込む前です。

AIには本文と分類基準を渡し、決めた項目で返すようにします。次は出力形式の設計例です。

{
  "category": "導入相談",
  "reason": "導入に必要な期間を質問している",
  "needs_review": false
}

AIの返答は、そのままNotionの状態へ入れず、JSONとして読めるか、分類が許可した3種類のどれか、確認要否が真偽値かを検査します。形式が違う場合は「要確認」へ回し、外部IDと原文はAIに作り直させません。AI呼び出しが失敗した依頼も、受付自体を失わないよう、未分類として処理待ちに残します。

分類結果に応じて通知先を分けることはできますが、分類できたことを返信済みや対応完了には置き換えません。AIを加える前後で、同じ入力が同じNotionページへ対応することを確かめてください。

実行履歴に残すのは、どこまで進んだか

初回実行でページが1つ作られたら、同じ external_id のまま件名を変えて再実行します。Notionの件数は増えず、同じページの名前が変わることを確かめます。

次に検証用DBへ同じ外部IDの行をもう1件作り、複数件の経路で停止することを確認します。確認後は検証用の重複を整理します。

実運用では、n8nの実行ID、外部ID、処理種別、NotionページID、失敗したノードを残します。入力本文やCredentialの値を、不要な通知先へ丸ごと送らないようにします。

Error Triggerで、失敗を確認できるようにする

別ワークフローの先頭にError Triggerを置き、メインのWorkflow SettingsからError workflowとして指定します。そこから管理用の記録や担当者への通知を行う構成にできます。n8n公式：エラー処理

Error Triggerは手動実行では起動せず、自動実行の失敗時に動きます。手動でエラーを確認した後、検証用の自動トリガーでも通知を確かめてください。n8n公式：Error Triggerの実行条件

書き込み後に通信が切れた場合は、Notion側では作成済みということもあります。再実行前に外部IDで検索し、更新経路へ進めるかを確かめます。複数実行が同時に「0件」と判定する競合もあるため、最初は処理が重ならない構成にします。

外部サービスをつなぐのは、3経路を確認してから

作成・更新・重複時の停止ができたら、Manual Triggerと架空データを、実際の受信処理や定期取得へ置き換えます。Webhookで受信するなら送信元の認証、定期取得なら取得済み位置の管理も追加します。

フローが動いたかだけでなく、入力1件がどのページへ反映され、失敗したらどこから再開するかまで見えることが、継続して使えるn8n連携の条件です。