フリーランスエンジニアの業務委託契約書サンプルと改定ポイント

本記事はAIによる一次チェックの観点から書いており、個別の法的助言は弁護士にご相談ください。

フリーランスエンジニアとして独立したとき、多くの人が最初に直面するのが業務委託契約書です。クライアントから提示されるドラフトには、IT業界特有の論点（ソースコードの著作権、OSSライセンス、リポジトリ利用、瑕疵担保など）が含まれているのに、汎用テンプレートをそのまま使い回したためIT特有のリスクがカバーされていないケースも少なくありません。

本記事では、フリーランスエンジニアが押さえるべき5つの重要条項と、月額固定・時給制・成果報酬型の契約形態の違い、よくあるトラブル事例をまとめます。

💡 受領した契約書のIT特有リスクをClauseLensで一次チェック → 無料レビューを試す

【ダウンロード】エンジニア向け業務委託契約書テンプレート

基本的な雛形はエンジニア業務委託契約書テンプレートからダウンロードできます。本記事の解説と合わせてご活用ください。

エンジニア契約書で特に重要な5条項

1. ソースコードの著作権帰属

もっとも揉めやすい論点です。発注者側の標準的なドラフトでは

成果物に関する著作権（著作権法27条および28条の権利を含む）は、納品と同時に甲に移転する。

という書きぶりが多く見られます。27条・28条はそれぞれ翻案権・二次的著作物の利用権を指し、これらを明示しないと譲渡対象に含まれないと解されるため、発注者側は慎重に記載する傾向にあります。

受託者（エンジニア）側としては、

汎用コード・自作ライブラリの扱いを整理
納品物を自分のポートフォリオに載せられるか
類似案件での再利用可否

を確認する必要があります。一般的な修正提案としては、

成果物の範囲を本件業務固有のコードに限定
汎用ライブラリはライセンス許諾方式（所有権は受託者、使用権を発注者に付与）
ポートフォリオ利用については事前許諾または概要レベルでの公表を認める特約

などが考えられます。著作権関連の論点はデザイナーの業務委託契約書で著作権を守る3つの条項でも掘り下げています。

2. GitHubリポジトリ利用の取り扱い

GitHub/GitLabなどのリポジトリを発注者のOrganization配下で作成するのか、受託者個人のアカウントに作成して権限を付与するのか——これは契約書に明記されていないことが多いポイントです。

トラブル例：

契約終了時にリポジトリからアクセス権を一方的に剥奪され、自分のコード履歴にアクセスできなくなる
逆に受託者がフォークしたリポジトリを自身のアカウントに残し、情報漏洩リスクが残る

対策として、

リポジトリの帰属を明記
契約終了時のアクセス権扱い（履歴のエクスポート可否等）
個人アカウント利用時のセキュリティ要件

を別紙または特記事項として整理しておくと安全です。

3. OSSライセンスとの整合性

受託者が成果物にOSSライブラリを組み込む場合、GPL・AGPL・MITなどのライセンス条項と発注者への著作権全移転が矛盾しないよう注意が必要です。

例えば、

GPL系ライセンスのコードを組み込んだまま発注者にクローズドソースで納品すると、GPLのソースコード公開義務と発注者の秘匿要件が衝突する可能性があります
MIT・Apache 2.0は比較的自由度が高いものの、著作権表示・ライセンス文の同梱義務は残ります

契約書には、

乙は、本件成果物に組み込むOSSのライセンス条件を事前に甲に通知し、甲の承諾を得るものとする。

といったOSS利用の事前通知義務が入っていることが望ましいでしょう。発注者がOSSの条件を理解せず「著作権は全部譲渡」と主張するケースもあるため、リストを別紙で整理する実務運用が広まりつつあります。

4. 不具合対応期間（契約不適合責任）

2020年4月の民法改正により、従来の「瑕疵担保責任」は「契約不適合責任」に置き換わりました。条文上、請負契約では

種類・品質に関する不適合: 受託者は追完義務・代金減額・損害賠償責任
通知期間: 不適合を知った時から1年以内の通知が原則（民法637条）

となっています。契約書で特約により通知期間や対応期間を短縮・延長できるため、以下を確認しましょう。

不具合対応の無償期間: 3ヶ月〜1年が一般的な範囲とされる
対応範囲: 「受託者の責めに帰すべき事由による不具合」に限定されているか
運用保守との区別: 改修要件は別契約か

「納品後、永久に無償対応」といった条項は、受託者にとって非常に重い負担となるため交渉の余地があります。

5. 再委託の可否

繁忙期や専門領域外のタスクが発生した際、**再委託（サブコントラクター）**が使えるかどうかは実務で重要です。

完全禁止: 受託者が必ず自ら遂行する
事前承諾制: 発注者の書面承諾があれば再委託可
原則自由: 再委託先への秘密保持義務の承継を条件に自由

フリーランスエンジニアとしては、事前承諾制を入れつつ、承諾基準を合理的な範囲に限定する交渉が現実的でしょう。

💡 再委託条項の見落としもClauseLensなら自動検出 → /review/new

時給制/月額固定/成果報酬型：契約形態の違い

| 形態 | 特徴 | 向いているケース | |------|------|----------------| | 時給制（タイム&マテリアル） | 稼働時間×単価、実費ベース | 要件が流動的、長期のチーム参画 | | 月額固定（準委任） | 一定の成果ではなく「業務遂行」にコミット | SESに近い参画、定常運用 | | 成果報酬（請負） | 成果物の完成にコミット、完成責任 | 受託開発、明確なスコープ |

準委任と請負の違い

民法上、

請負（632条）: 仕事の完成を目的とし、成果物の引渡しと代金支払が対価関係
準委任（656条・643条）: 業務の遂行そのものを目的とし、成果物の完成責任は原則なし

という区分があります。準委任型であれば、契約不適合責任は原則として負わない（ただし善管注意義務違反は別途問題になり得る）と整理されるケースが多く、フリーランスエンジニアにとってはリスク軽減につながりやすい形態です。

一方、契約書のタイトルが「業務委託契約書」でも、条文が請負の性質を帯びているケースもあるため、報酬の支払条件（成果物納品と紐付いているか）や検収条項の有無で実態を判断する必要があります。

発注者とのよくある揉めごと3選

ケース1：仕様が固まっていないのに「成果物の完成」を要求される

株式会社サンプル（架空）は、要件定義が不十分なまま「Webアプリの新規開発」を発注。受託者のエンジニアEさんは途中で仕様変更の嵐に見舞われ、検収が通らないまま追加工数が発生。

防御策: 準委任型に切り替える、または請負でも仕様確定後に見積再提示できる条項を入れる。

ケース2：納品後の不具合対応が無限に続く

納品後、発注者が半年にわたり「ここもバグだから直して」と追加対応を要求。契約書には「不具合があれば受託者の責任で対応」とだけ書かれており、期間や範囲が不明確。

防御策: 対応期間を3〜6ヶ月に限定、範囲を受託者の重大な過失による不具合に限定、期間経過後は有償保守契約に切替。

ケース3：GitHubリポジトリの扱いで揉める

契約終了時に発注者側がOrganizationから受託者のアカウントを削除。自分のコミット履歴や議論記録にアクセスできなくなった。

防御策: 契約書に履歴エクスポート権を入れるか、少なくとも契約終了の一定期間前にアーカイブの権利を確保する。

まとめ

フリーランスエンジニアの業務委託契約書で押さえるべきIT特有の論点は、

ソースコード著作権の範囲（汎用コード・ライブラリの扱い）
リポジトリ利用の明記
OSSライセンスとの整合性
契約不適合責任の期間
再委託の可否

さらに契約形態（請負・準委任）の違いを理解すれば、リスク許容度に応じた交渉が可能になります。汎用的な契約書レビュー観点については業務委託契約書のチェックポイント完全ガイドもご覧ください。

よくある質問（FAQ）

Q1. 偽装請負にならないためのチェックポイントは？

発注者からの直接指揮命令がないこと、稼働時間を受託者が裁量で決められること、労務管理を受託者自身が行うことなどが判断要素とされます。契約書の名称よりも実態が重視されるため、日々の運用が契約形態と整合しているか定期的に確認するのが安全です。

Q2. 成果物にAI生成コード（Copilot等）を含んでも問題ない？

AI生成コードの扱いは発注者の方針次第で、近年はNGとする大企業も増えています。契約書に明示がなくても、秘密保持条項との関係でプロンプト送信がNGとされる場合があります。事前にAI利用可否を確認しておきましょう。

Q3. 契約書テンプレートはどこで入手できますか？

IPA（情報処理推進機構）や経産省が公開しているモデル契約書、各種業界団体のテンプレートなどが参考になります。ClauseLensでもエンジニア向けテンプレートを公開しています。

Q4. クライアントが中小企業の場合、どこまで交渉できますか？

交渉余地は案件規模や関係性によりますが、金額よりも条項リスクのほうが交渉しやすい傾向があります。「この条項が残ったまま受注するのは難しい」と伝えると、多くの場合は協議に応じてもらえるでしょう。

Q5. 遠隔地のクライアントとの契約で気をつけることは？

管轄裁判所を自分の所在地近くの裁判所、または合意管轄（両地とも可）にしておくこと、電子署名（クラウドサインやDocuSignなど）で署名コストを減らすことが実務的です。

💡 エンジニア特有の論点（OSS・リポジトリ・契約不適合）もClauseLensなら自動チェック → 無料レビューを試す

ClauseLens編集部