業務委託の再委託条項を正しく設計する方法｜外部エンジニア活用のトラブル防止

外部エンジニアを業務委託で活用するとき、「再委託（丸投げ）のリスク」を意識していますか？

発注担当者の多くは、業務委託契約を締結した時点で安心してしまいます。しかし、実際に作業しているのが依頼した本人ではなく、その知人や別のフリーランスエンジニアだったとしたら——スキル偽装、品質責任の曖昧化、機密情報の流出、コードの著作権問題が一気に発生します。

再委託によるトラブルは「契約書に再委託禁止と書けば解決する」ほど単純ではありません。条項を書くだけでは機能しないケースが多く、発注者が本当に必要としているのは「条項の書き方」ではなく「条項を実効的に機能させる仕組み」です。

本記事では、業務委託の再委託条項を設計する際の3つのパターン（禁止・条件付き許可・完全許可）と、IT/エンジニア案件特有のリスクへの対処法、そして条項を実際に機能させる運用設計について、発注担当者が自社契約書を見直す際にそのまま活用できる形でまとめます。

外部エンジニアとの業務委託契約をこれから結ぶ方も、既存の契約書を見直したい方も、本記事で「再委託条項の設計と運用」についての判断基準を得ていただけます。

1. そもそも「再委託」とは何か——外注・下請けとの違い

再委託の定義

再委託とは、業務の委託を受けた受託者が、その業務の全部または一部を、さらに第三者（別の個人・法人）に委託することを指します。

たとえば、発注者であるA社がフリーランスエンジニアBさんに「システム開発の業務委託契約」を締結したとします。このとき、Bさんがその業務の一部を知人のフリーランスCさんに任せる行為が「再委託」です。

外注・下請けとの言葉の違い

「外注」「下請け」「再委託」は、文脈によって使い分けられることがありますが、実質的には「委託先がさらに別の第三者に仕事を依頼する構造」という点で同じ意味合いを持ちます。

IT/エンジニア業界では以下のような典型的な再委託が発生しやすいです。

• フリーランスエンジニアが受注した案件を、自分のコミュニティの別のフリーランスに丸投げする
• SES（システムエンジニアリングサービス）会社が契約した案件を、実質的に個人のフリーランスに再委託する
• 開発会社が受注した案件の一部を、別の開発会社または個人に外注する

再委託は原則として違法ではない

重要なのは、再委託それ自体は原則として違法ではないという点です。法律上の制限がないからこそ、発注者が契約書で明示的に制御する必要があります。「法律に違反していないから問題ない」という受託者の論理を封じるためにも、条項への明記が不可欠です。

2. 業務委託契約の形態と再委託可否——請負・準委任で規制が変わる

業務委託契約には大きく2つの形態があります。それぞれで再委託に関する法的な扱いが異なるため、理解しておきましょう。

請負契約における再委託

請負契約は、受託者が成果物を完成させることを約束する契約です（民法第632条）。

請負契約の場合、民法上は再委託を制限する規定が明示されていません。受託者は「成果物を完成させる責任」を負いますが、その過程でどのように作業するかは原則として受託者の自由です。つまり、請負では契約書に明記しない限り、再委託は自由に行えます。

ただし、成果物に不具合が生じた場合の責任は、再委託先に関わらず受託者が負います（民法第632条の請負人の責任）。

準委任契約における再委託

外部エンジニアとの業務委託で多く用いられるのが準委任契約です。システム開発の要件定義・設計・保守運用など、「成果物」ではなく「業務遂行プロセス」に対して報酬が発生する形式がこれにあたります。

準委任契約では、民法第644条の「委任者への忠実義務」の類推適用により、受任者（受託者）は原則として再委託が禁止されると解されています。これは、委任関係が受任者個人の技術・信頼に基づいて結ばれているという考え方によるものです。

つまり、外部エンジニアとの準委任ベースの業務委託では、無断で再委託を行うことは契約違反になりやすいという法的背景があります。

だからこそ「条項に明記して共通認識を作る」ことが重要

準委任では「原則禁止」が民法上の解釈として成り立ちますが、受託者にその認識がなければ無断再委託が発生するリスクがあります。また、請負契約では明示的な制限がないため、条項がなければ自由に再委託されてしまいます。

どちらの形態であっても、再委託に関する取り決めを契約書に明記することが、発注者リスク管理の第一歩です。

請負契約と準委任契約の違いをさらに詳しく把握したい方は、システム開発の請負契約と準委任契約の違いと選び方もあわせてご参照ください。

3. 再委託条項の3パターン——禁止・条件付き許可・完全許可

再委託条項の設計は、大きく3つのパターンに分類できます。自社の案件特性・リスク許容度に合わせて選択しましょう。

3-1. 禁止パターン（最もリスク回避）

条文例

受託者は、委託者の事前の書面による承諾を得た場合を除き、本業務の全部または一部を第三者に再委託してはならない。

このパターンは、原則として再委託を禁止し、例外的に書面承諾を得た場合のみ許可するという設計です。

禁止パターンが適している場面

• 機密情報・個人情報を大量に扱う案件
• 特定エンジニアのスキル・経験を前提に発注している案件
• 品質基準の高い案件（金融・医療・行政系システム）
• 小規模案件で管理コストをかけたくない場合

違反した場合の効果

再委託禁止条項に違反した場合、発注者は契約解除（民法第541条・第542条）および損害賠償請求（民法第415条）の根拠として主張できます。ただし、条文に「違反した場合の効果」を明示しておくと、より強い抑止効果が生まれます。

前項に違反して第三者に再委託した場合、委託者は何らの通知・催告なく本契約を解除することができる。

3-2. 条件付き許可パターン（実務でよく使われる）

条文例

受託者は、委託者の事前の書面による承諾を得た場合に限り、本業務の一部を第三者に再委託することができる。この場合、受託者は再委託先の名称・担当業務範囲・スキル概要を書面で委託者に届け出るものとする。

このパターンは、事前書面承諾を条件に再委託を認める設計です。大規模案件・長期案件で現実的に一人のエンジニアが全業務をこなせない場合に適しています。

承諾条件に組み込むべき要件

条件付き許可の場合、承諾申請書に以下を含めると実効性が高まります。

• 再委託先の名称・連絡先
• 再委託先が担当する業務範囲
• 再委託先のスキルシート（IT案件の場合は必須）
• 再委託先との守秘義務契約（NDA）の締結証明

再委託先への義務の連鎖

受託者は、再委託先に対し、本契約と同等の義務（秘密保持・著作権帰属・再々委託の禁止を含む）を課さなければならない。

この条文を加えることで、NDAや著作権帰属の義務が再委託先にも連鎖することを担保できます。

3-3. 完全許可パターン（大規模開発での現実解）

条文例

受託者は、本業務の一部を第三者に再委託することができる。この場合、受託者は再委託先に対し本契約と同等の義務を課し、再委託先の行為について委託者に対して直接責任を負う。

このパターンは、大規模開発プロジェクトや複数社が連携することが前提の案件に適しています。事前承諾の手続きなしに再委託を認めつつ、受託者が再委託先の行為について連帯責任・使用者責任を負う仕組みにします。

適するケース

• 複数の技術領域にまたがる大規模開発
• 初回契約時から複数社連携が前提と分かっている案件
• 継続的な大型プロジェクトで柔軟な体制変更が必要な場合

注意点

完全許可パターンでも「再委託先への義務連鎖」「受託者の直接責任」「報告義務」は必ず条項に盛り込みましょう。承諾手続きを省くだけで、実効的な制御が損なわれないよう設計することが重要です。

4. 再委託を実効的に制御する「運用設計」——条項だけでは不十分な理由

ここが、他の記事と最も差別化される核心部分です。

「書いてあっても守られているか分からない」という発注者の不安

再委託禁止条項や条件付き許可条項を契約書に盛り込んでも、発注者の多くは「本当に守られているか分からない」という不安を抱えています。この不安は当然です。

業務委託では、受託者の作業現場を発注者が直接監視することはできません（それを過度に行うと偽装請負のリスクが生じます）。したがって、条項の存在を「気づかせる仕組み」と「違反を検知できる仕組み」を運用として設計することが必要です。

実効性を担保する5つの仕組み

1. 業務日報・週次報告の義務化

実作業者の名前・担当内容・進捗を記載した報告書の提出を契約上の義務とします。報告書の内容が契約したエンジニアの業務範囲と一致しているかを確認することで、無断再委託の早期発見につながります。

2. 再委託先承認フローの書面化

条件付き許可パターンを採用する場合、「承認申請書のフォーマット」「誰が承認するか」「承認期間の上限」を運用規程として定義します。口頭での確認やメールのみでは記録が散逸するため、書面または電子承認フローで管理します。

3. 成果物の著作権帰属条項とセット

再委託が行われた場合でも、再委託先が作成したコード・設計書・ドキュメントの著作権が委託者に帰属することを明記します。

受託者が再委託先に作成させた成果物に係る著作権は、受託者から委託者に譲渡される。受託者はこれを確保するために必要な措置を講じなければならない。

4. 違反時の損害賠償・即時解除条項

再委託条項の違反を「重大な契約違反」として、損害賠償と即時解除の根拠を明示します。単なる注意事項ではなく、実効的な抑止力としての条文設計が重要です。

5. 検収フロー

成果物の検収時に「作業した人物が契約したエンジニアと同一の技術水準か」をチェックするポイントを設けます。スキル水準の著しい乖離は無断再委託のサインになり得るため、検収段階でのスクリーニングが有効です。

5. IT/エンジニア案件特有の注意点

一般的な業務委託の再委託リスクに加えて、IT/エンジニア案件特有のリスクを把握しておきましょう。

スキル偽装リスク

外部エンジニア案件で最も多い再委託トラブルのひとつが「スキル偽装」です。

発注時に「〇〇言語10年経験・アーキテクチャ設計経験あり」として紹介されたエンジニアが、実際には受注した後に業務の大半を経験の浅い別のエンジニアに任せているケースがあります。

対処法: 条件付き許可パターンで「再委託先のスキルシート提出」を承諾申請の必須要件とする。また、月次の業務報告に「担当者名と担当範囲」を明記させることで、実作業者のモニタリングを行います。

知的財産権の散逸リスク

再委託先が作成したソースコードの著作権は、原則として作成者（再委託先）に帰属します。受託者が委託者への著作権譲渡を約束していても、再委託先との著作権譲渡契約が結ばれていなければ、発注者は再委託先が作成した部分のコードを自由に利用できない状況が生じます。

対処法: 前述の「成果物の著作権帰属条項」をセットで設計し、「受託者が再委託先から著作権を取得して委託者に譲渡する義務」を明記します。

NDA の連鎖リスク

発注者とエンジニアの間でNDAを締結していても、そのエンジニアが無断再委託をした場合、NDAの範囲外の第三者に自社の機密情報が渡ります。

対処法: 「再委託先に対し、本契約と同等の守秘義務を課す義務」を条項に明記します。再委託先との守秘義務契約の締結証明を承諾申請書に添付させることが有効です。

NDA条項の設計について詳しくは、NDAとは｜システム開発の雛形を発注者目線でレビューするチェックリストをご覧ください。

SES（準委任型）との違い

SES（システムエンジニアリングサービス）の場合、発注者・SES会社・エンジニア個人の三者間契約構造が最初から明示されています。しかし、個人のフリーランスエンジニアと準委任型の業務委託を締結する場合は、この構造が不透明になりがちです。

「個人として契約しているのに実作業は別の人」というケースが発生しやすいのは、個人フリーランスとの準委任契約であることを認識しておきましょう。

6. 条文例と自社契約書へのチェックリスト

標準的な再委託条項の条文例（禁止寄りのバランス設計）

以下の条文は、実務でよく使われる「原則禁止・例外的書面承諾で許可・再委託先への義務連鎖・受託者の直接責任」を組み合わせた標準的な設計例です。

（再委託の禁止）
第〇条　受託者は、委託者の事前の書面による承諾を得た場合を除き、本業務の全部または一部を第三者に再委託してはならない。
２　受託者は、再委託を行う場合、再委託先に対し、本契約と同等の義務（秘密保持・著作権帰属・再々委託の禁止を含む）を課さなければならない。
３　再委託先の行為について受託者は委託者に対して直接責任を負う。
４　受託者が第１項に違反した場合、委託者は何らの通知・催告なく本契約を解除し、受託者に対し損害賠償を請求することができる。

発注者向け自社契約書チェックリスト（5項目）

現在の契約書を以下の観点で確認してください。

• 再委託の可否（禁止か許可か）が明記されているか
• 再委託する場合の事前承諾要件（書面・申請フォーマット）が書かれているか
• 再委託先にも NDA・守秘義務を課す義務が明記されているか
• 再委託先の成果物の著作権帰属が明記されているか
• 再委託条項違反時の損害賠償・契約解除条項があるか

5項目のうち1つでも欠けている場合、次回の契約更新または新規契約締結時に条文の追加・修正を検討しましょう。

システム開発の契約書全般のチェックポイントについては、システム開発の契約書｜発注者が確認すべき7条項と交渉アクションも参考にしてください。

まとめ——再委託条項は「書く」ではなく「機能させる」

本記事で解説した内容を整理します。

再委託条項の3パターン

実効性を担保する5つの運用要素

1. 業務日報・週次報告の義務化（実作業者の確認）
2. 再委託先承認フローの書面化
3. 成果物の著作権帰属条項とセット設計
4. 違反時の損害賠償・即時解除条項
5. 検収フローでのスクリーニング

IT/エンジニア案件特有の3大リスク

• スキル偽装リスク（スキルシートと実作業者の乖離）
• 知的財産権の散逸リスク（再委託先作成コードの著作権）
• NDAの連鎖リスク（機密情報の第三者流出）

再委託条項は「書く」だけでは機能しません。報告義務・承認フロー・著作権帰属のセット設計で初めて実効性を持ちます。

外部エンジニアの業務委託契約の設計・見直しにお悩みの方は、Workee の活用サポートについてお気軽にご相談ください。業務委託契約の契約管理から外部エンジニアの評価・マッチングまで、発注者の課題解決を支援しています。