システム開発の途中で、開発会社から追加費用の見積もりが届いた。こちらは「最初から頼んでいたつもり」の機能なのに、開発会社は「当初の仕様には含まれていません」と言う。システム開発の追加費用をめぐるこうした食い違いは、発注者が戸惑いやすい場面の一つです。
「開発途中で追加費用を請求された。仕様の解釈が違っていたらしいけど、これって払わないといけないの？」
先に結論をお伝えします。すぐに払う必要も、すぐに断る必要もありません。まず「それは契約の範囲内か、範囲外の変更か」を、契約書・要件定義書・見積もりの前提条件・議事録と照らし合わせて確認します。そのうえで、判断が分かれる部分は開発会社と選択肢を出し合って協議し、決まったことを書面に残す。この順番で進めれば、感情的な対立を避けながら納得できる結論に近づけます。
この記事では、追加費用が発生する理由、「変更か範囲内か」を見極める手順、協議の進め方、次の案件で繰り返さないための備えを、チェックリストと開発会社への質問例つきで解説します。
短い回答：払うかどうかは「根拠資料」で決まる
追加費用を払うべきかどうかは、「誰の言い分が正しいか」ではなく、双方が合意した資料に何が書かれているかで考えるのが基本です。
- 合意した資料に書かれている、または当然含まれると読める → 範囲内として対応を求める余地がある
- 合意した資料に書かれておらず、後から追加・変更した → 追加費用の対象になりやすい
- 資料の書き方がどちらにも読める → 「解釈の差」として協議して決める
実際には3つ目の「どちらにも読める」ケースがとても多く、ここをどう話し合うかがポイントになります。なお、契約上の最終的な判断は個別の契約書の内容によって変わります。金額が大きい場合や話し合いがまとまらない場合は、弁護士などの専門家に相談してください。
開発途中で追加費用が発生する4つの理由
まず、追加費用がなぜ生まれるのかを押さえておきましょう。多くの場合、開発会社が後から金額を上乗せしようとしているのではなく、見積もりの時点で決まっていたことと、今決まったことの差が費用として表れています。
理由1：仕様の書き方が曖昧で、解釈が分かれた
「顧客一覧を検索できる」と書いてあっても、発注者は「名前・電話番号・住所のどれでも探せる」と考え、開発会社は「名前で探せる」と考えていた、ということは珍しくありません。書かれた言葉は同じでも、頭の中の完成イメージが違っていたのです。
📰 出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」
IPAと経済産業省が公開しているモデル契約書の解説でも、開発の工程でシステム仕様の解釈などについて発注者に確認が必要になる場合があり、開発会社は必要な協力を求めることができ、発注者は適時に応じるという考え方が示されています。解釈の違いは、どちらか一方の落ち度というより、確認のやり取りで埋めていくものだと言えます。
理由2：要件の追加・変更があった
打ち合わせの中で「こういう機能もあると便利」「この画面はこう変えたい」といった要望が加わると、作業量が増えます。口頭の軽いお願いのつもりでも、開発側では設計・実装・テストのやり直しが発生していることがあります。変更そのものの進め方は、システム開発の途中で仕様変更したい！どこまで変えていい？判断の物差しと進め方で詳しく解説しています。
理由3：見積もりの「前提条件」が崩れた
見積書には、「既存データは○件程度」「連携先のシステムは仕様書どおりに動く」「素材は発注者が用意する」といった前提条件が付いていることがよくあります。この前提が実際と違っていた場合、作業量が変わり、再見積もりが必要になることがあります。
IPAのモデル契約書の解説では、前の工程の結果として後の工程の見積もりの前提条件に影響が出た場合に、工程の開始時に改めて見積もることができる「多段階契約」と「再見積り」の考え方を採用しています。また、画面や帳票を決める外部設計（＝画面や操作の仕様を決める工程）を発注者が承認した後の要件追加・仕様変更・未決事項の確定については、変更管理の手続き（＝変更の中身・費用・スケジュールを協議して合意する手順）に沿って、委託料や納期を協議するのが望ましいとしています。
理由4：「後で決める」としていたことが決まった
「帳票のレイアウトは後で決めます」のように、見積もり時点で決まっていなかった事項（未確定事項）が、決まってみたら想定より大がかりだったというケースです。IPAのモデル契約書では、未確定事項がある場合は、その内容・確定予定時期・確定によって費用や納期が変わりうることを、あらかじめ書面で確認しておく仕組みが示されています。
契約の形によって「費用の考え方」も違う
追加費用の考え方は、契約の形によっても変わります。
📰 出典：e-Gov法令検索「民法」
民法では、請負は「仕事を完成すること」を約束し、その仕事の結果に対して報酬を支払う契約とされています（第632条）。一方、準委任（＝作業や事務の処理そのものを委託する契約）は、IPAのモデル契約書の解説によれば、善良な管理者の注意をもって業務を処理する義務を負うものの、仕事の完成までは義務として負わない契約です。
| 契約の形 | 何に対して払うか（一般的な考え方） | 追加費用の出方の傾向 |
|---|---|---|
| 請負 | 決めた仕様どおりの完成物 | 仕様の範囲外の追加・変更が、追加見積もりの対象になりやすい |
| 準委任 | 作業（期間・人数など） | 作業時間や期間が延びた分が、費用の増加として表れやすい |
実際の契約は、この一般論どおりとは限りません。工程ごとに契約の形を分けていることも多いので、まず自社の契約書で「今の工程はどちらの形か」を確認しましょう。
「変更」か「範囲内」かを見極める5ステップ
ここからは、追加見積もりが届いたときに発注者が取る具体的な手順です。
ステップ1：追加費用の中身を分解して説明してもらう
最初にやるべきことは、請求の中身を細かく知ることです。「一式○○円」のままでは判断できません。
- 具体的に何の作業が増えるのか（画面、機能、データ移行など）
- なぜ当初の範囲外と考えているのか（根拠となる資料はどれか）
- 金額の内訳（作業量の見込み）と、納期への影響
「どの資料のどの記載を根拠に『範囲外』と判断したのかを示すのは、私たち開発側の役目です。資料を並べて一緒に確認してもらえると、話が早く進みます」
ステップ2：根拠資料を時系列で並べて照らし合わせる
次に、双方が合意した資料を集め、問題の機能がどう書かれているかを確認します。
| 資料 | 確認するポイント |
|---|---|
| 契約書・個別契約書 | 業務の範囲、契約の形（請負か準委任か）、変更の手続きの定め |
| 見積書 | 項目の内訳、前提条件、「含まれないもの」の記載 |
| 提案書・RFP（＝発注時に渡した依頼書） | 発注者が何を求め、開発会社が何を提案したか |
| 要件定義書・設計書 | 問題の機能の記載と、承認した日付 |
| 議事録・メール・チャット | 口頭で合意したこと、「後で決める」とした事項 |
ポイントは、後から双方で確認・承認した資料も必ず見ることです。見積もり時点では曖昧でも、その後の要件定義書や承認済みの画面イメージで具体的に決まっていれば、それが判断の大きな手がかりになります。IPAのモデル契約書でも、発注者が承認した中間資料（設計の途中の資料）の内容を変えるには変更管理の手続きが必要とされており、承認には一定の重みがあると考えておきましょう。
ステップ3：3つのパターンに仕分ける
照らし合わせた結果を、次の3つに分けてみましょう。
| パターン | 目安 | 基本の進め方 |
|---|---|---|
| 範囲内に近い | 資料に明記されている、または書かれた内容を実現するのに当然必要 | 根拠を示して、範囲内での対応を相談する |
| 変更に近い | 資料になく、承認後に発注者から追加・変更を依頼した | 追加見積もりを前提に、入れるかどうかを判断する |
| グレー | どちらにも読める、または「後で決める」とされていた | 解釈の差として、選択肢を出し合って協議する |
1つの請求の中に複数のパターンが混ざっていることもあります。機能単位に分けて仕分けると、話し合いがかみ合いやすくなります。
ステップ4：グレーの部分は「選択肢」で協議する
グレーの部分は、どちらかが一方的に正しいと言い切れないことがほとんどです。「全額払う」「一切払わない」の二択にせず、次のような選択肢を並べて話し合うのが現実的です。
- 機能を簡易な形にして、追加費用を抑える
- 優先度の低い別の機能と入れ替える
- リリース後の改修（第2弾）に回す
- 解釈の差が生まれた経緯を踏まえて、費用の負担を話し合う
IPAのモデル契約書の解説では、発注者から変更の要望を受けた開発会社は、スケジュールや費用などへの影響を十分に分析して発注者に説明し、本当にその変更を行うべきか慎重に協議する必要があるとされています。影響の説明を求めることは、発注者として遠慮すべきことではありません。なお、このモデル契約書は対等な交渉力を持つ企業どうしの取引を想定したひな型なので、中小企業の案件では考え方の参考として使ってください。
ステップ5：合意した内容を書面に残す
結論が出たら、対応内容・費用・納期への影響を書面（変更の記録票やメールなど）に残し、双方の責任者が確認します。IPAのモデル契約書では、契約内容の変更は書面による変更契約で行うこととし、その理由として口頭での契約変更がトラブルの原因になることを挙げています。具体的な書き方は前述の仕様変更の記事を参考にしてください。
追加費用の話し合いで注意したいこと
- 支払いを保留したまま放置しない：協議が長引くと、開発が止まり納期全体に影響します。IPAのモデル契約書にも、変更の協議がまとまらない間、事情によって開発会社が作業を中断できるという定めがあります
- 「ついでにこれも」を口頭で重ねない：小さな依頼の積み重ねが、後でまとめて追加費用になることがあります
- 発注者側の責任もゼロではない：IPAの解説では、仕様を固める合意をした後に発注者が大量の追加要望を出し、開発が遅れた事案で、発注者側の責任が認められた裁判例も紹介されています
- 担当者どうしで抱え込まない：金額や納期に影響する判断は、社内の決裁者を早めに巻き込みましょう
発注者には業務の内容を明確に伝える役割があり、開発会社にはプロジェクトを管理し、影響を説明する役割があります。どちらか一方が悪いと決めつけず、資料と事実をもとに話すことが、結果的に早い解決につながります。
次の案件で追加費用のトラブルを防ぐ4つの備え
見積もりの前提条件と「含まれないもの」を契約前に確認する
見積書の前提条件は、追加費用の出発点になりやすい部分です。契約前に一つずつ確認し、分からない点は質問しておきましょう。見積もりの読み方はシステム開発の見積もりが3倍違うのはなぜ？相見積もりの正しい比べ方と判断ポイントも参考になります。
「後で決めること」をリストにしておく
未確定の事項は、確定予定の時期と「決まったら費用が変わる可能性がある」ことを、あらかじめ書面で共有しておきます。後から「聞いていない」となるのを防げます。
画面イメージや具体例で完成形をすり合わせる
解釈違いを減らすには、言葉だけでなく、画面イメージや実際のデータの例で確認するのが効果的です。承認するときは「どの場面で・誰が・どう使うか」を思い浮かべながら見ましょう。
変更の手続きを最初に決めておく
「変更の相談は誰から誰へ」「見積もりが出るまでの目安」「承認するのは誰か」を着手前に決めておくと、途中の追加費用も落ち着いて判断できます。
発注者がやることチェックリスト
- ☐ 追加費用の内訳（作業内容・金額・納期への影響）を書面で受け取った
- ☐ 開発会社が「範囲外」と判断した根拠の資料と記載箇所を確認した
- ☐ 契約書で、今の工程の契約の形（請負か準委任か）と変更の手続きを確認した
- ☐ 見積書の前提条件と「含まれないもの」を読み直した
- ☐ 要件定義書・議事録・メールを時系列で並べ、問題の機能の記載を確認した
- ☐ 機能ごとに「範囲内に近い／変更に近い／グレー」に仕分けた
- ☐ グレーの部分について、簡易化・入れ替え・後回しなどの選択肢を用意した
- ☐ 合意した内容を書面に残し、社内の決裁者の承認を得た
開発会社への質問例
打ち合わせでそのまま使える質問です。
- 「今回の追加分を範囲外と判断された根拠は、どの資料のどの記載でしょうか？」
- 「追加費用の内訳と、作業量の見込みを機能ごとに教えていただけますか？」
- 「機能を簡易な形にした場合や、リリース後に回した場合、費用と納期はどう変わりますか？」
- 「この変更を入れた場合、ほかの機能やテスト、納期にどんな影響がありますか？」
- 「今後同じような解釈の違いを防ぐために、確認の進め方で変えたほうがよい点はありますか？」
まとめ：追加費用は「資料で確認し、選択肢で話し合う」
開発途中で追加費用を請求されたときは、次の順番で進めましょう。
- 請求の中身を分解して説明してもらう
- 契約書・見積もりの前提条件・要件定義書・議事録と照らし合わせる
- 「範囲内に近い／変更に近い／グレー」に仕分ける
- グレーの部分は選択肢を出し合って協議する
- 決まったことを書面に残す
追加費用の多くは、どちらかの悪意ではなく、完成イメージのずれや前提の変化から生まれます。資料と事実をもとに落ち着いて話し合えば、開発会社との関係を保ちながら納得できる結論を出しやすくなります。契約の解釈で判断に迷う場合や金額が大きい場合は、早めに弁護士などの専門家へ相談してください。
あわせて読みたい関連記事
