Claude Agent SDKを『エディタの共通言語ACP』に翻訳する──Zed製アダプタが対応する機能を数えてみた

Anthropicの「Claude Agent SDK」は、Claudeをエージェントとして自作アプリに組み込むための公式SDKだ。だがこのSDKをそのまま使うには、独自のインターフェースに合わせて統合コードを書く必要がある。Zed Industriesが公開している「claude-agent-acp」は、この統合作業を「ACP(Agent Client Protocol)」という共通規格1本に肩代わりさせるアダプタだ。GitHub APIで確認したところ、リポジトリは2025年8月27日に作成され、スター数2,431・直近更新は本記事執筆前日の8月27日(2026年8月27日確認時点)。npmパッケージ名は@agentclientprotocol/claude-agent-acp。

3行まとめ

1. claude-agent-acpは、公式のClaude Agent SDKを使ってACPエージェントを実装したアダプタ。ACP対応クライアント(Zed、JetBrains系IDE等)から、Claude Agent SDKの機能をそのまま呼び出せるようにする。
2. READMEに列挙されている対応機能は、コンテキストの@メンション・画像・ツール呼び出し(許可リクエスト付き)・フォロー・編集レビュー・TODOリスト・ネストしたサブエージェントの文字起こし・対話型(およびバックグラウンド)ターミナル・カスタムスラッシュコマンド・クライアント側MCPサーバー・セッション単位の長期目標(goal extension)・構造化エラー/リカバリ/警告(session failure extension)・ツール権限の提示と編集可能な選択肢(permission extension)の13項目。
3. サブエージェントセッションの表示は、クライアント側とのcapability negotiation(機能のすり合わせ)が成立して初めて有効になる。ACP SDKの正式版がまだドラフト段階のclientCapabilities.subagentsフィールドを持たない間は、JetBrains由来の_meta.jetbrains.air.capabilities内のnativeSubagentSessionsという代替シグナルにも対応しており、正式フィールドが利用可能になればそちらが優先される、という移行期特有の設計になっている。

Anthropic公式SDK×Zed製アダプタという組み合わせ

READMEの冒頭は端的だ。「ACP対応クライアントからClaude Agent SDKを使おう」。中身は、公式のClaude Agent SDKを土台にしてACPエージェントを実装したラッパーで、Anthropic自身が作ったものではなく、Agent Client Protocolを開発しているZed Industriesが作っている点に注意が必要だ。ACP公式サイトの「全対応エージェント一覧」でも、「Claude Agent」の項目は「Zed's SDK adapter」への参照として掲載されている。

サブエージェントの文字起こしを「まとめて見せるか、分解して見せるか」

READMEの中で最も技術的に踏み込んでいたのが「Subagent sessions」という項目だ。サブエージェント(エージェントが呼び出す子エージェント)は、クライアントとの機能交渉が双方向で成立した場合にのみ、独立したセッションとして表示される。ACP SDKの正式リリース版がまだドラフト段階のclientCapabilities.subagentsフィールドを実装していない間は、対応クライアントが_meta.jetbrains.air.capabilities内でnativeSubagentSessionsという代替シグナルを掲げることもでき、アダプタ側もこれをinitializeレスポンスに反映する。正式フィールドが使えるようになれば、そちらが優先されるという。どちらのシグナルも無いクライアントでは、Agent/Taskのライフサイクルは従来通りの通常ACPツール呼び出し表現のままとなり、子とのやり取りはルートセッションに留まる。過去の_meta["subagent-transcript"]という機能やforwardSubagentTextセッションオプションを使うクライアントは、フラット化された子の文字起こし挙動を維持する。標準化の途中にある機能を、後方互換性を保ちながら段階的に切り替えていく様子がそのままREADMEに書かれている形だ。

CLAは不要、Apache 2.0で受け付ける

コントリビューションポリシーも明記されている。「このプロジェクトはContributor License Agreement(CLA)を要求しない。代わりに、貢献はApache License Version 2.0でライセンスされることに同意する、法的な権利を持つ作業だけを提出する、CLAを必要としないことを理解している、という条件のもとで受け付けられる」とある。

3つの拡張ドキュメントを実際に開いて読む

READMEは「goal extension」「session failure extension」「permission extension」という3つの拡張の存在をリンクだけで示していたが、docs/配下の各ファイルを実際にcurlして本文を読むと、それぞれ実装レベルの仕様書になっていた。

goal extensionは、セッションに紐づく長期目標（_meta.goal）をset/pause/resume/clearの4アクションで制御する仕組みだ。Claude側では、セッション単位の/goalコマンドがStopフックをインストールする形で実装されており、目標の状態はactive・paused・blocked・limited・completeのいずれかで表現される。ドキュメントは「あるClaudeランタイムのバージョンでは、Stopフックのワークフローを開始しても最初のactive_goalメッセージをSDKストリームに流さないことがある」と明記しており、その場合はアダプタが/goal <condition>を送信した時点で楽観的な最小スナップショットを先に公開する、という回避策も書かれている。

session failure extensionは、エラー・警告をチャットの一時的なバナーではなく「順序を保った文字起こしの一部」として扱う仕組みだ。ワイヤーフォーマットにはid・revision・category・severity・title・details・actionsという7フィールドがあり、ドキュメントは明示的に「phase・source・safeMessage・retryable・retryAfterMs・turnId・リトライカウンタ・プロバイダ固有コードのフィールドは存在しない」と否定形で仕様範囲を区切っている。カテゴリは6種類に整理されており、Claude SDK側の個別のエラー条件がどのカテゴリにマッピングされるかも定義されている。

Claude SDK側では、たとえばauthentication_failedやoauth_org_not_allowedはaccessに、billing_error・rate_limit・max_output_tokensはlimitに、overloaded・server_errorはserviceに、それぞれマッピングされる。未知のSDKエラー種別は自動的にserviceへ「格下げ」され、成功として扱われることはない、とドキュメントは明記している。

permission extensionは、ツール呼び出しの許可リクエストにtitle・descriptionという表示用メタデータを追加するものだ。ドキュメントは「この拡張はACPの許可の仕組みを置き換えるものではない」と明記しており、RequestPermissionRequest.toolCall・options・RequestPermissionResponse.outcomeといった標準ACPフィールドが引き続き権威を持つ、という位置づけになっている。

GitHubとnpmで組織名が食い違っている

この記事を書く過程で気づいたのが、GitHub上のリポジトリはzed-industries/claude-agent-acp名義なのに、npmパッケージ名は@agentclientprotocol/claude-agent-acpとACP側の組織スコープになっている点だ。READMEにもnpmバッジにも矛盾した記載は無く、意図的にACPプロジェクトの公式スコープへパッケージを公開しているのだと読めるが、なぜGitHubリポジトリ自体はZed Industries名義のままなのか、両者の関係については公式の説明を見つけられなかった。

数えた機能は13、動かして試したのは0

この記事の「13項目」という数字は、README本文の箇条書きを実際に数えた結果で、公式側が「13機能」と集計しているわけではない。goal extension・session failure extension・permission extensionという3つの拡張ドキュメントは今回docs/配下のファイルを直接curlして本文を読んだが、実際にZedやJetBrains系IDEからこのアダプタ経由でClaude Agent SDKを呼び出して動作を確認したわけではなく、あくまでドキュメント本文の記述をそのまま紹介している。npmパッケージの実際のダウンロード数やバージョン履歴も、この記事の時点では未確認。session failure extensionのカテゴリ表もドキュメント本文の記述の翻訳であり、実際のエラー発生時にどのカテゴリへ分類されるかを手元で再現して確かめてはいない。

関連記事

• Agent Client Protocol(ACP)とは──コーディングエージェントを「LSPのように」つなぐ標準規格
• ACP対応エージェントだけを集めた「レジストリ」──認証対応の39件をJSON1本で配布する仕組み
• copilot --acpの1行でIDEから呼び出せる──GitHub Copilot CLIがACP対応をパブリックプレビュー化