n8nのMCPサーバーをClaude Codeにつなぐ方法と本番の注意点

実務ノート実務ノート公開 2026年10月7日

Claude Code から n8n のワークフローを探したり、直したりしたい。そのための入り口が、n8n に組み込まれている MCP サーバーです。MCP は、Claude Code のような AI のアプリが外のサービスを操作するための共通の決まりごとです。つなぐ作業は短く終わりますが、本番で使うと「直したのに本番は古いまま」という食い違いが起きました。この記事では、つなぎ方と、弊社がつまずいた点をまとめます。

扱うのは、n8n のインスタンス（動かしている n8n 1台ぶん）に組み込まれた MCP サーバーです。ワークフローの中に置く「MCP Server Trigger」や「MCP Client Tool」のノードの話ではありません。

この記事の結論

n8n 2.19.2 では、設定で MCP を有効にし、アクセストークン（本人確認に使う文字列）を付けて claude mcp add で登録します。
ワークフローは1本ずつ「Available in MCP」を ON にしないと、中身の取得も実行も編集もできません。
update_workflow で直しただけでは、本番は変わりません。publish_workflow で公開して、はじめて本番の実行に載ります。
本番の実行は「公開版」の中身を使います。データベースにあるワークフロー本体の行を直に書き換えても、本番は変わりません。

実際に起きたこと

弊社は n8n を 2.19.2 に上げたあと、MCP サーバーを Claude Code に登録して使っています。登録は本番の機械用と、手元の機械用の2つです。

2026-07-05、弊社で動かしているワークフローの Code ノード（JavaScript を書いて動かすノード）の中身を差し替えました。ところが、実行すると古いコードのまま動きました。試したことと結果は次のとおりです。

データベース（SQLite）の workflow_entity.nodes を直接書き換え、有効化しなおした。→ 古いコードのままだった。
MCP の update_workflow で更新し、publish_workflow で公開した。→ 新しいコードで動いた。

2026-08-04 には、別の食い違いを踏みました。データベースを直接直す作業で、実行に使われる側（workflow_history）だけを直したときです。実行は新しいコードになったのに、画面でワークフローを開くと古いコードが出ました。画面から保存した瞬間に、古いコードへ戻ってしまう状態です。社内の検査も workflow_entity 側を見ていたので、直したのに警告が鳴り続けました。

2026-08-07 には、workflow_history にワークフローごとの行が1行しか残っていないものがあると分かりました。n8n の上では前の版に戻せない、ということです。同じ時期に、Code ノードの console.log が n8n のログファイルに出ないことも確かめました。

原因

MCP の入り口と認証のしくみ

n8n の MCP サーバーは /mcp-server/http で POST を受けます。設定で MCP が無効のときは、403 と MCP access is disabled を返します。

認証には、Authorization: Bearer のヘッダーで渡すトークンを使います。ヘッダーが無いと、401 で Unauthorized: Authorization header not sent が返ります。ソースを読むと、このトークンは JWT（署名つきの文字列）で、宛先に mcp-server-api が入っています。一度作ったトークンは、次からは末尾の4文字だけを残して伏せた形でしか返りません。作り直すと、前のトークンは消されます。

ワークフローごとの許可

MCP のツール（update_workflow など、つないだアプリから呼べる操作）は、ワークフローを扱う前に同じ確認を通ります。ワークフローの設定で availableInMCP が ON でなければ、次の文で止まります。

Workflow is not available in MCP. Enable MCP access in workflow settings.

公式ドキュメントによると、例外は search_workflows だけです。それも、見える範囲のワークフローの概要を返すだけで、中身は返しません。なお、create_workflow_from_code で新しく作ったワークフローには、作った時点で availableInMCP: true が付きます。

update_workflow は下書きを作るだけ

n8n 2.13 から、ワークフローは「下書き」と「公開版」に分かれました。

update_workflow は、渡したコードからワークフローを組み立てて保存します。nodes か connections が変わっていれば新しい版の番号を振り、版の履歴（workflow_history）に保存します。

ただし、公開版の番号（activeVersionId）が動くのは、保存のときに publishIfActive が指定された場合だけです。既定は false です。update_workflow はこれを指定せずに保存します。そのため、本番は前の公開版のまま動き続けます。

publish_workflow は、版の番号を指定しなければ、いまの下書きの番号を公開します。このとき中身は、ワークフロー本体の行ではなく、版の履歴から読みます。

本番の実行も、公開版の中身を使います。execute_workflow の既定は本番のモードで、公開版の nodes で動きます。公開版が無ければ has no published (active) version to execute で止まります。

データベースを直に書き換えても効かない理由

ここまでで、7月の症状の説明がつきます。workflow_entity.nodes を書き換えても、版の番号は前のままです。有効化すると、その番号の中身を版の履歴から読むので、古いコードがそのまま公開されます。

反対に、版の履歴だけを直すと、8月の状態になります。実行は新しく、画面で開くと古い、という食い違いです。弊社の環境では、画面で開いたときに出るのは workflow_entity 側の中身でした。

公開 API の PUT は保存と同時に公開する

update_workflow と違い、公開 API の PUT（/api/v1/workflows/{id}）は、ソースでは publishIfActive: true を付けて保存します。公開版のあるワークフローなら、保存と同時に公開版の番号が新しい版へ動く作りです。そのため PUT のあとに publish_workflow を呼ぶと、同じ versionId（版の番号）が返ります。これは失敗の印ではありません。

直し方

手順1：MCP を有効にする

n8n の設定で MCP を有効にします。弊社の 2.19.2 では、設定の画面は /settings/mcp でした。/settings/instance-mcp ではありません。

公式ドキュメントでは「Settings > Instance-level MCP」の「Enable MCP access」を選びます。インスタンスの持ち主か、管理者の権限が要ります。画面の並びは版で変わっていて、公式ドキュメントの説明は 2.33.0 からの並びです。古い版では、画面が説明と違って見えることがあります。

手順2：トークンを取って Claude Code に登録する

MCP の設定画面の「Connection details」から「Access Token」のタブを開き、トークンを取ります。

公式ドキュメントによると、そのタブを離れると、トークンは伏せた形でしか表示されません。もう一度写したいときは、作り直すしかありません。作り直すと前のトークンは使えなくなるので、つないでいるアプリすべてで差し替えが要ります。

弊社では、次の形で Claude Code に登録しています。XXXX_N8N_DOMAIN は n8n のドメイン、XXXX_MCP_TOKEN は手順2で取ったトークンに置き換えます。

claude mcp add --transport http --scope user n8n-mcp \
  https://XXXX_N8N_DOMAIN/mcp-server/http \
  --header "Authorization: Bearer XXXX_MCP_TOKEN"

手元で動かしている n8n なら、公式ドキュメントのとおり http://localhost:5678 のように http で始まる URL を使います。

公式ドキュメントには、OAuth（画面で許可する方式）でつなぐ方法もあります。その場合は Claude Code で /mcp を開き、n8n を選んで許可します。

手順3：ワークフローごとに「Available in MCP」を ON にする

ワークフローを開き、右上のメニュー（…）から Settings を開いて「Available in MCP」を ON にします。既定は OFF です。

公式ドキュメントには、ON にできるのは公開済みで、Webhook・フォーム・スケジュール・チャットのどれかのトリガーを持つワークフローだけ、とあります。ただし 2.19.2 のサーバー側の処理（ON と OFF を切り替える処理）では、この条件を確かめていません。設定の値を書き換えて保存するだけです。画面の側で ON にできる場合を絞っているかは、確かめていません。

ON にしたワークフローは、つないだすべてのアプリから見えます。アプリごとに見せる範囲を分けることはできない、と公式ドキュメントにあります。本番の大事なワークフローを ON にするかどうかは、この前提で決めてください。

手順4：直すときは update_workflow のあとに publish_workflow

弊社では、ワークフローを直すとき、次の順でツールを呼んでいます。

get_sdk_reference
→ search_nodes
→ get_node_types
→ validate_workflow
→ update_workflow
→ publish_workflow

2.19.2 の update_workflow は、ワークフロー全体をコードから組み立てなおします。ノードの資格情報（API キーなどの登録）は、ノードの名前と種類が前と同じときだけ引き継がれます。HTTP Request ノードは自動の割り当ても飛ばされるので、名前を変えたら手で付けなおしてください。公式ドキュメントでは、2.20.0 から部分的に書き換える方式に変わったとあります。

SDK のコードを書くときは、Buffer と String.raw が使えません。弊社では Security violation や Unsupported syntax で止まりました。

手順5：データベースは直に書き換えない

どうしてもデータベースを直接直すなら、workflow_entity と workflow_history の両方を同じ内容にします。片方だけ直すと、実行と画面が食い違います。

書き換える前に、nodes をファイルへ退避してください。版の履歴が1行しか無いワークフローは、n8n の上では前に戻せません。

直ったかを確かめる

search_workflows の結果で、そのワークフローの availableInMCP が true になっているか。
publish_workflow の返り値で、success が true で、activeVersionId が入っているか。
本番で一度動かし、実行データの出力に、直した部分の新しい項目が出ているか。

データベースを直接直した場合は、versionId が変わらないまま中身だけ入れ替わることがあります。versionId だけで判断しないでください。

確認のために Code ノードへ console.log を足しても、弊社の環境では n8n のログファイルに出ませんでした。残したい値は、ノードの戻り値の JSON に入れて、実行データで見ます。

それでも直らないとき

MCP のツールから返る文と、見るところを並べます。文はどれも n8n 2.19.2 のソースにあるものです。

返ってきた文	見るところ
`MCP access is disabled`（403）	設定で MCP が有効になっているか
`Unauthorized: Authorization header not sent`（401）	トークンで登録した場合は、`--header` を付け忘れていないか。OAuth でつないだ場合は、Claude Code の `/mcp` で許可を済ませたか
そのほかの `Unauthorized`	伏せた形のトークンを貼っていないか。分からなければ作り直して、つないでいるすべてのアプリで差し替える
`Workflow is not available in MCP. Enable MCP access in workflow settings.`	そのワークフローの「Available in MCP」
`Workflow 'XXXX' is archived and cannot be accessed.`	ワークフローがアーカイブされていないか
`Workflow 'XXXX' has no published (active) version to execute`	公開してから実行する。下書きのまま試すなら manual のモードで動かす
`Only workflows with the following trigger nodes can be executed: …`	本番のモードで動かせるのは Schedule Trigger・Webhook Trigger・Form Trigger・Chat Trigger。Manual Trigger は manual のモードだけ

MCP からの公開はできたのに、実行すると Code ノードで止まることもあります。これは MCP ではなく、Code ノードの実行環境の制限です。弊社の 2.19.2 では new URL() が ReferenceError になりました。$env を読むと止まる場合は「n8nのCodeノードで「access to env vars denied」が出る原因と直し方」を、fetch で止まる場合は「n8nのCodeノードで「fetch is not defined」が出る原因と直し方」を見てください。