.png?width=500&height=250&name=%E7%9F%A5%E7%9A%84%E8%B2%A1%E7%94%A3%E4%BA%8B%E5%8B%99%E6%89%80%E3%82%A8%E3%83%9C%E3%83%AA%E3%82%AF%E3%82%B9%20(500%20%C3%97%20250%20px).png)
リード：「ビジネスモデルは特許にならない」——この通説は半分だけ正しい...
AIサービスの特許出願チェックリスト｜学習データ・モデル・プロンプト・出力、どのレイヤーを権利化するかを弁理士が解説
リード：AIサービスの特許は「どのレイヤーを守るか」で考える
「AIを使ったサービスを作ったが、何が特許になるのか分からない」——この問いに一言で答えるなら、AIサービスは単一の発明ではなく、レイヤーの積み重ねだということです。学習データ、モデルと訓練方法、推論の入出力（プロンプト・出力）、そしてサービスへの組み込み。レイヤーごとに「特許で守れるか」「秘匿すべきか」「そもそも権利にならないか」の答えが違います。本記事は、当ブログで蓄積してきたAI特許解説（特許庁のAI審査事例、Anthropic・OpenAI・NVIDIA等の実特許・出願分析）を1枚のチェックリストに集約した総合ガイド（ハブ記事）です。
この記事の要点
- AIサービスの知財は5レイヤー（学習データ／モデル／プロンプト／組み込み／出力物）で考える。レイヤーごとに答えが違う
- 学習データは秘匿、モデル・訓練の工夫と組み込みの非自明なデータ選択は特許が基本線
- 落とし穴は2つ：AI予測だけの物は原則権利化不可（審査事例51・52）、発明者は自然人のみ（DABUS事件）
目次
1. 全体マップ：AIサービスの5レイヤーと守り方
| レイヤー | 守り方の第一候補 | 鍵になる論点 |
|---|---|---|
| ①学習データ・特徴量 | 秘匿（営業秘密） | データ自体は特許にならない。令和7年指針改訂で営業秘密保護が明確化 |
| ②モデル・訓練方法 | 特許（方法・プログラム） | 訓練の工夫・アーキテクチャは権利化の中心。ただし侵害検知性に注意 |
| ③プロンプト・入出力処理 | 特許（構成次第） | プロンプト文字列自体は×。生成・制御の仕組みは○（登録例あり） |
| ④サービス組み込み（UI・業務適用） | 特許 | 「単なるAI適用」を超える入力データの選択・構成の工夫が進歩性の核 |
| ⑤AIの出力物（物・コンテンツ） | 要注意 | AI予測だけの物は実施例なしでは原則特許不可。発明者は自然人のみ |
2. レイヤー①学習データ：特許ではなく「秘匿」の主戦場
データそのもの（データセット）は「情報の単なる提示」であり特許の対象になりません（特許庁のAI審査事例の整理）。一方で、収集・整備に投資した学習データはAIサービスの競争力の本体です。守り方は営業秘密としての秘匿が基本で、経産省の営業秘密管理指針（令和7年3月改訂）は、公知情報の組合せでも取得に相当の時間・費用を要するAI学習用データの非公知性が認められ得ることを明確化しました。外部提供するデータには限定提供データ（不正競争防止法）という受け皿もあります。詳しくは特許か秘匿かの使い分け記事へ。
3. レイヤー②モデル・訓練方法：AI企業の権利化の中心
モデルのアーキテクチャや訓練方法の工夫は、AI企業の出願の中心です。実例は当ブログの特許分析シリーズで多数検証してきました：AnthropicのAIエージェント特許（US 12,566,913）、同Computer Use特許、OpenAIの動画学習特許（VPT）、同マルチエージェント特許、NVIDIAのAIガードレール出願、Salesforceのマルチエージェント出願など。日本でもPFNのニューラルネットワークポテンシャル訓練特許（MI×AI特許の記事で検証）が好例です。留意点は侵害検知性で、訓練方法のクレームは他社サーバー内の実施を立証しにくいため、出力・API挙動・製品仕様に現れる特徴とセットで権利化する設計が要ります。
4. レイヤー③プロンプト・入出力：権利になる形とならない形
プロンプトの文言そのものは著作物性・営業秘密の問題であって特許の対象ではありません。特許になるのはプロンプトを生成・最適化・制御する仕組みです。日本では「プロンプトからプログラムを生成する」技術が特許第7564601号として登録されており（解説記事）、特許庁のAI審査事例38（プロンプト生成）も権利化の型を示しています（事例38の解説・国内プロンプト特許の事例調査）。チャットボット・対話系の権利化ポイントはチャット機能・AIボットの特許事例集にまとめています。
5. レイヤー④サービス組み込み：進歩性の主戦場
既存業務にAIを当てはめるタイプの発明で問われるのが進歩性です。特許庁のAI審査事例は、既存の推定業務を汎用の機械学習でシステム化しただけでは進歩性なし（事例33）、一方で相関関係が技術常識でなかった入力データを加えて顕著な効果を得た場合は進歩性あり（事例34）という基準を示しています。つまりこのレイヤーの発明の核は、アルゴリズムの新しさではなく「ドメイン知識に基づく入力データ・特徴量の非自明な選択」です。審査基準の全体像はAIエージェント技術の出願解説・日米欧の事例比較を、業務ツール系の具体論は生成AI業務効率化ツールの記事をご覧ください。ハードウェアと絡む場合はフィジカルAIの特許戦略も参考になります。
6. レイヤー⑤AIの出力物：物・コンテンツ・発明者問題
2つの落とし穴：①AIが「この物質・配合が良い」と予測しただけの物の発明は、AIの予測が実測に代わり得ると認められる例外的な場合を除き、実際に製造・評価した実施例がなければ記載要件を満たしません（特許庁AI審査事例51・52。出願後の実験データ提出では治癒しません）。②発明者として記載できるのは自然人のみです（DABUS事件：知財高裁令和7年1月30日ほか）。「AIが発明した」という整理ではなく、課題設定・データ選択・検証に創作的に関与した人間を発明者として特定してください。
この論点の詳細（MIの逆設計を題材にした事例52の分析）はMI×AI特許の記事で、生成AI利用時の権利関係の全体像は生成AIと特許の解説記事で扱っています。
7. 特許庁「AI審査事例」主要8事例の早見表
特許庁の「AI関連技術に関する特許審査の事例」（計25事例）のうち、AIサービスの実務で参照頻度の高い8事例を、結論ベースで一覧化しました（審査ハンドブック附属書掲載の設例に基づく要約です）。
| 事例 | 題材 | 結論の要点 |
|---|---|---|
| 事例3-2 | 糖度データと予測方法 | データそのものは「情報の単なる提示」で発明非該当。予測方法はソフトウエアの情報処理として実現されていれば該当 |
| 事例33 | がんレベル算出装置 | 医師の推定業務を単にシステム化しただけでは進歩性なし |
| 事例34 | 水力発電量の推定 | 回帰→NNの置き換えだけは進歩性なし。相関が技術常識でなかった入力データの追加＋顕著な効果があれば進歩性あり（AI発明の進歩性の核心） |
| 事例37・38 | 生成AIの回答生成／プロンプト生成 | 事例37: 質問文を単にLLMに入力して回答を自動生成するだけでは進歩性なし。事例38: 参考情報の単純な付加は進歩性なし、関連文章からのキーワード抽出等の工夫を特定した構成は進歩性あり（令和6年3月追加。事例38の詳細解説） |
| 事例50 | アレルギー発症率予測 | 記述子（入力データ）を特定しない広い予測方法クレームはサポート要件・実施可能要件違反。検証済みの記述子3種の組合せに加え、対象（アレルギーの種類）も検証済みの範囲に限定して初めて適法 |
| 事例51 | 嫌気性接着剤の配合 | AIが予測しただけの数値限定組成物は実施可能・サポート要件違反。出願後の実験成績証明書でも治癒しない |
| 事例52 | 蛍光発光性化合物（逆設計） | 実測済みの化合物のクレームのみ適法。予測のみの化合物・特性だけの包括クレームは違反（MI実務の核心。詳細解説） |
8. 日米欧でどう違う？──AI・ソフトウェア特許の三極比較
AIサービスの海外展開を見据えるなら、三極の判断枠組みの違いを押さえておく価値があります。
| 法域 | 判断枠組み | 実務上の含意 |
|---|---|---|
| 日本（JPO） | ソフトウエアとハードウエア資源の「協働」基準（審査ハンドブック附属書B） | 処理主体と入出力の具体化で比較的通しやすい |
| 米国（USPTO） | §101のAlice2ステップ（抽象的アイデア＝数学的概念・人間活動の組織化・精神的プロセスに当たるか→実用的応用への統合があるか） | 汎用コンピュータでの実装だけでは不十分とされ得る。ビジネス色の強いAI発明は日本より厳しい場面がある |
| 欧州（EPO） | プログラム"as such"は除外、「さらなる技術的効果」があれば対象。進歩性では非技術的特徴を算入しないCOMVIKアプローチ | ビジネス的な工夫は進歩性の根拠にならない。技術的効果の主張が必須 |
三極に共通して効くのは、処理負荷の軽減・通信量の削減・応答性の向上といった「技術的効果」をクレームと明細書に書き込むことです（この整理は各庁の公表基準を踏まえた実務上の一般論です）。日米欧の具体的な特許・出願例の比較はAIエージェントの日米欧事例解説をご覧ください。
9. 出願前チェックリスト（保存版）
- □ 5レイヤーのどこに自社の競争力があるか仕分けしたか（データは秘匿・仕組みは特許が基本線）
- □ 「入力データ・特徴量の選択」に、技術常識でない工夫と効果があるか（事例34の型）
- □ 訓練方法・内部処理のクレームに、外から検知できる特徴（出力・挙動・UI）を併せて立てたか
- □ AIの予測結果を物としてクレームする場合、実測の実施例を用意したか（事例51・52）
- □ 発明者（自然人）を特定し、学習データの権利処理・営業秘密管理と矛盾がないか
- □ リリース・論文発表・デモの前に出願日を確保するスケジュールか（出願の流れ）
10. よくある質問（FAQ）
Q1. 既存のLLM（GPT・Claude等）のAPIを使ったサービスでも特許は取れますか？
A. 取れる可能性があります。モデル自体が他社のものでも、レイヤー③（プロンプトの生成・制御の仕組み）やレイヤー④（業務への組み込みにおける非自明な入力データの選択・前処理・後処理）に自社の発明が宿ります。「APIを呼んでいるだけ」に見えるサービスでも、呼ぶ前後の処理に工夫があれば検討の価値があります。
Q2. ファインチューニングした自社モデルは特許で守れますか？
A. モデルのパラメータそのものは特許の対象になじまず、守れるのは「訓練方法・データ処理の仕組み」です。パラメータや学習済みモデルの実体は営業秘密（レイヤー①の考え方）で守るのが基本で、特許と秘匿の組合せになります。
Q3. 生成AIで書いたコードやアイデアをもとに出願しても大丈夫ですか？
A. 大丈夫です。ただし発明者として記載できるのは、課題設定・構成の選択・検証に創作的に関与した自然人です。AIの出力をそのまま出願するのではなく、人間による発明の特定と検証のプロセスを残しておくことが重要です（生成AIと特許の解説）。
Q4. RAG（検索拡張生成）の構成は特許になりますか？
A. 一般的なRAG構成そのものは既に広く知られていますが、検索対象の絞り込み方・ドメイン固有のインデックス設計・回答の検証機構など、課題に応じた具体的な工夫には権利化の余地があります。事例34の考え方（非自明な入力データの選択＋顕著な効果）がそのまま当てはまる領域です。
AIサービスのレイヤー診断（初回相談）：サービス概要と「どのレイヤーが強みか」の仮説をお送りいただければ、権利化候補と秘匿すべき範囲の初期見解をご案内します。知財事務所エボリクスのお問い合わせフォームよりどうぞ。
この記事の監修
弁理士 杉浦健文（日本弁理士会 登録第19446号／知的財産事務所EVORIX）。IT・ソフトウェア・AI分野の特許出願を中心に扱い、AI関連発明の特許化をテーマとするセミナー講師の実績があります。審査事例・判決の記載は特許庁・裁判所等の公表資料を確認のうえ記載しています。
【免責事項】本記事は2026年7月18日時点の特許庁公表資料（AI関連技術に関する特許審査の事例ほか）・公開特許情報・公刊の判決情報に基づく一般的な解説であり、法的助言ではありません（2026年7月19日増補）。早見表・三極比較は公表基準の要約・実務上の一般的な整理であり、個別の判断に代わるものではありません。リンク先の各記事の免責事項もあわせてご参照ください。
