ウォレットがAIエージェントを組み込み始める時：ERC-8211の新たなインタラクションパラダイム、なぜ注目に値するのか？
- 核心的な視点：ERC-8211標準は、AIエージェントが複雑なオンチェーン操作（例：多段階DeFi戦略）を実行する際の核心的なボトルネック、すなわち既存の「静的バッチ処理」モデルがオンチェーン状態の動的変化に対応できない問題を解決することを目的としており、「動的評価プログラム」パラダイムを導入することで、AIエージェントにネイティブで安全なオンチェーン実行レイヤーを提供します。
- 重要な要素：
- 核心的な問題：既存の標準（例：ERC-4337）は1回の署名で複数の呼び出しをパッケージ化できますが、パラメータは署名時に「凍結」され、実行時にリアルタイムのオンチェーン状態（例：スリッページ、流動性）に基づいて動的に調整することができず、複雑なプロセスが脆弱で失敗しやすくなります。
- 解決策：ERC-8211はバッチ処理を「静的トランザクションシーケンス」から「動的評価プログラム」へと進化させ、Fetchers（リアルタイム値取得）、Constraints（条件制約）、Predicates（トリガー条件）という3つのプリミティブを通じて、各ステップの入力が前のステップの実際の出力に基づき、かつ事前設定された条件を満たすことを保証します。
- 実行保証：このメカニズムはアトミック実行を実現し、どのステップでも期待通りでない場合（例：交換金額不足、スリッページ超過）はバッチ全体がロールバックされ、資金の遊休や中途半端なトランザクションが残るリスクを回避します。
- ウォレットへの影響：ウォレットの役割は「安全な署名者」から「インテントプログラムインタプリタ」へと進化し、ユーザーに個々のトランザクションの詳細ではなく、値取得ロジックと条件判断を含む完全な実行プログラムを明確に提示する必要があります。
- エコシステムにおける位置付け：ERC-8211はERC-4337などのアカウント抽象化標準と互換性があり、その上に追加される「プログラム的実行セマンティクス」レイヤーとして、オンチェーンインタラクションをより高度な「インテント」表現パラダイムへと進化させることを共同で推進します。
2025年が始まると、多くの人は新しいインタラクション方法に徐々に慣れ始めるかもしれません：GPTやGeminiに「来週香港に行く旅程を計画して、適切な航空券とホテルを推薦して」と一言伝えると、バックグラウンドで黙々と情報検索、条件フィルタリング、ルート選択、価格比較などの一連のステップを完了し、最後に結果だけを確認のために渡してくれます。
しかし、同じ期待をオンチェーンに持ち込むと、話は完全に変わります。
例えば、あるDeFi Agentに「ウォレット内のETHをUSDCに交換し、Baseチェーンにブリッジして、全額Aaveに預け入れて」という指示を出したとします。客観的に言えば、「ニーズの理解」と「パス計画」の観点では、今日のAgentが必ずしもできないわけではありません。真の断層は実行段階に現れます：
依然として、署名、承認、交換、クロスチェーン、預入などの操作を段階的に完了する必要があり、かつ各ステップはスリッページの変動、Gasの変動、ブリッジの遅延、オンチェーン状態の変化のリスクにさらされています。これは、中間のいずれかのステップが予想から外れると、前のアクションは必ずしも撤回できず、後のアクションも続けられなくなる可能性があり、最終的にチェーン上に残るのは、多くの場合、完了していない半製品のプロセスであることを意味します。
問題はAIが十分に賢くないことではなく、オンチェーン実行レイヤーが今日まで、真にAgentに適した表現方法を欠いていることにあります。
このため、2026年4月初旬、Biconomyとイーサリアム財団が共同で発表したERC-8211は、現在のスマートコントラクト実行における「静的制限」問題の解決を目指し、AIエージェントおよび複雑なDeFiワークフローにより表現力豊かな実行レイヤーを提供し、この欠けているピースを埋めようと試みています。
一、AI Agentがオンチェーンに接続する「最後の断層」
過去1～2年間、暗号業界の注目の焦点は、L2スケーリング、RWA流動性から、AI Agentがどのように真にオンチェーン操作を引き継ぐかという、非常に破壊的なテーマに明らかにシフトしています。
客観的に言えば、「自然言語で多段階のDeFi戦略を指示する」から「自律Agentにクロスチェーンの投資ポートフォリオ全体を管理させる」まで、最近では多くの実践例が見られ、ほとんどの構想はデモレベルではすでに成熟しています。自然言語による多段階DeFi戦略の生成、自律的なリバランス実行、自動収益移行、クロスチェーンポジション調整、さらにはより複雑なポートフォリオ管理などです。
推論とオーケストレーションの観点では、AIの能力はかなり速く進歩していますが、実際に本番環境に投入すると、実行レイヤーの短所がますます明らかになります。
本番環境に落とし込むと、この短所は一言で要約できます：DeFiは動的ですが、今日のほとんどのバッチ処理は依然として静的です。
ERC-8211の公式サイトとディスカッション投稿はどちらもこの問題を明確に説明しており、既存のERC-4337とEIP-5792は、確かに「1回の署名が1回の呼び出しに対応する」という古いモードから、「1回の署名で複数の呼び出しをパッケージ化できる」という新段階に進めましたが、これらの呼び出しのパラメータは、本質的には依然として署名時点で凍結されているものがほとんどです。
つまり、ユーザーが署名時に記入した金額、目標値、期待される出力は、実際に実行される時点では、オンチェーン状態の変化に応じて自動的に調整されることはありません。
しかし、DeFi自体はまさに不確実性に満ちています。1回のスワップの実際の出力は、実行されるブロック内のスリッページと流動性に依存します。1回のブリッジの到着時間と最終到着金額は、ブリッジ自体のメカニズムと手数料に依存します。レンディングプロトコルやVaultのshare-to-asset比率も絶えず変化します。
結局のところ、ユーザーやAgentが署名時に見る数値は、多くの場合、単なる現在の推定値であり、実行時の実際の結果ではありません。
ERC-8211が何を解決するかを理解するには、最も典型的な例を見るのが良いでしょう。それは、Agentが一見普通に見えることをしたいと仮定する場合です——アカウント内のETHをUSDCに交換し、その後全額をSparkに預けて利息を稼ぐことです。
既存の静的バッチ処理モデルでは、Agentは署名前にスワップ後にどれだけのUSDCを受け取るかを推定しなければならず、多くの場合、署名時に事前に2番目のステップの入力金額を固定して記入することを強制されます。推定が高すぎると、実際の入金額が不足し、バッチ全体が直接ロールバックされます。推定が低すぎると、一部の資金がウォレット内で何もできずに放置されてしまいます。
言い換えれば、基本的にいわゆるジレンマに陥ります。失敗のリスクを負うか、機会費用を負うかのどちらかです。これが、多くの一見複雑ではないオンチェーンプロセスが、ステップが5ステップ、8ステップ、さらには2つのチェーンにまたがるようになると、急速に脆弱になる理由です。これは戦略自体が複雑すぎて記述できないからではなく、既存の実行パラダイムが事前に固定されたパラメータに依存しすぎているからです。
要するに、静的バッチ処理の能力上限が、事実上、Agentが真に安全に実行できる戦略の上限を決定しているのです。
この観点から、ERC-8211が解決しようとしているのは、AI Agentがどのように意思決定を行うかではなく、Agentがすでに意思決定を行った後、オンチェーンにそれを実行するためのより自然で、安定しており、安全な方法があるかどうかです。それによって、オンチェーン実行が初めて、AI Agentのためにネイティブに設計された表現形式を持つようになります。
二、ERC-8211は結局何を変えたのか？
ERC-8211の中核的なブレークスルーは、より多くのステップを1回の署名に詰め込むことではなく、バッチ処理を、パラメータが固定された一連のトランザクションから、「パラメータが実行現場で動的に評価されるプログラム」にアップグレードすることにあります。
確かに抽象的ですが、理解するのは難しくありません。公式はそれを一言で表現しています：From transactions to programs（トランザクションからプログラムへ）。
これは、ERC-8211がバッチを順番に実行するアクションリストとして見るのではなく、実行時に評価され、安全条件を伴う実行プログラムとして見ることを意味します。具体的に分解すると、それは3つの組み合わせ可能なプリミティブを通じてこれを実現します：
- Fetchers（フェッチャー）：このパラメータがどこから値を取得するかを定義します。それは、あるアドレスの現在の残高に対するクエリであり、パラメータが署名時のスナップショットではなく、実行瞬間にオンチェーン状態から取得されるリアルタイムの読み取り値になります。
- Constraints（制約）：パラメータが解決された後、インライン制約チェックを通過する必要があります——例えば「交換されたUSDCは少なくとも≥2500」または「スリッページは0.5%を超えてはならない」などです。これらの制約は、値が次の呼び出しにルーティングされる前に検証が完了し、いずれかが満たされない場合、バッチ全体が即座にロールバックされます。
- Predicates（述語）：ステップ間の門番と理解することができます。値を生成する責任はなく、実行を続行するかどうかを判断する責任があります。例えば、クロスチェーンシナリオでは、イーサリアム側のバッチは、「クロスチェーンされてきたWETHがすでに入金された」という条件をpredicateで監視し、入金されるまでずっとコミットしないようにすることができます。
この設計では、各パラメータは2つの質問に答える必要があります：第一に、この値は実行時にどこから来るべきか；第二に、それが実際に呼び出しに使用される前に、どのような条件を満たす必要があるか。この3つが組み合わさると、バッチはもはや単なるトランザクションシーケンスではなく、組み込みの安全チェックを備えたプログラムになります。
結局のところ、静的バッチ処理のメンタルモデルはリストです——A、B、Cの3ステップを順番に実行する。一方、ERC-8211のメンタルモデルは条件付きのプログラムです——Aを実行した後、Aの実際の出力をBの入力として取得する；Bが制約を満たした場合にのみCに進む；いずれかのステップが期待に沿わない場合、バッチ全体がロールバックされる。
実際、これを、AI Agentと複雑なDeFi操作のために特別に設計された「インテリジェントバッチ処理」メカニズムと簡単に理解することができます。なぜなら、従来のオンチェーン操作では、複雑なDeFi戦略を完了するには、多くの場合、複数の独立したトランザクションが必要だからです：レンディングプロトコルから資金を引き出す、トークンを交換する、別のプロトコルに預け入れる（拡張読書『暗号AIプロトコルパノラマ：イーサリアムの主戦場から、AI Agentのために新しいオペレーティングシステムを構築する方法は？』）。
各ステップは個別の署名と確認を必要とし、これは人間のユーザーにとってはすでに煩雑ですが、高頻度で自律的な操作を必要とするAI Agentにとってはさらにボトルネックです。ERC-8211の解決策は、複数のブロックチェーン操作を1つのトランザクションで組み合わせて実行することを可能にし、各ステップは実行時に実際の数値を動的に解析し、事前定義された条件を満たさなければ次のステップに進めないようにします。
例えば、Agentは1回の署名トランザクションで完了できます：Aaveから資金を引き出す → 実際に受け取った金額をUniswapで交換 → 交換結果をCompoundに預け入れる——すべてがアトミックに実行され、新しいスマートコントラクトを書く必要はありません。
三、なぜウォレット、特にスマートウォレットとの関係がより大きいと言えるのか
ERC-8211がウォレット業界の注目に値する理由は、それがAgentに適しているからだけでなく、インタラクション連鎖におけるウォレットの位置を再定義するからです。
過去のウォレットは、より安全な署名装置に似ていました。その責任は秘密鍵の保管、トランザクションの表示、ユーザーによる確認、そして署名の発行です。この役割はEOA時代にはすでに十分に重要であり、アカウント抽象化時代にも引き続き成立します。しかし、将来ますます多くのオンチェーン操作がAgentによって代行されるようになると、ウォレットの役割はより中央的で重要になります。
理由は簡単です。ユーザーがもはやオンチェーンアクションを一つ一つ操作するのではなく、Agentに一連の目標を実行することを承認し始めると、ウォレットはこのようなより高レベルのインタラクションオブジェクトを受け入れる能力を持たなければなりません。表示するのはもはや特定のコントラクトアドレスとcalldataではなく、「意図—値取得ロジック—条件判断—最終結果」という一連の実行プログラム全体です。
したがって、将来のウォレットが理解する必要があるのは、もはやトランザクションではなく、プログラムです。ERC-8211はまさにこのレイヤーでウォレットにより明確な手がかりを提供します。なぜなら、これらの実行セマンティクスをすべて符号化構造に明示的に書き込んでいるからです。パラメータがどこから来るか、どの条件を満たさなければならないか、いつ続行するか、いつロールバックするかは、バックエンドロジックに隠されたブラックボックスではなく、ウォレットによって解釈、シミュレーション、表示可能なオブジェクトです。
ウォレットの視点から見ると、この一連のメカニズムは最終的に同じことを指しています。つまり、ユーザーはもはや完全に理解するのが難しい低レベルの呼び出しに署名しているのではなく、結果指向で、境界が明確で、条件が検証可能な実行プログラムに署名しているのです：
- AI Agentはユーザーの意図を理解し、パスを生成する責任を負うことができる。
- ウォレットはこのパスをより明確な方法でユーザーに提示して審査する責任を負う。
- そしてrelayerは条件が成立した時にのみコミットする責任を負い、結果を改ざんする権限を持たない。
これがまさに、非カストディアル実行がAgentic DeFiの前提と見なされる理由です。なぜなら、インテリジェントエージェントは参加できますが、主権、制約、最終決済は依然としてオンチェーンに残るからです。これがまた、ERC-8211とスマートウォレットが真に適合する点です。それは「複雑な意図を安全に表現する」ということを、プロトコルレイヤーの標準に書き込んだことです。
特筆すべきは、ERC-8211がERC-4337、EIP-7702、ERC-7579などのアカウント抽象化フレームワークと完全に互換性があることです。それはアカウント抽象化に取って代わるものではなく、アカウント抽象化の上に、Agentのためにプログラム的な実行セマンティクスのレイヤーを追加したものです。
もしERC-4337が「誰が私に代わってトランザクションを開始できるか」を解決し、EIP-7702が「EOAが一時的にスマートコントラクト能力を持つ方法」を解決するなら、ERC-8211が解決するのは、Agentが私に代わって操作を開始したら、1回の署名で意思決定チェーン全体を完了できるかどうかです。
イーサリアムの過去10年間のオンチェーンインタラクションパラダイムの進化を振り返ると：
- 第1段階：1回の署名 = 1回の関数呼び出し（EOA時代）
- 第2段階：1回の署名 = 1組の静的にパッケージ化された呼び出し（ERC-4337、EIP-5792時代）
- 第3段階：1回の署名 = 1つの動的に評価される意図プログラム（ERC-8211時代）
