定義
自律型エージェントは、各ステップごとに人の確認を受けずに、目標を決めて一連のアクションを実行することで、その目標を追求するソフトウェアです。現代のエージェントは言語モデルを使って計画を立て、ツールを呼び出し、結果を読み取り、調整します。通常は人または組織が目標と境界を定め、その間の作業をエージェントが担います。
actor intelligence において、自律型エージェントは Agent クラスに対応します。つまり、その相互作用は、各アクションを人が指示するのではなく、自動化から始まっています。各クラスの違いについては Human, AI-assisted or agent: a practical taxonomy for application traffic を参照してください。
エージェントと他の自動化の比較
- Scripts and crawlers は固定された指示に従います。予測しやすく、範囲も限定的です。
- 自律型エージェント は適応します。アプリケーションの返答を読み取り、次に何をするかを選びます。そのため、自動化を前提に設計されていない app の領域に到達することがあります。
- AI-assisted people は AI を補助として使いますが、制御は人が保ちます。詳細は AI-assisted interaction を参照してください。
自律型エージェントがアプリケーション所有者にとって重要な理由
エージェントは、実際の顧客の代理としてますます行動しています。たとえば、製品の比較、ドキュメントの収集、チケットの起票、データの同期、API の呼び出しなどです。こうした相互作用の多くは有用です。デフォルトでそれらを遮断するアプリケーションは、正当な利用を失う可能性があります。一方で、それらを人間とまったく同じように扱うアプリケーションは、振る舞いが大きく異なる参加者に対して機微な操作を公開してしまうおそれがあります。
あらゆるエージェントの相互作用について、有用な問いは次のとおりです。
- これはどのエージェントか? HTTP message signature (RFC 9421) のような検証可能な identity があるのか、それとも自己申告だけなのか。
- 何をしてよいのか? identity は権限ではありません。これは authorization の問題です。
- その背後にいるのは誰か? 人がエージェントに delegated authority を与えている場合もあれば、エージェントが組織のために動いている場合もあります。identity の証拠だけでは delegation は立証できません。
- このアクションの影響は何か? 公開カタログの閲覧とアカウント設定の変更では、求められる制御が異なります。
自律型エージェントを見分ける方法
認識には、強さの異なる証拠を組み合わせます。公開された operator からの検証済み署名は強い証拠です。申告された client 名は有用ですが、模倣される可能性があります。行動パターンやプロトコルのパターンは推論を支えることができます。これらのどれでも十分でない場合、正しい答えは推測ではなく Unknown です。
エージェントを適切に扱うには
エージェントのトラフィックを前提とするアプリケーションでは、次のような対応がよく見られます。
- 一般的な読み取り操作向けに、構造化された API または機械可読な応答を提供する。
- 自動化された呼び出し元に適した、route レベルの rate limit を適用する。
- 影響の大きいアクションには、より強い資格情報または明示的な user 承認を求める（designing app-level policies for humans and AI agents を参照）。
- 人間向けページは高速に保ち、自動化向けの challenge を避ける。
よくある誤解
"Agents are bots, and bots are bad." 多くのエージェントは顧客のツールです。目的は、反射的に遮断することではなく、適切な体験を提供することです。
"A verified agent can do anything its account can." Verification は client を識別します。アクションを許可するものではありません。
Proof of Actor におけるエージェントの扱い
Proof of Actor は、エージェントの相互作用を、明示的な basis (verified、declared、または inferred) とともに Agent として分類します。これにより、署名された operator と自己申告のものを、policy で別々に扱えます。各 route で何を許可するかは、あなたが決めます。詳細は APIs と MCP servers の use case、または apply for early access を参照してください。
参考文献
- RFC 9421: HTTP Message Signatures: 自動化された client のための検証可能な identity
- IETF Web Bot Auth working group: bot とエージェントの認証に関する標準化作業