# システム開発の支払い条件｜前払い・分割の決め方

- 公開日: 2026-10-24
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/system-development-payment-terms

システム開発の支払い条件は、契約類型と成果確認の単位に合わせて決めます。中規模以上の請負開発は着手・要件確定・中間納品・検収後の分割払い、準委任開発は月次払いが基本です。金額だけでなく、各支払いの条件、検収期限、中止時の精算まで契約前に合意することが重要です。

## システム開発の支払い条件で最初に決めること

支払い条件を決める際は、「いつ払うか」だけでなく、「何が完了したら支払い義務が生じるか」を明確にします。契約書に支払日だけが書かれていても、納品物、確認方法、中止時の扱いが曖昧では、開発が止まったときに精算額を判断できません。

まず、次の5点をセットで決めます。

- 支払い回数：一括、2回、工程別、毎月など
- 支払い時期：契約時、納品時、検収後、請求月の翌月末など
- 支払い条件：日付の到来、成果物の提出、検収完了、作業報告の承認など
- 支払い金額：定額、契約金額に対する割合、実績工数による精算など
- 中止時の精算：実施済み作業、未使用の着手金、解約費用の扱い

### 契約類型によって適した支払い方が異なる

システム開発では、主に請負契約と準委任契約が使われます。

請負契約（＝合意した成果物を完成させる責任を負う契約）では、納品や検収と支払いを連動させる方法が適しています。検収とは、納品物が合意した仕様や品質基準を満たすか確認し、受け入れることです。

一方、準委任契約（＝専門業務を適切に遂行することを依頼する契約）では、特定の成果物の完成だけを支払い条件にするとは限りません。毎月の稼働実績、作業報告書、会議への参加、調査結果などを確認し、月次で支払う形が一般的です。

| 確認項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 契約の中心 | 成果物の完成 | 業務の遂行 |
| 主な支払い方式 | 納品後一括、着手金＋残金、工程別分割 | 月次払い、工数精算 |
| 支払い前の確認 | 成果物、完成基準、検収結果 | 作業報告、稼働時間、実施内容 |
| 仕様変更への対応 | 追加見積もりになりやすい | 優先順位や工数配分を調整しやすい |
| 発注者の注意点 | 検収基準を事前に決める | 月ごとの成果と残作業を可視化する |

契約名だけで判断せず、実際の責任範囲と支払い条件が一致しているか確認してください。例えば、準委任契約なのに完成責任を前提とした支払い条件になっていると、双方の認識が食い違います。

### 支払いサイトも確認する

支払いサイトとは、請求の締め日から実際の支払日までの期間です。「月末締め翌月末払い」「検収月の翌月末払い」などを指します。発注企業の社内規程が翌々月払いでも、開発会社が受け入れるとは限らないため、見積もり段階で伝える必要があります。

なお、取引条件によっては中小受託取引適正化法（取適法。旧下請法）などの法令が適用され、支払期日の設定等にルールがあります。適用の有無は企業規模、従業員数、委託内容などで異なるため、長い支払いサイトを設定する場合は法務担当者や専門家へ確認してください。

## 前払い・分割払い・月次払いの違い

発注者と開発会社のリスクを比較的均衡させやすいのは、成果確認と連動した分割払いです。ただし、すべての案件を分割払いにする必要はありません。短期間の小規模改修なら全額前払いまたは2回払い、要件が変化する開発なら月次払いの方が管理しやすい場合があります。

| 支払い方式 | 典型的な条件 | 向いている案件 | 発注者の利点 | 主な注意点 |
|---|---|---|---|---|
| 全額前払い | 契約時に100％ | 数日〜数週間の小規模作業、定型サービス | 請求処理が1回で済む | 中止・未完了時の返金条件が必要 |
| 納品後一括 | 検収後に100％ | 範囲が明確な短期開発 | 成果確認後に支払える | 開発会社の資金負担が大きく、受注不可や価格上乗せの可能性がある |
| 着手金＋残金 | 契約時20〜50％、検収後に残額 | 小〜中規模の請負開発 | 双方でリスクを分担しやすい | 着手金で何を実施するか明確にする |
| 工程別の分割払い | 要件確定、中間納品、検収などで分割 | 数か月以上の中〜大規模開発 | 進捗と支払いを連動できる | 工程の完了基準が曖昧だと争点になる |
| 月次払い | 毎月定額または実績工数で精算 | 準委任、アジャイル開発、継続改修 | 優先順位を変更しやすい | 総額と完成時期が固定されない場合がある |

アジャイル開発とは、短い期間で設計・開発・確認を繰り返し、優先順位を調整しながら作る進め方です。要件の変化を前提とするため、毎月のチーム費用を支払う方式と相性があります。

### 着手金20〜50％は目安であり、妥当性は内訳で判断する

システム開発の着手金は、契約金額の20〜50％程度で提案されることがあります。ただし、法定の割合や業界共通の基準があるわけではありません。次のような初期負担が大きいほど、着手金が高くなることには合理性があります。

- エンジニアやデザイナーを事前に確保する必要がある
- 開発環境や検証端末を新たに用意する
- 外部サービスの年間ライセンスを購入する
- 要件定義や設計を契約直後に集中的に行う
- 他案件を断って専任体制を組む

反対に、着手金の使途が説明されず、契約解除時の精算条項もないまま全額前払いを求められる場合は確認が必要です。全額前払い自体が問題なのではなく、案件規模、取引実績、返金条件、途中成果物の引き渡し条件との釣り合いで判断します。

### 工程別分割払いの設定例

6か月程度の請負開発なら、次のような支払いスケジュールが一例です。

| 時点 | 割合の例 | 支払い条件の例 |
|---|---:|---|
| 契約・着手時 | 20％ | 契約締結、開発体制の確保、着手 |
| 要件定義完了時 | 20％ | 要件定義書の提出と承認 |
| テスト環境への中間納品時 | 30％ | 主要機能の実装、所定のテスト結果の提出 |
| 本番納品・検収後 | 30％ | 受入テスト完了、重大な不具合の解消 |

割合をそのまま採用するのではなく、各工程までに投入される工数や外部費用に合わせて調整します。要件定義に多くの工数が必要な案件なら、要件確定時点までの割合が高くなることもあります。

重要なのは、支払いの節目であるマイルストーン（＝プロジェクト上の重要な到達点）を、単なる予定日ではなく確認可能な成果と結び付けることです。「4月末に30％」よりも、「4月末までに要件定義書を提出し、承認後に30％」の方が判断しやすくなります。

## 案件に合う支払い条件の決め方

支払い条件は、価格交渉の一部ではなく、プロジェクトの不確実性を分担する仕組みとして設計します。発注者に有利な後払いだけを求めると、開発会社が資金負担分を見積もりへ上乗せしたり、十分な体制を確保できなかったりする可能性があります。

### 1. 開発範囲と不確実性を確認する

作る機能、対象画面、外部システムとの連携、品質条件が具体的なら、請負契約と工程別分割払いを検討しやすくなります。反対に、利用者の反応を見ながら機能を変える新規サービスでは、月次払いで優先順位を調整する方が現実的です。

開発対象が曖昧な場合は、支払い交渉より先に範囲を整理します。具体的な方法は、[開発スコープの決め方｜要件定義前の整理手順](https://www.geek-bridge.com/column/development-scope-definition-guide)も参考にしてください。

### 2. 支払い単位ごとの成果物を決める

支払い単位ごとに、開発会社から受け取るものを列挙します。設計工程なら要件定義書、画面一覧、画面遷移図、データ項目一覧などが候補です。開発工程なら、テスト環境で操作できる機能、テスト結果、ソースコードの更新状況などを確認します。

ただし、文書の提出だけで工程完了とするのは不十分です。発注者が確認し、修正依頼を出し、承認する期間までスケジュールへ組み込みます。

### 3. 検収期間と修正の扱いを決める

検収期間は、案件規模に応じて5〜15営業日程度が設定例として考えられます。大規模な業務システムでは、部門横断の確認に数週間以上必要なこともあります。社内確認に必要な人数とシナリオ数から逆算してください。

契約前に、少なくとも次を決めます。

- 検収開始に必要な納品物
- 合格・不合格の判定基準
- 不具合と仕様変更の区別
- 不具合修正後の再確認方法
- 検収期間を延長できる条件
- 期間内に回答しない場合の扱い
- 軽微な不具合を残して検収する場合の対応期限

「検収に合格するまで支払わない」という条件だけでは、発注者がいつまでも回答しないリスクを開発会社が負います。反対に、納品の翌日に自動的に検収完了とする条件では、発注者が十分に確認できません。現実的な確認期間と、双方の連絡義務を定めることが大切です。

### 4. 変更・中止時の精算方法を決める

開発途中の仕様変更は、当初契約の支払い条件とは分けて管理します。追加作業の金額、納期への影響、支払い時期を書面で合意してから着手する運用が基本です。追加費用の判断方法は、[システム開発の追加費用相場｜発生原因と防ぎ方](https://www.geek-bridge.com/column/system-development-additional-cost-guide)で詳しく解説しています。

また、事業方針の変更で開発を中止する可能性にも備えます。中止時の精算では、次の項目を確認します。

- 中止日までに完了した作業の金額
- 発注済みで取消不能なライセンスや外注費
- 確保済み人員のキャンセル費用
- 未実施分の着手金を返金するか
- 作成途中の設計書やソースコードを引き渡すか
- 引き渡し時点での知的財産権と利用権

中止時の条件がないと、「成果物が完成していないため支払わない」という発注者の認識と、「人員を確保して作業したため全額を請求する」という開発会社の認識が衝突します。

## 契約・見積もりで確認すべき項目

支払い条件の確認では、契約書だけでなく、見積書、発注書、仕様書、開発スケジュールの記載を照合します。書類ごとに金額や支払日が異なる場合、どの文書を優先するか分からなくなるためです。

### 契約前チェックリスト

- [ ] 契約金額が税込・税別のどちらか明記されている
- [ ] 一括、分割、月次などの支払い方式が明記されている
- [ ] 各回の金額または割合が一致している
- [ ] 請求書の発行条件と提出期限が決まっている
- [ ] 締め日、支払日、振込手数料の負担者が明記されている
- [ ] 各支払いに対応する成果物または作業報告が定義されている
- [ ] 検収期間と合格基準が決まっている
- [ ] 不具合修正と仕様変更の扱いが区別されている
- [ ] クラウド、API、ライセンスなどの外部費用が分離されている
- [ ] 交通費や端末購入費などの実費精算条件がある
- [ ] 遅延時に支払い時期をどう調整するか決まっている
- [ ] 中途解約時の精算方法と成果物の引き渡し条件がある
- [ ] ソースコードや各種アカウントの引き渡し時期が明確である

### 見積もりでは支払い総額以外も比較する

同じ500万円の見積もりでも、「契約時に500万円」と「契約時100万円、要件確定時100万円、検収後300万円」では発注者のリスクが異なります。そのため、複数社を比較するときは、総額だけでなく資金の支出時期も一覧にします。

| 比較項目 | 確認する内容 |
|---|---|
| 初回支払額 | 契約時に必要な金額と算定根拠 |
| 支払い回数 | 社内の請求処理負担も含めて現実的か |
| 中間支払い | 確認できる成果物と連動しているか |
| 最終支払い | 納品時か、検収完了後か |
| 外部費用 | 開発費に含むか、実費で別請求か |
| 変更費用 | 事前承認なしに請求されない仕組みか |
| 解約精算 | 未実施分と実施済み分を区別できるか |

発注のご相談を受ける開発会社の立場では、支払い条件を柔軟に交渉できるかだけでなく、条件の根拠を説明できるかが重要だと考えます。工程表と支払いの節目が一致し、各時点で何を確認できるかを説明する会社は、進行管理の設計も具体的な傾向があります。

### 支払い条件から開発会社を見極めるポイント

次のような説明があるか確認してください。

- 着手金が必要な理由を、人員確保や外部費用と結び付けて説明できる
- 工程ごとの作業量と請求割合がおおむね対応している
- 月次払いの場合、作業報告と残工数を定期的に共有する
- 追加作業は見積もりと承認後に着手する運用がある
- 中止時に設計書やソースコードをどこまで渡せるか説明できる
- 発注者側の支払い規程も踏まえて代替案を提示できる

一方、次の場合は理由と契約内容を追加で確認します。

- 中規模以上の案件で、根拠なく全額前払いのみを求める
- 支払日だけがあり、成果物や作業内容との対応がない
- 見積書と契約書で支払い回数や金額が異なる
- 外部サービス費が概算のまま上限なく請求される
- 解約後に途中成果物を一切受け取れない
- 仕様変更の承認手順がなく、後からまとめて請求される

ただし、全額前払いや返金不可という条件だけで不適切とは判断できません。パッケージ製品のライセンス、定型診断、短期の調査など、着手時点で費用が確定するサービスでは合理的な場合があります。条件と案件の性質が一致しているかを見ます。

### よくある失敗と回避策

**予定日と工程完了を混同する**

「6月末に30％支払い」とだけ定めると、開発が遅れていても請求可能なのかが曖昧になります。予定日と成果条件を併記し、遅延時の再設定方法を決めます。

**発注者の確認遅れを想定していない**

担当者が多忙で承認できず、請求だけが止まることがあります。確認責任者と代理承認者を置き、回答期限を社内でも共有します。

**中間成果物を最終成果物と同じ感覚で検収する**

要件定義書を承認した時点では、システム全体が完成したわけではありません。各工程で確認できる範囲と、最終検収で確認する範囲を分けます。

**外部費用の発生時期を見落とす**

クラウド利用料、アプリストアの登録料、地図・決済・生成AIなどのAPI利用料は、開発費とは別に早期から発生することがあります。契約主体、請求先、利用上限を確認します。

**口頭で支払い条件を変更する**

納期変更や機能追加に伴って支払い時期を変更する場合は、メールだけで済ませず、変更契約書や合意書など記録が残る形にします。

支払い条件を含めて契約前に開発計画を整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。

## まとめ

- 支払い条件は、支払日だけでなく支払いの成立条件まで決めます
- 請負開発は成果確認と連動した分割払い、準委任開発は月次払いが適しています
- 着手金は20〜50％程度が提案例ですが、固定的な相場ではありません
- 中規模以上の開発では、要件確定や中間納品などの節目と支払いを連動させます
- 検収期間、不具合修正、仕様変更、中止時の精算条件を契約前に明文化します
- 総額が同じでも、前払い割合や最終支払いの条件によって発注リスクは変わります
- 開発会社は、着手金や支払い割合の根拠を説明できるかで見極めます

支払い条件は、発注者が一方的に支払いを遅らせるためのものでも、開発会社が早く代金を回収するためだけのものでもありません。開発の進捗と成果を双方で確認し、継続可否を判断する仕組みとして設計することが、安定したプロジェクト運営につながります。

## よくある質問

### システム開発費は前払いが一般的ですか？

一律ではありません。短期間の小規模開発は全額前払いまたは着手金と残金の2回払い、中規模以上の請負開発は工程ごとの分割払い、準委任開発は月次払いが選ばれやすい傾向です。

### 着手金は何％が妥当ですか？

一般的な提案例としては契約金額の20〜50％程度ですが、明確な相場があるわけではありません。初期に必要な人員確保、外部ライセンス、機材などの根拠と、未実施分の精算条件を確認して判断します。

### 開発が遅れた場合も予定どおり支払う必要がありますか？

契約に定めた支払い条件によります。日付だけで支払う契約か、成果物の完成や検収を条件とする契約かを確認し、遅延原因が発注者側と開発会社側のどちらにあるかも整理して協議します。

### 月次払いでも検収は必要ですか？

準委任契約の月次払いでは、完成した機能の検収ではなく、作業報告書や稼働実績の確認を支払い条件にするのが一般的です。ただし、リリース前には別途受入テストや品質確認を設ける必要があります。