RPAとAPIの違いは？受注登録の例でわかる選び方
受注データを別の画面へ写す仕事を減らしたい。そんな担当者が迷いやすいのが、「RPAとAPIのどちらを使うか」です。APIはシステム同士が決められた方法で情報を受け渡す仕組み、RPAは人が画面で行う操作をソフトに繰り返させる方法です。どちらが優れているかではなく、今のソフトで使える方法と、止まったときに直せる人で選びます。
この記事では、架空の注文10件を同じ条件で試す例を使って、既存の連携機能・CSV・API・RPAを比べます。読み終えると、自社で先に確かめる方法と、導入前に担当者や提供会社へ聞くことを決められます。
まず、使っているソフトの標準連携やCSV取込を確認します。両方で足りない工程だけAPIを調べ、画面操作しかできない工程ではRPAを候補にします。APIが使えるかは、製品・契約プラン・権限で異なります。
まず全体像：画面を動かすか、データを渡すか
注文データを、どの方法で渡す？
左から順に確認。全部を一度に置き換える必要はありません。
今のソフトに用意された機能
最初に確認一覧を出して別の表へ取り込む
手作業が一部残るソフトの窓口からデータを直接渡す
使える条件を確認画面を開いてクリック・入力する
画面の変更に備える「自動で動いた」だけで完了にせず、元の注文と登録結果を照らし合わせます。
図の「API」と「RPA」は役割が違います。APIはデータを渡す窓口、RPAは画面で行う操作です。一つの仕事の中で、APIで情報を渡し、APIがない画面だけRPAで入力する組み合わせもあります。
APIとRPAの違いを、受注登録で比べる
たとえば、取引先から届いた注文を受注管理ソフトへ登録し、担当者が内容を確認する仕事を考えます。RPAなら、担当者が画面を開いて注文番号や数量を入力する動きを再現します。APIなら、受注管理ソフトが決めた窓口に、注文番号や数量などのデータを渡します。
| 方法 | 何をする？ | 候補になるとき | 先に確かめること |
|---|---|---|---|
| 標準連携 | 今のソフトにある機能でデータをつなぐ | 対応する相手ソフトや項目が決まっている | 対象のソフト・項目・契約プラン |
| CSV・ファイル | 一覧をファイルにして、別のソフトへ取り込む | 毎分の反映が不要で、人が取込を確認できる | 文字・列・日付の形式、二重取込を防ぐ方法 |
| API | ソフトが用意した窓口を通じてデータを渡す | 決まった情報をソフト間で定期的に渡したい | 使えるプラン、権限、対象項目、回数制限、失敗後の確認方法 |
| RPA | 画面を開き、クリックや入力を行う | APIや取込機能がなく、画面での操作が必要 | 画面や項目が変わったとき直す人、処理済みの確認、再実行の範囲 |
APIならいつも速くて安い、RPAなら壊れやすい、と決めつけることはできません。使える機能、毎月の費用、設定・確認・修正に必要な時間は、ソフトや契約内容で変わります。RPAも画面の位置だけを見るとは限らず、製品によって画面上の項目名などを手がかりに操作します。それでも画面や表示条件が変わると調整が必要なことがあるため、保守する人を決めておきます。
架空の注文10件で、同じ完成条件を試す
方法を選ぶときは、候補ごとに違う注文を使わず、同じデータと同じ完成条件で比べます。次の10件は説明用の架空例です。処理時間や費用を実測した結果ではありません。
| 注文10件の内訳 | 何を確認する？ | 試行後の正しい状態 |
|---|---|---|
| 通常の注文 7件 | 番号・数量・商品が受注管理へ渡るか | 7件が元の注文と同じ内容で登録される |
| 同じ注文番号がある行 2件 | 重複を勝手に登録・削除しないか | 2行とも確認待ちに分かれる |
| 数量が空欄の行 1件 | 書かれていない数量を補わないか | 確認待ちに分かれる |
この例の完成条件は「通常の7件は元の注文と同じ内容で登録され、重複2件と数量空欄1件は確認待ちとして残る」です。金額の計算や販売確定は、この試行の範囲に含めません。受注管理の担当者が確認待ちの3件を原本と照合してから、先へ進めます。
試す前に決める6項目
- 対象を一つに絞る：例「注文メールから、受注管理ソフトへの登録まで」。請求・出荷・支払まで一度に広げません。
- 元資料と完成形を決める：受け取る項目、登録先、未記入や重複の扱いを一覧にします。
- 使える方法を確認する：標準連携、CSV出力・取込、API、画面操作の順に、提供会社の公式資料と契約プランで確認します。
- 使ってよい範囲を確認する：取引情報を渡す先、アカウント権限、社内ルールを確認します。動作のために個人用アカウントや共有パスワードを安易に使いません。
- 失敗したときの戻し方を決める：どの行まで登録したか、重複をどう見つけるか、誰が停止・再開するかを決めます。
- 同じ10件を候補ごとに試す：登録内容、確認待ち、抜け、重複、確認と修正の時間、費用を記録します。
「APIあり」と書かれていても、必要なデータを書き込めるとは限りません。読むだけか、登録・更新もできるか、使うプランで許可されるかを、製品の公式資料や提供会社への質問で確かめてください。仕様や契約条件が確認できないまま、本番データで試さないことが大切です。
止まった後の確認で、APIとRPAを比べる
通常どおり動くかだけでなく、途中で止まったときに「どこまで終わったか分かるか」「同じ注文をもう一度入れないか」も確かめます。次の4つは、同じ架空の注文を使って確認できる試験項目の例です。特定の製品で実行した結果ではありません。実際に使う製品・契約・設定で、許可されたテスト環境を使って確認してください。
1. 送信後に返事が来ない
通信が切れて、登録先に届いたか分からない。
先にすること：同じ注文番号が登録先にあるか検索します。見つからず結果も確かめられない間は、再送せず確認待ちにします。提供会社には「同じ依頼を再送した場合、二重登録を防げるか」を聞きます。
2. RPAが入力欄を見つけない
画面や項目が変わり、操作先が分からない。
先にすること：近くの別のボタンを押さず、その注文の処理を止めます。止まった画面・手順・注文番号を記録し、担当者がテスト環境で直した後に確認します。
3. ログインや権限が切れた
登録先へ入れず、処理が続けられない。
先にすること：自動処理を止め、権限を持つ人が原因を確認します。個人のアカウントや共有パスワードで回避せず、誰がアクセスを戻したかを記録します。
4. APIの後でRPAが止まった
組み合わせて使う場合、前半だけ済むことがある。
先にすること：注文番号で登録先を照合し、終わった工程と残った工程を分けます。全体を最初からやり直さず、未完了分だけを再開できるか試します。
まず注文番号で登録先を照合し、どこまで終わったか分けます。
同じ注文を続けて送らず、停止した時刻と手順を残す。
登録画面と実行記録を見て、処理済みの工程を探す。
処理済みと記録し、同じ注文を再送しない。
担当者が確認して、終わっていない工程だけ再開する。
確認待ちで止め、担当者が原本と登録先を照合する。
一件だけ再開し、登録結果を確かめてから次へ進む。
図では、注文番号で照合した結果を「登録済み」「未処理」「結果が不明」に分けます。登録済みなら再送せず、結果が不明なら確認待ちで止めます。未処理と確認できた工程だけを担当者が一件ずつ再開し、登録先をもう一度照合してから次の注文へ進みます。
記録する項目：試した状況／注文番号／どの工程まで終わったか／画面や記録で確認できた根拠／止めた人／再開してよいと判断した人。合格の目安は、通常の7件が一度ずつ登録され、重複2件と数量空欄1件は確認待ちに残り、途中で止めても処理済みと未処理を分けられることです。実際の製品の動作や処理時間は、このページでは測定していません。
画面項目が見つからない場合の直し方や、エラー時の再試行方法は製品によって違います。Microsoftの説明では、画面の項目やその見つけ方が変わると、RPAが対象を見つけられず止まることがあります。APIも、通信が切れたからといって何度でも同じ依頼を送り直してよいとは限りません。登録先に結果があるかを先に確かめ、再送時の重複防止を提供会社へ確認します。
迷ったら、この順番で決める
1. 標準連携があり、必要な項目まで渡せる
まず少量のデータで試し、元データと登録結果を確認します。
2. 標準連携がなく、CSVで安全に受け渡せる
取込前後の件数と重複を確認する人を決めます。
3. 定期的に直接データを渡したく、使えるAPIがある
契約プラン、対象項目、失敗時の通知と再実行を確認します。
4. APIや取込機能がなく、画面操作しかできない
RPAを候補にし、画面の変更を直す人と、止める・戻す方法を決めてから試します。
どれか一つの方法を全体に当てはめなくてもかまいません。注文データの受け取りはファイル、対応ソフト同士の受け渡しはAPI、残った画面操作はRPAというように、工程ごとに分けられます。最初の仕事の選び方は、業務自動化で最初に試す仕事の決め方も参考になります。
提供会社に聞くこと
- この契約プランで使える連携方法は何ですか。追加料金や件数上限はありますか。
- 必要な項目を登録・更新できますか。読取だけの項目はありますか。
- 一部だけ処理して止まった場合、どこまで終わったか確認できますか。
- 同じ注文をもう一度送ったとき、二重登録を防げますか。防げない場合の確認方法は何ですか。
- 画面や項目名が変わった場合、誰がいつ修正し、費用はいくらですか。
- 利用をやめるとき、設定・データ・記録をどの形で取り出せますか。
よくある質問
APIが使えるなら、RPAは不要ですか？
不要とは限りません。APIで扱えない画面操作が工程に残る場合や、APIが用意されていない古いソフトがある場合は、RPAを一部で使うことがあります。先にAPIで渡せる範囲を確認し、画面操作に残る工程だけ別の方法を検討します。
RPAは画面が変わると必ず止まりますか？
必ず止まるわけではありません。使う製品や画面の作りで違います。ただ、画面の項目や表示条件が変わると、操作の調整が必要になることがあります。修正する人、エラーに気づく方法、処理済みの確認方法を用意しておきます。Microsoftの公式資料も、画面要素を見つける条件が画面変更や解像度の影響を受ける例を説明しています。
最初から全部の注文を自動登録してよいですか？
最初は少ない件数で試し、通常の注文だけでなく重複や空欄も確認します。元の注文と同じ内容になり、確認待ちが正しく分けられ、止め方と戻し方が分かるまでは、対象を広げません。停止後の手順は業務自動化が止まったときの安全な再開方法で確認できます。
参考にした資料
- 政府CIOポータル「RPA導入実践ガイドブック」（RPAを使う場合の適性と、従来技術を比べる考え方）
- Microsoft Learn「UI要素を使った自動化」（画面上の項目を見つける仕組み）
- Microsoft Learn「Power Automate のライセンスの種類」（コネクタやRPAの利用条件。実際の契約条件は各社で確認）
- Microsoft Learn「デスクトップ フローでのエラー処理」（操作が失敗した場合の停止・再試行の設定例）
- AWS「Ensuring idempotency in Amazon EC2 API requests」（APIを再送する際の重複防止の仕組みの一例。利用するAPIの仕様は個別に確認）
このページの注文例は説明用の架空データです。自社の処理時間・費用・削減効果を測った結果ではありません。製品の機能や契約条件は、導入前に提供会社の最新の公式資料で確認してください。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。
