【ITニュース解説】Wiring seven coding agent CLIs into one app: four ways in, and what each can't do

システムエンジニアを目指す初心者の皆さんにとって、開発作業を効率化してくれるAIコーディングエージェントは、日々の業務を大きく助けてくれる存在となるだろう。しかし、現在世の中には数多くのAIエージェントが存在し、それぞれ異なる動作メカニズムを持っている。これらの多様なエージェントを、まるで一つのアプリケーションのように統合し、統一された方法で利用できるようにすることは、技術的に多くの工夫が必要となる。今回紹介するStyxというプロジェクトは、まさにこの課題に取り組んでおり、7つのAIコーディングエージェントと通常のシェルを、同じ開発プロジェクトで一元的に使えるようにしている。

Styxが複数のエージェントを統合する上で直面する主な課題の一つは、外部のプログラムから各エージェントのCLI（コマンドラインインターフェース）を操作する方法が、一つだけではないことだ。実際には、エージェントの種類に応じて4つの異なる方法が存在し、それぞれが独自の特性や制限を持っている。これらの方法を理解することは、システム設計を行う上で非常に重要となる。

一つ目の統合方法は「Streaming JSON」と呼ばれるものだ。これはClaude Codeのようなエージェントで採用されている方式で、CLIがユーザーインターフェースを持たずにバックグラウンドで動作し、その過程で発生するイベントをJSON形式のテキスト行として出力する。Styxのような統合アプリケーションは、このJSONデータをリアルタイムで読み取ることで、エージェントがどのようなツールを呼び出そうとしているのか、どのような許可を求めているのか、そしてその結果がどうなったのかをデータとして正確に把握できる。そして、Styxはエージェントに対する指示やメッセージを同じくJSON形式で書き戻すことで、エージェントとの対話を実現する。この方式は、統合アプリケーション上にエージェントとのチャット機能を構築するのに非常に適している。しかし、エージェントが何らかの処理を実行している最中にメッセージを送っても、そのメッセージは現在の処理が完了するまで保留されてしまい、即座に反応を返せないという制限がある。

二つ目の方法は「App Server」を利用する方式だ。Codexというエージェントがこの方式で動作する。Codexは通常のCLIとして直接実行されるのではなく、「codex app-server」というコマンドでアプリケーションサーバーとして起動する。Styxはこのサーバーが提供する独自のプロトコルを通じて、Codexと通信を行う。なぜこのようなサーバー経由での通信が必要かというと、Codexの持つターミナルベースのUIは、pty（擬似端末）を介して直接メッセージを受け取ることができないため、ターミナルとして操作することが難しいからだ。このApp Server方式の大きな利点は、エージェントが処理を実行している「ミッドターン」（途中の段階）であっても、Styxからメッセージを送ることで、即座にエージェントの処理の方向性を調整させられる点にある。ただし、このプロトコルはCodex専用であり、他のエージェントでは利用できないという制約がある。

三つ目の方法は、「ACP（Agent Client Protocol）」という、エージェントとクライアント間の共通プロトコルを利用するものだ。Gemini CLI、Cursor、OpenCode、Gooseといった複数のエージェントがこのプロトコルに対応している。ACPは、ネイティブなチャット機能、ユーザーに許可を求める際に表示されるカード形式のUI、利用するAIモデルの選択、そしてMCP（Multi-agent Coordination Protocol）といった、複数の高度な機能を提供し、単一のランナー（エージェントを実行するプログラム）からこれらを一元的に制御できる。Cursorのエージェントは、もしACPが利用できない状況の場合、「--print stream-json」というオプションを使って、最初のStreaming JSON方式にフォールバックすることも可能だ。また、古いバージョンのGooseでは、ACPに対応していないため、代わりにターミナルとして動作するケースもある。この方式で利用できる機能は、各エージェントがACPをどこまでサポートしているかに大きく依存するため、利用するエージェントの対応状況を確認する必要がある。

四つ目の方法は、最も基本的とも言える「Terminal（ターミナル）」を直接操作する方式だ。Ampというエージェントや、ごく一般的なシェルがこの方式で利用される。Ampの場合、その出力ストリームからは、外部プログラムが承認要求に答えるための明確な方法が提供されていない。そのため、Ampの対話的なUIはpty（擬似端末）上で実行される。ユーザーはStyx内の「Terminal」タブを開き、そこでAmpが提示するプロンプトに直接答える必要がある。この方式の利点は、エージェントが持つフル機能のユーザーインターフェースを、そのまま利用できる点にある。しかし、Styxのような統合アプリケーションから見ると、ネイティブなチャットカードの表示や、処理中にモードを切り替えるライブモード、バックグラウンドでのタスク実行といった、より高度な連携機能を実現することは難しい。

Styxの内部では、小さなルーターが各エージェントの実行方式を自動的に判断し、上記4つのうち適切な方法でエージェントを起動・接続している。このルーターより上位の機能は、全てのエージェントがまるで一つの統一されたセッションであるかのように操作できる設計となっている。

このように複数の方式が存在するため、それぞれには特有の「できないこと」がある。Streaming JSON方式では、ネイティブなチャットやツール呼び出しをデータとして扱える一方で、エージェントが処理中のミッドターンで送られたメッセージは、現在のターンが終了するまで保留されてしまう。App server方式は、ネイティブなチャットやミッドターンでのメッセージ送信が可能で、機能的な欠点も少ないが、Codex専用のプロトコルであるため、他のエージェントでは利用できない。ACP方式は、ネイティブチャット、許可カード、モデル選択、MCPといった機能を提供するが、その利用範囲はエージェント側のACPサポート状況に左右される。Terminal方式では、エージェントの完全なUIを利用できる反面、ネイティブなチャットカードの表示、ライブモードの切り替え、バックグラウンドタスクといった統合アプリケーションならではの高度な連携は難しい。Styxでは、Claude Code、Gemini CLI、Cursorのエージェント、OpenCodeに対してミッドターンでメッセージを送っても、それはターンが終了するまで待機する。しかし、Codexはミッドターンメッセージをすぐに受け入れて処理を調整できる。Styxのチャット入力欄には、他のエージェント向けに「今すぐ送信」ボタンが用意されており、ターンが終了するのを待たずにメッセージを送る選択肢も提供されている。

エージェントのデフォルト設定も統一されていないため、注意が必要だ。例えばGooseは、特に指定がない限りツール呼び出しを自動的に承認する動作をする。そのためStyxでは、Gooseのモードをプロセスごとに細かく設定し、デフォルトではツール呼び出しに対してユーザーに許可を求めるようにしている。また、編集を自動で受け入れるモードや、全てを自動で処理するモードなども設定できる。チャット専用のモード（例えば計画を立てるだけで具体的な作業はしない、あるいは何も尋ねない）では、全てのツールが無効化され、データの読み込み操作も含まれない。Ampのエージェントも同様に、計画モードや何も尋ねないモードでは、データの読み込み操作を含め全てのツールを拒否する。これらの設定は、ユーザーが個別に設定しているエージェントのコンフィグとは別のレイヤーで適用される。このように、CLIのデフォルトのツール呼び出し動作を事前に確認することは、エージェントを統合する上で非常に重要となる。

ターミナル操作に関する細かな点も、開発に時間を要する要因となることがある。例えば、TUI（テキストベースのユーザーインターフェース）は単なるチャットとは異なる。複数行にわたるメッセージを入力する際には、「ブラケットペースト」という特別な機能を使って入力する必要がある。これは、単なる改行が「メッセージを送信」と解釈されてしまわないようにするための工夫だ。StyxのTerminalタブは、アプリケーションが起動したプロセスに直接アタッチされるため、過去のログ（バックログ）の確認、キーボードでの承認操作、そしてアプリケーションを再起動してもプロセスが維持されるといった利点がある。

また、エージェントのログイン状態の確認が、常にオフラインで行えるわけではないという課題もある。GooseやAmpの場合、ユーザーの「検証」ステップが「未検証」のままとなることがある。Ampにはオフラインでユーザーが誰であるかを尋ねる手段がなく、Gooseのプロバイダーチェックは、AIモデルの実行（つまり、利用料金であるトークンの消費）を伴うことがある。正直なところ、このような状況では、ユーザーにその状態を伝えつつも、タスクの開始は許可することが最善の判断となるだろう。

エージェントをテストする際には、実際のエージェントサービスを使わずに済む工夫もされている。Styxでは、全てのエージェントに対して「フェイクCLI」（実際の機能は持たないが、あたかも本物のように振る舞うテスト用のCLI）を用意している。エンドツーエンドのテストを実行する際には、フェイクのclaude、codex、geminiといったバイナリをシステムのPATH環境変数の先頭に配置することで、実際のエージェントプロバイダーや実際のアカウントと通信することなく、テストを実行できるようにしている。

これらの経験から、新しいエージェントを統合する際の重要なチェックリストが導き出されている。 一つは、そのエージェントがミッドターン（処理途中）でどのように入力を受け取るかを確認すること。 次に、承認要求が外部から応答できるのか、それともターミナル内でのみ可能なのかを確認する。 そのエージェントのデフォルトの許可モードは何で、プロセスごとに設定できるのか。 トークンを消費せずに、そのエージェントが誰としてサインインしているかを確認する方法はあるか。 そして、エージェントを実行するランナーコードを実装する前に、フェイクCLIを先に作成すること。これらが今後のエージェント追加における重要な教訓となる。

StyxはApache-2.0ライセンスでオープンソースとして公開されており、新しいエージェントを追加するための詳細なステップバイステップガイドも提供されている。GooseやAmpもこのガイドに沿って追加されたエージェントだ。システムエンジニアを目指す皆さんにとって、このような複数のシステム連携の課題と解決策を学ぶことは、将来のキャリアにおいて貴重な経験となるだろう。