UiPath StudioとStudioXの違いとは?プロファイルの境界・ライセンス・互換性から使い分けまで解説【2026年版】
UiPath StudioとStudioXは、カタログ上は並んで載っていても、実体としては別々の製品ではありません。同じStudioというアプリケーションの中に用意された二つのプロファイルであり、どちらを開くかで見えるアクティビティも、扱える変数の型も、プロジェクトの構造すら変わります。この記事は画面の見た目を並べるのではなく、開発者版と現場版の間にどこで線が引かれているのか、その線を越えたときに何が壊れるのかを実装目線で扱うものです。製品そのものの構成から確かめたい場合はUiPathとは?三層構成・ライセンス・LTS運用から導入判断まで実装目線で解説を先に読むと、この記事の前提が揃います。
まとめ:両者を分けているのは機能の多寡ではなく設計思想
先に結論を書きます。StudioXは機能を削ったStudioではなく、変数という概念を利用者から隠すという設計思想のもとで作られたプロファイルです。この一点から、扱えるアクティビティの範囲も、プロジェクトの構造の縛りも、すべて派生しています。したがって「StudioXでできないことをStudioで補う」という発想で境界を越えると、StudioX側から開けないプロジェクトが出来上がります。
配布前に決めるべきことは三つあります。第一に、現場担当者が触るプロジェクトの範囲をMain.xaml一枚に収める設計にするか。第二に、開発者がStudioプロファイルで手を入れたあと、現場側が引き続き編集できる状態を保つか、それとも保守を開発側で引き取るか。第三に、ライセンスの割り当てです。StudioライセンスからはStudioXへ降りられますが、StudioX向けのCitizen DeveloperライセンスからStudioへ上がることはできません。ここを取り違えると、開発者に配ったつもりのライセンスで開発ができないという事態が起こります。
加えて、2025.10系ではStudioXの機能がStudio側へ取り込まれ、プロファイルを切り替えずに設計できる方向へ動いています。導入時期によって前提が変わるため、後述の統合の項も併せて確認してください。
前提の整理:StudioXは独立した製品ではなくStudioのプロファイル
混乱の出発点は、StudioXを単体の製品だと考えてしまう点にあります。公式のFAQには、StudioXはUiPath Studioの中のプロファイルであり、使うにはStudioをインストールして認証し、StudioXプロファイルを選択する、と明記されています(2026年8月13日時点)。動作要件もStudioと同一です。つまり「StudioXをダウンロードする」という手順は存在せず、入手するものはStudioのインストーラー一つです。
実行環境についても同様で、StudioXと一緒にRobotが導入されます。このRobotは別のマシンへ切り離して置くことができません。現場担当者の端末で作って、その端末で動かす。この形が標準の使い方であり、後述するUnattended運用との相性の悪さもここに由来します。
StudioとStudioXのプロファイル切り替えで変わる画面・設定・構造の範囲
プロファイルの切り替えで変わるのは、アクティビティパネルに並ぶ項目だけではありません。設定できるプロパティの置き場所、既定で追加されるルートのコンテナ、プロジェクトに保存されるファイルの構成まで含めて切り替わる仕組みです。StudioX側ではアクティビティの主要な設定が本体(デザイナー上の枠内)に露出しており、プロパティパネルを開かずに済むよう組まれています。逆にStudio向けに作られたアクティビティは、細かい設定をプロパティパネル側に持たせているものが多く、StudioXの画面に置いても設定しきれない場合があります。
ブラウザ上で完結する開発環境という別の軸もあります。こちらはプロファイルではなく提供形態の話で、UiPath Studio Webとは?デスクトップ版との違い・できること・始め方で扱っています。「開発者版か現場版か」と「デスクトップかブラウザか」は独立した二つの軸なので、選定の場では混ぜないでください。
2025.10系で起きた統合:StudioXの機能がStudioへ入った
2025.10系のリリースノートには、StudioXの機能がStudioに統合され、プロファイルを切り替えずに自動化を設計できるようになった、と記載されています(2026年8月13日時点)。具体的には、Data ManagerからExcelファイルを接続すると、Use Excel Fileのスコープを置かずにワークフロー内でそのファイルを参照できます。StudioXのプロジェクトテンプレートもTemplatesタブへ入り、空のTaskテンプレートからProject Notebookを使えるようになりました。
同じリリースノートには、StudioXがStudio for Citizen Developersという呼称へ変わるという記載もあります。名前は変わるが同じプラットフォームであり、既存プロジェクトの継続も新規作成も従来どおり、という説明です。現場向けの入口が消えるわけではないため、運用設計を組み直す必要はありません。ただし社内の手順書やライセンス台帳で製品名を文字列一致で管理している場合、呼称の差で照合が外れることがあります。導入バージョンを上げる前に、名称の表記を確認しておくと手戻りを避けられます。
できることの境界:StudioXが届く範囲と、そこで止まる理由
StudioXで自動化できる対象は、公式FAQでは四つに整理されています。Webとデスクトップのアプリケーション操作(フォーム入力、データ抽出など)、Excel・Word・PowerPointといったOffice製品の操作、Outlook・Exchange 365・Gmailを対象としたメールとカレンダーの処理、そしてファイルとフォルダーの操作です。これらを跨いだ処理も組めます。受信メールの添付Excelを保存し、その中身でWebフォームを埋めるといった流れは、StudioXの標準的な守備範囲に収まります。
ここで止まる理由は、機能を意図的に減らしたからではなく、変数の型を単純に保つという設計を優先しているためです。StudioXは変数という概念を利用者から極力隠す方向で作られており、型を細かく指定させる操作を持ちません。この前提があるため、型の指定や変換を利用者に求めるアクティビティは、パッケージとして追加できても実際には設定しきれないことが起こります。追加そのものはManage Packagesから可能なので、「入れられたのに使えない」という形で表面化するのが厄介な点です。
プロジェクト構造の縛り:Main.xaml一枚とSequenceX
実装面で最も効いてくるのが構造の縛りです。StudioXプロファイルから参照できるワークフローファイルはMain.xamlだけで、それ以外のファイルをプロジェクトに追加してもStudioX側の画面には現れません。追加したワークフローはInvoke Workflow Fileアクティビティ経由で呼び出す形になります。さらに、Main.xaml内のアクティビティは、StudioXプロジェクトへ既定で置かれるSequenceXというルートのコンテナの中に収めておく必要があります。
この二点を知らずに開発者がStudio側で整理すると、処理を機能ごとにファイル分割した瞬間に、現場担当者からは中身が見えないプロジェクトになります。分割自体は動作に影響しませんが、現場で保守を回す前提が崩れます。分割するかどうかは、保守を誰が持つかという運用の決定と一体で考えてください。
| 観点 | Studioプロファイル | StudioXプロファイル |
|---|---|---|
| 想定利用者 | RPA開発者・エンジニア | 業務部門の担当者 |
| 変数の扱い | 型を明示して宣言する | 概念を隠し型指定を求めない |
| ワークフロー構成 | 複数ファイルへ分割できる | Main.xamlのみ参照できる |
| ルートコンテナ | 任意の構造を組める | SequenceX内に収める |
| アクティビティ設定 | プロパティパネル中心 | デザイナー本体に露出 |
| 想定実行形態 | AttendedとUnattendedの両方 | Attendedのみを前提 |
ライセンスの非対称性:Citizen Developer側からStudioは開けない
ライセンスの関係は片方向です。公式FAQには、Studioプロファイルへアクセスできるライセンスであれば、そのままStudioXプロファイルにもアクセスできると書かれています。逆に、StudioX向けのCitizen Developerライセンスで得られるのはStudioXプロファイルへのアクセスのみで、Studioプロファイルは開けません(2026年8月13日時点)。
この非対称性は、割り当ての設計へそのまま影響する要素です。開発者が現場のプロジェクトを引き取って直す運用を想定しているなら、その開発者にはStudio側のライセンスが要ります。反対に、現場担当者へ配るならCitizen Developerで十分です。ここを「同じStudioなのだから安いほうでよい」と判断すると、トラブル時に開発者が中身を開けないという止まり方をします。
実行権については、UiPathのライセンスは下位のライセンスが持つ機能を含むという考え方で組まれています。Citizen Developerライセンスには本番用のAttendedライセンスが含まれており、UiPath Assistantから本番の自動化を実行できます。つまり現場担当者に対して、作る権利と動かす権利を別々に手当てする必要はありません。種別ごとの割当単位と本数の見積もりについてはUiPathの料金・ライセンスとは?種別と割当単位・本数見積もりから導入判断まで解説で扱っています。
プロジェクト互換性:StudioXで作りStudioで直す運用の作法
両者の行き来には、方向によって可否が分かれます。StudioXで作ったプロジェクトは、Studioプロファイルから開いて編集できます。開発者が不具合を調べたり、現場では組み込みにくい処理を足したりできる設計です。一方で、Studioプロファイルから新規にStudioXプロジェクトを作ることはできません。器を用意するのは現場側、手を入れるのは開発側という一方通行の関係になります。
Studioで互換を壊さずStudioXへ戻すために守る三つの編集条件
Studio側で編集したあと、現場担当者が引き続き開ける状態を保ちたい場合、守るべき点は三つです。ひとつ、処理をMain.xamlの外へ出さない。出す場合はInvoke Workflow Fileで呼ぶ形にし、現場から見えなくなることを合意しておく。ふたつ、追加するアクティビティはSequenceXコンテナの内側へ置く。みっつ、StudioX向けに設計されていないアクティビティを混ぜない。混ぜた場合、現場担当者はその項目を設定できません。
逆方向の心配は不要です。StudioXで使えるアクティビティはすべてStudio側でも使えるため、開発者が現場のプロジェクトを開いて設定内容を読めなくなることはありません。問題が起きるのは常に、Studio側で足したものを現場が触れるかどうかの一点に集約されます。
Orchestratorへの発行とUnattended運用の線引き
発行の手順は共通です。StudioXのプロジェクトも、Studioのプロジェクトと同じ流れでOrchestratorへ発行できます。Robotが接続されていなければRobot Defaultsでローカルへ発行し、接続済みならOrchestratorへ発行する形です。互換性はOrchestrator 2019.10以降で、2019.10についてはライセンスとログの範囲に限られます。
ただし、Unattended用途については公式に線が引かれています。StudioXのプロジェクトはAttended用途を前提に設計されており、Unattendedを想定した開発にStudioXを使うことは推奨されていません。どうしても転用する場合は、Studioプロファイル側でGlobal Exception Handlerを外したうえで、発行前に開発者のレビューを通すという手順が案内されています。レビューでは、追加のログ出力とエラー処理、そしてアセットへ移すべき値がハードコードされていないかを見ます。無人実行は誰も画面を見ていない状態で走るため、現場が作った前提のままでは異常時に止まれません。
現場に配る線引き:StudioXを採用する条件と、開発側で引き取る場面
判断基準を言い切ります。StudioXを現場へ配って回るのは、次の三条件が揃うときです。第一に、対象業務がExcelとメールとブラウザ操作の範囲に収まり、外部システムのAPI連携や複雑な分岐を含まないこと。第二に、担当者がExcelの関数やピボットテーブルを自力で組める水準にあり、処理を手順へ分解できること。公式FAQもStudioXの適性をこの水準で説明しています。第三に、その業務の手順を決める権限が担当者本人にあること。手順の変更に承認が要る業務では、現場で直せる利点が消えます。
反対に、開発側で引き取るべき場面も三つあります。ひとつ、無人実行を前提とする処理。前項のとおり設計思想から外れます。ふたつ、複数部門が同じ処理を使う場合。共通部品として切り出す必要が出た時点で、Main.xaml一枚という縛りが足かせになります。みっつ、扱うデータに機微情報が含まれる場合。資格情報の扱いや例外時の挙動を設計する必要があり、変数を隠す前提の環境では詰め切れません。
この線引きは製品固有の話に見えて、実際にはRPAを現場配布するか集中管理するかという運用方針そのものです。国産製品を含めて配布形態を比べたい場合はWinActorとは?純国産RPAの仕組み・価格・エディションから導入判断まで実装目線で解説、無償の範囲から現場配布を試したい場合はPower Automate Desktopとは?無償RPAでできること・使い方・導入判断を解説が対になります。手法そのものの向き不向きから確かめたい場合はRPAとは?仕組み・できること・主要ツールと導入判断をわかりやすく解説、製品を横断して比べたい場合はRPAツール比較|UiPath・WinActor・BizRobo!など主要6製品の選び方から入ると判断が早くなります。
両者を橋渡しする設計:ライブラリ・カスタムアクティビティ・ガバナンス
境界を引いたうえで、現場側の届く範囲を広げる手立てがあります。中心になるのがライブラリです。Studioから発行したライブラリは、StudioXのプロジェクトへ依存関係として追加できます。開発者が発行先をパッケージソースとして登録しておけば、現場担当者はManage Packagesの画面から入れるだけで使えます。基幹システムへの接続や独自の判定ロジックのように、現場では組めない処理を一つのアクティビティへ畳んで渡す形です。
カスタムアクティビティも同様に作れますが、注意点があります。StudioX向けのアクティビティは設計の指針が異なるため、Studio向けと同じ作り方をすると現場側で設定しきれません。主要なプロパティをデザイナー本体へ露出させ、型の指定を求めない形に寄せる必要があります。この手当てを省くと、せっかく配ったライブラリが現場で使われないまま残ります。
配布の統制はガバナンス機能で行います。アクティビティパッケージのフィードへのアクセス、Workflow Analyzerのルールと設定、製品内の機能の有効化と無効化を組織側で制御できます。適用の手段は二つで、Automation Opsから配布する方法と、JSON形式のポリシーファイルをローカルまたは外部、あるいはOrchestrator経由で配る方法です。現場配布を広げるなら、配る前にこのポリシーを決めておいてください。配ってから制限を足す順序にすると、既に動いている自動化を止めることになります。
一創では、UiPathの導入設計から開発、現場への内製化支援までを一貫してお引き受けしています。どの業務をStudioXで現場に任せ、どこから開発側で引き取るかの線引き、共通部品のライブラリ設計、ガバナンスポリシーの整備まで含めて相談したい場合はUiPath導入支援サービスをご確認ください。配布を始める前の設計段階からご一緒できます。
よくある質問
StudioXは単体でダウンロードできますか?
単体の配布物はありません。StudioXはUiPath Studioの中のプロファイルという位置づけで、入手するのはStudioのインストーラーです。インストールして認証したあと、プロファイルの選択でStudioXを選ぶという手順になります。動作要件もStudioと共通で、StudioXのために別の環境を用意する必要はありません。
StudioXで作ったプロジェクトをStudioで開けますか?
開けます。StudioXのプロジェクトはStudioプロファイルから開いて編集でき、開発者が不具合を調べたり機能を足したりする用途が想定されています。ただし逆方向、つまりStudioプロファイルからStudioXプロジェクトを新規作成することはできません。また編集の際は、Main.xaml以外のファイルが現場側から見えないこと、SequenceXコンテナの外へアクティビティを出さないことに注意してください。
StudioライセンスがあればStudioXも使えますか?
使えます。Studioプロファイルへアクセスできるライセンスは、StudioXプロファイルへのアクセスも含みます。注意が要るのは逆側で、StudioX向けのCitizen DeveloperライセンスではStudioプロファイルを開けません。開発者と現場担当者でライセンスを揃えるのではなく、Studio側を開く必要がある人にだけ上位のライセンスを割り当てる形が費用面でも噛み合います。
StudioXで作った自動化を無人実行に回せますか?
推奨されていません。StudioXのプロジェクトはAttended用途を前提に設計されているためです。転用する場合は、Studioプロファイル側でGlobal Exception Handlerを外し、発行前に開発者のレビューを通すという手順が案内されています。レビューでは追加のログ出力とエラー処理、ハードコードされた値をアセットへ移す作業を行います。最初から無人実行が決まっている処理は、Studio側で組むほうが手戻りが出ません。
2025.10系でStudioXはなくなるのですか?
なくなりません。2025.10系のリリースノートでは、StudioXの機能がStudioへ統合され、プロファイルを切り替えずに設計できるようになったこと、そしてStudioXがStudio for Citizen Developersへ名称変更されることが示されています。同じプラットフォームであり、既存プロジェクトの継続も新規作成も従来どおりと説明されています。呼称が変わる点だけ、社内の手順書やライセンス台帳の表記に反映しておいてください。