情報技術専攻 早原特許技術事務所

Date：2026年2月18日 ｜ Category：ＩＴ特許Q＆A

自社事業のために生成ＡＩを利用する場合、プロンプトにおける特許性の有無を検討することは、非常に重要です。
「プロンプトなんて特許にならない」と思い込む前に、ダメ元で一度、弁理士とディスカッションすることも必要かもしれません。

 

プロンプトには、一般的に以下の項目を記載することが好ましいとされています。

1. 役割定義
2. 知識データの提供
3. 出力形式の指定
4. 思考プロセスの指示
5. 制約条件・禁止条件の指定

 

ここで検討するのは、自社事業・自社サービスに照らして、特有な条件を設定しているか否か、にあります。

1. 役割定義
   特許性を見出すのは難しいように思えます。
2. 知識データの提供
   例えばＲＡＧ（検索拡張生成）のような知識データについて、自社事業に合わせて、どのような情報を、どのようなデータ形式で利用するか、を検討する必要があります。
3. 出力形式の指定
   一般的なJSONなどではなく、自社事業に合わせてどのようなデータ形式へ加工するか、を検討する必要があります。
4. 思考プロセスの指示
   一般的なステップバイステップではなく、ＡＩエージェントも考慮して、自社事業に合わせたＣｏＴ（Chain of Thought）の論理的ステップを指示しているか、を検討する必要があります。
5. 制約条件・禁止条件の指定
   出力情報や思考プロセスについて、自社事業に合わせた制約や禁止する条件があるか、を検討する必要があります。

Date：2026年2月17日 ｜ Category：ＩＴ特許Q＆A

現在、ユーザは、５Ｇ／６Ｇ／無線ネットワーク／光ネットワークのような次世代通信インフラを介して、人工知能としての生成ＡＩにアクセスし、様々な知識を得ることができるようになってきました。
しかしながら、ＡＩとネットワークとが融合した技術までは、まだ十分に発展してきていないと思います。
これからは、ＡＩに何を掛けるか？（ＡＩ×？）を競う時代になってくると思われます。
その代表的なものとして、「ＡＩ×ネットワーク」があり、例えば「ＡＩ駆動型ネットワーク」や「ＡＩ分散ネットワーク」のような新たな技術領域が、特許出願の主戦場となってくると思われます。

 

この融合領域で勝つための特許戦略について、発明抽出の観点を考えてみました。

1.  狙うのは「境界線」にある
   ＡＩとネットワークとを結びつける接点部分に、工夫した点が有るか否かを検討してください。
   第１に、ＡＩから見た、ネットワークにおける訓練（学習）データ、対象（入力）データ、プロンプト、通信制御を検討することができます。
   第２に、ネットワークから見た、ＡＩの分散協調を検討することがきます。
2. エッジＡＩ
   全てを大規模なＬＬＭで処理するのではなく、階層化された末端のエッジ（縁）ＡＩの挙動を検討することできます。
   エッジＡＩは、端末に近いエッジでＡＩ処理を実行するものであって、リアルタイム性とプライバシー保護を両立させることが鍵となります。
3. ＡＩネットワーク・オーケストレータ
   ＡＩによって、通信トラフィックに応じた制御をワークフロー（例えば動的リソース割当て）を記述したプロンプトを、複数のＡＩを連携させるオーケストレータに指示します。
   このとき、各ＡＩが、ネットワークの各要素を制御するものであり、オーケストレータのワークフローに従って、ネットワーク全体が制御されるような技術です。
4. ＡＩモデルの分散化
   ＡＩモデルを１か所の生成ＡＩに収集させて訓練することなく、ネットワーク上にあえてモデルの更新値のみを分散させて共有するような技術も想定できます。

従来、ビジネスモデルの特許明細書は、「如何に概念的に書いて、具体的に書かないか」を追求されているような気がします。
概念的に含めることが、訴訟に強いと思われていることが、一理あるのかもしれません。
日本では、そのようなビジネスモデル特許思考が強すぎるように思います。
一方で、特に米国のＡＩ企業の特許明細書は、かなり技術的に深く記載した明細書が多いように感じます。

個人的には、ＡＩ×ネットワークにおける「技術的根拠」を、明細書の中で明確に言語化する必要があると思っています。

Date：2026年2月16日 ｜ Category：ＩＴ特許Q＆A

ＡＩエージェントは、バックエンドで自律的に機能するために、法的な注意点が生じると考えています。
利用者側は、サービス提供者側に対して、「ＡＩエージェントによって生成・実行された回答情報やプロセスが、第三者の知的財産権を侵害しないこと」の保証を求めると思われます。

1. サービス提供者側は、「ユーザのプロンプト（指示）に起因する場合は免責とする」ことを契約書に記載する必要があります。例えば「Ａ社の特許技術を参考にして効率化した技術を提案して」のような、侵害を誘発するような指示を明確に禁止する必要があります。但し、この「起因」に基づく責任の切り分けは難しいです。
2. サービス提供者側は、例えばＲＡＧ（検索拡張生成）の場合、知識データが、適切なライセンス（パブリックドメイン）に基づくものであること保証する必要もあります。
3. サービス提供者側は、ＡＩエージェントの予測不能な挙動に対して、損害賠償額の上限額も設定した上で、ユーザと契約する必要もあります。
4. サービス提供者側は、ＡＩエージェントが使用する外部ツールやライブラリ、参照先を、法的に確認済みのものだけに制限する必要もあります。例えばホワイトリスト／ブラックリストを設定したものであってもよいかもしれません。
5. サービス提供者側は、ＡＩエージェントが出力する回答情報が、知的財産権の侵害の有無を推論する判定プロセスを設けることも必要かもしれません。侵害の可能性が高い場合、「警告」を出して、その実行をブロックする必要もあります。
6. サービス提供者側は、ＡＩエージェントのワークフローによって複数のＡＩを連携させる中で、強制的に人間の承認を介在させることで、不用意な挙動を防止することができます。このとき、人間の承認を介在させたログを残すことも必要です。

Date：2026年2月14日 ｜ Category：ＩＴ特許Q＆A

ＡＩを利用した特許出願では、請求項を概念的に広く書きすぎるがあまり、記載不備の拒絶理由通知（36条4項1号（実施可能要件）、36条6項1号（サポート要件））を受けることも多いです。

ＡＩエンジンに関しては、「Ａを入力してＢを出力するモデル」を明確にする必要があります。
重要なことは、「当業者（ＩＴエンジニア）から見て、実装できる程度の記載」にあります。

 

モデルが事前学習済みの既存の生成ＡＩ（ＬＬＭ）である場合、明細書は、「どのようなプロンプト（入力情報）を入力し、どのような結果（出力情報）を得るのか」を明確に記載する必要があります。
「プロンプトも、最低限の具体的な事例は記載すべき」と考えています。
プロンプトとしては、指示文のみならず、最低限の役割定義、例示、制約条件についても、記載しておくのがいいと思います。

 

また、既存の生成ＡＩの場合、モデル内のアルゴリズムを明確に記載できない以上、具体的に利用したモデル名（例えばGPT-4、Claude 3.5 Sonnet（登録商標）など）も記載した方がよいと考えています。
当業者が「その性能や特性」を前提とした追試（再現）をしやすくするためです。

 

図面は、抽象的な概念図に留めず、ソフトウェアとハードウェアとの連携を一体的に記載することが好ましいと考えています。
また、図面では最低限、機能部の間の連携について、入出力（矢印）を明確にする必要があると考えています。
このとき、端末側の「ユーザインターフェース」と、バックエンドの「ＡＩエンジン」とを明確に区別したネットワーク構成図が必要と思います。
また、訓練を要するＡＩエンジンに対しては、教師データによる訓練段階と、対象データによる推論段階とを明確に区別すべきです。

Date：2026年2月13日 ｜ Category：ＩＴ特許Q＆A

ＡＩエージェントにおける複数のＡＩ間の連携に、ＭＣＰ(Model Context Protocol)（Anthropic）が注目されています。
ＭＣＰに関する特許を取得することは、＝「ＡＩエージェントのインフラを握る」ことにつながります。

 

ＭＣＰとは、ＬＬＭ（大規模言語モデル）がローカルデータや外部ツールに安全かつ簡単にアクセスするための共通規格です。
従来、ツール毎にＡＰＩを用意する必要がありましたが、ＭＣＰという「共通のコンセント」を通すことで、ＡＩエージェントの連携拡張性を向上させたものです。

 

ここで、１件の特許公報を発見しました。

特許第77311144号公報（特許権者：株式会社RAYVEN）

 

この特許は、「ＭＣＰホストの権限を、ユーザ端末のＧＵＩ上で視覚的に設定する」というものです。意外と簡易です。
これによって、ユーザは、ＧＵＩで、ＭＣＰホストの「どの権限を許可するか」を選択できるようにしたものです。

 

一見、ＧＵＩ設定なんて「当たり前じゃん」と思わると思います。
しかしながら、この特許は、ＭＣＰのみに限定して、これ以外に権利範囲を及ぼすものとなっていません。
「ＭＣＰとして限定的に狭く、且つ、ＭＣＰを採用するＡＩ全てを対象として将来的に広く」権利を設定したように感じます。

 

生成ＡＩやＡＩエージェントの内部構造では、日本では周回遅れとなっていますが、これらＡＩを取り巻く「インフラ制御」や「ユーザインタフェース」を特許で抑えることは、ビジネスモデルも含めて重要となってきます。

 

ＡＩサービスを提供する会社は、「ＭＣＰはオープン規格だから自由に使える」と考えるのではなく、その実装方法やユーザインタフェースには、他社の特許が網を張っている可能性もあります。
例えば以下のような３点を確認してみることも重要です。

1. 競合他社サービスにおけるユーザインタフェース
2. ＡＩエージェント（ＭＣＰなど）の特許の確認（既に多数出願済み）
3. 自社独自の工夫部分を確認し、カウンターとなる特許出願の検討