2026.11.06 AI

n8n MCP：MCP Server TriggerとClient Toolの設定とAIに渡す権限の設計

n8nとMCPの組み合わせには、向きの違う入口が3つあります。n8nのワークフローをClaudeなど外部のAIから呼ばせるMCP Server Trigger、n8nのインスタンスそのものをMCPサーバーにするインスタンス単位のMCPアクセス、n8nのAIエージェントから外部のMCPサーバーを呼ぶMCP Client Toolです。選び方で、AIに渡る権限の広さが変わります。この記事では、各設定をClaude DesktopとClaude Codeへの登録例つきで示し、権限設計とセルフホストで接続が切れる原因まで、2026年11月6日時点の公式ドキュメントに沿って整理します。

まとめ：n8nのMCPは公開する入口の選び方とトークンの切り分けで決まる

特定の業務処理だけをAIに呼ばせるなら、MCP Server Triggerにサブワークフローをツールとしてつなぎます。開発者がClaude Codeなどからワークフローの検索・実行・編集まで行うなら、インスタンス単位のMCPアクセスが選択肢です。n8nのAIエージェントに社外のMCPサーバーを使わせる場合は、MCP Client Toolでツールを絞って渡します。

権限の要は、トークン1本で呼べる範囲を狭く保つことです。読み取り用と書き込み用でMCP Server Triggerを分け、社内利用者が呼ぶならn8n User Authで実行者を記録します。インスタンス単位のMCPアクセスは接続先クライアントごとに公開範囲を絞れないため、送信や削除を伴うワークフローは公開しない前提で運用してください。

n8nのMCP対応を3つの入口に分けて見るサーバー側とクライアント側の全体像

MCPの仕組み自体はMCP（Model Context Protocol）とは？仕組み・APIとの違い・MCPサーバーの作り方で解説しています。ここではn8nに固有の部分だけを扱います。

MCP Server Triggerとインスタンス単位のMCPアクセスの公開範囲の違い

どちらもn8nをMCPサーバーとして外部のAIから使わせる機能ですが、公開する単位が違います。

比較項目	MCP Server Trigger	インスタンス単位のMCPアクセス
公開する単位	トリガーにつないだツールだけ	MCP公開を有効にしたワークフロー
接続URL	ノード別のテスト用・本番用URL	インスタンスごとに1つ
認証	4方式（下記の認証方式を参照）	OAuth（推奨）または個人のAPI key
AIができること	公開したツールの呼び出し	検索・実行・作成・編集・公開など
主な利用者	業務担当者が使うAIクライアント	n8nを組む開発者のコーディングエージェント

表の公開設定は、ワークフローのAvailable in MCPをオンにする操作です。ノード別のURLはTest URLとProduction URLを指します。インスタンス共通の接続URLの末尾は/mcp-server/httpです。MCP Server Triggerの認証方式はNone・Bearer・Header・n8n User Authの4方式から選択します。

MCP Server Triggerの公式ページによると、このトリガーにつなげるのはツールノードだけで、トランスポートはSSEとStreamable HTTPに対応し、stdioには対応しません。一方のインスタンス単位のMCPアクセスは、ワークフローの作成や編集まで含むツール群を提供します。業務の窓口はServer Trigger、開発の道具はインスタンス単位、と分けて考えると選び間違えません。

MCP Client ToolとMCP Clientノードで外部サーバーを呼ぶ2つの形

逆向きに、n8nから外部のMCPサーバーを使う方法も2つあります。AI AgentノードのツールとしてつなぐのがMCP Client Toolで、どのツールを呼ぶかはモデルが決めます。モデルを介さず、ワークフローの1ステップとして特定のツールを決め打ちで呼ぶのがMCP Clientノードです。

MCP Clientノードは、毎朝決まったツールで在庫を取得するような定型処理に向きます。MCP Client ToolをAI Agentにつなぐときは、Tools to IncludeをAllにせず、Selectedで読み取り系だけを選ぶか、All Exceptで削除や送信のツールを外してください。AI Agentノード自体の組み方はn8n AIエージェント：AI Agentノードのツール接続と人の承認を挟む作り方にまとめました。

MCP Server Triggerの公開とClaude Desktopからの実行手順

n8nの導入方法と基本操作はn8nとは？読み方・料金・商用利用の範囲と3.0で変わる始め方を参照してください。ここでは、社員マスタを検索するサブワークフローをClaude Desktopから呼べるようにする例で進めます。

Call n8n Workflow Toolをつないでツール名と説明文を設定する手順

社員マスタを検索するサブワークフローを作り、Execute Sub-workflow Triggerで入力項目（例：employee_id）を定義して公開する
新しいワークフローにMCP Server Triggerを置く
トリガーのツール口にCall n8n Workflow Toolをつなぎ、SourceをDatabaseにして1のサブワークフローを選ぶ
Workflow Inputsのemployee_id欄で「Let the model define this parameter」を選び、値をAIに決めさせる
Descriptionに「社員IDから氏名・部署・上長を返す。退職者は返さない」のように、いつ使うツールかを書く

Call n8n Workflow Toolの公式ページのとおり、Descriptionはモデルがツールを選ぶ手がかりです。SourceをDatabaseにしたサブワークフローは、公開していないと本番の呼び出しでWorkflow is not active and cannot be executedが返ります。MCP Server TriggerのInstructions欄に書いた文は接続時にクライアントへ送られ、多くの場合システムプロンプトに加わります。ツール全体の使い方についての注意事項は、このInstructions欄に記載してください。

Claude DesktopのBearer認証とmcp-remoteの登録手順

Authenticationの既定はNoneで、URLを知っていれば誰でもツールを呼べる状態です。Bearer authを選び、推測できない長さのトークンを資格情報として登録します。Claude Desktopはstdio接続が前提のため、公式ページの例どおりmcp-remoteを中継に使います。

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<MCP Server TriggerのProduction URL>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<資格情報に登録したトークン>"
      }
    }
  }
}

トークンをargsに直接書かずenvに分けるのは、プロセス一覧や設定ファイルの共有で値が漏れる経路を減らすためです。

Test URLとProduction URLの使い分けとcurlによる初期化確認

Test URLは、エディターで「Listen for Test Event」か「Execute workflow」を押している間だけ受け付け、呼び出しの中身がキャンバス上に表示されます。Production URLはワークフローを公開すると有効になり、記録の確認先はExecutionsタブです。Claude Desktopに登録する前に、curlでMCPの初期化要求を送って経路と認証を確認しておくと、切り分けが速く済みます。

curl -sN -X POST "<Production URL>" \
  -H "Authorization: Bearer $N8N_MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl-check","version":"0.1"}}}'

応答にserverInfoとcapabilitiesが返れば、プロキシと認証は通っています。401や403ならトークン、404ならワークフローが公開されているか、応答が途中で止まるならプロキシのバッファリングを確認してください。SSEとStreamable HTTPの違いはStreamable HTTPとは？MCPのトランスポートとSSEの違いで詳しく扱っています。

インスタンス単位のMCPアクセスを有効にしてClaude Codeから接続する設定

n8nを組む開発者が、コーディングエージェントからワークフローを探して実行し、修正まで任せたい。この用途にはインスタンス単位のMCPアクセスが合います。

Instance-level MCPの有効化とワークフローごとの公開設定

Settings > Instance-level MCPを開き、Enable MCP accessをオンにします。操作できるのはインスタンスのownerかadminです。有効にしただけでは、ワークフローは1つも公開されません。エディターの設定でAvailable in MCPをオンにしたものだけが、実行や詳細取得の対象になります。

プロジェクトやフォルダ単位の一括切り替えは2.24.0以降、新規ワークフローを自動で公開するAuto-expose new workflowsは2.36.0以降です。最新安定版はGitHubのリリース一覧で2.46.6（2026年11月4日）なので、いずれも使えます。ただしAuto-exposeは、後から作られた送信系のワークフローまで黙って公開します。業務用のインスタンスではオフのままにしてください。セルフホストで機能ごと止めたい場合は、環境変数N8N_DISABLED_MODULES=mcpを設定します。

OAuthとAPI keyの選び方とClaude CodeやCodexへの登録コマンド

認証はOAuthが推奨で、クライアントが表示するn8nの画面でサインインして承認します。API keyは個人のアクセストークンで、発行時にしか表示されず、再生成すると古いトークンは無効になります。クライアント別の接続例にあるClaude Codeの登録コマンドは次の形です。

# API key で登録する場合（OAuth なら --header を付けず URL だけを指定する）
claude mcp add --transport http n8n-mcp https://n8n.example.co.jp/mcp-server/http \
  --header "Authorization: Bearer <n8nで発行したMCP用トークン>"

# Codex CLI は ~/.codex/config.toml に書く
[mcp_servers.n8n-mcp]
url = "https://n8n.example.co.jp/mcp-server/http"
http_headers = { "authorization" = "Bearer <n8nで発行したMCP用トークン>" }

API keyは発行した個人の権限で動くため、退職や異動のたびに失効させる手間が残ります。複数人で使うならOAuthにし、Connected clientsのRevoke accessで個別に接続を解除できる状態にしてください。OAuthのコールバック先は既定で任意のURLを許すので、Allowed callback URLsをOnly trusted URLsに絞っておきます。

execute_workflowが実行IDだけを即時に返す仕様と結果の受け取り方

MCP server tools referenceによると、execute_workflowは実行を開始して実行IDをすぐに返し、完了を待ちません。結果はget_workflow_executionで取りにいく2段構えです。Webhookで始まるワークフローに値を渡す呼び出しは、次のような引数になります。

{
  "workflowId": "<ワークフローID>",
  "executionMode": "production",
  "triggerNodeName": "Webhook",
  "inputs": {
    "type": "webhook",
    "webhookData": {
      "method": "POST",
      "body": { "ticketId": "T-1024" }
    }
  }
}

executionModeは公開中の版を動かすproductionと、保存中の未公開版を動かすmanualの2つです。inputsを渡すときはtriggerNodeNameが必須で、これは2.36.0以降の引数です。AIに「実行しました」とだけ答えさせると、失敗に気づけません。実行IDで結果を確かめるところまで指示しておきます。

AIからワークフローを呼ぶときの権限設計｜認証方式・ツール範囲・記録の決め方

MCPでAIに渡すのは、社内システムを操作する権限です。設定画面の既定値は、業務で使うには広すぎます。

読み取り用と書き込み用でMCP Server Triggerを分けてトークンを別にする

1つのMCP Server Triggerにつないだツールは、同じトークンですべて呼べます。社員検索と経費の登録を同じトリガーに並べると、検索だけさせたい利用者にも登録の権限が渡ります。トリガーを読み取り用と書き込み用の2つのワークフローに分け、トークンも別に発行してください。

書き込み用は、利用者を絞ったうえで、サブワークフロー側にも上限を置きます。金額が10万円を超える登録は承認待ちの行として書くだけにする、削除は論理削除に限る、といった歯止めをn8nの中に作っておけば、AIクライアント側の確認画面に頼らずに済みます。

n8n User Authによる実行権限の確認と呼び出したユーザーの記録

ノードのバージョン2以降では、Authenticationにn8n User Auth (OAuth2)を選べます。Require Workflow Execute Permission（既定で有効）がオンなら、呼び出したユーザーがそのプロジェクトでワークフローの実行権限を持っていない限り動きません。n8n側のプロジェクト権限が、そのままAIからの呼び出しの権限になります。

バージョン2.1以降のInclude User in Output（既定で有効）は、呼び出したユーザーのID・メール・名前をトリガーの出力とツールへの要求に含めます。この値をサブワークフローの先頭で監査用のテーブルに書けば、誰のAIがいつ何を呼んだかが残ります。共有トークンのBearer authでは、この記録は取れません。

インスタンス単位のMCPはクライアント単位で絞れない前提で公開対象を決める

インスタンス単位のMCPアクセスには、接続したクライアントごとに見せるワークフローを変える設定がありません。ある開発者のClaude Code向けに公開したワークフローは、別の人が接続したクライアントからも見えます。各ユーザーの閲覧権限は保たれますが、ownerやadminのアカウントで接続すれば広い範囲が見えてしまいます。

加えて、2.13.0以降はAIがワークフローを作成・編集でき、2.12.0以降はpublish_workflowで公開の切り替えもできます。本番の業務ワークフローが載ったインスタンスでは、インスタンス単位のMCPアクセスを有効にしないと決めてください。開発用のインスタンスを分け、そこで組んだワークフローを書き出して本番へ移す運用が安全です。

セルフホストでMCP接続が切れる原因とリバースプロキシ・キューモードの設定

MCPのSSEとStreamable HTTPは、1本の接続を長く保ちます。通常のWebhookでは問題にならないプロキシの設定や負荷分散が、MCPでは接続切れの原因です。Docker Composeでの基本構成はn8n docker：Composeで建てる本番構成とHTTPS公開・更新・バックアップ手順を前提にしています。

nginxのMCP用locationでバッファリングとgzipを無効にする設定

公式ページは、MCPのエンドポイントでプロキシのバッファリング、gzip、チャンク転送を無効にし、Connectionヘッダーを空にするよう求めています。他の場所の設定を継承させないため、MCP用のlocationブロックに明示します。

# /mcp の前方一致で /mcp/・/mcp-test/・/mcp-server/ をまとめて受ける
location /mcp {
    proxy_pass http://n8n:5678;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
    gzip off;
    chunked_transfer_encoding off;
    proxy_read_timeout 3600s;
}

proxy_read_timeoutは公式の必須項目ではありませんが、既定の60秒のままだと、ツールの処理が長いときにnginx側で接続が切られます。WAFを挟む構成では、MCP-Protocol-Version・Mcp-Method・Mcp-Nameの3つのヘッダーを通す設定も必要です。落とされると接続に失敗するか、古いプロトコルでの接続に戻ります。

Webhookレプリカが複数あるとき/mcpへの要求を1台に寄せる構成

キューモードでWebhookを受けるプロセスが1台なら、そのままで動きます。負荷分散のためにWebhookのレプリカを複数並べている場合は、/mcpで始まる要求をすべて専用の1台へ振り分ける構成が必要です。振り分けないと、同じ接続の続きが別のレプリカに届き、イベントの配信が途切れます。

MCP専用のレプリカを1台だけのグループとして立て、ロードバランサーかIngressでパスが/mcpで始まる要求をそこへ送ります。他のWebhookは従来どおり分散させてください。呼び出しが1台に集まるため、そのレプリカのCPUとメモリには余裕を持たせておきます。

n8nのMCPを採用する条件と見送る条件｜Zapier MCPや自作サーバーとの境界

社内のワークフローがすでにn8nにあるなら、MCPはそれをAIから呼べるようにする近道です。n8nを新しく入れてまでMCPの窓口にする場合は、他の選択肢と比べてから決めます。

社内のワークフローをAIクライアントから呼ばせたい場合にn8nが向く条件

向くのは、呼ばせたい処理が5〜10本程度のサブワークフローにまとまり、その中身が複数のSaaSや社内APIをまたぐ場合です。経費の照会、在庫の引当、問い合わせチケットの起票といった処理を、ノードの組み合わせで作り、MCP Server Triggerで窓口を1つにできます。接続先がSaaSばかりで、自前のサーバーを持ちたくないならZapierも候補です。タスク消費と権限の違いはZapier MCPとは？AIから9,000超アプリを動かす仕組みとタスク消費・権限設計で比べています。

監査や細かな権限分離が要る業務でMCPサーバーを自作に切り替える基準

次のどれかに当てはまるなら、n8nのMCPは窓口に使わず、MCPサーバーをコードで実装します。

ツールごと・利用者ごとに異なるOAuthスコープを要求したい
呼び出しの全件を改ざんできない監査ログとして保存する規程がある
ツールの入出力をテストコードで固定し、変更のたびに回帰確認したい
自社サービスの機能として顧客にMCPサーバーを提供する

n8nで分けられる権限は、トリガー単位とプロジェクト単位までです。自作する場合の認可の実装はMCPサーバーの作り方とAIエージェントへの接続手順で扱っています。既存のRPAやn8nのワークフローをAIエージェントから安全に呼べる形に整える作業は、一創のRPA×AIエージェント連携（インテリジェントオートメーション）で、権限の設計から対応しています。

よくある質問：n8nのMCP接続で多いClaude連携・認証・ワークフロー編集の疑問

n8nをMCPで使うときによく聞かれる質問をまとめました。

Claude DesktopからMCP Server Triggerにつながらないときは何を確認しますか？

順に、ワークフローが公開されているか、Production URLを登録しているか、トークンが正しいかを見ます。Test URLはエディターで待ち受けている間しか応答しません。次に、前述のcurlで初期化要求を送り、応答が返るかを確かめます。curlで通ってClaude Desktopだけ失敗するなら、npxが動くNode.jsの有無と、設定ファイルのJSONの書式を疑ってください。

claude.aiのカスタムコネクタでサインインを求められるのはなぜですか？

公式ページによると、claude.aiのカスタムコネクタは、MCP Server TriggerのAuthenticationをNoneにしていてもn8nへのサインインを求めます。n8nの他のトリガーがn8nのユーザー認証を使うため、claude.aiが同じドメインのMCPエンドポイントすべてに同じ認証が要ると判断するためです。この挙動が確認されているのはclaude.aiだけとされています。

コミュニティ製のn8n-mcpと公式のMCP機能は何が違いますか？

コミュニティ製のn8n-mcpは、n8nのREST APIキーを渡して外部で動かすMCPサーバーです。公式のインスタンス単位のMCPアクセスは、n8n本体で有効にし、OAuthやクライアントごとの失効、ワークフロー単位の公開設定を持ちます。業務のインスタンスにつなぐなら、権限の管理がn8nの中で完結する公式の機能を選びます。

stdioにしか対応しないMCPクライアントからもつなげますか？

中継のプロセスを使えば接続可能です。MCP Server Triggerもインスタンス単位のMCPアクセスもstdioには対応していないため、中継のプロセスを挟みます。MCP Server Triggerの公式例はmcp-remote、インスタンス単位のClaude Desktop向けの例はsupergatewayを使います。どちらもローカルでstdioを受け、n8nへHTTPで中継する役割です。

AIにn8nのワークフローを作成・編集させても大丈夫ですか？

開発用のインスタンスに限るなら有効です。2.13.0以降は作成と編集、2.12.0以降は公開と非公開の切り替えまでツールとして提供されています。本番のインスタンスで許すと、AIの誤った編集がそのまま業務に反映されかねません。開発用で作らせ、人が差分を確かめてから本番へ移す手順にしてください。get_workflow_versions_diff（2.36.0以降）で版の差分も取れます。