0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【UiPath】移行改修影響調査のすすめ

0
Last updated at Posted at 2026-05-18

はじめに

  • 本記事は、UiPathの旧ロボットの最新化を検討されている方向けに、影響調査や改修優先度の付け方で参考になる情報を扱います。
  • 記事の内容は、個人の見解または確認結果であり、UiPath の公式見解ではありません。
  • 製品仕様や参考画像はUiPath Studio 26.0.192 STSバージョンのもので構成しています。

影響調査の進め方

影響調査は次のステップで進めます。

【STEP1】 移行ロボット情報整理

  1. 移行ロボットのプロジェクトファイルの収集
  2. 移行ロボット一覧の作成
  3. 処理概要、ステップ数、依存パッケージ、トリガー、対向システム・操作対象アプリ、テスト環境の有無などの情報を整理する

ロボットの仕様書き出し便利ツール

PJDocument:プロジェクトで使用しているxamlファイル、アクティビティ、変数、引数・ワークフロー呼び出し・セレクタの一覧をHTML出力するスニペット

PJDocument の使い方は以下の記事を参考:

ステップ数=アクティビティの数

image.png

アクティビティの数はワークフローアナライザーの「ST-ANA-009」で簡単に計測できます。

image.png

複数プロジェクトを一気に確認したい場合、次の様なシェルスクリプトの作成・利用を勧めます。
(Get-ChildItem -Path "C:\UiPath\MyProject" -Filter *.xaml -Recurse | Select-String -Pattern "displayName" -AllMatches).Count

依存パッケージの出力

Newtonsoft.Json.Linq.JObject.Parse(System.IO.File.ReadAllText("★project.jsonのパス"))("dependencies").ToString().Replace("{","").Replace("}","").Replace("""","").Trim()

↑★の部分だけ変更すればOK

タイムトリガーの実行タイミングとプロセス名の取得

APIワークフローの利用がお勧め

GetTriggerInfo.png

(Autopilot向けの指示文サンプル)

Orchestratorのトリガー情報を取得するAPIワークフローの作成をお願いします。

利用するエンドポイント: "
https://cloud.uipath.com/{★組織ID}/{★テナント名}/orchestrator_/odata/ProcessSchedules
"
Selectするフィールド: 
実行タイミング、プロセス名、表示名

<補足> 
・実行タイミングは「StartProcessCronSummary」の値を利用 
・紐づくプロセス名は「ReleaseName」の値を利用
・トリガーの表示名は「Name」の値を利用

(①のプロパティ:ヘッダーパラメータの例)

{ "X-Uipath-Organizationunitid": "★" }

(①のプロパティ:クエリパラメータの例)

{ "$select": "Name,ReleaseName,StartProcessCronSummary,StartStrategy" }

(②のプロパティ:スクリプトの例)

const schedules = $context.outputs.getProcessSchedules.content.value;
if (!schedules || !Array.isArray(schedules)) {
    return [];
}

const mappedSchedules = schedules.map(schedule => ({
    "ExecutionTiming": schedule.StartProcessCronSummary,
    "ProcessName": schedule.ReleaseName,
    "DisplayName": schedule.Name
}));

return mappedSchedules;

(出力例)
image.png

プロセスの平均処理時間と実行回数の取得

こちらはInsightsでカスタムダッシュボードを作成するのが簡単でお勧め
プロセス名をディメンションに、カスタムメジャーフィールドとして「ジョブの実行時間_平均」と「ジョブの実行回数」などを追加すればOK

image.png

(カスタムメジャーフィールドの編集画面例)
image.png

Windows11にアップデートする際の影響調査ポイント

以下の利用状況の事前確認をすすめます。(※以下はわたしが把握している限りであってすべてではありません)

  • 「文字を入力」アクティビティ ← IMEの影響で全角/半角が切り替わったケースあり
  • メモ帳アプリ ← セレクタの変更が確認されている
  • 「名前を付けて保存」の操作 ← セレクタの仕様変更でウィンドウセレクタを個別に認識させる必要あり
  • ペイントアプリ ← 従来操作だと画像が開けなくなる
  • エクスプローラーへのNASアドレス入力 ← ID/PASSの入力を求められるので、事前にNASの指定アドレスのローカル割り当てるなどが必要
  • 256文字以上のファイルパス ← レジストリでロングパスを有効化しないといけない
  • EXCELアプリケーションスコープ ← 不明なエラーが出ることがあるのでOffice修復をかけてください
  • Edge ← ブラウザの起動遅延があるので適当に待機などいれましょう
  • グループポリシー ← 設定によっては、ローカルRDPセッションにおいて TLS/NLA のセキュリティ方式が許可されておらずUR実行エラーになる可能性あり / 「Outlook セキュリティ モード」の設定によりメールが送信できなくなる可能性あり

【STEP2】 パッケージ最新化の影響確認

  1. 依存パッケージの最新化 ※ランタイムの変更(「Windows - レガシ」 → 「Windowsプロジェクト」への変換はパッケージの最新化の後に実施しましょう。「Windows - レガシ」プロジェクトはStudio/Robot v2024.10のサポート期間中(2027年10月)まで継続利用可能(サポート期限の公式発表がないため現在提供中のサポートバージョンのエンドで仮記載)なため、対象ロボットの利用予定を加味して移行を計画しましょう。
  2. 上記でパッケージを更新した際に破損したアクティビティパッケージの情報を移行ロボット一覧に追記する

「Windows - レガシ」から「Windows」プロジェクトへのマイグレーションについては以下の記事を参考にしてください。
https://forum.uipath.com/t/windows-windows/2772862

アクティビティの破損について

以下は、共通部品を改修する際に注意が必要なパッケージ更新仕様の記事です。

パッケージを最新化した際、互換性がなくなったアクティビティについてはStudio上で正常に表示されなくなります。

(例)
image.png

互換性を失う理由は単純に同名のアクティビティが上位バージョンのパッケージに存在しないというケースだけではなく、プロパティの仕様変更引数の名称変更などもあります。
このため、インストール済みのアクティビティの単純な差分では拾い漏れが生じる可能性があるので、Studio上でパッケージ更新をかけるのが確実です。

(参考 - Studioの標準アクティビティの変遷)

【STEP3】 代替実装の検討

  1. 破損したアクティビティの処理の代替実装方針を検討・試験する
  2. 上記の検討・試験結果を踏まえた移行方針を移行ロボット一覧に追記する

改修優先度付け

重要度の色づけ

【STEP1】 テスト環境が“ない”

  1. テスト環境がないロボットの検証方針を依頼主とすり合わせる
  2. 対象データの発生が稀で試験可能期間が限られる、または本番で処理を動かさないと業務アウトプットの確認ができないロボットを「優先度:最高」とする

【STEP2】 業務インパクト

  1. 正常に動作しなかった際の本番運用影響が極めて大きい(支払に影響が出る、稼働時間が長い、実行回数が多い、手動でのリカバリ・代替運用が困難など)ロボットを「優先度:高」とする

【STEP3】 改修難易度

  1. 破損したアクティビティの代替実装が複雑、または改修時に手を入れる範囲が広いロボットを「優先度:中」とする
  2. 上記以外を「優先度:低」とする
順位 重要度 説明
1 最重要 改修時テストの実行制限が多い
2 重要 業務インパクトが大きい
3 一定以上の改修ボリュームが認められる
4 改修不要または改修ボリュームが限定的な見込み

未知リスク度の色づけ

【STEP1】 未標準化

  1. 改修手順が確立されている → 手順化済み
  2. 上記以外 → 未手順化

不確実性の高いものは重要度より優先して確認しましょう

【STEP2】 横展開性

  1. 複製開発で差分が軽微、またはConfigを変更してパブリッシュしているだけ → 横展開性あり
  2. 上記以外 → 横展開性なし

横展開性のあるものは優先着手することで全体感が早期にクリアになります。

【STEP3】 分岐複雑度

  1. 分岐が多い(単純分岐のみは問題なし)、かつ、ネストの中で更に分岐が続くつくりになっている → 複雑分岐
  2. 上記以外 → 単純分岐

【STEP4】 未知リスク度のラベリング

順位 未知リスク度 説明
1 最高 未手順化 and (横展開性あり or 複雑分岐)
2 未手順化 and (横展開性なし or 単純分岐)
3 手順化済み and (横展開性あり or 複雑分岐)
4 手順化済み and (横展開性なし or 単純分岐)

移行改修時に網羅テストを実施することは現実的に難しいため、カバレッジが低くなりやすいワークフローを優先着手し、効率よくテストを実施するためのパターンを依頼主に確認しましょう。

未知リスク度 * 重要度でソート

移行ロボット一覧に「未知リスク度」と「重要度」の順位を入力できたら、
「未知リスク度」の列を最優先にして未知リスク度 * 重要度でソートしましょう!

(イメージ)

ロボット 未知リスク度 重要度
SAP月次 最高 最高
Citrix登録 最高
共通Mail 最高
単純Excel 最高

さいごに

いかがでしたでしょうか。
ロボットを改修する際は一定期間コードフリーズする必要があります。
利用者向けに納得感のある説明をするためにも影響調査と改修優先度付けのロジックは明確にしておきましょう!
これから移行改修に取り組み方に少しでもお役に立てれば幸いです。
最後までお読みいただきありがとうございます(´▽`)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?