ERC-8004 完全ガイド：AIエージェント時代における信頼レイヤーとは

2026年2月10日

ERC-8004 完全ガイド：AIエージェント時代における信頼レイヤーとは

日々の雑務からビジネスワークフローまで、AIエージェントは急速にインターネットの「標準的な作業者」として台頭しています。APIの呼び出し、サービスとの交渉、さらには資金の移動までも自律的に行うこうしたエージェント。かつてSFの話だった自律的で自己組織化されたエージェント経済の世界は、すでに暗号資産取引、DeFiの運用、オンチェーンリサーチ、エージェント型コマースなど、現実のものとなり始めています。

しかし、その盛り上がりとは裏腹に、根幹となる重要な問いがあります。

異なる開発者によって独立して作られたAIエージェントが協働する際、どうやって「信頼」を確立できるのか？

たとえば、全く知らない外注業者を雇う場合であれば、実績や評価、資格の確認などを通じて信頼性を判断します。ERC-8004は、それと同じ仕組みをEthereumの分散型ネットワークに持ち込みます。Ethereumを中立的な信頼の基盤とし、エージェントの身元、評判、検証を可能にするプロトコルです。(eips.ethereum.org)

ERC-8004とは何か、そして何ではないか

**ERC-8004（別名「Trustless Agents」）**は、異なる組織間でもAIエージェントが発見され、評価されることを目的とした、Ethereumのアプリケーション層における標準規格の草案です。この規格は、中央集権的なプラットフォームに頼らずにエージェントを「信頼」する仕組みを提供します。(eips.ethereum.org)

その実現方法は、以下の3つの軽量なオンチェーン・レジストリの標準化です。

  1. アイデンティティ レジストリ
  2. レピュテーション（評判）レジストリ
  3. バリデーション（検証）レジストリ

重要なのは、ERC-8004があくまでリファレンス規格であり、以下のようなことを提供しない点です：

  • エージェント同士の通信プロトコルには立ち入らない（ただし参照は可能）
  • 支払いメカニズムを定義しない（ただし支払いの証明はフィードバックに含められる）
    （詳しくは ERC-8004 原文 を参照）

なぜ2025〜2026年の暗号資産業界に「信頼レイヤー」が必要か

2025年、暗号資産領域ではユーザー体験の自動化が急速に進んでいます。意図（インテント）に基づく実行、チェーンの抽象化、賢くなるウォレット、運用支援のAI「コパイロット」などが標準になります。そして、2026年に進むべき次のステップは、エージェント同士が雇い合うマーケットの形成です。

たとえば、あるエージェントが別のエージェントに対して以下のような依頼を行います：

  • データの取得
  • 処理や実行の代行
  • 精度監査や検証
  • オーダールーティング
  • 決済業務の完了

しかしここで問題となるのは、自動化によって悪意ある攻撃のリスクが拡大されるという現実です。

信頼を持ち回せる基本構造＝ポータブルな信頼プリミティブがなければ、自由なエージェント市場は次のような脆弱性にさらされます：

  • なりすましや偽サービスの横行
  • シビル攻撃による偽の評価ネットワーク構築
  • 根拠のない主張（例：「私が戦略を実行した」「この証明を確認済み」）
  • 秘密鍵の漏洩による資金の不正移動など

ERC-8004は、Ethereum上に信頼を再構成可能かつ検証可能な形で持ち運べるインフラを作ることで、この問題に対応しようとしています。

ERC-8004の中核設計：3つのレジストリ

1) アイデンティティレジストリ：エージェントの「パスポート」

ERC-8004では、エージェントの身元情報をERC-721トークン形式で管理します。これにより、NFT関連の既存ツールを使ってエージェントの情報を簡単に検索・表示できます。

ポイントは下記の通りです：

  • エージェントIDは、次の構成で定義されます：
    • agentRegistry = {namespace}:{chainId}:{identityRegistry}
    • agentId = tokenId
  • agentURIというフィールドには、以下を含む登録用JSONのリンクを指定できます：
    • 名前、説明、画像
    • サービスのエンドポイント (Web、A2A通信、MCPプロトコル、ENS、DID、Eメールなど)
    • 評判、暗号経済的な検証、TEEによる証明の対応有無

実際に重要となる活用例：

  • モデルコンテキストプロトコル（MCP）のエンドポイントを公開し、異なるAIアプリ間でのツール利用を標準化。
    参考：Introducing the Model Context Protocol
  • ウォレットのアドレスを、署名付きで信頼できる形で公開（EIP-712 署名や ERC-1271 に対応）

また、ドメイン所有者が正当であることを確認するために /.well-known/agent-registration.json を使ったドメイン検証機能もオプションで組み込まれています。

2) レピュテーションレジストリ：標準化されたフィードバック

エージェントと取引をした後、ユーザーや他のエージェントは、統一されたインターフェースを通じてフィードバックを投稿できます。

設計面での注目点：

  • フィードバックは署名付きの定点数（ int128 + 小数点）として記録され、オプションでタグも追加可能。
  • 詳細な証拠はオフチェーン（IPFSなど）に保存し、オンチェーンでは次の情報を取り扱います：
    • インデックス用のイベント
    • 内容アドレスでないURIに対応した整合性保証ハッシュ
  • シビル攻撃対策として、信頼できるアドレスからのフィードバックのみを抽出して使うべき。

暗号資産業界において評判は取引ルーティングの基盤情報となります：

  • 「このオーダーを実行すべきはどのエージェントか？」
  • 「このOTCスワップを見積もるのに適したエージェントは？」
  • 「最終決済前に監査・検証を行うエージェントは誰が良いか？」

3) バリデーションレジストリ：信頼性の高いタスク実行の検証

評判だけでは正確性を保証できない場面も多々あります。ERC-8004では、以下のバリデーション仕組みを導入します：

  • エージェントが、オフチェーンのペイロード（とそのハッシュ）を参照しながら検証リクエストを送信
  • 「バリデータ」契約がそれに対してスコア（0〜100点）と、必要に応じて証拠を返す

対応可能なバリデーション方法：

  • ステーキング担保付きの再実行
  • zkMLのようなゼロ知識証明
  • TEE（信頼実行環境）オラクル

簡単に言えば：

  • 「評判が良いらしい」から
  • 「第三者が暗号的・経済的に正しく行われたと証明できる」世界へと進化させます。

ERC-8004とエージェントスタック全体との関係

以下のような分業構造で捉えると理解しやすいです。

  • MCP（Model Context Protocol）：エージェントが「どのツール・文脈を使うか」を定義する 垂直的な基盤。
    MCP ドキュメント
  • A2A：エージェント同士が「どう通信・協働するか」を扱う 水平方向のプロトコル。
  • ERC-8004：その外側にある 信頼と発見のレイヤー。エージェントの身元、信用の有無、成果物の検証可能性などを担保します。

支払いに関してはスコープ外とされていますが、ERC-8004規格内に**支払い証明（proof of payment）**をフィードバックに含める設計が想定されています。具体的な支払いインフラとしては、HTTP 402エラーをWebネイティブの支払いに活用する「x402」が注目されています。

関連情報：CloudflareとCoinbaseが「x402 Foundation」設立を発表

現在の状況：草案段階ながらも急速に進む実装

ERC-8004は2025年8月13日に提案され、現在もEthereumの公式ERCリポジトリ上ではDraft（草案）段階です。

しかし現実のコミュニティはすでに一歩進んでいます。複数の報告によると、2026年1月29日にはERC-8004の中核レジストリがEthereumメインネットにデプロイされたことが確認されており、規格確定前から「リファレンス実装」が稼働している実態があります。

中国メディアの視点からは、Foresight NewsがERC-8004 + A2A + MCPを3層の信頼アーキテクチャとして解説した記事を発表しています。 AI Agent Economy 基础设施：ERC-8004 & A2A & MCP

見落としてはいけないセキュリティとユーザー保護ポイント

ERC-8004によって「信頼の持ち運び」は改善されますが、リスクが完全に無くなるわけではありません。以下のような注意点があります：

  1. シビル攻撃や評判の操作
    攻撃者ネットワークによる虚偽のレビューを想定し、信頼できるレビュアーセットや評価の重み付け、検証階層の設計が重要です。

  2. エンドポイントのハッキングや悪質なアップデート
    エンドポイントの動作が後から変更される可能性があるため、ドメイン検証はあくまで最低条件と捉えるべきです。

  3. 鍵管理が死活問題になる
    ERC-721型のIDトークンの秘密鍵が攻撃されると、そのエージェントの評判や支払い先、エンドポイントが乗っ取られるリスクが生じます。

  4. 「身元証明」への過剰な信頼に注意
    エージェントが正しく登録されていても、その能力や善悪を保証するものではありません。そのためにも評判＋検証が不可欠です。

実用的チェックリスト：エージェントとやり取りする前に確認すべきこと

ユーザーあるいはプロトコルがERC-8004準拠エージェントと連携する場合は、次のことを確認してください：

  • オンチェーンID（レジストリ + agentId）を確認
  • 登録JSONを読み、エンドポイントが信頼できるか検証（可能であれば /.well-known/ もチェック）
  • 評判は状況依存として扱い、信頼あるレビュアーやタグでフィルター
  • 重要事項では必ずバリデーションを要請（認める検証手順を事前に定義）
  • トークンの無制限承認は避ける（利便性のための過剰な許可はリスク大）
  • 明示的かつ署名付きのインテントフローを採用（暗黙のバックグラウンド実行より安全）

OneKeyの立ち位置：エージェントIDを守る「鍵」の防御線

ERC-8004によって、エージェントのアイデンティティや評判は持ち運び可能になりますが、それは同時に秘密鍵の重要性がかつてなく高まることを意味します。

OneKeyのようなハードウェアウォレットは、ERC-8004時代におけるセキュリティモデルの一翼を担えます：

  • オーナーキーをオフラインに保管することで、鍵漏洩→エージェントの乗っ取りを防止
  • 敏感な操作（ERC-721の移転や支払い先の変更）に物理的な確認を追加
  • ユーザーがエージェント主導の処理とやり取りする際の勝手な署名を防ぐブレーキ役

オープンなエージェント経済において成功するのは、単に優秀なエージェントではありません。信頼性の高い信号と、堅牢なセキュリティ運用を備えた者たちです。ERC-8004はその未来へと続く、大きなステップです。

OneKeyで暗号化の旅を守る

View details for OneKeyのご購入OneKeyのご購入

OneKeyのご購入

世界最先端のハードウェアウォレット。

View details for アプリをダウンロードアプリをダウンロード

アプリをダウンロード

詐欺アラート。すべてのコインをサポート。

View details for OneKey SifuOneKey Sifu

OneKey Sifu

暗号化の疑問を解消するために、一つの電話で。