AI開発における知的財産権の扱い方
AI開発プロジェクトでは、完成したモデルやソースコードだけでなく、学習データの加工物や生成された出力物についても知的財産権の扱いが論点になります。曖昧なまま進めると、将来的に「このモデルを他の用途に使えるのか」「開発会社が同種のモデルを他社に提供してよいのか」といった疑問が解決できないまま残ってしまいます。
AI開発で発生しうる知的財産権の種類
AI開発プロジェクトで論点になりやすい権利は、主にソースコードやドキュメントの著作権、学習済みモデル（パラメータ）の扱い、そして独自性の高いアルゴリズムに関する特許の可能性です。特許化を検討するような高度な独自技術でない限り、実務上は著作権とモデルの利用権の扱いが中心になります。
特許化を検討すべきケースとそうでないケース
既存の手法の組み合わせや、一般的なライブラリを用いた開発の場合、特許として保護できる新規性・進歩性を満たすことは少なく、実務上は著作権とモデルの利用権の整理で十分なケースがほとんどです。一方で、独自のアルゴリズムやデータ処理手法を新規に考案した場合は、特許出願によって競合他社の模倣を防げる可能性があります。
特許化には専門的な調査と費用が必要になるため、まずは自社の開発内容に特許性がありそうか、開発会社や弁理士に相談した上で方針を決めるとよいでしょう。多くの中小規模のAI開発案件では、特許よりも契約上の利用権の整理が現実的な対応になります。
営業秘密として保護するという選択肢
特許出願は技術内容を公開することとセットになるため、競合に模倣されるリスクを減らしたい独自ノウハウについては、あえて特許化せず「営業秘密」として社内外に非公開のまま管理するという選択肢もあります。営業秘密として法的保護を受けるには、秘密として管理されていること、有用な情報であること、公然と知られていないことの3要件を満たす必要があり、社内のアクセス権限管理やNDAの整備が前提になります。
特許化と営業秘密のどちらが自社にとって有利かは、技術の性質や公開によるメリット・デメリットを踏まえて判断する必要があるため、迷う場合は開発会社だけでなく知的財産の専門家に相談することをおすすめします。
学習済みモデルは「著作物」として扱われるのか
学習済みモデルのパラメータそのものは、現状の実務上、著作物として明確に保護されるかどうか議論が分かれる部分があります。そのため多くの契約では、著作権の帰属という形式ではなく、「モデルの利用権をどちらが持つか」「独占的に利用できるのか、非独占的か」という形で契約に落とし込むのが実務上の一般的な対応です。
発注者としては、開発してもらったモデルを自社専用として独占利用したいのか、費用を抑える代わりに開発会社が類似モデルを他社にも提供することを許容するのか、方針を決めたうえで契約交渉に臨むとスムーズです。
独占利用と非独占利用、費用への影響
独占的な利用権を求める場合、開発会社にとってはその開発工数を他社案件に転用できなくなるため、見積もり金額が高くなる傾向があります。逆に非独占での利用を許容すれば、開発会社は類似の基盤を複数社に展開してコストを分散できるため、発注者側の費用負担が抑えられることが一般的です。
自社の事業がAI活用そのものを競争優位の源泉としているのか、それとも業務効率化の手段として位置づけているのかによって、独占利用にこだわるべきかどうかの判断も変わってきます。
業界特化型モデルにおける権利関係の考え方
特定の業界（製造業の検品、医療の画像診断補助など）に特化したAIモデルを開発する場合、開発会社側がその業界向けの汎用的なノウハウとして今後も展開していきたいと考えるケースが少なくありません。発注者としては自社の競争優位に直結する部分だからこそ独占を求めたい一方、開発会社は業界特化のノウハウを蓄積して事業を広げたいという思惑があり、両者の利害が対立しやすい領域です。
この場合、モデル全体を独占するのではなく、自社の業務データそのものや、そのデータを用いて微調整した部分のみを独占対象とし、基盤となる汎用モデル部分は開発会社が他社にも提供できる、という折衷案で合意するケースもよく見られます。
既存ライブラリ・フレームワーク部分の権利
AI開発では、オープンソースのライブラリや開発会社が独自に保有する共通基盤（フレームワーク）を活用することが一般的です。これらの部分については開発会社側に権利が残るのが通常であり、発注者に譲渡される対象は「その案件のために新規開発された部分」に限定されるケースが大半です。
契約書に「成果物の権利は発注者に帰属する」とだけ書かれている場合、この切り分けが曖昧になっていることがあるため、既存基盤部分の扱いについて具体的に質問しておくとよいでしょう。
オープンソースライセンスの確認も忘れずに
開発に使用されるオープンソースソフトウェアには、それぞれ異なるライセンス条件（商用利用の可否、改変時の公開義務など）が定められています。自社の事業内容によっては、特定のライセンス（強いコピーレフト型など）が適用されるライブラリの利用が望ましくない場合もあるため、主要な構成要素にどのようなライセンスのソフトウェアが使われているか、開発会社に一覧を提示してもらうと安心です。
特に、自社サービスをSaaSとして外部に提供する予定がある場合は、改変したソースコードの公開を義務付けるライセンス（コピーレフト型）が含まれていないか、事前にチェックしておくことをおすすめします。意図せずソースコードの公開義務を負ってしまうと、自社の非公開にしたい実装まで開示対象になってしまうおそれがあります。
生成AIを使った成果物特有の論点
生成AIを組み込んだアプリケーションの場合、AIが生成したコンテンツ自体の権利関係についても整理が必要です。特に、外部の生成AI APIを利用している場合は、そのAPI提供元の利用規約によって、生成物の商用利用可否や権利帰属のルールが定められていることが多いため、開発会社との契約内容とAPI提供元の規約の両方を確認する必要があります。
第三者の権利を侵害しないかという観点
生成AIが作り出す文章や画像は、学習データの性質によっては既存の著作物と類似した内容を出力してしまうリスクがゼロではありません。自社サービスで生成物を外部に公開する用途がある場合は、意図せず第三者の権利を侵害するリスクをどう低減するか、開発会社にチェック体制の有無を確認しておくと安心です。
既存の作品との類似性を機械的に検出する仕組みを組み込む、生成物を公開前に人が確認するフローを設けるなど、リスクの許容度に応じた対策を講じることが望ましいでしょう。
生成物の権利侵害が発覚した場合の責任分担
万が一、生成AIの出力が第三者の権利を侵害していると指摘を受けた場合に、その対応費用や賠償責任を発注者・開発会社のどちらが負担するのかも契約書で確認しておくべき点です。開発会社が採用した生成AIサービスの提供元によっては、著作権侵害の申し立てに対する補償制度を用意している場合もあるため、利用予定のサービスにそうした制度があるかどうかも合わせて確認しておくと安心材料になります。
契約書で確認しておきたいチェックポイント
権利関係を巡るトラブルを避けるために、契約段階で以下のような点を具体的に確認しておくことをおすすめします。
- 成果物（モデル・コード）の権利が発注者・開発会社のどちらに帰属するか
- 開発会社が類似モデルを他社に提供することを制限できるか（独占/非独占）
- 既存ライブラリ・フレームワーク部分の権利の扱い
- 外部AI APIを利用する場合の提供元規約との整合性
- 契約終了後も成果物を利用し続けられるか
小規模な発注でも権利関係は明確にしておく
小規模なPoCや試験的な開発であっても、後々本格導入に進んだ際に「権利関係が曖昧なまま作られたモデル」が土台になっていると、スケールする段階で契約の巻き直しが必要になることがあります。プロジェクトの規模にかかわらず、最初の契約段階で権利関係を明確にしておくことが、長期的な手戻りを防ぐことにつながります。
PoC段階の契約書にも権利条項を盛り込む
PoCは検証目的であるため簡易な契約書で済ませてしまいがちですが、PoCで作成したプロトタイプやデータ加工物をそのまま本開発に引き継ぐケースは多く見られます。PoC契約であっても、成果物の権利帰属や利用範囲について最低限の条項を盛り込んでおくことで、本開発への移行時に権利関係を整理し直す手間を省くことができます。
また、PoCの結果が思わしくなく本開発に進まなかった場合でも、PoC中に作成した分析結果やレポートを自社の今後の検討材料として保持・利用できるかどうかも、契約時に確認しておくとよいでしょう。
