RPA入門｜定型作業を自動化するルールベースの基本とAIとの違い

「この転記作業、毎週くり返してるな……」。毎週決まった曜日に、同じ画面を開いて、同じ順番でコピーして、別の画面に貼り付けて、保存する。受信したデータを別のシステムに移すだけの作業なのに、毎回30分。気づけば一定の時間がそれだけで消えていきます。「RPAで楽になるらしい」と聞いたことはあっても、何が自動化できて何ができないのか、そもそも「AIと何が違うのか」が分からないまま、最初の一歩を踏み出せずにいる——本講座は、まさにそこから始めます。

先に、本講座が扱う範囲をはっきりさせます。本講座が相手にするのは「人があらかじめ決めたルールどおりに、画面操作やデータ転記を機械が反復実行する自動化」、つまりRPA（ロボティック・プロセス・オートメーション）です。逆に、内容を読み取って判断したり、要約や分類や文面作成のように何かを生み出したりする自動化は扱いません。読み取り・要約・分類・文面作成をAIに任せる自動化はAI業務自動化入門が、コードを書かずにツール同士をつなぐノーコード連携はノーコードツール入門が、それぞれの正本です。改善ネタ（ムダ・ムラ・ムリ）の見つけ方は業務改善の基本、デジタル化とDXの全体地図はDXの基礎に譲ります。本講座は「ルールが完全に決まった画面操作・転記をRPAに反復させる」ところだけに集中します。

この講座を終えると、次の3つができるようになります。RPAとは何か（人が決めたルールどおりに画面操作・転記を反復する仕組み）と、AIによる自動化との違いを説明できること。自分の定型作業を操作手順に分解して、ルールが固定できる工程（RPA向き）と判断・例外が多い工程（不向き）を見分けられること。そして1つの作業について、RPA化の流れ（操作手順の洗い出し → ルール固定 → 例外時に止めて人へ渡す設計）を1枚にまとめて作成できることです。覚えて帰る型は「作業を操作手順に分解する → ルールを固定する → 例外時は止めて人に渡す → 小さく試して回す」。本講座では、毎週くり返している「受信データを別システムへ転記する作業」（例）を共通の題材にして、全章で同じ作業を追いかけます。なお、RPAの定義や用語、効果の数字や製品名は、調査で出典が取れたものだけを扱い、変わりやすい数値は「（例）」と断ったうえで使います。

RPAとは何か——ルールベースの反復自動化とAIとの違い

RPAは「決めた手順を機械が反復する」ルールベースの自動化

RPAとは、これまで人間が行ってきた定型的なパソコン操作を、ソフトウェアのロボットによって自動化する仕組みです（出典：総務省「情報通信統計データベース」）。ここでいうロボットは、工場の腕や掃除機のような物理的なボディを持つものではありません。パソコンやサーバーの上で動き、人間のマウスやキーボードの操作を画面ごと再現します（出典：J-Net21「第24回：RPA導入編」）。表計算ソフト、メールソフト、基幹システムなど、複数のアプリケーションをまたいで「人が画面でやっていた操作」を、そのまま機械にやらせる——これがRPAの素の姿です。

ひとことで言えば、RPAは「パソコンで実施する定型業務を、ソフトウェア型のロボットで代行する仕組み」です（出典：J-Net21「第24回：RPA導入編」）。共通例の転記作業で言えば、「Aシステムを開く → 該当する行をコピーする → Bシステムに貼り付ける → 保存する」という一連の操作を、人の代わりに機械がくり返してくれる、ということになります。順番が毎回同じで、判断を挟まずに進められる操作ほど、RPAの出番です。

RPAが得意なこと・しないこと——判断と生成はAIの領域

ここで多くの人がつまずくのが、AIとの違いです。RPAとAIは混同されやすいのですが、別物です。AIはデータを活用してコンピューター自らが判断を下しますが、RPAの判断基準はあくまで人間が決め、コンピューターはそれに従うだけです（出典：J-Net21「第24回：RPA導入編」）。つまりRPAは、人間が覚えさせた動作を、決めたとおりにくり返すだけ。自分で考えたり、内容を読んで分類したり、文面を作ったりはしません。データからパターンを学習して未知の状況に対応したり、予測や意思決定をしたりするのは、機械学習・深層学習を使うAIの領域です（出典：J-Net21「RPAツールを導入する」）。だからこそ、RPAが向くのは「様式の決まったデータを大量に扱う」定型業務です（出典：J-Net21「第24回：RPA導入編」）。

参考までに、RPAは自動化のレベルでクラス1・クラス2・クラス3に分けて語られることがあります。クラス1（RPA）は情報取得・入力・検証といった定型業務の自動化、クラス2（EPA）はAI技術と組み合わせて一部の非定型を自動化、クラス3（CA）はディープラーニング等でプロセスの改善や意思決定まで担う、という段階です（出典：総務省「情報通信統計データベース」）。本講座が扱うのは、このうちクラス1にあたる「ルールベースの定型自動化」です。判断や生成をAIに任せたくなったら、それはクラス2以上の話で、AI業務自動化入門の射程になります。本講座では、判断のいらない反復操作だけを相手にします。

「RPA＝AIで何でも判断してくれる」というつまずき

ここでのつまずきは2つあります。1つは「RPAはAIだから、何でも賢く判断して自動化してくれる」という思い込み。実際のRPAは判断をしません。決めた手順を、速く・正確にくり返すだけです。もう1つは逆方向のつまずきで、「ただの繰り返しだから簡単だろう」と軽く見て、例外への備えを忘れることです。RPAは一度きちんと手順が定義されれば、コピー元やペースト先を人間のように間違えることはありません。ただし「きちんと定義されていること」が大前提で、想定と違うものが画面に表示されると、すぐに停止してしまいます（出典：J-Net21「第24回：RPA導入編」）。つまりRPAは、決めたとおりにしか動けないからこそ正確で、決めていない事態には弱い。この性質が、後の章で出てくる「ルールを固定する」「例外時は止めて人に渡す」という設計の土台になります。記憶に残してほしいのは、RPAは賢く考える機械ではなく、決めたとおりに正確にくり返す機械だ、ということです。

この章の確認（演習）

自分の身近な作業を1つ挙げ、その作業の中の操作を「順番が毎回同じ操作（ルールベース）」と「内容を読んで判断する操作」の2列に分けて書き出してみましょう。たとえば共通例の転記作業なら、「コピーして貼る」は前者、「この案件はどの担当に振り分けるか考える」は後者です。そのうえで、「RPAに任せられそうなのはどちらの列か」「AIや人の判断が要るのはどちらか」を一言で説明してみてください。

RPAに向く作業を見分ける——定型作業の棚卸し

RPAが効くのは「くり返しが多い・手順が同じ・判断が要らない」作業

RPAが最も力を発揮するのは、単純な繰り返し作業やルーチンワークです（出典：J-Net21「RPAツールを導入する」）。様式の決まったデータを大量に扱う業務——帳簿入力、伝票作成、経費チェック、データの転記など——が代表例です（出典：J-Net21「第24回：RPA導入編」）。これらを機能の言葉に言い換えると、RPAが向く作業には3つの共通点があります。くり返し回数が多いこと、操作の順番（手順）が毎回ほぼ同じこと、そして内容の判断がほぼ要らないこと。共通例の転記作業は、毎週・同じ画面・同じ順番・判断なしでコピーして貼るだけなので、まさにRPA向きの典型です。

逆に、RPAが不向きなのは「人の判断が必要な作業」「臨機応変な対応が必要な作業」「毎回ルールが変わる非定型の作業」です。RPAは人間の指示どおりにしか動かず、その都度考えて判断が必要な作業は、現在主流のクラス1では難しいとされています（出典：総務省「情報通信統計データベース」）。そもそもRPAは人工知能ではないので、想定外の状況にファジー（柔軟）に対応してはくれません（出典：J-Net21「第24回：RPA導入編」）。たとえば「受信データの内容を読んで、どの部署に回すか決める」工程は、内容次第で答えが変わる判断なので、RPAだけでは任せきれません。こうした内容を読んで分類・要約する工程をAIに委ねたくなったら、それはAI業務自動化入門の領域です。

まず作業を「画面・操作・データ」の単位で手順に分解する

向き・不向きを見分けるコツは、作業を「まるごと」見ないことです。1つの作業の中にも、ルールが固定できる工程と、判断が要る工程が混ざっています。だから、まず作業を「どの画面で・どんな操作を・どのデータに対して行うか」という単位に分解します。共通例の転記作業なら、「Aシステムを開く」「検索条件を入れる」「該当データをコピーする」「Bシステムに貼る」「保存する」というように、操作を一つずつ並べます。そのうえで、各工程に「毎回同じか／判断が要るか」で印を付けます。順番が固定できる連続した区間が、RPAに任せられる範囲です。途中に「内容を読んで仕分ける」ような判断工程が挟まっていたら、そこは人が残す範囲として切り分けます。

このとき大事なのは、「自動化できなさそう」と決めつけて作業を選ばないことではなく、ふだん時間や手間を多く取られているルーチンワークに注目して選ぶことです（出典：J-Net21「第24回：RPA導入編」）。時間が溶けている作業ほど、RPA化の効果が出やすいからです。

“まるごと自動化”しようとして不向きな工程まで詰め込むつまずき

ここでのつまずきは2つです。1つは、作業全体を「まるごと自動化」しようとして、判断が要る不向きな工程まで無理に詰め込んでしまうこと。判断工程を機械に押し付けると、想定外の入力で止まったり、誤ったまま進んだりします。もう1つは、分解が粗すぎて「どの工程で操作が変わるか」「どこに判断が入るか」が見えないことです。「データを処理する」のような大きな塊のままでは、向き・不向きの線が引けません。1クリック・1入力の単位まで分けて初めて、任せる範囲と人が残す範囲の境目が見えてきます。RPAに向くのは、あくまで判断のいらない反復区間だけ——この線引きが、次の章の設計の出発点になります。

この章の確認（演習）

自分の定型作業を1つ選び、その作業を「画面・操作・データ」の単位で手順に分解してください。各工程に「毎回同じ（向き）」「判断が要る（不向き）」の印を付け、ルールが固定できる連続した区間を線で囲みます。そのうえで、「RPAに任せる範囲」と「人が残す範囲」を1文ずつで言えるようにしてみましょう。

RPA化の流れを設計する——手順の洗い出し → ルール固定 → 例外時の止め方

動かす前にルールを書き切る——手順を洗い出し、インプットとアウトプットを整理する

RPA化でいちばん大事なのは、動かす前にルールを書き切ることです。前章で「RPAに任せる範囲」として囲んだ区間について、操作手順を1ステップずつ洗い出します。このとき、その作業の「インプット（参照する帳票やデータベース）」と「アウトプット（出力する帳票や入力するデータベース）」を整理しておきます（出典：J-Net21「第24回：RPA導入編」）。共通例なら、インプットは「Aシステムの受信データ」、アウトプットは「Bシステムの転記先」です。RPAに実行させる手順は「シナリオ」（ツールによっては「ワークフロー」「パターン」とも）と呼ばれ、手作業で行っていた業務を手本に、画面上の操作を一つずつ登録して一連の流れとして定義します（出典：J-Net21「第24回：RPA導入編」／日立ソリューションズ「RPAに起こりがちなエラーは『例外』と『変更』」）。ここで、人が無意識にやっている確認（たとえば「貼り付け先の行が正しいか目視する」）も、忘れずに手順として書き出すのがコツです。暗黙の確認をルールに書き落とすと、後で例外を見逃す原因になります。

毎回固定する値・判定条件をルールとして決める

手順を書き出したら、各ステップで「毎回固定する値」や「判定条件」をルールとして決めます。共通例なら、「検索条件は常にこの値」「コピーする列はこの3列」「貼り付け先はBシステムのこの画面」といった具合に、変わらない部分をはっきりさせます。あわせて、変わりやすい値（参照先のURLやファイルの置き場所など）は、手順の本体に埋め込まず、外に切り出して管理できるようにしておくと、後の変更に強くなります（出典：日立ソリューションズ「RPAに起こりがちなエラーは『例外』と『変更』」）。なお、特定のツールでこの設定をどう作るかという操作手順そのものには、本講座は踏み込みません。コードを書かずにツールをつなぐ連携の操作はノーコードツール入門が正本です。本講座はあくまで「何をルールとして固定すべきか」という設計の考え方に集中します。

想定外が来たら勝手に進めず止めて人に渡す設計が暴走を防ぐ

設計でいちばん抜けやすく、いちばん大事なのが、例外時の止め方です。RPAは人の指示どおりにしか動かず、その指示の段階に誤りがあっても、RPA自身は「間違い」として検知できません。そのまま誤発注や誤送信、無意味なデータ収集を進行し続けてしまうこともあります（出典：日立ソリューションズ「RPA運用におけるリスク」）。だからこそ、エラーを想定して、最初のシナリオ作成時に「例外処理」をきちんと組み込んでおくことが欠かせません（出典：日立ソリューションズ「RPAに起こりがちなエラーは『例外』と『変更』」）。共通例なら、「該当データが0件のときは処理せず担当者に通知して止める」「貼り付け先がいつもと違う画面なら止める」といった例外時のルールを、あらかじめ1枚に書いておきます。想定外が来たら勝手に進めず、止めて人に渡す——この“止め方”の設計が、暴走や誤転記を防ぎます。

もう1つ覚えておきたいのが、シナリオを適切な単位で分割しておくことです。処理が長く複雑なシナリオを1本にまとめてしまうと、途中で止まったときに原因の特定がしづらく、復旧後も最初からやり直しになりがちです。適切な単位で分割しておけば、例外が起きた箇所を特定しやすく、再実行する範囲も限定できます（出典：日立ソリューションズ「RPAに起こりがちなエラーは『例外』と『変更』」）。最後に、ここまでの「操作手順」「固定するルール」「例外時に止める条件」を1枚のRPA化メモにまとめれば、設計は完成です。

この章の確認（演習）

第2章で選んだ作業について、「操作手順（1ステップずつ）」「固定するルール（毎回変えない値・判定条件）」「例外時に止める条件（想定外データ・想定外画面が来たらどうするか）」の3つを、1枚のRPA化メモにまとめてください。とくに、人が無意識にやっている確認を手順に書き出せているか、止める条件を1つ以上書けているかを確認しましょう。

動かした後に回し続ける——テスト・例外対応・運用の勘所

まず一部だけ・少量で試して、元データと突き合わせる

RPAは「作って終わり」ではありません。最初はトライ＆エラーの連続だと考えておくのが現実的です。正常なデータではスムーズに動いても、想定外のデータが入ると、そこで止まってしまうことがよくあります（出典：J-Net21「第24回：RPA導入編」）。だからこそ、いきなり全件・本番で動かすのではなく、従来の業務と並行しながら、小さな業務・少量から試すスモールスタートが基本です（出典：J-Net21「第24回：RPA導入編」）。共通例の転記作業なら、まず数件（例）だけで動かし、想定どおりに貼られるか、想定外のときにきちんと止まるかを確認します。このとき、RPAの出力を元データと突き合わせて、誤転記や抜けがないかを人が確かめる工程を必ず残します。RPAは指示の誤りを自分では検知しないので、「RPA化した分は機械が処理し、人間はエラーチェックに引っかかったものを精査する」という分担が現実的です（出典：J-Net21「第24回：RPA導入編」／日立ソリューションズ「RPA運用におけるリスク」）。

止まったら例外ルールに沿って原因を切り分ける

RPAが止まる原因は、大きく2つに分けられます。1つはパソコン環境の変化による「例外」、もう1つは業務上の「変更」です（出典：日立ソリューションズ「RPAに起こりがちなエラーは『例外』と『変更』」）。操作対象アプリのボタンの仕様が変わった、ダウンロードするファイルの拡張子が変わった、といった変化は、事前通知なく起こることが大半で、防ぐのが難しいものです（出典：日立ソリューションズ「RPAに起こりがちなエラーは『例外』と『変更』」）。止まったときは、第3章で決めた例外ルールと照らし合わせ、「どのステップで・どんな想定外が起きたのか」を切り分けます。シナリオを単位ごとに分割しておけば、この特定と再実行が楽になります。つまずきやすいのは、正常時の手順だけを作って例外を決めておらず、止まったときに原因を説明できないことです。例外を先に決めてあれば、止まること自体が「設計どおりの安全装置が働いた」と分かります。

画面・仕様変更で止まる前提——見直す人と頻度を決めておく

最後の勘所は、運用です。RPAは画面やシステムの仕様変更で、いつか必ず動かなくなる前提で運用します。ここで気をつけたいのが「野良RPA（野良ロボット）」です。業務やシステムの変更でロボットが現行の運用に合わなくなり、それでも停止されずに残り続けると、誰が作ったか・誰が直せるか分からないブラックボックスになります。作成者が異動・退職するとなおさらで、誤処理や無駄なシステム負荷、ほかのロボットへの連鎖的な悪影響を招きます（出典：ユーザックシステム「RPA運用で野良ロボットを生み出さないためのポイント」）。これを防ぐには、定期的な棚卸し（いま使われているか・業務に合っているか）と、廃止を判断する仕組みが要ります（出典：ユーザックシステム「RPA運用で野良ロボットを生み出さないためのポイント」）。実務では、「誰が見直し担当か」「どのくらいの頻度で点検するか」「止まったときの連絡先はどこか」を、運用ルールとして最初に決めておきます。任せきりにせず、人が監督する範囲を残す——これが安全運用の勘所です。なお、自動化の前提として業務そのものの見直し・標準化から手をつけたい場合は、業務改善の基本が正本です。

この章の確認（演習）

第3章で作ったRPA化メモに、2行を追記してください。1行目は「テストのやり方」——まず何件（例）を、どの元データと突き合わせて、何を確認するか。2行目は「運用ルール」——見直し担当は誰か、点検の頻度はどのくらいか、止まったときの連絡先はどこか。これで、設計から運用までが1枚でつながります。