結論から書きます。これから作る業務自動化は、RPAではなくAIによるブラウザ操作で作るべきです。
RPA（ソフトウェアのロボットが画面操作を代行する仕組み）には、長く3つの弱点がありました。作れる人が限られること、画面が変わると止まること、そして直すのに手間がかかることです。この3つは、AIがブラウザを操作できるようになったことで、性質が変わりました。
この記事は、RPAの保守に疲れている情報システム部門に向けて書いています。これから自動化を始める現場部門、投資判断をする経営層にも役立ちます。読めば、自社がRPAとAIをどう使い分けるべきかの判断材料が手に入ります。
根拠にしたのは、RPAベンダー各社の公式発表、MM総研の調査、実際に乗り換えた実務者の報告です。
RPAが行き詰まった3つの理由
RPAが社内に広がらなかった原因は、技術ではなく構造にあります。次の3点です。
- 作れる人が限られる／画面上の要素を指定し、条件分岐を組む作業は、実質的に開発です。担当者が異動すると誰も触れなくなります
- 画面が変わると止まる／ボタンの位置やHTMLの構造が変わるだけでシナリオが壊れます。SaaSの画面更新は自社で制御できません
- 直すのに手間がかかる／壊れた箇所を特定し、シナリオを開いて作り直す必要があります。動かない間、業務は手作業に戻ります
この結果は数字にも表れています。MM総研が2024年3月に1,599社を対象に実施した調査を見ると、差は明らかです。RPAの導入率は中堅・大手企業で44%、中小企業では15%にとどまります。
中小企業の62%は導入を検討すらしていません。その理由の最多は「どういうことができるかわからない」で28%でした。
この62%は、そもそも導入前で止まっている層です。導入した企業の側では、上の3つが保守を圧迫しています。入口でも出口でも詰まっているのが、RPAの現状です。
3つの弱点は、どれも「作った後」に効いてきます。導入時の説明で語られるのは削減時間ですが、実際に効いてくるのは保守の総量です。シナリオが増えるほど、止まる頻度も直す手間も積み上がります。
現場の負担も見過ごせません。導入支援の場でよく聞くのは、担当者が置かれる立場の話です。動いている間は誰も気に留めず、止まった瞬間だけ「すぐ直して」と言われます。
属人化をなくすために入れたRPAで、担当者自身が最大の属人要素になる。これが最も起きやすい失敗です。
AIブラウザ操作が変えた3つの点
AIがブラウザを操作できるようになり、上の3点はそれぞれ解消に向かいました。最大の変化は、直し方が「作り直し」から「言い直し」になったことです。
作る側から見た違いを整理すると、次のようになります。
| 観点 | RPA | AIブラウザ操作 |
|---|---|---|
| 作れる人 | 研修を受けた担当者 | 業務を知っている人なら誰でも |
| 作り方 | 画面要素の指定と条件分岐の設計 | やりたいことを日本語で指示 |
| 画面が変わったとき | 停止する | 画面を見て判断し、続行できる場合がある |
| 直し方 | シナリオを開いて作り直す | 指示を言い直す |
| 得意な仕事 | 手順が固定された大量処理 | 判断や例外が混じる作業 |
| 苦手なこと | 例外処理、画面変更への追従 | 毎回まったく同じ結果の保証、速度 |
従来は「この座標のボタンを押し、この項目に値を入れる」と手順で指定していました。AIには「請求一覧を開いて、未処理のものを担当者ごとに振り分けて」と目的で伝えます。画面の細部が変わっても、目的は変わりません。
ここで重要なのは、AIが万能になったという話ではない点です。変わったのは「誰が作れて、誰が直せるか」です。業務を知っている本人が、自分の言葉で自動化を作り、壊れたら自分で直せます。
ただし、誰でも作れることは統制の緩みと表裏です。放置すればシャドーITと同じ問題が起きます。どの部門がどのサイトを操作してよいかは、情報システム部門が先に決めておく必要があります。
RPAベンダー自身の方向転換
移行を判断するうえで最も強い材料は、RPAベンダー自身がAIエージェントへ舵を切っている事実です。4社とも、機能の追加ではなく土台の作り直しに動いています。
| 時期 | ベンダー | 内容 |
|---|---|---|
| 2025年4月 | UiPath | エージェント型自動化のプラットフォームを発表。コンピュータ操作を担うUI Agentを含む |
| 2026年5月 | Microsoft | Copilot Studio のコンピュータ操作機能を一般提供へ。2025年9月のプレビューを経て全商用地域に展開 |
| 2026年1月 | Automation Anywhere | OpenAIとの提携を発表。推論モデルを組み込んだエージェント型製品へ |
| 2026年2月 | WinActor | 管理製品にMCPサーバー機能を搭載し、AIエージェント連携を強化 |
特に見ておきたいのはMicrosoftの説明です。固定のセレクタ（画面要素の指定）に依存したロボットについて、同社は公式ブログでこう書いています。「Webフォームが変わるたびに壊れた」。従来型RPAの弱点を、提供側が公に認めた記述です。
UiPathも公式発表で、会話型AIやアシスタントの価値は限定的だったと述べています。企業全体へのAI展開が難しいままだった点も認めたうえで、エージェント型の基盤を打ち出しました。
国産で最大級のWinActor（2025年3月時点で8,500社超が導入）も動いています。AIエージェントと連携するMCPサーバー機能を、管理製品に載せました。MCPは、AIが外部システムとつながるための共通規格です。
つまり、RPAの提供側が従来のやり方では足りないと判断し、AIエージェントへ移っています。しかも実験段階ではありません。Microsoftは2026年5月に一般提供へ踏み切りました。
利用する側が様子見を続ける理由は、もうほとんど残っていません。
市場の現在地と、動き出した企業の順序
市場全体で見れば、移行はまだ始まったばかりです。前出のMM総研の調査では、生成AIとRPAを組み合わせて本格的に活用している中堅・大手企業は10%にとどまります。準備・検討中が53%です。
裏を返せば、今動けば先行できる余地が大きく残っています。その先行事例も出始めています。
導入支援の現場で見ていると、動き出した企業には共通する順序があります。既存のRPAを一斉に止めるのではなく、まず1つの業務をAIに置き換え、手応えを確かめてから範囲を広げます。
最初に選ばれやすいのは、画面がよく変わるSaaSの操作と、月次で発生する転記作業です。どちらも保守の負担が大きく、効果がすぐ見えます。
逆に止まりやすいのは、全部を評価してから決めようとする企業です。RPAの棚卸しに時間がかかり、その間も保守の負担は続きます。
それでもRPAが残る領域
すべてをAIに置き換えるべきではありません。AIは毎回まったく同じ動作を保証しません。この一点が、残す業務と移す業務を分ける基準になります。
AI提供側も、無条件に任せてよいとは書いていません。OpenAIは公式ドキュメントで、3つの安全策を求めています。
- 隔離されたブラウザや仮想マシンで動かす
- 影響の大きい操作には人を介在させる
- ページの内容は信頼できない入力として扱う
現実的な形は役割分担です。AIが判断し、RPAが決まった手順を実行し、取り消せない操作は人が承認します。この3層で組むのが、いまのところ最も安全です。
判断の目安は、業務の性質で決まります。
| 業務の性質 | どちらで動かすか | 理由 |
|---|---|---|
| 画面がよく変わるSaaSの操作 | AIへ移す | 保守が最も重い領域。追従できる利点が直接効く |
| 判断や例外が混じる作業 | AIへ移す | 条件分岐で書き切れない部分を任せられる |
| 毎日同じ手順の大量処理 | 当面はRPAを残す | 速度と再現性で優位。壊れていないなら急いで替えない |
| 証跡が厳密に問われる処理（経理の仕訳、法定帳票の作成など） | 当面はRPAを残す | 同じ入力に同じ結果を返す性質が求められる |
| API連携で置き換えられる処理 | どちらでもなく連携へ | 画面を操作させること自体が遠回りになる |
移行の進め方（3ステップ）
今動いているRPAを止める必要はありません。止めずに、作る場所だけを移すのが安全で確実です。
- 新規はAIで作ります／画面がよく変わる案件や、判断・例外が混じる案件は、RPAで作らないと決めます。安定した大量処理や証跡が問われる処理は、新規でも上の判断表の基準を当てはめてください。壊れやすい資産が増えるのを止められます
- 壊れやすい順に置き換えます／過去1年で最も多く直したシナリオから移します。保守の負担が大きい順に効果が出ます
- 残す業務を決めます／上の判断表に沿って、残すものを明示します。決めないまま両方を抱えると、管理対象が二重になります
導入支援の現場で見ていると、失敗するのは順番を逆にしたときです。既存の大物から置き換えようとすると、検証に時間がかかり、その間に現場が疲れます。小さく作れる新規案件で成功体験を作るほうが、社内は動きます。
AIに操作させるブラウザは、普段使いのものと分けてください。人間の操作とぶつからず、業務データを巻き込む事故も防げます。自社で運用する際も、専用のプロファイルを用意することを勧めています。
立場別の最初の一歩
最初の一歩は立場で変わります。自分に当てはまるものから始めてください。
- 情報システム部門／過去1年で最も多く直したシナリオを1本選び、AIで作り直して比べます。保守の手触りの差が最も分かりやすく出ます
- 現場部門／毎日手作業でやっている転記や集計を1つ選び、日本語で指示して動かします。読み取りと転記だけの作業なら、失敗しても被害がありません
- 経営層／新規の自動化をRPAで作らない方針を決めます。加えて、許可するサイト・扱うデータ・人が承認する操作の3点をルール化します
まとめ
RPAの3つの弱点は、AIによるブラウザ操作で性質が変わりました。作れる人が広がり、画面変更に追従でき、直し方が言い直しになりました。RPAベンダー自身がエージェント型へ移っている事実が、この変化の裏づけです。
一方で、毎日同じ手順の大量処理や、証跡が厳密に問われる処理は当面RPAに残すのが妥当です。AIは同じ結果を毎回保証しません。全部を入れ替えるのではなく、置き場所を選び直す作業だと考えてください。
今日できることは1つです。次に作る自動化を1本、AI側で作ってみてください。比較の材料は、それで手に入ります。
なお本記事の内容は2026年7月25日時点の情報にもとづいています。各製品の機能や提供条件は変更される可能性があるため、導入前に公式サイトで確認してください。
参考リンク
- RPA国内利活用動向調査（MM総研、2024年）
- Copilot Studio のコンピュータ操作エージェント（Microsoft 公式ブログ）
- エージェント型自動化プラットフォームの発表（UiPath 公式）
- OpenAIとの提携発表（Automation Anywhere 公式）
- Computer-Using Agent（OpenAI 公式）
監修者
池田 智彦 ｜ 株式会社Spovisor 代表取締役
NTTドコモ・KDDIで通信業界に21年従事し、グローバル／国内市場で10以上の新規事業の立ち上げと、1,000万ユーザー規模サービスの開発・運用を主導。事業戦略から海外展開、エンジニアリングまで横断する経験を活かし、2023年6月に株式会社Spovisorを設立。現在はAI・アプリ開発、生成AIコンサル、AI駆動開発支援、AI顧問など、企業のDXを実装まで伴走する支援に取り組む。
生成AI／AIエージェントを「成果」に変える、Spovisorの伴走支援
株式会社Spovisorは、生成AI・AIエージェントを「使ってみた」で終わらせず、業務やプロダクトに組み込んで成果を出すところまで伴走する実装パートナーです。
| 支援領域 | 内容 |
|---|---|
| 生成AI組み込みアプリ開発 | Claude／ChatGPT／AIエージェントを組み込んだ業務アプリや自社プロダクトの設計から実装まで支援 |
| 生成AI導入コンサル／AI顧問 | 経営課題や業務プロセスから導入ポイントを設計し、本番運用まで伴走 |
| AI駆動開発支援 | Claude Code／Codexを使った開発生産性向上を現場へ定着 |