ガイド

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

Omnigentで複数のAIエージェントCLIを統合する方法

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

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

OmnigentはClaude CodeやCodexなど、インストール済みのagent CLIを1つのYAML設定で制御するメタハーネスです。release 0.7.0の固定方法とVPSで各sub-agentをsandbox化する手順を紹介します。

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 もハーネスです。インストールしてログインすれば、単独で動作します。

フレームワークは、コードから利用するライブラリです。インポートし、Python で手順を定義すると、そのプログラム自体がエージェントになります。この場合、ベンダーを変更するにはコードを編集する必要があります。ベンダーのクライアントがプログラムに組み込まれているためです。

メタハーネスは、ハーネスとフレームワークのさらに上位で動作します。ハーネスを子プロセスとして実行するスーパーバイザーです。Omnigent はベンダーの CLI を起動して作業を渡し、返された結果を読み取ります。すでにインストールしている CLI をそのまま使えます。CLI の利用料金を支払っている既存のサブスクリプションや API (application programming interface) key も、そのまま利用できます。違いはこれだけです。そして、この違いによって対象ユーザーが決まります。すでに複数のエージェント CLI を運用していて、それらを端末ごとに手動で操作することに疲れている人向けのツールです。

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 のタグは 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 自身はコードを書きません。目標を計画し、作業項目に分割し、それぞれを委任して、各 diff を別のベンダーのレビュアーに割り当てます。

Polly は、処理を委任する前に preflight check を実行し、実際に使用できるサブエージェント CLI がマシン上に存在するか確認します。1 つのベンダーの CLI しかインストールされていない場合、diff のレビューを依頼できる相手がいません。そのため、出力を評価する前に少なくとも 2 つインストールしてください。もう 1 つの同梱サンプルである Debby は、Claude と GPT という 2 つのヘッドを持つ debate エージェントです。

omni debby

何らかの応答を返すには両方が必要なため、2 つのプロバイダーが設定されていることを簡単に確認できます。

サブエージェントはツールとして宣言します

エージェントファイルは 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 もサポートされています。これを指定すると、親の会話がサブエージェントに渡されます。委譲のたびにトークンを消費するため、目の前のタスクだけが必要なサブエージェントでは指定しないでください。

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

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

omnigent server --background
omnigent server status

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

6767 を public address で公開しないでください。安全な構成は 2 通りあります。ファイアウォールで 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

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

コンテナでデプロイする場合、リポジトリの deploy/ ディレクトリに Compose の設定があります。./bootstrap.sh で .env に Secret を生成し、docker compose up -d で Omnigent と Postgres を port 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 は漏洩しません。複数のハーネスを使用する構成では、各サブエージェントが独自の設定ファイル内の agents/ 以下に独自のサンドボックスブロックを持ちます。そのため、レビュー担当にはネットワークを拒否し、実装担当にはネットワークを許可できます。

この制限はドキュメントに明記されており、重要です。OS サンドボックスが適用されるのは sys_os_* のツール呼び出しとターミナルです。MCP サーバーには適用されず、Omnigent の supervisor プロセス自体にも適用されません。起動した MCP サーバーは、あなたの権限でサンドボックスの外部で実行されます。この差があるため、より強固な構成は現在もエージェントごとに使い捨てのマシンを 1 台用意する方法です。詳細は使い捨て VM でコーディングエージェントを実行するを参照してください。もう一つの課題は認証情報です。6 個のサブエージェントが 1 台のホストを共有すると、エージェントの手の届かない場所に Secret を保管することは容易になるのではなく、難しくなります。

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

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 か所で支出が発生します。そのため、最初の請求書を受け取ってからではなく、最初の無人実行を開始する前に上限を設定してください。組み込み機能には max_tool_calls_per_session と ask_on_os_tools もあります。これらを使用すると、ファイル操作と shell 操作の前に承認を求めることができます。VPS 上で AI エージェントのコストを抑えるに関する説明は、ここにもそのまま適用できます。並列サブエージェントでは支出速度が増幅されるため、より重要です。

リポジトリの更新ペースはどの程度ですか？

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 相当であることが分かります。

本番環境の認証情報を保持するホストでは実行しません。サンドボックスは 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 台のマシンで、実際のサンドボックスを利用して、これは現在でも動作します。それを超える部分については、将来性はあるものの、まだ完成していない機能として扱ってください。

FAQ

Omnigent はエージェントですか。それともエージェントを実行するものですか。

エージェントを実行します。Omnigent はメタハーネスです。すでにインストールしている Claude Code、Codex、OpenCode などのベンダー CLI を起動し、それぞれに作業を割り当て、1 つのセッションで結果を監督します。独自のモデルは搭載していません。Python からライブラリを使って自分のプログラムをエージェントにするフレームワークとは、この点が異なります。

Omnigent を有用にするには、Claude Code と Codex を事前にインストールする必要がありますか。

少なくとも 1 つのベンダー CLI をインストールし、ログインしておく必要があります。Omnigent はそれらのプログラムを操作するものであり、置き換えるものではないためです。付属の Polly の例を使う場合は、異なるベンダーの CLI を 2 つ以上用意します。Polly では、レビューは必ず実装担当とは異なるベンダーが行うというルールになっています。そのため、CLI が 1 つしかない場合、差分を送る別のベンダーが存在しません。

Omnibox のサンドボックスで、エージェントを無人で実行するのに十分ですか。

対象範囲については強力で、対象外も明確です。Linux では bubblewrap と seccomp を使用するため、ファイルとネットワークの制限をカーネルが適用し、エージェントが回避することはできません。ドキュメントによると、これは sys_os_* のツール呼び出しとターミナルに適用されますが、MCP サーバーや Omnigent のスーパーバイザープロセスには適用されません。したがって、MCP サーバーは通常の権限で実行されます。無人運用では、エージェントごとに使い捨ての仮想マシンを用意するほうが、より強力な分離になります。

VPS 上の Omnigent サーバーには、どの程度のメモリが必要ですか。

プロジェクトのデプロイに関する注意事項では、サーバーのワーキングセットをおよそ 512 MB から 1 GB としています。また、Fly.io の構成では 1 GB を割り当てています。これは、スーパーバイザーと port 6767 で待ち受ける Web インターフェースだけを対象とした値です。各サブエージェントは、独自の作業コピーとモデルクライアントを持つ別プロセスです。Polly 形式の実行では、並列の git worktree も使用します。そのため、サーバーではなく、同時に実行するエージェント数に合わせて RAM とディスク容量を決めてください。

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