AIエージェントからオンチェーン権限境界へ：ERC-8004は何を変えようとしているのか？

DeFi、アカウント抽象化、AIエージェントなどのアプリケーションの発展に伴い、オンチェーン承認は、単発の署名確認から、長期間有効で繰り返し使用可能な実行権限へと徐々に進化しています。同時に、新しい変化も起きています：AIエージェントはすでに、サービスを自動的にリクエストし、支払いを自動的に完了する能力を持ち始めており、例えばx402プロトコルはHTTP 402ステータスコードを通じて、エージェントが人間の介入なしに、安定したコインでリソースやサービスの即時支払いを可能にしています。これにより、オンチェーンでの行動はもはや孤立した取引ではなく、継続的に実行される自動化された協調プロセスとなっています。

このような背景の中で、承認の問題はさらに拡大しています。現在のWeb3システムにおける承認方法は、依然として境界が曖昧で表現が粗く、資産が使えるかどうかしか解決せず、具体的に何を許可するのか、どの程度まで許可するのかという問いに答えることは困難です。ERC-8004はまさにこのような背景で提案されました。それは新しい資産を定義するものでも、取引や支払いの実行方法を変えるものでもなく、オンチェーンでの行動に対してシステムが理解し検証可能な権限モデルを構築しようとする試みであり、承認そのものを記述可能で、制約可能で、管理可能な対象にしようとしています。

より大きなシステムの視点から見ると、ERC-8004とアカウント抽象化やx402などの自動化支払いプロトコルは競合関係ではなく、異なるレイヤーでの分業協力関係にあります：x402は行動発生後の価値交換の問題を解決し、ERC-8004は行動が発生する前に、誰が行動を許可されているのか、権限が越権していないかどうかに焦点を当てています。DeFi、AIエージェント、そして企業やRWAなどのシナリオにおいて、この「権限先行、支払い後続」の構造は、承認を資産レベルから行動レベルへと進化させ、より複雑で長期的な自動化協力に制御可能な基盤を提供することが期待されています。学習コスト、ウォレットのサポート、ユーザーエクスペリエンスにおいて現実的な課題は残っていますが、ERC-8004は短期的なストーリーツールではなく、Web3が複雑なシステムの運用を担えるかどうかに関わる基盤的な標準です。

1. ERC-8004が提案された動機

オンチェーンインフラが絶えず進化するにつれ、資産のオンチェーン化と取引実行に関連する能力は継続的に抽象化され強化されています。ERC-20、NFTから、マルチシグウォレットとアカウント抽象化（ERC-4337）まで、ユーザーがオンチェーン活動に参加するハードルは下がり続け、アカウント自体もますますスマートになっています。

しかし、この進化の中で、一つの基本的な問題が体系的に解決されていません：承認メカニズム自体がほとんど実質的な進化を遂げていないのです。初期のWeb3では、承認は一度の秘密鍵署名を意味していました。ユーザーは署名を通じて「同意する」ことを表明し、送金、コントラクト呼び出し、あるいはapprove操作であれ、承認は単発の確認行為と見なされ、リスクの境界は完全にユーザー自身が負担していました。

しかし、今日のオンチェーン環境は変化しています。DeFiのシナリオでは、approveはしばしば長期間有効です。自動化戦略やSession Keyシステムの下では、承認は繰り返し使用されます。AIエージェントやBotが取引を実行するモードでは、ユーザーはもはや各操作に直接関与しません。承認は単発の確認から、継続的に存在する実行能力へと進化しており、むしろ、あることを行う権限を一時的に委譲することに似ています。

問題は、現在のWeb3のインフラが、このような長期的な承認状態に対して、明確で統一された制約方法をほとんど提供していないことです。権限範囲の曖昧さ、承認の取り消しの難しさ、リスクの予測不可能さが、多くのセキュリティインシデントの源となっています。同時に、アカウント抽象化はこの矛盾をさらに拡大しています：アカウントが取引を自動実行し、サードパーティがGasを支払う場合、それが具体的に何をできて、何ができないのかが、かえって不明確になっています。

まさにこのような背景の中で、ERC-8004は提案されました。それは、Web3が長らく欠けていた一環を補おうとするものです：承認そのものに対して、明確で、制約可能で、システムが理解可能な権限モデルを構築することです。

2. ERC-8004の核心的内容

ERC-8004のアプローチは、資産の形態や取引の実行方法ではなく、承認が単独で記述され、独立して検証され、システムレベルで継続的に管理できるかどうかにあります。

2.1 ERC-8004は何を定義しているのか？

Ethereum Improvement Proposals（EIP）公式サイトの定義によると：ERC-8004は、イーサリアム上で信頼できる自律エージェント（autonomous agents）を発見、選択、相互作用するための標準プロトコルです。それは、オンチェーン登録、評判、検証メカニズムを通じて、事前の信頼なしに分散型で相互作用できるエージェントインフラを構築します。

ここでの自律エージェントは、AIエージェントに限定されず、承認可能で、独立して行動を実行できるあらゆる主体、例えばコントラクト、自動化スクリプト、マルチシグ、サービスプロセスなどを指します。ERC-8004が注目するのは、実行主体が明確な承認と権限の境界を持つ能力を備えているかどうかであり、AIエージェントはその典型的な応用例の一つに過ぎません。

より一般的な視点から見ると、ERC-8004は新しい資産標準やアカウントタイプではなく、ある主体がどのような条件下でどのような行動を実行することを許可されているかを記述し、操作前に検証するための、オンチェーン権限表現と検証のフレームワークです。したがって、ERC-8004が注目するのは「お金が何か」や「取引がどのように実行されるか」ではなく、「どのような行動が許可されているか」です。それは新しい資産を作成したり、既存の資産属性を変更したりするものではなく、資産とアカウントの上に、明確で検証可能な権限ルールのレイヤーを追加するだけです。

さらに、ERC-8004はアカウント抽象化（ERC-4337）の代替ではありません。アカウント抽象化は取引がどのように実行されるかに注目し、ERC-8004は取引が発生する前の権限判断を解決します。アカウント抽象化がアカウントをより柔軟にするならば、ERC-8004はその柔軟性に明確な境界を設定します。

ERC-8004の核心は、承認を署名に暗黙的に含まれる動作から、明確に記述可能で、独立して検証可能で、継続的に管理可能な権限オブジェクトへと変えることにあります。

2.2 ERC-8004の核心的メカニズムフレームワーク

ERC-8004の核心メカニズムを理解するには、複雑な技術実装を一旦置いて、「オンチェーン権限説明書」として理解することができます。従来の承認ロジックでは、ユーザーはしばしば漠然とした決定を下します：「私はあなたが私の資産を操作することを許可します。」具体的に何ができるのか、どれだけできるのか、どのくらいの期間できるのかについては、システムはそれ以上区別しません。一方、ERC-8004のフレームワークでは、一度の承認はもはや曖昧な同意ではなく、明確に記述可能で、システムによって強制実行される一連のルールに分解されます。この「権限説明書」は通常、以下の5種類の重要な情報を含みます。

承認主体（Who）：誰が実行を許可されているのか？

まず明確にするのは、誰が実行権限を付与されているかです。ERC-8004では、承認される対象は固定のウォレットアドレスに限定されず、コントラクト、自律エージェント、さらには短期操作のためのSession Keyも可能です。これにより、承認はより多くの複雑なシナリオに適応できます。例えば、特定の戦略コントラクトに限定された範囲内で操作を実行させたり、エージェントが繰り返し署名することなく特定のタスクを完了させたりすることができます。重要なのは、権限は常に「ある明確な主体」に付与され、曖昧に委譲されるわけではないことです。

実行可能な行動（What）：どのような操作が許可されているのか？

次に、どのような行動の実行が許可されているかです。従来の承認はしばしば全か無かであり、一度承認されると、デフォルトでコントラクトは権限の範囲内で自由に呼び出し可能となります。一方、ERC-8004の設計では、承認は具体的な行動タイプ、例えばswapやtransferのみの実行、または特定の種類の関数呼び出しのみに限定することができ、デフォルトですべての可能な操作を開放するわけではありません。ERC-8004が答えるのは「使えるかどうか」ではなく、「どこまで使えるか」です。

制約条件（Under what conditions）：どのような条件下でのみ実行可能か？

これはERC-8004が従来の承認と異なる重要な部分です。権限説明書では、承認には通常明確な制限条件が付随します。例えば、単一または累積の金額上限、実行頻度または回数制限、特定のプロトコル、プール、またはコントラクトアドレスにのみ適用可能などです。これらの条件は事後の監視ルールではなく、実行前に満たされなければならない前提条件です。条件が成立しない場合、操作自体が実行できなくなります。

有効化・無効化ルール（When）：権限はいつ成立し、いつ終了するのか？

ERC-8004はまた、明確な時間とライフサイクルの概念を導入しています。承認は以下のように設定できます：（a）特定の時間帯のみ有効、（b）一度使用すると自動的に無効、（c）いつでも取り消し可能。これにより、承認は一度与えたら取り戻せない長期的な負担ではなく、細かく管理可能な一時的な能力となります。

検証方法（How enforced）：ルールはどのように実際に実行されるのか？

最後に、そして最も見落とされがちな点：これらのルールはどのように実行されるのかです。ERC-8004の核心思想は、操作が発生する前に権限検証を行うことです。ある行動が事前に定義された権限ルールに適合しない場合、システムは問題が発生した後で責任を追及するのではなく、直接実行を拒否します。これこそが、ERC-8004と従来のリスク管理ロジックの根本的な違いです。

2.3 ERC-8004が追加する能力タイプ：以前はなぜできなかったのか？

表面的には、ERC-8004は承認をより詳細化するだけのように見えますが、初期のイーサリアム承認モデルは実際には複雑な承認ロジックを表現できませんでした。従来の承認は、あるアドレスが操作を許可されているかどうかをチェックするだけで、一度承認が通ると、何ができるのか、どれだけできるのか、いつできるのかは、システムが認識できませんでした。

ERC-8004の核心的ブレークスルーは、承認を「身元判断」から「行動判断」へとアップグレードしたことにあります。システムは、誰が開始したかを確認するだけでなく、ある操作がユーザーが設定した権限の境界に適合しているかどうかを判断し始めます。これにより、承認には金額、頻度、範囲、有効期限などの条件が自然に含まれ、ユーザーが事後に取り消したり、人間が監視したりする必要がなくなります。

承認ロジックが構造化されると、それは初めて組み合わせ可能で再利用可能な能力を備えます。多段階、クロスプロトコルの操作は、実行時に臨時判断に任せるのではなく、承認段階で明確に制限することができます。まさにこのため、ERC-8004は真にエージェントシナリオに道を開きます。自動化プログラムはもはや「無制限の承認」を必要とせず、明確で検証可能な行動範囲内に制限され、境界を越えれば実行が拒否されます。

ERC-8004が追加するのは、単純な「より安全な承認」ではなく、承認ロジックをシステムが理解し実行可能にすることであり、これが従来の承認メカニズムとの本質的な違いです。

3. ERC-8004の潜在的な応用方向

ERC-8004は、特定の具体的な製品のために設計された標準ではなく、承認能力の汎用言語のようなものです。したがって、その応用価値は、単一シナリオでの爆発的な普及には現れず、複数のシステムが承認の複雑化に伴い、同じ種類の能力に対する共通の需要に現れます。

DeFi：「資産レベルの承認」から「行動レベルの承認」へ

現在のDeFiシステムでは、最も一般的な承認方法は依然として「一度の承認、無制限の額」です。例えば、ユーザーが一度のswap、借入、またはステーキングを行うために、まずコントラクトに対してapproveを行う必要があり、本質的には資産のコントロール権を丸ごと委譲しています。これは体験上は非常に効率的ですが、リスクも直感的です：コントラクトがアップグレードされたり、攻撃されたり、ユーザーが想定していないロジックに使用されたりすると、承認自体がリスク増幅器となります。ERC-8004が承認する対象はもはや資産ではなく、具体的な行動です。例えば、ユーザーは要求できます：このコントラクトが私のUSDCを無制限に使用することを許可するのではなく、24時間以内に、1,000 USDCを超えない範囲で、一度のswap操作を完了することを許可する。一部のプロジェクトはすでに承認の範囲と期間を制限しようと試みていますが、現在はほとんどが独自路線です。ERC-8004の価値は、行動レベルの承認を標準化し、再利用可能で組み合わせ可能な権限管理を実現し、根本的にリスク管理能力を向上させることにあります。

AIエージェント：自動化実行に検証可能な権限境界を提供

AIエージェントが徐々にオンチェーンでの意思決定と実行に参加するにつれ、承認問題は新たなレベルに拡大されています。エージェントの価値は継続的な実行と自動実行にありますが、これは同時に、