ERC-8257とは? エージェント ツールレジストリの解説
ERC-8257とは?Ethereum エージェント ツールレジストリ、ツールの発見、述語、 エージェント マーケットプレイス、およびAIインフラストラクチャに関するガイド。

2026年6月22日 — 読了時間8分

AI エージェント は、コードを生成したり、ワークフローを実行したり、外部サービスと連携したりすることができます。
新しいツールを見つけることは、依然としてはるかに難しい。
多くの場合 エージェント は、プロンプト、フレームワーク、API、あるいはマーケットプレイス などを通じて、あらかじめ設定された統合機能に依存しています。 エージェント利用可能なサービスの数が増えるにつれ、このアプローチでは拡張が難しくなってきます。
ERC-8257は、エージェント型ツールやサービスを許可不要な方法で発見・検証する手段を提供します。
このブログでは、ERC-8257とは何か、 エージェント ツールレジストリがどのように機能するか、それがエージェント型インフラストラクチャ全体の中でどのような位置づけにあるか、そしてこのレジストリによってどのような機能が実現されるかについて解説します。
ERC-8257(エージェント Ethereum オンチェーン ツールレジストリ) は、AI エージェント およびツール向けの、許可不要なxml-ph-0001@deepl.internalレジストリを定義するxml-ph-0000@deepl.internal規格の草案です。この規格は、ツールが何であるか、誰が公開したか、そして誰がそれを呼び出すことが許可されているかについて、最小限かつ検証可能な記録を標準化するものです。
2026年4月、OpenSeaのコディ・シアーズ氏とライアン・ゴッズ氏は、AIが エージェント が自律的にツールを発見し、その利用権を購入し、ツールを起動できるようにするため、この標準を提案した。
登録済みの各ツール、またはERC-8257互換の エージェント には、3つの構成要素からなるオンチェーン レコードが設定されます:
作成者住所:発行者。登録時に恒久的に記載される。
メタデータ URI:ツールのオフチェーン・マニフェストへのポインタ
マニフェストハッシュ:説明文に変更がないことを確認する
また、アクセス述語にはオプションの4つ目の構成要素として、ツールを呼び出せるユーザーを決定する契約アドレスが含まれます。
これらを組み合わせることで、ツールメタデータに関する共通の信頼できる情報源が形成され、1つの保証が得られます。それは、取得したマニフェストが、作成者が管理するオリジンから、その作成者が署名したアドレスを用いてコミットしたものであるということです。
ツールレジストリに含まれる目的や構成要素を理解した上で、 エージェント ツールレジストリの目的と構成要素を理解したところで、それらがどのように連携して機能するのか、またflow がどのようなものなのかを見ていきましょう。
ご存知でしたか? ERC-8257 はEthereum メインネット およびBase で公開されており、2026年半ば時点で76のツールがインデックスに登録されています。
ERC-8257には2つのワークフローがあり、具体的には以下の通りです:
レジストリFlow :発行者とレジストリ間の連携。
発見と検証Flow: エージェント、レジストリ、およびツール間の相互作用。
それぞれについて個別に理解していきましょう。
レジストリflow は、ツールの公開方法および検索可能にする方法を規定しています。発行者は、ツールの作成者アドレス、メタデータ URI、マニフェストのハッシュ(およびオプションのアクセス述語)を登録することで、オンチェーン レコードを作成します。このレコードは エージェント 、後で解決および検証が可能となります。
何かが エージェント ツールやサービスを見つけたとき、この発見と検証のプロセスを通じて、 エージェント 読み取っているメタデータに対する信頼を確立します。
レジストリの役割は、 エージェント マニフェスト、発行者、およびアクセス要件が登録されたレコードと一致していることを確認した時点で終了する。
これまでのところ、ERC-8257は単なる一般的なレジストリのように見えますが、オプションの述語セクションこそが、ERC-8257を単なるレジストリ以上のものにする要素なのです。
この エージェント ツールレジストリは、ツールの検出と検証の課題を解決します。しかし、すべてのツールがby で呼び出せるようにすべきとは限りません。 エージェント 呼び出せるようにすべきでも、完全に公開されるべきでもありません。
一部のサービスでは、サブスクリプションが必要な場合があります。また、NFT保有者、法人顧客、あるいは エージェント 特定の評判要件を満たすユーザーに限定される場合があります。
ERC-8257は、「アクセス述語」と呼ばれるオプションのコンポーネントを用いてアクセス問題を解決しています。これは、呼び出し元がツールを使用できるかどうかを判断する外部契約です。
アクセス述語とは、ツール登録に紐付けられた契約アドレスのことです。
ある エージェント ツールを使用しようとするとき、そのツールは述語契約を呼び出し、「この呼び出し元はこのツールにアクセスする権限があるか?」という単純な質問を投げかけることができます。
これで、述語契約は、あるユーザーが エージェント がNFTを所有しているか、サブスクリプショントークンを保有しているか、アクセス料金を支払っているか、許可リストに含まれているか、あるいは評判要件を満たしているかを確認できるようになりました。
レジストリ自体を変更することなく、さまざまなツールを使ってさまざまなポリシーを適用することができます。以下にいくつかの例を挙げます。
ツールの種類 | 述語論理 |
|---|---|
公開API | 常にtrueを返す |
プレミアムリサーチツール | 有効なサブスクリプションを確認する |
エンタープライズサービス | 許可リストへの登録状況を確認する |
NFT限定ツール | NFTの所有権を確認する |
エージェント マーケットプレイス | 支払い条件や信用要件を確認する |
最も重要な点は、ERC-8257がこれらのルールを一切ハードコードしておらず、述語コントラクトをオプションのアドオンとして扱えるようにしていることです。これにより、規格自体は軽量なまま保たれつつ、多様なユースケースに対応できるよう拡張性も確保されています。
ツールレジストリとは何か、 エージェント ツールレジストリとは何か、どのように登録されるのか、 エージェント 検出されるのか、そしてアクセスがどのように制御されるのかがわかりました。では、これを用いて何を作ることができるでしょうか?
by というレジストリ自体は、特に興味深いものではありません。
DNSが重要になったのは、それを通じてウェブサイトを見つけられるようになったからです。パッケージレジストリが重要になったのは、ソフトウェアがそれらに依存できるようになったからです。アプリストアが重要になったのは、ユーザー とアプリケーションを結びつけたからです。
ERC-8257は、 エージェント-アクセシブルなツールのためのディスカバリーレイヤーを構築します。これにより実現される数々の機能について見ていきましょう:
すべてのツールには、検証可能な出所、プログラムによるアクセス、およびオンチェーン の価格ヒントが備わっています。これだけで、プラットフォーム運営者が一切仲介することなく、ツールの発見、アクセス、取引が行われるマーケットプレイス を構築するのに十分です。
ツールプロバイダーは、述語契約を通じて、価格設定、サブスクリプション、トークン所有要件、評判の閾値、またはエンタープライズ権限を定義することができます。この柔軟性により、ディスカバリー層での相互運用性を維持しつつ、さまざまなアクセスモデルが競合することが可能になります。
ERC-8257により、各ツールが個別に検証され、ゲート処理される多段階の エージェント ERC-8257により、各ツールが個別に検証され、ゲート制御される多段階のパイプラインが実現可能になりました。
例えば、ある取引 エージェント 24時間365日稼働のニューススクレイピングツールや予測市場と連携させることが可能です エージェント をTwitter(X)と連携させることも可能です エージェントと連携させることができます。
ERC-8257は、これらの依存関係を特定・検証するための標準的な方法を提供しており、これにより、エージェント ワークフローを、独立したプロバイダー間でより容易に組み合わせて作成できるようになります。
どのプラットフォームも、最終的には同じ課題に直面することになります。それは、独自のサービスディレクトリを維持管理することです。
ERC-8257では、その責任が共有インフラストラクチャに移管されます。ツールプロバイダーは一度公開するだけで済みます。 エージェント フレームワーク、ウォレット、マーケットプレイス 、およびアプリケーションは、同じレコードを利用します。
現在、ほとんどの エージェント 今日のワークフローの多くは、単一の組織またはプラットフォーム内で運用されています。
ERC-8257は、ベンダーとクライアント、クライアントとマーケットプレイス など、組織をまたぐワークフローの実現に向けた道を開きます。
例えば、ある研究機関は エージェント は、登録済みのツールを通じて公開されている独自のデータフィードへのアクセス権を購入することができる。
ERC-8257の仕組みと機能については、これで理解できた。次は、 エージェント 実際に機能させるために必要な エージェント 実際に機能させるために必要な、より広範なスタックを把握することです。
ERC-8257は、より広範な エージェント スタックにおいて、特定の課題、すなわち機能の発見と検証可能な相互作用を解決します。
しかし、 エージェント 相互に連携するためには、依然として識別情報、実行環境、決済インフラ、そして調整が必要となります。
それでは、スタックを組み立ててみましょう。
レイヤー | 質問 | プロトコル |
|---|---|---|
エージェントID | その人物は誰ですか? エージェント? | ERC-8004のIDまたはウォレット |
ディスカバリー | どのような機能がありますか? | ERC-8257 |
アクセス制御 | 誰が利用できますか? | ERC-8257 の述語 |
お支払い | 利用料金はどのように支払われるのですか? | x402, ステーブルコイン |
実行 | ツールはどのように呼び出されるのですか? | MCP、API、 エージェント フレームワーク |
調整 | どうやって エージェント 連携するのですか? | マルチ-エージェント マルチシステム |
このlens により、ERC-8257はAI規格というよりは、むしろインフラのようなものに見えてきます。
登録済みのツールは、MCPサーバーを公開している可能性があります。
述語によっては、アクセスが許可される前に支払いが求められる場合があります。
ある エージェント 本人確認基準を用いて、リクエストの送信者が誰であるかを証明することができます。
これらの責任はいずれも、ERC-8257自体には帰属しません。
この規格の役割は、「どのような機能が利用可能で、それらはどこにあるのか」という、より単純な疑問に答えることにあります。
さて、アーキテクチャは堅牢であり、設計上の選択も妥当です。未解決の課題は、その採用に関するものです。
今日のソフトウェアの多くは、直接的な連携を基盤として構築されています。
開発者はサービスを選び、そのドキュメントを読み、そのAPIに合わせてコードを書き、その関係を長期にわたって維持していきます。
ERC-8257はこれを推進するものではなく、エージェント型インフラストラクチャを別の方向へと導くものである。
機能は実行時に検出可能になります。
アクセスポリシーがプログラムで制御可能になります。
サービスは、人の承認なしに利用することができます。
ERC-8257は、一般的なディスカバリーレイヤーです。一見、些細なインフラのように思えるかもしれません。
DNSはインフラの一部に過ぎませんでした。パッケージレジストリもインフラの一部に過ぎませんでした。アプリストアは、当初は単なるディレクトリとして始まりました。
これからが、さらに困難な挑戦となる。
評判はどのように エージェント 評判をどのように評価すべきか?マーケットプレイス はツールをどのようにランク付けすべきか? 自律システム間の支払い、サブスクリプション、収益分配については、どのような基準で管理すべきか? 組織は、セキュリティを損なうことなく、内部の機能をどのように公開すべきか?
ERC-8257は、これらの疑問に直接答えるものではありません。それは、対話と解決への道筋を切り開くものです。
プロバイダーは、作成者アドレス、メタデータURI、マニフェストハッシュ、およびオプションのアクセス述語を公開して、ツールby を登録します。 エージェント マニフェストを取得し、オンチェーン のレコードと照合して検証を行い、アクセス要件を評価した上で、ツールを起動します。
マニフェストとは、ツールを機械可読形式で記述したものです。これには、機能、エンドポイント、使用要件、および エージェント 、そのサービスを理解し、操作するために必要な情報が含まれています。
いいえ。機械が利用可能なサービスであれば、ERC-8257を通じて登録することができます。この規格はAIを念頭に置いて設計されましたが エージェント を念頭に置いて設計されましたが、API、ソフトウェアサービス、自動化システム、その他のプログラム可能なアプリケーションも、同じディスカバリーモデルを利用できます。
MCPは、ツールの公開および呼び出し方法を標準化しています。ERC-8257は、ツールの検出および検証方法を標準化しています。これら2つは相互に補完し合うものであり、同じ エージェント アーキテクチャ内で併用することが可能です。
開発者 構築可能 エージェント マーケットプレイス、プログラム可能なアクセスシステム、組織横断的な エージェント ワークフロー、サービスディスカバリー層、およびエージェント エコシステムを構築できます。
はい。ToolRegistry コントラクトは、以下の場所にデプロイされています。 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 onEthereum メインネット およびBase でも公開されています。2026年半ばの時点で、76のツールがインデックスに登録されています。このEIPは依然として「Draft」ステータスにあり、最終確定前にインターフェースが変更される可能性があります。
いいえ。レジストリには、メタデータそのものではなく、メタデータへの参照情報が格納されています。ツールの説明はオフチェーンのままですが、オンチェーン に保存されたハッシュ値により エージェント その完全性を検証することが可能です。
2017年に設立されたQuicknode は、開発者 および企業向けに、機関投資家レベルのブロックチェーン インフラストラクチャを提供しています。99.99%の稼働率と、77以上のチェーンに対応したサポート を備え、チーム は妥協のないオンチェーン アプリケーションの構築とスケーリングを実現します。
最新のエンジニアリングに関する知見、製品の最新情報、Web3のニュースを、メールボックスに直接お届けします。
📚 新刊:『金融ソフトウェアの構築』Solanaオプションからパーペチュアルまで、10の完全なプログラムが収録された無料の書籍。
入手する