LASSIC Media らしくメディア
システム開発の契約書で発注側が確認すべきチェックポイント｜検収・知財・契約不適合責任
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 検収条件・知的財産権・契約不適合責任など、発注側が見落としがちな6項目を体系的に整理しています。
- 改正民法（2020年4月施行）の契約不適合責任が請負契約にどう適用されるか、条文ベースで確認できます。
- IPA「情報システム・モデル取引・契約書（第二版）」を参照軸に置き、実務で使える確認軸を提示しています。
目次
システム開発契約書でまず確認すべき全体像
システム開発の契約書チェックポイントとは、発注側がベンダーから提示された契約書を締結前に確認すべき条項の観点を指します。検収条件・知的財産権の帰属・契約不適合責任・再委託・秘密保持・中途解約の6項目が実務上の主要な確認軸です。
契約書レビューが発注側にとって重要な理由
システム開発では、契約締結後に「想定していた機能が納品されていない」「著作権がベンダーに残っていた」「プロジェクトが中断したのに多額の損害賠償を請求された」といった紛争が起きやすいです。こうしたリスクの多くは、契約書の条項を事前に確認・修正することで回避できます。
ベンダーが提示する契約書は、ベンダー側に有利な条件を含んでいる場合があります。発注側が何も確認せず署名すると、後に不利な立場に置かれる可能性があります。特に初めてシステム開発を発注する企業ほど、この点を見落としがちです。
チェックポイント6項目の確認方法
本記事では、①検収条件、②知的財産権の帰属、③契約不適合責任、④再委託条項、⑤秘密保持条項（NDA）、⑥中途解約条項の6項目を順に解説します。各項目で「なぜその条項が重要か」「どう修正を要求すべきか」を具体的に示しています。
参照軸として、IPA（独立行政法人情報処理推進機構）が公開する「情報システム・モデル取引・契約書（第二版）」（2020年12月公表、2025年6月最終更新）を活用します。この資料はユーザ企業・ITベンダーのどちらにも偏らない中立的なモデル契約書であり、改正民法への対応も組み込まれています。
検収条件——合格基準を数値で定める
曖昧な検収条項が招くトラブル
検収とは、ベンダーから納品された成果物が仕様を満たしているかを発注側が確認し、合否を判定するプロセスです。検収が完了するとベンダーへの代金支払義務が確定し、契約不適合責任の期間カウントが始まります。
よくある問題は「検収基準が明記されていない」ケースです。「仕様書に準拠していること」という文言のみでは、ベンダーは「仕様通りに作った」と主張し、発注側は「想定していた動作と違う」と主張する水掛け論が発生します。こうした紛争は当事者間での解決が難しく、法的手続きに至るケースもあります。
合格基準・検収期間・みなし検収条項の確認方法
契約書に検収に関する条項が含まれている場合は、以下の3点を確認してください。
（1）合格基準の明記：「レスポンス時間が3秒以内であること」「テスト仕様書に記載した全テストケースを通過すること」のように、客観的に判定できる数値や文書を基準とすることが大切です。「正常に動作すること」という定性表現は解釈の幅が生じるため、具体的な仕様書・テスト仕様書を契約書の別紙として添付し、それを基準とする形にします。
（2）検収期間の設定：納品から検収完了までの期間（例：「納品後14営業日以内」）を明記します。期間が短すぎると発注側の確認が不十分になりますし、長すぎるとベンダーの次案件への着手が遅れます。プロジェクト規模に応じた合理的な期間を設定してください。
（3）みなし検収条項の確認：みなし検収条項とは、納品から一定期間内に発注側から合否の通知がなければ検収完了と「みなす」規定です。ベンダー側にとって有利な条項であり、見落とすと発注側が気づかないうちに検収が完了してしまいます。条項の有無を確認し、期間が過剰に短い場合は修正を交渉してください。
知的財産権の帰属——開発成果物は誰のものか
著作権は自動では発注側に移転しない
システム開発では、ベンダーの従業員が作成したプログラムや設計書の著作権は、原始的にベンダーに帰属します。発注側が開発費を全額負担しても、著作権法上は自動的に発注側に移転しません。これはソフトウェア開発に限らず、著作物全般に共通するルールです。
著作権がベンダーに残ったままでは、発注側はそのシステムを改修・保守するときに毎回ベンダーの許諾が必要になります。また、ベンダーが倒産・廃業した場合は許諾を得る相手がいなくなり、システムの維持管理が困難になるリスクがあります。
「譲渡」と「利用許諾」の違いと契約書への明記
発注側が取り得る選択肢は大きく2つです。1つ目は著作権の「譲渡」で、開発成果物の著作権を発注側に移転させます。2つ目は「利用許諾（ライセンス）」で、著作権はベンダーに残しつつ、発注側が利用できる権利を受ける形です。
完全な権利確保を望む場合は著作権譲渡を選択しますが、ベンダーが自社のフレームワークやライブラリを流用している場合は、それらをまとめて譲渡することが技術的・商業的に難しいケースもあります。その場合は「汎用部分はベンダーに残し、発注側固有の開発部分のみ譲渡する」という折衷案が現実的です。
いずれの選択をするにしても、契約書に「著作権（著作権法第27条・第28条所定の権利を含む）は、検収完了時に発注者に移転する」のように明示することが必要です。著作権法27条（翻案権）・28条（二次的著作物の利用権）を含める旨を明記しないと、プログラムを改変する権利が移転しない場合があります。
| 権利処理の方式 | 発注側のメリット | 発注側のデメリット・注意点 |
|---|---|---|
| 著作権譲渡 | 自由に改修・再利用が可能。 第三者への再使用許諾もできる。 |
ベンダーが難色を示す場合が多い。 汎用ライブラリ部分は譲渡対象外が現実的。 |
| 独占的利用許諾 | 競合他社への同一技術の提供を防げる。 著作権はベンダーに残る。 |
許諾範囲・期間・地域を明記する必要がある。 ベンダーの倒産時のリスクが残る。 |
| 非独占的利用許諾 | 費用交渉で譲渡より低額になることが多い。 | 同じ成果物を競合他社に提供される可能性がある。 改修権が限定される場合がある。 |
契約不適合責任——改正民法に対応しているか
旧瑕疵担保から契約不適合責任への変更（民法562条〜566条）
2020年4月に施行された改正民法では、従来の「瑕疵担保責任」が「契約不適合責任」に改められました。この変更はシステム開発委託にも直接影響します。改正民法559条により、売買契約の規定（562条〜566条）は請負契約にも準用されるためです。
旧民法の瑕疵担保責任では「隠れた瑕疵」であることが要件でしたが、改正後の契約不適合責任では「種類、品質又は数量に関して契約の内容に適合しないもの」であれば足り、「隠れているか否か」を問いません。発注側が発見しやすい不具合も責任の対象になります。
改正民法562条〜566条が定める買主（発注側）の権利は次のとおりです。
- 追完請求権（562条）：修補・代替成果物の引渡し・不足分の引渡しを請求できます。
- 代金減額請求権（563条）：追完を催告して一定期間内に対応がない場合、不適合の程度に応じて代金の減額を請求できます。
- 損害賠償・解除権（564条）：一般の債務不履行規定（415条・541条・542条）に基づき、損害賠償請求や契約解除を行使できます。
- 期間制限（566条）：不適合を知った時から1年以内に売主（ベンダー）へ通知しなければ、上記の権利を失います。
これらの規定は当事者間で別段の定めが可能です。ただし、消費者契約（企業対個人）とは異なり、企業間取引では特約による制限も有効です。発注側として、以下の条件を契約書で確認・修正することが大切です。
システム開発特有の適用ポイントと期間制限
企業間取引のシステム開発では、商法526条により「納品後直ちに」検査・通知を行うことが原則です。一方、民法566条の1年通知ルールは商法の特則として機能し、不具合の発見が遅れた場合でも「知った時から1年以内」の通知があれば権利を保持できます。
契約書に「検収後90日間」などの短い保証期間が設けられている場合、それは民法566条より短く発注側に不利な特約です。特に「バグ修正期間はリリース後6か月以内に限る」といった条項は、長期にわたる品質問題への対処を制限します。IPA「情報システム・モデル取引・契約書（第二版）」では、契約不適合責任の期間について当事者間の合意を前提とした条項案が示されており、参照して適切な期間を設定することをお勧めします。
また、ベンダー提示の契約書に「ベンダーの責任は直接損害に限る」「損害賠償額は請負代金の範囲内に限定する」などの免責条項が盛り込まれている場合があります。これ自体は業界慣行上許容される範囲もありますが、発注側として重大なリスクを招く内容でないかを確認してください。
再委託条項——開発を外注される範囲と管理責任
再委託の無制限許容が生むリスク
システム開発では、ベンダーが作業の一部を別の会社（再委託先）に外注することが一般的です。発注側がAという会社と契約しても、実際の開発は面識のないB社・C社が担当する状況が生じます。
再委託を無制限に許容する条項では、発注側の秘密情報・個人データが再委託先に渡るリスクがあります。再委託先がセキュリティ管理の不十分な会社であった場合、情報漏洩の被害を受けても発注側は再委託先に直接請求できません。また、再委託先の品質が低ければプロジェクト全体の品質に影響しますが、発注側は再委託先を直接管理する立場にありません。
事前承認条項・義務の流し下げ確認
発注側として、再委託条項には以下の内容が含まれているかを確認してください。
（1）発注側への事前承認義務：ベンダーが再委託する場合は、発注側の書面による事前承認を必要とする条項です。この条項があれば、発注側は再委託先の信頼性・実績を審査した上で許可・不許可を判断できます。
（2）義務の流し下げ義務：ベンダーが再委託先に対して、守秘義務・セキュリティ対策義務・個人情報保護義務を同等以上の内容で課す義務を明記させてください。これにより、再委託先でセキュリティ事故が起きた場合もベンダー経由で責任追及が可能になります。
（3）再委託先リストの開示：プロジェクト開始時に再委託先の一覧を発注側に開示する義務を加えることも有効です。すべての再委託を事前承認する負担を避けながら、透明性を確保できます。
秘密保持条項（NDA）——情報管理の範囲と期間
秘密情報の定義が曖昧だと何が起きるか
秘密保持条項（NDA：Non-Disclosure Agreement）は、システム開発に関して開示した業務情報・技術情報・個人情報などを相手方が第三者に漏洩しないことを義務付ける条項です。
問題が起きやすいのは「秘密情報の定義」が曖昧な場合です。「秘密と指定した情報のみ」という条項では、口頭で伝えた重要な仕様や会議で共有した顧客データが対象外になる可能性があります。発注側の秘密情報の多くは口頭やメールで共有されるため、定義の範囲が広い方が発注側にとって有利です。
秘密保持期間・例外規定・違反時の効果
秘密保持条項を確認する際は、以下の3点に注目してください。
（1）秘密保持期間：契約終了後も秘密保持義務が継続する期間を確認します。「契約終了後2年間」といった条項が一般的ですが、システムに含まれる個人情報や営業機密の性質によっては、より長い期間が望ましいケースもあります。
（2）例外規定の内容：「公知の情報」「独自に開発した情報」「第三者から正当に取得した情報」は秘密保持義務の例外とされるのが通例です。これ自体は合理的ですが、「ベンダーが独自に開発した類似技術」として例外扱いされないか確認が必要です。
（3）違反時の効果：秘密保持義務違反があった場合の損害賠償・契約解除に関する規定を確認します。損害額の立証が難しいため、「違反1件あたり○円」という違約金条項を設けることも検討に値します。ただし過大な違約金は相手方が合意しない場合もあるため、リスクに応じた現実的な水準を設定してください。
中途解約条項——プロジェクト中断時のリスク管理
請負と準委任で異なる解除のルール
システム開発契約の類型（請負か準委任か）によって、中途解約のルールが異なります。請負契約では、民法641条により発注側（注文者）は損害を賠償することでいつでも解除できます。準委任契約では、民法651条1項により各当事者はいつでも解除できますが、相手方に不利な時期の解除は損害賠償義務を負います。
重要なのは、「法律上当然に認められている解除権」と「契約書で定める解除権」の両方を把握することです。法律上は解除できても、契約書に損害賠償額の上限がなければ、高額な請求を受けるリスクがあります。
解除事由・損害賠償上限額・既成作業分の清算
中途解約条項では以下の3点を確認・修正してください。
（1）解除事由の具体化：「ベンダーが重大な品質上の問題を解消しない場合」「納期を30日以上遅延した場合」などの具体的な解除事由を明記することで、発注側が正当に解除できる場面を明確にします。解除事由が曖昧だと、発注側がプロジェクトを中断させたいと考えても「正当な解除」と認められず、損害賠償を請求される可能性があります。
（2）損害賠償額の上限設定：ベンダーへの損害賠償額に上限（例：「解除時点までの未払い請負代金相当額を上限とする」）を設ける条項を盛り込みます。上限がなければ、プロジェクトが中断した場合に残工期全体の逸失利益を請求されるリスクがあります。
（3）既成作業分の清算方法：解除時点までに完了した作業の対価をどう清算するかを明確にします。「解除時点までに完成した成果物の比率に応じた代金を支払う」「中間成果物（設計書・プログラム等）の所有権は発注側に移転する」という条項が発注側保護になります。成果物の引き渡しを受けずに対価だけ支払う事態を避けるためにも、清算方法の明示は重要です。
まとめ——発注側が押さえるべき6つの確認軸
本稿では、システム開発契約書で発注側が確認すべき6つのチェックポイントを整理しました。要点を3つに集約すると次のとおりです。
第一に、検収条件・契約不適合責任・中途解約は「事後のトラブルを防ぐリスク管理の仕組み」です。合格基準を数値で定め、改正民法（562条〜566条）に沿った責任規定を確認し、解除事由と損害賠償上限を明記することで、プロジェクトが想定外の展開を迎えた際のリスクを抑えられます。
第二に、知的財産権の帰属と再委託は「システムを自社の資産として活用できるか」を左右します。著作権法27条・28条まで含めた譲渡条項の確認と、再委託先への義務流し下げの明記が実務上の鍵となります。
第三に、秘密保持条項は定義・期間・違反時の効果をセットで見ることが大切です。情報の性質に応じた秘密情報の定義の範囲と、契約終了後の継続期間を確認してください。
IPA「情報システム・モデル取引・契約書（第二版）」はこれらの条項を網羅したひな形として無償で公開されています。自社が受け取った契約書との差分を確認する際の対照資料として活用してください。
よくある質問
システム開発の契約書はベンダー提示のものをそのまま使ってもよいですか？
ベンダーが提示する契約書はベンダー側に有利な条件を含んでいる場合があります。特に知的財産権の帰属・損害賠償の上限・契約不適合責任の期間は発注側に不利な内容になりやすいです。IPA「情報システム・モデル取引・契約書（第二版）」を参照し、重要条項を自社側の要件と照合した上で修正交渉を行うことをお勧めします。
改正民法の契約不適合責任は2020年以前に結んだ契約にも適用されますか？
改正民法は2020年4月1日以降に締結された契約に適用されます。それ以前に締結した契約には旧民法の瑕疵担保責任が適用されます。現在新規でシステム開発契約を締結する場合は改正民法が適用される前提で条項を確認してください。なお、既存の長期保守運用契約を更新・改定する際は、改正民法対応の条項に書き換えることをお勧めします。
著作権をベンダーに残したまま利用許諾だけもらう場合、どのような点を確認すればよいですか？
利用許諾（ライセンス）の場合は、①許諾の範囲（改修・複製・再配布が可能かどうか）、②期間（無期限か有期限かの設定）、③ベンダー倒産時の処理（許諾権が第三者に引き継がれるか）の3点を確認してください。ベンダーが廃業した場合でも継続利用できるよう、「ソースコードの供託」や「ソースコード開示請求権」を条項に盛り込むことも有効です。
中途解約したい場合、どのような証拠を残しておくべきですか？
解除事由（納期遅延・品質不適合など）を証明できる記録を保存することが大切です。具体的には、進捗報告書・議事録・メール・バグ報告のトラッキング記録などです。解除の意思表示は書面（電子メールも含む）で行い、相手方の受信確認を得ておくと後々の証明に役立ちます。解除後の損害算定にも残存作業量の記録が必要になるため、プロジェクト管理ツールの記録も保持してください。
IPAのモデル契約書は無料で使えますか？どこからダウンロードできますか？
IPA「情報システム・モデル取引・契約書（第二版）」はIPAの公式サイトから無償でダウンロードできます。Word形式で提供されており、自社の取引条件に合わせて編集して使用できます。ダウンロードはIPA公式ページ（情報システム・モデル取引・契約書第二版）から行えます。なお、内容は2020年12月公表・2025年6月最終更新です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA独立行政法人情報処理推進機構「情報システム・モデル取引・契約書（第二版）」（2020年12月公表、2025年6月最終更新）
- *2 出典：民法（e-Gov法令検索） 第562条〜566条（契約不適合責任）・第641条（請負人の解除権）・第651条（委任の解除）
