Ollamaとn8nを連携させる方法｜ローカルLLMでメール・Slack・CSVの業務フローを自動化する手順

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ローカルLLM ＞ Ollamaとn8nを連携させる方法｜ローカルLLMでメール・Slack・CSVの業務フローを自動化する手順

「業務フローはn8nで自動化しているが、LLM連携の部分だけ外部クラウドAPIに頼っている」
「顧客情報や社内文書をクラウドAIサービスに送ることへのコンプライアンスリスクが消えない」

そんな悩みを抱えるLinuxエンジニアや情報システム担当者は多いはずです。この記事では、オープンソースのワークフロー自動化ツール「n8n」とOllamaを連携させ、メール自動分類・Slack要約翻訳・CSVバッチ解析の3つの業務フローを完全なローカルLLMで動かす手順を解説します。
外部APIキーを一切使わず、社内LAN内のサーバーだけで完結する構成のため、機密データを扱う現場でも導入しやすい点が特徴です。Ollamaの導入・基本設定は完了している前提で話を進めます。導入手順から確認したい方は、Ubuntu ServerでローカルLLMを構築する方法を参照してください。

この記事のポイント

・n8nのHTTP RequestノードでOllamaのREST APIを呼び出し、ワークフローにローカルLLMを組み込める
・メール分類・Slack要約翻訳・CSVバッチ解析の3フローを設定例付きで解説
・タイムアウトが発生する場合はnum_ctxを削減するか軽量モデルへの切り替えで対処できる
・全データは社内LAN内のコンテナで完結し、クラウドAPIへのデータ送信は一切不要

Ollamaとn8nを連携させる方法｜ローカルLLMでメール・Slack・CSVの業務フローを自動化する手順

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

n8nとOllamaで実現するローカル業務自動化の全体像

n8nはドイツ発のオープンソースワークフロー自動化ツールです。ZapierやMakeと同じ「トリガー→アクション」の設計思想を持ちながら、セルフホスティングが可能な点が大きく異なります。GmailやSlack、Google Sheets、データベースなど350以上の外部サービスとのコネクタを標準搭載しており、ビジュアルエディタでフローを組めるため、複雑なコードをほとんど書かずに業務自動化を実現できます。

OllamaはHTTP REST APIを通じてLLMを呼び出せるため、n8nの「HTTP Request」ノードと組み合わせるだけで、どのワークフローにも自然言語処理を挿入できます。専用のOllamaノードを導入しなくても、n8nが標準で持つ汎用的なHTTPノードだけで接続できるシンプルさがこの構成の最大の利点です。

全体の構成イメージは以下のとおりです。
・n8n（Dockerコンテナ）: ワークフローエンジン兼UIホスト、処理フローをビジュアルで管理
・Ollama（Dockerコンテナまたはネイティブ）: LLM推論エンジン、テキストの分類・要約・生成を担当
・使用モデル: Llama3.3（汎用・日本語対応）またはMistral（軽量・英文処理向け）など
・通信: 同一Docker network内のサービス名で解決、または実IPを直接指定（外部インターネット不要）

情シスが最も気にするのは「データがどこに行くか」です。この構成では、メール本文・Slackメッセージ・CSVの内容がすべて社内LAN内のコンテナで処理されます。処理したデータが一切外部に出ないため、個人情報や営業秘密を含む文書でも安心して扱えます。社内でChatGPTが使えないときの代替手段として検討しているチームにとって、n8n×Ollamaはデータ主権を保ちながら業務AIを実現できる現実的な選択肢です。

n8nとFlarewiseはどちらもOllamaと連携できるノーコード系ツールですが、使い分けの目安があります。Flowiseは「AIワークフロー専用」の設計思想であり、RAGやエージェントの構築を中心とした用途に特化しています。対してn8nはメール・Slack・データベース・スプレッドシートなどの「業務システム連携」が強みです。AIが必要なのはワークフローの一部だけで、残りは既存の業務システムと統合したいという要件にはn8nの方が向いています。

n8nをDockerでLinuxサーバーにインストールする手順

n8nはDockerで動かすのが最も管理しやすい方法です。OllamaもDockerで稼働している場合は、同一のdocker-compose.ymlにまとめることで、コンテナ間通信の設定がシンプルになります。以降の手順はUbuntu 24.04 LTSにDockerがインストール済みの環境を前提とします。

1. docker-compose.ymlを作成する

作業ディレクトリを作成し、n8nとOllamaを含むcompose設定を書きます。

$ mkdir ~/n8n-ollama && cd ~/n8n-ollama $ cat > docker-compose.yml << 'EOF' version: "3.8" services: n8n: image: n8nio/n8n:latest ports: - "5678:5678" environment: - N8N_BASIC_AUTH_ACTIVE=true - N8N_BASIC_AUTH_USER=admin - N8N_BASIC_AUTH_PASSWORD=your_secure_password - WEBHOOK_URL=http://192.168.1.100:5678/ - GENERIC_TIMEZONE=Asia/Tokyo volumes: - n8n_data:/home/node/.n8n restart: unless-stopped networks: - ai_net ollama: image: ollama/ollama:latest ports: - "11434:11434" volumes: - ollama_data:/root/.ollama restart: unless-stopped networks: - ai_net networks: ai_net: driver: bridge volumes: n8n_data: ollama_data: EOF

`WEBHOOK_URL` はn8nがWebhookを受信するURLです。社内サーバーの実際のIPアドレスに置き換えてください。`N8N_BASIC_AUTH_PASSWORD` は十分に強いパスワードを設定します。GPUを使いたい場合はollamaサービスに `deploy.resources.reservations.devices` を追加してNVIDIA GPUをパススルーします。

2. コンテナを起動してOllamaモデルをダウンロードする

# コンテナをバックグラウンドで起動 $ docker compose up -d # 起動確認 $ docker compose ps NAME IMAGE STATUS n8n-ollama-n8n-1 n8nio/n8n:latest Up 2 minutes n8n-ollama-ollama-1 ollama/ollama:latest Up 2 minutes # Ollamaコンテナにモデルをダウンロード（約4.7GB） $ docker compose exec ollama ollama pull llama3.3:8b-instruct-q4_K_M # 動作確認（利用可能なモデルの一覧を取得） $ curl http://localhost:11434/api/tags {"models":[{"name":"llama3.3:8b-instruct-q4_K_M","modified_at":"2026-08-01T00:00:00Z","size":4700000000}]}

起動後、ブラウザで `http://サーバーIP:5678` にアクセスするとn8nのログイン画面が表示されます。設定したパスワードでログインし、「Workflows」→「Add Workflow」からフローの作成を始めます。

モデルの選択方法については、ローカルLLMのモデルを比較する方法を参考にしてください。日本語テキストの分類・要約にはLlama3.3が安定した品質を示します。英文処理が中心の場合はMistralの7Bモデルが速度と品質のバランスに優れた選択肢です。

OllamaのREST APIをn8nから呼び出す基本設定

n8nからOllamaを呼び出すには、標準の「HTTP Request」ノードを使います。n8nにはOllama専用のコミュニティノードも存在しますが、n8nのバージョンアップとの互換性リスクを避けるため、HTTP Requestノードで直接REST APIを叩く方法が長期運用では安定しています。

1. HTTP Requestノードの基本パラメータ設定

ワークフローキャンバスにHTTP Requestノードを追加し、以下のように設定します。
・Method: POST
・URL: `http://ollama:11434/api/generate`（同一Docker network内のコンテナはサービス名で解決される）
・Body Content Type: JSON
・Specify Body: JSON

JSON Bodyには以下のオブジェクトを設定します。`{{ $json.inputText }}` は前ノードから渡される入力テキストを参照するn8n式です。ノードの「Body Parameters」セクションを選択し、「JSON」モードに切り替えてから入力します。

{
  "model": "llama3.3:8b-instruct-q4_K_M",
  "prompt": "{{ $json.inputText }}",
  "stream": false,
  "options": {
    "num_ctx": 4096,
    "temperature": 0.2
  }
}

`stream: false` を指定することでOllamaがレスポンス全文を1つのJSONオブジェクトで返すため、後続ノードでのデータ参照が簡単になります。`stream: true` の場合はストリーミング形式となりレスポンスが断片化して扱いにくくなるため、n8n連携では必ずfalseを指定します。

2. レスポンスの受け取りと後続ノードへのデータの渡し方

Ollamaのレスポンスは `response` フィールドに文字列として格納されます。後続ノードで使う場合は `{{ $json.response }}` で参照します。特定のフィールドだけを取り出してリネームしたい場合は、直後にSet Fieldノードを配置して `{{ $json.response }}` を任意のキー名に格納します。

`num_ctx` はコンテキストウィンドウのトークン数を指定するパラメータです。メール本文や長いドキュメントを処理するには4096程度が適切ですが、VRAMが少ない環境では2048以下に抑えることで処理速度を改善できます。`temperature` は0.1～0.3程度に下げると、分類・翻訳などのタスクでの出力一貫性が向上します。創作・文章生成など多様な出力が欲しい場合は0.7～0.9に上げて使います。

また、n8nのHTTP Requestノードはデフォルトのタイムアウトが短めです。LLMのレスポンス生成が遅い場合に備え、ノードの「Options」セクションで「Timeout」を60000以上（ミリ秒）にあらかじめ設定しておくことを推奨します。

メール受信からOllama分類・返信下書き生成までのフロー構成

最初の実用フローとして、受信メールをOllamaで自動分類し、カテゴリに応じた返信下書きを生成する構成を作ります。問い合わせ対応の初動作業を自動化できるため、担当者の業務負荷を大幅に削減できます。

1. フローの全体ノード構成

・IMAPノード（トリガー）: 5分ごとに新着メールをポーリング
・Set Fieldノード: 件名と本文の先頭300文字を抽出して整形
・HTTP Requestノード（分類）: Ollamaに件名・本文を渡してカテゴリを判定させる
・Switchノード: 分類結果（問い合わせ／クレーム／発注／その他）に応じて処理を分岐
・HTTP Requestノード（下書き生成）: カテゴリに合ったプロンプトで返信文を生成
・Gmailノード（下書き保存）: 生成された返信文をGmailの下書きフォルダに保存

2. 分類プロンプトの設計と精度向上のポイント

分類精度はプロンプトの明確さに直結します。以下のテンプレートはシンプルながら実務で安定した結果を出しやすい形式です。HTTP RequestノードのJSON Bodyの`prompt`フィールドに設定します。

以下のメールを読み、次の4カテゴリのいずれか1語だけを返答してください。
カテゴリ一覧: 問い合わせ / クレーム / 発注 / その他
件名: {{ $json.subject }}
本文（先頭300文字）: {{ $json.body.slice(0, 300) }}
返答は上記カテゴリ名を1語のみ。他の文章や説明を一切含めないこと。

`temperature: 0.1` に設定すると分類の一貫性が向上します。知人のインフラエンジニアがこの構成を試したところ、300通のテストメールに対して93%以上の分類精度が得られたとのことでした。「その他」に分類されるケースを減らしたい場合は、カテゴリ数を絞るか、プロンプト内に具体的な判定基準を追加するのが効果的です。

Switchノードの設定では、Ollama出力の `{{ $json.response.trim() }}` をルール比較の対象にします。`trim()` を付けることで、レスポンスの末尾に改行や空白が混入した場合でも条件の比較が正しく機能します。

3. 返信下書き生成プロンプトの設定例

Switchノードで分岐した「問い合わせ」ブランチでは、以下のプロンプトをOllamaに渡します。

あなたは丁寧な日本語のビジネスメール担当者です。以下の問い合わせメールへの返信下書きを200文字以内で作成してください。件名: {{ $json.subject }} 本文: {{ $json.body }} 返信文の本文のみを出力してください。件名・宛名・署名は含めないこと。

生成された文字列は `{{ $json.response }}` で参照し、GmailノードのBody（メッセージ本文）フィールドに渡します。Gmail下書きフォルダに自動保存する形にしておくと、担当者がひと目確認してから送信ボタンを押す運用になり、誤送信リスクを最小化できます。クレームや発注ブランチも同じ構造で、カテゴリに合わせたプロンプトを個別に設定します。

SlackメッセージをOllamaでリアルタイム要約・翻訳するフロー構成

海外ベンダーとの英語のやり取りが多いチームや、Slackの投稿量が多く重要なメッセージを見逃しがちな現場に有効なフローです。

1. Slack Triggerノードの設定

n8nにはSlack専用のTriggerノードが用意されています。Slack Appを自社ワークスペースにインストールしてBot Token（xoxb-から始まるトークン）を取得し、n8nの「Credentials」に登録します。ノード設定で監視するチャンネルIDを指定し、新着メッセージが届くたびにフローが起動するよう設定します。

ボット自身のメッセージに反応しないよう、フロー冒頭にIF条件ノードを配置して `{{ $json.bot_id }}` が存在しない場合のみ後続処理に進む条件を設けます。これを忘れると、OllamaがSlackに投稿した返信に再びOllamaが反応するという無限ループが発生するため、必ず設定してください。

2. 要約・翻訳プロンプトの設定例

英語メッセージを日本語で要約するプロンプト例を以下に示します。

以下のSlackメッセージを日本語で100文字以内に要約してください。専門用語はそのままにし、要点だけを自然な文章で出力してください。メッセージ: {{ $json.text }}

日本語メッセージを英語に翻訳してグローバルチームに共有する逆パターンも同様に組めます。翻訳結果をSlackの返信スレッドに自動投稿するか、専用の通知チャンネルに転送するか、運用方針に合わせて後続のSlackノードを設定します。

処理速度はモデルとGPUの性能に依存します。Mistralの7Bモデル（`mistral:7b-instruct-q4_K_M`）であれば、CPUのみの環境でも平均5～10秒でレスポンスが得られます。GPUがあれば2～4秒程度に短縮されます。リアルタイム性が求められるSlack連携では、Llama3.3よりもMistralの軽量モデルを選ぶ方が体感速度は向上します。

3. 要約・翻訳結果のSlack投稿設定

Ollamaのレスポンス（`{{ $json.response }}`）を受け取ったら、Slackノードを使って結果を投稿します。元メッセージのスレッド内に返信する場合は、SlackノードのThread Tsフィールドに `{{ $json.ts }}` を渡します。

要約・翻訳の精度をモニタリングするには、結果をGoogle Sheetsや社内Wikiに自動記録するノードを末尾に追加すると便利です。n8nの350以上のコネクタがそのまま使えるため、出力先を変えるのはノードを差し替えるだけです。Slack以外の社内ツールへの統合も同じ構造で実現できます。

CSVデータをOllamaでバッチ解析するフロー構成

夜間バッチで日次レポートのCSVをOllamaに読み込ませ、異常値の検出や文章化されたサマリーを自動生成する構成を作ります。

1. CSVファイルの読み込みとループ処理の設定

n8nでCSVを処理するには、Read Binary FileノードでファイルをバイナリとしてReadし、続けてSpreadsheet Fileノードで行ごとのデータに変換します。変換後のデータを1レコードずつOllamaに渡す場合は「Loop Over Items」ノードを挟みます。

一度に大量のレコードをOllamaに送るとサーバー負荷が上がりタイムアウトが発生しやすくなるため、ループのバッチサイズは10件程度を目安にします。「Wait」ノードで1秒のインターバルを入れることでOllamaへのリクエスト集中を防ぎ、安定した動作が得られます。処理対象がCSVで数百行あっても、夜間バッチであれば時間的な余裕があるため実用上問題ありません。

2. 解析プロンプトと出力フォーマットの設計

売上データの異常検出を例にしたプロンプト設計です。

以下の売上データを読み、前日比で30%以上の増減がある場合は「異常あり」と判定し、
考えられる原因を50文字以内で述べてください。
30%未満の場合は「正常」とだけ返してください。
日付: {{ $json.date }}
商品名: {{ $json.product_name }}
前日売上: {{ $json.yesterday_amount }}
本日売上: {{ $json.today_amount }}

解析結果はSet Fieldノードで `{{ $json.response }}` を取り出し、元レコードのデータと合わせて整形します。その後、Spreadsheet Fileノードで結果CSVとして出力するか、Google Sheetsノードでスプレッドシートに書き戻すことで、担当者がリアルタイムで確認できる環境が整います。

ログファイルの異常検知にも同じ構造が使えます。journalctlの出力をn8nのExecute Commandノードで取得し、OllamaにERROR/WARNを含む行の要約と重大度の判定を依頼するフローを組むと、システム監視業務の初動対応を自動化できます。

3. Schedule Triggerで夜間バッチを自動化する

n8nのSchedule Triggerノードでフローの自動実行時刻を指定します。
・Trigger Rule: Cron
・Cron Expression: `0 2 * * *`（毎日午前2時に実行）

夜間バッチの信頼性を高めるには、Ollamaが確実に起動している状態を維持する必要があります。Dockerの `restart: unless-stopped` を設定しておけば、サーバー再起動後もコンテナが自動で立ち上がります。

CSVファイルの配置場所は、n8nコンテナがアクセスできるパスに設定します。compose設定に以下のようなボリュームマウントを追加すれば、ホスト側の任意ディレクトリをn8nコンテナから参照できます。
n8nのvolumesセクションに `- /home/tomohiro/data:/data` を追加し、Read Binary FileノードのPath設定を `/data/daily_report.csv` のように指定します。

n8n×Ollama連携時のトラブル対処と運用上の注意点

1. OllamaにDockerコンテナから接続できない（Connection refused）

Ollamaをネイティブ（Dockerなし）でインストールしている場合、デフォルトでは `127.0.0.1:11434` にバインドされるため、Dockerコンテナからは到達できません。

解決策: systemdのoverride.confを作成してバインドアドレスを変更します。

# override.confを作成
$ sudo mkdir -p /etc/systemd/system/ollama.service.d
$ sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF'
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
EOF

# 設定を反映して再起動
$ sudo systemctl daemon-reload && sudo systemctl restart ollama

# バインドアドレスの確認
$ ss -tlnp | grep 11434
LISTEN  0  128  0.0.0.0:11434  0.0.0.0:*  users:(("ollama",pid=...,fd=...))

その後、n8nのHTTP RequestノードのURL設定を `http://ollama:11434/api/generate` から `http://host.docker.internal:11434/api/generate`（Docker Desktop環境）または `http://サーバーの実IPアドレス:11434/api/generate` に変更します。

n8nとOllamaを両方Dockerで動かしている場合でも、同一のDocker networkに属していないと接続できません。composeのnetworksセクションで両サービスが同じネットワーク名を参照しているか確認してください。

2. HTTP Requestノードがタイムアウトする

n8nのHTTP Requestノードはデフォルトのタイムアウトが10秒程度に設定されています。LLMのレスポンス生成がそれより長い場合、処理が打ち切られてエラーになります。

解決策: HTTP Requestノードの「Options」セクションで「Timeout」を120000（ミリ秒、2分相当）以上に延ばします。それでも遅い場合は `num_ctx` を2048以下に減らすか、Phi-4などの軽量モデルに切り替えることで処理速度が向上します。VRAM搭載量に応じた量子化モデルの選び方については、クラスター内の関連記事も参考にしてください。

3. Ollamaのレスポンスに余分な文章が混入する

分類フローでOllamaが「はい、このメールは○○カテゴリです」のような余分な説明文を付けて返す場合があります。プロンプトに「○○のみを返答し、それ以外の文章を一切含めないこと」という制約を明示するのが効果的です。

それでも改善しない場合は `temperature` を0.05～0.1に下げます。Llama3.3はInstruct系モデルで指示への忠実度が高く、分類・抽出タスクには特に適しています。Switchノードで後続処理を分岐させる場合は、Ollamaの出力文字列を `{{ $json.response.trim() }}` でトリムしてから条件比較に使うと、空白文字や改行の混入による分岐ミスを防げます。

4. n8nのメモリ使用量が増加する

n8nはワークフロー数と実行履歴が増えるとメモリ消費量が増加します。`docker stats` で監視し、n8nコンテナが1GBを超えてきたら以下の対策を検討します。
・n8n設定画面の「Executions」で「Save Executions」の保持日数を7日程度に短縮する
・compose設定で `mem_limit: 2g` を追加してコンテナのメモリ上限を設ける
・Cron Triggerを使って定期的に `docker restart n8n` を実行する

n8n・Ollamaの両方を安定して監視するには、Prometheus+Grafanaの監視基盤と組み合わせることも選択肢のひとつです。

本記事のまとめ

n8nとOllamaを組み合わせることで、外部APIに依存しないローカル完結の業務自動化基盤を構築できます。HTTP Requestノード1つでOllama REST APIを呼び出せるシンプルな設計が、350以上のn8nコネクタとの自由な組み合わせを可能にしています。この記事で解説した主要な手順と設定値をまとめます。

フロー・設定	主要コマンド・設定値	推奨モデル
n8n起動	docker compose up -d	—
モデル取得	docker compose exec ollama ollama pull llama3.3:8b-instruct-q4_K_M	Llama3.3
Ollama API呼び出し設定	HTTP Request POST http://ollama:11434/api/generate	Llama3.3 / Mistral
メール自動分類	IMAPトリガー → HTTP Request（分類）→ Switch → Gmail下書き保存	Llama3.3 q4_K_M
Slack要約翻訳	Slack Trigger → HTTP Request（要約）→ Slack返信投稿	Mistral q4_K_M
CSVバッチ解析	Schedule Trigger → CSV Parse → Loop → HTTP Request → 結果出力	Llama3.3 q4_K_M
タイムアウト対処	HTTP Requestノードの Timeout を 120000ms に延長	—
接続エラー対処（ネイティブOllama）	override.conf に OLLAMA_HOST=0.0.0.0:11434 を追加	—

n8nの350以上のコネクタを活用すれば、今回紹介した3フロー以外にも、CRMデータのローカルAI分析・契約書の自動要約・障害ログの自動トリアージなど、幅広い現場ニーズに対応できます。
まずはメール分類フローから始め、Ollamaのレスポンス精度・速度を確認しながら段階的に用途を広げていくのが現実的なアプローチです。

n8n×Ollamaで業務自動化の全工程を2日間のハンズオンで体験する

「記事を読んだだけでは実際に動かせない」という壁を越えるには、実機で手を動かす経験が最も近道です。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。

＞＞ローカルAIマスターセミナーの詳細を確認する

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

次のページへ：Ollamaのモデルをベンチマークする方法｜応答速度・トークン/秒・VRAM使用量を実測してLinuxサーバーの最適構成を判断する手順
前のページへ：OllamaをDocker Composeでマルチサービス構成にデプロイする方法｜Open WebUI・NginxをYAMLで一元管理してチーム運用を安定化させる
この記事の属するカテゴリ：ローカルLLMへ戻る