システム開発の契約書チェックポイント10選｜発注者が見落としがちな条項と交渉のコツ
開発会社から契約書のドラフトが届いた。ページを開いてみたはよいが、「請負型」「準委任型」「契約不適合責任」「知的財産権の帰属」——馴染みのない専門用語が並んでいて、どこから読み解けばよいかわからない。そんな経験をお持ちの方は少なくないはずです。
法律の専門家でなければ、システム開発の契約書を一から読み込むのは難しいものです。しかし、「よくわからないからとりあえずサインしてしまった」という選択は、後から深刻なトラブルを招く原因になりかねません。
実際、システム開発に関するトラブルの多くは、契約締結前のチェックが不十分だったことに起因しています。特に「開発範囲の曖昧さ」「知的財産権の取り決め不足」「契約不適合責任の範囲の誤解」は繰り返し問題になりやすい領域です。
この記事では、法務の専門知識がなくても実践できる、発注者が最低限確認すべき契約書10大チェックポイントを解説します。さらにNDA・知財・契約不適合責任という3大トラブル条項の読み方と、契約締結前の実践的な確認フローも紹介します。読み終えたあとには、開発会社との交渉で必要な「判断基準」が手に入ります。
目次
システム開発契約の種類を3分で理解する
チェックポイントを確認する前に、契約の基本構造を押さえておきましょう。契約の種類を理解することで「なぜその条項が発注者にとってリスクになるのか」が理解しやすくなります。
請負契約と準委任契約の違い（発注者リスク視点）
システム開発における契約は、大きく「請負契約」と「準委任契約」の2種類に分けられます。
請負契約は「成果物の完成」を目的とする契約です。開発会社（受注者）は完成したシステムを納品する義務を負い、完成しなければ報酬を受け取れません。発注者にとっては「完成物に対してお金を払う」形式であるため、品質保証の面で有利に見えます。しかし一方で、仕様変更が発生した場合に「当初契約の範囲内か否か」の判断が難しく、追加費用をめぐるトラブルが起きやすいという特徴もあります。
準委任契約は「業務の遂行」を目的とする契約です。開発会社は一定の作業を行えば報酬を受け取れるため、成果物の完成は保証されません。要件定義など「正解が事前に確定しない工程」に適しており、IPAの「情報システム・モデル取引・契約書」でも要件定義工程には準委任型が推奨されています（IPA 独立行政法人情報処理推進機構）。
発注者リスクの違いを端的に言うと、請負では「完成しないリスク」が受注者側に、準委任では「品質・完成リスク」が発注者側にかかります。契約書で「何工程をどちらの契約形態で行うか」を確認し、リスク配分を意識することが大切です。
基本契約と個別契約の役割分担
多くの場合、システム開発では「基本契約書」と「個別契約書（個別発注書）」の2層構造を使います。
- 基本契約書: 取引全体に共通するルール（知的財産権・秘密保持・損害賠償・解除条件など）を定める
- 個別契約書: 各フェーズごとの具体的な作業範囲・納期・報酬額を定める
2つが矛盾した場合どちらが優先されるか、必ず確認してください。「個別契約書が優先」とされることが多いですが、明記されていない場合はトラブルの種になります。
「多段階契約」が推奨される理由
IPAのモデル契約書では、システム開発を「要件定義フェーズ」「設計・開発フェーズ」「テスト・検収フェーズ」などに分けて個別に契約する「多段階契約」を推奨しています。
一括で全工程を契約してしまうと、要件定義の段階で発生した仕様変更が後工程のコストや納期に影響しても、変更費用を請求する根拠が曖昧になりやすいためです。フェーズごとに契約を分けることで、各工程の責任範囲と費用が明確になります。
発注者が必ず確認すべき契約書10大チェックポイント
それでは、契約書を受け取ったときに確認すべき10のポイントを見ていきましょう。各ポイントには「危険シグナル（こう書かれていたら要注意）」と「修正の方向性」を付記します。
①開発範囲の明確性（何を作るのかの特定）
確認内容: 開発対象のシステム・機能が仕様書や要件定義書として明文化されており、契約書に添付または参照されているか。
危険シグナル: 「別途協議の上で定める機能を開発する」など、開発範囲が契約書単体では判断できない場合。
修正の方向性: 契約書に別紙として仕様書（少なくとも機能一覧レベルの概要版）を添付し、参照先を明記するよう求める。「仕様の変更が発生した場合は書面で合意する」条項も必須です。
②仕様変更時の取り扱い（追加費用発生ルール）
確認内容: 開発途中で仕様変更が発生した場合、追加費用の発生条件と金額決定プロセスが定められているか。
危険シグナル: 仕様変更への言及がない、または「合理的な範囲での変更は受け入れる」など曖昧な記述のみ。
修正の方向性: 「変更依頼は書面で行い、費用・スケジュールへの影響を相互合意した上で実施する」という変更管理条項を明記するよう求める。アジャイル開発の場合は特に重要です。
③納期と遅延時の対応
確認内容: 各フェーズの納期が明示されており、遅延が発生した場合の対応（ペナルティ・契約解除条件など）が定められているか。
危険シグナル: 「見込みでの納期提示」「納期は変更する場合がある」など、納期の拘束力が弱い記述。
修正の方向性: 納期を確定値として記載し、遅延日数に応じた損害賠償条項を求める。ただし不可抗力（自然災害・感染症等）の免責条項とバランスをとることも重要です。
④検収基準と検収期間
確認内容: 納品後の検収基準（何をもって「完成」とみなすか）と検収期間（何日以内に検収を完了するか）が明確に定められているか。
危険シグナル: 検収基準が「発注者の承認」のみ、または検収期間が定められていない。
修正の方向性: 検収基準には「仕様書に記載された機能が動作すること」など客観的な基準を設ける。検収期間（一般的には2〜4週間）と、期間満了時に検収報告がない場合の取り扱いも明記する。
⑤知的財産権の帰属（著作権・特許権）
確認内容: 開発されたシステムのプログラム著作権・特許権がどちらに帰属するか。発注者が将来的に修正・改変・再委託を行う際に制限が生じないか。
危険シグナル: 「開発会社に帰属する」「開発会社の事前承諾が必要」など、発注者の利用に制限がかかる記述。
修正の方向性: 開発費用を全額負担する場合は著作権の発注者への譲渡を求める。完全譲渡が難しい場合でも「修正・改変・再委託・複製の許諾を含む通常実施権」を明確に確保する。既存コンポーネント（ライブラリ・フレームワーク）については開発会社に権利が残ることが一般的なので、「バックグラウンドIP」の扱いも確認しましょう。
詳しい知的財産権の取り扱いについては、システム開発の著作権は誰のもの？発注者が知っておきたい権利帰属と契約のポイントをご参照ください。
⑥秘密保持義務（NDA）の有効期間と対象情報
確認内容: 秘密保持の対象となる情報の範囲、有効期間（契約終了後も継続するか）、下請けへの開示可否が明記されているか。
危険シグナル: 秘密情報の定義が「双方が秘密と指定したもの」だけで、口頭で共有した情報が保護されない可能性がある。また有効期間が「契約期間中のみ」で終了後の保護がない。
修正の方向性: 秘密情報の定義を「口頭・書面・電磁的方法を問わず開示された情報」と広く設定する。有効期間は「契約終了後2〜3年」の継続が一般的です。再委託先への開示については「事前書面承諾＋同等の義務を再委託先に課す」条項を求める。
⑦契約不適合責任の範囲と期間
確認内容: 納品後に不具合が発覚した場合、開発会社が負う責任の範囲（修補・損害賠償等）と通知期限が定められているか。
危険シグナル: 「納品後6か月以内の通知のみ有効」など、発注者にとって不合理に短い期限設定。
修正の方向性: 2020年の民法改正により、契約不適合責任の追及は「不適合を知ったときから1年以内の通知」で権利を保全できます（Authense法律事務所の解説）。ただし、この民法の規定より短い期限を契約書で定めることは有効なため、特約で短縮されていないか必ず確認しましょう。SLAとの関係についてはシステム開発・保守契約のSLAガイドも参照してください。
⑧損害賠償の上限と範囲
確認内容: 損害賠償の上限額と免責条項が定められているか。上限が不当に低くないか。
危険シグナル: 損害賠償額が「支払済み報酬額の50%まで」など、実損害と比べて著しく低い場合。または「いかなる場合も責任を負わない」という広すぎる免責条項。
修正の方向性: 上限額は「契約金額と同額程度」が一般的な落としどころです。特に重大な過失（故意・重過失）による損害は免責対象外とする条項を加えることを求める。
⑨再委託の可否と承認ルール
確認内容: 開発会社が業務を第三者（下請け）に再委託する場合の承認プロセスが定められているか。再委託先の管理責任が明示されているか。
危険シグナル: 再委託について言及がなく、契約書の記載から再委託を自由に行えると解釈できる。
修正の方向性: 「事前書面承諾制」を求める。再委託先が業務を実施する場合でも、発注者に対する責任は元の開発会社が負うことを明記する。
⑩契約解除条件と代金の扱い
確認内容: 契約を途中で解除できる条件（発注者都合・受注者都合・双方合意）と、その場合の既払い代金・未払い代金の精算方法が定められているか。
危険シグナル: 「発注者都合の解除時は全額支払い済み」「解除後の清算規定なし」など、発注者が不利な形での解除条件。
修正の方向性: 発注者都合での解除時も、完了した作業分のみ支払う「比例按分精算」条項を求める。開発会社側の重大な義務違反（納期の著しい遅延・品質の著しい不足）による解除では損害賠償請求ができる旨を明記する。
特にトラブルになりやすい3大条項の読み方
上記10項目の中でも、特にトラブルに発展しやすい3つの条項について、「危険な文言例」と「安全な文言例」を対比しながら解説します。
NDA（秘密保持契約）で見落としやすい落とし穴
システム開発では、発注者側の業務フロー・顧客データ・システム設計など機密性の高い情報を開発会社と共有します。NDAの条項で特に注意すべき点は以下の3つです。
落とし穴1: 秘密情報の定義が狭すぎる
- 危険な文言: 「書面で『秘密』と明示された情報のみを秘密情報とする」
- 安全な文言: 「開示された情報は、口頭・書面・電磁的手段を問わず、相手方が秘密と指定したものを秘密情報とする」
口頭での打ち合わせや画面共有で伝えた情報が「書面で明示」されていない場合、保護対象外になるリスクがあります。
落とし穴2: 有効期間が短すぎる
- 危険な文言: 「本義務は本契約の存続期間中のみ有効とする」
- 安全な文言: 「本義務は本契約の終了後3年間も継続して有効とする」
開発完了後にも機密情報は残ります。契約終了後の保護期間がない場合、元従業員や再委託先を経由した情報漏洩リスクが残ります。
落とし穴3: 再委託先への義務が不明確
開発会社が下請けに業務を委託する場合、下請けがNDAに拘束されていないケースがあります。「再委託先に対しても本NDAと同等の秘密保持義務を課す」条項が入っているか確認してください。
知的財産権の帰属 — ソースコードの所有権は誰のもの？
「開発費用を払ったのだから、そのシステムは当然自社のもの」と考えている発注者は多いですが、法律上はそうとは限りません。著作権法の原則として、プログラムの著作権は作成者（開発会社）に自動的に帰属します。
つまり、契約書に「著作権は発注者に帰属する」と明記されていなければ、お金を払ってシステムを作ってもらっても、そのソースコードを自由に修正・複製・再委託することができなくなる可能性があります。
確認すべき3点
- 著作権譲渡の有無: 「成果物の著作権は、代金支払い完了をもって発注者に移転する」と書かれているか
- 改変権の明記: 著作権が完全譲渡されない場合でも、「発注者は成果物を修正・改変・複製できる」という利用許諾が明記されているか
- ソースコードの納品: ソースコードが納品物に明示されているか（バイナリのみの納品では後から修正できない）
契約不適合責任 — 民法改正後に変わったポイントと交渉のコツ
2020年4月の民法改正で、「瑕疵担保責任」は「契約不適合責任」に置き換わりました。発注者にとって最も重要な変更点は「権利行使の起算点」です。
- 改正前（瑕疵担保責任）: 納品時から1年以内の請求が必要
- 改正後（契約不適合責任）: 不適合を「知った時から1年以内の通知」で権利を保全可能。その後、消滅時効（納品から10年）の範囲で権利行使できる
これは発注者にとって有利な改正ですが、契約書に「納品後1年以内」などの特約があると、法律の規定より短い期間に短縮されてしまいます（EGG SYSTEMの解説）。
交渉のポイント: 特約で短縮されている場合は「納品後2年間は契約不適合責任を負う」など延長を求める。また、責任の内容として「修補請求・代替品請求・損害賠償請求・契約解除」の4つが明記されているか確認する。
契約締結前の5ステップ確認フロー
契約書ドラフトを受け取ってから署名するまでの実践的な手順を5ステップで整理します。
ステップ1 — 契約種類と基本構造の確認
まず「何の契約書か」を確認します。
- 請負型 or 準委任型か
- 基本契約書 + 個別契約書のどちらか、または一本化か
- 複数の契約書がある場合の優先関係
この段階で構造を把握できれば、次のチェックがスムーズになります。
ステップ2 — 10大チェックポイントの照合
本記事の10大チェックポイントを参照しながら、各条項が存在するか、内容が適切かを確認します。チェックしながら「不明点」「懸念点」をリストアップしてください。
目安として、一通り確認するのに半日〜1日程度見ておきましょう。
ステップ3 — 曖昧な表現をリストアップ
「別途協議する」「合理的な範囲で」「善意の管理」など、判断基準が曖昧な表現を全てリストアップします。これらの表現はトラブル発生時に解釈の食い違いを生む原因になります。
ステップ4 — 修正依頼事項の整理と優先度付け
ステップ2・3でリストアップした懸念点を「必須修正」「できれば修正」「確認したい」の3段階に分けます。
必須修正の例: 知的財産権の帰属が明記されていない、契約不適合責任の期間が著しく短い できれば修正の例: NDAの有効期間の延長、損害賠償上限の引き上げ 確認したい例: 特定の契約用語の意味、再委託先の具体的な企業
ステップ5 — 専門家（弁護士）への依頼判断基準
以下に当てはまる場合は、弁護士への相談を強くおすすめします。
- 契約金額が1,000万円以上の大型案件
- 社内に機密性の高い情報（顧客データ・独自アルゴリズム等）が含まれる
- ステップ4で「必須修正」が3項目以上ある
- 開発会社が修正依頼に応じない
弁護士費用は一般的に契約書レビューで3〜10万円程度ですが、契約トラブルが訴訟に発展した場合の費用（数百万円〜）と比較すれば、はるかに低リスクな投資です。
まとめ — 契約書の確認は「発注成功」の起点
システム開発の契約書チェックは、トラブルを未然に防ぐためだけのものではありません。「この発注者はきちんと契約内容を理解している」と開発会社に伝わることで、プロジェクト全体の管理水準が上がり、信頼関係を早期に構築できるという効果もあります。
本記事で解説した10大チェックポイントをまとめます。
# |
チェックポイント |
最重要確認事項 |
|---|---|---|
① |
開発範囲の明確性 |
仕様書が契約書に添付・参照されているか |
② |
仕様変更の取り扱い |
変更管理条項（書面合意・費用決定プロセス）があるか |
③ |
納期と遅延対応 |
納期が確定値で記載されているか |
④ |
検収基準と検収期間 |
客観的な検収基準と期間が明記されているか |
⑤ |
知的財産権の帰属 |
著作権の帰属先と改変権が明記されているか |
⑥ |
NDA（秘密保持） |
定義・有効期間・再委託先への義務が適切か |
⑦ |
契約不適合責任 |
民法より不当に短縮されていないか |
⑧ |
損害賠償の上限 |
上限額が実損害と乖離していないか |
⑨ |
再委託の可否 |
事前承諾制と再委託先の責任規定があるか |
⑩ |
契約解除条件 |
比例按分精算など公平な精算ルールがあるか |
システム開発の発注を検討されている方は、ぜひこのチェックリストを手元に契約書の確認を進めてみてください。不明点は開発会社に質問し、必要であれば弁護士に相談することで、契約締結後のトラブルリスクを大きく下げることができます。
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
