移行: コマンド マップ

従来の「uipcli」動詞から同等の UiPath CLI へのコマンド マップを、コマンド ファミリ別にグループ化します。

すべてのレガシ uipcli 動詞と、それに相当する uip 動詞。レガシ エントリは、2025.10 以前に文書化された公開uipcli サーフェスを反映しています。uip列は、公開されているリファレンスページと一致します。

このページの読み方行は、従来の動詞ファミリ (package、 job、 test、 asset、 solution、 run) でグループ化されます。各行には分類が含まれます。

• 1:1 — 直接名前を変更する。新しいフラグセットは、機械的なポートが機能するほど近くにあります。
• 2ステップ / Nステップ —1つのレガシー動詞が複数の uip 呼び出しにマップされます。
• 削除 — 置換: ... —レガシー動詞には直接の後継者がいません。「replacement」列には、同じ結果に対する慣用的な新しいCLIフローが表示されます。

各動詞内のフラグ レベルの詳細については、「 フラグの名前の変更」を参照してください。すべての動詞に適用される基になる認証/出力の変更については、「 重大な変更」を参照してください。

パッケージ

レガシ コマンド	uip 相当	備考
uipcli package pack <project>	uip rpa pack <project> <output-path>	1:1ですが、純粋なケバブケースではありません。 --outputType → --output-type 期待どおりですが、 --autoVersion には 同等のものがありません 。 uip rpa packには auto-generate-version フラグがありません。バージョンを自分で計算して渡 --package-version。--author/--description は --package-author/--package-descriptionになり、cert フラグには signing- プレフィックス (--signing-certificate-pathなど) が付きます。uip rpa コマンドは、Studio パッケージャー () を呼び出します。NET でサポートされる — ランナーには引き続き利用可能な .NET ランタイムが必要です。uip rpa pack と migration-flag-renames.md の完全なフラグの表をご覧ください。
uipcli package analyze <project>	uip rpa analyze <project> --governance-file-path <policy>	引き継がれるフラグについては 1:1 ですが、 --resultPath と --stopOnRuleViolation には同等のものがまったくありません — それらは uip rpa analyzeには存在せず、単に文書化されていません。結果を得るために自分自身を stdout リダイレクトします。大まかな重大度ゲートで十分な場合は、 --default-severity を使用します。--governanceFilePath--governance-file-path(ケバブケース)になります。ワークフロー アナライザーのルールに変更はありません。.NET バックエンドは rpa packと同様に適用されます。詳しくは、 uip rpa analyze と migration-flag-renames.md の完全なフラグ テーブルをご覧ください。
uipcli package deploy <path> <url> <tenant>	uip or packages upload <path> Then uip or processes create --name <n> --package-key <k> --package-version <v> --folder-path <path>	2ステップ。レガシ デプロイでは、1 回の呼び出しで .nupkgがアップロード され、 プロセスが作成されます。新しいCLIは、これらの懸念を分割します。「 uip or packages upload 」および「 uip or processes create」をご覧ください。
uipcli package restore <project>	uip rpa restore <project> [output-path]	1:1、復元固有のフラグは一切なし — restore は、一般的なパッケージ化オプション (--project-dir、 --exclude-configured-sources、 --nuget-sources-config-path、 --feed-folder、 --format、 --log-level) とその 2 つの位置のみを取ります。--nugetConfigFilePath は --nuget-sources-config-pathにマップされます。.NET バックエンドが適用されます。「 uip rpa 復元」をご覧ください。

パッケージパック

# Legacy
uipcli package pack "C:\proj\project.json" -o "C:\dist" \
    --outputType Process --autoVersion

# uip - no --auto-version equivalent; pass an explicit --package-version instead
uip rpa pack ./proj ./dist --output-type Process --package-version 1.0.0

フラグの完全なリストについては、 uip rpa pack をご覧ください。このツールは、従来の CLI で使用されていたものと同じ Studio パッケージャーをラップするため、出力形式とプロジェクトのサポートは同じです。

パッケージ分析

# Legacy
uipcli package analyze "C:\proj\project.json" \
    --governanceFilePath "C:\policy.json" \
    --resultPath "C:\result.json" \
    --stopOnRuleViolation

# uip - --result-path and --stop-on-rule-violation do not exist; redirect stdout instead
uip rpa analyze ./proj \
    --governance-file-path ./policy.json \
    > ./result.json

パッケージのデプロイ

これは、すべてのパイプライン ポートをキャッチする行です。Legacy deploy は、アップロードと作成が 1 回限りで完了します。 uip では、パッケージを一度アップロードすれば複数のフォルダーにバインドできるよう、2 つの明確なステップに分割されています。

# Legacy — upload and create a process in one call
uipcli package deploy "C:\pkg\InvoiceProcessing.1.0.3.nupkg" \
    "https://cloud.uipath.com/" "TenantName" \
    -A "myOrg" -I "<app-id>" -S "<app-secret>" \
    --applicationScope "OR.Folders OR.Execution" \
    -o "Shared" \
    --processName "InvoiceProcessing" \
    --entryPointsPath "Main.xaml"

# uip — upload, then create the process
uip login \
  --client-id env.UIPATH_CLIENT_ID \
  --client-secret env.UIPATH_CLIENT_SECRET \
  --tenant TenantName

uip or packages upload ./InvoiceProcessing.1.0.3.nupkg
#    response includes "body": "InvoiceProcessing:1.0.3"

uip or processes create \
    --name InvoiceProcessing \
    --package-key InvoiceProcessing \
    --package-version 1.0.3 \
    --folder-path Shared \
    --entry-point Main.xaml

注:

• 従来の位置 <orchestrator_url> と <orchestrator_tenant> は、 uip login のセッション コンテキストに置き換えられます ( uip login tenant set <name>でセッションの途中でテナントを切り替えます)。uipでは位置引数として表示されません。
• レガシ --processName は、作成されるプロセスのカスタム表示名です。uipでは、同等のものはprocesses createで--nameであり、--process(存在しない)ではありません。
• レガシ --processNames <csv> (25.10 の複数プロセス一括作成) には、 直接に相当するものはありません。行に対するループのスクリプトを作成するか、推奨される複数プロセス フローの 「ソリューション 」をご覧ください。
• レガシ --entryPointsPath (CSV) は uip or processes createで--entry-point (単一パス) になります。マルチエントリ ポイント パッケージの場合は、エントリ ポイントごとに 1 回processes createを実行します。

パッケージの復元

# Legacy
uipcli package restore "C:\proj" \
    --restoreFolder "C:\deps" \
    --nugetConfigFilePath "C:\NuGet.Config"

# uip
uip rpa restore ./proj ./deps

ジョブ

レガシ コマンド	uip 相当	備考
uipcli job run <processName> <url> <tenant>	uip or jobs start <process-key>	意図的に1:1; ID は名前ではなく GUID です。レガシCLIは、位置引数としてプロセスのリリース名を取りました。新しいCLIは、 uip or processes listによって返されるプロセスキー(GUID)を受け取ります。レガシ -w true + -W <timeout> の動作には --wait-for-completion を使用します。「uip or jobs start」をご覧ください。

# Legacy
uipcli job run "InvoiceProcessing" \
    "https://cloud.uipath.com/" "TenantName" \
    -A "myOrg" -I "<app-id>" -S "<app-secret>" \
    --applicationScope "OR.Folders OR.Execution OR.Jobs" \
    -o "Shared" \
    -i "C:\input.json" \
    -w true -W 3600

# uip — resolve the name to a key, then start with wait-for-completion
PROCESS_KEY=$(uip or processes list --folder-path Shared \
    --name InvoiceProcessing \
    --output-filter "Data[0].Key" \
    --output plain)

uip or jobs start "$PROCESS_KEY" \
    --input-file ./input.json \
    --wait-for-completion \
    --timeout 3600

processes listの--nameは、完全一致ではなく一致を含む、つまりスーパー文字列名です (例:InvoiceProcessingV2) は、 Data[0]に一致させ、シフトまたは複製することもできます。完全一致を保証するには、結果を信頼する前に、返された Name フィールド ( --output-filter "Data[?Name=='InvoiceProcessing'].Key | [0]"など) をさらにフィルター処理します。

フラグレベルの詳細:

• レガシ -i, --input_path <file> → uip には、インライン JSON 用の --input-arguments '<json>' とファイル ペイロード用の --input-file <path> の 2 つの選択肢があります。これらは相互に排他的です。
• レガシ の-j, --jobscount <n> → --jobs-count <n>
• レガシ の-P, --priority <Low|Normal|High> → --job-priority <Low|Normal|High>
• レガシ -r, --robots <csv> → に直接相当するものはありません (レガシにおけるクラシック フォルダーのみの概念)。ターゲット マシンには --machine-keys <csv> (GUID) があり、ユーザーは --user-keys <csv> (GUID) です。
• レガシー-f, --fail_when_job_fails(デフォルトtrue)→待機中のジョブがFaulted終了した場合、新しいCLIは常に1終了します。オプトアウトはありません。
• レガシ -R, --result_path <file> → 新しい CLI では、ジョブ エンベロープが stdout に出力されます。 > result.jsonでリダイレクトするか、 --output-filter を使用して特定のフィールドを抽出します。
• レガシ の-b, --job_type <Unattended|NonProduction> → --runtime-type <Unattended|Headless|Serverless|NonProduction|Development|TestAutomation>

test

レガシ コマンド	uip 相当	備考
uipcli test run <url> <tenant> -s <testset>	uip tm testsets run --test-set-key <key> Then uip tm wait --execution-id <id> Then uip tm report get --execution-id <id>	3 つのステップ (起動→待機→検証)。新しいCLIは、「run を起動する」と「block on it」と「read the verdict」を分離しているため、CIスクリプトはそれぞれできれいに分岐できます。「 uip tm テスト セットの実行」をご覧ください。テスト セットから新しい実行を開始する動詞は、 testsets リソース上に として存在 uip tm testsets run。uip tm executions run も存在しますが、目的は異なります。テスト セットから新しい実行を開始するのではなく、 既存の 実行の特定のテスト ケースのログを再実行するものです。
uipcli test run <url> <tenant> -P <project.json> (プロジェクトをパッケージ化 + テストする)	uip rpa pack Test Manager → uip tm testsets run でテスト セットを作成→ uip or packages upload →	N ステップ。従来の 1 回限りの「このプロジェクトをパッケージ化してデプロイし、テストを実行する」というフローは、 rpaツール、 orツール、 tm ツールに分割されています。テスト セットの作成は、通常、Test Manager の Web UI で 1 回だけ設定する必要があります。
uipcli test parallel <url> <tenant> --testsConfigurationFilePath <file>	直接同等のものはありません — uip tm testsets run 呼び出しをループします	削除 — 置換: スクリプトは、独立したテストセットを uip tm testsets run で並行して起動し (それぞれが ExecutionIdを返します)、その後、実行ごとに 1 つの uip tm wait 。従来の parallel 動詞の test-project ドライバー ( uipcli test run 内部で呼び出される) には、対応するものがありません。新しいモデルでは、テスト セットが Test Manager で作成済みであることを前提としています。

テスト実行 (単一のテスト セット)

# Legacy
uipcli test run \
    "https://cloud.uipath.com/" "TenantName" \
    -A "myOrg" -I "<app-id>" -S "<app-secret>" \
    --applicationScope "OR.Folders OR.TestSets OR.TestSetExecutions" \
    -o "Shared" \
    -s "Smoke Suite" \
    --out junit \
    --result_path "C:\results.xml" \
    --timeout 1800

# uip — three verbs, clean exit-code branching
EXECUTION_ID=$(uip tm testsets run \
    --test-set-key DEMO:10 \
    --output-filter "Data.ExecutionId" \
    --output plain)

if ! uip tm wait --execution-id "$EXECUTION_ID" --project-key DEMO --timeout 1800; then
    case $? in
        2) echo "timeout" >&2; exit 2 ;;
        *) echo "wait failed" >&2; exit 1 ;;
    esac
fi

FAILED=$(uip tm report get --execution-id "$EXECUTION_ID" --project-key DEMO \
    --output-filter "Data.Failed" --output plain)

if [ "$FAILED" -gt 0 ]; then
    uip tm result download --execution-id "$EXECUTION_ID" --project-key DEMO \
        --result-path ./results.xml
    exit 1
fi

フラグレベルのメモ:

• レガシ -s, --testset <name> には表示名があります。新しい --test-set-key <key> は Test Manager キー (形式 PROJECT:NN) を取得します。uip tm testsets list --project-key <key>で調べてください。
• レガシー -t, --testsetkey <key> (新しいレガシーエイリアス)も存在し、これらの値は新しい --test-set-keyに直接移植されます。
• レガシ --out junit|uipath には同等のフラグがありません。 uip tm result download には --output-format オプションがまったくありません。現在、JUnit XML のみがサポートされています (コマンド自体の説明はまさにそれを示しています)。
• レガシ --attachRobotLogs → 実行後に uip tm attachment download --execution-id <id> を使用して成果物をアタッチします。
• レガシ --retryCount <n> → uip tm executions retry --execution-id <id> 完了した実行の失敗したケースのみを再実行します。起動時に自動リトライ フラグはありません。上記の report get exit-branchでスクリプトを作成します。

並列テスト

従来のtest parallelを反映するuip動詞はありません。最も近いイディオムは、複数の uip tm testsets run 呼び出しを同時に起動し、各 ExecutionIdをキャプチャし、それぞれを待機するシェル ループです。

# Launch in parallel (bash)
EXEC1=$(uip tm testsets run --test-set-key DEMO:10 --output-filter Data.ExecutionId --output plain) &
EXEC2=$(uip tm testsets run --test-set-key DEMO:11 --output-filter Data.ExecutionId --output plain) &
wait

# Then wait on each
uip tm wait --execution-id "$EXEC1" --project-key DEMO --timeout 1800 &
uip tm wait --execution-id "$EXEC2" --project-key DEMO --timeout 1800 &
wait

レガシ --testsConfigurationFilePath スキーマ (プロジェクトごとのパスとそのテスト セットを一覧表示) には、 uip スキーマに対応するものがありません。CIマトリックスまたはテストセットキーの単純なシェルリストからループを駆動します。

アセット

レガシ コマンド	uip 相当	備考
uipcli asset deploy <csv> <url> <tenant>	行ごとに uip or assets create <name> <value> のループオーバー	削除 — 置換: シェル ループで CSV を反復処理し、行ごとに create 呼び出します。新しい CLI では、1 回限りの CSV デプロイは提供されません。「 UIP」または「アセット」をご覧ください。
uipcli asset delete <csv> <url> <tenant>	行ごとに uip or assets delete <key> --yes のループオーバー	削除 — 置換: キーによる反復処理と削除。delete は名前ではなくアセットの GUID を受け取ります。最初に を使用して名前をキーに解決します uip or assets list --folder-path <path>を使用します。-y, --yes が必要です。CLI はプロンプトを表示しません。

# Legacy — bulk CSV
uipcli asset deploy "C:\assets.csv" "https://cloud.uipath.com/" "TenantName" \
    -A "myOrg" -I "<app-id>" -S "<app-secret>" \
    --applicationScope "OR.Assets" -o "Shared"

# uip — script the loop
# CSV columns: name,type,value,description
while IFS=, read -r NAME TYPE VALUE DESCRIPTION; do
    [ "$NAME" = "name" ] && continue    # skip header
    uip or assets create "$NAME" "$VALUE" \
        --folder-path Shared \
        --type "$TYPE" \
        --description "$DESCRIPTION"
done < assets.csv

注:

レガシの Credential タイプのアセットでは、[ username::password 値] 形式が使用されます。uip or assets createでは、資格情報の値の形式は username:password (単一のコロン) になり、シークレットには --credential-store-key <guid>が必要です。「 uip またはアセット — 作成」をご覧ください。

ソリューション

レガシ コマンド	uip 相当	備考
uipcli solution pack <path>	uip solution pack <solutionPath> <outputPath>	意図に応じて 1 対 1 です。出力は両方の世代で .zip です (内部 .nupkg ファイルを含む)。引数の形状が -o から定位置出力ディレクトリに変更されました。
uipcli solution analyze <path>	uip rpa analyze <project> プロジェクトごと	N ステップ。ソリューション内の各プロジェクトでアナライザーを実行する uip solution analyze 動詞は1つではありません。
uipcli solution restore <path>	uip rpa restore <project> プロジェクトごと	N ステップ。solution analyzeと同じパターンです。
uipcli solution upload-package <zip>	uip solution publish <zip>	1:1.新しい名前は publishです。動作 (テナントのソリューション フィードにアップロード) は変更されません。
uipcli solution download-package <name> <version>	直接に相当するものはありません	削除 — 置換: 基になる .nupkg パッケージを uip or packages download <key>でダウンロードするか、パブリッシュ済みのソリューション レコードを Orchestrator REST API 経由で取得します。
uipcli solution delete-package <name> <version>	uip solution packages delete <packageName> <packageVersion> --yes	1:1、および必須の -y, --yes 確認フラグ (レガシでは必要ありません)。
uipcli solution download-config <name>	uip solution deploy config get <package-name> [--package-version <v>] [-d <path>]	1:1.
uipcli solution deploy <...>	uip solution deploy run --name <n> --package-name <n> --package-version <v> --folder-name <n> [--parent-folder-path <path>]	意図的に1:1;フラグ名が変更されました。--name はパッケージ名ではなく デプロイ 名です。first-pipeline.md — ステップ3を参照してください。
uipcli solution deploy-activate <...>	uip solution deploy activate <deployment-name>	1:1.
uipcli solution deploy-uninstall <...>	uip solution deploy uninstall <deployment-name>	1:1.

# Legacy — pack + upload + deploy, one verb each
uipcli solution pack "C:\my-solution" \
    -o "C:\dist" \
    -v 1.2.0
uipcli solution upload-package "C:\dist\my-solution.1.2.0.zip" \
    "https://cloud.uipath.com/" "TenantName" \
    -A "myOrg" -I "<app-id>" -S "<app-secret>" \
    --applicationScope "OR.Folders"
uipcli solution deploy "..." "..."

# uip — publish replaces upload-package; positional --version in pack
uip login --client-id env.UIPATH_CLIENT_ID --client-secret env.UIPATH_CLIENT_SECRET --tenant TenantName
uip solution pack ./my-solution ./dist --version 1.2.0
uip solution publish ./dist/my-solution_1.2.0.zip
uip solution deploy run \
    --name "my-solution-deployment" \
    --package-name my-solution \
    --package-version 1.2.0 \
    --folder-name MySolution \
    --parent-folder-path Shared

各ステップの説明を含むチュートリアルについては、「 最初のパイプライン 」を参照してください。

実行

レガシ コマンド	uip 相当	備考
uipcli run <arguments.json>	直接に相当するものはありません	削除 — 置換: パイプライン ステップを、フラグを使用して uip を直接呼び出すシェル スクリプトとして書き換えます。従来の run 動詞は、完全な uipcli <verb> <args> 呼び出し (非表示の --captureCommandToJsonFile フラグによって生成される) をシリアル化する JSON ファイルを使用していました。 uip に相当するものは出荷されません。

注:

1.x CLI では、一括引数リプレイ用のユニバーサル --from-file フラグは公開されていません。パイプラインがこのパターン (従来の captureCommandToJsonFile + uipcli run ワークフローで一般的) に依存している場合は、JSON ペイロードを uip の直接呼び出しに変換します。

同等のレガシがないコマンド

これらの uip 動詞には、従来のCLIに対応する動詞はありません。 uipcli だけでは不可能だったワークフローを開きます。どれも移行の必要はなく、新機能です。

• uip login、 uip login tenant list/set、 uip logout、 uip login status — 完全なセッション管理。
• uip or folders *、 uip or machines *、 uip or users *、 uip or roles *、 uip or licenses *、 uip or sessions *、 uip or audit-logs *、 uip or calendars *、 の uip or credential-stores *、 uip or feeds *、 uip or settings * — Orchestrator の完全な管理画面
• uip or jobs list / get / stop / restart / resume / logs / traces / healing-data / history、 uip or processes list / get / edit / update-version / rollback、 uip or packages list / get / versions / entry-points / download — レガシーが公開しなかった内省動詞。
• uip or assets / buckets / bucket-files / libraries / queues / queue-items / triggers / webhooks — Orchestrator のランタイム リソースの CRUD。
• uip agent *、 uip codedagent *、 uip codedapp *、 uip maestro flow *、 uip maestro *、 uip api-workflow *、 uip df *、 uip insights *、 uip traces *、 uip docsai *、 uip vss * — まったく新しい表面。
• uip eval *、 uip gov *、 uip admin *、 uip tasks *、 uip aops *、 uip llm-configuration *、 uip llm-gateway *、 uip guardrails *、 uip model-hub *、 uip platform *、 uip ixp *、 uip pm *、 uip coder *、 uip ah *、 uip agenthub *、 uip conversational *、 uip context-grounding *、 uip function * — レガシ CLI は一切含まれない、さらに 18 個のスタンドアロン ツール パッケージを追加しました。
• uip solution deploy upgrade / status / list、 uip solution feeds list、 uip solution project *、 uip solution resource *、 uip solution cleanup、 uip solution init、 uip solution download、 uip solution run — レガシのパック/パブリッシュ/デプロイ フローを超えるソリューション ツールの動詞です。
• uip tools *、 uip skills *、 uip mcp、 uip completion — ホストレベルの管理。

参照

• フラグの名前変更 — uipcli と uipの間で名前が変更されたすべてのフラグをマッピングルールで変更します。
• 破壊的変更 — 名前変更の背後にある意味的変更(認証、stdout形式、終了コード)。
• パイプラインの例 — Azure DevOps と Jenkins のパイプラインの前/後
• 参照インデックス — すべての uip ツールと動詞を 1 か所にまとめました。