RPAとプログラムの違いは？注文集計の例でわかる選び方

毎月、注文画面からデータを取り出して、Excelにまとめる。件数が増えるほど、転記や確認に時間がかかります。「RPAを使えばよいのか、それともプログラムを作るべきか」と迷っていませんか。

この記事は、社内の繰り返し作業を減らしたい担当者や、導入を判断する責任者に向けたものです。同じ注文データを例に、二つの方法の違い、選ぶ前に確認すること、間違いや変更が起きたときの対応を説明します。読み終えると、自社の仕事で何を調べ、誰とどこまで試せばよいかが見えてきます。

先に結論：データの受け取り方と、直せる人で選ぶ

図を拡大して見る

• 決まった画面を操作する必要があるなら、画面操作を自動化するRPAが候補です。
• 利用を許可されたCSVファイルを取り出せるなら、ファイルを直接読み込むプログラムも候補です。
• 取り出しは画面から、集計はファイルでというように、組み合わせることもできます。
• どちらも、間違ったデータをどう扱うか、止まったときに誰が直すかが決まらなければ、すぐに本番へ進まず小さく試します。

CSVは、表のデータを文字で保存するファイルです。Excelなどで開けます。どの方法がよいかは、作業の順番、使える機能、費用、社内で直せる人によって変わります。

まずは今使っている受注システムに、集計やCSV出力の機能がないか確認しましょう。すでに必要なことができるなら、新しい仕組みを作らずに済む場合があります。

RPAとプログラムは、何が違う？

RPAは、繰り返す事務作業をソフトウェアで自動化する方法です。たとえば、人が行う「注文画面を開く→条件を選ぶ→一覧を保存する」という操作を、ツールに実行させます。ツールによって、画面だけでなくファイルや他の機能と連携できるものもあります。

プログラムは、「ファイルを読み、数量と単価を掛け、結果を書き出す」といった手順を、コンピューターが実行できる形で記述したものです。Pythonは、その記述に使える言語の一つです。

RPAにもプログラムのような指示やコードを使うものがあります。ここでは違いをつかみやすくするため、画面を操作するRPAと、CSVを直接読むプログラムを例に比べます。

画面の変更に強いか、誰でも直せるか、費用がいくらかは、使う製品や作り方によって変わります。名前だけで決めず、実際の仕事で確かめます。

同じ5行の注文データで考えてみよう

図を拡大して見る

次は説明用の架空データです。注文一覧には5行ありますが、A02は同じ番号が2行あるため、それぞれ別の注文かどうかは確認が必要です。A03は数量が空欄です。

この例では、「同じ注文番号が複数あれば、どちらも確認待ちにする」「数量が空欄なら計算しない」という仮のルールを使います。結果は、計算できる2行の小計が1,600円、確認待ちが3行です。1,600円は全注文の売上ではありません。

重複は、単なる再送とは限りません。注文の訂正や分割を表す場合もあります。実際にどう扱うかは、元の注文と業務のルールを確認して決めましょう。

画面操作を使う場合

たとえば、担当者が普段使う注文画面をRPAで開き、対象月の一覧を表示します。保存できる場合は一覧を保存し、決めたルールで確認待ちと計算対象を分ける仕組みを用意します。画面上で直接確認するか、保存したファイルを別の方法で処理するかは、システムと許可された操作に合わせて決めます。

画面の見た目が変わったり、ログインを求められたりすると、予定どおり進まないことがあります。途中で止まったら担当者に知らせ、処理済みの範囲を確認してから再開できるようにします。

CSVを使う場合

注文一覧をCSVとして取り出せるなら、そのファイルをプログラムで読みます。たとえばPythonの標準ライブラリには、CSVの行を読み書きする機能があります。プログラムに、注文番号の重複と数量の空欄を探すルールを与え、計算できる行と確認待ちの行を分けます。

今回の架空例は、CSVを読むPythonの処理で「計算対象2行、小計1,600円、確認待ち3行」になることを確認しています。RPAの実際の操作や所要時間は測っていません。どちらが速いか、この例だけでは決められません。

どちらを使っても、最後に人が確認する

図を拡大して見る

出力は合計金額だけにしないことが大切です。少なくとも「元の5行」「計算した2行」「確認待ちの3行」「計算対象の小計」を照らし合わせます。確認待ちの理由と注文番号が残っていれば、担当者が元の注文を探せます。

A02が再送なのか訂正なのか、A03の数量はいくつか。担当者が元の資料で確かめ、正しい注文データを用意してから再計算します。空欄を勝手に0として扱ったり、重複の片方を根拠なく消したりしないことがポイントです。

自社では、どちらから試す？

図を拡大して見る

1. まず、データの入り口を確かめる

図を拡大して見る

注文一覧を、許可を得たうえでCSVとして出せますか。出せるなら、直接ファイルを処理する方法を検討できます。画面での操作しか認められていないなら、画面操作が候補になります。CSVの取得自体に画面操作が必要なら、両方を組み合わせる選択もあります。

顧客情報が含まれる場合は、保存先や利用権限も社内のルールに従って確認してください。説明用には、実際の顧客情報を含まないデータを使いましょう。

2. できあがりを決める

「合計を出す」だけでなく、何件のうち何件を計算し、何件が確認待ちかを決めます。先ほどの例なら、完成の目印は「5行を確認し、2行の小計1,600円と3行の確認待ちを区別できること」です。

出力を誰が、元のどの資料と照らし合わせるのかも先に決めます。確認できない結果は、そのまま請求や売上の確定に使わないようにします。

3. 動かす人と直す人を決める

図を拡大して見る

画面を操作する方法なら、画面が変わったときに操作を直せる人が必要です。ファイルを読む方法なら、列名や計算ルールが変わったときに処理を直せる人が必要です。外部へ依頼する場合も、変更を誰に伝え、どこまで対応してもらえるか確認します。

毎月の操作に使う時間だけでなく、初期設定、利用料、エラーの確認、修正の負担も合わせて比べましょう。費用を比較するときは、同じ期間で必要な金額と社内の作業時間をそれぞれ確認します。

4. 同じ条件で少量を試す

図を拡大して見る

同じ種類・件数のデータを使い、今の方法と候補の方法を比べます。作業時間を測るときは、自動処理の時間だけでなく、人の確認や直しにかかった時間も含めます。結果が合っているかを確かめる基準も、先にそろえます。

一度成功しても、空欄、重複、列名変更などで止まる場合を試し、結果や確認待ちが残るかを確認しましょう。実行に必要な端末の状態や権限は製品ごとに異なります。

止まったとき、何をすればいい？

図を拡大して見る

1. いったん止める。 途中でエラーが出たら、結果を完成扱いにせず、送信や請求など次の作業へ渡すのを止めます。
2. どこまで処理したか調べる。 元データ、処理済みの行、確認待ち、エラー内容を照合します。処理済みのものを再び登録しないようにします。
3. 原因を直す。 空欄なら担当者が元の注文を確認し、画面や列名の変更なら修正できる人へ知らせます。
4. 再開前に方法を決める。 修正後は、どのデータからやり直すかを確認します。安全に再実行できるか不明なら、担当者が確認しながら従来の手順に戻します。
5. 結果をもう一度照合する。 件数、確認待ち、小計を元資料と比べ、責任者が次の作業へ進めるか判断します。

自動で止まる条件、通知先、再開の方法は、使うシステムに合わせて実装・確認する必要があります。どの方法でも最初から備わっているとは限りません。

よくある疑問

図を拡大して見る

プログラムが書けない人はRPA一択ですか？

いいえ。既存システムの機能で足りる場合も、外部担当者と一緒にファイル処理を作る場合もあります。一方、RPAも作って終わりではなく、画面変更やエラーへの対応が必要です。社内外の誰が運用するかを合わせて考えます。

RPAなら間違いはなくなりますか？

図を拡大して見る

いいえ。入力された情報が間違っていたり、画面や手順が変わったりすると、誤った結果になることがあります。確認待ちを分け、元資料と照らし合わせる工程を残しましょう。

最初から全部の注文を自動処理してよいですか？

図を拡大して見る

少量の説明用データで、通常の行と空欄・重複などを確認するところから始めます。本番へ広げるかは、担当者、費用、確認方法、止め方を決めてから判断します。

まとめ：最初に確認するのは、この3つ

1. 注文データを、どの画面やファイルから受け取れるか。
2. 結果と確認待ちを、誰が何と照らし合わせるか。
3. 画面やデータが変わったとき、誰が止めて直せるか。

この3つを、普段の仕事をよく知る人と一緒に確認してみてください。そのうえで、既存の機能、画面操作、ファイル処理、組み合わせの中から、小さく試せる方法を選びましょう。

参考資料

• Microsoft：Power Automate for desktop のUI要素 — 画面の要素を扱う機能の説明。
• Python公式：csv — CSVファイルの読み書き — PythonでCSVを扱う機能の説明。
• Microsoft：無人実行の問題を解決する — 同製品で無人実行する際に確認する条件。
• 業務自動化は何から始める？ — 自動化する仕事を選ぶときの考え方。
• システム連携について — システム間で情報を受け渡すときの考え方。