システム開発委託基本契約(請負型)のサンプルとポイントの解説

HOME > 取扱案件解説 > IT法務・IT紛争対応(システム開発・ウェブサービス) > IT法務・ソフトウェア法務・システム開発法務の解説 > システム開発委託基本契約(請負型)のサンプルとポイントの解説

以下の検索ボックスを利用して、IT法務関連のページから検索できます。

前のページ　IT関連契約と収入印紙　┃　次のページ　システム開発委託基本契約(準委任型)の解説

システム開発業務委託基本契約（請負型）の主要な項目

　本ページでは、「請負型」を主として念頭に置きつつ、システム開発業務委託基本契約の基本的な知識をご説明し、さらに主要条項の一部をサンプル条文を通じてご説明します。

　なお、システム開発委託契約における「請負」と「準委任」の意味や相違は、「システム開発契約の必要性と法的性質」のページをご覧ください。

開発委託基本契約（請負型）と収入印紙

　開発委託基本契約（請負型）において収入印紙の貼付は必要でしょうか。必要だとすれば金額はいくらになるでしょうか。

　この点については、IT関連契約と収入印紙のページをご覧ください。

形式的記載事項

契約書の表題・名称の意味

　契約書の表題（タイトル）には法的な意味があるのでしょうか。結論からいえば、表題（タイトル）には本質的な意味はありません。したがって、「開発委託契約」というタイトルであっても、法的には「準委任」という契約となる場合もあれば、請負契約となることもあります。

　また、書面の名称については、「契約書」、「合意書」、「覚書」など諸々ありますが、これについても、名称によって法解釈が大きく変わることはありません。重要なのはあくまでも中身・内容です。

契約当事者

　契約のタイトルとは異なり、契約当事者はきちんと特定する必要があります。例を挙げると以下のとおりです。

●　契約当事者が個人事業主であって、屋号を使用している場合

この場合、住所、屋号だけではなく、個人名の表記も求めるほうが安全です。屋号だけだと当事者が特定されない場合があるからです。

●　契約当事者が法人の場合

この場合、法人の本店所在地、法人名、肩書（代表取締役など）と代表者名を表示し、代表者印を押印してもらいます。

　もっとも契約当事者が大企業の場合、契約当事者が代表取締役ではなく、事業部長名だったり、執行役員名だったりすることもあります。ただし、大企業の場合、一定の役職者に契約締結の権限を与えていることは珍しくありませんので、通常は問題ありません。

主要条項一覧

　システム開発委託契約（請負型）において、押さえるべきポイントとなる条項のうち主なものは以下のとおりです。

契約書の表題等	契約書の表題を定めます。ただしあまり神経質になる必要はありません。
契約当事者の特定	契約当事者を特定します。また、法人であれば代表者名などにも留意が必要です。
開発対象の特定・明確化	開発対象の範囲を特定・明確化します。これがないと、成果物が完成したのか否か、ユーザの要求が契約に沿ったものなのか中途変更なのか等が不明確となり、紛争の温床となってしまいます。
仕様確定・主体と変更	仕様をいつどの時点でどのように確定させるのか、仕様変更の場合の手順や委託料の変更等について取り決めます。
成果物の納品	納品すべき成果物の定義、成果物の納品の方法・時期について定めます。
成果物の検査・検収	成果物の検査の基準・方法・役割分担について定めます。
成果物の所有権の移転・危険負担	成果物の所有権がいつ移転するのか、危険の移転（成果物が滅失毀損した場合の代金支払義務の消長）についてどのように規定するかを検討します。
対価・その変更	対価の金額又は定め方、変更がある場合の方法について定めます。
瑕疵担保責任・成果物の保証の内容と範囲	瑕疵担保責任の期間と内容、成果物についてどんな内容の保証をどこまで行うかを定めます。
成果物に関する著作権・知的財産権の取扱	成果物の著作権の帰属のほか、その他の知的財産権の取扱などを定めます。
他者のソフトウェアやオープンソース等の利用	他者のソフトウェアやオープンソース等の利用に関する規定についてご説明します。
知的財産権紛争の処理	成果物について第三者から知的財産権侵害について紛争が生じた場合の対応・手当などを定めます。
下請・再委託の可否	下請・再委託の可否、条件について定めます。
秘密保持	秘密保持の内容、例外規定、秘密保持期間等について定めます。
解除事由・解除後の措置	どんな場合に契約が解除できるか、解除後の成果物（仕掛品）の取扱い等について定めます。
損害賠償の事由・範囲・内容	損害賠償を負う事由、どの範囲まで損害賠償を負うのか、賠償額の上限の定めの要否等を検討します。

システム開発業務委託契約（請負型）の主要条項のサンプルと解説

　以下、請負型を主として念頭に置きつつ、システム開発業務委託基本契約の主要条項の一部を、サンプル条文を通じてご説明します。なお、このサンプル条文については、もっぱら説明のためのものであり、完全性や条文間の整合性などは保証しておりませんので、これをひな形（雛形）として使用することはご遠慮ください。

第＊条（開発対象）
　甲は、別紙１開発対象目録記載のシステム（以下「本システム」という）の開発を乙に委託し、乙はこれを受託する。
（別紙１）開発対象目録
1 本システムの内容
　甲の●●業務に使用するための●●管理システム
　仕様については別紙２において定める。
２　納入物
・要件定義書
・フローチャート図
・UI・UXデザイン図、画面設計図
・設計書
・プログラム本体（オブジェクト、ソースコード）及びデータベース
・試験項目書・試験結果報告書
・運用環境設定情報
・操作マニュアル
・その他甲乙間で、都度書面又は電子メールで合意したもの

条項のポイント１～開発対象の特定・明確化の重要性

　システム開発委託契約において、開発対象の範囲を特定・明確化することは重要といえます。

　そもそも受託者・ベンダは何を開発すべきなのか、という点が明確になっていないと、成果物が完成したのか否か、開発途中になされたユーザの要求が当初契約の履行の要求なのか、これを超えた中途変更・追加なのか等が不明確となります。

　それでも開発がスムーズに進めばよいのですが、遅延が発生したり、品質がユーザの期待に沿わないようなものであった場合、紛争が現実化する温床となってしまいます。

条項のポイント２～開発対象の特定・明確化の方法

　それで、契約書、別紙又はこれらの附属書類において、開発対象を特定し、範囲を明確にするすることが重要となります。この点具体的には、単に「××システム」といった名称にとどまらず、仕様書や別紙などで、実装すべき機能をできる限り詳細に特定することが望ましいと考えられます。

　なおこの点で、RFPや提案書が、法的拘束力を持つ意味での開発対象となるかが問題となることがあります。この点は、「RFP・提案書と法律」のページをご覧ください。

　他方、案件によっては、開発対象を具体的に特定するために、要件定義や基本設計を経ないと困難というケースもあります。

　この場合、当初の契約において定める開発対象は、ある程度抽象的なものとならざるをえませんが、開発対象の具体的な内容を特定する時期や方法を定め、要件定義や基本設計といった段階後に速やかに書面などで開発対象を特定するようにすることが望ましいと考えられます。

条項のポイント３～納入すべき成果物の定め

　またあわせて、納入すべき成果物についてもできる限り詳細に定めることは望ましいといえます。特に発注側が、ソースコードの納入が必要であると考えるときは、ソースコードは納入物に明示しておく必要があります。

成果物の納品

　以下は「納品物の納入」に関する比較的シンプルな条項の例です。

第＊条（成果物の納入）
　乙は、個別契約において定めた期限までに、個別契約に定める成果物（以下「本成果物」という）を、個別契約において定められた方法により納入する。ただし、天災地変その他不可抗力によって当該期限までの納入が困難になった場合、乙は、甲に対し、納期の延長を求めることができる。

ポイント１～納入期限の明示

　まず、納入期限を明示することは発注者（ユーザ）側にとっても、受注者（ベンダ）側にとっても重要です。基本契約と個別契約とで契約を分ける場合、個別契約に定めることが多いといえます。あるいは、注文書と請書などで定めても差し支えありません。

ポイント２～納入方法の明示

　個別契約、仕様書、見積書、発注者等何らかのドキュメントにおいて、成果物の納入方法についてもできる限り具体的に記載することも重要です。納入方法についての認識の相違は、トラブルの原因となりやすいものの一つです。

　ＣＤやＤＶＤなどの固定媒体を納入する、ユーザー指定のサーバにデータをアップロードさせる、クラウド上のストレージに納品する、ユーザが管理するサーバや端末にインストールする等、種々のパターンが考えられます。

成果物の検査

　以下は「納品物の検査」に関する比較的シンプルな条項の例です。

第＊条（検査）
１　甲は、本成果物の納入後●日以内に、甲乙の協議によって定める検査仕様書に基づき検査し本成果物の検査を行い、検査結果について乙に書面で通知するものとする。
２　前項の期間内に甲が乙に具体的な理由を付した検査不合格の通知をなさない場合、本成果物については、検査に合格したものとみなす。

ポイント１～検査期間の明示

　検査期間を明示することは発注者（ユーザ）側にとっても、受注者（ベンダ）側にとっても重要です。ある基本契約に基づく複数の開発案件が同種のものである場合、検査期間を基本契約で定めることもできます。他方、案件ごとの成果物の性質や規模に応じて、個別契約に定めることも少なくありません。

　特に、検査期間の定めがないと、発注者（ユーザ）側が検査をずるずると先延ばししても受注者（ベンダ）側は文句が言えなくなるおそれがありますから、この点でも検査期間の定めは重要と思われます。

ポイント２～検査仕様・基準の明示

　検査仕様・検査基準を定めておく必要があります。この点、検査仕様書において、システム仕様書に基づき、仕様書、テスト項目、テストデータ、テスト方法を定めることが実務上多く行われています。

　この点、検査・検収は発注者（ユーザ）側の業務であるため、検査仕様書の作成は、原則として、本来は発注者（ユーザ）側の責務とされることが多いと考えられますが、検査仕様書の策定には実際に開発業務を行ったベンダ（受注者）の積極的関与が不可欠な場合が多いこと、ユーザ側が一方的に検査仕様を定めることがベンダ側に不利益となりうることから、検査仕様書の作成や確定においては、両者協議によって行うとされることは実務上珍しくありません。

ポイント３～検査期間満了時の取扱

　検査期間満了時に発注者（ユーザ）から通知がない場合の取扱を定めておくことも検討できます。

　上のサンプルでは、通知がない場合に検査合格とみなす旨の規定としています。

成果物の所有権の移転・危険負担

　以下は「成果物の所有権の移転・危険負担」に関する比較的シンプルな条項の例です。

第＊条（成果物の所有権・危険負担）
１　乙が甲に納入した本成果物の所有権は、第＊条に基づき、甲が乙に委託料を全額支払ったきに乙から甲に移転する。
２　前項にかかわらず、乙が甲に納入した本成果物の危険は、本成果物の納入の時点で甲に移転する。

ポイント１～所有権移転時期の明示

　まず、成果物の所有権の移転時期を明示することは発注者（ユーザ）側にとっても、受注者（ベンダ）側にとっても重要です。

　上のサンプルでは、委託料支払の確実性を少しでも高めるという意味でベンダー（受注者）側寄りの「委託料支払時期」を移転時期としていますが、これは一つの例です。

　そのほか、成果物の所有権の移転時期として、納入時、検収時などと定める方法もあります。

ポイント２～「危険負担」の移転明示

　まず、「危険負担」という言葉自体、法律に馴染みのない方であれば初耳かもしれません。

　これは、民法に定められた概念であり、取引対象物が、いずれの当事者にも責任がないのに滅失してしまった場合（例えば天災による滅失）、対価（取引対象物の代金）の請求権が消滅するのか、あるいは存続するのかを規定するものです。

　そして、「危険」が移転する前は、対価の請求権は消滅する一方、「危険」が移転した後は、対価の請求権は消滅します。

　この点上の条項例では、「乙が甲に納入した本成果物の危険は、本成果物の納入の時点で甲に移転する」と定めています。

　そうすると、この場合、ベンダーが成果物を納入する前に、成果物が滅失してしまった場合、「危険」が移転する前であるため、対価の請求権も消滅します。

　他方、ベンダーが成果物を納入した後に成果物が滅失しても、発注者（ユーザ）は対価支払義務を負うということになります。

対価・委託料とその変更

　以下は「対価」「委託料」とその変更に関する比較的シンプルな条項の例です。

第＊条（委託料）
　甲が乙に支払うべき本件業務の対価（以下「委託料」という。）は、総額●●●●万円（税別）とし、甲は、乙に対し、これを以下のとおり、消費税を付加して支払う。
　(1)本契約日の翌月末日まで　　　　●●●●万円（税別）
　(2)平成●年●月●日限り　　　　　　●●●●万円（税別）
　(3)平成●年●月●日限り　　　　　　●●●●万円（税別）
　(4)本成果物の検収完了日の翌月末日までに　残額●●●●万円（税別）

第＊条（委託料の変更）
　以下のいずれかの場合、甲と乙は、委託料の変更につき協議するものとする。
　(1)本成果物の仕様につき、追加または変更しようとする場合
　(2)本成果物の納期を変更しようとする場合

ポイント１～対価の支払時期

　まず、対価の支払時期・条件を明確にすることは重要です。この点、複数の定め方があります。

成果物納入後の一括払い

　本来の請負契約の原則から考えると、支払時期は、成果物の納入後という考え方が素直ではあり、多くのケースでそのような方法が取られています。

　またこれは、ユーザ（発注者）側から見れば、開発の成果が生じない限り支払をする必要がないという意味でリスクが低い条件でもあるといえます。

段階的支払

　他方、システム開発については、特に規模が大きいものだと、プロジェクトの開始から納入まで長期にわたるものとなり、ベンダー（受注者）はその間非常に厳しい資金繰りを余儀なくされることにもなります。

　そのため、ベンダ（受注者）側では、プロジェクトの中途での段階的な支払を定めるよう交渉することは検討に値するといえます。

　その方法にはいくつかありますが、一つは、年月日という時間で区切る方法です（上のサンプルはその内容で記述しています）。

　他方、プロジェクトのある段階の完了ごとに支払うという方法もあります。例えば以下のような例です。

(1)　基本設計完了後
(2)　詳細設計完了後
(3)　プログラム検収後

ポイント2～対価の変更

　システム開発においては、ユーザ（発注者）側から仕様や機能の追加や変更の要望がなされることは珍しくありません。

　この場合に、ベンダ（受注者）側として、この要望を断ることは難しい場合も多く、かつ要望の内容によっては当初の費用では行えない、というケースが少なくありません。

　そのため、上のサンプルのように、対価の変更の協議の余地を定めておくことは有益といえます。

瑕疵担保責任・保証

　以下は「瑕疵担保責任・保証」に関する比較的シンプルな条項の例です。

第＊条（瑕疵担保責任）
１　本成果物の検査完了日から６か月以内に、検査の時点では判明できなかった本成果物の瑕疵（契約不適合）が発見された場合には、乙は、自らの費用と責任において修正するものとする。修正が不可能又は著しく困難な場合、乙は、甲に対し、当該違反に応じた委託代金の減額をなすものとする。
２　前項の瑕疵（契約不適合）は、本成果物が、甲乙が別途定める仕様書に適合しないことに限るものとする。
３　本成果物に関する保証は本条第１項に定めるものをもってすべてとし、本成果物にかかる保証違反及び瑕疵に関する乙の責任は本条に定めるものに限るものとする。

ポイント１～瑕疵の内容

瑕疵の内容の明確化の必要性

　まず、瑕疵担保責任における「瑕疵」（2020年4月1日から施行された改正民法では「契約不適合」）の内容を明確にすることは重要です。

　「瑕疵」とは、きずや欠陥といった意味の法律用語です。言い換えれば、一般的には通常備わっているべき、機能・性能・品質・状態が備わっていないことをいいます。

　この点で、システム開発の成果物における瑕疵については、特にベンダー（受注者）側としては、できる限り明確化・限定することが重要となります。この点が不明確だと、仕様どおりに開発しても、ユーザー（発注者）の意図や好みに合わないという理由での成果物の修正を求められるなどの不都合が生じることにつながりかねないからです。

　上のサンプルでは、瑕疵（契約不適合）の定義について、仕様書適合性違反のみと明示した上で、３項で、保証違反に関する責任は同条に定めるものに限定するという、比較的ベンダー側（受注者）寄りの規定となっています。

仕様を明確にする

　この場合、ユーザ（発注者）側もベンダ（受注者）側も、曖昧な仕様書は紛争の種になることになりますので、仕様書において必要十分な要求を明示しておくことは、特に重要となってきます。

　例えば、保証に関連して、以下のような内容について仕様書で明示することが重要といえます。

システムの規模（接続端末数、同時利用者数、トランザクション量、データ量）
システムの稼働環境（ハードウェア構成、ソフトウェア構成、ネットワーク構成）
システムの機能の詳細
システムの中立性・特定の技術や環境への依存性
システムの性能の詳細（速度、処理量）
画面の一覧と遷移
システムの信頼性、安全性（システム停止時間・頻度、障害からの復旧手順、データ消失対策、バックアップ方法等）
セキュリティ上の対策（機密性、可用性及び完全性、権限管理、アクセス制御、データ暗号化）
データに関する要件
処理連携・データの授受を行う他のシステムとの間でやりとりするデータ、インターフェイス、連携方式、データ量・頻度、タイミング、制約条件等
システムの運用時間・監視に関する要件
テスト実施要件

ポイント２～保証の始期と保証期間

　保証の期間（瑕疵担保責任の期間）と始期を定める必要があります。

保証の期間

　保証の期間については、上の例では６か月としています。実務上は、1年間とされるケースも少なくありません。保証期間については、システムの規模、性質等を考慮してケースバイケースにより、当事者間で定めることとなります。

保証期間の始期

　同期間の始期については、サンプルでは「検収完了」時を始期としています。この点、納入時という選択肢もありえます。

改正民法との関係

　2020年4月1日から施行された改正民法では、瑕疵担保（改正法では「契約不適合」）責任の追及ができる期間が変更されました。その結果、原則、契約不適合（瑕疵）を「知った時」から1年以内に通知をすればよいという形に変わりました（改正民法637条1項^{[カーソルを載せて条文表示]}）。

　そのため、改正民法の施行後に締結された契約においては、瑕疵担保責任（契約不適合責任）の期間や始期を定めないと、ベンダーは長期にわたり瑕疵（契約不適合）について責任を負うことになります。

　この点、改正民法の前記規定は、「任意規定」といい、契約でこれを変更することができます。したがって、改正民法施行後は特に、ベンダー（受注者）側は、契約において、瑕疵担保責任（契約不適合責任）の始期と期間を明確にする必要性は強くなるといえます。

　つまり、改正後であっても、瑕疵担保責任の始期を「ユーザーが知ったとき」ではなく、「納品時」や「検収時」とすることは可能ですし、今までと同様、これらの始期から6ヶ月や1年という定め方はできるわけです。

ポイント３～保証違反・瑕疵の場合の対応

　保証違反（瑕疵担保責任）が生じた場合の対応を明示します。

　この点、民法で認められている瑕疵担保責任（契約不適合責任）は、瑕疵の修補（修正）、代品の納入、代金減額、損害賠償です。なお、瑕疵担保責任の具体的な内容については、「納入後の瑕疵(契約不適合)」のページをご覧ください。

　しかしながら、契約においては、瑕疵担保責任（契約不適合責任）についての民法の規定を修正することができます。それで、当事者間の協議によって、民法に定める責任の一部のみをベンダーの責任として規定することも可能です。

　上のサンプルでは、比較的ベンダー側（受注者）寄りの規定として、基本的には修正（修補）の義務のみとし、修正が不可能又は著しく困難な場合、違反に応じた委託代金の減額をなすという規定としています。

著作権の帰属

問題の所在

　システム開発契約において合意に至りにくい規定に、開発したシステムの著作権の帰属の規定があります。発注者側は、お金を出して開発を委託する以上発注者側に帰属すると規定したいと考えます。他方ベンダー側は、開発成果物の一部やノウハウを再利用したいといった要請や、もともと持っていたライブラリなどを使っている部分について再利用できなくなってしまうことを考えて自社に留保したいと考えることが少なくありません。

　それで、契約締結においては、著作権の移転の有無、またベンダー側が留保する権利があれば、全部とするか必要な範囲とするか等を明確にする必要があります。また著作権を移転させなくとも行える別の方策もあります。

　この点、一般的に見られる、著作権の帰属に関する規定には以下のようなバリエーションがあります。それぞれの主たる法的効果は以下のようなものです。こうしたバリエーションを念頭に複数の案を持っておき、交渉に臨むことも有益かもしれません。

著作権の帰属に関する規定のバリエーション

一般的に見られる、著作権の帰属に関する規定には以下のようなバリエーションがあります。

著作権：ユーザーに移転

規定の要旨

＜ユーザー側＞　成果物の著作権はユーザーに移転する
＜ベンダー側＞　定めなし

解説

　成果物の著作権はユーザーに移転する規定のみが定められている条項であり、ユーザーにとっては最も有利な規定ではあります。

　他方ベンダー側としては、成果物をパッケージ化して横展開することは通常はできませんし、すでに持っているモジュールや改めて開発した汎用的なモジュールについての再利用の可否についても疑義が生じることがありますので、受け入れにくいと感じるかもしれません。

著作権：ユーザーに移転　　既存の著作物等：ベンダーに留保

規定の要旨

＜ユーザー側＞　成果物の著作権はユーザーに移転する
＜ベンダー側＞　既存の著作物や今回の成果物のうち汎用的なモジュールの著作権はベンダーに留保

解説

　成果物の著作権はユーザーに移転するため、ユーザーにとっては、今後の追加開発や成果物の修正なども自ら行えますので、特段の不都合は少ない規定ではあります。もっとも、ベンダーに留保された部分についてユーザーが手を入れることの可否について疑義が残るという観点からは、ベンダーに留保された部分も、ユーザーが自由に使える（改変も含め）ことについて許諾する規定を含めるとより安心かもしれません。

　ベンダー側としては、すでに持っているモジュールや改めて開発した汎用的なモジュールについての再利用の可否について疑義が生じないという点で、他の開発案件について足かせとならないことから、受け入れる余地は少なくないといえます。ただし、この規定では成果物をパッケージ化して横展開することは通常はできません（もっとも、同種の機能を持つ成果物を設計からやり直せば可能ではあります）。

著作権：ベンダーに留保　　ユーザーへライセンス

規定の要旨

＜ユーザー側＞　成果物について一切の著作権法上の行為（改変含む）について許諾を受ける
＜ベンダー側＞　成果物の著作権はベンダーに留保

解説

　成果物の著作権はベンダーに留保されるものですが、ユーザーは、改変も含めた一切の行為について許諾を受けるというスキームです。この場合も、今後の追加開発や成果物の修正なども自ら行えますので、特段の不都合は少ない規定ではあります。

　ただしこの場合、ユーザーにとっては、こうした許諾を受ける地位（利用権）を、事業譲渡などに伴って第三者に移転させられるか疑義が残ることがありますので、この点を契約上フォローすることも必要な場合があります。またベンダーの倒産の場合に成果物の著作権が第三者に移転してしまうというケースへの手当も必要となると思われます。

　また、成果物の著作権がベンダーに留保される結果、ベンダー側は今回の成果物を利用した横展開する可能性があることになりますが、そこでユーザー側の秘密情報が使用されないような手当も必要になると考えられます。

　ベンダー側としては、すでに持っているモジュールや改めて開発した汎用的なモジュールについての再利用の可否について疑義が生じないという点で、他の開発案件について足かせとならない上、成果物をパッケージ化して横展開することも通常は許されますので、使い勝手は良いといえるかと思われます。

著作権：ベンダーに留保

規定の要旨

＜ユーザー側＞　規定なし
＜ベンダー側＞　成果物の著作権はベンダーに留保

解説

　成果物の著作権はベンダーに留保されるものですが、ユーザー側の権利移転については規定がない、というパターンです。この場合でも、成果物を自社で使用することについては、著作権の移転を受けなくても当然にできることなので、純ユーザーにとどまるなら、支障がないというケースもあることと思います。

　もっとも、今後の追加開発や成果物の修正などは、ベンダー側は自らは行えない、ということになります。例えば万一ベンダー側と揉めてしまい関係を終わらせたという場合も、ベンダーに留保された著作権が障害となり、第三者に修正や機能追加なども依頼できないという自体になりうる点は、問題となるかもしれません。またベンダーの倒産の場合に成果物の著作権が第三者に移転してしまうというケースへの手当も必要となると思われます。

著作権：触れない

規定の要旨

＜ユーザー側＞　規定なし
＜ベンダー側＞　規定なし

解説

　成果物の著作権について、「触れない」というパターンです。ただし紛争の温床ともなり、望ましくはありません。

　まずユーザー側は、著作物は実際の創作行為を行った者に帰属するというのが著作権法上の原則であることを頭に入れておく必要があります。それで、「触れない」というパターンの場合、著作権がユーザー側に移転しないというのが原則です。ただし、成果物を自社で使用することについては、著作権の移転を受けなくても当然にできることなので、純ユーザーにとどまるなら、支障がないというケースもあることと思います。

　もっとも、いざ紛争時には、開発成果物と委託金額のバランスから、著作権の移転が暗黙のうちに合意されたと主張したり、少なくともユーザー側は改変の権利について許諾を受けていた等の主張を行うことは可能ですが、これが認められるかどうかは不透明です。

　ベンダー側としては、著作権の帰属についてユーザー側との交渉が難航する場合、「触れない」という案を奥の手として使い、著作権法上の原則（創作行為を行った側に帰属）を活用するという手段はないとはいえません。

　もっとも、成果物をパッケージ化して横展開したといった場合に、ユーザー側から、「高額な費用を払ったのだから著作権はユーザー側に移転するのは当然だ」等の主張を受け訴訟に至るなど、思わぬ落とし穴が待っている可能性があります。

他者ソフトウェア・オープンソース等の利用

　
　以下は「他者ソフトウェア・オープンソース等の利用」に関する比較的シンプルな条項の例です。

第＊条（第三者のソフトウェアの利用）
１　本件ソフトウェアにおいて第三者が権利を有するソフトウェア（以下「第三者ソフトウェア」）を使用し、又は組み込む必要がある場合、乙は、乙の費用と責任において、乙と当該第三者との間で、当該第三者ソフトウェアの使用に必要な権限を取得し、維持するものとする。
２　前項の第三者ソフトウェアがオープンソースソフトウェアである場合、乙は甲に対し事前に使用につき申請し、承認を得るものとする。

ポイント１～第三者のソフトウェアを使用する場合の取扱

　受託開発において、第三者のソフトウェアを使用する必要が生じるかもしれません。あるいは開発期間を短縮することができるという判断から、これらのソフトウェアを使用したいと考える場合もあると思います。

　しかし、受託者側が正当な権利を得ずに第三者のソフトウェアを使用し、後に権利侵害の問題が生じるという事態は委託者側にとっては避けたいとことです。それで、１項では、第三者のソフトウェアの使用について、受託者側に、権限の取得と維持の義務を課す規定を設けています。

　もっとも、１項の場合も、２項のオープンソースの場合と同様、受託者側に事前に申請をしてもらい、承認を必要とする、という規定の仕方もあります。

ポイント２～オープンソースソフトウェアを使用する場合

　受託開発において使用する第三者のソフトウェアがオープンソースソフトウェアである場合もあります。この場合、通常は使用権限の問題は生じませんが、別の厄介な問題が生じることはあります。

　特に、使用するオープンソースが準拠するライセンス条件が、伝搬性の強いもの（GPLなど）の場合、GPLソフトウェアをその一部に使用したソフトウェアについては、当該GPLソフトウェアの派生物として、GPLが適用されることになると考えられています。したがって、委託開発したプログラムの一部のモジュールが自社の意図に反してソースの公開を余儀なくされるといった事態が生じないとも限りません。

　また、多くのオープンソースソフトウェアは、使用条件として、現状有姿（”AS IS”）で瑕疵担保責任を負わないという点が含められることが多いため、委託開発したソフトウェアにつき、瑕疵担保責任の追求が制限される事態も生じえます。

　そこで、上のサンプルでは、２項として、オープンソースを使用する場合には事前承認を要するという規定としています。

　なお、オープンソースソフトウェアの概要についての説明は、https://www.ishioroshi.com/biz/kaisetu/it/index/oss_outline/　をご覧ください。

知的財産権紛争の処理

　以下は「知的財産権紛争の処理」に関する比較的シンプルな条項の例です。

第＊条（知的財産権侵害への対応）
１　乙は甲に対し、委託業務に基づく本成果物が、納品時において、日本国内において成立している第三者の著作権、著作者人格権、特許権、実用新案権、意匠権、ノウハウ、営業秘密又は他の知的財産権（以下これらをあわせ「知的財産権」という。）を侵害していないことを保証する。
２　前項に反し、本成果物が第三者の知的財産権を侵害した場合、乙は、第＊条に定める委託料総額を限度として、当該侵害によって甲が受けた損害を賠償するものとする。
３　前二項の規定は、本成果物の知的財産権侵害が、甲が指定又は提供した仕様、データ、又は素材によって生じた場合については適用しない。

ポイント１～保証内容と範囲

　まず、成果物に関する知的財産権侵害の保証の有無、内容と範囲を明確にすることは重要です。ベンダ（受注者）としては保証責任を負わないのがベストでしょうが、ユーザ（発注者）がこうした保証を求めるのはある意味自然ともいえます。

　それで、上のサンプルでは、「納品時」「日本国内において成立」という限定を加える例を挙げています。他方、こうした限定を加えない保証規定を定める例もあります。

　また、他の例としては、保証期間を一定期間に制限する例、非侵害という結果を保証するのではなく、侵害の有無について合理的な調査をした旨を保証する例、などもあります。

ポイント２～保証違反の場合の責任

　また、保証違反が生じた場合の責任について規定する例は少なくありません。

　上のサンプルでは、ベンダ（受注者）寄りの規定として、侵害の結果が生じた場合に、かつ委託料を上限として補償する規定としています。

　しかしながら、ユーザ（発注者）としては、補償の上限を定めることは望まないことが多く、上限を定めない例も多く見られます。

　また上のサンプルのように、侵害の結果が生じた場合のみならず、侵害を理由とした紛争が生じた場合の対応費用（弁護士費用を含む）の補償を定めるケースもあります。

　また、補償責任を負うベンダとしては、侵害を争う機会を確保したいと考えることも多いため、補償の前提として、侵害の主張があった場合のユーザ（発注者）の通知義務、ベンダに対して紛争解決の権限を付与すること、ユーザ（発注者）が解決する前にはベンダの同意を得ることなどの規定を置くことを検討する場合があります。

ポイント３～保証責任の例外

　ベンダとしては、ユーザ（発注者）が定めた仕様や素材に基づき開発する場合などは、保証責任を負えないと考えるのは当然といえます。

　それで、ケースに即して、保証責任の例外規定を含めることは重要といえます。

再委託

　以下は「再委託」に関する比較的シンプルな条項の例です。

＜例１　再委託を承認制とするもの＞

第＊条（再委託）
１　乙が委託業務の全部又は一部につき第三者に再委託しようとする場合、甲の事前の書面による承認を得るものとする。
２　乙が前項に定める承認を得て再委託をなす場合においても、再委託先に対して本契約に定める義務と同等以上の義務を負わせるとともに、再委託先の行為について一切の責任を負うものとする。
３　甲は、第１項に定める承認をいつでも撤回することができる。

＜例２　再委託を原則自由とするもの＞

第＊条（再委託）
　乙は、必要に応じて、委託業務の全部又は一部につき、乙の責任において第三者に再委託することができる。ただし、乙は、再委託先に対し、第＊条に定める乙の秘密保持義務を含めた乙の義務と同等以上の義務を負わせるものとする。

ポイント１～再委託の可否

　システム開発業務においては、業務の一部を再委託や再下請することは珍しくなく、ときにはこうした再委託・再下請先関係が何層にもわたることもあります。

　そこで、システム開発委託契約においては、再委託の可否について契約で定められる場合が多いといえます。なお、契約において再委託に関する規定がない場合にどのように考えるかについては、「再下請・再委託」のページをご覧ください。

再委託の事前承認制の規定

　さて、再委託の可否に関する規定で比較的多いのは、上のサンプルのうち「例１」にあるような、再委託を事前承認にかからせるという規定です。

　すなわち、ユーザ（発注者）側としては、ベンダ（受注者）が自由に再委託できる状況だと、責任の所在が不明確になったり、秘密情報や個人情報の情報漏えいのリスクが高まるといった懸念があることから、事前承認制を好むことが多いといえます。

再委託を自由とする規定

　他方、上のサンプルのうち「例２」にあるような、再委託を自由とする規定もないことはありません。

　この場合には、ベンダ（受注者）としては適宜かつ臨機応変に再委託ができるようになるというメリットがあります。ただしこの場合も、当然ですが、ベンダ（受注者）は、再委託先に対しては、開発委託契約上の義務を負わせ、適切な監督や管理をする必要があります。

再委託に関する他の規定

　以上の典型的なパターンのほか、以下のような定め方をすることもあります。ユーザ（発注者）側とベンダ（受注者）側の利益のバランスを考えた妥協案・オプションとして考えてもよいかもしれません。

再委託を事前承認制ではなく、事前通知制とする。
再委託を事前承認制とするが、契約時点ですでに再委託を具体的に考えている再委託先については、契約において再委託可能である旨を明示する。

ポイント２～再委託先の管理・再委託先の行為に対する責任

　システム開発業務を再委託する以上、再委託先の管理について、多くの場合、ベンダ（受注者）の義務や責任が定められます。その内容としては、以下のものが例として考えられます。

再委託先に対し、ベンダ（受注者）が負う義務と同等以上の義務を負わせるようにする義務
再委託先の行為について、ベンダ（受注者）が全面的に責任を負うようにする
再々委託をしない義務/li>
再委託先について審査をし、反社会的勢力の有無、財務状況、業務遂行能力、情報セキュリティ体制についてチェックする義務
再委託先の情報セキュリティ体制や再委託先との情報受渡しの記録をユーザ（発注者）に開示する義務

ポイント３～再委託に関する発注者（ユーザ）の権利

　システム開発業務の再委託に関し、ユーザ（発注者）の権利を定めておくというケースも見られます。例えば以下のようなものが考えられます。

再委託の承認を撤回・取り消すことのできる権利
再委託先への立入調査・業務モニタリングを実施する権利

秘密保持（機密保持）

　
　以下は「秘密保持（機密保持）」に関する条項の例です。

第＊条（機密保持義務）
１　本契約において、「機密情報」とは、有形・無形を問わず、委託業務を遂行するに際して、一方当事者（以下「受領当事者」という。）が知り又は知り得た他方当事者（以下「開示当事者」という。）の技術上、営業上、業務上その他の一切の情報（ノウハウを含む）をいう。ただし、次のいずれかに該当する情報は機密情報に含まれない。
(1) 開示の時点ですでに公知の情報、又はその後受領当事者の責によらずして公知となった情報
(2) 開示するについて開示当事者の書面による同意を得た情報
(3) 受領当事者が第三者から秘密保持義務を負うことなく正当に入手した情報
(4) 開示の時点ですでに受領当事者が保有している情報
(5) 受領当事者が機密情報によらず独自に開発した情報

２　前項の規定にかかわらず、個人情報の保護に関する法律に定義される個人情報については、前項ただし書きを適用しない。

３　受領当事者は、善良なる管理者の注意義務をもって管理し、事前に開示当事者の書面による承諾を得ることなく、機密情報を第三者へ開示・漏洩しない。ただし、監督官庁の正当な要求若しくは法令の定めに従って開示する場合、受領当事者の役員・従業員（当該個別業務の遂行上必要な者に限る）、弁護士、若しくは会計士その他法律上機密保持義務を負う者への開示はこの限りではない。

４　受領当事者は、開示当事者から開示された機密情報を、委託業務に直接に関連する目的にのみ使用し、他のいかなる目的にも使用してはならない。

５　受領当事者は、委託業務に直接関与するその役員及び従業員並びに委託業務の委託先（第●条に基づき甲の承認を得たものに限る）をに機密情報を開示することができる。ただし、これら役職員若しくは委託先に対し、退職後若しくは委託契約終了後も含めて本条の機密保持義務を遵守させるものとし、これらの者の機密保持義務違反について一切の責任を負うものとする。

６　受領当事者は、本契約終了後又は開示当事者から要請があった場合には、提供された機密情報を開示当事者の指示にしたがって返還し、又はその責任において廃棄し、廃棄したことを証する書面を提出する。

７　本条の機密保持義務は、本契約終了後も有効に存続する。

８　前各項にかかわらず、乙は、本条の義務に反しない範囲で、自己の実績として、乙のウェブサイト、パンフレット、会社案内及びその他の資料において、甲と取引を行った事実を掲載又は表示することができ、当該目的に限って、甲の商標を使用することができる。

ポイント１～機密情報の定義

　機密情報の定義については以下の複数の視点から考える必要があります。

網羅的定義と限定列挙

　機密情報の定義については、大まかにいえば以下の２つの考え方があります。

開示される情報の一切を網羅的に機密情報とした上で、一定の例外を設けるパターン
開示される情報の種類を限定して機密情報として列挙するパターン

　この点、開発業務委託基本契約など、複数の開発案件を個別契約で行うための契約では、前者のパターンが多いと思われます。

「機密」表示の有無

　また、機密情報の定義の中に、「機密」「Confidential」などの表示を必要とする場合もあれば、そうでない場合もあります。

　前者のメリットとしては、受領当事者として何が保持すべき機密なのかの見分けがつきやすい、という点があります。他方、前者のデメリットとしては、機密情報にいちいち表示をしなければならないという点で煩瑣であること、またうっかり表示を忘れてしまった場合に、相手方が秘密として管理しなくても責任を問えない、という点があります。

　他方、後者のメリットとしては、機密情報にいちいち表示をしなくてもよいという点は簡便であり、うっかり表示を忘れてしまった場合でも責任追及が直ちにできなくなることはないという点があるものの、デメリットしては、何が機密情報で何が機密情報ではないのかの区分が曖昧になり、相手方が意図せずに違反行為をしてしまう原因を作ってしまうといというデメリットがあります。

　もっとも、前者の定義を取るとしても、実務上の扱いとしては、開示先が機密としてきちんと管理することを望むのであれば、「機密」「Confidential」といった表示をつけることをルール化・習慣化することが望ましいと考えます。

ポイント２～機密保持の例外事項

　また、機密情報としての取扱から除外される例外事由として規定することが、実務上頻繁になされています。

　その例としては、サンプルのような、「既知」、「公知」、「第三者からの知得」、「独自開発」が主たるものです。また、機密保護を重視する立場からは、サンプルのような規定に代えて、「次のいずれかに該当することを受領当事者が書面その他の客観的証拠によって証明することのできる情報は機密情報に含まれない。」といった形で、例外事由の適用についての立証方法を厳格にするという規定もありえます。

　また、個人情報については、例外事由を適用しないという規定も多く見られます。電話帳のように個人情報の一部が公開されたとしても、それが保護されないというのは不合理だからです。

ポイント３～開示を許す場合

法令等に基づく開示

　実務上、税務当局や許認可官庁などの行政機関、司法機関等から、機密情報の開示を要求される場合があります。また、弁護士や会計士などから助言を得るため機密情報を開示する場合もあります。

　そえでこうした事態に備えて、機密保持義務についての例外を定めておくことが有益といえます。もっとも、弁護士や会計士といった法律上当然に守秘義務を負う専門家への開示は、サンプルにあるような例外規定がない限りはできないと考える必要はなく、実務上は許されています。

　もっとも、官公庁からの秘密情報の開示要求があった場合、当然にこれを例外として許すのではなく、開示者に対して当該要求のあった旨を遅滞なく書面にて通知すること、開示が要求されている部分について厳格に限定して開示すること、開示者が官公庁に意見を述べる機会を与えること、といった条件をつける規定も考えられます。

社内や再委託先への開示

　社内では、機密情報を直接知る必要がある役職員にのみ開示する、社外では承認を得た再委託先へのみ開示することができる、といった規定を定めることが多く見られます。

　またこの場合、当該役職員や業務委託先に機密保持義務を課す義務や、特に退職後や業務委託終了後もその義務を存続させる規定、また受領当事者が連帯して責任を負うことなどを定めることを検討できます。

ポイント４～機密保持義務の存続期間

　秘密保持義務については、開発委託契約が終了しても存続させる必要があることから、その旨を規定することは重要です。

　この点、3年～5年といった期間存続するという規定と、特に期間を定めずに、公知化等がない限り存続するという規定があります。

　これらは、秘密情報を受領する側の手間、機密の性質と陳腐化の有無や速度などを考えて設定します。

損害賠償の制限・範囲

　以下は「損害賠償の制限・範囲」に関する条項の例です。

第＊条（損害賠償の制限）
１　本契約のいずれかの当事者が、本契約に違反して相手方に損害を与えた場合には、当該当事者は、直接かつ現実に生じた通常の損害を賠償する責を負うものとする。ただし、逸失利益、事業機会の喪失、データの喪失、間接損害、特別損害、派生的損害及び付随的損害は除くものとする。
２　一方当事者が他方当事者に対して負う損害賠償の累計総額は、債務不履行、瑕疵担保責任、不当利得、不法行為その他請求原因のいかんにかかわらず、当該損害発生事由にかかる個別契約に定める委託料相当額を限度とする。

損害賠償の制限規定の意義

　システム開発契約では、開発遅延により発注者（ユーザ）がビジネス機会等を失ったことによる損害が発生すると、損害額が膨大なものとなることがありえます。

　このような多額の損害賠償義務は、会社の事業継続や存続自体にすら重大な影響を与えることがあることから、これを回避するため、損害賠償の制限のための規定が置かれることがあります。

ポイント２～「範囲」の制限

制限の趣旨・目的

　損害賠償の範囲を制限する方法として、損害が生じた原因・因果関係や賠償項目の種類によって損害賠償を制限するという定め方があります。

逸失利益の除外

　典型的な除外項目として、「逸失利益」があります。

　「逸失利益」とは、契約が履行できていれば得られたと想定されるのに、契約が履行されなかったゆえに、又は履行が遅延したゆえに得られなかった利益をいいます。

　客先の重要な事業に関わるシステムの開発を遂行する場合、開発が頓挫した場合のほか、遅延した場合でも、客先が重要なビジネスの機会を逃したという理由で莫大な損害の賠償を請求する場合があります。

　それで、こうした賠償額を特に大きくする損害費目を賠償の対象から明示的に除外する規定が考えられます。

「直接かつ現実に生じた通常の損害」「特別損害」等

　また、契約規定上、「直接かつ現実に生じた通常の損害」を賠償の範囲として限定し、対象とならないものとして「特別損害」「偶発的損害」「間接損害」「付随的損害」「派生的損害」といった損害を除外することも実務上少なくありません。

　これら用語のうち、日本法において定着しているのは、「通常損害」と「特別損害」です。通常損害とは、ある不履行の事実によって、通常予見しうる範囲の損害と考えられています（民法416条1項^{[カーソルを載せて条文表示]}）。

　他方、特別損害とは、特別の事情によって生じた損害、つまり通常は予見し得ない損害をいいます。民法では、特別の事情によって生じた損害であっても、当事者がその事情を予見することができたときは、その賠償を請求することができるとされています（民法416条2項^{[カーソルを載せて条文表示]}）。

　したがって、契約条文上「特別損害」を賠償の対象から除外することは、通常は予見し得ない損害を賠償の対象から除外するものとして機能することが考えられます。

「偶発的損害」「付随的損害」「派生的損害」

　他方、「偶発的損害」「付随的損害」「派生的損害」は日本民法の用語ではないので、具体的な裁判においてどのように機能するかはケース・バイ・ケースではあります。

　もっとも、通常はおよそ予見できないような特殊な損害や、ある債務不履行行為と損害の間に多重の因果関係が入るような損害（「風が吹けば桶屋が儲かる」のようなもの）は、通常は賠償の対象からは除外されるはずです。

ポイント３～「損害賠償額」の制限

　また、損害賠償責任の軽減の別の方法として、端的に、損害賠償額の上限を定めるという方法もあります。

金額の定め方

　上限金額の定め方はどのようにしたらよいのでしょうか。少なくともBtoBに関する契約である限り、その「上限」に特に決まりはありません。開発委託契約では、開発委託料と同額の金額を上限とする、という定め方が比較的よく見られます。

　他方、開発委託契約とは離れますが、例えばＡＳＰやＳａａＳなどの利用契約において、または保守契約において、ユーザが月額利用料を支払うというケースですと、賠償額の制限が極端に低すぎると、無効と判断されるおそれがある点は留意する必要があります。

　例えば、「１ヶ月分の利用料」といった制限額ですと、無効になるリスクが上がってしまうように思います。

「現実に支払済みの対価相当額」とする考え方

　また、時折目にする損害賠償額の上限として、「当該損害発生事由にかかる個別契約に定める委託料相当額であって現実に支払われた額を限度とする」といった定め方がされているものがあります。

　この文言を文字どおり解釈すれば、未払いの段階で損害賠償の請求があった場合、賠償額がゼロになるということになります。ただしこの規定が現実の裁判でどう解釈されるかは未知数の部分があります。

弊所と法律相談等のご案内

弊所へのご相談・弊所の事務所情報等については以下をご覧ください。

契約法務弁護士費用自動見積のご案内

　弊所の弁護士費用のうち、以下のものについては、オンラインで自動的に費用の目安を知ることができます。どうぞご利用ください。

弁護士費用オンライン自動見積ページに移動する

英文契約・和文契約のチェック・レビュー
英文契約・和文契約の翻訳（和訳、英訳）

メールマガジンご案内

弊所では、メールマガジン「ビジネスに直結する判例・法律・知的財産情報」を発行し、比較的最近の判例を通じ、ビジネスに直結する法律知識と実務上の指針を提供しております。

学術的で難解な判例の評論は極力避け、分かりやすさと実践性に主眼を置いています。経営者、企業の法務担当者、知財担当者、管理部署の社員が知っておくべき知的財産とビジネスに必要な法律知識を少しずつ吸収することができます。主な分野として、知的財産（特許、商標、著作権、不正競争防止法等）、会社法、労働法、企業取引、金融法等を取り上げます。メルマガの購読は無料です。ぜひ、以下のフォームからご登録ください。

バックナンバーはこちらからご覧になれます。　https://www.ishioroshi.com/biz/mailmag/topic/

ご注意事項

本ページの内容は、執筆時点で有効な法令に基づいており、執筆後の法改正その他の事情の変化に対応していないことがありますので、くれぐれもご注意ください。

メールマガジンご案内

メールマガジン登録
「ビジネスに直結する
判例・法律・知的財産情報」

特許・商標と知的財産・ITに強い・企業法務中心 弁護士法人クラフトマン