ERC-8004とは?Ethereum上でトラストレスエージェントが機能する仕組み

2026年9月9日公開読了時間 1 分

ERC-8004は「Trustless Agents」と題されたEthereumの標準規格で、AIエージェントにオンチェーンのアイデンティティ、公開される評判の記録、作業内容を検証する手段を与え、事前の信頼関係がなくても組織をまたいで取引できるようにするものです。このガイドでは、3つのレジストリがどう動くか、現時点でmainnetに実際にデプロイされているものは何か、A2AやMCP、x402とこの標準がどう組み合わさるか、そして構築前に注意すべき点を扱います。

ERC-8004とは何か

ERC-8004は2025年8月にMetaMask、Ethereum Foundation、Google、Coinbaseの著者らによって提案され、3つのレジストリを定義しています。Identity Registryはエージェントが何者かを記録します。Reputation Registryはクライアントがそのエージェントについて何を言っているかを記録します。Validation Registryは独立した検証者がその作業をチェックしたかどうかを記録します。

仕様書は、信頼は画一的なものではないと明言しています。仕様書自身の言葉で言えば、信頼モデルは「プラガブルで階層化されており、ピザの注文のような低リスクのタスクから医療診断のような高リスクのタスクまで、リスクにさらされる価値に比例したセキュリティを持つ」ものです。夕食の予約をするエージェントは評判スコアに頼ればよい一方、資金を管理するエージェントは、資金を賭けている誰かによって作業を再検証してもらう必要があります。

なぜAIエージェントに信頼レイヤーが必要なのか

現在使われている信頼の仕組みはすべて、間に立つプラットフォームの存在を前提としています。マーケットプレイスのレビューは一企業のデータベースの中にあります。チャージバックが存在するのは、カードネットワークが買い手と売り手の間に入っているからです。OAuthログインが機能するのは、大手のIDプロバイダーが本人を保証しているからです。このモデルは、共有の運営者を持たず企業・クラウド・法域をまたいで動くよう作られた自律エージェントには通用しません。

エージェントスタックの残りの部分は、このギャップを埋めるように発展してきました。Model Context Protocol（MCP）はエージェントをツールやデータソースに接続します。Agent2Agent（A2A）はエージェント同士が互いを見つけ、構造化されたメッセージをやり取りできるようにします。x402は素のHTTP経由でサービスへの支払いを可能にします。これらはいずれも、どの相手と組むかをすでに決めていることを前提としています。その決定自体を助けるものはありません。

その役割を担うのがERC-8004であり、だからこそレジストリは誰かのデータベースではなくブロックチェーン上に存在します。実行先を選ぶDeFiエージェント、データラベリングエージェントを雇う調査エージェント、見知らぬ買い手にサービスを提供するかどうかを判断する商店、これらはすべて同じ3つの照会を必要とします。このエージェントは何者か。過去に関わった相手には何が起きたか。誰かがその出力を検証したか。ERC-8004はこれらの答えを、どの一者も支配しない場所に、すべてのエージェントが読める単一のスキーマとして置きます。

ERC-8004のIdentity Registryはどう動くか

登録された各エージェントは、NFTを支える標準規格と同じERC-721トークンです。登録はIdentity Registry上でregister()を呼び出すことで行われ、そのIDがエージェントの番号になるトークンをミントします。エージェントの完全な識別子は、チェーンとレジストリアドレスをそのIDと組み合わせたものなので、「Base上のエージェント4,205」はグローバルに一意です。

トークンのURIは登録ファイルを指します。このファイルはIPFSやHTTPSでホストされるか、オンチェーンに直接埋め込まれ、そのエージェントが何であり、どうやって到達するかを記述します。簡略化した登録ファイルは次のようになります。

jsonCopied
{
"type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
"name": "Research Agent",
"description": "Fetches and summarizes onchain data on request",
"image": "ipfs://<image-hash>",
"services": [
  { "name": "A2A", "endpoint": "https://agent.example/a2a" },
  { "name": "MCP", "endpoint": "https://agent.example/mcp" }
],
"supportedTrust": ["reputation", "tee-attestation"]
}

services配列はディスカバリー用のペイロードです。A2A、MCP、ENS名、分散識別子など、エージェントが話すあらゆるプロトコルにわたるライブのエンドポイントを広告します。supportedTrustフィールドは、そのエージェントがどの信頼モデルを採用するかを宣言します。仕様書によれば、これが存在しない場合、その登録はディスカバリー専用として使われます。

ERC-721の上に構築することで多くのものが無償で手に入ります。所有権、譲渡、委任はすでに機能し、ウォレットやマーケットプレイスはすでにこれらのトークンを表示でき、エコシステムのツール群もそのまま使えます。またこのレジストリは、アイデンティティと日々の動作に使われる鍵を分離します。setAgentWalletは署名済みの承認によって稼働用ウォレットをエージェントに紐付けるので、アイデンティティトークンの所有者とトランザクションに署名するウォレットは、それぞれ異なる被害範囲を持つ別々の鍵にできます。これはエージェントにウォレットを持たせる際に私たちが推奨しているのと同じ分離であり、そこではエージェントに生の秘密鍵の代わりにスコープ付きで時間制限のある署名アクセスを与えます。

ERC-8004のReputation Registryはどう動くか

どのアドレスでも、Reputation Registry上でgiveFeedbackを呼び出すことで任意のエージェントを評価できます。フィードバックエントリは、設定可能な小数点を持つ符号付きの数値を伴うので、粗い5段階評価ではなく負の値や精密な値を取ることができ、さらにフィルタリング用のタグを最大2つ、そしてよりリッチなオフチェーンの記述を指すオプションのURIを付けられ、これはそのハッシュ値としてオンチェーンにコミットされます。唯一の厳格な制限は、エージェントの所有者やオペレーターが自分自身のエージェントを評価できないことです。

関数のシグネチャよりも重要な設計上の選択が2つあります。第一に、クライアントはどこにも登録する必要がなく、これによりフィードバックを残すハードルがゼロに保たれ、サービス側がユーザーのレビューのガス代を肩代わりすることも可能になります。第二に、このレジストリは意図的に、正規のスコアを一切算出しません。生のシグナルを保存し、要約や読み取り用の関数を提供するだけで、解釈は問い合わせる側に委ねられます。この提案に関する議論では早い段階から、単一の集約された評判スコアは寡占的な力学やゲーミングを招くという指摘がなされており、そのためスコアリングはインデクサー層に置かれ、異なる利用者が同じデータを異なる重み付けで評価できるようになっています。

オフチェーンのフィードバックファイルは、レビューに実効性を持たせる部分です。やり取りで使われた具体的なMCPツールやA2Aタスクを参照でき、x402の支払いの証明を埋め込むこともできるので、そのレビューを検証可能に実際に起きた取引に紐付けられます。支払いの受領証によって裏付けられたレビューは、匿名ウォレットからの単なるスコアよりもはるかに強いシグナルであり、まさにそうしたレビューを絞り込んで扱うことこそが、このレジストリの本格的な利用者に期待される使い方です。

ERC-8004のValidation Registryはどう動くか

フィードバックスコアは、過去のクライアントが何を思ったかを教えてくれます。より高い価値を持つ作業については、それだけでは不十分で、出力自体をチェックする必要があります。Validation Registryは、あるエージェントが指名した検証者に特定の作業をチェックするよう依頼できるようにします。validationRequestは検証者、エージェント、そして作業へのハッシュコミット済みのポインタを記録し、検証者はvalidationResponseで応答し、自身のハッシュコミット済みの証拠とともに結果を0から100でスコア付けします。

「チェックする」が何を意味するかは検証者次第です。タスクを再実行して出力を比較し、不正な証明をすれば失うステークを持つやり方もあります。エージェントがTEE（信頼実行環境、実行したコードを証明できるハードウェア）内で動いたことを証明するやり方もあります。ゼロ知識機械学習証明（zkML、特定のモデルが特定の出力を生成したことを示す暗号学的証明）を検証するやり方もあります。レジストリはどの方式かは問わず、依頼と応答のやり取りを標準化するだけです。

ほとんど言及されない現状の注意点が一つあります。公式のマルチチェーンデプロイにはIdentity RegistryとReputation Registryが含まれていますが、Validation RegistryはTEEコミュニティとの再設計のため引き戻されており、現時点では公式のmainnetセットには含まれていません。今すぐ検証が必要なチームは、EigenCloudのtrustless agents統合のような特定のプロバイダーを通じてそれを組み込んでいます。これはERC-8004のアイデンティティと独自の検証可能な計算を組み合わせたものです。構築する前に、デプロイの状況については公式のcontractsリポジトリを確認してください。

エージェントはどの信頼モデルを使うべきか

仕様書の「リスクにさらされる価値」という枠組みは、かなり明快な判断基準になります。検証コストを、間違えた場合のコストに見合わせることです。

Trust model	How it works	Fits
Reputation	Clients post signed feedback onchain after each interaction	Low-stakes, high-volume tasks
Crypto-economic validation	Staked validators re-run the work and lose stake for false attestations	Higher-value tasks with checkable outputs
TEE attestation	Hardware proves which code the agent actually ran	Tasks where process integrity matters, like key handling
zkML proofs	A cryptographic proof that a specific model produced the output	Highest assurance, currently the most expensive

これらのモデルは重ね合わせることもできます。実運用のエージェントは、TEE上で動作し、評判の履歴を持ちながら、高価値の出力をステーク付きの再実行に提出することができ、この3つのシグナルすべてを同じsupportedTrustの宣言を通じて提示できます。

ERC-8004、A2A、MCP、x402はどう組み合わさるか

エージェントスタック:MCP、A2A、x402、そしてオンチェーンの信頼レイヤーとしてのERC-8004

エージェントスタックは、4つの異なる運営者による4つのレイヤーとして捉えるのが最も分かりやすいです。Anthropicが手がけるMCPは、エージェントをツールやコンテキストに接続します。Googleが始めたA2Aは、エージェント同士のディスカバリーとメッセージングを担います。Coinbase主導のx402は資金を動かし、これは複数存在する競合するエージェント決済プロトコルの一つです。ERC-8004は信頼を支える土台であり、意図的にブロックチェーン上に存在する唯一のレイヤーです。アイデンティティと評判は、どの相手も支配していない場合にのみ有用だからです。

一つのやり取りがこの4つすべてに触れることもあります。買い手側のエージェントは、必要とするスキルを広告しているエージェントをIdentity Registryに問い合わせ、候補者の登録ファイルを取得し、その評判の要約と検証結果を確認します。タスクを交渉するためにA2Aセッションを開くか、あるいは売り手のMCPエンドポイントを直接呼び出します。売り手が返すx402の請求書を支払います。作業が完了すると、支払いへの参照とともにgiveFeedbackを呼び出し、売り手の次の見込みクライアントは受領証付きのレビューを目にすることになります。

このスタックは全体のループを必須とするわけではありません。ERC-8004なしでx402を採用するチームもあれば、検証を一度も依頼せずにアイデンティティだけを登録するチームもあります。ただし各レイヤーは互いを参照し合うように設計されています。登録ファイルにはA2AとMCPのエンドポイントが列挙され、フィードバックファイルにはx402の受領証が埋め込まれるので、これらを組み合わせるにはグルーコードではなく設定だけで済みます。

ERC-8004の上に何を構築すればよいか

レジストリは通常のコントラクトなので、読み取るのに特別なツールは必要ありません。アイデンティティの照会はERC-721の呼び出しであり、各レジストリはインデックス可能なイベントを発行します。私たちは主要なデプロイ先チェーンをすべてサポートしているので、標準的なRPCエンドポイントがあれば始められます。エージェントの登録ファイルを取得するには、1回の読み取りで済みます。

typescriptCopied
import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";
const client = createPublicClient({
chain: mainnet,
transport: http("https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
});
// The Identity Registry is an ERC-721; tokenURI returns the agent's registration file URI
const agentURI = await client.readContract({
address: "0x8004A169FB4a3325136EB29fA0ceB6D2e539a432",
abi: [
  {
    name: "tokenURI",
    type: "function",
    stateMutability: "view",
    inputs: [{ name: "tokenId", type: "uint256" }],
    outputs: [{ type: "string" }],
  },
],
functionName: "tokenURI",
args: [1n],
});

そこから先は、おそらくすでに運用しているインフラにマッピングできます。Webhooksを使えば、新しい登録やフィードバックのイベントをポーリングではなくプッシュとして受け取れます。それらのイベントを中心にどうループを組むかは、オンチェーンAIエージェントアーキテクチャのガイドで解説しています。エージェントの運用ウォレットは生の鍵ではなくスコープ付きの署名者であるべきで、そのパターンはオンチェーンエージェントガイドで一通り解説しています。さらにエージェントは、ウォレットをアイデンティティとして私たちのプラットフォームに自ら申し込み、x402経由で呼び出しごとに支払うことで、人間を介さずに自分自身のインフラ利用関係を自律的に運用することもできます。コーディングエージェントから構築する場合は、Claude Code向けのAlchemyプラグインが私たちのMCPサーバーとスキルを1つのインストールにまとめています。

ERC-8004エージェントがレジストリの下流で行うことすべて、チェーンの状態を読む、イベントを監視する、トランザクションに署名する、自身のAPI利用料を支払う、これらはすべて、エージェントを第一級のユーザーとして想定して私たちが構築したインフラの上で動きます。Alchemy CLIから無料のエンドポイントを取得するか、エージェント自身にオンボーディングさせてください。APIキーの受け渡しも、契約も、サインアップの流れに人間を必要とする箇所も一切ありません。

ERC-8004にはどんな限界があるか

この標準はまだ若く、その粗削りな部分は議論スレッド自体に記録されています。設計に影響すべき点は次の通りです。

Sybilによるフィードバックは安価に作れる。 ウォレットの発行にコストはかからないため、生の評判スコアは容易に作り出せます。既知のクライアントや支払いの証明でフィルタリングされたフィードバックだけを利用し、フィルタリングされていない平均値は決して使わないでください。
アイデンティティは譲渡可能。 エージェントのアイデンティティは標準のERC-721なので、クリーンな履歴を持つ古いアイデンティティが売却されることがあり、評判もそれに付いていきます。履歴を信頼する前に所有権の変化を追跡してください。
スコアは劣化しやすい。 エージェントは確率的であり、モデルの更新によって挙動が一夜にして変わることがあるため、先月のフィードバックは先月のエージェントを描写しているに過ぎません。
評判は1つのチェーンに留まる。 Base上で登録されたエージェントはArbitrum上ではゼロから始まります。クロスチェーンの集約は、この標準がまだ解決していないインデクサー側の課題です。
インターフェースはまだ変わる可能性がある。 この標準は依然ドラフトであり、すでに一度再設計されています。統合はデプロイ済みのコントラクトに固定し、新しいサーフェスに依存する前に仕様を注視してください。

これらのいずれも、この標準が実際に主張していることを否定するものではありません。この標準は、オンチェーンの評判が偽造不可能だと主張したことは一度もありません。その主張は、エージェントの信頼シグナルは、私的なデータベースに散在するのではなく、公開され共有された、パーミッションレスなスキーマの中に属すべきだというものです。その主張に照らせば、この標準はすでに稼働しており、実際のシステムによってすでに読み取られています。

よくある質問

ERC-8004とは何か、そしてどのようにtrustlessなAIエージェントを可能にするのか

ERC-8004は、アイデンティティ、評判、検証をカバーする3つのレジストリを通じてAIエージェントをオンチェーンに登録するEthereumの標準規格です。エージェントはERC-721トークンとして携帯可能で検証可能なアイデンティティを得て、クライアントはフィードバックを公開の場に投稿し、検証者は作業の品質を証明します。これにより、エージェントは事前の信頼関係がなくても組織をまたいで取引できます。

ERC-8004はmainnetで稼働しているか

はい。Identity RegistryとReputation Registryは2026年1月からEthereum mainnet上で稼働しており、20を超えるネットワークで同一のアドレスにデプロイされています。

ERC-8004にトークンはあるか

いいえ。ERC-8004はスマートコントラクトの標準規格であり、トークンを持つプロジェクトではありません。エージェントを登録すると、そのエージェント専用のERC-721アイデンティティトークンがミントされますが、代替可能なERC-8004資産というものは存在せず、そのようなものとして販売されているものがあれば、この標準とは無関係です。

ERC-8004エージェントのアイデンティティは売却できるか

はい。エージェントのアイデンティティは標準のERC-721トークンなので、他のNFTと同様に譲渡でき、蓄積された評判もそのトークンとともに移動します。そのため所有権の履歴はデューデリジェンスの一部であり、クリーンな評判は現在の運用者が築いたものではなく、購入されたものである可能性があります。

どのチェーンがERC-8004をサポートしているか

公式のレジストリは、Ethereum、Base、Arbitrum、Optimism、Polygon、BSC、Monadを含む20を超えるEVMネットワークに同一のアドレスでデプロイされています。Alchemyはこれらのチェーン全体にわたってRPCとデータAPIを提供しているので、エージェントはレジストリがデプロイされているどこででも読み書きできます。

ERC-8004はx402やA2Aとどう違うのか

これらは同じスタックの異なるレイヤーを解決しています。A2Aはエージェント同士がどう見つけ合い、メッセージをやり取りするかを扱い、x402はHTTP経由でどう支払い合うかを扱い、ERC-8004は、アイデンティティ、評判、検証の記録をオンチェーンに固定することで、互いを信頼すべきかどうかを扱います。実運用のエージェントシステムは通常、この3つすべてを組み合わせて使います。