RPA の業務を API・AI エージェントへどう移すか — 読む・書く・判断するで分ける
API 連携は何から調べるかでは、手段を選ぶ順番を置きました。すでに RPA で動いている業務を移すときは、その順番が変わります。
「RPA が画面の変更で止まった。もう API か AI に替えたい」— その気持ちで全部を一度に移そうとすると、別の形で止まります。まず分けます。
シナリオを 3 つに分ける
| 種類 | RPA がやっていること | 移し先 |
|---|---|---|
| 読む | 相手の画面を開いて値を取り、表に貼る | 相手に API があれば API。無ければ CSV の書き出し（純正の機能で足りることが多い） |
| 書く | 表の値を相手の画面に入力する | 相手に API があれば API。無ければ、人の確認を挟んだ AI エージェント（画面操作） |
| 判断する | 値を見て、人が分岐を決めている | 移さない。人に残し、前後だけを自動にする |
分ける物差しは「相手のシステムに API があるか」です。純正連携・CSV・API・iPaaS（システム同士をつなぐ中継サービス）・RPA の 5 つの手段のどれで繋ぐかは 連携の手段の選び方 に置きました。
移す順番
| 順 | 何から | なぜ |
|---|---|---|
| 1 | 相手に公開 API がある「読む」 | 一番安定し、失敗しても元のデータは壊れない |
| 2 | 相手に公開 API がある「書く」 | 認証（OAuth なら範囲と期限を絞れる）と回数の上限を先に読む |
| 3 | API が無い「書く」 | 人の確認を挟んだ AI エージェントか、RPA のまま残す。壊れ方（止まるか、進み続けるか）の既定を決める |
「API があるか」は ○ × ではありません。公開度（第三者に使えるか）と契約の壁（いまのプランで使えるか）の 2 軸で読みます。契約の壁は製品ごとに答えが逆になります — 上位コースからと書く製品もあれば、契約していれば追加料金なしと書く製品もあります。
kintone API/MCP SmartHR API/MCP
移した後の壊れ方を決める
RPA は止まり、AI は間違えたまま進む — この通説は公開資料の上では成り立たず、止まるか進むかは種類ではなく設定で決まります（自動化が壊れた日に何が出るか）。移し先が API でもエージェントでも、失敗したときの既定（止まる／進む／通知だけ）と、戻せるか・途中から再開できるかを、移す前に決めておきます。
| 移す前に決めること | 読む欄 |
|---|---|
| 失敗したら止まるのか、進むのか | 壊れ方・エラー処理 |
| 戻せるか、途中から再開できるか | 記録・やり直し |
| 回数の上限に達したらどうなるか | レート制限（AI は人より速く叩く） |
RPA を残す判断も立派な設計です。相手に API が無く、人の確認が要る「書く」は、RPA のまま壊れ方の設定だけ見直す方が安全なことがあります。