自動化

UiPathとは?三層構成・ライセンス・LTS運用から導入判断まで実装目線で解説【2026年版】

UiPath(ユーアイパス)は、画面操作の自動化を出発点に、AIエージェントや業務プロセスの統制までを一つの基盤にまとめた業務自動化プラットフォームです。実装を担当する立場で最初に押さえたいのは、製品カタログの広さではなく「開発・実行・管理がどう分かれているか」「どのバージョンを本番に置くか」「上限と課金が設計をどう縛るか」の三点でしょう。この記事では機能紹介ではなく、構成・実行形態・バージョン運用・料金という実装の四つの軸から、採用の可否を判断できるところまで整理します。

まとめ:UiPathを採る条件と別解に回すべき条件

先に結論を書きます。UiPathが噛み合うのは、次の三つが同時に成り立つ場合です。第一に、自動化したい業務がWindowsデスクトップアプリや社内Webシステムを含み、APIだけでは処理を完結できないこと。第二に、ロボットの本数が十数本を超えて増える見込みがあり、実行スケジュールと権限と証跡を一元管理する必要が出てくること。第三に、開発を担う人員を社内に置き、テンプレート化と教育まで含めた運用体制を組む意思があることです。

逆に別解へ回したほうがよい場面もはっきりしています。対象システムがすべて公開APIを備えているなら、画面操作を挟まず連携基盤で直結するほうが壊れにくく、実行コストも下がる構成です。自動化したい業務が数本で、しかも今後増える見込みがないなら、ライセンス費と運用体制の固定費が回収できません。加えて、業務手順そのものが月単位で変わり続ける領域では、画面依存の自動化は保守で赤字になります。製品を横断して選定軸から比べたい場合はRPAツール比較|UiPath・WinActor・BizRobo!など主要6製品の選び方を先に読むと判断が早くなります。

UiPathとは何か:開発・実行・管理の三層構成で捉える製品の実体

UiPathという名前は単一のソフトウェアを指しません。実装者の視点で骨格だけ抜き出すと、開発する層・実行する層・管理する層の三つに分かれます。この三層を混同したまま見積もりを組むと、ライセンス本数もサーバー構成も外れます。

開発する層がStudioです。アクティビティと呼ぶ処理部品をフローチャート状に並べてワークフローを組み立て、変数と例外処理を定義し、デバッグ実行で挙動を確かめます。実体としてはWindows上で動くIDEで、成果物はNuGetパッケージ形式で発行されます。ブラウザだけで開発を完結させる系統としてStudio Webも用意されており、こちらの詳細はUiPath Studio Webとは?デスクトップ版との違い・できること・始め方にまとめました。

実行する層がRobotです。発行されたパッケージを受け取り、対象アプリケーションを操作します。ここは人の隣で動くAttendedと、無人環境で動くUnattendedに分かれ、後述するとおりライセンスも設計思想も別物になります。

管理する層がOrchestratorです。パッケージの配布、実行スケジュール、キューによる処理対象の配分、資格情報の保管、実行ログと監査証跡の集約を担う役割です。ロボットが1本のうちは不要に見えますが、本数が増えた瞬間に、どの端末でいつ何が動いたかを追えるかどうかが運用の生死を分けます。レコーディング機能まわりの挙動はUiPath Orchestratorにおけるレコーディング機能の概要と特徴で扱っています。

三層を経由する処理の流れと障害対応に備えた責任分界点の置き方

典型的な流れはこうなります。開発者がStudioでワークフローを作り、Orchestratorへパッケージを発行する。運用担当がそのパッケージをプロセスとして環境に割り当て、トリガーを設定する。時刻または外部イベントでOrchestratorがジョブを生成し、対象のRobotへ配信する。Robotが処理を実行し、結果とログをOrchestratorへ返す。

設計上の要点は、責任分界点をOrchestratorに置くことです。ロボットが失敗したときに「誰がどこを見るか」を、開発側とインフラ側と業務側で切り分けておく。ジョブの失敗はOrchestratorのログで一次切り分けし、対象アプリの画面変更が原因ならワークフロー修正へ、端末やネットワークが原因ならインフラへ回す。この経路を最初に文書化しておくと、障害時の押し付け合いが起きません。

Orchestratorは外部から操作するためのREST APIも備えており、既存の運用基盤からジョブを起動する構成が取れます。おおまかな呼び出しの形は次のようになります。エンドポイントとパラメータは版によって変わるため、実装前に公式のAPIリファレンスで現行仕様を確認してください。

POST /odata/Jobs/UiPath.Server.Configuration.OData.StartJobs
Authorization: Bearer <access_token>
X-UIPATH-OrganizationUnitId: <folder_id>
Content-Type: application/json

{
  "startInfo": {
    "ReleaseKey": "<release_key>",
    "Strategy": "ModernJobsCount",
    "JobsCount": 1,
    "InputArguments": "{\"in_TargetDate\":\"2026-07-31\"}"
  }
}

プラットフォーム全体像:発見・自動化・運用・エージェンティックの4レイヤー

公式の製品ページでは、構成要素が発見・自動化・運用・エージェンティックという区分で整理されています(2026年7月31日時点)。実装者が全体像を把握するには、この区分を業務の時間軸に読み替えると理解が早くなります。何を自動化するか決める段階、作る段階、回す段階、そしてAIエージェントを組み込む段階です。

レイヤー 主な構成要素 担う役割
発見 業務・タスクの分析製品群 自動化対象の抽出と優先順位づけ
自動化 開発・実行・連携の製品群 ワークフローの開発と実行
運用 統制・分析・テストの製品群 配布・統制・効果測定
エージェンティック AI構築・指揮・支援の製品群 AIエージェントの構築と統制
基盤 クラウド・自社ホスト基盤 SaaS型と自社ホスト型の提供形態

表中の製品群には、発見層のProcess Mining・Task Mining・Communications Mining・Automation Hub、自動化層のStudio・Robots・Assistant・Apps・Document Understanding・Integration Service・Data Service・Action Center、運用層のOrchestrator・Automation Ops・Insights・Test Manager・AI Centerが含まれます。エージェンティック層はMaestro・Agent Builder・Autopilot、基盤層はAutomation Cloud・Automation Suiteに対応します。

導入初期にすべてを揃える必要はありません。実務では、StudioとAttended Robotだけで数本作って効果を確かめ、本数が増える見通しが立った時点でOrchestratorを入れ、非定型の帳票処理が壁になったところでDocument Understandingを足す、という順序が現実的です。発見レイヤーの製品は、自動化対象の候補が社内で出尽くさなくなってから検討しても遅くはありません。

提供形態はAutomation Cloudによるクラウド利用と、自社の基盤へ載せるAutomation Suiteの二択です。データを国外へ出せない要件や、閉域ネットワーク内の業務システムしか触らない構成では後者を選ぶことになりますが、Kubernetes基盤の構築と維持が前提になるため、インフラ側の体制がないまま踏み込むのは勧めません。

実行形態の選び分け:AttendedとUnattendedの設計差

ライセンス費と設計の両方に効くのがこの分岐です。名前は実行の有人・無人を指しますが、実装上の違いはそれ以上に大きくなります。

Attended Robotは、担当者の端末上で、その人のログオンセッションを使って動きます。人が画面を見ている前提なので、途中で確認ダイアログを出したり、判断を人に返したりする処理を組み込めます。処理の起点は人のクリックやショートカットで、対象は問い合わせ対応中の情報収集や、申請入力の下書き生成といった、人の作業に寄り添う領域です。

Unattended Robotは、無人の実行環境で動きます。仮想デスクトップやサーバー上のセッションを占有し、Orchestratorのスケジュールやキューに従って処理を回します。人が見ていないため、例外が起きたときに止まって待つ設計は成り立ちません。すべての分岐を事前に定義し、想定外は例外として記録して次の対象へ進む作りにする必要があります。

観点 Attended Unattended
実行環境 担当者の端末 無人の専用セッション
起動方法 人の操作 スケジュール・キュー・API
例外時の扱い 人が介入できる 記録して継続または中断
資格情報 担当者の権限を利用 専用アカウントを保管して払い出し
向く業務 判断が挟まる対人業務 大量・定型・夜間バッチ

実装で見落とされやすいのがUnattended側のアカウント設計です。専用のサービスアカウントを用意し、対象システムの権限を必要最小限に絞り、資格情報はOrchestratorの保管領域から実行時に払い出す。この形にしておかないと、担当者の個人アカウントでロボットが動き続け、異動や退職のたびに全ロボットが止まります。監査の観点でも、誰の権限で何が行われたかを説明できなくなります。

AIエージェント機能の現在地:三製品の役割と導入時の判断基準

2025年以降のUiPathは、決められた手順をなぞるロボットに加えて、判断を伴う処理をAIエージェントへ委ねる方向へ製品を広げています。実装者としては、この三つの名前が指す層の違いを取り違えないことが肝心です。

Autopilotは開発と業務の支援にあたる層です。自然言語の指示からワークフローの骨格を生成したり、業務担当者の作業を対話で補助したりします。導入時の効き方はUiPath Autopilot for everyoneとは?機能・使い方・必要ライセンスとファミリー3種の違いで詳しく扱いました。

Agent Builderは、業務判断を担うAIエージェントそのものを作る層です。エージェントに渡す指示、参照させるデータ、呼び出せるツール(既存のロボットやAPI)を定義し、人の承認を挟む地点を設計します。

Maestroは、それらを束ねて業務プロセス全体を指揮する層です。BPMN 2.0という業務プロセス記述の標準記法でプロセスをモデル化し、AIエージェント・ロボット・人・外部システムの間の受け渡しを一つの流れとして実行します。2026年6月18日には、手順が固定しきらない例外の多い業務を扱うMaestro Caseも発表されました。

実装判断としては、いきなりエージェント前提で組まないことをお勧めします。手順が確定している処理は従来どおりワークフローで書いたほうが、結果が再現し、テストも書けます。エージェントを入れる価値が出るのは、入力の形式が揺れる、例外の分岐が事前に数え切れない、判断に文脈の読み取りが要る、という条件が揃った工程だけです。まずは既存のロボットを部品としてエージェントから呼べる形に整えておくと、後から段階的に移せます。

バージョン管理の要点:LTSとContinuous Releaseの選び分け

ここが本番運用でもっとも事故につながりやすく、しかも導入前に検討されにくい論点です。UiPathの版番号は年・月・パッチのカレンダーバージョニングで、公式ドキュメントでは「2020.10.2」のような表記(省略形は「20.10.2」)が示されています。数字が大きいほど新しいという以上の意味があり、系列によって支援期間がまったく違います。

系列は二つに分かれます。ひとつがContinuous Release、短期サポート(STS)の系列で、Studio・Robot・Assistantが対象です。公式のライフサイクル資料によれば、リリース間隔は2か月に一度で、これらのバージョンはAutomation Cloudとの接続を前提とします。新機能はここから先に入ります。2026年に入ってからも、3月にソース管理パネルとターミナルパネル、4月にWindows Defender Application Controlへの対応を含むDLLのコード署名、6月にStudioの拡張機能対応が加わりました(各月のリリースノート・2026年7月31日時点)。

もうひとつが長期サポート(LTS)の系列です。現行はStudioで2025.10系にあたり、公式のライフサイクル一覧ではStudio 2025.10.15が2025年10月30日リリース、メインストリームサポートの終了が2027年11月11日、延長サポートの終了が2028年11月11日と示されています。おおむね2年の主支援と1年の延長という構成です。LTS系列にも月次の累積更新(CU)が提供され、機能追加を抑えつつ不具合修正と安全性の更新を受け取れます。

観点 Continuous Release(STS) LTS
対象 Studio・Robot・Assistant 主要製品の広い範囲
リリース間隔 2か月ごと おおむね年1回
支援期間 短い 主支援2年+延長1年が目安
接続前提 Automation Cloud クラウド・自社ホストの両方
向く用途 新機能の検証・少数精鋭の開発 本番の大規模運用

選び分けの原則は単純です。本番のUnattended環境はLTSで固定し、更新はCUだけを当てる。検証環境と一部の開発者端末にContinuous Releaseを置き、次のLTSで入る機能を先に触っておく。この二本立てにしておくと、機能検証のために本番を動かす必要がなくなります。

もう一点、Studioの版とRobotの版、そしてプロジェクトの依存パッケージの版は、それぞれ別に管理される点に注意してください。開発端末のStudioだけ先に上げると、発行したパッケージが古いRobotで動かない事態が起きます。版の組み合わせはプロジェクト単位で記録し、更新は開発・検証・本番の順で足並みを揃えて上げるのが安全です。

ライセンスと料金:Automation Cloudのプランと無償枠の位置づけ

公開されている料金体系は、Automation Cloudのプラン区分として示されています。公式の日本語ページでは、ベーシックが月額25米ドルからと明示され、スタンダードとエンタープライズは問い合わせによる見積もりです(2026年7月31日時点)。ベーシックは個人単位の自動化と限定的な拡張性という位置づけで、エージェント込みの企業利用や複数リージョンでのホスティングはスタンダード以上に入ります。テスト自動化を主目的とする場合はTest Cloudという別系統のプランが用意されています。

実際の見積もりは、プラン料金だけでは決まりません。効いてくるのは次の四つです。Unattended Robotの本数、Attendedを配る利用者数、Document Understandingのようにページ数や件数で従量課金される機能の使用量、そして自社ホストを選ぶ場合の基盤費用です。とくにUnattendedは同時実行数がそのまま本数になるため、夜間バッチの時間帯が重なるほど必要本数が増えます。処理の時間帯をずらすだけでライセンス本数を減らせるケースは珍しくありません。種別ごとの割当単位、Unattended本数の逆算手順、三年間の総額まで踏み込んだ見積もりの組み立てはUiPathの料金・ライセンスとは?種別と割当単位・本数見積もりから導入判断まで解説で個別に扱っています。

無償で触れる手段は二つあります。ひとつはEnterprise Serverの60日間無料トライアルで、公式の案内ではStudio・StudioX・Orchestrator・Document Understanding・AI Center・Insights・Robots・Apps・Action Centerなどを含む構成が提供されます。もうひとつがCommunity Editionで、こちらは学習や評価を主眼とした位置づけです。ただし利用条件は過去に改定を重ねてきた経緯があるため、業務での使用を考える場合は必ず契約前に現行のライセンス条項を確認してください。無償枠のまま本番運用へ滑り込ませる進め方は、監査で指摘を受ける典型例です。

導入判断:UiPathを採用する条件と別解を採る場面を見極める基準

ここまでの構成と制約を踏まえて、判断の基準を言い切ります。UiPathを採用すべきなのは、次の三条件が揃うときです。

第一に、自動化対象にAPIを持たないシステムが含まれること。基幹の画面や取引先のポータル、あるいは業務用のWindowsアプリケーションのように、画面を操作するしか手段がない対象があるなら、そこはRPAの土俵です。第二に、ロボットが増える前提が立っていること。統制と証跡の仕組みは本数が増えるほど効いてくるため、数本で終わる想定ならOrchestratorの価値が出ません。第三に、社内に開発と保守の担い手を置けること。対象システムの画面が変われば自動化は止まるので、直せる人がいない構成は運用に入った瞬間から劣化します。

逆に、別解を採るべき場面は三つあります。対象がすべてAPIを備えているなら、画面操作を挟まず連携基盤で結ぶほうが安定しやすい構成です。対象業務が国内の中小規模に限られ、社内に英語資料を読む体制がなく、扱う本数も限られるなら、国内向けの製品も検討対象です。判断材料としてはWinActorとは?純国産RPAの仕組み・価格・エディションから導入判断まで実装目線で解説が対になります。そして自動化したい手順が四半期ごとに変わるなら、手順を固定してからでないと保守費が効果を上回ります。RPAという手法そのものの向き不向きから確かめたい場合はRPAとは?仕組み・できること・主要ツールと導入判断をわかりやすく解説から読み始めてください。

採用を決めた後に効いてくるのは、実は製品選定より定着のほうです。作れる人を増やし、命名規則と例外処理の型を揃え、作りっぱなしのロボットを棚卸しする仕組みを回す。この観点はUiPath導入後の教育・トレーニング支援の重要性と内容で整理しました。

一創では、UiPathの導入設計から開発、内製化の支援までを一貫してお引き受けしています。どこまで内製し、どこを外部に任せるかの線引きや、AttendedとUnattendedの本数見積もりから相談したい場合はUiPath導入支援サービスをご確認ください。既存システムとの連携方針を含め、実装前の設計段階からご一緒できます。

よくある質問

UiPathの読み方は何ですか?

読み方は「ユーアイパス」です。UIはユーザーインターフェース、Pathは経路を指し、画面を経由して業務をつなぐという製品の成り立ちが名前に表れています。日本法人はUiPath株式会社として国内向けの資料と支援を提供しており、公式サイトの日本語ページでも同じ表記が使われています。

UiPathとExcelマクロはどう使い分けますか?

境界は「処理がExcelの中で閉じるか」です。ブック内のデータ整形や集計だけならマクロのほうが速く、実行コストもかかりません。Excelから基幹システムへ転記する、Webサイトから取得した情報をExcelへ落として次のアプリへ渡すというように、複数のアプリケーションをまたぐ時点でUiPathの領域に入ります。実行の記録を残し、担当者以外でも保守できる形にしたい場合も、こちらへ寄せる理由になります。

Community Editionのまま業務で使い続けられますか?

推奨できません。無償版は学習と評価を主眼とした位置づけで、利用条件は改定されてきた経緯があります。業務での常用や商用利用の可否は契約時点の条項に依存するため、本番運用に入る前に必ず現行のライセンス条項を確認してください。機能を確かめたいだけであれば、Enterprise Serverの60日間無料トライアルを使うほうが、条項の解釈で悩む余地がありません。

Unattended Robotは何本必要になりますか?

本数は業務の数ではなく同時実行数で決まります。夜間の1時から3時までの間に5本のロボットを並行して走らせるなら5本必要ですが、順番に流して時間内に収まるなら1本で足ります。見積もりの手順としては、まず各処理の想定実行時間を測り、時間帯ごとに並べて重なりを可視化し、ずらせる処理を分散させてから必要本数を確定させてください。実行時間はデータ件数に比例して伸びるため、繁忙期の件数で見積もることをおすすめします。

対象システムの画面が変わるとロボットは止まりますか?

耐性を左右するのは設計です。画面上の座標に依存した実装は、レイアウトが少し動いただけで壊れます。要素の識別子や属性を使ったセレクター指定にしておけば、位置の変更には耐えられる場合が多くなります。それでも項目名や画面遷移そのものが変わればワークフローの修正は避けられません。対象システムの更新予定を事前に把握し、更新前に検証環境で通す運用を組み込んでおくのが、止めないための現実的な備えです。

関連記事

資料請求

RELATED POSTS 関連記事