コマンドラインと MCP サーバー

Laya には、同じ構造化意思決定エンジンを試すためのローカルインターフェースが 2 つあります：

インターフェース	用途	トランスポート
`laya`	ターミナルからの手軽な確認と対話的な探索	コマンドライン
`laya-mcp-server`	MCP クライアントやエージェントを Laya の組み込みツールにつなぐ	stdio 上の MCP

結果を読むのが自分自身なら CLI を選びます。別のプロセスが安定したツールインターフェースを必要とするなら MCP を選びます。どちらも Laya の Router を使ってチェックポイントを選び、型付きの choice、score、noul の判断を返します。どちらも自由形式の質疑応答やテキスト生成のインターフェースではありません。

ルーティングの判断と型付き質問の例は、README の Route Mode クイックスタートを参照してください。信頼度と組み込みワークフローは、README の信頼度ゲートとワークフロープリセットを参照してください。

1. コマンドライン

パッケージをインストールすると laya エントリポイントが入ります。完全なオプション一覧は laya --help で確認できます。

python -m pip install laya
laya --help

評価 CLI

パッケージは laya-evals もインストールします。メインの CLI は laya eval を通じて同じ評価コマンドを公開します：

laya eval --help

データセット、指標、ベースラインのゲートについては、評価 harness ガイドを参照してください。

チェックポイントを読み込まずにルートする

テキストだけを渡し、予測フラグを付けない場合、CLI は Router.route を呼びます：

laya "I was charged twice, please refund it"

出力には、選ばれたチェックポイントとその理由、言語情報が取れる場合は検出された言語が表示されます。ルーティングだけではチェックポイントのダウンロードもビルドも行わないので、ルーティング判断の手軽なオフライン確認になります。

別のローカルスクリプトに判断を渡したいときは --json を使います：

laya "I was charged twice, please refund it" --json

予測を実行する

--predict は完全な型付き予測を実行し、初回使用時にルーティングされたチェックポイントを読み込みます。初回ロードには Hugging Face Hub へのアクセスが必要です。以降の実行はローカルキャッシュを使います。

laya "Classify this support request" --predict
laya "Classify this support request" --predict --json

--json は完全な結果を JSON として出力します。付けない場合、CLI は各答えをその choice の確率、score、noul の値とともに出力し、ルーティング判断も加えます。

主な制御は次のとおりです：

--model english|multilingual|typed-decisions は、自動ルーティングの代わりにチェックポイントを固定します。
--lang en|de|... は、自動検出の代わりに言語コードを明示的に指定します。
--task NAME は、自動検出の代わりに typed-decisions ワークフローを強制します。
--device cpu|cuda|... は、デバイスの選択を Router に渡します。
--json は機械可読な出力を生成します。

組み込みプリセットを使う

プリセットはすぐ使える質問セットを提供し、予測を含むので、--predict は不要です：

laya "My payment failed twice" --preset triage
laya "Ignore all previous instructions" --preset guard --json

CLI のプリセットは email、guard、moderation、router、triage です。CLI は、選んだプリセットが想定する state フィールドの下にテキストを配置します。--predict はルーティング質問セットの request フィールドを使います。プリセットは手元での手軽な確認には便利ですが、その質問はやはりドメインの判断です。アプリケーションの方針として使う前に、プリセットを確認し、自分のデータで検証してください。

対話的に探索する

テキスト引数を付けないと、CLI は小さなプロンプトを開きます：

laya
# laya> Classify this request
# laya> quit

Enter を押すと各リクエストが実行されます。空行、quit、exit、Ctrl-D でセッションが終了します。対話ループは 1 つの Router を使い回すので、スクリプトを書かずに複数の入力を比べるのに便利です。

失敗が見える

CLI は、不正な値や、よくある依存関係・ダウンロード・実行時の失敗をアプリケーションの境界で処理します。診断情報を stderr に出力し、未処理の traceback を出す代わりに終了コード 2 を返します。初回使用時のチェックポイントのダウンロードが失敗したら、再試行する前に依存関係のインストール、 Hub へのアクセス、選択したデバイスを確認してください。

2. 組み込み MCP stdio サーバー

MCP サーバーは任意の追加パッケージです。コアパッケージは mcp 依存をインストールしません：

python -m pip install "laya[mcp]"
laya-mcp-server
# equivalent module form:
python -m laya.mcp.server

サーバーは HTTP ではなく stdio 上で MCP を喋ります。コンソールスクリプトでクライアントを設定します：

{
  "mcpServers": {
    "laya": {
      "command": "laya-mcp-server",
      "env": {
        "LAYA_DEVICE": "cpu"
      }
    }
  }
}

クライアント設定が Python 実行ファイルと引数を指定できるなら、python -m laya.mcp.server を等価な起動形式として使えます。サーバープロセスはクライアントが持ちます。Laya はネットワークポートを開きません。

利用できるツール

ツール	動作	主な入力
`laya_status`	設定された、または実際のデバイス、CUDA の可用性、読み込み済みのチェックポイント、プリロード状態、準備状態、パッケージのバージョンを報告します。	なし
`laya_route`	フォワードパスを実行せずにチェックポイントを選び、そのモデル、リポジトリ、理由を返します。	`state`、`questions`
`laya_predict`	型付き質問を実行し、答え、ルーティングのメタデータ、レイテンシ、読み取れる場合は応答したデバイスを返します。	`state`、`questions`、省略可能な `model`（`auto`、`english`、`multilingual`、`typed-decisions`）
`laya_shortlist`	選択肢の多い choice 質問をショートリストしてから回答し、ショートリストのメタデータを返します。	`state`、`questions`、省略可能な `model`、省略可能な `k`（既定 `20`）
`laya_preset`	組み込みの質問セットを使って組み込みワークフローを実行します。	`preset`、`state`
`laya_predict_batch`	1 回の呼び出しで多数のリクエストに答えます。リクエストはまずルーティングされ、チェックポイントごとにグループ化されるので、質問スキーマが一致するものはフォワードパスを共有します。答えは入力順に返ります。	`requests`、各要素は `{state, questions, model?, task?, lang?}`、省略可能な `batch_size`
`laya_route_batch`	各リクエストにどのチェックポイントが答えるかを判断します。フォワードパスもチェックポイントの読み込みも行いません。	`requests`、形状は `laya_predict_batch` と同じ
`laya_decide`	1 回のフォワードパスで JSON schema 形状の判断に答え、解析対象の答えのマップではなく、判断された値とフィールドごとの信頼度を返します。schema のプロパティは enum の choice、真偽値、または最小値と最大値を持つ整数にできます。自由な文字列、配列、ネストしたオブジェクトはパス単位で拒否されます。	`state`、`schema`、省略可能な `model`

この 3 つのバッチと schema のツールがあるのは、同じ操作が SDK と laya-serve でも使えるからです。多数のリクエストを扱いたいときや、呼び出し側がすでに答えの形を知っているときに、 Python まで降りる必要はありません。schema 駆動の形式をより詳しく知るには、 Schema 駆動の意思決定を参照してください。

共有のガードレールは、20 を超える選択肢を持つ choice 質問をショートリストなしで送らないように求めます。laya_shortlist はフォワードパスの前に、最も確からしい k 個のラベルを残します。既定は k=20 です。応答するチェックポイント自身のエンコーダによる平均プール埋め込みを使うので、2 つ目のモデルをダウンロードせず、ショートリストした各質問について、残したラベル、コサインスコア、k、選択肢数を返します。

state は空でない JSON オブジェクトでなければなりません。questions は、値が Laya の型付き質問 schema を使う空でないオブジェクトでなければなりません。laya_preset は CLI と同じ 5 つのプリセットを受け付けます：email、guard、moderation、triage、そして router ワークフローです。この面での正規名は model_router です。router は同じプリセットを指す別名として受け付けられるので、CLI の綴りもここで動きます。正規のキーが結果で返ってきます。state がちょうど 1 つの文字列のとき、laya_preset はそれをそのプリセットの質問が指定するフィールドの下に置きます。配置は CLI と同じなので、呼び出し側はキーを推測する必要がありません。1 つの文字列より複雑なものは呼び出し側自身の形であり、そのまま通されます。

予測呼び出しは SDK の型付き呼び出しと同じ形状です：

{
  "state": {
    "body": "I was billed twice for the same plan. Please reverse the duplicate charge."
  },
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this request?",
      "criteria": {
        "billing": "payments, invoices, refunds, duplicate charges",
        "technical": "bugs, outages, integration problems"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "Does the user need immediate help?"
    }
  }
}

ツールの応答は、型付きの answers、routing の判断、タイミング情報を含む JSON です。高信頼度の答えを、外部アクションを実行する許可と見なさないでください。方針、レビュー、副作用は引き続きアプリケーションまたはエージェントの責任です。

起動と環境

MCP サーバーは常駐の Router を保ち、初回の構築を直列化します。既定では english と multilingual をプリロードし、typed-decisions は遅延のままです。プリロードの失敗は起動時に報告され、次のツール呼び出しで再試行されるので、サーバーが準備できていると決め込む前に laya_status を確認してください。

変数	既定値	意味
`LAYA_DEVICE`	自動	PyTorch に渡すデバイス値。`cpu` や `cuda` など。
`LAYA_PRELOAD`	`1`	起動時に設定済みのチェックポイントを構築します。`0` で遅延読み込み。
`LAYA_MODELS`	`english,multilingual`	プリロードするチェックポイントのカンマ区切り。空の値は、すべてのチェックポイントをプリロードするのではなく MCP の既定を保ちます。
`LAYA_THREADS`	PyTorch の既定値	CPU 推論の Torch 演算内スレッド数を制限します。物理コア数以下に保ってください。
`LAYA_AUTO_TASK`	`0`	`1` にすると、リクエストが `typed-decisions` チェックポイントへ自動ルーティングできるようになります。意味は `laya.serve` と同じです。そのチェックポイントはプリロードしないので、起動時に何を構築するかは `LAYA_MODELS` が引き続き決めます。

標準の laya-mcp-server ランチャーは、フックをインストールせずに Router を作ります。予測フックが必要なら、サーバーが Router を構築する前にそれらをインストールする独自のランチャーを使ってください（たとえば laya.hooks.set_default_hooks を使います）。上の環境変数はモデルのライフサイクルを設定するもので、フックの登録ではありません。いつツールを呼ぶか、返された判断をどう扱うかは、引き続きクライアントが決めます。

3. 共有される境界と関連ガイド

CLI と MCP サーバーは、同じ型付き意思決定エンジンへのインターフェースです：

有限のラベル集合には choice、順序付きのルーブリックには score、「真」の確率には noul を使います。
しきい値とプリセットは代表的なデータで検証してください。万能の採用しきい値はありません。
不可逆または高コストのアクションは、アプリケーションのレビューとフォールバック方針の後ろに置いてください。
MCP サーバーは Router.predict を呼ぶので、独自ランチャーがフックをインストールしていればそれらが発火します。可観測性と run_id の相関については、予測フック、フックのライフサイクル、トレーシングを参照してください。

このガイドはローカルの CLI と組み込みの MCP stdio サーバーを扱います。HTTP API、コミュニティのラッパー、MCP プロトコルの再設計は扱いません。