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

ブログ

Date:2026年2月16日 | Category:

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

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

Date:2026年2月14日 | Category:

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

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

 

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

 

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

 

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

Date:2026年2月13日 | Category:

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

 

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

 

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

特許第77311144号公報(特許権者:株式会社RAYVEN)

 

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

 

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

 

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

 

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

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

 

Date:2026年2月12日 | Category:

生成AIを用いた特許を検索すると、出願日と特許公報発行日との間の日柄が短くなっており、早期審査請求のケースが多いように感じます(当然かと)。

 

最近、「AIエージェント」という言葉も流行ってきており、特許公報における請求項にも多く記載されるようになってきました。
生成AI(大規模言語モデル)は、受動的に指示されたテキストを生成するものであるのに対し、「AIエージェント」とは、能動的に複数のAIを連携して稼働させる指揮者です。

 

しかしながら、検索された特許公報に記載されたAIエージェントとは、既存の生成AIを、単に「AIエージェント」と記載したに過ぎないものが多いように読めます。

 

一方で、AIエージェントの本質とは、「オーケストレータ」にあると考えています。
ここで、「AIエージェント」&「オーケストレーション(またはオーケストレータ、オーケストラ)」をキーワードとして特許公報を検索すると、現時点で全くヒットしませんでした。但し、特許出願自体は、既に多くされていると思います。

 

AIエージェントとは、生成AIのような単なる応答マシンではなく、特定の目標を達成するために「自ら計画を立て、環境を認識し、外部ツールを使用して行動する」自律的なエンティティです。即ち、ビジネスモデルを構築するために、「オーケストレータ」をどのように設定するか?が重要となってきていると考えています。

オーケストレータを言語化せよ!

 

AIエージェントのオーケストレータに対するプロンプトは、単一の生成AIへの指示(シングルプロンプト)とは異なり、「何を答えるか」という指示から、「どのように問題を分解し、誰に解決させるか」というマネジメントの指示となります。以下のように例えば複数のプロンプトに分類されます。

 

  • システム・メタプロンプト
    全体挙動を規定する最上位の指示(役割定義、制約事項、停止条件)
  • エージェント定義プロンプト
    エージェント毎の個別指示(例えばペルソナ指示、スキル指示、出力形式)
  • プランニング・推論プロンプト
    ワークフロー(思考プロセス、条件分岐)
  • ツール・定義
    外部ツールに対する機能説明・引数指定

 

特徴あるビジネスモデルを、AIエージェントに対する言語化をすることによって、複数のAIを連携させるシステムに対して特許性が認められる可能性もあります。

Date:2026年2月10日 | Category:

IT分野については、1件の特許出願をすればよい、という感じではありません。市場動向や自社の開発状況を見ながら、戦略的な分割出願が「攻め」と「守り」の両面で不可欠となってきてきます。
現在、IT分野における日本の特許出願全体の中で、分割出願は、約15%~20%に達しているようです。

 

以下では、分割出願のメリットを列挙します。

  1.  IT製品の「進化」と特許の「ズレ」を解消する
    IT製品のアップデートの速さに応じて、親出願における権利範囲を、シフトさせたり、広げたり、調整したりすることができます。
  2.  競合他社への対策
    特許が成立(登録)してしまうと、その権利範囲は固定されます。自社の権利範囲をできる限り長期に渡って不安定な状態(審査中の状態)におくことは、競合他社に対する牽制となります。
    例えば自社サービスを模倣してきた競合他社に対して、その構成をピンポイントでカバーするように権利範囲を修正して特許を取得することもできます。
  3. 「広い権利」へのチャレンジ
    親出願について拒絶理由通知を受けて、独立請求項に係る発明を、従属請求項aに係る発明に限定しなければならない場合があります。このとき、分割出願では、独立請求項に係る発明を、明細書に記載された他の構成要素を付加した広い権利範囲で再度、出願することができます。希望する場合もあります。
    (1)まずは、認められた権利範囲でサクッと特許を取得し、早期に「特許保有」の実績を作る。
    (2)同時に、分割出願を行い、認められなかった「広い範囲」や「別の角度からの権利」について、粘り強く審査官と交渉を続ける。

カテゴリー

アーカイブス

このページのトップへ