AIエージェントを雇う時代の信頼設計: ERC-8004の3つのレジストリが担う役割

AIエージェントを雇う時代の信頼設計: ERC-8004の3つのレジストリが担う役割 cover image

企業がAIエージェントを「雇う」時代が、もうすぐ来ます。

すでに一部の企業では、カスタマーサポート、コード生成、データ分析といったタスクをAIエージェントに任せ始めています。人間の従業員と同じように、エージェントに仕事を発注し、成果物を受け取り、報酬を支払う。そういうワークフローが現実になりつつあります。

ただ、ここで問題が出てきます。「このAIエージェントに仕事を頼んでいいのか？」——そう思ったとき、あなたは何を確認しますか？

人間なら履歴書、面接、リファレンスチェックがあります。でもAIエージェントには、今のところそういう仕組みがありません。ERC-8004 （Trustless Agents）は、この問いに「ブロックチェーンで解決しよう」と提案した規格です。2025年8月にドラフトが公開され、2026年1月にEthereum メインネットへのデプロイが始まりました。

なぜ今、エージェントの「信頼」が問題になるのか

Model Context Protocol （MCP）や Agent2Agent （A2A）のようなプロトコルが整備されたことで、AIエージェント同士が通信し、タスクを委譲し合う基盤は揃いつつあります。

しかし、これらのプロトコルが解決しているのは「どうやって通信するか」です。「誰を信頼するか」は別の問題として残っています。

たとえば、あなたのエージェントが「医療診断を手伝ってくれる別のエージェント」を探すとします。候補が10個あったとして、どれを選びますか？自称「精度99%」のエージェントが本当に信頼できるかどうか、今の仕組みでは確認する手段がありません。

ERC-8004はこの問題に対して、3つのレジストリ（登録・管理の仕組み）を提案しています。

3つのレジストリの役割

Identity Registry: エージェントの身分証明

まず「このエージェントは誰か」を確認できる仕組みが必要です。

Identity Registryは ERC-721 （NFT規格）を拡張したものです。エージェントをNFTとして登録することで、以下が実現します：

グローバルに一意なIDの付与
所有権の移転（エージェントを「売る」「引き継ぐ」ことができる）
エージェントの登録ファイルへのリンク

登録ファイルには、エージェントが対応しているプロトコル（MCP、A2Aなど）のエンドポイントや、サポートしている信頼モデルが記述されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
{
  "name": "myAgentName",
  "description": "医療文献の検索と要約を行うエージェント",
  "services": [
    {
      "name": "A2A",
      "endpoint": "https://agent.example/.well-known/agent-card.json"
    },
    {
      "name": "MCP",
      "endpoint": "https://mcp.agent.example/"
    }
  ],
  "supportedTrust": ["reputation", "tee-attestation"]
}

supportedTrustフィールドが空の場合、このレジストリは「発見」のためだけに使われます。信頼の仕組みはオプションです。

Reputation Registry: 利用者からの評価記録

次に「このエージェントはどれくらい信頼できるか」を確認する仕組みです。

Reputation Registryは、クライアント（エージェントを利用した側）がフィードバックを記録できる仕組みです。評価値はint128の固定小数点数で表現され、タグで意味を付けられます。

タグ	意味	例
`starred`	品質評価（0-100）	`87`
`uptime`	稼働率（%）	`9977`（= 99.77%）
`successRate`	成功率（%）	`89`
`responseTime`	応答時間（ms）	`560`

フィードバックはオンチェーンに記録されるため、改ざんできません。ただし、誰でも投稿できるため、Sybil攻撃（偽アカウントで評価を水増しする攻撃）は防げません。

この点について、ERC-8004の仕様書はこう明記しています：

Sybil attacks are possible, inflating the reputation of fake agents. The protocol’s contribution is to make signals public and use the same schema.
（Sybil攻撃は可能であり、偽エージェントの評判を水増しできる。このプロトコルの貢献は、シグナルを公開し、同じスキーマを使うことだ）

「防げない」と認めた上で、「シグナルを公開することで、誰でも独自の評価システムを作れる」という方向に割り切っています。

実際、getSummary()関数はclientAddresses（信頼するレビュアーのアドレスリスト）を必須パラメータとして要求します。「誰のフィードバックを集計するか」を呼び出し側が決める設計です。

1
2
3
4
5
6
function getSummary(
    uint256 agentId,
    address[] calldata clientAddresses,  // 必須: 信頼するレビュアーを指定
    string tag1,
    string tag2
) external view returns (uint64 count, int128 summaryValue, uint8 summaryValueDecimals)

つまり、「信頼できるレビュアーのリスト」を別途管理する必要があります。これはオフチェーンの仕組みに委ねられています。

Validation Registry: 第三者による検証

評判だけでは不十分な高リスクなタスク（医療診断、金融取引など）のために、Validation Registryがあります。

エージェントが自分の仕事を検証してもらいたい場合、validationRequest()を呼び出します。検証者（バリデーター）は独立したスマートコントラクトで、以下のような手法で検証を行います：

ステーク再実行: 別のエージェントが同じ入力で再実行し、結果を比較
zkML: ゼロ知識証明を使って、推論が正しく行われたことを証明
TEEオラクル: 信頼できる実行環境（Trusted Execution Environment）での検証

検証結果は0〜100のスコアで記録されます。バイナリ（0か100か）でも、段階的なスコアでも使えます。

「信頼のブートストラップ問題」は解決していない

ERC-8004を読んで気になったのは、新しいエージェントがどうやって最初の信頼を獲得するかという問題です。

レピュテーションがないと使われない
使われないとレピュテーションが貯まらない

この循環は、ERC-8004では明示的に解決されていません。Validation Registryで「仕事の質」を証明することはできますが、zkMLやTEEの検証はコストが高く、ピザの注文のような低リスクなタスクには向きません。

仕様書には「信頼モデルはプラガブル（差し替え可能）で、リスクに比例したセキュリティを選べる」と書かれています。低リスクなタスクは評判だけで、高リスクなタスクはValidation Registryを使う、という使い分けが想定されています。

ただ、「低リスクなタスクでも評判がゼロのエージェントは使いにくい」という問題は残ります。これはおそらく、エコシステムが育つにつれて、エージェントのインキュベーター的な仕組みや、初期評判を付与するサービスが生まれることで解決されていくのだと思います。

x402との組み合わせ

ERC-8004はペイメント（支払い）を「直交する問題」として仕様の外に置いています。ただし、x402 （HTTP 402ステータスを使ったマイクロペイメントプロトコル）との統合例が示されています。

sequenceDiagram
    participant Client as クライアント
    participant Agent as AIエージェント
    participant x402 as x402
(決済)
    participant Reputation as Reputation
Registry

    Client->>Agent: 1. タスク依頼
    Agent-->>Client: 2. HTTP 402 (Payment Required)
    Client->>x402: 3. ステーブルコインで支払い
    x402-->>Client: 4. txHash（決済証明）
    Client->>Agent: 5. 支払い証明付きでリトライ
    Agent-->>Client: 6. タスク完了
    Client->>Reputation: 7. フィードバック投稿
(proofOfPayment付き)

フィードバックにproofOfPaymentフィールドを含めることで、「実際にお金を払って使ったユーザーからのフィードバック」として重み付けできます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{
  "agentId": 22,
  "value": 87,
  "valueDecimals": 0,
  "tag1": "starred",
  "proofOfPayment": {
    "fromAddress": "0x...",
    "toAddress": "0x...",
    "chainId": "1",
    "txHash": "0x..."
  }
}

「お金を払って使った人のレビュー」は、無料で使った人のレビューより信頼性が高い、という考え方です。Sybil攻撃のコストを上げる効果もあります。

マルチチェーン対応の設計

ERC-8004はEthereumメインネットだけでなく、任意のL2やBNB Chainにもデプロイできます。エージェントのIDは{namespace}:{chainId}:{registryAddress}という形式で、どのチェーンのどのレジストリに登録されているかを一意に識別できます。

eip155:1:0x742...    # Ethereumメインネット
eip155:8453:0x...    # Base (L2)

エージェントは複数のチェーンに登録でき、登録ファイルのregistrationsフィールドに全ての登録情報を記載します。

ただし、チェーンをまたいだレピュテーションの集約は仕様外です。「Ethereumで高評価のエージェントがBaseでも高評価か」を確認するには、それぞれのチェーンのデータを別途集計する必要があります。

既存のエージェント設計との関係

このブログでは以前、Agentic CLI Design: CLIをAIエージェント向けプロトコルとして設計する7つの原則という記事で、エージェントが安全にCLIを呼び出すための設計を整理しました。

ERC-8004が担うのは、その「前段」の問題です：

問題	担う仕組み
どのエージェントを選ぶか	ERC-8004（Identity + Reputation）
選んだエージェントの仕事を検証するか	ERC-8004（Validation）
エージェントがCLIを安全に呼び出すか	Agentic CLI Design
エージェントに過剰な権限を与えないか	Claude Code Damage Control

「信頼の発見」と「実行の安全性」は別レイヤーの問題で、ERC-8004は前者に特化しています。

まとめ

ERC-8004が面白いのは、「完璧な信頼システムを作ろうとしていない」点です。

Sybil攻撃は防げないと認め、フィルタリングをオフチェーンに委ね、ペイメントは別プロトコルに任せる。その代わりに、「シグナルを公開し、誰でも独自の評価システムを作れる基盤」を提供することに集中しています。

分散システムの設計としては、これは正直な割り切りだと思います。「全部解決する」と主張するプロトコルより、「何を解決して何を解決しないか」を明示しているほうが、実際に使いやすい。

エージェント経済がどこまで広がるかはまだわかりませんが、その基盤として「誰を信頼するか」の仕組みが必要なのは確かです。ERC-8004がその標準になるかどうかは、エコシステムの育ち方次第だと思います。

Fragments of verbose memory

冗長な記憶の断片 - Web技術のメモをほぼ毎日更新