技術担当者ができる簡易IPデューデリジェンスの進め方

M&Aや投資のIPデューデリジェンス（IP DD）というと、弁護士・弁理士が行う専門的な法的調査をイメージする方が多いです。しかし実際には、法的判断が必要な領域に入る前に、技術担当者が事前調査として確認できる項目が多く存在します。

本稿では、技術の専門知識を持つが法律の専門家ではない担当者が、投資・買収の予備的なIPチェックとして実施できる項目を整理します。ここで挙げる確認作業はあくまで「技術的な事実の把握」であり、法的判断は弁護士・弁理士に委ねることを前提とします。

簡易IP DDの位置づけ

技術DDと完全なIP DDの間に、技術担当者が担える調査フェーズがあります。

フェーズ	担当	目的
技術DD	エンジニア・技術顧問	コード品質・アーキテクチャ・組織能力の評価
簡易IP DD（本稿）	技術担当者	IPリスクの所在を技術的に把握し、専門家調査の要否を判断する
本格IP DD	弁護士・弁理士	法的権利関係の確定、FTO分析、契約精査

簡易IP DDの目的は「法的な結論を出すこと」ではありません。「どこにリスクがありそうか」「どの領域を専門家に深掘りしてもらうべきか」を整理することです。

技術デューデリジェンスの全体像と7つの評価軸で述べた「競合優位性」の評価においても、コードの出自や利用ライセンスの把握は技術担当者が主体的に進められる部分です。

チェック1：OSSライセンスの確認

技術担当者が最も確認しやすく、かつリスクが見つかりやすいのがOSSライセンスです。

確認すべきライセンスの種類

OSSライセンスは、大きく2種類に分かれます。

種別	代表例	注意点
コピーレフト型	GPL, LGPL, AGPL	組み込み方によってはソースコード開示義務が発生しえます
パーミッシブ型	MIT, Apache 2.0, BSD	商用利用・改変・配布の自由度が高いです

コピーレフト型のOSSが製品の中核部分に組み込まれている場合、ソースコードの開示が求められる可能性があります。これは法的判断が必要な領域ですが、「どのOSSがどのライセンスで使われているか」を把握すること自体は技術担当者が行えます。

実施方法

package.json / requirements.txt / go.mod 等の依存ファイルを確認する
npm licenses / pip-licenses 等のコマンドでライセンス一覧を出力する
依存ライブラリの数が多い場合は、OSSスキャンツール（例：FOSSA、Snyk、Dependabot）の出力レポートを共有してもらう
確認ポイント: GPL / LGPL / AGPL が含まれているか、それがプロダクトのどの部分で使われているか

法的なリスク評価（「この組み込み方で開示義務が発生するか」）は専門家に委ねますが、「コピーレフト型OSSが存在するかどうか」は技術担当者が確認できます。

チェック2：ソースコードの出自確認

コードが「会社が適切な権限を持って作成・取得したもの」かどうかを技術的に把握します。

git履歴・コミット情報の確認

主要なコードを書いたコミッターは誰か（現在も在籍しているか）
大量のコードが一度にコミットされているタイミングはないか（外部からのコピーの可能性）
コミットメッセージに「from」「port」「copy」「migrate」等の記述がないか

これらは「確認して専門家に伝える事実」であり、法的判断ではありません。

外部委託・フリーランスの把握

コードの一部を外部委託やフリーランスに依頼したことがあるか経営陣に確認する
その場合、著作権の帰属について書面があるかどうかを確認する（内容の法的評価ではなく「書面が存在するか」の確認）
特に創業初期のコアプロダクトに関わったメンバーのリスト化

チェック3：AIモデル・データセットの利用条件確認

AIを活用したプロダクトでは、モデルとデータの利用条件の確認が必須です。ここは技術担当者が最も効果的に確認できる領域の一つです。

基盤モデルのAPI利用規約

使用している基盤モデルのAPIやSDKには、利用規約があります。以下の点を確認します。

商用利用の可否: 利用規約に商用利用の制限がないか
禁止用途の確認: 競合サービスの開発・モデルの蒸留・ベンチマーク用途が制限されていないか
モデルのバージョン管理: 利用しているモデルバージョンの利用規約が変更されていないか（利用規約はバージョンごとに異なる場合があります）

OSSモデルのライセンス確認

LLaMA・Mistral・Gemma等のOSSモデルを使用している場合、それぞれ独自のライセンスがあります。

MITやApache 2.0とは異なる「カスタムライセンス」が多い
商用利用・競合への提供・派生モデルの配布に制限がある場合があります
確認方法: モデルのHugging Faceページや公式リポジトリのLICENSEファイルを参照する

学習データの出所確認

独自データの場合：そのデータは誰が収集・生成したものか、利用許諾はあるか
公開データセットの場合：そのデータセットのライセンスが商用利用を許可しているか
スクレイピングで収集したデータの場合：利用規約上の制限がないか（法的判断は専門家に委ねますが、スクレイピングの有無自体は技術担当者が把握できます）

チェック4：特許・商標の基本確認

特許の法的評価（権利範囲・FTO分析）は専門家の領域ですが、「特許があるかどうか」の事実確認は技術担当者が行えます。

確認できること

特許出願・登録の有無と件数（J-PlatPatで社名検索すれば確認できます）
「特許あり」と主張している場合、それが「出願中」なのか「登録済み」なのかの区別
特許の内容がプロダクトの現行機能と対応しているかの概要確認

技術担当者が判断しないこと

特許の権利範囲が有効か
競合他社の特許を侵害していないか（FTO分析）
特許のビジネス上の価値

これらは弁理士・弁護士の領域です。簡易IP DDでは「特許が存在するか」「内容がプロダクトと関連しているか」の事実把握に留めます。

チェック5：情報管理の実態確認

営業秘密として保護されるべき技術ノウハウが適切に管理されているかを、技術的な観点から確認します。

アクセス制御: 重要な技術ドキュメント・ソースコードへのアクセスが適切に制限されているか（GitリポジトリのPrivate設定、VPNの有無、権限管理）
退職者管理: 退職した開発者のアカウント・アクセス権が適切に削除されているか
ドキュメントの存在: 重要な技術仕様・設計書が社内に文書化されており、特定の個人の頭の中だけにない状態か（キーマン依存の評価にもなります）

確認結果の整理と専門家への引き渡し

簡易IP DDで得られた情報は、以下の形式で整理し、本格的なIP DDを担う専門家へ引き渡します。

技術担当者が整理する項目:

項目	確認結果	専門家への引き継ぎ要否
OSS: コピーレフト型ライセンスの有無	あり / なし / 要確認	あれば要引き継ぎ
コードの外部委託状況	委託先・契約書の有無	契約書なしなら要引き継ぎ
AIモデルの利用規約	制限事項の有無	制限がある場合は要確認
特許の出願・登録状況	件数・登録状況	プロダクトとの関連確認が必要な場合
アクセス管理の状態	適切 / 課題あり	課題がある場合は要確認

このリストを専門家に渡すことで、「どこを重点的に調査するか」の優先順位付けができ、DD全体の効率が上がります。

投資家が実施すべき技術デューデリジェンスの全項目では、技術DDの全体像をチェックリスト形式で整理しています。本稿のIP確認項目は、そのチェックリストの「IP・ライセンス」領域を技術担当者が実施できる粒度まで落とし込んだものです。

Tied株式会社では、技術DDおよび簡易IP DD支援を提供しています。詳細は投資家向けサービスページをご覧ください。