# [ERC8004] トラストレスに動くエージェントの仕組みを理解しよう！

> このプロトコルは、ブロックチェーンを活用して、組織をまたいでエージェント（自律的なプログラムやAI）を「発見」、「選択」、「やり取り」できる仕組みを提案しています。ここで重要なのは、事前に信頼関係がなくても安全に協働できるという点です。

- URL: https://cardene.dev/articles/4958873135ba9892c298
- 公開日: 2025-11-12
- 更新日: 2025-11-12
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

https://amzn.asia/d/gxvJ0Pw

今回は、評判（レピュテーション）と検証に基づき、事前の信頼関係なしでもエージェントを発見し信頼を確立できるプロトコルを提案している**ERC8004**についてまとめていきます！

:::message
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
:::

https://eips.ethereum.org/EIPS/eip-8004

他にも様々なEIP・BIP・SLIP・CAIP・ENSIP・RFC・ACPについてまとめています。

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## 概要

このプロトコルは、ブロックチェーンを活用して、組織をまたいでエージェント（自律的なプログラムやAI）を「**発見**」、「**選択**」、「**やり取り**」できる仕組みを提案しています。
ここで重要なのは、事前に信頼関係がなくても安全に協働できるという点です。
これにより、特定の企業やプラットフォームに縛られない「**オープンなエージェント経済**」を実現することを目的としています。

このプロトコルでは、信頼モデル（Trust Model）を柔軟に切り替えられる「**プラグイン型構造**」を採用しています。
タスクの重要度や金銭的リスクの大きさに応じて、異なるレベルのセキュリティを選べます。
例えば、軽いタスク（ピザの注文など）には簡易な信頼モデルを使い、医療診断のような高リスクなタスクでは厳重な検証モデルを使う、といった具合です。

開発者は以下の3つの信頼モデルから選択できます。

| 信頼モデル   | 説明   |
| ------------- | ---------- |
| レピュテーションシステム（Reputation System）  | クライアントのフィードバックを利用してエージェントの信頼度を算出する方式です。 |
| ステーク担保付き再実行（Stake-Secured Re-execution）   | エージェントがタスクを実行した結果を、他の参加者が再度実行して検証する方式です。ステーク（担保金）を預けることで不正を抑止します。     |
| zkML・TEEオラクル検証（zkML Proofs / TEE Oracles） | 機械学習の結果をゼロ知識証明（zkML）や信頼実行環境（TEE）で安全に検証します。外部の信頼できる計算サービス（オラクル）を利用します。 |

このように、タスクの性質やリスクに応じて適切な信頼モデルを選ぶことで、安全かつ柔軟なエージェント間取引を実現します。

## 動機

MCP（Model Context Protocol）は、サーバーが自身の提供できる機能（プロンプト、リソース、ツール、補完など）を一覧化して公開できる仕組みを提供しています。
一方で、A2A（Agent-to-Agent）プロトコルは、エージェント同士の認証、スキルの公開（AgentCardという形式）、直接メッセージのやり取り、タスクの管理といった通信部分を担当しています。

しかし、これらの通信プロトコルには「**信頼できるエージェントをどうやって発見するか**」という仕組みが含まれていません。
つまり、「**誰を信頼して仕事を任せるか**」という問題が未解決のままです。

この課題を解決し、異なる組織や個人が自由に協力できるオープンなエージェント経済を作るために、**ERC8004**は3つの軽量なレジストリを提案しています。
これらはEthereumのL2ネットワークやメインネット上に単一のコントラクト（singleton）として配置することができます。

#### Identity Registry

これは、エージェントの「**身元**」を示す最小限のオンチェーン識別子を提供します。
技術的には**ERC721**（NFT規格）の拡張であるURIStorageを利用し、各エージェントの登録ファイルへのリンクを保持します。
この仕組みにより、各エージェントは検閲されない、持ち運び可能な一意のIDを持つことができます。
つまり、特定のプラットフォームに依存せずに自身の存在を証明できるようになります。

#### Reputation Registry

このレジストリは、フィードバック情報の投稿や取得を標準化するためのインターフェースを提供します。
スコアリングや集計はオンチェーンとオフチェーンの両方で行われます。

* オンチェーン処理
    透明性と「**組み合わせ可能性（composability）**」を重視し、他のスマートコントラクトと連携しやすくなっています。
* オフチェーン処理
    より複雑なアルゴリズムを用いて分析やスコアリングを行うことができます。

この設計により、専門的なスコアリングサービスや監査ネットワーク、保険プールといった周辺エコシステムが発展できるようになります。

#### Validation Registry

ここでは、第三者による検証（バリデーション）をリクエストし、その結果を記録するための仕組みを提供します。
検証者（バリデータ）は、以下のような方法でタスク結果の正当性をチェックします。

* ステークを担保して再実行する参加者
* zkML（ゼロ知識機械学習）による自動検証
* TEE（Trusted Execution Environment）を使う信頼できるオラクル
* 信頼された審査員（Trusted Judges）

これにより、エージェントが生成した結果が正しいかどうかを客観的に確認できます。

#### 支払いについて

このプロトコルでは、支払いの仕組みそのもの（Payment Protocol）は対象外としています。
ただし、例として「**x402**」という支払い証明（Payment Proof）を利用し、取引の履歴やフィードバックと関連付ける方法を紹介しています。
これにより、エージェントの評価情報がより信頼性を持つようになります。

## 仕様

### Identity Registry

#### 概要

Identity Registryは、エージェントの登録・識別・所有権の管理を行うレジストリです。
技術的には**ERC721**（NFT規格）に **URIStorage**拡張を加えたもので、エージェントをNFTとして登録・管理できます。
NFT対応アプリを通して、すべてのエージェントを即座に閲覧・移転できるようになります。

#### エージェントの識別構造

各エージェントは以下の要素によってグローバルに一意に識別されます。

| 項目               | 説明                                   |
| ---------------- | ------------------------------------ |
| `namespace`  | EVM互換チェーンでは「**eip155**」が使われます。    |
| `chainId`    | 使用しているブロックチェーンのネットワークID。  |
| `identityRegistry` | **ERC721**レジストリコントラクトがデプロイされているアドレス。 |
| `agentId`    | レジストリによって自動で割り当てられるトークンID。 |

ここで `tokenId` は `agentId` と同義です。
`agentId` の所有者がエージェントの所有者であり、**ERC721URIStorage**に基づき、登録ファイルの更新や管理権限の委譲を行えます。

:::message
**EIP155**については以下の記事を参考にしてください。
:::

[\[EIP155\] Ethereumネットワークでリプレイ攻撃を防ぐ仕組みを理解しよう！](/articles/2526432899353e4a0225)

#### トークンURIとエージェント登録ファイル

**tokenURI** はエージェント登録ファイルの場所を指し示します。
URIは `ipfs://` または `https://` など任意のスキームを利用できます。

登録情報が更新された場合、**ERC721URIStorage** の `_setTokenURI()` 関数を使って更新できます。

登録ファイルの構造は以下の通りです。

```json
{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "myAgentName",
  "description": "A natural language description of the Agent, which MAY include what it does, how it works, pricing, and interaction methods",
  "image": "https://example.com/agentimage.png",
  "endpoints": [
    {
      "name": "A2A",
      "endpoint": "https://agent.example/.well-known/agent-card.json",
      "version": "0.3.0"
    },
    {
      "name": "MCP",
      "endpoint": "https://mcp.agent.eth/",
      "capabilities": {},
      "version": "2025-06-18"
    },
    {
      "name": "OASF",
      "endpoint": "ipfs://{cid}",
      "version": "0.7"
    },
    {
      "name": "ENS",
      "endpoint": "vitalik.eth",
      "version": "v1"
    },
    {
      "name": "DID",
      "endpoint": "did:method:foobar",
      "version": "v1"
    },
    {
      "name": "agentWallet",
      "endpoint": "eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb7"
    }
  ],
  "registrations": [
    {
      "agentId": 22,
      "agentRegistry": "eip155:1:{identityRegistry}"
    }
  ],
  "supportedTrust": [
    "reputation",
    "crypto-economic",
    "tee-attestation"
  ]
}
```

この構造により、エージェントは自身の情報（説明・画像・接続ポイントなど）を明示的に公開できます。

**type・name・description・image** は**ERC721**対応アプリと互換性を保つための基本項目です。
`endpoints` では、A2A・MCP・ENS・DID・ウォレットなど、複数の通信・識別手段を登録可能です。
`version` は推奨項目であり、必須ではありません。

エージェントは少なくとも1つ以上の登録情報を持つ必要があります。
`supportedTrust` フィールドが空または欠落している場合、**ERC8004**は「**発見（Discovery）**」のみに使用され、信頼モデルとしては利用されません。

#### オンチェーンメタデータの拡張

このレジストリは**ERC721**に以下の関数を追加し、オンチェーンでメタデータを保持できます。

##### `getMetadata`

```javascript
function getMetadata(uint256 agentId, string key)
```

オンチェーン上に保存された特定のメタデータを取得する関数。
指定したエージェントIDとキーに対応する値を返します。

**引数**

* `agentId`
  * 取得対象のエージェントのID。
* `key`
  * メタデータのキー名。

##### `setMetadata`

```javascript
function setMetadata(uint256 agentId, string key, bytes value)
```

エージェントに関するメタデータを設定する関数。
メタデータを追加または更新し、`MetadataSet` イベントを発行します。

**引数**

* `agentId`
  * 対象となるエージェントのID。
* `key`
  * 設定するメタデータのキー。
* `value`
  * 設定する値。

##### `MetadataSet`

```javascript
event MetadataSet(uint256 indexed agentId, string indexed indexedKey, string key, bytes value)
```

メタデータが設定されたときに発行されるイベント。
エージェントのメタデータが更新されたことを通知します。

**パラメータ**

* `agentId`
  * 対象のエージェントID。
* `indexedKey`
  * インデックスとして使用されるキー。
* `key`
  * 設定されたメタデータのキー。
* `value`
  * 設定されたメタデータの値。

#### エージェント登録関連の関数

新しいエージェントを登録（mint）するための関数が定義されています。

##### `MetadataEntry`

```javascript
struct MetadataEntry {
  string key;
  bytes value;
}
```

メタデータの1項目を表す構造体。
登録時にエージェントに紐づけるメタデータを定義します。

**パラメータ**

* `key`
  * メタデータのキー。
* `value`
  * メタデータの値。

##### `register`

```javascript
function register(string tokenURI, MetadataEntry[] calldata metadata) returns (uint256 agentId)
```

新しいエージェントを登録する関数。
登録ファイルとメタデータを指定してエージェントをmintします。
登録時に `Transfer` と `MetadataSet` イベントが発行されます。

**引数**

* `tokenURI`
  * エージェント登録ファイルを指すURI。
* `metadata`
  * メタデータの配列。

**戻り値**

* `agentId`
  * 新規登録されたエージェントのID。

##### `register`

```javascript
function register(string tokenURI) returns (uint256 agentId)
```

URIのみを指定してエージェントを登録する関数。
メタデータを指定せずに登録し、後から `_setTokenURI()` で追加可能です。

**引数**

* `tokenURI`
  * エージェント登録ファイルを指すURI。

**戻り値**

* `agentId`
  * 登録されたエージェントのID。

##### `register`

```javascript
function register() returns (uint256 agentId)
```

最小限の情報でエージェントを登録する関数。
URIは後から `_setTokenURI()` で追加します。

**戻り値**

* `agentId`
  * 登録されたエージェントのID。

##### `Registered`

```javascript
event Registered(uint256 indexed agentId, string tokenURI, address indexed owner)
```

エージェントが登録されたときに発行されるイベント。
登録が成功した際に、所有者とURIを記録します。

**パラメータ**

* `agentId`
  * 新しく登録されたエージェントのID。
* `tokenURI`
  * 登録ファイルのURI。
* `owner`
  * エージェントの所有者アドレス。

## 補足

**ERC8004**は、既存のエージェント通信系（MCPやA2A）と、Web3側の識別・資産要素（ウォレットアドレス、DID、ENS）を「**オンチェーンから参照できる登録ファイル**」でゆるやかに束ねる設計です。
固定のスキーマに閉じず、拡張可能なエンドポイント一覧をリンクすることで、新しいプロトコルが登場しても差し替えや追加で追随できます。

| 観点 | ねらい       | 仕組み   | 初見の方向け補足   |
| --------- | ----- | ----- | ----------- |
| エージェント通信プロトコル連携 | エージェントの“居場所”と“話し方”を一本化して示すこと。  | Identity Registryの`tokenURI`が指す登録ファイルに、MCP・A2A・ENS・DID・ウォレット等のエンドポイントを列挙します。 | MCPはAIツールやプロンプトを公開する仕組み、A2Aはエージェント同士の認証・メッセージ・タスク管理の仕組みです。ENSは人間可読な名前、DIDは分散IDです。 |
| フィードバック設計   | A2AとMCPの用語（タスク・スキル／ツール・プロンプト）を生かしつつ、評価シグナル構造は自由度を保つこと。 | スコア（0–100）・タグ・外部JSON（IPFS推奨）を組み合わせ、オンチェーン集計とオフチェーン高度分析の両立を狙います。    | 「タグ」は用途や領域などの分類に使い、外部JSONに経緯・結果・支払い証跡を格納できます。    |
| ガススポンサーシップ      | クライアントの事前登録なしで“摩擦の少ない評価投稿”を可能にすること。  | **EIP7702**を活用し、必要に応じてアプリ側が手数料を肩代わりする前提を想定します。        | ガススポンサーシップは、エンドユーザーが手数料を用意しなくても操作できる体験のことです。   |
| インデクシング  | 公開された評価を取り込み、UXを高めること。    | スコア等はオンチェーン、詳細はIPFSを推奨することで、サブグラフ（The Graph系）で効率的に索引化できます。     | 「**Subgraph**」はブロックチェーンデータを検索しやすい形にするインデックスです。        |
| デプロイ戦略 | 各チェーンで単一インスタンス（シングルトン）として展開する前提。   | チェーンAで登録・評価されても、エージェントは他チェーンで動作・取引できます。必要なら複数チェーンに重複登録も可能です。   | 「**シングルトン**」はチェーンごとに“これが正規”という単独のレジストリを置く運用です。   |

:::message
**EIP7702**については以下の記事を参考にしてください。
:::

[\[EIP7702\] EOAをコントラクトアカウントに変換する仕組みを理解しよう！](/articles/13a828c97786aab953e4)

## テストケース

このプロトコルにより、以下のような実装が可能になります。

| 実現したいこと  | 具体像  | 実装のポイント  |
| ---------- | ------------- | ----- |
| エージェントのクローリング       | 中央的な起点から全エージェントをたどり、名前・画像・提供サービス、通信エンドポイント（MCP・A2Aなど）、ENS、ウォレット、対応する信頼モデル（レピュテーション・検証・TEE証明）を発見します。 | Identity Registryで発行された`agentId`から登録ファイルへ辿り、`endpoints`や`supportedTrust`を読み出します。 |
| エージェントエクスプローラ／マーケット | **ERC721**互換アプリで、エージェントの閲覧・移転・管理ができます。  | エージェントは**ERC721**トークンとして表現されるため、既存NFTインフラを再利用できます。   |
| レピュテーションシステム  | スマートコントラクト内で平均スコア等を合成したり、外部で高度な分析を行います。公開シグナルとして再利用可能です。  | オンチェーンのスコア・タグに加え、IPFSの詳細JSONを併用して集計・可視化を設計します。   |
| 検証対応エージェントの発見 | ステーク担保再実行やzkML、TEE検証に対応しているかを確認し、標準化されたインターフェイスで検証依頼を送ります。 | Validation Registryのリクエスト／レスポンスを参照し、検証可否やスコア（0–100）を追跡します。  |

## セキュリティ

**ERC8004**は「**評価・検証のための公共シグナルを整える**」ことに注力しており、単独で全リスクを排除するものではありません。
前提と限界、実務上の対策の方向性を整理します。

| 論点   | 仕様が与える性質 | 留意点（限界） | 実務的な使い方の指針   |
| ------ | ---------- | --------- | ------------ |
| フィードバックの事前許可  | 事前許可（pre-authorization）でスパムを一定程度抑制できます。 | **Sybil攻撃**（多数の偽アカウントで評判を水増しする行為）は残ります。  | レビューワー（クライアント）側の信頼度モデルを別途構築し、レビューワーでフィルタする設計を採用します。        |
| 監査証跡の完全性      | オンチェーンのポインタとハッシュは削除できず、後から改ざんされません。  | 間違ったデータが登録された場合も残り続けます。 | 記録前の検証フローやロールベースの承認、訂正は新たなレスポンスを追記して履歴で示します。  |
| バリデータのインセンティブ | 検証に伴うスラッシングや報酬は、各検証プロトコルに委ねます。  | 本レジストリ単体では経済的誘因を制御しません。 | ステーク設計・報酬配分・不正時のスラッシュは、検証プロトコル側の仕様で厳密に定義します。 |
| 広告された能力の真正性   | 登録ファイルとオンチェーンの対応は暗号的に結びつきます。 | 掲載された機能が実際に動作するか、悪意がないかは本ERCだけでは保証できません。 | 三つの信頼モデル（レピュテーション／検証／TEEアテステーション）を組み合わせ、リスクに応じた保証レベルを選びます。 |

※ Sybil攻撃
    同一主体が多数の偽名アイデンティティを作り、投票や評判を不正に操作する手口です。
※ TEE（Trusted Execution Environment）
    改ざん耐性のある実行環境で、計算の正当性をハードウェア由来の証明で示します。
※ zkML（ゼロ知識機械学習）
    機械学習推論の正しさを、入力やモデルそのものを明かさず暗号学的に証明する手法です。

## 引用

Marco De Rossi (@MarcoMetaMask), Davide Crapis (@dcrapis) <davide@ethereum.org>, Jordan Ellis <jordanellis@google.com>, Erik Reppel <erik.reppel@coinbase.com>, "ERC-8004: Trustless Agents [DRAFT]," Ethereum Improvement Proposals, no. 8004, August 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-8004.

## 最後に

今回は「評判（レピュテーション）と検証に基づき、事前の信頼関係なしでもエージェントを発見し信頼を確立できるプロトコルを提案している**ERC8004**」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

[Twitter @cardene777](https://twitter.com/cardene777)

他の媒体でも情報発信しているのでぜひ他も見ていってください！

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4