n8n 2.36.0 — 破壊的変更3件（Array.merge 廃止・認証情報作成の team project 限定・重複トリガー ID の拒否）と Agent 周りの大型更新

要約

n8n 2.36.0 が 2026-08-18 にリリースされました。Agent 周りの機能追加が中心の回ですが、実務上いちばん重要なのは破壊的変更が3件同時に入っている点です。

1つ目は式（expression）の Array.merge の廃止です。代わりに Array.mergeIntoObject が追加されました。既存ワークフローの式に Array.merge を使っている場合、書き換えが必要になります。式の中に埋まっているため、ワークフロー一覧を眺めても見つかりません。

2つ目はエンドユーザーによる認証情報（credential）の作成が team project 内に限定されたことです。個人スコープで認証情報を作らせる運用をしていた組織は、権限設計の見直しが要ります。「今まで作れていた人が作れなくなる」形の変更なので、問い合わせが来てから気づくパターンになりやすい部分です。

3つ目は durable poller が重複したトリガーノード ID を持つ場合に有効化を拒否するようになったことです。ワークフローを複製して使い回している環境では、重複が潜んでいる可能性があります。

機能面は Agent 周りが中心です。新規 agent のモデルが妥当な既定値で自動選択されるようになり、MCP server のツールを skill builder から使えるようになりました。agent サンドボックスが principal 単位で実行を分離するようになったのはセキュリティ上の変更で、複数の利用者が同じ n8n インスタンスで agent を動かす環境に効きます。Agent Knowledge が n8n Sandbox に対応し、agent 向けの Slack 連携チャネルも追加されました。

ワークフロー運用では、**Schedule Trigger がダウンタイム後のキャッチアップ実行をまとめる（coalesce）**ようになりました。停止から復帰したときに溜まった実行が一斉に走る問題への対処です。猶予期間付きの未実行ハンドリングも追加されています。MCP 経由でのデータテーブル行の読み取り、フォルダ作成、ワークフロー移動も可能になりました。パッケージエクスポートではワークフローのバージョンポリシーを保持できます。

API 側はロール管理エンドポイント（一覧、個別取得、ロールマッピング規則の作成、カスタムロールの更新）が追加されました。ノードでは Discord にメンバーモデレーション操作、Confluence Cloud に OAuth2 資格情報とページ取得が入り、Google Ads ノードが API v21 から v25 へ移行しています。

なお 2.36.0 の前後で n8n@2.36.2、n8n@2.35.4、n8n@2.35.3、n8n@1.123.73（1.x backport）も出ています。

何が変わったか

破壊的変更（3件）

• 式の Array.merge を廃止。Array.mergeIntoObject を追加
• エンドユーザーによる認証情報の作成を team project 内に限定
• durable poller が重複したトリガーノード IDを持つ場合、有効化を拒否

Agent

• 新規 agent のモデル既定値を自動選択
• skill builder から MCP server のツールを利用可能
• agent サンドボックスが principal 単位で実行を分離
• Agent Knowledge が n8n Sandbox に対応
• agent 向けの Slack 連携チャネルを追加

ワークフロー運用

• Schedule Trigger がダウンタイム後のキャッチアップ実行を集約（coalesce）
• 猶予期間付きの未実行ハンドリング
• MCP 経由でのデータテーブル行の読み取り、フォルダ作成、ワークフロー移動
• パッケージエクスポートでワークフローのバージョンポリシーを保持

API / ノード

• ロール管理 API（一覧 / 個別取得 / ロールマッピング規則の作成 / カスタムロールの更新）
• Discord: メンバーモデレーション操作
• Confluence Cloud: OAuth2 資格情報とページ取得
• Google Ads: API v21 → v25 へ移行

業務インパクト（一般企業向け）

2.36 系へ上げる前に、3つの棚卸しが必要です。

第一に、式の中の Array.merge の使用箇所です。ワークフロー定義をエクスポートして文字列検索するのが確実で、画面を目視で追う方法では抜けます。件数が多い場合は、アップグレードそのものをステージング環境で先に通して、失敗するワークフローを洗い出すほうが早い場合もあります。

第二に、認証情報の作成スコープです。誰が認証情報を作れる想定なのか、いま実際に誰が作っているのかを突き合わせます。個人スコープでの作成を前提にした運用をしていた場合、team project の設計から見直すことになります。**この変更は「権限を絞った」方向なので、絞られた側から問い合わせが来ます。**アップグレード前に対象者へ周知しておかないと、切り替え当日にヘルプデスクが詰まります。

第三に、durable poller を使っているワークフローのトリガーノード ID の重複です。ワークフローの複製を運用の主軸にしている環境では起きやすい形です。

Google Ads ノードの API v21 → v25 移行にも注意が要ります。2026-08-14 の 2.34.6 で Google Ads / Microsoft Teams ノードの API sunset 対応が入っており、これと同じ系列の変更です。依存先の API の世代交代が、n8n 側の破壊的変更として降ってくる構造になっているため、外部 API に依存するノードを使っている場合はリリースノートを読む習慣が要ります。

一方でプラス側の変更として、agent サンドボックスの principal 単位分離は、複数部署で1つの n8n インスタンスを共有している組織にとって意味のある強化です。ロール管理 API の追加も、権限付与を人手で回している運用を自動化する足がかりになります。Schedule Trigger のキャッチアップ集約は、メンテナンス明けに実行が殺到して二次障害になる、という典型的な事故を減らします。

副業・個人活用視点

n8n で受託の自動化を組んでいる場合、今回の破壊的変更3件はそのまま保守案件になります。特に Array.merge の廃止は、納品済みのワークフローが顧客側のアップグレードで止まる形なので、先回りして連絡を入れる価値があります。「アップグレードしたら動かなくなった」と言われてから調べるのと、事前に「この変更が来るので確認します」と言うのとでは、同じ作業でも受け取られ方が違います。

自分の環境で n8n を回している場合は、アップグレード前にワークフロー定義を全部エクスポートして Array.merge を検索するだけで、事故の大半は防げます。5分で終わる作業です。

機能追加のほうでは、skill builder から MCP server のツールを使えるようになった点が個人利用でも効きます。n8n を「ノードを並べる自動化ツール」ではなく「agent の実行基盤」として使う方向が、これで一段実用に近づきました。MCP 経由でのデータテーブル操作やフォルダ作成が入ったことで、n8n の中で完結する範囲も広がっています。

agent 向けの Slack チャネル追加は、個人事業でも使いどころがあります。Slack に常駐させて、案件の問い合わせを一次受けさせる、といった構成が組みやすくなりました。ただし agent サンドボックスの principal 単位分離が入ったばかりの領域なので、外部からの入力を受ける構成にする場合は権限の範囲を慎重に決めてください。

なお n8n は 2026-08-19 付で日次巡回から週次確認ソースへ移りました。マイナーアップデートが多く日次で追う必要が薄いという判断ですが、2.36.0 のような破壊的変更を含む回は週次でも見落とせません。バージョンを上げる前にリリースノートを読む、という原則は変わりません。