「契約金額は800万円のはずが、納品時には1,100万円になっていた」——システム開発の現場で繰り返される追加費用の問題は、ベンダーの不誠実さよりも、契約書に最初から組み込まれた条文構造に原因があります。仕様変更があれば追加請求できる、検収基準が曖昧なため再作業はすべて有償、瑕疵担保期間は短い——これらは交渉時に詰められる条項ばかりです。本記事では、追加費用が発生する契約条項の典型と、契約書レベルで防ぐためのチェックリスト7項目を経営者目線で整理します。
この記事の結論（3行）
- 追加費用の8割は事故ではなく、契約書の条文構造に組み込まれた「合法的な追加請求の仕組み」から発生する
- 契約書チェックの本丸は仕様変更条項・検収基準・瑕疵担保期間の3点で、ここを詰めれば追加請求の30〜50%は防げる
- 契約締結前に条文レベルで7項目を確認すれば、納品後の「想定外の追加200万円」は構造的に避けられる
追加費用が発生する契約上の典型条項
システム開発の契約書には、追加費用を生み出す典型的な条文パターンが存在します。これらは違法でも不誠実でもなく、契約として有効に機能する条項です。ただし、買う側が条文の意味を理解しないまま署名した場合、納品時の請求書で初めて「そういう契約だったのか」と気づくことになりがちです。
- 仕様変更時の追加費用条項
- 検収基準が曖昧なまま納品される条項
- 瑕疵担保期間と無償修補範囲の限定条項
- 再委託・再下請けの自由度を認める条項
800万円の契約が1,100万円になる経路は、多くの場合この4つの条項のどれかを経由します。「仕様変更があったので追加200万円」「検収後の指摘なので有償対応で50万円」「瑕疵担保期間が過ぎているので改修費用50万円」——どれもベンダー側が悪いわけではなく、契約書通りの処理にすぎません。経営者として大事なのは、契約締結の段階で、これらの条文が自社にとって不利になっていないかを条文単位で確認しておくことです。
仕様変更時の追加費用条項
「乙は、甲の要請による仕様変更が発生した場合、別途見積もりに基づき追加費用を請求できるものとする」——この一文がすべての契約書に入っています。問題は、何を「仕様変更」と定義するかが曖昧なまま署名されることです。要件定義書に書かれていない細かい挙動の調整、画面の文言修正、ボタンの位置変更——これらが「仕様変更」とみなされれば、すべて追加請求の対象になります。契約書には「軽微な調整は仕様変更に該当しない」「仕様変更の判定はベンダー単独ではなく双方協議とする」という条文を必ず入れてください。
検収基準が曖昧なまま納品される条項
「乙が指定する検収基準書に従って甲が検収を行う」とだけ書かれた契約は要注意です。検収基準書がベンダー側で作成され、甲（発注側）が内容を吟味する時間のないまま納品日が来ます。検収基準があいまいだと、納品後に発生したバグや動作不良が「検収済みの仕様」として処理され、修正費用がすべて追加請求になりがちです。契約書には「検収基準書は契約締結後14日以内に双方合意で確定する」「合意なき検収基準書による検収は無効」という条文を盛り込むのが守りの基本です。
契約書チェックリスト：7項目の具体条項と確認ポイント
ここからは、契約締結前に条文レベルで確認すべき7項目を具体的にお伝えします。各項目に対して、契約書のどの条文を、何のために確認するのかを明確にしました。
| 確認項目 | 条文の見出し例 | 追加費用を防ぐ確認ポイント | |---|---|---| | 1. 仕様変更の定義 | 第○条（仕様変更） | 「軽微な調整は変更に該当しない」と明記、判定は双方協議 | | 2. 検収基準と検収期間 | 第○条（検収） | 検収基準書を契約後14日以内に双方合意で確定 | | 3. 瑕疵担保期間 | 第○条（契約不適合責任） | 最低12ヶ月、無償修補の範囲を明文化 | | 4. 追加開発の単価 | 第○条（追加業務） | 人月単価を契約時に固定、後出し単価を禁止 | | 5. 運用・保守の範囲 | 第○条（運用保守） | 月額固定費の対象を列挙、対象外は別表で明示 | | 6. 再委託の制限 | 第○条（再委託） | 事前承諾制、再委託先の責任は元請けが負う | | 7. 中途解約時の精算 | 第○条（中途解約） | 出来高ベースで精算、違約金の上限を明示 |
7項目すべてに該当する条文が契約書に存在しない場合、その契約は買う側の保護が弱い構造になっています。逆に、これら7項目が明文化されている契約書は、追加請求が発生する余地が条文レベルで狭まっており、納品時の請求金額が契約金額を大きく超える確率が下がります。手元の契約書ドラフトをこの粒度で点検したい場合は、業務改善・システム見積もりAI適正診断で項目別に整理できます。
仕様変更の定義を「双方協議」に変える
契約書のドラフトには「仕様変更が発生した場合、別途見積もりに基づき追加費用を請求する」とだけ書かれているケースがほとんどです。ここに「仕様変更の該当性は甲乙双方の協議により判定する」「明らかな実装ミス・仕様書の解釈相違による修正は仕様変更に該当しない」という2文を追記してください。この一文が入るかどうかで、納品時の追加請求額が数十万〜百万円単位で変わってきます。
瑕疵担保期間は最低12ヶ月、無償修補範囲を明文化
民法上の契約不適合責任は、引渡しから1年間が原則です。しかし、システム開発の契約書では「瑕疵担保期間は納品後3ヶ月とする」と短縮されていることが多くなりがちです。3ヶ月以内にすべての不具合を洗い出すのは現実的ではないため、ここは必ず12ヶ月に修正してもらってください。あわせて「無償修補の範囲は仕様書記載の機能の不動作・誤動作とする」のように、無償対応の範囲を明文化しておくことが重要になります。
追加費用を生む契約上の危険信号
契約書ドラフトを読む時に、次の3つの危険信号が見つかった場合は、署名前に必ず修正交渉を入れてください。これらが残ったまま契約すると、追加費用は事実上ベンダーの裁量で青天井になります。
- 「別途協議」「別途見積もり」が5箇所以上ある
- 「乙は」「乙が」で始まる権利条項が一方的に多い
- 違約金・損害賠償の上限が買う側にだけ厳しい
「別途協議」が5箇所以上ある契約書
「別途協議の上決定する」という条文が契約書のあちこちに散らばっている状態は危険信号の代表格です。別途協議の結論はベンダー側が主導権を握るケースが多く、結果として追加費用の根拠条文として機能します。本来であれば、契約時点で決められる事項は契約書に書き切るのが筋です。「別途協議」が5箇所以上ある契約書は、契約として未完成と考えてください。
「乙は」で始まる権利条項の偏り
契約書を音読すると、「乙は〜することができる」「乙は〜を留保する」という条文が異常に多いケースがあります。これは契約が一方的にベンダー側に有利に設計されている兆候です。買う側の権利条項——「甲は中途解約できる」「甲は検収基準の合意なき場合は検収を拒否できる」など——が同等以上に書かれているかを必ず確認してください。条文の数が偏っている契約書は、納品後のトラブル発生時に買う側の選択肢が極端に少なくなりがちです。
違約金条項の非対称性
中途解約時に買う側が払う違約金は「契約金額の50%」「残期間の費用全額」と厳しい一方で、ベンダー側の納期遅延・品質不備に対する違約金は「協議の上決定」と曖昧——こうした非対称性は典型的な不利契約のサインです。違約金条項は双方対称に設計されているべきで、納期遅延に対する違約金（遅延損害金）の上限と算定式を契約書に明記してもらってください。
経営者目線で考える「契約書を武器にする発注力」
ここからは技術論ではなく、経営の話です。システム開発の契約書を読む力は、社員の労務契約や賃貸借契約と同じく、経営者が持っておくべき基礎的な経営スキルだと考えてください。多くの中小企業の経営者は、ベンダーから提示された契約書ドラフトを、ほぼそのまま署名しています。「専門家が作った書面だから問題ないだろう」「修正交渉すると関係が悪くなる」という心理が働きがちです。しかし、契約書はベンダー側が自社のリスクを最小化するために設計した書面であり、買う側のリスクは何も守ってくれません。
業界の構造を一度断っておくと、システム開発の契約書ドラフトは、業界団体が公開している「モデル契約書」をベースにしているケースが大半です。モデル契約書自体はバランスの取れた構成になっているのですが、ベンダー側が自社の経験を踏まえて買う側の権利条項を削っているドラフトが流通しているのが実態と言えるでしょう。特に多重下請け構造で発注した場合、元請けは下請けへの再委託で発生するリスクをすべて買う側に転嫁する条文を入れてくる傾向があります。「再委託先の不履行による損害は乙の責任に帰さない」のような条文を見たら、必ず削除交渉してください。
経営者として持つべき視点は3つです。第一に、契約書は交渉できるという当たり前の事実を思い出すこと。ベンダー側のドラフトを修正することは、関係悪化ではなく対等な商取引の前提です。第二に、追加費用を防ぐ条文は、署名前に書面で詰めるしかないこと。納品後の口頭交渉では構造的に勝てません。第三に、契約書チェックは社内の総務や顧問弁護士に丸投げせず、経営者自身が条文の経済的意味を理解しておくこと。法的にOKでも経済的に不利な条文は山ほどあり、そこは経営判断の領域だからです。
ぷらすわんの実例：ある製造業A社の場合
弊社が伴走した製造業A社（仮想ケース）は、生産管理システムの開発を大手SIerに発注し、当初契約金額は1,400万円でした。契約書には「仕様変更時は別途見積もり」「検収基準は別途協議」「瑕疵担保期間3ヶ月」という典型条文が並んでいたのですが、A社は内容を精査せずに署名しました。納品時の請求書は1,820万円。約420万円の追加請求の内訳は、仕様変更8件分で260万円、検収後の修正対応で90万円、運用フェーズの初期チューニングで70万円という構成でした。
A社の事例から学ぶべきポイントは3つです。1つ目は、仕様変更8件のうち5件が「画面文言の調整」「ボタン配置の変更」といった軽微な調整だった点。契約書に「軽微な調整は仕様変更に該当しない」という1文があれば、約160万円の追加請求は防げた計算になります。2つ目は、検収基準書がベンダー単独で作成されたため、検収後に発生したバグが「仕様通り」と処理された点。3つ目は、瑕疵担保期間が3ヶ月と短かったため、納品4ヶ月後に発覚した不具合の修正が有償対応になった点です。
弊社が同じ規模の生産管理システムを発注検討段階から伴走する場合、契約書ドラフトの7項目チェックを契約締結前に必ず実施しています。その上でAI駆動開発を組み合わせれば、市場相場1,200〜1,800万円の生産管理システムを700〜900万円のレンジで構築できる構造を持っています。契約書を整え、構造的に追加費用を防いだ上で、開発工数も削れるという二重の効果が生まれるためです。手元の契約書ドラフトを診断することで、追加費用が発生しうる条文の有無を具体的な数字で把握できます。
契約書チェックを実行する3つの実践ステップ
最後に、契約書チェックを実際の発注プロセスに組み込むための実践ステップを3つ紹介します。これは弁護士に依頼する前に、経営者自身が15〜30分でできる範囲の作業として設計しています。
- ドラフト受領後、署名前に必ず7項目チェックを行う
- 修正交渉は書面で行い、口頭合意で済ませない
- 契約締結後も検収基準書の合意までは気を抜かない
3つのステップは独立した作業ではなく、契約締結プロセスに組み込む流れとして連続しています。ドラフト受領→7項目チェック→書面修正交渉→契約締結→検収基準書合意——この5段階を踏むことで、追加費用が発生する余地が条文レベルで狭まります。
ドラフト受領後、署名前に必ず7項目チェックを行う
ベンダーから契約書ドラフトを受け取ったら、署名までに最低3営業日は確保してください。その日のうちに署名してしまう経営者もいますが、契約書は数百万円〜数千万円の経済的影響を持つ書面です。本記事の7項目を1項目ずつ条文で確認し、該当する条文がない場合は追記を依頼するという作業を、まず自分でやってみる価値があります。15〜30分の作業で、納品時の追加請求が数十万円単位で減る可能性があるためです。
修正交渉は書面で行い、口頭合意で済ませない
修正交渉は必ずメールやチャットなど書面で行い、合意した内容は契約書本体に反映してもらってください。「口頭で確認しました、覚書で対応します」というベンダー側の提案は要注意です。覚書は契約書本体より法的優位性が弱く、担当者が異動した時に「そんな約束は聞いていない」となりがちです。合意事項はすべて契約書の本文または別紙に明文化する——これを徹底するだけで、納品時のトラブル発生率が大きく下がります。
検収基準書の合意までは気を抜かない
契約締結後にもう一山あります。検収基準書の合意です。多くの案件で、検収基準書はベンダー側から「これで進めます」と一方的に提示され、買う側が確認の時間を取らないまま開発が進行しがちです。契約書に「検収基準書は双方合意で確定する」と書かれていても、合意プロセスを実行しなければ意味がありません。契約締結後14日以内に、ベンダーから提示された検収基準書を経営者自身が読み、「ここが不明確」「この項目を追加してほしい」を必ず書面で返してください。手元の契約書ドラフトと既存案件の見積もりを照らし合わせて比較を依頼することで、追加費用リスクの構造を具体的に確認できます。
まとめ
システム開発の追加費用は、ベンダーの不誠実さではなく、契約書の条文構造に組み込まれた合法的な仕組みから発生します。仕様変更条項・検収基準・瑕疵担保期間という3つの本丸を、契約締結前に条文単位で詰めることで、納品時の「想定外の追加200万円」は構造的に防げます。経営者として大事なのは、契約書を「専門家任せ」にせず、自身で7項目を確認し、修正交渉を書面で行い、検収基準書の合意までを発注プロセスに組み込むことです。手元に契約書ドラフトがある段階なら、現在の条文を診断することで、追加費用が発生しうる条文の有無を具体的な数字で把握できます。