SNA と ACP
SNA と Zed Agent Client Protocol の役割の違いを整理します。
ACP は、エディタとコーディングエージェント の間の相互運用プロトコルです。Zed は ACP を、 ACP 対応エディタ環境に任意の ACP-speaking エージェントを接続するための 標準として定義しています。この構造では、エディタが UI を提供し、 エージェントが共通プロトコルで応答します。
SNA が解く問題は別です。SNA は、アプリがネイティブエージェント CLI を バックエンドのように組み込むためのランタイムサーバです。アプリが SNA を ホストし、SNA がエージェントランタイムを spawn して管理します。その上で、 セッションライフサイクル、正規化履歴、権限、HTTP/WebSocket API、React バインディングを提供します。
| 軸 | ACP | SNA |
|---|---|---|
| 主な層 | エディタ-エージェント wire protocol | ランタイムサーバと SDK |
| 主なホスト | エディタまたは IDE | アプリ、Electron アプリ、サービス |
| 中心目的 | 1 つのプロトコルでエディタが複数エージェントをサポートする | アプリがエージェントランタイムをバックエンドとして組み込み、制御する |
| 状態モデル | プロトコルレベルのセッションと更新 | SessionManager、SQLite 履歴、runtime chain、イベントバッファ |
| ランタイム戦略 | エージェントが ACP を公開し、多くの場合アダプタを経由する | SNA は高忠実度のネイティブランタイムアダプタを優先し、ACP 互換性は後から追加できる |
| UI 対象 | エディタネイティブの agent panel | アプリ定義の UI、React コンポーネント、カスタムクライアント |
なぜ ACP は SNA を置き換えないのか
ACP は、エディタとエージェントの N×M 統合コストを下げる点で重要です。 ただし、それは SNA のランタイム制御面を置き換えるものではありません。 SNA は wire protocol の周辺にあるプロダクト上の問題を直接所有する必要が あります。
- マルチセッションライフサイクルとセッションごとのランタイム設定。
- 再起動やランタイム切り替えに耐える正規化履歴。
- Claude Code、Codex、OpenCode 向けのランタイムネイティブ replay アダプタ。
- 異なるネイティブ承認システムを横断する権限正規化。
- 子プロセスライフサイクルやネイティブ SQLite バインディング解決などの Electron 組み込み詳細。
- Web、Node、React アプリ向けの SDK 表面。
SNA が早い段階で ACP だけをランタイム層にすると、ネイティブ制御面に アクセスできなくなったり、ACP ラッパーが必要な機能を公開するのを待つ 必要が出たりします。これは SNA の哲学と合いません。SNA はまずネイティブ エージェントの機能を最大限に使い、アプリが依存すべき境界だけを正規化します。
どう共存できるか
ACP は SNA にとっても有用です。中核の哲学を変えずに、2 つの境界へ 追加できます。
- SNA が ACP を公開できます。 ACP 対応エディタが SNA に接続すれば、 SNA のセッション管理、正規化履歴、ランタイム切り替え、権限モデルを そのまま利用できます。
- SNA が ACP を利用できます。 generic ACP runtime adapter を追加すれば、 対応できるエージェントの幅を広げられます。ただし、深い制御が必要な ランタイムではネイティブランタイムアダプタが高忠実度の経路として残ります。
したがって、意図している関係は「ACP 対 SNA」ではありません。ACP は標準の 互換性表面です。SNA はネイティブエージェントの挙動を保ちながら、 アプリ向けの durable state を所有するランタイム層であり、必要に応じて 境界で ACP を話せます。