ACP と acpx で agent を Kubernetes にスケール — Onur Solmaz (OpenCode メンテナ / TextCortex)

AI Engineer Code Summit 2026 / 約 19 分

オヌル・ソルマズ / Onur Solmaz · 05:23 「MCP はモデルにツールを与えるためのもの。 ACP はエージェントとクライアント間のインタラクションを標準化するためのもの」

動画は準備中

AI Engineer Code Summit 2026 における登壇。約 19 分。講師は Onur Solmaz (OpenCode メンテナ、 TextCortex 創業エンジニア)。 OpenCode は sst が公開する OSS coding agent で、 Discord 上の試作 (講演中の旧呼称 CloudBot) 期から数えて 2 回の改名を経て現在に至る。トークは ACP (Agent Client Protocol) と Onur 自身が開発した CLI ACPX、そして TextCortex の Kubernetes operator Sprits の三層を順に紹介する。

Onur は ChatGPT 公開の数ヶ月前から harness を作り続けてきた。初代 codex モデル (davinci-codex-002) 上に JupyterLab 拡張を載せた経験が現在の TextCortex 製品の harness に直結する — 「テセウスの船のように部品を入れ替え続けて、結果として全部入れ替わった」と表現する。 OpenCode との関わりは「CloudBot が最初に Discord に登場した翌日、会社のクラスタに入れた」ところから始まり、現在は agent 相互運用と orchestration に主軸を置く。

ACP は MCP の対偶 — エージェント標準化の二系統

ACP は Zed 発の提案で、 MCP との混同を Onur は冒頭で断ち切る。 MCP はモデルにツールを与える方向の標準。 ACP はエージェント実装を共通インターフェイスで包む方向の標準。

現状の問題提起は明快。 Codex / Claude Code / OpenCode それぞれに対し、 Zed / VS Code / その他のエディタが個別にプラグインを書いている。「重複した作業」という言い方で Onur は片付ける。 ACP に統一すればアダプタは一度書けば済む。競合する仕様として agent-to-agent 用の agent protocol も存在し、 ACP は human-to-agent が建前だが agent から呼ぶ用途にも転用できる。「採用された仕様は全部サポートする、 ACP を選んだのは Zed が Codex と Claude Code のアダプタを最初に書いていたから」と実用判断を明示する。

ACPX — Swiss army knife への漸進的拡張

ACPX の起点は単純な発想。「OpenCode に機能を追加するときは CLI 経由が定石、だったら ACP 用の CLI を作って任意のエージェントをコマンドラインから呼べるようにしよう」。起動の容易さで他のクライアントから独立した呼び出しが可能になる。

その後 ACPX は ATN 風のワークフローエンジンへ拡張中。 OpenCode リポジトリには 1 日 300〜500 件の PR が流入する。「PR が届く、何これと聞く、これが最善の修正かと聞く、ほとんどの場合答えはノー」 — Onur が日常的に繰り返す機械的判定を SOP (Standard Operating Procedure) として ACPX に組み込む。各ステップは JSON で構造化出力させ、 ATN 的に分岐させる。シャローなバグを agent ループで掘る Ralph review-refactor loop については、「設計をさせるな、単純なバグを掘らせろ」という条件付きで採用する。

Discord 駆動開発 — 5 並列の即席 IDE

ACPX 自体は Discord 上で書かれた。 Onur の作業画面では codex-1 から codex-5 までのチャンネルが並び、加えて Claude チャンネルが ACP 機能テスト専用に立つ。「常時 1〜5 体のエージェントと並行で作業している」。略称は TDD (Telegram-Driven Development) 。

「サイドプロジェクト依存症」を自認する Onur にとって AI の効用は明快。平日のスキマと週末に複数の閃きを並行で実装に移し、そのまま出荷できる。 ACPX 自体がその好例で、ロンドン行きの飛行機に乗る前に「ACP のドキュメントを PDF 化してくれ」と Codex に指示し、別チャンネルに転送する形で完成させた。「開発者として、自分が使う道具を磨く時間はないが、利点と欠点は熟知している」という現場感覚が一貫する。

OpenCode の Fire Hose と SOP 自動化

OpenCode への要望流量は急増した。「一夜にして数万人のステイクホルダーが目を覚まして OpenCode を気に入った」 — Onur の表現。 60 件以上の KPR が同時並走、平均 300〜500 件/日の PR が開く。課題は AI スロップを生まずに全員の要望を吸収する仕組みづくり。

ACPX のワークフローエンジンが受け持つのは機械的判定の連鎖 — 意図抽出、実装妥当性評価、コンフリクト解消、 CI の通し直し。「PR が人の目に届く前に解決できる工程は全部解決すべき」。設計判断は人間が握り、表層リファクタとビルド修復は agent に委ねる。「agent は薬を塗布するように generously に当てるべき。自分をループから外し、 agent で解決できる問題は全部 agent に渡す」という方針。

Personal vs Enterprise の分岐と Sprits

Onur の中核主張は「個人エージェントと法人エージェントは今後分岐する」。 PC が職場と自宅で同じだった時代は終わる。法人ではエージェントが消費する推論量が桁違いになり、そこに金が動く。 enterprise OpenCode への期待もそこから来る。

法人で要るのはオンデマンドの使い捨てエージェント。 Slack 上の OpenCode 1 インスタンスでは複数の Slack app を別名・別アイコンで並列起動できない、という制約が boundary を作る。タスクごとに 1 エージェント、終了で破棄、という想定では Kubernetes pod + agent harness + 読み書き + 状態同期 (R-Sync 的、 Dropbox 的) が必要になる。「冗長だが、 OpenCode が示した『フルコンピュータをエージェントに渡すと強い』という方向性に賛同するなら、抽象化として正しい」と Onur。

TextCortex 製の OSS Sprits がこの層を担う。 React 製の Web UI もクラスタ内で動かす。運用例として TextCortex 内のエラー報告フローを Onur は示す — Slack で本番リリース後のエラーを誰かが言及し、「デバッグ用エージェントを起動」と命じると Sprits が pod を立て、別 UI でセッションが続く。 Cognition の Devin が同カテゴリの先行例である点を補足しつつ、 ACP で抽象化されているのでエージェントは差し替え可能、 lock-in は無い、と締めくくる。

編集所見

ACP / ACPX / Sprits の三層は、単体で読むと別物だが、並べると一つの作業仮説に収束する。「個別エージェント実装は標準化で吸収する (ACP)、機械的判定は SOP で自動化する (ACPX)、計算実体は Kubernetes pod で使い捨てる (Sprits)」 — それぞれの層で複雑さを別の場所に逃がす設計。 OpenCode メンテナとしての 1 日 300〜500 PR の現場感覚と、 TextCortex の enterprise SaaS の運用負荷が、同じ抽象階段の上で語られている点が、この talk の特徴。

着眼点

「Cloud Code is my computer に従って — ベテラン側の証言」 (01:30)

Onur は OpenCode 文化の証言者として「私が Peter を追い始めたのは『Claude Code is my computer』を書いた頃」と述懐する。 OpenCode コミュニティの中で「コンピュータをエージェントに渡す」思想がいつから当たり前になったかを示す重要な時系列マーカー。当初「この人は気が触れている、私は自分のマシンを渡さない」と思った人間が、後にその思想を OpenCode のクラスタに採用し、 enterprise 顧客に売る側に回るまでの過程は、業界の常識転換の縮図として読める。

「Open source agents on open source frameworks on Kubernetes」という三段重ね

Talk の表題は ACP / ACPX に絞られているが、中身の主語は「open source agents を open source framework に載せて Kubernetes に置く」という三段重ねの構造。これは Anthropic / OpenAI / Google の SaaS 型 agent と対比される選択。 Frontier model が私有の API 越しにしか動かない現実を前提とした上で、上位層 (harness / orchestration / chat UX) を全て OSS で組み上げる、という Onur の編集判断は、法人 IT 部門の購買判断における新しいデフォルトを提示する。

SOP (Standard Operating Procedure) という日常語の再利用

Onur が ACPX のワークフローを「SOP」と呼ぶのは偶然ではない。「ワークフロー」という抽象度の高い言葉を避け、製造業や medical 業界が使う標準作業手順書という日常語を借りる。エージェントの自動化対象を「人間が機械的に繰り返している判定の連鎖」と定義し直す効果がある。「設計を agent にさせるな、 SOP に従わせろ」 — この re-framing は Ara Khan の slop 警告と同じ系譜にある。

動画の構成

(00:00) オープニング、自己紹介 (OpenCode メンテナ + TextCortex 創業エンジニア)
(01:30) ChatGPT 公開前から harness を作り続けてきた経歴、 OG codex 時代の JupyterLab 拡張
(02:30) CloudBot 時代の Discord 参加、翌日に社内クラスタへ導入
(03:30) Discord 駆動開発 (TDD) のはじまり、 Opus + Codex 電話ゲーム時代
(04:20) 5 チャンネル並列、 codex-1 から codex-5 + Claude チャンネル
(05:23) ACP は MCP ではない、エージェント ↔ クライアント標準化
(06:00) Zed への謝辞、各エディタが個別プラグインを書く現状の重複
(06:30) 競合仕様 (agent protocol / ACP) との位置関係
(07:00) ACPX の起動点、 CLI から Swiss army knife へ
(08:30) OpenCode の Fire Hose、 60+ KPR と 300〜500 PR/日
(09:30) PR 判定の機械的繰り返しを SOP として ACPX に組み込む
(11:00) Ralph review-refactor loop、設計はさせず shallow バグを掘る
(11:45) ATN 風ワークフロー、 JSON 出力で分岐
(12:30) Personal vs Enterprise エージェントの分岐、推論量と金
(13:30) Slack 1 アプリ = 1 エージェントの制約、 multi-agent provisioning の不在
(14:30) Kubernetes pod + harness + 状態同期、 R-Sync 的アプローチ
(15:30) TextCortex Sprits の紹介、 Go operator
(16:30) 運用例: Slack 内のエラー報告 → デバッグ用エージェント起動 → 別 UI でセッション
(17:30) Cognition / Devin への謝辞、 OSS での同カテゴリ実装
(18:30) ACP による lock-in 回避、まとめ

用語集

ACP (Agent Client Protocol): Zed が 2025 年に提唱した、エージェント ↔ クライアント (エディタ / IDE / チャット UI) 間のインタラクションを標準化するプロトコル。 MCP がモデルにツールを与える方向の標準化なのに対し、 ACP は実装の異なるエージェント (Claude Code / Codex / OpenCode 等) を共通インターフェイスから呼べるようにする。 Onur Solmaz が ACP を採用した理由は実用的で、「Zed が Codex と Claude Code のアダプタを最初に書いていたから」。
ACPX: Onur Solmaz が開発した ACP 用 CLI。任意の ACP 対応エージェントをコマンドラインから起動・対話できる。起点は「OpenCode への機能追加は CLI 経由」という運用慣行。開発の過程で ATN 風のワークフローエンジン機能が加わり、 JSON 出力を介して PR レビュー等の SOP を自動化する Swiss army knife へ拡張している。
TDD (Telegram/Discord-Driven Development): Onur Solmaz が冗談で命名した、チャットアプリ越しに Codex / Claude Code 等を駆動する並列開発スタイル。元の Test-Driven Development との被りを承知の上で、「常時 1〜5 体のエージェントと並行作業」を象徴するラベルとして使う。 Onur の作業画面では codex-1 から codex-5 までのチャンネルと、 ACP 機能テスト用の Claude チャンネルが並ぶ構成が標準形。
SOP (Standard Operating Procedure): Onur が ACPX のワークフローを呼ぶときに使う用語。「ワークフロー」という抽象語を避け、製造業や medical 業界が使う標準作業手順書という日常語を借りる。 PR レビューの (1) 意図抽出、 (2) 実装評価、 (3) コンフリクト解消、 (4) CI 通し直し、という機械的判定の連鎖を、設計判断を agent から取り上げた上で自動化する。
Sprits: TextCortex が公開する Go 製 Kubernetes operator (textcortex/sprits)。 ACP 対応エージェントをオンデマンドで Kubernetes pod として起動・破棄するオーケストレーター。 Slack 等のチャットアプリでの会話起点と、 cluster 内で動く React Web UI の両方からのアクセスを提供する。 Cognition の Devin が同カテゴリの先行例で、 Sprits は OSS としての同等抽象を提示する。
OpenCode の Fire Hose: Onur が用いる比喩。 OpenCode が広く採用された結果、 60 件以上の KPR と平均 300〜500 件/日の PR が同時並走する状況。主な課題は AI スロップを生まずに全員の要望を吸収する仕組みづくりで、 ACPX の SOP 自動化はその直接の応答として設計されている。