著作権の基礎と委託開発契約：権利帰属・利用許諾の実務ポイント

1．この記事が対象とする企業・担当者・場面

次のような場面では、知財・著作権の問題を契約締結後や紛争発生後に確認するのではなく、企画・発注・開発の段階から法務上の整理を行うことが重要です。

• 委託開発契約で、成果物の著作権を発注者へ帰属させるべきか検討している
• 著作権譲渡と利用許諾のどちらが適切か判断したい
• 受託者の既存モジュール、OSS、第三者素材を含む開発を予定している
• 開発後に別ベンダへ保守・改修を移管できる契約にしたい
• 既存契約の著作権条項が不明確で、M&A・事業譲渡や継続利用への影響を確認したい

2．委託開発で最初に押さえるべき著作権の基本

2-1．著作権は「創作した者」に原則として発生する

著作権法は、著作物を「思想又は感情を創作的に表現したもの」と定義し、著作者を「著作物を創作する者」としています。著作権と著作者人格権は、登録や申請をしなくても創作時に発生します。したがって、外部事業者へ制作を依頼した場合、契約で別途権利処理をしない限り、発注者が費用を負担したことや企画を提示したことだけを理由として、発注者に著作権が発生するわけではありません。

委託開発では、受託会社そのものが著作者になる場合もあれば、受託会社の従業員等が著作者となり、受託会社が権利を承継している場合もあります。最終的に発注者が権利を取得する設計にする場合には、受託者が発注者へ移転できるだけの権利を適切に確保しているかという「権利の連鎖」も確認する必要があります。

2-2．プログラムは著作物になり得るが、アイデアや機能そのものが著作権で独占されるわけではない

著作権法は「プログラムの著作物」を著作物の例として掲げています。一方、プログラムを作成するために用いるプログラム言語、規約や解法（アルゴリズム）には著作権による保護が及ばないとされています。システムの機能や業務上のアイデアも、それ自体が直ちに著作権で独占されるわけではありません。

実務では、ソースコードだけでなく、画面デザイン、画像、文章、マニュアル、仕様書、データベースその他の成果物について、著作物性と権利者を個別に確認します。技術的アイデアやノウハウについては、特許、営業秘密、秘密保持義務など別の保護手段を組み合わせることも重要です。

2-3．職務著作は外部委託に当然適用される制度ではない

著作権法15条は、一定の要件を満たす職務上の著作物について法人等を著作者とする職務著作制度を定めています。プログラムの著作物については、法人等の発意に基づき、その法人等の業務に従事する者が職務上作成した場合、作成時の契約・勤務規則等に別段の定めがない限り、法人等が著作者となります。

しかし、発注者と外部の受託会社・フリーランスとの関係は、通常、発注者の「業務に従事する者」が職務上作成する関係とは異なります。外注したから職務著作になり、発注者に当然帰属すると考えるのは危険です。外部委託では契約による権利処理を基本に考えるべきです。

2-4．裁判例から見る：委託開発の著作権帰属は契約と創作実態の双方で確認する

東京地方裁判所平成25年9月20日判決（平成24年（ワ）第6801号・第15155号）は、POS情報開示プログラムの開発を外部会社へ委託した事案で、基本契約に「委託業務の成果物に関する一切の権利は発注者に帰属する」との定めがあったことなどから、当該プログラムの著作権は発注者側に帰属すると判断しました。後に開発会社側から著作権譲渡を受けたと主張する者についても、開発会社が既に権利を有していなかった以上、著作権を取得しないとされています。

また、後継システムについて、仕様に関する要望を述べたり開発会社との打合せに参加したりしていたとしても、それだけで実際にプログラムを作成したとは評価できないとして、共同開発による著作権の共有も否定しました。費用負担や企画・仕様への関与と、著作権法上の創作行為は分けて考える必要があります。

この裁判例からも、委託開発では「誰が実際に創作したか」と「その権利を契約で誰に移転させるか」を二段階で確認することが重要です。発注者側で権利を確保するのであれば、成果物の範囲と権利帰属を契約書で具体的に定め、受託者側も発注者へ移転できる権利を適切に確保しておく必要があります。

3．「全部譲渡」と「利用許諾」はどちらを選ぶべきか

委託開発契約では、成果物に関する著作権を発注者へ譲渡する方式と、受託者に著作権を残して発注者へ利用を許諾する方式が代表的です。常に全部譲渡が最善というわけではありません。事業の性質、受託者の既存資産、将来の改修体制、価格、再利用の必要性などを踏まえて設計します。

自社サービスの中核となる専用開発で、別ベンダへの保守移管や将来の売却まで想定する場合は、発注者側が広い権利を確保する必要性が高くなります。他方、受託者の汎用ライブラリや開発基盤を組み込む案件では、それらまで譲渡対象とするのではなく、案件固有部分と既存資産を分け、既存資産について必要十分な利用権を確保する方が合理的なことがあります。

4．著作権譲渡条項で見落としやすい重要ポイント

4-1．27条・28条の権利を明示する

著作権は全部又は一部を譲渡できます。ただし、著作権法61条2項は、譲渡契約で著作権法27条（翻訳権、翻案権等）又は28条（二次的著作物の利用に関する原著作者の権利）の権利が譲渡の目的として特に掲げられていない場合、これらの権利は譲渡人に留保されたものと推定すると定めています。

システムやWebサービスは、納品後の改修、機能追加、UI変更、他サービスとの統合が通常想定されます。そのため、発注者へ著作権を譲渡する設計であれば、「著作権の全部を譲渡する」という記載だけで終わらせず、27条・28条の権利を含むことを明示するのが実務上重要です。

4-2．裁判例から見る：61条2項の推定が覆る場合

知的財産高等裁判所平成18年8月31日判決（平成17年（ネ）第10070号）は、ソフトウェア開発会社が作成したプログラムについて、基本契約等に「開発されたソフトウェアの著作権は発注者に帰属する」との条項があった一方、翻案権は譲渡対象として明示されていなかった事案です。裁判所は、まず著作権法61条2項により翻案権が受託者側に留保されたものと推定されるとした上で、その推定が覆るかを検討しました。

その結果、契約締結までの交渉過程で、将来の改良を発注者側が主体となって実施し、受託者はこれに協力することが当然の前提とされていたことや、契約条項も改良・翻案を発注者側が行うことを予定した内容であったことなどから、翻案権も発注者へ譲渡する合意があったと認定しました。裁判所は、単に「著作権が発注者に帰属する」という文言だけで推定を覆したのではなく、交渉経緯や契約全体から当事者の合理的意思を認定しています。

もっとも、実務上は、訴訟になってから交渉経緯や取引実態によって61条2項の推定を覆すことを期待すべきではありません。納品後の改修、機能追加、別ベンダによる追加開発等を予定するのであれば、著作権法27条・28条の権利を譲渡対象に含むことを契約書に明記するのが安全です。なお、同判決は、契約関係が解消されても、既に発注者へ移転した著作権・翻案権が当然に受託者へ戻るわけではないとも判断しており、契約終了時の権利関係もあらかじめ整理しておくことが重要です。

4-3．著作者人格権は譲渡できない

著作者人格権は著作者の一身に専属し、譲渡することができません。したがって、契約書に「著作権及び著作者人格権を譲渡する」と記載しても、著作者人格権そのものを移転させることはできません。

委託開発では、発注者や後継ベンダが成果物を改変したり、著作者名を表示せず利用したりする可能性があります。そのため、必要に応じて、受託者及び実際の創作者から著作者人格権を行使しない旨の合意を確保します。もっとも、不行使の対象や相手方を無限定に広げるのではなく、予定する利用方法に照らして条項を設計することが望まれます。

4-4．権利が移転する時点を決める

「成果物の著作権は甲に帰属する」とだけ記載すると、いつ権利が移転するのかが不明確になることがあります。納品時、検収完了時、代金完済時など、移転時期を明示しておくと紛争予防につながります。

受託者側は未払いリスクを考慮して代金完済時の移転を希望し、発注者側は納品・検収時から継続利用できる状態を求めることがあります。代金完済まで譲渡しない設計を採る場合でも、それまでの業務上必要な利用権をどうするかを併せて定めておく必要があります。

5．委託開発では「成果物を一括りにしない」ことが重要

実際の開発成果物には、案件のために新たに作ったものと、受託者や第三者が以前から保有していたものが混在します。契約上、この区別をしないまま一律に権利帰属を定めると、発注者には必要な権利が残らず、受託者には過大な譲渡義務が生じるおそれがあります。

5-1．既存資産を発注者専用成果物と区別する

受託者が複数案件で利用している汎用的なプログラムやノウハウまで発注者へ譲渡する契約は、受託者にとって受け入れにくく、価格にも影響します。他方で、既存資産をすべて受託者に留保するだけでは、発注者がサービスを継続するために必要な改修や保守移管ができなくなることがあります。

そこで、契約締結前から保有していたもの、案件固有に新規作成したもの、開発過程で汎用化されたものをできる限り区別し、既存資産については、発注者に必要な範囲の永続的・取消不能な利用権や改変権、第三者への再委託に必要な権限を確保する設計が考えられます。

5-2．OSS・第三者素材は「受託者が権利を持っていない」ことを前提に確認する

OSSや第三者のフォント、画像、SDK等は、受託者自身が著作権を保有しているとは限りません。そのため、受託者が発注者に「著作権を全部譲渡する」と約束しても、第三者の権利まで移転させることはできません。

契約では、第三者ソフトウェア等を使用できる条件、事前承諾の要否、ライセンス情報の開示、費用負担、利用条件違反が判明した場合の対応などを定めます。特にOSSは、ライセンスごとに条件が異なるため、「OSSを利用してよいか」だけではなく、採用するライセンスと組み込み方が自社の配布・提供形態に適合するかを確認する必要があります。

5-3．再委託がある場合は権利処理を一段深く確認する

受託者が開発の一部を再委託する場合、実際の創作者が再委託先にいることがあります。発注者と一次受託者との契約だけ整っていても、一次受託者が再委託先から必要な著作権を取得していなければ、発注者への譲渡や広い利用許諾ができない可能性があります。

そのため、再委託を認める場合には、一次受託者に対し、再委託先との間でも本契約と整合する知財条項を設けること、著作者人格権の不行使を確保すること、第三者権利を侵害しないことなどを義務付けることが有効です。

6．発注者側が確保しておきたい利用・改修の権限

発注者にとって、著作権の名義以上に重要なのが「サービスを継続できるか」です。契約終了後やベンダ変更時に困らないよう、少なくとも次の行為ができる状態かを確認します。

• 自社のサービス提供・社内業務のために成果物を継続利用すること
• 不具合修正、機能追加、仕様変更等のために改変すること
• 別の開発会社・保守会社へソースコード等を開示し、改修を委託すること
• グループ会社や事業承継先に必要な範囲で利用させること
• 事業譲渡、会社分割、M&A等に伴って権利又は利用上の地位を承継させること
• バックアップ、テスト、移行その他運用に必要な複製を行うこと

利用許諾方式を採る場合、これらを許諾範囲に含めるかが特に重要です。現在の担当ベンダに依存したままでも運用できるという前提で契約すると、将来ベンダを変更する局面で、技術的には可能でも法的に改修できないという問題が生じ得ます。

6-1．著作権の確保と「技術的に引き継げる状態」は別に確認する

著作権を取得し、又は十分な利用許諾を受けていても、ソースコード、リポジトリ、ビルド手順、開発環境、設計資料、各種アカウント等が受託者側にしか存在しなければ、別ベンダへの移管が実務上困難になることがあります。権利条項と納品・引継ぎ条項は別々に確認する必要があります。

特に、自社サービスの中核システムでは、ソースコードだけでなく、編集可能な元データ、リポジトリへの管理権限、依存ライブラリ一覧、ビルド・デプロイ手順、環境構築情報、必要な設計書・運用資料など、後継ベンダが合理的に保守・改修を開始するために必要な情報を納品・引継ぎ対象として定めることが重要です。パスワードや秘密情報については、安全な移管方法や管理主体も併せて設計します。

6-2．契約終了・受託者の事業継続不能時にも利用できる設計にする

利用許諾方式では、契約終了と同時に利用権まで消滅するのか、既に導入したシステムについては継続利用できるのかを明確にします。保守契約の終了と、成果物を利用する権利の終了を当然に同一扱いにしないことが重要です。

また、受託者の倒産、事業撤退、連絡不能等が生じても事業を継続できるよう、成果物・ソースコード等の引渡し、既存資産の継続利用、第三者ライセンスの承継・再取得の要否、引継ぎ協力義務などを検討します。ソースコードを常時共有しない案件では、案件の重要性に応じてエスクロー等の仕組みを検討する余地もあります。

7．契約条項で確認すべき主要項目

8．権利侵害保証は「絶対保証」にせず、実務対応まで決める

発注者としては、納品物が第三者の著作権を侵害していないことを受託者に保証してもらいたい場面が多くあります。他方、システム開発ではOSSや各種ライブラリを利用することも多く、受託者があらゆる第三者権利について無限定の結果保証をすることが現実的でない場合もあります。

重要なのは、保証文言だけではなく、侵害の主張があった場合の対応を設計することです。例えば、受託者による調査・防御への協力、利用継続のためのライセンス取得、非侵害品への差替え・修正、利用できなくなった場合の費用負担や損害賠償との関係を定めます。発注者が指定した素材や仕様に起因する場合の扱いも整理しておくと、責任分担が明確になります。

9．著作権を譲渡する場合は登録も検討する

著作権の取得そのものに登録は必要ありませんが、著作権の移転等は、登録しなければ第三者に対抗できないとされています。文化庁も、著作権譲渡の登録には、二重譲渡等が生じた場合に権利の変動を第三者へ対抗できる効果があると説明しています。

すべての開発案件で登録まで行う必要があるわけではありませんが、企業価値の中核となるコンテンツやプログラム、高額な取引、M&Aや資金調達で権利帰属の明確性が特に重要となる案件では、登録の要否を検討する余地があります。なお、プログラムの著作物については創作年月日の登録制度もありますが、これは権利を発生させるための制度ではありません。

10．既存契約の著作権条項が不明確な場合の確認手順

既に開発が終わっている案件で契約書の権利条項が曖昧な場合は、結論を推測する前に、成果物ごとに契約関係と作成経緯を整理します。契約書だけでなく、個別契約、発注書、見積書、仕様書、納品書、メール・チャット、ライセンス一覧、リポジトリ履歴等も確認対象になります。

実務上は、①何が成果物か、②誰が各成果物を作成したか、③契約上どの権利を誰に帰属させる合意があるか、④現在どの範囲で利用・改変・第三者開示しているか、⑤今後必要な利用方法は何か、の順に整理すると、不足する権利や追加合意の必要性を把握しやすくなります。

権利関係が不明なまま第三者ベンダへソースコードを渡したり、大幅な改修を開始したりすると、後から権利侵害や契約違反が争われる可能性があります。必要な場合は、現受託者との間で確認書、追加譲渡契約、追加利用許諾、引継ぎ合意等を整えた上で移行します。

11．弊所の実務上の視点：契約締結時に「将来のベンダ変更」を想定する

委託開発契約の知財条項は、開発が順調な時には問題が表面化しにくい一方、関係が悪化した時、保守費用が上がった時、別ベンダへ移管したい時、事業を売却したい時に一気に重要になります。

契約レビューでは、「成果物の著作権は発注者に帰属するか」という一問だけで判断するのではなく、契約終了翌日から別の会社が保守・改修を担当すると仮定して、その会社へ何を渡せるか、何を改変できるか、第三者ライセンスは継続するかを確認すると、実務上の不足が見えやすくなります。

また、受託者の既存技術まで一律に発注者へ譲渡させることが適切とは限りません。事業継続に必要な権限を発注者へ確保しつつ、受託者が本来保有すべき汎用技術を切り分ける方が、交渉可能性と契約の実効性を両立しやすいことがあります。重要なのは、雛形上の強さではなく、その案件の技術構成と将来利用に合った権利設計です。

12．委託開発契約を締結する前のチェックリスト

13．FAQ

14．結論：著作権の「名義」ではなく、事業を止めない権利設計をする

委託開発契約では、「著作権は発注者に帰属する」と一文入れるだけでは十分ではありません。新規成果物と既存資産・OSS・第三者素材を分け、譲渡か利用許諾かを選び、27条・28条、著作者人格権、再委託、改修、第三者ベンダへの開示、契約終了後の利用、M&A時の承継まで確認する必要があります。

さらに、法的に改修できることと、実際に改修できることは別です。ソースコード、リポジトリ、設計資料、ビルド・デプロイ情報等まで含め、将来のベンダ変更や受託者の事業継続不能時にも事業を継続できる状態を契約と運用の双方で確保することが、委託開発における知財管理の実務上の要点です。

15．弁護士への相談を検討すべき場面

標準的な制作物であっても、事業の中核となるシステムやコンテンツでは、知財条項が事業継続性に直結します。特に、独自サービスの開発、複数ベンダが関与する開発、海外事業者への委託、OSSを多く利用するシステム、将来的なM&Aや事業譲渡を想定する案件では、開発開始前に権利構造を整理することが有益です。

すでに開発が進んでいるにもかかわらず契約が未締結である場合、既存契約に著作権条項がない場合、ベンダ変更を予定しているがソースコードや権利関係が不明な場合も、紛争が顕在化する前に契約・発注書・仕様書・納品物・ライセンス一覧をまとめて確認することが重要です。

16．主要な裁判例・一次資料

• 著作権法（e-Gov法令検索）
• 文化庁「著作権契約書作成支援システム」
• 文化庁「誰でもできる著作権契約マニュアル」
• 文化庁「著作権の登録手続き」
• IPA「情報システム・モデル取引・契約書（第二版）」
• 東京地方裁判所平成25年9月20日判決（平成24年（ワ）第6801号・第15155号）
• 知的財産高等裁判所平成18年8月31日判決（平成17年（ネ）第10070号）