RPAの保守費用はロボット数で決まるのか｜変更頻度・実行頻度・失敗対応で見る

保守の見積書に「RPA運用保守　ロボット10体　月額◯万円」と書かれている。ロボットが増えれば保守費が上がるのは分かる気もするけれど、去年から止まった話は聞いていないのに毎月同じ額が請求されている。あるいは逆に、月に何度も「シナリオが動かなくなった」という連絡が来ていて、そのたびに追加費用の見積書が届く——この記事は、その状態から一歩進むための手順書です。

先に立場を書いておきます。「ロボットの数で課金するのが間違いだ」とは書きません。 ロボット数が費用の実態とよく対応しているケースは実在しますし、後述するとおりライセンス費だけは、製品によってはロボット数にほぼ正確に比例します。ただしRPAの保守費で厄介なのは、比例するその部分が、費用全体のごく一部でしかないことです。残りを動かしているのはロボットの数ではなく、ロボットが触りにいく相手側の変更頻度です。RPAは自分が壊れるのではなく、触っている相手が変わったときに壊れるためです。

TL;DR｜ロボット数が効くのはライセンス。保守費を動かすのは「相手側の変更」

• 「1体」の数え方が書かれていない見積書は、比較も交渉もできません。 シナリオのファイル単位なのか、業務プロセス単位なのか、実行する端末単位なのか、ライセンス単位なのか。同じ自動化が、別の会社の見積書では「3体」にも「12体」にもなります
• RPAが壊れるきっかけは、あなたの都合とは無関係に、公表されたスケジュールで来ます。 Chromeの安定版メジャーバージョンは4週間ごと、セキュリティ修正の更新（refresh）は週次です。Microsoft Edgeは公式スケジュール上、バージョン152以降は2週間サイクルへ移行します。Microsoft 365 Apps（法人向けの for enterprise / for business）の既定である最新チャネル（更新をいつ受け取るかの設定。企業向けには更新間隔の長い選択肢が用意されています）は、機能更新が「準備ができたらすぐ（月に1回）」で、特定バージョンのサポート期間は通常約1か月です（いずれも2026年8月25日取得）。更新のたびに必ず壊れるわけではありません。ただし「確認が必要になる回数」は、カレンダーで先に数えられます
• だから効く軸はロボット数ではなく「対象システムの延べ数×その変更頻度」です。 10体すべてが同じ社内の基幹システム1つだけを触っているなら、追従の面は1系統ぶんです。3体でも、それぞれがWindowsアプリ・ブラウザ・Excel・外部SaaSを触っているなら、追従の面は3体のほうが広くなります
• 実行頻度は、失敗の絶対回数を通じて費用に効きます。 月1回のロボットと1日20回のロボットは、同じ「1体」でも、止まったときに人が動く回数が違います。見積書に「10体」としか書かれていない場合、この差は金額に反映されていません
• ライセンスだけはロボット数に比例します。しかも有人か無人かで単位が変わります。 Power Automateの公式価格は、有人（アテンド型）が「ユーザー/月」、無人（非アテンド型）が「ボット/月」です（2026年8月25日取得・税抜・年払い）。同じ「10体」でも、どちらの構成かでライセンス実費は大きく変わります
• 金額の高い・安いより先に決めることがあります。 「1体」の定義に加えて、追従・実行頻度・切り分けと業務復旧・ライセンスの4つがどこまで含まれるかを書面に落とせば、他社の見積書と同じ土俵に並びます。並べたあとで初めて、金額を比べる意味が出ます

本記事は、そのうちRPAに固有の部分を扱います。保守見積書そのものの分解手順はシステム保守費用の相場と妥当性を先に読んでください。

見積書では、RPAの保守がどう書かれているか

まず、実際の書かれ方を並べます。それぞれの表記から何が決まらないのかと、後述する4つの作業——①対象システムの変更への追従、②実行頻度、③失敗時の切り分けと業務復旧、④ライセンス——のどこに当たるのかを並記しました。各作業の中身は次章で扱います。

「1体」の数え方は、たいてい書かれていない

請求書の発行業務を自動化している、という前提で考えてみます。同じ自動化について、次のどの数え方をしても「本数」は成立します。

数え方が書かれていない見積書は、ロボット数を比較できません。 A社の「5体」とB社の「12体」を並べても、それが対象範囲の違いなのか数え方の違いなのかを判別できないためです。相見積もりを取るなら、金額を聞く前に「自動化している業務の一覧」を作り、「この一覧を、御社の数え方で何体と数えますか」と全社へ同じ表を送るほうが早く進みます。

RPAの保守費を実際に生む4つの作業

ここからが本題です。RPAの保守費を動かしているのはロボット数ではなく、次の4つの作業量です。順に見ていきます。

うち②実行頻度は、それ自体が独立した作業ではなく、①と③の作業量を何倍にするかを決める倍率です。ロボット数とは独立に費用へ効くため、4つのうちに数えています。なお、保守見積書全般をどう行に分解するかと、保守費全体を「待機・人の作業・システムの作業・実費」という4区分で読む方法はシステム保守費用の相場と妥当性にあります。この4区分は、これから見る4つの作業とは別の切り口です。ここではRPAに固有の部分だけを見ます。

①対象システムの変更への追従｜変更頻度は、カレンダーで先に分かる

以降、提供元の公式ドキュメントを引くときは原典どおり「更新」と書き、本記事の分析軸としては「変更頻度」と呼びます。RPAが壊れるのは、更新によって画面や仕様が変わったときだからです。

RPAが他のシステム開発と決定的に違うのは、自分は何も変えていないのに、外側の都合で動かなくなる点です。RPAは人が画面を操作する手順をそのままなぞるので、なぞる相手（業務システムの画面、ブラウザ、Excel、社内アプリ）のどこかが変わると、その手順が成立しなくなります。

ここで経営判断に直結する事実が一つあります。「相手がいつ変わるか」の多くは、あらかじめ公表されています。 主要なソフトウェアの提供元は、更新の間隔を公式ドキュメントに書いています。つまり、来年度に「確認が必要になる回数」は、契約する前に数えられます。

主要な対象環境について、公式ドキュメントに書かれている更新の間隔を、同じ基準で並べたものが次の表です。いずれも2026年8月25日に取得しました。

※Microsoft 365 Apps の原典では、セキュリティ更新の欄が「セキュリティ更新プログラム（必要な場合）」と限定されています。上表の「月1回・第2火曜」は配信のタイミングであって、毎月必ず配信されることを保証する記述ではありません。

この表から、経営判断に使える読み方が3つ出てきます。

1つ目。ブラウザを触るロボットは、いま最も変更頻度が高い場所にいます。 Chromeの4週、Edgeの2週移行という数字は、いずれも公式ドキュメントに書かれた計画です。Edgeの2週間サイクルは、記事執筆時点でバージョン152が「ターゲットのリリース」（＝予定）として掲載されている段階です。ただし方向としては、企業側がテストにかけられる猶予が短くなる側に動いています。

2つ目。「更新を遅らせる選択肢」が公式に用意されています。 Chromeのextended stable（8週間）、Edgeの拡張安定（8週間）、Microsoft 365 Appsの月次・半期エンタープライズチャネル、Windows のLTSCがそれです。RPAの保守費を下げる交渉より先に、情報システム部門にこのチャネル設定を確認するほうが効くことがあります。 ただしEdgeの拡張安定は「管理された環境のお客様のみ」、Chromeのextended stableは「Windows と Mac の企業向けのみ、企業ポリシーで有効化」と、いずれも適用条件が公式に限定されています。自社が対象になるかは確認が必要です。

3つ目。半期エンタープライズチャネルを前提に組んだ運用は、2026年7月以降に前提が変わる告知が出ています。 Microsoftは「半期エンタープライズチャネルでは、月次エンタープライズチャネルと同じベースで、機能とセキュリティの更新プログラムを毎月受け取ります」と公式に告知しています。年2回のテスト計画で回していたなら、この告知どおりであれば前提が合わなくなります。 ただし原典は「2026年7月以降に…変更を加えます」という予告の形で書かれた文書です。自社環境で実際にどう適用されているかは情報システム部門に確認したうえで、その変更を織り込んだ保守体制になっているかをベンダーへ確認してください。

ここで一つ、書きすぎない線を引いておきます。上の表は「更新が入る間隔」であって、「RPAが壊れる回数」ではありません。 各社の公式ドキュメントは配信のスケジュールを述べているだけで、破損率については何も書いていません。実際に壊れるかどうかは、そのロボットが画面上の要素をどう特定しているか（要素の識別子で指定しているか、画像や座標で指定しているか）に強く依存します。画像や座標で指定している箇所が多いほど、見た目の小さな変更でも動かなくなりやすいというのは実務上よく言われる観点ですが、これは一般的な確認観点であって、価格相場の根拠になる公表データではありません。だからこそ、「どう指定しているか」は見積もりを取る前にベンダーへ聞くべき項目になります（後述の質問4）。

②実行頻度｜同じ「1体」でも、月1回と1日20回は別物

2つ目は実行頻度です。ここは論理としては単純で、失敗率が同じなら、実行回数が多いほど失敗の絶対回数が増えるという話です。月1回しか動かないロボットと、1日20回動くロボットでは、月あたりの実行回数が（月20営業日なら）およそ400倍違います。同じ「1体」として同じ単価で計上されていても、人が対応する回数は同じになりません。

実行頻度が費用に効く経路は3つあります。

この3つは、見積書に「10体」としか書かれていない限り、金額に反映されようがありません。 ロボットごとの実行頻度（1日◯回／週◯回／月◯回）の一覧を出してもらうのが、最初の一手になります。

③失敗時の切り分けと業務復旧｜「途中で止まった」を誰が戻すか

3つ目が、実務でいちばん揉める場所です。見積書で「エラー対応」「失敗対応」とまとめられがちなのが、この作業にあたります。RPAは人の操作をなぞるため、業務の途中で止まります。500件の請求書のうち137件目まで処理して落ちた、という止まり方をします。このとき必要になる作業は3つあり、それぞれ担当が違いうるのに、上記のとおり一語にまとめられています。

3つ目の「業務の復旧」は、金額として見えにくいのに負担が大きい部分です。137件目まで処理して落ちたとき、選択肢は2つあります。最初からやり直すか、138件目から再開するか。最初からやり直すなら、137件分が二重に登録されていないかを誰かが確認しなければなりません。138件目から再開するなら、「本当に137件目まで完了しているか」を誰かが確認しなければなりません。どちらの確認も、RPAの見積書に載っていないことがあります。

載っていない場合、その作業は消えたのではなく、発注側の現場に移っているだけです。保守費が安く見える見積書ほど、この移動が起きていないかを確認する価値があります。

④ライセンス｜ここだけはロボット数に比例する。ただし「有人か無人か」で単位が変わる

4つ目がライセンスです。本記事で唯一、ロボット数への比例が公式価格として確認できるのがここです。

Microsoftが日本語の公式価格ページに掲載しているPower Automateのプランは、次のようになっています（2026年8月25日取得。いずれも年払い、価格ページに「価格には消費税は含まれていません」と明記）。

この表で見るべきなのは金額そのものではなく、課金単位が2種類あることです。

• アテンド型（有人）は「ユーザー/月」です。人が自席で起動して、その人が見ている前で動く使い方を指します。課金されるのは人の数であって、ロボットの数ではありません
• 非アテンド型（無人）は「ボット/月」です。夜間や休日に人がいない状態で動く使い方を指します。ここはロボット数に比例します

※アテンド型／非アテンド型の運用イメージは一般的な説明であり、価格ページに書かれている記述ではありません。

これが見積書の読み方に直結します。「ロボット10体」と書かれていても、それが有人10体なのか無人10体なのかで、ライセンス実費は大きく変わります。 上の公式価格をそのまま10倍すると、有人10ユーザーなら月¥22,480、無人10ボットなら月¥224,880、Microsoftホスト型の無人10ボットなら月¥322,330です（いずれも公表単価からの本記事による単純計算で、Microsoftが提示している金額ではありません。税抜・年払い基準）。

さらに、アテンド型ではロボット数とライセンス本数が一致しません。10体のロボットを3人が使い分けているなら、必要なのは3ライセンスです。「10体だから10ライセンス」と積まれた見積書は、この点を確認する価値があります。

これはPower Automate固有のライセンス体系であり、他のRPA製品が同じ単位で課金しているとは限りません。ただし「有人と無人で課金単位が違う」という構造自体は、確認すべき論点として他製品にも持ち込めます。 見積書にライセンス費が「一式」で含まれている場合は、次を確認してください。

• どの製品の、どのプランを、何本使っているか
• 有人（アテンド型）と無人（非アテンド型）の内訳
• ベンダー経由で購入しているなら、提供元の公式価格に対して手数料がいくら乗っているか
• 契約期間の途中で減らせるか。年払い契約なら、途中解約時の残債の扱い

製品ごとの機能や価格帯を先に見比べたい場合は、業務自動化ツール16製品の比較にRPA・iPaaS・生成AI・ノーコードの分類ごとにまとめてあります。

4つの作業のまとめ｜ロボット数に比例するもの、しないもの

「止まらなかった月にも発生するか」の列が、毎月同額の請求に納得できるかどうかの分かれ目です。 ①と④は、障害が一度も起きなかった月にも発生します。③は待機の対価として発生します。②だけが、起きたときの費用です。毎月同額の見積書が妥当かどうかは、「今月は何もしていないのでは」ではなく、「この月額に対応する行が契約書のどこにあるか」で判断してください。

その料金体系が合理的といえる条件｜本数課金でよいとき

ここまで「ロボット数は実態と対応しない」と書いてきましたが、本数課金が説明のつく条件は実在します。 次の3つがすべて満たされているなら、ロボット数を単価の基準にすることに合理性があります。

1. ロボットどうしの性質がそろっている。 対象システムが同じ、実行頻度の桁が同じ、失敗時の復旧手順が同じ。この場合、1体あたりの作業量は実際にほぼ一定になります
2. 「1体」の定義が書面にあり、増減のルールが決まっている。 増えたときの単価だけでなく、減らしたときの減額が書かれているか。増えるときだけ課金され、減らしても下がらない契約は、本数課金の体裁をとった固定費です
3. ロボット数と一緒に、①〜④の範囲が書かれている。 「10体・月◯万円」の10体が、追従・実行頻度・切り分けと業務復旧・ライセンスのどこまでを含むかが定義されている

逆にいえば、この3つのどれかが欠けているとき、ロボット数は金額の根拠になりません。 よくあるのは1つ目が崩れているケースです。10体のうち2体だけが外部SaaSを触っていて、その2体が全体の保守工数の大半を占めている、という状態は珍しくありません。この場合、10体を同じ単価で並べた見積書は、実態としては「2体ぶんの作業を10体に薄めた金額」になります。これ自体は単価設定の方法として成立するもので、それだけで問題があるとはいえません。ただしそのロボットを2体減らしても金額は5分の1しか下がらないため、削減の判断を誤ります。

ロボット数より効く軸｜「対象システムの延べ数 × その変更頻度」

ロボット数の代わりに何を見るか、という問いへの答えがここです。追従の作業量は、ロボットの数ではなく、ロボット全体が触っている対象システムの延べ数と、それぞれの変更頻度で決まります。

同じ「保守対象10体」でも、次の2社ではまったく別のものを買っています。

「10体だから3体の3倍以上」という見積書は、この表を見せられて初めて検証できます。 相見積もりを取るなら、ロボット数ではなく「対象システムの一覧」と「そのうち自社で更新日程を握れるものはどれか」を全社へ同じ形式で送ってください。これが本記事でいちばん実務に効く一手です。

4状態で仕分ける｜説明済み・要確認・高リスク・判断不能

手元の見積書と契約書を、次の表と照らしてください。「高い」ではなく「書かれているか」で仕分けます。 ロボット数が多いこと自体は、高リスクの理由になりません。

「判断不能」の欄に印が集中したなら、価格交渉より先にやることがあります。 書かれていない項目を書いてもらうことです。なお、この表は書面に何が書かれているかを見る道具なので、「そもそも保守契約の対象一覧に載っていないロボットがある」状態は判定できません。これは書面ではなく実体の問題で、次章以降で扱います。加えてこの状態では、自社側にも材料がありません。いま何体のロボットが動いていて、それぞれが何を触っているかを、自社の資料として把握するところから始めてください（手順は末尾のFAQで扱います）。

手元に見積書のPDFやテキストがある場合は、見積書の登録不要レビューで行項目の分解と確認質問の生成を試せます。見積書のテキストはブラウザ内で識別情報をマスクしたうえで診断にかけられ、結果を見るまでメールアドレスの入力は不要です。返ってくるのは「高い／安い」の判定ではなく、上表と同じく確認すべき項目とベンダーへの質問です。

同じ「10体・月◯万円」でも、中身は同じではない

同じロボット数・同じ月額の2つの見積書が、どこまで違いうるかを並べます。下表はいずれも実在の見積書ではなく、書き方の違いを見るために作った対比です。

Yのほうが金額が高くても、比較可能なのはYだけです。 Xは、月額が安く見えたとしても、書かれていない作業がどこへ行ったのかが分かりません。相見積もりで最初にやるべきなのは金額の比較ではなく、Xの列をYの列と同じ粒度まで埋めさせることです。

「安い」RPA保守のほうが危険なとき

過大な見積もりだけが問題ではありません。RPAでは、保守費を削った結果として、後から大きな支出になる形がいくつかあります。

1. 誰も把握していないロボットが動き続ける。 RPAは現場が自分で作れることが利点ですが、同じ理由で、作った人が異動したあとも動き続けるロボットが残ります。動いていることに誰も気づいていないロボットは、止まったことにも誰も気づきません。 保守契約の対象一覧に載っていないロボットが業務に組み込まれている状態は、保守費を削って作られた状態であることが多いものです。この一覧が無いと、そもそも保守範囲を契約書に書けません。手順は末尾のFAQで扱います。

2. 実行ログが残っていない。 「動いた」「動かなかった」の記録が残っていない構成だと、失敗に気づくのが業務側の異変からになります。ログの保管と確認の作業は保守費の一部であり、削れば費用は下がりますが、検知が遅れた分は業務側の手戻りとして出ます。

3. ロボットが使うIDと権限が個人アカウントのまま。 作成者本人のアカウントで動いている場合、その人が退職したりパスワードを変更したりした時点で止まります。専用のアカウントに分けて、その棚卸しを誰が行うかを決める作業は、見積書に載りにくく、載っていなければ誰の担当でもありません。

4. 対象システム更新時の事前確認が範囲外。 「壊れてから直す」だけの契約は安く見えます。ただし①対象システムの変更への追従で見たとおり、更新のスケジュールは公表されています。壊れる前に確認する余地があるのに、壊れてから都度見積もりで対応する契約は、年間の合計では高くなりうるうえに、業務が止まった状態で対応することになります。

5. 引き継ぎの条件が無い。 シナリオファイルの中身、実行環境の構成、対象システムの認証情報の管理方法が、ベンダー側にしか無い状態は、保守会社を変えられない状態です。RPAは「動いている手順書」そのものなので、この資料が無いと業務そのものが移せません。契約終了時に何が引き渡されるかは、後述の質問8でそのまま確認できます。

ベンダーへそのまま送れる確認質問8問

ここまでの論点を、コピーしてそのまま送れる形にしました。技術的な知識がなくても送れます。メール文面の「ロボット◯体」と社名だけ、自社の見積書に合わせて置き換えてください。

そのまま送れるメール文面

いつもお世話になっております。

RPAの運用保守について、社内で費用と作業範囲の対応を整理しております。
恐れ入りますが、下記8点についてご回答をお願いできますでしょうか。
現在の契約内容を変更したいという趣旨ではなく、社内で説明できる
状態にすることが目的です。

1. 「1体」の数え方
見積書の「ロボット◯体」は、何を1体として数えていますか。
業務プロセス単位／シナリオファイル単位／対象システム単位／
実行端末単位／ライセンス単位のいずれかでご教示ください。
あわせて、現在保守対象となっているロボットの一覧をいただけますでしょうか。
また、保守対象のロボットを追加・削除した場合の単価の扱い
（追加時の単価と、削除時の減額の有無・幅）もご教示ください。

2. 対象システムの一覧
各ロボットが操作している対象システム（業務システム名、ブラウザ、
Excel等のアプリ、外部サービス）の一覧をご教示ください。
そのうち、更新の日程を当社側で把握・調整できるものと、
提供元の都合で入るものの区別もお願いします。

3. 対象システムの更新への対応が保守費に含まれるか
ブラウザやOffice、OSの更新によってロボットが動作しなくなった場合の
修正は、月額に含まれますか。
含まれる場合は年間の上限回数（または上限時間）を、
含まれない場合は都度費用の単価と最低課金単位をご教示ください。

4. 画面上の要素の指定方法
各ロボットが操作対象の画面要素をどのように特定しているか
（要素の識別子による指定か、画像や座標による指定か）の内訳を
ご教示ください。
画像・座標による指定が多いロボットがあれば、それがどれかを
併せてお知らせください。

5. 実行頻度と実績
ロボットごとの実行頻度（1日◯回／週◯回／月◯回）と、
直近12か月の実行回数・失敗回数をご教示ください。

6. 失敗時の役割分担（3点、それぞれご回答ください）
(1) 失敗の検知は、どなたが、いつ行いますか
    （監視の有無、通知先に当社担当者が含まれるか）。
(2) 原因が「ロボット側か対象システム側か」の判定は、どなたが
    行いますか。判定が分かれた場合の手順もご教示ください。
(3) 業務が途中で止まった場合、処理済み分の確認と残りの実行は、
    御社と当社のどちらの作業になりますか。

7. ライセンスの内訳
保守費に含まれるライセンスについて、製品名・プラン名・ライセンス本数と、
有人（アテンド型）／無人（非アテンド型）の別をご教示ください。
ベンダー経由でのご購入の場合、ライセンス実費と御社の役務費の
内訳もお願いします。
あわせて、契約期間の途中で本数を減らした場合の取り扱い
（減額の可否、残債の有無）もご教示ください。

8. 引き継ぎに必要な資料
シナリオファイル、実行環境の構成情報、運用手順書、
認証情報の管理方法について、現在どこまで当社側に渡っているか、
契約終了時に何が引き渡されるかをご教示ください。

お手数をおかけしますが、よろしくお願いいたします。

回答をどう読むか

送ったあとの読み方です。回答の「無い」と「答えられない」は、意味が違います。 記録が存在しないのか、ベンダー側も把握していないのかで、次の一手が変わります。

質問4で「画像認識が多い」と返ってきたときの扱いだけ、補足します。 これは正直な回答であり、責める材料ではありません。対象システムによっては、要素の識別子で指定する方法が使えないことがあるためです。重要なのは、その事実が分かった時点で「毎月の保守費として払い続ける」のか「一度改修して追従コストを下げる」のかを、金額で比較できるようになることです。 比較のためには、改修の見積もりを保守費とは別に取る必要があります。

この記事のあとに進む順番

1. 自社で、稼働しているロボットの一覧を作る。 作り方（5列の内訳）は末尾のFAQにあります。ベンダーに聞く前に、自社が把握している範囲を先に固めます
2. 情報システム部門に、ブラウザとOfficeの更新チャネル設定を確認する。 最新チャネルなのか、月次エンタープライズチャネルなのか。ここが変わると、①対象システムの変更への追従の前提が変わります
3. 上の8問を送る。 回答が揃ってから、初めて金額の議論に入ります
4. 見積書の各行を「待機・人の作業・システムの作業・実費」に割り振る。 割り振れない行が、次に聞く場所です。手順はシステム保守費用の相場と妥当性にあります

同じ「本数で単価が決まる」構造は、API連携の保守にもあります。判断の型は共通なので、両方を契約しているならAPI連携の保守費用は1本いくらが妥当かも並べて読むと、確認質問をまとめて送れます。本数・件数・台数・ユーザー数といった数量課金全般の判断枠組みは数量課金の見積もりをどう判断するかにまとめています。

根拠資料と適用条件

本記事で使用した資料と、その適用条件です。いずれも2026年8月25日に取得しました。

本記事で提示していないもの、およびその理由です。

よくある質問