AIエージェントは増えましたが、使う側が最初に知りたいのは性能ではなく「この相手を信じてよいか」です。SolanaのAgent Registryは、その問題に正面から向き合う仕組みです。

https://solana.com/agent-registry

Agent Registryは、AIエージェントに検証可能なID、持ち運べる評価、登録情報を与えるオンチェーンの仕組みです。単に「動くエージェント」を増やすのではなく、「見つけられる」「評価できる」「信頼して接続できる」状態を作ろうとしています。

この記事でわかること
– Agent Registryが何を解決するのか
– ERC-8004とSolanaの関係
– 既存のA2AやMCPと何が違うのか
– どの場面で実用価値が出るのか

エージェント普及で先に壊れるのは信頼です

AIエージェントが業務に入ると、問題は「賢いかどうか」だけでは終わりません。外部ツールを呼ぶ、別のエージェントと連携する、ウォレットやAPIキーに触る、といった行動が増えるほど、相手の正体と実績が重要になります。

今のエージェント運用は、ベンダーの説明、GitHubのREADME、SNSの評判に頼りがちです。これでは、同名の別実装や、実績のない派生プロジェクトを見分けにくいです。業務で使うなら、評価を口約束から構造化データに変える必要があります。

Agent Registryは、まさにこの穴を埋めるための設計です。

何が変わるのか

Solanaの説明では、Agent Registryは「open, onchain protocol」として位置づけられています。要点は3つです。第一に、エージェントごとの識別子を持てること。第二に、利用者のフィードバックや検証結果を蓄積できること。第三に、その情報をネットワークの外ではなくチェーン上で扱えることです。

これにより、エージェントは単発のデモではなく、履歴を持つ参加者として扱えます。たとえば、あるエージェントがどの仕事をこなし、誰から評価され、どの条件で検証されたかを追えるようになります。信頼が「雰囲気」ではなく「記録」になるわけです。

さらにSolanaのページでは、ERC-8004との相互運用性が明示されています。ERC-8004はEthereum側で進む trustless agents の標準で、Identity、Reputation、Validation の3つのレジストリを使ってエージェントの発見と信頼を支える考え方です。Solana側のAgent Registryは、この流れとつながる実装です。

A2AやMCPだけでは足りない理由

A2Aはエージェント同士の会話や連携を進めます。MCPは外部ツールやデータ接続を標準化します。どちらも重要ですが、どちらも「相手が誰か」を保証しません。

ここがAgent Registryの役割です。A2Aが通信路、MCPが接続口だとすれば、Agent Registryは身分証と評判簿です。通信できても、接続できても、相手の由来が不明なら本番利用は難しいです。業務フローに入れるなら、接続の前に信頼の層が必要になります。

この発想は、Web3の文脈に寄りがちに見えますが、実際には一般のSaaS連携にも効きます。営業支援、調査、運用監視、社内申請の自動化など、外部エージェントが増える場面ほど「誰が何をしたか」が重要になるからです。

実運用で効く場面

一番わかりやすいのは、エージェントのマーケットプレイスです。タスクを外部委託する前に、実績のあるエージェントだけを選びたいからです。評価がない相手に重要業務を投げるのは危険です。Agent Registryがあれば、発見と選定の判断材料が増えます。

次に、社内向けの自動化です。たとえば、問い合わせ分類、資料収集、ウォレット操作、承認フロー補助など、複数のエージェントをつなぐ場面では、個々の挙動よりも、どのエージェントがどの権限を持っているかが重要です。IDと評価が見えるだけで、運用の設計がかなり変わります。

さらに、クロスチェーンの連携にも意味があります。Solanaのページでは、EthereumのERC-8004と相互運用できるとされています。エコシステムをまたいで信頼情報を共有できれば、閉じたプラットフォームごとに評価を作り直す必要が減ります。

使い方のイメージ

SolanaのAgent Registryページには、登録、フィードバック、ウォレット設定、Quickstartが用意されています。つまり、これは研究用の概念だけではなく、試せるプロダクトとして出ています。

最初の使い方は単純です。エージェントを登録し、識別情報を発行し、利用後に評価を残す。次に、その評価を元に別のエージェントを選ぶ。この循環が回り始めると、エージェントは「作って終わり」ではなく、「使われて育つ」対象になります。

重要なのは、信頼を一回の審査で固定しないことです。仕事を重ねるほど評価が蓄積される設計なら、実力のあるエージェントが見つかりやすくなります。逆に問題のあるエージェントは、早い段階で見抜けます。

先に見るべき注意点

便利そうに見えても、オンチェーン化すればすべて解決するわけではありません。評価の質が低ければ、レジストリの価値も下がります。悪意ある相互評価や、形だけの登録が増えると、信頼は簡単に壊れます。

また、エージェントの能力と安全性は別です。高評価のエージェントでも、権限設定が甘ければ事故は起こります。Agent Registryは信頼の入口を整える仕組みであって、運用ポリシーや権限管理の代わりではありません。

それでも、入口がないままエージェントを増やすよりははるかに前進です。今後のエージェント活用でボトルネックになるのは、性能差よりも信頼の扱い方です。その点で、SolanaのAgent Registryは重要な一歩です。

まとめ

Agent Registryは、AIエージェントを単なる自動化ツールではなく、識別可能で評価可能な参加者として扱うための基盤です。A2AやMCPが広がるほど、次に必要になるのは信頼層です。Solanaはその答えを、オンチェーンのレジストリとして示しました。