AI開発の特許侵害リスクと責任の所在｜外部モデル・OSS利用時の契約実務と対策

株式会社IPリッチのライセンス担当です。

自社の新規サービスや業務効率化のためにAIシステムを導入する際、すべての機能を社内でゼロから開発するケースは稀です。多くの場合、既存の基盤モデル、外部のクラウドAPI、世界中で公開されているオープンソースソフトウェア（OSS）、そして外部ベンダーに委託して開発した独自コードなどを複雑に組み合わせてシステムが構築されます。

しかし、このように多様な外部リソースを利用して完成したAIシステムが、他社の特許権や著作権などの知的財産権を侵害してしまった場合、「外部ベンダーが開発した機能だから」「自社は他社の特許を知らなかったから」という事情だけで、当然に責任を免れられるとは限りません。

この記事では、AI開発における特許侵害リスクに直面している経営者や法務・知財担当者に向けて、特許法上の過失の推定、総務省・経済産業省が策定した「AI事業者ガイドライン」が示す各主体の役割、そして外部ベンダーとの契約実務における補償条項の設計について解説します。本記事をお読みいただくことで、外部リソースを安全に活用し、自社の事業を法的リスクから守るための実務的な対応策を理解することができます。

企業の知的財産戦略において、権利侵害などのリスクを適切に管理することと同時に検討すべきなのが「知財の収益化」という攻めの視点です。自社で開発したAI関連の特許技術や、安全な開発体制のもとで蓄積された独自のノウハウは、他社への技術ライセンスや権利の売却を通じて、新たな収益の柱となる可能性を秘めています。

特許権の売却やライセンスによる活用先を探す場合は、候補企業との接点を増やす手段の一つとして、特許売買・ライセンスプラットフォーム「PatentRevenue」に無料登録することも検討できます。リスクを抑えつつ、保有する知的財産を事業価値の最大化につなげる戦略的なアプローチが、現代の企業経営には求められています。

外部リソースを組み合わせたAI開発における特許侵害の構造

現在のAIシステム開発は、単一の企業がすべてのコードを記述するのではなく、外部の多様なコンポーネントを統合するエコシステムへと移行しています。この開発手法は、開発期間の大幅な短縮とコスト削減をもたらす一方で、システム内部に潜む知的財産権の侵害リスクを複雑なものにしています。

外部ベンダーへの委託開発であっても、ベンダーが利用するOSSや外部APIの内部構造までを委託元企業が完全に把握することは困難であり、いわゆるブラックボックス化が生じやすいためです。

この知的財産リスクを実務上評価するにあたり、まず「著作権」と「特許権」の性質の違いを明確に区別して理解する必要があります。

文化庁の整理等でも示されている通り、著作権の侵害が成立するためには、原則として既存の著作物との「類似性」に加えて、その著作物に基づいて創作したという「依拠性」が必要です。したがって、開発者が既存のソースコードやコンテンツに依拠せず、独自に同一または類似の表現を創作した場合には、原則として著作権侵害は成立しません。

これに対し、特許権は技術的思想である発明を独占排他的に保護する権利であり、侵害の成立要件として依拠性は求められません。第三者が保有する特許発明の技術的範囲に属するAIシステムやソフトウェアについて、製造、使用、譲渡、提供等の特許法上の実施行為を行った場合、自社や外部ベンダーがその特許を知らず、独自に開発していたとしても、特許権侵害が成立する可能性があります。

OSSの多くは、利用や改変を認めるライセンス条件を設けていますが、その許諾範囲はライセンスごとに異なります。また、OSSライセンスによる許諾が、そのソフトウェアの利用によって第三者の特許権を侵害しないことまで保証するとは限りません。

したがって、外部リソースの組み合わせによるAI開発においては、著作権やOSSライセンスへの対応だけでなく、意図しない特許侵害への備えも経営上の重要な課題となります。

委託開発で「知らなかった」が通用しにくい特許法上の過失の推定

外部ベンダーに開発を委託したAIシステムが他社の特許権を侵害していた場合、そのシステムを利用してサービスを提供する委託元企業は、「ベンダーが開発したものであり、自社は特許侵害の事実を知らなかった」と主張すれば、損害賠償を免れることができるのでしょうか。

日本の特許法の下では、特許を知らなかったという事情だけで責任を免れることは困難です。

民法上の不法行為に基づく損害賠償請求では、原則として権利を侵害された側が、侵害者側の故意または過失を立証します。しかし、特許法第103条には、「他人の特許権又は専用実施権を侵害した者は、その侵害の行為について過失があったものと推定する」と規定されています。

この規定により、特許権侵害が認められた場合、侵害者側が過失の推定を覆す事情を立証できなければ、損害賠償責任を負う可能性があります。ただし、第103条は反証を一切認めない「みなし規定」ではなく、あくまで推定規定です。

特許権は特許公報を通じて公開されています。そのため、事業として特定の技術を実施する企業には、事業分野、製品やサービスの技術内容、企業の規模や専門性などに応じて、関連する特許権の存在を合理的な範囲で確認することが求められます。

もっとも、世界中の関連特許を完全かつ網羅的に調査することは現実的ではありません。実務上は、どのような技術をどの国で実施するのかを整理したうえで、重要な機能や競合企業の権利を中心にFTO調査を行い、その過程と判断記録を残すことが重要です。

また、委託元企業と外部ベンダーのどちらが特許権者に対して責任を負うかは、それぞれが実際に行った行為に応じて判断されます。委託元が侵害製品を使用したり、侵害機能を含むサービスを提供したりしていれば、委託元自身について侵害が成立する可能性があります。ベンダーへの委託や契約上の責任分担だけで、特許権者に対する責任を当然に免れるわけではありません。

特許権者から侵害の警告を受けた際に備え、開発プロセスの初期段階から知的財産権のクリアランスに向けた体制を構築し、外部ベンダーとの間で適切な契約を結んでおくことが、法務および知財担当者に求められる実務対応となります。

AI事業者ガイドラインに基づく各主体の役割と知財保護

生成AIをはじめとする技術の急速な発展に伴い、AIが社会に与える影響とリスクの多様化に対応するため、総務省と経済産業省は2024年に「AI事業者ガイドライン」を策定しました。その後も改訂が行われ、2026年3月には第1.2版が公表されています。

本ガイドラインは、法的拘束力を持つ法律ではなく、事業者の自主的な取り組みを促すための指針です。そのため、個別の特許権侵害や契約上の責任の所在を直接決定するものではありませんが、AIビジネスに関わる企業が構築すべきガバナンスや、各主体に期待される取り組みを検討するうえで重要な資料となります。

本ガイドラインでは、AIのライフサイクルに関与する事業者を、主として以下の3つの主体に分類しています。

第一に「AI開発者」です。これは、AIシステムを研究、設計、開発する事業者を指します。

第二に「AI提供者」です。これは、AIシステムをアプリケーションや既存システムに組み込み、利用者に提供する事業者を指します。

第三に「AI利用者」です。これは、事業活動において、AI提供者から提供されたAIシステムやサービスを利用する事業者を指します。

ただし、実際の事業では、一つの企業が複数の立場を兼ねる場合があります。外部ベンダーにAIシステムの開発を委託し、完成したシステムを自社の顧客向けサービスとして展開する場合、ベンダーがAI開発者やAI提供者に該当し、発注元企業もサービスの提供形態に応じてAI提供者またはAI利用者に該当する可能性があります。

したがって、契約書上の「委託者」「受託者」という名称だけで役割が決まるのではなく、各社が実際にどのような開発、提供、利用を行っているかを確認する必要があります。

ガイドラインにおける共通の指針では、人間中心、安全性、公平性、プライバシー保護などとともに、セキュリティ確保や知的財産権への配慮が示されています。AIシステムが第三者の知的財産を侵害しないよう、データの入力、モデルの開発、システムへの統合、サービスの提供、出力の利用に至る各段階で、関係者が連携して対策を講じることが重要です。

外部ベンダーには、開発時に使用するデータ、コード、OSS、モデル等を適切に管理することが求められます。一方、発注元企業にも、導入するシステムの用途や利用地域を整理し、提供された機能や出力をどのように利用するかを確認することが求められます。

AIに関するリスクを一方の当事者だけに押し付けるのではなく、各主体の管理可能性、保有情報、役割、対価などに応じて、リスクを合理的に分担することが重要です。

AI・データの利用に関する契約ガイドラインと探索的段階型開発

AIシステムの開発を外部ベンダーに委託する際、従来型のシステム開発で使用していた契約書を、内容を確認せずそのまま流用することは、実務上のトラブルを招く原因となります。

従来型のシステム開発では、事前に要求仕様を確定し、その仕様に沿ったプログラムを完成させるウォーターフォール型の開発方式が採用されることがあります。

しかし、機械学習を用いたAIシステムでは、学習用データの質や量、採用する手法によって出力結果の精度が変動します。開発に着手する段階では、目標とする精度を達成できるか、どのような成果物が完成するかを確定的に予測することが困難な場合があります。

経済産業省の「AI・データの利用に関する契約ガイドライン（AI編）」では、このようなAI開発の不確実性を踏まえ、開発を複数の段階に分けて進める「探索的段階型」の開発方式が示されています。この方式は、主として次の4段階で構成されます。

最初のステップは「アセスメント段階」です。委託元が保有するデータや利用可能なデータを確認し、目的とするAIシステムの開発可能性や、採用する手法の方向性を検討します。

次に「PoC段階」へ進みます。一定のデータを用いて試作モデルを構築し、期待する精度や機能を実現できるか、開発手法が事業上の要件を満たす可能性があるかを検証します。

PoC段階で実用化の可能性が確認された場合、「開発段階」に移行し、本格的なAIシステムや学習済みモデルを開発して、本番環境への組み込みを進めます。

さらに、導入後のデータや運用結果を利用して性能を改善する「追加学習段階」があります。追加学習を誰が行うのか、追加データをどのように利用するのか、改善後のモデルの権利や利用条件をどう扱うのかも、契約上の重要な論点となります。

この探索的段階型の開発アプローチは、知的財産権の侵害リスクを管理するうえでも有効です。PoCや開発段階で、ベンダーがどのようなアルゴリズム、OSS、外部API、基盤モデルを使用する予定なのかを確認できれば、本格開発やサービス開始前に、重要な機能に関する特許調査やライセンス条件の確認を行うことができます。

これにより、開発の最終盤になってから権利侵害の可能性が判明し、多額の設計変更コストや事業停止リスクを抱える事態を回避しやすくなります。

外部ベンダーとの契約実務における第三者の権利侵害と補償条項

AIシステムの委託開発契約において、委託元企業と外部ベンダーの間で交渉が難航しやすい事項の一つが、完成したシステムが第三者の知的財産権を侵害した場合の「非侵害保証」および「補償条項」の取り扱いです。

システム開発契約では、成果物が第三者の特許権や著作権を侵害しないことについて、ベンダーが一定の保証や責任を負う条項が設けられる場合があります。しかし、保証の有無や範囲、責任上限、除外事由は契約によって異なり、常に完全な非侵害保証や無制限の補償が定められるわけではありません。

AI開発では、外部モデル、OSS、クラウドAPI、委託元が提供したデータなど、多数の要素が組み合わされます。そのため、侵害の原因がベンダーの独自コードにあるのか、委託元が指定した仕様やデータにあるのか、外部サービスの変更によって生じたのかを事前に完全に予測することは困難です。

実務上は、個別のプロジェクトの性質や対価、各当事者が管理できる範囲に応じて、次のような事項を組み合わせて契約条件を調整します。

第一に、補償責任の上限を設定する方法です。たとえば、通常の損害賠償責任について、委託料の総額や一定期間に支払われた利用料を上限とすることが考えられます。ただし、知的財産権侵害を一般の責任上限の対象外とするのか、別の上限を設定するのかも交渉事項となります。

第二に、保証や補償の対象を限定する方法です。ベンダーが独自に作成したコードについては保証する一方、委託元が指定または提供したデータ、モデル、仕様、第三者サービス、委託元による契約外の改変や利用については対象外とする設計が考えられます。

第三に、責任が発生する要件を定める方法です。ベンダーに故意または過失がある場合に責任を負わせる方法のほか、特定の表明保証に違反した場合に責任を負わせる方法などがあります。故意または重過失に限定するかどうかは、案件の内容や交渉力によって異なります。

第四に、金銭賠償以外の救済措置を定める方法です。第三者から権利侵害を主張された場合に、ベンダーが必要なライセンスを取得する、侵害を回避するようにシステムを修正する、同等機能を持つ代替物に交換する、利用できない場合には契約を解除して一定額を返金するといった対応が考えられます。

契約書には、第三者から警告や請求を受けた場合の通知期限、交渉や訴訟を主導する当事者、和解に必要な同意、費用負担、情報提供、証拠保全などの手続も明記しておく必要があります。

委託元企業は、ベンダーからの保証だけに依存せず、自社でも重要な技術に関する特許調査を行い、採用するOSSや外部サービスの条件を確認する体制を整えることが重要です。

OSSや外部APIを安全に利用するためのSBOM活用と管理体制

AIシステムの構成要素に、多数のOSS、外部モデル、クラウド事業者のAPIが含まれる場合、それらを正確に把握し、継続的に管理することが知的財産リスクをコントロールするための前提となります。

「自社のシステムの中に、誰が作ったどの部品が、どのバージョンで組み込まれているか分からない」という状態では、ライセンス条件や脆弱性を確認できず、特許調査の対象となる機能を整理することも困難です。

そこで重要となるのが、SBOM（Software Bill of Materials：ソフトウェア部品表）の導入です。

経済産業省の「ソフトウェア管理に向けたSBOMの導入に関する手引」では、SBOMを、ソフトウェアを構成するコンポーネントやそれらの依存関係等を一覧化したものとして説明しています。SBOMには、部品名、バージョン、供給者、依存関係、ライセンスなどの情報が含まれます。

SBOMは、もともと脆弱性を迅速に特定するためのサイバーセキュリティ対策として注目されてきましたが、OSSライセンスの管理や、使用している技術要素を把握するための基礎資料としても利用できます。

ただし、SBOMを作成しただけで、第三者の特許権を侵害していないことが確認できるわけではありません。SBOMによって構成要素を把握したうえで、重要な機能、採用技術、提供地域などを踏まえて、必要な特許調査や契約確認を行う必要があります。

OSSのライセンスには、利用、改変、再配布、ソースコードの提供などに関するさまざまな条件があります。一部のOSSライセンスには、特許ライセンスや、一定の特許訴訟を提起した場合にライセンスが終了する特許報復条項が含まれています。

もっとも、特許報復条項の内容や終了の対象範囲はライセンスごとに異なります。自社が保有する特許権を行使する可能性がある場合には、利用しているOSSのライセンス条項を個別に確認する必要があります。

委託開発契約においては、ベンダーに対してSBOMまたはこれに相当する構成部品一覧の作成・提出を求めることが考えられます。さらに、開発後にOSSや外部モジュールが追加・更新される場合に備え、SBOMの更新時期、提出形式、正確性の確認方法も定めておく必要があります。

IPAの2025年度ソフトウェア動向調査では、日本企業におけるOSSポリシーの整備率は36.7％まで上昇した一方、OSPOまたは同等部門の設置率は4.1％にとどまっています。

外部リソースを多用するAI開発を安全に進めるためには、契約によるベンダー管理だけでなく、自社内にOSSや外部モデルの利用ルールを定め、継続的に監視するガバナンス体制を構築することが重要です。

委託先の選定から契約後の監査まで法務担当者が確認すべき事項

AI開発における知的財産リスクを最小化するためには、法務担当者や知財担当者が、外部ベンダーの選定段階から契約締結、開発進行中、システム稼働後の運用に至るまで継続的に関与することが重要です。

まず、委託先の選定段階において、ベンダーの知財リテラシーと開発体制を確認する必要があります。

提案書や商談の中で、「開発においてどのようなOSSや外部APIを使用する予定か」「学習用データの権利や利用条件をどのように確認しているか」「SBOMの生成やライセンス管理の仕組みを導入しているか」といった質問を行い、ベンダー側が知的財産リスクに対して十分な認識と管理手法を持っているかを確認します。

契約書のレビューにおいては、第三者の権利侵害に対する保証、補償条項、責任上限に加えて、紛争発生時の手続を明確に定めておくことが必要です。

自社が第三者から特許侵害の警告を受けた場合に備え、ベンダーに対する通知期限、交渉や訴訟への参加、必要資料の提出、システムの修正、代替手段の提供、和解に関する同意などを定めます。

また、ベンダーが防御活動を行うために必要なシステムの利用環境や操作履歴などについて、委託元が合理的な範囲で協力する義務を設けることも考えられます。

さらに、学習済みモデルや開発成果の権利帰属についても慎重な判断が必要です。自社が提供した学習用データに高い経済的価値や秘密性がある場合、完成した学習済みモデルや成果物の権利を自社に帰属させたいと考えることがあります。

一方、ベンダー側も、自社の汎用的なノウハウ、既存モデル、ライブラリ、アルゴリズムなどを開発に利用している場合があります。そのため、成果物に関するすべての権利を委託元へ移転することが、常に適切とは限りません。

実務上は、既存知的財産と新たに生じた成果を区別したうえで、権利帰属と利用条件を分けて設計することが考えられます。モデルの権利をベンダーに残しながら、委託元企業に必要な範囲の利用権を許諾する方法や、特定の業種・用途・地域について独占的な利用を認める方法もあります。

ただし、「独占的な利用権」という名称だけでは、禁止できる行為や第三者への対抗関係が明確にならない場合があります。利用可能な用途、地域、期間、再許諾、改変、追加学習、同業他社への提供制限などを具体的に規定する必要があります。

AI開発の知財リスクを管理し事業収益に変えるための実務対応

外部API、OSS、既存モデルなどを組み合わせたAIの委託開発には、第三者の特許権侵害をはじめとする知的財産リスクが伴います。

特許法第103条による過失の推定があるため、「外部ベンダーが作成したものだから知らなかった」という事情だけで、委託元企業が当然に損害賠償責任を免れるわけではありません。また、委託元とベンダーの契約で責任を分担しても、その契約だけで第三者である特許権者からの請求を排除することはできません。

このリスクに対応するためには、AI事業者ガイドラインを参考に、開発の初期段階から法務・知財部門がプロジェクトに関与することが重要です。

探索的段階型の開発方式を採用し、アセスメントやPoCの段階で使用技術と権利侵害リスクを確認します。契約書では、非侵害保証の対象、責任上限、除外事由、第三者請求への対応、システムの修正や代替措置などを具体的に定める必要があります。

また、SBOMを活用してシステム内部の構成要素を可視化し、OSSのライセンス条件や特許条項を確認する社内ガバナンスを構築することが、安全なAIビジネスを展開するための基盤となります。

適切にリスクが管理され、権利関係が整理されたAIシステムや、開発過程で自社に蓄積された独自のアルゴリズム、データ処理技術、ノウハウは、自社の事業を守るだけでなく、価値の高い知的財産となる可能性があります。

こうした特許やノウハウは、他業界の企業に対するライセンス供与や、事業戦略の見直しに伴う特許権の売却など、新たな収益化の道を開く手段となります。

まずは、自社が関与するAI開発プロジェクトにおいて、契約書の補償条項、使用しているOSSや外部モデル、SBOMの作成状況を確認してください。

そのうえで、特許権の売却やライセンスによる活用先を探す場合は、候補企業との接点を増やす手段の一つとして、PatentRevenueに無料登録することも検討できます。リスク管理を事業防衛にとどめず、保有する知的財産の価値を最大化し、知財を起点とした事業収益の創出へつなげることが重要です。

（この記事はAIを用いて作成しています。）