1つのルームに複数のエージェントを配置でき、エージェント間でランタイムを共有する必要もありません。CodexとClaude Codeを同じルームに並べて配置し、それぞれ別のディレクトリ（あるいは順番に同じディレクトリ）を割り当て、個別のhandleと権限モードを持たせつつ、同じ権限付与、承認、監査ログの下で管理できます。どの同僚に相談するかを選ぶのと同じ感覚で、どちらにメンションするかを選べます。
この記事では、それがどのような場面で役立つのか、そして何が変わるのか（実際には想像以上に変わりません）について解説します。
2つのランタイムを使う理由
- タスクごとに異なる強み。 大規模なリファクタリングには一方のランタイムが適しており、小さな修正にはもう一方が素早い、あるいはコードベースによってその逆もある、といった報告がチームから寄せられています。両方を用意しておくことで、依頼する側が最適な方を選択できます。
- クォータ対策。 午後の途中で片方のサブスクリプションの上限に達しても、もう片方のエージェントには空きがあります。ランタイム間でのエージェントの融通は、人同士でエージェントを融通するのとまったく同じ仕組みです。エージェントの融通を参照してください。
- セカンドオピニオン。 一方のエージェントに、もう一方のdiffをレビューさせることができます。どちらの出力も同じタイムライン上に表示されます。
- 別々のディレクトリ。 データパイプラインにはCodex、WebアプリにはClaude Codeを割り当て、同じ3人のメンバーが両方を扱うため1つのルームにまとめます。
ルーム内での見え方
ランタイム名ではなく、pipeline（Codex）やweb（Claude Code）といった明確な名前を持つ2つのエージェントを用意します。メンバーはどちらか一方にメンションします。各エージェントは独立したシリアルキューを保持するため、Codexの長時間のジョブがClaude Codeへのちょっとした質問をブロックすることはありません。それぞれが個別の権限モードを持ちますが、常に一時停止する4つのアクションはどちらにも等しく適用されます。
daemonがマシンにインストールされているランタイムを検出し、そのバージョンを報告します。各エージェントを作成する際に、使用するランタイムを選択します。
エージェント間の参照
リクエストでは、IDによって過去のリクエストに言及できます。「@web, apply the schema change from R-12 to the API models」と指示すれば、Claude CodeエージェントにCodexエージェントの結果がコンテキストとして渡されます。参照されたリクエスト、その出力、アーティファクトが新しい実行に取り込まれるため、手動で貼り付ける必要は一切ありません。リクエストIDと再開可能な実行を参照してください。
共通して変わらないもの
ルームは抽象化レイヤーです。ランタイムはエージェントの詳細にすぎません。
ランタイム間の権限モード
Claude Codeのモードにはplan、default、acceptEdits、bypassPermissionsがあります。Codexにも独自の承認設定があり、提案のみから完全自動まで同様の段階が存在します。ルームではエージェントごとに対応するレベルを選択し、その上にユーザーごとの権限付与が重なります。対応関係の詳細は権限モードの解説を参照してください。
よくある質問
両方のエージェントが同じディレクトリで作業できますか？ 可能です。ただし、各エージェントのキューがシリアルに処理されるのは自身の中だけです。2つのエージェントが1つのリポジトリを同時に編集すると衝突する可能性があります。別々のディレクトリを割り当てるか、時には待機することを許容してください。
両方のサブスクリプションが必要ですか？ 各ランタイムがそれぞれのサブスクリプションを使用します。mutiはどちらもホストしておらず、どちらの請求も行いません。
他にどのランタイムが検出されますか？ Cursorは実装済みで検証待ちの状態です。OpenCode、DeepSeek、Hermesがそれに続きます。ランタイムによってルームのモデルが変わることはありません。
メンバーはエージェントの背後にあるランタイムを確認できますか？ 確認できます。エージェントカードにランタイムとバージョンが表示されます。エージェントに役割に応じた名前を付けておけば、ベンダーではなくタスクに基づいた選択がしやすくなります。
2つのエージェント、1つのルーム、1つの共通ルール。ルームを作成する
公開日