AI・ソフトウェア発明の
特許適格性

特許適格性とは、あるアイデアや成果物が、そもそも特許制度の対象となり得る種類のものかという問題です。日本では、特許法2条1項の発明該当性や、特許法29条1項柱書の産業上利用可能性に関する問題として現れます。一方で、特許性はより広い概念であり、特許適格性を満たしていても、新規性、進歩性、記載要件、明確性、権利帰属などで特許を受けられないことがあります。

次の比較表は、特許適格性と周辺要件の違いを整理したものです。読者にとって重要なのは、AI技術の価値が高いことと、特許制度上の要件を満たすことは別問題だと分けて考えられる点です。各行から、どの問いが入口の問題で、どの問いが権利化・事業保護の問題なのかを読み取ってください。

日本の特許法は、発明を「自然法則を利用した技術的思想の創作のうち高度のもの」と定義しています。自然法則は、経済法則、商取引上の取り決め、人間の心理、数学上の公式そのもの、ゲームのルールそのものとは区別されます。技術的思想は、課題解決のための技術的手段として把握できる考え方であり、創作は単なる発見や情報提示ではなく、技術的な構成・方法として形成されたものを意味します。

学習済みモデルは、プログラム、情報処理装置、情報処理方法、記録媒体、推論システム等として請求されることがあります。請求項の末尾がモデルやニューラルネットワークであっても、請求項や明細書からコンピュータを機能させるプログラムであることが明確であれば、そのように扱われ得ます。一方で、コンピュータに関する記載がなく、プログラムであるか不明確な場合は、明確性の問題が生じ得ます。

次の表は、学習済みモデルを請求項や明細書で扱うときの確認事項です。重要なのは、モデル名だけで権利範囲を作ろうとせず、入力、出力、学習、推論、検証、秘密管理を一体で確認する点です。各行から、開示する情報と秘匿する情報の境界を読み取ってください。

学習データの種類、入力データと出力データの関係、教師データの作成方法も重要です。「AIが見つける」と書くだけでは足りません。材料開発AIでは組成、製造条件、結晶構造、物性値、評価結果の関係を、医療AIでは画像特徴、臨床情報、診断支援出力の関係を、製造AIではセンサ波形、設備状態、異常判定、制御信号の関係を説明する必要があります。

AI予測物では、予測結果が実際の評価・実験と同視できるだけの裏付けを持つかが問題になります。早期出願と裏付け不足、実験完了待ちと新規性喪失の間で判断が必要です。次の時系列は、研究開発スピードと出願タイミングを整理するためのものです。各段階で、出願、追加実験、秘匿、防衛出願のどれを選ぶべきかを読み取ってください。

生成AI、プロンプト設計、RAG、AIエージェント、マルチモーダルAIでも核心は同じです。単なるプロンプト文や業務指示文は、人間の言語的指示や業務手順に近く、特許適格性を基礎づけにくいと考えられます。検索インデックス、埋め込みベクトル、再ランキング、キャッシュ制御、幻覚抑制の検証処理、根拠文書照合、出力制約、権限判定、ログ制御、推論コスト低減など、技術的情報処理として把握できるかが重要です。

AI・ソフトウェア発明の特許適格性は、5段階で検討すると整理しやすくなります。重要なのは、事業上の便利さをそのまま主張するのではなく、抽象的アイデアを取り除き、技術的課題、具体的構成、請求項表現へ順に変換することです。次の判断の流れでは、上から下へ進むほど、発明の説明が権利化に近づいているかを読み取ってください。

技術的課題は、売上増加や業務効率化ではなく、情報処理・制御・データ品質・セキュリティ等の課題として定義する必要があります。次の表は、事業課題を技術的課題へ置き換える際の候補を示します。各行では、明細書上の効果測定につなげやすいかを確認してください。

たとえば「AIで契約書をレビューする」という表現は、業務支援の説明にとどまります。これを、条項候補の埋め込み表現と社内標準条項の階層的インデックスを照合し、類似条項の検索範囲を動的に制限して検索遅延を抑制する情報処理方法として整理できれば、技術的課題、技術的手段、技術的効果が見えやすくなります。

AI・ソフトウェア発明は、特許適格性を満たしても、進歩性や記載要件で拒絶されることがあります。従来のルールベース処理を機械学習に置き換えただけ、周知のCNN、RNN、Transformer、勾配ブースティング等を適用しただけ、既存業務にAIを適用しただけ、特徴量や前処理が周知である、精度向上の効果が明細書から確認できない、といった拒絶理由が想定されます。

次の一覧は、適格性の入口を越えた後に問題になりやすい要件を整理したものです。重要なのは、出願時点で各要件への説明材料を同時に準備することです。どの要件が、実施例、比較データ、用語定義、請求項範囲の調整に結びつくかを読み取ってください。

海外展開では、日本、欧州、米国で判断枠組みが異なります。次の比較表は、各地域の中心概念と明細書戦略を示します。読者にとって重要なのは、日本で通じる説明がそのまま欧州・米国で通じるとは限らない点です。各地域で、技術的貢献、実用的応用、コンピュータ機能改善をどのように言語化するかを読み取ってください。

欧州では、AI・機械学習のモデルやアルゴリズムは、技術的課題の解決に貢献する場合に技術的性格を持ち得ます。心臓モニタリング、画像・音声・信号等の技術的データ処理は説明しやすい一方、テキスト内容に基づく文書分類は技術性が弱いとされやすい領域です。米国では、AIモデル、数学的処理、データ分類、業務自動化が抽象的アイデアとして問題になり得る一方、コンピュータ機能の改善、具体的な技術分野での実用的応用、装置制御、データ処理技術の改善として構成できれば主張しやすくなります。

AI・ソフトウェア特許が成立しても、侵害訴訟や無効審判で発明該当性が争われる可能性があります。特に、ビジネス方法、金融処理、広告配信、契約管理、人事評価、文書分類などでは、被疑侵害者が人為的取り決め、抽象的アイデア、単なる情報処理と主張することが考えられます。

次の一覧は、出願段階から残しておくと有用な記録を整理したものです。重要なのは、紛争になってから技術的効果を作るのでは遅い場合がある点です。各項目から、開発・知財・法務・情報システムが平時に保存すべき証拠を読み取ってください。

AI・ソフトウェア紛争では、内部処理が見えにくいという問題があります。クラウドサービスやブラックボックスAIでは、被疑侵害システムのデータ構造、モデル処理、推論手順、ログ、API呼出しを外部から確認しにくいため、請求項作成段階から、外部から観察できる入力・出力、ログやUIから推認できる処理、API仕様に現れる特徴、装置制御や表示結果に現れる特徴、実施主体が単一か複数か、顧客側操作を構成要件に含めるかを検討します。

次の時系列は、平時から紛争時までの証拠管理の流れを示します。読者にとって重要なのは、開発記録、秘密管理、アクセスログ、退職者・外注先対応、証拠保全の手順がつながっていないと、紛争時に技術的主張を支えにくい点です。順番に、どの部門がどの記録を整えるかを読み取ってください。

Q1. AIアルゴリズムそのものは特許になりますか。

一般的には、アルゴリズムそのもの、数学的手法そのもの、抽象的なモデル構造そのものは、特許適格性を満たしにくいとされています。ただし、特定の技術的課題を解決するために、コンピュータ上で具体的に実現された情報処理方法、装置、プログラム、制御方法として記載できる場合は、特許の対象となる可能性があります。具体的な出願方針は、技術内容、請求項案、先行技術、実施例を整理したうえで弁理士・弁護士等の専門家へ相談する必要があります。

Q2. 学習済みモデルを請求項に書けますか。

一般的には、学習済みモデルを請求項に含める余地はあります。ただし、モデルがプログラムとして理解できるのか、どの入力に対してどの出力を行うのか、技術的用途が何か、明細書で十分に説明されているかによって結論が変わる可能性があります。具体的な記載方法は、モデル構造、実施形態、出力用途、評価データを整理して専門家に確認する必要があります。

Q3. 生成AIのプロンプトは特許になりますか。

一般的には、プロンプト文そのものは、人間の言語的指示や業務手順に近く、特許適格性を支えにくいとされています。ただし、プロンプト生成、検索、検証、権限制御、外部ツール呼出し、ログ制御、推論最適化などを含む具体的な情報処理方法として構成できる場合は、特許対象となる可能性があります。具体的には、技術的課題と処理構成を整理したうえで専門家へ相談する必要があります。

Q4. ビジネス方法をAIで自動化した場合は特許になりますか。

一般的には、AIで自動化しただけでは足りないとされています。業務ルール、人為的取り決め、経済的判断をコンピュータで実行するだけでは、特許適格性が弱くなる可能性があります。ただし、計算量削減、リアルタイム処理、セキュリティ、データ構造、システム制御などの技術的課題に結びつく場合は評価が変わり得ます。具体的な見通しは、請求項案と明細書案をもとに専門家へ確認する必要があります。

Q5. 明細書にソースコードを書く必要がありますか。

一般的には、ソースコードそのものを書く必要はないとされています。ただし、当業者が発明を実施できる程度に、処理手順、データ構造、モデル構成、入出力、評価方法を記載する必要があります。ソースコードを秘匿したい場合でも、実施可能要件を満たす説明が必要になるため、開示範囲は営業秘密管理とあわせて専門家へ確認する必要があります。

Q6. AIが発明を考えた場合、AIを発明者にできますか。

一般的には、日本法・米国法を含め、多くの制度ではAIシステム自体を発明者として扱うことには慎重または否定的な立場が取られています。もっとも、AI支援研究では、自然人の研究者・開発者がどのように発明の完成に寄与したかの記録が重要になります。具体的な発明者認定は、研究記録、プロンプト・出力ログ、実験経緯、寄与内容により変わる可能性があるため、専門家に確認する必要があります。

Q7. 出願すべきか、営業秘密にすべきか迷います。

一般的には、製品からリバースエンジニアリングされやすい技術、競合が独自実装しやすい技術、ライセンス価値がある技術は特許出願に向きやすいとされています。一方で、モデル重み、学習データ、評価ノウハウ、運用ノウハウなど外部から見えにくく秘密管理できるものは営業秘密に向きやすい場合があります。ただし、営業秘密は漏えい時の救済や独自開発者への対抗に限界があるため、技術内容と管理体制を整理して専門家へ相談する必要があります。

実務例を見ると、同じAI利用でも、技術的文脈と具体的情報処理があるかどうかで特許適格性の見え方が変わります。次の比較一覧は、営業支援AI、製造設備の異常検知AI、契約書レビューAIを並べたものです。重要なのは、業務の自動化ではなく、技術的課題をどこに置くかです。各例から、弱い表現をどの方向に改善できるかを読み取ってください。

もっとも、法的リスク判定そのものは、人間の法的判断や業務ルールに近い領域です。契約書レビューAIを特許化する場合でも、請求項の中心を、検索、分類、照合、マスキング、出力検証、ログ制御などの技術的情報処理に置く必要があります。

AI・ソフトウェア発明の特許適格性は、「AIだから特許になる」「ソフトウェアだから特許にならない」という単純な問題ではありません。日本法上は、請求項全体として自然法則を利用した技術的思想の創作といえるかが出発点です。ソフトウェア関連発明では、ソフトウェアによる情報処理がハードウェア資源を用いて具体的に実現されているか、または機器制御・対象物の技術的性質に基づく処理として説明できるかが重要です。

AI関連発明では、モデル名や「AIを用いる」という表現ではなく、学習データ、特徴量、モデル構造、推論処理、出力の技術的利用、評価結果、技術的効果を具体的に記載する必要があります。生成AI、RAG、プロンプト、AIエージェントの時代でも、この基本は変わりません。

企業法務にとって、AI・ソフトウェア発明の特許適格性は、特許出願部門だけの問題ではありません。契約、データ、OSS、職務発明、共同研究、営業秘密、FTO、M&A、訴訟、内部統制、海外展開を含む総合的な企業リスク管理の問題です。

最後に確認すべき問いは、そのAI・ソフトウェア発明が、単なる業務上のアイデアではなく、技術的課題を、具体的な情報処理手段により解決しているかという点です。この問いに、請求項、明細書、実施例、評価データ、契約、社内記録のすべてで一貫して答えられる状態を作ることが、実務上の核心です。