執筆・文責：弁理士　中村幸雄

AIが「答える」から「実行する」へ

AIエージェントは、単に文章を生成するだけではありません。

ユーザの依頼を複数のタスクに分解し、必要なツールを選択し、外部APIを呼び出し、処理結果を見て次の判断を行う。人への確認が必要な場面では処理を止め、失敗した場合には別の手順に切り替える。

こうした「処理を進めるAI」において、発明のポイントはどこにあるのでしょうか。

結論からいえば、AIが生成する文章そのものではなく、タスク分解・ツール選択・承認フロー・実行権限・失敗時リカバリーといった実行設計にポイントがあります。

AIエージェントをめぐっては、OpenAIも、 Agents SDK において、ツール、handoff、guardrails、構造化出力などを含む開発枠組みを示しています。 本稿では、こうした技術動向を踏まえつつ、特許の観点からどこに発明のポイントが現れるかを整理します。

タスク分解：依頼を処理単位に分ける

たとえば「来週の候補日を探して、相手に日程調整メールを送ってください」という依頼を考えます。単なる文章生成なら、メール文案を作るだけです。しかしAIエージェントとして処理する場合、次のような流れになります。

  1. 依頼内容の解析
  2. カレンダーの確認・空き時間の抽出
  3. 相手との関係や過去のやり取りを踏まえた文面生成
  4. 送信前の確認要否の判定
  5. 必要であれば人への確認依頼
  6. 承認後のメール送信・実行ログの記録

発明の手がかりは「AIがメール文を作ること」だけにあるのではなく、依頼をどの処理単位に分解し、どの順番で処理し、どこで外部システムを呼び出し、どこで人の確認を挟むかにあります。

マルチエージェント：複数エージェントが連携するとき

AIエージェントの設計が進むと、ひとつのAIがすべてを処理するのではなく、役割の異なる複数のエージェントを組み合わせることがあります。たとえば、調査を担うエージェント、判断を担うエージェント、実行を担うエージェントを分け、それぞれの結果を受け渡しながら処理を進める構成です。

こうした構成では、単一エージェントにはない設計上の課題が発生します。

重要なのは、「複数のエージェントを使っている」という構成そのものではありません。どの条件でタスクを振り分けるか、エージェント間の結果をどう検証して次に渡すか、全体の処理をどう制御・記録するか——この連携設計に、発明の手がかりが現れます。

特に、あるエージェントの出力を別のエージェントが検証してから次の処理に進む構成や、並列処理と逐次処理を業務状態に応じて切り替える構成は、単一エージェントでは設計する必要のない課題です。その制御の仕方に、発明として成立できる余地があります。

ツール選択：単なる外部接続ではない

AIエージェントは、業務状態に応じてカレンダー・CRM・会計システム・契約管理システムなど多様なツールを選択しながら処理を進めます。重要なのは「外部APIと連携している」という事実ではありません。

外部ツールとの接続については、Anthropicが提唱した Model Context Protocol（MCP） のように、AIアプリケーションと外部データソース・ツールを接続するための標準化も進んでいます。 もっとも、特許の観点では「接続している」こと自体よりも、どの条件でツールを選び、結果を次の処理にどう渡すかが重要になります。

どの条件で、どのツールを選び、どの順序で呼び出し、その結果を次の処理にどう渡すか——この部分に、発明の手がかりがあります。

たとえば顧客対応エージェントであれば、こうした設計が考えられます。

「AIを使った顧客対応」というだけでは輪郭が曖昧なままです。ツール選択条件・処理順序・実行可否の判定・承認フローまで整理されて初めて、発明の輪郭が見えてきます。

自動実行と人への確認の切り分け

AIエージェントが業務に入り込むほど重要になるのが、どこまで自動で実行し、どこから人に戻すかという設計です。

自動化しやすい処理（候補日の抽出、下書きの作成、定型通知など）と、人の確認を挟むべき処理（外部へのメール送信、顧客情報の変更、発注・決済、後戻りが難しい操作など）を明確に分けることが必要です。

発明として整理するなら、一般論ではなく具体的な条件設計が問われます。

AIが進める部分と人が判断すべき部分を適切に切り分ける設計——そこに実務上の価値があり、具体的な情報処理として設計されていれば、特許の検討対象となります。

実行権限：「見る権限」から「実行する権限」へ

AIエージェントが実際に処理を実行する場合、問われるのは「誰がどの情報を見られるか」ではなく、誰の権限で、どの処理を、どこまで実行できるかです。

この権限管理は単なるアクセス制御ではなく、AIエージェントの実行範囲そのものを制御する設計です。ユーザ属性・業務状態・対象データの種類に応じて実行可否が動的に変わる構成は、発明として整理できる可能性があります。

失敗時リカバリー：止まり方・戻り方・再実行の設計

処理が常に予定どおり進むとは限りません。外部APIの失敗、情報不足、権限不足、矛盾する結果——こうした場面でAIエージェントがどう振る舞うかは、信頼性に直結します。

失敗時の選択肢は単純なエラー終了だけではありません。

どこで止めるか、どこまで戻すか、どの情報を人に示すか、再実行時にどの条件を変更するか——このリカバリー設計は、エラー検出・状態管理・分岐制御・再実行条件・ログ記録と結びつきます。発明の手がかりは成功時の処理だけでなく、失敗時の立て直し方にも現れます。

実行ログ：判断の構造を残す

AIエージェントが業務処理を実行する以上、後から検証できることも重要です。なぜそのツールを選んだのか、誰の承認を得たのか、どの時点で処理が失敗したのか——これらが記録できなければ、運用は不安定になります。

実行ログは単なる記録ではなく、AIエージェントの処理を検証・改善・説明するための基盤です。次のような設計に、工夫の余地があります。

特にBtoBのAI SaaSや業務向けエージェントでは、この監査性が大きな価値になります。ログ設計の工夫にも、発明の手がかりは現れます。

AI関連発明については、特許庁も AI関連技術に関する特許審査の事例 を公開しています。 AIエージェントについても、「AIを使っているか」ではなく、どのような具体的な情報処理によって課題を解決しているかを整理することが重要です。

発明を整理するための5つの問い

# 問い 確認する内容
1 何を実行するのか？ 回答か、外部システムの操作か、業務フローの実行か
2 処理はどう分解されているか？ 依頼がどの処理単位に分かれ、どの順序で並ぶか
3 どの条件でツールを選ぶか？ どの情報を見て、どのAPIを選び、結果を次にどう渡すか
4 どこで人に確認を求めるか？ 金額・送信先・リスク・権限・不確実性に応じた条件
5 失敗時にどうリカバリーするか？ 停止・再質問・別ルート・差し戻し・再実行の条件

よくある質問

Q AIエージェントなら特許になりやすいですか？

そうとは限りません。どのような課題を、どのような処理フロー・判断条件・実行制御によって解決しているかが重要です。

Q 外部APIを呼び出すだけで特許になりますか？

通常は困難でしょう。ただし、選択条件・失敗時の切り替え・実行前の承認・後続処理への反映に工夫があれば対象になり得ます。

Q 複数のAIエージェントを組み合わせるだけで特許になりますか？

複数のエージェントを使うこと自体で特許になるわけではありません。どの条件でタスクを振り分けるか、エージェント間で処理結果をどう受け渡すか、失敗時にどのように停止・差し戻し・再実行するか、といった連携設計が問われます。

Q 人への確認を求める仕組みは、運用であって技術ではないのでは？

単なる運用ルールは技術と呼べないかもしれません。しかし、処理対象・金額・権限・不確実性・過去履歴に基づいて確認要否をシステムが判定し、処理を停止・差し戻し・再開するのであれば、情報処理として特許を取得できる可能性はあります。

Q AIモデルを自社開発していなくても検討できますか？

できます。外部AIモデルやAPIを利用していても、タスク分解・ツール選択・実行制御・承認フロー・リカバリーなど、自社サービス側の設計に特徴があれば検討対象になります。

発明は「AIが何を答えるか」ではなく「どう実行するか」に宿る

AIエージェント時代の発明は、「AIが何を答えるか」だけにあるのではありません。

AIがどの順序で判断し、どの処理を実行し、どこで人に戻し、失敗時にどう立て直すか。

タスク分解、マルチエージェント連携、ツール選択、承認フロー、実行権限、失敗時リカバリー、実行ログ——現場の業務を理解し、AI・外部ツール・人の判断をどう接続するか。その設計の中に、発明の手がかりがあります。

「まだ整理できていない」「どこが発明なのかわからない」という段階でも構いません。発明の余白では、AIエージェントの発明の本質を、事業・開発フローも踏まえながら一緒に整理しています。

執筆・文責

弁理士　中村幸雄

AIサービス、ソフトウェア、業務フロー、試作・現場改善に関する発明整理・特許相談を扱う弁理士。 「発明の余白」では、まだ曖昧な技術構想や現場の工夫を、発明のポイントとして整理するための情報を発信しています。