システム開発の仕様変更を無償で頼めるか｜不当な給付内容変更になる線引き 2026

「システム開発の途中で、ちょっとした仕様変更をお願いしたら、追加費用を請求された」。こんなご相談を受けることがあります。予算が限られている個人事業主や中小企業の担当者にとって、仕様変更のたびに費用が発生するのは正直つらいものです。この記事では、システム開発の仕様変更を無償で頼めるのか、どこからが有償になるのかという線引きを、発注者の立場から整理していきます。

システム開発の仕様変更をめぐる現状

まず知っておいていただきたいのは、システム開発において仕様変更はほぼ避けられないという事実です。プロジェクトを進める中で、「やっぱりこの機能も欲しい」「この画面の動きを変えたい」という要望が出てくるのは自然なことで、決して珍しいことではありません。

仕様変更は、システム開発においてほぼ不可避のものです。実際、ある調査によると、システム開発プロジェクトの約80%で当初の仕様から何らかの変更が発生しているとされています。 出典: note.com

この数字を見て、「じゃあ、うちも仕様変更が起きて当然なんだ」と少し安心された方もいるかもしれません。実際、私自身も外注を依頼した経験がありますが、最初にイメージしていたものと、実際に動くシステムを見たときのイメージには必ずと言っていいほどズレが生じます。これは発注者の理解不足というより、システム開発という工程の性質上、避けられないことなのです。

一方で、仕様変更が「無償で当然」と考えてしまうと、開発会社やフリーランスエンジニアとの間で深刻なトラブルに発展します。70%以上のシステム開発プロジェクトで、仕様変更に関する費用の認識違いが何らかの形でトラブルの火種になっているという実務者の声もあります。無償か有償かを感覚で判断せず、契約と法律の観点から整理しておくことが、発注者にとって最大の防御策になります。

近年はフリーランスエンジニアへの直接発注が増えており、代理店や仲介会社を通さない分、コミュニケーションの行き違いが起きやすい傾向もあります。だからこそ、仕様変更の取り扱いについて事前に共通認識を持つことが、これまで以上に重要になっています。

「仕様変更」とは何か。まず定義を整理する

「仕様変更」という言葉は日常的に使われますが、法律的にはきちんとした意味があります。

システム開発プロジェクトでは、一度仕様が合意されたあとも、プロジェクトの途中でユーザーから仕様を変更したり、機能を追加したりするように要望が上がることは珍しくありません。このような、仕様の合意後に、仕様が変更されることを「仕様変更」といい、法的には、当事者間で債務内容を変更するよう合意することであると評価できます。 出典: businesslawyers.jp

つまり、仕様変更とは「一度合意した内容を、両者の合意によって変更すること」です。ここで大切なのは「両者の合意」という部分です。発注者が一方的に「これも追加してほしい」と伝えただけでは、法的な意味での仕様変更が成立したことにはなりません。開発会社やエンジニア側が変更内容を理解し、費用や納期への影響を確認したうえで合意する。このプロセスを経て初めて、正式な仕様変更として扱われます。

仕様変更と「バグ修正」の違い

発注者の方からよくいただく質問に、「これは仕様変更なのか、それとも納品物の不具合(バグ)なのか」というものがあります。この線引きは非常に重要です。

・バグ修正: 最初に合意した仕様どおりに動作していない部分を直すこと。原則として開発側の責任で無償対応 ・仕様変更: 最初に合意した仕様にはなかった内容を新たに追加・変更すること。原則として追加費用が発生

例えば、「会員登録フォームでメールアドレスの重複チェックをする」という仕様が最初の要件定義書に明記されていたのに、実際には重複チェックが機能していなかった場合、これはバグであり無償修正の対象です。一方、「会員登録フォームに電話番号の入力欄を追加してほしい」というのは、最初の仕様になかった内容なので仕様変更にあたり、追加費用が発生する可能性が高くなります。

この違いを理解していないと、「動かないから直して」というつもりで伝えた要望が、実は仕様変更として扱われて追加費用を請求される、というすれ違いが起こります。逆に、発注者側が「これは追加機能だから当然お金がかかる」と思い込んでいたものが、実は最初の要件定義書に含まれていて無償修正の対象だった、というケースもあります。判断に迷ったら、最初に交わした要件定義書や見積書の内容を必ず確認してください。

仕様変更が無償になるケース・有償になるケースの線引き

ここが読者の皆さんが最も知りたい部分だと思います。整理すると、以下のような線引きになります。

無償対応が原則となるケース

・要件定義書や仕様書に明記されていた内容と異なる動作をしている(バグ) ・開発会社・エンジニア側の見積もり漏れや説明不足による誤解が原因 ・軽微な文言修正、ボタンの色や配置など、機能に影響しない微調整(事前に「軽微な修正は無償」と契約書に明記されている場合) ・契約不適合責任の範囲内の不具合(民法上、成果物が契約内容に適合しない場合の修補請求)

有償対応が原則となるケース

・最初の要件定義書になかった新機能の追加 ・データベース構造やシステムの根幹に関わる仕様の変更 ・すでに完成した機能を別の仕様に作り直す(手戻り作業) ・当初想定していなかった外部サービスとの連携追加 ・スケジュールの大幅な変更を伴う要望

ここで注意していただきたいのは、「無償が原則」と書いたケースであっても、契約書に別段の定めがあれば、その内容が優先されるという点です。特に契約不適合責任については、民法上、発注者が不適合を知った時から1年以内に通知しないと権利を失うという期間制限があるため、納品後の確認は早めに行うことが重要です。

無償の名目で不当な追加作業をさせてしまうリスク

発注者側にとって見落としがちなのが、「無償でお願いできるなら、できるだけ多く頼んでおこう」という発想がリスクを生む、という点です。

他方で、ユーザーとの関係性を壊したくないというベンダーの現場担当者の思いもあり、費用について曖昧なままにして、サービスとして無償で追加作業を行ってしまい、ユーザー側がこの作業は無償であると信頼をしてしまうようなケースであれば、追加費用請求ができなくなる可能性が高くなります。プロジェクトの進行状況により、個別の機能について、ユーザーと事前に協議をすることが困難であれば、「仕様変更にあたるか否かの判定を経て、別途費用について精算させていただきます」というような文言を差し入れることでも、後のトラブル時には一定の効果は見込めます。 出典: businesslawyers.jp

この指摘は開発会社側の視点で書かれたものですが、発注者にとっても重要な学びがあります。それは、「無償でやってもらえた」という一度きりの成功体験が、その後の関係性を歪めてしまうリスクがあるということです。

開発会社やフリーランスエンジニアが好意で無償対応してくれたことに甘えて、次から次へと追加要望を重ねると、相手は疲弊し、モチベーションが下がります。結果として、納期の遅延や品質の低下という形で、発注者自身に跳ね返ってくることも珍しくありません。長く良い関係を築きたいのであれば、無償で対応してもらった分は、次の機会に別の形で配慮を示す、あるいは適切な追加費用を支払う姿勢を持つことが、結果的に発注者自身の利益になります。

不当な給付内容変更にならないための注意点

「不当な給付内容変更」という言葉は聞き慣れないかもしれませんが、これは発注者が優越的な立場を利用して、一方的に不利な条件変更を強いることを指す考え方です。下請法(下請代金支払遅延等防止法)が適用される取引においては、発注者が費用を負担せずに給付内容を変更させることは、違反行為として問題になる可能性があります。

中小企業庁や公正取引委員会は、下請取引における適正化を強く求めており、資本金の要件などに該当する取引では、発注者側に厳格な義務が課されています。

・書面での発注内容の交付義務 ・発注内容を変更する場合の費用負担の明確化 ・受注者の責任によらない給付内容の変更・やり直しは発注者が費用を負担する義務

フリーランスエンジニアや小規模な開発会社に業務委託する場合、下請法の直接の適用対象にならないケースもありますが、令和6年に成立したフリーランス保護新法(特定受託事業者に係る取引の適正化等に関する法律)により、フリーランスへの業務委託全般で、書面等による取引条件の明示や、報酬支払いのルールが定められました。発注者側は、「相手がフリーランスだから曖昧な口約束でもいい」という発想自体が、法的リスクを伴う時代になっていることを理解しておく必要があります。

無償を前提に一方的に仕様変更を要求する行為は、単なるマナー違反にとどまらず、法令上の問題に発展する可能性がある。この認識を持っておくことが、発注者自身を守ることにもつながります。

トラブルを防ぐための契約書・見積書の作り方

仕様変更トラブルの多くは、契約の入り口で防げます。ここでは発注者として押さえておきたいポイントを紹介します。

ポイント1: 要件定義書をできる限り具体的にする

「ECサイトを作ってほしい」という抽象的な依頼ではなく、「商品一覧ページ、カート機能、決済機能(クレジットカード対応)、会員登録機能」というように、機能を一つひとつ書き出しておくことが重要です。要件定義が曖昧なほど、後から「これも含まれていると思っていた」という認識のズレが生じやすくなります。

ポイント2: 見積書に「含まれる作業範囲」を明記してもらう

見積書を受け取ったら、金額だけでなく、その金額にどこまでの作業が含まれているかを必ず確認してください。「デザイン修正は2回まで無料、それ以降は1回あたり1万円」のように、無償対応の回数や範囲を数値で明記してもらうと、後々のトラブルを大きく減らせます。

ポイント3: 仕様変更が発生した場合のルールを契約書に盛り込む

・仕様変更の申し出は書面(メールやチャットの文面でも可)で行う ・変更内容によって費用・納期にどう影響するかを、開発側が見積もりを提示してから作業に着手する ・軽微な変更(文言修正など)は無償の範囲とする、といった線引きをあらかじめ合意しておく

こうしたルールを最初に決めておくことで、「言った・言わない」の水掛け論を防げます。口頭でのやり取りだけで進めてしまうと、後から証拠がなく、発注者・受注者どちらにとっても不利益になりかねません。

ポイント4: 予備費・変更対応費をあらかじめ予算に組み込む

これは発注者側の心構えの話ですが、システム開発の総予算のうち10%から20%程度を、仕様変更対応の予備費として確保しておくことをおすすめします。仕様変更が発生すること自体は前述のとおり避けられない現象であり、「一切追加費用は払わない」というスタンスでは、結果的にプロジェクトが停滞したり、品質の低い妥協案で進めざるを得なくなったりするリスクがあります。

仕様変更の費用相場はどれくらいか

仕様変更の費用は、変更内容の規模によって大きく異なります。おおまかな目安は以下のとおりです。

・軽微な変更(文言・色・配置の調整): 無償〜数千円程度 ・中規模な変更(既存機能の仕様変更、画面の追加): 3万円〜15万円程度 ・大規模な変更(データベース構造の変更、新機能の大幅追加): 20万円以上、場合によっては再見積もりが必要

エンジニアの単価は経験や専門性によって幅があり、時間単価で3,000円から1万円程度が一般的なレンジとされています。仕様変更にかかる時間を単価に掛け合わせて見積もりが算出されるのが基本の考え方です。「なぜこの金額なのか」がわからないときは、遠慮せずに作業内訳を尋ねてみてください。誠実な開発会社やエンジニアであれば、内訳を丁寧に説明してくれるはずです。

発注先の選び方も、仕様変更トラブルの予防につながる

ここまで契約や法律の話をしてきましたが、実はもっと根本的な予防策があります。それは「発注先の選び方」そのものです。

代理店や制作会社を経由すると、仕様変更のたびに複数の担当者を介してやり取りが行われ、伝言ゲームのようになって認識のズレが起きやすくなります。加えて、代理店経由の場合は中間マージンが上乗せされる分、同じ予算でも実際に開発に使える金額が目減りしてしまいます。

一方、フリーランスのエンジニアに直接依頼すれば、仲介コストがかからないぶん、同じ予算でもより多くの開発時間を確保できたり、仕様変更対応にも柔軟に応じてもらいやすくなったりします。中間業者を挟まないことで、要望が直接エンジニアに伝わり、認識のズレそのものが起きにくくなるという副次的なメリットもあります。

もちろん、直接契約には「誰に頼めばいいかわからない」という不安がつきものです。ここで役立つのが、システム開発を専門とするフリーランスの実績やスキルを確認できる仕組みです。Web・業務システム開発のお仕事では、業務システムやWebアプリケーション開発を依頼できるフリーランスエンジニアの探し方や、依頼時に確認すべきポイントがまとめられています。また、AIを活用したシステムの構築や、セキュリティ面での相談を検討している場合は、AI・マーケティング・セキュリティのお仕事も参考になります。

システム開発を外注する際の全体の流れそのものに不安がある方は、システム開発を外注する方法｜失敗しない発注の進め方【2026年版】で、発注の準備段階から納品後のフォローまでを詳しく解説していますので、あわせて確認しておくと安心です。

発注者としての私の失敗談

正直に告白すると、私自身、フリーランスとして独立してオンラインカウンセリングサービスの予約システムを外注した際、仕様変更で苦い思いをした経験があります。

最初に依頼したのは、格安を売りにしていた制作会社でした。見積もりの安さに惹かれて契約したのですが、契約書には「基本機能一式」としか書かれておらず、具体的にどこまでの機能が含まれるのか、私自身もきちんと確認していませんでした。開発が進む中で、「予約のキャンセル機能も当然含まれていると思っていた」と伝えたところ、「それは別料金です」と言われ、想定外の追加費用が発生してしまったのです。

今振り返れば、安さだけで発注先を決めてしまい、要件定義を曖昧なまま進めてしまった私自身の準備不足が招いた結果でした。この経験から学んだのは、金額の比較だけでなく、「何が含まれていて、何が含まれていないか」を契約前に徹底的に確認することの大切さです。それ以降は、複数のエンジニアから見積もりを取り、作業範囲を書面で明確にしてもらうようにしています。この一手間を惜しまないことが、結果的に無用なトラブルと出費を防いでくれると実感しています。

20年の市場観察から見える、仕様変更トラブルの本質

フリーランス・在宅ワーク市場を長年見てきた運営者の立場から言えば、仕様変更をめぐるトラブルの多くは、「お金の話をタブー視する」日本的な商習慣に根があるように感じます。契約の最初の段階で費用について踏み込んだ話をすることを、なんとなく気まずいと感じてしまう発注者は少なくありません。

しかし、長く良い関係を築いているエンジニアと発注者のペアを見ていると、共通しているのは「お金の話を早い段階で、率直にしている」という点です。仕様変更が発生したときに、「これは追加費用がかかりますか」「かかるとすればどれくらいですか」と、発注者側から先に確認する。この一言があるかないかで、その後の信頼関係の築かれ方が大きく変わります。

もう一つ、運営者として見てきた実感があります。中間マージンが乗らない直接取引では、発注者は同じ予算でより多くの相談や調整を依頼でき、受け手であるエンジニアも中抜きされない分、対応にかけられる時間や熱量に余裕が生まれます。これは金額の大小の問題ではなく、「双方にとって手取りが厚くなる」という質の違いです。手数料0%で直接つながる仕組みは、単に安く済むという以上に、仕様変更のような細やかなやり取りが必要な場面でこそ、その良さが発揮されると感じています。

エンジニアのスキルや実績を見極める際は、実際の年収や単価の相場観を知っておくことも判断材料になります。ソフトウェア作成者の年収・単価相場では、システム開発に携わるフリーランスエンジニアのおおよその収入水準がまとめられており、見積もり金額が適正な範囲かどうかを判断する目安として役立ちます。

仕様変更対応がスムーズなエンジニアの見極め方

最後に、これから発注先を探す方に向けて、仕様変更への対応力という観点から、良いエンジニアを見極めるポイントをお伝えします。

・見積もり時点で、想定される仕様変更のパターンと概算費用を提示してくれるか ・「無償です」と即答するのではなく、内容を確認したうえで丁寧に説明してくれるか ・進行中のタスク管理ツールやチャットで、やり取りの履歴が残る形でコミュニケーションを取ってくれるか ・過去の類似プロジェクトでの仕様変更対応の実例を、具体的に話せるか

こうした姿勢を持つエンジニアは、仕様変更が発生した際にも、感情的な対立ではなく、建設的な話し合いで解決に導いてくれる可能性が高いといえます。逆に、「その場のノリ」で無償対応を約束してしまうタイプのエンジニアは、一見親切に見えても、後々「思っていたのと違う」というトラブルに発展しやすい傾向があります。

システム開発は一度きりの取引で終わることは少なく、運用・保守を含めて長期的な関係になるケースがほとんどです。目先の見積もり額の安さだけでなく、仕様変更というプロジェクト特有の不確実性にどう向き合ってくれるか、という視点で発注先を選ぶことをおすすめします。

作曲・編曲などクリエイティブ分野も含め、フリーランスへの直接発注全般に共通する考え方として、作曲・編曲・効果音・ジングルのお仕事のような専門分野別のガイドも、依頼前の相場観をつかむ参考になります。また、発注する側の担当者としての実務スキルを底上げしたい場合は、著述家，記者，編集者の年収・単価相場のように、関連する職種の相場情報を横断的に確認しておくと、外注先とのコミュニケーションにも自信が持てるようになります。

仕様変更は、システム開発という営みの中で自然に起きる出来事です。それを「無償か有償か」の二択で捉えるのではなく、最初にルールを決め、必要なコミュニケーションを重ねながら進めていく。この姿勢こそが、発注者にとって最も安心できるプロジェクトの進め方だと、私は考えています。

なお、関連テーマを扱った取適法の不当な給付内容の変更禁止｜追加作業を無償で求めない発注設計 2026もあわせて参考にしてください。

よくある質問

Q. システム開発の仕様変更は必ず有償になりますか？

必ずしも有償にはなりません。開発側の見積もり漏れや、契約書に明記されていた内容との相違(バグ)は原則無償対応の対象です。ただし新機能の追加など、当初の要件定義になかった内容は有償になるのが一般的です。

Q. 仕様変更とバグ修正はどう見分ければいいですか？

最初に合意した要件定義書や見積書を確認してください。合意した内容どおりに動いていない場合はバグで無償修正の対象、合意していなかった内容を新たに求める場合は仕様変更として有償になる可能性が高いです。

Q. 仕様変更トラブルを避けるために発注者が最初にすべきことは？

要件定義をできるだけ具体的に書き出し、見積書に含まれる作業範囲を明記してもらうことです。あわせて、仕様変更が発生した場合の費用負担ルールを契約書に盛り込んでおくと、後々の認識違いを防げます。

Q. 代理店経由とフリーランス直接発注では、仕様変更対応に違いがありますか？

代理店経由は複数担当者を介するため伝達のズレが起きやすく、中間マージン分コストも高くなりがちです。フリーランスへの直接発注は仲介コストがかからず、要望が直接伝わるため、仕様変更にも柔軟に対応してもらいやすい傾向があります。