著者 Omnigentで複数のagent CLIをまとめて実行する方法
OmnigentはClaude CodeやCodexなど既存のagent CLIを1つの設定で制御するメタハーネスです。release 0.7.0の固定方法とVPSで各agentをsandbox化する手順を紹介します。
Omnigent とは
Omnigent はオープンソースのメタハーネスです。すでにインストールされているエージェントのコマンドラインツール（CLI）を制御するオーケストレーション層です。Claude Code、Codex、Cursor、OpenCode、Hermes、Pi を置き換えるものではありません。これらを起動し、それぞれに作業を割り当て、1 つのポリシーセットに基づいて単一セッション内の結果を監視します。Databricks は 2026 年 6 月に Apache 2.0 ライセンスでリポジトリを公開しました。PyPI では現在もパッケージを alpha と分類しています。
実用上の主張は限定的で、明確に説明できます。エージェントを YAML で 1 度定義し、それを実行するハーネスを指定します。その 1 行を変更するだけで、同じエージェントを別のベンダーの CLI 上で実行できます。Omnigent はエージェント内部のループではなく、エージェントの 上位 にあるループを管理するため、構成の他の部分を変更する必要はありません。
メタハーネスとは何ですか。フレームワークとはどう違いますか。
ハーネスとは、モデルをループ内で実行するプログラムです。プロンプトを読み取り、ツールを呼び出し、ファイルを編集して、結果を返します。Claude Code はハーネスです。Codex もハーネスです。インストールしてログインすれば、単独で動作します。
フレームワークは、その上でコードを記述するライブラリです。フレームワークを import し、Python で手順を定義すると、プログラム自体がエージェントになります。この場合、ベンダーを変更するにはコードを編集する必要があります。ベンダーのクライアントがプログラムに組み込まれているためです。
メタハーネスは、ハーネスとフレームワークの両方より 1 つ上の層にあります。ハーネスを子プロセスとして実行するスーパーバイザーです。Omnigent はベンダーの CLI を起動し、作業を渡して、返された結果を読み取ります。すでにインストールしている CLI をそのまま使えます。CLI の利用料金を支払っている既存のサブスクリプションや API (application programming interface) key も継続して使えます。違いはこの点に集約されます。そして、この仕組みが対象とする利用者も決まります。すでに複数の agent CLI を運用していて、それらを端末ごとに 1 つずつ操作することに疲れている人です。
1 つのオーケストレーション層でどのような問題を解決できるか
- ベンダーの切り替えが 1 行で済みます。 エージェント定義では
harnessとmodelをデータとして保持するため、役割を別のベンダーへ移すときに必要なのは YAML ファイルの編集であり、書き直しではありません。 - ベンダーをまたいでレビューできます。 1 つのモデルが作成した差分を、別会社のモデルが読み取ります。同じファミリーに属する 2 つのモデルは同じ盲点を共有しやすいため、同じベンダーによるセカンドオピニオンの価値は低くなります。
- ポリシーを 1 か所で管理できます。 予算のしきい値と承認プロンプトをエージェントファイルで宣言し、その下にあるすべてのサブエージェントに適用できます。
- セッションが特定のツールに依存しません。 複数の CLI で行った作業を 1 つのトランスクリプトにまとめられるため、4 つのスクロールバックをつなぎ合わせなくても経緯を確認できます。
コストは、この層自体にあります。Omnigent のバグが、単独で動作していたエージェントとの間に存在するバグになります。alpha 段階では、これは理論上のコストではなく、現実のコストです。
マルチエージェントハーネスを単一エージェントツールと併用する位置付け
サーバー上でまだエージェントを 1 つも実行していない場合は、まず単一エージェントから始めてください。VPS でコーディングエージェントを実行する のガイドでは、単一エージェントの構成を最初から最後まで説明しています。Omnigent は、この構成がすでに用意されていることを前提としています。セルフホスト AI エージェント の分野では、使用するエージェント自体を選びます。ここで使う用語に慣れていない場合は、エージェントの実際の動作を学ぶ ことから始めるのが適しています。
Omnigent は、コネクターレイヤーとは異なる軸の製品です。エージェントから独自のデータソースにアクセスできるようにする といった仕組みは、エージェントがアクセスできる対象を扱います。Omnigent は、どのエージェントをどの順序で実行し、どの制限を適用するかを扱います。両方を同時に必要とすることはありますが、両者の機能は重複しません。
インストール前に必要なもの
- Python 3.12 以降。公開パッケージでは
requires-python >= 3.12が宣言されています。 tmux。ターミナルハーネスはその中で実行されるためです。- 少なくとも1つのベンダー CLI。インストール済みで、ログインも完了している必要があります。
npmを備えた Node.js 22 以降。Claude、Codex、Pi のハーネスで必要です。インストーラーは Node 22.10 以降を確認し、見つからない場合は警告します。Omnigent 自体に Node は不要です。PyPI の wheel にはビルド済みの Web アセットが含まれており、Node が必須になるのは git checkout からビルドする場合だけです。
固定したリリースをインストールし、main は使用しない
curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0sh -s -- の部分は装飾ではありません。これがないと、sh は --version を自身のオプションとして解釈し、インストーラーはまったく実行されません。sh が Bash の場合、Bash 自身のバージョンを表示して正常終了するため、何もインストールされず、警告も表示されません。-s -- を指定すると、sh はパイプからスクリプトを読み取り、--version 0.7.0 をインストーラーに渡します。数週間ごとに破壊的変更を含む更新をリリースするリポジトリでは、これが再現可能な環境になるか、予期しない変更に見舞われるかの違いになります。
2026 年 10 月 29 日時点で、リリース 0.7.0 はまだ PyPI で公開されています。ただし、最新リリースは 2026 年 11 月 5 日の 0.21.0 です。それ以前の 0.19.1 は、新機能を含まないセキュリティ重視の修正版です。eMudhra の中間認証局が侵害されたことを受けて依存関係を更新しており、プロジェクトもアップグレードを推奨しています。重要なのは番号ではなく固定することです。テスト済みのバージョンを固定し、更新する前にリリースノートの破壊的変更を確認してください。ただし、固定を理由にセキュリティリリースを見送ってはいけません。リリースされたら更新します。
インストーラーは Astral の Python パッケージマネージャーである uv を使用します。uv が存在しない場合は、最初に uv をインストールするか確認します。uv がすでに存在する場合は、スクリプトを省略します。
uv tool install --force --python 3.12 "omnigent==0.7.0"追加機能も同じ形式で指定し、フラグも繰り返します。スクリプトでは --extra e2b --extra kubernetes、uv では "omnigent[e2b,kubernetes]" を指定します。スクリプトは、--no-databricks を渡さない限り databricks の追加機能も追加します。一方、上記の uv の行は、それを付けずにパッケージをインストールします。git tag は v0.7.0 ですが、PyPI 上のパッケージバージョンは 0.7.0 である点に注意してください。
uv は、uv tool dir --bin が報告するディレクトリにバイナリを配置します。通常は ~/.local/bin です。インストーラーは、このディレクトリをシェルのプロファイルに追加するか確認します。クリーンインストールの直後にコマンドが見つからない場合は、これが原因です。最終的な状態を確認します。
omni upgrade --checkこれは、インストール済みのバージョンと公開済みの最新バージョンを比較し、アップグレードが存在するかを通知します。アップグレード自体は実行しません。omni と omnigent は、名前が異なるだけで同じプログラムです。
モデルプロバイダーを指定する
omni setupウィザードは環境にすでに設定されている認証情報を確認し、不足しているものの入力を求めます。API キー、ベンダーのサブスクリプション、OpenRouter や Ollama などのゲートウェイ、Databricks ワークスペースに対応しています。同じマシンで Ollama を使用したローカルモデルサーバーをすでに運用している場合は、ゲートウェイの接続先に指定できます。ネットワークトラフィックがマシンの外部に出ることはありません。
最小構成のマルチエージェント実行
サンプルエージェントはリポジトリに含まれているため、mainではなく、インストールしたものと同じタグを clone してください。
git clone --depth 1 --branch v0.7.0 https://github.com/omnigent-ai/omnigent.git
cd omnigent
omnigent run examples/polly/Polly は、リポジトリに含まれるマルチエージェント型のコーディングオーケストレーターです。設定では、claude_code、codex、opencode、cursor、hermes、piという名前のサブエージェントと、この演習を実行する価値を生む1つのルールが定義されています。それは、レビューを必ず実装担当者とは異なるベンダーが行うことです。Polly 自身はコードを書きません。目的を計画し、作業項目に分割し、それぞれを委任して、各差分を別のベンダーのレビュアーへ振り分けます。
何かを委任する前に、Polly はプリフライトチェックを実行し、実際に利用できるサブエージェント CLI がマシン上に存在するか確認します。1つのベンダーの CLI しかインストールされていない場合、差分を渡せる相手がいません。そのため、出力を評価する前に少なくとも2つをインストールしてください。もう1つの同梱サンプルである Debby は、Claude と GPT の2つのヘッドを持つディベートエージェントです。
omni debby両方のプロバイダーが設定されていることを短時間で確認できます。どちらも応答できる必要があるためです。
サブエージェントをツールとして宣言する
エージェントファイルは YAML 形式です。executor では、ハーネス、モデル、認証を指定します。tools には、MCP（model context protocol）サーバー、Python 関数、サブエージェントを記述します。サブエージェントは type: agent と独自の executor を持つツールです。これが、前述したすべての機能の基盤です。
name: orchestrator
prompt: |
You coordinate coding and review tasks.
executor:
harness: claude-sdk
model: databricks-claude-sonnet-4-6
tools:
coder:
type: agent
prompt: Write and test code.
executor:
harness: claude-sdk
model: databricks-claude-opus-4-7
reviewer:
type: agent
prompt: Review proposed changes.
executor:
harness: claude-sdk
model: databricks-claude-sonnet-4-6omnigent run path/to/my_agent.yamlこれらのモデル ID はプロジェクト独自の docs/AGENT_YAML_SPEC.md の例に記載されており、Databricks がホストする名前です。harness と model は、使用する環境で omni setup が設定した値に置き換えてください。この仕様で指定できるその他のハーネス値には、antigravity、copilot、kimi、qwen があります。main にある現在の仕様では、Agent Client Protocol サーバー用の acp:<slug> も説明されています。ただし、v0.7.0 の仕様には記載されていないため、依存する前に固定したバージョンで動作することを確認してください。仕様では、サブエージェントに pass_history: true を指定することもできます。これにより、親の会話がサブエージェントに渡されます。委譲のたびにトークンを消費するため、目の前のタスクだけが必要なサブエージェントでは無効にしてください。prompt で 動作する最小限の変更を行うよう指定したコーダーは、実際に読める短さの差分をレビュアーに渡します。この点は、どちらの役割にどのモデルを選ぶかよりも重要です。
長時間のオーケストレーションを VPS で実行する理由
複数エージェントの実行は、2 分で終わるコマンドではありません。計画し、委任し、並列で動作する git worktree を待ち、レビューして、修正します。ノートパソコンの lid を閉じると、その処理はすべて終了します。VPS（仮想プライベートサーバー）は稼働し続け、ネットワーク接続も維持するため、監視していない間もセッションが継続します。
omnigent server --background
omnigent server statusサーバーは port 6767 で Web user interface を提供します。omnigent server status はサーバーが実行中かどうかを報告し、omnigent stop はサーバーを停止します。v0.7.0 では omni server start が削除され、代わりに omni server --background が使用されるようになりました。v0.9.0 では、非推奨の alias として omni server start が復元されました。
6767 を public address で公開しないでください。安全な構成は 2 種類あります。firewall で port を閉じたまま、ssh -N -L 6767:localhost:6767 you@your-server で SSH 経由の転送を設定し、自分のマシンで http://localhost:6767 を開きます。もう 1 つは、その前段で TLS（transport layer security）を終端し、認証を有効にする方法です。
OMNIGENT_AUTH_ENABLED=1 omnigent server --backgroundこの構成の firewall 部分は通常の作業であり、VPS の ufw firewall の基本で説明しています。また、すでに 複数の Docker Compose アプリの前段に Traefik を置く構成でコンテナを運用している場合、Omnigent も同じパターンに追加するサービスの 1 つです。
コンテナでデプロイする場合、repository の deploy/docker/ directory に Compose 設定があります。./bootstrap.sh は .env に secret を生成し、docker compose up -d は Omnigent と Postgres を起動します。この場合、server は 6767 ではなく port 8000 で動作します。OMNIGENT_PORT でその host port を変更できます。Compose は DATABASE_URL を自動的に設定します（他の deploy target では、同じ variable で Postgres または SQLite を選択します）。また、コンテナ内では OMNIGENT_AUTH_ENABLED の既定値が 1 です。これは外部から到達可能なものに適した既定値です。
サイジングについては、deploy notes で server の idle 時のメモリ使用量を約 275 MB RSS としており、Fly.io の設定では 1 GB の machine を指定しています。idle 時の測定値は supervisor 単体のもので、1 GB は割り当てられた machine memory です。sub-agent は os_env: inherit を通じて、親の working directory と environment（sandbox を含む）を共有できます。個別の git worktree を使うかどうかはオーケストレーション上の選択なので、同時に実行する harness と agent に合わせて VPS のサイズを決めてください。server の起動後、omnigent login https://your-host に続けて omnigent host https://your-host を実行すると laptop が server に登録され、omnigent attach <session_id> により別の device から実行中の session を再開できます。
各サブエージェントをサンドボックス化してから離れる
Omnigent は、Omnibox という OS レベルのサンドボックスを提供しています。Linux では bubblewrap の namespace と seccomp を使用するため、境界はエージェントのプロンプトではなくカーネルによって強制されます。プロンプトインジェクションを受けたエージェントでも、カーネルのルールを言いくるめて抜け出すことはできません。まず依存関係をインストールします。
sudo apt install bubblewrap設定は、エージェントファイル内の os_env 以下に記述します。
os_env:
type: caller_process
cwd: .
sandbox:
type: linux_bwrap
write_paths: [.]
write_files: []
read_paths: []
allow_network: true
cwd_allow_hidden: [.venv]
env_passthrough: []
egress_rules: []
credential_proxy: []write_paths に記載するまで、作業ディレクトリは読み取り専用です。そのため、異常な動作をするエージェントでも、workspace の外部に書き込むことはできません。作業ディレクトリ直下の dotfile と各 read_paths root は、cwd_allow_hidden に明示しない限り非表示になります。これにより、広範な読み取り許可を与えても、直下の .ssh や .aws ディレクトリが意図せず公開されることはありません。下位階層の dotfile はデフォルトで表示されます。ツリー全体でそれらをマスクするには cwd_hidden_scan_recursive: true を設定します。egress_rules を設定すると、すべての HTTP および HTTPS トラフィックがデフォルト拒否のプロキシを経由します。各ルールは "METHODS host/path-glob" として記述します。credential_proxy はさらに一歩進んだ設定です。エージェントが保持するのはプレースホルダーだけで、リクエストが外部へ出る際にプロキシが実際の Secret と置き換えます。そのため、トランスクリプトが漏洩しても、使用可能な情報は漏れません。複数の harness を使用する構成では、各サブエージェントが agents/ 以下にある自身の config file 内に、独自の sandbox block を持ちます。そのため、reviewer にはネットワークを許可せず、implementer には許可するといった構成にできます。
この制限はドキュメントに明記されており、重要な点です。OS sandbox は sys_os_* の tool call と terminal に適用されます。MCP server には適用されず、Omnigent supervisor process 自体にも適用されません。起動した MCP server は sandbox の外側で、起動元の権限を使って実行されます。この差があるため、より強力な構成として、依然としてエージェントごとに使い捨てのマシンを 1 台用意する方法があります。これは 使い捨て VM で coding agent を実行する で説明しています。もう一つの課題は credentials です。6 個のサブエージェントが 1 台の host を共有すると、エージェントの手の届かない場所に Secret を保管する ことは容易になるのではなく、難しくなります。
支出の threshold は policy として、同じ file に定義します。
policies:
budget:
type: function
handler: omnigent.policies.builtins.cost.cost_budget
factory_params:
max_cost_usd: 5.00
ask_thresholds_usd: [1.00, 3.00]cost_budget policy は soft threshold に達した時点で確認を求め、max_cost_usd ではデフォルトですべての model を block します。空でない expensive_models list を設定すると、この limit は downgrade gate になります。その list に含まれない model は、支出を継続できます。1 つ目の vendor で plan を作成し、2 つ目で implement し、3 つ目で review する run では、同時に 3 か所で支出が発生します。そのため、最初の請求後ではなく、最初の unattended run の前に threshold を設定してください。組み込みの policy には max_tool_calls_per_session と ask_on_os_tools もあり、file 操作と shell 操作の前に approval を求めます。VPS で AI agent のコストを抑える にある説明は、ここにもそのまま適用できます。並列のサブエージェントでは burn rate が増加するため、より重要です。
このリポジトリの更新ペースはどの程度ですか？
このグラフのデータ
[
{
"version": "v0.2.0",
"released": "2026-06-19",
"interval": 3
},
{
"version": "v0.3.0",
"released": "2026-06-27",
"interval": 8
},
{
"version": "v0.4.0",
"released": "2026-07-03",
"interval": 6
},
{
"version": "v0.5.0",
"released": "2026-07-10",
"interval": 7
},
{
"version": "v0.5.1",
"released": "2026-07-10",
"interval": 0
},
{
"version": "v0.6.0",
"released": "2026-07-21",
"interval": 11
},
{
"version": "v0.7.0",
"released": "2026-07-27",
"interval": 6
}
]これは、2026 年 8 月 3 日にプロジェクト独自のリリースページから確認した公開リリース日です。7 件のタグ付きリリースが、2026-06-19 から 2026-07-27 の間に公開されました。2 つのリリース間の最長間隔は 11 日でした。v0.5.1 は、その直前のリリースと同じ日に公開されています。最初の 2 件の PyPI リリースである 2026 年 6 月 13 日の 0.1.0 と 2026 年 6 月 16 日の 0.1.1 は、GitHub のリリースページに記録がないため、グラフから除外しています。v0.2.0 に示されている 3 日間は、0.1.1 から数えています。
このうち 2 件のリリースでは、ガイドがすでに説明していたコマンドが変更されました。v0.7.0 では omni server start が削除され、代わりに omni server --background が使用されます。v0.6.0 では omnigent[memory] extra の名前が omnigent[hindsight] に変更されましたが、互換性のための別名として memory も維持され、0.10.0 まで使用できました。2026 年 8 月 25 日に公開された 0.11.0 以降、この別名は削除されています。そのため、6 月に書かれた記事からインストール行をコピーしても、Hindsight client はインストールされません。これは、インストールコマンドに --version を指定し、git clone にタグを指定する理由です。単なる書式上の好みではありません。
この確認以降も更新ペースは落ちていません。2026 年 10 月 29 日の時点で、PyPI には 2026 年 10 月 28 日に公開された 0.20.0 が掲載されています。これは 0.7.0 以降 13 回目の minor release であり、そのうち複数のリリースノートで破壊的変更が示されています。このページの内容をコピーして使う場合、特に重要なのは 2 点です。v0.12.0 では、単独の omni が Polly agent ではなくバックグラウンドの host を起動するようになりました。デフォルトの agent を起動するには、現在は omni run を使用します。また、v0.13.0 以降、managed terminal には tmux 3.3 以降が必要です。
現時点では任せないこと
2026年10月27日時点で、このリポジトリには約11k個のスター、1.8k個のフォーク、約910件のオープンイシューがあります。最初の公開リリースからは、まだ4か月余りです。スターは関心の大きさを示すものであり、成熟度を示すものではありません。プロジェクト自身が alpha と明記しており、上記のリリース履歴からも、alpha 相当であることが分かります。
- 本番環境の認証情報を保持するホストでは実行しません。sandbox は MCP サーバーや supervisor を対象としていないためです。
cost_budgetポリシーを設定せずに実行を放置しません。3つのベンダーが並行して課金する可能性があるためです。expensive_modelsリストが空でなければ、より安価なモデルで支出が継続する可能性があります。OMNIGENT_AUTH_ENABLEDを設定し、前段に TLS を置かずに、サーバーをパブリック IP アドレスで公開しません。- agent YAML がマイナーバージョン間で安定しているとは、まだ考えません。バージョンを固定し、アップグレード前にリリースノートを確認してください。
予想外の動作を防ぐために、もう1つ確認しておくことがあります。v0.6.0 では、匿名化された使用状況テレメトリーが追加されました。README には、これがデフォルトで収集されると記載されています。プロジェクトでは、オプトアウト方法を含む詳細を専用のテレメトリーページで説明しています。クライアント向けの作業を扱うマシンで使用する場合は、そのページを読み、意図的に判断してください。
現時点で Omnigent が本当に得意なのは、構築された目的そのものです。3つまたは4つの agent CLI を使っていて、それらの料金をすでに支払っており、1つに記述させながら別の1つにレビューさせたい場合です。Linux 上の1台のマシンで、実際の sandbox を利用して、現在すでに実現できます。それより先の機能は、将来性はあるものの未完成だと考えてください。
FAQ
Omnigent はエージェントですか。それともエージェントを実行するものですか？
エージェントを実行します。Omnigent はメタハーネスです。インストール済みの Claude Code、Codex、OpenCode などのベンダー CLI を起動し、それぞれに作業を割り当て、1 つのセッションで結果を監督します。独自のモデルは提供しません。ライブラリを使って Python でコードを書き、そのプログラム自体をエージェントにするフレームワークとは、この点が異なります。
Omnigent を有効に使うには、Claude Code と Codex を事前にインストールする必要がありますか？
少なくとも 1 つのベンダー CLI をインストールしてログインしておく必要があります。Omnigent はそれらのプログラムを操作するものであり、置き換えるものではないためです。付属の Polly の例では、異なるベンダーの CLI を 2 つ以上用意します。Polly では、レビューを実装担当とは必ず異なるベンダーが行うルールになっています。そのため、CLI が 1 つしかない場合は、差分を送る別のベンダーが存在しません。
最新版ではなく、特定の Omnigent バージョンをインストールするにはどうすればよいですか？
sh -s -- を使って、--version をインストールスクリプトに渡します。例は sh -s -- --version 0.7.0 です。-s -- を付けない場合、sh は --version を自身のオプションとして解釈するため、インストーラーは実行されません。たとえば Bash は自身のバージョンを表示して終了します。すでに uv がある場合は、uv tool install --force --python 3.12 "omnigent==0.7.0" でも同じことができます。git tag は v0.7.0 で、PyPI のバージョン文字列は 0.7.0 です。
Omnibox のサンドボックスだけでエージェントを無人実行できますか？
対応範囲については強力で、対応しない範囲も明確です。Linux では bubblewrap と seccomp を使用するため、ファイルとネットワークの制限をカーネルが適用し、エージェントが無効化することはできません。ドキュメントには、sys_os_* のツール呼び出しと端末に適用され、MCP サーバーや Omnigent の監督プロセスには適用されないと記載されています。したがって、MCP サーバーは通常の権限で実行されます。無人実行では、エージェントごとに使い捨ての仮想マシンを用意するほうが、引き続き強力な分離になります。
VPS 上の Omnigent サーバーには、どの程度のメモリが必要ですか？
プロジェクトのデプロイに関するメモでは、アイドル時の RSS はおよそ 275 MB と報告されています。また、Fly.io の設定では 1 GB のマシンを割り当てています。このアイドル時の測定値に含まれるのはサーバー本体だけで、サブエージェントは含まれません。サブエージェントは os_env: inherit を通じて、サンドボックスを含む親プロセスの作業ディレクトリと環境を共有できます。別の作業コピーが保証されるわけではありません。Polly 形式の実行では git worktree を並列で使用するため、サーバーではなく、同時に実行するエージェント数に応じて RAM とディスク容量を見積もってください。