lmstudio-cli

LM Studio CLI

実際の作業が LM Studio 自体の操作である場合に、このスキルを使用します。lms が存在するかの確認、ローカルまたはリモートの LM Studio サーバーが実際に稼働しているかの確認、正確なモデル ID の特定、OpenAI 互換エンドポイントで十分かどうかの判断、後続ツールを正しいベース URL とモデル識別子に接続する作業が該当します。

汎用的なローカル LLM 比較スキルとしては使用しないでください。プロバイダーの広範な比較やプラットフォームの選定は、調査・比較の作業に振り分けてください。LM Studio 自体の動作確認が済んだ後の、後続ツール固有のスキャンやアプリケーションセキュリティ運用は、そのツールのスキル（たとえば strix）に振り分けてください。

このスキルを使う場面

• ユーザーが LM Studio、lms、または LM Studio サーバーについて直接言及している
• LM Studio がローカルまたは別の許可されたホストで稼働しているか確認する必要がある
• 別のツールを接続する前に、/v1/models が返す正確なモデル ID が必要である
• LM Studio の OpenAI 互換エンドポイントとネイティブ REST API のどちらを使うか選ぶ必要がある
• エージェントまたは CLI がモデルを使用できるよう、モデルをロード、確認、または検証する必要がある
• 後続ツールが OpenAI 互換エンドポイントに対応しているが、ユーザーが LM Studio 固有のセットアップ支援を必要としている
• リモート／ヘッドレスの LM Studio ワークフローに問題があり、確実な検証手順が必要である

手順

ステップ 1：動作モードを特定する

コマンドを実行する前に、リクエストを次のように分類します。

1. ローカルネイティブ CLI モード — 対象マシンに LM Studio がインストールされ、lms が利用可能である必要があります
2. リモート HTTP モード — 許可された LM Studio エンドポイントをテストまたは利用するだけで十分です
3. LM Studio ネイティブ管理モード — 汎用的な OpenAI 互換呼び出しでは対応できない、モデルのロード／一覧表示／アンロードが必要です
4. 後続ツール接続モード — ユーザーはすでに LM Studio を起動しており、別のツールを接続する必要があります

リクエストに対応できる最小限のモードを使用してください。

ステップ 2：ローカルに lms があるか確認する

ローカル CLI の操作が想定される場合は、まず確認します。

command -v lms
lms --help

lms が見つからない場合は、ローカル CLI の出力を捏造しないでください。ホスト／エンドポイントが明示的に許可されている場合に限り、リモート HTTP による確認を続けてください。

ステップ 3：サーバーの状態またはエンドポイントへの到達性を確認する

ローカルのネイティブ確認の場合：

lms server status
lms server status --json --quiet

リモートまたはクライアント形式のスモークテストの場合：

curl -fsS http://HOST:PORT/v1/models

最小限の応答テスト（任意）：

curl -fsS http://HOST:PORT/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODEL_ID",
    "messages": [{"role": "user", "content": "reply with exactly OK"}],
    "temperature": 0,
    "max_tokens": 8
  }'

curl のコピー＆ペーストではなく再利用可能なパーサーを使う場合は、python3 scripts/check_lmstudio_endpoint.py --base-url http://HOST:PORT/v1 を使用してください。

ステップ 4：正確なモデル識別子を特定する

モデル名を推測しないでください。

次のいずれかを使用します。

lms ls
lms ls --llm
lms ps --json
curl -fsS http://HOST:PORT/v1/models

ロード済みインスタンスの正確な情報やランタイムの状態が必要な場合は、汎用的な後続クライアントの表示よりも、lms ps またはネイティブ REST API を優先してください。

ステップ 5：必要な場合に限り、LM Studio ネイティブ管理に切り替える

OpenAI 互換機能では不十分な場合は、ネイティブ REST API または LM Studio ネイティブコマンドを使用します。

curl -fsS http://HOST:PORT/api/v1/models
curl -fsS http://HOST:PORT/api/v1/models/load \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "MODEL_KEY",
    "context_length": 262144,
    "echo_load_config": true
  }'

ローカルでは次のとおりです。

lms load MODEL_KEY --identifier my-model
lms ps --json

コンテキスト長、ロード状態、またはインスタンス固有の質問には、この方法を使用してください。/v1/models と /v1/chat/completions でユーザーのニーズにすでに対応できる場合、あらゆる連携の問題をネイティブ管理の問題として扱わないでください。

ステップ 6：後続ツールを慎重に接続する

OpenAI 互換サーバーを想定しているツールには、正確なモデル ID とベース URL を渡します。

export LLM_API_BASE="http://HOST:PORT/v1"
export STRIX_LLM="openai/MODEL_ID"

OpenAI 互換クライアントによっては、LM Studio 自体に実際のプロバイダーキーが不要な場合でも、API キー欄への入力を要求するものがあります。その場合は、LM Studio の認証方式について誤解を招く説明をするのではなく、クライアントが要求するダミーキーを後続ツールの設定にのみ指定してください。

ステップ 7：推測ではなく、動作確認で得た事実を報告する

適切な最終報告には、次の内容を含めます。

• lms がローカルに存在していたか
• サーバーをローカル、リモート、またはその両方で検証できたか
• テストした正確なベース URL
• 特定した正確なモデル ID
• ユーザーが OpenAI 互換の呼び出しだけを必要としていたか、LM Studio ネイティブ管理を必要としていたか
• 後続ツールに必要な最終的な環境変数／設定のスニペット、またはコマンド

例

例 1：LM Studio がインストールされたローカルマシン

ユーザーの質問：「lms はインストールされていますか？また、どのモデルが読み込まれていますか？」

推奨されるフロー：

command -v lms
lms server status --json --quiet
lms ps --json

例 2：別のツール向けのリモート LM Studio ホスト

ユーザーの質問：「Strix を自分の LM Studio マシンに接続してください。」

推奨されるフロー：

curl -fsS http://HOST:PORT/v1/models
python3 scripts/check_lmstudio_endpoint.py --base-url http://HOST:PORT/v1
export STRIX_LLM="openai/MODEL_ID"
export LLM_API_BASE="http://HOST:PORT/v1"

例 3：OpenAI 互換のスモークテスト以上の確認が必要な場合

ユーザーの質問：「より大きなコンテキスト長でモデルを読み込み、有効な設定を教えてください。」

推奨されるフロー：

curl -fsS http://HOST:PORT/api/v1/models
curl -fsS http://HOST:PORT/api/v1/models/load \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_KEY","context_length":262144,"echo_load_config":true}'

例 4：ヘッドレス環境での障害切り分け

ユーザーの質問：「Linux VM で lms server start が失敗しました。まず何を確認すればよいですか？」

推奨されるフロー：

• lms --help を確認する
• lms server status --json --quiet を実行する
• 必要に応じて、詳細ログを有効にして再実行する
• 設定を編集する前に、ローカルのデーモン／サーバーの障害と、下流の OpenAI クライアントの障害を切り分ける

ベストプラクティス

1. ローカル CLI の利用可否とリモート HTTP への到達性は分けて考えてください。関連はありますが、同じ事実ではありません。
2. 名前を独自に短縮せず、LM Studio が返す正確なモデル ID を使ってください。
3. 下流ツールとの接続には OpenAI 互換エンドポイントを優先し、モデル管理に関する質問にはネイティブの REST／CLI インターフェースを使ってください。
4. 下流のクライアントで API キー欄が必須になっている場合は、LM Studio の要件ではなく、クライアントの互換性に関する仕様として説明してください。
5. プライベートネットワーク上のリモートホストは機密性の高い対象として扱ってください。ユーザーが許可したエンドポイントのみを確認してください。
6. シンプルな /v1/models の確認では不十分な場合に限り、モデルの読み込み状態やコンテキスト長に関する案内に進んでください。
7. 境界を明確にしてください。lmstudio-cli は LM Studio 自体の検証と設定を担当し、エンドポイントが動作した後の処理は下流ツールのスキルが担当します。

参考資料

• references/cli-and-server-basics.md
• references/endpoints-and-escalation.md
• references/downstream-tool-wiring.md
• scripts/check_lmstudio_endpoint.py
• LM Studio CLI のドキュメント
• LM Studio OpenAI 互換性ドキュメント
• LM Studio REST API のドキュメント