RPA から AI RPA への切り替え手順：棚卸しから定着まで

RPA を入れて数年がたち、ロボットの数は増えたのに、止まるたびに直す手間も増えている。作った担当者はもういない。ライセンスの更新時期も近い。そうしたときに「止まりやすいロボットを AI RPA に切り替えたい」という相談が増えます。

切り替えで一番大切なのは、すべてを一度に置き換えないことです。RPA が得意な業務は残し、止まりやすく、止まったときの影響が大きいロボットから順に移します。この記事では、WinActor、UiPath、Power Automate、BizRobo! などで作ったロボットを、AI が画面を読んで操作する AI RPA に移す手順を、棚卸しから切り替えの後片付けまで順に解説します。

ロボットが画面の変更で止まる理由は「RPA が画面変更で止まる理由と、止まりにくい自動化の作り方」で、製品ごとの事情は「RPA の課題」の製品別ガイドで整理しています。

移行を考え始めるきっかけ

ロボットが止まる回数と、直すのにかかる時間が増えてきた
ロボットを作った担当者が異動・退職し、中身がわからない
ライセンスの更新や価格の改定が近い
業務の手順が変わり、ロボットが実態に合わなくなった
監査や内部統制で、ロボットの管理状況を説明する必要が出てきた

全体の流れ

ステップ	やること	成果物
1. 棚卸し	動いているロボットを洗い出し、止まった回数などを集める	ロボットの一覧（台帳）
2. 仕分け	廃止・公式連携・RPA に残す・AI に移す、に分ける	仕分けの結果
3. 優先順位	止まりやすさと影響で、移す順番を決める	移す順の一覧
4. 書き直し	シナリオを、業務の言葉の手順に書き直す	新しいワークフロー
5. PoC	1〜3 件で、本番と同じ画面とデータで確かめる	成功基準に対する結果
6. 並行稼働	古いロボットと並べて動かし、結果を突き合わせる	差異の記録
7. 切り替え	新しいほうに切り替え、古いロボットを片付ける	更新した台帳
8. 定着	社内で直せる体制を整え、次の業務に広げる	運用のルール

ライセンスの更新日がある場合は、そこから逆算して、PoC と並行稼働の期間を確保します。並行稼働には、少なくとも月末などの繁忙期を 1 回含めるのが安全です。

ステップ 1：ロボットを棚卸しする

動いているロボットを一覧にし、次の項目を集めます。

項目	確認すること
業務の内容	何の業務を、何のために自動化しているか
担当	業務の担当部門と、ロボットを直せる人
頻度と件数	毎日・毎月など実行の頻度と、1 回あたりの件数
操作するシステム	社内か社外か、Web かデスクトップアプリか
止まった回数	直近半年に止まった回数と、直すのにかかった時間
公式の連携	API、CSV のダウンロード、データ連携の有無
判断の有無	人が判断している、または判断すべき箇所があるか
止まったときの影響	業務が遅れるか、取引先や顧客に影響するか

止まった回数と直した時間は、記録がなければ担当者の記憶でかまいません。正確さより、ロボットどうしを比べられることが大切です。この一覧はそのままロボット管理台帳の土台になります。項目と書き方は「RPA のロボット管理台帳の作り方」にまとめ、Excel のテンプレートも用意しています。

作った人がいないロボットの調べ方は「作った人がいない RPA ロボットの引き継ぎ方」で解説しています。

ステップ 2：ロボットを 4 つに仕分ける

仕分け	向いているロボット
廃止する	使われていない、業務がなくなった、手作業で十分な件数しかない
公式の連携に置き換える	相手のシステムに API、CSV のダウンロード、データ連携が用意されている
RPA のまま残す	画面がほとんど変わらない社内システムで、決まった操作を大量・高速に繰り返す
AI の画面操作に移す	社外の Web システムを操作する、画面がよく変わる、例外や判断が多い

画面操作の自動化は、ほかの方法がない業務の最後の手段です。公式の連携があるなら、そちらが変更に強く、速く、確実です。

ステップ 3：止まりやすさと影響で順番を決める

「AI の画面操作に移す」に分けたロボットに、次の 3 つの観点で 1〜3 点をつけ、掛け合わせた点数の高い順に移します。

観点	1 点	2 点	3 点
止まりやすさ	半年に 1 回以下	2〜3 か月に 1 回	毎月のように止まる
止まったときの影響	後で処理すれば済む	社内の業務が遅れる	支払や顧客・取引先に影響する
直すのにかかる手間	社内ですぐ直せる	直せる人が限られる	直せる人がいない、外部に頼んでいる

例えば、毎月止まり（3 点）、支払に影響し（3 点）、外部の保守会社に頼んでいる（3 点）ロボットは 27 点で、最初に移す候補になります。半年に 1 回しか止まらず（1 点）、後で処理すれば済み（1 点）、社内ですぐ直せる（1 点）ロボットは 1 点で、急いで移す必要はありません。

点数が高くても、利用規約で自動操作が禁止されているサービスを操作するロボットは移せません。「自動化の前に確かめる利用規約」の手順で先に確認します。

ステップ 4：シナリオを業務の言葉で書き直す

移すときに、RPA のシナリオを 1 操作ずつ写す必要はありません。むしろ、写さないほうがうまくいきます。シナリオには、座標、待ち時間、画面要素の指定など、その時点の画面に合わせた細部が詰まっているからです。

代わりに、業務の担当者と一緒に、業務の流れを言葉で書き出します。

業務の目的と区切りを書く：「取引先から届いた請求書を、会計システムに登録する」
手順を、画面ではなく業務の単位で書く：「請求書の PDF を読む」「金額と登録番号を確かめる」「会計システムに 1 件ずつ登録する」
人が判断している所を書く：「保存の前に、経理担当者が内容を確認する」
確かめる所を書く：「登録したら、伝票番号が表示されたことを確かめる」
例外を書く：「登録番号が見つからない請求書は、担当者に回す」

RPA のシナリオに出てくる要素は、おおむね次のように置き換わります。

RPA のシナリオ	AI が操作する手順
座標や画面要素の指定によるクリック	「保存ボタンを押す」のように、操作の対象を言葉で書く
秒数を決めた待機	「一覧が表示されたことを確かめる」のように、待つ条件を書く
画像認識による対象の特定	画面の見出しや役割で対象を書く
Excel の最終行の検出と繰り返し	「一覧の各行について」と書き、行ごとに処理する
分岐（もし〜なら）	条件を言葉で書き、判断が難しいものは人に回す
エラー時の再試行や通知	失敗したステップから再開し、担当者に知らせる

書き出した手順は、作った人以外が読んでも意味が通じるかで確かめます。通じれば、それがそのまま引き継ぎの資料にもなります。

ステップ 5：PoC で確かめる

最初から最も重要な業務を選ぶ必要はありません。止まったときの影響が大きすぎず、効果が見えやすい 1〜3 件から始めると、結果を社内で説明しやすくなります。

成功の基準を先に決める

基準がないと、終わったあとに「よかったのか」を判断できません。今のロボットや手作業の数字も同じ項目で測っておきます。

1 件あたりの処理時間と、担当者の作業時間
処理できた件数の割合と、止まった回数とその理由
止まったときに、原因の特定から再開までにかかった時間
人の確認や承認に回った件数の割合
誤った処理の件数
AI モデルの利用料（初回と、2 回目以降に分けて）

PoC で確かめること

本番と同じ画面とデータで動くか：デモ用の環境ではなく、本番と同じ画面と、本番に近いデータで動かします
費用と時間：一度うまくいった操作を覚えて繰り返す仕組みなら、AI を使うのは初めての操作、画面が変わったとき、画面から情報を読み取るときに限られます。初回と 2 回目以降に分けて実測します
セキュリティ：認証情報の扱い、AI モデルに送られる情報、使うモデルを情報システム部門と確認します
現場で直せるか：作った人以外が手順を読み、修正できるか

ステップ 6：並行して動かし、結果を突き合わせる

PoC で効果が確かめられても、いきなり切り替えません。一定期間、古いロボット（または手作業）と新しいワークフローを並べて動かし、結果を突き合わせます。

期間：月末や締め日など、件数が多く例外が出やすい時期を少なくとも 1 回含める
突き合わせ方：登録した件数、金額の合計、登録番号などを 1 件ずつ比べ、違いを記録する
違いが出たら：どちらが正しいかを業務の担当者が判断し、手順を直す。古いロボットの誤りが見つかることもある
切り替えの条件を決めておく：「繁忙期を含む 2 回の締めで違いがなければ切り替える」のように、事前に決める

並行稼働中は、登録先のシステムに二重に登録しないよう、新しいほうは確認の手前で止める、テスト用の登録先を使う、などの工夫が必要です。

ステップ 7：切り替えと後片付け

古いロボットはすぐに消さない：問題が起きたときに戻せるよう、しばらくは停止した状態で残す
台帳を更新する：新しいワークフローを登録し、古いロボットの状態を「廃止」にする
アカウントとライセンスを整理する：ロボット用のアカウント、保存されたパスワード、不要になったライセンスを、更新時期に合わせて整理する
シナリオと手順書を保管する：監査や後からの確認に備えて、古いシナリオと記録を保管する

ステップ 8：社内で直せる体制をつくる

移行の目的は、ロボットを入れ替えることではなく、止まっても社内で直せる状態にすることです。

ワークフローごとに担当者を決め、変更を確認する人を決める
変更は内容を確認してから反映し、履歴を残す
失敗や承認待ちの通知先を、個人ではなくチームにする
すべてのワークフローの実行状況を一か所で把握できるようにする

最初の 1〜3 件で体制ができたら、ステップ 3 の点数の順に、次の業務へ広げます。

よくある失敗

すべてを一度に置き換えようとする：対象が多すぎて PoC が終わらず、効果も見えないまま時間だけがかかります
シナリオを 1 操作ずつ写す：古い画面の前提まで持ち込み、新しい仕組みでも止まりやすくなります
成功の基準を決めずに始める：結果を比べる物差しがなく、導入の判断ができません
並行稼働を飛ばす：繁忙期に初めて出る例外で止まり、手作業に戻すことになります
利用規約の確認を後回しにする：自動操作が禁止されているサービスを対象にすると、PoC の成果を本番で使えません
作る人だけで進める：業務の担当者と、運用・修正を担う人が関わらないと、定着しません

Kitewell での進め方

Descarty の Kitewell は、手順を業務の言葉で書き、画面の操作を AI に任せ、判断を人が承認する業務自動化ソフトウェアです。一度うまくいったクリックや入力は覚えて、次からは同じ手順で繰り返し、画面が変わったときだけ AI が操作を覚え直します。請求書の読み取りのように内容を判断する所では、毎回 AI を使います。止まったときは止まったステップから再開でき、AI アシスタントとの会話で原因の調査と修正ができます。Web ブラウザに加えて、macOS と Windows のデスクトップアプリも操作できます。

法人向けには、止まりがちなロボットを 1 本選び、2 週間で Kitewell に置き換える PoC（30 万円・税別）から始められます。合意した成功基準を満たさなければ、費用はいただきません。複数の業務をまとめて確かめる PoC も承ります。詳しくは「導入と料金」をご覧ください。

まとめ

すべてを一度に置き換えず、止まりやすく影響の大きいロボットから移す
順番は、止まりやすさ、止まったときの影響、直す手間の 3 つで決める
シナリオは 1 操作ずつ写さず、業務の言葉で書き直す。人の判断と、確かめる所を明記する
成功の基準を先に決めてから PoC を始める
繁忙期を含めて並行稼働し、決めた条件を満たしてから切り替え、台帳とアカウントを片付ける