OpenRig - Claude CodeとCodexを統括するローカルエージェント基盤

Claude CodeとCodexを別々の端末で起動する方法は、少数の短い作業なら分かりやすい。だがセッションが増えると、どの端末が何を担当し、どこまで進み、再起動後に何を立ち上げ直すべきかを人が追う必要がある。OpenRigが管理対象に挙げるのは、このセッションの所在と継続性だ。エージェントの推論や編集機能を置き換えるのではなく、それらを動かす作業体制を定義して扱う。

手動運用では、相手を「いま開いている端末」や「現在の会話」で識別しがちだ。OpenRigのSeatは、これを安定した役割と宛先として表す。たとえばdev-owner@first-projectという宛先は、担当する会話が入れ替わっても保持される。通信相手を役割で指定できるため、会話の存続とチーム内の責務を分けて考えられる。ただし、宛先が安定していることと、作業内容が自動的に引き継がれることは同義ではない。

複数エージェントの運用では、メッセージを届けることと、担当作業を追跡できる形で残すことを混同しやすい。READMEによれば、rig sendで送信してもキュー項目は作られず、担当エージェントが作業を記録する。したがって、OpenRigの通信経路だけでタスク管理が完結するとは考えない方がよい。チームで使うなら、何をメッセージで伝え、何をキューに記録するかを運用として決める必要がある。

RigSpecはPod、メンバー、接続、継続方針などを記述するチームの仕様で、AgentSpecはガイダンスやフックなどを持つ再利用可能な役割定義だ。まず役割と接続を宣言し、rig up <name> --planで起動計画を確認できる。その後のrig up <name>が、定義を実行中のチームへ移す入口となる。構成をファイルとして明示できる点が、端末を一つずつ開いて人が配置を覚える方法との違いである。

READMEの構成図では、CLI、TUI、MCPサーバーが操作の入口となり、Hono HTTPデーモンとドメインサービスが実行状態を扱う。その先に、状態保存のSQLite、端末セッションを担うtmux、Claude CodeやCodexなどに接続するランタイムアダプターがある。rig upはtmuxセッション、エージェントを動かす環境、起動ファイル、準備確認を扱う。各エージェントはアクセス可能なtmuxセッション内でネイティブに動くため、OpenRigはそれらの上位で配置と運用操作をまとめる層と捉えられる。READMEは端末ノードに加え、端末ペイン内のRPCランナーを使うPiアダプターも挙げている。

Podは複数のSeatをまとめ、ガイダンスと文脈を共有する単位だ。一方、それぞれのエージェントのコンテキスト窓は独立している。つまり、同じPodに入れただけで内部状態が一つに統合されるわけではない。役割間の受け渡しには、明示的な通信や作業記録が要る。実行中はrig sendで通信し、TUIやrig psで状態を確認できる。MCPサーバーはrig_up、rig_ps、rig_sendなどの操作をエージェント側にも公開する。

管理下の起動では、Seatの識別子とデーモン接続情報が渡され、選択されたガイダンスやリソースが作業領域に配置される。プロバイダーの信頼設定やフックも書き込まれるため、これは単なるtmuxの起動補助ではない。停止時にrig down --snapshotを使うと構成状態を保存でき、次のrig up <name>では最新のスナップショットから復元を試みる。結果はノードごとに報告される。「復元を試みる」という説明は、すべての会話や作業が必ず元どおりになる保証とは区別したい。

Claude CodeとCodexを役割ごとに配置し、同じリポジトリで継続して使うチームには、共通の宛先、状態表示、通信、復元手順が役立ちうる。各セッションへ直接入れる状態を保ちながら、チーム全体をTUIやCLIから見られるのも特徴だ。手動の端末管理に対しては、役割定義と運用操作の部分を置き換える。一方、単一エージェントによる短い作業では、仕様やSeatを管理する手間の方が目立つ可能性がある。

OpenRigはClaude CodeやCodexそのものの代替ではなく、両者を同じ作業体制に含める運用層だ。READMEはClaude Managed Agentsとの比較で、OpenRigをセルフホストと説明し、選択したモデルプロバイダーの利用料金は別途かかるとしている。したがって比較の焦点は、エージェントの能力差だけでなく、構成と実行状態をどこで管理するかにもある。セルフホストを選ぶ場合、そのローカル環境の設定と継続運用も利用側の仕事になる。

要件はNode.js 22または24、tmux、macOSまたはLinux。ネイティブWindowsは未対応で、WSL2は未検証とされる。Apple siliconではNode.js 22の利用が案内されている。旧React Web UIは保守モードで、サポートはベストエフォートだ。また、v0.6.0のリリースノートは、今回の検証でLinux、Windows、認証済みのネイティブ権限操作を確認できていないと記す。対応環境という記載と、そのリリースで確認された範囲は分けて判断したい。

セットアップと起動は、信頼設定、実行可能なフック、作業領域のファイルを書き換える。rig setup --dry-runでも、後続の自動変更すべては表示されない。Seatの権限モードの選択は将来の起動に適用されるが、表示された選択や起動引数だけで、ネイティブプロセス側の強制まで証明できるわけではない。プロバイダー設定や作業領域への書き込みを制限する環境では適合しにくい。導入評価では、起動計画に加えて、実際の変更先と権限の効き方を確認する必要がある。