著作権譲渡で失敗しない7つのポイント|契約書サンプルとシステム外注の注意点
システム開発を外注する際、成果物の著作権譲渡を適切に処理しないと将来の改修やM&Aで法的リスクを抱えます。本記事では、著作権とはどこまで譲渡できるのか、譲渡できない著作者人格権の扱いや、契約書で失敗しないための7つのポイントと具体的な条文サンプルを起業家向けに解説します。

新規事業でシステム開発を外注する際、成果物の著作権の扱いで法的トラブルを抱えていませんか。
著作権譲渡で失敗しない最大の鍵は、財産権と著作者人格権の区分や既存モジュールとの切り分けを理解し、契約書で明確に合意することです。
本記事では、著作権とはどこまで譲渡できるのか、著作権譲渡の契約書で失敗しないための7つのポイントと、そのまま使える条文のサンプルを具体的に解説します。
ポイント1:財産権と著作者人格権を切り分ける

システム開発やアプリ制作を外部に委託して新規事業を立ち上げる際、「著作権とはどこまで譲渡できるものなのか」と疑問に感じる方は少なくありません。まずは成果物に対する権利の所在を明確にすることが不可欠です。
著作権の譲渡契約を結んだとしても、すべての権利が発注者に移るわけではありません。著作権法上、権利は大きく「財産権としての著作権」と「著作者人格権」の2つに分かれます。
複製権や翻案権などの「財産権」は他者へ譲渡可能ですが、クリエイターの精神的利益を保護する「著作者人格権」は、他人に著作権を譲渡できない権利として法律で定められています。具体的には、公表権、氏名表示権、同一性保持権が含まれます。
ポイント2:著作者人格権の不行使特約を結ぶ

著作者人格権が開発側に残ったままだと、後からシステムを改修しようとした際に、開発会社から同一性保持権を主張され、無断で変更できないといったトラブルに発展するリスクがあります。
この事態を防ぐための注意点として、「著作者人格権の不行使特約」を著作権譲渡の契約書に盛り込むことが重要です。
不行使特約の条文サンプル
契約書には以下のような一文を明記します。
第〇条(著作者人格権の不行使) 乙(開発会社)は、甲(発注者)または甲の指定する第三者に対し、本件成果物に関する著作者人格権を行使しないものとする。
この一文があることで、納品後の自由な改修やアップデートが可能になります。
ポイント3:著作権法第27条・第28条を明記する

著作権の譲渡において、もっとも誤解されやすいのが譲渡される権利の範囲です。単に「成果物の著作権を譲渡する」と合意しただけでは、すべての財産権が発注者に移転するわけではありません。
日本の著作権法では、第27条(翻訳権、翻案権等)および第28条(二次的著作物の利用に関する原著作者の権利)について、契約に譲渡する旨を明確に記載しない限り、開発側(譲渡人)に留保されたものと推定されます。将来的にシステムを自社で改修したり他プラットフォームへ展開しようとした際、開発側の許可が必要になるリスクが生じます。
第27条・第28条の条文サンプル
このリスクを回避するためには、契約書に特掲事項を正しく記載する必要があります。
第〇条(著作権の譲渡) 乙(開発会社)は、本件成果物の納品および代金の完済をもって、本件成果物に関する著作権(著作権法第27条および第28条に規定する権利を含む)を甲(発注者)に譲渡する。
自社のビジネス展開においてシステムの改修や二次利用がどの程度発生するかを予測し、必要な権利が網羅されているかを確認することが重要です。
ポイント4:既存コードやOSSは利用許諾とする
システム開発において著作権譲渡の契約を結ぶ際、押さえておくべきなのが既存コードやOSS(オープンソースソフトウェア)の取り扱いです。現在の開発現場ではすべてのプログラムをゼロから記述することは少なく、開発会社が過去に作成した汎用モジュールや、第三者が権利を持つOSSが組み込まれることが一般的です。
これらの既存コードやOSSの権利まで、発注者に譲渡することは法的に不可能です。そのため、どの部分が譲渡対象となり、どの部分が対象外なのかを明確に切り分けることが重要な判断ポイントとなります。
具体的には、新規に開発された固有の機能部分のみを譲渡対象とし、汎用モジュールやOSSについては発注者に利用許諾(ライセンス)を与える形をとるのが実務上の基本事項です。すべての権利を無理に買い取ろうとすると、開発費用が高騰する原因になります。
既存モジュールの利用許諾条文サンプル
契約書には、以下のように既存モジュールの権利の所在と、発注者への利用許諾を明記します。
第〇条(従前からの著作物の取り扱い)
- 本件成果物のうち、乙(開発会社)が本契約締結前から保有していたプログラムおよびモジュール(以下「既存著作物」という)に関する著作権は、乙に留保されるものとし、甲(発注者)には譲渡されない。
- 乙は甲に対し、本件成果物を甲の事業において利用する目的の範囲内で、前項の既存著作物を無償で利用(複製、改変を含む)することを許諾する。
ポイント5:第三者の権利侵害を防ぐ非侵害保証を取る

システム開発の契約において、権利を受け取った後の現場での運用ルールと、第三者の権利侵害に関する保証は、見落とされがちな重要なポイントです。
納品物が「第三者の著作権や特許権を侵害していないこと」を開発会社に保証させる非侵害保証条項を契約書に盛り込むことが必須です。
万が一、納品されたコードに他社の権利を無断で使用した内容が含まれていた場合、運用開始後にサービスの停止や損害賠償を請求される恐れがあります。単に権利を受け取るだけでなく、実際の運用フェーズでトラブルを防ぐためのリスク管理を徹底することが、安全な著作権の譲渡を実現するための最大の要点です。
非侵害保証の条文サンプル
第〇条(第三者の権利侵害) 乙(開発会社)は、本件成果物が第三者の著作権、特許権、実用新案権、意匠権、商標権その他のいかなる権利をも侵害するものではないことを保証する。
ポイント6:納品物の範囲を明確に定義する
システム開発においては、ソースコードだけでなく、要件定義書、画面デザイン、データベースの構造など、多岐にわたる成果物が発生します。
著作権譲渡の対象となる「成果物」が何を指すのかが曖昧だと、後日別の開発会社に保守を依頼する際に「仕様書の権利が渡っていない」といったトラブルに発展する恐れがあります。
契約書を作成する際は、譲渡の対象となる成果物を別紙などで明確にリストアップし、漏れがないように定義することが不可欠です。
納品物定義のサンプル
契約書の本文または別紙において、以下のように具体的な項目を列挙して定義します。
【別紙:納品物一覧(例)】 本契約に基づき著作権譲渡の対象となる成果物は以下の通りとする。
- プログラムソースコード一式およびオブジェクトコード
- 要件定義書、基本設計書、詳細設計書、API仕様書
- データベース論理設計書および物理設計書(ER図含む)
- 画面レイアウト設計書およびUIデザインデータ(Figma等の元データを含む)
- 運用マニュアルおよびテスト仕様書・結果報告書
ポイント7:無料の契約書ひな形をそのまま利用しない

起業直後や新規事業の立ち上げフェーズでは、法務コストを抑えるために無料の契約書テンプレートを利用するケースが少なくありません。しかし、一般的な著作権譲渡契約書のひな形は、イラストや文章などの単一コンテンツを想定していることが多く、複雑なシステム開発には適していません。
ひな形をそのまま流用すると、これまでに挙げた第27条・第28条の特掲や不行使特約、既存モジュールの扱いなどが抜け落ちる危険性があります。
一般的なひな形とシステム外注向け契約書の違い
無料のひな形と、システム外注に特化した契約書では、主に以下の点で決定的な違いがあります。
- 権利の細分化 :一般的なひな形は「著作権を譲渡する」という包括的な記載にとどまりますが、システム向けは「既存モジュール」「OSS」「新規開発部分」の権利を厳密に切り分けます。
- 改修・二次利用の想定 :一般的なひな形には「著作者人格権の不行使特約」や「第27条・第28条の特掲」がないことが多く、将来のシステムアップデートや他プラットフォームへの展開時に支障をきたします。
- 納品物の定義 :システム向けはソースコードだけでなく、Figma等のデザインデータや各種設計書など、運用・保守に必要な付随物を具体的に指定します。
自社のプロジェクトに合わせたカスタマイズの重要性を認識し、必要に応じて専門家のレビューを受けることが結果的にコスト削減につながります。開発に関わる法務や契約の整備には十分な予算の確保が重要です。資金計画に不安がある場合は、新規事業の資金調達方法を徹底比較!融資を成功させる3つのポイントと審査通過のコツ や 個人事業主が資金調達を成功させる手順|新規事業の融資・補助金と審査通過3つのコツ も併せて参考にしてください。
よくある質問
システム開発における著作権とはどこまでを指しますか?
プログラムのソースコード、データベースの構造、画面のUIデザイン、要件定義書や設計書などのドキュメント類など、システム開発の過程で制作された成果物全般が著作権の対象となります。
著作者人格権はなぜ譲渡できないのですか?
著作者人格権は、クリエイター(開発者)の精神的利益を保護するための権利であり、財産のように他人に移転することが法的に認められていないためです。そのため契約書では「不行使特約」を結ぶのが一般的です。
開発会社が著作権譲渡を拒否する場合はどうすればよいですか?
自社のコアとなる独自のビジネスロジック部分のみ著作権の譲渡を求め、汎用的な機能についてはライセンス(利用許諾)での合意を目指すなど、切り分けを提案することで交渉がまとまりやすくなります。
まとめ
システム開発を外部に委託して新規事業を立ち上げる際、著作権の譲渡は単なる形式的な手続きではなく、将来のビジネス展開を左右する重要なプロセスです。本記事で解説した7つのポイントとサンプル条文を活用し、適切に対応することで、予期せぬトラブルを未然に防ぎ、安心して事業を推進できます。
特に重要なのは、以下の点です。
- 財産権と著作者人格権の切り分け :著作者人格権の不行使特約を必ず結ぶ
- 著作権法第27条・第28条の明記 :二次利用や改変の権利を確実に自社に帰属させる
- 既存コード・OSSの扱い :新規開発部分と既存モジュールを切り分け、利用許諾とする
- 非侵害保証の取得 :第三者の権利侵害を防ぐための保証条項を入れる
- 納品物の定義とひな形のリスク :安易な流用を避け、対象物を明確にリストアップする
これらの要点を押さえ、開発パートナーと密に連携しながら、法的にも盤石な事業基盤を構築してください。


ねこ太郎
独立系ベンチャーキャピタルでの投資業務を経て現在は研究機関で起業家の成功要因を分析する専門家です。キャピタリスト時代に数多くのアプリやウェブサービスの立ち上げを支援してきた豊富な経験を持っています。その現場での知見と最新の研究データを掛け合わせゼロからのビジネス立ち上げを成功に導くための実践的なノウハウを発信しています。
関連記事

著作権はどこまでセーフ?Web制作・アプリ開発で失敗しないための判断基準と侵害要件
Webサイト制作やアプリ開発で他者の画像・文章を利用する際、「著作権はどこまでセーフ?」と不安に思うことはありませんか。本記事では、著作権侵害となる要件や、フリー素材を安全に使うための判断基準を具体的に解説します。

著作権とは?新規事業で失敗しないための6つのポイント
起業家やクリエイターが必ず知っておくべき「著作権とは」何かをわかりやすく解説。著作権法の基本的な仕組みや保護期間、実際に起こりやすい著作権侵害のトラブル事例、外部委託時の権利帰属について紹介し、安全にビジネスを展開するための知識を提供します。

システム開発におけるバグの英語表現とは?海外チームと連携する3つのコツ
アプリやWebサービス開発で頻発する「バグ」とは何か。正しい意味や語源、そして「バグ」の英語表現といった基礎知識から、なぜプログラムにバグが生まれるのかという原因、リリース前の品質を守るテスト計画の重要性を解説します。

エンジニアとは?年収・種類・未経験から成功する5つのステップ
エンジニアとは、単なる開発者ではなく技術でビジネス課題を解決し、新規事業を牽引するパートナーです。自社に最適な人材を見極めるため、システムエンジニアの仕事内容や種類、年収相場を徹底解説。さらに未経験から成功する学習ステップを紹介します。

サーバーとは?仕組みと4つの種類を図解で簡単に解説
サーバーとは、ユーザーからの要求に対してデータやサービスを提供するコンピュータのことです。IT知識がない方に向けて、サーバーの基本的な仕組みや、レンタル・VPS・クラウドなど4つの種類の違い、事業規模に合わせた選び方を図解で簡単に解説します。

【初心者向け】データベースとは?簡単にわかる基礎知識と無料での作り方
データベースとは何か、簡単に基礎を知りたい初心者向けに、IT知識がなくても理解できる概念から、プログラミング不要のノーコードツールを使った無料での作り方まで解説します。ビジネスを加速させるデータ基盤の構築をサポートします。