ERC-8211 徹底解説:AIエージェントに「取引前に考える力」を与えるEthereum標準規格
DeFiボットに「自分のWETHを全てUSDCにスワップし、Aaveに供給して。ただし最終残高が5,000ドル以上を維持する場合に限る」と指示する場面を想像してください。現在、この指示を実行するには開発者が署名前にすべてのパラメータをハードコードする必要があります — 正確なWETH残高、予想されるUSDC出力量、Aaveへの預入額 — そのため、署名されたブロックとオンチェーンに着地するブロックの間で市場状況が変化した瞬間に失敗する脆弱なトランザクションが生まれます。2026年4月6日にBiconomyとEthereum Foundationによって公開されたERC-8211は、この脆弱性を完全に排除します。AIエージェントがライブのチェーン状態を読み取り、条件を検証し、複数ステップの戦略を単一のアトミックトランザクションで実行できる初のEthereum標準規格です — 静的なバッチコールをインテリジェントな自己調整型ワークフローに変えます。
このタイミングは 偶然ではありません。Virtuals Protocolだけで17,000以上のAIエージェントが稼働しています。CoinbaseのAgentKitは複数のLLMプロバイダーにまたがる自律型ウォレットを支えています。NEARの共同創設者は「ブロックチェーンのユーザーはAIエージェントになる」と宣言しています。しかし、これまでエージェントは、フロントエンドのボタンをクリックする人間向けに設計された同じ硬直的なトランザクション形式でDeFiとやり取りすることを余儀なくされてきました。ERC-8211は根本的に異なるものを提供します:実行時にオンチェーンで意思決定を構成する能力と、組み込みの安全ガードレールです。
課題:静的バッチングは自律エージェント向けに作られていなかった
Multicall3やERC-4337バンドラーのようなマルチコールコントラクトは、複数のトランザクションを一つにまとめることを可能にしています。しかし、すべてのパラメータは署名時に固定されなければなりません。AIエージェントが2.5 WETHをUSDCにスワップしてその収益をAaveに供給するバッチに署名した場合、2.5 WETHという数値は固定されます — たとえ保留中の送金の到着や手数料控除により、署名と実行の間にエージェントの実際の残高が変化したとしてもです。
これは自律エージェントにとって3つの連鎖的な問題を引き起こします:
- 古い状態: バッチトランザクションがブロックに含まれる頃には、それが前提としていたオンチェーン状態はもはや有効でない可能性があります。0.3%の価格変動でスワップがリバートし、ガスを浪費して戦略が中途半端に実行されたままになることがあります。
- 過剰な事前指定: エージェントは署名前にすべての中間値(正確な出力量、スリッページ閾値、預入量)を事前計算しなければなりません。5ステップのレバレッジループでは、5つの連続した出力を予測することを意味し、そのどれか一つが残りすべてを無効にし得ます。
- 条件ロジックの欠如: 静的バッチはオール・オア・ナッシングです。「ステップ2の結果が閾値を超えた場合のみステップ3を進める」という表現方法がありません。エージェントはバッチ自体の中で安全制約を表現できないのです。
その結果、今日のAIエージェントは印刷された搭乗券と同程度の柔軟性でDeFi戦略を実行しています — すべての詳細が出発前に正しくなければならず、変更があれば最初からやり直す必要があります。
ERC-8211の仕組み:Fetcher、Constraint、Predicate
ERC-8211はBiconomyが「スマートバッチング」と呼 ぶものを導入します — バッチ内の各パラメータがその値をどのように取得するか、そしてその値が満たすべき条件を宣言するコントラクトレイヤーのエンコーディング標準です。この標準は3つのプリミティブで構築されています:
Fetcher
すべての入力パラメータは、署名時ではなく実行時にその値がどのようにソースされるかを決定するfetcherタイプを持ちます。3つのfetcherタイプが利用可能です:
- RAW_BYTES: 値はハードコードされ、従来のバッチングと同じです。
- STATIC_CALL: 値はライブのオンチェーンコントラクトコールから読み取られます — 残高の確認、オラクル価格の照会、プールのリザーブの読み取りなどです。
- BALANCE: 値は実行時点での実行アカウントのネイティブトークンまたはERC-20残高です。
ルーティング先は、解決された値の送り先を決定します:コールのターゲットアドレス、value フィールド、またはcalldataです。
Constraint
すべての解決された値にはインライン制約を付与できます — コールが進む前にオンチェーンで検証される論理チェックです。サポートされる制約タイプには、EQ(等しい)、GTE(以上)、LTE(以下)、IN(集合への所属)があります。いずれか の制約が失敗すると、バッチ全体がアトミックにリバートします。
実際には、エージェントは次のように表現できます:「自分のWETH残高を取得し(BALANCE fetcher)、1.0 WETH以上であることを確認し(constraint)、解決された値をスワップのcalldataに渡す(routing)。」
Predicate
target = address(0) のエントリは、純粋なアサーションチェックポイントとして機能します。これらはチェーン状態に対するブール条件をエンコードします — 例えば、レバレッジループ後にウォレットのUSDC残高が安全下限を上回っていることを検証する — 外部コールを実行せずにです。predicateが失敗すると、バッチはリバートします。
これら3つのプリミティブが組み合わさることで、バッチは静的なスクリプトからリアクティブなプログラムに変わります:「自分のWETH残高全額をUSDCにスワップし、到着した分をそのままAaveに供給する。ただし、最終残高が安全下限を超える場合のみ。」すべてが1つのトランザクション内で、すべてが実行時に解決されます。
台頭するエージェントプロトコルスタック
ERC-8211は単独で存在するものではありません。Ethereum Foundationが自律エージェント向けに構築してきた、ますます一貫性を持つプロトコルスタックに組み込まれます:
| レイヤー | 標準規格 | 機能 | 主要ビルダー |
|---|---|---|---|
| アイデンティティ | ERC-8004 | エージェントの発見、信頼、レピュテーションスコアリング | Ethereum Foundation |
| コマース | ERC-8183 | ジョブライフサイクル管理 — エスクロー、納品証明、決済 | Virtuals Protocol |
| 実行 | ERC-8211 | スマートバッチング — 条件付き、状態認識型のオンチェーン実行 | Biconomy |
| 決済 | x402 | エージェントサービスのためのHTTPネイティブなステーブルコインマイクロペイメント | Coinbase + Cloudflare |
この類推は偶然ではありません:ERC-8004は誰がトランザクションしているかを識別し、ERC-8183はどのような仕事が交換されているかを管理し、ERC-8211はその仕事がオンチェーンでどのように実行されるかを処理し、x402はエージェント間の支払いの流れを管理します。これらを合わせて、業界のオブザーバーが「オンチェーンAIのTCP/IPモーメント」と呼び始めているものを形成します — 各プロトコルが一つの関心事をクリーンに処理するレイヤードスタックです。
ERC-8183は特に補完的です。そのJobプリミティブ — クライアントエージェントがプロバイダーエージェントを雇い、エスクローされた資金が保持され、評価者が納品を証明する — は、まさにERC-8211が実行するために設計された種類のマルチステップで条件付きのオンチェーンアクションを生成します 。ERC-8183を通じてジョブを受け入れるAIエージェントは、仕事の遂行の一環として一連のDeFi操作(スワップ、供給、借入)を実行する必要があるかもしれません。ERC-8211は、ジョブの受諾と実行の間に市場状況が変化しても、それらの操作が正しく実行されることを保証します。
競合するアプローチ:AgentKit、NEAR Chain Signatures、そして断片化リスク
ERC-8211のスマートバッチングは、AIエージェントの標準実行レイヤーとなることを目指す唯一のフレームワークではありません:
Coinbase AgentKit は、OpenAI、Anthropic、Llamaモデルをネイティブサポートし、AIエージェント向けのウォレットインフラストラクチャとオンチェーンアクションプリミティブを提供します。2026年3月、World(Sam Altmanのアイデンティティプロジェクト)がx402決済とWorld ID検証を備えたAgentKit統合をローンチし、エージェントが人間による裏付けの暗号学的証明を携帯できるようにしました。AgentKitはウォレット管理とシンプルなトランザクションに優れていますが、ERC-8211が提供する条件付きの状態認識型実行は現時点では提供していません。
NEAR Chain Signatures は異なるアーキテクチャアプローチを取ります:エージェントは自身のNEARアカウントを取得し、秘密鍵はTrusted Execution Environment(TEE)に保管され、Chain Signatures技術を通じて、単一のNEARベースのアイデンティティから任意のブロックチェーン — Ethereum、Bitcoin、Solana — 上のトランザクションに署名できます。これはマルチチェーンの問題をエレガントに解決しますが、実行セマンティクスレイヤーではなくインフラストラクチャレイヤーで動作します。
VisaのTrusted Agent Protocol と GoogleのAP2(Agent Payment Protocol 2.0) は、決済とマーチャント検証の側面に取り組み、従来のコマースがAIエージェントのトランザクションを認識し処理できるようにします。これらはERC-8211のオンチェーン実行に対する焦点を補完するものであり、競合するものではありません。
断片化リスクは現実のものです。AgentKitが独自の条件付き実行プリミティブを構築したり、NEARが競合するバッチ実行標準を開発したりすれば、エージェントは初期のDeFiを悩ませたのと同じ相互運用性の課題に直面する可能性があります — 同じ問題を解決する複数の標準が存在し、どれもクリティカルマスに達しないという状況です。ERC-8211の優位性は、既存のアカウント抽象化インフラストラクチャ(ERC-4337、ERC-7683)との互換性と、その最小限のフットプリントにあります:プロトコルフォークも、新しいオペコードも不要で、あらゆるスマートアカウント実装で動作します。