ACP対応エージェントだけを集めた「レジストリ」──認証対応の39件をJSON1本で配布する仕組み

当サイトでは以前、Agent Client Protocol(ACP)そのものの仕組みを解説する記事を公開した。今回はそのACP公式サイトの中でも、まだ扱っていなかった「ACP Registry」というページを開いてみる。これはACP対応エージェントの中でも、特に「認証に対応しているもの」だけを集めた、開発者向けの配布ディレクトリだ。

3行まとめ

1. ACP Registryは、認証プロトコルに対応したACPエージェントだけを厳選して掲載する公式ディレクトリ。curlで確認したところ39件のカードが並んでいた（2026年8月27日確認時点）。
2. 「全ACP対応エージェント一覧(agents.md)」には40件が載っているが、うち17件(AgentPool・AutoDev・Blackbox AI・Bub・Claw Orchestrator・Code Assistant・Construct・Docker's cagent・fount・Hermes Agent・Kaagum・Kiro CLI・localharness・OpenClaw・OpenHands・Raxol・stdio Bus)はRegistry側の39件に見当たらない。認証対応の有無という選別基準の違いが表れている。
3. レジストリはWebページとしてだけでなく、curl https://cdn.agentclientprotocol.com/registry/v1/latest/registry.jsonでJSON形式でも取得できる。このJSONには配布情報が含まれており、クライアント側が自動インストールに使うことを想定した設計になっている。

「掲載されているエージェント」から見える顔ぶれ

Registryページに掲載されている39件をcurlで数えると、コーディングエージェント界隈の主要な顔ぶれが並ぶ。Anthropicの「Claude Agent」(ACP wrapper、バージョン0.70.0)、AI基盤モデル企業Poolsideの「Poolside」、Rust製OSSの「VT Code」(バージョン0.96.14)、Zhipu AIのGLMコーディングプランを使う「GLM Agent」(glm-5.1・glm-5-turbo・glm-4.7・glm-4.5-airに対応、ストリーミングやセッションの保存・分岐・再開に対応と説明文に明記)、MoonshotAIの「Kimi CLI」、Googleの「Gemini CLI」「Google Antigravity」、GitHubの「GitHub Copilot」、xAIの「Grok Build」などだ。

各カードにはバージョン番号とGitHubリンクが添えられており、たとえば「Agoragentic」の説明文は「174以上のAIケイパビリティを持つエージェントマーケットプレイス。Base L2上でUSDC決済されるエージェントサービスを閲覧・呼び出しできる」となっていた。エージェント同士が課金付きで呼び出し合うマーケットプレイス構想が、ACPのエコシステムの中にすでに組み込まれている。

「全エージェント一覧」との差分が意味するもの

ACP公式サイトには、Registryとは別に「全ACP対応エージェント一覧」(agents.md)というページもあり、そちらは40件を掲載している。2つのリストの名称を突き合わせると、Registry側の39件には見当たらないエージェントが17件あった。AgentPool、AutoDev、Blackbox AI、Bub、Claw Orchestrator、Code Assistant、Construct、Docker's cagent、fount、Hermes Agent、Kaagum、Kiro CLI、localharness、OpenClaw、OpenHands、Raxol、stdio Busだ(agents.mdの「Augment Code」は、Registry側の「Auggie CLI」がリンク先ドメインを共有しており同一製品と判断できたため、差分には含めていない)。

Registryページ本文には「これは認証(authentication)に対応しているものだけを含む、厳選されたエージェントの集合だ」と明記されている。つまりこの17件は、ACPプロトコル自体には対応していても、Registryが要求する認証機構をまだ実装していない(あるいは実装しているが未申請の)エージェント群だと推測できる。OpenClawがこの「未掲載17件」に含まれていたのは意外な発見だった。

JSON1本でエージェントを配布する設計

Registryページの「Using the Registry」セクションによれば、クライアントは次のコマンドでレジストリ全体をプログラム的に取得できる。

curl https://cdn.agentclientprotocol.com/registry/v1/latest/registry.json

このJSONには「エージェントのメタデータ全て、自動インストールのための配布情報を含む」とされている。つまりRegistryは人間がブラウザで見るカタログであると同時に、IDEやツール側が定期的にポーリングして「対応エージェントの最新版」を機械的に把握するためのAPIでもある。エージェント開発者が自分のエージェントをここに登録するには、GitHub上のレジストリリポジトリをフォークし、エージェントIDのフォルダにagent.json(公開のスキーマに準拠)を追加してプルリクエストを送る、という手順が案内されていた。

追加で、このregistry.jsonを実際にダウンロードしてPythonで構造を読んだところ、version(スキーマバージョン、1.0.0)・agents(配列、39件)・extensions(配列、0件)という3つのトップレベルキーで構成されていた。ページ上の目視カウントと、JSON側のlen(agents)が39件で完全に一致することも確認できた。

各エージェントのエントリにはid・name・version・description・repository・website・authors・license・distribution(配布方法)・iconが含まれている。配布方法とライセンスを集計すると次のようになった。

ライセンス表記に「Apache-2.0とApache 2.0」「proprietaryとProprietary」という大文字・ハイフンの表記ゆれがそれぞれ存在した。これはおそらく、各エージェント開発者がプルリクエストでagent.jsonを個別に提出する運用のため、表記の統一までは強制されていないことを示している。npxとbinaryの両方に対応しているのはKilo・siGit Codeの2件のみだった。

「認証対応」とは具体的に何を指すか

Registryの選別基準である「認証(authentication)対応」が具体的に何を意味するのか、ACPプロトコル仕様の該当ページを直接確認した。仕様によれば、認証はinitializationの段階で交渉され、エージェントはinitialize応答のauthMethodsフィールドで対応する認証方式を提示する。方式は大きく2種類あるとされる。

• エージェント主導のログイン: クライアントがauthenticate(methodId指定)を呼び、エージェント側がログイン処理を完結させる
• ターミナル認証: クライアントが設定済みのエージェントプログラムをターミナルで起動してログインさせ、成功後に再接続してinitializeをやり直す

さらに、ログアウトに対応するエージェントはagentCapabilities.auth.logoutを提示し、対応しないエージェントに対してクライアント側がlogoutを呼び出すことは仕様上禁止されている(MUST NOT)。

ただし今回確認したregistry.jsonのスキーマには、authMethodsのような認証方式そのものを示すフィールドは含まれていなかった。つまりRegistryは「認証プロトコルに対応していること」自体をフィルタ条件にしているが、各エージェントがOAuthを使うのか、APIキーを使うのか、エージェント固有のログインフローを使うのかは、Registryのメタデータからは分からない。この情報を得るには、エージェントごとに実際にinitializeを呼んでauthMethodsの中身を見るしかなさそうだ。

パッケージレジストリと同じ発想

npmやPyPIのようなパッケージマネージャのレジストリと同様の設計思想を、コーディングエージェントというカテゴリに適用したのがACP Registryだと理解した。エディタ側は「このエージェントに対応している」と個別にハードコードする必要がなく、レジストリのJSONを見に行けば対応可能なエージェントの一覧と最新バージョンが分かる。以前書いたACP自体の解説記事ではLSP(Language Server Protocol)とのアナロジーを使ったが、Registryの仕組みはさらにVS Code拡張機能マーケットプレイスのような「配布層」の比喩のほうがしっくりくる。

「40件」側はまだ手作業集計のまま

registry.jsonを実際にダウンロードして中身を確認したことで、「39件」という数字と配布方法・ライセンスの内訳はJSONの構造から機械的に確認できた。一方で、次の点はなお手作業・推測にとどまっている。

• 比較対象である「全ACP対応エージェント一覧」(agents.md、40件)側は構造化データとして配布されておらず、この記事の「40件」「差分17件」という数字は、curlで取得したMarkdownページ内のリスト項目を目視とgrepで数えた結果のままだ。名称が完全一致しないエントリ(「Codex」と「Codex CLI」、「goose」と「Goose」、「Junie」と「Junie by JetBrains」、「pi ACP」と「Pi」)はリンク先の同一性から同じ製品と判断して差分から除外したが、機械的な突合ではなく手作業での判断であり、見落としの可能性は残る
• 各エージェントの認証方式(OAuth・APIキーなど個別のauthMethodsの中身)は、registry.jsonのスキーマに含まれておらず、ACPプロトコル仕様は認証の一般的な仕組み(エージェント主導ログイン／ターミナル認証の2方式)を説明するのみだった。39件それぞれが実際にどちらの方式を使っているかは、個別にinitializeを呼ばない限り分からない
• ライセンス表記の揺れ(Apache-2.0/Apache 2.0など)から「提出は個別のプルリクエストで、表記の統一は強制されていなさそうだ」と推測したが、これはJSONの見た目から当サイトが推測したものであり、ACP運営側がレビュー基準をどう運用しているかを公式に説明した記述は見つけられなかった

関連記事

• Agent Client Protocol(ACP)とは──コーディングエージェントを「LSPのように」つなぐ標準規格
• Claude Agent SDKを"エディタの共通言語ACP"経由で他IDEに繋ぐZed製アダプタ
• ACP v2はまだ怖くて使えない、と公式が言っている話──Claw Orchestrator