UiPath Studio・Robotのバージョンアップ方法とは？自動更新とバッチ配布を実例で解説

公開日：2026年9月

UiPathのデスクトップクライアントであるStudioとRobot（Robotの操作を行うUiPath Assistantを含む）は、業務プロセスを自動化するロボットの設計・開発・保守を支える重要な基盤です。長期運用においては、バージョンアップを単なる機能追加ではなく、開発環境と実行環境の互換性、セキュリティ、サポート期間、そして業務継続性を支える管理活動として考える必要があります。
本稿では、UiPath StudioとRobotのバージョンアップを実施する代表的な二つの方法を取り上げます。一つはUiPathが提供する自動更新機能を利用する方法、もう一つは自動更新を利用せずにインストーラーと実行用バッチを社内の配布基盤から展開する方法です。
自動更新は作業負担を抑えやすい一方、組織のルールやネットワーク環境によっては適用が難しい場合があります。バッチ配布は準備や管理に手間がかかるものの、更新時期、対象端末、検証手順、実行結果を細かく統制できます。両方式の特徴を理解し、自社の業務特性に合った方法を選ぶことが重要です。

1．自動更新機能とは

UiPathの自動更新機能は、各クライアント端末で利用しているStudioとRobotを、UiPathが提供する更新情報に基づいて新しいバージョンへ移行するための仕組みです。利用者がインストーラーを手動で取得・実行する作業を減らし、端末を一定のバージョンに保ちやすくすることを目的としています。
具体的には、クライアントが更新情報を確認し、適用可能なバージョンを検知したうえで、必要なインストール処理を実行するという流れでバージョンアップします。

図1はマシンオブジェクトごとに自動更新を設定する画面、図2はユーザーごとに自動更新を設定する画面を示しており、画面のプルダウンを設定するだけで自動更新機能を利用できます。プルダウンの各選択肢の違いは以下の通りです。

表1：プルダウンの各選択肢の違い

「最新のパッチ」や「特定のバージョン」を選択した場合は、さらにプルダウンが表示され、インストールするバージョンを選択します。

また、マシンオブジェクトごとの自動更新機能ではスケジュールを設定することができ、自動更新を実施するタイミングを制御することができます。
「その他オプション」で設定しているウィンドウの合計時間以内に更新が完了しなかった場合は、次に実施可能なメンテナンスウィンドウ（更新を実施してよい時間帯）に再スケジュールされます。

なお、実際の対象バージョンや通知方法、実行タイミング、再起動の扱い、必要な権限や設定条件は、利用するUiPath製品のバージョンおよび仕様によって異なる場合があります。導入前には必ず、対象バージョンの公式ドキュメントと自社環境の設定を確認してください。
自動更新機能を利用するための前提条件は以下の通りです。

表2：自動更新機能を利用するための前提条件

Robotの自動更新機能を有効化する場合、2021.10以降のUiPathStudio.msi、または2024.10以降のUiPathRobot.msiを使用して、Robotアプリケーションをインストールする必要があります。

より詳細な自動更新機能については、UiPathの公式ドキュメントに記載されています。
https://docs.uipath.com/ja/orchestrator/automation-cloud/latest/user-guide/auto-updating-client-components

2．バッチ配布が必要となる背景

本章では、1章の自動更新機能の説明を踏まえ、バッチ配布によるバージョンアップが必要となる場合の背景についてお話します。
1章で紹介した通り、自動更新機能は利用者の作業負担を抑えながら迅速に最新化したい場合に適しています。
一方で、バッチ配布が有効なバージョンアップ手段となるケースもあります。
厳格なプロキシや外部通信の制限などにより、クライアントが更新情報やインストーラーを取得できない環境である場合です。その場合には、承認済みのインストーラーを社内へ持ち込み、配布基盤から適用する方法が現実的です。
また、自動更新機能の公式ドキュメント内では「前のバージョンと同じ設定を保持したまま、新しいバージョンがマシンにインストールされます。」と記載されていますが、筆者が支援した一部環境では、NLog.configなどの設定ファイルが初期状態に戻る事象を確認しました。その場合には、自動更新後に設定ファイルを手動で差し替える必要があります。バージョンアップ対象の端末が少ない場合には、手動による差し替えも可能ですが、端末が多い場合には手動で差し替える手間が大きくかかります。そこで、バージョンアップと設定ファイルの差し替えを実施するバッチの配布が選択肢になります。
自動更新の利便性とバッチ配布の統制性を比較し、自社のネットワーク、業務影響、運用体制に合う方式を選ぶことが重要です。

3．バージョンアップの手順

本章では、自動更新機能を利用する場合と、インストーラーを含むバッチを配布する場合の手順を分けて説明します。いずれの方式でも、最初に対象バージョン、対象端末、実施日、担当者、問い合わせ窓口を決めておきましょう。

表3：UiPathの自動更新機能を利用する手順

表4：自動更新を利用せず、インストーラーを含むバッチを配布する手順

4．バッチ配布 によるバージョンアップ時に考慮すべきこと

本章では、筆者が配布バッチを用いてバージョンアップを実施したプロジェクト経験をもとに、実施時に考慮すべきことを紹介します。

前提として環境は以下の通りです。

表5：実プロジェクトにおけるバージョンアップ対象環境

まずは、バッチの配布と展開の方法についてです。社内の配布基盤を利用することで比較的容易に達成できますが、環境によっては社内の配布基盤が利用できないケースも考えられます。
実際のプロジェクトでは次のような問題が発生しました。
配布バッチの実行には対象端末へのインストールやシステム設定の変更を伴うため、管理者権限が必要ですが、管理者権限は社内の申請や承認手続きを経て付与される方針だったため、バッチの配布と展開を手動で実施する必要がありました。さらに、現行バージョンのEOSL（End of Service Life：製品のサポート終了） が近づいていたため、期限を踏まえて計画的に実施する必要がありました。具体的には、バッチの実行作業は3名で分担し、約3カ月の期間ですべての端末にバージョンアップを適用することがミッションでした。
次に、これらの状況を踏まえて、作成するバッチの検討です。
人による作業量を減らすために、実行するだけでバージョンアップや環境構築、実行結果の検証が可能となるようなバッチの作成を目指しました。
社内環境や方針によってバッチに求められることは変わるため、参考程度ですが以下のような処理を含めることを意識してバッチを作成しました。

表6：バージョンアップ用バッチに実装した処理内容

最後に、バージョンアップで不具合が発生した場合の復旧方針をあらかじめ検討します。
不具合を確認した際は、対象端末、発生日時、エラーメッセージなどを確認して状況を把握し、影響範囲と業務への影響度を判断します。影響が大きい場合は、バッチの実行や配布を一時停止し、被害の拡大を防ぎます。そのうえで、必要に応じて問題が発生した端末を対象に個別対応を行います。
個別対応では、UiPath StudioやRobotのアンインストールとバッチの再実行をします。早急な復旧が難しい場合に備え、更新前のバージョンへ戻すためのバッチを事前に用意しておくことも重要です。
バッチ処理では、バージョンアップ用のファイルを実行するだけではなく、社内環境や目的に合わせてその他の確認事項もバッチファイルで処理をすることで、手間を大幅に削減することができます。

5．自動更新機能とバッチ配布の比較

ここまで、自動更新とバッチ配布それぞれの手順（3章）と、バッチ配布の実際の運用例（4章）を見てきました。本章では、両方式を同じ軸で並べ、どの環境でどちらを選ぶべきかを整理します。
自動更新機能とバッチ配布の特徴を比較すると以下の通りです。

表7：自動更新機能とバッチ配布の特徴

ネットワークや端末権限が標準化されており、利用者や運用担当者の作業負担を抑えながら、短期間で更新したい場合は、クライアント自動更新が適しています。
一方で、部門や拠点ごとに段階展開したい場合、閉域網や通信制限環境で更新する場合、または設定ファイルの初期化・差し替えまで同時に行いたい場合は、バッチ配布が適しています。
実際の運用では、端末の重要度や環境に応じて、重要端末はバッチ配布、検証用端末や標準環境の端末は自動更新とするなど、両方式を組み合わせる方法も有効です。

6．まとめ

UiPath StudioとRobotのバージョンアップには、自動更新機能を利用する方法とインストーラーを含むバッチを配布する方法があります。自動更新機能は更新作業を簡素化しやすく、迅速な最新化に適しています。バッチ配布は、事前検証、対象範囲、実施時期、ログ、再実行を組織側で管理しやすく、統制を重視する環境に適しています。
重要なのは、方式の優劣を一律に決めることではなく、UiPathの構成、端末の重要度、ネットワーク制約、社内の変更管理、監査要件、運用担当者の体制を確認し、目的に合った方法を選ぶことです。
どちらを採用する場合でも、検証環境で主要な業務シナリオを確認し、更新後の問い合わせ窓口と復旧方針を準備しておくことが望ましいです。
更新を一度きりの作業として扱わず、更新手順や結果を手順書、FAQ、チェックリスト等へ反映することで、次回以降のバージョンアップ作業の品質向上や効率化につながることが期待できます。適切な計画と記録をもって実施すれば、安定した業務自動化基盤として継続利用するための土台を整えられます。

さいごに

TISIでは、UiPathの導入から運用後の課題解決まで、現場に寄り添ったサポートを行っています。今回ご紹介した内容以外にも、実際の現場で得られた知見が多数ございますので、UiPathの運用・バージョンアップについてお悩みの際は、ぜひTISIにご相談ください。

執筆者：星 尚徹

※本コラムはTISIエンジニアの実体験・知見に基づく内容を記載していますが、記載された情報や手順が全ての環境で同様に動作することを保証するものではありません。万が一、本コラム内容を参考にしたことによる損害等が生じた場合、当社は責任を負いかねますのでご了承ください。また、記載されている情報はコラム公開時点のものであり、予告なく変更される場合があります。
※本文記載の社名・製品名・ロゴは各社の商標または登録商標です。

お問い合わせ

＜TISの［RPA業務自動化ソリューション：UiPath］について確認する＞

バックナンバー

RPA開発現場のリアルレポ！ #8
TISIエンジニアが解説！RPA運用品質の考え方と実践ガイド

RPA開発現場のリアルレポ！ #7
サポート終了目前？古いロボットから脱却しよう！～Windowsレガシプロジェクト移行における教訓～