RPA・業務自動化の修正を何回まで受けるか｜先に決めておく

2026年6月29日

長谷川奈津

この記事のポイント

✓RPA・業務自動化の修正対応で消耗しないために
✓無償で直す範囲と別料金になる範囲の線引き
✓検収と受付窓口の決め方

RPAの案件で最も相談が多いのは、実は単価の話ではありません。「納品したはずなのに、修正依頼が終わらない」という話です。これ、知らない人が本当に多いんですが、RPAの修正対応が長引く原因のほとんどは、開発者の技術力ではなく、契約前に「どこまでが修正で、どこからが別作業か」を決めていないことにあります。結論から言うと、回数の上限だけを決めても止まりません。止めるには「何を修正と呼ぶか」の定義と、回数または期間のどちらで区切るかを、着手前に文書で確定させる必要があります。

この記事では、RPA・業務自動化の修正対応について、無償で直すべき範囲と別料金にしてよい範囲の線引き、回数制と期間制それぞれの設計方法、検収の定義の書き方、そして実際に揉めたときの進め方までを順に整理します。※個別の紛争に発展しているケースでは、この記事の内容を参考にしたうえで弁護士に相談してください。

RPAの修正依頼が終わらなくなる構造

RPAの開発は、Webサイト制作やデザインの仕事と決定的に違う点があります。納品物が「見た目」ではなく「動作」であり、しかもその動作が依存している対象が、納品後も勝手に変わり続けるという点です。ここを理解しないまま、他の制作系の仕事と同じ感覚で契約すると、修正対応が無限に伸びます。

「動くはず」と「動いた」の間にある溝

RPAのロボットは、画面上の要素を認識して操作します。ボタンの位置、テーブルの列の並び、ポップアップの有無、読み込み速度。これらのどれか一つが変われば、ロボットは止まるか、誤った動作をします。開発時の環境では完璧に動いたものが、依頼者の端末では動かない。この現象自体は、RPAの世界では珍しくもなんともない日常です。

問題は、依頼者側から見ると、この現象が「不具合」に見えることです。動くと言われたものが動かない。ならば直すのは当然だ。この認識は、依頼者として自然なものです。一方、開発者から見れば、原因は自分の書いたロジックではなく、依頼者の端末設定や、依頼者が使っている業務システムの側にあります。どちらの言い分にも根拠があるからこそ、線引きを決めていないと平行線になります。

RPAツールの提供元が示している説明を見ると、この「修正すれば対応できる」という柔軟性そのものが、RPAの利点として整理されています。

デジタルレイバーは自己都合で辞めることはありませんし、24時間休みなく働き続けることも可能です。作業の初回から終わりまで、抜け・漏れや見落としといった“うっかりミス”とは無縁で、もし実際の稼働中にエラーが発生しても、1度修正すれば繰り返しません。さらに、業務の手順や仕様が急に変化しても、RPAツールで簡単な修正をすれば対応できる柔軟性も備えています。出典: rpa-technologies.com

つまり、修正できることはRPAの長所として説明されているわけです。依頼者がその説明を読んでいれば、「簡単な修正で対応できるはずだ」と考えるのは当然の流れになります。ここに、開発者側の「その修正は簡単ではない」という実感とのズレが生まれます。長所として語られている柔軟性が、受注側では無償対応の圧力に変わる。この構造を先に理解しておくことが、契約書の文言を組み立てる出発点になります。

業務そのものが動き続けるという前提

もう一つの厄介な性質は、自動化の対象である業務が生き物だということです。請求書の様式が変わる、承認フローに一段階増える、取引先が増えてマスタの管理方法が変わる。業務側の変化は、依頼者の社内では「ちょっとした運用変更」として扱われます。しかしロボットにとっては、処理の分岐が丸ごと増えることを意味します。

依頼者に悪意があるわけではありません。むしろ多くの場合、依頼者は自分たちの変更がロボットにどれだけ影響するかを、そもそも想像できていません。だからこそ、契約時に「業務側の変更が発生した場合は、修正ではなく追加作業として扱う」と書いておく必要があります。書いていなければ、相手は書いていない側に有利な解釈をします。これは意地悪ではなく、単に情報がないからです。

修正と追加開発を分ける3つの分類

修正対応の議論を感情論にしないために、まず「修正」という言葉を3つに分解します。この分解ができていれば、依頼が来たときに「これは無償」「これは別料金」を即座に判断でき、その根拠を相手に説明できます。

契約不適合責任にあたるもの

合意した仕様どおりに動いていない状態です。仕様書に「A列の値をB画面に転記する」と書いてあるのに、C列を転記している。エラー時にログを残すと合意したのに、残していない。これは開発側の責任であり、無償で直す領域です。

法律上、この責任は民法の契約不適合責任として整理されます。つまり、引き渡したものが契約の内容に適合していなければ、直す義務があるという考え方です。ここを争っても勝ち目はありませんし、争うべきでもありません。重要なのは、この範囲を明確にするために「合意した仕様」が文書として存在していることです。口頭のやりとりだけで進めた案件では、何が仕様だったかを後から証明できず、相手の主張する仕様がそのまま基準になってしまいます。

仕様変更にあたるもの

合意した仕様には含まれていなかった動作を、後から求められる状態です。「ついでにこの帳票も出力してほしい」「エラーになった行をチャットに通知してほしい」。この種の依頼は、依頼者にとっては小さな追加に見えますが、実装としては新しい処理系を一つ増やすことになります。

ここは別料金の領域です。ただし、実務では「追加ですね」と一言で返すより、「対応可能です。この内容は当初の仕様に含まれていないため、追加のお見積もりをお出しします」と、可否と費用発生をセットで伝えるほうが摩擦が少なくなります。断っているのではなく、条件を提示しているという形にすることが要点です。

環境変化にあたるもの

対象システムのバージョンアップ、画面デザインの変更、ブラウザの更新、業務フローの変更によってロボットが止まる状態です。開発時点では正しく動いていたのですから、開発側の不履行ではありません。しかし依頼者から見ると「動かなくなった」という一点で、不具合と区別がつきません。

この領域こそ、事前の合意が決定的に効きます。「納品後に対象システムまたは業務手順が変更されたことに起因する不具合は、保守の対象とし、別途費用を要する」。この一文があるかないかで、その後の数か月の労力がまったく変わります。RPAの案件では、この環境変化による停止が、修正依頼全体のかなりの割合を占めます。ここを無償の範囲に入れてしまうと、納品後もずっと無償の運用担当者を続けることになります。

回数で区切るか、期間で区切るか

修正対応の範囲を決める方法は、大きく分けて2つあります。回数で区切る方法と、期間で区切る方法です。どちらが優れているという話ではなく、案件の性質によって適する形が違います。

回数制の設計

「納品後の修正は2回まで無償」という形です。単発の小規模な自動化、対象システムが安定していて変更の少ない業務、依頼者側に確認できる担当者が一人しかいない案件などに向きます。

回数制で必ず決めておくべきなのは、1回の定義です。ここが曖昧だと、依頼者は指摘を小出しにして回数を稼ぎ、あるいは開発者側が「今のは1回に数えます」と言えずに終わります。実務では、「1回の修正とは、依頼者から一括で提出された指摘事項の集合に対する対応を指す」と定義します。つまり、指摘は一覧にまとめて出してもらう。これを契約時に決めておけば、指摘の提出方法まで自然に統制できます。

もう一つ、回数の起点も決めます。検収完了日から起算するのか、初回納品日から起算するのか。検収が長引くタイプの依頼者の場合、初回納品日を起点にしておかないと、いつまでも回数が消化されません。

期間制（保守）の設計

「納品後30日間は無償で対応し、以降は月額の保守契約に移行する」という形です。対象システムの変更が読めない業務、複数部署が使うロボット、他システムと連携する処理などに向きます。

期間制の利点は、依頼者にとっても分かりやすいことです。回数制だと「あと1回しか残っていないから、この不具合を報告すべきか迷う」という状態が生まれ、結果として依頼者が不満を溜めます。期間制なら期間内は気兼ねなく報告してもらえるため、初期の安定化が早く進みます。開発側にとっても、期間が切れれば自動的に保守契約の話に移行できるため、継続的な関係に繋げやすくなります。

期間制で決めておくべきなのは、対応の範囲と応答時間です。期間内なら何でも無償かというと、そうではありません。期間制であっても、上で整理した仕様変更にあたる依頼は別料金です。「期間内の無償対応は、契約不適合にあたる不具合の修正に限る」と明記しておきます。

両方を組み合わせる

実務で最も揉めにくいのは、両方を併用する形です。「検収完了後14日間、かつ2回までを無償修正の範囲とする」。期間で終わりを作り、回数で1回あたりの分量を統制します。どちらか一方に達した時点で無償対応は終了、という書き方にすれば、期限のない対応を防げます。

契約前に決めておく項目

修正対応で消耗する人と、しない人の違いは、契約書に書いてある項目の数です。以下は、RPA案件で最低限決めておきたい項目です。金額の交渉より先に、この項目を埋める作業をしてください。

検収の定義と期限

いつをもって納品完了とするかを決めます。RPAの場合、「テスト用のデータで想定どおりの結果が得られたこと」を検収条件にするのが現実的です。本番データでの完全動作を検収条件にすると、依頼者側の準備が整うまで検収が終わらず、その間ずっと修正対応が続きます。

検収の期限も必要です。「納品後7日以内に検収結果の通知がない場合は、検収完了とみなす」というみなし検収の条項です。これ、書いていない人が本当に多いんですが、書いていないと「まだ検収していない」という理由で報酬の支払いも修正対応の終了も先延ばしにされます。

なお、フリーランス保護新法（特定受託事業者に係る取引の適正化等に関する法律）では、発注者は物品等を受領した日から60日以内のできる限り短い期間内に報酬支払期日を定めることが求められています。つまり、検収が終わっていないことを理由に支払いを無期限に遅らせることは、そもそも法の枠組みに反します。制度の全体像は公正取引委員会の公表資料で確認できます。

修正の受付窓口と申請方法

誰から、どの経路で受け付けるかを決めます。ここを決めないと、依頼者の社内の複数人から、チャット、メール、電話、口頭で修正依頼が飛んできます。しかもその内容が互いに矛盾していることがあります。

窓口は一人に絞ります。経路も一つに絞ります。「修正依頼は、依頼者側の指定担当者から、指定のフォームまたはメールにより、事象・発生手順・スクリーンショットを添えて提出する」。この形式を決めておくと、それだけで曖昧な依頼が減ります。再現手順を書けない依頼は、そもそも不具合ではないことが多いためです。

対象環境の固定

どの端末、どのOS、どのブラウザ、どのバージョンの業務システムで動作することを保証するのかを明記します。これを書いていないと、依頼者が別の端末で動かして「動かない」と言ってきたときに反論できません。

「本ロボットは、依頼者が指定した端末1台における動作を保証対象とする。他の端末での動作、および対象環境の更新後の動作は保証対象外とする」。この一文が、環境変化による無償対応を防ぐ最後の砦になります。

例外条項

想定外の事態に備えて、無償対応の対象外を列挙しておきます。対象システムの仕様変更、依頼者による設定変更、ネットワーク障害、依頼者が提供したデータの不備、ロボットの改変。これらに起因する不具合は保証対象外とする、と書きます。

特に「依頼者による改変」は重要です。RPAの開発物は、依頼者側でも編集できるツールが多いためです。依頼者の担当者が自分で少し触って壊し、それを不具合として報告してくるケースは実際に起きます。改変後の動作は保証対象外と書いておけば、この場面で調査費用を請求する根拠になります。

保守の入口を見積書に書いておく

見積書に開発費だけを書くと、依頼者は「納品されたら支払いは終わり」と理解します。その状態で保守の話を後から持ち出すと、追加請求の交渉に見えてしまいます。

これを避けるには、見積書の段階で保守の欄を設けます。金額を確定させる必要はなく、「納品後の保守について、無償対応期間の終了後は別途ご相談」という一行があるだけでも効果があります。依頼者の頭のなかに「納品後にも費用が発生しうる」という前提が入るからです。逆に、この一行がないまま納品まで進むと、保守の提案そのものが唐突に感じられます。

見積書は金額を伝える書類であると同時に、取引の前提条件を共有する書類でもあります。修正対応の範囲、対象環境、検収の考え方を見積書の備考に書いておけば、契約書を交わさない小規模案件でも、後から参照できる合意の記録になります。

納品前後の実務手順

契約書を整えても、進め方が雑だと修正は増えます。着手から納品後までの各段階で、修正を減らすために踏むべき手順があります。

着手前：業務の観察と例外の洗い出し

依頼者が説明する業務手順は、たいてい正常系だけです。実際の業務には、月末だけ発生する処理、特定の取引先だけ様式が違う書類、担当者が経験則で判断している例外が必ず含まれます。これらを着手前に洗い出さないと、納品後に「この場合はどうなるのか」という指摘が連続します。

有効なのは、依頼者に作業を実演してもらい、その画面を記録することです。口頭のヒアリングでは出てこない例外が、実演では必ず出ます。「あ、この取引先のときは別のファイルを見るんです」という発言が出た瞬間が、仕様の分岐点です。この段階で拾った例外は、仕様書に明記して見積もりに含めます。拾わなかった例外は、納品後に無償の修正依頼として戻ってきます。

開発中：仕様の変更を都度記録する

開発中に依頼者から出る「やっぱりこうしてほしい」を、その場で口頭合意して進めるのは避けます。小さな変更であっても、記録に残します。メールやチャットで「本日ご指示いただいた内容を仕様に反映します。当初仕様からの変更点は次のとおりです」と送るだけで十分です。

この記録がないと、納品後に「最初からこう言っていたはずだ」という議論になり、開発側に証拠がありません。記録があれば、その変更が当初仕様に含まれていなかったことを示せます。相手を疑うためではなく、双方の記憶違いを防ぐための作業です。

納品時：引き渡すものを揃える

RPAの納品物は、ロボットのファイルだけではありません。動作手順書、エラー時の対処方法、設定値の一覧、対象環境の条件。これらを添えて納品します。

引き渡す資料を充実させると仕事を失うのではないか、と考える人がいますが、実際は逆に働きます。資料がないと、依頼者は些細な疑問でも開発者に連絡するしかありません。その連絡一つ一つが、無償の対応時間になります。資料を渡して自己解決できる範囲を広げたほうが、開発者の時間は守られます。そして、資料を整備できる開発者は、次の案件でも指名されます。

納品後：ログを見る習慣を持つ

RPAは動かして終わりではなく、動き続けているかどうかが価値です。納品後の一定期間、実行ログを確認できる状態にしておくと、依頼者から報告が来る前に異常を把握できます。先に気づいて連絡すれば、それは不具合報告ではなく、保守提案の場になります。

ツールの種類によって修正の起きやすさは変わる

修正対応の量は、どのツールで作るかによっても大きく変わります。ツールの選び方は依頼者が決めることが多いのですが、開発者側から提案できる場面では、修正の起きにくさを判断材料に入れてください。ここを押さえておくと、見積もり時に保守条件を設計しやすくなります。

クラウド型は対象が絞られるぶん安定しやすい

ブラウザ上の操作を対象とするクラウド型は、端末ごとの環境差の影響を受けにくく、修正の発生要因が比較的少なくなります。導入の敷居が低いことも、ツール提供元の説明で強調されています。

クラウド型RPAツールによる自動化のメーンターゲットは、Webブラウザ上で行われる単純作業で、現場の担当者が日々の業務の中で行っている作業を自動化できます。こうした身近な領域から業務自動化を進めることで、導入の効果がより早く感じられ、広範囲の業務自動化に取り組みやすくなるでしょう。出典: rpa-technologies.com

メリットは、対象がブラウザに限定されるため、動作保証の範囲を契約書で書きやすいことです。デメリットは、対象サイト側の改修が入ると一斉に止まる点で、これは環境変化にあたるため保守の設計が必須になります。

デスクトップ型は端末環境が変数になる

端末上のアプリケーションを操作するデスクトップ型は、自動化できる範囲が広い代わりに、端末ごとの解像度、フォント設定、常駐ソフト、更新プログラムの適用状況といった変数が一気に増えます。開発環境では動いたものが依頼者の端末で動かない、という典型的な事象はこの型で最も多く起きます。

このため、デスクトップ型の案件では、対象端末を1台に固定する条項が特に重要になります。加えて、可能であれば依頼者の実端末で最終確認まで行い、その状態を記録に残してから納品します。この一手間が、納品後の「動かない」という報告を大きく減らします。

サーバー型は関係者が増える

サーバー上で集中管理する型は、規模の大きい業務に向く一方、情報システム部門や他ベンダーが関与します。関係者が増えるほど、修正依頼の窓口が分散し、依頼内容が矛盾しやすくなります。窓口の一本化と、変更管理の手順の共有を、着手前に取り決めておく必要があります。

修正を減らす進め方と、増やしてしまう進め方

同じ内容の案件でも、進め方の違いで修正の総量は変わります。実際に相談を受けた案件から、事象を匿名化して整理します。

失敗しやすい進め方は、ヒアリングを一度きりの打ち合わせで済ませ、その場のメモをもとに一気に開発し、完成品を一括で見せる形です。ある案件では、依頼者が説明した手順どおりに請求処理を自動化して納品したところ、月末に処理する取引先だけ様式が違うことが判明し、そこから修正依頼が連続しました。原因は開発の質ではなく、例外を洗い出す工程を省いたことにあります。

成功しやすい進め方は、工程を小さく刻み、途中経過を見せながら進める形です。具体的には次のステップになります。第1に、依頼者に作業を実演してもらい、記録を取る。第2に、対象範囲と例外を一覧にして、依頼者の署名または明示的な同意を得る。第3に、処理の一部だけを動く状態にして早い段階で見せる。第4に、依頼者の実端末で確認する。第5に、手順書と設定値の一覧を添えて納品する。

このステップを踏むと、納品前に依頼者側の認識のずれが表面化します。ずれは、納品後に発見すれば修正依頼になりますが、開発途中で発見すれば仕様調整で済みます。同じ作業でも、発見する時期が違うだけで、無償か有償かが変わるわけです。これ、知らない人が本当に多いポイントです。

一つ補足しておくと、途中経過を見せる進め方は、依頼者の要望が膨らむのではないかと敬遠されることがあります。実際には逆で、完成品を一括で見せるほうが、依頼者は「まだ言い足りない」という状態のまま検収に入るため、修正依頼が増えます。早い段階で意見を出してもらい、その内容を仕様に反映して合意を取り直すほうが、結果として総量は減ります。

揉めたときの進め方

線引きをしていても、認識の相違は起きます。そのときに感情的な応酬にしないための手順を、あらかじめ持っておきます。

まず、依頼された内容を分類し直します。3つの分類のどれにあたるかを、相手の言葉ではなく事象で判断します。次に、判断の根拠を示します。「仕様書のこの項目にはこう記載しており、今回のご依頼はこの範囲外にあたります」。契約書と仕様書という共通の基準に立ち返るだけで、多くの議論は落ち着きます。

それでも折り合わない場合は、対応そのものを止めるのではなく、条件を提示します。「本件は追加作業にあたりますが、対応は可能です。工数と納期をお出ししますので、ご判断ください」。相手に判断を渡す形にすると、対立ではなく検討事項になります。

支払いの遅延や、一方的な報酬の減額を伴う場合は、様相が変わります。フリーランス保護新法では、発注者が受領後に理由なく報酬を減額することや、支払いを遅延させることは明確に規制されています。取引条件の書面での明示も義務です。取引に関する相談窓口は公正取引委員会や中小企業庁が案内していますので、当事者間だけで抱え込まないことが大切です。※減額や支払い拒否が現実に発生している場合は、早い段階で弁護士に相談してください。法律は、条件を明確にして働く人の味方になります。

案件の入口で決まる部分

20年この市場を見てきた立場から言えば、修正対応で疲弊するかどうかは、開発者の交渉力より、案件の入口の構造で決まっている部分がかなり大きいです。仲介が何層も入る案件では、依頼者の本当の要望が伝言で薄まり、仕様が曖昧なまま着手することになります。曖昧な仕様は、納品後に必ず修正依頼として跳ね返ってきます。

一方、依頼者と直接やりとりできる案件では、着手前に業務を見せてもらい、例外を洗い出し、条件を文書にする一連の流れを、開発者自身の手で組み立てられます。中間マージンが乗らない直接取引では、同じ予算でも依頼者はより多くを頼め、受け手は手数料0%のぶん手取りが厚くなります。ただ、金額以上に効いているのは、条件を自分で決められるという点のほうです。長く続いている人ほど、単発の作業を積むのではなく、この「決められる関係」を先に作ることに時間を使っています。

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

見積もりの根拠を説明するには、開発工数を金額に換算する感覚も要ります。開発職の報酬水準の考え方はソフトウェア作成者の年収・単価相場で確認できます。また、仕様書や手順書の書き方そのものが修正削減に直結するため、文書作成の型を学び直すのも有効です。実務文書の基本を体系的に扱う資格としてビジネス文書検定があります。ネットワーク環境が絡む自動化を扱うなら、通信の基礎知識を証明できるCCNA（シスコ技術者認定）も、依頼者への説明力を支える材料になります。

修正を何回まで受けるか。この問いへの答えは、数字そのものではありません。何を修正と呼ぶかを定義し、終わりの条件を文書に落とし、その基準で淡々と判断する。この準備を着手前に済ませているかどうかが、納品後の数か月を決めます。

よくある質問

Q. RPAの無償修正は何回に設定するのが一般的ですか？

単発かつ対象システムが安定している案件なら2回程度、対象システムの変更が読めない案件なら期間制が向きます。実務では「検収完了後14日間、かつ2回まで」のように期間と回数を併用し、どちらかに達した時点で無償対応を終了する形が最も揉めにくくなります。回数を決める以上に、1回の定義を先に決めることが重要です。

Q. 対象システムの画面が変わってロボットが止まった場合も無償で直すべきですか？

納品時点で仕様どおり動作していたのであれば、開発側の不履行ではないため無償対応の義務はありません。ただし契約書に「対象システムまたは業務手順の変更に起因する不具合は保守の対象とし、別途費用を要する」と明記していない場合、依頼者は不具合として扱ってきます。着手前に環境変化を保証対象外と定めておいてください。

Q. 検収がいつまでも終わらず修正依頼が続きます。どうすればよいですか？

検収の条件と期限を契約に入れていないことが原因です。テスト用データでの想定結果を検収条件とし、「納品後7日以内に検収結果の通知がない場合は検収完了とみなす」というみなし検収の条項を入れます。なお報酬の支払期日は受領日から60日以内に定めることが法で求められており、検収未了を理由に無期限に遅らせることはできません。