UiPath Academyだけでは見えなかった保守開発案件で気づいた4つの気づき

公開日：2026年8月

UiPathには、初めてUiPath Studioでの開発を担当する人に向け、UiPath Academyをはじめとした公式ドキュメントや動画コンテンツなど、学習に役立つ情報がオンライン上で数多く用意されています。一方で、学習を進めるほど「どこまでできれば実務で通用するのか」が見えづらく、「Academyの演習と実際の案件では何が違うのか」不安になる方も多いのではないでしょうか？
本コラムでは、Studio開発の初学者だった私が案件参画後に感じた学習と実務のギャップを紹介します。また、その経験を踏まえ、おすすめの学習の進め方についてもお伝えします。学習を始めた当初の私と同じ悩みを抱えている方の参考となれば幸いです。

1．Academy受講時の私が抱いていたイメージ
2．案件参画後に気づいた学習と実務のギャップ
- ギャップ1：アクティビティの知識だけでは、ロボットの設計や構成を理解できなかった
- ギャップ2：最初に想定した原因が正しいとは限らなかった
3．実務経験から得た学び
- ①自分で作ることだけが学びではなかった
- ②原因を当てるのではなく、事実から原因を特定することが重要だった
4．今振り返るとこう学ぶ
5．初学者へ伝えたいこと
さいごに

1．Academy受講時の私が抱いていたイメージ

UiPath Academyでは、UiPath Studioの基本的な使い方や主要なアクティビティについて学ぶことができます。また、演習を通じてロボット開発の流れを実際に体験できるため、私自身も学習を進める中で少しずつStudioを使った開発のイメージを持てるようになっていました。
そのため当時は、「Academyで学んだ内容を身につければ、実務でもある程度対応できるようになるだろう」と考えていました。
しかし、案件へ参画すると、実務ではアクティビティの知識だけでは対応できない場面が多くありました。既存ロボットの改修やエラー調査では、ロボット単体だけでなく、設計書やフレームワーク（^*1）を含めた仕組み全体を理解する必要があったのです。

（^*1）フレームワーク：例外時の再実行やログを標準化した“プログラムのテンプレート”

次章では、実際に案件へ参画して感じた学習と実務のギャップについてご紹介します。

2．案件参画後に気づいた学習と実務のギャップ

私は、業務管理システムの操作を自動化するUiPathロボットの保守開発案件に開発メンバーとして参画し、既存ロボットの改修やエラー調査を担当しました。運用中のロボットに触れる中で、Academyで学んだ内容だけでは対応が難しい場面や、実務ならではの考え方が求められる場面を経験しました。
ここでは、そうした業務を通じて感じた学習と実務のギャップの中から、特に印象に残っているものを2つご紹介します。

ギャップ1：アクティビティの知識だけでは、ロボットの設計や構成を理解できなかった

既存ロボットの改修やエラー調査を進める中で、特に難しさを感じたのは、ロボットの全体像を理解することでした。参画当初に身につけていたのは主にStudioでロボットを作成するための知識であり、その知識だけでは、こうした業務を思うように進められませんでした。Academyの演習とは異なり、実務においては、ログに出力されたアクティビティを確認してもなかなか原因にたどり着けないケースが多くあります。どこで値が設定されているのか、どのような流れで処理が実行されているのかを、設計書やフレームワークなども参照しながら調査する必要がありました。
Academyではアクティビティの使い方やロボット作成の流れを学びましたが、実務ではそれに加えて、既存ロボットの構成やプロジェクト全体の設計を理解することも求められました。これが、実務に携わる中で感じた一つ目のギャップです。

ギャップ2：最初に想定した原因が正しいとは限らなかった

Academyでロボットを作成していた頃は、エラーが発生しても、原因と修正すべき箇所の関係は比較的分かりやすいものでした。変数名の指定ミスや条件分岐の判定誤りなど、エラーログに示された内容と該当箇所が直接結びついており、修正箇所を確認すれば原因を特定できるケースが中心でした。
しかし、実務ではエラーが発生した箇所や目の前の事象だけを見ても、原因を特定できないことがあります。
ここで、実際に経験した事例をご紹介します。ある画面操作でエラーが発生した際、当時は仮想デスクトップ環境上でロボットを実行していたため、私はまず画面表示の遅延を疑い、エラーログやエラーが発生したアクティビティ、その前後の画面操作を確認しました。また、暫定的な対応として待機時間を延長し、さらにリトライ処理も追加しました。しかし、決定的な原因は特定できませんでした。そこでエラー発生箇所だけを局所的に見るのではなく、調査範囲を広げて設計書や処理全体の流れを見直しました。その結果、同じ画面に対して類似の操作を正常に実行している処理が別の箇所にもあることに気づきました。両者の設定内容やセレクターを比較したところ、一部の認識条件に違いがあることが分かり、原因は画面表示の遅延ではなく、ロボットが対象画面を正しく認識できていないことだと判明しました。
この経験を通じて、目の前のエラーから想像した原因と、実際の原因は必ずしも一致しないことを実感しました。Academyでは「どう実装するか」を中心に学んでいましたが、実務では「何が原因なのか」を調査する機会も多くありました。これが、実務に携わる中で感じた二つ目のギャップです。

学習時に重視していたこと	実務で必要だったこと
アクティビティを理解し、ロボットを作成すること	設計書やフレームワークを確認しながら、既存ロボットの改修や調査を行うこと
エラーログから原因を特定すること	エラーが発生した「事象」を調査し、原因を特定すること

表1：Academyでの学習と実務のギャップ

このように、実務ではAcademy受講時には想像していなかったさまざまなギャップがありました。
初学者のうちは、Studio上でロボットを作る練習に意識が向きがちです。
しかし実務では、「なぜこの構成になっているのか」「どこで値が設定されているのか」「エラー時にどの処理を通るのか」を追う力も必要になります。
そのため、学習段階から“作る”だけでなく、“読む・追う・調べる”練習を少しずつ取り入れることが大切だと感じました。
次に、私がこれらの経験を通じて得た学びについてご紹介します。

3．実務経験から得た学び

実務で感じたギャップは、単に「Academyでは学ばなかったこと」ではありませんでした。既存ロボットの改修やエラー調査を経験する中で、私自身の開発や調査に対する考え方も少しずつ変わっていきました。ここでは、それらの経験を通じて得た学びについてご紹介します。

①自分で作ることだけが学びではなかった

保守開発では、既存ロボットや設計書、フレームワークなどを確認しながら調査や改修を進める機会が多くありました。
当初の私は、フレームワークを「決められた手順で利用するもの」と捉えていました。しかし処理内容を追っていく中で、例外処理の共通化やパラメータシートによる設定管理、共通部品化などには、それぞれ理由があることに気づきました。
それらは単なる開発ルールではなく、保守性や再利用性、運用効率を高めるための工夫や知見が反映されたものだと感じました。
また、フレームワークの挙動を理解することで、エラー発生時にどの処理を通るのか、フレームワーク側で処理されるのか、それとも業務ロジック側で処理されるのかといった観点も持てるようになりました。
この経験を通じて、自分でロボットを作ることだけが学びではないと感じるようになりました。既存ロボットやフレームワークを理解する過程にも、実務で培われた考え方や工夫が詰まっており、それらを読み解くことも重要な学習方法なのだと感じています。

②原因を当てるのではなく、事実から原因を特定することが重要だった

エラー調査を経験する中で、問題解決に対する考え方も変わりました。当初の私は、エラーが発生すると「このエラーなら原因はこれだろう」と考え、自分が知っている知識の中から答えを探そうとしていました。
しかし実際には、最初に想定した原因が正しいとは限りません。私が関わった案件の先輩開発者は、一つの原因に決めつけるのではなく、複数の可能性を考えながら確認を進めていました。そして、ログや実行結果、画面の状態など、発生している事実をもとに原因候補を絞り込んでいました。
私は「正解を知っていること」が重要だと思っていました。しかし実務で求められるのは、知識の中から答えを探すことではなく、事実をもとに原因を整理し、一つずつ確認しながら真因を特定することだったのです。
この経験を通じて、知識を増やすことだけでなく、発生している事象を観察し、論理的に原因を切り分ける力も重要だと学びました。

実務経験から得た気づき	実務で重要だと感じたこと
自分で作ることだけが学びではなかった	既存ロボットやフレームワークを読み解くことも重要な学習方法である
原因を当てることよりも、事実を積み上げることが重要だった	事実をもとに原因候補を切り分けながら調査することが重要である

表2：実務経験から得た学び

次の章では、これらの学びを踏まえて、今振り返るとどのように学ぶのが良かったと考えているのかをご紹介します。

4．今振り返るとこう学ぶ

ここまで紹介した内容を見ると、「では何から学べばよいのか」と感じる方もいるかもしれません。私自身、案件へ参画した当初は実務とのギャップに戸惑うこともありました。しかし今振り返ると、学習方法そのものが間違っていたわけではなく、学習の目的や期待値に少しズレがあったのだと思います。もし今の知識や経験を持ったまま、もう一度UiPathを学び始めるとしたら、次のような順番で学習を進めるでしょう。

STEP1：Academyで基礎を学ぶ

Academyでは、以下のようなUiPath Studio開発の基礎を体系的に学ぶことができます。

UiPathとは何か
Studioの基本操作
アクティビティの使い方
デバッグの基本

インターネット上にはさまざまな学習コンテンツがありますが、まずはAcademyを通じてStudioの基本的な知識や使い方を身につけることをおすすめします。

STEP2：小さなロボットを作ってみる

Academyで基礎を学んだ後は、小さくてもよいので自分でロボットを作ってみることが大切です。学習中は「もっと理解してから作ろう」と考えてしまいがちですが、実際には作りながら学ぶことも多くあります。

例えば、以下のような身近な業務を題材にすると取り組みやすいでしょう。

Excelの転記
CSVファイルの集計
フォルダ内のファイル整理
Webサイトからの情報取得

最初から複雑なロボットを作る必要はありません。むしろ、処理の流れが分かりやすい小さなロボットを作り、少しずつ機能を追加していく方が理解しやすくなります。ロボットが思った通りに動かなかった経験も含めて、開発スキルの習得につながります。

STEP3：他人が作ったロボットを読んでみる

案件に参画してから特に重要だと感じたのが、「読む力」です。Academy学習中は自分でロボットを作ることが中心になるため、「他人が作ったロボットを理解する経験」をする機会は多くありません。しかし、開発スキルを高めるためには、自分で作るだけでなく、他人が作ったワークフローを読むことも有効です。

最初は処理の流れを追うだけでも大変ですが、例えば以下のような観点で確認すると、多くの学びを得ることができます。

どのような単位でワークフローを分割しているか
変数名をどのように付けているか
どのように例外処理を実装しているか
共通部品をどのように呼び出しているか

また、3章で触れたように、フレームワークや共通部品には過去の開発者が積み重ねてきた知見が含まれています。実装内容だけでなく、「なぜこのような構成にしているのか」「どのような課題を解決するための仕組みなのか」という視点で読むことで、実務で求められる考え方への理解も深まります。
もしサンプルプログラムや過去案件の資料がある場合は、積極的に処理内容を追いかけてみることをおすすめします。自分でロボットを作る経験とはまた違った学びを得られます。

STEP4：エラー調査に慣れる

学習中は「エラーを出さないこと」を目標にしがちです。私も初学者の頃は、エラーが発生すると焦ってしまい、できるだけ避けたいと考えていました。しかし実務では、エラー調査そのものが重要な業務になります。

そのため、まずは以下のような機能を使いながら原因を調査する経験を積むことをおすすめします。

ブレークポイント（^*2）
ローカルパネル（^*3）
ログ出力
デバッグ実行

（^*2）ブレークポイント：ワークフロー内の任意のアクティビティに設定し、デバッグ実行時にその箇所で処理を一時停止させる機能。
（^*3）ローカルパネル：デバッグ実行中に、現在の処理で使用されている変数や引数の値を確認できる画面。ブレークポイントによる一時停止時などに、値が想定どおりに設定されているかを確認するために使用する。

実際にエラーと向き合うことで、Studioのデバッグ機能の使い方を学ぶとともに、エラー発生時には「どこを確認すればよいのか」「どのように原因を切り分ければよいのか」が少しずつ分かるようになります。振り返ると、開発スキルと同じくらい調査スキルも重要だったと感じています。

5．初学者へ伝えたいこと

私自身、案件へ参画するまでは「アクティビティを知っていること」と「開発できること」はほぼ同じだと考えていました。しかし実務では、既存ロボットやフレームワークを読み解く力、発生しているエラー事象をもとに原因を切り分け特定する力など、Academyだけでは見えにくい力も求められました。
一方で、Academyの学習が不要というわけではありません。Studioの基本操作やアクティビティ、ロボット開発の基本的な流れを学んでいたからこそ、案件参画後に既存ロボットの構成やエラー調査の考え方を理解し、吸収することができました。
これから学習を始める方には、Academyを「ゴール」ではなく実務を円滑に進めるための「スタート地点」として捉えてほしいと思います。Academyで学ぶ内容は、実務で必要となる土台です。
まずは基礎を学び、小さなロボットを作ってみる。そのうえで、他人が作ったロボットを読んだり、エラーの原因を調べたりする経験を重ねていくことで、実務で求められる力に少しずつ近づけます。

本コラムで紹介した内容が、これからUiPathを学ぶ方や案件参画を目指している方にとって、実務で求められる力を意識しながら、学習を進めるきっかけとなれば幸いです。

参考：UiPath Academy　https://academy.uipath.com/ja

さいごに

TISIでは、UiPathの導入から運用後の課題解決まで、現場に寄り添ったサポートを行っています。今回ご紹介した内容以外にも、UiPathの導入や運用支援を通じて得た経験や知見が豊富です。ご関心があればぜひご相談ください。

執筆者：小林　諒介

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

お問い合わせ

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