ターミナル、コード、またはAIエージェントからQuicknodeを管理できます。CLI、Admin API、MCP、SDKが利用可能になりました。
作成を開始するERC-8257とは?エージェント・ツール・レジストリの解説
ERC-8257とは? イーサリアム・エージェント・ツール・レジストリ、ツールの発見、述語、エージェント・マーケットプレイス、AIインフラに関するガイド。

SOC 2 タイプ II 認証取得 · ISO 27001
2026年6月22日 — 読了時間8分

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