huawei-cloud-cloudrobo-infer

Windows / PowerShell： 例では bash 構文を使用しています。Windows PowerShell で実行するには：

• \ による行継続を1行にまとめるか、行末にバッククォートを付けてください。
• export NAME="value" の代わりに $env:NAME="value" で環境変数を設定してください。
• シングルクォートで囲んだ JSON '{"a":"b"}' はそのまま使えます。

概要

cloudrobo-infer スキルは、CloudRobo の推論サービス（モデルサービング／推論サービスとも呼ばれます）のライフサイクル全体を管理します。--model-json JSON オブジェクトとして渡された model_id と model_version_id で特定されるモデルを、長時間稼働する推論サービスにデプロイし、そのサービスの監視と運用（起動／停止／更新／削除／ログ）を行えます。また、wait-deploy を使ってサービスのステータスが DEPLOYING でなくなるまでポーリングし（status != "DEPLOYING"）、その時点の別の状態（例：RUNNING、FAILED、STOPPED）を返せます。

注：wait-deploy は DEPLOYING フェーズのみを待機します。CREATING の間は待機しません。 正確な動作については、Wait-Deploy のリファレンスを参照してください。

適用シナリオ：

• モデルのデプロイ — モデルを推論サービスとしてデプロイします（create → wait-deploy）
• Wait-Deploy — サービスのステータスが DEPLOYING でなくなるまで5秒ごとにポーリングします（間隔5秒、デフォルト600秒）
• サービスの運用・保守 — デプロイ済みサービスの一覧表示、詳細表示、設定更新、起動／停止を行います
• ログの診断 — ミリ秒単位の時間範囲とキーワードフィルターを使って list-logs を実行します
• スキル間のオーケストレーション — cloudrobo-train がエクスポートしたモデルを利用し、具現化タスク向けに robo-dispatcher へサービスを公開します（infer_service_id 経由）。

アーキテクチャ：

Agent / LLM
    │
    ├── CLI  →  cloudrobo infer <command>
    └── SDK  →  InferClient (Python)
                    │
                    ▼
              cloudrobo-service (REST API)
              /v1/infer-services/*

すべての操作は cloudrobo-service バックエンドを対象とし、有効な workspace_id が必要です（明示的に指定しない場合はデフォルトのワークスペースが使用されます）。サービスのデプロイではコンピューティング（プール）リソースを消費するため、長時間稼働するサービスを開始する前に必ず確認してください。

前提条件

• CLI のインストール、AK/SK 認証、ワークスペースの設定については、references/cli-installation-guide.md を参照してください。
• 有効な workspace_id（cloudrobo workspace current または list + use で解決します）。
• デプロイ可能なモデル：model_id（=asset_id）+ model_version_id（=latest_version_id）を、単一の --model-json 引数として create に渡します： --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>"}'。 モデルの show-asset 出力で、ONLINE_DEPLOYMENT アクションの status が "ENABLE" である必要があります。DRAFT／CREATING ステータスのモデルはデプロイできません（403 エラー）。
• コンピューティングプール：pool_id（resource_id に pool- を付けたもの、つまり pool-<resource_id>）+ pool_type + flavor。cloudrobo resource list-pools --resource-type MODELARTS で確認します。status: "AVAILABLE" のプールのみ使用できます。
• create では --stop-schedule-json が実質的に必須です（CLI での必須指定ではありません）。 形式：{"duration": <N>, "time_unit": "MINUTES"}。

ワークフロー

自然言語優先の原則

以下の各ワークフローは、手動での CLI／SDK オーケストレーションではなく、ユーザーの意図（1～2文）から始まります。その後、スキルが該当するコマンドチェーンを実行し、状態のフィードバック（ステータスの変化、ポーリングの進捗）を報告します。

モデルのデプロイワークフロー（対話形式のパラメーター解決）

シナリオ：「推論サービスを作成したい」／「モデル X を推論サービスとしてデプロイしてください。」

基本原則：必要なパラメーターをそれぞれ確認 → 選択肢を提示 → ユーザーに選んでもらう → 完全なコマンドを組み立てる → 実行する。

1. ワークスペースを解決する — cloudrobo workspace current。

   • デフォルトのワークスペースが設定されている場合 → workspace_id と asset_catalog_id をそのまま使います。
   • 設定されていない場合 → cloudrobo workspace list → ワークスペース名と ID をユーザーに提示 → cloudrobo workspace use --workspace-id <id> → current を再実行して確認します。

2. モデルのソースとタイプを確認する — 次の順序で、ユーザーに2つの質問をします。

   • ソース（どこを検索するか。最初に質問）：具身广场（具身广场）、ワークスペースアセット （空间资产）、またはカスタム（自定义）。ソースによって、以下のパラメーターの方針がすべて決まります — 具身广场のモデルはプラットフォームで事前設定されているため、必須のコアパラメーターのみを指定する必要があります。ワークスペースアセット／カスタムモデルでは、自動検出フローを実行します。
   • タイプ（ext_metadata.model_type に基づく。2番目に質問）：知覚（感知）、vln（導航）、 vla（操作）、計画（规划）。
   • ユーザーの指定が曖昧な場合（例：「so101 関連のモデル」）→ 両方の質問を省略し、 search-assets でキーワードをグローバル検索します。
   • ソースが判明したら、create を組み立てる前に、すぐに該当するパラメーター方針へ進みます。 Model Source → Parameter Policy の表を参照してください。

3. モデルを検索する — ユーザーの選択に基づいて検索します。

   • 具身广场：cloudrobo asset list-publication-assets --type model --actions ONLINE_DEPLOYMENT --action-status ENABLE（オンラインデプロイが有効な RELEASE モデルを返します）。
   • ワークスペースアセット：cloudrobo asset list-assets --catalog-id <asset_catalog_id> --type model（注：ワークスペースの --catalog-id を使用してください。--repository-id は使用しないでください）。
   • キーワード検索：cloudrobo asset search-assets --keyword "<keyword>" --type model。
   • 該当するモデル（名前、asset_id、ステータス、model_type）をユーザーに提示し、選択してもらいます。

4. モデルのバージョンを解決する — cloudrobo asset show-asset --asset-id <asset_id>。

   • latest_version_id を使用して、--model-json の model_version_id フィールドに設定します。
   • version_count > 1 の場合 → cloudrobo asset list-versions --asset-id <id> → ユーザーに選択してもらいます。
   • デプロイ可能か確認する：actions 配列を確認します — ONLINE_DEPLOYMENT の status: "ENABLE" が必要です。DISABLE の場合、モデルはデプロイできません（403 エラー）。
   • モデルのステータスを確認する：ステータスは RELEASE（广场）または公開済み状態である必要があります。 DRAFT／CREATING モデルは 403 "Model asset permission deny" で拒否されます。

5. デプロイパラメーターを自動検出する — ワークスペースアセット／カスタムモデルのみ。 具身广场のモデル（具身广场）では、この手順全体を省略し、以下のパラメーターを一切指定しないでください（ここに記載されているもの、および --cmd／--image-swr-url／--envs-json／ --skill-config-json／--service-invoke-json／--readiness-health-json／--model-ext-metadata／ --model-json.mount_path に関するものも含みます）。 广场モデルはプラットフォームで事前設定されており、オーケストレーション、イメージ、環境変数、スキル、ヘルスプローブ、r2c マッピングがすでにモデルに紐付けられています。广场モデルにこれらの追加パラメーターを渡すと、デプロイが無効になったり、設定の不一致が発生したりするおそれがあります。これは、このワークフローで禁止されている「不该带的参数」そのものです。

   ワークスペースアセット／カスタムモデル：モデルのバージョンを解決した後、デプロイパラメーターを提供する関連アルゴリズムアセットがモデルにあるかどうかを確認します。これらはモデルのアルゴリズムアセットと設定ファイルから自動検出されます。

   a. ONLINE_DEPLOYMENT アクションを確認する — ステップ 4 の show-asset 出力で、 actions[] 内の type: "ONLINE_DEPLOYMENT" を確認します。存在し、 status: "ENABLE" の場合、関連アルゴリズムアセットを示す algorithm.asset_id と algorithm.version_id が含まれています。 b. アルゴリズムアセットを照会（アクションが見つかった場合）— cloudrobo asset show-asset --asset-id <algorithm.asset_id> を実行し、続けて cloudrobo asset show-version --asset-id <algorithm.asset_id> --version-id <algorithm.version_id> を実行して、アルゴリズムの ext_metadata を取得します：

   • ext_metadata.command → --cmd
   • ext_metadata.engine.image_url → --image-swr-url
   • ext_metadata.environment_variables（{"name":"K","default":"V"} の配列） → マップ {"K":"V"} に変換 → --envs-json
   • ext_metadata.deployment_config.model_mount_path → --model-json.mount_path
   • ext_metadata.deployment_config.service_invoke → --service-invoke-json
   • ext_metadata.deployment_config.readiness_health → --readiness-health-json

   c. skill_config.json をダウンロード — download-url API 経由で行います（CLI/SDK ではラップされていないため、HttpClient を直接使用します）：

   from cloudrobo_core.sdk import Config, HttpClient
   from cloudrobo_asset.client import AssetClient
   import requests
   
   config = Config()
   http = HttpClient(config)
   asset_client = AssetClient(http)
   
   resp = http.get(
       asset_client._url(f'/v1/assets/{asset_id}/versions/{version_id}/download-url'),
       params={'file_name': 'skill_config.json'}
   )
   skill_config = requests.get(resp['file_url']).text
   

   • スキル項目を name と prompt のフィールドのみに絞り込みます（追加フィールドの priority／ description は削除します）→ --skill-config-json
   • strict フィールド：デプロイされたサービスが、事前定義されたスキルプロンプトのみを受け付けるか、ユーザー独自のプロンプトも受け付けるかを制御します：
     • strict: true — サービスは事前定義されたスキル（name で照合）のみを受け付けます。ユーザーは実行時にカスタムプロンプトを入力できません
     • strict: false または省略 — サービスは事前定義されたスキルに加えて、ユーザーが実行時に独自のカスタムプロンプトを入力することも許可します
     • 顧客がカスタムプロンプトを利用できるようにする場合は、skill_config.json で strict が false に設定されているか、指定されていないことを確認します

   d. r2c 設定をダウンロード — 同じ download-url API を使用し、次のフォールバックルールに従います：

   • まず file_name=r2c_config.yaml を試します
   • 失敗した場合（404）、file_name=r2c.json を試します
   • どちらも失敗した場合（r2c 設定ファイルが見つからない場合）：
     • ユーザーに、独自の r2c 設定ファイルを提供するかどうか確認します
     • --model-ext-metadata がなくてもデプロイは妨げられませんが、その後の robo-dispatcher 操作が機能しなくなることを説明します（robo-dispatcher ワークフローの詳細は huawei-cloud-cloudrobo-dispatch スキルを参照してください）
     • ユーザーが設定ファイルを提供した場合は、その内容を --model-ext-metadata として使用します
     • ユーザーが提供しない場合は、--model-ext-metadata なしで進めます（robo-dispatcher 操作は利用できないことを警告します）
   • ファイルの内容（生の文字列）→ --model-ext-metadata

   優先順位：設定ファイル > ext_metadata フィールド > ユーザーへの確認。パラメーターを 特定できない場合は、黙ってスキップします（デプロイを妨げないでください）。アルゴリズムが関連付けられていない 「ベア」モデルの場合は、任意のパラメーターを手動で指定するかどうかをユーザーに確認します。

6. プールとフレーバーを解決 — cloudrobo resource list-pools --resource-type MODELARTS。

   • 利用可能なプール（resource_name、pool_type、status、flavors）をユーザーに提示します。
   • status: "AVAILABLE" のプールのみ使用できます。
   • プールのフィールド：resource_id → --pool-id（pool- を先頭に付けます。例： pool-d1cc6d45-...）、pool_type → --pool-type（選択肢：DEDICATED／SHARED）。
   • フレーバーは、ハードウェアタイプ（CPU/GPU/ASCEND）ごとに分類された config.flavor の下にあります。
   • ユーザーにプールとフレーバー文字列（例："1 * SNT9B2 | 24 vCPUs | 192 GiB"）を選択してもらいます。

7. パラメーターを確認してデプロイする — ユーザーに create コマンドを提示します。Step 2 のモデルソースに合ったバリアントを選択してください（モデルソース → パラメーターポリシーの表を参照）。2 つのバリアントを混在させてはいけません。

   バリアント A — embodiment plaza モデル（具身广场、必須のコアパラメーターのみ）：

   cloudrobo infer create --name <service-name> --flavor "<flavor>" --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>"}' --workspace-id <workspace_id> --pool-id pool-<resource_id> --pool-type <pool_type> --stop-schedule-json '{"duration": 60, "time_unit": "MINUTES"}' [--dry-run]
   

   • --cmd／--image-swr-url／--envs-json／--skill-config-json／ --service-invoke-json／--readiness-health-json／--model-ext-metadata／--model-json.mount_path は追加しないでください。 Plaza モデルはプラットフォーム上で事前設定されています。これらの余分なパラメーターを指定するとデプロイのリスクとなり、このワークフローでは明示的に禁止されています。

   バリアント B — space asset／カスタムモデル（自動検出されたパラメーターを使用）：

   cloudrobo infer create --name <service-name> --flavor "<flavor>" --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>", "mount_path": "<mount_path>"}' --workspace-id <workspace_id> --pool-id pool-<resource_id> --pool-type <pool_type> --stop-schedule-json '{"duration": 60, "time_unit": "MINUTES"}' [--cmd "<command>"] [--image-swr-url "<image_url>"] [--envs-json '{"KEY":"VALUE"}'] [--skill-config-json '{"skills":[{"name":"...","prompt":"..."}],"strict":true}'] [--service-invoke-json '{"auth_type":"...","port":8080,"protocol":"HTTP"}'] [--readiness-health-json '{"path":"/ready","port":8080}'] [--model-ext-metadata '<r2c_config_file_content>'] [--dry-run]
   

   • 実際に検出されたパラメーター（Step 5）のみを含め、検出されていないものは省略してください。
   • --model-json.mount_path は、アルゴリズムの deployment_config に指定されている場合にのみ含めてください。
   • --envs-json はアセットの配列形式からマップ形式に変換する必要があります。
   • --skill-config-json のスキル項目には name と prompt のみを残し、priority と description は削除してください。
   • --model-ext-metadata にはファイルの生の内容（文字列）を指定します。
   • パラメーターの組み立てを検証するため、最初に --dry-run を実行することを推奨します。
   • --stop-schedule-json は CLI では必須ではありませんが、実際には必須です。指定しないとバックエンドが作成を拒否する場合があります。形式：{"duration": <N>, "time_unit": "MINUTES"}。
   • dry-run が成功したら、ユーザーに確認してから --dry-run を付けずに実行してください。
   • 返された service_id を記録します。

8. デプロイを待機する — cloudrobo infer wait-deploy --service-id <sid> を実行し、ステータスが DEPLOYING ではなくなるまで（status != "DEPLOYING"）5 秒ごとにポーリングします。その後のステータス（例：RUNNING、FAILED）を返します。

   • create の後、サービスは自動的に CREATING → DEPLOYING に移行します。create の直後に start を呼び出さないでください。「Status DEPLOYING does not support start」という 400 エラーが返されます。
   • start は STOPPED 状態のサービスの再起動にのみ使用し、初回デプロイには使用しません。
   • 正確な動作：wait-deploy は status != "DEPLOYING" になった時点で返ります。CREATING フェーズ中は待機しません。サービスがまだ CREATING の間に呼び出すと、CREATING のステータスですぐに返ります。実際には create の後に呼び出し、バックエンドが CREATING → DEPLOYING → RUNNING と遷移するのを待ちます。このヘルパーは DEPLOYING の間、処理をブロックします。

9. 結果を報告する — service_id、モデル名、フレーバー、最終ステータスを出力します。

   • ステータスが FAILED の場合は、診断のために cloudrobo infer list-logs を実行します。
   • 失敗したサービスを自動削除してはいけません。クリーンアップが必要な場合は、delete コマンドを提示し、実行前にユーザーの明示的な確認を求めてください。

アセットに関する注意：model_id／version_id／flavor／pool_id は、上記のクエリコマンドで動的に解決する必要があります。ハードコードしてはいけません。必ずクエリ結果の選択肢からユーザーに選んでもらってください。

モデルソース → パラメーターポリシー（正式な判断表）

この表は、Step 2 で解決したモデルソースに基づいて、どの create パラメーターを引き継ぐかを決める唯一の信頼できる情報源です。両方のスキルの整合性を保つため、cloudrobo-model-workflow の Stage 3 で参照されます。推論サービスを作成する際は、まずモデルソースを解決してから、該当する列を正確に適用してください。異なるパターンを混在させないでください。

モデルソース（Step 2 より）	検索コマンド（Step 3）	自動検出（Step 5）	引き継ぐ create パラメーター
具身広場（Embodiment plaza）	asset list-publication-assets --type model --actions ONLINE_DEPLOYMENT --action-status ENABLE	完全にスキップ — モデルはプラットフォーム上で事前設定済みです	必須のコア項目のみ：--name、--flavor、--model-json（model_id+model_version_id）、--workspace-id、--pool-id、--pool-type、--stop-schedule-json。引き継がないこと：--cmd/--image-swr-url/--envs-json/--skill-config-json/--service-invoke-json/--readiness-health-json/--model-ext-metadata/--model-json.mount_path
Space asset / カスタム（空间资产/自定义）	asset list-assets --catalog-id <asset_catalog_id> --type model / search-assets --keyword ...	Step 5 をすべて実行 — アルゴリズムアセットを照会（cmd/image/envs/mount_path/service-invoke/readiness-health）＋ skill_config.json をダウンロード＋ r2c 設定	必須のコア項目に加えて、Step 5 で実際に検出されたすべてのパラメーター。検出されなかった項目は黙って省略します
不明なモデル ID（ユーザーが明示的な ID を指定）	asset show-asset --asset-id <id>	show-asset の結果に基づいて判断：モデルにプラットフォームアルゴリズムを示す ONLINE_DEPLOYMENT アクションがある場合 → Space asset の手順として扱う（Step 5 を実行）。モデルのデプロイ設定が自己完結型／事前設定済みの場合 → 必須のコア項目のみ引き継ぐ	解決した手順に従う

理由：具身広場のモデルには、オーケストレーション、イメージ、環境変数、ヘルスプローブ、スキル、r2c の機能マッピングがプラットフォーム上にまとめられています。具身広場のモデルに対して、これらを create で再指定するのは冗長であり、無効または不整合なデプロイにつながるおそれがあります（これは「不该带的参数不要带」というルールです）。Space asset / カスタムモデルにはこのような設定がまとめられていないため、パラメーターを自動検出し、明示的に渡す必要があります。

デプロイ完了待機ワークフロー（CLI の利便性機能）

シナリオ：「この推論サービスのデプロイが完了するまで待ちます。」

1. cloudrobo infer wait-deploy --service-id <sid> [--timeout 600]
   • wait-deploy はCLI クライアント側のポーリングヘルパーです。サービスの状態が DEPLOYING でなくなる（status != "DEPLOYING"）まで 5 秒ごとに show をポーリングし、他の状態（例：RUNNING、FAILED、STOPPED）を返します。
   • タイムアウトのデフォルトは 600s です（CLI の --timeout の範囲は 1～3600）。タイムアウトを超えると、クライアントは RuntimeError を発生させ、CLI はタイムアウトエラー（JSON エラー＋ClickException、終了コードは 0 以外）を報告します。
2. 結果の報告 — 最終状態を報告します。FAILED の場合は、原因を調べるため list-logs を提案します。

注：wait-deploy はサービスを作成しません。先に create を呼び出してから、wait-deploy を実行してください。 create の後に start を呼び出さないでください — サービスは自動的にデプロイされます（CREATING → DEPLOYING → RUNNING）。 start は STOPPED 状態のサービスを再起動する場合にのみ使用します。

サービスの運用・保守／検索ワークフロー（モジュール＋ワークスペース）

シナリオ：「ワークスペースで実行中の推論サービスを確認したい。」

1. ページネーション（--limit/--offset）と並べ替え（--sort-key/--sort-dir）を指定して、cloudrobo infer list --workspace-id <ws> [--status <status>] [--model-id <mid>] [--name <name>] [--model-name <mn>] [--model-version-id <mvid>] [--model-version-name <mvn>] [--user-name <un>] [--user-id <uid>] を実行します。
2. 完全な設定スナップショットを確認するには、cloudrobo infer show --service-id <sid> を実行します。
3. 状態と主要なフィールド（モデル、フレーバー、状態、プール）を報告します。

サービスの起動／停止ワークフロー（モジュール）

シナリオ：「この API の背後にある推論サービスを停止して。」／「再び起動して。」

1. show --service-id <sid> でサービスを確認します。
2. cloudrobo infer stop --service-id <sid> または cloudrobo infer start --service-id <sid> （変更を伴うため、実行前に確認してください）。
3. 目的の終端状態（STOPPED／RUNNING）になるまで show をポーリングします。

ログ診断ワークフロー（モジュール）

シナリオ：「デプロイしたサービスが失敗するのはなぜですか？ログを見せてください。」

1. cloudrobo infer list-logs --service-id <sid> --start-time <ms> --end-time <ms> — どちらの タイムスタンプもミリ秒（13 桁）です。必要に応じて --keywords、--limit、 --line-num、--is-count、--highlight、--is-desc で絞り込みます。
2. ログ行を確認し、show のステータス（例：CREATE_FAILED／START_FAILED）と照合します。
3. 対処方法を提案します（プールの容量、モデルアーティファクト、ヘルスチェックの設定）。

サービスの更新／削除ワークフロー（モジュール）

シナリオ：「このサービスを再設定して。」／「このサービスをシャットダウンして削除して。」

• 更新 — cloudrobo infer update --service-id <sid> [--description <desc>] [--model-ext-metadata <json>] [--dry-run]（変更を伴うため、確認してください）。
• 削除 — cloudrobo infer delete --service-id <sid> [--dry-run]（変更を伴い、元に戻せないため、確認してください）。

複合ワークフロー A — 学習済みモデルをデプロイする（infer + train + asset）

シナリオ：「VLA モデルを学習しました。推論サービスとしてデプロイしてください。」

1. ワークスペースを解決します：cloudrobo workspace current（または list + use）。
2. 学習済みモデルを検索します：cloudrobo asset list-assets --catalog-id <asset_catalog_id> --type model（または train スキルの output_models を使用）。asset_id を取得します。
3. モデルのバージョンを解決します：cloudrobo asset show-asset --asset-id <asset_id> → latest_version_id を --model-json の model_version_id フィールドに使用します。 ONLINE_DEPLOYMENT アクションの status: "ENABLE" を確認します。
4. プールとフレーバーを解決します：cloudrobo resource list-pools --resource-type MODELARTS → ユーザーに resource_id と flavor を選択してもらいます。 4a. 学習済みモデルはスペースアセットです → モデルデプロイワークフローの Variant B／スペースアセットのパスに従います。（学習済みモデルにアルゴリズムが関連付けられている場合）ステップ 5 に従ってデプロイ パラメーターを自動検出します — アルゴリズムアセットを照会して cmd/image/envs/service-invoke/readiness-health を取得し、skill_config.json と r2c config をダウンロードします。 これらを引き継ぐのがスペースアセットの正しい動作です。「引き継がない」というルールは embodiment plaza モデルにのみ適用されます。
5. cloudrobo infer create --name <name> --flavor "<flavor>" --model-json '{"model_id": "<asset_id>", "model_version_id": "<latest_version_id>"}' --workspace-id <ws> --pool-id pool-<resource_id> --pool-type <type> --stop-schedule-json '{"duration": 60, "time_unit": "MINUTES"}' — ステップ 4a で実際に検出したパラメーターを追加します（ステップ 7 の Variant B に従います）。
6. cloudrobo infer wait-deploy --service-id <sid> — ステータスが DEPLOYING でなくなるまで 5 秒ごとに ポーリングします（サービスは create の後に自動デプロイされます。start は呼び出さないでください — 400 エラーになります）。
7. service_id とステータスを報告します。サービスを利用できる状態です。

パラメーターの自動検出：スペースアセット／カスタムモデルの場合、デプロイパラメーター （cmd、image、envs、skill-config、health-checks、model-ext-metadata など）は、上記の ステップ 5 に従い、関連するアルゴリズムアセットと設定ファイルから 自動検出されます。検出元の一覧表、download-url API のコード、主なルールについては references/service-config-catalog.md →「パラメーターの自動検出元」を参照してください。

CLI コマンドの概要

cloudrobo infer <command> [OPTIONS]

サブコマンド	説明	主なオプション
create	新しい推論サービスをデプロイします	--name、--flavor、--model-json、--workspace-id、--pool-id、--pool-type、--stop-schedule-json
wait-deploy	デプロイが完了するまでポーリングします	--service-id、--timeout
list	推論サービスを一覧表示します	--workspace-id、--status、--limit、--offset
show	サービスの詳細を表示します	--service-id
start / stop	サービスを開始または停止します	--service-id
update	サービスの設定を更新します	--service-id、--description、--model-ext-metadata
delete	サービスを削除します	--service-id
list-logs	サービスのログを照会します	--service-id、--start-time（ミリ秒）、--end-time（ミリ秒）、--keywords

CLI／SDK の完全な例、パラメーター解決表、エッジケース：
references/service-config-catalog.md → 「Command Examples」、「Parameter
Resolution & Confirmation」、「Edge Cases」を参照してください。
SDK は9つのメソッド、CLI は9つのコマンドを公開しています（不足なし）。
wait-deploy は、CLI と SDK の両方で利用できるクライアント側のポーリングヘルパーです。
CLI が不便な場合（動的な JSON、パッケージをまたぐ照会など）は、Python
SDK を直接使用してください。InferClient は9つのメソッドを公開しています。

参考ドキュメント

• CLI インストールガイド — cloudrobo CLI のインストールと設定
• IAM ポリシー — 最小権限の認証情報およびアクセスモデル
• 検証方法 — 検証方法の詳細
• データフロー図 — Mermaid によるデータフロー図
• 受け入れ基準 — 受け入れ基準
• サービス設定リファレンス — InferServiceDto のフィールド、ヘルスチェック、ステータス、ログ、パラメーターの自動検出、CLI／SDK のコマンド例、パラメーター解決と確認、エッジケース、カバレッジマトリックス

エッジケース

シナリオ対応表の全容（model_id がない、JSON が無効、タイムスタンプの単位が誤っている、
403 権限拒否、500 内部エラー、stop-schedule がない、r2c 設定への
フォールバック、envs 形式の不一致、スキルをまたぐ呼び出しなど）については、
references/service-config-catalog.md → 「Edge Cases」を参照してください。

検証方法

仕様準拠の検証

bash scripts/test-cli-commands.sh

機能テスト

bash scripts/test-cli-commands.sh

テストケース

デプロイ、wait-deploy、サービスのライフサイクル、ログ、安全性のシナリオを網羅したテストケース一覧は、templates/test-vars.json を参照してください。

検証チェックリスト

• create の実行後、サービスが正しいステータスで list に表示される
• wait-deploy の実行後、サービスのステータスが DEPLOYING ではなくなる（status != "DEPLOYING"。タイムアウト／失敗時はログを確認する手順が報告される）
• start／stop の実行後、show に新しいステータスが反映される
• delete の実行後、show は見つからないことを返す
• ミリ秒単位のタイムスタンプを指定した list-logs でログ行が返され、キーワードフィルターが機能する
• 無効な JSON／パストラバーサルは拒否される。validate_safe_id により ../ はブロックされる
• 状態変更操作（特に start）では、ユーザーに確認を求める

ベストプラクティス

• 各createパラメーターはクエリーコマンドで解決してから、ユーザーに選択してもらいます。ハードコードはしないでください。
• モデルソースによってパラメーターポリシーが決まります：まずソースを解決し（ステップ2）、その後 モデルソース → パラメーターポリシーの表を適用します。Embodiment plaza のモデルには必須のコアパラメーターのみを指定します（--cmd／--image-swr-url／--envs-json／ --skill-config-json／--service-invoke-json／--readiness-health-json／--model-ext-metadata／ --model-json.mount_pathは指定しません）。スペースアセット／カスタムモデルではステップ5の自動検出を実行し、実際に検出された項目を指定します。
• モデル検索：デプロイ可能なplazaモデルにはlist-publication-assets --actions ONLINE_DEPLOYMENT --action-status ENABLE を優先して使います。ワークスペースモデルにはlist-assets --catalog-id <id>を使います。 あいまい検索／キーワード検索にはsearch-assets --keyword "<kw>"を使います。
• --model-jsonのmodel_version_idには、actions[].algorithm.version_idではなく、show-assetのlatest_version_idを指定する必要があります。
• createでは必ず--stop-schedule-json '{"duration": N, "time_unit": "MINUTES"}'を指定します。
• createの後はwait-deployを使い、デプロイが完了するまでポーリングします（間隔は5秒、デフォルトは600秒）。createの後にstartを呼び出さないでください。サービスは自動でデプロイされます。
• wait-deployはstatus != "DEPLOYING"になると戻ります。ブロックするのはDEPLOYINGフェーズのみ（CREATINGではありません）です。そのため、createの後に呼び出し、バックエンドでCREATING → DEPLOYING → RUNNINGへ遷移させます。まだCREATINGの状態で戻った場合は、すぐにwait-deployを再度呼び出してください。
• 実際に送信する前にパラメーターの組み立てを検証するには、createで--dry-runを使います。
• デプロイの検証の一環として、ヘルスチェックによる検出結果を報告します。
• エラーをすばやく特定するには、--keywordsを指定してlist-logsを使います。タイムスタンプの単位はmsであることに注意してください。
• ユーザーが外部へのアクセスを明示的に必要としている場合を除き、internet_access_enableはOFFのままにします。
• 機密性の高い環境変数／値はマスキングし、認証情報を表示しないでください。
• ワークスペース／モデルのコンテキストを解決するには、ワークスペース（cloudrobo workspace current）およびアセットのスキルと組み合わせます。身体性タスクを実行するには、ディスパッチ機能と組み合わせます。