はじめに：n8n MCPの役割が変わった
n8nの公式MCPサーバーが、かなり実務寄りの進化をしました。
これまでのn8n MCPは、主に「既存ワークフローをAIクライアントから実行する」ための入口という印象が強かったです。
しかし今回のアップデートで、Claude、Claude Code、Codex CLI、Cursor、Windsurf、ChatGPTなどのMCP対応クライアントから、n8nインスタンス内にワークフローを直接作成・更新できるようになりました。
従来のよくある流れはこうでした。
AIにn8nワークフローJSONを書かせる
↓
n8nにインポートする
↓
ノード設定や認証情報で壊れる
↓
エラーをコピーしてAIに戻す
↓
またJSONを貼り直す
今回の公式MCPでは、この往復がかなり短くなります。
AIエージェントに作りたい自動化を伝える
↓
エージェントがn8n Workflow SDKでワークフローを組む
↓
validate_workflowで検証する
↓
create_workflow_from_code / update_workflowでn8nに反映する
↓
必要に応じてtest_workflowで確認する
つまり、n8nが「AIで動かす自動化基盤」から、AIエージェントが直接編集できる自動化IDEに近づいたということです。
本記事は2026年5月6日時点の公式ブログ・公式ドキュメントを元にしています。n8n公式ブログでは、ワークフロー作成体験には 2.18.4 以上の利用が推奨されています。また、この機能はPublic Previewとして案内されているため、本番業務に使う場合はステージング用プロジェクトで検証してから反映するのが安全です。
まず整理：これは「MCP Server Trigger node」とは別物
n8nにはMCP関連の機能が複数あるため、ここは最初に分けておいた方がいいです。
今回の記事で扱うのは、Instance-level MCP serverです。
これは、外部のAIクライアントがn8nインスタンス全体に接続し、許可された範囲でワークフローを検索・実行・テスト・作成・編集するための機能です。
一方で、MCP Server Trigger nodeは、n8n上の特定ワークフローをMCPサーバーとして公開するためのノードです。
ざっくり言うと、こうです。
| 機能 | 役割 |
|---|---|
| Instance-level MCP server | Claude/Codexなど外部AIクライアントからn8nインスタンスを操作する |
| MCP Server Trigger node | n8nの1つのワークフローをMCPツールとして外部に公開する |
今回のアップデートで熱いのは前者です。
何ができるようになったのか
公式ドキュメント上のMCP tools referenceを見ると、ワークフロー管理、ワークフロービルダー、データテーブル操作のためのツールが用意されています。
特にワークフロー構築に関係するのは以下です。
| ツール | 役割 |
|---|---|
search_projects |
作成先プロジェクトを探す |
search_nodes |
利用できるノードを検索する |
get_suggested_nodes |
用途に合ったノード候補を取得する |
get_node_types |
ノードのTypeScript型定義を取得する |
validate_workflow |
SDKコードからワークフローとして妥当か検証する |
create_workflow_from_code |
検証済みコードから新規ワークフローを作る |
update_workflow |
検証済みコードで既存ワークフローを更新する |
prepare_test_pin_data |
テスト用のpin dataスキーマを準備する |
test_workflow |
外部サービスをpin dataで置き換えてロジックをテストする |
ここで重要なのは、AIがいきなり巨大なJSONを吐いてn8nに押し込むのではなく、TypeScriptベースのWorkflow SDKコードを生成し、検証してから反映する点です。
これにより、ノードのパラメータ名、型、接続関係のミスを、インポート後ではなく作成前に潰しやすくなります。
新しいワークフロー作成フロー
全体像はこうなります。
この流れのよいところは、AIが「作る」だけで終わらず、検証と修正のループまで同じ会話内で回せることです。
特にn8nは、ノードの設定項目が細かく、Gmail、Slack、HTTP Request、Set、Code、Ifなどで微妙に設定の癖が違います。
AIに「n8nっぽいJSON」を推測させるより、MCP経由でノード定義を取りに行かせる方が、かなり現実的です。
セットアップの流れ
1. n8nを更新する
公式ブログでは、ワークフロー作成用途では 2.18.4 以上が推奨されています。
Cloud版なら管理画面側の更新状況を確認します。セルフホストなら、Docker imageやnpmパッケージを更新してから試すのがよいです。
2. Instance-level MCPを有効化する
n8nの管理画面で以下に進みます。
Settings
↓
Instance-level MCP
ここでMCPアクセスを有効化し、接続情報を取得します。
認証方法は主に以下です。
| 方法 | 向いているケース |
|---|---|
| OAuth2 | Claude Desktopなど、OAuth対応クライアントで使う |
| Access Token | Claude Code、Codex CLI、Google ADKなどに設定する |
Access Tokenは秘密情報です。記事、GitHub、Slack、スクリーンショット、Qiitaの下書きに貼らないようにしてください。特に ~/.codex/config.toml や claude.json に直接書く場合、リポジトリ管理外に置くことを確認してください。
3. Claude Desktopで接続する場合
Claude Desktopでは、SettingsまたはConnectorsからn8n MCPを追加します。
手順はシンプルです。
- Claude DesktopのConnectorsを開く
- n8n MCPを追加する
- n8n側に表示されるMCP Server URLを入れる
- OAuth認証する
チャットUIで軽く試すならClaude Desktopでも十分ですが、公式ブログでは、複雑なワークフロー作成にはClaude Codeのようなコーディングエージェントの方が良い結果になりやすいと紹介されています。
4. Claude Codeで接続する場合
Claude Codeでは、公式ドキュメントにあるようにHTTP transportでMCPサーバーを追加します。
claude mcp add --transport http n8n-mcp https://<your-n8n-domain>/mcp-server/http \
--header "Authorization: Bearer <YOUR_N8N_MCP_TOKEN>"
5. Codex CLIで接続する場合
Codex CLIでは、~/.codex/config.toml にMCPサーバーを追加します。
[mcp_servers.n8n_mcp]
url = "https://<your-n8n-domain>/mcp-server/http"
http_headers = { "authorization" = "Bearer <YOUR_N8N_MCP_TOKEN>" }
Codexを日常的に使っているなら、この接続はかなり相性がいいです。
n8nのUIを見ながら人間がざっくり設計し、Codex側に「この要件でワークフローを作って、検証して、テストまで回して」と頼めるからです。
既存ワークフローを見せるには明示的に許可する
Instance-level MCPを有効にしても、すべての既存ワークフローが丸見えになるわけではありません。
既存ワークフローをMCPクライアントから扱いたい場合は、対象ワークフローごとに Available in MCP を有効化します。
方法は複数あります。
- Instance-level MCP画面から有効化する
- ワークフローエディタの設定から有効化する
- ワークフロー一覧のメニューから有効化する
また、ワークフローには説明文を付けておくのがおすすめです。
AIエージェントは、人間のように「あの青いアイコンのやつ」「先月作ったSlack通知っぽいやつ」とは探せません。
請求書PDFを受け取り、OCRして、Notion DBに登録し、Slackへ通知するワークフロー のような説明があると、検索・更新対象を間違えにくくなります。
コピペ用：n8n MCPでワークフローを作るプロンプト
最初は「いい感じに作って」ではなく、かなり明示的に指示した方が安定します。
以下は、Codex CLIやClaude Codeに投げる前提のプロンプト例です。
n8n MCPを使って、以下のワークフローを新規作成してください。
目的:
毎朝7:00 JSTに今日の天気を取得し、Gmailで自分に送信する。
作成先:
- Project: MCP Server testing
- Workflow name: Daily Weather Mail
利用したいノード:
- Schedule Trigger
- HTTP Request
- Set または Edit Fields
- Gmail
制約:
- できるだけCodeノードを使わない
- タイムゾーンはAsia/Tokyo
- Gmail本文はGmailノード側のテンプレートで整形する
- HTTP Requestの認証が必要な場合は、手動設定が必要な箇所を最後に報告する
- ワークフローには1〜2文のdescriptionを付ける
作業手順:
1. search_projectsで作成先Projectを確認する
2. search_nodes / get_suggested_nodesで使うノードを確認する
3. get_node_typesで必要なノード定義を取得する
4. Workflow SDKコードを生成する
5. validate_workflowで検証し、失敗したら修正する
6. create_workflow_from_codeで作成する
7. prepare_test_pin_dataとtest_workflowで可能な範囲のテストを行う
8. 最後に、作成したURL、ノード一覧、手動設定が必要な項目を報告する
このプロンプトのポイントは、何を作るかだけでなく、どう作ってほしいかも指定していることです。
n8nに慣れている人ほど、ここを明確にした方がいいです。
たとえば以下は、最初に指定しておくと事故が減ります。
- Codeノードを使ってよいか
- ネイティブノードを優先するか
- GmailとSMTPのどちらを使うか
- HTTP Requestと専用ノードのどちらを使うか
- タイムゾーンを固定するか
- 本文整形をCodeノードでやるか、Gmailテンプレート側でやるか
- 既存ワークフローを更新する前に最新版を読み直すか
実務で一番変わるのは「初回作成」より「会話しながらの改善」
このアップデートの価値は、単に「AIがワークフローを作れる」ことではありません。
本当に大きいのは、一度作ったワークフローを、同じ会話の中で自然に改善できることです。
たとえば、AIが最初の版でCodeノードを多用したとします。
その場合、こう返せます。
このワークフローはCodeノードが重すぎます。
可能な限りSet、If、Gmailテンプレート、HTTP Requestの標準機能に寄せて、
Codeノードを削減してください。
更新前に現在のワークフローを読み直し、validate_workflowしてからupdate_workflowしてください。
従来なら、JSONを再生成してインポートし直す必要がありました。
MCP経由なら、エージェントが既存ワークフローを読んで、差分を作り、検証して、更新できます。
これは「AIで一発生成」ではなく、AIとペアでn8nを設計する体験に近いです。
ただし、何でも任せていいわけではない
ここは強く言っておきたいです。
n8n MCPが便利になっても、AIが業務要件の責任まで引き受けてくれるわけではありません。
特に本番ワークフローでは、以下は人間がレビューすべきです。
| 観点 | 見るべきこと |
|---|---|
| 認証情報 | 想定外のcredentialが自動割当されていないか |
| 外部API | HTTP RequestのURL、メソッド、ヘッダー、リトライ方針が正しいか |
| データ破壊 | Update/Delete系ノードが安全な条件付きになっているか |
| 重複実行 | idempotency keyや重複チェックがあるか |
| エラー処理 | Error Trigger、失敗通知、再実行方針があるか |
| コスト | LLM/API呼び出しがループ内で爆発しないか |
| 個人情報 | メール本文、顧客情報、添付ファイルを不要にLLMへ送っていないか |
AIがワークフローを作れるようになったからこそ、人間の仕事は「ノードを置くこと」から「失敗条件を設計すること」に移ります。
公式ブログから読み取れる運用のコツ
公式ブログで紹介されていたTipsは、実務でもかなり納得感があります。
私なら以下のルールで運用します。
1. チャットよりコーディングエージェントを使う
簡単な検証ならClaude Desktopのチャットでもよいです。
ただ、ワークフロー作成はTypeScriptコード生成、検証、修正、テスト結果の読み取りが入ります。
そのため、Claude CodeやCodex CLIのようなコーディングエージェントの方が向いています。
2. ノード選定をAIに丸投げしない
「通知して」だけだと、Slack、Email、Gmail、SMTP、Webhookなど、候補が複数あります。
AIは推測します。そして、たまに外します。
実務では最初からこう書いた方がいいです。
通知はSlackノードを使ってください。
メール送信はSMTPではなくGmailノードを使ってください。
データ整形はCodeノードではなくSetノードを優先してください。
3. 80%合っていたら作り直さず、同じ会話で直す
AIに作り直させると、前回の良かった設計まで失うことがあります。
特にn8n MCPでは、既存ワークフローを読んで更新できるので、最初から作り直すより、同じ会話で差分修正した方がよいです。
4. UIで手動変更したら、必ず「最新版を読んで」と言う
人間がn8n UIでノードを直した後、そのことをAIに伝えないまま更新させると、手動変更が上書きされる可能性があります。
これはかなり現実的な事故です。
n8n UIでGmailノードの宛先とテンプレートを手動修正しました。
update_workflowする前に、必ず現在の最新版を読み直してください。
この一文は習慣にした方がいいです。
私ならこう使う
私が実務で使うなら、いきなり本番ワークフローを作らせません。
以下のように段階を分けます。
AIに任せる範囲は、以下です。
- 初期ノード配置
- 単純なデータ整形
- 条件分岐のたたき台
- descriptionの作成
- pin dataによるロジックテスト
- Codeノードの削減提案
人間が持つべき範囲は、以下です。
- 本番データの意味
- 削除・更新系処理の許可条件
- 認証情報の扱い
- SLA、リトライ、通知設計
- どこまで自動化し、どこに承認を挟むか
ここを分けないと、「AIが作ったワークフローが動いた」だけで満足してしまいます。
でも業務自動化で大事なのは、動くことではなく、壊れ方が設計されていることです。
まとめ：n8nはAIエージェントの「手」になった
今回のn8n公式MCPアップデートは、かなり大きいです。
今までは、AIがn8nワークフローを作るといっても、実態は「JSONを生成して、人間がn8nに貼る」でした。
これからは違います。
AIエージェントがn8nに接続し、ノード定義を読み、SDKコードを書き、検証し、ワークフローを作成・更新し、テストまで回す。
つまり、n8nはAIエージェントにとって、実際に手を動かせる自動化ランタイムになりました。
ただし、これは人間が不要になるという話ではありません。
むしろ逆です。
ノードを並べる作業がAIに寄るほど、人間は「何を自動化するべきか」「どこで止めるべきか」「失敗した時に誰へ通知するか」を設計する必要があります。
AIはワークフローを作れる。
でも、業務の責任境界を決めるのは人間です。
ここを守れるなら、n8n MCPは自動化エンジニアにとってかなり強力な武器になります。
参考リンク
この記事を書いた人✏️@YushiYamamoto
株式会社プロドウガ CEO / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。