ソフトウェア開発契約書レビューの基本｜定義・チェックリスト・立場別リスク
こんにちは。LegalAgent 代表弁護士の朝戸です。
ソフトウェア開発契約書は、企業法務の中でも特にレビューの難易度が高い契約書の一つだと感じています。法律の知識だけでなく、開発プロセスや要件定義、知的財産、セキュリティまでを一体として理解する必要があるためです。
事業部から見ると、ソフトウェア開発は「システムを作ってもらう契約」に見えるかもしれません。しかし実際には、何を作るのかが最初から完全に決まっていないことも多く、開発途中で仕様が変わり、ユーザー企業とベンダが協力しながら完成に近づけていくことがあります。この実態を契約書に反映できていないと、納期遅延や追加費用、著作権帰属をめぐって大きなトラブルになりやすいです。
契約書の形式より、開発の進め方を見る
ソフトウェア開発契約書とは、ユーザー企業がベンダに対し、業務システムやWebサービス、アプリケーションなどの開発を委託する契約書です。新規開発だけでなく、既存システムの改修や移行、PoCが含まれることもあります。
ソフトウェア開発契約には、請負型と準委任型の要素が混在することが多いです。要件定義や調査分析は準委任に近く、詳細仕様が固まった後の開発・納品は請負に近いと整理されることがあります。ウォーターフォール型では、要件定義から検収までの段階を分けやすい一方、アジャイル型では、短いサイクルで開発と改善を繰り返すため、成果物や検収の考え方を別途設計します。
契約書には、基本契約と個別契約を分ける形式もあります。基本契約で共通条件を定め、個別契約や注文書で具体的な開発範囲や費用を定める形です。この場合、基本契約だけを読んでも実際のリスクは見えません。個別契約や提案書、要件定義書まで確認します。また、完成した成果物だけでなく、ソースコードや設計書なども契約上の論点になります。何が納品物なのか、何がベンダの既存資産なのかを分けて考えます。
要件定義と仕様変更が、最初のつまずき所
ソフトウェア開発契約書を慎重に見る理由は、開発プロジェクトが失敗したときの損害が大きくなりやすいからです。開発費用そのものだけでなく、サービス開始の遅れやデータ移行失敗など、事業上の影響が広がります。
特に問題になりやすいのは、要件定義と仕様変更です。ユーザー側は「当然この機能も入っている」と考え、ベンダ側は「見積り範囲外です」と考えることがあります。要件が曖昧なまま固定価格で契約すると、どちらかに過大な負担が寄りやすいです。契約書では、要件の確定方法、仕様変更の手続、追加費用を明確にしておきます。仕様変更条項では、変更依頼の方法や承認、追加費用、影響範囲の確認を定めます。口頭やチャットで依頼された変更が無制限に取り込まれると、ベンダ側に過大な負担が生じる一方、変更手続が重すぎると、ユーザー側が必要な改善を進めにくくなることがあります。
検収と契約不適合責任
検収も大きな論点です。検収基準が曖昧だと、ユーザー側は品質に不満があっても契約上どこまで拒否できるのかが不明確になり、ベンダ側はいつ報酬を受け取れるのかが不安定になります。検収期間や不具合の重要度、不合格時の修補義務まで具体的に書き込んでおくと、この不安定さを減らせます。軽微な不具合が残っている場合でも検収できるのか、重大不具合がある場合は検収を拒否できるのかを、あらかじめ決めておきます。検収後の不具合対応と保守の関係も整理しておきたいところです。
契約不適合責任では、修補義務、対応期間、責任期間、代金減額の範囲を確認します。ベンダ側では、責任期間が長すぎないか、無償修補の範囲が広すぎないかを見ます。ユーザー側では、重大な不具合が責任制限で十分にカバーされない状態になっていないかを確認します。
知的財産権とセキュリティ・個人情報
知的財産権も慎重に見る必要があります。ユーザー側は、完成したシステムを自社サービスや社内業務で自由に使いたいと考えます。一方でベンダ側は、既存のプログラムやフレームワーク、開発ノウハウを他案件でも使いたいと考えます。成果物の著作権を一括譲渡する条項にすると、ベンダの既存資産まで移転するように読める場合があります。著作権譲渡、利用許諾、改変、著作者人格権不行使の範囲を見て、OSSを使う場合はライセンス条件に反しないかを確認します。
セキュリティと個人情報も確認が欠かせません。開発中に本番データを使うのか、テストデータは匿名化されているのか、事故時の報告義務はどうするのかを見ます。開発環境に本番データを入れる場合は、特に慎重な検討が求められます。AI関連開発では、入力データや出力結果、モデルの権利関係も問題になる可能性があります。最後に、損害賠償や責任上限、紛争解決も確認します。開発契約では損害が大きくなりやすいため責任上限を設けることが多い一方、情報漏えいや知的財産侵害、故意又は重過失について例外を置くかが交渉になります。
ユーザー側・ベンダ側で変わるリスク
ユーザー側のリスクは、必要な機能が契約範囲に入っていないこと、検収基準が弱いこと、保守や不具合対応が別契約になっていることです。提案書では説明されていた内容が契約書や仕様書に入っていない場合、後から「契約範囲外」と言われる可能性があります。また、ソースコードや設計書が納品されない、運用に必要なアカウントが渡されないと、将来の改修やベンダ変更が難しくなります。契約時点で、納品物と利用権限を明確にしておきます。
ベンダ側のリスクは、要件が曖昧なまま固定価格で完成責任を負うこと、仕様変更が無償対応になること、ユーザー側の協力遅延まで自社の責任にされることです。ユーザー側の意思決定が遅いプロジェクトでは、ベンダだけでは進められない場面が多くあります。協力義務と変更管理がない契約は、ベンダ側にとって負担が大きくなりやすいです。知的財産の一括譲渡にも注意が必要で、自社が以前から持っている開発部品やライブラリまで譲渡対象に入ると、他案件で使えなくなるように読まれる可能性があります。
双方に共通するリスクは、プロジェクトの失敗原因が一方だけにあるとは限らないことです。要件未確定、仕様変更、社内承認遅延、外部サービス障害などが複合的に影響します。契約書の役割は、誰が何をいつまでに行うのか、問題が起きたときにどう協議するのかを事前に決めておくことにあります。ソフトウェア開発契約書は、相手を縛るためだけの書類ではなく、プロジェクトを前に進めるためのルールです。契約書が現場の進め方と合っているかを確認することが、レビューの中心になると考えています。
生成AIは、ソフトウェア開発契約書の論点抽出に役立ちます。仕様変更や検収、OSS、セキュリティなど、典型的なチェックポイントを短時間で洗い出せます。ただし、開発プロジェクトの実態を知らないままレビューすると、形式的なコメントになりやすいです。ウォーターフォールなのかアジャイルなのか、要件定義は終わっているのか、固定価格なのか時間単価なのかによって、レビュー方針は大きく変わります。AIにレビューさせる場合は、提案書や要件定義書、開発体制、利用予定のクラウドやOSSを入力しておくと、一般的なチェックリストで終わらずに済みます。すべての不具合を解消するまで検収できない条項は、ユーザー側には強く見えても開発現場では実務に合わない場合があり、AIの修正案が技術的に現実的かどうかも確認しておきたいところです。
開発契約のレビューはLegalAgentへ
LegalAgentでは、ソフトウェア開発契約書について、ユーザー側・ベンダ側の双方の立場から、開発範囲や仕様変更、知的財産、責任制限を整理したレビューを行っています。AI・SaaS・データ連携を含む開発案件では、契約書だけでなく提案書や仕様書も確認し、事業部が相手方と交渉しやすい形に落とし込むことを重視しています。