7月18日、Skyvernが「Agentic Process Automation vs. RPA Updated July 2026」と題した記事を公開した。RPAとエージェントプロセスオートメーション（APA）の構造的な違いと、2026年時点での実践的な使い分け基準について詳しく紹介されている。なお、本記事はAPAプラットフォームを提供するSkyvern自身が執筆したものであり、自社製品への言及を含む点は読み進める上で念頭に置いていただきたい。
RPA運用チームが直面する「メンテナンストラップ」
RPAを導入した後に待っていたのが「ボットの維持コスト問題」だった、という経験を持つエンジニアは多いはずだ。
Forresterの調査によれば、企業の45%が週次でボットの障害を経験しており、RPAチームの工数の30〜70%がボットの新規開発ではなく既存ボットの維持に費やされている。
この問題の根本はスクリプトの品質ではなく、アーキテクチャにある。UiPathやAutomation Anywhere、Blue Prismに代表されるセレクターベースのRPAは、「記録した時点のページ構造が将来も変わらない」という前提で動作する。RPAは2010年代を通じて急速に普及し、多くの企業が定型業務の自動化基盤として採用してきた。しかし2026年時点では、クラウドSaaSの更新サイクルが加速し、外部ポータルのUI変更が常態化したことで、この前提が成立しにくくなっている。保険会社の見積もりシステム、政府の許可申請フォーム、サプライヤーのオンボーディング画面——これらはベンダーのスケジュールで予告なく変更される。
RPA特有の問題は「サイレントな失敗」だ。セレクターが対象要素を見つけられなかった場合、スクリプトはエラーを返さずに完了する。ダウンストリームのシステムにデータが届いていないことに気づく頃には、ポータルはすでに再度変更されているかもしれない。
APAが採るアーキテクチャの違い
Agentic Process Automation（APA）は、AIエージェントが実行時にページをリアルタイムで読み取り、目標から行動を計画・実行するアプローチだ。記録されたパスを再生するのではなく、ページの現在の状態を見て次のアクションを判断する。LLMを活用したAIエージェントの業務適用は2024〜2025年にかけて急速に研究・実装が進んでおり、APAはその実務応用形として位置づけられる。
記事ではAPA動作の核心を4つのコンポーネントとして整理している。
- ビジュアルページリーダー: セレクターマップではなく実行時のライブページを読む。ボタンのリネームやフォームの再構成は「エラー」ではなく「新しい入力」として扱われる。
- ゴール指向プランナー: 記録済みパスを再生するのではなく、ステップごとに状況を再評価して行動列を生成する。
- 認証ハンドラー: 2FA、セッションタイムアウトモーダル、ローテーションするログインフローをスクリプトのパターンマッチングではなく「状態の推論」で処理する。
- 構造化アウトプット抽出: ポータルのレイアウトが変わっても、ダウンストリームシステムには一定のJSONスキーマで結果を返す。
RPA vs. APA：比較表
| 比較軸 | 従来型RPA | APA |
|---|---|---|
| ページの読み取り方法 | セレクターベース（XPath、CSS、DOM） | 実行時にライブページをビジュアルに読む |
| レイアウト変更への対応 | サイレントに失敗、手動修正が必要 | 再読み取りして処理を継続 |
| 認証処理 | 記録済みのログインパスを再生 | ログインフロー・2FA・セッションモーダルを推論で処理 |
| 意思決定 | 固定されたスクリプトを実行 | ゴール指向でステップごとに行動を再評価 |
| 例外処理 | 失敗またはヒューマンキューへエスカレーション | 自律的に解決を試み、パラメータ外の場合のみエスカレーション |
| メンテナンス負荷 | 全工数の30〜70%がメンテナンス | セルフヒーリングにより大幅に削減 |
| 利用者 | 変更のたびに開発者が必要 | 非技術者チームがコード変更なしで調整可能 |
| 最適な用途 | 変更の少ない安定した内部システム | レイアウトが予告なく変わるポータル群 |
RPAでは埋めきれないギャップが生じる3つのシナリオ
記事が明示する「APAでなければ対応できない」ケースは以下の3つだ。
予告なく変わるポータルレイアウト: ベンダーがボタン名を変えたりフォームを再構成した瞬間、RPAはサイレントに止まる。APAエージェントはページをその場で読み直すため、レイアウト変更は致命的なブレークポイントにならない。
セッションごとにローテーションする認証フロー: 2FAプロンプトや動的なログインシーケンスは、「見たことがないもの」には対応できないRPAの構造的限界を突く。APAエージェントはプロンプトが現れるたびに状態を推論して対処する。
非技術者チームが管理するマルチポータル業務: ワークフローの担当チームがコードを書けない環境では、ポータルが変わるたびに開発者へのサポート依頼が発生する。ゴール指向のエージェントはポータルが変わっても目標から新しいパスを自律的に見つける。
APAが適さないケースも明示されている
記事はAPA一辺倒の主張ではない。高ボリュームで構造が安定した内部業務——固定されたERPでの給与処理、自社管理システム間のデータ入力、チームが完全に統制するシステムからのレポート生成——ではRPAが依然として有効であることを明記している。
また、高リスクなワークフローでの最終送信前には人間によるレビューが必要であるとも述べている。RPAとAPAの違いは「エスカレーションが発生する理由」にも現れる。RPAはスクリプトが壊れたからエスカレーションし、APAはエージェントが自分の動作パラメータ外と判断したからエスカレーションする。
※編集部の考察：RPA市場は成熟期に入りつつあり、主要ベンダー各社もAI機能の統合を進めている。純粋なRPAとAPAの境界は今後さらに曖昧になる可能性があり、自社の業務特性に応じた段階的な移行判断が現実的な選択肢となるだろう。
詳細はAgentic Process Automation vs. RPA Updated July 2026を参照していただきたい。
