作った人がいない RPA ロボットの引き継ぎ方

ロボットを作った担当者が異動した。退職した。それでもロボットは毎朝動き続け、ある日、取引先の画面が変わって止まる。そのとき初めて、誰も中身を知らないことに気づく。RPA を数年運用した会社では珍しくない話です。

「野良ロボット」への対策は、作る前のルールづくりとして語られることがほとんどです。ところが現場で困っているのは、すでに動いている、作った人のいないロボットをどうするかです。この記事では、そうしたロボットを止めずに引き継ぎ、二度と同じ状態にしないための手順を解説します。製品は問いません。WinActor、UiPath、Power Automate、BizRobo! など、どの RPA で作ったロボットにも使える進め方です。

なぜ「作った人しか直せない」ロボットができるのか

手順がシナリオの中にしかない：何をしているかは、RPA の開発画面でシナリオを開かないとわからない。開いても、作った人の意図までは書かれていない
手順書がシナリオと別に管理されている：最初に作った手順書が、その後の修正に追いついていない
現場で作られ、管理する部門が知らない：部門の担当者が作ったロボットを、情報システム部門が把握していない
個人の PC やアカウントで動いている：作った人の PC、作った人のアカウントで動いていて、異動とともに置き場所ごと宙に浮く

どれも、ロボットを作った時点では問題になりません。問題になるのは、作った人がいなくなってからです。

引き継ぎの前に：いきなり止めない

中身がわからないからといって、すぐに止めるのは危険です。そのロボットが作るファイルや登録するデータを、別の業務や別のロボットが前提にしていることがあります。止めるかどうかは、何をしているかを調べてから決めます。

反対に、誤った処理を続けている疑いがあるなら、すぐに止めて影響を調べます。判断に迷うときは、出力を受け取っている部門に確認します。

ステップ 1：ロボットを見つける

まず、作った人のいないロボットが、どこで、いくつ動いているかを洗い出します。探す場所は次のとおりです。

探す場所	見つかるもの
RPA の管理サーバー（WinActor の WMC、UiPath の Orchestrator など）	登録されたロボット、スケジュール、実行の履歴
ロボットを動かす PC のタスクスケジューラ	管理サーバーを通さずに定時起動しているロボット
共有フォルダや個人のフォルダ	シナリオのファイル、設定ファイル、出力されたファイル
ロボット用アカウントのログイン履歴	どのシステムに、いつログインしているか
業務部門へのヒアリング	「毎朝このファイルができている」といった、受け取る側の記憶

見つけたものは、ロボットの名前と動いている場所だけでも、すぐに一覧にします。この一覧が、後で台帳になります。

ステップ 2：何をしているかを調べる

1 体ずつ、次の順で調べます。

実行の記録を読む：いつ、どのくらいの時間動き、成功しているか失敗しているか
入力と出力を突き止める：どのファイルや画面を読み、何を作り、どこに登録しているか
操作する画面とアカウントを確かめる：どのシステムに、どのアカウントでログインしているか。パスワードがシナリオに直接書かれていないか
動くところを見る：テスト環境があればそこで、なければ業務部門の立ち会いのもとで、実際の動きを画面で確かめる
受け取る人に聞く：出力を使っている人に、何に使っているか、なくなったら何が困るかを聞く

シナリオの中身を 1 行ずつ読み解くより、入力と出力、動くところを先に押さえるほうが早く全体像がつかめます。シナリオを読むのは、直す必要があると決めてからで十分です。

調べた結果は、その場で書き残します。後で書こうとすると、細部が抜け落ちます。

ステップ 3：リスクを見積もる

調べた内容から、ロボットごとに次の点を判断します。

止まったときの影響：業務が遅れるだけか、支払や顧客への連絡に影響するか
誤った処理の影響：誤った金額の登録や、誤った宛先への送信が起こり得るか
認証情報の扱い：パスワードがシナリオや設定ファイルに平文で書かれていないか。退職者のアカウントで動いていないか
止まりやすさ：社外のシステムなど、予告なく画面が変わる相手を操作していないか

影響の大きいロボットから順に、ステップ 4 に進みます。

ステップ 4：残す・直す・置き換える・廃止するを決める

判断	向いているロボット
担当を決めて残す	安定して動いていて、画面がほとんど変わらない社内システムを操作している
直して残す	止まる原因がはっきりしていて、直せば当面は安定しそう
置き換える	相手の画面がよく変わる、例外や判断が多い、直せる人を確保できない
廃止する	業務がなくなった、使われていない、手作業で十分な件数しかない

置き換え先は、相手のシステムに API やデータ連携があればそちらを優先し、画面でしか操作できなければ、画面が変わっても直しやすい仕組みを選びます。判断の基準は「RPA の課題」の「残す・直す・AI RPA に切り替える」で詳しく整理しています。

ステップ 5：台帳と引き継ぎ書を残す

残すロボットも置き換えるロボットも、調べた内容を次の 2 つに残します。

ロボット管理台帳には、すべてのロボットを 1 行ずつ、名前、動く周期、業務の内容、入力と出力、責任者と担当者、止まったときの対応などを記入します。金融情報システムセンター（FISC）の『RPA 導入にあたっての解説書』の検討資料は、台帳をロボットの利用開始前までに作り、改修や担当者の変更のたびに更新する必要があるとしています。総務省の自治体向けガイドブックも、運用中の見直しが反映されないままでは、担当職員が異動したときに引き継ぎが難しくなると指摘しています。項目と書き方は「RPA のロボット管理台帳の作り方」で解説し、そのまま使える Excel のテンプレートも用意しています。

引き継ぎ書には、台帳の 1 行には収まらないことを書きます。

そのロボットが何のためにあるか（業務上の目的）
手順の要約と、途中で人が確認していること
過去に止まった原因と、そのときの直し方
止まったときに、代わりに手作業で処理する方法
関係する部門と、問い合わせ先

引き継ぎ書は、ロボットと同じ場所に置き、ロボットを直したら同時に更新します。別の場所で別の人が管理すると、すぐに実態から離れます。

ステップ 6：同じことを繰り返さない仕組み

引き継ぎを終えたら、作った人がいなくなっても困らない状態を保つ仕組みを入れます。

台帳に載っていないロボットは動かさない：新しく作るときは台帳への記入を条件にする
担当者は 2 人決める：責任者と担当者を分け、異動の連絡で台帳を必ず更新する
個人のアカウントや PC で動かさない：ロボット用のアカウントと、管理された実行環境を使う
変更のたびに台帳と引き継ぎ書を更新する：更新されたかを、変更を承認する人が確かめる
年に 1 回は棚卸しする：台帳と実際に動いているロボットを突き合わせる
止まったら必ず誰かに届く：失敗の通知先を、個人ではなくチームにする

Kitewell での引き継ぎ

Descarty の Kitewell は、作った人がいなくなっても直せることを前提に設計した業務自動化ソフトウェアです。

手順が業務の言葉で残る：「請求書の金額を入力する」のように、手順そのものが読める文章で書かれます
アシスタントがナレッジを書く：AI アシスタントは、ワークフローを作ったり直したりしながら、その目的、作りの理由、壊れたときの直し方をナレッジとして書き残し、次に相談を受けたときはそれを読んでから答えます
台帳を書き出せる：すべてのワークフローの名前、周期、業務内容、読み書きする Excel、接続するシステム、ナレッジを、FISC の管理項目に沿ったロボット管理台帳として Excel に書き出せます。責任者や対応方針など、人が決める欄は空けてあります
すべての実行と変更が残る：いつ何が動き、ワークフローがどう変わったか、どのステップで止まったかが記録に残ります

いま動いている RPA のロボットのうち、止まりやすいものから置き換える場合の進め方は「RPA から AI RPA への切り替え手順」をご覧ください。

まとめ

作った人のいないロボットは、いきなり止めず、入力と出力、動くところ、受け取る人から先に調べる
影響の大きいものから、残す・直す・置き換える・廃止するを決める
調べた内容は、台帳と引き継ぎ書に残し、ロボットと同じ場所で、変更のたびに更新する
台帳への登録、2 人の担当、管理された実行環境、年 1 回の棚卸しで、同じ状態を繰り返さない

出典

金融情報システムセンター（FISC）「RPA 導入にあたっての解説書【原案】」（検討資料、2019 年 12 月）
総務省「自治体における RPA 導入ガイドブック」（2025 年 7 月）