はじめに：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で発信しています。