システム開発の契約書で確認すべき条項と注意点
「開発会社から契約書のひな形が届いたが、どこを見ればよいのかわからない」「法務担当がいないので、そのまま押印してよいか不安」。システム開発の契約書は専門用語が多く、発注者が内容を十分に理解しないまま締結してしまうケースが少なくありません。
この記事では、システム開発の契約書で発注者が必ず確認すべき条項を12項目に整理し、それぞれの注意点と、トラブルになりやすい書き方を解説します。2026年1月に施行された取適法（旧下請法）との関係にも触れます。
- 契約書は「何を・いつまでに・いくらで・どう終わらせるか」を決める文書。業務範囲と検収条件が最重要
- 請負か準委任かで、完成責任や契約不適合責任の有無が変わる。工程ごとに契約形態を分けるのが一般的
- 知的財産権・ソースコードの引き渡し・損害賠償の上限は、後から変更しにくいので締結前に必ず確認
- 不明点は押印前に質問し、口頭の約束は議事録や覚書で書面に残す
目次
システム開発の契約書とは
システム開発の契約書とは、発注者と開発会社の間で、開発する範囲・納期・費用・成果物の権利・責任の分担などを取り決めた文書です。システム開発は、完成品を買う取引と違って、作りながら内容が固まっていく性質があります。そのため「どこまでが契約の範囲か」「完成したと言えるのはどの時点か」があいまいだと、追加費用や納期遅延をめぐるトラブルにつながります。
契約書は、一般に「基本契約書」と「個別契約書」の2段構えで作られます。基本契約書には取引全体の共通ルール（権利、秘密保持、損害賠償など）を定め、個別契約書には工程ごとの業務内容・金額・納期を定めます。
基本契約と個別契約の役割分担
| 区分 | 主な記載内容 | 締結のタイミング |
|---|---|---|
| 基本契約書 | 契約形態の考え方、知的財産権、秘密保持、損害賠償、解除、再委託、紛争解決 | 最初の取引開始時に1回 |
| 個別契約書（注文書・注文請書） | 対象工程、業務範囲、成果物、金額、支払条件、納期、検収方法 | 要件定義・設計・開発など工程ごと |
| 付属資料 | 要件定義書、見積書、提案書、体制表 | 個別契約に添付 |
発注者が確認すべき12の条項
ここからは、契約書の中でも特に発注者への影響が大きい条項を順に見ていきます。
1. 契約形態（請負か準委任か）
請負契約は「成果物の完成」に対して報酬を支払う契約で、開発会社に完成責任があります。準委任契約は「業務の遂行」に対して報酬を支払う契約で、完成責任はありませんが、専門家として注意を尽くす義務（善管注意義務）があります。要件定義は準委任、設計〜テストは請負、というように工程ごとに使い分けるのが一般的です。
関連記事請負と準委任の違い｜システム開発での使い分けと注意点
2. 業務範囲と成果物
もっともトラブルが多いのがこの条項です。「システム一式」のような表現では、データ移行・操作マニュアル・利用者研修・本番環境の構築が含まれるのか判断できません。含むもの・含まないものを一覧にし、要件定義書や見積書を契約書の添付資料として位置づけておきます。
3. 納期とスケジュール
最終納期だけでなく、主要な中間成果物の提出日や、発注者側の確認期限も記載します。発注者の確認や資料提供が遅れた場合に納期がどう扱われるかも確認しておきましょう。
4. 金額と支払条件
一括払いか、着手金・中間金・検収後払いの分割かを確認します。準委任契約の場合は、月額・人月単価・想定工数と、超過した場合の精算方法を明記します。
5. 仕様変更・追加費用の手続き
開発途中の仕様変更は避けられません。変更の申し入れ方法、影響範囲（費用・納期）の見積もり、双方の書面合意を経て反映する、という手続きを定めておくと、後から「言った・言わない」になりにくくなります。
6. 検収（受入テスト）の条件と期間
検収とは、納品された成果物が仕様どおりかを発注者が確認し、受け入れる手続きです。検収期間（例：納品後10営業日以内など）と、期間内に不合格の通知がなければ合格とみなす「みなし検収」の有無を確認します。みなし検収がある場合は、社内で確認体制を事前に用意しておく必要があります。
7. 契約不適合責任
2020年4月の民法改正で「瑕疵担保責任」は「契約不適合責任」に改められました。納品物が契約内容に適合しない場合に、発注者は修補（修正）や代金減額、損害賠償、解除を求めることができます。民法上は「不適合を知った時から1年以内に通知」が原則ですが、契約で「検収後6か月以内」などと短縮されていることが多いため、期間の起算点と長さを必ず確認します。
8. 知的財産権（著作権）の帰属
プログラムの著作権は、特に定めがなければ作成した開発会社に残ります。発注者に移転するのか、開発会社に残して発注者は利用権を得るのかを明記します。開発会社が汎用的に使う部品（ライブラリ等）は開発会社に留保し、案件固有部分を発注者に移転する形が一般的です。
9. ソースコード・設計書の引き渡し
著作権の条項とは別に、ソースコードや設計書を納品物に含めるかを確認します。引き渡しがないと、将来ほかの会社に保守を依頼したり、リプレイスしたりする際に大きな障害になります。
10. 損害賠償の範囲と上限
多くの契約書では、損害賠償額の上限を「当該個別契約の代金額」とする条項が入っています。上限の有無、対象となる損害の範囲、故意・重過失の場合は上限を適用しない定めがあるかを確認します。
11. 再委託
開発会社が業務の一部を別の会社に委託する（再委託する）ことを認めるか、認める場合は事前の承諾を必要とするかを定めます。個人情報や機密情報を扱うシステムでは特に重要です。
12. 秘密保持・解除・紛争解決
秘密保持の対象と期間、契約を途中で解除できる条件と、その場合の費用精算方法、紛争時の管轄裁判所を確認します。途中解除時に「それまでの成果物を引き渡してもらえるか」は見落としやすいポイントです。
押印前のチェックリスト
- 業務範囲：含むもの・含まないものが一覧になっているか
- 契約形態：工程ごとに請負・準委任が明記されているか
- 変更手続き：仕様変更時の見積もりと合意方法が決まっているか
- 検収：検収期間・合格基準・みなし検収の有無を確認したか
- 契約不適合責任：通知期間と起算点を確認したか
- 権利：著作権の帰属とソースコードの引き渡しが明記されているか
- 損害賠償：上限額と対象範囲を確認したか
取適法（旧下請法）との関係
2026年1月1日から、下請法は「中小受託取引適正化法（通称：取適法）」に改められました。プログラムの作成を委託する取引は「情報成果物作成委託」として対象になり得ます。2026年9月時点の公表資料では、資本金基準に加えて従業員数基準（プログラム作成の委託では、委託側が300人超・受託側が300人以下）が追加されています。
対象となる場合、発注側には発注内容の明示や支払期日の設定（受領から60日以内）などの義務があり、手形での支払いや、協議に応じない一方的な代金決定などが禁止されます。多くの中小企業の発注では対象外となりますが、自社の規模によっては委託事業者に該当する可能性があるため、法務部門や専門家に確認してください。
契約トラブルを防ぐための進め方
- 契約前に要件と範囲を文書化要件定義書・見積書の前提条件を確認し、契約書の添付資料にする
- ひな形を早めに受け取る発注直前ではなく、見積もり比較の段階で契約書案を入手し検討時間を確保する
- 疑問点を書面で質問回答はメールや議事録で残し、必要に応じて契約書に反映する
- 変更は覚書で管理開発中の変更は、都度覚書や変更合意書で費用・納期を確定させる
関連記事システム開発で追加費用が発生する理由と防ぐ契約・進め方
よくある質問
- 開発会社の契約書ひな形を修正してもらうことはできますか？
- 可能です。契約書は双方の合意で内容を決めるものなので、発注者から修正を依頼するのは一般的です。修正したい条項と理由を具体的に伝えると、交渉がスムーズに進みます。
- 注文書と注文請書だけで契約しても問題ありませんか？
- 小規模な案件ではよく見られますが、知的財産権や契約不適合責任などが定められていないことが多く、トラブル時の判断基準がありません。継続的な取引になる場合は基本契約書を締結しておくのが安心です。
- 契約不適合責任の期間はどのくらいが一般的ですか？
- システム開発では、検収後6か月から1年程度とする契約がよく見られます。期間が短すぎると本番運用で見つかった不具合に対応してもらえない可能性があるため、業務の繁忙期なども考慮して確認しましょう。
- ソースコードの引き渡しは必ず求めるべきですか？
- 将来の保守会社の変更やリプレイスを考えると、引き渡しを受けておくことをおすすめします。引き渡しがないと、改修のたびに同じ会社に依頼せざるを得ない状態になりやすいためです。
まとめ
システム開発の契約書は、業務範囲・契約形態・検収・契約不適合責任・知的財産権・損害賠償の6点を中心に確認すると、主要なリスクを押さえられます。契約書は開発会社を疑うためのものではなく、双方の認識をそろえるための道具です。不明点は押印前に質問し、変更は書面で残す習慣をつけましょう。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
