---
title: "ERC-8004とは？Ethereum上のトラストレスエージェントの仕組み"
description: "ERC-8004はEthereumのトラストレスエージェント標準である。オンチェーンのアイデンティティ、レピュテーション、バリデーションの各レジストリが、AIエージェントの安全な取引をどう可能にするかを解説する。"
---

# ERC-8004とは？Ethereum上のトラストレスエージェントの仕組み

<ImageBlock
  src="https://media.alchemy.com/blog/erc-8004-hero.png"
  alt="ERC-8004 ガイドのカバー画像"
  width={1920}
  height={900}
  priority
/>

ERC-8004は「Trustless Agents」と題されたEthereum標準であり、AIエージェントにオンチェーンのアイデンティティ、公開のレピュテーション記録、そして成果物を検証してもらう手段を与えることで、事前の信頼関係なしに組織をまたいで取引できるようにする。本ガイドでは、3つのレジストリの仕組み、現時点でメインネットに実際にデプロイされているもの、この標準が[A2A](https://github.com/a2aproject/A2A)、MCP、[x402](https://www.alchemy.com/blog/how-x402-brings-real-time-crypto-payments-to-the-web)とどう組み合わさるか、そして構築を始める前に注意すべき点を扱う。

## ERC-8004とは何か

[ERC-8004](https://eips.ethereum.org/EIPS/eip-8004)は2025年8月、MetaMask、Ethereum Foundation、Google、Coinbaseに所属する著者らによって提案され、3つのレジストリを定義している。Identity Registry（アイデンティティレジストリ）はエージェントが誰であるかを記録する。Reputation Registry（レピュテーションレジストリ）はクライアントがそのエージェントをどう評価したかを記録する。Validation Registry（バリデーションレジストリ）は独立したバリデータがその成果物を検証したかどうかを記録する。

この仕様は、信頼が一律のものではないことを明言している。仕様自身の言葉を借りれば、信頼モデルは「プラガブルかつ階層的であり、セキュリティはリスクにさらされる価値に比例する。ピザの注文のような低リスクのタスクから、医療診断のような高リスクのタスクまで」である。ディナーの予約を取るエージェントはレピュテーションスコアに頼ればよい。トレジャリーを管理するエージェントには、資金をリスクにさらしている誰かによる成果物の再検証が必要である。

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

今日使われている信頼システムはどれも、中央にプラットフォームがあることを前提としている。マーケットプレイスのレビューは1つの企業のデータベースに保存されている。チャージバックが存在するのは、買い手と売り手の間にカードネットワークが介在するからである。OAuthログインが機能するのは、大手のアイデンティティプロバイダーがあなたを保証してくれるからである。このモデルは、企業、クラウド、法域をまたいで、共有の運営者なしに動くよう作られた自律エージェントには通用しない。

エージェントスタックの残りの部分は、このギャップの周囲を埋めてきた。[Model Context Protocol](https://modelcontextprotocol.io/)（MCP、モデルコンテキストプロトコル）はエージェントをツールやデータソースに接続する。Agent2Agent（A2A）はエージェント同士が互いを見つけ、構造化されたメッセージを交換できるようにする。x402は、エージェントがプレーンなHTTP上で[サービスの対価を支払える](https://www.alchemy.com/overviews/what-are-agent-payments)ようにする。これらはいずれも、どの相手と取引するかをすでに決めていることを前提としている。その決定を助けてくれるものは1つもない。

それこそがERC-8004が引き受ける仕事であり、レジストリが誰かのデータベースではなくブロックチェーン上に置かれている理由でもある。実行先を選ぶ[DeFiエージェント](https://www.alchemy.com/overviews/defi-ai-agents)も、データラベリングエージェントを雇うリサーチエージェントも、見知らぬ買い手に応じるかを判断するマーチャントも、必要とするのは同じ3つの照会である。このエージェントは誰か。他者がこのエージェントと取引したとき何が起きたか。誰かがその出力を検証したか。ERC-8004はこれらの答えを、単一の当事者が支配しない場所に、すべてのエージェントが読める1つのスキーマで置く。

## ERC-8004のアイデンティティレジストリはどう機能するか

登録された各エージェントは、NFTを支えるのと同じ標準である[ERC-721トークン](https://www.alchemy.com/blog/comparing-erc-721-to-erc-1155)である。登録はIdentity Registryの`register()`を呼び出してトークンをミントし、そのIDがエージェントの番号になる。エージェントの完全な識別子はチェーンとレジストリアドレスにこのIDを組み合わせたものであるため、「Base上のエージェント4,205」はグローバルに一意である。

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

<CodeSnippet
  language="json"
  code={`{
  "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`は署名付きの認可によって稼働用ウォレットをエージェントに紐付けるため、アイデンティティトークンの所有者と、トランザクションに署名するウォレットは、影響範囲の異なる別々の鍵にできる。これは、そもそも[エージェントにウォレットを与える](https://www.alchemy.com/blog/agent-wallets-alchemy-cli)際に推奨しているのと同じ分離であり、エージェントは生の秘密鍵ではなく、スコープ付きで期限付きの署名アクセスを得る。

## ERC-8004のレピュテーションレジストリはどう機能するか

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

関数シグネチャよりも重要な設計上の選択が2つある。第一に、クライアントはどこにも登録しないため、フィードバックを残す障壁はゼロのままであり、サービス側がユーザーのレビューの[ガス代をスポンサーする](https://www.alchemy.com/gasless-transactions)こともできる。第二に、レジストリは意図的に正規のスコアを一切計算しない。生のシグナルを保存し、集計用・読み取り用の関数を提供し、解釈は照会する側に委ねる。提案のディスカッションでは早くから、単一の集約レピュテーション値は独占の力学と不正操作を招くと論じられており、そのためスコアリングはインデクサーレイヤーに置かれ、異なる消費者が同じデータを異なる重み付けで扱えるようになっている。

レビューに実効性を持たせるのは、オフチェーンのフィードバックファイルである。そのインタラクションが使った具体的なMCPツールやA2Aタスクを参照でき、x402決済の証明を埋め込むこともできるため、レビューを検証可能に実在したトランザクションに紐付けられる。決済レシートに裏付けられたレビューは、匿名ウォレットからの単なるスコアよりもはるかに強いシグナルであり、まさにそうしたレビューだけをフィルタリングすることが、このレジストリの真剣な利用者に期待される使い方である。

## ERC-8004のバリデーションレジストリはどう機能するか

フィードバックスコアが教えてくれるのは、過去のクライアントがどう思ったかである。より高価値な仕事ではそれだけでは足りず、出力そのものの検証が必要になる。Validation Registryは、エージェントが指名したバリデータに特定の成果物の検証を依頼できるようにする。`validationRequest`はバリデータ、エージェント、成果物へのハッシュコミット付きポインタを記録し、バリデータは`validationResponse`で応答し、独自のハッシュコミット付きエビデンスとともに結果を0から100でスコアリングする。

「検証」が何を意味するかはバリデータ次第である。タスクを再実行して出力を比較することもでき、その場合、不誠実な証明をすれば失うステークを伴う。エージェントがtrusted execution environment（TEE、どのコードを実行したかを証明できるハードウェア）内で動作したことを証明することもできる。zkML（特定のモデルが特定の出力を生成したことを示す暗号学的証明であるゼロ知識機械学習証明）を検証することもできる。レジストリはどの方式かを問わず、リクエストとレスポンスの配管を標準化するだけである。

ほとんどの解説が触れない現状の注意点が1つある。公式のマルチチェーンデプロイにはIdentityとReputationの両レジストリが含まれるが、Validation RegistryはTEEコミュニティとの再検討のために引き戻され、今日の公式メインネットセットには含まれていない。今すぐバリデーションが必要なチームは、[EigenCloudのtrustless agentsインテグレーション](https://docs.eigencloud.xyz/products/eigenai/howto/build-trustless-agents)のような特定のプロバイダー経由で組み込んでいる。これはERC-8004のアイデンティティを同社の検証可能なコンピュートと組み合わせるものである。構築を始める前に、デプロイ状況を[公式コントラクトリポジトリ](https://github.com/erc-8004/erc-8004-contracts)で確認してほしい。

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

仕様の「リスクにさらされる価値」という枠組みは、かなり明快な判断ルールに落とし込める。検証のコストを、間違えたときのコストに見合わせることである。

<EmbeddedTable
  table={{
    columns: [
      { key: "model", width: 200, title: "信頼モデル", dataType: "object" },
      { key: "how", width: 320, title: "仕組み", dataType: "object" },
      { key: "fits", width: 260, title: "適する用途", dataType: "object" },
    ],
    data: [
      {
        model: { title: "レピュテーション", tooltip: "", icon: "" },
        how: {
          title:
            "クライアントがインタラクションごとに署名付きフィードバックをオンチェーンに投稿する",
          tooltip: "",
          icon: "",
        },
        fits: { title: "低リスクで高頻度のタスク", tooltip: "", icon: "" },
        id: 0,
      },
      {
        model: { title: "暗号経済的バリデーション", tooltip: "", icon: "" },
        how: {
          title:
            "ステークを預けたバリデータが作業を再実行し、虚偽の証明をすればステークを失う",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "検証可能な出力を持つ、より高価値なタスク",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        model: { title: "TEEアテステーション", tooltip: "", icon: "" },
        how: {
          title: "エージェントが実際に実行したコードをハードウェアが証明する",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "鍵の取り扱いなど、プロセスの完全性が重要なタスク",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        model: { title: "zkML証明", tooltip: "", icon: "" },
        how: {
          title: "特定のモデルがその出力を生成したことの暗号学的証明",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "最高の保証。現時点では最も高コスト",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

これらのモデルは積み重ねることもできる。本番のエージェントは、TEE内で動作し、レピュテーション履歴を持ち、高価値な出力をステーク付きの再実行に提出し、その3つのシグナルすべてを同じ`supportedTrust`宣言を通じて提示する、という形を取り得る。

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

<ImageBlock
  src="https://media.alchemy.com/blog/erc-8004-agent-stack.png"
  alt="エージェントスタック:MCP、A2A、x402と、オンチェーン信頼レイヤーとしてのERC-8004"
  width={1600}
  height={900}
/>

エージェントスタックは、それぞれ異なる主体が担う4つのレイヤーとして捉えるのが最も分かりやすい。Anthropic発のMCPはエージェントをツールとコンテキストに接続する。Googleが始めたA2Aはエージェント間のディスカバリーとメッセージングを担う。Coinbaseが推進するx402は資金を動かすもので、[複数の競合するエージェント決済プロトコル](https://www.alchemy.com/overviews/x402-vs-mpp-comparing-agent-payment-protocols)の1つである。ERC-8004は信頼をアンカーし、意図的にブロックチェーン上に置かれた唯一のレイヤーである。アイデンティティとレピュテーションは、どの取引相手にも支配されていない場合にのみ有用だからである。

1つのインタラクションが4つすべてに触れることもある。買い手エージェントはIdentity Registryに必要なスキルを広告するエージェントを照会し、候補の登録ファイルを取得し、そのレピュテーションのサマリーとバリデーションを確認する。A2Aセッションを開いてタスクを交渉するか、売り手のMCPエンドポイントを直接呼び出す。売り手が返すx402のインボイスを支払う。作業が完了したら、決済への参照を添えて`giveFeedback`を呼び出し、売り手の次の見込みクライアントはレシート付きのレビューを目にする。

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

## ERC-8004の上でどう構築するか

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

<CodeSnippet
  language="typescript"
  code={`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](https://www.alchemy.com/webhooks)を使えば、新しい登録やフィードバックのイベントをポーリングではなくプッシュで受け取れる。それらのイベントの周りにどうループを組むかは、[オンチェーンAIエージェントアーキテクチャガイド](https://www.alchemy.com/overviews/onchain-ai-agent-architectures)で扱っている。エージェントの運用ウォレットは生の鍵ではなくスコープ付きのsignerにすべきであり、そのパターンは[オンチェーンエージェントガイド](https://www.alchemy.com/blog/how-to-build-onchain-agents)がエンドツーエンドで解説している。さらにエージェントは、自身のインフラとの契約関係を自律的に運用することもできる。[エージェントはウォレットをアイデンティティとしてAlchemyのプラットフォームに自らサインアップし](https://www.alchemy.com/blog/ai-agents-can-now-sign-up-for-alchemy)、x402経由で呼び出しごとに支払うことができ、人間の介在は不要である。コーディングエージェントから構築するなら、[Alchemy plugin for Claude Code](https://www.alchemy.com/blog/alchemy-claude-plugin-now-live)がAlchemyのMCPサーバーとスキル一式を1回のインストールにまとめている。

ERC-8004エージェントがレジストリの下流で行うすべてのこと、すなわちチェーン状態の読み取り、イベントの監視、トランザクションへの署名、自身のAPI利用料の支払いは、エージェントをファーストクラスのユーザーとして扱うために構築されたAlchemyのインフラ上で動く。[Alchemy CLI](https://www.alchemy.com/agents)で無料のエンドポイントを取得するか、エージェント自身にオンボーディングさせてほしい。APIキーの受け渡しも契約も不要で、サインアップのループに人間を必要とする箇所はない。

## ERC-8004の限界は何か

この標準は若く、その粗削りな部分は提案自身のディスカッションスレッドに記録されている。設計に影響すべきものは次のとおりである。

- **Sybilフィードバックは安価である。** ウォレットの作成は無料であるため、生のレピュテーションスコアは容易に捏造できる。フィードバックは既知のクライアントや決済証明でフィルタリングして消費し、フィルタリングされていない平均値は決して使わないこと。
- **アイデンティティは移転可能である。** エージェントのアイデンティティは標準のERC-721であるため、クリーンな履歴を持つ古参のアイデンティティは売却可能であり、レピュテーションもそれに付いていく。履歴を信頼する前に、所有権の変更を追跡すること。
- **スコアは陳腐化しやすい。** エージェントは確率的であり、モデルの更新は挙動を一夜にして変え得るため、先月のフィードバックが記述しているのは先月のエージェントである。
- **レピュテーションは1つのチェーンに留まる。** Baseで登録されたエージェントは、Arbitrumではゼロから始まる。チェーン横断の集約は、この標準がまだ解決していないインデクサー側の課題である。
- **インターフェースはまだ動く可能性がある。** この標準は依然としてドラフトであり、すでに一度再設計されている。インテグレーションはデプロイ済みコントラクトに固定し、新しいサーフェスに依存する前に仕様の動向を注視すること。

これらのいずれも、この標準の実際の主張を損なうものではない。その主張は、オンチェーンのレピュテーションは偽造不可能だというものでは決してなかった。主張は、エージェントの信頼シグナルは、散在するプライベートなデータベースではなく、公開され、共有され、パーミッションレスなスキーマに置かれるべきだ、というものである。その主張に照らして判断すれば、この標準はすでに稼働しており、現実のシステムに読まれている。

## よくある質問

### ERC-8004とは何か。どのようにトラストレスなAIエージェントを可能にするのか

ERC-8004は、アイデンティティ、レピュテーション、バリデーションを扱う3つのレジストリを通じてAIエージェントをオンチェーンに登録するEthereum標準である。エージェントはERC-721トークンとしてポータブルで検証可能なアイデンティティを得て、クライアントはフィードバックを公開で投稿し、バリデータは成果物の品質を証明する。これにより、エージェントは事前の信頼関係なしに組織をまたいで取引できる。

### ERC-8004はメインネットで稼働しているか

稼働している。IdentityとReputationの両レジストリは2026年1月からEthereumメインネットで稼働しており、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つすべてを組み合わせる。