ソフトウェア開発契約書レビューの基本｜定義・チェックリスト・立場別リスク

こんにちは。LegalAgent 代表弁護士の朝戸です。

ソフトウェア開発契約書は、企業法務の中でも特にレビューの難易度が高い分野の一つだと感じています。民法や知的財産法、情報セキュリティに関する法的な理解にとどまらず、開発プロセスの実務や要件定義の進め方を一体として捉える必要があるためです。

発注側の事業部門から見ると「完成したシステムを納品してもらう契約」と単純に捉えられがちですが、実際には当初から仕様の細部まで確定しているプロジェクトばかりではありません。PoC（概念実証）や既存システムからの移行、段階的な機能拡張など、ユーザー企業とベンダが協働しながら作り上げていく場面も多くあります。この開発実態と契約条項がずれていると、スケジュールの遅延や追加費用の発生、成果物の権利帰属をめぐる大きなトラブルに発展しかねません。

開発手法と契約構造の整理

ソフトウェア開発契約書は、ユーザー企業がベンダに対して業務システムやWebサービス、アプリケーションなどの設計や開発を委託する契約です。基本契約で共通条件を定め、個別契約や注文書で具体的な開発対象や納期、費用を定める二層構造が多く用いられます。基本契約の条文だけを確認しても個別の取引リスクは判断できないため、注文書や提案書、仕様書の内容まで一体として読み解くことが大切です。

契約の性質としても、開発手法や工程の名称だけで一律に請負か準委任かを断定することはできません。ウォーターフォール型であっても要件定義や基本設計フェーズは準委任、詳細設計以降は請負と分ける例があれば、アジャイル型のように反復開発を行う場合でもスプリントごとの成果物検収を取り入れる例があります。また、納品物として実行ファイルだけでなくソースコードや設計書、運用に必要な各種アカウントの管理者権限まで引き渡されるのか、ベンダの既存資産やOSS（オープンソースソフトウェア）とどのように切り分けるのかを明確にしておきます。

要件定義と仕様変更の手続き

開発プロジェクトで問題になりやすい論点が、要件の未確定と仕様変更の扱いです。ユーザー側は「提案書に書いてあったこの機能も含まれている」と考え、ベンダ側は「見積りの前提に含まれていない追加要望」と受け止めるような認識の齟齬が典型です。仕様が未確定のまま固定額で完成を約束すると、ベンダが見積りを超える作業を負担するおそれがあります。提案書にのみ記載された約束事項がある場合は、契約書や個別仕様の合意に明示的に取り込んでおく必要があります。

仕様変更については、口頭やチャットでの気軽な依頼によって無償の作業が膨らまないよう、変更依頼の方法、ベンダによる見積りと影響範囲の提示、ユーザー側の承認手続き、費用や日程の調整手順を契約であらかじめ定めておきます。変更手続きが重すぎると機動的な開発が阻害される一方、手続きが曖昧だと現場の負担が一方に偏る原因となります。また、仕様確定や資料提供、社内承認などユーザー側の協力が遅れたことによって生じた開発遅延について、ベンダ側のみが納期遅滞の責任を負わされないよう、委託者の協力義務と遅延時の日程延長条項を入れておくことも実務的な手当てとなります。プロジェクトの遅延や頓挫は、仕様の未確定や承認遅れ、外部クラウドサービスの障害などが複合的に重なって起こることが多いためです。

検収基準と契約不適合責任

検収条項は、報酬の支払義務と成果物の品質確定が交差する要の条項です。合格基準が曖昧なままでは、どの不具合を理由に検収を保留できるのかが双方で食い違い、ベンダ側も支払いを受けられる時期を見通しにくくなります。基準の記載がないことだけで、契約の他の合意内容に基づく品質上の請求までできなくなるわけではありません。検収期間や不合格時の修補義務、不具合の重要度に応じた合格基準を具体化しておくことが有効です。軽微な不具合が残っていても本番稼働に支障がなければ一旦検収を合格とし、残存不具合は契約で定めた対応期間中に修補するのか、重大な不具合がある場合は検収を保留できるのかを取り決めておきます。

契約不適合責任については、無償修補の請求期間や代金減額、解除の要件を確認します。納品後の保守運用を別契約とする構成自体は一般的ですが、検収直後の初期不具合対応と保守契約の対象範囲との間に空白期間や対応漏れが生じないかを確認します。保守の対応範囲やSLA、追加費用の確認事項は、保守契約・システム保守契約書のチェックポイントで整理しています。損害賠償条項では、委託料相当額などを上限とする責任制限条項を設けることが多い一方、情報漏えいや知的財産権侵害、故意・重過失による損害について上限の例外とするかを交渉します。責任を制限する条項自体の効力については、適用法令や裁判例、事案の具体的事情を踏まえて別に判断します。

知的財産権とデータ管理の設計

成果物の知的財産権の帰属も主要な検討項目です。ユーザー側は成果物を自社の事業で改変・展開できるよう著作権の譲渡を求めることが一般的ですが、著作権法27条（翻訳権・翻案権等）および28条（二次的著作物の利用に関する原著作者の権利）の権利は特掲して譲渡する旨を定めておかないと委託者に移転しないと推定されます（同法61条2項）。権利をベンダに残す場合でも、予定する利用・改変に十分な利用許諾を得られるかを確認します。また、著作者人格権は一身専属権であり譲渡できないため（同法59条）、不行使特約を設けるかどうかも論点となります。ベンダ側としては、開発以前から保有している共通モジュールやフレームワークなどの既存資産まで譲渡対象に巻き込まれないよう明確に除外し、OSSのライセンス条件に反しない利用形態となっているかも確かめます。

AIを活用した開発やシステムへの機械学習組み込みでは、入力データや学習済みモデル、生成された出力結果の権利関係の整理も必要となりますが、AIの生成モデルや出力結果が当然に著作権法上の著作物として保護されるとは限らない点に留意します。また、開発環境で本番データを利用する際は、個人情報保護法上の安全管理措置や事故時の速やかな報告義務を定めます。契約書に「匿名化されたテストデータ」と記載されていても、法律上の「匿名加工情報」の細かい要件を満たしているとは限らないため、実際のデータ処理内容と契約条項の整合性を確認します。

生成AIによる契約書レビューは論点の洗い出しに便利ですが、開発手法や仕様の確定状況を伝えず、報酬が固定額か時間単価かを示さなければ、形式的な指摘にとどまります。提案書や仕様書の背景に加え、利用予定のクラウドやOSSも確認材料にします。提示された修正案が技術的に現場で運用可能なものかを、開発担当者とともに確認する姿勢が欠かせません。開発契約の審査を日常業務として外部に任せる場合の内容は法務アウトソーシングで確認できます。