n8nのWebUIを開くのが、地味にしんどい。
ワークフローが25本を超えたあたりから、ブラウザでポチポチやるのが苦痛になってきた。ノードをドラッグして、設定画面を開いて、JSONを手で貼って、テスト実行ボタンを押して——1本のWFを修正するのに、画面遷移だけで5回は必要になる。
ある晩、npx n8n-mcp という1行を見つけた。n8nの公式MCP。Claude Codeから直接n8nを操作できるらしい。
試した。世界が変わった。
n8n MCPとは何か
n8nが公式に提供するMCPサーバーだ。Claude Code、Cursor、その他MCP対応ツールからn8nのAPIを叩ける。インストールはnpx一発。
できることは大きく分けてこのあたり：
| カテゴリ | ツール | やること |
|---|---|---|
| WF管理 | list / get / create / update / delete | ワークフローのCRUD |
| 実行 | test / executions | テスト実行・実行履歴の取得 |
| バージョン | workflow_versions | 変更履歴の管理 |
| 修正 | autofix | エラーの自動修正 |
| 検証 | validate | WF構造の検証 |
| テンプレ | search_templates / deploy_template | 公式テンプレートの検索・デプロイ |
全部で21ツール。正直、WebUIでやっていたことの8割はカバーされている。
セットアップ
Claude Codeの設定ファイル（.claude/settings.json）にMCPサーバーとして追加する。
{
"mcpServers": {
"n8n-mcp": {
"command": "npx",
"args": ["-y", "n8n-mcp"],
"env": {
"N8N_BASE_URL": "https://your-n8n-instance.example.com",
"N8N_API_KEY": "n8n_api_xxxxxxxxxxxxxxxx"
}
}
}
}
APIキーはn8nの Settings → API で生成する。VPS上のn8nなら、URLはそのVPSのドメインかIPを指定する。ローカルで動かしているなら http://localhost:5678 だ。
設定したらClaude Codeを再起動するだけ。npxが自動でパッケージを取得してくれるので、事前インストールは不要。
最初にハマったこと
APIキーを設定したのに接続できない。30分悩んだ。
原因は単純だった。セルフホスト版のn8n側で「API」機能が有効になっていなかった。Docker環境の場合、環境変数に N8N_PUBLIC_API_ENABLED=true を追加する必要がある。n8n cloudを使っている場合はデフォルトで有効なので関係ない。セルフホスト版だけの罠だ。ドキュメントの奥の方に小さく書いてあった。
# docker-compose.yml
environment:
- N8N_PUBLIC_API_ENABLED=true
これだけで動く。だがこの1行を見つけるまでの30分は返ってこない。
実践：WFの一覧取得と中身の確認
接続できたら、まずは既存WFの確認から。
「n8nのワークフロー一覧を見せて」
これだけでClaude Codeが n8n_list_workflows を叩いて、全WFのID・名前・ステータス（active/inactive）を返してくれる。
特定のWFの中身を見たいときは：
「WF "API監視Bot v2" の詳細を見せて」
ノード構成、接続関係、各ノードの設定値がJSONで返ってくる。WebUIで1ノードずつクリックして確認していたのが、一覧でまるっと見える。
ここで気づいたのだが、WFの全体構造を俯瞰するのは、テキストの方がUIより速い。ノードの接続関係が一目で見えるし、設定値の比較もgrepできる。UIだとノードを1個ずつ開かないと設定値が見えない。まさかテキストの方が「見やすい」とは思わなかった。
実践：WFの作成
新規WFの作成。ここがn8n MCPの真骨頂だ。
「Chatwork APIを5分おきにポーリングして、未読メッセージがあったらSlackに転送するn8n WFを作って」
Claude Codeが以下のような流れで動く：
-
search_templatesでChatwork関連のテンプレートを探す - テンプレートがなければ、
n8n_create_workflowでゼロからWFを組む - 各ノード（Schedule Trigger → HTTP Request → IF → Slack）の設定をJSONで生成
-
n8n_validate_workflowで構造を検証 -
n8n_test_workflowでテスト実行
自然言語で「こういうWFが欲しい」と言うだけで、ノードの組み立てからテスト実行まで一気にやってくれる。手でやったら20分かかる作業が、3分で終わる。
作成時の注意点
思うに、ここが一番ハマりやすいポイントだ。
認証情報（Credentials）はMCPから作れない。WF内でHTTP Requestノードを使う場合、APIキーやOAuthトークンはn8nのWebUIから事前に登録しておく必要がある。MCPで作成したWFがCredentialを参照する場合、そのCredential IDを指定する。
つまりフローはこうなる：
[事前準備] WebUIでCredentialを登録 → IDをメモ
↓
[MCP] WF作成時にCredential IDを指定
「全部CLIでやりたい」という気持ちはわかる。俺もそう思った。でもCredentialには秘密鍵やトークンが含まれるので、WebUIの暗号化ストレージに入れる方が安全だ。ここは割り切っている。
実践：既存WFの修正とバージョン管理
25本もあると、「あのWFのあのノード、設定値いくつだっけ」が頻発する。
「"エラー通知WF" のHTTP Requestノードのタイムアウト値を30秒から60秒に変更して」
MCPが n8n_get_workflow でWFを取得し、該当ノードの設定を書き換え、n8n_update_full_workflow で保存する。差分だけを変えてくれるので、他のノードに影響しない。
変更前の状態は n8n_workflow_versions で確認できる。n8nにはバージョン管理機能があるので、「3つ前のバージョンに戻して」もできる。gitのように使える。
一括修正が効く
ここからが面白い。正直、これには助かった。
「全WFのHTTP Requestノードで、タイムアウトが10秒以下のものを一覧にして」
こういう横断検索はWebUIでは不可能だ。25本のWFを1本ずつ開いて、ノードを1つずつ確認する——考えただけで帰りたくなる。MCPなら全WFをループで取得して、JSONの中身をフィルタするだけ。5秒で終わる。
同僚のCが「タイムアウト10秒だと夜間バッチで落ちるから全部30秒にしてくれ」と言ったとき、5分で全WFの修正が終わった。WebUIなら1時間コースだった。
実践：テスト実行と実行履歴
修正したWFが正しく動くか確認する。
「"エラー通知WF" をテスト実行して」
n8n_test_workflow が実行され、各ノードの出力がJSONで返ってくる。成功・失敗・スキップの状態がノードごとに見えるので、どこで詰まったかがすぐわかる。
過去の実行履歴も取れる：
「"API監視Bot" の直近10件の実行履歴を見せて」
n8n_executions が実行時刻・ステータス・実行時間を返す。「昨日の夜、3回失敗してるな」が一目でわかる。
テスト実行の落とし穴
一つ注意がある。n8n_test_workflow はWFを実際に実行する。テスト用のモックモードではない。
つまり、Chatworkに通知するWFをテスト実行したら、本当にChatworkにメッセージが飛ぶ。本番のAPIを叩く。最初にこれをやらかして、テスト用のメッセージが本番ルームに投稿された。深夜2時に。
[テスト] n8n MCP動作確認
という投稿を見た同僚が「何事？」とリアクションしてくれた。申し訳ない。
対策は簡単で、テスト用のWFは通知先をテスト用ルームに向けておくか、IFノードで {{ $env.NODE_ENV === 'test' }} のような分岐を入れておく。
autofixが地味に便利
WFを修正した後、構造がおかしくなることがある。ノードの接続が切れていたり、必須パラメータが抜けていたり。
「"エラー通知WF" を検証して、問題があれば自動修正して」
n8n_validate_workflow で問題を検出し、n8n_autofix_workflow で修正する。修正内容はdiffで返してくれるので、「何を直したか」が確認できる。
万能ではない。複雑なロジックの誤りは検出できない。だが、接続の断線やパラメータの型不一致といった「構造的な問題」はほぼ拾ってくれる。ちょっとしたlinterだ。
WebUIとMCPの使い分け
1ヶ月使ってみて、棲み分けが見えてきた。
| 作業 | WebUI | MCP |
|---|---|---|
| 新規WFを「見ながら」組む | ◎ | △ |
| 既存WFの設定値を修正 | △ | ◎ |
| 全WFの横断検索・一括修正 | × | ◎ |
| テスト実行 | ○ | ◎ |
| Credentialの登録 | ◎ | ×（未対応） |
| ノードの視覚的なデバッグ | ◎ | △ |
| バージョン比較 | △ | ◎ |
初めて組むWFは、WebUIでノードをドラッグしながら試行錯誤した方が速い。ビジュアルで確認できる安心感がある。
一方、既存WFのメンテナンス——設定変更・横断検索・一括修正・テスト実行——はMCPが圧倒的に速い。WFが増えれば増えるほど、差が開く。
まとめない
正直に言うと、AIの憲法を23,000語で書く人がいる時代に（Amanda Askellの件だ）、ワークフローを手でポチポチ作っているのが急にバカバカしくなった。それがn8n MCPを試したきっかけだった。
25本のWFをCLIから管理できるようになって、n8nの画面を開く頻度は半分以下に減った。「ブラウザを開かずにインフラを操作する」という感覚は、一度味わうと戻れない。
MCPの設定は5分。ハマりポイントは N8N_PUBLIC_API_ENABLED=true の1行。それだけで25本のWFがターミナルから操作できるようになる。