この記事は UiPath ブログ発信チャレンジ2026サマー の 11日目 の記事です。

はじめに

こんにちは、@Gaboz です。

RPA を運用していると、最初は誰も気にしないのに、あとからじわじわ効いてくる設計判断があります。その筆頭が Orchestrator（OC）のフォルダ設計 だと思っています。

新規で OC を立ち上げるとき、フォルダ構成って「とりあえず動けばいい」で決めがちですよね。でも、クラシックフォルダからモダンフォルダへの移行や、オンプレミス OC から Automation Cloud への移行を何度か経験して、最初のフォルダ設計の良し悪しが、数年後の運用コストとガバナンスを丸ごと決めていた ことを何度も痛感しました。

この記事では、そのあたりの「あとで泣かないための勘どころ」を、現場目線でまとめてみます。これから OC を設計する方、あるいは今の構成に薄々モヤモヤしている方の参考になれば嬉しいです。

なぜフォルダ設計が"あとから"効いてくるのか

Orchestrator のフォルダは、単なる「入れ物」ではありません。

リソース（プロセス・キュー・アセット・トリガー）の整理単位であり、
ユーザー／グループへのアクセス権限を割り当てる単位でもあります。

この2つが同じ「フォルダ」に紐づいているのがポイントです。つまりフォルダ設計を間違えると、「業務の整理」と「権限管理」の両方が同時に破綻する。しかも稼働中のプロセスやトリガーがぶら下がっているので、あとから直すのが本当に大変なんです。

イメージとしては、こんな図です。フォルダを「業務（パッケージ）のまとまり」として設計し、そこに人を割り当てていくのがおすすめの形。1人が複数フォルダに割り当てられても、フォルダ自体は業務の数だけで済みます。

逆に、「この人にこの権限を」という発想でフォルダを人ごとに切っていくと、こうなります。移行案件で一番よく見た地獄が、まさにこの 「権限を付けたいだけなのにフォルダが際限なく増えていく」 パターンでした。

同じ登場人物でも、フォルダの切り方ひとつで管理の重さがまるで変わります。ここを最初に押さえておくと、後半がだいぶ楽になります。

フォルダの「単位」5パターン

まず、フォルダを何を軸に切るか。実務でよく使う単位は次の5つです。組み合わせて使うのが前提です。

① 部署／部門単位（個人的にはこれが基本形）

例：営業部、経理部、人事部、情報システム部、製造部

各部署が使うリソースを部署フォルダに格納し、部署固有の権限をそこに設定します。

現場で一番効くのが 異動への強さ です。業務はプロジェクト（＝部署の担当領域）に紐づいていることが多いので、担当者が変わっても 割り当てを直すだけ で済む。「他部署のフォルダには原則アクセス不可」というシンプルなルールが敷けるのも大きい。

移行時にも、部署単位で切ってあると「この部署ぶんだけ先に移す」といった段階移行がやりやすく、何度も助けられました。

② プロジェクト／業務単位

例：RPA導入プロジェクトA、請求書処理業務、顧客データ登録業務

特定のプロジェクトや業務にひもづくリソースを1フォルダに集約します。細かい制御ができる反面、フォルダ数が爆発しやすい。運用コストが上がるので、乱用は禁物です。

ただ、プロジェクト終了時や業務変更時に フォルダ単位でまるっと管理・移行できる のは強み。期間限定のPoCや、明確に終わりのある業務にはハマります。

③ 環境単位（開発／テスト／本番）

例：Development / Testing / Production

環境を明確に分離して、誤操作や事故を防ぐための切り方。テナントレベルで分けるのが王道ですが、部署フォルダ配下に孫フォルダとして置く ケースもあります。この場合、親フォルダの設定を継承できるのがメリット。

④ ロボットタイプ／実行形態単位

例：Attended / Unattended / Studio

Unattended ロボットのタイムトリガーやジョブを一覧で管理したいときに効きます。実務では 部署フォルダ配下に Unattended フォルダを置く 形が多いです（後述の「トリガーはフォルダ単位管理」の話とセットで効いてきます）。

⑤ 共通リソース単位

例：共通モジュール、共通ライブラリ、汎用アセット、全社共通プロセス

複数の部署・プロジェクトで共用するリソースを集約します。鉄則は 通常は読み取り専用権限、変更できるのは特定の管理者だけ。ここが緩いと、誰かの変更が全社に波及して事故ります。

おすすめの「組み合わせ」パターン

上の単位を、実際にはこんな形で組み合わせます。よく使う4パターンを、実際の Orchestrator 画面で。

① 部署単位（基本形）

まず迷ったらこれ。シンプルで、権限も異動対応も一番ラク。

② 部署単位 × 環境単位

部署の中で開発〜本番を分けたいとき。親（部署）の設定を継承しつつ、環境ごとに事故を防げます。

③ 部署単位 × ロボットタイプ（Unattended）

Unattended のトリガー／ジョブを部署ごとに一覧管理したいとき。

④ 共通リソース × 部署単位

共通部品を1か所に集約し、各部署からは参照だけ。変更は管理者に限定。

運用でハマる／効くポイント6つ

設計と同じくらい、運用ルールが効きます。ここは移行案件で「やっておけばよかった」を煮詰めた6点です。

1. 監視（Insights）はフォルダを"跨いで"見える。でもトリガーは別

「監視」タブを使うと、フォルダを横断して ジョブ実行状況やマシン状況を一元管理できます。だからこそ、「情報収集のためだけにフォルダを細かく区切る」のは、区切る前に一度立ち止まってほしい。監視で足りるかもしれません。

一方で、タイムトリガーの情報はフォルダ単位管理 です。ここが盲点で、Unattended マシンごとにフォルダを分けるか、Excel 等で別管理する運用が必要になります。移行時に「トリガー、どこ行った？」となりがちなポイント。

2. 権限は最小限（Least Privilege）

標準ロール（Folder Administrator / Automation Developer / Automation User）を基本に、足りないぶんだけカスタムロールを足す。

よくあるのが、アセット更新が必要なプロセスなのに Automation User 権限しかなくて動かない ケース。ここは専用ロールを1つ作るのが正解です。「とりあえず強い権限を全員に」は、移行のたびに棚卸しで泣きます。

💡 ハマりどころ：フォルダ割り当て時に権限の警告が出るのは、対応するテナントロール（「Allow to be 〜」）が未付与 なことが多いです。テナントロールとフォルダロールは対応させておく、が鉄則。

3. 命名規則を最初に決める

フォルダもリソースも、統一命名規則を最初に決めておく。地味ですが、移行時の突合と、事故ったときの特定速度がまるで違います。あとから変えるのは本当に大変なので、最初の30分をここに使う 価値があります。

4. 階層は深くしすぎない（3〜4階層まで）

階層が深いと、権限の継承関係が追えなくなって管理が破綻します。3〜4階層程度 に留めるのがおすすめ。「部署 > 環境 > (せいぜいロボットタイプ)」くらいで止める感覚です。

5. 定期的に見直す

組織変更やビジネス変化に合わせて、フォルダとリソースを定期的に棚卸し。フォルダ移動機能 を使えば再配置は思ったよりラクなので、「一度作ったら触らない」にしないこと。

6. フォルダごとに責任者を置く

各フォルダに Folder Administrator の担当者 を明確に配置する。「誰のフォルダか分からない」状態が、権限肥大化と放置プロセスの温床になります。責任者がいるだけで、運用の質がまるで変わります。

移行で特に気をつけたい2つ

最後に、移行案件でよく踏む地雷を2つだけ。

クラシック → モダンフォルダ：権限モデルが変わるので、「今の権限をそのまま移す」ではなく、移行を"権限の棚卸しのチャンス"にする のが吉。前述の Least Privilege をここで一気に整えると後がラクです。
オンプレミス → Automation Cloud：トリガー・アセット・キューの持ち先が変わるので、フォルダ単位で「何がぶら下がっているか」を先に棚卸し しておく。特にタイムトリガーは見落としやすい（監視の話と同じ）。

まとめ

Orchestrator のフォルダ設計は、運用効率とガバナンスの両立に直結する、最初の重要な設計判断 です。

迷ったら 部署単位を基本形 に。
そこに 環境・ロボットタイプ・共通リソース を必要なぶんだけ組み合わせる。
命名規則・最小権限・階層の浅さ・定期見直し・責任者 の5つを運用ルールとして最初に決める。

これだけで、数年後の「あとで泣く」がだいぶ減ります。移行のときに過去の自分に感謝できる設計を、ぜひ最初にやっておきましょう。

最後までお読みいただきありがとうございました！

#UiPathブログ #UiPathFriends