気候テック企業は、特許を取得すれば技術保護が完了したと考えがちです。しかし実際の製品は、請求項に記された発明だけで動くわけではありません。センサーの校正係数、畜舎ごとの設置位置を決める規則、欠測を判定するコード、学習データ、顧客別の運用記録、API、ダッシュボード、現場対応手順が一体となって性能を生みます。その一部は特許にできますが、秘密にして初めて価値を保てるものもあり、著作権や契約で利用範囲を定めるべきものもあります。

したがって、特許後のIP戦略は権利をできるだけ多く登録することではありません。どの資産を誰にどの程度見せ、漏えい・複製・独自開発・契約終了後の再利用のリスクをどの手段で管理するかを決めることです。保護手段ごとに成立要件と限界が異なるため、一つの技術を複数の層に分けて設計しなければなりません。

まず正すべき誤解：特許は製品全体の所有権証明書ではない

特許は、定められた要件を満たす発明について、特定の国または地域で認められる排他的権利です。本稿は一般的な運用の枠組みであり、新規性の例外、職務発明、データ保護、契約の効力は国の法律と契約によって異なるため、現地の弁理士・弁護士による確認が必要です。WIPOは、特許は属地主義の権利であり、権利を付与した国・地域でのみ効力を持つと説明しています。国内出願・登録が海外販売国の保護を自動的に生むわけではなく、PCT国際出願も世界共通の単一特許を発行する制度ではありません。目標市場、製造国、競合、権利行使の可能性を見て国ごとの進出を決めるべきです。

特許は発明を公開する代わりに権利を得る仕組みでもあります。出願前に論文、展示会、提案書、顧客デモで核心を公開すると、国によっては新規性を失います。一方、公開すれば競合が容易に回避設計でき、侵害の発見も難しい運用パラメータなら、営業秘密の方が適する可能性があります。何でも特許にすることも、何でも隠すことも、どちらも危険です。

著作権も万能ではありません。WIPOは、コンピュータプログラムやデータベースは著作権の保護対象になり得るものの、保護されるのは表現であり、アイデア、手順、運用方法、数学的概念そのものには及ばないと説明しています。競合が別のコードで同じ機能を独自実装するリスクは、著作権だけでは防ぎにくいものです。結局、特許、営業秘密、著作権、商標、契約、セキュリティを役割に応じて組み合わせなければなりません。

第一歩は「IP資産マップ」を作ること

畜産メタン・プラットフォームを一つの発明と見なさず、資産単位に分解します。ハードウェアにはセンサー配置構造、サンプリング流路、校正装置、製造図面があります。分析層には換気量の推定式、外れ値判定、ベースラインモデル、特徴量、モデルの重みがあります。データ層には生の観測値、ラベル、活動データ、校正履歴、派生排出量、レポートがあります。ソフトウェア層にはファームウェア、エッジアプリケーション、クラウドコード、API仕様、UI、デプロイスクリプトがあります。事業層には価格、顧客リスト、設置原価、パートナー評価があります。

各資産について、少なくとも所有者、創作者・発明者、作成日、保管場所、公開状況、製品バージョン、事業価値、リバースエンジニアリングの可能性、漏えいの影響、関連契約、保護手段を記録します。従業員が職務中に作ったコード、外注先が開発したファームウェア、大学と共同研究したモデル、農場が提供したデータは、権利帰属が同じだと仮定してはいけません。費用を支払ったことやサーバーを運用していることだけで、必要な権利がすべて自動的に移転するわけでもありません。

資産マップは法務部門の一覧で終わらせてはいけません。製品機能、データパイプライン、契約の実際の流れに結び付けます。例えば「排出量モデルv3」には、利用した原資料の許可目的、オープンソースライブラリ、コードリポジトリ、学習実行ID、デプロイ済みモデルのハッシュ、外部公開文書を関連付けます。そうして初めて、技術が変わったとき保護範囲と義務も同時に更新できます。

アルゴリズムは特許と営業秘密の境界を先に定める

アルゴリズムという言葉の下には、異なるものが混在しています。技術的効果を生む処理方法、モデル構造、特徴量の選択、学習データの精製方法、閾値、現場ごとの調整値、結果を説明する文書などです。管轄と具体的な請求内容によっては特許検討の対象になりますが、「AIアルゴリズム」という名称だけで特許性が生じるわけではありません。公開前に弁理士と発明の要素、先行技術、権利化する国を検討すべきです。

製品を使えば機能は見えるものの内部パラメータが分かりにくい場合は、営業秘密戦略を検討できます。ただし営業秘密は、秘密だと宣言するだけでは保護されません。WIPOは一般に、情報が秘密であるため商業的価値を持ち、限られた人だけが知り、権利者が秘密保持のため合理的な措置を講じる必要があると説明しています。同じ方法を独自に開発した相手や、合法的にリバースエンジニアリングした相手にまで独占権を行使する制度でもありません。

アルゴリズムを営業秘密にするなら、モデルファイルだけをロックしてはいけません。特徴量の定義、学習・検証データ、ハイパーパラメータ、性能限界、デプロイ設定を等級別に分類し、業務上必要な人だけにアクセスを与えます。リポジトリ権限、多要素認証、エクスポートログ、暗号化、協力会社とのNDA、退職・契約終了時の回収とアクセス遮断を一体で運用します。論文や顧客向け資料には性能を評価できる十分な情報を示しつつ、再現に不要な秘密パラメータまで自動的に公開しない原則が必要です。

データは「所有権」という一語では保護できない

センサーデータをサーバーに保存したからといって、プラットフォームがすべての権利を持つと断定すれば紛争になります。農場が提供した活動データ、機器が観測した生データ、人が付けたイベントラベル、モデルが作った補正値、集計排出量、顧客向けレポート、複数農場で学習したモデルは、生成主体と利害関係が異なります。データ自体、データベース構造、営業秘密、個人情報、契約上の利用権も別々の問題です。

契約では抽象的な「データ所有」より、権限を動詞で書きます。誰が収集、閲覧、複製、訂正、結合、モデル学習、第3者提供、対外的な主張に利用できるのかを、目的・期間・地域・匿名化の水準に分けて定めます。契約終了時の原資料の返却・削除、バックアップの扱い、既に作成した集計統計やモデルの継続利用、法定保存義務も決めます。検証機関には、主張の確認に必要な期間と範囲だけ読み取り権限を付与できます。

データ権利を広く取得することだけが良い戦略ではありません。目的が不明確な永久利用権は農場の信頼を損ない、海外規制や顧客の調達審査で負担になる可能性があります。逆に、サービス提供に必要な校正・品質管理・モデル改善の権限がなければ、製品の運用は困難です。必要最小限の権限と、顧客に説明できる価値を釣り合わせることが核心です。

ソフトウェアはコード、依存関係、配布権を一体で管理する

ソフトウェア著作権はコードの表現を保護しますが、実際の事業では誰がコードを書き、会社がどの権利を確保したかが先です。従業員、フリーランサー、外注開発、共同研究の契約を確認し、成果物の帰属、改変・複製・配布・再ライセンス権、ソースコードの引き渡し、文書とテストを含むかを明記します。リポジトリのコミットとレビュー記録は、創作過程とバージョンを説明する証拠になります。

オープンソースは無料だから権利確認が不要なコードではありません。構成要素、バージョン、ライセンス、改変の有無、配布方法をソフトウェア部品表に記録し、表示・ソース提供などの義務を確認します。センサーファームウェア、エッジイメージ、クラウドサービス、顧客にインストールするプログラムは配布形態が異なるため、同じライセンス判断をそのまま適用してはいけません。生成AIが作ったコードも、出典、レビュー、セキュリティ試験、ライセンス衝突の可能性を開発手順で扱う必要があります。

顧客契約ではアカウント利用権とソフトウェア所有権を区別します。顧客は成果を利用する権利を得ても、ソースコードやモデルの譲渡を受けるとは限りません。逆に、供給者がサービスを停止した場合に備え、大企業の購入者がソースコード・エスクロー、データ搬出、移行支援を求めることがあります。要求を無条件に拒否したり全面譲渡したりせず、発動条件、範囲、費用、秘密保持義務を設計します。

現場シナリオ：農場・大学・製造パートナーと共同開発する場合

仮想のメタンモニタリング企業が農場からデータを収集し、大学の研究チームと排出量モデルを改善し、製造パートナーがゲートウェイのファームウェアを作るとします。共同研究の開始後になって成果物の所有権を議論すると、発明者、論文公開、コード利用、データ学習の範囲が衝突する可能性があります。

開始前に各当事者が持ち込む背景IPを一覧として固定します。共同研究で新たに生じる前景IPについて、発明と著作物ごとの帰属、出願の意思決定、費用、実施権、事業分野を定めます。大学の論文公開手続には、出願検討と営業秘密の削除のための事前審査期間を設けます。農場データは、研究、サービス提供、モデル学習、公開事例について別々の同意に分け、製造パートナーには生産に必要な図面・鍵・ファームウェアモジュールだけを提供します。

WIPOも技術移転契約においてライセンスと譲渡を区別し、共同研究契約では背景IP、成果物の所有・アクセス権、利益・リスク、商用化権を定める必要があると説明しています。標準契約書をそのまま使わず、実際の協業構造と管轄に合わせて法律専門家と調整すべきです。本稿の枠組みは法律意見に代わるものではありません。

運用基準：IP Registerと公開ゲートを接続する

IP Registerには特許番号だけを入れません。資産ID、種類、所有者、創作者・発明者、関連契約、管轄、公開状況、秘密区分、アクセス者、保管場所、製品バージョン、更新・再検討日、侵害・漏えい対応者を記録します。四半期ごとに製品ロードマップと照合し、新しいコード・データ・ノウハウが抜けていないか確認します。

外部公開には一つのゲートを設けます。論文、プレスリリース、提案書、Gitリポジトリ公開、展示デモ、顧客向けAPI文書を出す前に、特許出願の必要性、営業秘密、個人情報、顧客契約、オープンソース義務を確認します。承認結果と公開版のハッシュを残せば、何がいつ公開されたかを後から追跡できます。

事故対応も準備します。認証情報の漏えい、リポジトリの複製、退職者からの未回収機器、パートナーによる目的外利用が判明した場合に、アクセス遮断、証拠保全、影響範囲の確認、契約上の通知、法的対応を誰が決めるかを定めます。営業秘密は漏えい後に秘密性を取り戻すことが難しいため、予防と初動の速さが重要です。

実行チェックリスト

  • 製品をハードウェア、アルゴリズム、データ、ソフトウェア、運用ノウハウの資産に分解したか。

  • 国内の出願・登録と海外権利の管轄・状態を正確に区別したか。

  • 外部発表前に新規性、秘密情報、顧客の公開権限を確認しているか。

  • リバースエンジニアリングの可能性、公開コスト、権利行使の可能性で特許と営業秘密を選んだか。

  • 営業秘密の一覧、秘密区分、最小権限、NDA、退職・終了手続が実際に運用されているか。

  • 生データ、ラベル、派生値、レポート、モデル学習権を契約で分けたか。

  • 従業員・外注・共同研究の成果物の権利帰属と利用範囲を文書で確認したか。

  • オープンソースの構成要素とライセンス義務を配布形態別に管理しているか。

  • IP Registerが製品・モデル・データのバージョンと関連契約まで結び付いているか。

  • 国ごとの法律と契約の違いを、進出前に現地専門家へ確認しているか。

結論：IPポートフォリオは技術の境界を運用するシステムである

特許は重要な出発点ですが、アルゴリズムの非公開パラメータ、農場のデータ利用権、ソフトウェアコード、現場ノウハウまで一度に保護することはできません。保護対象と露出経路が異なるため、特許、営業秘密、著作権、契約、セキュリティ管理を資産ごとに配置する必要があります。

優れたIP戦略は、すべての情報をロックするものではありません。顧客と検証者が性能を判断できる証拠を提供しながら、再現に不要な秘密は最小権限で守ります。誰が作り、誰が使えるのか、どの国で効力を持つのか、契約終了後に何が残るのかを追跡するとき、IPは登録証の束ではなく、製品の拡張と協業を可能にする運用基盤になります。

出典