システム開発の請負・準委任契約とは｜契約書の条項と契約不適合責任を解説

システム開発の請負・準委任契約とは、発注者とベンダー（開発会社）の間で交わされる業務委託契約の主要な2形態であり、それぞれ責任範囲・費用構造・成果物の定義が根本的に異なります。

契約形態の選択を誤ると、「仕様と異なるシステムが納品された」「途中で費用が予算を大幅に超えた」「著作権が自社に帰属していなかった」といったトラブルに直結します。社内にエンジニアや法務担当者がいない発注者ほど、ベンダーから提示された契約書をそのまま受け入れてしまいがちですが、契約内容の確認は発注者自身が行うべき重要な工程です。

本記事では、請負契約と準委任契約の違いと工程ごとの使い分け、契約書に盛り込むべき条項の判断軸、契約不適合責任の内容、経済産業省のモデル契約書の活用方法、典型的なトラブル事例と回避策を体系的に解説します。

システム開発の契約形態の種類とは？請負契約と準委任契約の違いと選び方

システム開発の契約には大きく「請負契約」と「準委任契約」の2種類があります。どちらを選ぶかによって、発注者とベンダーそれぞれの責任範囲や費用の発生構造が大きく異なります。プロジェクトの実態に合わない契約形態を選ぶと、後から費用トラブルや品質問題の温床になるため、基本的な仕組みを理解した上で選択することが重要です。

請負契約の特徴と発注者にとってのメリット・リスク

請負契約とは、ベンダーが「成果物の完成」を約束し、発注者がその対価を支払う契約形態です（民法第632条）。システム開発においては、「要件定義書に基づいたシステムを完成させること」が契約の目的となります。

発注者にとってのメリットとして、以下が挙げられます。

• 成果物が完成しない場合、報酬を支払う義務が生じない
• 契約不適合責任（旧：瑕疵担保責任）により、納品後の不具合に対して追完請求や報酬減額請求ができる
• 費用が固定されやすく、予算管理がしやすい

一方で、以下のリスクも考えられます。

• 要件定義が不十分だと、仕様変更のたびに追加費用が発生する
• ベンダー側が「完成」と主張した場合、検収で争いになりやすい
• 開発途中で仕様が変化しやすいプロジェクトには向かない

※参考：民法

準委任契約の特徴と発注者にとってのメリット・リスク

準委任契約とは、ベンダーが「業務の遂行」を約束し、発注者がその対価を支払う契約形態です（民法第656条・第643条）。成果物の完成は保証されず、業務を行ったこと自体が報酬の対象となります。

発注者にとってのメリットとして、以下が挙げられます。

• 仕様が固まっていない初期フェーズでも契約しやすい
• 業務内容の変更や調整が柔軟に行える
• 実態に即した工数管理ができる

一方で、次のようなリスクも考慮が必要です。

• ベンダーに成果物完成の義務がないため、思ったような成果が出なくても費用が発生する
• 契約不適合責任が適用されにくいため、品質の担保が難しい
• 工数が増えると費用が際限なく膨らむ恐れがある

なお、2020年4月施行の改正民法により、準委任契約においても「成果完成型」（民法第648条の2）という形態が設けられました。成果完成型では、一定の成果物の引き渡しを条件に報酬が発生するため、請負に近い性質を持たせることができます。

※参考：民法

契約の種類の選び方

実務では、1つのプロジェクト内で工程ごとに契約形態を使い分けるのが標準的な考え方です。以下の表は、一般的な使い分けの目安です。

工程	推奨される契約形態	理由
要件定義	準委任契約	仕様が未確定であり、成果物の完成を約束しにくい
基本設計	準委任契約	合意形成プロセスが中心で、成果物が流動的
詳細設計・開発・テスト	請負契約	仕様が確定しており、成果物の完成を約束できる
保守・運用	準委任契約	継続的な業務遂行が主目的であり、成果物が固定しにくい

このような多段階の契約形態は、経済産業省およびIPA（独立行政法人情報処理推進機構）が公表している「情報システム・モデル取引・契約書」でも推奨されています。ベンダーから提示された契約書が全工程を一括して請負契約にしている場合は、プロジェクトの実態と合致しているか確認することが重要です。

※参考：情報システム・モデル取引・契約書（第二版）| IPA 独立行政法人 情報処理推進機構 

システム開発の契約書に盛り込むべき条項

契約書に何が書かれているかによって、トラブル発生時の対応可能性は大きく変わります。発注者として最低限確認すべき条項を、「成果物・品質」「費用・変更」「権利・体制」の3つに分けて解説します。

成果物・品質の定義に関する条項

成果物・品質の定義に関する条項は、「何を作るか」「どうなれば完成か」を契約上で確定させるための基盤であり、検収トラブルや不具合対応の責任範囲を左右する最も重要な条項群です。

仕様書で成果物を明確にする

契約書本文だけで成果物を定義しようとすると、認識のズレが生じやすくなります。契約書には「仕様書（別紙）に定める成果物を納品する」と明記し、仕様書を契約の一部として添付することが基本です。

仕様書に記載すべき内容の例は以下の通りです。

• 開発するシステムの機能一覧と画面一覧
• 使用する技術スタック（言語・フレームワーク・インフラ構成）
• 性能要件（レスポンスタイム、同時接続数など）
• セキュリティ要件

仕様書が存在しない場合、完成の基準が曖昧になり、検収時のトラブルに発展するリスクが高まります。

検収条件を明文化する

検収とは、発注者がベンダーから納品物を受け取り、契約内容に適合しているかを確認するプロセスです。検収条件が不明確だと、「ベンダーは完成と主張するが発注者は未完成と判断する」という対立が起きやすくなります。

契約書に明記すべき検収関連の事項は以下の通りです。

• 検収期間（最低10営業日以上を確保することが望ましい）
• 検収基準（仕様書との照合方法、テスト項目の定義）
• 検収合格・不合格の判定方法
• 不合格の場合の修正対応期間と再検収の手順

契約不適合責任の範囲を確認する（概要）

請負契約では、納品後に発覚した不具合に対して、発注者は契約不適合責任に基づく追完請求や報酬減額請求を行える場合があります。この責任の対象範囲と期間は、契約書に明記されているかどうかで大きく変わります。詳細は後述のセクションで解説します。

費用・変更の管理に関する条項

費用・変更の管理に関する条項は、仕様変更や中途解除が発生した際に「誰がいくら負担するか」を事前に定めるものであり、これが曖昧なままでは追加請求や費用超過のトラブルを防ぐことができません。

変更管理と追加費用を決める

開発プロジェクトでは、途中で仕様が変わることが珍しくありません。変更管理（チェンジオーダー）の手続きを契約書に定めておかないと、「口頭で依頼した変更がいつの間にか追加費用として請求された」というトラブルに発展します。

変更管理条項に含めるべき事項の例は以下の通りです。

• 仕様変更の申請方法（書面または電子メールによる書面化の義務付け）
• 変更内容の見積もりとベンダー・発注者双方による承認手順
• 変更が承認されるまでは変更作業に着手しない旨の明記

損害賠償の上限を設定する

契約書には、ベンダーが負う損害賠償の上限額（責任制限条項）が記載されていることが多くあります。一般的には「当該契約の報酬額を上限とする」という条文が多く見られます。発注者としては、損害賠償上限額が著しく低くないか、または免責事項が広範すぎないかを確認することが重要です。

中途解除時の精算方法を決める

プロジェクトの途中で契約を解除する場合の費用精算ルールは、事前に明確にしておく必要があります。請負契約では、民法第641条により発注者はいつでも契約を解除できますが、ベンダーに損害が生じた場合はその賠償責任を負います。

精算条項に含めるべき事項の例は以下の通りです。

• 解除までに完了した作業に対する費用の算定方法
• ベンダーが請求できる損害の範囲と上限
• 中途成果物（仕様書・設計書など）の取り扱いと所有権の帰属

権利・体制の管理に関する条項

権利・体制の管理に関する条項は、開発後のシステムを誰が自由に使えるか、誰が実際に開発を担うかを規定するものであり、著作権の帰属や再委託の制限を明記しておかないと、納品後に想定外の制約が生じる恐れがあります。

著作権の帰属を確認する

システム開発で作成されたプログラムは著作物として保護されます（著作権法第10条第1項第9号）。契約書に著作権の帰属が明記されていない場合、原則としてプログラムを作成したベンダー側に著作権が帰属します。

発注者が自由にシステムを改修・流用・転売するためには、著作権の発注者への譲渡、または発注者に対する利用許諾（ライセンス）が契約書に明記されている必要があります。著作権の帰属条項は見落としやすい箇所であるため、必ず確認してください。

再委託の制限を入れる

ベンダーが発注者の知らない間に業務を第三者（下請け会社）に委託するケースがあります。再委託先の品質管理が不十分な場合、成果物の品質や情報漏洩リスクに影響が出ることがあります。

再委託条項に含めるべき事項の例は以下の通りです。

• 再委託を行う場合は発注者の事前承諾を必要とすること
• 再委託先に対しても本契約と同等の義務を課すこと
• 再委託先の業務に起因する損害についてもベンダーが責任を負うこと

契約締結の実務：印紙税・電子契約

請負契約はいわゆる「2号文書（請負に関する契約書）」に該当し、印紙税が課税される対象となります。契約金額に応じて印紙税額が変わるため、負担者を契約書で明確にしておくことが重要です。

一方、電子契約（電子データとして締結される契約）については、現行の印紙税法上、課税文書に該当しないという税務当局の解釈が示されています。電子契約サービスを活用することで、印紙税のコストを削減できる場合があります。ただし、電子契約の法的有効性や運用については、プロジェクトの規模や相手方との合意状況を踏まえて判断してください。

発注者が契約交渉で押さえるべきチェックリスト

以下のチェックリストは、契約書のレビュー時に発注者が確認すべき項目をまとめたものです。各項目は本記事内の該当セクションと対応しています。

• 契約形態（請負/準委任）はプロジェクトの実態と合っているか
  →「契約の種類の選び方」を参照
  
• 業務範囲・成果物が別紙仕様書で明確に定義されているか
  →「仕様書で成果物を明確にする」を参照
  
• 検収期間は十分か（最低10営業日以上が望ましい）
  →「検収条件を明文化する」を参照
  
• 変更管理条項（チェンジオーダー）が明記されているか
  →「変更管理と追加費用を決める」を参照
  
• 契約不適合責任の期間は1年以上確保されているか
  →「契約不適合責任の基本：発注者が行使できる4つの権利」を参照
  
• 損害賠償の上限額は妥当か
  →「損害賠償の上限を設定する」を参照
  
• 中途解除時の費用精算ルールが明記されているか
  →「中途解除時の精算方法を決める」を参照
  
• 知的財産権（著作権）の帰属は発注者側になっているか
  →「著作権の帰属を確認する」を参照
  
• 印紙税の負担者と電子契約の可否が明記されているか
  →「契約締結の実務」を参照
  
• 再委託・外注先の制限条項があるか

→「再委託の制限を入れる」を参照

10項目すべてを満たした契約書であれば、主要なトラブルリスクは大幅に低減できます。一方、ベンダーから提示された契約書にこのチェックリストの項目が含まれていない場合や、条項の内容が自社に不利となるおそれがある場合は、交渉または修正を求めることが重要です。

契約書の確認や契約形態の選択に迷った場合は、Incubation Baseへご相談ください。システム開発の発注経験が豊富なチームが、契約内容の整理から開発パートナーの選定まで、発注者の立場で一貫してサポートします。

お問い合わせはこちら

システム開発の契約不適合責任とは？瑕疵担保責任との違いと期間

2020年4月施行の改正民法により、それまで使われていた「瑕疵担保責任」という用語は「契約不適合責任」に改められました。名称の変更にとどまらず、発注者が行使できる権利の内容も整理・拡充されています。

なお、以下の記述は民法の規定に関する客観的な情報です。個別の契約条件や権利行使の可否については、弁護士等の専門家にご相談ください。

契約不適合責任の基本：発注者が行使できる4つの権利

改正民法では、契約不適合責任に基づいて発注者が行使できる権利として、以下の4つが規定されています。

権利の種類	内容	根拠条文
追完請求権	契約内容に適合した成果物への修補・代替物の引き渡し・不足分の引き渡しを請求する権利	民法第562条
代金減額請求権	ベンダーが追完を行わない場合に、不適合の程度に応じて報酬の減額を請求する権利	民法第563条
損害賠償請求権	契約不適合によって生じた損害の賠償を請求する権利	民法第564条・第415条
解除権	契約の目的を達成できない場合に契約を解除する権利	民法第564条・第541条・第542条

※参考：民法

システム開発における期間の考え方（5年・10年）

契約不適合責任を追及できる期間については、以下の2つのルールが民法に定められています。

• 知った時から1年以内の通知義務（民法第637条）

発注者は、契約不適合を知った時から1年以内にその旨をベンダーに通知する必要があります。この通知を怠ると、原則として契約不適合責任を追及する権利が失われます。ただし、契約書でこの期間を延長することは可能です。

• 消滅時効（民法第166条）

上記の通知を行った後、実際に権利を行使できる期間は「権利を行使できることを知った時から5年」または「権利を行使できる時から10年」のどちらか早い方とされています。この「5年・10年」という数字は、システム開発の文脈でよく参照される消滅時効のルールです。

なお、ベンダーが「不適合を知っていた場合」や「重大な過失により知らなかった場合」は、1年以内の通知義務が免除される規定もあります（民法第637条第2項）。

※参考：民法

準委任契約における責任範囲と発注者が主張できること

準委任契約では、ベンダーは成果物の完成を約束していないため、請負契約における契約不適合責任（民法第562条以下）は原則として適用されません。準委任契約においてベンダーが負う主な義務は「善管注意義務（善良な管理者の注意義務）」（民法第644条）です。

ベンダーが善管注意義務に違反した場合、発注者は債務不履行に基づく損害賠償請求（民法第415条）を行うことができます。ただし、具体的に何が義務違反に当たるかは個別の契約内容や業務の性質によって判断が異なります。

個別の契約条件については、弁護士等の専門家にご相談ください。

※参考：民法

経済産業省のモデル契約書をシステム開発に活用する方法

経済産業省は、ITシステムの取引を適正化することを目的として「情報システム・モデル取引・契約書」を公表しています。発注者とベンダーの対等な関係を前提とした標準的な契約書の雛形として、業界で広く参照されています。

経産省モデル契約書の構成と対象フェーズ

経済産業省のモデル契約書は、システム開発の各フェーズに対応した複数の書式で構成されています。主な構成は以下の通りです。

フェーズ	契約書の名称（例）	契約形態
要件定義	業務要件定義書作成支援業務委託契約書	準委任
システム設計・開発	システム開発業務委託契約書	請負または準委任
保守・運用	システム保守業務委託契約書	準委任

このように、フェーズごとに契約を締結する「多段階契約」を推奨している点が特徴です。最新版の構成や書式については、経済産業省の公式ページで確認してください。

モデル契約書をそのまま使ってはいけない理由

モデル契約書はあくまで標準的な雛形であり、個別のプロジェクトに無修正で適用することは推奨されません。主な理由は以下の通りです。

• 案件ごとに異なる成果物・工数・リスク分担が反映されていない
• 発注者とベンダーの力関係や業界慣行によって、修正が必要な条項が存在する
• 改訂が入ることがあるため、古いバージョンを参照しているリスクがある

モデル契約書を活用する際は、必ず最新版の年度・版番号を確認した上で、自社の案件に合わせて修正を加えることが重要です。

雛形・テンプレートを使う際のポイント

モデル契約書や各種テンプレートを活用する際には、以下の点を意識してください。

• 別紙として添付する仕様書・要件定義書を先に整備し、契約書との整合性を確認する
• 変更管理や検収条件など、トラブルが起きやすい条項は特に丁寧に確認する
• 法的な専門知識が必要な条項については、弁護士等の専門家への相談を検討する
• 改訂履歴を管理し、契約書のバージョン管理を行う

システム開発の契約トラブルの典型パターンと裁判例に学ぶ教訓

契約書の不備がどのようなトラブルに発展するかを、典型的なパターンを通じて確認します。

検収後に発覚した不具合の責任範囲が争われたケース

検収後の不具合と責任範囲の考え方を検討する上では、東京地方裁判所平成14年4月22日判決が参考となる裁判例の一つとされています。同判決では、情報処理システムの開発において一定の不具合発生が避けがたいことを前提に、検収後に不具合が判明した場合であっても、ベンダーが合理的な期間内に補修対応を行うなど適切な措置を講じたかどうかが、責任判断の一要素となり得ることが示されています。

発注者としては、仕様書をもとに検収基準を具体的に定めること、検収後の責任期間と補修の範囲を契約書に明記しておくことが事前の対策となります。この2点を契約時に整備しておくことで、検収後のトラブルが発生した際の対応がスムーズになります。

仕様変更の合意が口頭のみで費用トラブルになったケース

変更管理の書面化が争点となった事例として、東京地方裁判所平成22年5月21日判決があります。同判決は、納期変更の合意の有無が争われたケースで、裁判所は「口頭による合意だけでは認定できず、書面や記録が重要な立証資料となる」という立場を示しました。同裁判例の資料では、「仕様変更はドキュメントに残すことが立証上不可欠であり、書面が詳細なほど争いの余地が狭まる」と指摘しています。

発注者としては、変更内容・費用への影響・承認手続きを書面（またはメール等の記録が残る形式）で合意しておくことが、このトラブルを防ぐ有効な手段です。

著作権帰属の未定義により二次利用を制限されたケース

著作権帰属の未定義が納入後のトラブルに発展した事例として、経済産業省「情報システム・ソフトウェア取引トラブル事例集」（2010年3月）に収録された事例があります。同資料では、委託者がソフトウェアの販売を開始した後、著作権が受託者側に帰属したままであったとして、受託者から複製・頒布の差止請求を受けたケースが取り上げられています。

著作権法上、ベンダーの従業員が開発したプログラムの著作権は、対価の支払いの有無に関わらず原始的にベンダーに帰属します（著作権法第15条）。そのため、発注者が自社にすべての著作権を帰属させたい場合は、「著作権（著作権法第27条・第28条に規定する権利を含む）を発注者に譲渡する」旨の条項を契約書に明記する必要があります。

システム開発の契約に関するよくある質問（FAQ）

システム開発の契約では、発注者が実務の現場で判断に迷いやすい場面が数多く存在します。ここでは、契約形態の切り替えや専門家への相談の要否など、考えられる疑問点について解説します。

請負と準委任はプロジェクト途中で切り替えられますか？

切り替えることは可能です。ただし、工程ごとに別の契約書を締結する「多段階契約」の形式を取る必要があります。既存の契約書を修正覚書で変更する方法もありますが、その場合は変更後の責任範囲や費用精算の起算点を明確にしておく必要があります。実務では、要件定義フェーズは準委任、開発・テストフェーズは請負という分け方が一般的です。

契約書のリーガルチェックは外部に依頼すべきですか？

社内に法務担当者がいない場合、弁護士またはIT契約に詳しい法務サービスへの相談は検討すべきと言えます。特に、契約金額が大きいプロジェクトや、著作権・損害賠償・秘密保持義務など専門的な判断が必要な条項が含まれる場合は、外部専門家の確認を経ることでリスクを大幅に軽減できます。リーガルチェックの費用は、後から発生するトラブル対応コストと比較すると、一般的に大幅に低く抑えられます。

SES契約と準委任契約の違いは何ですか？

SES（システムエンジニアリングサービス）契約は、エンジニアの労働力を一定期間提供することを目的とした契約で、法的な性質は準委任契約（または請負契約）として整理されます。

SES契約と一般的な準委任契約の主な違いは、エンジニアの「指揮命令権」の所在にあります。準委任契約では発注者がエンジニアに直接指示を出すことが難しく、指示系統が明確でないと「偽装請負」と見なされるリスクがあります。エンジニアの常駐を伴う開発体制を組む場合は、指揮命令の範囲と責任の所在を契約書で明確にすることが重要です。

まとめ：システム開発の契約トラブルを防ぐために発注者が今すぐできること

システム開発の契約は、プロジェクトの成否を左右する重要な取り決めです。契約形態の選択、条項の内容確認、著作権の帰属確認、変更管理の仕組みづくりなど、事前に対策を講じることで、大半の典型的なトラブルは回避できます。

本記事で取り上げた内容を整理すると、発注者が最優先で確認すべきポイントは以下の通りです。

• プロジェクトの工程ごとに適切な契約形態（請負または準委任）を選択する
• 仕様書を別紙として整備し、成果物と検収条件を明確にする
• 変更管理条項を設け、仕様変更は必ず書面で記録する
• 著作権の帰属を契約書に明示的に定める
• 契約不適合責任の期間と範囲を確認し、不十分であれば交渉する
• 経産省モデル契約書の最新版を参照し、自社案件に合わせてカスタマイズする

契約書の内容に不明点がある場合や、開発会社から提示された契約書をどう交渉すればよいか判断が難しい場合は、専門家への相談を検討してください。

Incubation Base株式会社では、システム開発の発注支援から要件定義、開発、保守に至るまで一貫してサポートしています。「契約形態の選択から相談したい」「ベンダー選定と同時に契約条件の妥当性も確認したい」といったご相談は、お問い合わせフォームよりお気軽にご連絡ください。