n8n + Ollama：ローカルLLMをワークフロートリガーとして使う実装例

AI・ローカルLLM活用中級
n8nOllamaLLMAutomationDocker

TL;DR

n8nからOllamaを使う方法は2通りあります。Ollama ModelノードはUIだけで設定が完結しますが、AI Agentノードと接続できず、かつ20〜25秒の遅延が発生する既知の問題があります（n8n GitHub Issue #15263・v1.91.3時点）。HTTP Requestノードで直接API呼び出しをすると応答が速く、モデルの動的切り替えもできますが、レスポンスのパース処理を自前で書く必要があります。この記事では、両パターンの実装手順・Docker/Mac/Linux別の接続設定・CPUのみでの実用判断・Slack分類→Google Sheetsログの具体的なフロー例を整理します。

Ollamaノードで接続できたのに、なぜかワークフローが20秒以上返ってこない。あるいは、AI Agentノードに繋ごうとしたら接続できなかった。こうした詰まり方をしている場合、原因はハードウェアでも設定ミスでもなく、n8nとOllamaの接続方式に起因する構造的な制約にあります。

制約を知らないまま設定を試行錯誤しても解決しません。まず制約を把握してから実装の方向を決めると、余計な時間を使わずに済みます。

n8nでOllamaを使う前に確認する3つの制約

制約①：Ollama ModelノードはAI Agentノードと接続できない

n8n公式ドキュメントには次の記載があります。

This node lacks tools support, so it won’t work with the AI Agent node. Instead, connect it with the Basic LLM Chain node.

— n8n Docs: Ollama Model node

AI Agentノードはツール呼び出し（function calling）に対応したモデルを前提としており、Ollama Modelサブノードはその要件を満たしていません。接続先はBasic LLM Chainノードのみです。AI Agentを使いたい場合は、後述のHTTP Requestパターンか、OpenAI互換APIとして公開する別の手段が必要になります。

制約②：Ollama Modelノードには20〜25秒の遅延が発生する既知のバグがある

n8n GitHub Issue #15263（v1.91.3時点・オープン中）に次の報告があります。

there is a significant delay of approximately 20-25 seconds per LLM call. This occurs even with small models like llama3.2:3b and simple prompts.

同じOllamaに対してcurlで直接リクエストすると1〜3秒で返ります。遅延はn8nのOllama Modelノードに固有の問題であり、ハードウェアのスペック不足ではありません。回避策は後述します。

制約③：デフォルトのコンテキストウィンドウは4096トークンで、長文処理には不足する

Ollama公式FAQに次の記載があります。

By default, Ollama uses a context window size of 4096 tokens.

— Ollama FAQ

長い会話履歴・PDFの全文処理・長いシステムプロンプトを想定している場合、デフォルトのままでは途中でカットされます。num_ctxパラメータで拡張できます（後述）。

接続パターンは2種類ある：Ollama Modelノード vs HTTP Requestノード

比較軸パターンA：Ollama ModelノードパターンB：HTTP Requestノード
実装難易度低（UIで完結）中（JSON・パース処理が必要）
AI Agentノード接続不可不可（直接）※
応答速度20〜25秒の遅延あり（既知バグ）1〜3秒（curl相当）
モデルの動的切り替え不可可（bodyでmodelを変数指定）
主な用途シンプルなチャット・試作分類・要約・バッチ処理・本番フロー

※ AI AgentノードにOllamaを接続したい場合は、Open WebUIなどのOpenAI互換APIレイヤーを挟む必要があります。

まず試作するならパターンA、遅延が問題になるか本番に近い用途ならパターンBが適しています。

パターンA：Ollama Modelノードの設定手順

接続の流れ

Chat Trigger → Basic LLM Chain → Ollama Model（サブノード）

Credentialsの設定

n8n公式ドキュメント（Ollama Credentials）によると、デフォルトのBase URLは次のとおりです。

  • ローカルで直接起動している場合：http://localhost:11434
  • n8nをDockerで動かしている場合：http://host.docker.internal:11434
  • localhostで接続できない場合は 127.0.0.1 を試す、と公式が明記しています

主なパラメータ

  • Temperature：0〜1。高いほど出力のランダム性が増す（創造的な出力に）。低いほど安定した出力になる（分類・要約に）。
  • Top K：次のトークン候補を上位K個に絞る。低いほど予測可能な出力になる。
  • Top P：確率の累積がP以下のトークンに候補を絞る（Top Kと組み合わせて使う）。
  • num_ctx：コンテキストウィンドウサイズ。デフォルト4096。長文処理時は8192〜32768に拡張する。

Ollama ModelノードはBasic LLM ChainにのみサブノードとしてAIモデルの位置に接続します。AI Agentノードのモデルスロットには接続できません。

パターンB：HTTP RequestノードでOllama APIを直接叩く

エンドポイント

POST http://host.docker.internal:11434/api/generate

n8nをDockerで動かしている環境の場合です。ネイティブ起動であれば http://localhost:11434 を使います（接続パターンの詳細は次のセクションを参照）。

リクエストボディ（JSON）

{
  "model": "mistral",
  "prompt": "{{ $json.message }}",
  "stream": false,
  "options": {
    "num_ctx": 8192,
    "temperature": 0.3
  }
}

stream: false を明示する理由は、n8nのResponseノードがストリーミングレスポンスをネイティブに処理できないためです。stream: true のままにするとレスポンスの組み立てが正常に行われません。

レスポンスのパース

Ollama /api/generate のレスポンスはJSONで、本文は response フィールドに入ります。n8n上では次の式で取り出せます。

{{ $json.response }}

モデルの動的切り替え

前のノードで選択したモデルを渡したい場合は、bodyの model フィールドに式を使います。

{
  "model": "={{ $json['selectedModel'] || 'mistral' }}"
}

モデル名にフォールバックを設定しておくと、アップストリームで未設定のまま流れてきた場合にエラーを防げます。

num_ctx の拡張は options オブジェクト内に入れます。Ollama公式FAQに記載のあるパラメータです。

Docker / Mac / Linux 別：接続設定の早見表

環境によってBase URLとOllamaの起動方法が変わります。間違った組み合わせを使うと接続エラーになります。

環境Ollamaの起動方法n8nから使うBase URL
Linux + Docker Compose（AI Starter Kit）DockerコンテナとしてOllamaを起動http://ollama:11434（同一Composeネットワーク内）
Mac + Docker DesktopmacOSネイティブでOllamaを起動http://host.docker.internal:11434
同一マシン（n8nもOllamaもネイティブ起動）ネイティブで ollama servehttp://localhost:11434

Mac + Docker Desktopについての補足

n8n公式のSelf-hosted AI Starter Kit（GitHub）には次の記載があります。

If you’re using a Mac with an M1 or newer processor, you can’t expose your GPU to the Docker instance, unfortunately.

macOSのDockerコンテナはGPUに直接アクセスできません。ただしこれはmacOS固有のDocker制約であり、「Macで動かない」わけではありません。OllamaをmacOSネイティブで起動すれば、CPUまたはApple SiliconのGPU（Metal）を使いながら、Dockerで動くn8nから host.docker.internal 経由で接続できます。

CORS設定

別コンテナや別ホストからOllamaにアクセスする場合、起動時に次の環境変数を設定して全インターフェースにバインドします。

OLLAMA_HOST=0.0.0.0:11434

Docker Composeの場合は environment: セクションに追加します。

モデルの保存先パス

  • macOS：~/.ollama/models
  • Linux：/usr/share/ollama/.ollama/models

モデルが見つからない場合はパスを確認してください。

実装例：SlackメッセージをローカルでAI分類してGoogle Sheetsに記録する

n8nの公式テンプレート #13811「Build a private Llama chatbot with Ollama, Groq, Slack and Google Sheets」はこのユースケースの参考になります。Google Sheetsが毎ターンの会話を記録し、Slackへの返信はエスカレーション時のみ発火する構成です。

以下はこのテンプレートをベースにしたフロー構成の概要です。

フロー全体の流れ

Slack Event Trigger
  → Set（プロンプトを組み立て）
  → HTTP Request → Ollama /api/generate
  → Code（$json.responseをパース）
  → IF（分類結果に応じて分岐）
    → Google Sheets Append（全件ログ）
    → Slack（Hot / 要エスカレーション時のみ返信）

モデルの選択

Mistral 7B Instructは分類・要約タスクに向いているとコミュニティで広く言及されています（コミュニティ知見であり、公式ベンチマークではありません）。より軽い用途であればgemma2:2b、コンテキスト追跡が重要な場合はllama3.1:8bも候補になります。Ollamaでpull済みのモデルであれば何でも指定できます（公式ドキュメントのモデルリストは参考程度にとどめ、実際にpull可能かは ollama pull <model> で確認してください）。

分類ロジックの例（プロンプト）

以下のメッセージをHot / Warm / Support / Otherに分類してください。
メッセージ: {{ $json.text }}
カテゴリ名のみを返してください。

temperature: 0.1 に下げることで、出力が安定して分類ラベルのみが返る確率が上がります。

分岐の実装

IFノードで $json.response の値を評価します。Hot が含まれていればSlack通知ブランチ、それ以外はGoogle Sheetsへのログのみで終了させる構成が基本形です。

WhatsApp版の同様のテンプレート（#13450）では、confidence scoringを含む4カテゴリ分類をAI Agentで実装しています。ただしAI Agentを使う場合はOllamaをOpenAI互換APIとして公開する設定が別途必要になります。

GPUなしで使えるか：CPU推論の実用ライン

GPUを持っていない、あるいはまず手元の環境で試したいという場合、CPU推論での実用性を判断する必要があります。

Markaicode.comのコミュニティベンチマーク（4bit量子化モデル・参考値）によると、速度の差は次のとおりです。

推論環境7Bモデルでの速度（目安）
GPU（RTX 3070相当）約27 tok/s
CPUのみ約3.5 tok/s

GPU比で約8倍の差があります。

用途別の実用判断

  • CPU推論で動く用途：バッチ処理・社内ドキュメントへの非同期検索・夜間の自動仕分け・応答速度に余裕がある社内ツール。7B以下の量子化モデル（Q4_K_M）であれば、処理が完了すれば良い用途には使えます。
  • CPU推論では厳しい用途：リアルタイムチャットボット（1メッセージに数十秒かかる）・複数ユーザーへの同時配信。

70Bモデルは現実的なCPUでは1 tok/s未満になり、リアルタイム用途には使えません。

メモリ要件

Contabo Blogの情報によると、7Bパラメータモデルを動かす最小構成は「4 vCPU、8GB RAM、75GB ストレージ」程度とされています。モデルを安定して動かすには16GB RAMを推奨します。Mixtral 8x7Bはモデルファイルだけで約50GBのディスクを消費します。

現在使っている推論デバイスを確認する方法

ollama ps

PROCESSOR 列に 100% GPU と表示されればGPU推論、100% CPU であればCPU推論です。意図せずCPU推論になっている場合は、ここで確認できます。

既知の問題まとめ：先に知っておくと詰まらない

実装を始める前に把握しておくと、無駄なデバッグ時間を省ける問題を整理します。

  • Ollama Modelノードの20〜25秒遅延（既知バグ） 原因：n8n側のノード実装の問題（GitHub Issue #15263・v1.91.3時点でオープン中）。同じOllamaをcurlで叩くと1〜3秒。回避策はHTTP Requestノードへの切り替え。

  • Mac + Dockerで GPU が使えない（仕様・設計上の制約） 原因：macOSのDockerコンテナはGPUにアクセスできない（公式Starter Kitドキュメント明記）。回避策はOllamaをmacOSネイティブで起動し、Dockerから host.docker.internal 経由で接続する。

  • Ollama ModelノードがAI Agentノードと接続できない（仕様制約） 原因：Ollama Modelノードはtools support（function calling）に対応していない（公式ドキュメント明記）。回避策は2つ。①Open WebUIなどでOllamaをOpenAI互換APIとして公開する。②HTTP Requestで自前実装する。

  • ストリーミング（stream: true）がn8nでネイティブ未対応（設計上の制約） HTTP Requestノードでリクエストする場合は stream: false を明示してください。stream: true のままにするとレスポンスが正常に組み立てられません。

  • デフォルトコンテキスト4096トークンの不足（設定の問題） Ollama公式FAQに記載のとおり、デフォルトは4096トークンです。長文処理・長い会話履歴を使う場合は options.num_ctx を8192〜32768に設定してください。HTTP Requestノードであればリクエストボディで指定できます。

n8nとOllamaを本番に近い構成で使うために

試作が動いた段階で、本番に近い構成に整えるために必要な要素を整理します。

n8n公式のSelf-hosted AI Starter Kitは、n8n・Ollama・Qdrant・PostgreSQLの4サービスをDocker Composeで起動できるキットです。ただし公式ドキュメント（Deploy with the AI Starter Kit）には次の記載があります。

n8n designed this kit to help you get started with self-hosted AI workflows. While it’s not fully optimized for production environments

試作・PoC段階の出発点として使えますが、本番環境にそのまま使うことは想定されていません。

本番に近い構成で追加が必要な要素（概要）

  • 認証（n8nのBasic Auth / APIキー管理）
  • NginxなどのリバースプロキシとTLS終端
  • ログ設計と集約
  • 使用するOllamaモデルのバージョン固定（pullするモデルを明示的に管理）
  • バックアップとリストア手順

これらの設計・実装は構成によって変わるため、要件に合わせた設計が必要です。

GPU環境の判断については、利用者数・応答速度要件が固まった段階でGPU選定を行ってください。選定の判断軸はこちらの記事で整理しています。

→ 社内LLMサーバーのGPU選定【2026年】小さく始めるか、最初から両取りか

ワークフロー構成の相談

n8n + Ollamaの試作が動いた段階から、本番構成（認証・リバースプロキシ・モデル管理・ログ設計）への移行や、分類・要約フローの構築代行に対応しています。要件を整理したい段階からでも構いません。

自動化・n8n構築の相談はこちら

関連記事

AI・ローカルLLM活用Ollama + Open WebUI をVPS（Ubuntu）にセルフホストする手順2026AI・ローカルLLM活用n8n AIエージェント機能入門：複数ステップ推論を使ったドキュメント要約パイプラインAI・ローカルLLM活用プライベートGPT（機密データ対応LLM）の設計パターン4選
記事一覧に戻る