n8nとOllamaを連携させてローカルLLMをワークフローに組み込んでいる。OpenAIのAPI費用をゼロにしたいという動機ではじめたが、副次効果として社内データのプライバシー保護とオフライン動作という利点も得られた。
ただし「ローカルLLMがあれば全部OpenAIから移行できる」という話ではない。実際に使ってみると、GPT-4oとの性能差が処理によっては無視できないレベルで存在する。この記事では、どんな処理なら使えてどんな処理では使わない方がいいかを含めて書く。
この記事でわかること：
- OllamaのインストールとLlama 3のセットアップ手順
- n8nのOllamaノードの設定方法
- 実務で使えるワークフロー例3つ（RAG・メール分類・CSV分析）
- ローカルLLMの限界とGPT-4oとの使い分け基準
n8n + Ollamaで何ができるか、まず整理する
OllamaとはローカルでLLMを動かすためのツール
Ollamaは、LLM（大規模言語モデル）をローカルマシン上で実行するためのオープンソースツールだ。Llama 3・Mistral・Phi-3・Qwen・CodeLlamaなど主要なオープンソースモデルに対応している。
公式サイト（https://ollama.com/）からインストーラーをダウンロードするか、コマンド1行でインストールできる。インストール後は ollama run llama3 のようにコマンドを実行するだけで指定のモデルが動く。
内部的にはOpenAI互換のREST APIをローカルで提供する（デフォルトポート：11434）。このAPIをn8nから呼び出すことで、OpenAI APIを使う感覚でローカルのLLMを使えるようになる。
n8nにはOllamaノードが標準で組み込まれており、Base URLにローカルサーバーのアドレスを入力するだけで接続できる。追加のAPI認証設定は不要だ。
API費用ゼロ・プライバシー保護・オフライン処理という3つのメリット
n8n + Ollamaを使う主なメリットは3つだ。
メリット①：API費用ゼロ
OpenAI GPT-4o-miniの場合、1Mトークンあたり入力$0.15・出力$0.60かかる。月100本の記事要約を自動化するとすれば、1本あたり2,000トークン程度使用するとして月額$0.30程度とわずかに見えるが、処理量が増えれば増えるほど積み上がる。Ollamaならモデルを一度ダウンロードすれば追加費用はゼロだ。
メリット②：プライバシー保護
社内の機密情報・個人情報・未公開データをOpenAI APIに送ると、利用規約上はデータがAIの学習に使われないとされているが、組織のセキュリティポリシーやコンプライアンス要件によっては外部APIへのデータ送信が禁止されている場合がある。Ollamaならデータがローカルを出ないため、この問題が発生しない。
メリット③：オフライン処理・レート制限なし
インターネット接続が不安定な環境やセキュリティ上の理由で外部接続が制限されている環境でも動作する。またOpenAI APIのレート制限（1分あたりのリクエスト数・トークン数の上限）がないため、バッチ処理で大量データを一気に処理できる。
セットアップ手順：OllamaとLlama 3をインストールしてn8nと繋ぐ
Ollamaのインストールとモデルのダウンロード
macOSの場合：
brew install ollama
またはOllamaの公式サイトからmacOSインストーラーをダウンロードしてインストールする。
Linuxの場合：
curl -fsSL https://ollama.com/install.sh | sh
インストール後、Ollamaサービスを起動する：
ollama serve
次に使用するモデルをダウンロードする。Llama 3 8Bモデル（約5GB）の場合：
ollama pull llama3
Windowsの場合： 公式サイトのWindowsインストーラーを使用する（2024年後半からWindowsが正式対応）。
モデルが動いているか確認するには：
ollama run llama3 "日本語で自己紹介してください"
と実行して応答が返ってくれば成功だ。
なお、Llama 3 8Bの最低動作環境は約8GB VRAM（GPU）または16GB RAM（CPUで実行の場合）。自分のMac（M2、16GB RAM）ではCPU実行で応答速度が数秒〜十数秒程度かかった。Llama 3 70Bは試したが遅すぎて実用にならなかった。8Bモデルに絞ることを推奨する。
n8nのOllamaノードの設定方法
n8nのワークフロー編集画面でノードを追加する際、「Ollama」で検索するとOllamaノードが表示される。
設定方法：
- Ollamaノードをワークフローに追加する
- 「Credentials」から新規クレデンシャルを作成する
- 「Base URL」に
http://localhost:11434を入力する（n8nがローカルで動いている場合） - 「Model」欄でダウンロード済みのモデルを選択する（例：llama3）
n8nをDockerで動かしている場合は注意が必要だ。DockerコンテナのネットワークからはlocalhostではなくホストマシンのIPを指定する。Dockerの場合は http://host.docker.internal:11434（macOS/Windows）または http://172.17.0.1:11434（Linux）を使う。
AI AgentノードとOllamaを組み合わせる場合：
AI Agentノードの「Chat Model」設定で「Ollama Chat Model」を選択すると、AI AgentがバックエンドとしてローカルのOllamaを使うようになる。ReActループで自律的にツールを呼び出す処理もローカルLLMで動かせる（ただし後述の通り、複雑な推論タスクは精度が下がる）。
動作確認：シンプルなチャットワークフローを組む
最初の動作確認として、テキスト入力→Ollama→出力という3ノードのシンプルなワークフローを組む。
- Manual Triggerノード（手動起動用）
- Set Value（テスト用テキストを設定）
- Ollamaノード（モデル：llama3、プロンプトに前ノードの値を渡す）
このワークフローを実行してOllamaから応答が返ってくれば、基本的な接続は成功だ。
実務で使えるワークフロー例3つ
社内ドキュメントのQ&Aチャットbot（RAG構成）
RAG（Retrieval-Augmented Generation）は「関連ドキュメントを検索してLLMに渡す」構成だ。これにより、LLMが学習していないドキュメント（社内マニュアル・議事録など）についての質問に答えられるようになる。
n8nでのRAG構成：
- Document Loader（PDFやテキストファイルを読み込む）
- Recursive Character Text Splitter（テキストをチャンクに分割）
- Ollama Embeddings（テキストをベクトルに変換）
- Vector Store（Pinecone・Qdrant・In-memory等でベクトルを保存）
- ユーザー質問のVector Store検索（類似ドキュメントを取得）
- Ollamaノード（取得したドキュメントをコンテキストとして回答生成）
一点注意が必要なのは日本語の埋め込み精度だ。Ollamaの標準埋め込みモデル（nomic-embed-text等）は日本語のベクトル検索精度が英語と比べて低い。日本語ドキュメントへのQ&A精度を高めるには、OpenAIの埋め込みAPI（text-embedding-3-small: 1Mトークン$0.02と安価）を埋め込み部分だけに使い、推論部分はOllamaにする、というハイブリッド構成がコストと精度のバランスが良い。
ローカルで動くメール分類・タグ付けワークフロー
受信メールを自動分類するワークフローは、ローカルLLMに向いた典型的な処理だ。
構成：
- Gmail Trigger（新着メールを受信）
- Ollamaノード（件名と本文冒頭を分類）
- プロンプト例：「以下のメールを「問い合わせ・クレーム・情報提供・その他」のいずれかに分類してください。JSON形式で出力してください。」
- IF分岐（分類結果に応じてルーティング）
- Google Sheets（分類結果を記録）またはSlack通知
このワークフローでOllamaが使える理由は、メール分類は高度な推論が不要で「このテキストはどのカテゴリか」という判断がLlama 3 8Bでも精度よくできるからだ。実際に1ヶ月分（約200通）のメールで試したところ、分類精度はGPT-4o比で約85〜90%程度だった（複雑な文脈のメールでは誤分類が増えた）。
また、メール本文には顧客の連絡先・取引内容などが含まれるため、外部APIに送りたくないというケースにもローカル処理が適している。
機密データを含むCSVの要約・分析
社内の売上データや顧客リストをOpenAI APIに送るのをためらっている場合、Ollamaを使えばローカルで処理できる。
構成：
- Google Drive（CSVファイルを読み込む）
- CSV Parse（データをパース）
- データ整形（LLMに渡すテキスト形式に変換）
- Ollamaノード（要約・異常値検出・トレンド分析）
- Slack通知（結果を指定チャンネルに送信）
Llama 3 8Bが得意な処理は「数値データの異常値検出」や「定型フォーマットの要約」だ。「この月の売上で前月比30%以上増減した項目を列挙せよ」のような明確な指示には高い精度で応える。
一方で「この売上データからビジネス上の洞察を3つ述べよ」のような高度な推論・創造的判断はGPT-4oの方が明確に優れている。定型処理にはOllama、判断が必要な分析にはGPT-4o、という使い分けが現実的だ。
n8n + Ollama連携でよくあるトラブルと対処法
実際に使い始めると遭遇するトラブルを事前に把握しておくと、セットアップがスムーズになる。
DockerコンテナからOllamaに接続できない
最も多いのがこの問題だ。n8nをDockerで動かしている場合、OllamaのBase URLに http://localhost:11434 を設定してもエラーになる。Dockerコンテナのlocalhostはコンテナ自身を指すため、ホストマシンのOllamaサーバーには届かない。
対処方法：
– macOS / Windows（Docker Desktop使用）：http://host.docker.internal:11434 を使う
– Linux（Dockerデーモン直接使用）：http://172.17.0.1:11434 を使う（dockerの bridge networkのゲートウェイIP）
または docker-compose.yml でネットワーク設定を network_mode: host にするとlocalhostで繋がるが、セキュリティ面では推奨されない。
モデルの応答が遅すぎる
「動くは動くが実用的な速度でない」という場合の対処。
主な原因と対処：
- RAM不足でスワップが発生している：Llama 3 8Bは8GB RAMで動くが、16GB RAMを推奨する。タスクマネージャーやActivityMonitorでメモリ使用量を確認する
- CPUオンリーで動いている（GPUが使われていない）：
ollama run llama3 --verboseで実行して出力にGPU使用が表示されていない場合はGPUドライバの設定を見直す - モデルサイズが大きすぎる：70Bモデルはハイスペックマシン（GPU 40GB VRAM以上）でないと実用的でない。8B以下に絞る
自分のM2 MacBook（16GB統合メモリ）ではLlama 3 8Bで1〜3秒程度の応答速度が出ている。短いテキスト処理なら実用的なレベルだ。
JSONフォーマットの出力が崩れる
n8nワークフローでOllamaの出力をJSONとして後続ノードで処理する場合、Ollamaが正しいJSON形式で返さないことがある。
対処方法：
1. プロンプトに「必ずJSON形式のみで出力せよ。説明文は不要」と明示する
2. Ollamaノードの「Format」オプションで「JSON」を選択する（対応モデルのみ）
3. 後続にCode（Function）ノードを追加してJSONのパース・正規化処理を実装する
Llama 3はJSON出力に比較的対応しているが、モデルによっては不安定なものもある。Mistral系モデルはJSON出力の安定性が比較的高い印象だ。
モデルの日本語品質を上げるためのプロンプト工夫
Llama 3 8Bの日本語品質を少しでも上げるためのプロンプト調整のコツを書く。
- システムプロンプトを英語で書く：
You are a helpful assistant. Always respond in Japanese.のように、システムプロンプトは英語で書いた方が安定した日本語応答が得られることがある - 出力フォーマットを明示する：「箇条書き3点で答えよ」「100字以内で答えよ」のように出力形式を具体的に指定する
- few-shotの例を含める：期待する入出力の例を1〜2個プロンプトに含めると精度が上がる
ただし、日本語の微妙なニュアンスが必要な処理（顧客向け文章・ブログ記事生成）では、プロンプトの工夫で補える限界がある。そういった処理はOpenAI GPT-4oを使う方が現実的だ。
ローカルLLMの限界と使い分けの基準
GPT-4oと比べて何が劣るか
Llama 3 8BをGPT-4oと1ヶ月間並行して使ってわかった差を書く。
明確に劣る点：
– 日本語の自然さ：Llama 3 8Bは日本語の微妙なニュアンスが不自然になることがある。特に文体の指定（「敬体で書く」「ですます調で短く」）への対応がGPT-4oより精度が低い
– 複雑な推論：多段階の論理推論（数学的問題・複雑な因果関係の分析）はGPT-4oが明確に上回る
– 長文コンテキスト：コンテキストウィンドウはLlama 3 8Bが128K（理論値）だが、長いコンテキストになると後半の内容を忘れる傾向がある
– 指示への精密な追従：「JSON形式で出力せよ」という指示でも、形式が崩れることがGPT-4oより多い
大きな差がない点：
– 短い定型テキストの分類・タグ付け
– 英語のテキスト要約
– 単純なデータ抽出・変換
「クラウドLLM vs ローカルLLM」の使い分け判断フロー
以下の判断基準で使い分けている：
ローカルLLM（Ollama）を選ぶ条件：
– データにプライバシー上の懸念がある（顧客情報・社内機密）
– 処理量が多くAPI費用が無視できない規模になっている
– 処理精度への要求が高くない（分類・タグ付け・定型抽出）
– オフライン環境での動作が必要
クラウドLLM（OpenAI等）を選ぶ条件：
– 日本語の品質が重要（顧客向けメール・コンテンツ生成）
– 複雑な推論・判断が必要
– セットアップの手間を省きたい
– 処理量が少なくAPI費用が低い
コスト面では、月のAPI費用が$10〜20を超えるような用途からローカルLLMへの移行を検討し始めると現実的だ。ただしマシンの電気代（GPUで常時稼働の場合は月数百円〜数千円程度）や、初期セットアップの時間コストも考慮に入れる必要がある。
まとめ：「費用ゼロ・プライバシー保護」が必要な処理に絞ると価値がある
n8n + Ollamaの組み合わせは、使い方を絞れば確かに価値がある。特に「APIコストを削減したい」「社内データを外部に出したくない」という要件がある場合には有効な選択肢だ。
ただし「全部OpenAIから乗り換えられる」という期待は裏切られる。日本語対応・複雑な推論・精密な指示追従という点では、Llama 3 8BはGPT-4oに及ばない。
実務での結論として、自分は以下の使い分けで落ち着いている：
- Ollama：英語ドキュメント処理・数値データの定型分類・バッチ処理・プライバシーが重要なデータ
- GPT-4o / GPT-4o-mini：日本語コンテンツ生成・複雑な推論・高品質な文章生成が必要な処理
Ollamaの日本語対応は新モデルが出るたびに改善されている。QwenやPhi-3などの多言語モデルも選択肢として増えており、1〜2年後には使い分けの境界が変わっているかもしれない。ただし2026年4月時点では「日本語の品質が重要な処理にはまだクラウドLLMが必要」というのが正直な評価だ。
セットアップコストは思ったより低い。Ollamaのインストールは10分以内で終わり、n8nとの接続も設定は数分だ。コスト削減やプライバシー保護の要件があるなら、まず試してみる価値はある。
日本語でのOllama活用についての情報はZennのollama関連記事やQiitaのOllamaタグでも増えてきているので参考にしてほしい。
合わせて読みたい
- n8n AI Agentノードを自腹で試した：LLMと繋ぐだけで何ができて何ができないか正直に書く
- n8nの使い方入門：ワークフローの基本をゼロから理解する
コメント