ERC-8211は、DeFiにおけるAIエージェントの動的実行を可能にすることを目的としています

2025年から、多くの人が新しいインタラクション方法に徐々に慣れていくでしょう。たとえば、「来週の香港旅行のスケジュールを立てて、適切な航空券とホテルをおすすめして」とGPTやGeminiに言うと、それらは裏で情報検索、条件フィルタリング、ルート選定、価格比較などの一連のプロセスを自動で実行し、最終的に結果だけをあなたに確認してもらいます。

しかし、同じ期待をチェーン上に持ち込むと、物語はまったく変わります。

たとえば、DeFi Agent に「ウォレット内の ETH を USDC に交換し、Base チェーンにクロスし、すべてを Aave に預ける」と指示した場合、客観的に見れば、今日の Agent は「要件の理解」と「パスの計画」の面では必ずしも不可能ではない。真の断絶は実行段階で生じる：

署名、承認、交換、クロスチェーン、デポジットなどの操作を段階的に完了する必要があり、各ステップはスリッページの変動、Gasの変動、ブリッジの遅延、チェーン上のステータス変化のリスクにさらされます。これにより、途中で1つでも予期しない事態が発生すると、これまでの操作を取り消せない可能性があり、次の操作も続かないため、チェーン上に残るのは未完了の中途半端なプロセスになることが多いです。

問題はAIが十分に賢くないことではなく、チェーン上の実行層がまだエージェントに真正に適した表現方法を欠いていることである。

そのため、2026年4月初頭、Biconomyとイーサリアム財団は、現在のスマートコントラクト実行における「静的制限」の問題を解決し、AIエージェントおよび複雑なDeFiワークフローにより表現力のある実行レイヤーを提供することを目的としてERC-8211を共同で発表しました。

過去1〜2年間、暗号資産業界の注目点は、L2スケーリングやRWA流動性から、AIエージェントがチェーン上操作を実際に支配するという画期的なテーマへと明確に移行しています。

客観的に見ると、「自然言語で複数ステップのDeFi戦略を実行する」から「自律エージェントがクロスチェーン投資ポートフォリオ全体を管理する」まで、最近多くの実践が見られ、自然言語による複数ステップのDeFi戦略生成、自律的なリバランス実行、自動収益移動、クロスチェーンポジション調整、さらにはより複雑なポートフォリオ管理まで、ほとんどの構想がデモレベルで成熟しています。

推論と編成の観点から見ると、AIの能力はすでに非常に速く進化しているが、実際に生産環境に導入した際、実行層の課題がますます明確になってきている。

本質的に本番環境に適用する場合、この短所は一言でまとめられます：DeFiは動的ですが、今日のほとんどのbatchは依然として静的です。

ERC-8211の公式サイトとディスカッション投稿では、既存のERC-4337とEIP-5792が、「1回の署名で1回の呼び出し」という従来のモデルを、「1回の署名で複数の呼び出しをバッチ処理」する新しい段階へと進化させたことが明確に説明されていますが、これらの呼び出しのパラメータは、本質的にまだ署名時の時点で固定されています。

つまり、ユーザーが署名時に入力した金額、目標値、予想出力は、実際の実行時にチェーン上の状態変化によって自動的に調整されることはありません。

DeFi自体がまさに不確実性に満ちている。スワップの実際の出力は、実行されるブロック内のスリッページと流動性に依存する。ブリッジの到着時間と最終到着額は、ブリッジ自体のメカニズムと手数料に依存する。貸借プロトコルやVaultのshare-to-asset比率も常に変化している。

結局、ユーザーまたはエージェントが署名時に見る数値は、多くの場合、実行時の実際の結果ではなく、その時点での推定値です。

ERC-8211が何を解決するかを理解するには、最も典型的な例を見てみましょう。たとえば、エージェントがアカウント内のETHをUSDCに交換し、その全額をSparkに預けて利子を得ようとするような、ごく普通の行動を想定します。

従来の静的バッチ処理モデルでは、エージェントは署名前にスワップ後に受け取るUSDCの額を予測しなければならず、これにより署名時に第二ステップの入力金額を事前に固定せざるを得ず、過大に見積もると実際の到着額が不足してバッチ全体がロールバックされ、過小に見積もると資金がウォレットに余剰として残り、利用できなくなります。

言い換えれば、失敗のリスクを負うか、機会損失を負うかの二択に陥る。そのため、看似単純なチェーン上のプロセスでも、ステップが5ステップ、8ステップ、あるいは複数のチェーンをまたぐと、一気に脆弱になる。これは戦略自体が説明できないほど複雑だからではなく、現在の実行パラダイムが事前に固定されたパラメータに過度に依存しているからである。

要するに、静的バッチの能力限界は、エージェントが実際に安全に実行できる戦略の上限を決定する。

この観点から見ると、ERC-8211 が解決しようとしているのは、AI Agent がどのように意思決定を行うかではなく、Agent がすでに意思決定を下した後、チェーン上でそれをより自然で安定かつ安全な方法で実行する手段があるかどうかです。これにより、チェーン上の実行が初めて AI Agent 用にネイティブに設計された表現形式を持つことになります。

ERC-8211の核心的な進歩は、より多くのステップを1回の署名に詰め込むことではなく、バッチ処理をパラメータが固定された交易列から、「実行時に動的に評価されるプログラム」へと昇格させたことです。

確かに抽象的に聞こえますが、理解するのは難しくありません。公式はこれを「From transactions to programs」と一言で説明しています。

これにより、ERC-8211 はバッチを順次実行されるアクションのリストではなく、実行時に評価され、セキュリティ条件を伴う実行プログラムと見なすようになります。具体的には、この仕組みは以下の3つの組み合わせ可能なプリミティブによって実現されています：

• Fetchers（取值器）：このパラメータの値をどこから取得するかを定義します。特定のアドレスの現在の残高を一度クエリすることで、パラメータは署名時のスナップショットではなく、実行瞬間にチェーン上の状態から取得するリアルタイムの読み取り値になります。
• 制約条件：パラメータが展開された後、インライン制約チェックを実行します——たとえば「取得するUSDCが2500以上であること」や「スリッページが0.5%を超えないこと」など、これらの制約は値が次の呼び出しにルーティングされる前に検証され、いずれかの条件を満たさない場合、バッチ全体が即座にロールバックされます；
• 述語（トリガー条件）：ステップ間のゲートキーパーとして機能し、値を生成するのではなく、実行を継続するかどうかを判断します。たとえば、クロスチェーンのシナリオでは、イーサリアム側のバッチは、「クロスチェーンで転送されたWETHが到着した」という条件を述語で監視し、到着するまで送信を保留できます。

この設計では、各パラメータが次の2つの質問に答えなければなりません。第一に、この値は実行時にどこから取得されるか。第二に、呼び出しに実際に使用される前に、どのような条件を満たす必要があるか。この3つを組み合わせることで、バッチは単なる取引の列ではなく、組み込まれたセキュリティチェックを備えたプログラムとなります。

結局のところ、静的バッチ処理のマインドセットはチェックリストであり、A、B、Cのステップを順番に実行する。一方、ERC-8211のマインドセットは条件付きのプログラムであり、Aを実行した後、Aの真の出力をBの入力として使用し、Bが制約を満たした場合にのみCに進む。どのステップも期待通りに進まなければ、バッチ全体がロールバックされる。

私たちはこれを、AI Agentや複雑なDeFi操作専用の「スマートバッチ処理」メカニズムと単純に理解できます。なぜなら、従来のチェーン上操作では、複雑なDeFi戦略を実行するのに複数の独立した取引が必要になるからです。例えば、貸借プロトコルから資金を引き出し、トークンを交換し、別のプロトコルに再預入するといった手順です（関連読み物：《加密 AI 協議全景：從以太坊的主戰場出發，如何為 AI Agent 搭建新操作系統？》）。

各ステップごとに個別に署名と確認が必要であり、これは人間のユーザーにとってすでに煩雑であり、高頻度の自律操作を必要とするAIエージェントにとってはボトルネックとなっている。ERC-8211の解決策は、複数のブロックチェーン操作を1つのトランザクションに組み合わせて実行可能にし、各ステップは実行時に実際の値を動的に解析し、定義された条件を満たした場合にのみ次ステップに進むことである。

たとえば、エージェントは1つの署名取引で以下を実行できます：Aaveから資金を引き出し→Uniswapで実際に受け取った金額を交換→交換結果をCompoundに預ける——すべてを原子的に実行し、新しいスマートコントラクトを記述する必要はありません。

ERC-8211がウォレット業界に注目される理由は、エージェントに適しているだけでなく、ウォレットがインタラクションチェーン上で果たす役割を再定義するからである。

過去のウォレットは、より安全な署名ツールに近いもので、その役割は秘密鍵の管理、トランザクションの表示、ユーザーによる確認、そして署名の送信にありました。この役割はEOA時代において十分に重要であり、アカウント抽象化の時代においても引き続き成立します。しかし、今後ますます多くのチェーン上の操作がエージェントによって代行されるようになると、ウォレットの役割はさらに中核的かつ重要なものとなるでしょう。

理由は簡単です。ユーザーがチェーン上のアクションを1つずつ操作するのではなく、エージェントに一連の目標を実行させるようになると、ウォレットはこのより高次のインタラクション対象を処理できる能力を備える必要があります。これ以上、特定のコントラクトアドレスと1つのcalldataを表示するだけではなく、「意図—値取得ロジック—条件判断—最終結果」の実行プロセス全体を示す必要があります。

したがって、将来のウォレットが理解すべきは、取引だけでなく、プログラムそのものです。ERC-8211は、この層でウォレットにより明確なハンドルを提供します。なぜなら、この仕様は実行の意味を明示的にコード構造に組み込んでおり、パラメータの来源、満たすべき条件、継続またはロールバックのタイミングなどが、バックエンドロジックに隠されたブラックボックスではなく、ウォレットが解釈・シミュレーション・表示可能な対象となっているからです。

ウォレットの視点から見ると、この一連のメカニズムは結局のところ、ユーザーが自分ではほとんど理解できない低レベルの呼び出しに署名するのではなく、結果指向で境界が明確かつ条件が検証可能な実行プログラムに署名することを意味します：

• AIエージェントはユーザーの意図を理解し、パスを生成することができます；
• ウォレットは、このパスをユーザーが確認しやすい形で表示します。
• リレイヤーは条件が満たされた場合にのみ提出を行い、結果を改ざんする権限は持ちません。

これが非管理型実行がAgentic DeFiの前提と見なされる理由であり、エージェントは参加できるが、主権、制約、最終決済は依然としてチェーン上に残る。これがERC-8211がスマートウォレットと真正に一致する点であり、その协议層標準に「複雑な意図を安全に表現する」ことが組み込まれているからである。

注目すべき点は、ERC-8211がERC-4337、EIP-7702、ERC-7579などのアカウント抽象フレームワークと完全に互換性があり、アカウント抽象を置き換えるのではなく、アカウント抽象の上にエージェント向けのプログラム実行セマンティクスを追加する点です。

ERC-4337が「誰が私の代わりにトランザクションを発信できるか」を解決し、EIP-7702が「EOAが一時的にスマートコントラクトの機能を獲得する方法」を解決するのであれば、ERC-8211は、エージェントが私の代わりに操作を開始した際に、1回の署名で一連の意思決定フローを完了できるかどうかを解決します。

イーサリアムの過去10年間のチェーン上インタラクションの進化を振り返る：

• 第1段階：1回の署名 = 1回の関数呼び出し（EOA時代）
• 第二段階：1回の署名 = 一連の静的パッケージ化呼び出し（ERC-4337、EIP-5792時代）
• 第3段階：1回の署名 = 動的評価される意図プログラム（ERC-8211時代）

每一次跃迁，都意味着用户（或代表用户的 Agent）能用更少的摩擦，表达更复杂的目标。

ERC-8211は現在ドラフト段階にあり、技術的な議論が進行中であり、プロトコルの大規模な導入にはまだ時間がかかりますが、その指向する方向はすでに十分に明確です。AIエージェントが本格的にオンチェーンでの意思決定を人間の代わりに開始するとき、オンチェーンにはそれに匹敵するネイティブな実行構文が必要になります。