概要

1.1 要旨

ローカルモデルサービスプロトコル（LMSP）は、クライアントが、ユーザー自身のデバイスやローカルネットワーク上で動作する言語モデルサービスを見つけて利用する方法を定義する。サービス発見、モデルカタログ、同期生成とストリーミング生成、再起動後も残る非同期タスクを規定する。また、1 つのサービスが LMSP インターフェースと並べて OpenAI 互換インターフェースを提供する方法も定義し、既存のクライアントがそのまま動作できるようにする。

LMSP は OpenAI API、Ollama、MCP を置き換えるものではない。それぞれの長所を、常駐するローカルサービス向けのプロトコル層にまとめたものである。

1.2 本文書の状態

本文書は 2026-11-08 に公開された LMSP 1.0 の最初の公開ドラフトである。「LMSP」は仮称である。内容はフィードバックを受け付けており、1.0 が確定するまでは互換性のない変更が入る可能性がある。

英語版が規範である。翻訳は利便性のために提供されており、両者が異なる場合は英語版が優先される。

1.3 設計の基礎

LMSP は新しい設計を発明せず、実績のある設計を再利用する。

• OpenAI Responses API。 構造化された出力アイテム、意味を持つサーバー送信イベント、長時間処理のための照会とキャンセルを備えたバックグラウンド実行。LMSP のコア会話インターフェースの手本である。ストリーミングレスポンスとバックグラウンドモードを参照。
• Ollama。 OpenAI 互換の /v1/models、/v1/chat/completions、/v1/responses エンドポイントを提供しており、1 つのサービスに OpenAI 適応層を加えることで導入コストが大きく下がることを示している。Ollama の OpenAI 互換性を参照。
• Model Context Protocol（MCP）。 最新の設計は、必須のセッション初期化からステートレスな発見へ移っている。すべてのリクエストが自分のバージョン情報を携え、クライアントは発見用インターフェースを通じて機能を知る。再起動、クライアントのクラッシュ、接続断があってもプロトコルの状態が壊れてはならないローカルサービスに適している。MCP を参照。
• Agent2Agent（A2A）。 サービスカード、明示的なタスク状態、タスクの購読とキャンセルは、LMSP のサービス記述と非同期タスクモデルの参考になっている。A2A を参照。

1.4 アーキテクチャ

LMSP は、モデルランタイムと通信するアダプターの上に、3 つの層で構成される。

+---------------------------------------------------------------+
| Discovery      mDNS / DNS-SD + well-known service document    |
+---------------------------------------------------------------+
| Core           model catalog, responses, SSE, async tasks     |
+---------------------------------------------------------------+
| Compatibility  OpenAI API, optional Ollama API                |
+---------------------------------------------------------------+
| Adapters       llama.cpp, Ollama, vLLM, custom runtimes       |
+---------------------------------------------------------------+

• 発見。 mDNS/DNS-SD と、well-known のサービス記述ドキュメント（第 3 章）。
• コア。 モデルカタログ、同期レスポンス、サーバー送信イベント、非同期タスク（第 5〜7 章）。
• 互換。 OpenAI 互換 API と、任意の Ollama 互換 API（第 8 章）。
• アダプター。 llama.cpp、Ollama、vLLM、またはカスタムランタイムへのブリッジ。

指針は「1 つのモデル実行コア、2 つのインターフェースファミリー」である。サービスは同じコアの上に LMSP インターフェースと OpenAI インターフェースを提供するため、モデルのロード、リクエストの実行、タスクの追跡を行う場所が 1 か所に定まる。

1.5 適合性の表現

本文書で太字で表記された なければならない（MUST）、てはならない（MUST NOT）、必須（REQUIRED）、べきである（SHOULD）、べきではない（SHOULD NOT）、推奨（RECOMMENDED）、てもよい（MAY）、任意（OPTIONAL）は、BCP 14（RFC 2119、RFC 8174）に記述されているとおりに解釈する。太字で表記されていない場合は、通常の語として扱う。

各ページには、規範的か参考情報かが示されている。規範的なページは要件を定め、参考情報のページは手引きを与える。例はすべて参考情報である。JSON は UTF-8 とし、フィールド名には snake_case を使う。

1.6 用語