請負契約のシステム開発で追加費用を請求された｜法的に支払う必要はある？

「追加費用が発生します」——請負契約なのに、なぜ？

「最初に○○万円で請負契約を結んだはずなのに、開発会社から『追加費用が発生します』と言われました。これ、支払わないといけないんでしょうか？」

中小工務店・設計事務所の経営者から、こうした相談が後を絶ちません。施工管理システム、原価管理システム、顧客管理ツール——DX推進の流れに乗ってシステム開発を発注したものの、開発途中で思いもよらない追加費用の請求書が届く。

典型的なのは、こんなパターンです。

「要件定義で決めた範囲より作業が増えたので、追加で200万円です」
「当初想定していなかった機能が必要になったので、別途見積もりになります」
「テスト工程で不具合が多発し、修正対応に追加工数がかかりました」
「サーバー環境の構築は契約範囲外なので、追加費用をいただきます」
「お客様側の仕様確認が遅れたため、スケジュール延伸に伴う追加費用が発生します」

請負契約とは**「最初に決めた金額で、決めたものを完成させる契約」**のはず。なのに追加費用を請求されるのは、そもそもおかしくないのか？支払いを拒否したら、開発がストップしてしまうのか？かといって言われるがまま払えば、当初の予算計画が崩壊する——。

この記事では、請負契約における追加費用請求の法的根拠を整理し、「支払うべきケース」と「拒否できるケース」を明確に区別します。 中小工務店・設計事務所の経営者が、DX投資で不当な追加費用に泣き寝入りしないための実践知識をお伝えします。

「契約書にサインしたのは自分だけど、こんなはずじゃなかった」——よくある話です

この悩み、あなただけのものではありません。

実は、システム開発における追加費用トラブルは業界全体で最も多い紛争類型のひとつです。独立行政法人情報処理推進機構（IPA）が公表している「IT紛争事例」でも、請負契約における追加費用・追加作業の範囲をめぐるトラブルは繰り返し取り上げられています。

特に中小工務店・設計事務所のように、IT発注の経験が少ない組織では、次のような構造的な不利を抱えています。

「紙の台帳やExcelで回してきた業務をシステム化したい。でも、何をどう発注すればいいかわからない。だからベンダーに任せるしかない。ベンダーが出してきた契約書や見積もりの妥当性を判断する術がない」

建設業の感覚で言い換えれば、「施主が建築のことを何も知らない状態で、工務店の言い値で請負契約を結ぶ」ようなものです。工事が始まってから「この部分は別途です」と言われたら、施主は困りますよね。しかも建築なら「追加工事は事前に書面で合意」という業界慣行がありますが、IT業界では口頭ベースのやりとりで追加作業が発生し、後から請求書が届くケースが少なくないのです。

だからこそ、「追加費用を請求されたとき、法的にどう判断すればいいのか」という知識を事前に持っておくことが、DX投資を成功させる鍵になります。

結論：請負契約の追加費用には「払うべきもの」と「払わなくていいもの」がある

結論から言えば、請負契約で追加費用を請求されたとき、法的に支払い義務があるかどうかは「追加作業が当初の契約範囲に含まれるか否か」で決まります。

契約範囲内の作業であれば → 追加費用の支払い義務はない（請負契約の性質上、当初の報酬に含まれる）
契約範囲外の作業であれば → 追加の合意がなければ支払い義務はないが、合意があれば支払い義務が生じる
発注者側の原因で追加作業が発生した場合 → 状況により支払い義務が生じうる

つまり、**「追加費用が正当か不当かは、契約書に何が書いてあるかで決まる」**のです。

この記事を読み終えれば、あなたは——

請負契約における追加費用の法的根拠を正確に理解できます
「この追加費用は払うべきか？」を自分で判断するためのチェックポイントを身につけられます
開発会社との交渉で使える具体的なフレーズと対処法を知ることができます
そもそも追加費用トラブルを予防するための契約書設計のポイントを把握できます
万が一トラブルになった場合の法的な対応手段を理解できます

追加費用の法的判断フロー

請負契約の追加費用を法的に徹底分析——支払うべきケースと拒否できるケース

大前提：請負契約とは「完成義務」を負う契約である

まず、請負契約の法的な性質を正確に押さえましょう。

民法第632条は、請負契約を次のように定義しています。

請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。

ここで重要なのは2つのポイントです。

請負人（開発会社）は「仕事の完成」を約束している——つまり、完成させる義務がある
報酬は「仕事の結果に対して」支払われる——つまり、途中の作業量ではなく完成した結果に対する対価

この原則に従えば、請負契約で合意した仕事を完成させるために必要な作業は、すべて当初の報酬に含まれるはずです。途中で「思ったより作業量が増えた」としても、それは請負人側のリスクです。

建設業に例えれば、「住宅を2,000万円で建てます」と請負契約を結んだ工務店が、工事の途中で「基礎工事が想定より大変だったので追加で300万円ください」とは言えないのと同じです。地盤調査を怠ったのは工務店の責任であり、施主に追加費用を転嫁することはできません。

では、なぜ追加費用が発生するのか？——4つのパターン

「請負契約なのに追加費用が発生する」には、法的に4つのパターンがあります。それぞれ支払い義務の有無が異なります。

パターン1：発注者が仕様変更を依頼した場合（支払い義務あり）

最も正当な追加費用パターンです。

当初の契約で合意した仕様（成果物の内容）を、発注者側の都合で変更した場合、その変更によって増加した作業に対する追加費用は正当です。

民法第634条の2（注文者による契約の変更）の趣旨からも、仕様変更は新たな合意（変更契約）として処理されるべきとされています。

ただし重要なのは、「仕様変更であることの合意」と「追加費用の合意」が事前に成立していることです。

発注者が仕様変更を依頼し、開発会社が追加見積もりを提示し、発注者がそれを承認した → 支払い義務あり
開発会社が勝手に仕様を拡張し、後から「仕様変更扱い」として追加費用を請求した → 支払い義務なし

建設業の感覚では当然のことですよね。施主が「やっぱり窓を大きくしてほしい」と言えば追加費用がかかるのは当然。しかし、工務店が勝手に窓を大きくして「追加費用です」とは言えません。

パターン2：契約範囲の解釈が曖昧だった場合（ケースバイケース）

最も紛争になりやすいパターンです。

契約書や要件定義書の記載が曖昧で、「この作業は契約範囲に含まれるのか、含まれないのか」が不明確な場合、開発会社は「範囲外だから追加費用」と主張し、発注者は「当然含まれていると思っていた」と主張します。

この場合、法的には以下の要素を総合的に判断します。

契約書の文言：具体的にどの範囲の作業が記載されているか
要件定義書・仕様書の内容：成果物として何が合意されていたか
見積書の明細：何の作業に対して費用が計上されていたか
打ち合わせ議事録：口頭でどのような合意がなされていたか
業界慣行：同種のシステム開発で通常含まれる作業範囲
信義則（民法第1条第2項）：契約当事者が社会通念上期待する範囲

**実務上は、「契約書に明記されていない作業は、請負人の義務に含まれるとは限らない」**という判断がなされることが多いです。つまり、契約書が曖昧であるほど、発注者に不利に働く傾向があるのです。

ここに、IT発注経験の少ない中小工務店・設計事務所の構造的な弱さが表れます。建設業では「基礎工事」「躯体工事」「内装工事」「電気工事」といった工種が業界標準として確立しており、何がどこまで含まれるかが比較的明確です。しかし、システム開発では「要件定義」「設計」「開発」「テスト」「移行」といった工程の境界が曖昧で、同じ「テスト」でも単体テスト・結合テスト・ユーザー受入テスト・負荷テストなど多岐にわたります。

パターン3：開発会社の見積もりミスや技術力不足が原因の場合（支払い義務なし）

開発会社の見積もりが甘かった、技術的な見通しが甘かった、プロジェクト管理が不適切だった——これらの理由で追加作業が発生した場合、その費用を発注者に転嫁することは法的に認められません。

請負契約において、仕事を完成させるためのリスクは請負人が負うのが原則です。これは民法第632条の「仕事の完成を約す」という文言から導かれる当然の帰結です。

具体的には——

「当初の技術選定が誤りで、作り直しが必要になった」 → 開発会社の責任。追加費用は請求不可
「見積もり段階で工数を少なく見積もりすぎた」 → 開発会社の責任。追加費用は請求不可
「プロジェクトマネジメントの不備で手戻りが発生した」 → 開発会社の責任。追加費用は請求不可
「テストで大量のバグが発覚し、修正工数がかかった」 → 開発会社の責任。追加費用は請求不可

建設業で言えば、「工期の見積もりを甘く見て人手が足りなくなった」からといって、施主に追加費用を請求する工務店がいたら、信用を失いますよね。IT業界でもロジックは同じです。

パターン4：発注者側の協力義務違反が原因の場合（支払い義務が生じうる）

見落としがちなのが、発注者にも「協力義務」があるという点です。

システム開発の請負契約では、発注者は単に「お金を払って待っていればいい」わけではありません。仕様の確認、テストデータの提供、業務フローのヒアリングへの対応、検収の実施など、発注者側がタイムリーに協力しなければ、開発は進みません。

発注者の協力義務違反によって追加作業が発生した場合、以下のような追加費用は法的に正当とされる可能性があります。

発注者が仕様確認を大幅に遅延させ、それによる手待ち期間のコスト
発注者が提供すべきデータを提供せず、開発会社がデータ整備を代行した場合のコスト
発注者が検収を長期間放置し、その間のプロジェクト維持コスト
発注者の担当者が頻繁に変わり、意思決定のやり直しが発生した場合のコスト

建設業で考えれば、施主が「設計図面の承認を3ヶ月放置」したら、工期が延び、その間の仮設費用や現場管理費が追加になるのは当然です。システム開発でも同じことが起きます。

追加費用を請求されたときの実践的な対応フロー

では、実際に追加費用を請求されたとき、どのように対応すればよいのかを具体的に解説します。

ステップ1：まず、感情的に反応しない

追加費用の請求書を受け取ると、「話が違う」と怒りを感じるのは自然です。しかし、感情的に拒否したり、逆に言われるまま支払ったりするのは最悪の対応です。まずは冷静に状況を整理しましょう。

ステップ2：契約書を読み返す

追加費用の請求内容が、当初の契約書・要件定義書・仕様書に記載された範囲に含まれるかどうかを確認します。契約書に「○○機能の開発を含む」と明記されている作業について追加費用を請求されたのなら、それは明らかに不当です。

ステップ3：追加費用の根拠を書面で求める

開発会社に対し、追加費用の**「根拠」「作業内容」「工数の内訳」を書面で提出するよう求めます**。口頭での説明だけで済ませようとする開発会社は、根拠が弱いことを自覚している可能性があります。

ステップ4：4つのパターンに当てはめて判断する

上述の4パターンのどれに該当するかを判断します。

パターン1（発注者の仕様変更）に該当するなら → 変更合意の有無を確認し、合意があれば支払い、なければ交渉
パターン2（契約範囲の曖昧さ）に該当するなら → 契約書・議事録等の証拠を整理し、交渉
パターン3（開発会社のミス）に該当するなら → 支払い拒否が妥当
パターン4（発注者の協力義務違反）に該当するなら → 自社側にも責任がある可能性を認め、協議

ステップ5：交渉の記録をすべて書面で残す

電話やオンライン会議で話し合った内容も、必ず議事録やメールで確認書を送り、書面化してください。「言った・言わない」問題は、システム開発トラブルの最大の敵です。

追加費用トラブルを「予防」する契約書設計の5つの鉄則

追加費用トラブルは、「起きてから対処する」よりも「起きないように契約書を設計する」方が圧倒的にコストが低いです。以下の5つの鉄則を契約段階で押さえてください。

鉄則1：成果物の範囲を具体的に定義する

「システム一式」「業務に必要な機能」のような曖昧な表現ではなく、機能一覧表・画面一覧表・帳票一覧表を契約書の別紙として添付し、「この範囲を請負金額に含む」と明記してください。

鉄則2：追加作業の発生条件と承認プロセスを明記する

「契約範囲外の作業が必要になった場合は、事前に書面で変更提案書を提出し、発注者の書面承認を得た場合にのみ追加作業を行う」——この一文があるだけで、一方的な追加費用請求を防止できます。

鉄則3：見積もり前提条件を契約書に添付する

開発会社の見積もりには、必ず**「前提条件」があります。「データ移行は既存システムからCSV出力できることを前提とする」「テスト環境は発注者が用意する」など。この前提条件を契約書の別紙として添付し、双方で合意**しておくことで、「前提が崩れたから追加費用」という主張の妥当性を事前に確認できます。

鉄則4：変更管理ルールを契約書に組み込む

仕様変更が発生した場合の**「変更依頼→影響分析→見積もり提示→承認→実施」というプロセス**を契約書に明記してください。建設業では「追加工事は事前に書面で合意」が当たり前ですが、IT業界ではこの当たり前が当たり前になっていないことが多いのです。

鉄則5：紛争解決条項を入れる

万が一トラブルになった場合の**解決手段（協議→調停→裁判、または協議→仲裁）**を契約書に明記してください。IT紛争に詳しい弁護士や、ソフトウェア紛争に対応できるADR（裁判外紛争解決手続）機関の利用を想定しておくと安心です。

中小工務店・設計事務所が特に注意すべきポイント

中小工務店・設計事務所がシステム開発を発注する場面には、他の業界にはない特有の落とし穴があります。

「建設業の請負契約の感覚」で「IT開発の請負契約」を理解すると、ズレが生じるのです。

建設業では——

成果物が物理的に目に見える（建物・構造物）
工種ごとの業界標準単価が存在する
設計図書で成果物が明確に定義される
追加工事は現場で目に見えるため、認識のズレが起きにくい

しかしIT開発では——

成果物はコードやデータであり、目に見えにくい
業界標準単価がなく、同じ機能でもベンダーによって数倍の価格差がある
要件定義書は設計図書ほど厳密でないことが多く、解釈の余地が大きい
追加作業が「画面上」で起きるため、発注者が気づきにくい

この構造的な違いを理解しないまま、建設業と同じ感覚で契約すると、「完成するまで中身がわからず、追加費用の妥当性も判断できない」という状況に陥りやすいのです。

だからこそ、紙とExcelに頼った業務からの脱却、属人化した見積もり作成の効率化、現場と事務所の情報共有といったDX案件を進める際には、建設業の実務とITの両方を理解している専門家のサポートが重要になります。アトリエ・バイナリ（atelier binary）では、こうした中小工務店・設計事務所特有の「レガシーな悩み」を熟知した上で、契約書レビューから要件定義の伴走、ベンダーとの交渉支援まで、発注者の立場に立ったコンサルティングを提供しています。「追加費用を請求されたけど妥当なのかわからない」「そもそも契約書のどこを見ればいいかわからない」という段階からでも相談できるのが強みです。

追加費用トラブル予防の5つの鉄則

追加費用トラブルが発生した場合の法的手段

交渉で解決しない場合、以下の法的手段があることも知っておきましょう。

手段1：内容証明郵便の送付

開発会社に対し、追加費用の支払いを拒否する旨、およびその法的根拠を内容証明郵便で通知します。法的拘束力はありませんが、「こちらは法的手段も辞さない」という意思表示になり、交渉を動かす効果があります。

手段2：ADR（裁判外紛争解決手続）の利用

IT紛争に特化したADR機関として、**「ソフトウェア紛争解決センター」**があります。裁判より迅速・低コストで、IT業界の専門家が調停にあたるため、技術的な争点がある場合に特に有効です。

手段3：民事調停

簡易裁判所で行う調停手続です。費用が低廉で、話し合いベースの解決が図られます。IT紛争でも利用可能です。

手段4：訴訟

最終手段として民事訴訟があります。請負契約に関するIT紛争では、東京地裁・大阪地裁に専門部（IT関連紛争を集中的に扱う部署）が設けられているため、専門的な判断が期待できます。ただし、時間とコストがかかるため、争点の金額と訴訟コストのバランスを考慮する必要があります。

判例から学ぶ——裁判所はどう判断しているか

参考として、IT開発の追加費用に関する裁判所の判断傾向を紹介します。

傾向1：契約書に明記されていない作業は、安易に請負範囲に含まれるとは認定しない

裁判所は、**「契約書に書かれていない作業を請負範囲に含めるには、それなりの根拠が必要」**と判断する傾向にあります。つまり、「当然含まれていると思っていた」という発注者の主観的な期待だけでは、法的な主張としては弱いのです。これは発注者にとって不利に働く場面がありますので、契約書で範囲を明確にしておくことの重要性を裏付けています。

傾向2：発注者の協力義務違反があった場合、追加費用の一部を認めることがある

発注者側の遅延や非協力が原因で追加コストが発生した場合、裁判所は開発会社側の追加費用請求を一部認容することがあります。特に、仕様確認の遅延や、発注者側の意思決定の頻繁な変更が原因となっているケースでは、応分の負担を求められることがあります。

傾向3：開発会社のプロとしての説明義務を重視する

一方で裁判所は、開発会社には「ITの専門家として発注者に適切に説明する義務」があると判断する傾向にあります。追加費用が発生する可能性があるなら、事前に発注者に説明し、書面で合意を得るべきという考え方です。この説明義務を怠った場合、追加費用の請求が認められないこともあります。

こんな方に今すぐ読んでほしい

請負契約でシステム開発を発注中に、追加費用を請求されて困っている方
追加費用の請求が正当なのか不当なのか、判断基準がわからない方
これからシステム開発を発注する予定で、追加費用トラブルを予防したい方
過去にシステム開発で「言った・言わない」のトラブルを経験した方
DXを推進したいが、ITベンダーとの契約に不安を感じている中小工務店・設計事務所の経営者
紙とExcelに頼った業務を脱却したいが、システム投資で損をしたくない方

追加費用のトラブルは、発生してからでは選択肢が限られます。最も効果的なのは、契約段階で「追加費用が発生しにくい契約書」を設計することです。しかし、それにはIT発注と契約法務の両方の知識が必要であり、IT発注経験の少ない中小企業が独力で対応するのは困難です。

「建設業のことはわかるけど、ITのことはわからない」——その正直な自覚こそが、正しい判断への第一歩です。 わからないことを認め、専門家の力を借りることが、結果的に最も安く・最も確実にDXを成功させる道です。

まとめ

請負契約のシステム開発で追加費用を請求されたとき、法的に支払い義務があるかどうかは「契約範囲」と「追加作業の原因」で決まります。

本記事のポイントを整理します。

請負契約の原則は「合意した金額で完成させる」——契約範囲内の作業について追加費用は発生しない
追加費用が正当なのは「発注者の仕様変更」と「発注者の協力義務違反」のケース——ただし事前の書面合意が必要
開発会社の見積もりミスや技術力不足が原因なら、追加費用の支払い義務はない——完成リスクは請負人が負う
契約範囲の曖昧さが最大のリスク——「当然含まれると思っていた」は法的に弱い主張
予防が最善の対策——契約書に成果物の範囲・変更管理ルール・追加作業の承認プロセスを明記する
交渉は書面ベースで、4つのパターンに当てはめて判断する——感情的な対応は禁物
法的手段はADR→調停→訴訟の順で検討する——コストと効果のバランスを見極める

中小工務店・設計事務所にとって、DX投資は避けて通れない経営課題です。しかし、IT発注の経験不足から不利な契約を結んでしまい、追加費用で予算が膨らむケースは後を絶ちません。「建設業の請負感覚」と「IT開発の請負契約」のギャップを正しく理解し、契約書で自社を守る——この知識があるだけで、DX投資の成功確率は格段に上がります。

追加費用を請求されて困っている方、これから契約を結ぶ方は、まず契約書を手元に置いて、本記事のチェックポイントを一つずつ確認してみてください。それだけでも、「払うべきか、拒否すべきか」の判断材料が明確になるはずです。