LM StudioのTool UseをWindowsで使う方法｜/v1/chat/completions・function calling

先に結論：custom toolsとnative /api/v1/chatを選び分ける

LM Studio公式のREST API比較では、nativeのPOST /api/v1/chatはstateful chat、LM StudioのMCP、モデル操作、context length指定などが強みです。一方、custom toolsはOpenAI互換のPOST /v1/chat/completions、POST /v1/responses、またはAnthropic互換endpointの機能として整理されています。

Tool Useはモデルが直接コードを実行する機能ではありません。モデルの要求、アプリ側のdispatch、実行結果、最終回答を別の段階として設計し、未知の関数や危険な引数をそのまま実行しないことが重要です。

• ローカルAI API入門 - localhost、API server、providerの全体像を確認する
• LM Studioのlms CLI - server start、status、model IDを端末から確認する
• LM Studio公式REST API - nativeと互換endpointの機能比較を読む

Windowsでlocal serverとモデルを先に確認する

Tool Useのコードを書く前に、LM StudioのDeveloper tabでlocal serverが起動しているか、利用モデルがロードされているか、接続portと認証設定が何かを確認します。公式例ではlocalhost:1234が使われますが、実際のportはLM Studioの画面やlms server statusを基準にします。

1. LM StudioをWindowsで起動し、Developer tabでlocal serverの状態とportを確認する。
2. モデルをChatまたはDeveloper tabからロードし、短い通常chatでモデル単体が応答するか確認する。
3. 既存の端末運用ならlms ls、lms ps、lms server statusで保存済み・ロード中・serverを別々に見る。
4. GET http://localhost:1234/v1/modelsで、OpenAI互換clientへ渡すmodel identifierを確認する。portは実際の表示に合わせる。
5. まずtool 1個、短い質問、localhost、非機密データ、stream=falseでtool_callsを確認する。

lms server start
lms server status
lms ls
lms ps
curl.exe http://localhost:1234/v1/models

LM Studioの画面でchatできることは、OpenAI互換API、Tool Use、MCP、Responsesが同じ条件で動くことを意味しません。server、model identifier、endpoint、認証、tool対応を別々に記録します。

• LM Studioの基本情報 - Windowsアプリ、モデル、serverの入口を見る
• LM Studioで最初のモデル - モデル選びと単体chatを先に確認する
• LM Studioが起動しないとき - アプリ、runtime、Windows側の切り分けへ進む

Chat Completionsへtoolsを渡す

LM Studio公式Tool Use docsでは、/v1/chat/completionsへOpenAI形式のtools配列を渡す例が案内されています。function名、description、引数のJSON Schemaをモデルへ提示し、tool callが返った場合だけアプリ側で関数を処理します。

curl.exe http://localhost:1234/v1/chat/completions -H "Content-Type: application/json" -d "{"model":"MODEL_IDENTIFIER","messages":[{"role":"user","content":"注文123の配送日を確認して"}],"tools":[{"type":"function","function":{"name":"get_delivery_date","description":"注文番号のテスト用配送日を返す","parameters":{"type":"object","required":["order_id"],"properties":{"order_id":{"type":"string"}}}}}],"stream":false}"

LM Studioはモデルの出力を解析して、正しい形式のtool callをchat.completionのmessage.tool_callsへ入れようとします。モデルが未対応、chat templateが合わない、形式が崩れる場合は、普通のcontentとして返る場合があります。

• LM Studio Tool Use公式docs - tools schemaとsingle turnの公式例を見る
• LM Studio OpenAI互換API - base URL、endpoint、model IDの全体像へ戻る
• LM Studio公式OpenAI Compatibility - 互換endpointの前提を確認する

Python・JavaScriptではtool_callsを検証してdispatchする

OpenAI clientなどの互換SDKを使う場合も、LM Studioが返したtool_callsをそのまま実行せず、許可した関数だけへdispatchします。SDKを追加するかどうかは読者のアプリ側の選択であり、このサイトの依存関係は変更していません。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:1234/v1", api_key="lm-studio")
functions = {"get_delivery_date": get_delivery_date}
messages = [{"role": "user", "content": "注文123の配送日を確認して"}]

response = client.chat.completions.create(
    model="MODEL_IDENTIFIER",
    messages=messages,
    tools=[{
        "type": "function",
        "function": {
            "name": "get_delivery_date",
            "description": "注文番号のテスト用配送日を返す",
            "parameters": {
                "type": "object",
                "required": ["order_id"],
                "properties": {"order_id": {"type": "string"}},
            },
        },
    }],
)
message = response.choices[0].message
messages.append(message)
for call in message.tool_calls or []:
    fn = functions.get(call.function.name)
    order_id = call.function.arguments.get("order_id")
    if fn is None or not isinstance(order_id, str) or not order_id.isdecimal():
        continue
    messages.append({"role": "tool", "tool_call_id": call.id, "content": fn(order_id)})
if message.tool_calls:
    final = client.chat.completions.create(model="MODEL_IDENTIFIER", messages=messages)
    print(final.choices[0].message.content)

tool_call_idや引数の扱いは使うSDKとendpointの仕様に合わせます。Python、JavaScript、curlの表記を混ぜず、まず公式Tool Useの例と手元のレスポンスを確認してから型を固定してください。

• LM Studio Tool UseのPython例 - single turn・multi-turn・agent例を見る
• VS CodeでLM Studioを使う - provider、Chat、agent、APIを分けて確認する
• WindowsローカルAIコーディング - ファイル作業のcheckpointと権限を確認する

Responsesとnative /api/v1/chatの違いを確認する

LM Studioのnative REST APIは、入力と応答を保持するstateful chat、MCP integrations、モデルloadやprompt processingのイベント、context length指定に向いています。custom toolを自分のfunctionとして渡す目的なら、公式比較表にあるOpenAI互換のChat CompletionsまたはResponsesを検討します。

native /api/v1/chatへOpenAIのmessagesやtool_callsをそのまま送る、またはOpenAI互換のresponseをnative outputと同じparserで読む、といった混在は避けます。MCPを使う場合はnative chatのintegrations、custom functionを使う場合は互換endpointというように、目的からpathを決めます。

• LM Studio REST APIの比較表 - stateful、MCP、custom tools、streamの対応を確認する
• LM Studio native chat API - input、integrations、response output、statefulを確認する
• MCPとは - MCP、tool calling、権限の役割を分ける

tool_callsが出ない・streamが崩れるときの切り分け

LM Studio公式Tool Use docsは、tool use用に学習されていないモデルや小さいモデルでは、tool callの形式を正しく出せず、tool_callsへ解析されずcontentとして返る可能性を説明しています。最初からモデルだけを疑わず、server、model identifier、endpoint、tools schema、chat template、streamを順に分けます。

1. 通常の短文chatを確認する。
2. Chat Completionsのstream=falseでtool 1個を確認する。
3. tool_callsが返ったresponseと、戻すtool resultの形を保存する。
4. multi-turn、Responses、stream、MCPの順に1つずつ追加する。
5. 一度にモデル、port、API path、tools schema、parserを全部変えない。

• LM Studioのトラブルハブ - 起動、Prompt Processing、native API、streamの共通診断へ進む
• LM Studio Prompt Processing - tool定義やMCPで入力が重くなる条件を確認する
• LM Studio GPU offload - モデルとPC負荷をTool Useの成否と分ける

最初は読み取り用toolだけにし、外部作用を人間の確認へ残す

Tool Useを動かすことと、安全に自動化することは別です。LM Studioがlocal serverで動いていても、toolがfilesystem、network、メール、データベース、ブラウザ、認証情報へ到達するなら、実行範囲と送信先は別途確認が必要です。

• toolsは必要な関数だけをallowlistにし、ホームディレクトリ全体や任意コマンドを渡さない。
• argumentsを型、値、対象ID、ファイル範囲、URL、送信先、認証情報の有無で検証する。
• 最初は公開データの読み取り、テスト用注文番号、限定フォルダ、localhostに絞る。
• 削除、上書き、コード実行、外部送信、購入、メール送信は自動loopにせず、人間の確認を必須にする。
• local model、LM Studio server、MCP、tool関数、ログ、cloud providerを別々の通信・保存経路として記録する。

Structured OutputはJSONの形を検証しやすくする仕組みで、Tool Useは関数呼び出しの要求と実行結果を往復する仕組みです。診断結果のJSON化と、実際のファイル操作やAPI送信を同じ許可として扱いません。

• LM Studio Structured Output公式docs - JSON Schemaと出力検証の役割を見る
• ローカルLLMの安全性 - 外部送信、履歴、provider、権限を確認する
• LM StudioやOllamaのログ - server、履歴、ログ、model fileの保存範囲を分ける