RPA・業務自動化の見積もりの作り方｜あとで足せない項目

2026年4月15日

長谷川奈津

この記事のポイント

✓RPA・業務自動化の見積もりの出し方を
✓あとから請求できなくなる項目
✓変更が起きたときの再見積もりの手順まで

RPAの見積もりで相談が多いのは、金額の水準ではありません。「見積もりに書き忘れた作業を、あとから請求できるか」という話です。結論から言うと、原則として請求できません。見積書に書かれていない作業は、合意の対象になっていないからです。つまり、見積もりを作る作業とは、金額を計算する作業ではなく、これから発生する作業の輪郭を全部書き出す作業です。

この記事では、RPA・業務自動化の見積もりの出し方について、工程の分け方、あとから足せなくなる項目、前提条件の書き方、そして途中で条件が変わったときの再見積もりの手順までを順に整理します。これ、知らない人が本当に多いんですが、見積書は金額の通知ではなく、取引条件を記録する書類です。※既に金額をめぐって争いになっている場合は、この記事の内容を踏まえたうえで弁護士に相談してください。

RPAの見積もりが難しい理由

他の制作系の仕事と比べて、RPAの見積もりには固有の難しさがあります。この難しさの正体を理解しておくと、どこに前提条件を書くべきかが見えてきます。

作業量が対象業務の実態に依存する

依頼者から「請求書の作成を自動化したい」と言われたとき、この一文からは作業量が読み取れません。取引先が数社なのか数百社なのか、様式が一つなのか複数あるのか、単価の計算に例外があるのか。これらによって、実装の分岐の数がまったく変わります。

しかも、依頼者はこの違いを重要な情報だと認識していないことが多い。日々の業務では当たり前に処理していることなので、わざわざ説明する対象になりません。「あ、この取引先だけは別のフォーマットです」という一言が出てくるのは、たいてい開発が進んでからです。

連携するツールの数が工数を押し上げる

見積書に関わる作業を自動化する場合、対象は一つのシステムに閉じません。業務管理ツール、表計算ソフト、メール、クラウドストレージ。これらの間でデータをやりとりする部分が、実装の中心になります。

SalesforceなどのCRM、kintoneなどの業務管理ツール、Excelやスプレッドシート、クラウドストレージ、メールクライアント。見積書に関わるツールが複数あるほど、情報の転記・同期に手間がかかります。BizteXの調査によると、86.9%の企業がSaaSのデータ連携に何らかの課題を感じています。ツールが増えるほど、見積業務の効率は下がりやすくなります。出典: service.biztex.co.jp

つまり、連携するツールの数は工数に直結します。見積もりの前に、対象業務がいくつのツールをまたぐのかを必ず確認してください。ツールが一つ増えるごとに、認証の処理、データ形式の変換、エラー時の扱いが増えます。この確認をせずに全体の金額を出すと、実装に入ってから工数が膨らみます。

完成の定義が人によって違う

「動くようになったら完成」という感覚は、依頼者と開発者で内容が違います。開発者にとっての完成は、想定した条件下で正しく動作することです。依頼者にとっての完成は、日々の業務で人が触らなくなることです。この二つの間には、例外処理、エラー通知、運用手順の整備といった作業が挟まっています。

見積もりの段階でこの差を埋めておかないと、金額に含まれていない作業を求められます。完成の定義を文章で書き、その定義に対する金額であることを見積書に明示してください。

見積もりを工程に分ける

RPAの見積もりは、一括の金額ではなく、工程に分けて提示するのが基本です。分けることで、各作業の必要性が伝わり、範囲の調整もしやすくなります。

業務調査

対象業務の実態を確認する工程です。依頼者に作業を実演してもらい、手順を記録し、例外を洗い出します。この工程を無償のヒアリングとして扱っている人が多いのですが、実際には最も重要な作業です。

この工程を有償にしておくと、依頼者の側にも「時間を確保して協力する」という意識が生まれます。無償のヒアリングだと、担当者は片手間で対応し、結果として情報が不足します。情報が不足したまま設計に入れば、あとで作り直しになります。

設計

自動化する処理の流れ、例外時の扱い、エラー通知の方法、実行のタイミングを決める工程です。ここで作る仕様書が、あとの検収の基準になります。

設計工程を見積書に立てておくと、もう一つの効果があります。依頼者が仕様を確認して承認するという手続きが、工程として可視化されることです。承認の記録が残れば、納品後に「そういう仕様だと思っていなかった」という指摘が出たときに、合意の証拠として示せます。

実装

ロボットを組み立てる工程です。ここは作業量が読みやすい部分に見えますが、例外処理の量によって大きく変動します。設計工程で例外を洗い出しているかどうかで、精度が変わります。

実装の見積もりを出すときは、正常系と例外系を分けて数えるのが有効です。「主処理の実装」「例外処理の実装（想定4パターン）」というように分けて書くと、パターンが増えたときに追加を提案する根拠になります。

テストと検証

作ったものが正しく動くかを確認する工程です。開発者側の単体確認と、依頼者側の業務確認は別物として扱います。依頼者側の確認に立ち会う時間も、工数として計上してください。

テストで見落とされがちなのが、実際の運用時間帯での確認です。業務システムの応答速度は、時間帯によって変わります。夜間に作った処理が、業務のピーク時間には間に合わないことがあります。この確認を工程に入れておくと、納品後の「遅くて使えない」という指摘を防げます。

引き渡しと初期運用

手順書の作成、設定値の一覧化、依頼者側の担当者への説明、そして稼働開始後の一定期間の見守りです。この工程を見積もりに入れていない人が非常に多い。しかし実際には、ここに時間が集中します。

稼働開始直後は、想定していなかった入力データが必ず出てきます。この対応を無償の範囲に入れてしまうと、納品後に無給で運用担当をすることになります。初期運用の期間と対応範囲を、金額の対象として明示してください。

あとから足せなくなる項目

見積書に書かなかった作業を、後日請求するのは困難です。ここでは、書き漏らしやすく、かつ工数の大きい項目を挙げます。この一覧を、見積もりを作るときのチェックリストとして使ってください。

業務整理そのもの

依頼者の業務が言語化されていない場合、それを整理する作業が発生します。これは自動化の準備ではなく、独立した作業です。書かなければ、開発の一部として無償で担うことになります。

例外パターンの追加分

設計時に想定した例外の数を、見積書に明記します。「想定パターンを超える例外が判明した場合、追加のお見積もりとなります」と書いておけば、実装中にパターンが増えたときに交渉できます。書いていなければ、いくつ増えても同じ金額です。

対象システムの調査

依頼者が使っている業務システムの仕様が公開されていない場合、動作を確認しながら仕様を推測する作業が発生します。この調査は、実装そのものより時間がかかることがあります。対象システムが特殊な場合、調査工程を別に立ててください。

依頼者側の環境準備の支援

実行端末の設定、ソフトウェアのインストール、権限の申請、セキュリティ製品の例外設定。これらは本来、依頼者側の情報システム部門が行う作業です。しかし担当者がいない場合、開発者が支援することになります。

支援するかどうかは案件次第ですが、支援するなら見積もりに入れます。入れないまま巻き込まれると、開発とは別の作業に時間を取られます。

依頼者側の担当者への操作説明

作ったロボットを、依頼者側の誰が起動し、誰が結果を確認するのか。その担当者に操作を説明する時間は、確実に発生します。しかも、担当者が複数いる場合や、途中で異動があった場合には、同じ説明を繰り返すことになります。

見積書には、説明の対象人数と実施回数を書きます。「操作説明を1回、最大3名まで実施」という形にしておけば、追加の説明を求められたときに別途の作業として提案できます。書いていないと、何度でも無償で対応する前提と受け取られます。

テストデータの作成

依頼者が用意すると思っていたテストデータを、開発者が作ることになる場合があります。実データには個人情報が含まれることが多く、そのまま受け取れないため、代替のデータが必要になります。誰が用意するかを見積書の前提条件に書いてください。

納品後の修正対応

無償で対応する範囲と期間を明示します。「検収完了後14日間、かつ2回までの修正を含む」という書き方であれば、その先は別料金であることが自動的に決まります。範囲を書かなければ、期限のない対応が前提と受け取られます。

マニュアルと引き継ぎ資料

手順書や設定値の一覧は、作れば必ず時間がかかります。成果物として明記し、金額の対象に含めてください。含めずに作ると、無償の追加作業になります。含めておけば、資料の充実が価値として伝わります。

ツールの選び方が見積もりを左右する

同じ業務を自動化する場合でも、どの方法で作るかによって工数は変わります。見積もりを作る段階で、方法の選択肢を持っているかどうかが、金額の妥当性と実装のしやすさを決めます。

画面操作型と連携型の使い分け

RPAは画面上の操作を再現する方法が基本ですが、対象のシステムが外部連携の仕組みを持っている場合は、そちらを使うほうが安定します。画面の見た目に依存しないため、対象システムの改修で止まる可能性が下がるからです。

見積書に関わる自動化の領域では、この使い分けが一つの論点として整理されています。

この記事では、RPAやiPaaSを使って見積書作成のどこまでを自動化できるのか、実際の導入事例、そして自動化を成功させるために押さえておくべきポイントを解説します。出典: service.biztex.co.jp

つまり、どこまでを画面操作で行い、どこからを連携の仕組みで行うかは、設計の判断です。この判断を見積もりの前に済ませておくと、工数の見通しが立ちます。判断せずに全体を画面操作で組む前提にすると、対象システムの改修のたびに修正が発生し、保守の負担が増えます。

依頼者が保守できる作りにするかどうか

現場の担当者が自分で手直しできる作りにすると、納品後の細かな連絡が減ります。これは依頼者にとってのメリットであり、開発者にとっても時間を守るメリットになります。

一方でデメリットもあります。依頼者側が手を入れて動かなくなったとき、原因の切り分けが難しくなる点です。この場合、改変後の動作を保証対象外とする条件を、見積書の前提条件に書いておく必要があります。作りやすさだけでなく、責任の切り分けまで含めて方法を選んでください。

ライセンスと費用の負担者を決める

RPAツールには利用料が発生するものがあります。この費用を誰が負担するのかを、見積もりの段階で明確にします。開発者側が立て替える前提になっていると、案件が終わったあとも費用だけが残ります。

原則として、ツールの契約は依頼者名義で行い、費用も依頼者が負担する形にします。開発者は依頼者のアカウントを借りて作業する立場です。この整理をしておくと、案件終了後の権利関係も明確になります。見積書には「ツールのライセンス費用は含みません」と明記してください。

見積もりで失敗する型と、うまくいく手順

相談を受けるなかで、見積もりの失敗には共通の型があります。同時に、うまくいっている人の手順にも共通点があります。

失敗しやすい型

一つ目は、依頼者の説明だけを聞いて、その場で概算の金額を口頭で伝えてしまう型です。口にした数字は基準になります。あとで正式な見積もりを出すときに、その数字より高くなると「話が違う」と受け取られます。概算を求められた場合は、「業務を拝見してからお出しします」と伝えるのが安全です。

二つ目は、作業内容を一行にまとめてしまう型です。「請求処理の自動化一式」という書き方では、どこまでが含まれるかが読み取れません。含まれると解釈されうる作業は、すべて含まれることになります。

三つ目は、納期だけを先に約束してしまう型です。依頼者側の確認や環境準備にかかる時間を計算せずに納期を出すと、遅れの責任が開発者に集まります。納期は、依頼者側の作業も工程に入れたうえで提示してください。

うまくいく手順

成功している進め方は、順序が決まっています。第1に、対象業務を実演で見せてもらい、記録を取ります。第2に、対象範囲の始点と終点を一文で書き、依頼者に確認します。第3に、洗い出した例外を一覧にして、実装する範囲を決めます。第4に、工程ごとに時間を積み上げて金額を出します。第5に、前提条件と変更時の手続きを添えて提示します。

この5つのステップを踏むと、見積もりの提示までに時間がかかります。しかし、この時間を惜しんで出した見積もりは、実装中に必ず崩れます。崩れた分は開発者が吸収するため、結果として損失は大きくなります。

もう一つのポイントは、見積書を出したあとに口頭で補足しないことです。補足した内容は記録に残らず、しかも依頼者の記憶には残ります。伝えるべきことがあれば、見積書か、見積書に添えるメールに書いてください。書面に残っている条件だけが、後日の基準になります。

前提条件の書き方

見積書の中で、金額と同じくらい重要なのが前提条件の欄です。ここに書いた内容が、後日の交渉の基準になります。

書くべきは、対象範囲の始点と終点、対象となる実行端末とその環境、依頼者側で用意するもの、確認や承認に要する期間の想定、そして想定している例外の数です。これらを列挙したうえで、最後に一文を添えます。「上記前提に変更が生じた場合は、工数および納期を再度お見積もりします」。

この一文の意味は、変更を拒否することではありません。変更が起きたら、その時点で条件を作り直すという手続きを、あらかじめ合意しておくことです。手続きが決まっていれば、変更は交渉事ではなく作業になります。

なお、フリーランス保護新法（特定受託事業者に係る取引の適正化等に関する法律）のもとでは、発注者は業務の内容、報酬額、支払期日などの取引条件を書面または電磁的方法で明示する義務を負っています。制度の概要は公正取引委員会が公表しています。つまり、条件を文書で確定させることは、受注側の要望である以前に、発注側が本来行うべき手続きです。見積書と発注書のやりとりを丁寧に行うことは、双方にとって法の枠組みに沿った進め方になります。

金額の根拠を説明できる形にする

見積もりの金額そのものより、その根拠を説明できるかどうかが交渉の結果を左右します。根拠のない総額は、値引き交渉の対象になります。工程と時間に分解された金額は、範囲の調整という話に変わります。

時間で分解する

各工程に必要な時間を積み上げて金額を出します。依頼者から「もう少し下げられませんか」と言われたときに、「どの工程を減らしますか」という会話に持っていけます。総額だけを提示していると、値引きに応じるか断るかの二択になります。

削れる工程と削れない工程を示す

業務調査と設計は、削ると後工程の失敗に直結します。一方、引き渡し資料の詳細度や、初期運用の見守り期間は、依頼者の体制によって調整できます。どこが調整可能かを示すと、予算に合わせた提案ができます。

削れない工程については、削った場合に何が起きるかを説明します。「業務調査を省くと、例外が実装後に判明し、結果として追加費用が発生する可能性が高くなります」。この説明は脅しではなく、実際に起きることの共有です。

段階的な見積もりを提案する

対象業務の実態が見えない段階では、全体の金額を出すこと自体に無理があります。この場合は、業務調査だけを先に受注し、その結果をもとに本開発の見積もりを出す二段構えにします。

依頼者にとっても、いきなり大きな金額を決めずに済むため受け入れられやすく、開発者にとっては精度の高い見積もりを出せます。調査の結果、自動化に向かないと判明した場合でも、その判断自体が依頼者にとっての成果になります。

支払いの条件も見積書に書く

金額と作業内容だけを書いて、支払いの条件を書かない見積書をよく見ます。しかし、いつ、どのように支払われるかは、受注側にとって金額と同じくらい重要な条件です。

書くべきは、支払期日の考え方、分割の有無、検収の基準です。開発期間が長い案件では、着手時と納品時に分ける形が一般的です。全額を納品後にすると、途中で案件が止まったときに、それまでの作業が回収できません。

検収の基準も、支払いの条件と一体で書きます。「テスト用データによる動作確認をもって検収完了とし、その後に請求します」という形にしておけば、検収の遅延が支払いの遅延に直結する構造を避けられます。あわせて、「納品後7日以内に検収結果の通知がない場合は検収完了とみなす」という条項を入れておくと、確認が止まったまま時間だけが過ぎる事態を防げます。

知的財産の扱いを一行入れる

開発したロボットの権利がどちらに帰属するのかも、見積書または契約書で決めます。書かないままにすると、後日、別の案件で似た処理を作るときに問題になる可能性があります。

実務では、成果物そのものの権利は依頼者に譲渡し、汎用的な処理の部品については開発者が引き続き利用できる、という整理をすることが多くあります。この整理を一行書いておくだけで、次の案件での作業効率が変わります。※権利の扱いが重要な案件では、契約書の文言を弁護士に確認してもらってください。

稼働後の運用体制を見積もりの最後に置く

自動化は、作った瞬間ではなく、動き続けている間に価値を生みます。そのため、見積書の最後には、稼働後の体制についての項目を置いておくと、依頼者の理解が変わります。

書くのは、実行結果をどう確認するか、異常時に誰が気づくか、その連絡経路はどうするか、という3点です。金額を確定させる必要はありません。「稼働開始後の保守については、無償対応期間の終了後に別途ご相談」という一行があるだけで、依頼者の頭のなかに「納品後にも運用が続く」という前提が入ります。

この一行がないまま納品まで進むと、保守の提案が唐突に感じられます。逆に、最初から見積書に項目として存在していれば、保守の話は当初からの計画の一部として受け取られます。見積書は金額の通知であると同時に、案件全体の設計図でもあります。

途中で条件が変わったときの手順

見積もりを出したあとに条件が変わることは、珍しくありません。重要なのは、変化に気づいた時点で手続きを踏むことです。

まず、変化の内容を記録します。「本日のお打ち合わせで、対象に月次の集計処理を追加するご要望を伺いました」という一文をメールで送るだけで十分です。次に、その変更が当初の前提条件のどれに該当するかを示します。そして、追加の工数と納期への影響を提示します。

この3つを踏まずに作業を進めると、変更は無償で吸収されたものとして扱われます。しかも、依頼者は追加を依頼した自覚を持たないまま進むため、後から請求すると不信感につながります。手続きを踏むことは、自分を守るだけでなく、相手との認識をそろえる作業でもあります。

実際に相談を受けた案件では、開発の途中で対象の取引先が増え、様式の分岐が倍になったにもかかわらず、その場では何も言わずに実装を進め、納品後に追加請求をして揉めたケースがありました。作業した事実は変わらないのに、記録がないために交渉が難しくなる。この構造を避けるには、変化した時点で記録を残すしかありません。※記録を残しても支払いに応じてもらえない場合は、早い段階で弁護士に相談してください。法律は、条件を明確にして働く人の味方になります。

見積もりの精度は入口の構造で変わる

20年この市場を見てきた立場から言えば、見積もりの精度は、開発者の経験値だけでは決まりません。依頼者と直接話せるかどうかで、集められる情報の量がまったく違うからです。仲介が何層も入る経路では、業務の実演を見ることも、例外について質問することも難しく、断片的な情報から金額を出すことになります。外れた分は、開発者が無償で吸収します。

依頼者と直接やりとりできる経路であれば、業務調査から関与し、前提条件を自分で書き、変更が起きたときの手続きも自分で設計できます。中間マージンが乗らない直接取引では、同じ予算でも依頼者はより多くを頼め、受け手は手数料0%のぶん手取りが厚くなります。ただ、運営者として見てきた限りでは、長く続いている人が重視しているのは金額よりも、条件を自分で決められる関係のほうです。

RPAの依頼がどのような形で発注されているかを知っておくと、見積もりの前提を組み立てやすくなります。定型業務の自動化がどう案件化されているかはRPA・業務自動化ツールのお仕事にまとまっています。自動化の周辺には、データ分析や広告運用の効率化といった隣接領域の依頼も発生します。この広がりはAI・マーケティング・セキュリティのお仕事で確認できます。

工数を金額に換算する感覚を持つには、開発職の報酬水準の考え方を知っておくことが役に立ちます。基準となる情報はソフトウェア作成者の年収・単価相場で整理されています。また、見積書や仕様書の書き方そのものが、後々の交渉力を左右します。実務文書の型を体系的に扱う資格としてビジネス文書検定があります。ネットワークやセキュリティの制約が絡む環境を扱う場合は、CCNA（シスコ技術者認定）の知識が、実行環境の確認や情報システム部門との会話で効いてきます。

見積もりに書けなかった項目は、あとから足せません。だからこそ、金額を計算する前に、これから起きることを全部書き出す。その作業に時間をかけた分だけ、納品までの数か月が静かになります。