RPAで業務を自動化するには?定型作業の選び方と止まったときの戻し方

受付カードを台帳へ送る紙のコンベヤーと途中停止を表すゲートのイメージ

こんにちは。バナナデスクです。

毎日の転記をRPAに任せたい。そう考えたとき、最初に思いつくのは「どの順番でクリックするか」かもしれません。RPA(アールピーエー)は、パソコン上の入力や転記を、決めた手順に沿って自動化する仕組みです。

ただ、仕事では、途中で止まったあとにどう戻すかも大切です。台帳へ保存した直後に止まると、転記元の完了欄は空のままでも、台帳には登録が残っていることがあります。その状態で最初から動かし直すと、同じ受付をもう1件登録してしまうかもしれません。

私は、操作の順番に加えて、何を確認したら完了にするか、止まったらどこを調べて再開するかを先に決めることを勧めます。この記事では、架空の受付1件を転記する5工程と、保存直後に止まった場合の戻し方を、設計書にまとめるところまで説明します。

参照するのは、Microsoftの自動化ソフト「Power Automate for desktop」の公式資料です。掲載例は、処理をソフトへ組み込む前の設計で、製品上で実行した処理記録や時短実績ではありません。

更新日:2026年11月7日

RPAへ任せる作業は、入力と完了条件を固定できるものから

まず、毎日行っている作業を一つ選び、「何を受け取り、どこへ入力し、どうなれば終わりか」を書き出します。同じ入力条件で同じ操作を繰り返し、処理後の結果を確かめられる作業が、最初の候補になります。途中で人の判断が必要なら、その判断を自動処理の外へ分けられるかも考えます。

今回の題材は、受付の番号、種別、希望日を台帳へ移す作業です。このように1件を区別する番号や文字列をIDと呼び、ここではR001などの受付IDを使います。同じ受付を二度登録していないかも、このIDで調べます。

台帳に取り込み機能がある場合は、そちらも候補にします。CSVは表の行と列のデータを保存するファイル形式、APIはソフト同士がデータをやり取りするための窓口です。画面へ一つずつ入力する方法と、用意された取り込み機能のどちらで目的を満たせるかを確認します。

作業例 初期の候補判断 先に決めること
受付ID・種別・希望日を台帳へ転記 入力形式と登録先が決まれば候補 ID重複、入力不足、保存結果
自由文の相談に最適な回答を作り送信 そのまま定型転記と同じ扱いにしない 判断基準と人が承認する範囲
毎回構成の違うPDFを読んで見積額を確定 読み取りと価格判断を分ける 入力の標準化、金額の確認担当
すでにCSV取込やAPI連携がある台帳 画面操作以外の方法も確認 既存機能で同じ結果を安全に作れるか

最初に用意するのは、架空の受付ID・種別・希望日と、検証専用の台帳です。実顧客の情報は使わず、まず1件を対象に、入力から保存確認までの手順を決めます。処理を組んだあとも1件の結果を確かめてから件数を増やすと、どこで問題が起きたかを追いやすくなります。

無料の手元実行と、無人・クラウド連携を分ける

実行方法は、自分のPCで開始して結果を確認する使い方と、ネット経由で起動・予約実行する使い方を分けて考えます。クラウドはネット経由で利用するサービス、ライセンスは製品や機能を利用できる範囲を定めた契約です。人がPCに付かずに動かす無人実行も、同じ条件で使えるとは限りません。

2026年11月7日に確認したMicrosoftの個人Microsoftアカウント向け説明では、追加費用なしで使えるデスクトップの自動化を案内しています。一方、クラウドからの起動、スケジュール実行、組織内の共有は、アカウントやライセンスの条件が異なります。まず、自分が必要とする実行方法を一つ決めましょう。

現行の必要環境では、Windows Homeの手元での実行と、クラウドからの起動を区別しています。OSはWindowsなどの基本ソフト、CPUはPCの計算処理を担う部品です。導入するPCのOSの種類・版とCPU構成、サインインするアカウント、台帳など対象アプリの利用条件、手元かクラウドかという実行方法を控え、公式の必要環境と照合してください。ここでは特定のライセンスを購入する前提を置きません。

使う製品と版が決まったら、設計するときと実行するときの画面条件もそろえます。画面サイズ、表示倍率、ログイン状態、対象アプリの版を記録しておきましょう。条件が変わると、同じ位置を押したつもりでも別の操作になる場合があります。

受付転記を5工程へ分ける

ここからは、一つの自動処理が受付を1件ずつ順番に扱う設計です。この一連の処理を「フロー」と呼びます。入力するのは「受付ID・種別・希望日」の3項目です。

受付IDは、1件を重複なく見分けるための「一意のキー」にします。同じ受付を再開するときもIDを変えません。転記先の台帳でそのIDを検索でき、保存後にIDと内容を読み出して確かめられることが前提です。保存内容を読み出し直す作業を、ここでは「読み戻す」と呼びます。IDで検索できない台帳なら、その方法を先に決めてください。

工程 すること 進む条件
1 読み込む 未処理の受付1件を取り出す 対象IDを特定できる
2 確かめる ID・種別・希望日と転記先の既存IDを確認 必須項目がそろい、既存内容との関係を判定できる
3 登録する 未登録なら検証用台帳へ入力・保存 正しい入力先を特定できる
4 読み戻す 保存先のID・種別・希望日を読み戻す 入力と保存内容が一致する
5 完了を残す 転記元の処理結果と台帳側の識別情報を記録 保存を確認した記録がある

特に分けたいのは、工程3の「登録する」と、工程5の「完了を残す」です。工程3で保存できても、工程5へ進む前に止まれば、台帳には受付があり、転記元の完了欄は空という状態になります。完了欄だけを見ても、まだ保存していないのか、保存後に止まったのかは分かりません。

架空の受付転記を、読む、確かめる、保存する、読み戻す、完了を残すの5工程に分けた図。保存直後に止まると台帳は登録済みでも転記元の完了欄は空のままになる。
保存と完了の記録は別の工程です。保存直後の停止では、転記元の完了欄が空でも、台帳に受付が登録されている可能性があります。

工程2で同じIDが見つかった場合も、件数と保存内容を確かめます。1件だけあり、種別と希望日も同じなら、工程3の追加登録をせずに工程4・5の確認へ進めます。内容が違う場合や同じIDが複数ある場合は、自動で上書きせず、人が確認する対象として止めます。

保存直後の停止時に、同じ受付IDが保存先にあるかを照合してから進む図
1件ずつ順番に処理する設計例。同時実行の競合は別対策が必要。実RPA処理の観測図ではありません。

正常系より先に、止まり方の期待結果を書いておく

予定どおりに最後まで進むケースを「正常系」と呼びます。ただ、再開の設計では、入力不足や保存直後の停止も先に考えておきます。「この条件なら、登録を何件にし、どこで止めるか」を、試す前に書いたものが期待結果です。

次の表は、テストで確かめたい期待結果の記入例です。処理を組んだら「実際の結果」を別に残し、登録件数、保存内容、転記元の状態が期待どおりかを照合します。

試す条件 架空データ・状態 設計上の期待結果
正常 R001/相談/2026-10-12。台帳に同IDなし 1件登録し、読み戻しが一致してから完了
入力不足 R002/種別が空/2026-10-13 登録前に止める。R002の不足項目を残す
画面変更 検証画面の保存ボタンを見つけられない 推測で別ボタンを押さず停止。画面条件を確認
保存後に停止 R003は台帳へ保存済み、転記元の完了欄は空 再開時にR003を検索し、内容一致なら追加登録しない
同IDで内容不一致 台帳のR004と転記元R004の希望日が違う 自動上書きを止めて差分を確認

表の条件は、一度に1件ずつ確かめる計画にします。例えばR002なら、台帳へ書き込む前に止まるかが確認点です。R003なら、すでに台帳へ保存され、転記元の完了欄が空という状態から再開し、台帳に2件目を追加しないかを確かめます。

保存ボタンを押せても、必須項目の不足を知らせる画面や、通信エラーが出ているかもしれません。完了の条件は「ボタンを押したこと」だけにせず、「保存先から読み戻した3項目が入力と一致したこと」にします。一致しなければ、実際に見えた状態と止まった工程を残し、次の受付へ進まないように設計します。

再試行は、同じ操作を何度してもよいかで分ける

再試行とは、うまく終わらなかった処理をもう一度行うことです。RPAで組み合わせる「検索する」「文字を入力する」「保存する」といった一つずつの操作を、アクションと呼びます。

Power Automateのエラー処理資料には、一つのアクションと、複数アクションのまとまりでエラーを扱う方法があります。まとまりに再試行を設定した場合は、そのまとまりの先頭から実行し直すと説明されています。中に登録処理があるなら、再試行の回数を増やす前に、登録がもう一度行われるかを確かめる必要があります。

IDを検索し直すだけなら、台帳の登録件数は増えません。一方、新しい行を保存する操作は、繰り返すたびに件数が増える可能性があります。入力画面を開き直す操作と追加登録を分け、工程3を再び行う前には、工程2の既存ID照合へ戻す設計にします。

入力画面の再表示と新規受付の追加保存では、繰り返したときの影響が異なることを示す図。保存をやり直す前には受付IDと登録内容を照合する。
再試行の設計では、画面を開き直す操作と、新しいデータを追加する操作を分けます。保存を含む処理を先頭からやり直す場合は、重複を防ぐ照合が必要です。

保存直後に止まったR003を例に、再開手順を具体的に書いてみます。転記元の完了欄が空でも、すぐ保存ボタンを押し直さず、次の順で判断します。

  1. 止まった受付を特定する。転記元のR003を選び、種別と希望日を控えます。同じ受付を新しいIDに付け替えず、R003のまま調べます。
  2. 正しい台帳でR003を検索する。別の台帳や期間の絞り込みを見ていないかを確認し、IDが完全に一致する行を探します。検索結果が正常に表示されたことも確認します。読み込み中、通信エラー、アクセスできない状態は「未確認」であり、「0件」ではありません。その場合は書き込まずに止めます。
  3. 検索が完了し、0件なら登録する。未登録と確認できた場合だけ工程3へ進み、R003の種別・希望日を入力して保存します。その後、工程4で台帳を読み戻し、3項目の一致を確かめます。
  4. 1件あり、内容が一致するなら追加登録をしない。台帳のR003と、転記元のR003の種別・希望日を比べます。すべて同じなら、その読み戻し結果と台帳側の識別情報を控え、工程5で転記元の状態を整えます。
  5. 内容が違う、または同じIDが複数あるなら止める。どの項目が違うか、同じIDが何件あるかを記録し、担当者の確認へ戻します。自動で一方を上書きしたり、余分と思った行を削除したりしない設計にします。

表のR003で、検索結果が1件で内容も一致すると確認できた場合は、上の4番目へ進みます。新規登録はせず、保存内容を確認した記録と、転記元の完了状態をそろえます。3番目から新しく登録した場合も、読み戻しが一致してから工程5へ進めます。

この手順は、一つのフローが1件ずつ扱う前提です。複数のフローが同時に動くと、両方が「まだない」と検索したあとで、同じIDを登録する競合が起こり得ます。本番で同時実行するなら、保存先で同じIDを二つ登録できなくする「一意制約」など、台帳側で重複を防ぐ対策も必要です。

止まった時に必要な情報を、処理の記録へ残す

処理がいつ、どこまで進んだかを残す記録をログと呼びます。再開する人が同じ受付を特定でき、保存済みかどうかを調べ直せる内容にします。最初に設計書へ、次の記録欄を用意してください。

  • 実行IDと受付ID:実行IDは自動処理を1回開始するごとに付ける識別名です。どの実行で、どの受付を処理していたかを組にして残します。
  • 工程と時刻:開始時刻、止まった時刻、最後に確認できた工程。保存ボタンを押しただけなのか、保存内容まで確認したのかも分けます。
  • 照合と保存確認:IDの検索が完了したか、見つかった件数、種別・希望日の一致、台帳側の識別情報。
  • 対応と次の作業:追加登録したか、既存の内容を確認したか、誰の確認を待っているか、どの工程から再開するか。

R003の記入例なら、止まった直後は「工程3の後で停止。保存確認は未確認。次に台帳のR003を検索」と書きます。その後、1件だけあり内容も一致すると確かめられた場合に、「保存先にR003が1件あり、種別と希望日は一致。追加登録せず、工程4の確認記録と工程5の完了状態を整える」と更新します。未確認のことを、最初から保存済みと書かないのが要点です。

受付R003の架空の記録例。対象IDと停止工程、台帳が1件で内容が一致した確認結果、追加登録せず読み戻しと完了状態を整える次の対応を分けて残す。
照合できた後の架空の記入例です。止まった場所、保存先で確認できた内容、次にすることを分けると、同じ受付を追加せずに再開する判断を引き継げます。

入力内容を丸ごとログへ写すより、問題を特定するために必要な項目を選びます。パスワードや認証用のキーなど、ログインに使う資格情報は、ログや配布資料へ入れないようにしてください。

自動処理を動かせるようになってから効果を調べるときは、自動実行の時間に加えて、準備、監視、例外の修正、画面変更に合わせた修正や動作確認にかかる保守の時間も記録します。転記の時間が短くなっても、修正に長い時間がかかるなら、CSV取り込みやAPI連携などの別の方法も見直す材料になります。

最初の設計は、正常に終わる1件と、保存直後に止まる1件について、「台帳の件数と内容」「転記元の状態」「再開前に調べること」を書ければ、一つの区切りです。その設計に沿って自動処理を組み、期待結果と実際の結果を分けて確かめることで、途中からでも戻せる自動化へ進めます。