ローカルLLM Function Calling / Tool Use 実装ガイド 2026年版:gpt-oss / Qwen 3 / Llama 4 でツール呼び出しを動かす OpenAI 互換 API 構成

結論:ローカルLLM でツール呼び出しを動かす定石は「OpenAI 互換 API の tools パラメータを、Tool Use 対応モデル (gpt-oss / Qwen 3 14B 以上 / Llama 4 / Hermes 3 8B) に渡す」一択です。ランタイムは Ollama が最短(tools をそのまま渡せる)、本番性能なら vLLM(--enable-auto-tool-choice --tool-call-parser hermes 等)、CPU/Mac 主体なら llama.cpp の --jinja フラグ。3B 級小型モデルは安定性が落ちるので、最低でも 7-8B、複数ツール並列呼び出しを使うなら 14B 以上を選ぶのが失敗しないコツです。

ローカル LLM の世界はこの 1〜2 年で「文章を生成する」から「ツールを呼ぶ」へ重心が移りました。OpenAI gpt-oss が MXFP4 ネイティブで Tool Use を持って登場し、Anthropic MCP が普及して、ローカルエージェントが現実的な選択肢になっています。本記事は「ローカル LLM に Function Calling を実装したい」人向けに、API 仕様 → モデル選び → ランタイム別実装 → 詰まりどころの順で整理します。

ハードウェア側の前提は「ローカルLLMを動かすPCの最低スペック 2026年版」「OpenAI gpt-oss 120B / 20B ローカル実行完全ガイド 2026年版」を先に押さえると、本記事の構成例が動かしやすくなります。

Function Calling とは:OpenAI 互換 API の tools パラメータ

Function Calling (=Tool Use) は、LLM に「使えるツールの一覧 (JSON Schema)」を渡し、LLM が必要に応じて「このツールをこの引数で呼んで」と返してくれる仕組みです。OpenAI が API 仕様を作り、ローカル LLM ランタイムも基本これと互換にしてあります。

最小の往復は次の 4 ステップです。

1. クライアントから送る:メッセージ + tools (関数一覧、JSON Schema) を chat completion に渡す
2. モデルが返す:通常の content の代わりに tool_calls 配列が返り、name と arguments (JSON 文字列) が入る
3. クライアント側でツール実行:返ってきた name と引数を使って実際に Python 関数 / API を叩く
4. 結果を戻す:role: tool メッセージで tool_call_id と結果を返し、もう一度モデルを呼ぶ

tools の中身は次のような形です。

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "指定都市の現在の天気を取得する",
    "parameters": {
      "type": "object",
      "properties": {
        "city": { "type": "string", "description": "都市名" }
      },
      "required": ["city"]
    }
  }
}

tool_choice は呼び出し方の制御で、"auto" (モデル判断、既定)、"none" (使わせない)、"required" (必ず何か呼ばせる)、{"type": "function", "function": {"name": "X"}} (特定ツール指定) の 4 種類。ローカル側のランタイムでも auto と required は基本サポートされていますが、required は vLLM 0.8.3 以降など対応バージョンに注意します。

Tool Use 対応モデル:2026 年 6 月時点の推奨ライン

ツール呼び出しは「対応モデルで、対応 chat template を使う」ことが必須です。古いモデルや chat template だと tools パラメータを渡しても普通の文章生成になります。2026 年 6 月時点で安定して動く代表モデルを並べます。

モデル	サイズ	Tool Use 対応	強み
OpenAI gpt-oss	20B / 120B	公式対応・chat template 同梱	MXFP4 ネイティブ、Apache 2.0、reasoning が o3-mini / o4-mini クラス
Qwen 3	8B / 14B / 32B / 72B	公式対応 (Hermes 形式)	バランス型、Qwen-Agent との組み合わせで安定
Llama 4 (Scout / Maverick)	17B(A) / 109B(A) MoE	公式対応	Llama 3.1 系の Tool Use を継承、llama.cpp の chat template 対応
Hermes 3	3B / 8B / 70B	Tool Use 特化ファインチューン	小型でも比較的安定
Mistral / Mixtral	7B / 8x7B / 8x22B	公式 chat template	フランス系、ヨーロッパで採用例多い
DeepSeek-V3 / V3.2	671B(A 37B) MoE	対応	コードエージェント向き

実用上の選び方は 「サイズで決める」 のが分かりやすいです。

• 3〜4B クラス:Tool Use は動くが、複雑な JSON Schema で parse 失敗しやすい。簡単な 1 引数 1 ツールまで
• 7〜8B クラス:Hermes 3 8B / Qwen 3 8B など。日常的なツール呼び出しは安定
• 14B 以上:Qwen 3 14B / gpt-oss-20B など。複数ツールの並列呼び出し、ネストした JSON Schema も実用域
• 70B〜120B クラス:gpt-oss-120B / Llama 4 / DeepSeek-V3。本格的なエージェント実装の本命

モデル選び全般は「ローカルLLMモデル選び完全ガイド 2026年版」、gpt-oss を Tool Use 対応で動かす具体ハードは「OpenAI gpt-oss 120B / 20B ローカル実行完全ガイド」が詳しいです。

ランタイム別の実装:Ollama / vLLM / llama.cpp / LM Studio

ツール呼び出しを「どこで動かすか」で構成が変わります。それぞれ最短手順を整理します。

Ollama:最短ルート

Ollama は /api/chat と /v1/chat/completions (OpenAI 互換) のどちらでも tools をそのまま渡せます。chat template はモデルカードに同梱されたものが自動適用されるので、ユーザー側で --jinja のような追加フラグは不要です。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama",  # ダミーで何でも良い
)

resp = client.chat.completions.create(
    model="qwen3:14b",
    messages=[{"role": "user", "content": "東京の天気は?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "指定都市の現在の天気を取得",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        },
    }],
)
print(resp.choices[0].message.tool_calls)

サポートモデルは Llama 3.1+ / Qwen 2.5+ / Mistral Nemo 系から徐々に拡大し、2026 年は gpt-oss / Qwen 3 / Llama 4 がいずれも ollama pull 一発で動きます。Python SDK 側 (ollama-python 0.4 以降) では「関数オブジェクトそのものを渡せば docstring から JSON Schema を生成する」便利機能もあります。

vLLM:本番性能と並列呼び出し

vLLM は GPU を本気で回すための推論サーバで、Tool Use を有効化するには 2 つのフラグが必要です。

vllm serve Qwen/Qwen3-14B \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

--tool-call-parser はモデルごとに値を変えます。

モデル系統	tool-call-parser
Qwen 3 / Qwen 2.5 / Hermes 3	hermes
Llama 3.1 / Llama 3.3 / Llama 4	llama3_json
Mistral 系	mistral
InternLM 系	internlm

chat template も忘れがちな落とし穴で、Llama 3.1 系では --chat-template examples/tool_chat_template_llama3.1_json.jinja のように同梱テンプレを明示するケースがあります。vLLM 公式ドキュメントの「Tool Calling」ページに parser とテンプレの対応表があるので、新しいモデルを乗せるときはまずそこを確認します。

なお Qwen-Agent フレームワークを併用する場合は、Qwen-Agent 側でツール出力を parse するため --enable-auto-tool-choice と --tool-call-parser を 付けない ことが推奨される構成もあります。Qwen 3 系で「ツール呼び出しが二重に parse されて壊れる」場合は、まず Qwen-Agent との重複を疑います。

llama.cpp:CPU / Mac で動かす本命

llama.cpp 系の llama-server でも /v1/chat/completions 経由で tools パラメータが正式対応しています。決定的なポイントは --jinja フラグです。

llama-server \
  -m models/qwen3-14b-Q4_K_M.gguf \
  --jinja \
  --port 8080

--jinja を付けないと llama.cpp 内部の C++ chat template が動き、Tool Use 対応の Jinja テンプレートが無効化されます。--jinja を付けると llama.cpp の C++ 製 Jinja2 エンジンと PEG ベースの tool-call parser が走り、JSON ネイティブ形式 (Qwen 3 / Hermes) と Tag 形式 (<tool_code> / [TOOL_CALLS] 等) の両方を自動判別します。

モデルの GGUF に chat template が同梱されていない場合は --chat-template-file で公式 Jinja テンプレを上書きする必要があります。Llama 4 や gpt-oss は最新版でほぼ自動認識されますが、コミュニティ量子化版だと chat template が古いことがあるので、Tool Use が動かないときはまず元のモデルカードから Jinja を持ってきて差し替えます。

LM Studio:GUI 派の最短ルート

LM Studio は GUI でモデルをダウンロードし、OpenAI 互換 endpoint をデフォルトで起動するタイプ。chat template はモデル選択時に自動適用されるので、Ollama と同じ感覚で tools を渡せます。Mac 上で MLX / GGUF を切り替えながら試すユースケースだと最短です。

ランタイム選びの全体観は「ローカルLLM 推論ツール比較 2026年版」で扱っています。

Tool Use で詰まる典型パターン

実装で踏みやすい地雷を 4 つ。

1. tools を渡しても普通の文章で返ってくる

ほぼ 100% chat template が古い・Tool Use 非対応 が原因です。llama.cpp 系では --jinja 漏れ、GGUF 配布元の chat template が古い、というケースが多いです。ollama show <model> --modelfile や llama-server --verbose で template を確認します。

2. 3B / 7B クラスで JSON parsing が失敗する

小型モデルは Tool Use 自体は出せても、引数 JSON の生成が崩れることがあります (引用符の閉じ忘れ、余分なテキスト混入)。

• ネスト深さは 2-3 段まで
• required フィールドを最小化する
• ツール数は 1 回の呼び出しで 5 個程度まで
• 安定性が必要なら Hermes 3 8B / Qwen 3 14B 以上に上げる

3. 並列ツール呼び出し (Parallel Tool Calls) が動かない

「1 回のターンで複数ツールを呼ぶ」は対応モデル限定です。gpt-oss / Qwen 3 / Llama 4 は対応、古い Llama 3.0 などは 1 ターン 1 ツール。llama.cpp 側でも parallel_tool_calls フラグの動作は Jinja テンプレ依存で、未対応モデルだとフラグを付けても 1 つしか返ってきません。エージェント実装で複数 API を一気に叩きたい場合は、最初から並列対応モデルを選びます。

4. Reasoning モデル + ReAct 風プロンプトで stopwords 衝突

Qwen 3 などの reasoning モデルでは、thinking セクションに stopword (Action: 等) を出力してしまい、ReAct 系のテンプレートが壊れる事例があります。Qwen 公式も「reasoning モデルでは stopword 依存の ReAct ベース tool template は非推奨」としていて、Hermes 形式や Qwen-Agent の native parser に寄せるのが安全です。

どのランタイムで何を動かすか:用途別チート

迷ったときの第一選択を表に。

目的	おすすめランタイム	代表モデル	備考
とにかく最短で動かす	Ollama	qwen3:14b / gpt-oss:20b	フラグ不要、SDK が一番揃う
本番 API として並列性能を稼ぐ	vLLM	Qwen3-14B / Llama 4 / gpt-oss-120B	parser 設定必須、要 GPU
Mac / CPU 主体	llama.cpp + --jinja	Qwen 3 GGUF / Hermes 3	chat template 確認必須
GUI で試す・切り替える	LM Studio	gpt-oss-20B / Qwen 3	MLX 切替が楽
Cline / Aider 等のコーディングエージェント	Ollama or vLLM	gpt-oss-20B / Qwen 3 Coder	コンテキスト 32K+ 推奨

ローカルエージェント実装の PC 構成は「ローカルコーディングエージェント向け PC ビルドガイド 2026年版」、UI から Tool Use を叩きたい人は「Open WebUI / LibreChat でローカルLLM チャット UI を立てるガイド」が続きです。

まとめ:Tool Use は「対応モデル × 対応 chat template」が 9 割

• API は OpenAI 互換 tools パラメータの 1 種類だけ覚えれば十分
• モデルは 7-8B 以上 (gpt-oss-20B / Qwen 3 14B / Hermes 3 8B) を選ぶと安定
• ランタイムは Ollama (最短) / vLLM (本番性能) / llama.cpp --jinja (Mac・CPU) の使い分け
• 詰まったら chat template と parser の対応をまず疑う
• 並列呼び出しと reasoning モデル ReAct 衝突は対応モデルとテンプレで回避

「ローカルでもエージェントが動く」は 2025〜2026 年で完全に現実になりましたが、安定して動かすには「対応モデル × 対応 chat template × 対応 parser」の 3 点を揃えるのが必須です。本記事の組み合わせから 1 つ選んで、最小の get_weather 例で 1 往復通せれば、あとは tools 配列を増やしていくだけでローカル MCP / Cline / Aider 風のエージェントは構築できます。

---

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート

関連記事

• OpenAI gpt-oss 120B / 20B ローカル実行完全ガイド 2026年版
• ローカルLLMモデル選び完全ガイド 2026年版
• ローカルLLM 推論ツール比較 2026年版
• ローカルコーディングエージェント向け PC ビルドガイド 2026年版
• Open WebUI / LibreChat でローカルLLM チャット UI を立てるガイド 2026年版