社内向けのAIエージェントを検討していて、OpenAIやAnthropicのAPIにデータを送りたくないという要件に直面したことはないでしょうか。n8n（ノーコードでワークフローを組める自動化ツール）とOllama（ローカルでLLMを動かすランタイム）を組み合わせる構成は、そうした要件への現実的な選択肢の一つです。この構成が自分のプロジェクトに合うかどうかを、非機能要件の観点から整理します。
この組み合わせは、n8nが提供する公式のSelf-hosted AI Starter Kitで手早く試せます。DockerComposeのテンプレートにn8n、Ollama、Qdrant（ベクトル検索用のデータベース）、PostgreSQLがまとめて入っており、コンテナ同士が自動的に接続される設計です。試すだけなら数分で立ち上がりますが、「試せる」ことと「本番で運用できる」ことは別の話です。
どんな場面でこの判断が必要になるか
典型的には、顧客データや社内文書を扱うAIエージェントを検討していて、クラウドLLMへの外部送信がセキュリティポリシー上NGになった場面が挙げられます。
もう一つは、APIコストが従量課金で膨らみ、固定費であるGPUサーバーに寄せたほうが経済的かどうかを見積もる場面です。
どちらの場面でも、n8n+Ollamaは選択肢に上がりますが、採用する前に押さえておきたい判断軸があります。
判断軸
データ主権: データが外部に一切出ないことがどの程度の重みを持つ要件かを確認します。Ollamaはローカルまたは自社管理サーバーでLLM推論を行うため、推論データは外部のAPIエンドポイントに送られません。医療・金融など規制業界のデータや、契約書のような機密文書を扱う場合はこの軸の重要度が高くなります。逆に一般的な社内FAQボットなら、クラウドLLMでも許容されるケースもあります。
性能要件とハードウェア制約: ローカルLLMの応答品質と速度は、GPUのVRAM容量とモデルのパラメータ数に直結します。Apple SiliconのMac上でDockerを使う場合、コンテナからはGPUにアクセスできないという制約があります。そのためOllama自体はMac本体にネイティブインストールし、n8nコンテナからhost.docker.internal:11434経由で呼び出す構成が推奨されています。GPUサーバーで動かす場合はこの制約はありませんが、モデルサイズに応じたVRAM要件の見積もりが必要です。
運用の複雑さ: n8n単体、n8n+Ollama、Starter Kit全体（Qdrant・PostgreSQL含む）の3段階で運用対象が増えます。ベクトル検索を使わないシンプルなチャットボットなら、Qdrantまで導入する必要はありません。構成要素が増えるほど、障害点とアップデート対象も増える点は見落とされやすいところです。
ツール呼び出しの信頼性: n8nのAI Agentノードは、HTTPリクエストやGmail連携などのツールをLLMに呼び出させる機能を持ちます。ただしこれはモデルがtool use（ツール呼び出し）に対応している場合に限られます。llama3.1のようにツール対応が明示されたモデルを使う必要があり、ollama.comのモデルページで「tools」タグの有無を確認してから採用するかどうかを決めます。
選択肢の比較
| 構成 | データ外部送信 | 初期コスト | 運用負荷 |
|---|---|---|---|
| クラウドLLM API単体 | あり | 低い（従量課金） | 低い |
| n8n単体+クラウドLLM | あり | 低〜中 | 中（ワークフロー保守） |
| n8n+Ollama（Mac/単体GPU機） | なし | 中（ハードウェア次第） | 中〜高 |
| Starter Kit全体（Qdrant含む） | なし | 高 | 高（構成要素4つ） |
ケース別の推奨
データを一切外部に出せない要件があり、既にGPU搭載マシンかMacを持っているなら、n8n+Ollamaの組み合わせを選ぶ根拠は十分にあります。まずはStarter Kitでなくn8n単体とOllamaだけの構成から試し、必要なノードを見極めるのが無理のない進め方です。
社内の技術文書検索のように、文書量が多くベクトル検索が前提になるなら、Starter Kit全体（Qdrant込み）を選ぶ理由があります。ただしPostgreSQLとQdrantの運用・バックアップ体制も同時に検討する必要があります。
エージェントに外部API呼び出しやメール送信などのツール実行を任せたいなら、llama3.1のようなtool use対応モデルを選び、事前にollama.comのモデルページでタグを確認してから組み込みます。
あえて見送るべき条件
社内に運用担当が薄く、GPUサーバーの調達・保守にリソースを割けない場合は、クラウドLLM＋n8nの組み合わせで様子を見るほうが現実的です。ローカルLLMは無料に見えても、ハードウェアと運用の人的コストが乗ってきます。
扱うタスクが高度な推論や長文コンテキストを要求する場合も注意が必要です。ローカルで動かせるモデルサイズはVRAM制約を受けるため、クラウドの大規模モデルに性能面で見劣りする場面があります。タスクがローカルモデルの能力で足りるかどうかは、事前にモデルのパラメータ数やコンテキスト長を確認しておくべき点です。
接続トラブルを運用中に頻発させたくない場合、n8nとOllamaの配置関係（同一Dockerネットワークか、ホストマシン上にOllamaがあるか）によってベースURLの指定方法（host.docker.internalかサービス名かplainなlocalhostか）が変わる点も、事前に整理しておく必要があります。
まとめ
n8n+Ollamaは、データを外部に出したくない要件があり、かつGPUリソースと運用体制を用意できる場合に理にかなう構成です。
判断の起点は、データ主権の要件がどれだけ厳格か、そしてハードウェアと運用負荷を引き受けられるかの2点に尽きます。
まず手元の環境でollama pull llama3.1を実行し、ollama listでモデルが使えるかを確認し、n8nのCredentials画面でベースURLの接続テストをしてみると、自分のケースに当てはまるかどうかの手触りが得られます。