システム開発の追加費用が増える7つの条件｜対象外・仕様変更・再見積もりの見方

システム開発の追加費用は、多くの場合「トラブルが起きたから発生した」のではありません。契約書と見積書に書かれていない条件が、そのまま増額の請求根拠になるという構造から発生しています。だから、増額の連絡を受けてから原因を探すより、発注前に「どの条件が埋まっていないか」を見るほうが早く、確実です。

この記事は、受け取った1社の見積書と契約書を前提に、開発費が後から増える条件を7つに分けて整理します。相場のレンジを示すのではなく、どの行を見て、ベンダーへ何を質問すればいいかを提供することが目的です。

なお表記について、条文の引用・要約では原典に合わせて「発注者（甲）」「受注者（乙）」、記事の説明では「発注側」「ベンダー」と書きます。

この記事の結論｜増額は事故ではなく、埋まっていない条件から起きる

追加費用をめぐる話がこじれるのは、たいてい「高いか安いか」を先に議論してしまうからです。金額の議論は、範囲と手続きが決まったあとにしか成立しません。順序を逆にしないでください。

まず、増額を4つの状態に仕分ける

提示された増額を「妥当／不当」の2択で見ないでください。実務で使えるのは次の4状態です。この記事の判定はすべてこの4つに落とします。

「高リスク」と「判断不能」の違いは、条件が抜けているだけなのか、判定の土台そのものが無いのかです。たとえば当初の見積もりが「一式」でまとめられていると、増額分が本当に追加なのか、もともと含まれていたはずのものなのかを誰も検証できません。この状態で金額交渉をしても、根拠のない値引き合戦になるだけです。当初見積もりの分解手順は見積書の「一式」を工程・成果物・工数へ分ける方法で扱っています。

7つの条件の一覧

7つすべてを埋めてから発注できる案件は多くありません。すべてを埋めることが目的ではなく、「どれが埋まっていないかを発注側が把握したうえで発注する」ことが目的です。 把握していれば、増額が来たときに交渉ではなく確認から始められます。

この記事で金額のレンジを出さない理由

「追加費用は当初契約の何%が相場か」という数字を、この記事では出しません。公開されている一次統計で確認できなかったためです。

追加費用の増加率は、対象外の書き方・変更の頻度・契約類型・要件の確定度で大きく変わります。母集団の条件が揃っていない平均値を示すと、読者は自分の案件を平均と比べて「高い／安い」と判断してしまいますが、その比較自体が成立しません。数字を作らず、代わりに判断の手順を示します。

同じ理由で、クラウドやSaaSの具体的な料金も示しません。料金は改定が頻繁で、取得日・税区分・契約期間・最低利用条件を添えないと比較の役に立たないためです。

なお、開発費そのものの相場観と内訳構造はシステム・アプリ開発費用の相場と見積もり妥当性の判断で扱っています。当初見積もりの水準を知りたい場合はそちらを先に読んでください。

追加費用は見積書と契約書のどこから入ってくるか

増額の入口は3つしかない

追加費用の請求は、理由の書き方こそさまざまですが、契約上の入口は大きく次の3つに分かれます。増額の連絡を受けたら、まずどの入口から来たのかを分類してください。分類が決まると、確認すべき書類が決まります。

この3つは、必要な反論が違います。「対象外」なら範囲の記載を、「変更」なら変更前の仕様書と合意の記録を、「未確定」なら概算である旨の記載と確定手順を見ます。混ぜて議論すると、どの書類を見ればいいのか誰にも分からなくなります。

見積書で実際にどう書かれているか

増額の根拠になりやすい書かれ方は、だいたい決まっています。以下は、それ自体が問題なのではなく、そのままでは範囲を確定できないため増額の余地が残るという意味で挙げています。

• 「上記に含まれないものは別途お見積りとなります」（何が含まれないかの列挙がない）
• 「仕様変更が生じた場合は別途協議のうえ決定します」（協議の手続きと単価がない）
• 「本見積もりは現時点の想定に基づく概算です」（確定へ切り替える時期と手順がない）
• 「詳細は要件定義完了後に確定します」（確定後に金額が動く範囲の上限がない）
• 「インフラ費用一式」（第三者へ支払う実費と、ベンダーの作業費が同じ行にある）
• 「検収後、瑕疵については無償対応いたします」（何を不具合と呼ぶかの定義がない）

このうち複数に当てはまるなら、それは価格の問題ではなく分解単位と手続きの問題です。値引き交渉ではなく、記載を足す依頼から始めてください。

見積書から落ちやすい4つの作業

対象外の欄は、増額のリスクを示すだけでなく、安すぎる見積もりを見抜く場所でもあります。総額が他社より明らかに低いとき、その差は次の4つのどれかが対象外に落ちていることで説明できる場合があります。これらは消えたのではなく、発注側の作業か、後日の追加費用へ移動しただけです。

総額の低さを喜ぶ前に、対象外欄にこの4つが並んでいないかを確認してください。過小な見積もりは、過大な見積もりと同じかそれ以上に予算の見通しを狂わせます。

開発費が後から増える7つの条件

ここからが本題です。各条件について、見積書での現れ方 → なぜ増額につながるか → 根拠となる規定 → 4状態の判定の順で整理します。条文が苦手な場合は「根拠となる規定」を飛ばして判定表へ進んでも、判断はできます。

条件1｜「対象外」の範囲が書かれていない

見積書での現れ方：前提条件欄が空欄、または「上記に含まれないものは別途お見積り」の一文だけがある状態です。

なぜ増額につながるか：範囲の記載がないと、含まれる／含まれないの解釈が発注側とベンダーでずれます。増額は、そのズレの差分を請求として顕在化させたものです。ベンダーに悪意がなくても発生します。

根拠となる規定：IPAと経済産業省が公開する情報システム・モデル取引・契約書（第二版）（2020年12月22日公表。以下の引用は受託開発版 第二版 R1 のひな型による）は、業務に着手する前に締結する個別契約について、提案依頼書（RFP）・提案書・見積書を基礎として「以下の各号のうち必要となる取引条件を定め、個別契約を締結する」と定め、12項目を挙げています（第4条第1項）。その筆頭が「具体的作業内容（範囲、仕様等）」です。範囲は契約書の前文で決まるものではなく、個別契約で明示的に定めるものとして設計されています。

なお、条文は「各号のうち必要となる取引条件」と書いており、12項目すべてを常に定めることを求めているわけではありません。案件に応じて取捨する前提です。ただし「具体的作業内容（範囲、仕様等）」を不要と判断できる開発案件は、実務上ほとんどありません。

対象外を書いてもらうときは、粒度を指定してください。「テストは対象外」では何も決まりません。工程単位（結合テストは含むが受入テスト支援は含まない）、成果物単位（テスト仕様書は納品するがテストデータは発注側が用意する）、機能単位（管理画面の権限別テストは対象外）のどれで切るのかを指定すると、返ってきた回答がそのまま契約書の除外事項欄になります。

判定：

条件2｜仕様変更と不具合の境界が定義されていない

見積書での現れ方：「検収後の瑕疵は無償対応」「バグは無償修正」とだけ書かれ、何を不具合と呼ぶかの定義がない状態です。

なぜ増額につながるか：発注側が「不具合だから無償で直すべきだ」と考えるものを、ベンダーが「仕様に書かれていないので追加開発です」と扱うためです。この対立は感情論ではなく、境界を決める文書が存在しないことから起きています。

根拠となる規定：モデル契約書のひな型は、この境界を明示的に置いています。第29条第1項は、検収完了後に「納入物についてシステム仕様書との不一致（バグも含む。以下本条において「契約不適合」という。）」が発見された場合に、発注者が履行の追完を請求できると定めます。つまり判定の基準は「システム仕様書との一致・不一致」であり、発注側の期待との一致ではありません。仕様書に書かれていない挙動は、不具合ではなく変更の対象になります。

ここから導かれる実務上の結論は明快です。仕様書の粒度が、そのまま無償修理の範囲を決めます。 仕様書が粗いほど「仕様書との不一致」を主張できる範囲が狭くなり、追加費用になる領域が広がります。見積書の分解単位が細かいことは、発注側にとって単なる透明性の話ではなく、保証範囲の話でもあります。

もう一つ、発注側が不利になる規定があります。民法第636条は、請負人が契約内容に適合しない目的物を引き渡した場合でも、注文者は「注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合」を理由として、履行の追完の請求・報酬の減額の請求・損害賠償の請求・契約の解除をすることができない、と定めています。ただし同条ただし書きにより、請負人がその材料または指図が不適当であることを「知りながら告げなかったとき」は、この制限は適用されません。

モデル契約書のひな型も第29条第6項で同趣旨を置き、契約不適合が「甲の提供した資料等又は甲の与えた指示によって生じたとき」は追完請求などの規定を適用しないとしたうえで、「乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない」というただし書きを付けています。

これが意味するのは、発注側が出した指示に起因する不具合は、無償修正ではなく追加費用になりうるということです。だからこそ、発注側からの指示は口頭で終わらせず、記録に残す形で出す必要があります。「言った・言わない」は、この条文の適用可否を左右します。

判定：

条件3｜変更の手続きと金額の決め方が決まっていない

見積書での現れ方：「仕様変更が生じた場合は別途協議のうえ決定します」の一文だけが置かれている状態です。

なぜ増額につながるか：「別途協議」は手続きではありません。誰が、何を書いた書面を、いつまでに出し、誰が承認すると変更が確定するのか——これが決まっていないと、変更のたびに交渉が発生し、そのつど金額の根拠が場当たりになります。

根拠となる規定：モデル契約書のひな型は、ここに正規の手順を置いています。まず第33条が、本契約および個別契約の内容の変更は「事前に甲乙協議の上、別途、書面により変更契約を締結することよってのみこれを行うことができる」と定めます。第34条は、仕様書等の変更が必要と認める場合に、変更の内容・理由等を明記した書面（変更提案書）を相手方に交付して提案できるとし、仕様書等の変更は第37条の変更管理手続によってのみ行えるとしています。

そして第37条第1項が、変更提案書を受領した側が交付する書面（変更管理書）に記載する事項として、次の8項目を挙げています。

発注側にとって重いのは⑥と⑧です。⑥はその変更単体の金額、⑧はその変更が納期・委託料・契約条項全体へ与える波及を指します。実務で見落とされやすいのは⑧のほうです。1件の変更を単体の金額だけで承認していくと、納期の後ろ倒しと、それに伴う体制維持費の増加が積み上がり、最後にまとめて跳ね返ってきます。変更を承認する前に⑧の欄が埋まっているかを確認してください。

同条第2項・第3項は、双方の責任者が変更管理書の記載事項を承認して記名押印し、その承認をもって変更が確定するとしています。ただし本契約および個別契約の条件に影響を及ぼす場合は、変更管理書に従って第33条に基づく変更契約を締結したときをもって変更が確定する、としています。金額や納期が動く変更は、変更管理書の承認だけでは確定しません。 承認印を押す前に、これが変更契約の締結を要する変更なのかを確認してください。要するなら、変更契約の文面が出てくるまで作業着手を認めない運用にできます。

同条第4項には、発注側が知っておくべき規定があります。受注者は「甲から中断要請があるなどその他特段の事情がある場合」に、変更の協議が調わない間、業務を中断することができます。条文には「特段の事情がある場合」という限定が付いており、協議が不調なだけで常に中断できると読むものではありません。ただし発注側としては、協議が長引けばスケジュールが止まりうる前提で、変更の可否を決める社内の意思決定期限をあらかじめ決めておくのが安全です。

判定：

条件4｜要件未確定箇所が概算か確定か決まっていない

見積書での現れ方：「本見積もりは概算です」「詳細は要件定義完了後に確定します」と書かれているものの、いつ・どういう手順で確定するのかが書かれていない状態です。

なぜ増額につながるか：概算のまま発注すると、確定時の増額が「仕様変更」ではなく「もともと未確定だった部分の確定」として説明されます。この説明自体は正当ですが、発注側が概算と確定の違いを理解して発注したかどうかで、納得感も交渉余地もまったく変わります。

根拠となる規定：モデル契約書のひな型は、要件が固まっていない状態を否定していません。未確定のまま進めるための正規の手順を第36条に置き、その請求も第37条の変更管理手続によってのみ行えるとしています（第36条第2項）。この手順の中身と、再見積もり（確定見積もりへの切り替え）の依頼方法は、記事後半の要件が固まっていない段階の見積もりは、概算か確定かでまとめて扱います。ここでは、概算のまま発注するなら、確定時に何が起きるかを事前に書面化する手順が存在するという事実だけ押さえてください。

判定：

条件5｜検収条件と検収後の保証範囲がない

見積書での現れ方：「検収後○日以内に完了とします」とだけ書かれ、何をもって合格とするかの基準が示されていない状態です。

なぜ増額につながるか：検収の基準がないと、リリース後に見つかった問題が「保証の対象」なのか「追加開発」なのかを決められません。決められないものは、たいてい追加費用として扱われます。

根拠となる規定：モデル契約書のひな型は、検収の設計を3段階で置いています。

第27条第1項は、発注者が受注者と協議のうえ、システム仕様書に基づいてテスト項目・テストデータ・テスト方法・テスト期間等を定めた検査仕様書を作成し、受注者に提出すると定めています。受注者の責任者はシステム仕様書に適合するかを点検し、適合を承認する場合は記名押印して交付します。協議は前提とされていますが、検査仕様書を作る主体と、そこにかかる工数は発注側にあります。

同条第3項は、発注者がその作成支援を受注者に委託する必要がある場合、ソフトウェア開発業務の個別契約を締結するときまでに申し込み、検査仕様書作成支援業務に関する個別契約を別途締結することができるとしています。つまり、支援が必要なら別の契約と別の費用になるという設計です。見積書に検査仕様書作成支援が入っていない場合、それは安いのではなく、発注側が自前で作る前提だということです。

第28条第1項は、発注者が検査期間内に検査仕様書に基づいて検査し、システム仕様書とソフトウェアが合致するかを点検しなければならないと定めます。そして第3項に、発注側が最も注意すべき規定があります。

検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を明示して異議を述べない場合は、本件ソフトウェアは、本条所定の検査に合格したものとみなされる。

沈黙は合格とみなされます。 忙しくて検査ができなかった、担当者が異動した、といった事情は考慮されません。検査期間の長さは個別契約で定めるものなので、社内で検査に充てられる体制と期間が釣り合っているかを、契約前に確認してください。

検収後の責任期間についても注意が必要です。ひな型の第29条第5項は、受注者が契約不適合責任を負うのは「前条の検収完了後〇ヶ月／○年以内【であって、かつ甲が当該契約不適合を知った時から〇ヶ月以内】に甲から当該契約不適合を通知された場合に限る」としていますが、この期間はひな型では空欄で、当事者が定めるものです。「モデル契約書が1年と決めている」といった理解は誤りです。空欄のまま契約しないでください。なお、これは条文の定めではなく実務上の目安ですが、何ヶ月・何年とするかは、そのシステムの繁忙期を1周できる長さを出発点に交渉できます。

民法上の期間制限は別に存在します。第637条第1項は、注文者がその不適合を「知った時から一年以内」にその旨を請負人に通知しないときは、追完請求・報酬減額請求・損害賠償請求・契約解除ができないと定めています。起算点は引渡しからではなく、不適合を知った時からです。ただし同条第2項により、引渡しの時点で請負人が不適合を知っていた、または重大な過失によって知らなかった場合には、この期間制限は適用されません。

起算点が「知った時」である以上、いつ知ったかを立証できるのは発注側の記録だけです。不具合を認識した日付と内容を、発見のつど記録に残す運用を、稼働と同時に始めてください。

判定：

条件6｜第三者費用が開発費と分離されていない

見積書での現れ方：「インフラ費用一式」「サーバー・ライセンス込み」のように、外部へ支払う実費とベンダーの作業費が同じ行に入っている状態です。

なぜ増額につながるか：クラウド、SaaS、外部API、商用ライセンスといった第三者費用は、ベンダーの見積もり精度とは無関係に動きます。料金改定、為替、利用量の変動で変わり、ベンダーには止められません。

問題は金額そのものではなく、混ざっていると増額の原因を切り分けられなくなることです。「インフラ費用が上がりました」と言われたとき、それが第三者の価格改定なのか、想定より多くのリソースを使う設計になったのか、ベンダーの構築工数が増えたのかが判別できません。分離されていれば、実費部分は実費として受け止め、作業費部分だけを議論できます。

根拠となる規定：モデル契約書のひな型は第9条第3項で「甲の責任者」（発注者側の責任者）が有する権限および責任を列挙しており、そのなかに「第48条及び第49条所定の第三者ソフトウェア及びFOSSの採否を行う権限及び責任」が含まれています。どの第三者製品を使うかは発注側が決める事項として設計されているということです。ベンダーの提案をそのまま受け入れる場合でも、その選択によって発生し続ける費用は発注側の負担になります。

確認すべきなのは金額ではなく構造です。見積書に対して、次の3つが分かれているかを見てください。

1. 第三者へ支払う実費（クラウド利用料、ライセンス料、外部APIの従量課金）— 誰が契約主体で、誰の名義の請求書が来るのか
2. ベンダーの構築・設定作業費（環境構築、権限設計、監視設定）— 一度きりか、継続か
3. 請求代行や管理の手数料（実費に上乗せされる率または固定額）— 実費との区別が付いているか

判定：

条件7｜支払条件と中止時の精算が決まっていない

見積書での現れ方：工程が複数あるのに「着手金50%、納品時50%」のように支払いが2回だけで、工程ごとの成果物と対応していない状態です。

なぜ増額につながるか：直接的に増額を生むわけではありませんが、増額を断りにくくする構造を作ります。すでに大半を支払っている状態では、「この増額を飲まなければ止まる」という状況で交渉することになります。

そしてもう一つ、多くの発注側が誤解している点があります。「増額を断って途中でやめる」は無料ではありません。

根拠となる規定：民法第641条は、「請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる」と定めています。いつでも解除できるのは事実ですが、無償ではありません。

民法第634条は、請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなし、請負人は注文者が受ける利益の割合に応じて報酬を請求できると定め、その適用場面として次の2つを挙げています。

• 一 注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき
• 二 請負が仕事の完成前に解除されたとき

準委任契約でも同様の考え方が置かれています。民法第648条第3項は、委任者の責めに帰することができない事由によって履行できなくなったとき、または委任が履行の中途で終了したときに、受任者は既にした履行の割合に応じて報酬を請求できるとしています。成果完成型については第648条の2第2項が第634条を準用します。

モデル契約書のひな型も同じ設計です。第38条第1項は、変更の協議の結果として発注者が個別契約の続行を中止しようとするとき、未了部分について解約できるとし、第2項でこう定めています。

甲は、前項により個別業務の未了部分について解約しようとする場合、中止時点まで乙が遂行した個別業務についての委託料を支払うとともに、解約により乙が出捐すべきこととなる費用その他乙に生じた損害を賠償しなければならない。

なお、ひな型の第38条にはA案とB案の2つの選択肢が併記されており、上記の第1項・第2項はA案・B案に共通の条文です。 B案はこれに加えて、続行が困難となる事情が客観的に認められる場合に受注者側からも中止を提言し、発注者が合理的な期間内に合理的な理由を示さず応じないときは受注者が解約できる、という規定を置いています。どちらを採用しているかで、ベンダー側が持つ解約権の有無が変わります。自社の契約書がどちらの型なのかを確認してください。

つまり、増額を飲むか、やめるかの二択に見えたとき、「やめる」側にも金銭的な帰結があります。これを知らずに交渉に入ると、実際には選べない選択肢を前提に判断してしまいます。工程ごとに支払いと検収を対応させておくことが、この構造を和らげる唯一の手段です。

判定：

要件が固まっていない段階の見積もりは、概算か確定か

条件4で触れた論点を、ここで詳しく扱います。要件定義前に受け取った見積もりをどこまで信用してよいか、という問いです。

違いは「精度」ではなく「何を約束しているか」

概算見積もりと確定見積もりの差は、しばしば誤差の幅で説明されます。しかし発注判断で効いてくるのは、誤差の数字ではなく約束の中身です。

この表の3行目が最も重要です。 同じ増額でも、概算段階なら「確定」、確定後なら「変更」として扱われます。扱いが変われば、必要な手続きも、発注側が主張できる内容も変わります。したがって、手元の見積もりが概算なのか確定なのかは、金額の妥当性より先に確認すべき事項です。

見積書に「概算」と書かれていない場合でも、確定見積もりとは限りません。次のどれかに当てはまるなら、実質的には概算です。

• 要件定義書・外部設計書がまだ存在しない、または未確定の箇所がある
• 見積もりの前提条件欄に「〜と想定」「〜の場合」という条件付きの記述が複数ある
• 機能一覧はあるが、画面・API・処理の単位まで分解されていない
• 外部システムとの連携があるのに、相手側の仕様を確認した記録がない

モデル契約書が置いている未確定事項の正規手順

モデル契約書のひな型第36条は、発注者が業務遂行に必要な事項を「甲のやむを得ない事情により確定して提示することができない場合」に、次を記載した書面を作成し、双方が記名押印することで、確定後に要件定義書・外部設計書の追完や修正を請求できる、という組み立てになっています。これを発注側の言葉に置き換えると次のようになります。

注目すべきは3つ目です。未確定事項が確定した結果として費用・期間が動くことを、発注側があらかじめ受け入れると書面で確認する設計になっています。裏を返せば、この書面がないまま「概算です」とだけ書かれた見積もりで発注した場合、確定時の増額をどう扱うかについて合意が存在しないことになります。

この条項が前提としているのは発注者の「やむを得ない事情」であって、要件を詰める時間や体制を単に確保しなかった場合に、この手順が当然に使えると読むべきものではありません。

なお、「第二版の公表にあたって」は、第一版ではモデル契約書・逐条解説が要件定義フェーズ以降を対象としており、企画支援サービス業務についてはモデル契約書・逐条解説が用意されていないと述べています。ただし第二版そのものは表題に「受託開発（一部企画を含む）」と掲げ、システム再構築の企画プロセスをモデル契約プロセスの解説として収録しています。つまり、企画段階が扱われていないのではなく、企画段階には逐条解説付きの契約書ひな型という形の拠り所が無いということです。要件定義より前の段階で受け取った超概算見積もりは、ここで挙げた条項をそのまま当てはめられる段階にはまだ無い、と理解してください。

段階見積もり（再見積もり）へ切り替える依頼の仕方

要件定義前の見積もりを、そのまま固定価格の契約にしないための現実的な方法は、契約を工程で分けることです。モデル契約書のひな型がまさにこの構造を採っています。第3条は業務が要件定義作成支援業務・外部設計書作成支援業務・ソフトウェア開発業務・ソフトウェア運用準備／移行支援業務の全部または一部から構成されるとし、それぞれに個別契約が適用されるとしています（工程名は選択する案によって変わります）。第4条第2号は、個別契約で定める取引条件として「契約類型（請負・準委任）」を挙げており、工程ごとに契約類型を選べる設計です。

ベンダーへ送る依頼としては、次のように書けます。

現時点では要件が確定していないため、いただいた見積もりを固定価格の契約とすることは避けたいと考えています。工程を分け、要件定義（および外部設計）までを先に契約し、その成果物をもって開発工程の確定見積もりをいただく形に変更していただけないでしょうか。要件定義工程については、成果物と完了条件、想定期間、体制をご提示ください。あわせて、要件定義の結果として開発工程の金額が現在の概算から動きうる範囲について、現時点でのお考えを伺えますと助かります。

この依頼には、ベンダー側にも利点があります。要件が固まらない段階の固定価格は、ベンダーにとってもリスク上乗せの対象です。分割することで、双方が過剰なバッファを持たずに済みます。

要件定義そのものの進め方（目的とKPIの定義、業務プロセスの棚卸し、非機能要件の決め方など）は、この記事の範囲外です。AIシステム開発の要件定義の進め方で6ステップと発注前チェックリスト20項目を扱っているので、要件定義工程の設計に入る段階ではそちらを参照してください。

増額が「合理的」なケース

ここからは、実際に増額を提示された後の話です。追加費用のすべてが避けるべきものではありません。次のケースは、増額が発生することのほうが健全です。断ることが目的化すると、必要な品質まで削ることになります。

ケース1｜発注側の都合で要件が変わった 市場環境や社内方針の変更で仕様を変えたなら、その分の費用が発生するのは当然です。確認すべきは金額の有無ではなく、変更管理の手続きが踏まれているか（第37条の8項目が埋まっているか）です。

ケース2｜発注側が提供する前提が揃わなかった テストデータ、既存システムの仕様書、外部システムの接続情報、担当者の確認時間——これらの提供が遅れると、ベンダー側に待機や手戻りが発生します。モデル契約書のひな型が第4条第7号で「甲が乙に提供する情報、資料、機器、設備等」を個別契約の取引条件に挙げているのは、この責任分界を事前に決めるためです。

ケース3｜分割発注した他社との調整が発生した モデル契約書のひな型第13条は、発注者がシステムの一部を分割発注し、連携する他のソフトウェアを第三者が開発している場合、機能の整合性・開発スケジュールの調整・第三者との進捗管理および調整等に係る事項について、発注者が責任を負うと定めています。この調整をベンダーに担ってもらうなら、それは追加の業務です。

ケース4｜未確定事項が確定した結果として金額が動いた 第36条の手順を踏んでいるなら、これは想定内の動きです。確定によって減る場合もあります。

ケース5｜外部要因で第三者費用が変わった クラウドやライセンスの価格改定、為替変動による費用増は、ベンダーの見積もり精度の問題ではありません。実費として分離されていれば、そのまま受け止める対象です。

いずれのケースも、合理的である条件は「手続きが踏まれていること」と「根拠が示せること」です。理由が正当でも、手続きを飛ばして請求が来ているなら、それは「要確認」です。

増額を提示されたら最初に開く4つの書類

開く順番があります。上から順に開いてください。

1. 見積書の前提条件欄・除外事項欄 — 請求されている作業が、明示的に除外されていないかを見る
2. 契約書の業務範囲と変更管理条項 — 変更を有償にする手続きが定められているか、その手続きが踏まれたかを見る
3. 仕様書（要件定義書・外部設計書） — 「変更前の状態」がどこに書いてあったのかを特定する
4. 変更の依頼と合意の記録 — 誰が、いつ、何を依頼し、誰が承認したのかを時系列に並べる

4つ目が最も重要で、最も欠けています。口頭やチャットで「じゃあそれでお願いします」と答えた記録が、後から変更の合意として扱われることがあります。逆に、発注側が変更を依頼していないのに増額が来ている場合は、この時系列を作るだけで論点が絞れます。

4状態で仕分ける判定表

4つの書類を開いたら、この表で仕分けます。増額の言い分ごとに、どの入口から来たのか、何を確認するのかを1枚にまとめました。条件7（支払条件と中止時の精算）だけは増額の言い分としてではなく、断ったときの帰結として効いてくるため、最終行に置いています。

表の使い方：右2列のどちらに当てはまるかで、次の行動が決まります。「説明済み」は承認、「要確認」は質問、「高リスク」は個別交渉ではなく手続きの合意し直し、「判断不能」は基準になる文書を作らせることです。「高リスク」に該当する行が複数ある場合、その案件は個々の増額ではなく契約構造の問題を抱えています。 目の前の1件を値切っても、同じ理由で次が来ます。

ベンダーへそのまま送れる確認質問8と依頼文

そのままコピーして送れる形にしてあります。全部を一度に送る必要はありません。発注前なら8問を、増額を提示された後なら末尾の依頼文を使ってください。

発注前に送る8問

1. 本見積もりに含まれない作業を、工程・成果物の単位で列挙していただけますか。特に、テスト（種別ごと）、データ移行、セキュリティ対応、プロジェクト管理の4つについて、含む／含まないをご明示ください。
2. 本見積もりは概算・確定のどちらでしょうか。概算の場合、どの部分が未確定で、いつ・どの成果物をもって確定する想定かをお示しください。
3. 仕様変更と不具合の判定は、どの文書を基準に行いますか。 その文書が現時点で存在しない場合、いつまでに、どの粒度で作成される想定でしょうか。
4. 仕様変更が発生した場合の手続きをお教えください。どのような書面で提案し、誰が承認すると変更が確定しますか。また、その書面には金額と、納期・契約条件への影響を記載していただけますか。
5. 追加作業が発生した場合の単価または算定方法（職種別の単価、最小の作業単位、見積もり提示までの日数）をお示しください。
6. 検収の合格基準と検査期間をお教えください。あわせて、検査期間内に当社が異議を述べなかった場合の扱いもご教示ください。
7. 検査仕様書はどちらが作成する前提でしょうか。 当社が作成する場合、作成支援を別途お願いすることは可能ですか。その場合の費用もあわせてお示しください。
8. クラウド・ライセンス・外部APIなど第三者へ支払う費用を、御社の作業費と分けてご提示いただけますか。あわせて、各サービスの契約主体（当社名義か御社名義か）と、請求経路をお教えください。

増額を提示された後に送る依頼文

○○株式会社 ○○様

お世話になっております。 先日ご提示いただいた追加費用について、社内で判断するために確認させてください。

恐れ入りますが、今回の増額について、契約上の根拠となる箇所（契約書または見積書の該当条項・該当行）をご指定いただけますでしょうか。あわせて、契約範囲外の作業・仕様変更・未確定事項の確定のいずれに該当するかをご教示ください。

また、今回の変更が納期および後続工程の費用に与える影響についても、現時点での見通しをお示しいただけますと助かります。今回の金額のみで判断すると、後続への波及を見落とす可能性があるためです。

あわせて、今回の変更を行わない場合の選択肢（現行仕様のまま進める／範囲を縮小する／後続フェーズへ送る）と、それぞれの費用・納期への影響もご教示いただけますでしょうか。

ご対応をお願いできますと幸いです。

質問の目的は交渉ではなく分類です。 回答が返ってきたら、前掲の判定表で4状態のどこに入るかを決めてください。回答の速さと具体性そのものも、そのベンダーの管理水準を示す情報になります。

契約前に埋めておくチェックリスト

前掲の7つの判定表で「説明済み」にならなかった項目が、そのまま埋めるべき項目です。発注前に印刷して使えるよう、条件番号つきで並べておきます。

範囲（条件1）

• 含む作業が工程・成果物の単位で列挙されている
• 含まない作業が列挙されている（特にテスト・移行・セキュリティ・PM）
• 発注側が提供する情報・資料・環境と、その提供期限が定められている

変更と不具合（条件2・条件3）

• 不具合の判定基準となる文書が指定されている
• 変更の提案から確定までの手続きが定められている
• 変更を記載する書面に、金額と、納期・契約条件への影響の欄がある
• 追加作業の単価または算定方法が示されている

未確定要件（条件4）

• 概算部分と確定部分が区別されている
• 未確定事項の内容・確定予定時期・確定時の扱いが書面になっている
• 工程ごとに契約類型（請負・準委任）が選ばれている

検収と保証（条件5）

• 検査の合格基準と検査期間が定められている
• 検査仕様書の作成主体が決まっている
• 契約不適合責任の期間が具体的な数値で埋まっている

費用構造（条件6・条件7）

• 第三者費用と作業費が別行になっている
• 第三者サービスの契約主体が決まっている
• 支払いが工程・成果物・検収と対応している
• 中途解約時の精算方法が定められている

埋まっていない項目は、そのまま増額が入ってくる入口になります。

根拠資料と適用条件

この記事で使った一次資料

適用条件（そのまま自社契約へ写さないでください）

モデル契約書には、想定している取引の性格が明記されています。「第二版の公表にあたって」は、第一版と追補版の前提の違いについて次のように述べています。

第一版と追補版で大きく異なるのは、その前提であり、第一版では情報の非対称性がありつつも企業同士の交渉力としては対等なユーザ・ベンダ間の契約であり、重要インフラ・企業基幹システムの受託開発を念頭に置いていたのに対し、追補版では IT の専門知識を有しないユーザを業として情報サービスを提供するベンダ間の契約であって、必ずしも基幹システムのような大きいシステムの開発を想定していない。

この記事が参照した受託開発版は第一版の系統にあたり、重要インフラ・企業基幹システムの受託開発を念頭に置いた設計です。パッケージやSaaS/ASPの活用を前提とする取引には、別に第二版追補版（パッケージ、SaaS/ASP活用、保守・運用）が用意されています。

したがって、この記事で引用した条項はそのまま自社の契約書へ写すためのものではなく、「同じ論点が自社の契約書で決まっているか」を確認するための一覧として使ってください。小規模な開発やパッケージ活用型の案件では、条項の粒度がそのまま適合しない場合があります。

また、ひな型には第38条のようにA案・B案の選択肢が併記されている条項や、選択する案によって工程名が変わる箇所があります。「モデル契約書はこう定めている」と一意に語れない箇所があることに注意してください。

この記事の性格について

本記事は法令およびモデル契約書の一般的な整理であり、個別案件についての法的判断ではありません。契約条項の適否、増額請求の当否については、弁護士へご確認ください。また、金額の相場・増加率については、確認できる一次統計がなかったため記載していません。

よくある質問

まとめ

システム開発の追加費用は、契約書と見積書に書かれていない条件から発生します。この記事で整理した7つの条件——対象外の範囲、仕様変更と不具合の境界、変更の手続き、未確定要件の扱い、検収と保証、第三者費用の分離、支払条件と中止時の精算——は、いずれも発注前に確認できるものです。

増額の連絡を受けたときは、「高いか安いか」ではなく、説明済み／要確認／高リスク／判断不能の4状態のどれかに仕分けてください。仕分けが決まれば、次の行動（承認・質問・手続きの合意し直し・基準になる文書の作成依頼）が自動的に決まります。

そして、追加費用が一切発生しない開発が理想なのではありません。発注側の都合で要件が変われば費用は増えますし、それは健全なことです。目指すべきは、増額が起きたときにその根拠を双方が同じ書面で確認できる状態です。

手元の見積書の確認方法

手元の開発見積書について、7つの条件のうち範囲・変更条件・検収条件・第三者費用の4点の記載状況を確認したい場合は、要件・契約範囲チェック（登録不要）をご利用ください。見積書のテキストから該当する記載の有無を確認し、ベンダーへ送る質問の候補を返します。結果の閲覧までメールアドレスの入力は不要です。

複数社の見積もりを同じ条件へそろえて比較する段階であれば、開発会社の見積もり比較ガイドでRFPの整備と比較表の作り方を扱っています。