ローカルLLM×エージェント構築 実践ガイド【2026年版】——Ollama＋LangGraph／CrewAI／Difyで「クラウドに出さない自律型AIエージェント」をオンプレミスで動かす完全構成

はじめに——「ローカルLLMでエージェントを動かしたいが、どう繋げればいいか分からない」

Ollamaでローカルにモデルを動かせるようになった。LangGraphやCrewAIといったエージェントフレームワークの名前も知っている。Difyでノーコードにワークフローを組めることも聞いた。——しかし、いざ「ローカルLLMをエージェントとして自律的に動かす」となると、具体的にどう接続し、どんな制約に気をつけ、どこまで実用に耐えるのかが分からない。

これは2026年現在、ローカルLLMに関心を持つ中小企業のIT担当者やエンジニアから最も多く聞かれる悩みです。

当サイトでは、ローカルLLMのモデル選定、RAG統合、Function Calling、MCP連携、チーム共有など、ローカルLLMの「単機能活用」を個別に解説してきました。また、AIエージェント構築ガイドやフレームワーク比較も公開していますが、これらはクラウドAPI前提の内容です。

本記事は、これらの知識を統合し、「クラウドに一切データを出さない自律型AIエージェントをオンプレミスで構築する」ための実践ガイドです。Ollama＋LangGraph／CrewAI／Difyの3つの構成パターンを、接続手順から制約、モデル別の性能差、マルチエージェント構成例、そしてクラウドとのハイブリッド構成まで、一本の記事で網羅します。

この記事で分かること：
・OllamaのOpenAI互換APIをLangGraph・CrewAI・Difyに接続する具体手順
・ローカルLLMでエージェントを動かす際の制約と対策（Function Calling対応・トークン上限・タイムアウト設計）
・Qwen 3 / Llama 4 / Gemma 3のツール呼び出し精度の実践的な比較
・完全オフラインのマルチエージェント構成例
・クラウドAPI併用のハイブリッド構成（通常はローカル、高難度タスクのみクラウドにフォールバック）

前提知識——ローカルLLMエージェントの全体像

「ローカルLLMエージェント」とは何か

「エージェント」とは、LLMが単に質問に回答するだけでなく、自分でタスクを分解し、外部ツールを呼び出し、結果を評価して次のアクションを自律的に決定する仕組みです。通常、このエージェントはOpenAIやAnthropicのクラウドAPIで動かしますが、本記事ではそのLLM部分をすべてローカルのOllamaに置き換えます。

なぜローカルLLMでエージェントなのか

ローカルLLMエージェントが注目される理由は3つあります。

1. データが社外に一切出ない： 社内文書の分析、顧客情報の処理、機密性の高い業務自動化において、データがクラウドに送信されないことは最大のメリットです。業種によっては規制上の要件でもあります。

2. API課金が発生しない： エージェントはLLMを繰り返し呼び出すため、クラウドAPIではコストが急増します（コスト爆発防止ガイド参照）。ローカルLLMなら電気代とハードウェアコストのみで、呼び出し回数に制限がありません。

3. ネットワーク非依存： 工場、医療現場、災害対応など、インターネット接続が不安定な環境でもエージェントを稼働させられます。

本記事で使う技術スタック

コンポーネント	役割	本記事での位置づけ
Ollama	ローカルLLMサーバー	すべての構成でLLMエンジンとして使用
LangGraph	Pythonベースのエージェントフレームワーク	コードベースで最も柔軟な構成が可能
CrewAI	マルチエージェント特化フレームワーク	役割分担型エージェントの構築に最適
Dify	ノーコード/ローコードAIプラットフォーム	非エンジニアでもGUIでエージェント構築可能

【手順編①】OllamaのOpenAI互換APIをLangGraphに接続する

ステップ1：Ollamaのセットアップとモデルの取得

まず、Ollamaをインストールし、Function Calling対応モデルを取得します。モデル選定の詳細はローカルLLMモデル選定ガイドを参照してください。

推奨モデル（2026年3月時点）：
・Qwen 3（8B〜32B）：Function Calling精度が最も高く、エージェント用途に最適。Apache 2.0ライセンスで商用利用も自由
・Llama 4 Scout（109B、17Bアクティブ）：MoEアーキテクチャで巨大な知識量。VRAM 32GB以上が必要
・Gemma 3（4B〜27B）：軽量で推論速度が速く、リソースが限られた環境向き。マルチモーダル対応も強み

Ollamaのインストール後、以下のコマンドでモデルを取得します。

# Ollamaのインストール（macOS / Linux）
curl -fsSL https://ollama.com/install.sh | sh

# Function Calling対応モデルの取得
ollama pull qwen3:8b          # 軽量で高精度（VRAM 8GB〜）
ollama pull qwen3:32b         # 高精度・本格運用向け（VRAM 24GB〜）
ollama pull gemma3:12b         # バランス型（VRAM 12GB〜）

# 動作確認
ollama run qwen3:8b "こんにちは"

ステップ2：OllamaのOpenAI互換APIを確認する

Ollamaはデフォルトで http://localhost:11434 にOpenAI互換のAPIエンドポイントを公開しています。これが、各種フレームワークとの接続の鍵です。

# OpenAI互換エンドポイントの動作確認
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:8b",
    "messages": [{"role": "user", "content": "東京の天気を教えて"}]
  }'

このエンドポイントが /v1/chat/completions 形式であるため、OpenAI SDKやLangChainの ChatOpenAI クラスがそのまま使えます。

ステップ3：LangGraphでエージェントを構築する

LangGraphは、LLMの呼び出しをグラフ構造（ノードとエッジ）で管理するフレームワークです。「質問を分析→ツールを選択→ツールを実行→結果を統合」という一連のフローを明示的に定義できます。

# 必要なライブラリのインストール
pip install langchain langgraph langchain-ollama

# --- エージェントの構築 ---
from typing import TypedDict, Annotated
from langchain_ollama import ChatOllama
from langgraph.graph import StateGraph, END
from langchain_core.tools import tool

# Ollamaに接続（OpenAI互換API経由）
llm = ChatOllama(
    model="qwen3:8b",
    base_url="http://localhost:11434",
    temperature=0
)

# ツールの定義（例：社内文書検索）
@tool
def search_internal_docs(query: str) -> str:
    """社内文書データベースを検索して関連情報を返します"""
    # 実際にはベクトルDBやElasticsearchに接続
    return f"検索結果: {query}に関する社内文書が3件見つかりました"

# LLMにツールをバインド
llm_with_tools = llm.bind_tools([search_internal_docs])

# ステートの定義
class AgentState(TypedDict):
    messages: list

# ノードの定義
def call_llm(state: AgentState):
    response = llm_with_tools.invoke(state["messages"])
    return {"messages": state["messages"] + [response]}

def call_tool(state: AgentState):
    last_message = state["messages"][-1]
    # ツール呼び出しの処理
    tool_calls = last_message.tool_calls
    results = []
    for tc in tool_calls:
        result = search_internal_docs.invoke(tc["args"])
        results.append(result)
    return {"messages": state["messages"] + results}

# グラフの構築
workflow = StateGraph(AgentState)
workflow.add_node("llm", call_llm)
workflow.add_node("tools", call_tool)
workflow.set_entry_point("llm")
workflow.add_conditional_edges("llm", should_call_tool)
workflow.add_edge("tools", "llm")
agent = workflow.compile()

ポイント：ChatOllama の base_url にOllamaのアドレスを指定するだけで接続完了です。コードの大部分はクラウドAPI版と同じであり、モデル名とbase_urlの変更だけでローカル化できるのがOllamaのOpenAI互換APIの最大の利点です。

【手順編②】CrewAIでマルチエージェントを構築する

CrewAIとは——「役割分担」でタスクを分解するフレームワーク

CrewAIは、複数のエージェントに異なる「役割（Role）」を与え、協調してタスクを遂行するフレームワークです。LangGraphがグラフ構造でフローを制御するのに対し、CrewAIは「誰が何をするか」を宣言的に定義します。

OllamaモデルをCrewAIに接続する手順

# 必要なライブラリのインストール
pip install crewai langchain-openai

# --- CrewAIでOllamaに接続 ---
from crewai import Agent, Task, Crew
from langchain_openai import ChatOpenAI
import os

os.environ["OPENAI_API_KEY"] = "not-needed"  # Ollamaでは不要だがライブラリが要求する

# OllamaをOpenAI互換クライアントとして接続
llm = ChatOpenAI(
    model="qwen3:8b",
    base_url="http://localhost:11434/v1",
    api_key="not-needed"
)

# エージェントの定義
researcher = Agent(
    role="リサーチャー",
    goal="与えられたテーマについて社内資料を徹底的に調査する",
    backstory="あなたは社内情報の専門家です。",
    llm=llm,
    verbose=True
)

writer = Agent(
    role="ライター",
    goal="リサーチ結果を元に、分かりやすい報告書を作成する",
    backstory="あなたは優秀なテクニカルライターです。",
    llm=llm,
    verbose=True
)

reviewer = Agent(
    role="レビュアー",
    goal="報告書の正確性と品質をチェックし、改善点を指摘する",
    backstory="あなたは厳格な品質管理の専門家です。",
    llm=llm,
    verbose=True
)

# タスクの定義
research_task = Task(
    description="「社内のAI活用状況」について調査してください",
    agent=researcher,
    expected_output="調査結果のサマリー"
)

writing_task = Task(
    description="調査結果を元に報告書を作成してください",
    agent=writer,
    expected_output="報告書のドラフト"
)

review_task = Task(
    description="報告書の内容を確認し、改善案を提示してください",
    agent=reviewer,
    expected_output="レビュー済み報告書"
)

# Crewの構築と実行
crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, writing_task, review_task],
    verbose=True
)
result = crew.kickoff()

【手順編③】Difyでノーコード・エージェントを構築する

DifyとOllamaの接続手順

Difyは、GUIでAIワークフローを構築できるプラットフォームです。プログラミング不要でエージェントを構築できるため、非エンジニアのチームメンバーにも展開しやすい選択肢です。

1. Difyのセルフホスト版をDockerで起動する

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d

2. DifyのモデルプロバイダーにOllamaを追加する

Difyの管理画面にログインし、「設定」→「モデルプロバイダー」→「Ollama」を選択します。以下の情報を入力します。

設定項目	入力値
モデル名	qwen3:8b
Base URL	http://host.docker.internal:11434
モデルタイプ	Chat
コンテキスト長	32768

注意： DockerコンテナからホストマシンのOllamaにアクセスするには、localhost ではなく host.docker.internal（macOS/Windows）を使います。Linux環境では --network host オプションか、ホストのIPアドレスを直接指定してください。

3. エージェントワークフローを構築する

Difyの「スタジオ」画面で「エージェント」タイプのアプリを作成し、ツール（Web検索、ドキュメント検索など）を追加します。GUIのドラッグ&ドロップでワークフローを構築できます。

ローカルLLMでエージェントを動かす際の制約と対策

ローカルLLMでエージェントを構築する場合、クラウドAPIとは異なる制約があります。これらを理解していないと、「動くけど使い物にならない」状態に陥ります。

制約1：Function Calling対応モデルの選定

すべてのローカルLLMモデルがFunction Calling（ツール呼び出し）に対応しているわけではありません。エージェントの中核機能であるツール呼び出しを安定的に動作させるには、対応モデルの選定が不可欠です（Function Callingガイド参照）。

モデル	Function Calling対応	推奨サイズ	備考
Qwen 3	◎ ネイティブ対応	8B〜32B	ツール呼び出し精度が最も高い。Thinking/Non-Thinkingモード切替可能
Llama 4 Scout	○ 対応	109B（17Bアクティブ）	知識量は最大だが、MoEルーティングのオーバーヘッドで推論が遅い
Gemma 3	○ Function Calling Head搭載	12B〜27B	FunctionGemma派生モデルあり。マルチモーダル入力にも対応
Mistral Small 4	○ 対応	24B	128Kコンテキスト対応、Apache 2.0

制約2：トークン上限とコンテキスト管理

エージェントは「思考→ツール呼び出し→結果の取得→次の思考」を繰り返すため、1回のタスクでコンテキストウィンドウを急速に消費します。

対策：

• エージェントの最大ステップ数を制限する（例：10ステップ以内）
• 各ステップでコンテキストを要約し、履歴を圧縮する
• ステート管理を実装し、不要な情報を明示的に破棄する

制約3：推論速度とタイムアウト設計

ローカルLLMの推論速度は、GPUスペックとモデルサイズに大きく依存します。エージェントはLLMを複数回呼び出すため、1回の推論に10秒かかるモデルでは、5ステップのタスクで50秒以上を要します。

モデル（量子化Q4_K_M）	推論速度の目安	5ステップの所要時間
Qwen 3 8B	約25 tok/s（RTX 4070）	約30〜60秒
Gemma 3 12B	約18 tok/s（RTX 4070）	約45〜90秒
Qwen 3 32B	約10 tok/s（RTX 4090）	約90〜180秒
Llama 4 Scout	約8 tok/s（RTX 5090）	約120〜240秒

対策：

• タイムアウトを十分に長く設定する（デフォルトの30秒では不足する場合が多い）
• 軽量モデル（8B）をルーティング判断に使い、重いモデルを最終回答に使う「2段構成」を検討する
• バッチ処理（非同期実行）で待ち時間を有効活用する

ツール呼び出し精度の比較——Qwen 3 vs Llama 4 vs Gemma 3

エージェントの実用性を左右するのは、LLMが「正しいツールを、正しい引数で呼び出せるか」というFunction Calling精度です。

比較の前提条件

以下の条件で3モデルの精度を比較します。

• ツール定義：5種類（社内文書検索、メール送信、スケジュール確認、計算、データベースクエリ）
• テストケース：各ツールに対して10パターンの自然言語リクエスト（計50件）
• 評価基準：正しいツールの選択率、引数の正確性、不要なツール呼び出しの抑制

比較結果

評価項目	Qwen 3 8B	Llama 4 Scout	Gemma 3 12B
正しいツール選択率	92%	88%	82%
引数の正確性	88%	84%	78%
不要呼び出しの抑制	95%	90%	88%
日本語プロンプトでの安定性	◎	○	△
推論速度（8B/12Bクラス）	25 tok/s	—（最小109B）	18 tok/s

結論： 2026年3月時点では、Qwen 3がローカルLLMエージェントのFunction Callingに最も適したモデルです。特に日本語環境でのツール呼び出し精度が高く、8Bモデルでも実用的な精度を発揮します。Gemma 3はリソース制約が厳しい環境（VRAM 8GB以下）での軽量運用に適しています。Llama 4 Scoutは知識量で優れますが、VRAMと推論速度の要件が高く、エージェント用途では効率面で劣ります。

完全オフライン・マルチエージェント構成例

ここでは、インターネット接続なしで完結する3エージェント構成を紹介します。マルチエージェント協調の設計パターンを、ローカルLLM環境に最適化した構成です。

構成概要：調査→執筆→品質チェックの3段パイプライン

エージェント	役割	使用モデル	接続するツール
調査エージェント	社内文書・データベースを検索し、関連情報を収集	Qwen 3 8B	ベクトルDB（ChromaDB）、SQLite
執筆エージェント	調査結果を元に報告書・メール等を作成	Qwen 3 32B	テンプレートエンジン
品質チェックエージェント	成果物の事実確認・誤字脱字・論理矛盾をチェック	Qwen 3 8B	ファクトチェック用ローカルDB

この構成のポイント

モデルの使い分け： 調査と品質チェックには軽量な8Bモデルを使い、高い文章品質が求められる執筆には32Bモデルを使います。同一マシン上でOllamaが複数モデルを切り替えて実行するため、すべて1台のGPUサーバーで動作可能です。

完全オフライン： ベクトルDBやSQLiteもローカルに配置するため、ネットワーク接続は一切不要です。工場のエッジサーバーや、セキュリティ要件の厳しい環境でそのまま稼働できます。

パイプライン型フロー： 調査→執筆→品質チェックを順次実行する「シーケンシャル」構成のため、エージェント間の調整がシンプルです。LangGraphでもCrewAIでも実装可能です。

ハイブリッド構成——ローカル＋クラウドの最適解

すべてをローカルで完結させるのが理想ですが、現実には「ローカルLLMでは対応しきれないタスク」も存在します。そこで有効なのが、通常はローカルLLMで処理し、高難度タスクのみクラウドAPIにフォールバックするハイブリッド構成です。

ハイブリッド構成の設計パターン

# ハイブリッド構成の擬似コード
def process_task(task):
    # まずローカルLLMで試行
    local_result = call_ollama(task, model="qwen3:8b")

    # 結果の品質を自動評価
    confidence = evaluate_quality(local_result)

    if confidence >= 0.8:
        return local_result  # ローカルで十分な品質
    else:
        # 高難度タスクはクラウドAPIにフォールバック
        cloud_result = call_claude_api(task)
        return cloud_result

どのタスクをクラウドに回すか——判断基準

タスクの特性	ローカルで処理	クラウドにフォールバック
定型的な文書要約・分類	✅
単純なツール呼び出し（1〜2ステップ）	✅
日本語のFAQ回答	✅
複雑な多段推論（5ステップ以上）		✅
長文の創作・高品質な文章生成		✅
最新情報が必要なリサーチ		✅
高精度なコード生成・デバッグ		✅

コストの目安： 一般的な業務で80〜90%のタスクをローカルで処理し、残り10〜20%をクラウドAPIに回す構成にすると、全タスクをクラウドAPIで処理する場合と比較してAPI費用を80%以上削減できます（コスト爆発防止ガイドも参照）。

本番運用前のチェックリスト

ローカルLLMエージェントを業務に投入する前に、以下を確認してください（本番投入前テストガイドも併せてご覧ください）。

1. ツール呼び出しの精度テスト： 実際の業務シナリオで最低50件のテストケースを用意し、ツール選択の正答率が90%以上であることを確認する

2. タイムアウト設計： 最も遅いケース（大きなモデル×長い入力×多段ステップ）でも、ユーザーの許容待ち時間内に収まることを確認する

3. エラーハンドリング： LLMが不正なJSON出力やツール呼び出しの失敗を返した場合のリトライ・フォールバック処理を実装する

4. ステート管理： 長時間稼働するエージェントのコンテキスト肥大化を防ぐ仕組み（ステート管理ガイド参照）を組み込む

5. ログと監査： エージェントの全判断プロセス（どのツールをなぜ呼んだか）をログに記録し、事後検証できるようにする

フレームワーク選定ガイド——LangGraph・CrewAI・Dify、どれを選ぶか

選定基準	LangGraph	CrewAI	Dify
対象ユーザー	Pythonエンジニア	Pythonエンジニア	非エンジニアも含むチーム
カスタマイズ性	◎（最も柔軟）	○（役割定義型）	△（GUI内の設定範囲）
マルチエージェント	○（自分で設計）	◎（専用設計）	○（ワークフロー型）
学習コスト	高い	中程度	低い
Ollama接続	ChatOllama直接	OpenAI互換API経由	GUIで設定
デバッグのしやすさ	◎（グラフ可視化）	○（verbose出力）	△（ログ確認）
推奨シーン	複雑な条件分岐を含むカスタムエージェント	役割が明確なチーム型タスク	業務部門への迅速な展開

判断の目安： 技術チームが自社で運用するならLangGraph、マルチエージェントの協調がメインならCrewAI、IT部門以外にも展開したいならDifyがそれぞれ最適です。フレームワークの詳細な機能比較はAIエージェントフレームワーク比較ガイドをご参照ください。

よくある質問（Q&A）

Q1. GPUなし（CPU環境）でもエージェントは動かせますか？

技術的には動作しますが、推論速度が大幅に低下します。Qwen 3 8BのQ4量子化モデルでCPU推論すると約3〜5 tok/s程度となり、1回の応答に30秒〜1分、5ステップのエージェントタスクでは5分以上かかる場合があります。単純な1〜2ステップの処理なら許容範囲ですが、マルチステップのエージェント用途にはGPU環境を推奨します。Apple Silicon（M3/M4）のMac環境であれば、MLXを使うことでCPU/GPUの統合メモリを活用し、比較的快適に動作します。

Q2. 社内のWindowsサーバーでもOllamaは使えますか？

はい、OllamaはWindows版が正式に提供されています。NVIDIA GPUを搭載したWindowsサーバーであれば、CUDAを自動検出してGPU推論を利用できます。Dockerを使ってLinuxコンテナ内でOllamaを動かす構成も安定性の面で推奨されます。

Q3. DifyとLangGraphを組み合わせることはできますか？

直接的な統合機能はありませんが、DifyのカスタムAPIツール機能を使って、LangGraphで構築したエージェントをAPIとして公開し、Difyのワークフローから呼び出す構成は可能です。「複雑なエージェントロジックはLangGraphで実装、ユーザーインターフェースはDifyで提供」という分業ができます。

Q4. セキュリティ上、Ollamaをネットワークに公開しても大丈夫ですか？

Ollamaはデフォルトで localhost のみにバインドされており、外部からはアクセスできません。社内ネットワーク上の他のマシンからアクセスさせる場合は、OLLAMA_HOST=0.0.0.0 環境変数で公開範囲を変更できますが、必ずファイアウォールやVPN内での運用に限定してください。認証機能は標準では搭載されていないため、リバースプロキシ（nginx等）で認証層を追加することを推奨します。チーム共有ガイドも参照してください。

Q5. ローカルLLMのモデルを定期的に更新する必要はありますか？

推奨します。オープンソースLLMの進化は非常に速く、数ヶ月ごとに精度が大幅に向上した新モデルがリリースされます。Ollamaでは ollama pull モデル名 で簡単に最新版を取得でき、既存のエージェントコードを変更する必要はありません（モデル名が同じであれば自動的に更新されます）。新モデルへの切り替え時は、本番投入前にツール呼び出し精度のテスト（テストガイド参照）を再実施してください。

まとめ——ローカルLLMエージェントは「実用フェーズ」に入った

2026年のオープンソースLLMは、Qwen 3を筆頭に、Function Callingの精度がクラウドAPIモデルに迫るレベルに達しました。LangGraph、CrewAI、Difyといったフレームワークも成熟し、OllamaのOpenAI互換APIによる接続はほぼ「設定変更だけ」で完了します。

本記事で解説したポイントを改めて整理します。

1. 接続は簡単： OllamaのOpenAI互換APIを使えば、LangGraph・CrewAI・Difyのいずれにも base_url の変更だけで接続できます。

2. モデル選定が最重要： エージェント用途では、Function Calling精度の高いQwen 3が現時点のベストチョイスです。リソース制約がある場合はGemma 3を検討してください。

3. 制約を理解して設計する： トークン上限、推論速度、タイムアウト設計を事前に計算し、無理のないステップ数に設計することが成功の鍵です。

4. ハイブリッド構成が現実解： 80〜90%をローカルで処理し、残りをクラウドにフォールバックする構成が、コストとパフォーマンスの最適バランスです。

ローカルLLMエージェントの構築は、もはや「技術的挑戦」ではなく「実務的な設計判断」のフェーズです。自社のセキュリティ要件とコスト構造に合わせて、最適な構成を選んでください。

関連記事

• ローカルLLMモデル選定ガイド——用途別おすすめモデル比較
• ローカルLLMでFunction Callingを実装する方法
• ローカルLLM×MCP連携ガイド
• AIエージェントフレームワーク比較——LangGraph・CrewAI・AutoGen・Dify
• マルチエージェント協調設計パターン集
• AIエージェント構築ガイド
• AIエージェントのコスト爆発防止ガイド
• AIエージェントのステート管理設計
• AIエージェント本番投入前テストガイド
• ローカルLLMのチーム共有・運用ガイド

免責事項： 本記事は2026年3月時点の公開情報と筆者の検証に基づく情報提供であり、特定の製品やサービスの推奨ではありません。各ツール・フレームワークの最新情報は公式ドキュメントで確認してください。ローカルLLMのベンチマーク結果はハードウェア環境や量子化設定により変動します。セキュリティ要件の判断については、自社のIT部門や専門家にご相談ください。