LM StudioのStructured OutputをWindowsで使う方法｜response_format・JSON Schema・Python

先に結論：Structured Outputは/v1/chat/completionsのJSON契約

LM Studio公式docsでは、JSON Schemaを /v1/chat/completions のresponse_formatへ渡し、返答をchoices[0].message.contentの文字列として受け取ってからJSONへparseする流れが案内されています。Structured Outputは「返答の形」を固定しやすくする機能で、回答の事実性やアプリ側の業務検証を省略するものではありません。

公式REST APIの比較では、native /api/v1/chatはstateful chatやMCPを扱い、custom toolsは/v1/responsesや/v1/chat/completionsなどの互換endpoint側に整理されています。Structured OutputはそのうちJSON Schemaを使う返答形式の問題として扱います。

• ローカルAIでJSON出力 - JSON Schemaの概念、用途、検証の全体像を見る
• LM Studio Tool Use - 関数呼び出しとStructured Outputの違いを見る
• LM Studio公式Structured Output - response_formatとJSON Schemaの公式例を見る

WindowsでDeveloper tab・server・model identifierを確認する

Structured Outputのコードを書く前に、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で、clientへ渡すmodel identifierを確認する。portは実際の表示に合わせる。
5. 最初はschemaを3項目程度、stream=false、短い入力、外部送信なしで基準を作る。

lms server start
lms server status
GET http://localhost:1234/v1/models

LM StudioのChat画面が動くことは、OpenAI互換API、Structured Output、Tool Use、MCPが同じ条件で動くことを意味しません。server、model、endpoint、schemaを分けてログします。

• LM Studioのlms CLI - server start、status、model操作を端末から確認する
• LM StudioをWindowsに入れる - 導入と初回モデル確認へ戻る
• LM Studioモデル保存場所 - モデルの保存と空き容量を確認する

PowerShellからresponse_formatとJSON Schemaを送る

WindowsのPowerShellでは、response_formatの入れ子をハッシュテーブルで組み立ててConvertTo-Jsonに渡すと、引用符のエスケープを減らせます。LM Studio公式例はcurlで /v1/chat/completions へ送り、schemaはresponse_formatのjson_schemaフィールドへ入れています。

$body = @{
  model = "MODEL_IDENTIFIER"
  messages = @(
    @{ role = "system"; content = "JSON Schemaに従って返答してください" }
    @{ role = "user"; content = "メモを分類してください" }
  )
  response_format = @{
    type = "json_schema"
    json_schema = @{
      name = "note_result"
      schema = @{
        type = "object"
        properties = @{
          category = @{ type = "string" }
          summary = @{ type = "string" }
          tags = @{ type = "array"; items = @{ type = "string" } }
        }
        required = @("category", "summary", "tags")
      }
    }
  }
  temperature = 0.2
  stream = $false
} | ConvertTo-Json -Depth 10

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

$result = $response.choices[0].message.content | ConvertFrom-Json
$result | ConvertTo-Json

JSONとしてparseできても、categoryの候補、tagsの長さ、summaryの文字数などアプリ固有のルールまでは自動で決まりません。schema検証と業務検証を分けます。

• LM Studio Chat Completions公式docs - POST、payload、stream、modelの公式仕様を見る
• LM Studio OpenAI Compatibility - base URLと対応endpointを確認する
• ローカルAI API入門 - localhost APIとproviderの基本へ進む

PythonのOpenAI clientでschemaを渡してJSONをparseする

LM Studio公式のStructured Output docsでは、OpenAI clientのbase_urlをlocalhostへ向け、response_formatへJSON Schemaを渡し、choices[0].message.contentをjson.loadsする例が示されています。clientを使っても、parse・型・値の検証はアプリ側に残ります。

from openai import OpenAI
import json

client = OpenAI(
    base_url="http://localhost:1234/v1",
    api_key="lm-studio",
)

schema = {
    "type": "json_schema",
    "json_schema": {
        "name": "note_result",
        "schema": {
            "type": "object",
            "properties": {
                "category": {"type": "string"},
                "summary": {"type": "string"},
                "tags": {"type": "array", "items": {"type": "string"}},
            },
            "required": ["category", "summary", "tags"],
        },
    },
}

response = client.chat.completions.create(
    model="MODEL_IDENTIFIER",
    messages=[{"role": "user", "content": "メモを分類してください"}],
    response_format=schema,
    temperature=0.2,
)

result = json.loads(response.choices[0].message.content)
print(result["category"])

• base_urlはOpenAIの公開先ではなく、LM Studioのlocal serverへ向ける。
• api_keyはserverの認証設定に合わせ、サンプル文字列を秘密情報として扱わない。
• response_formatのschemaとmodel identifierをログに残し、変更時の差を追えるようにする。
• json.loadsの例外、必須key、値の候補、長さを別のエラー処理にする。

OpenAI clientやPythonの依存関係をこのサイトへ追加する手順ではありません。読者のアプリ側で既存の環境に合わせて導入し、SDKのバージョンと例外処理を管理します。

• LM Studio Structured Output公式docs - Python clientとjson.loadsの公式例を見る
• WindowsローカルAIコーディング - コード実行と権限の境界を確認する
• ローカルLLMの安全性 - 入力・ログ・送信先の扱いを見る

JavaScriptのOpenAI clientでもresponse_formatを使える

LM StudioのOpenAI互換endpointはJavaScriptやTypeScriptなどのclientからbase URLを切り替えて使う入口があります。JavaScriptではresponse_formatを送ったあと、choices[0].message.contentをJSON.parseし、必要ならZodなどのschema検証をアプリ側で追加します。

import OpenAI from "openai"

const client = new OpenAI({
  baseURL: "http://localhost:1234/v1",
  apiKey: "lm-studio",
})

const response = await client.chat.completions.create({
  model: "MODEL_IDENTIFIER",
  messages: [{ role: "user", content: "メモを分類してください" }],
  response_format: {
    type: "json_schema",
    json_schema: {
      name: "note_result",
      schema: {
        type: "object",
        properties: {
          category: { type: "string" },
          summary: { type: "string" },
          tags: { type: "array", items: { type: "string" } },
        },
        required: ["category", "summary", "tags"],
      },
    },
  },
  temperature: 0.2,
})

const result = JSON.parse(response.choices[0].message.content)
console.log(result.category, result.tags)

stream=trueでは返答が断片になるため、最初はfalseでJSON化と検証を確認します。表示を早く始めることと、完全なJSONを安全に処理することを同じ段階にしません。

• LM Studio OpenAI Compatibility公式docs - JS/TypeScriptのbase URL例を見る
• LM Studio Tool Use - toolsとJSON出力の役割を分ける
• LM Studioのlms CLI - serverとmodel identifierを再確認する

モデル制約とGGUF・MLX engineを確認する

LM Studio公式docsは、すべてのモデルがStructured Outputに対応するわけではなく、特に7B未満のLLMでは難しい場合があると説明しています。モデルカードやREADMEで対応情報を確認し、schemaが複雑になるほど安定性が下がる可能性を前提にします。

• モデルカードREADMEでStructured Output、JSON Schema、chat templateの記載を確認する。
• 最初はobject、string、arrayなど少ない型で、required項目を絞る。
• temperature、max_tokens、streamを固定して、モデル変更時の差を比較する。
• Structured Outputが動いたことと、生成内容の正しさ・業務判断の正しさを分ける。

• LM Studio公式Structured Output - 7B未満、GGUF、MLX engineの注記を見る
• LM Studio GPU offload - モデルとPC負荷の問題を分ける
• GGUFが読み込めないとき - 形式・保存・ロードの診断へ進む

失敗時はendpoint・model・schema・parseを一つずつ切り分ける

Structured Outputが返らないときは、LM Studioが起動していない、portやmodel identifierが違う、schemaが複雑、モデルが対応していない、streamの処理が未完成、native v1 endpointとOpenAI互換endpointを混同している、などを順番に分けます。

1. Developer tabまたはlms server statusでlocal serverとportを確認し、GET /v1/modelsでmodel identifierを確認する。
2. 通常の /v1/chat/completions をstream=falseで呼び、choices[0].message.contentが返るか確認する。
3. response_formatをjson_schemaへ追加し、schemaを短くしてJSON.parseを確認する。
4. モデルカード、chat template、GGUF/MLX、7B未満などの条件を比較する。
5. native /api/v1/chat、OpenAI互換/v1、Tool Use、MCPを混ぜず、必要な機能のendpointだけを使う。

• HTTP接続エラーは、server、port、認証、model identifierを確認する。
• 本文が空・通常文の場合は、response_format、schema、stream、モデル対応を確認する。
• JSON.parse成功後の値が不適切なら、列挙値・長さ・件数・業務ルールを追加する。
• 実ファイル、秘密情報、削除・書き込み、外部APIを最初のStructured Outputテストに使わない。

• LM Studio REST API公式docs - nativeと互換endpointの機能比較を再確認する
• LM Studioが起動しないとき - server、port、モデルの診断へ進む
• ローカルAIのトラブルシューティング - モデル・メモリ・入力の問題を横断して見る