RPA からの移行の進め方：ロボットの棚卸しから PoC まで
公開日:
RPA を入れて数年がたち、ロボットの数は増えたのに、止まるたびに直す手間も増えている。作った担当者はもういない。ライセンスの更新時期も近い。そうしたときに「RPA から移行したい」という相談が増えます。
ただし、すべてのロボットを一度に置き換える必要はありません。RPA が得意な業務は残し、止まりやすく効果の大きい業務から順に移すのが、失敗しにくい進め方です。この記事では、WinActor、UiPath、BizRobo! などの RPA 製品で作ったロボットを見直すときの手順を、棚卸しから PoC、切り替えまで順に解説します。
画面の変更でロボットが止まる理由は、「RPA が画面変更で止まる理由と、止まりにくい自動化の作り方」で整理しています。
移行を考え始めるきっかけ
- ロボットが止まる回数と、直すのにかかる時間が増えてきた
- ロボットを作った担当者が異動・退職し、中身がわからない
- ライセンスの更新時期が近い
- 業務の手順が変わり、ロボットが実態に合わなくなった
- 監査や内部統制で、ロボットの管理状況を説明する必要が出てきた
どれか一つでも当てはまるなら、まずは今あるロボットの状況を把握するところから始めます。
ステップ 1：ロボットを棚卸しする
動いているロボットを一覧にし、次の項目を集めます。
| 項目 | 確認すること |
|---|---|
| 業務の内容 | 何の業務を、何のために自動化しているか |
| 担当 | 業務の担当部門と、ロボットを直せる人 |
| 頻度と件数 | 毎日・毎月など実行の頻度と、1 回あたりの件数 |
| 操作するシステム | 社内か社外か、Web かデスクトップアプリか |
| 止まった回数 | 直近半年に止まった回数と、直すのにかかった時間 |
| 公式の連携 | API、CSV のダウンロード、データ連携の有無 |
| 判断の有無 | 人が判断している、または判断すべき箇所があるか |
| 止まったときの影響 | 業務が遅れるか、取引先や顧客に影響するか |
棚卸しをすると、もう使われていないロボットや、業務がなくなったのに動き続けているロボットが見つかることも少なくありません。
ステップ 2：ロボットを 4 つに仕分ける
棚卸しの結果をもとに、ロボットを 4 つに分けます。
| 仕分け | 向いているロボット |
|---|---|
| 廃止する | 使われていない、業務がなくなった、手作業で十分な件数しかない |
| 公式の連携に置き換える | 相手のシステムに API、CSV のダウンロード、データ連携が用意されている |
| RPA のまま残す | デスクトップアプリや Excel を操作する、画面がほとんど変わらない社内システムで大量の定型操作をする |
| AI の画面操作に移す | 社外の Web システムを操作する、画面がよく変わる、例外や判断が多い |
画面操作の自動化は、ほかの方法がない業務の最後の手段です。公式の連携があるなら、そちらが変更に強く、速く、確実です。一方で、取引先ごとに違う Web ポータルや、事前の連絡なしに画面が変わる社外のシステムは、手順を文章で書いて AI が画面を読んで操作する方法が向いています。
ステップ 3：PoC の対象を 1〜3 件選ぶ
「AI の画面操作に移す」に分けたロボットから、PoC（概念実証）の対象を選びます。次の条件を満たすものが向いています。
- Web ブラウザの操作で完結する
- よく止まる、または直すのに手間がかかっている
- 件数や作業時間が多く、効果を数字で比べやすい
- 利用規約で自動操作が認められている
- 業務の担当者が PoC に協力できる
最初から最も重要な業務を選ぶ必要はありません。止まったときの影響が大きすぎず、効果が見えやすい業務から始めると、結果を社内で説明しやすくなります。
成功の基準を先に決める
PoC を始める前に、何をもって成功とするかを決めておきます。基準がないと、終わったあとに「よかったのか」を判断できません。
- 1 件あたりの処理時間と、担当者の作業時間
- 処理できた件数の割合と、止まった回数
- 止まったときに、原因の特定から再開までにかかった時間
- 人の確認や承認に回った件数の割合
- 誤った処理の件数
今のロボットや手作業の数字も同じ項目で測っておくと、比べやすくなります。
ステップ 4：PoC で確かめること
- 実際の画面とデータで動くか：デモ用の環境ではなく、本番と同じ画面と、本番に近いデータで動かします
- 変更と例外への強さ：ポップアップや想定外のデータが来たとき、どう止まり、どう再開できるか
- 費用と時間：AI の画面操作は操作のたびに AI モデルの利用料と時間がかかります。1 件あたりの費用と処理時間を実測します
- セキュリティ：認証情報の扱い、AI モデルに送られる情報、使うモデルを情報システム部門と確認します
- 現場で直せるか：ロボットを作った人以外が手順を読み、修正できるか
ステップ 5：並行して動かしてから切り替える
PoC で効果が確かめられたら、いきなり切り替えずに、一定期間は既存のロボットや手作業と並行して動かし、結果を比べます。切り替えたあとも、しばらくは元のロボットを残しておくと、問題が起きたときにすぐ戻せます。
ライセンスの更新時期がある場合は、そこから逆算して、棚卸し、PoC、並行稼働の期間を確保します。
ステップ 6：社内で直せる体制をつくる
移行の目的は、ロボットを入れ替えることではなく、止まっても社内で直せる状態にすることです。
- ワークフローごとに担当者を決め、変更を確認する人を決める
- 変更は内容を確認してから反映し、履歴を残す
- 失敗や承認待ちの通知先を決める
- すべてのワークフローの実行状況を一か所で把握できるようにする
よくある失敗
- すべてを一度に置き換えようとする：対象が多すぎて PoC が終わらず、効果も見えないまま時間だけがかかります
- 成功の基準を決めずに始める：結果を比べる物差しがなく、導入の判断ができません
- 利用規約の確認を後回しにする：自動操作が禁止されているサービスを対象にすると、PoC の成果を本番で使えません
- 作る人だけで進める：業務の担当者と、運用・修正を担う人が関わらないと、定着しません
Kitewell での進め方
Descarty の Kitewell は、手順を日常の言葉で書き、Web の操作を AI に任せ、判断を人が承認する業務自動化ソフトウェアです。止まったときは止まったステップから再開でき、AI アシスタントとの会話で原因の調査と修正ができます。デスクトップアプリの画面操作には対応していないため、そうした業務は RPA に残すことをおすすめしています。
法人向けには、貴社の実際の業務から 1〜3 件を選び、本番と同じ画面とデータで効果を確かめる有償の PoC から始めます。目安の期間は合計 4〜6 週間です。PoC の後に本契約へ進む場合、PoC の費用は初年度の契約金額に充当します。詳しくは「導入と料金」を、RPA との違いは「脱RPA」をご覧ください。