LM StudioのResponses APIをWindowsで使う方法｜/v1/responses・stateful・streaming

先に結論：Responses APIはstateful・streamingを含む互換入口

LM Studio公式のResponses docsでは、POST /v1/responsesへmodelとinputを送り、非ストリーム、previous_response_idによる継続、stream=trueのSSE、reasoning、オプションのRemote MCPが案内されています。まずstream=falseで最小の応答を確認し、必要な機能を1つずつ足す順番が切り分けやすいです。

Responses APIは、モデルが自分でWindowsのコードを実行する仕組みではありません。Remote MCPやcustom toolsを有効にする場合も、外部送信先、許可する操作、実行結果の扱いをアプリ側で確認します。

• ローカルAI API入門 - localhost、API server、providerの全体像を見る
• LM Studio Tool Use - custom toolsのschema・dispatch・権限を分けて確認する
• LM Studio公式Responses - 現行のrequest例とSSEイベントを見る

Windowsでlocal serverとmodel identifierを先に確認する

Responses APIのコードを書く前に、LM StudioのDeveloper tabでlocal serverの状態、port、認証、ロード済みmodelを確認します。公式例ではlocalhost:1234が使われますが、手元のDeveloper表示とlms server statusを基準にします。

1. LM StudioをWindowsで起動し、Developer tabでlocal serverを開始する。
2. モデルをロードし、画面上の通常chatで短い質問へ返答できることを確認する。
3. 端末運用ならlms server startとlms server statusでserver状態を確認する。
4. GET http://localhost:1234/v1/modelsで、Responses APIへ渡すmodel identifierを確認する。portは実際の表示に合わせる。
5. 最初は短いinput、stream=false、外部送信なしで基準を作る。

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

LM Studioの画面でchatできることと、互換APIのResponsesが同じ条件で動くことは同義ではありません。server、model identifier、endpoint、認証、モデルのreasoning対応を別々に記録します。

• LM Studioのlms CLI - server start、status、model IDの確認を先に読む
• LM Studioで最初のモデル - モデル単体の動作確認から始める
• LM Studioが起動しないとき - アプリ・runtime・serverの切り分けへ進む

PowerShellから非ストリームのResponsesを送る

WindowsではPowerShellのInvoke-RestMethodでJSONを送れます。最初はResponses docsの最小形に寄せ、model、input、streamを必要最小限にします。reasoningを追加する場合は、利用モデルがその設定に対応するかを先に確認します。

$body = @{
  model = "MODEL_IDENTIFIER"
  input = "WindowsのローカルAIでResponses APIを試す"
  stream = $false
} | ConvertTo-Json -Depth 8

$response = Invoke-RestMethod `
  -Uri "http://localhost:1234/v1/responses" `
  -Method Post `
  -ContentType "application/json" `
  -Body $body

$response | ConvertTo-Json -Depth 12

MODEL_IDENTIFIERは固定の表示名ではなく、GET /v1/modelsで確認した実際の値に置き換えます。接続できないときは、まずport、server、modelを変えずに、ブラウザや画面ではなく同じ端末からlocalhostの応答を確認します。

• LM Studio公式Responses - POST /v1/responsesの現行例を見る
• LM Studio Structured Output - JSON Schemaの返答が必要な場合に進む
• OllamaのOpenAI互換API - Ollama側の互換pathと比較する

previous_response_idで会話を続ける

Responses docsには、前回responseのidを次のrequestのprevious_response_idへ渡すstateful follow-upが掲載されています。履歴を自分でmessages配列へ再構成する方式と同じものだと決めつけず、response idの保存場所、storeの設定、削除や期限、機密情報の扱いをアプリ側で確認します。

$firstBody = @{
  model = "MODEL_IDENTIFIER"
  input = "短いテスト文を1つ返してください"
  store = $true
} | ConvertTo-Json -Depth 8
$first = Invoke-RestMethod `
  -Uri "http://localhost:1234/v1/responses" `
  -Method Post -ContentType "application/json" -Body $firstBody

$nextBody = @{
  model = "MODEL_IDENTIFIER"
  input = "直前の内容を一文で言い換えてください"
  previous_response_id = $first.id
} | ConvertTo-Json -Depth 8
$next = Invoke-RestMethod `
  -Uri "http://localhost:1234/v1/responses" `
  -Method Post -ContentType "application/json" -Body $nextBody
$next | ConvertTo-Json -Depth 12

実際のresponseにidが含まれるか、保存設定が有効かは手元のLM Studioの応答で確認します。最初の検証では公開テスト文だけを使い、個人情報・秘密鍵・業務資料をstateful履歴へ入れません。

• 最初のresponseをそのままログへ保存せず、必要なidと時刻だけを記録する。
• previous_response_idの値がresp_で始まる現行例と一致するか確認する。
• 新しい会話にしたいときは前回idを送らず、明示的に履歴の境界を作る。
• statefulを使わない設計では、アプリ側で必要な履歴と保存先を自分で管理する。

• LM Studio native chat - native /api/v1/chatのstore・response_idとの違いを見る
• ログとプライバシー - 履歴・server・model fileの保存範囲を分ける
• ローカルLLMの安全性 - 機密情報を送る前の確認項目へ進む

stream=trueのSSEをWindowsで観察する

Responses docsではstream=trueのとき、response.created、response.output_text.delta、response.completedなどのSSEイベントが案内されています。最初はcurl.exe -Nでイベント列を目視し、PowerShellのInvoke-RestMethodで完成済みJSONを読む場合と同じparserを使わないようにします。

curl.exe -N http://localhost:1234/v1/responses `
  -H "Content-Type: application/json" `
  -d "{"model":"MODEL_IDENTIFIER","input":"短いストリーミング応答を返してください","stream":true}"

SSEでは途中の断片だけを永続化せず、接続切断、再接続、重複、完了イベントの扱いを決めます。streamが崩れたときは、まずstream=falseで同じmodelとinputが返ることを確認してからchunk処理を追加します。

• LM Studio公式Responses - response.created・delta・completedの現行例を見る
• LM Studio native streaming - native APIのoutput・イベント形式を比較する
• Prompt Processingの遅さ - 接続後の入力処理と生成を分けて診断する

reasoning・Tool Use・MCPを別の機能として扱う

Responses docsの現行例にはreasoningのeffort指定と、Remote MCP toolsを有効化したrequestが掲載されています。ただし、reasoningが使えるか、toolやMCPがどこへ接続するか、モデルがどの出力を返すかは別々の確認項目です。JSON Schemaを固定したい場合はStructured Output、custom functionを自作する場合はTool Useの記事へ分岐します。

local serverがlocalhostにあるだけで、Remote MCP先やcustom toolの外部作用までローカル完結になるわけではありません。削除、上書き、購入、メール送信、認証情報の利用などは自動実行へ直結させず、人間の確認を残します。

• LM Studio Tool Use - custom toolsのdispatchと安全な実行範囲を見る
• LM Studio Structured Output - response_formatとJSON Schemaを実装する
• MCPとは - MCP、tool calling、権限の役割を分ける

つながらない・404・継続できない時の切り分け

Responses APIのトラブルは、LM Studioアプリ、local server、model、path、request body、SSE parserを一度に変えずに確認します。native /api/v1/chatの成功を、互換 /v1/responsesの成功と読み替えないことも重要です。

1. LM Studioの通常chatでモデル単体の返答を確認する。
2. Developer tab、port、lms server statusを確認する。
3. GET /v1/modelsでmodel identifierを確定する。
4. POST /v1/responsesをstream=false、短いinputで呼ぶ。
5. stateful、reasoning、SSE、tool・MCPを1機能ずつ追加する。

• LM Studioのトラブルハブ - 起動、モデル、Prompt Processing、APIの共通診断へ進む
• LM Studio GPU offload - PC負荷とAPI失敗を分けて確認する
• LM Studio公式REST API - nativeと互換endpointの機能差を再確認する