ガイド

著者 Matt Connor 2026-08-03 ・更新日 2026-08-13

Omnigentで複数のエージェントCLIを一元管理する方法

Q: 最新版ではなく、特定の Omnigent バージョンをインストールするにはどうすればよいですか？

sh -s -- --version 0.7.0 のように、--version を sh -s -- とともにインストールスクリプトへ渡します。-s -- を指定しない場合、そのフラグは sh 自体によって消費され、スクリプトは最新リリースをインストールします。uv がすでに存在する場合は、uv tool install --force --python 3.12 "omnigent==0.7.0" で同じことができます。git tag は v0.7.0、PyPI のバージョン文字列は 0.7.0 です。

OmnigentはClaude CodeやCodexなど既存のagent CLIを置き換えず、1つのメタハーネスで制御します。仕組み、release 0.7.0の固定方法、VPSで子エージェントを隔離する手順を解説します。

Omnigent とは

Omnigent はオープンソースのメタハーネスです。すでにインストール済みのエージェント用コマンドラインツール（CLI）を制御する、1 つのオーケストレーション層です。Claude Code、Codex、Cursor、OpenCode、Hermes、Pi を置き換えるものではありません。これらを起動し、それぞれにジョブを割り当て、1 つのポリシーセットに基づいて単一セッション内で結果を監視します。Databricks は 2026 年 6 月にリポジトリを Apache 2.0 ライセンスで公開しました。現在もトップページには Status: 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 か所で管理できます。 支出上限と承認プロンプトをエージェントファイルで宣言し、その配下にあるすべてのサブエージェントに適用できます。
セッションが特定のツールに依存しません。 複数の CLI で行った作業を 1 つのトランスクリプトにまとめられるため、4 つのスクロールバックをつなぎ合わせなくても作業内容を確認できます。

コストは、この層自体にあります。Omnigent のバグが、単独で動作していたエージェントとの間に存在するバグになります。alpha では、これは理論上のコストではなく、実際のコストです。

マルチエージェントハーネスを単一エージェントツールと併用する位置付け

サーバー上でまだエージェントを 1 つも実行していない場合は、まず単一エージェントから始めてください。VPS でコーディングエージェントを実行するのガイドでは、単一エージェントの構成を最初から最後まで説明しています。Omnigent は、この構成がすでに用意されていることを前提としています。セルフホスト AI エージェントの分野では、使用するエージェント自体を選びます。ここで使う用語に慣れていない場合は、エージェントの実際の動作を学ぶことから始めるのが適しています。

Omnigent は、コネクターレイヤーとは異なる軸の製品です。エージェントから独自のデータソースにアクセスできるようにするといった仕組みは、エージェントがアクセスできる対象を扱います。Omnigent は、どのエージェントをどの順序で実行し、どの制限を適用するかを扱います。両方を同時に必要とすることはありますが、両者の機能は重複しません。

インストール前に必要なもの

Python 3.12 以降。公開パッケージでは requires-python >= 3.12 が宣言されています。
tmux。ターミナルハーネスはその中で実行されるためです。
ベンダー CLI を少なくとも 1 つ。事前にインストールし、ログイン済みにしておきます。
git checkout からビルドする場合のみ Node.js 22。PyPI の wheel にはビルド済みの Web アセットが含まれているため、通常のインストールに Node は不要です。

固定したリリースをインストールし、main は使用しないでください

curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh -s -- --version 0.7.0

sh -s -- の部分は飾りではありません。これがないと、sh は --version を自身のオプションとして解釈し、インストーラーはそのフラグを認識できません。その結果、その日に最新のものがインストールされます。数週間ごとに破壊的変更を含むリリースを公開するリポジトリでは、再現可能なサーバーになるか、予期しない状態になるかを分ける重要な違いです。

このインストーラーは、Astral の Python パッケージマネージャーである uv を使用します。uv がない場合は、先に uv をインストールするか確認されます。すでに uv がある場合は、スクリプトを省略してください。

uv tool install --force --python 3.12 "omnigent==0.7.0"

Extras も同じ形式に従い、フラグを指定します。スクリプトでは --extra e2b --extra kubernetes、uv では "omnigent[e2b,kubernetes]" を使用します。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-6

omnigent run path/to/my_agent.yaml

これらのモデル ID はプロジェクト独自の docs/AGENT_YAML_SPEC.md の例に由来し、Databricks がホストする名前です。harness と model は、使用する環境で omni setup に設定した値に置き換えてください。仕様には、汎用プロトコルを使用するものとして、antigravity、copilot、kimi、qwen、acp:<slug> などのハーネス値もあります。サブエージェントでは pass_history: true も指定できます。これにより、親の会話がサブエージェントに渡されます。委譲するたびにトークンを消費するため、目の前のタスクだけが必要なサブエージェントでは無効のままにしてください。prompt で動作する最小限の変更を行うよう指示された coder は、実際に読める短さの差分を reviewer に渡します。この点では、どちらの役割にもどのモデルを選ぶかより重要です。

長時間実行するオーケストレーションを VPS で行う理由

マルチエージェントの実行は、2 分で終わるコマンドではありません。計画し、委任し、並列の git worktree を待ち、レビューし、修正します。ノートパソコンを閉じると、これらはすべて終了します。VPS（仮想プライベートサーバー）は稼働し続け、ネットワーク接続も維持するため、監視していない間もセッションが継続します。

omnigent server --background
omnigent server status

サーバーは 6767 番ポートで Web ユーザーインターフェイスを提供します。omnigent server status で実行中のセッションがあるか確認でき、omnigent stop で停止できます。v0.7.0 より前のリリースでは omni server start でしたが、これは削除されています。そのため、古い記事やスクリーンショットの内容は、実際に端末で実行する場合と一致しません。

6767 番ポートをパブリックアドレスで公開しないでください。安全な構成は 2 つあります。ファイアウォールでポートを閉じたまま、ssh -N -L 6767:localhost:6767 you@your-server で SSH 経由の転送を設定し、自分のマシンで http://localhost:6767 を開きます。または、手前で TLS（トランスポート層セキュリティ）を終端し、認証を有効にします。

OMNIGENT_AUTH_ENABLED=1 omnigent server --background

ファイアウォール部分は通常の作業であり、VPS 向け ufw ファイアウォールの基本で説明しています。すでに複数の Docker Compose アプリの前段に Traefik を配置してコンテナを運用している場合、Omnigent も同じ構成に追加するサービスの 1 つです。

コンテナでデプロイする場合、リポジトリの deploy/ ディレクトリに Compose の設定があります。./bootstrap.sh で .env に Secret を生成し、docker compose up -d で Omnigent と Postgres を 6767 番ポートで起動します。DATABASE_URL で Postgres または SQLite を選択できます。コンテナ内では OMNIGENT_AUTH_ENABLED の既定値が 1 になっており、外部から到達可能な環境では適切な設定です。

サイジングについて、デプロイ時の注記ではサーバーの作業セットをおよそ 512 MB から 1 GB としており、Fly.io の設定では 1 GB に固定しています。この値は supervisor だけを対象にしたものです。各サブエージェントは、それぞれの checkout と model client を保持する別プロセスです。そのため、エージェント数を基準にサーバーのサイズを決めてください。サーバーの準備ができたら、omnigent login https://your-host に続けて omnigent host https://your-host を実行するとノートパソコンをサーバーに登録でき、omnigent attach <session_id> で別のデバイスから実行中のセッションを再開できます。

サブエージェントを離れる前に、すべてをサンドボックス化する

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 に一覧化するまで読み取り専用です。そのため、誤動作したエージェントがワークスペースの外部に書き込むことはできません。ドットファイルは cwd_allow_hidden に指定しない限り非表示のままです。広範な読み取り許可を与えても、.ssh や .aws が意図せず公開されることはありません。egress_rules を設定すると、すべての HTTP および HTTPS トラフィックがデフォルト拒否のプロキシを経由します。各ルールは "METHODS host/path-glob" の形式で記述します。credential_proxy はさらに一歩進んだ機能です。エージェントが保持するのはプレースホルダーだけで、リクエストが送信される際にプロキシが実際の Secret に置き換えます。そのため、トランスクリプトが漏洩しても利用可能な Secret は漏れません。複数の harness を使う構成では、各サブエージェントが自身の設定ファイルの agents/ に独自のサンドボックスブロックを持ちます。そのため、レビュアーのネットワークアクセスを拒否しながら、実装担当にはネットワークアクセスを許可できます。

この制限はドキュメントに明記されており、重要です。OS サンドボックスが適用されるのは sys_os_* の tool call とターミナルです。MCP サーバーには適用されず、Omnigent の supervisor プロセス自体にも適用されません。起動した MCP サーバーは、ユーザーの権限でサンドボックスの外部で実行されます。この境界があるため、より強固な方法は、依然としてエージェントごとに使い捨てのマシンを 1 台用意することです。この方法については使い捨て VM で coding agent を実行するで説明しています。もう 1 つの課題は認証情報です。エージェントから Secret を遠ざけることは、6 つのサブエージェントが 1 台のホストを共有すると、容易になるどころか難しくなります。

支出上限はポリシーとして、同じファイルに定義します。

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]

1 つ目のベンダーで計画し、2 つ目のベンダーで実装し、3 つ目のベンダーでレビューする実行では、同時に 3 か所で支出が発生します。そのため、最初の請求後ではなく、最初の unattended run の前に上限を設定してください。組み込み機能には max_tool_calls_per_session と ask_on_os_tools もあります。これらは、ファイル操作や shell 操作の前に承認を求めます。VPS 上で AI agent のコストを抑えるで説明している内容は、ここにもそのまま適用できます。並列のサブエージェントを使うと支出の増加速度が高まるため、ここではさらに重要です。

このリポジトリの開発はどのくらいの速さで進んでいますか？

ChartDays between tagged Omnigent releases, v0.2.0 to v0.7.0

version

released

interval

v0.2.0

2026-06-19

v0.3.0

2026-06-27

v0.4.0

2026-07-03

v0.5.0

2026-07-10

v0.5.1

2026-07-10

v0.6.0

2026-07-21

v0.7.0

2026-07-27

The data behind this chart

[
  {
    "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 日にプロジェクト独自のリリースページから確認した、公開リリース日です。2026-06-19 から 2026-07-27 の間に 7 件のタグ付きリリースが公開され、2 つのリリース間の最長間隔は 11 日でした。v0.5.1 は、その直前のリリースと同じ日に公開されています。最初のリリースである 2026 年 6 月 16 日の 0.1.1 は、測定元となる前のタグがないため、グラフから除外しています。

これらのリリースのうち 2 件では、ガイドですでに説明されていたコマンドが動作しなくなりました。v0.7.0 では omni server start が削除され、代わりに omni server --background が使用されます。v0.6.0 では omnigent[memory] の extra が omnigent[hindsight] に変更されたため、6 月の記事からコピーしたインストール行は、7 月のビルドでは失敗します。これは、好みの問題ではなく、インストールコマンドに --version を指定し、git clone にタグを指定する必要がある理由です。

現時点では任せないこと

2026 年 8 月時点で、このリポジトリには約 8.1k 個のスター、1.2k 個のフォーク、約 350 件のオープン issue があります。最初の公開リリースからは 7 週間しか経過していません。スターは関心の度合いを示すものであり、成熟度を示すものではありません。プロジェクト自身が alpha と述べており、前述のリリース履歴もその意味が alpha であることを示しています。

本番環境の認証情報を保持するホストでは実行しません。sandbox は MCP サーバーと supervisor を対象としていないためです。
cost_budget ポリシーなしで実行を放置しません。3 つのベンダーが並行して課金でき、それを止める仕組みが他にないためです。
OMNIGENT_AUTH_ENABLED を設定し、前段に TLS を置かずに、サーバーをパブリック IP アドレスで公開しません。
まだ agent YAML がマイナーバージョン間で安定しているとは考えません。そのため、バージョンを固定し、アップグレード前にリリースノートを確認してください。

予期せぬ動作を避けるため、もう 1 つ確認しておくことがあります。v0.6.0 では匿名化された使用状況テレメトリが追加され、プロジェクトは専用のテレメトリページで説明しています。そのマシンでクライアントの作業を扱う場合は、そのページを読み、意図的に判断してください。

現在の 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 0.7.0 のように、--version を sh -s -- とともにインストールスクリプトへ渡します。-s -- を指定しない場合、そのフラグは sh 自体によって消費され、スクリプトは最新リリースをインストールします。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 サーバーには、どの程度のメモリが必要ですか？

プロジェクトのデプロイに関するメモでは、サーバーのワーキングセットをおよそ 512 MB〜1 GB としており、Fly.io の設定では 1 GB を割り当てています。これはスーパーバイザーと、6767 番ポートだけで動作する Web インターフェイスを対象とした値です。各サブエージェントは、独自の作業コピーとモデルクライアントを持つ別個のプロセスです。また、Polly 形式の実行では git worktree を並列に使用します。そのため、サーバーではなく、同時に実行するエージェント数に応じて RAM とディスク容量を確保してください。

#omnigent#ai-agents #orchestration #open-source #cli