Claude CodeとCodexをチーム化するOpenRigの仕組み

Claude Code と Codex を並行して使い始めると、手元のターミナルはすぐに散らかります。実装用のセッション、レビュー用のセッション、調査用のセッション。タブが増えるほど「どのセッションが何を担当していたか」が分からなくなり、マシンを再起動すれば積み上げた文脈はまとめて消えてしまいます。

単一ハーネスの SubAgent 機構を使えば 1 つのエージェント内部での分業はできますが、Claude Code と Codex のようにハーネスをまたいだチームは組めません。かといって tmux のペインを手で並べる運用は、席が 3 つを超えたあたりから管理コストが急に跳ね上がります。「エージェント本体」ではなく「エージェントが作るチーム」を管理する層が、そもそも手元に存在していないわけです。

OpenRig は、この欠けている層を埋めることを目的としたオープンソースのマルチエージェントハーネスです。YAML でチーム構成（トポロジ）を宣言し、rig up で tmux 上に一括起動し、rig down --snapshot で状態を保存して名前から復元します。README の冒頭にある「A harness wraps a model. A rig wraps your harnesses.」という一文が、責務の線引きをそのまま表しています。

本記事は、2026年10月14日時点で公開されている README・公式ドキュメント・公式サイトの記述に基づき、OpenRig の仕組み、導入要件、マシンへの変更点、類似 OSS との違いを整理します。インストールや実行による動作検証は行っておらず、すべて公開ドキュメントを一次情報とした内容です。採用可否を判断するための材料として読み進めてください。

OpenRigとは｜Claude CodeとCodexを1つのチームとして扱うOSS

OpenRig は、複数の AI コーディングエージェントを「永続的で組織化されたチーム」として運用するための自己ホスト型ソフトウェアです。公式サイトでは、Claude Code・Codex・Pi を使った永続的なコーディングエージェントチームの実行環境として位置づけられており、数週間から数ヶ月続くプロジェクトを想定しています。

README の「What It Does」では、OpenRig の責務が次のように説明されています。管理するのはエージェントそのものではなく、エージェントを同時に走らせたときに生まれるシステム、つまり「どのセッションが動いているか」「それらがどう関係しているか」「再起動後にどう復旧するか」「ターミナルの散乱（terminal sprawl）をどう防ぐか」です。

使い方のイメージとしては、lead エージェント（operator）に達成したい成果を伝えると、operator が各チームの専門エージェントへ委任し、作業を追跡して、結果と判断が必要な事項を手元に返してくる、という流れになります。公式ブログでは「the Terraform for Coding Agents」という自己表現も使われており、チーム構成をファイルで宣言するという設計思想が前面に出ています。

ハーネスとrigの違い

OpenRig を理解する上で最初に押さえるべきは、「ハーネス」と「rig」の階層関係です。

• ハーネス（harness）: Claude Code や Codex のように、モデルを包んで対話・ツール実行を可能にする単体のエージェント実行環境
• rig: 複数のハーネスを包み、役割・アドレス・通信経路・永続化ポリシーを与える上位レイヤー

この区別があるため、OpenRig は Claude Code や Codex を改造しません。README の記述によれば、各エージェントは attach 可能な tmux セッション上で、出荷状態のまま動きます。つまり OpenRig を入れても、個別のエージェントに直接触りたくなったときは、いつもの tmux セッションとして入っていけるわけです。この「ネイティブセッションを隠さない」という性質は、後述する類似 OSS との違いを考える際にも重要な軸になります。

リポジトリの基本情報とメンテナンス状況

採用判断の前提となるリポジトリの基本情報を整理します。以下は 2026年10月14日時点の GitHub API 取得値です。

ライセンスは Apache-2.0 で、特許条項を含む寛容型ライセンスです。商用プロジェクトでの利用条件を検討する際は、後述する claude-squad（AGPL-3.0）との差が判断材料になります。

最終更新が記事執筆日の前日であることから、現時点ではアクティブに開発が進んでいる状態と読み取れます。ただし機能ごとの成熟度には差があり、README では旧 React 製 Web UI が maintenance mode（best-effort サポート）であること、Slack 連携の rig slack manifest が experimental であることが明記されています。全機能が同じ水準で安定しているという前提は置かないほうが安全です。

OpenRigが解決する「ターミナルセッションの乱立」

README は OpenRig が解く課題を、AI コーディングエージェントを「a pile of terminal sessions（ターミナルセッションの山）」から「persistent, organized team（永続的で組織化されたチーム）」へ変えることだと表現しています。裏返せば、OpenRig の射程に入るのは次のような困りごとです。

• 複数エージェントのセッションが並行して走っているが、関係性が可視化されていない
• 再起動やセッション切断のたびに、どのエージェントが何をしていたかを人が思い出して組み直している
• 役割分担（実装・レビュー・QA）をその場の口頭指示で与えており、再現性がない
• エージェント間の受け渡しが、人のコピーアンドペーストに依存している

README の「What It Does」は、これらに対する機能を 9 つの動詞で整理しています。

注目したいのは、Define と Snapshot が揃っていることです。チーム構成を宣言的に定義でき、かつ稼働状態を保存・復元できるため、「毎回 tmux を手で組み直す」工程そのものが設計上なくなります。

既存セッションを捨てずに取り込む

導入のハードルを下げる仕組みとして、Discovery が用意されています。README によれば rig discover が既存の tmux セッションをフィンガープリントし、rig adopt がそれらを管理下に置きます。

これは「OpenRig を試すために、今動いている Claude Code / Codex のセッションを一度全部落とす」必要がないことを意味します。進行中の作業を抱えた状態でも段階的に移行できる設計になっている点は、既存の運用が回っているチームにとって実務上の意味が大きい部分です。

人が手入力する席を守るtyping guard

マルチエージェント基盤を手元で動かすとき、現実的に困るのが「人が入力している最中のペインに、自動メッセージが割り込んでくる」問題です。OpenRig はこれを seat 単位の typing guard として扱います。

README の記述では、rig seat set-typing-guard <seat> --enabled true --reason <text> を設定した seat に対しては、自動メッセージがそのまま打ち込まれるのではなく保留され、代わりに wake（起床通知）が行われます。既定ではオフで、必要な seat にだけ明示的に有効化する運用です。人とエージェントが同じ tmux を共有する前提で設計されていることが、こうした細部に表れています。

OpenRigのアーキテクチャ｜ローカルデーモンとtmuxで動く構造

OpenRig は、ローカルで動作する daemon と CLI・ターミナル UI・MCP サーバーの組み合わせで構成され、その基盤に tmux を使います。README の「How It Works」には、以下の構成が示されています。

CLI / TUI / MCP
      |
Hono HTTP daemon
      |
  Domain services
      |
  SQLite + tmux + runtime adapters

出典: mvschwarz/openrig README「How It Works」（引用は改変していません）

各層の役割は README で次のように説明されています。

• CLI: 人とエージェントの双方が使うコマンド群。チームの起動、状態の確認、メッセージ送信、担当作業の追跡、コンテキスト管理を担う
• TUI: トポロジエクスプローラ。テーブルビューとグラフビュー、seat 詳細、Specs・Projects・Terminals・Feed・System を持ち、キーボード・マウス・コマンドバーで操作する
• MCP: エージェント自身が自分たちのトポロジを操作するためのツール群（rig_up / rig_ps / rig_send / rig_chatroom_send など）
• Runtimes: ネイティブの Claude Code / Codex セッション、terminal node、および RPC runner 経由の Pi と Oh My Pi

この構成から読み取れる判断材料は 2 点あります。

1 点目は、完全にローカル完結であることです。状態は SQLite に、実行基盤は tmux に乗っており、外部のマネージドサービスにトポロジを預ける構造にはなっていません。ローカル完結を要件とする環境では評価しやすい一方、CI のような非対話環境で完結させたいケースとは前提が噛み合いません。tmux が必須である点も、環境制約として最初に確認すべきところです。

2 点目は、MCP 経由でエージェント自身がトポロジを操作できる点です。人が CLI を叩いてチームを組み替えるだけでなく、lead エージェントが必要に応じて席を増やす・メッセージを送るといった操作を自分で実行できます。チーム運用の自律度をどこまで上げるかは、この MCP ツールをどの seat に許可するかという設計問題に落ちます。より詳細な構成は公式ドキュメントで確認できます。

RigSpecでエージェントチームをYAML定義する

OpenRig の差別化点が最も明確に出ているのが、RigSpec と呼ばれる YAML の宣言的定義です。公式の RigSpec リファレンスには、最小構成の例として次の内容が掲載されています。

version: "0.2"
name: my-rig

pods:
  - id: dev
    label: Development
    members:
      - id: build
        agent_ref: "local:agents/impl"
        profile: default
        runtime: claude-code
        cwd: "."
    edges: []

edges: []

出典: RigSpec Reference（Minimal Valid Example）（引用は改変していません）

構造はシンプルです。pods の下に members を並べ、各 member に agent_ref（エージェント設計図の参照）、runtime（claude-code か codex か）、profile、cwd（作業ディレクトリ）を与えます。runtime が member 単位の属性であることが重要で、これにより同一の rig の中に Claude Code の席と Codex の席を混在させられます。Claude Code と Codex を 1 つのチームとして扱う、という OpenRig の主張は、この 1 行に支えられています。

完全版の例では、さらに culture_file（チームの協調規範を書く CULTURE.md）、startup（起動時に配布するガイダンスファイル）、continuity_policy（コンパクション前・シャットダウン前の同期トリガーや復元プロトコル）、services（Docker Compose によるサービス同梱）といったフィールドが使えることが示されています。なお同リファレンスは、冒頭で「0.6.6 cut 2620dea8 に対して 2026-10-07 に検証した」と検証時点を明記しています。バージョンによってスキーマが変わり得る領域なので、RigSpec を書き始める前に同ドキュメントの最新版を参照するのが確実です。

SeatとPod — 会話が入れ替わっても残るアドレス

RigSpec を読み解くうえで鍵になるのが、Seat と Pod という 2 つの概念です。README の Key Concepts では次のように定義されています。

• Seat: rig の中の安定した役割とアドレス。例として dev-build@starter のような形式が挙げられています。その席を占めている会話（セッション）が入れ替わっても、識別子と、その席が書き残した文脈は維持されます
• Pod: ガイダンスとコンテキストを共有する、関連する seat のグループ。ただし各エージェントのコンテキストウィンドウは個別に保たれます

この設計が効いてくるのは長期プロジェクトです。会話が長くなればコンテキストは限界を迎え、セッションを作り直すことになります。従来はそのたびに「誰が何を担当していたか」が失われますが、Seat というアドレスが先に存在していれば、新しい会話はその席に着くだけで済みます。役割と文脈をセッションから切り離すという考え方が、永続的なチーム運用の土台になっています。

スナップショットと復元

永続性のもう一方の柱が Snapshot / Restore です。README によれば rig down --snapshot が状態を丸ごと記録し、rig up <name> が最新のスナップショットから復元します。

実務上注目すべきなのは、復元結果がノード単位で報告される点です。README が挙げている結果の種類は、resumed（再開できた）、fresh-primed（新規に立ち上げ直して文脈を注入した）、awaiting-decision（元の会話を再開できないため --fresh を選ぶ必要がある）、attention_required、failed です。「全部復元できました」という曖昧な成功報告ではなく、どの席が本当に継続できたのかが区別されるため、復元後に何を確認すべきかが明確になります。

RigBundleでトポロジを配布する

チーム構成を自分のマシンだけで使うのか、他のメンバーやリポジトリへ配るのかは、採用設計に影響します。OpenRig はこれを RigBundle という形式で扱います。

README の Key Concepts では、RigBundle は AgentSpec を vendoring（同梱）し、SHA-256 の整合性情報を持つ可搬アーカイブと説明されています。rig up / rig bundle create / inspect / install は GitHub のフォルダリンクも受け取れ、共有前のチェックには rig bundle check、インストール前の内容確認には rig bundle inspect が用意されています。第三者が公開したトポロジを導入する前に「何が実行されるのか」を確認できる導線が、仕様として組み込まれているかたちです。

組み込みチーム（starter / workshop / factory）の使い分け

ゼロから RigSpec を書く必要はなく、README では段階的に大きくなる 3 つのチームが紹介されています。どれを選ぶかは kernel operator（手元の operator エージェント）が相談に乗る設計です。

これに加えて専門チームも同梱されています。README が挙げているのは code-review（独立した 2 つのレビュー）、research（analyst と synthesizer）、pm（product lead・researcher・builder）です。ライブラリ全体は rig specs ls で一覧できます。

起動の流れは次の形で README に示されています。

rig specs preview factory --kind rig
rig up factory

出典: mvschwarz/openrig README「Teams」（引用は改変していません）

rig specs preview で中身を確認してから rig up で立てる、という 2 段構えです。初めて使うチーム定義を、内容を見ずに起動しない運用ができるようになっています。

もう 1 つ特徴的なのが secrets-manager です。README の「Agent-Managed Software」では、rig がエージェントだけでなく稼働するソフトウェア本体を同梱できることの例として、専門エージェントが運用する HashiCorp Vault インスタンスが挙げられています。この種のサービス同梱 rig を使う場合は Docker が必要になります。

OpenRigの導入要件と主要コマンド

導入可否の判断で最初に突き合わせるべきは環境要件です。README の「Requirements」には次の内容が記載されています。

必須要件

• Node.js 22 または 24（当該リリースでのサポート対象。Node 20 はサポート対象外、Node 26 その他は未テスト）
• tmux
• macOS または Linux。Windows は WSL2 経由のみサポート（ネイティブ Windows は非対応）

任意要件

• herdr または cmux（エージェントの端末をまとめて表示するターミナルワークスペース）
• Docker（サービス同梱 rig・managed apps 用）

README には補足の注意事項もいくつか明記されています。Apple silicon の Mac では Node.js 22 を使うこと、Linux ではディストリビューション同梱の Node.js が古い場合がある（Ubuntu 24.04 は 18）ため nvm や NodeSource でサポート対象バージョンを入れること、そして WSL2 では OpenRig の自動テストがまだ走っていないことです。Windows 環境での本格利用を検討する場合、この点はリスクとして見積もる必要があります。

インストールは 1 コマンド版と段階実行版の 2 経路が用意されています。段階実行版は README に次の形で記載されています。

npm install -g @openrig/cli
rig setup --dry-run

出典: mvschwarz/openrig README「Install and first run」（引用は改変していません）

1 コマンド版は v0.6.8 リリースの install スクリプトを curl で実行する形式で、Node.js と npm を確認し、@openrig/cli を導入し、Node.js と SQLite のチェックを行ったうえで rig setup --dry-run と rig setup を順に走らせます。--dry-run を付けた 1 行目はプランを表示するだけで何も変更しません。

プロバイダの選択は rig setup --providers claude|codex|both で渡します。README には、1 コマンド版は選択を知り得ないため両方をインストール・チェックしてしまう旨が書かれており、片方のプロバイダだけを使う場合は段階実行で --providers <choice> を指定するよう案内されています。追加のサブスクリプションは不要で、すでに持っているアカウントを再利用する前提です。

運用で頻度が高いコマンドは次のとおりです。

ここで落とし穴になりやすいのが rig send の扱いです。README の記述では、rig send 自体はキュー項目を作らず、タスクとして記録するのは受け取った builder 側です。公式サイトの説明でも、rig send は追跡タスクを作らない直接の質問、rig queue は名前付きエージェントへの追跡付き割り当てと役割が分けられています。「送ったのに誰も担当していない」という状態を避けるには、この区別を運用ルールに落とす必要があります。導入手順の詳細は公式の Getting startedにまとまっています。

Node 20からの移行と非サポート化

既存の Node 20 環境で検討している場合は注意が必要です。README の「Upgrading an existing instance」には、0.6.0 以降は Node.js 22 または 24 が必要であり、Node 20 から移行する場合は Node を切り替えてから CLI を再インストールする手順が記載されています。背景には、同梱される SQLite モジュール（better-sqlite3）が Node 22 以上を要求するという事情があります。

また、npm 11 以降では postinstall スクリプトがスキップされ、npm warn install-scripts が表示される場合があることも明記されています。この場合でも CLI は動作しますが、Node.js と SQLite のチェックが実行時に走らないため、README では手動でチェックスクリプトを実行する方法も案内されています。Bun でグローバルインストールする場合も postinstall がブロックされ得る点は同様です。

なお、稼働中のインスタンスをアップグレードする場合は openrig-upgrade スキルの手順に従う形になっており、README は rig down がアップグレード手順ではないことを明示しています。

ターミナルワークスペース（herdr / cmux / 素のtmux）

OpenRig の TUI はチームの協調状態（誰がどの席でどういう状態か）を見せるもので、エージェントの端末そのものを並べて見せる役割は分離されています。README では、その表示を担うのが herdr と cmux だと説明されています。

herdr を導入して接続すると rig terminal open starter --provider herdr のようにまとめて端末を開けます。cmux の場合は --provider cmux を指定します。TUI の rig 詳細ビューからも端末ビューを開けて、herdr が入っていればそのレイアウトで（1 タブあたり最大 16 席）、入っていなければ素の tmux で表示されます。attach できない席は absent または degraded として報告され、いずれの場合も元のセッションは tmux 経由でアクセスできます。

つまり herdr や cmux は必須ではなく、入れなくても素の tmux で同じレイアウトが使えます。表示の快適さと導入するツールの数のトレードオフとして判断できる部分です。herdr 単体の仕組みについては別途整理しています。

導入前に把握すべきマシンへの変更点

ここが OpenRig を評価する際に最も時間をかけるべきセクションです。README には「What OpenRig changes on your machine」という独立した章があり、OpenRig が自マシンに何を書き込むのかが表形式で自己開示されています。冒頭では、変更内容に trust 設定と実行可能な hook が含まれることが明示されています。

書き込まれるファイルとstateの置き場所

README の記述を、タイミング別に整理します。

プロバイダ側の設定ファイルについても、README は具体的に列挙しています。Claude Code では workspace trust と onboarding 完了が書き込まれ、workspace の .claude/settings.local.json にコンテキストコレクタの statusLine コマンドと activity hook が設定されます。共有の settings リソースは permissions.defaultMode を acceptEdits に設定し、Exa / Context7 の MCP エントリを有効化します。Codex では daemon の CODEX_HOME/config.toml（通常 ~/.codex/config.toml）に hook と activity relay コマンド、trust hash が書き込まれ、seat 起動時に workspace へ trust_level = "trusted" が追加されます。

送信されるデータの範囲についても記述があります。activity relay が daemon の /api/activity/hooks に送るのは、イベントの type / subtype、seat と runtime の識別情報、タイムスタンプ、ネイティブセッションの識別情報で、プロンプト本文とツール引数は含まれないと明記されています。一方で Claude のコレクタは、コンテキスト／トークン使用量、セッションとトランスクリプトパスのメタデータ、取得可能なレート制限情報をインスタンスの state 配下に書き出します。

そして最も重要なのが、README 自身が置いている注記です。managed hook ブロックは OpenRig のエントリを対象とし無関係な hook は保持されるものの、trust エントリや Claude の既存ステータスライン設定は置き換えられ得る、そして「これは完全な保存・ロールバックの保証ではない（this is not a complete preservation or rollback guarantee）」ため、初回利用前に関係ファイルをバックアップすることが推奨されています。さらに、daemon / bootstrap の書き込みは自動であり個別の対話プレビューを持たず、rig setup --dry-run も後続の起動時の効果すべてをプレビューするわけではないと明記されています。

設定ファイルへの自動書き込みを組織のルールで制限している環境では、ここが採用可否の分岐点になります。詳細はマシンへの変更点に関する README の記述を原文で確認することをおすすめします。

権限モードとYOLOの既定

権限設計についても README は明確な既定値を示しています。

ビルトインの bootstrap は、設定ファイルに rig コマンドの allow ルールを書き込みません。権限ポリシーも per-seat の選択も（Codex の場合は名前付きプロファイルも）持たない team seat は、起動ごとに適用される team default で立ち上がります。team default では、Claude は通常の rig コマンド・プロジェクトの読み取り・一般的なテストを確認なしで実行できる一方、rig up や rig down のようなライフサイクルコマンドには確認を求めます。Codex には OpenRig の workspace と pod の state ディレクトリが書き込み可能ディレクトリとして与えられます。

一方、kernel という名前の rig の seat は operational default で起動します。こちらは Claude が acceptEdits モード、Codex が -s danger-full-access -a never という、より広い権限です。

全体として YOLO（全バイパス）は既定でオフであり、明示的に full-bypass ポリシーを選択した場合にのみ Claude の --dangerously-skip-permissions や Codex の -s danger-full-access -a never が選ばれます。ポリシーの設定は rig policy permissions list|show|current|apply、seat 単位の監査付き選択は rig seat set-permissions <seat> --mode <mode> --reason <text>（floor / full_bypass / inherit）で行います。

ここで見落としたくないのが、README が rig seat status について置いている注記です。同コマンドは「選択された設定」と「最後の起動引数」を分離して表示しますが、どちらもネイティブ側での強制を証明するものではないとされています。権限の最終的な担保はあくまで Claude Code / Codex 側にあり、OpenRig の表示は意図の記録に近いという理解で運用すべき部分です。

類似OSSとの違い｜Ruflo・claude-squad・herdrとの棲み分け

「マルチエージェント基盤」を名乗る OSS は複数あり、名前だけでは責務の違いが見えません。2026年10月14日時点のメタデータを並べたうえで、OpenRig の位置を確認します。

同じ「ハーネス」を名乗るRufloとの責務の違い

Ruflo は自らを「The original agent harness.」と表現し、Claude Code・Codex などと統合しつつ、swarm・適応メモリ・vector RAG・federation といった機構を自前で持つ方向に機能を広げています。つまりエージェントの「賢さ」を構成する部分まで取り込む設計です。

対する OpenRig は、エージェント側の知能機構には手を入れません。Claude Code と Codex を出荷状態のまま attach 可能な tmux セッションとして動かし、その上のチーム構造（席・ポッド・通信・永続化）に責務を絞ります。スター数では Ruflo が約 10 倍の規模ですが、評価軸が違うため単純比較はできません。「エージェントの能力を拡張したい」なら Ruflo、「すでに使っているエージェントを組織化したい」なら OpenRig という切り分けになります。Ruflo 側の設計思想はClaude向けマルチエージェント基盤にRufloが選ばれる理由と類似OSSとの違いで詳しく整理しています。

なお、単一ハーネス内での並列化（Claude Code の SubAgent 等）はさらに別のレイヤーです。公式サイトの説明では、OpenRig の各専門エージェントも小さな調査のために一時的なネイティブ subagent を使えるとされており、両者は排他ではなく併用関係にあります。1 つのハーネス内で完結するならClaude Code SubAgentで十分なケースも多く、ハーネスをまたぐ必要が出たときに OpenRig の領域に入る、と考えると整理しやすくなります。

端末マネージャ型（claude-squad）との違い

claude-squad は、Claude Code・Codex・OpenCode・Amp といった複数のターミナルエージェントを管理するツールです。性格としては「複数の端末を束ねて切り替えやすくする」方向で、OpenRig が持つ RigSpec のようなトポロジ定義や、スナップショットによる復元といった層は主眼ではありません。

実務上の判断材料としては 2 点あります。1 つはライセンスで、claude-squad は AGPL-3.0、OpenRig は Apache-2.0 です。社内利用や商用プロダクトへの組み込みを検討する場合、条件の違いを確認する必要があります。もう 1 つは更新間隔で、claude-squad の最終 push は 2026年8月20日、OpenRig・Ruflo・herdr はいずれも 2026年10月13日です。「複数エージェントを並べたいだけ」なら軽量な claude-squad が合う場面もありますが、チーム構成をコードとして管理し復元まで扱いたいなら OpenRig の層が必要になります。

herdr・cmuxは競合ではなく表示層

herdr は 43,813 スターの Rust 製プロジェクトで、「the runtime your coding agents live on」を名乗っています。数字だけ見ると OpenRig の競合のように見えますが、位置づけは連携先です。

先に触れたとおり、OpenRig の rig setup は macOS / Linux で herdr を既定インストールし（--no-herdr で辞退可能）、rig terminal open <rig> --provider herdr で seat の端末をまとめて開きます。役割分担は「OpenRig = チームの協調状態を管理する」「herdr / cmux = エージェント端末そのものをどう見せるか」です。どちらかを選ぶ関係ではないため、比較検討のテーブルに並べる際は注意が必要です。

Claude Managed Agentsとの構造的な対比

OSS 以外の選択肢との対比も押さえておきたいところです。OpenRig はClaude Managed Agents との比較ページを公式に公開しています。ただしこれは OpenRig のメンテナ自身が書いた比較であり、中立な第三者比較ではありません。同ページ自身も「カテゴリの地図を描くことを目的とし、勝者を宣言しない」と述べています。この前提を踏まえたうえで、構造的な対比として有用な観点を抜き出します。

要点は、OpenRig が「ターミナルの開発者が操作主体である」という前提に立っていることです。アプリケーションコードからエージェント群を呼び出したいユースケースとは設計の出発点が異なるため、そもそも比較対象として適切かどうかを先に判断するほうが早いでしょう。なお、プロバイダ側のモデル利用料は OpenRig とは別途かかる点も README と比較ページの双方で触れられています。

OpenRigの採用判断チェックポイント

ここまでの整理を、採用判断に使える形にまとめます。

向いているケース

• Claude Code と Codex の両方（または片方）を既に契約しており、ターミナル中心の開発スタイルが定着している
• 数週間以上続くプロジェクトで、実装・レビュー・QA といった役割分担をエージェントに持たせたい
• トポロジをクラウドに預けず、ローカル完結で運用することが要件になっている
• チーム構成をファイルとしてバージョン管理し、他のマシンへ持ち運びたい
• macOS または Linux が主要な開発環境である

見送りを検討すべきケース

• ネイティブ Windows が前提の環境（WSL2 のみサポートで、WSL2 では自動テストが未実施）
• Node.js 20 に固定されており、バージョンを上げられない
• CI など非対話環境で完結させたい（tmux セッション前提の設計と噛み合わない）
• ~/.tmux.conf・~/.claude/skills・~/.codex/config.toml 等への自動書き込みや trust 設定の付与を許容できない
• Slack 連携や Web UI が必須要件（前者は experimental、後者は maintenance mode）

メンテナンス健全性の見方

数値だけで判断せず、「機能ごとに成熟度が異なる」ことを前提に、自分が必要とする機能がどの成熟度にあるかを確認するのが実務的です。たとえば Slack 通知を運用の中核に据える設計は、experimental という表記を踏まえると現時点では慎重に判断すべき領域になります。

まとめ

OpenRig の位置づけを 3 点に整理します。

1. ハーネスを束ねる上位レイヤーである。Claude Code や Codex を改造せず、出荷状態のまま attach 可能な tmux セッションとして動かし、その上のチーム構造（Seat・Pod・通信・永続化）に責務を絞っている
2. ローカル完結の実行構造を持つ。Hono の HTTP daemon・SQLite・tmux・runtime adapters というスタックで、トポロジを外部サービスに預けない。その代わり tmux と Node.js 22/24、macOS または Linux という環境要件が付く
3. 宣言的なチーム定義と復元ができる。RigSpec（YAML）で pods / members / edges / continuity policy を定義し、rig down --snapshot と rig up <name> で状態を保存・復元する。member 単位で runtime を指定できるため、Claude Code と Codex を 1 つの rig に混在させられる

採用を検討する場合、次の順で公式情報を確認するのが効率的です。

• README の「Requirements」で Node.js と OS の要件を自環境と突き合わせる
• README の「What OpenRig changes on your machine」を原文で読み、書き込まれるファイルと trust 設定が組織のルールに収まるかを判断する
• RigSpec リファレンスで、自分が組みたいチーム構成が表現できるかを確認する
• Getting startedと公式ドキュメントで導入手順と運用コマンドを把握する

本記事は 2026年10月14日時点の公開ドキュメントを一次情報として整理したものです。OpenRig は更新頻度が高く、バージョンによって要件や書き込み内容が変わり得ます。導入時は最新の README と rig setup --dry-run の出力で差分を確認し、README が推奨するとおり関係ファイルのバックアップを取ったうえで進めるのが安全です。

関連情報

AI コーディングエージェントを組み込んだ開発体制の設計や、社内向けの技術検証・PoC の受託開発をご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。