アプリ開発の修正を何回まで受けるか｜先に決めておく

アプリ開発は、完成の状態を言葉で完全に記述できない仕事です。画面の遷移、動作の速度、ボタンの押し心地。仕様書に書ききれない要素が大量にあり、実物を見て初めて依頼者が「思っていたのと違う」と気づく。この構造がある限り、修正の発生は避けられません。

避けられないものを避けようとするから、揉めます。修正は必ず起きるという前提に立って、起きたときの扱いを先に決めておく。これが受注後の実務としての正解です。

「修正」という言葉が指す範囲が人によって違う

つまり、こういうことです。開発者が「修正」と言うとき、頭にあるのは「仕様どおりに動いていない箇所を直すこと」です。依頼者が「修正」と言うとき、頭にあるのは「思ったとおりになっていない箇所を直すこと」です。この2つは重なる部分もありますが、まったく同じではありません。

仕様どおりに動いているが、依頼者の思ったとおりではない。この状態が発生したときに、どちらが費用を負担するのか。ここが決まっていない契約が、揉める契約です。

決めるべきは回数と範囲と期限の3点

回数だけ決めても不十分な理由は単純で、1回の修正依頼にいくつの項目が入るか制限がないからです。「1回目の修正です」と言って30項目のリストが送られてきたら、回数の取り決めは意味を失います。

範囲を決めるとは、どの種類の依頼が回数を消費するかを定めることです。期限を決めるとは、納品後いつまで修正依頼を受け付けるかを定めることです。この3点が揃って初めて、取り決めが機能します。

修正の3分類

実務では、修正依頼を受け取った瞬間に次の3つに分類します。分類が全部の起点になります。

契約不適合にあたる修正

仕様書や合意した内容と、実際の動作が食い違っている場合です。ボタンを押しても画面が遷移しない、入力した値が保存されない、特定の端末で表示が崩れる。合意した内容を満たしていないのですから、これは開発側の責任で直します。無償です。回数にも数えません。

民法の改正で、以前「瑕疵担保責任」と呼ばれていたものは「契約不適合責任」という枠組みに整理されました。つまり、引き渡したものが契約の内容に適合していない場合、依頼者は修補や代金の減額などを請求できるという考え方です。この責任には期間の定めがあり、契約で別途取り決めることもできます。制度の詳細や自分の契約への当てはめについては、法令の原文を確認したうえで、判断に迷う場合は弁護士に相談してください。

仕様変更にあたる修正

合意した内容とは違うものを、新たに求められている場合です。「やっぱりこの画面に一覧表示も付けたい」「ログイン方法をもう一つ増やしたい」。これは修正ではなく追加開発です。

依頼者に悪気はありません。実物を見て、より良い形が見えただけです。だから、責める必要はまったくない。ただし、費用と納期は改めて見積もる必要があります。ここを曖昧に飲み込むと、そのまま無償の追加開発が積み上がります。

主観的な調整にあたる修正

仕様どおりに動いているが、色味、余白、文言、アニメーションの速度などを変えたいという依頼です。これが最も判断に迷い、最も膨らみます。

主観的な調整は、明確な正解がありません。だから終わりません。ここに回数の上限を設けるのが、修正回数を決める最大の目的です。「デザインの微調整は2回まで、それ以降は別途お見積り」といった形にします。

分類を先に共有する方法

この3分類を、契約前の打ち合わせで依頼者に説明しておきます。説明しておかないと、後から分類を持ち出したときに「後出しだ」と受け取られます。

説明のときは、依頼者にとっての利点も併せて伝えます。「不具合の修正は期限内なら何度でも無償で対応します。そのかわり、仕様の追加は都度お見積りさせてください」。無償の範囲を明示すると、有償の範囲も受け入れられやすくなります。

何回まで受けるか、決め方の基準

回数の決め方には、いくつかの考え方があります。案件の性質で使い分けます。

工程ごとに回数を割り当てる

一括で「修正は3回まで」とするより、工程ごとに分けたほうが実務的です。デザイン案の段階で2回、実装後の確認で2回、といった具合です。

工程を分ける利点は、手戻りの重さが工程によって違う点にあります。デザイン段階の修正は軽く、実装後の修正は重い。同じ「1回」でも消費するコストが違うのですから、同じ枠で数えるのは合理的ではありません。工程ごとに枠を切ると、依頼者にも「早い段階で言ったほうが得だ」という動機が生まれます。

回数ではなく期間で区切る方法

回数を数えるのが煩雑な案件では、期間で区切る方法もあります。「納品後2週間は無償で調整に対応、それ以降は保守契約または都度見積り」という形です。

この方式の利点は、数え方で揉めないことです。欠点は、期間内に依頼が集中すると負荷が読めない点です。期間方式を採るなら、対応の範囲を明確に絞っておく必要があります。

無償と有償の境目をどこに置くか

境目の置き方に唯一の正解はありませんが、判断の軸は一つです。「合意した内容を満たすための作業か、合意を超える作業か」。この軸で切ると、説明が一貫します。

作業量の大小で境目を決めると、説明が破綻します。「小さい修正だから無料でしょう」という交渉に対して、反論の根拠を失うからです。軸は量ではなく、合意の内側か外側か。ここを揺らさないことが、長く続けるコツです。

見積書と契約書に書く文言

決めた内容は、必ず書面に落とします。口頭の合意は、担当者が代わった瞬間に消えます。

見積書に書く一文

見積書の備考欄に、次の趣旨を1行入れておくだけでも効果があります。「本見積に含まれる修正対応は、仕様確定後のデザイン調整2回までとし、仕様の追加および変更が生じた場合は別途お見積りいたします」。

見積書は依頼者が社内で回覧する書類です。ここに書いてあると、依頼者の社内でも前提として共有されます。契約書だけに書いて見積書に書かないと、現場の担当者が知らないまま依頼を出してくることがあります。

契約書に入れる条項

契約書には、もう少し細かく書きます。修正対応の回数、対象となる作業の種類、受付の期限、期限後の対応方法と費用の考え方。加えて、依頼の窓口を誰にするかも決めておきます。

窓口の指定は軽視されがちですが、効きます。複数の関係者からバラバラに修正依頼が来る状態は、回数の取り決めを無効化します。「修正のご依頼は、貴社ご担当者様を通じて一本化してお送りください」という一文があるだけで、現場の混乱がかなり減ります。

検収の定義を書く

いつをもって納品が完了したとするか。これを決めていないと、修正の受付期限も始まりません。

実務的には「納品物の引き渡し後、○営業日以内に検収の可否をご連絡いただき、期間内にご連絡がない場合は検収が完了したものとみなします」という形が使われます。この日数は案件の規模で調整します。検収の起点が決まって初めて、その後の修正対応の期限が意味を持ちます。

書面の作成そのものに苦手意識がある場合、ビジネス文書の基本的な型を押さえておくと役に立ちます。契約書や見積書の文言は独特ですが、土台にあるのは正確に伝わる文章を書く技術です。ビジネス文書検定の出題範囲は、その基礎を体系的に確認する材料になります。

取引条件の明示と、やり直しの扱い

2024年に施行されたフリーランス保護新法（特定受託事業者に係る取引の適正化等に関する法律）では、発注する側の事業者に対していくつかの義務が定められています。代表的なものを挙げると、業務を委託した際に取引条件を書面または電磁的方法で明示すること、成果物を受領した日から起算して60日以内のできる限り短い期間内に報酬を支払うこと、そして受託者に責任のない理由で成果物のやり直しをさせることを禁じる規定などです。

つまり、これまで慣習で曖昧に処理されていた「言われるままの無償対応」に、法律上の歯止めが用意されたということです。ただし、どのケースがこの規定に該当するかは個別の事情によります。制度の正確な内容は所管の公的機関の情報で確認してください。取引の適正化に関する情報は公正取引委員会が公開しています。※ 実際のトラブルに当てはめる判断が必要な場合は、弁護士に相談してください。

法律があることを知っているだけでも、交渉の場での姿勢が変わります。知らないまま従い続けるのと、根拠を持って線を引くのとでは、その後の関係がまったく違うものになります。

依頼が来たときの手順

取り決めがあっても、運用しなければ意味がありません。修正依頼を受け取ったときの手順を決めておきます。

受けた依頼をその場で分類する

依頼のリストを受け取ったら、項目ごとに前述の3分類を当てます。1通のメールに、契約不適合の指摘と仕様変更の要望と主観的な調整が混在しているのが普通です。混ざったまま作業を始めると、後から切り分けられなくなります。

分類の結果を文字で返す

分類したら、その結果を依頼者に返します。項目番号ごとに「これは不具合なので無償で対応します」「これは仕様の追加なのでお見積りします」「これは調整枠の1回目として対応します」と書き分けます。

この返信が、最も重要な工程です。返さずに作業を始めると、依頼者は全部が無償で対応されたと認識します。認識されたものは、次の依頼の前提になります。1回目で線を引かないと、線は二度と引けません。

回数を消費するかどうかを明示する

調整枠を消費する依頼については、残り回数を毎回書きます。「今回の対応で調整枠の残りは1回です」。この一行があると、依頼者側も依頼をまとめるようになります。人は残数が見えると節約します。

追加見積の出し方

仕様変更に該当する項目は、作業と金額と納期を分けて提示します。金額だけを出すと、高いか安いかの議論になります。作業の内訳を出すと、依頼者は取捨選択ができるようになり、話が前に進みます。

見積を出した項目については、承認をもらってから着手します。「先に進めておきました」は、請求できない作業を自分で作る行為です。

修正が膨らむ前に効く予防策

そもそも修正を減らす工夫も、同時に効きます。

仕様の確定は、文章ではなく画面で合意します。文章の仕様書は、書いた側と読んだ側で違う絵が浮かびます。ワイヤーフレームや簡易な画面設計を見せて「この配置で進めます」と確認を取ると、後からの認識のずれが減ります。

プロトタイプ段階でのレビューを厚くするのも有効です。実装が進むほど修正のコストは上がります。動く前の段階で依頼者に触ってもらう機会を作れば、重い手戻りを軽い段階に移せます。

用語集を作るのも地味に効きます。「一覧画面」「詳細画面」「マイページ」といった言葉を、双方が同じものを指して使っているとは限りません。最初に用語を揃えておくと、依頼文の解釈で揉める場面が減ります。

依頼者側の決裁者を1人にしてもらうことも、事前に頼んでおきます。複数の関係者がそれぞれの好みで意見を出す状態になると、調整が終わらなくなります。「ご意見を取りまとめたうえで、ご担当者様からお送りください」と最初に伝えておきます。

AIを使った開発で増えている修正の型

近年は、生成AIを使ってアプリを組み立てる場面が増えています。それに伴って、これまでになかった種類の修正依頼が発生しています。指示したとおりに直っていない、一部だけが古い状態のまま残る、といった相談です。

chat gptを使ってアプリ開発をしています。 画像のように改善してといっても、一部元の状態が残ってしまうのは何が原因ですか？ UIの改善案を聞いたら、いい感じに画像にしてくれたのですが、それを使って画像のようにしてと言っても、一部だけもとの状態のまま更新されてしまいます。 出典: detail.chiebukuro.yahoo.co.jp

この種の相談は、依頼者側がAIで試作したものを持ち込んでくるケースでも起こります。試作の段階で作られたコードが部分的に残っており、どこまでが仕様でどこからが未完成なのか判別できない。この状態で「修正」を依頼されると、作業量の見積もりがまったく立ちません。

対処法は明確です。持ち込まれた既存のコードがある案件では、現状の把握そのものを有償の工程として切り出します。「まず現状の調査と整理を行い、その結果をもとに改修の見積もりを出します」という進め方です。調査を無償で引き受けると、案件全体の採算が最初の段階で崩れます。

AIを使う開発の周辺業務については、AIチャットボット・アプリ開発のお仕事に依頼の傾向が整理されています。関連する領域として、AI・マーケティング・セキュリティのお仕事も、案件の広がりを把握するのに使えます。

揉めてしまったときの対応

線を引き損ねて、無償の修正が延々と続く状態になってしまった場合の話もしておきます。

まず記録を集めます。依頼のやりとり、合意の経緯、実際に行った作業。メールやチャットの履歴がそのまま証拠になります。記録が残っていない口頭のやりとりは、後から主張しても通りにくいので、この機会に文字のやりとりへ移行します。

次に、話し合いの場を持ちます。ここで感情的に「もう無理です」と言うのは避けます。伝えるのは、これまでの対応が当初の合意の範囲を超えていること、今後は範囲を明確にして進めたいこと、その具体的な線引き案です。案を持って行くのが要点です。問題提起だけでは相手も動けません。

それでも解決しない場合、相談先があります。取引上の問題については行政の相談窓口が設けられており、契約書の内容や請求の可否といった法的な判断が必要な段階では弁護士への相談が確実です。※ 金額が大きい案件や、支払いそのものが止まっている場合は、早い段階で専門家に相談してください。時間が経つほど選択肢が減ります。

修正コストを最初の見積もりに織り込む

修正回数を決めることと、その分のコストを見積もりに入れることは別の話です。両方やって初めて成立します。

無償で対応すると決めた範囲にも、当然ながら作業時間はかかります。その時間を見積もりに入れていないと、取り決めどおりに運用しても採算が合いません。「デザイン調整2回まで無償」と書くのであれば、その2回ぶんの時間は最初から見積もりに含まれていなければなりません。

実務では、見積もりの内訳に修正対応の工数を独立した項目として立てる方法があります。項目として見えていると、依頼者も「これは無限に使えるものではない」と理解しやすくなります。逆に、開発工数の中に紛れ込ませて見えなくすると、依頼者からは無償のサービスに見えます。見えないものは、際限なく求められます。

見積もりを削られたときの調整

依頼者から金額を下げてほしいと言われたとき、修正対応の枠を減らすのは有効な調整です。作業の質を落とす、機能を削る、といった調整より、双方にとって痛みが少ない。

「金額を下げるかわりに、デザイン調整の枠を1回にさせてください」と提示すると、依頼者は自分で選べます。選んでもらった結果であれば、後から枠を超えた依頼が来たときにも説明が通ります。一方的に削った条件は、後から必ず蒸し返されます。

見積もりに書かない条件は存在しないのと同じ

打ち合わせで口頭合意した条件を、見積書にも契約書にも書かないまま進めてしまう。これがトラブルの典型です。書いていない条件は、相手の記憶の中にしかありません。記憶は都合よく変わります。悪意がなくても変わります。

打ち合わせの後、その日のうちに合意事項を箇条書きで送る習慣をつけておくと、この問題はほぼ消えます。相手が返信しなくても、送った記録が残ります。異議が出なかった事実そのものが、後の主張の支えになります。

納品後の関係を保守契約に移す

修正対応の期限が来た後、関係が途切れてしまうのはもったいない話です。アプリは公開してからのほうが長く使われます。運用の途中で必ず手を入れる必要が出てきます。

そこで、修正対応の期限が切れるタイミングに合わせて、保守契約の案を出しておきます。内容は、月あたりの対応時間の上限、対象となる作業の範囲、緊急時の連絡手段と対応の目安。この形にしておくと、期限後の依頼が「無償か有償か」の議論ではなく「保守の枠内か枠外か」の議論になります。議論の性質が変わるだけで、やりとりの負担がかなり減ります。

保守契約には、依頼者側にも利点があります。不具合が出たときに、その都度見積もりを取って発注する手間がなくなる。OS の更新やライブラリの変更に伴う対応も、あらかじめ枠に入れておけます。この利点を先に説明しておくと、契約の話が進みやすくなります。

技術的な守備範囲を広げておくと、保守の枠で引き受けられる作業が増えます。ネットワークやインフラ寄りの知識は、アプリの不具合の原因を切り分ける場面で効きます。基礎を体系的に確認する材料としてはCCNA（シスコ技術者認定）の学習範囲が使えます。

記録の残し方を仕組みにする

最後に、記録の話をもう少し具体的に書きます。トラブルになったときに効くのは、後から集めた記録ではなく、日々自然に溜まっている記録です。

やりとりの経路を一本化するのが第一歩です。メール、チャット、電話、対面が混在していると、記録が分散して追えなくなります。「ご依頼はこちらの経路でお願いします」と最初に決めておくと、記録が一箇所に集まります。

電話や対面で受けた依頼は、その日のうちに文字で送り返します。「本日ご相談いただいた内容を確認のため記載します」という形です。相手を疑っているのではなく、認識を揃えるための手順として説明すれば、角も立ちません。

作業の記録も残します。いつ、どの依頼に対して、どのくらいの時間を使ったか。細かい記録は不要で、日付と依頼番号と概要だけで十分です。この記録があると、「無償対応がどれだけ積み上がっているか」を自分でも把握できます。把握できていないものは、交渉の材料にできません。

単発で終わらせないための考え方

修正回数の取り決めは、依頼者を突き放すための道具ではありません。むしろ逆で、長く付き合うための道具です。

範囲が曖昧なまま無償対応を続けると、受け手は疲弊し、いずれ関係が終わります。終わり方も後味の悪いものになります。最初に線を引いておけば、双方が納得した状態で作業を進められ、追加の依頼も気持ちよく受けられます。

働き方の設計という点では、国内の取引だけでなく海外案件を視野に入れる選択肢もあります。契約の考え方や検収の運用は国によって違い、比較して見ると自分の契約の弱点が見えてきます。Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法には、その入口となる進め方がまとめられています。長期的なキャリアの組み立て方についてはWebマーケティング フリーランスで海外ノマド！年収、スキル、成功への道も参考になります。

運営者として見てきた限りでの観察

フリーランスと発注者をつなぐ場を20年運営してきた立場から言えば、修正対応でトラブルになる案件と、ならない案件の差は、開発者の技術力ではありません。最初の1回目の依頼にどう返したか、それだけです。

1回目に何も言わず対応した人は、2回目も言えません。1回目に「これは無償で対応します、これは調整枠の1回目として扱います」と書いて返した人は、10回目でも同じ返し方ができます。最初の返信の形が、その案件の全体を決めています。

もうひとつ、長く仕事が続いている人ほど、線を引くときの言い方が柔らかい。断っているのではなく、整理していることが伝わる書き方をしています。仲介の手数料が乗らない直接の取引では手数料0%で手取りが厚くなりますが、その厚みは無償の修正が積み上がれば簡単に消えます。線を引く技術は、そのまま手取りを守る技術です。法律も契約書も、あなたを守るために存在しています。使わない手はありません。

依頼者のタイプ別に線の引き方を変える

同じ取り決めでも、相手によって効く伝え方が違います。現場で出会う依頼者は、おおよそ3つのタイプに分かれます。

社内に開発の経験者がいる会社は、修正の分類そのものを理解しています。このタイプには、分類の根拠を技術的に説明すれば話が早い。逆に、説明を省いて「これは有償です」とだけ返すと、根拠が見えないぶん不信を招きます。

開発を初めて発注する会社は、そもそも何が普通なのか分かっていません。このタイプには、業界の一般的な進め方から説明します。「実物ができてから直したくなるのは普通のことなので、そのための枠を最初に用意しています」という説明の仕方をすると、安心して枠の中に収まってくれます。

自分でも少し作れる依頼者は、最も判断が難しい相手です。技術の話が通じるぶん、細部への要望が具体的で多くなりやすい。このタイプには、回数の枠より作業時間の枠で合意するほうが噛み合います。「調整には月あたりこの程度の時間を確保しています」という形にすると、要望の粒度を相手が自分で調整してくれます。

相手のタイプを見分ける質問

初回の打ち合わせで、次の3つを聞いておくと相手のタイプがだいたい分かります。過去に開発を外部に発注した経験があるか、社内で最終的に判断するのは誰か、公開した後の運用を誰が担当する予定か。

3つ目の質問は特に有効です。運用の担当者が決まっていない案件は、納品後に修正依頼が長引く傾向があります。決まっていない場合は、その点を早い段階で指摘しておくと、後の負担が減ります。

取り決めを見直す周期を決める

一度決めた修正回数の枠は、案件が進むうちに実態と合わなくなることがあります。想定より仕様が複雑だった、依頼者側の体制が変わった、公開後の反応で優先順位が変わった。事情はさまざまです。

そこで、長期の案件では取り決めを見直す時期を先に決めておきます。工程の区切りや、契約更新のタイミングに合わせるのが自然です。見直す前提があると、途中で無理が出たときに切り出しやすくなります。見直しの機会がないと、無理を抱えたまま最後まで走ることになります。

見直しの場では、消費した回数の実績を持って行きます。どの依頼にどれだけ対応したかの記録があれば、枠が足りているのか多すぎるのかが数字で分かります。感覚で議論すると、双方が違う印象を持ったまま話が進みます。

よくある質問

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

一律の正解はなく、工程ごとに枠を分ける方法が実務的です。デザイン案の段階で数回、実装後の確認で数回といった形にすると、手戻りの重さの違いを反映できます。回数を数えるのが煩雑な案件では、納品後の一定期間を無償対応の枠とし、それ以降は保守契約や都度見積りに切り替える方式もあります。

Q. バグの修正も回数に含めてよいですか？

含めません。仕様や合意した内容と実際の動作が食い違っている場合は、合意した内容を満たしていない状態なので、開発側の責任で無償対応するのが原則です。回数の上限を設けるのは、仕様どおりに動いているうえでの色味や文言といった主観的な調整に対してです。この区別を契約前に説明しておくと後から揉めにくくなります。

Q. 「小さい修正だから無料で」と言われたらどう返せばよいですか？

作業量の大小ではなく、合意した内容の内側か外側かで線を引くと説明が一貫します。量で判断すると、どこまでが小さいかの交渉になり、根拠を失います。返信では項目ごとに分類を書き分け、無償で対応するもの、調整枠を消費するもの、別途見積りが必要なものを明示してください。

Q. 修正依頼を受け付ける期限は決めたほうがよいですか？

決めてください。期限がないと、納品から数か月後の依頼も無償対応の対象と受け取られます。期限を決めるには検収の定義が先に必要で、引き渡し後の一定期間内に検収の可否を連絡してもらい、連絡がない場合は検収完了とみなす、といった取り決めを契約書に入れておきます。

Q. 依頼者が持ち込んだ既存コードの改修はどう見積もればよいですか？

現状の把握そのものを有償の工程として切り出してください。生成AIで試作されたコードなどは、どこまでが仕様でどこからが未完成か判別できず、調査なしに作業量を見積もれません。まず調査と整理を行い、その結果をもとに改修の見積りを出す進め方にすると、採算が崩れにくくなります。