2026.08.26 2026.08.26

ローカルLLMのツール呼び出しを実務に繋ぐ — OpenAI互換APIとMCPの使いどころ

ゲンキ

手元でモデルが動いた。チャット画面で質問すると、それらしい答えが返ってくる。ここで満足して終わる人が多い。しかし本当の価値は、その先で発生する。ファイルを読ませる、計算させる、社内の資料を検索させる。モデルが外の世界に手を伸ばせるようになって初めて、道具になる。

その橋渡しをするのがツール呼び出しであり、道具側を標準化するのが MCP だ。本記事では、手元のモデルを実際の作業に接続するまでの構造を扱う。公式ドキュメントに記載のある事実だけを使い、確認できなかったことは確認できなかったと書く。

チャット画面で動いた、その次で止まる
OpenAI互換という共通言語を使う
ツール呼び出しは何をしているのか
3つの呼び出しパターン
手元のモデルでどこまで通るか
MCP — 道具側を標準化する
MCPの3つのプリミティブ
版が変わって非推奨になったもの
得意な仕事と、苦しい仕事
併用する前提で組む
3Dプリントの設計作業に繋ぐ
まとめ — 2本の通り道を通す
出典・参考

忍者AdMax

チャット画面で動いた、その次で止まる

止まる理由ははっきりしている。チャット画面は入口であって、作業の場ではないからだ。実務では、答えを出すために外部の情報が要る。今日の在庫数、この図面の寸法、先週の測定ログ。モデルはそれらを知らない。

解決策は2段階になる。まず、モデルを外部から呼べる形にすること。次に、モデルが外部を呼べる形にすること。前者が OpenAI互換API、後者がツール呼び出しである。方向が逆の2本の通り道を、それぞれ通しておく必要がある。

OpenAI互換という共通言語を使う

主要な実行環境は、いずれも OpenAI互換のエンドポイントを提供している。これが1本目の通り道になる。

llama.cpp の llama-server は「OpenAI API compatible chat completions, responses, and embeddings routes」を提供すると公式に記載され、/v1/models /v1/completions /v1/chat/completions /v1/embeddings /v1/responses が用意されている。LM Studio も同じ5つを提供し、既定ポートは1234、接続先は http://localhost:1234/v1 になる。公式ドキュメントは、既存の OpenAI クライアントの接続先設定を差し替えるだけで使えると明記している。vLLM は OpenAI互換に加えて Anthropic Messages API と gRPC にも対応する。

Ollama については、記述の仕方に注意したい。公式ドキュメントは「compatibility with parts of the OpenAI API」という限定付きの表現を使っている。そして未対応項目を明示している。

対象	未対応と明記されている項目
chat completions	logprobs、tool choice、logit bias、`user`、`n`
embeddings	トークン配列・トークン配列の配列の入力形式、`user`
responses	`previous_response_id`、`conversation`
画像入力	Image URL 指定（base64 は対応）

この一覧を欠点と読むのは早計だろう。境界を公表しているという事実そのものが実務では有益だからだ。他の環境が同じ範囲をすべて満たしているかは、公式記述からは確認できない。分かっているのは、Ollama がどこまでかを公表しているという点である。

なお /v1/responses は v0.13.3 で追加されている。古い記事を参照するときは、この種の追加時期に注意が要る。

ツール呼び出しは何をしているのか

2本目の通り道がツール呼び出しだ。Ollama の公式ドキュメントは、これを「モデルがツールを呼び出し、その結果を返答に取り込めるようにする機能」と定義している。

動きを分解するとこうなる。

こちらが、使える道具の一覧を仕様つきで渡す
モデルが「この道具をこの引数で呼びたい」と返す
実際に呼ぶのはこちら側のプログラムである
結果をモデルに戻す
モデルがそれを踏まえて答える

3番目が重要で、モデル自身が外部を実行するわけではない。モデルは呼び出しの意図を構造化して出力するだけだ。実行の責任はこちら側に残る。この設計を理解していないと、権限管理の設計を誤る。

具体的に何を誤るかを書いておく。モデルが「このファイルを削除したい」と出力したとき、それをそのまま実行する実装にしてしまうと、モデルの判断がそのまま破壊的操作になる。モデルの出力は要求であって命令ではない。実行する前に、こちら側で検証する層を必ず挟む。

検証の観点は3つある。第一に、引数が想定の範囲に収まっているか。ファイルパスなら許可したディレクトリの外を指していないか。第二に、その操作が取り返しのつくものか。読み取りと書き込みでは、通すべき基準が違う。第三に、呼び出し回数に上限があるか。多ターンのループでは、同じ道具を延々と呼び続ける状態に陥ることがある。

手元で動かしている場合、この層を省略したくなる誘惑が強い。自分のマシンだから、という理由だ。しかし実行の責任が自分側にあるという構造は、クラウドでも手元でも変わらない。むしろ手元のほうが、ファイルシステムへの距離が近いぶん影響が大きい。

3つの呼び出しパターン

公式ドキュメントは3つの使い方を示している。

単発は、道具を1つ呼び、その結果を次のリクエストに含めて答えを得る形。最も単純で、多くの実務はこれで足りる。

並列は、複数の道具の呼び出しをまとめて要求し、結果をまとめて返す形。独立した情報を同時に取りに行くときに効く。

多ターンは、モデルが会話をまたいで必要なときに道具を呼ぶ形。いわゆるエージェントループにあたる。自由度が高い反面、止め時の設計が要る。

使い分けの目安を書いておく。取りに行く情報が事前に分かっているなら単発か並列で足りる。「この部品の在庫を見て、足りなければ発注履歴を確認する」のように次の行動が前の結果に依存するなら多ターンになる。逆に言えば、依存がないのに多ターンで組むと、モデルに余計な判断をさせることになって不安定になる。

手元のモデルで始めるなら、単発から入るのが堅実だ。単発が安定して通るようになってから並列に広げ、それでも足りない場面だけ多ターンにする。最初から多ターンで組むと、失敗したときにどの段階が原因か分からなくなる。

ストリーミングと併用するときには注意が要る。公式ドキュメントは、thinking、content、tool_calls のすべてのチャンクを集め、それらをツールの実行結果と一緒に次のリクエストへ返すよう指示している。部分的に受け取って部分的に返すと、状態が壊れる。

手元のモデルでどこまで通るか

ここが読者の一番知りたいところだと思うが、正直に書く。公式ドキュメントには、ツール呼び出しに対応するモデルの一覧が示されていない。Ollama の現行ドキュメントは、すべてのコード例で qwen3 を使っている。それ以外のモデル名は明示されていない。

ネット上には「このモデルとこのモデルが対応」という一覧が流通しているが、現行の公式ドキュメントで裏を取れなかったため、本記事では引き写さない。代わりに手順を書く。モデルカードとタグの表記で、ツール呼び出しの対応を自分で確認する。これが確実な方法だ。

小型モデル固有の制限についても、公式ドキュメントには記載がない。記載がないことは「制限がない」ことを意味しないので、自分の仕事で試すしかない。

失敗するとしたら、種類は2つに分かれる。ひとつは引数の型が崩れること。数値のはずが文字列で返る、必須項目が欠ける。もうひとつは呼ぶべき場面で呼ばないこと。道具を渡しているのに、記憶だけで答えようとする。前者は入力スキーマを厳しくすることで減らせるが、後者は指示の書き方に依存する。頻度については測定していないので書かない。

MCP — 道具側を標準化する

ツール呼び出しには構造的な弱点がある。道具の実装が、アプリケーションごとに閉じてしまうことだ。同じ「社内文書を検索する」道具を、使うアプリの数だけ書き直すことになる。

この重複を解消するのが MCP、Model Context Protocol である。公式は「AIアプリケーションを外部システムに接続するためのオープンソースの標準」と定義し、「AIアプリケーションにとっての USB-C ポートのようなもの」と説明している。道具の側を1回作れば、対応するどのアプリからも使える。

構造は3者からなる。Host が AI アプリケーション本体で、接続するサーバーの数だけ Client を作る。Server が道具や資料を提供するプログラムだ。サーバーは同じマシン上でも遠隔でも動く。

通信は2層に分かれる。データ層は JSON-RPC 2.0 を土台にしており、トランスポート層は2種類ある。Stdio は同一マシン上のプロセス間通信で、ネットワークのオーバーヘッドがない。Streamable HTTP は HTTP POST に任意の Server-Sent Events を組み合わせる形で、遠隔サーバー向けだ。手元で完結させたいなら Stdio を選ぶことになる。

この2層構造には実務上の意味がある。同じ JSON-RPC 2.0 のメッセージ形式が、どちらのトランスポートでも使われるため、道具の実装を書き換えずに配置を変えられる。最初は手元の Stdio で作り、後で遠隔に出す。あるいはその逆。移動のコストが低いということだ。

セキュリティの扱いもトランスポートによって変わる。Streamable HTTP は Bearer トークンや API キーといった標準的な HTTP 認証に対応し、公式は認証トークンの取得に OAuth を使うことを推奨している。一方 Stdio は同一マシン上のプロセス間なので、ネットワーク越しの認証という問題自体が発生しない。手元で完結させる構成が単純になるのは、この点でも同じである。

MCPの3つのプリミティブ

サーバーが提供できるものは3種類と定義されている。

種類	公式の定義	具体例
Tools	AIアプリが実行を呼び出せる関数	ファイル操作、API呼び出し、データストアへの照会
Resources	コンテキスト情報を提供するデータ源	ファイルの内容、DBレコード、APIレスポンス
Prompts	対話を構造化する再利用可能なテンプレート	システムプロンプト、少数例

それぞれ */list で列挙し、tools/call で実行する。この設計により、道具の一覧が動的に変わりうることが前提になっている。

3種類に分かれていることには理由がある。Tools は副作用を伴う実行、Resources は読み取りに限った情報、Prompts は対話の型。性質の違うものを同じ枠で扱わないという設計判断だ。前節で述べた検証層を設計するとき、この区別がそのまま効いてくる。読み取りだけの Resources と、破壊的操作を含みうる Tools では、通すべき基準が違って当然だからである。

もうひとつ、Prompts が独立した種類として立っている点も見逃せない。対話のテンプレートをサーバー側に置けるということは、道具の使い方の知識を、道具と一緒に配れるということだ。ある道具をどういう手順で呼ぶのが正しいかは、その道具を作った側が一番よく知っている。それをアプリケーション側に書かせず、サーバー側から供給する。手元の小さいモデルを使うときほど、この供給が効く。指示が具体的なほど、モデルに求める判断が減るからだ。

MCP はステートレスなプロトコルとして設計されており、各リクエストの _meta フィールドにプロトコル版と capabilities を載せる。サーバーは必須実装の server/discover で自身の対応版と機能を通知する。変更通知はオプトインで、クライアントが subscriptions/listen で受け取りたい種類を指定する形になっている。

版が変わって非推奨になったもの

ここは古い記事を読むときに効く話だ。プロトコル版 2026-07-28 で、クライアント側のプリミティブに変更が入っている。

現行で有効なのは Elicitation で、サーバーがユーザーに追加入力を求める仕組みだ。確認を取りたい操作の前に使える。

一方、Sampling は非推奨になった。サーバーがクライアント側の言語モデルに補完を要求する仕組みだったが、公式は新規実装では LLM プロバイダの API に直接統合するよう案内している。Logging も同じ版で非推奨となり、新規実装は stderr か OpenTelemetry を使うことになっている。

MCP を解説した記事の多くは、これらを現行機能として説明している。版を確認せずに設計を始めると、非推奨の仕組みの上に組んでしまう。仕様の版番号を見る習慣は、この領域では必須だ。

Sampling の非推奨は、設計思想の変化としても読める。サーバーがクライアント側のモデルを借りる仕組みは、サーバーをモデル非依存に保つための工夫だった。それを取り下げて直接統合を勧めるということは、プロトコルの役割をコンテキストの受け渡しに絞り込む方向に寄せたということになる。公式ドキュメント自身、MCP はプロトコルにのみ焦点を当てており、AIアプリがモデルをどう使うかには踏み込まないと明記している。役割分担がはっきりしているぶん、こちら側で組む部分も見通しやすい。

得意な仕事と、苦しい仕事

手元のモデルを道具として使うとき、向き不向きははっきり分かれる。

通りやすいのは、入力と出力の形が決まっている仕事だ。分類、書式変換、要約、抽出、コードの補完。道具の呼び出しも、引数が少なく型が単純なものほど安定する。

苦しいのは、長い多段の推論と、厳密な構造化出力を連発する仕事である。何段も条件を辿った末に結論を出す処理は、途中で筋を見失いやすい。また、複雑なスキーマに正確に合わせた出力を何十回も続けると、どこかで崩れる。

判断の目安はこうだ。その仕事は、失敗しても安く済むか。安く済むなら手元向き、1回で決めたいならクラウド向きになる。この線引きはクラウドAIの請求書を見てローカルAIを考え直す（2026-08-24 公開）で扱ったコストの判断とも重なる。

苦しい側を手元でどうにかしたい場合、打つ手はある。多段の推論を、こちら側のプログラムで分割するという方法だ。1回のやり取りで3段の判断をさせるのではなく、3回に分けてそれぞれ1段だけ判断させる。各段の入出力が単純になるので、通る確率が上がる。

構造化出力についても同じ考え方が使える。複雑なスキーマを一度に埋めさせるより、項目を分けて順に埋めるほうが安定する。モデルの能力で押し切るのではなく、こちら側の設計で難易度を下げる。これは手元のモデルを使うときの基本姿勢になる。

併用する前提で組む

以上を踏まえると、現実的な形は併用になる。組み方の指針を挙げる。

まず、接続先を差し替えられる形で書く。OpenAI互換なので、クライアント側の設定1つでローカルとクラウドを切り替えられる。この切り替え点を最初から用意しておけば、後から配分を変えるのが安くなる。

次に、道具は MCP サーバーとして切り出す。ツール呼び出しをアプリケーションに直書きすると、モデルを替えるたびに書き直しになる。プロトコルの側に寄せておけば、モデルの選択と道具の実装が独立する。

そして、同じ仕事を両方で走らせて比べる期間を作る。汎用のベンチマークではなく、自分の仕事での成否を見る。この比較ができる構成にしておくことが、移設の判断材料になる。

なお、モデルの選定とメモリの見積もりについては手元のVRAMで動くモデルを見積もる（2026-08-25 公開）で扱っている。道具に繋ぐ前段として、そちらが先になる。

3Dプリントの設計作業に繋ぐ

この構造がモノづくりにどう効くかを、最後に書いておく。

興味深いことに、MCP の公式ドキュメントは用例のひとつとして「AIモデルが Blender で3Dデザインを作り、3Dプリンターで出力する」ことを挙げている。プロトコルの提唱側が、3D制作を想定した用例に置いているわけだ。

実際の効き方はこうなる。寸法や公差を含む図面情報を扱うとき、外部に送信しない構成が要件になることがある。取引先から預かった図面なら、なおさらだ。手元のモデルに道具を持たせれば、設計データを外に出さずに設計支援を回せる。

コードで形状を記述する方式との相性も良い。パラメータを変えて何度も試す作業は、まさに「失敗しても安い」仕事にあたる。この方式の実際についてはOpenSCAD × LLM 実践 2026（2026-07-18 公開）で扱った通りで、手元で回すなら試行回数を気にしなくてよいという利点がそのまま乗る。