TodoONada株式会社
AI・ローカルLLM

ローカルLLMのtool calling。エージェント実用の鍵はモデル選び

ローカルLLMのtool calling。エージェント実用の鍵はモデル選び

ローカルLLMに関数を呼ばせる「tool calling」は、エージェント・MCP・業務自動化のすべてを支える土台の能力です。この精度が出るかどうかで、ローカルLLMが「賢いチャット」で終わるか「業務システムの一部」になるかが分かれます。本記事では、何が実用の分水嶺なのかを、確かめられた範囲の事実に絞って整理します。

この記事の要点

  • tool calling（function calling）は、モデルが「この関数をこの引数で呼べ」という構造化された指示を出せる能力で、エージェント・MCP・業務自動化のすべてがこの精度の上に載ります
  • 評価の標準ベンチマークはBerkeley Function Calling Leaderboard（BFCL）です。現行のV4（2025年リリース）は、複数ステップの自律的なエージェントタスクを重視した評価になっています
  • モデル選定はパラメータ数より「tool呼び出しを学習しているか」が効きます。2026年時点ではQwen3系・gpt-oss系が実用の候補です
  • 「量子化してもtool callingの精度は落ちない」と断言できる一次検証データは不十分です。本番採用前に、実際に使う量子化ファイルで実測するのが安全です
  • 実用の範囲は単発のtool呼び出し・MCP接続・1〜2ステップの連携までです。5ステップを超える自律ループはまだクラウド優位で、ローカルは32B級が実用の入口という感触です

tool calling（function calling）とは。ローカルLLM活用の分水嶺

ローカルLLMの用途は、大きく2つに分かれます。

用途の型例tool callingの要否
チャットで完結する用途質問応答・要約・翻訳不要（モデル単体で完結します）
システムと連携する用途社内検索・DB照会・社内API呼び出し必須（外部のツールを呼ぶ必要があります）

後者を可能にするのがtool calling（function calling）です。モデルが「この関数をこの引数で呼べ」という構造化された指示を出せる能力で、エージェント・MCP・業務自動化のすべてがこの精度の上に載ります。ローカルLLMを「賢いチャット」から「業務システムの一部」に引き上げる分水嶺が、ここにあります。

なお、システム連携の代表例である社内文書検索（RAG）の構築そのものは『社内文書RAGの作り方2026。パース・埋め込み・リランクの最新構成』で扱っています。

tool callingの評価指標はBFCL（Berkeley Function Calling Leaderboard）

tool callingの標準ベンチマークが、Berkeley Function Calling Leaderboard（BFCL）です。現行はV4（2025年リリース）で、単発の関数呼び出しだけでなく、複数ステップの自律的なエージェントタスクを重視した評価になっています。

Qwen3系、Llama 3.x系、GPT系、Gemini系、DeepSeek系などが評価対象です。傾向として、tool calling向けに学習されたモデルが上位に来ます。ただし具体的なスコア・順位は流動的なので、モデル選定時はBFCLの最新版を直接確認してください。

ローカルLLMのモデル選び。サイズより「tool学習の有無」が効く

tool callingで押さえるべき第一の原則は、モデルの大きさより「tool呼び出しを学習しているか」が効くことです。

Qwen3系は、公式モデルカードのベンダー記載で「tool calling能力に優れ、複雑なエージェントタスクでオープンソース中トップクラス」と位置づけられています。一方、大きいだけでtool学習が弱いモデルは、パラメータ数ほどの性能が出ないことがあります。

ただし「中型のQwenが大型のLlamaを常に上回る」といった具体的な優劣は、公開ベンチマークの一次データで断定できる範囲が限られます。方向性として「tool学習の有無が効く」ことは言えますが、個別モデルの優劣は自分のユースケースで測るのが確実です。2026年時点では、tool callingに強いローカルモデルとしてQwen3系・gpt-oss系が実用の候補になります。

量子化はtool callingの精度に影響するか。「無害」と断言はできない

「量子化してもtool callingの精度は落ちない」という説明を見かけますが、これは一次的な検証データが十分ではありません。むしろ、量子化方式によっては性能が落ちる例（あるモデルがGPTQ版を品質劣化のため非推奨にした等）もあります。

実務的な結論は次の通りです。

  • 量子化の影響は、タスクよりも方式・モデル依存が大きいのが実情です
  • 本番採用前に、自分のtool呼び出しで量子化版と非量子化版を比較します
  • 「Q4なら安全」と決め打ちせず、実際に使う量子化ファイルで実測するのが安全側です

量子化そのものの基礎は、別記事『量子化とは何か』で扱っています。

日本語ファインチューニング版の落とし穴。tool callingは保証対象外のことがある

日本語に強くしたファインチューニング版（例: Qwen3 Swallow系）を使うときの注意です。これらのモデルは日本語能力を高める一方で、tool calling能力については明示的に学習・検証されていないケースがあります。Swallowのモデルカードも、tool useを「未検証のユースケース」と位置づけています。

つまり「日本語が自然になった代わりにtoolが崩れた」のではなく、そもそもtool呼び出しは保証対象外、という理解が正確です。対策は構成の分離です。

役割使うモデル理由
対話・日本語生成日本語ファインチューニング版日本語の自然さを優先できます
tool呼び出し・エージェント実行tool callingを学習した素のモデル（Qwen3系等）tool能力が学習されたモデルに任せられます

このように用途でモデルを使い分けるのが、実務的な回避策になります。日本語モデルの候補整理は『日本語で使えるローカルLLMおすすめ2026。VRAM別の現実解』を参照してください。

ローカルLLMエージェントの使いどころと限界

2026年時点の現在地を一枚にまとめます。

区分内容
実用の範囲単発のtool呼び出し、MCP接続、1〜2ステップの連携
まだクラウド優位5ステップを超える自律ループ（検索→判断→実行→検証→再試行）
構成上の落とし穴n8n/Difyなどのワークフローツール連携時、Ollamaのサブノードがtool callingに対応していない等の制約

ローカルでの自律エージェントは、32B級が実用の入口という感触です。32B級を動かすためのハードウェアの目安は『予算別ローカルLLM PC 2026。10万・30万・60万・100万円で何が動くか』で整理しています。

また、n8n/Difyなどのワークフローツールと連携する場合は、モデル自体にtool calling能力があっても、ツール側のノードが対応していないという構成上の制約でつまずくことがあります。試作から本番への推論基盤の乗り換えは『試作はOllama、本番はvLLM。乗り換えのタイミングと20倍の性能差』も参考にしてください。

Claude Codeのバックエンドをローカルモデルに向ける話は、『Claude Codeをローカルモデルで動かす。Anthropic互換APIの現在地と限界』で実際に接続して確かめています。

導入前チェックリスト

tool callingを前提にローカルLLMを選定する前に、次の項目を確認してください。

  • 用途が「チャットで完結」か「システム連携」かを切り分けた
  • 候補モデルがtool callingを学習しているかをモデルカードで確認した
  • BFCLの最新版で候補モデルの評価を直接確認した
  • 実際に使う量子化ファイルで、自分のtool呼び出しを実測比較した
  • 日本語ファインチューニング版を使う場合、tool実行を素のモデルに分離する構成を検討した
  • エージェントのステップ数を見積もった（5ステップ超はクラウドとの比較が必要です）
  • n8n/Difyなどワークフローツール側のtool calling対応状況を確認した

まとめ

  • tool callingはエージェント・MCP・自動化の土台です。ローカルLLMを業務システムに載せる分水嶺になります
  • 評価はBFCL V4が標準です。モデルの大きさより「tool学習の有無」が効き、2026年時点ではQwen3系・gpt-oss系が実用の候補です
  • 「量子化は無害」は一次検証が不十分です。実際に使う量子化版で、自分のtool呼び出しを実測するのが安全です
  • 日本語ファインチューニング版はtool callingが保証対象外のことがあります。対話は日本語FT・tool実行は素のモデル、と分離するのが実務的な回避策です
  • 実用の範囲は単発のtool呼び出し・MCP接続・1〜2ステップの連携までで、5ステップを超える自律ループはまだクラウド優位です

よくある質問

Q. tool calling（function calling）とは何ですか？

モデルが「この関数をこの引数で呼べ」という構造化された指示を出せる能力です。質問応答・要約・翻訳のようにチャットで完結する用途と違い、社内検索・DB照会・社内API呼び出しのようにシステムと連携する用途ではこの能力が必須になります。エージェント・MCP・業務自動化のすべてが、tool callingの精度の上に成り立ちます。

Q. tool callingに強いローカルLLMはどれですか？

2026年時点では、Qwen3系・gpt-oss系が実用の候補です。Qwen3系は公式モデルカードで「tool calling能力に優れ、複雑なエージェントタスクでオープンソース中トップクラス」と位置づけられています。ただし具体的なスコア・順位は流動的なため、選定時はBerkeley Function Calling Leaderboard（BFCL）の最新版を直接確認し、最終的には自分のユースケースで実測するのが確実です。

Q. 量子化するとtool callingの精度は落ちますか？

「落ちない」と断言できる一次検証データは不十分です。量子化方式によっては性能が落ちる例（GPTQ版を品質劣化のため非推奨にしたモデル等）もあり、影響はタスクよりも方式・モデル依存が大きいのが実情です。本番採用前に、実際に使う量子化ファイルと非量子化版で、自分のtool呼び出しを比較実測することをおすすめします。

Q. 日本語ファインチューニング版のモデルでtool callingは使えますか？

保証対象外のことがあります。例えばQwen3 Swallow系のモデルカードは、tool useを「未検証のユースケース」と位置づけています。日本語が自然になった代わりに壊れたのではなく、そもそも検証されていないという理解が正確です。対話・日本語生成は日本語ファインチューニング版、tool呼び出し・エージェント実行はtool callingを学習した素のモデル、と用途で分離するのが実務的な回避策です。

Q. ローカルLLMでAIエージェントは実用になりますか？

範囲を絞れば実用段階です。単発のtool呼び出し、MCP接続、1〜2ステップの連携はローカルで実用になります。一方、5ステップを超える自律ループ（検索→判断→実行→検証→再試行）はまだクラウド優位で、ローカルでは32B級が実用の入口という感触です。32B級を動かすハードウェアの目安は『予算別ローカルLLM PC 2026』を参照してください。

Q. n8nやDifyからローカルLLMのtool callingを使うときの注意点はありますか？

ワークフローツール側の対応状況の確認が必要です。モデル自体にtool calling能力があっても、Ollamaのサブノードがtool callingに対応していない等の構成上の制約で使えないケースがあります。連携を組む前に、使用するノード・コネクタがtool callingをサポートしているかを確認してください。

主な参考資料: Berkeley Function Calling Leaderboard、Qwen3-32B（Hugging Face）、Qwen3-Swallow（tokyotech-llm, Hugging Face）

TodoONadaでは、ローカルLLMと社内システムの連携（エージェント化）の検証・実装を支援しています。tool callingの精度は、最終的には自社のツール定義と業務データで測って初めて判断できます。どのモデル・どの構成なら自社のシステム連携が実用になるのか、検証段階からのご相談を歓迎します。詳しくはローカルLLM導入支援をご覧ください。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。

出典・参照

関連記事

Claude Codeをローカルモデルで動かす。Anthropic互換APIの現在地と限界 試作はOllama、本番はvLLM。乗り換えのタイミングと20倍の性能差 日本語で使えるローカルLLMおすすめ2026。VRAM別の現実解 社内文書RAGの作り方2026。パース・埋め込み・リランクの最新構成
技術ブログ一覧へ戻る