成果物を発注者に帰属させながら、受注者の既存資産、汎用成果、保守・研究開発利用を守るための契約設計を整理します。
成果物を発注者に帰属させながら、受注者の既存資産、汎用成果、保守・研究開発利用を守るための契約設計を整理します。
発注側帰属でも受注側にライセンスを残す設計の全体像について、制度・リスク・実務対応を分けて確認します。
次の重要ポイント一覧は、受注側ライセンス設計で最初に分けるべき論点を示しています。権利の帰属だけで結論を出さず、利用できる範囲、秘密情報の除外、対価、AI・データ利用を切り分けて読み取ることが重要です。
発注者が権利者になっても、受注者に一定範囲の非独占的利用権を残せます。
発注者固有情報、未公開仕様、個人情報、営業秘密はライセンス対象から明確に外します。
譲渡・許諾の範囲と対価を、契約書、発注書、見積書、議事録に残します。
推論、保守、品質改善、モデル学習、第三者送信を分けて定めます。
この記事は、企業間の業務委託、システム開発、デザイン制作、研究開発、AI・データ利活用、製造委託、コンサルティング等で問題となる「発注側帰属でも受注側にライセンスを残す設計」について、企業法務・知財法務の観点から体系的に整理する専門的な解説です。個別案件の法的助言ではありません。実際の契約交渉、紛争対応、M&A、監査、税務・会計処理、個人情報・営業秘密・輸出管理・業法対応を伴う場合は、案件の事実関係に応じて、弁護士、弁理士、税理士、公認会計士、企業内法務、知財担当、プライバシー担当、情報セキュリティ担当等の関与を得るべきです。
この記事が扱う中心論点は、単に「成果物の著作権は発注者に帰属する」と書くことではありません。むしろ、発注者に権利を帰属させる商業的合理性を認めつつ、受注者が自社の既存部品、テンプレート、開発基盤、ノウハウ、汎用的知見、保守・再利用能力を失わないように、契約上どのような利用権を残すかという設計問題です。したがって、この記事のキーワードは一貫して「発注側帰属でも受注側にライセンスを残す設計」です。
「発注側帰属でも受注側にライセンスを残す設計」の核心は、権利の帰属と利用権の設定を分けて考える点にある。発注者が成果物の権利者になることと、受注者が一定範囲でその成果物または成果物に含まれる技術・素材・ノウハウを利用できることは、法的にも実務的にも両立し得ます。
もっとも、両立させるには、曖昧な「再利用可」「ノウハウは自由」「発注者に帰属」だけでは足りない。少なくとも、対象物、利用行為、利用目的、利用範囲、第三者提供、秘密情報、個人情報、派生成果、改良技術、対価、契約終了後の効力、M&A時の承継、侵害保証、オープンソース、AI学習利用の可否を明確化する必要があります。
特に日本法では、著作権法上、著作権は全部または一部を譲渡できる一方、著作者人格権は一身専属で譲渡できません。著作権の利用許諾は、許諾された方法・条件の範囲内で利用できる制度であり、利用権の対抗力に関する規定も存在します。特許法上も、専用実施権と通常実施権の設計、通常実施権の移転・対抗力が問題になります。さらに、2026年1月に施行された取適法、知的財産取引に関する中小企業庁ガイドライン、公正取引委員会の知的財産利用に関する独占禁止法上の指針を踏まえると、受注側に発生した知的財産の譲渡・許諾範囲と対価を明確にすることは、単なる契約テクニックではなく、取引適正化の中核です。
結論を先取りすれば、発注者が事業上必要な独占的支配を確保したい場合でも、受注者に対して、発注者の秘密情報・個人情報・固有仕様を除外したうえで、非独占的、全世界、無期限、撤回不能、ロイヤルティ込み、再許諾制限付きのライセンスを残す設計は、多くの取引で合理的です。ただし、競争上センシティブな案件、同業他社向け展開、共同開発、AI学習、医療・金融・防衛・輸出管理等が絡む案件では、より細分化した制限が必要になります。
発注側帰属でも受注側にライセンスを残す設計が必要な理由について、制度・リスク・実務対応を分けて確認します。
企業間取引では、発注者が次のような条項を提示することが多い。
この文言は一見すると簡潔で、発注者にとって安全に見える。しかし、実務上は多くの問題を生む。
第一に、「成果物」の範囲が不明確です。ソースコード、画面デザイン、設計書、提案書、仕様書、データベース構造、モデル、重み、プロンプト、テストデータ、テンプレート、ライブラリ、API連携部品、教育資料、調査報告書、図面、金型データ、CADデータ、分析ロジック、作業過程のメモまで含むのかが不明になります。
第二に、「一切の知的財産権」が広すぎます。著作権、特許を受ける権利、特許権、実用新案権、意匠権、商標権、ノウハウ、営業秘密、限定提供データ、データベース、半導体回路配置、ドメイン名、SNSアカウント、学習済みモデルの利用条件まで含めているつもりなのか、単なる著作権譲渡なのかが曖昧になります。
第三に、受注者の既存資産まで発注者に移るように読める場合があります。システム会社が長年蓄積してきた共通フレームワーク、デザイン会社の汎用テンプレート、コンサルティング会社の分析手法、AIベンダーの基盤モデル連携ノウハウ、製造会社の加工ノウハウまで「成果物に関する」として奪われるなら、受注者は以後の事業を継続しにくくなります。
第四に、発注者側にも不利益があります。過度に広い帰属条項は、受注者に価格上乗せを促し、交渉を長期化させ、優秀な受注者の参加を妨げます。さらに、受注者が既存部品を使えなくなると、開発効率が低下し、保守性も下がる。発注者が本当に必要としているのは、多くの場合「自社事業のために成果物を安全に利用・改変・第三者委託・承継できること」であって、受注者の汎用的な技術資産を丸ごと独占することではありません。
したがって、「発注側帰属でも受注側にライセンスを残す設計」は、発注者と受注者の利害を調整するための中間解です。発注者は自社事業に必要な権利支配を確保し、受注者は汎用技術・ノウハウ・再利用可能部品を失わない。この設計は、法務だけでなく、価格、納期、品質、保守、イノベーション、M&A、ガバナンスに影響する。
発注側帰属でも受注側にライセンスを残す設計の基本概念について、制度・リスク・実務対応を分けて確認します。
「帰属」とは、ある権利が誰に属するかという状態をいう。契約実務では「成果物の知的財産権は発注者に帰属する」という形で使われる。ただし、帰属という言葉だけでは、いつ移転するのか、どの権利が移転するのか、対価は含まれるのか、既存資産は除外されるのか、受注者の利用権は残るのかが明らかになりません。
「譲渡」とは、権利を移転する行為です。著作権法は、著作権について全部または一部の譲渡を認めている。また、翻案権や二次的著作物の利用に関する権利については、譲渡契約で特掲されていない場合、譲渡人に留保されたものと推定される。これは、成果物の著作権を発注者に移す契約で非常に重要です。単に「著作権を譲渡する」と書くだけでは、翻案・改変・二次利用の権利関係について意図しない余地が残るためです。
「許諾」または「ライセンス」とは、権利者が他人に一定の利用を認めることです。著作権法では、著作権者は他人に著作物の利用を許諾でき、許諾を受けた者は、許諾に係る利用方法および条件の範囲内で利用できます。特許法でも、特許権者は通常実施権を許諾できます。
ここで重要なのは、権利者でなくても、ライセンスがあれば利用できますという点です。発注者に著作権を帰属させた後でも、発注者が受注者に一定の利用を許諾すれば、受注者はその範囲で利用できます。これが、発注側帰属でも受注側にライセンスを残す設計の基礎です。
「留保」とは、権利移転の対象から一部を除外して、もとの権利者側に残すことです。たとえば、成果物のうち受注者の既存ライブラリは発注者に譲渡せず、発注者にはその利用権だけを与えるという構成がある。この場合、発注者に「成果物全部の権利が帰属する」のではなく、受注者既存資産は受注者に残る。
「ライセンスバック」とは、権利を譲渡した側が、譲受人から利用許諾を受ける構成です。たとえば、受注者が成果物の著作権を発注者に譲渡し、発注者が受注者に対して、秘密情報を除く範囲で保守、改良、研究開発、汎用部品化、他案件への再利用を認める。これが典型的な「発注側帰属でも受注側にライセンスを残す設計」です。
「レジデュアル・ナレッジ」とは、業務を通じて受注者の担当者の頭の中に残る一般的な知識、経験、技能、アイデア、ノウハウを指す実務上の概念です。ただし、これを無制限に認めると、発注者の秘密情報や個人情報の流用を正当化する危険がある。そのため、契約では、レジデュアル・ナレッジを認める場合でも、秘密情報、個人情報、発注者固有の仕様、未公開事業計画、顧客情報、ソースコード、データセット等の具体的情報の使用・開示は禁止するのが通常です。
発注側帰属でも受注側にライセンスを残す設計の法的基礎について、制度・リスク・実務対応を分けて確認します。
ソフトウェア、UI、デザイン、文章、写真、動画、提案書、設計書、マニュアル、研修資料、レポート等の多くは、著作権法上の著作物になり得る。発注側帰属でも受注側にライセンスを残す設計では、著作権法上、少なくとも次の点を押さえる必要があります。
1つ目は、著作権は全部または一部を譲渡できることです。したがって、発注者に成果物の著作権を移すこと自体は可能です。
2つ目は、翻案権および二次的著作物の利用に関する権利について、譲渡契約で特掲されていない場合には譲渡人に留保されたものと推定されることです。発注者が成果物を改変・翻案・派生利用したい場合、または受注者がライセンスバックにより改変・派生利用したい場合、条項上これらを明示する必要があります。
3つ目は、著作者人格権は譲渡できないことです。したがって、発注者に著作権が帰属しても、著作者人格権は当然には発注者へ移らない。実務では、著作者人格権を「譲渡する」と書くのではなく、著作者人格権の不行使、氏名表示、改変、公開時期等を契約で調整する。
4つ目は、著作権者による利用許諾の範囲を明確にする必要があることです。受注者に残すライセンスは、目的、方法、媒体、地域、期間、第三者提供、再許諾、改変、複製、公衆送信、翻案、二次利用の範囲を明示しなければなりません。
5つ目は、利用権の対抗力です。著作権法は、利用権について、当該著作物の著作権を取得した者その他の第三者に対抗できる旨を定めています。もっとも、対抗力があるからといって、契約書が不要になるわけではありません。実務では、どの利用権がいつ、誰に、どの範囲で付与されたかを証明できるようにしておく必要があります。
研究開発、製造、AIアルゴリズム、ハードウェア、材料、医療・ヘルスケア、センサー、通信、ロボティクス等では、特許法上の発明や実施権が問題になります。特許法上、専用実施権は設定行為で定めた範囲で業として特許発明を実施する権利を専有します。一方、通常実施権は、法律の規定または設定行為で定めた範囲で業として特許発明を実施する権利です。
発注側帰属でも受注側にライセンスを残す設計では、発注者が成果発明に係る特許を受ける権利または特許権を取得し、受注者に通常実施権を付与する構成があり得ます。受注者に残す権利が独占的である必要は、多くの場合ありません。むしろ、発注者の事業化自由度を確保しつつ、受注者が自社の技術基盤や他案件での利用を継続できるよう、非独占的通常実施権を設定する方が調整しやすくなります。
ただし、通常実施権の移転や質権設定には制限がある。受注者が事業譲渡、会社分割、M&A、グループ再編を予定している場合、ライセンスの承継可能性を契約で設計しておく必要があります。特許法上、通常実施権は、その発生後に特許権等を取得した者に対しても効力を有するが、これも対象特許、発生時期、許諾範囲の証跡がなければ紛争化しやすい。
ノウハウやデータは、著作権や特許権のような排他的権利として単純に「帰属」させにくい。営業秘密や限定提供データとして不正競争防止法上保護される場合もあるが、すべての情報が当然に保護されるわけではありません。経済産業省は営業秘密管理指針、秘密情報の保護ハンドブック、限定提供データに関する指針等を公表しており、情報管理の実務において参照される。
したがって、データ・ノウハウについては、「誰の所有物か」だけでなく、次を契約で定めるべきです。
発注側帰属でも受注側にライセンスを残す設計では、ノウハウについて「秘密情報を除く汎用的知識・経験は受注者が利用できます」と書くだけでは足りない。何を除外するのか、どのように匿名化・集計化するのか、発注者に競争上不利益を与える利用を禁止するのかを定める必要があります。
2026年1月1日から、旧下請法は改正により取適法として施行され、用語も「親事業者」「下請事業者」から「委託事業者」「中小受託事業者」へ見直されている。公正取引委員会は、取適法のFAQで、情報成果物作成委託において中小受託事業者に知的財産権が発生し、それを委託事業者に譲渡・許諾させる場合、譲渡・許諾の範囲を給付の内容の一部として明示し、その対価を代金に加える必要がある旨を示しています。
また、中小企業庁の「知的財産取引に関するガイドライン」は、相手方に帰属する知的財産権について無償譲渡や自社単独帰属を強要しないこと、従来から保有する知的財産権や相手方秘密情報に依拠せず独自に開発した知的財産権はその当事者に帰属すること、開発委託の目的とする成果は報酬・費用等の支払により発注者へ移転すること等を整理している。
この観点からも、発注側帰属でも受注側にライセンスを残す設計では、次が重要になります。
公正取引委員会の「知的財産の利用に関する独占禁止法上の指針」は、ライセンシーが開発した改良技術について、ライセンサーに権利を帰属させる義務や独占的ライセンス義務を課す行為は、ライセンシーの研究開発意欲を損なうなどとして、原則として不公正な取引方法に該当する考え方を示しています。一方、ライセンシーが自ら開発した改良技術を自由に利用できる場合に、ライセンサーへ非独占的にライセンスする義務は、原則として不公正な取引方法に該当しないと整理されています。
これは、発注側帰属でも受注側にライセンスを残す設計と親和的です。発注者が成果を全て独占し、受注者の改良技術まで吸い上げる条項は、技術取引を硬直化させる。一方、発注者に必要な利用権を確保しつつ、受注者にも非独占的な利用余地を残す設計は、研究開発意欲と取引合理性を両立しやすい。
発注側帰属でも受注側にライセンスを残す設計の4層構造について、制度・リスク・実務対応を分けて確認します。
次の4項目の一覧は、契約で分けるべき対象を上から順に整理したものです。どの層を移転し、どの層を受注者に残し、どの層を再利用禁止にするかを読むことで、過剰な権利取得と秘密情報流用の両方を避けやすくなります。
秘密情報、個人情報、顧客情報、未公開仕様、事業計画など、受注者の再利用対象から除外する情報です。
既存ライブラリ、テンプレート、ツール、ノウハウ、開発環境など、受注者に残す資産です。
発注者のために作成された納品物で、発注者帰属を基本にしつつ受注者利用を調整します。
成果物から抽象化された部品や改良技術で、秘密情報を除外して利用範囲を設計します。
発注側帰属でも受注側にライセンスを残す設計は、次の四層で構成すると分かりやすい。
次の比較表は、4. 契約設計の基本構造で扱う項目を「層、内容、契約上の役割」の列に分けて整理したものです。申請後・契約後の判断は一つの観点だけでは足りないため、列ごとの違いを確認し、どの項目に追加確認や社内記録が必要かを読み取ってください。
| 層 | 内容 | 契約上の役割 |
|---|---|---|
| 第1層 | 発注者固有情報 | 秘密情報、個人情報、顧客情報、未公開仕様、事業計画。受注者の再利用対象から除外する。 |
| 第2層 | 受注者既存資産 | 既存ライブラリ、テンプレート、ツール、ノウハウ、開発環境。受注者に帰属させ、発注者へ必要な利用権を付与する。 |
| 第3層 | 本件成果物 | 発注者のために作成された納品物。発注者帰属を基本としつつ、受注者へ限定的ライセンスを残す。 |
| 第4層 | 派生・改良・汎用化成果 | 成果物から抽象化された部品、改良技術、学習、ベンチマーク、集計知見。秘密情報を除外し、利用範囲を設計する。 |
この四層を分けないまま「全部発注者帰属」とすると、受注者の既存資産まで発注者に移転するかのように読める。逆に「受注者は自由に再利用できます」とだけ書くと、発注者固有情報の漏えいリスクが残る。したがって、発注側帰属でも受注側にライセンスを残す設計では、移転するもの、移転しないもの、利用だけ認めるもの、絶対に使ってはいけないものを分ける必要があります。
発注側帰属でも受注側に残すライセンスの設計軸について、制度・リスク・実務対応を分けて確認します。
まず、何に対してライセンスを残すのかを明確にする。対象物は大きく分けて次の通りです。
対象物を「本件成果物」とだけ書くと、狭すぎる場合も広すぎる場合もあります。たとえば、ソフトウェア開発で受注者が再利用したいのは、納品された業務アプリ全体ではなく、入力チェック、ログ管理、認証連携、帳票出力、デプロイ自動化、テスト自動化などの汎用部品であることが多いです。
著作権であれば、複製、翻案、改変、公衆送信、頒布、貸与、展示、二次的著作物の利用などが問題になります。特許であれば、製造、使用、譲渡、輸出入、方法の使用などが問題になります。データであれば、閲覧、複製、解析、加工、統計化、学習、提供、削除、保存が問題になります。
受注者に残すライセンスは、利用行為を明示しなければなりません。たとえば「受注者は本件成果物を再利用できます」とだけ書くより、次のように書く方が安全です。
利用目的を限定することで、発注者の不安を抑えられる。典型的な目的は次の通りです。
ただし、同業他社向け転用、競合製品への組込み、公開リポジトリへの掲載、学習データ化、広告利用は、発注者側が特に警戒するため、明示的な許可制または禁止制にすることが多い。
受注者が事業を継続するためには、利用地域は全世界、期間は無期限または権利存続期間中とするのが合理的な場合が多い。ただし、秘密情報の保護期間、個人情報の保存期間、競業避止的な制限、発注者の事業化前の公開禁止期間は別に設計する。
「無期限」と「永久」は同じように使われがちだが、契約解除、重大違反、秘密保持違反、支払不履行、法令違反の場合の停止・終了をどう扱うかは別途定めるべきです。
受注者に残すライセンスは、通常は非独占で足りる。発注者は成果物を自由に使い、第三者に委託し、M&Aや事業譲渡で承継できます。受注者は秘密情報を除く汎用部分を利用できます。これが最もバランスがよい。
独占的ライセンスを受注者に残す場合、発注者の利用や第三者許諾が制限されるため、発注側帰属の意味が薄れる。逆に、発注者が受注者の改良技術を独占的に取得する場合、独占禁止法上・取引適正上の問題も検討する必要があります。
「ロイヤルティフリー」とは、利用ごとに追加使用料を払わないという意味で使われることが多いです。ただし、無償という意味にしてしまうと、知財譲渡・許諾対価が不明確になる場合があります。実務上は、「本契約の委託料には、当該譲渡および許諾の対価を含む」と明記するのが望ましいです。特に中小受託事業者との取引では、譲渡・許諾範囲と対価の明示が重要です。
受注者が協力会社、クラウドベンダー、検証環境、子会社、外部専門家を使う場合、再許諾や第三者利用の可否を定める必要があります。発注者側は、秘密情報や個人情報の漏えいを懸念します。受注者側は、実務上、外部の開発者やクラウド環境を使えないと保守が困難になります。
妥当な設計としては、次のように段階化する。
次の比較表は、5. 受注側に残すライセンスの設計軸で扱う項目を「利用先、原則、条件」の列に分けて整理したものです。申請後・契約後の判断は一つの観点だけでは足りないため、列ごとの違いを確認し、どの項目に追加確認や社内記録が必要かを読み取ってください。
| 利用先 | 原則 | 条件 |
|---|---|---|
| 受注者内部 | 許可 | アクセス権限管理、秘密保持義務 |
| 受注者グループ会社 | 条件付き許可 | 同等の秘密保持義務、発注者固有情報の除外 |
| 再委託先 | 条件付き許可 | 事前承認または契約上の包括承認、監督義務 |
| 他顧客 | 汎用部分のみ許可 | 発注者秘密情報・固有仕様・個人情報を除外 |
| 公開リポジトリ | 原則禁止 | 発注者の書面承認がある場合のみ |
| AI学習基盤 | 原則個別合意 | 入力データ、生成物、学習利用、再識別リスクを明示 |
発注側帰属でも受注側にライセンスを残す類型別設計について、制度・リスク・実務対応を分けて確認します。
ソフトウェア開発では、発注者が業務アプリケーションの著作権を取得したい一方、受注者は共通部品を再利用したいという衝突が起きやすい。
望ましい設計は、次のような三分法です。
ソフトウェアでは、オープンソースソフトウェアの利用条件も重要です。発注者帰属と書いても、第三者ライセンスに基づく利用条件を消すことはできない。OSSの表示義務、ソース開示義務、商用利用条件、再配布条件、脆弱性対応、SBOM、第三者コンポーネント一覧の提出を契約で管理する必要があります。
デザイン制作では、発注者がロゴ、キービジュアル、広告コピー、写真、動画、LP、パンフレット等を自社ブランドのために独占的に使いたい一方、受注者は制作実績として掲載したい、または汎用的なレイアウト・手法を他案件で使いたいという問題がある。
設計のポイントは次です。
「発注側帰属でも受注側にライセンスを残す設計」を採る場合、受注者の実績公開ライセンスは、発注者のリリース後、秘密情報を含まず、発注者のブランドガイドラインに反しない範囲で認めるのが典型です。
研究開発・製造委託では、発明、試作品、図面、CADデータ、金型、製造条件、検査条件、材料配合、ノウハウ、改良技術が問題になります。発注者が成果発明を取得する場合でも、受注者の既存技術、製造ノウハウ、改善提案、横展開可能な加工技術を過度に縛ると、受注者の研究開発意欲を損ないます。
設計のポイントは次です。
AI・データ案件では、成果物の権利帰属よりも、入力データ、プロンプト、生成物、モデル、重み、ログ、評価データ、派生データ、学習利用、再学習、ファインチューニング、RAG用データベース、ベクトル化データの扱いが重要になります。
経済産業省は、AI・データの利用に関する契約ガイドラインにおいて、データの利用等に関する契約およびAI技術を利用するソフトウェアの開発・利用契約について、主な課題、論点、契約条項例、条項作成時の考慮要素を整理している。また、2025年にはAIの利用・開発に関する契約チェックリストを公表し、提供データの利用範囲、AI生成物の利用条件、リスク配分等の検討を促している。
AI・データ案件での発注側帰属でも受注側にライセンスを残す設計は、次のように分けるべきです。
次の比較表は、6. 類型別の実務設計で扱う項目を「対象、原則設計、注意点」の列に分けて整理したものです。申請後・契約後の判断は一つの観点だけでは足りないため、列ごとの違いを確認し、どの項目に追加確認や社内記録が必要かを読み取ってください。
| 対象 | 原則設計 | 注意点 |
|---|---|---|
| 発注者入力データ | 発注者管理、受注者は業務目的で利用 | 個人情報、営業秘密、目的外利用禁止 |
| プロンプト | 案件固有部分は発注者、汎用テンプレートは受注者 | 秘密情報を含むプロンプトは再利用不可 |
| 生成物 | 契約で利用権・責任を明示 | 著作物性・第三者権利侵害リスクに注意 |
| モデル・重み | 既存モデルは提供者、カスタム部分は契約で定義 | 学習済みモデルからデータを分離できるか確認 |
| ログ・評価データ | 目的限定利用 | セキュリティ、監査、改善利用の可否 |
| 匿名・統計・集計知見 | 条件付きで受注者利用可 | 再識別、営業秘密、競争上の不利益に注意 |
AI案件では、「受注者は本件データをサービス改善に利用できます」とだけ書くのは危険です。どのデータを、どのAIシステムで、どの期間、どの目的で、第三者モデルに送信するのか、学習に使うのか、推論時だけ使うのか、削除できるのか、出力が他ユーザーに影響するのかを明確にする必要があります。
コンサルティング、調査、研修、法務・会計・人事・戦略支援では、成果物は報告書、資料、テンプレート、分析モデル、ワークショップ資料、研修動画等です。発注者は自社内利用を確保したい。受注者はフレームワーク、分析視点、テンプレート、汎用知見を他案件で使いたい。
この類型では、次の設計が有効です。
発注側帰属でも受注側にライセンスを残す条項例について、制度・リスク・実務対応を分けて確認します。
以下の条項例は、汎用的な素材であり、個別契約にそのまま使用することを予定したものではありません。実際には、対象業務、業界規制、成果物、当事者の交渉力、対価、秘密情報、個人情報、第三者権利、国際取引、紛争解決条項に合わせて修正する必要があります。
第○条（定義） 1. 「本件成果物」とは、本契約に基づき受注者が発注者に納入する仕様書、設計書、プログラム、デザイン、文書、図面、データ、報告書その他の成果物であって、個別契約または発注書に明示されたものをいう。 2. 「受注者既存資産」とは、本契約締結前から受注者が保有し、または本契約に係る発注者の秘密情報に依拠せず独自に作成、開発、取得したプログラム、ライブラリ、テンプレート、ツール、ノウハウ、発明、著作物、データ、設計思想その他の知的財産または技術情報をいう。 3. 「発注者固有情報」とは、発注者が受注者に提供し、または本件業務を通じて受注者が知得した発注者の営業秘密、個人情報、顧客情報、業務仕様、未公開事業計画、価格情報、製品ロードマップ、データ、その他発注者を識別し得る非公開情報をいう。 4. 「汎用成果」とは、本件成果物または本件業務から得られる知見のうち、発注者固有情報を含まず、かつ発注者を識別できない形に抽象化、一般化または分離されたプログラム部品、設計思想、ノウハウ、テンプレート、技術的知見、分析手法その他の成果をいう。
第○条（本件成果物の知的財産権の帰属） 1. 本件成果物に係る著作権その他の知的財産権のうち、受注者既存資産および第三者権利を除くものは、発注者が本契約に定める委託料を全額支払った時点で、受注者から発注者に移転する。 2. 前項により移転する著作権には、著作権法第27条および第28条に規定する権利を含む。 3. 受注者既存資産に係る知的財産権は、受注者に留保される。受注者は、発注者に対し、本件成果物の利用に必要な範囲で、受注者既存資産を利用する非独占的、譲渡不可、再許諾不可、全世界、権利存続期間中の利用権を許諾する。ただし、個別契約に別段の定めがある場合はこの限りでない。
この条項のポイントは、発注者帰属を認めつつ、受注者既存資産を除外し、移転時期を支払時点にしていることです。支払前に権利が移ると、不払い時の交渉力を失うことがあるため、受注者側は移転時期を重視します。発注者側は、検収時点または納品時点で移転させたい場合がありますが、その場合も不払い時の利用停止や解除時の扱いを定めるべきです。
第○条（受注者に対する利用許諾） 1. 発注者は、受注者に対し、本件成果物のうち汎用成果に該当する部分について、受注者が自らまたは受注者のグループ会社、再委託先もしくは他の顧客に対する業務のために、複製、翻案、改変、実装、実行、検証、保守、研究開発、教育、品質改善および組込みを行う非独占的、全世界、無期限、撤回不能、ロイヤルティ追加負担なしの利用権を許諾する。 2. 前項の利用権には、著作権法第27条および第28条に係る利用を含む。ただし、受注者は、発注者固有情報、発注者の秘密情報、個人情報、発注者を識別可能な情報、発注者の未公開仕様、発注者のデータおよび発注者の商標・ロゴを、発注者の事前の書面承諾なく利用、開示、公表または第三者提供してはなりません。 3. 受注者は、本条に基づく利用にあたり、本件成果物を発注者の競合事業者のために発注者固有情報を推知し得る態様で利用してはなりません。 4. 本条に基づく利用権の対価は、本契約に定める委託料に含まれる。
この条項は、発注側帰属でも受注側にライセンスを残す設計の中心です。ただし、発注者側の不安が大きい場合は、他顧客利用を「発注者固有情報を含まない汎用成果に限る」と明確にし、同業他社利用を事前承認制にすることがある。
第○条（秘密情報等による制限） 前条にかかわらず、受注者は、発注者の秘密情報、個人情報、営業秘密、限定提供データ、未公開事業情報、顧客情報、発注者固有の業務仕様その他発注者固有情報について、本契約で明示的に認められた目的以外に利用してはなりません。受注者に残る利用権は、これらの情報の使用、開示、複製、学習利用、第三者提供または公表を許諾するものと解釈してはなりません。
受注者にライセンスを残す設計では、この秘密情報優先条項が不可欠です。これがないと、発注者は「ライセンスバックにより秘密情報まで再利用されるのではないか」と懸念します。
第○条（著作者人格権） 1. 受注者は、発注者または発注者が指定する第三者による本件成果物の利用、改変、翻案、公表、氏名表示の省略その他本契約の目的に従った利用について、著作者人格権を行使しません。 2. 受注者は、本件成果物の作成に関与した役職員、再委託先その他の著作者をして、前項と同等の義務を負わせるものとする。 3. 前二項は、受注者が本契約に基づき受注者に残された利用権を行使することを妨げない。
著作者人格権は譲渡できないため、不行使条項として設計する。発注者が成果物を改変して使う予定がある場合、とくに重要です。
第○条（改良成果） 1. 本件業務の遂行過程または本件成果物の利用過程で生じた改良、派生、汎用化、最適化その他の成果のうち、発注者固有情報に依拠し、発注者の事業または製品に特有のものは、発注者に帰属する。 2. 前項以外の改良成果であって、受注者既存資産、汎用成果または受注者が発注者固有情報に依拠せず独自に開発したものは、受注者に帰属する。 3. 前二項にかかわらず、相手方の事業遂行に必要な場合、当事者は、当該改良成果について、必要な範囲で非独占的利用権の付与を協議する。
改良成果は紛争化しやすい。発注者固有の改良と、受注者の汎用改良を分けることが重要です。
第○条（実績紹介） 受注者は、発注者の事前の書面承諾を得た場合に限り、本件業務に関する事実、発注者名、成果物の画像、ロゴ、画面、導入効果その他の情報を、受注者のウェブサイト、提案資料、営業資料、採用資料またはポートフォリオに掲載することができます。発注者は、秘密情報、未公開情報、ブランド管理上の合理的理由がある場合を除き、承諾を不当に拒絶しないものとする。
事例掲載は、発注者のブランド管理と受注者の営業上の利益が衝突する典型です。ライセンスバックに含めるのではなく、独立条項にする方が安全です。
第○条（データおよびAI利用） 1. 受注者は、発注者が提供するデータ、発注者の業務に関するログ、プロンプト、生成物、評価データその他の情報を、本件業務の遂行、保守、障害対応およびセキュリティ確保の目的でのみ利用する。 2. 受注者は、発注者の事前の書面承諾なく、前項の情報を第三者が提供するAIモデルの学習、ファインチューニング、サービス改善、ベンチマークまたは他顧客向け出力の改善に利用してはなりません。 3. 前二項にかかわらず、受注者は、発注者を識別できず、発注者固有情報、個人情報、営業秘密および限定提供データを含まず、かつ合理的な再識別防止措置を講じた統計的・抽象的知見を、受注者の品質改善および研究開発のために利用することができます。
AI条項では、「学習」と「推論」を分けることが重要です。発注者が許容しているのは、業務遂行のための推論利用だけであり、モデル改善や他顧客向け学習利用までは認めていないことが多い。
発注側帰属でも受注側にライセンスを残す場合の発注者側対策について、制度・リスク・実務対応を分けて確認します。
最も大きな懸念です。対策は、ライセンス対象を汎用成果に限定し、発注者固有情報を明示的に除外することです。さらに、ソースコード、データ、仕様書、顧客情報、画面、帳票、業務ルールを分類し、再利用可能な部品と再利用禁止の情報を別紙で整理する。
受注者が同業他社に全く同じシステムやデザインを提供すると、発注者の競争優位が損なわれる。対策として、次が考えられる。
ただし、広すぎる競業制限は受注者の事業を不当に縛る可能性があるため、必要最小限にする必要があります。
発注者が成果物を資産として評価される場面では、受注者に残るライセンスが「負担」または「権利制限」と見られることがある。対策は、ライセンスを非独占、秘密情報除外、発注者の利用・譲渡・再許諾を妨げないものとし、契約管理台帳に明記することです。
M&Aのデューデリジェンスでは、次を開示できる状態にしておきます。
濫用を防ぐには、利用目的、禁止事項、監査、違反時の停止、損害賠償、差止め、秘密保持、アクセス管理を組み合わせる。特にAI学習、公開、同業他社利用、第三者提供は明示的な承認制にすることが多い。
発注側帰属でも受注側にライセンスを残す場合の受注者側対策について、制度・リスク・実務対応を分けて確認します。
受注者にとって最も危険なのは、「本件業務に関連して生じた一切の成果、ノウハウ、知的財産権は発注者に帰属する」という広すぎる条項です。これを放置すると、既存ライブラリ、テンプレート、営業資料、開発手法、過去案件で培ったノウハウまで発注者帰属と主張される余地がある。
対策は、受注者既存資産を定義し、別紙で列挙し、発注者には必要な利用権だけを付与することです。列挙できない汎用ノウハウについても、「本契約に係る発注者固有情報に依拠せず独自に開発・保有するものは受注者に帰属する」と書く。
受注者のビジネスモデルがテンプレート化、SaaS化、横展開、再利用によって成り立つ場合、発注者帰属条項だけでは事業継続が危険になります。受注者は、汎用成果の再利用権、研究開発利用、他案件組込み、保守利用、教育利用を明示的に求めるべきです。
発注者が仕様を決めたにもかかわらず、第三者の知財紛争をすべて受注者が負担する条項は不合理になり得る。中小企業庁は、発注者の指示に基づく業務について、第三者との知的財産権上の責任を中小企業に一方的に転嫁する行為やその旨を契約に定めることは適正な取引とはいえないとの考え方を示している。
受注者側は、少なくとも次の限定を求めるべきです。
発注者に広範な権利を移転し、受注者の再利用を制限するほど、受注者の機会損失は大きくなる。したがって、対価に反映する必要があります。取適法の観点からも、譲渡・許諾の範囲と対価を明確にすることが重要です。
発注側帰属でも受注側にライセンスを残す交渉パターンについて、制度・リスク・実務対応を分けて確認します。
次の設計パターン一覧は、交渉で使いやすい4つの型を並べたものです。発注者の競争優位、受注者の事業継続、SaaS型か共同開発かによって、どの型に寄せるべきかを読み取ってください。
発注者は自社利用を確保し、受注者は秘密情報を除いた汎用成果を再利用します。
競争優位が重要な案件で、期間・製品・地域を限定して再利用範囲を狭めます。
共通基盤は受注者帰属とし、発注者固有の設定やデータだけを切り分けます。
背景知財、成果知財、実施分野、出願費用、相互利用を組み合わせます。
最も汎用的なパターンです。
このパターンは、システム開発、デザイン制作、コンサルティング、研修資料、業務改善プロジェクトなどで使いやすい。
発注者の競争優位が重要な案件では、受注者の再利用範囲を狭める。
ただし、同業他社の定義が広すぎると受注者の事業を過度に制限するため、製品、地域、顧客層、期間で限定する。
受注者がSaaS、パッケージ、共通基盤を提供する場合、発注者帰属は限定的にする必要があります。
この場合、「発注側帰属でも受注側にライセンスを残す設計」というより、受注者帰属を基本に発注者に利用権を与える設計に近い。発注者が成果物全部の権利取得を求めると、SaaSの構造と矛盾することがある。
共同開発では、単独帰属、共有、相互ライセンス、分野別独占、地域別独占、実施権設定を組み合わせる。
共同開発で安易に「成果はすべて発注者帰属」とすると、受注者側の研究開発意欲を損ない、独占禁止法・取引適正の観点でも問題になり得る。公正取引委員会の知財指針の考え方を参照しつつ、非独占的な相互利用を検討するのが実務的です。
発注側帰属でも受注側にライセンスを残す契約レビューの危険文言について、制度・リスク・実務対応を分けて確認します。
次の文言がある場合、発注側帰属でも受注側にライセンスを残す設計としては危険です。
次の比較表は、11. 契約レビューで見るべきレッドフラッグで扱う項目を「レッドフラッグ、問題点、修正方向」の列に分けて整理したものです。申請後・契約後の判断は一つの観点だけでは足りないため、列ごとの違いを確認し、どの項目に追加確認や社内記録が必要かを読み取ってください。
| レッドフラッグ | 問題点 | 修正方向 |
|---|---|---|
| 「一切の成果、ノウハウ、知見は発注者に帰属」 | 受注者既存資産まで奪う可能性 | 既存資産・汎用ノウハウを除外 |
| 「受注者は成果物を一切利用してはなりません」 | 保守・再利用・研究開発が困難 | 秘密情報除外の非独占ライセンスを設定 |
| 「著作者人格権を譲渡する」 | 著作者人格権は譲渡不可 | 不行使条項に修正 |
| 「著作権を譲渡する」のみ | 翻案権・二次的著作物利用権の扱いが不明 | 著作権法27条・28条を明記 |
| 「第三者紛争はすべて受注者負担」 | 発注者指示起因の責任転嫁 | 仕様・提供素材・改変起因を除外 |
| 「AI改善に利用できます」 | 学習利用の範囲が不明 | データ、目的、モデル、第三者提供を明示 |
| 「対価は委託料に含む」の記載なし | 譲渡・許諾対価が不明 | 譲渡対価・許諾対価の含有を明記 |
| 「再委託先利用不可」 | 実務上保守できない場合 | 承認制・同等義務で許可 |
| 「発注者は自由に第三者へ譲渡可」だが受注者ライセンスの承継不明 | M&A後に受注者利用が争われる | ライセンス存続・対抗・承継を明記 |
| 「OSS不使用」だけ | 現実的でない場合がある | OSS一覧、許諾条件、禁止ライセンスを管理 |
発注側帰属でも受注側にライセンスを残す取引前チェックリストについて、制度・リスク・実務対応を分けて確認します。
発注側帰属でも受注側にライセンスを残す設計を導入する前に、以下を確認する。
発注側帰属でも受注側にライセンスを残す契約の紛争シナリオについて、制度・リスク・実務対応を分けて確認します。
発注者は「当社の成果物を流用した」と主張し、受注者は「汎用部品を使っただけ」と反論する。解決の鍵は、発注者固有仕様と汎用部品の分離です。契約書とリポジトリ上で分離されていなければ、証明が難しい。
受注者既存資産を含む成果物を第三者ベンダーが改変できるかが争われます。発注者に付与された利用権が、第三者委託先による保守・改変を含むかを契約で定める必要があります。
受注者はポートフォリオ掲載のつもりでも、発注者にとっては未公開情報やブランド毀損になる場合があります。事例掲載は、受注者ライセンスとは別に、公開範囲、公開時期、承認フローを定めるべきです。
契約で「サービス改善に利用可」とだけ書かれていた場合、発注者データがモデル学習に使われるか、他ユーザーに影響するか、削除できるかが問題になります。AI・データ案件では、推論利用、保守利用、品質改善、学習利用、第三者モデル送信を分ける必要があります。
発注者が事業譲渡した後、譲受人が受注者に対して「当社が権利者なので再利用を止めろ」と主張することがある。利用権の対抗力や通常実施権の対抗力が問題になり得るが、契約上、ライセンスの存続、承継、譲渡先への拘束を明記しておく方が安全です。
発注側帰属でも受注側にライセンスを残す設計の実務手順について、制度・リスク・実務対応を分けて確認します。
次の時系列は、契約設計を進める実務上の順番を示しています。事業目的の確認から成果物分解、表による権利整理、対価、終了後、証跡化へ進むため、交渉前後で何を固めるべきかを読み取ってください。
自社利用、改変、保守移管、M&A、競合制限など、発注者帰属にしたい理由を確認します。
発注者提供物、受注者既存資産、本件専用成果物、汎用成果、第三者素材、データを分けます。
対象ごとに帰属、発注者の利用権、受注者の利用権、備考を整理します。
譲渡・許諾対価、契約終了後の利用、データ削除、承継を定めます。
発注書、見積書、成果物一覧、既存資産一覧、OSS一覧、検収書、再利用承認記録を残します。
法務が最初に聞くべきことは、「なぜ発注者帰属にしたいのか」です。理由によって設計は変わる。
発注者の目的が「自社利用の安全確保」であれば、完全な独占取得でなくても足りる場合があります。目的が「競合排除」であれば、受注者ライセンスに同業他社制限を設ける必要があります。
次に、成果物を分解する。分解しない契約は失敗しやすい。
この分解を別紙にすることで、交渉が感情論から設計論に変わる。
権利条項を長文だけで書くと読みにくい。別紙で次の表を作るとよい。
次の比較表は、14. 発注側帰属でも受注側にライセンスを残す設計の実務手順で扱う項目を「対象、帰属、発注者の利用権、受注者の利用権」の列に分けて整理したものです。申請後・契約後の判断は一つの観点だけでは足りないため、列ごとの違いを確認し、どの項目に追加確認や社内記録が必要かを読み取ってください。
| 対象 | 帰属 | 発注者の利用権 | 受注者の利用権 | 備考 |
|---|---|---|---|---|
| 業務仕様書 | 発注者 | 無制限 | 保守目的のみ | 秘密情報含む |
| ソースコード固有部分 | 発注者 | 改変・第三者委託可 | 保守・汎用化不可 | 個別仕様 |
| 共通ライブラリ | 受注者 | 本件利用に必要な範囲 | 無制限 | 既存資産 |
| 汎用ログ部品 | 受注者または発注者帰属＋受注者ライセンス | 本件利用可 | 他案件利用可 | 秘密情報除外 |
| 顧客データ | 発注者 | 自由 | 業務目的のみ | 学習利用不可 |
| 統計知見 | 条件付き受注者利用可 | 利用可 | 利用可 | 再識別禁止 |
知財の譲渡・許諾を含めるなら、見積書・発注書・個別契約に反映する。受注者が広範な再利用制限を受ける場合、委託料は高くなる。発注者が追加対価を払いたくない場合は、受注者に残すライセンスを広めにすることで調整できます。
契約終了後も、発注者は成果物を使い続けたい。受注者も汎用成果を使い続けたい。したがって、終了後存続条項に、知財帰属、利用許諾、秘密保持、個人情報、データ削除、監査、損害賠償、紛争解決を含める。
契約条項だけでは足りない。実務では、次の証跡が重要です。
発注側帰属でも受注側にライセンスを残す設計に関与する専門職について、制度・リスク・実務対応を分けて確認します。
発注側帰属でも受注側にライセンスを残す設計は、法務担当だけで完結しません。案件に応じて、次の専門職が関与する必要があります。
次の比較表は、15. 専門職の関与ポイントで扱う項目を「専門職・担当、関与ポイント」の列に分けて整理したものです。申請後・契約後の判断は一つの観点だけでは足りないため、列ごとの違いを確認し、どの項目に追加確認や社内記録が必要かを読み取ってください。
| 専門職・担当 | 関与ポイント |
|---|---|
| 企業内弁護士・法務担当 | 契約構造、リスク配分、交渉方針、紛争予防 |
| 外部弁護士 | 高額案件、M&A、訴訟リスク、国際契約、AI・データ論点 |
| 弁理士・知財法務担当 | 特許、意匠、商標、出願、実施権、改良技術 |
| 情報セキュリティ担当 | 秘密情報、アクセス権、ログ、クラウド、脆弱性 |
| 個人情報保護担当 | 個人データ、委託先管理、越境移転、漏えい対応 |
| 経理・税務担当 | 知財譲渡対価、資産計上、ロイヤルティ、源泉税、移転価格 |
| 内部監査・内部統制担当 | 契約管理、証跡管理、権限統制、監査対応 |
| 事業部門・PM | 成果物範囲、再利用ニーズ、保守体制、納期・価格 |
| 経営者・CLO・GC | 重要契約方針、事業戦略、M&A・資金調達への影響 |
受注側ライセンス設計のFAQについて、制度・リスク・実務対応を分けて確認します。
一般的には、発注者から受注者への利用許諾があれば、契約で定めた範囲で再利用できる可能性があります。ただし、発注者の秘密情報、個人情報、固有仕様の有無や、許諾対象、目的、期間、第三者提供の定めによって結論が変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、同じではないと整理されます。権利を残す場合は権利自体が受注者に帰属し、ライセンスを残す場合は権利者が発注者であっても受注者が一定範囲で利用できます。ただし、契約条項、成果物の性質、既存資産の扱いによって整理が変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、著作者人格権は一身専属で譲渡できないとされています。実務では、不行使条項や再委託先への同等義務で調整することがあります。ただし、成果物の種類、作成者、改変予定、表示方法によって必要な定めは変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、成果物の改変、翻案、二次利用、派生利用を予定する場合は明記することが望ましいとされています。ただし、譲渡範囲、利用許諾範囲、成果物の用途によって必要性は変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、汎用部品やノウハウの再利用には無期限の許諾が合理的な場合があります。ただし、秘密情報、個人情報、同業他社利用、公開、AI学習利用、重大違反時の停止・終了を別に定める必要があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、必ず別料金にしなければならないわけではありませんが、譲渡・許諾の対価が委託料に含まれるかは明記することが重要とされています。ただし、中小受託事業者との取引、譲渡範囲、再利用制限の強さによって対価設計は変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、発注者固有情報や成果物の複製・翻案を利用する行為は制限し得るとされています。ただし、受注者の汎用的な技術、経験、ノウハウまで広く禁止すると過度な制限になる可能性があります。具体的な対応は、対象業種、期間、地域、製品範囲を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、自動的に含めるのではなく個別に定めることが安全とされています。AI学習利用は、入力データ、生成物、プロンプト、ログ、第三者モデル、再識別、営業秘密、個人情報の問題を伴います。具体的な対応は、推論利用、保守利用、品質改善、モデル学習を分けたうえで弁護士等の専門家へ相談する必要があります。
一般的には、第三者委託先による利用、複製、改変、検証、保守の権限を契約で明示する必要があります。ただし、受注者既存資産、第三者素材、OSS、秘密保持義務の有無によって必要な範囲は変わる可能性があります。具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
一般的には、契約に明記がない場合でも、受注者既存資産や一般的ノウハウを利用できる余地はあります。ただし、発注者成果物の著作権が発注者に移転している場合、受注者が成果物を再利用すると侵害と主張される可能性があります。秘密情報や個人情報の問題もあるため、具体的な対応は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。
発注側帰属でも受注側にライセンスを残す設計の結論について、制度・リスク・実務対応を分けて確認します。
発注側帰属でも受注側にライセンスを残す設計は、発注者と受注者のどちらか一方を利する抜け道ではありません。むしろ、成果物を発注者の事業に安全に組み込みつつ、受注者の技術蓄積、再利用、保守、改良、研究開発を可能にするための合理的な契約設計です。
実務で最も重要なのは、次の5点です。
発注者にとって、受注者ライセンスを残すことは、必ずしも権利を弱めることではありません。適切に設計された非独占的・秘密情報除外型のライセンスバックは、むしろ、価格、保守、品質、ベンダー関係、技術発展、取引適正化に資します。受注者にとっても、単に「再利用したい」と主張するだけでなく、発注者固有情報を守る具体策を提示することが、交渉を前に進める鍵になります。
したがって、「発注側帰属でも受注側にライセンスを残す設計」は、企業法務・知財法務の現場において、権利を奪い合う発想から、権利と利用を精密に配分する発想へ移行するための重要な設計思想です。