huawei-cloud-cloudrobo-dispatch

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

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

概要

cloudrobo-dispatch スキルは、robo-dispatcher サービスを介して身体性タスクのディスパッチを管理します。エージェントは、セッション（session_id）内で実行モデル（exec_model_id）を使ってロボット（robot_id で識別）上で実行するタスクを作成し、その状態を監視してキャンセルし、自然言語によるタスク結果とログ項目を取得できます。

適用シナリオ：

• タスクのディスパッチ — 自然言語によるタスクの説明を指定して、ロボット上にタスクを作成します。必ず停止条件（exec_constraints：デフォルトでは max_run_time=10 分、max_iter_num=100 ステップ）を指定してください。
• タスクの監視 — セッション内のタスクを一覧表示または表示し、ステータス／ロボット／推論サービスで絞り込みます
• タスクの完了待ち — 手動でポーリングすることなく、ディスパッチしたタスクが RUNNING 状態を抜けるまでブロックします（wait-task。タスクの終了を待つ際に推奨される方法です）
• タスクのキャンセル — 実行中または保留中のタスクをキャンセルします
• 結果の取得 — 完了したタスクの結果（task + log_items）を取得します
• スキルをまたいだオーケストレーション — ロボット（cloudrobo-robot）と推論モデル （cloudrobo-infer / cloudrobo-asset）を組み合わせて、ロボットで実行可能な具体的なタスクを作成します。

アーキテクチャ：

Agent / LLM
    │
    ├── CLI  →  cloudrobo dispatch <command>
    └── SDK  →  DispatchClient (Python) — domain RoboDispatcherTaskManagement
                    │
                    ▼
              cloudrobo-service (REST API)
              /v1/robo-dispatcher/sessions/{session_id}/tasks*

すべての操作は cloudrobo-service バックエンドを対象とし、session_id のスコープ内で実行されます。また、有効な workspace_id が必要です。セッションは安定した実行コンテキストであり、1つのセッション内で複数のタスクを時期をまたいで作成できます。

session_id：現行バージョンでは、session_id は現在のワークスペースの workspace_id と同一です。アクティブなワークスペース（cloudrobo workspace current）または設定済みの workspace_id を読み取ることで取得し、その値を --session-id としてそのまま再利用できます。呼び出し元が異なる session_id を明示的に指定した場合は、現在のワークスペースと照合することを優先してください。

前提条件

• CLI のインストール、AK/SK 認証、ワークスペースの設定については、references/cli-installation-guide.md を参照してください。
• すべてのタスク操作に有効な session_id が必要です。現行バージョンでは、session_id は現在のワークスペースの workspace_id と同じです — cloudrobo workspace current または設定済みの workspace_id から読み取ってください（個別のセッション作成 API はありません）。
• 有効な robot_id（cloudrobo-robot から取得）と、タスクを実行する制約付きのモデルサービスの exec_model_id が必要です。タスクを実行するには、ロボットが ONLINE（つまり、R2C エッジクライアントが接続済み）である必要があります。そうでない場合、バックエンドは failure_reason: "Robot offline" でリクエストを拒否します。

exec_model_id の取得方法（重要） — exec_model_id は、タスクを実行する実行モデルのハンドルです。生のモデル／アセット ID（例：8b804b51-…）を設定してはいけません。バックエンドでアセット ID を解決できず、タスクは失敗します。

2 種類の exec_model_id（このプラットフォームで 2026-08 に確認済み）：

1. ユーザー作成の推論サービス（cloudrobo-infer の cloudrobo infer create でデプロイ）： exec_model_id は推論サービスの service_id と同じです。つまり、cloudrobo infer create と cloudrobo infer list が返す id です。具体的には、cloudrobo infer list を実行し、デプロイしたサービス（例：so101-real-demo-0828）を選んで、その id （<uuid>）をそのまま exec_model_id として使用します。ユーザーがデプロイしたサービスについては、別途「モデルサービス UUID」を検索する必要はありません。
2. プラットフォームの事前構築済み／外部モデルサービスには、ext_ が付いた不透明なハンドルが表示されます。例：ext_2dcc1539e72040c78650c554102debaf（名前の例：Claude-3.5-Updated）や ext_1ee0bcc7…（名前の例：cloudrobo-real-rl-model-…）。これらは infer list のサービスではありません。既存のタスクの constraints.model.exec_model_id から取得してください。

同じセッション内の既存の成功したタスクで、いつでも正確な値を確認できます：cloudrobo dispatch list-tasks --session-id <sid> --content-match "<skill prompt>" を実行し、返された constraints.model.exec_model_id を確認してください（返された exec_model_name は元のサービス名と一致します）。

ワークフロー

自然言語を優先する原則

以下のすべてのワークフローは、手動で CLI／SDK を操作するのではなく、ユーザーの意図（1～2 文）から始まります。その後、スキルが対応するコマンドの流れを実行し、状態のフィードバックを報告します。

タスクのディスパッチワークフロー（モジュール＋ロボット＋モデル＋ワークスペース）

シナリオ：「ロボット A に、赤いキューブを拾ってビンに入れるよう指示します。」

1. セッションを解決する — 現在のワークスペースから session_id を読み取ります。現行バージョンでは session_id == workspace_id です（cloudrobo workspace current または設定済みの workspace_id から取得します）。
2. ロボットとモデルを解決する — robot_id（ロボット登録から取得）と exec_model_id を取得します。 exec_model_id はタスクを動かす実行モデルハンドルです。デプロイしたサービスの場合は、 そのサービスの service_id です（以下の「exec_model_id の解決方法」を参照）。どちらも constraints で必須です。
3. ロボットに接続できることを確認する — 対象のロボットは ONLINE（r2c エッジクライアントが接続済み）である必要があります。 オフラインまたは未接続のロボットに対するディスパッチタスクは、失敗理由 Robot offline で失敗します。 ディスパッチする前に、cloudrobo-r2c を使用して（ダミーまたは実機の）ロボットをオンラインにします。
4. タスクを記述する — 自然言語の task テキスト（例：「赤いキューブを拾ってビンに入れる」）と name を用意します。推論サービスが strict:true でデプロイされている場合、task テキストは定義済みのスキルプロンプトと一致する必要があります。一致しない場合、サービスは拒否します。（skill_config.strict を設定したサービスのデプロイ方法については cloudrobo-infer を参照してください。）
5. 停止条件を指定してタスクを作成する — cloudrobo dispatch create-task --session-id <sid> --name <name> --task "<task>" --constraints-json '<json>'。--constraints-json は必須で、model、robot_id、 および停止条件 exec_constraints を指定します。タスクが無制限に実行されないよう、必ず停止条件 （max_run_time と max_iter_num）を設定します。ユーザーが指定しない場合のデフォルトは、 max_run_time=10（分）、max_iter_num=100（ステップ）です。 実行前に確認を求めてください（状態を変更する操作です）。
6. 完了を待つ（推奨） — 次のコマンドでタスクの終了まで待機します。 cloudrobo dispatch wait-task --session-id <sid> --task-id <task_id> [--timeout <secs>]。 このコマンドは内部で 5s ごとにポーリングし、タスクのステータスが RUNNING 以外に変わると （つまり COMPLETED／FAILED／CANCELLED、またはその他の RUNNING 以外の状態になると）戻ります。手動で show-task をポーリングする代わりに wait-task を使用してください。従来の手動ポーリングループ（20～30 秒間隔）を置き換えるコマンドです。
7. 結果を取得する — 完了後、cloudrobo dispatch show-task-result --session-id <sid> --task-id <task_id> を実行して、自然言語の結果とログ項目を確認します。

注：robot_id と exec_model_id は constraints 内で必須です。値をハードコードせず、 ロボットと推論／アセットの出力から解決してください。

exec_model_id の解決方法 — exec_model_id はモデルアセット ID ではありません（cloudrobo-asset の 8b804b51-... 形式のアセット UUID）。これはタスクを動かす実行モデルハンドルです。cloudrobo infer create で 自分でデプロイしたサービスの場合、exec_model_id はそのサービスの service_id と同じです （cloudrobo infer list または create の応答から取得します）。プラットフォームのビルド済みモデル／外部モデルサービスでは、 代わりに ext_ が先頭に付いた不透明なハンドルを使用します。次の方法で解決してください。

1. 対象モデルが自分でデプロイした推論サービスの場合 → cloudrobo infer list を実行し、サービスの id を exec_model_id として使用します（2026-08 に同一であることを確認済み）。
2. それ以外の場合は、同じセッションにある既存の成功タスクを確認して正確な値を特定します。 cloudrobo dispatch list-tasks --session-id <sid> --content-match "<deployed skill prompt>" を実行し、 constraints.model.exec_model_id を確認します（exec_model_name は元サービス名を示す参考情報です）。 exec_model_id に未加工のアセット UUID を使用することは、ディスパッチ失敗のよくある根本原因です。

タスクの監視／検索ワークフロー（モジュール＋フィルター）

シナリオ：「自分のセッションで実行中のタスクは何ですか？」

1. cloudrobo dispatch list-tasks --session-id <sid> [--status <status>] [--robot-id <rid>] [--infer-service-id <iid>] [--start-time <ms>] [--end-time <ms>] [--content-match <text>] ページネーション（--limit／--offset）と並べ替え（--sort-key／--sort-dir）に対応しています。
2. 詳細を確認するには、cloudrobo dispatch show-task --session-id <sid> --task-id <task_id> を実行します。
3. タスクのステータス、ロボット、モデル、内容を報告します。

タスク結果の取得ワークフロー（モジュール）

シナリオ：「あのピックアンドプレースタスクの結果を見せてください。」

1. wait-task でタスクの完了を待つか、show-task で終了状態であることを確認します。
2. cloudrobo dispatch show-task-result --session-id <sid> --task-id <task_id> — タスクオブジェクトと log_items を返します。ページネーションには --inverse、--limit、--offset を使用できます。

タスクのキャンセルワークフロー（モジュール）

シナリオ：「そのタスクを中止してください。ロボットが間違った物体を選びました。」

1. show-task でタスクを確認します。
2. cloudrobo dispatch cancel-task --session-id <sid> --task-id <task_id> を実行します（変更を伴います。確認してください）。
3. show-task で、タスクがキャンセル済み状態に移行したことを確認します。

セッションコンテキストに関する注意

• タスクは常に session_id のもとで作成されます。現行バージョンでは、session_id は現在のワークスペースの workspace_id と同じです。cloudrobo workspace current で取得してください。1 つのセッション内で、時間をおいて複数のタスクを作成できます。
• 停止条件：すべてのタスクは、時間内に停止するよう constraints.exec_constraints を指定して作成してください。必要なオブジェクト形式とデフォルト値については、「タスクの作成」セクションを参照してください。
• strict services：実行推論サービスが skill_config.strict:true を指定してデプロイされている場合、渡す task は、事前定義されたスキルプロンプトのいずれかと一致する必要があります。一致しないプロンプトは拒否されます。
• 従来の create-session／exec_task／create-session-task インターフェースは非推奨であり、使用しないでください。すべての操作で、タスクエンドポイントに session_id を直接指定します。

CLI コマンド形式の標準

cloudrobo dispatch <command> [OPTIONS]

機能	説明
コマンドグループ	dispatch
サブコマンド	ケバブケース：create-task、list-tasks、show-task、cancel-task、show-task-result、wait-task
セッション	--session-id <id>（すべてのタスク操作で指定。現行バージョンでは workspace_id と同じ）
JSON パラメーター	--constraints-json '<object>'（create-task で必須。model／robot_id／exec_constraints を含みます）
ドライラン	--dry-run（create-task／cancel-task）
結果のページネーション	--inverse、--limit、--offset（show-task-result）
待機タイムアウト	--timeout <secs>（wait-task。デフォルトは 600、IntRange は 1～3600）

完全なカバレッジ：SDK では 6 つのメソッド、CLI では 6 つのコマンドが公開されています（不足はありません）。 対応関係については、references/cli-installation-guide.md と受け入れ基準を参照してください。

主なコマンド

SDK の直接呼び出し：CLI が使いにくい場合（動的な JSON、パッケージをまたぐクエリー）は、Python SDK を直接使用してください。DispatchClient（ドメイン RoboDispatcherTaskManagement）では、以下の 6 つのメソッドが公開されています。

タスクの作成

cloudrobo dispatch create-task --session-id <session-id> --name <task-name> --task "<natural language task>" --constraints-json '{"model":{"exec_model_id":"<model-id>"},"robot_id":"<robot-id>","exec_constraints":{"max_run_time":10,"max_iter_num":100}}' [--dry-run]

実際の運用では停止条件が必須です（constraints.exec_constraints）。ユーザーが値を指定しない場合、デバッグタスクが無制限に実行されたり、長時間実行されたりするのを避けるため、max_run_time=10（分）、max_iter_num=100（ステップ）をデフォルト値にしてください。有効範囲：max_run_time は 1～300 分、max_iter_num は 1～300000 ステップです。

model オブジェクトの形式（重要） — create-task の constraints.model には、exec_model_id のみを含めてください。exec_model_name は追加しないでください。指定すると、作成 API は 400 Invalid parameter: exec_model_name を返します。exec_model_name はレスポンス専用のフィールド（show-task／list-tasks／show-task-result の出力に含まれる）であり、リクエストフィールドではありません。exec_model_id に指定する値については、「exec_model_id の解決方法」の注意を参照してください。

from cloudrobo_core.sdk import Config, HttpClient
from cloudrobo_dispatch import DispatchClient

config = Config()
http_client = HttpClient(config)
client = DispatchClient(http_client)

# session_id equals the current workspace_id in the current version
req = {
    "name": "pick-red-cube",
    "task": "pick up the red cube and place it in the bin",
    "constraints": {
        "model": {"exec_model_id": "<mid>"},
        "robot_id": "<robot-id>",
        # stop condition: use the given values, else default max_run_time=10, max_iter_num=100
        "exec_constraints": {"max_run_time": 10, "max_iter_num": 100},
    },
}
task = client.create_dispatcher_task("<session-id>", req)
print(task)  # includes task_id

タスクの一覧表示

cloudrobo dispatch list-tasks --session-id <sid> [--status <status>] [--limit 20] [--offset 0]

tasks = client.list_dispatcher_tasks("<session-id>", status="RUNNING")
for t in tasks.get("items", []):
    print(t["id"], t["status"], t["name"])

タスクの詳細を表示

cloudrobo dispatch show-task --session-id <sid> --task-id <task-id>

task = client.show_dispatcher_task("<session-id>", "<task-id>")
print(task["name"], task["status"], task["robot_id"])

タスクをキャンセル

cloudrobo dispatch cancel-task --session-id <sid> --task-id <task-id> [--dry-run]

client.cancel_dispatcher_task("<session-id>", "<task-id>")

タスクの結果を表示

cloudrobo dispatch show-task-result --session-id <sid> --task-id <task-id> [--inverse] [--limit 100] [--offset 0]

result = client.show_dispatcher_task_result("<session-id>", "<task-id>")
print(result["task"]["result"])
for item in result.get("log_items", []):
    print(item)

タスクの完了を待機

目的：ディスパッチされたタスクが終了するまで（ステータスが RUNNING 以外になるまで）ブロックするため、ループ内で show-task を手動でポーリングする必要がありません。これは、非対話型／自動化シナリオでタスクを待つ推奨方法です。

cloudrobo dispatch wait-task --session-id <sid> --task-id <task-id> [--timeout <seconds>]

result = client.wait_dispatcher_task("<session-id>", "<task-id>", timeout=600)
# result is the full task dict once status != "RUNNING" (e.g. COMPLETED / FAILED / CANCELLED)
status = (result.get("task") or {}).get("status")

動作（ソースに基づく確定情報）：

• メソッド：wait_dispatcher_task(session_id, task_id, timeout=600)。
• ポーリング：5 秒ごと（POLL_INTERVAL = 5）。内部で show_dispatcher_task （GET /v1/robo-dispatcher/sessions/{session_id}/tasks/{task_id}）を呼び出します。
• 戻り条件：data["task"]["status"] != "RUNNING" になると、タスク辞書を返します。 — COMPLETED、FAILED、CANCELLED、またはその他の RUNNING 以外の状態に到達したかどうかは問いません。終端状態は COMPLETED、FAILED、CANCELLED です。
• デフォルトのタイムアウト：600 秒。--timeout は IntRange(1, 3600) で、**最大 3600 秒（1 時間）**です。
• タイムアウト時：TimeoutError（クライアント）を発生させます。CLI は [ERROR] <msg> を標準エラー出力に表示し、コード 1 で終了します。成功、失敗、タイムアウトを区別するため、必ず戻り値のステータスを確認してください。
• 独立した REST API はありません：wait-task はクライアント側のポーリングヘルパーです。専用のバックエンドエンドポイントはなく、単に show-task をラップします。
• 先にタスクを作成する必要があります：wait-task はタスクを作成しません。まず create-task を呼び出して task_id を取得し、その後に wait-task を実行してください。

推奨事項（wait-task を使用するタイミング）：

• create-task の直後に wait-task を使用し、その後 show-task-result で結果を取得してください。これにより、20～30 秒ごとに手動で show-task をポーリングする従来の方法を置き換えられます。
• 終端状態になるまでブロックする必要がある非対話型／自動化のフローに最適です。
• 中間状態を確認したい対話型のフローでは、show-task で進捗を調べることもできます。結果を待つだけでよい場合は、wait-task を使用してください。

パラメーターの確認

パラメーター	出典	必須	確認が必要
--session-id	現在のワークスペース（workspace_id）	はい（すべて）	現行バージョンでは session_id == workspace_id です。cloudrobo workspace current に照らして確認してください
--task	ユーザー	はい（作成時）	自然言語によるタスクの説明です。厳格なサービスの場合は、事前定義されたスキルプロンプトと一致する必要があります
--name	ユーザー	はい（作成時）	タスク名
--constraints-json	ユーザー／導出値	はい（作成時）	JSON オブジェクト {model, robot_id, exec_constraints}。停止条件を保持します
exec_constraints（--constraints-json 内）	ユーザー、指定がなければデフォルト	実質的に必須（作成時）	デフォルトは max_run_time=10（分）、max_iter_num=100（ステップ）です。範囲はそれぞれ 1～300／1～300000 です
--task-id	ユーザーまたは前の出力	はい（表示／キャンセル／結果／待機時）	キャンセル前に確認してください。wait-task の前に（create-task で）作成されている必要があります
--timeout	導出可能	いいえ（待機時）	wait-task のタイムアウト（秒）。デフォルトは 600、IntRange は 1～3600 です
--dry-run	—	いいえ	実行せずにプレビューします

状態を変更する操作（create-task／cancel-task）を実行する前に、ユーザーに確認を求める必要があります。

参考ドキュメント

• CLI インストールガイド — cloudrobo CLI のインストールと設定
• IAM ポリシー — 最小権限の認証情報とアクセスモデル
• 検証方法 — 検証方法の詳細
• データフロー図 — Mermaid のデータフロー図
• 受け入れ基準 — 受け入れ基準

エッジケース

シナリオ	対応
session_id がない	現在のバージョンでは session_id == workspace_id です。cloudrobo workspace current から取得してください
robot_id / exec_model_id がない	create-task では、constraints 内に両方が必要です。ロボットとデプロイ済みのモデルサービス（アセット ID ではありません）から解決してください
exec_model_id が誤っている（アセット ID を使用）	デプロイしたサービスの場合、exec_model_id はそのサービスの service_id と同じです（cloudrobo infer list で確認できます）。アセット ID の生値（8b804b51-...）を使うと失敗しやすくなります。ビルド済み／外部のモデルサービスには、ext_ 接頭辞が付いたハンドルを使用します。list-tasks --content-match "<prompt>" で既存の成功したタスクと照合してください
create リクエストに exec_model_name を渡す	constraints.model に exec_model_name を含めないでください。create API は 400 Invalid parameter: exec_model_name を返します。exec_model_name はレスポンス専用です。削除して、exec_model_id のみで再試行してください
ロボットがオフライン／未接続	オフラインのロボットでタスクを実行すると、failure_reason: "Robot offline" で失敗します。ディスパッチする前に、cloudrobo-r2c（ダミー／実際のエッジクライアント）を使ってロボットをオンラインにしてください
停止条件がない	create-task では constraints.exec_constraints を設定してください。タスクが無制限に実行されないよう、デフォルト値として max_run_time=10、max_iter_num=100 を設定してください
タスクの実行時間が長すぎる	範囲を守ってください。max_run_time は 1～300 分、max_iter_num は 1～300000 ステップです。デバッグタスクの実行時間を制限するため、上限を超えないでください
strict:true のサービス	推論サービスが skill_config.strict:true を指定してデプロイされている場合、task は定義済みのスキルプロンプトと一致する必要があります。一致しない場合は拒否されます
タスクが見つからない	show/cancel/result は ResourceNotFoundError を返します。task_id / session_id を確認してください
パストラバーサル	validate_safe_id(session_id) / validate_safe_id(task_id) により、../ の入力がブロックされます
完了済みタスクのキャンセル	バックエンドが拒否します。キャンセルする前にステータスを確認してください
長時間実行タスク	wait-task を優先してください（5 秒ごとにポーリングし、ステータスが RUNNING 以外になると返ります）。中間状態の確認にのみ show-task を使い、短い間隔で手動ループを回さないでください
wait-task のタイムアウト	--timeout の最大値は 3600s（1h）です。タイムアウトすると CLI は [ERROR] を出力して終了コード 1 で終了します。ユーザーに伝えたうえで、show-task で再確認してください
終了状態のタスクに対する wait-task	（すでにステータスが RUNNING 以外のため）すぐに返ります。タスクの完了後に呼び出しても安全です
wait-task には既存のタスクが必要	タスクは作成されません。先に create-task を呼び出して task_id を取得してください。無効または不明なタスクを指定すると失敗します
自然言語のタスク内容	サニタイズし、インジェクションを防止してください。エスケープせずに生の内容をログに出力しないでください
AK/SK が設定されていない	HTTP 署名時に操作が失敗します。HUAWEI_CLOUD_AK / HUAWEI_CLOUD_SK を設定してください
非推奨のインターフェース	古い create-session / exec_task / create-session-task / list-sessions は使用しないでください
session_id / task_id / robot_id / exec_model_id	ハードコードせず、動的に解決してください（session_id は現在のワークスペースから取得）
スキル間の呼び出し	このスキルは他のスキルを呼び出しません。robot_id（robot）と exec_model_id（infer/asset）を受け取り、タスクの結果を報告します
変更を伴う操作	create-task / cancel-task はユーザーの確認を得てください

検証方法

仕様準拠の検証

bash scripts/test-cli-commands.sh

機能テスト

bash scripts/test-cli-commands.sh

テストケース

ディスパッチ、モニタリング、完了待ち、キャンセル、結果の取得、安全性に関するシナリオを網羅したテストケースの全リストについては、templates/test-vars.json を参照してください。

検証チェックリスト

• create-task の後、タスクが正しいステータスで list-tasks に表示される
• 作成されたタスクに停止条件（exec_constraints.max_run_time / max_iter_num）が設定されている。 ユーザーが指定しなかった場合は、デフォルトで 10 分／100 ステップになる
• 使用された session_id が現在のワークスペースの workspace_id と一致する
• 推論サービスが strict:true の場合、task が事前定義されたスキルプロンプトと一致する
• wait-task の後、コマンドがブロックされ（5 秒ごとにポーリング）、ステータスが RUNNING 以外になったときにのみ戻る。手動で 20～30 秒のポーリングループを使用していない
• 明示的な --timeout を指定した wait-task がタイムアウトを遵守し、期限切れ時に明確なエラーを報告する
• wait-task は create-task ですでに作成された task_id を指定して呼び出される（タスクは作成しない）
• show-task の後、詳細にロボット／モデル／ステータスを含むタスクが返される
• show-task-result の後、自然言語の結果と log_items が返される
• cancel-task の後、show-task にキャンセル済みの状態が反映される
• validate_safe_id によりパストラバーサル（../）がブロックされる
• 非推奨インターフェース（create-session／exec_task）は使用されない
• 変更を伴う操作では、実行前にユーザーの確認を求める

ベストプラクティス

• 現在のワークスペースから常に session_id を解決し（cloudrobo workspace current。現行バージョンでは session_id == workspace_id）、robot_id／exec_model_id は動的に解決します。 ハードコードしないでください
• タスクを作成するときは、必ず停止条件（constraints.exec_constraints）を設定します。ユーザーが指定しなかった場合は、デバッグタスクが長引かないよう、デフォルトの max_run_time=10（分）と max_iter_num=100（ステップ）を使用します（範囲 1～300／1～300000 を遵守してください）
• 駆動する推論サービスが strict:true でデプロイされている場合は、task を事前定義されたスキルプロンプトと一致させます
• create-task（実際のロボット動作を開始します）と cancel-task の前に確認します
• create-task の後は、show-task を手動でポーリングするのではなく、wait-task で待機します — ステータスが RUNNING 以外になるまでブロックし（5 秒ごとにポーリング）、その後 show-task-result で結果を取得します。必要な場合にのみ、中間状態の確認に show-task を使用します。エージェント環境では、手動でスリープしてから show-task を繰り返すのではなく、wait-task をバックグラウンドプロセスとして実行し、戻るまで待機します（タスクが終端状態になると自動的に終了します）。
• タスクが長時間実行される可能性がある場合は、wait-task に明示的な --timeout を設定します。タイムアウトした場合は、やみくもに再試行するのではなく、show-task で状態を再確認し、結果を報告します
• constraints.model に指定できるのは exec_model_id のみです — 作成リクエストに exec_model_name を渡さないでください（400 エラー）。これはレスポンス専用のフィールドです
• 自分がデプロイしたモデルサービス（cloudrobo infer create）の場合、exec_model_id はそのサービスの service_id です（cloudrobo infer list を参照）。ext_ 接頭辞付きのハンドルを使用するのは、プラットフォームのビルトイン／外部モデルサービスのみです。値を推測せず、cloudrobo infer list を優先して解決してください
• 操作前にパラメーターを検証するには、create-task／cancel-task で --dry-run を使用します
• タスクをすばやく見つけるには、list-tasks のフィルター（--status、--robot-id、--infer-service-id、--content-match）を使用します
• 自然言語の task 内容をサニタイズし、エスケープせずに生の内容をログへ出力しないでください
• ロボット（cloudrobo robot list/show）および推論（cloudrobo infer list）のスキルと組み合わせて、タスクの作成に必要なロボット／モデル ID を解決します