ローカルAIをAPIで使うには？LM Studio・Ollama・JanのOpenAI互換APIを初心者向けに解説

localhost:11434とLM Studio APIのトラブルを分ける

API一般の記事から、Ollamaのlocalhost:11434問題とLM Studioのnative v1/API互換問題へ分岐できるようにします。API接続が失敗した時は、アプリやserverが起動しているか、endpoint、model identifier、stream、HTTP error、モデル単体の速度を別に記録します。

• Ollamaが起動しない・localhost:11434につながらない - API接続不可をアプリ・server・portから切り分ける
• Ollamaが遅い - API usageとPROCESSORで段階を測る
• Ollamaの回答が途中で止まる - done_reasonと最終チャンクを確認する
• LM StudioのPrompt Processingが遅い - 最初の返答までの入力処理を確認する
• LM Studioの回答が途中で止まる - APIの生成途中停止を確認する

LM Studioの現行API pathを分ける

LM Studio 0.4.0の発表記事には歴史的な`/v1/chat`表記がありますが、現行Developer Docsのnative chat endpointは`POST /api/v1/chat`です。`/v1/chat/completions`と`/v1/responses`はOpenAI互換APIで、native pathとは別に扱います。

• LM Studio REST API - 現行native v1と互換endpointの比較を見る
• native chat API - POST /api/v1/chatの仕様を見る
• OpenAI互換tools - /v1/chat/completionsのtool useを見る

モデル一覧GETの成功から生成POSTを確かめる

LM Studioのmodel一覧を取得できても、chat生成が成功したとは限りません。OpenAI互換の`GET /v1/models`は`data[].id`を返し、JIT loadingが有効なら未ロードのダウンロード済みmodelも含むことがあります。nativeの`GET /api/v1/models`は別のschemaで、`models[].key`、`type`、`loaded_instances`からLLM・embedding・decisionの種類とロード中のinstanceを確認できます。nativeのresponseをOpenAI互換requestのmodel listとして扱わず、chatには`/v1/models`で返った実際の`id`を使います。

以下はLM Studio 0.4.0以降とWindows PowerShell 5.1またはPowerShell 7を対象にしています。まずLM StudioアプリのDeveloper / Local Server画面または`lms server status`で、起動状態と実際のloopback host・portを確認します。以下の`1234`は公式例のdefault値です。表示が別のportなら置き換え、`$server`にはhostとportだけを入れてください。LAN公開やfirewall変更は不要です。

Server認証を有効にしている場合は、LM Studio 0.4.0以降のManage Tokensで作成した有効なAPI tokenと必要なpermissionを`Authorization: Bearer`として`$headers`に設定してから実行します。3つのrequestは同じ`$headers`を使うので、両方のGETと次のPOSTへtokenが渡ります。認証を無効にして回避せず、tokenを共有ログやissueへ貼らないでください。

$server = 'http://localhost:1234' # 画面に表示されたloopback host・portに置き換える
$headers = @{} # 認証有効時は有効なAuthorization: Bearerを含むhashtableに置き換えて実行

$openAiRequest = @{
  Uri = "$server/v1/models"
  Method = 'Get'
  Headers = $headers
  ErrorAction = 'Stop'
  TimeoutSec = 20
  UseBasicParsing = $true
}
$openAiModels = Invoke-RestMethod @openAiRequest

$nativeRequest = @{
  Uri = "$server/api/v1/models"
  Method = 'Get'
  Headers = $headers
  ErrorAction = 'Stop'
  TimeoutSec = 20
  UseBasicParsing = $true
}
$nativeModels = Invoke-RestMethod @nativeRequest

$openAiModels.data | Select-Object -ExpandProperty id
$nativeModels.models | Select-Object type, key, @{Name = 'loaded'; Expression = { $_.loaded_instances.Count -gt 0 }}

一覧の先頭をそのまま選ばず、アプリ上のchat用LLMと照合します。native一覧で`type`が`embedding`または`decision`のmodelはchat用として選びません。`loaded_instances`が空なら未ロードです。JITでは未ロードmodelを最初のrequest時にロードする場合もありますが、GETが200でもロードや生成の成功を意味しません。

次に、`/v1/models`の`data[].id`からchat用として確認したIDを入力し、Chat Completionsのschemaで短いrequestを送ります。構造化したhashtableからJSONを作り、UTF-8 bytesを明示しているため、Windows PowerShell 5.1とPowerShell 7で同じbodyを送れます。

$modelId = Read-Host '/v1/models の data[].id にあるchat用model IDを入力'
if ($openAiModels.data.id -notcontains $modelId) {
  throw '入力したIDがGET /v1/modelsの一覧にありません。IDを再確認してください。'
}

$request = @{
  model = $modelId
  messages = @(@{ role = 'user'; content = '「OK」とだけ返してください。短い形式確認です。' })
  stream = $false
  max_tokens = 128
}
$json = $request | ConvertTo-Json -Depth 5 -Compress
$jsonBytes = [System.Text.Encoding]::UTF8.GetBytes($json)

$chatRequest = @{
  Uri = "$server/v1/chat/completions"
  Method = 'Post'
  Headers = $headers
  ErrorAction = 'Stop'
  ContentType = 'application/json; charset=utf-8'
  Body = $jsonBytes
  TimeoutSec = 120
  UseBasicParsing = $true
}
$response = Invoke-RestMethod @chatRequest

if (-not $response.choices -or -not $response.choices[0].message) {
  throw 'Chat Completions形式のchoices[0].messageがありません。response schema、選択したAPI family、serverのHTTP errorを確認してください。'
}
[pscustomobject]@{
  finish_reason = $response.choices[0].finish_reason
  content = $response.choices[0].message.content
}

POSTがtimeoutした場合も成功扱いにせず、アプリ側でload・JIT loadingの状態とmodel資源を確認してから、同じ短いrequestをもう一度試します。response本文にはpromptや環境情報が含まれることがあるので、共有時はtokenや個人データを除いて必要なstatusだけを伝えます。

• LM Studio CLIのserver・model確認 - lms server status、model一覧、ロード状態のCLI確認を見る
• LM Studio Responses API - Responses endpointを使う場合のschemaと動作を確認する
• ローカルAI全般のトラブルシューティング - この短いlist-to-chat確認後も続く失敗を切り分ける

• LM Studio OpenAI互換モデル一覧 - GET /v1/modelsとJIT時の一覧範囲を見る
• LM Studio native model list - type、key、loaded_instancesのresponse schemaを見る
• LM Studio Chat Completions - model、messages、streamの公式仕様を見る
• LM Studio API authentication - tokenとpermissionの条件を見る
• PowerShell 5.1 Invoke-RestMethod - UseBasicParsing、TimeoutSec、ContentType、Headersの構文を見る
• PowerShell 5.1 ConvertTo-Json - ConvertTo-JsonのDepthを確認する

Hermes Desktopでつながらない時の読み順

Hermes Desktopの設定を何度も変える前に、症状別ハブで provider 側、base URL、model ID、API key、PC負荷を分けて確認してください。

• Hermes Desktopトラブル解決ハブ - connection refused、model not found、401/429、timeout、WSL2を症状別に切り分ける
• Hermes Desktop接続トラブル診断 - 数問選んで最初に疑う原因と読む記事を確認する

ローカルAIをAPIで使うとは

APIは、別のアプリやコードからAIに指示を送る窓口です。チャット画面に文章を入力する代わりに、Python、JavaScript、自作ツール、ノートアプリ、RAGツールなどからローカルAIへリクエストを送ります。

ローカルAI APIを使うと、文章の下書き、要約、分類、翻訳、メモ整理、個人開発アプリへのAI機能追加などに進めます。ただし、APIで呼び出してもモデルが重ければ遅く、モデルサイズ、量子化、コンテキスト長、メモリ、VRAMの影響は残ります。

APIサーバーとは何か

APIサーバーとは、別のアプリからのリクエストを待ち受ける小さな窓口です。LM StudioやJanのデスクトップアプリ、Ollamaのような常駐プロセスを起動し、そこへコードや別ツールから接続します。

初心者は外部公開やLAN公開を急がず、自分のPC内だけで動くlocalhostから始めてください。localhostは「自分のPC自身」を指す住所のようなもので、最初の検証では外部へ開けないほうが安全です。

OpenAI互換APIとは何か

OpenAI互換APIは、OpenAI向けに作られたコードやツールを、ローカルAIのサーバーへ向け替えられる可能性がある仕組みです。たとえばbase URLをOpenAIではなくlocalhostのアドレスに変えることで、同じような形でチャット補完を呼び出せる場合があります。

ただし、完全互換ではありません。対応エンドポイント、パラメータ、ストリーミング、ツール呼び出し、埋め込み、レスポンス形式はツールやバージョンごとに異なります。「OpenAI互換だから何でも同じ」と考えず、使う機能ごとに公式ドキュメントを確認してください。

LM Studio / Ollama / Jan のAPI比較表

LM StudioのAPIでできること

LM StudioはローカルLLM APIサーバーとして使える機能があり、現行の公式REST APIではnative v1 APIの`/api/v1/*`と、OpenAI互換の`/v1/*`を分けて案内しています。`/api/v1/chat`、`/v1/responses`、`/v1/chat/completions`では対応機能が同じとは限らないため、使うendpointを先に決めます。

LM StudioはGUIでモデルを選び、読み込んでからAPIとして試しやすい点が入口になります。まず短い質問でモデル単体の速度を確認し、そのあとAPI呼び出しへ進むと原因を切り分けやすくなります。

• LM StudioのResponses API - OpenAI互換の/v1/responses、stateful、streamingを確認する
• LM StudioのMCPをAPIで使う - native /api/v1/chat、integrations、allowed_toolsを確認する
• LM StudioのPython SDK - Pythonからロード済みモデルを選び、応答やstreamを扱う

OllamaのAPIでできること

OllamaはAPIやOpenAI互換APIを使った連携に向きます。現行の公式docsではlocal APIのbase URLを`http://localhost:11434/api`、OpenAI互換を`http://localhost:11434/v1/`として分け、cloud APIは別のbase URLで案内しています。

コマンド操作に抵抗がない人なら、Ollamaは個人開発や自動化の土台にしやすいです。一方で、完全初心者はモデル名、実行状態、コンテキスト設定、停止方法を混同しやすいので、まず単体のチャット動作を確認してください。

• OllamaのOpenAI互換API - /v1、model、Chat Completions・Responsesの対応範囲を見る
• OllamaのResponses API - /v1/responsesのstreamingと非stateful制約を確認する

JanのローカルAPIサーバーでできること

Janの現行API Referenceでは、ローカルAPIを`http://127.0.0.1:1337`で提供し、`/v1/models`、`/v1/chat/completions`、`/v1/messages`を案内しています。API keyを設定してAuthorization headerを付ける前提があるため、LM StudioやOllamaのlocal例と認証条件を同じにしません。

JanはLM Studioの次に比較したい人、自分用AI環境を作りたい人、API連携も見たい人に向きます。APIだけで判断せず、ローカル実行なのか外部接続なのかを分けて確認してください。

Foundry LocalをAPI候補にするとき

Foundry LocalはLM Studio、Ollama、Janとは別のWindows向けruntimeです。CLIのlocal serverとOpenAI互換の`/v1/chat/completions`を使う入口がありますが、CLIとRESTはpreview・active developmentとして案内されているため、利用時点の公式referenceを確認します。

• Foundry LocalをWindowsで使う方法 - CLI、local REST、SDK、model aliasとExecution Providerを確認する
• Foundry Local CLI reference - 現行のfoundry service、model list --filter、model runを確認する
• Foundry Local REST API - /v1/chat/completionsとpreviewの注意を確認する

Foundry LocalのAPIは「ポート」よりendpoint・model ID・状態で確認する

Foundry Localの現行REST referenceには`/v1/chat/completions`だけでなく`/v1/audio/transcriptions`もあります。OpenAI互換と書かれていても、接続先のendpointだけで判断せず、ロード済みmodel ID、Execution Provider、サービス状態を一緒に記録します。

Foundry Localはdynamic portでサービスを起動するため、`5272`や`1337`のような数字を記事やコードへ固定しません。CLIなら`foundry server status`、SDKなら`manager.endpoint`など、実行時に得たendpointを使います。model aliasはcatalogやcacheを選ぶ入口であり、RESTのリクエストでは実際にロードされたmodel IDを確認して指定するのが安全です。

最初の切り分けは次の順番です。

1. CLIまたはSDKでserviceを起動し、CLIなら`foundry server status`、SDKならmanagerのendpointを記録する。
2. model alias、ダウンロード済み、ロード済みを分け、`/openai/loadedmodels`でRESTに渡すmodel IDを確定する。
3. 短い`/v1/chat/completions`を送り、日時、endpoint、model ID、Execution Provider、HTTP結果を残す。
4. 音声を試す場合は`/v1/audio/transcriptions`をASRとして確認し、話者区間や話者名は別のdiarization工程として扱う。
5. REST referenceはactive developmentでbreaking changesの可能性があるため、利用時点のバージョン、endpoint、model ID、Execution Provider、fallback条件を記録する。

• Foundry Local REST API - endpoint、model ID、Audio Transcriptions、Execution Providerの現行仕様を確認する
• Foundry Local CLI - server status、model list、download、cacheの確認方法を見る
• Foundry Local SDKの開始手順 - service自動起動、cache、load、chat、cloud fallbackの入口を見る
• 話者分離の保存単位 - 文字起こしと話者区間・話者IDを別工程で保存する

クラウドAPIとローカルAI APIの比較表

PythonやJavaScriptから呼び出すと何ができるか

短いスクリプトから文章の要約、分類、下書き、ファイル名の整理、ログの読み取り補助などを試せます。コード例を使う場合は、まずlocalhostの短いテストに限定し、APIキーや秘密情報を外部へ送らない形にしてください。

既存のOpenAI向けコードを流用する場合でも、base URL、モデル名、対応パラメータをローカルツールに合わせる必要があります。動かないときは、コードより先にAPIサーバーが起動しているか、モデルが読み込まれているかを確認します。

APIで使うときに必要なPCスペック

APIで呼び出すから軽くなるわけではありません。実際には同じモデルを動かしているため、モデルサイズ、Q4/Q5/Q8、コンテキスト長、CPU、GPU、VRAM、同時起動アプリが関係します。

• ローカルAIのモデルサイズ早見表 - 8GB、16GB、32GBで最初に選ぶモデルサイズを確認する
• コンテキスト長とは - 長文や会話履歴でAPIが重くなる理由を確認する
• GPUオフロードとは - LM StudioでCPU/GPU/VRAMを見るポイントを確認する

セキュリティで注意すること

外部公開やLAN公開を安易に勧めません。最初はlocalhostだけで動かし、必要が出た場合だけ、認証、ファイアウォール、CORS、接続元、ログ、入力データの扱いを確認してください。

クラウドAPIや外部APIへ接続する場合は、入力した文章やファイルの一部が外部へ送信される可能性があります。社内文書、顧客情報、個人情報、秘密情報を扱う前に、公式情報、利用規約、会社や案件のルールを確認してください。

初心者はどこから始めるべきか

最初はLM StudioまたはOllamaで軽いモデルを1つ動かし、短い日本語質問に答えられるか確認します。次にlocalhostのAPIへ短いリクエストを送り、最後に自分のスクリプトやツールへつなげる順番が安全です。

• LM Studioの基本情報 - GUIでモデルを起動してからAPIへ進む
• Ollamaの基本情報 - コマンド/API連携を前提に使う入口を確認する
• Janとは - ローカルAIと外部APIを1つの画面で扱う選択肢を確認する

次に読む記事

• コンテキスト長とは - APIで長文や会話履歴を扱う前に読む
• ローカルAIでJSON出力する方法 - APIの回答をプログラムで扱いやすい形にする
• MCPとは - AIに外部ツールを使わせる仕組みと注意点を見る
• RAG・埋め込み・ベクトルDBの仕組み - PDFや文書チャットをAPIと組み合わせる前に読む
• GPUオフロードとは - LM Studio APIが遅いときのPC側確認に進む
• Q4/Q5/Q8の違い - APIで使うモデルの軽さと品質を確認する