業務委託契約書｜エンジニア特有 4 領域の追加条項と書き方サンプル

汎用の業務委託契約書テンプレートは社内法務やひな形提供サービスから入手できますが、エンジニアへの発注では「テンプレートに書かれている条項だけで十分なのか」という不安を抱える発注担当者が少なくありません。検収の判定基準・ソースコードや OSS の権利関係・本番環境へのアクセス権・退任後の機密情報の取り扱いは、汎用ひな形が想定する一般的な業務委託では深掘りされにくい領域です。

実際に、過去に「検収で揉めて支払いが止まった」「納品されたコードに OSS が混じっていてライセンス確認に追われた」「退任後も本番環境の権限が残っていた」といった経験を持つ発注組織では、汎用テンプレートをそのまま使うことに対して強い警戒感が生まれます。一方で、社内に IT 法務の専任担当がいない場合、「何を追記すれば足りるのか」を自力で組み立てるのは負荷の高い作業です。

本記事では、汎用の業務委託契約書テンプレートを土台にして、エンジニア案件で特に重要となる 検収基準・著作権・情報セキュリティ・機密保持 の 4 領域について、追加すべき条項のポイントと文言例を整理します。「既存ひな形に何を足すか」というアドオン視点で構成しているため、汎用 13 項目の網羅解説は業務委託契約書テンプレート（発注側）に委ね、本記事ではエンジニア特有の深掘り部分に紙面を集中させます。

読み終えたあと、手元のテンプレートに対して「どの位置に・どんな文言で」追加条項を組み込めばよいかが分かり、社内法務レビューに通せる状態の契約書ドラフトを準備できることを目指します。なお、業務委託契約書の本文だけでは判断しきれない論点（偽装請負ライン・損害賠償上限の妥当水準など）も後半で整理し、自社単独で抱え込まずに済む判断軸を提示します。

エンジニア向け業務委託契約書の特有条項が必要な理由

汎用テンプレートが想定していないエンジニア案件のリスク

汎用の業務委託契約書ひな形は、コンサルティング・デザイン・事務代行など幅広い業種を想定して作られているため、エンジニア案件特有のリスクが条項として深掘りされていないケースが大半です。代表的なトラブルとして、次の 3 パターンが繰り返し発生しています。

1 つ目は 検収トラブル です。仕様書の解釈差や残バグの扱いをめぐって「完成したかどうか」の判定で揉め、支払いが止まる、または受託者から検収を強制される事態に発展します。汎用ひな形では「成果物を検収後、対価を支払う」程度の一文しかなく、合否判定の基準・再修正回数・みなし検収の扱いが定義されていないことが原因です。

2 つ目は 著作権・OSS トラブル です。納品されたソースコードに OSS（オープンソースソフトウェア）が組み込まれていた場合、ライセンス条件によっては自社の派生コードまで開示義務が発生する可能性があります。汎用ひな形は「成果物の著作権は発注者に帰属する」と一文で済ませがちですが、OSS・既存資産の流用・再利用権の扱いまでは触れません。

3 つ目は セキュリティ事故 です。業務委託エンジニアが顧客データや本番環境にアクセスする案件では、アクセス権の付与範囲・端末管理・退任時の権限剥奪が契約で定義されていないと、事故発生時の責任所在が曖昧になります。

追加すべき 4 領域（検収基準・著作権・セキュリティ・機密）の全体像

エンジニア案件で発生しやすいトラブルを契約条項で先回りするには、汎用ひな形に対して次の 4 領域を追加・強化する必要があります。

この 4 領域は独立したテーマではなく、相互に連動しています。たとえば検収条項で「ソースコードの納品」を定義する際は、著作権譲渡条項で「どの範囲のコードが譲渡対象か」を明示する必要があり、本番環境にアクセスする案件では情報セキュリティ条項と機密保持条項の存続期間が連動して退任後の防御線になります。

本記事の使い方（手元のひな形にアドオンするための読み方）

本記事は「汎用ひな形に追加する条項のセット」を 4 領域ごとに提示する構成です。読み進めるにあたっては、手元の業務委託契約書テンプレートを開きながら、次の順序で参照すると効率的です。

まず、各セクションの冒頭で「何が問題か」を確認し、続くサブセクションで具体的な条項要素と書き方を把握します。各セクションの最後には「文言例」を引用ブロック形式で掲載しているため、手元のひな形に対応する条文がない場合はそのまま参考にしてください。最後に、4 領域すべてを反映したうえで、後述の「アドオン条項を契約書に組み込む手順」のチェックリストで抜け漏れを確認する流れになります。

検収基準のアドオン条項｜エンジニア案件で「完成」を巡る紛争を防ぐ書き方

検収条項に書くべき 6 つの要素

エンジニア案件で検収トラブルを防ぐには、契約書本文に次の 6 要素を盛り込むことが推奨されます。

1. 検収期間: 成果物の納品から発注者が検収完了通知を出すまでの期間（営業日数で明記）。一般的には 10〜14 営業日が目安ですが、案件規模に応じて調整します。
2. 検収通知方式: 合格・不合格の通知方法（書面・電子メール・電子契約サービスのいずれを正式とするか）。
3. 合否判定基準: 別紙仕様書および受入テスト計画書に定める判定項目を満たしているかどうかで判定する旨を明記します。
4. 再修正回数の上限: 不合格時に受託者が修正を行う回数の上限。無制限にすると検収が長期化するため、通常 2〜3 回程度に設定します。
5. みなし検収: 検収期間内に発注者から合否通知がない場合に検収完了とみなすか否か。みなし検収を採用する場合は、発注者にとって不利になりすぎないよう期間設定に注意します。
6. 支払い起算日: 検収完了日を支払い起算日とすることで、検収と支払いを連動させます。

これらを契約書本文に書き切ろうとすると条文が長大になるため、判定項目の具体は別紙に切り出すのが実務的です。

別紙仕様書・受入テスト計画への切り出し方

検収の合否判定を客観化するには、契約書本文・別紙仕様書・受入テスト計画書の 3 点セットで設計する考え方が有効です。

「仕様書に丸投げ」になりがちな案件では、別紙仕様書を作成しても判定基準が曖昧なままになることが多いため、受入テスト計画書を別紙として明示的に位置づけることが重要です。受入テストの合格基準を「致命バグの発生件数」「主要機能の動作可否」など定量的に書くことで、検収時の解釈差を最小化できます。

契約不適合責任の期間・範囲を発注者保護で設定するポイント

検収完了後に欠陥が発見された場合の責任を定めるのが契約不適合責任です。改正民法（民法 562 条以降）では、買主・発注者は契約の内容に適合しない目的物について、追完請求・代金減額・損害賠償・契約解除を選択できる仕組みになっています（e-Gov 法令検索 民法第五百六十二条）。

エンジニア案件で発注者保護を厚くするには、次の点を契約書に明記します。

• 責任期間: 検収完了日から 1 年程度を目安に設定する案件が一般的です。バグの種類によっては短すぎる場合があるため、重大な脆弱性については別途長期の責任期間を設ける選択肢もあります。
• 責任範囲: 仕様書記載の機能不全だけでなく、性能要件未達・セキュリティ脆弱性・OSS ライセンス違反などを含めるかを明示します。
• 追完義務: 修補対応の方法（修補・代替物提供・代金減額のいずれを優先するか）を定めます。

検収不合格時の実務手順については、検収を拒否する手順など別記事で深掘りされていますが、本記事では契約書本文の条文設計に絞って整理しています。

文言例: 検収・契約不適合責任条項の書き方サンプル

以下は、汎用テンプレートに追加する検収条項の文言サンプルです。あくまで参考例として、自社の案件特性に合わせて調整してください。

第○条（検収）

1. 受託者は、本契約および別紙仕様書に従って成果物を完成させ、発注者に納品する。
2. 発注者は、成果物の納品を受けた日から 14 営業日以内（以下「検収期間」という）に、別紙受入テスト計画書に基づき検収を実施し、合否を電子メールにて受託者に通知する。
3. 検収不合格の場合、受託者は発注者の指示する期限内に無償で修正のうえ再納品する。再修正の回数は 2 回を上限とし、上限を超えてもなお合格に至らないときは、発注者は契約を解除し既払金の返還を請求できる。
4. 検収期間内に発注者から書面または電子メールによる通知がない場合であっても、自動的な検収完了とはみなさない。

第○条（契約不適合責任）

1. 検収完了後、成果物に契約の内容に適合しない欠陥（仕様書記載の機能不全、性能要件未達、セキュリティ脆弱性、第三者の知的財産権侵害を含む）が発見された場合、発注者は受託者に対し、追完請求・代金減額・損害賠償または契約解除を行うことができる。
2. 前項の請求権は、発注者が当該欠陥を知った時から 1 年間、または検収完了日から 2 年間のいずれか早い時点まで行使できる。

「みなし検収」を採用するか否かは案件ごとに判断が分かれますが、発注者保護を厚くしたい場合は、上記サンプルのように「自動的な検収完了とはみなさない」と明記する方法もあります。

著作権・知的財産権のアドオン条項｜ソースコード・OSS・派生物の権利を整理する

著作権譲渡条項（著作権法 27 条・28 条を含める書き方）

ソースコードの著作権を発注者に移転するには、契約書に明示的な譲渡条項が必要です。著作権法 27 条（翻訳権・翻案権等）と 28 条（二次的著作物の利用に関する原著作者の権利）は、譲渡契約に「これらの権利を含む」と明記しなければ譲渡されないと推定される仕組みになっています（文化庁 著作権制度の概要）。

したがって、汎用ひな形によくある「成果物の著作権は発注者に帰属する」という一文では、改変や再利用に必要な権利が完全には移転していない可能性があります。エンジニア案件では、納品後にコードを改修・派生開発する前提があるため、譲渡条項に 27 条・28 条を明示的に含めるのが安全です。

加えて、受託者側で「人格権の不行使」を約束させる条項を入れることで、納品後の改変や著者名の表示変更でのトラブルを防げます。著作者人格権は譲渡できない権利のため、不行使特約という形で対応します。

OSS ライセンス遵守義務（MIT / Apache / GPL の取り扱いを契約書に書く）

エンジニア案件で組み込まれる OSS には、ライセンス条件によって扱いが大きく異なります。代表的な OSS ライセンスの分類は次のとおりです。

GPL や AGPL の OSS を組み込んだソフトウェアを自社プロダクトとして提供する場合、派生コード全体の開示義務が発生する場合があるため、自社の事業形態に重大な影響を及ぼします。契約書には「成果物に組み込む OSS の事前報告義務」「コピーレフト型 OSS の組み込みは発注者の事前承諾を要する」旨を明記することが推奨されます。

既存資産・汎用モジュールの留保と再利用権の整理

受託者側が既に保有している汎用モジュール（社内ライブラリ・過去案件で開発したフレームワーク等）を流用して納品する場合、その部分の著作権をどう扱うかも論点になります。次の 2 つの選択肢があります。

• 全部譲渡型: 既存資産を含むすべての成果物の著作権を発注者に譲渡する。受託者は他案件で同じモジュールを使えなくなるため、開発単価が上がる傾向があります。
• 部分譲渡型: 新規開発部分のみ著作権を譲渡し、既存資産は受託者に留保。発注者には「成果物の利用に必要な範囲のライセンス」を付与する形を取ります。

部分譲渡型を採用する場合は、契約書に「留保される既存資産の特定」と「発注者に付与するライセンスの範囲（永続・無償・サブライセンス可否）」を明記する必要があります。

文言例: 著作権・OSS 利用条項の書き方サンプル

第○条（著作権の帰属）

1. 受託者が本契約に基づき作成した成果物（ソースコード、ドキュメント、設計書を含む）の著作権（著作権法第 27 条および第 28 条に定める権利を含む）は、検収完了および対価の支払い完了をもって、受託者から発注者に譲渡される。
2. 受託者は、発注者および発注者が指定する第三者に対し、成果物に関する著作者人格権を行使しない。
3. ただし、受託者が本契約締結前から保有していた汎用モジュール（別紙「留保資産一覧」に記載するもの）の著作権は受託者に留保され、受託者は発注者に対し、成果物を利用するために必要な範囲で、永続的かつ無償の利用許諾を行う。

第○条（OSS の取り扱い）

1. 受託者は、成果物に OSS（オープンソースソフトウェア）を組み込む場合、当該 OSS の名称・バージョン・ライセンス種別を別紙「OSS 利用一覧」に記載し、納品時に発注者に提出する。
2. GPL、AGPL その他のコピーレフト型ライセンスに該当する OSS を組み込む場合、受託者は事前に発注者の書面による承諾を得るものとする。
3. OSS のライセンス条件違反により発注者に損害が生じた場合、受託者はその損害を賠償する責任を負う。

OSS の取り扱いは、納品後にライセンス監査ツール（FOSSology・ScanCode 等）で組み込み状況を確認する運用と組み合わせると、契約条項の実効性を高められます。

情報セキュリティのアドオン条項｜本番環境アクセス・データ取扱・端末管理を契約で縛る

アクセス権・データ取扱範囲の限定条項

業務委託エンジニアに対しては、業務遂行上必要な最小限のアクセス権のみを付与する「最小権限の原則」を契約条項に落とし込みます。具体的には次の項目を明示します。

• アクセス可能なシステム・データの範囲: 本番環境・ステージング環境・開発環境・顧客データのうち、どこまでアクセスを認めるか
• アクセス手段の限定: 専用 VPN 経由のみ・特定 IP からのみなど
• アクセス権の付与・剥奪手続き: 発注者が一元管理し、受託者からの申請に基づき個別に付与・剥奪する流れ
• 個人情報・機微情報の取扱範囲: 個人情報保護法・改正個人情報保護法に定める要配慮個人情報を取り扱う場合の追加要件（個人情報保護委員会 法令・ガイドライン）

顧客データを取り扱う案件では、契約書本文に加えて「個人情報の取扱いに関する覚書」を別紙化し、委託先監督義務（個人情報保護法 25 条）を果たせる体制を契約で担保することが推奨されます。

端末・通信・作業環境のセキュリティ要件（別紙への切り出し方）

受託エンジニアが業務に使用する端末・通信環境に対するセキュリティ要件は、契約書本文に書き切れないため、別紙「情報セキュリティ要件」として切り出すのが一般的です。別紙に記載する代表的な項目は次のとおりです。

• 端末要件: OS バージョン・ディスク暗号化（BitLocker / FileVault 等）・マルウェア対策ソフトの導入・スクリーンロック設定
• 通信要件: 公衆 Wi-Fi での業務禁止・VPN 経由でのアクセス強制・Slack / GitHub などの通信経路の限定
• 作業環境: 自宅・コワーキングスペースでの作業可否・第三者から画面が見える環境での業務制限
• ログ取得: 本番環境への操作ログ取得・保管期間・監査時の提出義務

これらの要件は IPA（情報処理推進機構）が公表している「中小企業の情報セキュリティ対策ガイドライン」などを参考にしながら、自社の情報資産レベルに応じて調整します（IPA 中小企業の情報セキュリティ対策ガイドライン）。

インシデント時の通知義務・損害賠償・関係解消条項

セキュリティインシデント（不正アクセス・情報漏洩・脆弱性混入）が発生した際の対応も、契約条項で先回りで定義します。

• 通知義務: インシデント発生または発生のおそれを認識した時から 24 時間以内（または営業日 1 日以内）に発注者に書面で通知する義務
• 協力義務: 発注者が実施する原因調査・影響範囲特定・再発防止策の策定に協力する義務
• 損害賠償: 受託者の故意・重過失によるインシデントの場合、損害賠償の上限を撤廃する条項を入れる選択肢
• 関係解消: 重大なインシデント発生時は、発注者が無催告で契約を解除できる旨

退任時の権限剥奪については、契約終了日までに発注者が付与したすべてのアクセス権・アカウントを返還・削除する義務を明記します。受託者保有の端末から成果物・機密情報を完全削除する義務もここに含めます。

文言例: 情報セキュリティ条項の書き方サンプル

第○条（情報セキュリティ）

1. 受託者は、別紙「情報セキュリティ要件」に定める要件を遵守し、業務遂行に伴い知り得た発注者の情報資産を適切に管理する。
2. 受託者には、本契約に基づく業務遂行に必要な最小限の範囲でのみ、発注者のシステムおよびデータへのアクセス権が付与される。受託者は、付与された権限を超えるアクセスを行ってはならない。
3. 受託者は、業務遂行に使用する端末について、ディスク暗号化およびマルウェア対策ソフトの導入を行い、第三者による情報の閲覧・取得を防止する措置を講じる。

第○条（情報セキュリティインシデント）

1. 受託者は、情報セキュリティインシデント（不正アクセス、情報漏洩、マルウェア感染、未対応の脆弱性混入を含む）が発生し、または発生のおそれを認識した場合、認識した時から 24 時間以内に発注者に書面または電子メールにて通知する。
2. 受託者は、発注者が実施するインシデント対応（原因調査、影響範囲特定、再発防止策策定）に協力する。
3. 受託者の故意または重過失によりインシデントが発生し、発注者が損害を被った場合、受託者は当該損害を賠償する。本条のインシデントによる損害賠償については、第○条（損害賠償の上限）の適用を受けない。

第○条（権限の剥奪・資産の返還）

1. 本契約の終了または受託者個人の業務離任時、受託者は発注者から付与されたすべてのアクセス権・アカウントを返還し、発注者の指示に従い削除手続きに協力する。
2. 受託者は、業務遂行に使用した端末・記憶媒体から、発注者の機密情報および成果物に関するデータを完全に削除し、削除完了報告書を発注者に提出する。

機密保持のアドオン条項｜契約期間中・退任後・NDA 別紙の連動設計

機密情報の定義範囲（コード・データ・社内コミュニケーションを含める書き方）

エンジニア案件における「機密情報」は、汎用ひな形が想定するよりも広い範囲に及びます。コードレビューでの社内議論・Slack や GitHub Issue 上のコミュニケーション・本番データのスナップショットなど、開発業務の副産物として接触する情報をどこまで機密として扱うかを契約で明示する必要があります。

機密情報の定義範囲を契約書に書く際は、次の要素を含めることが推奨されます。

• ソースコード本体・設計書・ドキュメント
• 顧客データ・本番データ・テストデータ（個人情報を含む）
• 社内コミュニケーション（Slack・GitHub Issue・社内会議の議事録）
• 営業情報・経営情報（事業計画・売上数値・取引先情報）
• 開示時点で発注者が機密と指定した情報（口頭開示も含むか否かを明示）

「機密として指定した情報のみ」を機密扱いする限定型と、「業務遂行上知り得たすべての情報」を機密扱いする包括型があり、エンジニア案件では包括型を採用するケースが増えています。

契約期間中・退任後の存続期間の設定

機密保持義務の存続期間は、業界相場として契約終了後 3 年〜5 年が一般的です。営業情報や顧客データを取り扱う場合は 5 年、技術情報の汎用度が高いコードベースの場合は 3 年程度で設定するケースが目立ちます。

ただし、個人情報・要配慮個人情報については、個人情報保護法の規制に従い、原則として無期限の守秘義務を課す設計が安全です。技術ノウハウについても、競合への流出を防ぎたい場合は存続期間を長めに設定する選択肢があります。

業務委託契約書本文と NDA 別紙の役割分担

機密保持条項は、業務委託契約書本文に含める方法と、NDA（秘密保持契約書）を別途締結する方法があります。それぞれの使い分けは次のとおりです。

実務的には、業務委託契約書本文に基本的な機密保持条項を入れたうえで、機密情報の詳細定義・取扱手順・存続期間を NDA 別紙として切り出す構成が扱いやすい設計です。打診段階から守秘義務を課したい場合は、業務委託契約書締結前に NDA を単独で締結する選択肢もあります。

文言例: 機密保持条項の書き方サンプル

第○条（機密保持）

1. 受託者は、本契約の遂行に伴い知り得た発注者の機密情報（ソースコード、設計書、顧客データ、テストデータ、社内コミュニケーション、営業・経営情報、ならびに発注者が機密として指定した情報のすべてを含む）を、本契約の目的以外に使用してはならず、第三者に開示してはならない。
2. 前項の義務は、本契約の終了後 5 年間存続する。ただし、個人情報および要配慮個人情報については、期限なく機密保持義務を負う。
3. 受託者は、本契約の終了または発注者の請求があった場合、機密情報を含む書面・データを速やかに返還または完全に削除し、削除完了報告書を発注者に提出する。
4. 機密情報の範囲・取扱手順の詳細は、別紙「秘密保持に関する覚書」に定めるところによる。

機密情報の範囲をめぐる紛争を防ぐには、契約締結時に「何が機密情報に該当するか」のすり合わせを別紙レベルまで踏み込んで実施することが有効です。

アドオン条項を契約書に組み込む手順｜既存テンプレートに反映するチェックリスト

既存ひな形への組み込み順序とセクション配置

4 領域のアドオン条項を既存テンプレートに反映するには、次の順序で組み込むのが実務的です。

1. 既存ひな形の章立てを把握する: 検収・著作権・機密保持・損害賠償・契約解除など、既に存在する条項の章番号を確認します。
2. アドオン条項の挿入位置を決める: 既存条項を上書きするのか、新規に追記するのかを判断します。検収条項は既存条項を強化する形、情報セキュリティは新規追記が一般的です。
3. 別紙を切り出すかを判断する: 受入テスト計画書・情報セキュリティ要件・OSS 利用一覧・秘密保持に関する覚書は、本文ではなく別紙として切り出す案件が増えています。
4. 章番号と参照を整える: アドオン条項を追記した結果、章番号がずれた場合は、本文中の参照（「第○条」「別紙○」）を一括で見直します。
5. 社内法務レビューに回す: 反映が終わったら、社内法務または顧問弁護士のレビューを受けます。

社内法務レビュー前の自己点検チェックリスト（4 領域 × 観点）

社内法務に渡す前に、発注担当者自身で次の観点を点検することで、レビュー時の差し戻しを減らせます。

検収基準

• 検収期間・通知方式・合否判定基準が明文化されているか
• 再修正回数の上限が定義されているか
• みなし検収の有無と扱いが明確か
• 契約不適合責任の期間・範囲が定義されているか

著作権・知的財産権

• 著作権譲渡条項に著作権法 27 条・28 条が明示されているか
• 著作者人格権の不行使特約が含まれているか
• OSS 利用の事前報告義務・コピーレフト型の事前承諾が明文化されているか
• 既存資産の留保範囲と発注者へのライセンス付与範囲が明確か

情報セキュリティ

• アクセス権の範囲・最小権限の原則が明文化されているか
• 端末・通信・作業環境のセキュリティ要件が別紙化されているか
• インシデント時の通知義務（時限）が定義されているか
• 退任時の権限剥奪・資産返還・削除完了報告が定義されているか

機密保持

• 機密情報の定義範囲が広く（コード・データ・社内コミュニケーション）取られているか
• 退任後の存続期間が設定されているか（3 年〜5 年が目安）
• 個人情報・要配慮個人情報については期限なしの守秘義務が課されているか
• NDA 別紙との役割分担が整理されているか

受託者から条項修正を提案された場合の判断軸

契約書ドラフトを受託者に提示した後、修正提案を受けることがあります。発注者として譲歩できる範囲・譲歩すべきでない範囲を事前に整理しておくと、交渉がスムーズです。

電子契約サービス（クラウドサイン・GMO サイン等）を使う場合は、別紙ファイルの添付方式に注意します。本文 PDF と別紙 PDF を 1 つの契約書として扱える機能があるか、それぞれの版管理がどう連動するかを事前に確認しておきます。

契約書だけでは完結しない論点｜偽装請負・損害賠償上限・自社判断が難しいケース

偽装請負との境界線（指揮命令・勤怠管理の書き方注意）

業務委託契約は、発注者が受託者に対して指揮命令を行わないことが前提です。指揮命令の実態があると、形式上は業務委託契約でも「偽装請負」と判断され、労働者派遣法違反となる可能性があります（厚生労働省 労働者派遣事業と請負により行われる事業との区分に関する基準）。

契約書で偽装請負と判定されるリスクを下げるには、次の点に注意します。

• 業務の進め方・遂行方法を受託者の裁量に委ねる旨を明記する
• 作業時間・作業場所を発注者が指定しない旨を明記する（必要な場合は理由を添える）
• 受託者の他案件並行を制限しない旨を明記する（独占受託要求は労務性を強める要因）
• 報酬を作業時間ではなく成果物・期間で算定する形にする

実態として発注者の指揮命令下で業務が進められている場合は、契約書の文言だけで偽装請負と判定されないわけではありません。実務オペレーションを契約形態に合わせて見直すことが本質的な対応になります。

損害賠償上限の妥当水準（業界相場と発注者保護のバランス）

損害賠償の上限は、業界相場として「契約金額（個別案件・年間累計いずれか）」を上限とするケースが多く見られます。受託者保護の観点から上限を設けることが一般的ですが、発注者保護とのバランスを取るために、次の例外を設けることが推奨されます。

• 故意・重過失による損害は上限を適用しない
• 第三者の知的財産権侵害による損害は上限を適用しない
• 個人情報漏洩・セキュリティインシデントによる損害は上限を適用しない、または上限を別途設定

上限の妥当水準は案件規模・受託者の支払い能力・取得している賠償責任保険の有無によって変わるため、業界相場をそのまま適用するのではなく、案件特性に応じて調整します。

自社判断が難しい場合の相談観点

4 領域のアドオン条項を反映しても、なお自社判断が難しい論点が残ることがあります。次のような場合は、社内法務・顧問弁護士・専門サービスへの相談を検討します。

• 偽装請負との境界が実態として曖昧で、契約書の文言調整だけでは対応が難しい場合
• OSS ライセンスの解釈（特にコピーレフト型の影響範囲）が事業形態に重大な影響を及ぼす場合
• 損害賠償上限の妥当水準が業界相場では判断できない大型案件の場合
• 個人情報・要配慮個人情報の取扱いを伴う案件で、委託先監督義務を果たす体制設計が必要な場合
• 海外居住エンジニアへの委託で、準拠法・裁判管轄・源泉徴収などの国際的論点が絡む場合

これらは契約書の文言だけで完結する論点ではないため、発注プロセス全体を俯瞰した点検が必要になります。

まとめ｜エンジニア委託の契約書を「自社で安心して使える状態」にするために

本記事では、汎用の業務委託契約書テンプレートに対して、エンジニア案件で特に重要となる 4 領域（検収基準・著作権・情報セキュリティ・機密保持）の追加条項について、書き方のポイントと文言例を整理しました。

汎用ひな形をそのまま使うのではなく、各領域で次の点を押さえることで、エンジニア案件特有のトラブルを契約条項で先回りできます。

• 検収基準は「契約書本文・別紙仕様書・受入テスト計画書」の 3 点セットで設計し、合否判定を客観化する
• 著作権は「ソースコード本体・OSS・既存資産・派生物」に分解し、譲渡範囲と留保範囲を明示する
• 情報セキュリティは「アクセス権限定・端末管理・退任時の権限剥奪」の 3 層で設計し、インシデント対応条項と連動させる
• 機密保持は「機密の定義範囲・存続期間・NDA 別紙との連動」を整理し、退任後の防御線を引く

契約書ドラフトが整ったあとは、社内法務レビューに回す前に、本記事の「アドオン条項を契約書に組み込む手順」のチェックリストで 4 領域の抜け漏れを確認してください。受託者から条項修正を提案された場合の判断軸も併せて参照することで、交渉時の譲歩可否を整理できます。

なお、偽装請負ライン・損害賠償上限の妥当水準・OSS ライセンスの法的解釈など、契約書の文言だけでは完結しない論点も残ります。これらは契約書単体ではなく、発注プロセス全体を俯瞰した点検で扱うのが本質的なアプローチです。

お役立ち資料のご案内

業務委託契約書の条文設計に続く次のステップとして、発注プロセス全体のリスクを点検したい場合は、「フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド」を参考資料として用意しています。

このガイドでは、契約書の条文だけでは完結しない次のような論点を、発注プロセス全体の視点から整理しています。

• フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）への対応観点
• 偽装請負・労働者性の判定実務と発注プロセス上の注意点
• 個人情報・要配慮個人情報を取り扱う案件での委託先監督義務の体制設計
• 業務委託発注における社内承認フロー・契約書管理・支払サイトの設計観点

本記事で扱った契約書条文の整備が完了した後、発注プロセスそのものをチェックリスト形式で点検したい場合の参考として、ご活用いただけます。