.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エージェントがパソコンを「使う」時代が到来しました。その先頭を走るのがAnthropicの「Computer Use」（Claudeが画面を見てマウス・キーボードを操作する機能）です。そして、この機能を技術的に支えるのが、本記事で徹底解説する米国登録特許US 12,430,150 B1です。
本記事では、AI知財に精通した弁理士が、この特許の全クレーム構成・技術アーキテクチャ・明細書の工夫を、原文を引用しながら一件深掘りで解説します。「Computer Use型のエージェントを自社開発しているが、どこが権利化のポイントなのか」を知りたい開発者・知財担当者の方は必読です。
💡 要点：本記事は、AIエージェント特許シリーズの「個別特許 深掘り編」です。Anthropicの特許戦略全体の分析は「Anthropicの特許戦略を読み解く」を、基礎要件は基礎編をご覧ください。
目次
30秒サマリー｜この特許は何を守るのか
● 何の特許か：AIエージェントがマルチモーダル・インターフェースを自動操作するためのランタイム・アーキテクチャ（実行時の処理基盤）。
● 誰の特許か：Anthropic PBC（Claudeの開発元）。
● ステータス：米国登録特許（2025年9月30日登録、全20クレーム）。
● 中核アイデア：エージェント仕様 →（サーバ側で）中間表現 → エージェント呼び出し → 作動関数 → 作動コマンド、という多段変換でUI操作を自動化する。
● 対応製品：Anthropic「Computer Use」（2024年10月発表）。
● 誰の特許か：Anthropic PBC（Claudeの開発元）。
● ステータス：米国登録特許（2025年9月30日登録、全20クレーム）。
● 中核アイデア：エージェント仕様 →（サーバ側で）中間表現 → エージェント呼び出し → 作動関数 → 作動コマンド、という多段変換でUI操作を自動化する。
● 対応製品：Anthropic「Computer Use」（2024年10月発表）。
特許の基本情報
| 項目 | 内容 |
|---|---|
| 特許番号 | US 12,430,150 B1 |
| 発明の名称 | Runtime architecture for interfacing with agents to automate multimodal interface workflows |
| 登録日 | 2025年9月30日 |
| 出願日 | 2024年10月8日 |
| 優先日 | 2024年3月20日 |
| 出願人 | Anthropic PBC |
| 発明者 | Rohan Bavishi、Erich Elsen、Curtis Hawthorne ほか |
| クレーム数 | 20（独立3：クレーム1・14・20／従属17） |
| ステータス | 登録特許（granted） |
背景｜Anthropic「Computer Use」とは
「Computer Use」は、AIが人間と同じように画面を見て（スクリーンショットを認識し）、マウスを動かし、クリックし、文字を入力することで、あらゆるソフトウェアを操作できる技術です。従来のAPIを介した自動化とは異なり、UIそのものを操作するため、API非公開のアプリでも自動化できる点が画期的です。
本特許は、まさにこの「AIによるUI自動操作」を実行時（ランタイム）にどう成立させるかという基盤アーキテクチャを保護しています。アイデアではなく、それを動かす仕組みを権利化している点に注目してください。
技術アーキテクチャ｜クライアント／サーバ分担と中間表現
本特許の最大の特徴は、処理をクライアント側とサーバ側に分担させ、その間を「中間表現（intermediate representation）」という抽象化レイヤーでつなぐ構成です。全体の流れは次のとおりです。
【ランタイム処理フロー】 [クライアント側] ① エージェント仕様（agent specification）を構築 │ （ワークフローの自動化を規定） ▼ [サーバ側] ② エージェント仕様を「中間表現」へ翻訳 │ ▼ [クライアント側：ランタイム解釈ロジック] ③ 中間表現を受信 ④ 中間表現中の「エージェント機能」を検出 ⑤ エージェント機能から「エージェント呼び出し」を生成 ⑥ エージェント呼び出しをエージェントに発行 │ ▼ 応答 ⑦ エージェントから「ランタイム作動関数」を受信 ⑧ 作動関数を「ランタイム作動コマンド」に翻訳 │ ▼ ⑨ 作動コマンドが「機械作動アクション（合成アクション）」をトリガー → マルチモーダル・インターフェース・ワークフローを自動化
💡 要点：「中間表現（intermediate representation）」という抽象化レイヤーを挟むことで、エージェント仕様（何をしたいか）と、実際のUI作動コマンド（どう操作するか）を分離しています。これはコンパイラ設計に通じる発想で、単なる「AIにPCを操作させる」というアイデアを、具体的なソフトウェア・アーキテクチャへと昇華させています。
エージェント機能（agent function）の体系
明細書によれば、エージェントが呼び出せる「機能（agent function）」は複数の種類に体系化されています。これらは具体的な操作の語彙（ボキャブラリ）として、発明を支えています。
| 種別 | 機能の例（明細書記載） | 役割 |
|---|---|---|
| ビルトイン機能 | answerQuestionAboutScreen（画面に関する質問への回答）、click（クリック）、type（入力）、scroll（スクロール） | 基本的なUI操作・認識 |
| プランナー機能 | act（行動）、fillform（フォーム入力）、pickdate（日付選択） | 複数操作を束ねた高次のタスク |
| ワークフロー機能 | （ユーザー定義のワークフロー） | 業務固有の自動化単位 |
このように操作を関数として抽象化し、AIエージェントがそれらを組み合わせてタスクを遂行する構成は、従属クレーム（後述）でも具体的に押さえられています。
知覚ループ｜スクリーンショット・行動履歴・タスク記述
AIエージェントが「次に何をすべきか」を判断するには、現在の状況を知覚する必要があります。本特許の明細書では、観測ロジック（observation logic）が、以下をエージェントに供給すると記載されています。
| 観測情報 | 内容 |
|---|---|
| スクリーンショット | 現在の画面の視覚情報（マルチモーダル入力） |
| 行動履歴（action history） | これまでに実行した操作の履歴 |
| タスク記述（task description） | 達成すべきタスクの説明 |
「画面を見る → これまでの行動を踏まえる → 次の操作を決める」という知覚・行動ループ（perception-action loop）こそ、AIエージェントが「自律的」である根拠です。本特許はこのループを技術的に具体化しています。
クレーム構成｜独立3・従属17の全体像
本特許は全20クレームから成り、独立クレームを方法・システム・媒体の3カテゴリで立てる、ソフトウェア特許の王道構成をとります。
| クレーム | カテゴリ | 保護対象 | 想定侵害主体 |
|---|---|---|---|
| クレーム1 | システム（system） | プロセッサ上で動作するシステム | 装置を製造・使用・販売する者 |
| クレーム14 | コンピュータ実装方法（method） | 処理手順 | その方法を実施する者 |
| クレーム20 | 非一時的コンピュータ可読記憶媒体 | プログラムを記録した媒体 | プログラムを配布・提供する者 |
【クレームツリー】 ● クレーム1（システム・独立） └─ クレーム2〜13（従属：機能種別・観測ロジック・戻り値 等を限定） ● クレーム14（方法・独立） └─ クレーム15〜19（従属） ● クレーム20（媒体・独立）
従属クレーム（2〜13、15〜19）は、エージェント機能の種類、観測ロジック、戻り値などを具体的に限定し、独立クレームが万一無効とされても権利が残るよう、防御を重層化しています。
独立クレーム1（システム）を逐条で読む
権利化を支える3つの限定
| 限定 | 技術的意味 | 効いている理由 |
|---|---|---|
| 中間表現（intermediate representation）への翻訳 | 仕様と実行を分離する抽象化レイヤー | 抽象的アイデアからの脱却。アーキテクチャの具体性 |
| エージェント機能の検出・呼び出し生成 | 操作を関数化し動的に呼び出す | 制御ロジックの具体化。進歩性の主張点 |
| 作動関数→作動コマンドへの翻訳 | AIの判断を実際のUI操作へ変換 | 「画面を操作する」技術的実装の核心 |
独立クレーム14（方法）の妙｜エージェントは「サーバ側」
方法クレームであるクレーム14は、クレーム1とほぼ同一の処理を方法の形式で記載しますが、一点、重要な違いがあります。
クレーム1（システム）が単に「エージェントに発行（issue the agent calls to an agent）」と記載するのに対し、クレーム14（方法）と クレーム20（媒体）は「サーバ側のエージェントに発行（to an agent on the server-side）」と明示しています。
💡 要点：この違いは意図的なクレームドラフティングです。システムクレームはクライアント側装置のみを権利範囲とすることで、「クライアント側を実装する者」を広く捕捉します。一方、方法・媒体クレームは「サーバ側エージェント」との連携を明示し、分散システム全体の処理を捉えます。同じ発明を異なる切り口で重層的に保護する好例です。
弁理士の視点｜なぜ強い特許なのか
① 製品と一対一で対応している。「Computer Use」という実際の主力機能を直接守っており、事業上の価値が明確です。
② アイデアでなくアーキテクチャを権利化している。「AIがPCを操作する」という抽象論ではなく、中間表現・関数化・多段変換という具体的なソフトウェア構造として記載され、特許適格性が高い。
③ クレームの切り口が多層的。システム（クライアント側中心）・方法・媒体の3カテゴリに加え、システムクレームと方法クレームでエージェントの所在（サーバ側）の記載を変え、異なる侵害態様を捕捉しています。
日米欧の審査でどう評価されるか
米国（USPTO）
Alice/Mayoテストでは「抽象的アイデアか、発明的概念があるか」が問われます。本件は中間表現・エージェント呼び出し・作動コマンド翻訳という技術的実装を伴うため、「技術的課題（UIの自動操作）への技術的解決」を主張しやすく、現に登録されています。
日本（JPO）
「情報処理がハードウェア資源を用いて具体的に実現されているか」が基準です。プロセッサ上で動作するシステム、クライアント／サーバの分担、具体的なデータ変換が記載されており、ソフトウェア関連発明として特許適格性を満たしやすい構成です。進歩性は「中間表現による抽象化」「作動関数→コマンド変換」の技術的工夫が鍵となります。
欧州（EPO）
技術的貢献（COMVIK）が問われます。UI自動操作という技術的課題への、アーキテクチャ上の技術的解決と位置づけやすく、純粋なビジネス手法との評価を回避しやすい構成です。
AIエージェント特許の日米欧の審査実務の比較は、「日本・米国・欧州の特許事例と審査実務」で詳しく解説しています。
自社のエージェント開発への教訓
① 製品機能を直接守るクレームを書く。抽象的な上位概念だけでなく、自社製品の中核機能に対応する具体的構成を押さえる。
② アーキテクチャを言語化する。「中間表現」「観測ロジック」「作動コマンド」のように、システムの構成要素と処理の流れを技術用語で定義し、クレームに落とし込む。
③ 分散構成は「どこで何をするか」を記載し分ける。クライアント／サーバ／エージェントの役割分担を明示し、侵害主体ごとにクレームの切り口を変える。
④ 操作を関数化して網羅する。click・type・scroll等の操作語彙を従属クレームや明細書で具体化し、回避設計を困難にする。
自社のAIエージェント、特許になるか診断します。
IT・ソフトウェア・AI分野に精通した弁理士が、権利化可能性の無料診断、クレーム設計、FTO調査、日米欧での出願戦略までトータルでご支援します。
初回無料相談を予約IT・AI知財サービスよくある質問（FAQ）
Q. US 12,430,150 B1はどんな特許ですか？
A. Anthropic（アンソロピック）が保有する米国登録特許で、AIエージェントがマルチモーダル（画像＋テキスト）なユーザーインターフェースを自動操作するための「ランタイム・アーキテクチャ」を保護します。同社の「Computer Use（Claudeがパソコンを操作する機能）」に対応する中核特許で、2025年9月30日に登録されました。全20クレーム（独立3・従属17）から構成されます。
Q. この特許の独立クレームはいくつですか？
A. 3つです。クレーム1（システム）、クレーム14（コンピュータ実装方法）、クレーム20（非一時的コンピュータ可読記憶媒体）の3カテゴリで、ソフトウェア特許の定石どおり、異なる侵害主体を捕捉できるよう構成されています。
Q. 「クライアント側」と「サーバ側」を分けているのはなぜですか？
A. このアーキテクチャは、エージェント仕様の構築・中間表現の解釈・作動コマンドへの翻訳をクライアント側で行い、エージェント仕様の中間表現への翻訳やエージェント本体をサーバ側に置く分担構成です。重い推論をサーバ側のAIに任せ、UI操作の実行をクライアント側で担う、現実的な実装に即した構成であり、この具体性が特許適格性の確保に寄与しています。
Q. 日本企業がComputer Use型の技術で特許を取るには？
A. 「AIがPCを操作する」というアイデアではなく、本件のように①クライアント／サーバの役割分担、②中間表現という抽象化レイヤー、③エージェント呼び出し→作動関数→作動コマンドという多段変換、といった具体的なソフトウェア・アーキテクチャとして記載することが有効です。
Q. この特許に抵触しないか心配です。どうすればよいですか？
A. 本件は登録特許であり、実際の権利範囲は各クレームの文言と均等論、経過情報によって定まります。自社のエージェント技術が抵触するか否かの判断（FTO＝Freedom to Operate調査）は、クレーム解釈を要する専門的作業です。心配な場合は、IT・ソフトウェア分野に精通した弁理士にクレーム対比の検討をご依頼ください。
本記事の注意事項：本記事は、公開された特許公報に基づく一般的な技術・制度解説です。US 12,430,150 B1は登録特許ですが、実際の権利範囲は各クレームの文言・均等論・経過情報により定まります。引用したクレーム・要約・明細書記載は公開公報データ（FreePatentsOnline等）に基づきますが、法的に重要な用途（FTO・侵害分析・無効・出願等）では、必ずUSPTO正本と最新の経過情報をご確認のうえ、専門家の個別検討をご利用ください。日本語訳は理解のための参考訳であり、正文は英語原文です。
あわせて読みたい（AIエージェント特許シリーズ）：
・Anthropicの特許戦略を読み解く｜なぜ特許出願が少ないのか
・AIエージェント技術は特許出願できる？（基礎編）
・日本・米国・欧州の特許事例と審査実務（事例編）
・Salesforceのマルチエージェント特許を読み解く（個別解説編）
・Anthropicの特許戦略を読み解く｜なぜ特許出願が少ないのか
・AIエージェント技術は特許出願できる？（基礎編）
・日本・米国・欧州の特許事例と審査実務（事例編）
・Salesforceのマルチエージェント特許を読み解く（個別解説編）
出典
- US 12,430,150 B1（Google Patents）：https://patents.google.com/patent/US12430150B1/en
- クレーム・明細書（FreePatentsOnline）：https://www.freepatentsonline.com/12430150.html
