上級 12 分n8n

n8n と MCP：ワークフローを LLM に接続する ローカル

n8n と MCP は双方向に組み合わせられます。n8n は MCP Server Trigger ノードによってワークフローを MCP ツールとして公開でき、n8n のエージェントは MCP Client Tool ノードによって外部の MCP サーバーのツールを呼び出せます。このガイドでは、Ollama で提供されるローカルモデル上で動作するエージェントを使って両方の構成を示し、続いて n8n が公開する URL を保護する方法を説明します。本ガイドは n8n の公式ドキュメントに基づいており、n8n を操作するために作られたサードパーティ製 MCP サーバーは別のテーマであるため扱いません。

著者 Thomas P.·更新 2026-10-26·Windows・macOS・Linuxでテスト済み

#n8n と MCP：二つのノード、二つの流れの方向

Model Context Protocol（MCP）は、AIアプリケーションがサーバーの提供するツールをどのように検出し呼び出すかを定めたオープンなプロトコルです。初めて聞く概念であれば、ガイド「MCPとは？」で基本を確認できます。ここでは、クライアント、サーバー、ツールといった用語を理解していることを前提とします。

n8n では、MCP は AI ファミリー（n8n-nodes-langchain パッケージ）の二つのノードとして提供されています。両者は正反対の用途に対応しており、チュートリアルを読んでいると混同しがちです。

MCP Server Trigger：n8n がサーバーになる
このノードはMCP URLを公開します。ノードに接続した各ツール（サブワークフロー、HTTPリクエスト、組み込みツール）は、外部クライアントが一覧表示して呼び出せるMCPツールになります。典型的な用途は、ローカルのアシスタントに認証情報を渡すことなく、「チケットを作成」「CRMを検索」「サマリーを送信」へのアクセスを与えることです。
MCP Client Tool：n8nがクライアントになる
このノードは、AI Agent ノードの下にツールとして接続します。既存の MCP サーバーに接続してツール一覧を取得し、それらをエージェントが使えるようにします。典型的な用途は、スケジュール実行されるワークフローで、エージェントが既存の MCP サーバーを介してファイルを読み込んだり、データベースに問い合わせたり、ドキュメントを検索したりするケースです。
MCPによって変わらないこと
モデルの選択はこれとは独立しています。n8n のエージェントは Ollama 上で動作させることができ、MCP Server Trigger を呼び出すクライアント側もローカルモデルを使用できます。MCP が運ぶのはツールの説明とその呼び出しだけで、モデルそのものではありません。

両方のノードは同じインスタンス内に共存できます。いくつかの業務アクションを公開する「サーバー」ワークフローと、一つ以上の MCP サーバーを利用する「エージェント」ワークフローです。さらに、n8n のエージェントが同じインスタンス内の別のワークフローの MCP Server Trigger を呼び出すことも可能で、これは大きなエージェントを再利用可能な部品に分割することに相当します。

#前提条件

自分だけのAIエージェントを作るためのキット一式。

私たちの経験とガイド付きルートを活かして、ローカルエージェントと自動化をさらに使いこなしましょう。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 30日間返金対応
ローカルエージェントキットを見る: 24 €または 全キットを永久に：49 € →
最近のバージョンの n8n インスタンス
セルフホスト型で、できれば Docker を使用します。MCP ノードは 2025 年に登場し、その後も進化を続けています（トランスポート、認証オプション）。n8n を最新版に更新し、お使いのエディターに表示される内容に従ってください。インストール手順自体は、Docker を使った n8n のガイドで詳しく説明しています。
n8nからアクセス可能なOllama
Ollama はデフォルトで http://localhost:11434 で待ち受けます。n8n をコンテナ内で実行している場合、localhost はお使いのマシンではなくコンテナ自身を指すため、別のアドレスが必要になります（手順 1 を参照）。
ツール呼び出しに対応したモデル
エージェントが役に立つのは、モデルが構造化されたツール呼び出しを生成できる場合だけです。Ollama のページでtools機能が表示されているモデル、たとえばQwen3ファミリーのモデルを選んでください。Q4_K_Mでは、8Bは約5 GB、14Bは約9 GBのVRAMに収まるため、RTX 3060 12 GBや RTX 4070 12 GBでも余裕があります。
ステップ2向け
HTTPでアクセスできるMCPサーバー。stdio経由でローカルでのみ起動されるサーバー（npxやuvxコマンド）には、n8nからそのままでは接続できません。URLで待ち受けるサーバーが必要です。
ステップ 4 向け
リモートサーバーと通信できるMCPクライアント：LM Studio、Open WebUI、ゲートウェイ経由のClaude Desktop、またはテスト用のプロトコル公式インスペクター。

#ステップ 1：ローカルモデルに接続した n8n エージェント

MCP はどちらの方向でも、n8n 側またはクライアント側のエージェントを経由します。そのため、まず n8n がローカルモデルと通信できることを確認してください。基本的な接続方法は n8n + Ollama ガイドで詳しく説明しています。ここでは最低限必要な内容のみを示します。

ターミナル
# Télécharger un modèle compatible avec l'appel d'outils
ollama pull qwen3:8b

# Vérifier qu'Ollama répond et liste le modèle
curl http://localhost:11434/api/tags

n8nがDocker内で動作し、Ollama がホスト上で直接動作している場合は、host.docker.internalをホストマシンに向けるエントリをn8nサービスに追加してください。Docker Desktop（macOS、Windows）ではこの名前がすでに存在しますが、Linuxでは明示的に宣言する必要があります。

docker-compose.yml（抜粋）
services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    extra_hosts:
      - "host.docker.internal:host-gateway"

Linux では、Ollama はデフォルトで 127.0.0.1 でのみ待ち受けます。Ollama サービスで OLLAMA_HOST=0.0.0.0 を設定するまで、コンテナーから host-gateway 経由で接続することはできません。両方が同じ Compose ファイル内で動作している場合は、代わりにサービス名（例：http://ollama:11434）を使用してください。

  1. 01
    エージェントを作成する
    新しいワークフローで、Chat Triggerトリガー（テストに便利です）を追加し、続いてAI Agentノードを追加します。
  2. 02
    モデルを接続する
    エージェントのChat Model入力にOllama Chat Modelを追加します。ベースURLをhttp://host.docker.internal:11434（n8nをコンテナで実行していない場合はhttp://localhost:11434）として認証情報Ollamaを作成し、qwen3:8bを選択します。
  3. 03
    ツールなしでテストする
    ワークフローのチャットを開き、簡単な質問をしてみます。応答が返ってくれば、n8nからOllamaへの接続が確認できたことになります。ガイドの残りの部分では、その上にツールを追加していきます。

#ステップ 2：n8n エージェントから MCP サーバーを利用する

MCP Client Tool ノードは、他のツールと同様に AI Agent の Tool 入力に接続します。実行時には MCP サーバーに問い合わせ、各ツールの説明とパラメータスキーマを含むツール一覧を取得して、モデルに提示します。どのツールをどの引数で呼び出すかを決めるのはモデルであり、n8n は呼び出しを中継して結果を返す役割を担います。

  1. 01
    ノードを追加する
    手順 1 で作成したエージェントの下で、Tool 入力の + をクリックし、MCP Client Tool を選択します。
  2. 02
    エンドポイントを入力する
    MCP サーバーの URL を貼り付け、そのサーバーが提供するトランスポートを選択します。n8n のドキュメントでは、プロトコルの現行トランスポートである HTTP ストリーミング（streamable HTTP）と、より古く現在も一部のサーバーで提供されている Server-Sent Events（SSE）が挙げられています。サーバーのドキュメントに /sse で終わる URL が記載されていれば、通常は SSE です。そうでなければ HTTP を試してください。
  3. 03
    認証方式を選ぶ
    サーバーの要件に応じて、なし、Bearer（Authorization ヘッダーで送信されるトークン）、またはカスタムヘッダーのいずれかを選択します。正確なオプションは n8n のバージョンによって異なります。トークンはワークフロー内に平文で保存されるのではなく、n8n の認証情報（クレデンシャル）として保存されます。
  4. 04
    ツールを絞り込む
    Tools to Include パラメーターでは All、Selected、All Except を選べます。Selected をおすすめします。8B のローカルモデルは、三十個のツールよりも、説明の行き届いた三つのツールからのほうが適切に選択できます。また、エージェントが実行できる操作も制限できます。
  5. 05
    テストする
    チャットで、そのツールを必要とする操作を依頼してください。エージェントの実行ログに、呼び出されたツール、モデルが生成した引数、サーバーの応答が表示されます。
→
システムプロンプトが仕事の半分を担います
ローカルモデルを使う場合は、エージェントのシステムメッセージで、各ツールをいつ使い、いつ使わないかを記述してください。小規模なモデルは、ツールを無視するか、何にでもツールを呼び出すかのどちらかに偏りがちです。簡潔な指示と厳選した少数のツールのほうが、指示が不十分な大規模モデルよりも安定した呼び出しにつながります。

実用上の注意：n8n から MCP サーバーに到達できる必要があります。お使いのマシンで localhost:3000 として起動したサーバーは、n8n コンテナからは見えません。ここでも host.docker.internal または Docker のサービス名を使うという同じルールが当てはまります。

#手順 3：MCP Server Trigger でワークフローを公開する

「n8n mcp」という検索の背後で最も求められているのがこの方向です。つまり、既存の自動化をアシスタントが呼び出せるツールに変えることです。MCP Server Trigger は従来のトリガーとは異なり、一連のノードを起動するのではなく、ツールノードにのみ接続してそれらを公開します。

  1. 01
    サーバー側ワークフローの作成
    新しいワークフローを作成し、MCP Server Trigger ノードを追加します。テスト URL と本番 URL に加え、URL の末尾を決める Path フィールドが表示されます。必要に応じてランダムな識別子を読みやすいパスに置き換えてもかまいませんが、推測されにくいものにしてください。
  2. 02
    ツールを接続する
    トリガーのTool入力をクリックし、ツールを追加します。最も便利なのは、別のn8nワークフローを呼び出すツール（Call n8n Workflow Tool）で、既存の自動化をMCPツールにできます。HTTP Request Toolや、n8nが提供する連携ツールを接続することもできます。
  3. 03
    名前と説明を丁寧に書く
    クライアントに見えるのは、ツールの名前、説明、パラメーターのスキーマだけです。モデルはこのテキストを読んで呼び出すかどうかを判断します。ツールが何をするのか、どのようなパラメーターを受け取るのか、何を返すのかを、一、二文で明確に記述してください。
  4. 04
    サブワークフローのパラメーターを定義する
    呼び出されるワークフローで、想定する入力フィールド（たとえばチケットのタイトルと優先度）を宣言してください。MCP クライアントはこのスキーマを受け取り、モデルが値を入力します。
  5. 05
    テストしてから有効化する
    テストURLは、エディターがテストイベントを待ち受けている間だけ応答し、その実行はキャンバスに表示されます。本番URLは、ワークフローを有効化した後でなければ機能しません。調整にはテストURLを使い、クライアントには本番URLを渡してください。
URL の形式（ノードに表示されるものをコピーしてください）
Test        : https://n8n.mondomaine.lan/mcp-test/<chemin>
Production  : https://n8n.mondomaine.lan/mcp/<chemin>

ベースアドレスは、n8n が Webhook に使用するアドレスと同じです。別のホスト名でアクセスしているのに n8n が localhost:5678 と表示する場合は、インスタンスの WEBHOOK_URL 変数を修正してください。ノードに表示される URL はこの変数で決まります。

!
キューモードと複数の Webhook レプリカ
MCP のトランスポートは、特定のプロセスとの接続を維持します。n8n のドキュメントによると、複数の Webhook レプリカを使うキューモードでは、/mcp* パスへのリクエストをすべて単一の専用レプリカにルーティングする必要があり、そうしないと通信が断続的に失敗します。単一コンテナで動作するシンプルなインスタンスは対象外です。

#ステップ4：ローカルのMCPクライアントをn8nに接続する

残る作業は、同じくローカルモデル上で動作するアシスタントからこれらのツールを呼び出せるようにすることです。「インテリジェントな」クライアントを使う前に、まずプロトコル公式のインスペクターでサーバーを確認してください。インスペクターは公開されているツールを一覧表示し、モデルを介さずに手動で呼び出すことができます。

ターミナル
# Lance l'inspecteur MCP dans le navigateur (nécessite Node.js)
npx @modelcontextprotocol/inspector

インターフェースで対応するトランスポートを選択し、本番 URL を貼り付け、認証を有効にしている場合は Authorization ヘッダーを追加してから、ツールを一覧表示します。n8n のツールが説明付きで表示されれば、サーバーの準備は完了です。

#LM Studio と URL を受け付けるクライアント

最近のクライアントは、URL で指定されたリモート MCP サーバーを直接受け付けます。たとえば LM Studio は mcpServers 形式の mcp.json ファイルを読み込み、リモートのエントリは以下のような形式になります。フィールド名はソフトウェアによって異なる場合があるため、正確な名前はお使いのクライアントのドキュメントで確認してください。

mcp.json
{
  "mcpServers": {
    "n8n": {
      "url": "https://n8n.mondomaine.lan/mcp/<chemin>",
      "headers": {
        "Authorization": "Bearer <votre-jeton>"
      }
    }
  }
}

#stdioのみに対応したクライアント：ゲートウェイを経由する

クライアントによっては、stdio のローカルサーバーしか起動できないものがあります。このような場合について、n8n のドキュメントでは mcp-remote ゲートウェイの利用が説明されています。これは stdio サーバーとして起動し、呼び出しを n8n の URL へ中継します。トークンは引数に直接書き込まず、環境変数で渡します。

クライアント設定（mcpServers 形式）
{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://n8n.mondomaine.lan/mcp/<chemin>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<votre-jeton>"
      }
    }
  }
}

モデル側には手順 2 と同じルールが適用されます。ツール呼び出しに対応したモデルをクライアントに読み込み、表示するツールは少数に抑え、まずは曖昧さのないリクエストでテストしてください。Ollama とそのインターフェースにおけるクライアント側の設定は、MCP とローカル LLM のガイドで詳しく説明しています。

#n8n の MCP エンドポイントを保護する

MCP Server Trigger の URL は、n8n に保存された認証情報を使ってワークフローを起動するエントリーポイントです。認証がなければ、この URL を知っている人は誰でもチケットを作成したり CRM を読み取ったりできます。API キーと同様に扱ってください。

認証を有効にする
このノードでは Bearer トークンによる認証またはヘッダーによる認証を利用できます。ローカルネットワーク上であっても、必ず有効にしてください。たとえば以下の openssl コマンドで長くランダムなトークンを生成し、特定のクライアントのトークンだけを失効できるよう、クライアントごとに異なるトークンを使用してください。
理由なく n8n をインターネットに公開しない
個人や小規模チームでの利用であれば、n8n はローカルネットワーク内、または VPN（WireGuard、Tailscale）の背後に置いてください。外部公開が必要な場合は、HTTPS のリバースプロキシを経由させ、可能であれば IP フィルタリングも行ってください。
各ツールにできることを制限する
MCPツールは、範囲を限定したパラメーターで特定の処理を1つだけ行うものにすべきです。「SQLクエリを実行する」や「任意のURLを呼び出す」といった汎用的なツールの公開は避けてください。モデルが誤った判断をしたり、エージェントが読み込んだ悪意あるコンテンツによって、ツールが悪用されたりするおそれがあります。
プロンプトインジェクションに注意する
エージェントが外部コンテンツ（メール、Web ページ、ドキュメント）を読み込み、かつ実際に操作を行うツールを持っている場合、罠を仕込んだテキストによってツールの呼び出しを指示される可能性があります。読み取り用のツールと操作用のツールを分離し、取り消しのできない操作の前には人間による確認（待機ノードまたは承認ノード）を追加してください。
サードパーティ MCP サーバー側を監査する
クライアント側では、提供元とコードを把握している MCP サーバーだけをエージェントに追加してください。サーバーが提供するツールの説明は、そのままモデルのコンテキストに入ります。
実行を監視する
ツールが呼び出されるたびに、n8n で実行が一件記録されます。サーバー側ワークフローの履歴を定期的に確認してください。これが監査ログになります。
ターミナル
# Générer un jeton aléatoire de 64 caractères hexadécimaux
openssl rand -hex 32

n8n の前段にリバースプロキシがある場合は、ストリーミング応答を通過させる必要があります。n8n のドキュメントには MCP のパスに対してバッファリングを無効にする nginx の例が掲載されています。以下の抜粋はそのディレクティブを再掲したもので、お使いの構成に合わせて調整し、プロキシ経由でテストする場合は /mcp-test/ パスも追加してください。

nginx（server {} の抜粋）
location /mcp/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding off;
    gzip off;
}

#n8n MCP のトラブルシューティング：よくある問題

クライアントにツールが一つも表示されない
MCP Server Trigger の Tool 入力にツールが正しく接続されていること、そしてワークフローを有効化した状態で本番 URL を使用しているか、エディターが待ち受けている間にテスト URL を使用しているかを確認してください。
401 または 403 エラー
トークンが一致していないか、クライアントがヘッダーを送信していません。送信されるヘッダーを正確に表示する MCP インスペクターでテストしてください。「Bearer」の後のスペースに注意してください。
接続が切れる、または止まったままになる
ほとんどの場合、ストリームをバッファリングしているプロキシか、クライアント側で誤ったトランスポート（SSEとHTTP）が選択されていることが原因です。プロキシの問題を切り分けるには、ポート5678に直接接続してテストしてください。
表示される URL に localhost が含まれている
n8n の WEBHOOK_URL 変数が定義されていません。このままでは、他のマシンから URL にアクセスできません。インスタンスのパブリックアドレスまたはネットワークアドレスを設定してから、n8n を再起動してください。
Ollama への ECONNREFUSED
コンテナ内のn8nは、コンテナ内で Ollama を探します。host.docker.internalまたはDockerのサービス名を使用し、Ollama がアクセス可能なインターフェースで待ち受けていることを確認してください。
モデルがツールをまったく呼び出さない
ツール非対応のモデル、曖昧すぎるツールの説明、または公開しているツールが多すぎることが原因です。tools と表示されたモデルに切り替え、説明を書き直し、選択するツールを絞り込んでください。
モデルがパラメーターを捏造する
サブワークフローのスキーマの自由度が高すぎます。型付きのフィールドを宣言し、期待される値を記述してください。また、何らかの操作を行う前に、ワークフロー内で入力を検証してください。
i
パフォーマンスについて
本ガイドでは、速度やツール呼び出しの成功率の測定値は一切公開していません。結果は、モデル、その量子化、ツール説明の長さ、そしてお使いのハードウェアによって異なります。判断するには、代表的なリクエストを一通り用意してご自身のツールでテストし、実行ログを比較してください。

#さらに詳しく

このガイドでは n8n における MCP を扱います。プロトコルの基本、Ollama 側での MCP クライアントの設定、n8n とローカルモデルの接続については、以下のガイドをご覧ください。

このガイドは役に立ちましたか？

ご意見、誤りのご指摘、補足はありますか？ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。