n8n MCP｜Claude Codeから自然言語でn8nワークフローを構築するMCPサーバー

この記事ではMCPに特化して解説します。MCP（Model Context Protocol）全般は MCPサーバーの作り方2026完全ガイド をご覧ください。

n8n MCPは、ローコード自動化ツールn8nの全ノード仕様をModel Context Protocol経由でAIに渡し、Claude CodeやCursorから自然言語でワークフローを組み立てさせるMCPサーバーだ。GitHub Daily Trending入りで19,728スター、商用ダッシュボード（n8n-mcp.com）も並走している。

「n8nのノードが多すぎてAIが正しく組めない」という従来の課題に対し、1650ノード分のスキーマと2352個のテンプレートをツールとして提供することで、AIが推測ではなく辞書を引きながら設計するアプローチを取っている。

n8n MCPとは — n8n × Model Context Protocolの橋渡し

n8nはノードベースのワークフロー自動化ツールで、Slack通知、GitHub連携、HTTPリクエスト、AIエージェント、データベース操作までを画面上のドラッグで結合できる。一方で、ノード数が1650個（コア820 + コミュニティ830）まで膨れ上がり、「どのノードでどう設定すれば良いか」を頭に入れるコストが急増していた。

n8n MCPは、このノード辞書をMCPサーバーとして公開する。AI側（Claude Code、Cursor、Windsurfなど）はMCPツールを通じて以下を取得・実行できる。

• ノード検索（search_nodes）
• ノード仕様の詳細取得（get_node — minimal/standard/full の3粒度）
• テンプレート検索（search_templates — 2352件、メタデータ・タスク・ノードタイプで絞り込み）
• ノード設定の検証（validate_node — minimal / full）
• ワークフロー全体の検証（validate_workflow — 接続・式・AIツール）
• n8nインスタンスへの書き込み（n8n_create_workflow / n8n_update_partial_workflow / n8n_test_workflow）

つまり「AIが知識として内蔵していない最新のn8nノードを、ツール呼び出しで毎回調べてから書く」構造を作っている。これは生のLLMが幻覚で生成したJSONを投げるアプローチとは根本的に異なる。

何ができるか — 設計から検証・デプロイまで

n8n MCPで自動化できる作業は大きく4段階に分かれる。

1. テンプレート検索（最初に試すべき）

公式コミュニティに登録された2352個のワークフローテンプレートから、目的に近いものを検索する。複雑度・所要時間・対象ユーザー・必要サービスで絞り込めるため、ゼロから設計するより圧倒的に早い。

2. ノード設計（テンプレートで足りない場合）

トリガー、ロジック、アクションの各ノードを search_nodes で探し、get_node でスキーマを取得する。AI（Claude）はこの段階で「どのプロパティが必須か」を機械可読に取得できるため、デフォルト値で動かしてランタイムエラー、という典型的な失敗を避けられる。

3. 検証（生成→実行の前に必ず通る）

n8n MCPの設計上、検証はワークフロー作成と同格の重要ツールだ。

• validate_node({mode: 'minimal'}) — 必須フィールドのみ確認（100ms以下）
• validate_node({mode: 'full', profile: 'runtime'}) — 修正提案つき
• validate_workflow — 接続グラフ・n8n式（`` など）・AIツール接続の総合チェック

これによりAIは生成→検証→修正のループを自分で回せる。READMEに「検証はAIに自分のミスに気づかせる」とある通り、エージェント的な使い方が前提だ。

4. デプロイ（n8n本体APIキー設定時のみ）

N8N_API_URLとN8N_API_KEYを環境変数で渡している場合、AIはn8nインスタンスに直接ワークフローを作成・更新・実行できる。n8n_update_partial_workflowは1呼び出しで複数操作（ノード追加、接続変更、削除）をバッチ処理できるよう設計されている。

アーキテクチャ — ノードDBとMCPツール

n8n MCPはNode.jsで動くMCPサーバー単体だが、内部に事前にビルドされたノード仕様データベースを抱えている。これがn8n MCPの肝だ。

ポイントは2つ。

1. ノードDBはオフラインで完結：AI ↔ n8n MCP のやり取りはローカルで動き、外部に「Slack通知のワークフローを作って」というプロンプトが流出しない。
2. n8n本体は任意：N8N_API_KEYを渡さなければドキュメント検索専用モードになり、生成したJSONを手動で取り込む運用も可能。

ドキュメントはn8n本体のリリースに48時間以内で同期される設計とされており、最新ノードが追加されてもAIが古い情報で組まないよう保たれている。

セットアップ — Claude Codeで30秒

最小構成（ドキュメントツールのみ）

claude mcp add n8n-mcp \
  -e MCP_MODE=stdio \
  -e LOG_LEVEL=error \
  -e DISABLE_CONSOLE_OUTPUT=true \
  -- npx n8n-mcp

/mcp コマンドで接続を確認できる。これだけでノード検索・テンプレート検索・検証ツール群が使える。

フル構成（n8n本体への書き込みあり）

claude mcp add n8n-mcp \
  -e MCP_MODE=stdio \
  -e LOG_LEVEL=error \
  -e DISABLE_CONSOLE_OUTPUT=true \
  -e N8N_API_URL=https://your-n8n-instance.com \
  -e N8N_API_KEY=your-api-key \
  -- npx n8n-mcp

プロジェクト共有用 .mcp.json

チームで設定を共有する場合は、リポジトリのルートに置く。

{
  "mcpServers": {
    "n8n-mcp": {
      "command": "npx",
      "args": ["n8n-mcp"],
      "env": {
        "MCP_MODE": "stdio",
        "LOG_LEVEL": "error",
        "N8N_API_URL": "https://your-n8n-instance.com",
        "N8N_API_KEY": "your-api-key"
      }
    }
  }
}

Cursor / Windsurf / VS Code

それぞれ専用ガイドが用意されている。設定方法は共通で、stdioでnpxを叩くだけ。AntigravityやCodexなど他のAI IDEでも動作する。

自前ホスト不要のクラウド版

公式はdashboard.n8n-mcp.comというSaaS版を提供しており、無料枠は1日100ツール呼び出し。npx経由でローカルに立てるのが嫌な場合や、最新ノードDBのメンテナンスを任せたいチームはこちらを使う。

実践ワークフロー — 自然言語からn8nへ

ケース1: Slack通知ワークフロー

Claude Code: 「Webhookを受けて、JSONの message フィールドを Slack #general に投げるワークフローを作って」

このとき内部で走る流れ。

ポイントはClaude Codeが自分で検証エラーを読み、修正してから再送すること。SlackノードでありがちなchannelId未指定やselectパラメータの欠落を、ランタイムではなく生成時に潰せる。

ケース2: GitHub Issue → タスク変換

GitHubのIssue作成WebhookをトリガーにしてLinearやAsanaにタスクを切るワークフローも、テンプレート検索 → 必要に応じてフィールド変換ノード追加 → 検証、というパターンで組める。

> Claude Code:
> 「GitHubのIssueがopenになったら、本文をLinearの新規タスクとして
>  起票するワークフローを作って。優先度はラベルから推定」

LLMが推論する箇所は「ラベル → 優先度マッピング」のロジックノード（n8n Code node、JavaScript）だけで、配線とノード設定はすべて辞書ベースで決まる。

ケース3: 既存ワークフローの差分更新

n8n MCPの強みのひとつがn8n_update_partial_workflowのバッチ操作。個別呼び出しより遥かに効率的だ。

n8n_update_partial_workflow({
  id: "wf-123",
  operations: [
    {type: "updateNode", nodeId: "slack-1", changes: {channelId: "C999"}},
    {type: "addConnection", source: "If Node", target: "True Handler",
     sourcePort: "main", targetPort: "main", branch: "true"},
    {type: "cleanStaleConnections"}
  ]
})

特にIFノードは2出力（true/false）を持つため、branchパラメータの省略がサイレントなロジックバグになりやすい。READMEでも明示的に注意喚起されている、よくある罠だ。

n8n単体（GUI）との比較

n8n MCPはn8n本体を置き換えない。両者の住み分けを理解しないと、AIに任せて事故るか、AIを使う意味がなくなる。

実運用では「土台はAIで生成、最終調整はGUI」の組み合わせが最も合理的になる。AIは1650ノードを横断する探索が得意で、GUIは数ピクセルのレイアウトや視覚的なデバッグが得意だからだ。

他のMCPサーバーとの比較

「特定アプリに自然言語で命令する」MCPサーバーは増えているが、対象領域と接続方式によって性格が大きく違う。

n8n MCPの位置づけは「広範な業務自動化に対するAIゲートウェイ」。TradingView MCPがチャート操作という縦の領域に深く特化するのに対し、n8n MCPはn8nが繋がる先のSaaS群（Slack, Google, GitHub, AWS, OpenAI…）すべてに横展開できる点で性格が異なる。

既存n8nワークフロー資産との統合

すでにn8n上に運用中のワークフローがある場合、n8n MCPの導入順序は以下の判断フローが分かりやすい。

n8nのテンプレートを大量に集めたawesome-n8nのようなコレクションと組み合わせると、既存テンプレートをn8n MCPに読み込ませてAIに改造させる、という運用も組める。データパイプラインや重いETLは別ツール側に寄せ、n8n側はSaaS連携と通知系のラストワンマイルに専念させる役割分担が現実的だ。

注意事項とトラブルシューティング

n8n MCPを導入したチームが踏みやすい落とし穴を整理する。

加えて、addConnectionは4つの引数（source / target / sourcePort / targetPort）を文字列で渡す必要がある。3引数で書くとSource not foundというミスリーディングなエラーが出るので、最初に1度だけハマる箇所だ。詳細はGitHub Issue #327に蓄積されている。

どんなチームに向くか

n8n MCPの効用は、チームの自動化成熟度によって違う。

• n8n初学者：ノード辞書をAIが代わりに引いてくれるため、最初の1ワークフローまでの時間が短くなる。テンプレート検索だけでも効果が大きい
• 既存n8nユーザー：単純な定型ワークフロー追加（Slack通知系、CRUD連携系）の生産性が伸びる。GUIでやっていた配線作業をAIに委ねられる
• 複雑ワークフローの保守チーム：n8n_update_partial_workflowのバッチ更新と検証で、レビューコストが下がる。差分操作をAIにまとめさせると、人手のヒューマンエラーが減る
• n8n運用がない、入れる予定もない：恩恵は薄い。Zapier/Makeなど別ツール派なら、それぞれに対応するMCPを探す方が良い

逆に、本番ワークフローを直接書き換えたい用途や、n8nを使わずスクリプトで全部書く文化のチームには合わない。

参照ソース

• czlonkowski/n8n-mcp — GitHub（19,728スター・MIT）
• n8n-mcp公式サイト
• n8n-mcp Claude Code Setup Guide
• n8n-mcp CLAUDE.md（推奨システムプロンプト）
• czlonkowski/n8n-skills（Claude Code用スキル拡張）
• Model Context Protocol公式ドキュメント
• n8n本体リポジトリ

この記事はAI業界の最新動向を速報でお届けする「AI Heartland ニュース」です。