既存の業務委託契約書に発明の帰属条項がない場合、今から追加できますか？

覚書での追加合意が現実的です。開発着手前なら契約書本体への条項追加が望ましいですが、開発が進行中の案件でも、発明の帰属・移転条項と発明報告義務を覚書で合意すれば、外注先の先行出願を防ぐ対策として機能します。

外注先がフリーランス個人の場合、法人に発注する場合と比べて注意点は変わりますか？

フリーランスは職務発明の枠組みがそもそも働かないため、発明者となった時点で特許を受ける権利はその個人にそのまま留まります。法人発注時以上に、発注者との契約で権利移転を明記しておく必要性が高くなる点に注意してください。

生成AIツールの学習利用設定がオフになっているか、発注者はどう確認すればよいですか？

外注先に法人契約かどうかと学習利用設定の画面提示を求めるのが確実です。契約書に設定維持の義務を明記しておけば、着手時と契約更新時に毎回確認する運用として社内に定着させやすくなり、口頭確認だけに頼らずに済みます。

特許を受ける権利の帰属条項は、既存の著作権譲渡条項に含まれていると考えてよいですか？

含まれていません。著作権と特許権は保護対象や権利発生の仕組みが異なるため著作権譲渡条項だけでは発明の権利までは移転されず、既存契約に発明の帰属条項があるかを確認したうえで、両者を別条項として明記しておく必要があります。

発注側担当者と外注先エンジニアの双方が開発に関与している場合、発明者は社内だけで確定できますか？

自己判断で確定させるのは避けるべきです。共同発明の可能性がある場合、発明者の認定を誤ると冒認出願のリスクを抱えるため、設計判断の記録を材料として、発明者の認定自体を弁理士に相談することをおすすめします。

生成AIの特許リスク｜発注前に決める職務発明と出願の実務

外注先のエンジニアが生成AIを使って開発した仕組みについて、「これは特許が取れるのか」「取れたとして権利は自社に来るのか」と上司や法務から問われて、答えに詰まったことはないでしょうか。社内に知財の専任者がいない企業では、判断できる人がそもそも見当たらないという状況も珍しくありません。

この問いに答えにくいのには理由があります。生成AIと知的財産の話題は著作権に関する情報が圧倒的に多く、特許について語られる場合も「AIは発明者になれるのか」という制度論に議論が集中しがちだからです。発注者が本当に知りたいのは制度の是非ではなく、自社が使うつもりの技術について権利を確保できるのか、そのために契約と運用で何を決めておけばよいのか、という実務の話です。

しかも発注構造には、社内開発では起きない固有の落とし穴があります。多くの企業が整備している職務発明規程は自社の従業員を対象とした仕組みであり、業務委託先やフリーランスのエンジニアには当然には及びません。外注先のエンジニアが発明者と認定された場合、契約で手当てしていなければ、特許を受ける権利は外注先側に残ります。生成AIの利用は、この「誰が発明者か」の判断をさらに見えにくくします。

本記事では、生成AIの特許リスクを「権利が取れない」「権利が自社のものにならない」「他人の権利を侵す」の3類型に整理したうえで、発注者が契約書と開発運用で具体的に何を決めるべきかを解説します。弁理士や法務に相談する前に、論点と質問事項を自分の言葉で整理できる状態を目指します。

Contents — 目次

生成AIの特許リスクとは？発注者が押さえる3つの類型
AIは発明者になれない｜生成AIで特許出願する前提の確認
職務発明と生成AI｜社内利用と外注で特許権の帰属が変わる
発注した開発で特許を取り逃がす3つのパターン
生成AIの特許リスクを抑える発注時のチェックリスト
他社特許の侵害リスクと、弁理士・法務に相談すべきタイミング
まとめ｜生成AIの特許リスクは契約と記録で大半を抑えられる
関連情報

—Free Download / 資料ダウンロード

フリーランス新法対応業務委託発注の法律・契約リスク点検ガイド

この資料でわかること

業務委託でエンジニアに発注する企業担当者・法務担当者が、2024年11月に施行された「フリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）」への対応を含め、業務委託契約に関する法律・契約実務を体系的に把握し、自社のコンプライアンス体制を整備できる状態にする。

こんな方におすすめです

フリーランス新法への対応状況を社内で点検したい企業担当者
業務委託契約書・NDAの記載事項を確認したい法務担当者
偽装請負リスクを把握し指揮命令の境界線を整理したい開発マネージャー

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

入力いただいたメールアドレスにPDFをお送りします。

生成AIの特許リスクとは？発注者が押さえる3つの類型

「生成AIを使うと特許で問題が起きるらしい」という漠然とした不安は、そのままでは対策に結びつきません。まず、起こりうることを性質の異なる3つの類型に分解します。

生成AIの特許リスクは「取れない・自社のものにならない・侵す」の3つに分かれる

生成AIを使った開発で発生しうる特許上の問題は、次の3つに整理できます。

類型	何が起きるか	主な原因
①権利が取れない	出願しても特許にならない、そもそも出願できない	出願前の公開による新規性の喪失、発明者を特定できない
②権利が自社のものにならない	特許は成立するが、権利者が外注先や第三者になる	権利帰属の取り決め不足、外注先による先行出願、発明者の記載誤り
③他人の権利を侵す	他社の特許権を侵害し、差止・損害賠償の対象になる	先行技術調査の未実施、生成AIの出力をそのまま実装

SCROLL→

このうち③は生成AIに限らず、システム開発全般に共通するリスクです。一方で①と②は、生成AIの利用と外注という構造が組み合わさることで顕在化しやすくなります。

そして発注者にとって特に見落とされやすいのが②です。①や③は「特許が取れるか」「訴えられないか」という形で問題意識が持たれやすいのに対し、②は開発が順調に進んでいる限り表面化しません。外注先が納品を終え、いざ出願しようとした段階で「この発明の権利は誰のものか」が確定していないと気づく、というのが典型的な流れです。②は外注構造の中でのみ発生する論点であり、本記事の中心的なテーマにあたります。

生成AIの著作権リスクとの違い（保護対象と発生タイミング）

生成AIの知財リスクというと著作権を思い浮かべる方が多いため、特許との違いをここで整理しておきます。両者は保護する対象も、権利が発生する仕組みも異なります。

比較軸	特許権	著作権
保護対象	技術的思想の創作（アイデア・仕組み）	表現（ソースコードの記述そのもの、文章、画像）
権利の発生	特許庁への出願・審査・登録が必要	創作した時点で自動的に発生（登録不要）
独占の範囲	同じ仕組みに独立して到達した第三者にも権利が及ぶ	依拠せず独自に作った同一表現には及ばない
発注時の主な論点	発明者の特定、特許を受ける権利の帰属、出願タイミング	著作権の譲渡、著作者人格権の不行使、生成物の利用条件

SCROLL→

実務上の違いとして大きいのは、権利発生のタイミングです。著作権は納品されたコードについて自動的に発生するため、契約で譲渡を定めておけば事後的にも整理しやすい面があります。対して特許は、出願という能動的なアクションを、しかも公開より前に行わなければ権利化の道が閉ざされます。「後で考えよう」が通用しない点が、特許固有の難しさです。

著作権側の論点については、生成AIの著作権リスクで扱っています。保護対象が異なるため、両方を押さえておくと知財リスクの見取り図が完成します。

AIは発明者になれない｜生成AIで特許出願する前提の確認

権利帰属の話に入る前に、前提となる論点をひとつ確認しておきます。「AIは発明者になれるのか」という点です。この問いは日本ではすでに司法判断が確定しています。

発明者は自然人に限られる（DABUS事件の確定までの流れ）

AIを発明者として記載した特許出願の可否が争われた、いわゆるDABUS事件では、日本の裁判所は一貫して「発明者は自然人に限られる」との判断を示しました。

まず東京地方裁判所が令和6年5月16日の判決で、特許法上の「発明者」は自然人に限られ、AIは発明者に該当しないと判断しました（長島・大野・常松法律事務所の解説）。続いて知的財産高等裁判所が令和7年1月30日に控訴を棄却して一審の結論を維持し、最高裁判所は令和8年3月4日付の決定で上告を退けました。これにより「発明者は人間に限られる」との判断が確定しています（「AIは特許の発明者になれない」日本の最高裁が判断）。

発注者としてこの判断から読み取るべきことは、「AIが自律的に生み出した発明について、AIを発明者として出願する道は日本では閉ざされている」という点です。出願書類の発明者欄には、必ず人間の氏名を記載する必要があります。

生成AIを「使った」発明は特許出願できる｜判断は人の創作的関与の度合い

ここで混同しやすいのですが、「AIを発明者として記載できない」ことと「AIを使った発明は特許にならない」ことはまったく別の話です。後者は誤りです。

特許庁の審議会資料でも整理されているとおり、発明者とは技術的思想の創作行為に現実に加担した者を指し、発明の特徴的な部分の完成に創作的に貢献したかどうかで判断されます（日本における発明者の決定｜特許庁）。この考え方は、道具として生成AIを使った場合にも同じように適用されます。CADソフトや実験装置を使って発明が生まれても、発明者はそれを操作した人間であるのと同じ構造です。

したがって実務上の判断軸は、次のようになります。

課題を設定し、解決の方向づけを行い、生成AIの出力を評価・修正して発明の特徴的部分を具体化したのが人間であれば、その人間が発明者となる
逆に、人間の関与が「AIに指示を出しただけ」「出力をそのまま採用しただけ」に近づくほど、誰が創作的に貢献したのかの説明が難しくなる

つまり、生成AIを使うこと自体が特許を遠ざけるわけではありません。問題は、人の創作的関与を後から説明できるかどうかです。この「説明できるか」という点が、のちほど触れる開発記録の話につながります。

発明者を誤ると何が起きるか（冒認出願・拒絶理由・無効理由）

発明者の特定を軽視できないのは、誤った場合の影響が大きいためです。

発明者でない者で、その発明について特許を受ける権利を承継していない者が行う出願は「冒認出願」と呼ばれ、拒絶理由（特許法49条7号）および無効理由（同法123条1項6号）にあたります（冒認出願等に係る救済措置の整備｜特許庁）。審査段階で発覚すれば特許が認められず、登録後に発覚すれば無効審判で権利を失う可能性があります。

外注開発では、この論点が現実的なリスクとして立ち上がります。実際に発明の特徴的部分を具体化したのが外注先のエンジニアであるにもかかわらず、発注側の社員だけを発明者として記載して出願すれば、権利の承継がない限り冒認出願にあたる恐れがあるためです。「発注したのだから当社の発明」という感覚は、特許法の枠組みでは通用しません。誰が発明者かという事実認定と、その権利を誰が持つかという帰属の議論は、切り離して考える必要があります。

職務発明と生成AI｜社内利用と外注で特許権の帰属が変わる

ここからが本題です。発明者が特定できたとして、その権利は自社に来るのでしょうか。答えは、その発明者が自社の従業員か、外注先の人間かで大きく変わります。

職務発明制度（特許法35条）の基本と、生成AI利用時の発明者の特定

特許法35条が定める職務発明制度は、従業者がした発明のうち、その性質上使用者の業務範囲に属し、かつその発明をするに至った行為が従業者の現在または過去の職務に属するものを対象とします（職務発明制度の概要｜特許庁）。

発注者が押さえておくべき要点は3つです。

原則として特許を受ける権利は発明者（従業者）に帰属する。会社のものになるのは、契約・勤務規則その他の定めがある場合に限られます
平成27年改正により、あらかじめ定めを置けば発明の完成時から使用者に権利を帰属させられるようになりました。多くの企業の職務発明規程は、この形をとっています
使用者が権利を取得する場合、従業者には相当の利益を与える必要がある。金銭に限らず、昇進・留学機会等も含まれます

社内で開発が完結している限り、この規程が機能していれば権利は自社に集約されます。生成AIを使った場合も枠組みは変わらず、AIの出力を評価・修正して発明を具体化した従業員を発明者として特定し、規程に従って権利を承継させることになります。

職務発明規程は外注先に効かない｜業務委託・フリーランスとの契約が必要な理由

問題はここからです。職務発明制度は「使用者等」と「従業者等」の関係、すなわち雇用関係を前提とした制度です。自社が整備した職務発明規程は、自社の従業員を拘束するものであって、業務委託契約を結んだ受託開発会社の社員やフリーランスのエンジニアには及びません。

このため、外注先のエンジニアが発明者と認定された場合、次のような構図になります。

外注先が法人であれば、その法人の職務発明規程に従い、権利は外注先企業に帰属する
外注先がフリーランスであれば、そもそも職務発明の枠組みが働かず、権利はそのフリーランス個人に留まる
いずれの場合も、発注者に権利を移すには発注者と外注先の間の契約による定めが必要になる

つまり「社内に職務発明規程があるから大丈夫」という認識は、外注開発においては成り立ちません。守ってくれるのは規程ではなく契約です。

さらに厄介なのは、この構図が発注側に見えにくいことです。ソースコードの著作権については譲渡条項を置いている契約書が多い一方で、発明や特許を受ける権利に触れていない契約書は珍しくありません。著作権の譲渡条項は特許を受ける権利までカバーしないため、成果物の著作権は自社にあるのに発明の権利は外注先にある、という状態が生じます。

生成AIの利用は、この問題を深刻にする方向に働きます。エンジニアが生成AIとの対話を通じて設計案を絞り込んでいく開発では、誰がどの段階で創作的に関与したかの境界が曖昧になり、発注側の担当者と外注先のエンジニアの双方が関与した「共同発明」と評価される可能性も高まります。共同発明の場合、持分の取り決めがなければ、各共有者は他の共有者の同意なしに持分を譲渡できず、第三者へのライセンスもできません。自社の事業展開が外注先の同意に依存する状態になりかねません。

発注者が契約に入れる帰属・移転条項の項目（共同発明の持分・実施権を含む）

以上を踏まえ、発注者が契約で決めておくべき項目を整理します。文言の作成は法務・弁理士に委ねるとして、少なくとも次の論点が抜けていないかを確認してください。

項目	決めるべき内容
発明の帰属・移転	本契約に基づく業務の遂行過程で生じた発明について、特許を受ける権利を発注者に帰属または移転させる旨
対象範囲の明確化	「本業務に関連して生じた発明」の範囲。外注先が従前から保有する技術（バックグラウンドIP）との切り分け
発明報告義務	外注先が発明を認識した場合に、発注者へ遅滞なく報告する義務。報告前の第三者への開示・自己出願の禁止
共同発明の扱い	発注者側担当者と外注先が共同発明者となる場合の持分、および各当事者の実施条件・第三者へのライセンス可否
対価の取り決め	権利移転の対価を委託料に含めるのか、別途定めるのか。外注先の従業者に生じる相当の利益は外注先が負担する旨の確認
再委託先への承継	外注先がさらに再委託する場合に、同等の義務を再委託先に負わせる義務
秘密保持との接続	出願前の発明内容を秘密情報として扱う旨。公表・学会発表・技術ブログ掲載の事前承諾

SCROLL→

AI開発を外注する場合は、学習データや学習済みモデルの権利という別の論点も加わります。この点はAI開発を外注する際の知財・著作権の取り決めで詳しく整理していますので、あわせてご確認ください。

発注した開発で特許を取り逃がす3つのパターン

制度の説明だけでは、社内で危機感を共有しにくいものです。ここでは実務で起こりやすい失敗を、原因と発生タイミングとともに具体化します。

出願前のプロンプト投入で新規性が失われる懸念

特許を受けるには、出願時点でその発明が公然と知られていないことが必要です。ところが開発の現場では、設計を詰める過程で技術内容を生成AIに入力することが日常的に行われます。

ここで問題になるのが、入力した情報の扱いです。一般向けの生成AIサービスでは、入力内容が学習に利用される設定になっている場合があり、その場合には発明の内容が他のユーザーの生成物に紛れ込む可能性が指摘されています（生成AIによる特許出願書類作成は危険！？｜高野特許事務所）。加えて、外部に公開されるプロンプト共有機能や、社外メンバーが閲覧できるチャット履歴を使って技術内容をやり取りすれば、公然知られた状態と評価されるおそれが出てきます。

入力した瞬間に直ちに新規性が失われると断定できるわけではありませんが、出願段階で「この情報は公知ではない」と説明できない状態をつくること自体がリスクです。

発注者が今できる予防策: 出願を検討する技術については、学習利用がオフに設定された法人契約のサービスに利用を限定し、その設定状況を外注先にも確認します。加えて、公開範囲が管理できないツールでの技術内容のやり取りを契約上禁止します。

記録がなく発明者を特定できない

先ほど確認したとおり、発明者は発明の特徴的部分に創作的に貢献した人物です。しかし生成AIを併用した開発では、着想から具体化までの過程がチャット履歴とコミットログに分散し、しかもそれらは外注先の管理下にあります。

納品から半年後に出願を検討し始めた時点で、「この方式を最初に提案したのは誰か」「AIの出力をどう評価して採用に至ったか」を再構成しようとしても、資料が残っていなければ関係者の記憶に頼るほかありません。結果として発明者を確定できず、出願を断念する、あるいは不確かな認識のまま発明者を記載して冒認出願のリスクを抱えることになります。

発注者が今できる予防策: 設計上の重要な判断について、日付・提案者・採用理由を残す運用を発注時点で合意します。詳細な記録を求める必要はなく、設計レビューの議事録に判断の経緯を1〜2行加えるだけでも、後の再構成の材料になります。

帰属を決めないまま外注先が先に出願する

権利帰属の取り決めがない状態は、単に「権利が自社に来ない」だけでは終わりません。外注先が自社の技術資産として先に出願してしまう可能性があります。

外注先の立場からすれば、自社の従業員が発明者であり職務発明規程に基づき権利を保有している以上、出願は正当な行為です。発注者側に落ち度があると見るべき場面ではありません。しかし発注者にとっては、自社の事業の中核となる技術について、実施のたびに外注先の許諾が必要になる事態を意味します。契約更新の交渉力にも直接影響します。

発注者が今できる予防策: 発明の帰属条項と発明報告義務を、開発着手前の契約またはNDAに盛り込みます。すでに開発が始まっている案件では、覚書による追加合意も選択肢になります。

—Free Download / 資料ダウンロード