Software Development2026-10-14約8分で読めます

openrigとは — Claude CodeとCodexを役割分担させるマルチエージェントOSSの使い方・既存ツールと

の違い

openrigは、Claude Code・Codex・Piを役割・共有コンテキスト・作業の所有を持つチームとして動かすApache-2.0のOSS。インストール、RigSpec、rig send、Paperclip・Docker Agentとの違い、注意点を解説。【2026年10月】

AIエージェント開発ツールオープンソース Claude Code Codex Apache 2.0

openrigは、Claude Code・Codex・Piといった既存のコーディングエージェントCLIを、役割・共有コンテキスト・担当作業を持つ「チーム」としてまとめて動かすオープンソースのツールです。READMEは「ハーネスはモデルを包み、rigはハーネスを包む」と表現しています。TypeScript製で、ライセンスはApache-2.0、npmパッケージは@openrig/cli（rigコマンドを提供）です。GitHubの週間トレンドに入り、本稿執筆時点（2026年10月12日）で約7.1k スターです。

openrigで何ができるか

- 複数のエージェントCLIを1つのチームに: Claude CodeとCodexはネイティブ対応、PiとOh My PiはRPCランナー経由で動く（READMEの記載）
- YAMLでチーム構成を宣言: RigSpecにpod（グループ）・member（席）・edge（関係）を書き、rig upで一括起動する
- seatで役割と宛先を固定: dev-build@starterのような名前が安定した宛先になり、中身の会話が入れ替わってもアイデンティティは残る
- 共有コンテキスト: チーム共通の方針を書くCULTUREファイルと、コンテキストライブラリを全員が参照できる
- 作業の所有: rig sendで特定のseatへ依頼を送り、rig queueで宛先ごとの作業キューを確認できる
- 保存と復元: rig down --snapshotで状態を保存し、rig up <名前>で戻せる。再起動で布陣が消える問題への対策としてHNの紹介投稿でも動機に挙げられている
- tmuxベース: 各エージェントは独自のtmuxセッションで動き、直接アタッチして中身を見られる

RigSpec（YAML）からrig upで各seat（orch.lead=claude-code、dev.build=codex、dev.review=pi等）がtmuxセッションとして起動し、共有コンテキスト（CULTURE.md・コンテキストライブラリ）、作業の所有（rig send・rig queue）、保存と復元（snapshot）で支えられるopenrigの構成図。

インストール

動作要件は、Node.js 22または24、tmux、macOSまたはLinuxです（WindowsはWSL2のみ。ネイティブWindowsは非対応、README記載）。Bunでの導入も可能ですが、その場合もNode.js 22は必要です。

# 一括インストール（README記載。v0.6.8固定。先に --dry-run で内容を確認できる）
curl -fsSL https://raw.githubusercontent.com/mvschwarz/openrig/v0.6.8/scripts/install.sh | sh

# 手順を分けて入れる場合
npm install -g @openrig/cli
rig setup --dry-run
rig setup

rig setupは~/.tmux.confにopenrig用のブロックを書き込み、マウス操作とスクロールバックを有効にします。環境を変更する処理なので、まず--dry-runで内容を確認するのがおすすめです。対象のエージェントCLIはrig setup --providers claude|codex|bothで選べます。

最短の使い方

READMEのクイックスタートは、同梱のstarter rigを自分のリポジトリで起動する流れです。--planで起動計画だけを確認してから本起動できます。

rig daemon start                          # 停止中なら起動
rig terminal open saved:kernel --window   # オペレーター画面（TUI）を開く

cd /path/to/your/repository
rig specs preview starter --kind rig      # 同梱のstarter rigの中身を確認
rig up starter --cwd . --plan             # 起動計画だけ表示
rig up starter --cwd .                    # 起動

rig ps --nodes --rig starter              # 各seatの状態
rig send dev-build@starter '依頼内容'      # seatに作業を送る
rig queue list --destination dev-build@starter --limit 1000

同梱のrigとして、starterのほかfactory、報道によればproduct-team・adversarial-review（敵対的レビュー）・research-teamなどがあります。rig specs lsで一覧を確認してください。

役割・共有コンテキスト・作業の所有の仕組み

チームはRigSpecというYAMLで定義します。公式のリファレンスにある最小例を、共通方針ファイルと「リードがビルド担当へ委任する」関係つきに広げたものが次の形です。

version: "0.2"
name: my-rig
culture_file: culture/CULTURE.md

pods:
  - id: orch
    label: Orchestration
    members:
      - id: lead
        agent_ref: "local:agents/orchestrator"
        profile: default
        runtime: claude-code
        cwd: "."
    edges: []

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

edges:
  - kind: delegates_to
    from: orch.lead
    to: dev.build

- 役割（seat）: pod.memberが1つの席になり、rig send dev-build@starterのように宛先として指定できる。memberごとにruntime（claude-code・codex・pi・omp・terminalなど）、model、role、permission_policyを持てる
- 関係（edge）: delegates_to・escalates_to・can_observe・collaborates_with・spawned_byの5種類。起動順を制約するのはdelegates_toとspawned_byだけ
- 共有コンテキスト: culture_fileで指定したCULTURE.mdがrig全体の共通方針になる。再利用できるエージェントの雛形はAgentSpec（スキル・指示・フック・プロファイル）として別に定義する
- 作業の所有: 依頼はrig sendでseatに届き、rig queue list --destinationで宛先ごとのキューを見られる。誰が何を持っているかが席の単位で追える

HNのShow HNでは、作者がrig sendとrig captureを使ってエージェント同士が互いの端末に入力し、画面を読む仕組みだと説明しています（tmuxのラッパー）。別のメッセージ基盤は足していない、とも述べています。

既存ツールとの違い

「複数のエージェントを動かす」ツールは増えています。openrigは「すでに使っているCLIをそのまま並べ、布陣を保存・復元する」寄りの位置づけです。以下は目安の比較で、公式情報に基づく行以外は一般知識のため、導入前に最新のドキュメントを確認してください。

ツール	形態	主な軸	向いている場面
openrig	CLI＋デーモン（tmuxベース）	複数の既存エージェントCLI（Claude Code・Codex・Pi）をYAMLでチーム化し、seatで役割と宛先を固定	手元・サーバーで複数CLIを並べ、再起動後も同じ布陣を復元したい
Paperclip	セルフホスト型Webアプリ（MIT）	組織図・予算・承認ゲートで複数エージェントを「会社」として管理	予算や承認を含む運用管理をUIで行いたい
Claude Code サブエージェント／Agent Teams	Claude Code内蔵の機能	Claude Code内で作業を分担（機能の範囲は公式ドキュメントで要確認）	Claude Codeだけで完結させたい
claude-squad	ターミナルアプリ（tmux・git worktree利用と理解）	複数のエージェントセッションを並行管理（※一般知識。最新機能は公式で確認）	同じCLIを複数並走させ、作業ツリーを分けたい
Docker Agent	YAMLランタイム（Docker CLIプラグイン）	YAMLでエージェントを定義し、sub_agentsで委譲	汎用のマルチエージェントを設定中心で組みたい

PaperclipはPaperclipとは — 複数AIエージェントを「組織」として管理するOSS、Docker AgentはDocker Agent（旧cagent）とは — YAMLで作るマルチエージェント入門で詳しく解説しています。Claude Code側の設定を整える手段としてはclaude-code-templatesの解説も参考になります。

導入時の注意

- コストが増える: エージェントを並べるほどトークン消費も増える。作者はHNで、4〜5体を超えると状況を把握しきれなくなると述べている
- 人の監督は必要: HNのコメントでは、80%程度まで進んでも各PRのレビューと誘導が必要で、結局の手間が大きく減らなかったという報告もある。作者も、早い段階の誤りが後続作業に雪だるま式に広がると認めている
- 権限とサンドボックス: 複数のエージェントが端末へ入力し合うため、各CLIの権限設定が重要。RigSpecにはpermission_policyがあるが、運用ルールは自分で決める
- 同じリポジトリでの衝突: 複数のseatが同じ作業ディレクトリを編集すると競合し得る。seatごとにcwdやブランチを分ける設計を検討したい
- 成熟度: 作者自身が「初期段階」と述べ、これまでの最長連続稼働は約4日。バージョンは0.6系で、仕様が変わる可能性がある。個人の検証から始めるのが無難

よくある質問

openrigの「Pi」とは何ですか？

Piは、libGDXの作者としても知られるMario Zechner（badlogic）が開発するミニマルなターミナル型コーディングエージェントです（現在のリポジトリは earendil-works/pi）。対話・JSON出力・RPC・SDKの各モードを持ち、openrigはこのRPCモード経由でPiを動かします。Oh My PiはPiをベースにしたコミュニティ製のディストリビューションです。RigSpecのランタイム名はそれぞれ pi と omp です。

料金やライセンスは？

ライセンスはApache-2.0で、openrig自体は無料のオープンソースです。ただし、中で動かすClaude CodeやCodexの利用料金・サブスクリプションは別途かかります。

Windowsで使えますか？

ネイティブWindowsは非対応で、WSL2経由のみサポートとREADMEに書かれています。macOSとLinuxが対象で、tmuxが必要です。

Claude Codeのサブエージェントとの違いは？

サブエージェントはClaude Codeの内部で作業を分担する機能です。openrigは別々のCLI（Claude CodeとCodexなど）を独立したtmuxセッションとして並べ、seatの宛先で連携させる外側の層です。

既に動かしているtmuxセッションを取り込めますか？

READMEによると、rig discoverで既存のtmuxセッションを見つけ、rig adoptで管理下に取り込めます。実際の挙動は公式ドキュメントで確認してください。

まず何から試すべきですか？

小さなリポジトリでrig up starter --cwd . --planを実行して起動計画を確認し、1つのseatに小さな依頼を送るところから始めるのがおすすめです。

まとめ

openrigは、Claude CodeやCodexなど既存のエージェントCLIを、seatという安定した宛先・共有の方針ファイル・作業キュー・スナップショットでチームとして運用するための層です。tmuxベースで中身を直接覗けるのが利点で、一方で作者自身が述べる通りまだ初期段階で、人の監督も欠かせません。最新の仕様は公式リポジトリで確認してください。本稿は公式README、リファレンス、HN投稿の公開情報をもとにしており、筆者が実際に動かして検証したものではありません。

この記事に関連する無料ツール（登録不要・その場で結果）

ミツモリシミュレーター6つの質問で開発費用の概算レンジと期間の目安がわかる

お気軽にご相談ください

お問い合わせ