公開日:
｜最終更新日:
「開発を外注したいが、ひな形の契約書をそのまま使って問題ないだろうか」――ソフトウェア開発の委託では、請負と準委任のどちらを選ぶかで権利義務の内容が大きく変わります。契約類型の選択を誤ると、成果物の不具合に対する責任や知的財産権の帰属をめぐってトラブルに発展しかねません。この記事では、ソフトウェア開発契約書の作成に必要な請負・準委任の比較、必須条項の書き方、知的財産権の帰属に関する注意点を解説します。
「請負か準委任か迷っている」「ひな形の知財条項が自社の取引実態に合っているか確認したい」など、ソフトウェア開発契約書のご相談は行政書士法人Treeにお任せください。取引内容に合わせた契約書の作成・リーガルチェックに対応します。相談は何度でも無料・全国対応です。
目次
ソフトウェア開発契約の概要
請負契約と準委任契約の違い
ソフトウェア開発を外部に委託する場合、契約の法的性質は「請負」か「準委任」のいずれかに分類されます。どちらを採用するかは、開発プロセスの各フェーズや成果物の性質によって慎重に選択する必要があります。
請負契約（民法第632条）は、受注者が仕事の完成を約し、発注者がその結果に対して報酬を支払う契約です。一方、準委任契約（民法第656条・第648条の2）は、法律行為でない事務の委託であり、善管注意義務をもって事務を処理すること自体が契約の目的になります。
| 比較項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 定義（民法条文） | 仕事の完成を約束する契約（第632条） | 法律行為でない事務の委託（第656条） |
| 成果物の完成義務 | あり（完成が義務） | なし（善管注意義務で事務を処理） |
| 報酬の発生条件 | 仕事の完成に対して支払い（第632条） | 事務処理の履行に対して支払い（第648条）。成果完成型は成果の引渡しに対して支払い（第648条の2） |
| 契約不適合責任 | あり（第559条・第562条〜第564条）。発注者は修補請求・代金減額・損害賠償・契約解除が可能 | 原則なし。善管注意義務違反があれば債務不履行責任を問える |
| 中途解約 | 発注者はいつでも解除可能（第641条。損害賠償が必要） | 各当事者がいつでも解除可能（第651条。不利な時期の解除は損害賠償の可能性あり） |
| リスク所在 | 受注者側（完成できなければ報酬なし） | 発注者側（成果物が完成しなくても履行部分の報酬が発生しうる） |
多段階契約（フェーズ分割）の考え方
大規模なソフトウェア開発では、要件定義・基本設計・詳細設計・プログラミング・テスト・運用保守といった工程ごとに契約類型を使い分ける「多段階契約」が採用される場合があります。独立行政法人情報処理推進機構（IPA）が公表する「情報システム・モデル取引・契約書」（IPAウェブサイトより無料でダウンロード可能）でも、フェーズごとの契約類型の使い分けが推奨されています。
たとえば、要件定義や基本設計のように仕様が確定していない段階は準委任、プログラミングのように仕様に基づいて成果物を完成させる工程は請負、という組み合わせが一般的です。一括契約にすると、どの工程で生じた問題かが不明確になり、責任の所在が曖昧になるリスクがあります。
契約類型ごとの特徴については「契約書の種類一覧と選び方」で詳しく解説しています。また、委任と準委任の違いは「委任契約と準委任契約の違い」をご参照ください。
契約書の必須記載事項｜仕様・検収・知財・変更管理を確認
なお、発注者の資本金が1,000万円超で受注者が個人または資本金1,000万円以下であるなど一定の要件を満たす場合は、下請法（下請代金支払遅延等防止法）の適用を受けます。下請法が適用される取引では、発注書面の交付義務・支払期日の規制・減額禁止等の追加的な規制がかかるため、契約書を設計する際に合わせて確認が必要です。
ソフトウェア開発契約書には、以下の条項を漏れなく記載することが重要です。特に、開発範囲と知的財産権の帰属は、トラブルの原因になりやすい項目です。
Step 1: 開発範囲・仕様の特定
契約書本文または別紙の仕様書・要件定義書によって、開発対象となるシステムの範囲を明確に定めます。「別途協議の上決定する」という曖昧な記載では、後日の紛争原因になります。少なくとも以下を特定しましょう。
- 開発対象のシステム名称・機能一覧
- 動作環境（OS・ブラウザ・サーバ等）
- 納品物の形式（ソースコード・実行ファイル・設計書・テスト仕様書等）
- 開発スケジュールとマイルストーン
Step 2: 知的財産権の帰属
ソフトウェア開発で最もトラブルになりやすいのが、成果物に対する著作権の帰属です。著作権法上、著作権は著作物を創作した者（著作者）に原始的に帰属します（著作権法第17条第1項）。なお第2条第1項第2号は「著作者」を「著作物を創作する者」と定義しています。開発を外注した場合、受注者側が創作者又は権利者となるため、契約で明確に取り決めなければ発注者に著作権は移転しません。
著作権法第61条2項の規定により、翻案権（第27条）と二次的著作物の利用に関する原著作者の権利（第28条）は、契約書に具体的に記載しない限り譲渡人に留保されたものと推定されます。そのため、発注者に権利を帰属させる場合は「著作権法第27条及び第28条の権利を含む一切の著作権を発注者に帰属させる」と明記する必要があります。
Step 3: 検収条件と期間の設定
成果物の受入れ基準（検収条件）と検収期間を定めます。検収条件が不明確だと、納品物が契約の内容に適合しているかの判断で紛争が生じます。
- 検収期間（例: 納品後14営業日以内）
- 検収基準（仕様書に定めた機能要件を満たしていること等）
- 不合格時の対応手順（修補期間・再検収の回数上限）
- 検収期間内に通知がない場合の取扱い（みなし検収の有無）
Step 4: 再委託の可否
受注者が開発の一部または全部を第三者に再委託できるかを定めます。再委託を認める場合は、発注者の事前承認を要件とし、再委託先の行為について受注者が責任を負う旨を明記するのが一般的です。個人情報や営業秘密を扱う開発では、再委託先にも同等の秘密保持義務を課す条項が必要です。
Step 5: 秘密保持
開発過程で開示される仕様情報・業務ノウハウ・個人データ等の秘密情報について、その定義・利用目的の制限・開示範囲の制限・契約終了後の秘密保持期間・秘密情報の返還または廃棄方法を定めます。秘密保持条項を独立させず別途NDA（秘密保持契約）を締結する場合は、両契約の優先関係を明確にしておきましょう。NDAの書き方については「秘密保持契約書（NDA）の書き方」を参照してください。また、受注者に対してアクセス制限・暗号化・持出し禁止等のセキュリティ管理措置を義務付ける条項を設けることも、個人データや機密システムを扱う開発では特に重要です。
Step 6: 損害賠償の上限
ソフトウェア開発では、不具合によりシステム停止やデータ消失が発生した場合に、損害が広範囲に及ぶリスクがあります。そのため、損害賠償額の上限（例: 委託料総額を上限とする）や、間接損害・逸失利益の免責を契約書で定めておくことが実務上重要です。上限条項がなければ、受注者が想定外の高額賠償リスクを負う可能性があります。なお、損害賠償の上限を定める場合でも、故意または重過失による損害については上限の適用外とする条項が一般的であり、発注者側もこの点を確認しておくことが重要です。
開発契約書の作成・チェックをお考えの方へ
行政書士法人Treeでは、取引内容に応じた適切な契約書を作成します。
- ✔ 請負・準委任の選択から条項設計までトータルサポート
- ✔ 既存ひな形のリーガルチェックにも対応
- ✔ 相談は何度でも無料・全国対応
知的財産権の帰属で注意すべきポイント
民法・著作権法の原則
ソフトウェア開発の成果物に関する知的財産権について、法律上の原則を正しく理解しておくことが重要です。請負契約であっても、成果物の著作権が自動的に発注者に移転するわけではありません。民法には、請負の成果物の著作権帰属について直接定めた規定はなく、著作権法の一般原則に従います。
著作権法上、著作権は著作物を創作した者（著作者）に原始的に帰属します（著作権法第2条1項2号・第17条1項）。開発会社の従業員が職務上作成したプログラムは、法人著作（職務著作）として開発会社に帰属する場合があります（著作権法第15条2項）。つまり、契約で別途定めなければ、成果物の著作権は受注側の開発会社に帰属するのが原則です。
AIツールを利用したコード生成と著作権
GitHub CopilotやChatGPT等のAIツールを活用してコードを生成した場合、そのアウトプットへの著作権の発生は現時点で未確定です。文化庁の見解では、AIが自律的に生成したコードには著作権は生じないとされていますが、人間が創作的な寄与を行った部分には著作権が認められる可能性があります。契約書では「AIツールの使用有無・利用範囲」「AIが生成したコードの帰属・保証の範囲」をあらかじめ明記しておくことが今後ますます重要になります。
著作権の譲渡と第27条・第28条の特掲
発注者に著作権を帰属させるには、契約書に著作権の譲渡条項を設ける必要があります。その際、著作権法第61条2項の規定に注意が必要です。「全ての著作権を譲渡する」と記載しただけでは、翻案権（第27条）と二次的著作物の利用に関する原著作者の権利（第28条）は受注者に留保されたと推定されます。ソフトウェアの場合、翻案権が留保されると、発注者がプログラムを改変・バージョンアップする際に受注者の許諾が必要になるため、実務上の支障が生じます。
著作者人格権の不行使条項
著作者人格権（公表権・氏名表示権・同一性保持権）は一身専属の権利であり、譲渡できません（著作権法第59条）。特に同一性保持権は、著作者の意に反する改変を禁じる権利であるため、ソフトウェアの改修や機能追加を発注者が自由に行えるよう、受注者が著作者人格権を行使しない旨の特約（不行使条項）を設けるのが実務上の一般的な対応です。
契約書の基本的な書き方については「契約書の書き方完全ガイド」をご覧ください。リーガルチェックの方法は「契約書のリーガルチェック」で解説しています。
よくある質問
Q. アジャイル開発の場合、請負と準委任のどちらが適している？
アジャイル開発は、短いスプリント（反復期間）ごとに仕様の見直しと開発を繰り返す手法です。開発開始時点で最終的な仕様が確定していないため、「仕事の完成」を約束する請負契約にはなじみにくい場合があります。作業工数に応じた報酬を支払う準委任契約（履行割合型）のほうが実態に合うケースが多いとされています。ただし、スプリントごとに成果物を定義し、それぞれを請負とする契約設計も可能です。取引の実態に応じた選択が重要です。
Q. 受注者が開発に使った汎用ライブラリの著作権も発注者に移転する？
受注者が開発前から保有していた汎用プログラムやライブラリ（既存著作物）の著作権は、特段の合意がなければ受注者に留保されます。契約書で「成果物の著作権は発注者に帰属する」と定めた場合でも、既存著作物まで譲渡対象に含まれるかは解釈が分かれる可能性があります。既存著作物は受注者に帰属させたうえで、発注者に利用許諾（ライセンス）を付与する形が一般的です。
Q. 検収後に発見された不具合はどうなる？
請負契約の場合、検収完了後であっても、成果物が契約の内容に適合しないとき（契約不適合）は、発注者は受注者に対して修補請求・代金減額請求・損害賠償請求・契約解除ができます（民法第559条・第562条〜第564条）。ただし、契約不適合を知ったときから1年以内に通知する必要があります（民法第637条1項）。契約書で独自の契約不適合責任期間（例: 検収後6か月や1年）を定めることも可能で、この期間を「瑕疵担保期間」と呼ぶ慣行が残っています。
Q. 仕様変更が発生した場合の追加費用はどう定める？
開発途中での仕様変更は頻繁に発生します。契約書に仕様変更の手続き（変更管理条項）を定めておくことが重要です。具体的には、仕様変更の申入れ方法、影響範囲の調査手順、追加費用と納期延長の協議方法、書面による合意の要否を記載します。変更管理条項がないと、口頭での指示が仕様変更にあたるか否かの争いが生じる原因になります。
まとめ
- ソフトウェア開発契約では、請負と準委任の選択が最も重要な判断になる
- 著作権は契約で明示的に定めなければ受注者に帰属する（著作権法の原則）
- 著作権譲渡時は第27条・第28条の権利を明記し、著作者人格権の不行使条項を設ける
- 検収条件・仕様変更手続き・損害賠償の上限をあらかじめ取り決めておくことで紛争を予防できる
ソフトウェア開発契約書の作成はプロにお任せください
| サービス | 料金 |
|---|---|
| 契約書作成 | 19,800円（税抜）〜 |
| リーガルチェック | まずは無料相談をご利用ください |
※ ソフトウェア開発契約書は内容の規模・複雑度によって料金が異なります。個別にお見積りいたしますので、まずは無料相談をご利用ください。
- ✔ ソフトウェア開発契約・業務委託契約など各種契約書に対応
- ✔ 既存ひな形のリーガルチェックにも対応
- ✔ 相談は何度でも無料・全国対応
取引内容に応じた最適な契約書を行政書士が作成いたします。まずはお気軽にお問い合わせください。
※ 本記事の内容は2026年4月時点の民法・著作権法に基づく一般的な解説です。個別の法的助言ではありません。契約内容に関する詳細は弁護士にもご相談ください。
