huawei-cloud-cloudrobo-model-workflow

CloudRobo モデル開発オーケストレーションワークフロー

パイプラインをオーケストレーションします：アセットの検索 → モデルのトレーニング → 推論のデプロイ → 実機評価 → 結果の出力。全工程で CLI コマンドを使用してください。Python SDK の使用は禁止です。

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

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

---

概要

パイプラインのステージ

Stage 0: Use Case Parsing      → Extract robot type + task, select model; parse dataset source
Stage 1: Asset Query & Dataset → Query model/algorithm/dataset assets; get default hyperparams and confirm; OpenPI model constructs data.rename_map
Stage 2: Model Training        → CLI create-task creates training task, poll until complete
Stage 3: Inference Deployment  → CLI infer create deploys inference service
Stage 4: Real-Robot Evaluation → CLI dispatch create-task dispatches task to real robot (session_id=workspace_id, no session creation needed)
Stage 5: Result Output         → Output evaluation score and report

実行モード

モード	ユーザーの意図の例	ステージ
フルパイプライン	"用 so101 训练插笔任务并评测"	Stage 0→5
トレーニング＋デプロイ	"训练完帮我部署推理服务"	Stage 0→3
デプロイ＋評価	"我模型训练好了，帮我部署评测"	Stage 3→5

ステージ間の依存関係はスキップできません：評価には推論サービスが RUNNING であること、デプロイにはトレーニングが FINISHED であること、トレーニングにはアセット情報が必要です。中間ステージから開始する場合、ユーザーは先行するステージの出力パラメーターを指定する必要があります。

ステージをスキップする場合の入力要件

開始ステージ	ユーザーが指定する情報	プロンプト
Stage 2	base_model_asset_id、dataset_asset_id	"ベースモデルの asset_id とデータセットの asset_id を指定してください"
Stage 3	output_model_asset_id、output_model_version_id	"トレーニング出力モデルの asset_id と version_id を指定してください"
Stage 4	service_id	"推論サービスの service_id を指定してください"

データフローの契約

送信元 → 送信先	引き継ぐ値
Stage 0 → 1	model_keyword、dataset_source、dataset_value、robot_type
Stage 1 → 2	base_model_asset_id/version_id、algorithm_asset_id/version_id、train_method、default_hyperparams、dataset_asset_id/version_id、data.rename_map（OpenPI のみ）
Stage 2 → 3	output_model_asset_id、output_model_version_id
Stage 3 → 4	service_id
Stage 4 → 5	robot_id、task_id、task_status、task_result

---

前提条件

1. cloudrobo CLI がインストールされ、認証済みであること（HUAWEI_CLOUD_AK / HUAWEI_CLOUD_SK）
2. cloudrobo workspace use <id> で workspace_id を設定していること
3. マーケットプレイスでベースモデルのアセットを利用できること
4. ユーザーが提供するデータセット：登録済みアセット、OBS パス、またはローカルディレクトリ
5. 実機が登録済みでオンラインであること

Windows/PowerShell に関する注意： PowerShell では | や " などの特殊文字を含む JSON の解析に問題があります。複雑な JSON パラメーターを渡す場合は、JSON を一時ファイルに書き込み、Python の subprocess を使って CLI を呼び出してください（これは SDK ではなく、PowerShell のエンコード問題を回避して CLI を動作させるための Python ラッパーです）。references/cli-installation-guide.md を参照してください。

---

ワークフロー

Stage 0：ユースケースの解析

ユーザーの入力から、ロボットの種類、タスクの説明、データセットのソースを抽出します。

モデルの選択

ユーザーがモデルを指定した場合 → そのモデルを使用します。

ユーザーがモデルを指定しない場合 → マーケットプレイスのプリセットモデルを検索し、質問ツールを使ってユーザーに確認します：

cloudrobo asset list-publication-assets --type model

• 利用可能なすべてのプリセットモデルを一覧表示し、推奨モデルに「（推奨）」を付けます
• 推奨モデルをユーザーに確認せず選択してはいけません。ユーザーが ACT、DP、またはほかのモデルを希望する場合があります

ロボットから推奨モデルへのマッピング

ロボット	推奨モデル
so101 / jaka / franka / general	LeRobot_PI05-Base

データセットソースの解析

ユーザーの入力	タイプ	処理
アセット名／asset_id	user_specified	Stage 1 でこのアセットを検索します
OBS パス obs://	obs_path	Stage 1 でアセットとして登録します
ローカルディレクトリのパス	local_path	Stage 1 で OBS にアップロードし、登録します
未指定	need_ask	必ずユーザーに確認してください

Stage 1：アセットの検索とデータセットの処理

ステップ 1.1：ベースモデルへの問い合わせとアルゴリズム情報の抽出

cloudrobo asset search-assets --keyword "<model_keyword>"

結果から次の情報を抽出します：

• id → base_model_asset_id
• latest_version_id → base_model_version_id
• actions[].action → train_method（例：FFT、LORA）
• actions[].algorithm.asset_id → algorithm_asset_id
• actions[].algorithm.version_id → algorithm_version_id

train_method はモデルの actions[].action（例：FFT、LORA）から取得します。SFT／QLORAではありません。デフォルトは FFT です。ユーザーが LoRA をリクエストした場合は LORA を使用します。

ステップ 1.1b：アルゴリズムアセットの詳細を照会（デフォルトのハイパーパラメーターを取得）

cloudrobo asset show-asset --asset-id <algorithm_asset_id>

ext_metadata.hyperparams からデフォルトのハイパーパラメーターを抽出します。各ハイパーパラメーターには、name、default、constraint.type、constraint.editable、description があります。

ステップ 1.1c：ハイパーパラメーターの確認とカスタマイズ（必ず実行）

デフォルトのハイパーパラメーターを取得した後、必ず質問ツールを使って変更するかどうかをユーザーに尋ねます：

1. デフォルトのハイパーパラメーターを表（name、default、description）で表示します
2. 選択肢を提示します：「デフォルトのハイパーパラメーターを使用」（推奨）／「一部のハイパーパラメーターをカスタマイズ」
3. ユーザーがカスタマイズを選んだ場合は、デフォルト値をベースに、指定されたキーを上書きし、残りはデフォルトのままにします

重要：このステップは省略できません。ユーザーがデフォルト値を選んだ場合も、明示的に確認する必要があります。 パラメーターキーの捏造は禁止です：すべてのキーは、アルゴリズムの ext_metadata.hyperparams の name フィールドから取得する必要があります。

ステップ 1.1d：OpenPI モデルの data.rename_map の構築（OpenPI のみ）

適用対象：ベースモデルが Physical-Intelligence_PI0-Base または Physical-Intelligence_PI05-Base の場合に実行します。それ以外のモデルでは省略します。

構築の詳細については、references/openpi-rename-map.md を参照してください。

ステップ 1.2：ユーザーのデータセットを処理

ケース A：登録済みアセット

cloudrobo asset search-assets --keyword "<dataset_name_or_id>"

id → dataset_asset_id、latest_version_id → dataset_version_id を抽出します。

ケース B：OBS パス

cloudrobo workspace current  # Get asset_catalog_id
cloudrobo asset create-asset --catalog-id <catalog_id> --name "<dataset_name>" --type dataset --ext-metadata '{"annotation_status":true}'
cloudrobo asset create-version --asset-id <asset_id> --url "<obs_path>"
cloudrobo asset update-version --asset-id <asset_id> --version-id <version_id> --status RELEASE

ケース C：ローカルディレクトリ

cloudrobo workspace current  # Get asset_catalog_id
cloudrobo asset import-asset --catalog-id <catalog_id> --type dataset --local-path <local_dir_path> --name <dataset_name>
cloudrobo asset update-version --asset-id <asset_id> --version-id <version_id> --status RELEASE

重要：import-asset では、ローカルディレクトリに ext_metadata.annotation_status: true を含む YAML フロントマター付きの README.md が必要です。 重要：import-asset の後、データセットのバージョンステータスは CREATING になります。手動で RELEASE として公開する必要があります。そうしないと、トレーニングで「データセットの準備ができていません」と報告されます。

ケース D：未指定 — 質問ツールを使ってデータセットのソースをユーザーに尋ねます。

ステージ 2：モデルのトレーニング

全工程で CLI を使用します。cloudrobo train create-task --config <JSON> は完全な設定 JSON を受け付けます。 名前の一意性：name と output_models[0].model_name はグローバルに一意である必要があります。タイムスタンプのサフィックスを使用してください。

ステップ 2.1：トレーニング設定 JSON を構築

PowerShell の特殊文字に関する問題を避けるため、設定 JSON を一時ファイルに書き込みます：

{
  "name": "so101-pen-train-<timestamp>",
  "train_mode": "MODEL_TUNING",
  "train_method": "FFT",
  "algorithm": {
    "algorithm_asset_id": "<algorithm_asset_id>",
    "algorithm_version_id": "<algorithm_version_id>"
  },
  "input_models": [{
    "model_asset_id": "<base_model_asset_id>",
    "version_id": "<base_model_version_id>",
    "source_type": "PUBLIC_MODEL_ASSET"
  }],
  "datasets": [{
    "source_type": "CUSTOM_DATASET_ASSET",
    "dataset_asset_id": "<dataset_asset_id>",
    "version_id": "<dataset_version_id>", 
    "dataset_name": "<dataset_name>"
  }],
  "output_models": [{
    "model_name": "so101-pen-output-<timestamp>",
    "model_type": "vla",
    "save_mode": "NEW_MODEL",
    "strict": false
  }],
  "spec": "Ascend: 1 * SNT9B2 | 24 vCPUs | 192 GiB",
  "cluster_id": "<cluster_id_from_stage1>",
  "workspace_id": "<workspace_id>",
  "parameters": "[{\"key\":\"batch_size\",\"desc\":\"批次大小\",\"value\":\"64\",\"constraint\":{\"type\":\"Integer\",\"editable\":true,\"required\":true,\"sensitive\":false}},{\"key\":\"steps\",\"desc\":\"训练步数\",\"value\":\"100000\",\"constraint\":{\"type\":\"Integer\",\"editable\":true,\"required\":true,\"sensitive\":false}},...]", 
  "env": "[]"
}

必須フィールド：name（一意）、train_mode（固定値 MODEL_TUNING）、train_method（モデルの actions から取得）、algorithm、input_models[0].source_type（PUBLIC_MODEL_ASSET）、output_models[0].model_name（一意）、output_models[0].model_type（固定値 vla）、spec（文字列）、cluster_id（pool- プレフィックス付きのプール ID）、parameters（ステップ 1.1c の完全な形式の JSON 配列文字列）。

parameters の構築：アルゴリズムの ext_metadata.hyperparams から、アセットの照会結果の desc と constraint を保持した完全な形式の配列を構築します：

parameters = [
    {
        "key": hp["name"],
        "desc": hp.get("desc") or hp.get("description", ""),
        "value": str(custom_overrides.get(hp["name"], hp["default"])),
        "constraint": hp.get("constraint", {})
    }
    for hp in hyperparams
]
# Serialize to JSON string for the config
parameters_str = json.dumps(parameters, ensure_ascii=False)

完全な形式が必須です：各パラメーター項目には key、desc、value、constraint を含める必要があります。desc と constraint はアルゴリズムアセットの ext_metadata.hyperparams の照会結果からそのまま取得してください。捏造したり省略したりしないでください。 OpenPI の data.rename_map：default の値は、すでにシングルクォートで囲まれた JSON 文字列形式です。default の値をそのまま使用してください。カスタムマッピングについては、references/openpi-rename-map.md を参照してください。

リソース仕様：シングルカードは Ascend: 1 * SNT9B2 | 24 vCPUs | 192 GiB、デュアルカードは Ascend: 2 * SNT9B2 | 48 vCPUs | 384 GiB です。Ascend-910B ではなく、SNT9B2 チップを使用してください。

ステップ 2.2：トレーニングタスクを送信

import subprocess
with open("train_config.json", "r", encoding="utf-8") as f:
    config = f.read().strip()
result = subprocess.run(
    ["cloudrobo", "train", "create-task", "--config", config, "-v"],
    capture_output=True
)
print(result.stdout.decode("utf-8", errors="replace"))

{"task_id": "<task_id>"} が返されます。

ステップ 2.3：トレーニング状況を照会する

cloudrobo train show-task --task-id <task_id>

• FINISHED → ステージ 3 に進みます
• FAILED／CREATE_FAILED／SUBMIT_FAILED → references/fault-recovery.md を参照してください
• WAITING／RUNNING／PENDING → ポーリングを続けます

cloudrobo train get-stages --task-id <task_id>  # View training stages

ステージの流れ：scheduling → preparing → running → end

ステップ 2.4：トレーニング出力モデルを抽出する

output_models は、タスク作成時に model_asset_id と version_id を返します（プラットフォームが事前に作成します）。show-task の結果から取得してください。モデルファイルはトレーニングが FINISHED になった後に利用可能になります。

ステージ 3：推論のデプロイ

全工程で CLI を使用します cloudrobo infer create。 モデルソースのポリシー：ここでデプロイするモデルは、トレーニング出力であるスペースアセット （空间资产）です。そのため、cloudrobo-infer スキルの 「モデルソース → パラメータポリシー」テーブルのスペースアセット／バリアント B の手順が適用されます。 パラメータ（model-ext-metadata、 skill-config-json）は必須であり、明示的に構成します。 これは実体プラザのモデルではありません。ここでは実体プラザの「コアパラメータのみ」の ルールを適用しないでください。このワークフロー内で実体プラザから直接モデルをデプロイするようユーザーから求められた場合は、 代わりに cloudrobo-infer スキルのモデルデプロイワークフロー、バリアント A に従ってください （必須のコアパラメータのみ）。正式な判断基準として、cloudrobo-infer の SKILL.md →「モデルソース → パラメータ ポリシー」テーブルを参照してください。

ステップ 3.1：利用可能なリソースプールを照会する

cloudrobo resource list-pools

usages に MODEL_DEPLOYMENT が含まれ、pool_type が DEDICATED（推奨）または SHARED で、nodes[].available_resources > 0 のプールに絞り込みます。

cloudrobo resource show-pool --pool-id <resource_id>

show-pool の --pool-id には resource_id を使用します（pool- プレフィックスなし）。infer create の --pool-id には pool-<uuid> 形式を使用する必要があります（pool- プレフィックスあり）。

ステップ 3.2：model_ext_metadata を構成する（必須）

--model-ext-metadata を介して model_feature_mapping を渡す必要があります。プラットフォームはアセットバージョンの ext_metadata を読み取りません。渡さない場合、直ちに FAILED になります。

r2c テンプレートと構成手順の全体については、references/model-ext-metadata.md を参照してください。

主なポイント：

1. ロボットの種類に応じて r2c テンプレートを選択します
2. データセットの meta/info.json を読み、特徴量情報を確認します
3. input_features／output_features を動的に変更します
4. OpenPI モデルでは、3 つのカメラキーを固定し、wrist_left の値を wrist_right にコピーします
5. model_type フィールドを含めないでください
6. chunk_size はトレーニング時の model.action-horizon と一致させる必要があります（OpenPI のデフォルトは 50）

ステップ 3.3：推論サービスを作成する

cloudrobo infer create --name "<infer-service-name>" --flavor "1 * SNT9B2 | 24 vCPUs | 192 GiB" --model-json '{"model_id":"<output_model_asset_id>","model_version_id":"<output_model_version_id>"}' --workspace-id <workspace_id> --pool-id "pool-<resource_id>" --pool-type DEDICATED --model-ext-metadata '<model_ext_metadata_json>' --skill-config-json '{"strict":true,"skills":[{"name":"<skill_name>","prompt":"<task_description>"}]}' --stop-schedule-json '{"duration":6,"time_unit":"HOURS"}' --deploy-timeout-minutes 30

flavor の形式：1 * SNT9B2 | 24 vCPUs | 192 GiB（Ascend: プレフィックスなし）。 --pool-id（必須）：pool-<uuid> 形式を使用する必要があります。プレフィックスなしで resource_id を使用すると、直ちに FAILED になります。 --pool-type（必須）：大文字の DEDICATED または SHARED を使用する必要があります。 --model-json（必須）：デプロイするモデルです — {"model_id":"<output_model_asset_id>","model_version_id":"<output_model_version_id>"}（ステージ 2 のトレーニング出力のフィールド）。 --model-ext-metadata（必須）：ステップ 3.2 で構成した JSON を渡します。model_type は含めないでください。 --skill-config-json（重要）：実ロボット評価用のサービスでは、必ずスキルを定義する必要があります。定義しないと、ディスパッチの create-task が 500 を返します。形式：{"strict":true,"skills":[{"name":"<skill_name>","prompt":"<task_description>"}]}。prompt はステージ 4 の --task パラメータと完全に一致させる必要があります。 --internet-access-enable を渡さないでください：predict_url が internet タイプのみになり、ディスパッチで必要な intranet タイプの URL が取得できなくなります。 作成後、自動的に DEPLOYING に移行します。infer start を呼び出す必要はありません。FAILED になった場合は、infer start を呼び出して再試行してください。

ステップ 3.4：推論サービスの状態をポーリングする

cloudrobo infer show --service-id <service_id>

• RUNNING → ステージ 4 に進みます
• DEPLOYING → ポーリングを続けます
• FAILED → cloudrobo infer start --service-id <service_id> を呼び出して再試行します。references/fault-recovery.md を参照してください

ステージ 4：実機評価

タイミング：推論サービスが RUNNING になってからのみ、ロボットに問い合わせてください。 重要：dispatch には create-session コマンドがありません。session_id は workspace_id です。セッションを個別に作成する必要はありません。

ステップ 4.0：ロボットに問い合わせて選択を確認する

cloudrobo robot list --workspace-id <workspace_id>

ワークスペース内のすべてのロボットに問い合わせます。結果を次のように分けます。

• オンラインのロボット：status = ONLINE で、type が対象のロボットタイプ（例：ARM）と一致するもの
• オフラインのロボット：status = OFFLINE または INACTIVE

オンラインのロボットが見つかった場合 — 質問ツールを使って、ユーザーに確認を求めます。

オプション	説明
このオンラインのロボットを使用する（推奨）	選択したオンラインのロボットを使って、そのまま続行します
オフラインのロボットを選択してオンラインにする	証明書をエクスポートし、ロボット側でのオンボーディングを案内し、ONLINE になるまでポーリングします
新しいロボットを登録する	新しいロボットを作成して証明書をエクスポートし、オンボーディングを案内して、ONLINE になるまでポーリングします

ユーザーが確認できるよう、オンラインのロボットの詳細（名前、タイプ、メーカー、モデル、ステータス）を表示します。オンラインのロボットを黙って自動選択しないでください。

オンラインのロボットが見つからない場合 — オフラインのロボット（存在する場合）と新規登録オプションを提示し、ユーザーに選択を求めます（別のワークスペースに切り替える必要があるかどうかは尋ねないでください）。

重要：ロボットを使用する前に、ユーザーの確認が必要です。自動選択しないでください。 --workspace-id を必ず指定してください。status の値は大文字の ONLINE／OFFLINE／INACTIVE です。 オフラインロボットのオンボーディングと新規ロボットの登録手順については、references/robot-selection-guide.md を参照してください。

ステップ 4.1：session_id を確認する

セッションを作成する必要はありません。session_id = workspace_id です。workspace_id をそのまま --session-id として使用します。

cloudrobo dispatch list-tasks --session-id <workspace_id> --limit 1  # Verify

ステップ 4.2：タスクを作成して実行する

重要：create-task はタスクの作成と実行を同時に行います。別途 execute-task コマンドを実行する必要はありません。

cloudrobo dispatch create-task --session-id <workspace_id> --name "<task_name>" --task "<task_description>" --constraints-json '{"model":{"exec_model_id":"<service_id>"},"robot_id":"<robot_id>","exec_constraints":{"max_iter_num":60,"max_run_time":5}}'

• --session-id：workspace_id と同じ値
• --constraints-json（必須）：次の内容を含む JSON オブジェクト：
  • model.exec_model_id：推論サービス ID（service_id）。モデルアセット ID ではありません
  • robot_id：選択したオンラインロボットの ID
  • exec_constraints：実行制限。例：{"max_iter_num":60,"max_run_time":5}
• --task：タスクの説明／スキルのプロンプト。skill_config.strict=true の場合、スキルの prompt と完全に一致させる必要があります
• Windows／PowerShell では、JSON のエスケープに関する問題を避けるため、Python のサブプロセスを使用する必要があります

応答から id を抽出して task_id とします。タスクは自動的に開始されます（ステータスは RUNNING）。

ステップ 4.3：タスクのステータスをポーリングする

cloudrobo dispatch show-task --session-id <workspace_id> --task-id <task_id>

• RUNNING → ポーリングを続けます
• COMPLETED → ステージ 5 に進みます
• FAILED／CANCELLED → references/fault-recovery.md を参照してください

ステータスの値は大文字です。コマンドは get-task-status ではなく show-task です。

ステップ 4.4：実行ログと結果を表示する

cloudrobo dispatch show-task-result --session-id <workspace_id> --task-id <task_id> --limit 100

ステージ 5：結果の出力

ユースケース、ベースモデル、トレーニング方法、ハイパーパラメーター、データセット ID、トレーニングタスク ID、推論サービス ID、セッション ID、ロボット ID、評価スコア、レポートなど、パイプライン全体の結果を要約して出力します。部分的なパイプラインでは、最後のステージが完了した後に該当する概要を出力します。

長時間の非同期実行戦略

パイプライン全体の実行には数時間から数日かかります。cronjob によるポーリングとチェックポイントからの復旧を使用します。

ポーリング間隔：トレーニングは 30 分間隔／タイムアウト 72 時間、推論は 30 分間隔／タイムアウト 2 時間、評価は 30 分間隔／タイムアウト 1 時間です。cronjob の最小間隔は 30 分です。エージェントが現在のステージを判断できるよう、プロンプトにパイプラインの全状態（すべての ID）を含めてください。

チェックポイントからの復旧：セッションが中断した後、パイプラインの状態を読み込み → current_stage のタスクステータスを確認 → 待機を続ける／次のステージに進む／障害復旧を行います。

パイプラインの状態追跡テンプレートについては、references/pipeline-templates.md を参照してください。

---

基本コマンド

ステージ	コマンド	目的
0	cloudrobo asset list-publication-assets --type model	マーケットプレイスのモデルを一覧表示する
1	cloudrobo asset search-assets --keyword "<keyword>"	モデル／データセットのアセットを検索する
1	cloudrobo asset show-asset --asset-id <id>	アセットの詳細とハイパーパラメーターを取得する
1	cloudrobo asset create-asset	データセットアセットを作成する
1	cloudrobo asset create-version	アセットのバージョンを作成する
1	cloudrobo asset update-version --status RELEASE	バージョンを公開する
1	cloudrobo asset import-asset	ローカルディレクトリを OBS にインポートする
1	cloudrobo workspace current	現在のワークスペースと catalog_id を取得する
2	cloudrobo train create-task --config <json>	トレーニングタスクを作成する
2	cloudrobo train show-task --task-id <id>	トレーニングのステータスを照会する
2	cloudrobo train get-stages --task-id <id>	トレーニングのステージを取得する
2	cloudrobo train get-events --task-id <id> --start-time <ms> --end-time <ms>	トレーニングイベントを取得する（時間範囲の指定が必須、単位は ms）
3	cloudrobo resource list-pools	リソースプールを一覧表示する
3	cloudrobo resource show-pool --pool-id <id>	プールの詳細を取得する
3	cloudrobo infer create	推論サービスを作成する
3	cloudrobo infer show --service-id <id>	サービスのステータスを照会する
3	cloudrobo infer start --service-id <id>	失敗したデプロイを再試行する
3	cloudrobo infer list --workspace-id <id>	サービスを一覧表示する
3	cloudrobo infer list-logs --service-id <id>	サービスログを表示する
4	cloudrobo robot list --workspace-id <id>	ロボットを一覧表示する
4	cloudrobo robot show --robot-id <id>	ロボットのステータスを確認する（ディスパッチ前に ONLINE を再確認する）
4	cloudrobo robot create	新しいロボットを登録する（ユーザーが Option C を選択した場合）
4	cloudrobo robot export-certificate --robot-id <id>	オフラインでのロボット登録に使用するアクセス設定をエクスポートする
4	cloudrobo dispatch create-task	タスクを作成して実行する
4	cloudrobo dispatch show-task	タスクのステータスを照会する
4	cloudrobo dispatch list-tasks	タスクを一覧表示する
4	cloudrobo dispatch show-task-result	タスクの結果／ログを取得する
4	cloudrobo dispatch cancel-task	タスクをキャンセルする

---

パラメーターの確認

パラメーター	必須	説明	例
workspace_id	はい	アクティブなワークスペース ID	cloudrobo workspace use <id> で設定
model_keyword	はい	検索するベースモデル名	LeRobot_PI05-Base
train_method	はい	モデルのアクションから指定	FFT または LORA
spec	はい	リソース仕様の文字列	Ascend: 1 * SNT9B2 | 24 vCPUs | 192 GiB
parameters	はい	ハイパーパラメーターの JSON 配列文字列	[{"key":"batch_size","value":"32"}]
pool_id	はい（ステージ 3）	pool- プレフィックスが付いたリソースプール ID	pool-d1cc6d45-...
pool_type	はい（ステージ 3）	大文字表記のプールタイプ	DEDICATED または SHARED
model_ext_metadata	はい（ステージ 3）	特徴マッピングの JSON 文字列	references/model-ext-metadata.md を参照
skill_config_json	はい（ステージ 3）	ディスパッチ用のスキル定義	{"strict":true,"skills":[...]}
service_id	はい（ステージ 4）	推論サービス ID	infer create の応答から取得
robot_id	はい（ステージ 4）	オンラインのロボット ID	robot list の応答から取得
task	はい（ステージ 4）	タスクの説明／プロンプト	"Insert the pen into the pen holder"

ステージ 3 のパラメーターに関するコンテキスト：デプロイするモデルがスペースアセット（トレーニング出力）であり、実機評価（ステージ 4）がこれらに依存するため、このワークフローでは model_ext_metadata と skill_config_json が必須です。これは、cloudrobo-infer スキルの「Model Source → Parameter Policy」表にあるスペースアセット／Variant B の手順に従っています。embodiment plaza モデルをデプロイする場合は、代わりに cloudrobo-infer スキルの Variant A を使用してください。必要なコアパラメーターのみを指定し、model_ext_metadata／skill_config_json は渡さないでください。

---

参考ドキュメント

• references/cli-installation-guide.md — CloudRobo CLI のインストールと設定
• references/iam-policies.md — CloudRobo の最小権限 IAM ポリシー
• references/dataflow-diagram.md — パイプラインの Mermaid データフロー図
• references/pipeline-templates.md — クイックリファレンステンプレートとハイパーパラメーター設定
• references/openpi-rename-map.md — OpenPI の model.data.rename_map 構築ガイド
• references/model-ext-metadata.md — r2c テンプレートを使用した model_ext_metadata の構築
• references/fault-recovery.md — トレーニング、推論、評価の障害復旧
• references/robot-selection-guide.md — ロボット選択、オフラインでのオンボーディング、新しいロボットの登録手順の詳細
• references/constraints.md — 制約とルールの全一覧
• references/verification-method.md — 検証方法と CLI コマンドのリファレンス
• references/acceptance-criteria.md — パイプライン実行の受け入れ基準

---

KooCLI コマンド形式の標準

cloudrobo <Service> <Operation> [--params]

機能	説明	例
サービス名	cloudrobo のサービス名	asset、train、infer、dispatch、robot、resource、workspace
操作名	ケバブケースの操作名	search-assets、create-task、show-task
単純なパラメーター	--key=value	--keyword="LeRobot_PI05-Base"
JSON パラメーター	--key='<json>'	--config '{"name":"..."}'
リージョン	該当なし（cloudrobo はワークスペースを使用）	cloudrobo workspace use <id> で設定

Windows／PowerShell では、シェルのエスケープに関する問題を避けるため、複雑な JSON パラメーターはファイルに書き込み、Python の subprocess 経由で呼び出してください。

---

検証

• 実行モード：ユーザーの意図と対応するステージ範囲を正しく特定する
• ステージをスキップする場合の入力：中間ステージから開始する際に、必要な先行パラメーターがすべて指定されている
• エンドツーエンド：ステージ 0～5 を完了する — トレーニングが FINISHED → 推論が RUNNING → 評価が COMPLETED
• ハイパーパラメーターの確認：ステップ 1.1c でデフォルト値を表示してユーザーに確認した。data.rename_map：OpenPI では、シングルクォートで囲んだコンパクトな JSON を使用してステップ 1.1d を実行した
• データセット処理：ローカルディレクトリをアップロードし、バージョンは RELEASE。トレーニングで「dataset not ready」と報告されない
• アセットの引き渡し：各ステージの出力 ID が次のステージに正しく渡される
• トレーニング：CLI の create-task が task_id を返し、ステータスが CREATE_FAILED ではない。最終的に FINISHED になる
• 推論：infer show のステータスが RUNNING。pool_id が pool-<uuid> 形式で、pool_type が大文字であり、プールが MODEL_DEPLOYMENT をサポートする。model_ext_metadata が r2c テンプレートとデータセット情報から構築され、model_type フィールドがなく、chunk_size が model.action-horizon と一致し、グリッパーが end_effector_states.position を使用する
• 実機ロボット評価：ステップ 4.0 で質問ツールを使ってロボットの選択を確認した（暗黙的な自動選択は行わない）。dispatch show-task のステータスが COMPLETED。session_id = workspace_id。constraints-json の model.exec_model_id がサービス ID。推論サービスに空ではない skills を含む skill_config がある。predict_url に intranet タイプが含まれる
• チェックポイントからの復旧：セッションが中断された後も、パイプラインの状態を再開できる

詳細なチェックリストについては、references/verification-method.md と references/acceptance-criteria.md を参照してください。