Omnigentとは｜Claude CodeやCodexを差し替えるメタハーネスをポリシーとサンドボックスで解説

複数のAIコーディングエージェントを併用していると、必ず同じ壁に当たる。Claude Code用に書いた設定はCodexでは使えず、Cursorに移ればまた最初から書き直しになる。Omnigent（omnigent-ai・★8,007・Apache-2.0・Python）は、この乗り換えコストそのものを標的にした「メタハーネス（meta-harness）」だ。エージェントの定義はYAML1枚に置き、executor.harness の値を書き換えるだけで実行基盤を差し替える。そのうえでポリシーによる行動制御とOSサンドボックスによる隔離を、同じ仕組みの中に持つ。

エージェント基盤の全体像や他フレームワークとの位置づけを先に押さえたい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証を参照してほしい。本記事はその中でも「既存ハーネスを束ねる層」に絞り、差し替えの代償を実際に測るところまで踏み込む。

Omnigentとは——「メタハーネス」が解こうとしている問題

ハーネス（harness）とは、LLM本体の周りでツール実行・権限確認・履歴管理・サブエージェント起動などを担う「外枠」を指す。Claude Code、Codex CLI、Cursorはいずれも独自のハーネスを持っており、そこがベンダーごとに固有であるために乗り換えコストが生まれる。

Omnigentが取ったアプローチは、ハーネスを置き換えるのではなくハーネスの上に薄い共通層を敷くことだ。公式READMEはこれを meta-harness と呼び、次の6点を掲げている。

・どの端末からでも触れる——ターミナルで始めたセッションをブラウザやスマートフォンで継続。メッセージ・サブエージェント・ターミナル・ファイルが同期する
・複数エージェントの併走——Claude Code、Codex、Cursor、OpenCode、Hermes、Pi、YAMLで自作したエージェントを同一セッションに混ぜられる。片方の成果物をもう片方にレビューさせる使い方も想定されている
・任意のモデル——ベンダー直APIキー、Claude／ChatGPTのサブスクリプション、互換ゲートウェイのいずれも一級市民として扱う
・共同作業——セッションを共有してチームメイトがチャットに参加、あるいは実行中セッションへの co-attach、会話のフォーク
・クラウドサンドボックス——Modal・Daytona・Islo・E2B・CoreWeave・Kubernetes・OpenShell・Boxlite・Databricks 上で実行可能
・ポリシーによる統制——危険な操作の前で承認待ちにする、支出に上限を設ける、到達できるツールを絞る

このうち本記事が主題にするのは後半2つ、つまりポリシーとサンドボックスである。前半4つは「便利さ」の話だが、後半2つは「差し替え可能な基盤の上で、どうやって統制を効かせるか」という設計上の難所だからだ。

リポジトリの実体

2026年8月2日時点でGitHub APIから取得した実測値は次のとおり。

作成から7週間ほどで★8,007という立ち上がりの速さに対し、公開issueが812件ある点は見落とさない方がいい。READMEが自ら alpha を宣言しているとおり、開発途上のプロジェクトである。

インストールと最初のセッション

導入はワンライナーのブートストラップスクリプトが用意されている。

# 公式インストーラ（uv・依存ツールの導入まで面倒を見る）
curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh

# 手動で入れる場合（Python 3.12以上が必要）
uv tool install omnigent

# サンドボックスプロバイダやSDKハーネスを追加する場合
uv tool install "omnigent[databricks,modal]"

インストールすると omnigent と omni の2つの名前が同じCLIとしてPATHに載る。READMEはこれを明示しており、どちらを叩いても同じだ。

起動すると対話的にモデルを選び、ターミナルでセッションが始まると同時に http://localhost:6767 にローカルWeb UIが立ち上がる。同じセッションがブラウザからも見える構成だ。

omnigent                # モデルを選んでセッション開始（Web UIも同時に起動）
omnigent claude         # Claude Codeを指定して起動
omnigent codex          # Codex
omnigent server --background   # サーバーをバックグラウンド起動
omnigent host           # このマシンを実行ホストとして登録

READMEによれば初回起動時、環境にすでにある ANTHROPIC_API_KEY / OPENAI_API_KEY、あるいはログイン済みの claude / codex CLIを検出し、そのひとつを既定として提案する。

同梱サンプル：PollyとDebby

リポジトリには2つのサンプルエージェントが同梱されている。設計思想が端的に出ているので触れておく。

・🐙 Polly——自分ではコードを書かないマルチエージェント・オーケストレータ。テックリードとして計画を立て、Claude Code／Codex／Piのコーディング用サブエージェントに並列のgit worktreeで作業を委譲し、上がってきた差分を書いたのとは別ベンダーのレビュアへ回す。マージ判断は人間が行う
・🟠🔵 Debby——ClaudeとGPTという2つの頭を持つブレインストーミング相手。同じ質問を両方に投げて回答を並べ、/debate で頭同士に数ラウンド批評させてから収束させる（Claude・OpenAI双方のクレデンシャルが必要）

Pollyの「書いた側と違うベンダーにレビューさせる」設計は、メタハーネスであることを前提にしないと成立しない。単一ベンダーのハーネスでは物理的に組めない構成だ。

エージェント定義はYAML1枚

自作エージェントは短いYAMLで書く。差し替えの中心になるのが executor.harness である。

name: my_agent
prompt: You are a helpful data analyst.

executor:
  harness: claude-sdk        # ここを codex / cursor / pi などに変えるだけで実行基盤が変わる

tools:
  word_count:                # ローカルPython関数（スキーマは署名から自動生成）
    type: function
    callable: mypackage.mymodule.word_count
  docs:                      # MCPサーバー（ローカルコマンド or リモートURL）
    type: mcp
    url: https://example.com/mcp
  researcher:                # サブエージェント（スーパーバイザーが委譲できる）
    type: agent
    prompt: Search for relevant information and summarize it.
    tools:
      word_count: inherit

理屈のうえでは、この1行を書き換えるだけでベンダーを移れる。問題は、書き換えた先で同じことができるとは限らない点だ。次のセクションがその話になる。

24のハーネスは対等ではない——能力マトリクスを実際に出力する

Omnigentの実装で最も特徴的なのは、ハーネスごとの能力差をコード上の宣言として明示していることだ。omnigent/harness_capabilities.py は冒頭で、これがどういう意図の設計かを自ら説明している。以前は if harness == "x" という分岐やコンパニオンモジュールの有無に散らばっていた「そのハーネスに何ができるか」を、ひとつの宣言型の形に集約した、と。

実際の宣言は omnigent/harness_plugins.py の _BUILTIN_CAPABILITIES にある。これを機械的に集計すると、24の組み込みハーネスが次のように分布する。

軸ごとの分布は次のとおり。いずれも v0.7.0 タグと main（d880afe）の双方で同数だった。

「差し替えられる」と「差し替えても同じ」は別物だ、という事実がここに出ている。サブエージェントを起動できるのは24中3つ、認証をOmnigent側に預けられるのは7つだけで、残り14は各ベンダーのログインを自分で持つ。Pollyのようなサブエージェント委譲型の構成は、そもそも3つのハーネスの上でしか成立しない。

同梱ベンチをクレデンシャル無しで走らせる

ここからがOmnigentの面白いところで、リポジトリは tests/harness_bench/ に適合性テストベンチを同梱している。宣言された能力と実挙動を突き合わせ、食い違い（DRIFT）を炙り出すためのものだ。しかも --no-live を付けるとターンもクレデンシャルも不要で、宣言だけのマトリクスを出力できる。

# リポジトリをクローンして、宣言のみのマトリクスを出力（APIキー不要）
git clone --depth 1 https://github.com/omnigent-ai/omnigent.git && cd omnigent
uv run --python 3.12 --with omnigent --with pytest \
  python -m tests.harness_bench --no-live --markdown

実際に手元で実行した結果が以下である（14ハーネス×12列。✓ SUPPORTED／✗ UNSUPPORTED／? UNKNOWN）。

この表から読み取るべきことは3つある。

1. 12列のうち6列が全ハーネス「?」。Fork replay・Reasoning・Omnigent MCP・Policy ALLOW・Policy ASK・Cost tracking は、宣言だけでは判定できない。ベンチのコードコメントは理由を「P1のプローブは、トランスポートや料金体系によって妥当な結果が変わるためUNKNOWNのままにする」と説明している。つまりマトリクスのちょうど半分は、自分のクレデンシャルで実際に走らせるまで埋まらない。

2. Policy DENYは全14で ✓、Policy ASKは全14で ?。ここは慎重に読む必要がある。ブロックは宣言上どのハーネスでも効くが、「承認待ちにして人間に聞く」挙動が実際にどのハーネスで成立するかは、宣言マトリクスからは分からない。承認の提示経路（elicitation）が none と宣言されたハーネスが24中10ある、という先ほどの数字と合わせて読むところだ。

3. streamingが ✗ の3つは実測由来。cursor-native・kiro-native・qwen-native の streaming=False について、ソースコメントは「LIVE-VERIFIED：ベンチ実行でテキストのデルタが0件だった」と書いている。kiro-nativeについては「SSEを丸ごとキャプチャしてデルタ0件、返答全体が単一の response.output_item.done で届く」とまで書き添えてある。

リポジトリ自身が認めている限界

コード内のコメントが、この能力宣言の信頼度について率直に書いている点は評価に値する。_BUILTIN_CAPABILITIES の直前にはこうある——interrupt と streaming の2つについてライブ検証が済んでいるのは claude-sdk・codex・pi・openai-agents の4つ（P0）だけで、残りは統合方式から推測したベストエフォートの宣言であり、カバレッジ拡大に伴ってベンチのプローブと突き合わせていく、と。

さらに正直なのが pi-native に関する注記だ。「フォワーダが external_output_text_delta を投げていない」という静的なgrepだけで streaming=False に倒すのは不十分で、pi-native はそうしたフォワーダを持たないにもかかわらずライブでは7件のデルタを流していた（どの経路かは追跡できていない）ため、grepに基づく判定は誤りだった——と自ら書いている。

なお steering（実行中のターンへの入力追加）・live_queue・images・compaction の4軸は、24ハーネスのいずれも宣言していない。この場合ベンチは「非対応」ではなく UNKNOWN として報告する設計になっており、HarnessCapabilities のdocstringにもその旨が明記されている。

ポリシーは3層で重なる——サーバー／エージェント／セッション

ポリシーは、エージェントの各アクションを評価して3値のいずれかを返す宣言的なゲートだ。docs/POLICIES.md（550行）の定義は明快である。

・ALLOW——そのまま実行させる
・DENY——ブロックし、エージェントにはエラーが返る
・ASK——承認待ちで一時停止。承認されればALLOW、拒否されればDENYとして扱われる

複数のポリシーは同時に有効化でき、宣言順に評価される。いずれかがDENYを返した時点で残りの評価は打ち切られる（short-circuit）。

層ごとに想定される担当者が違うのがこの設計の要点だ。

セッション層が最初に評価されるため、利用者が自分のセッションだけをより厳しくすることができる。逆に言えば、管理者が敷いたサーバー全体のガードレールは最後に評価されても、DENYは打ち切りとして効く。

判定の流れをまとめると次のようになる。

組み込みポリシーの中身

サーバー設定やエージェントYAMLには次のように書く。

policies:
  approve_shell:                 # シェル実行・ファイル書き込みの前に承認を求める
    type: function
    handler: omnigent.policies.builtins.safety.ask_on_os_tools
  cap_calls:                     # 1セッションのツール呼び出し回数に上限
    type: function
    handler: omnigent.policies.builtins.safety.max_tool_calls_per_session
    factory_params:
      limit: 50
  budget:                        # 支出の上限と、途中の警告しきい値
    type: function
    handler: omnigent.policies.builtins.cost.cost_budget
    factory_params:
      max_cost_usd: 5.00
      ask_thresholds_usd: [3.00]

omnigent/policies/builtins/ には safety・cost・github・risk_score・working_dir・prompt・cel・routing・orchestration・context などのモジュールが並ぶ。うち挙動として面白いのは cost_budget だ。ドキュメントによれば、これはリクエスト段階（テキストのみのターンも予算対象にするため）とツール呼び出し段階の両方で判定し、ソフトしきい値を初めて超えたときにASKを出す。そしてハードリミットに達しても完全停止はしない——「ダウングレードゲート」として振る舞い、セッションが高価なモデルを使っている間だけDENYして /model で安いモデルに切り替えるよう促し、切り替われば再び通す。

risk_score はツール呼び出しと機微データのラベルからセッション単位のリスクスコアを積算し、しきい値を超えると対象ツールをASKまたはDENYに格上げする。github ポリシーはMCPツールと git／gh シェルコマンドの両方を見て、読み取りを許可リストに、書き込みを特定リポジトリ／ブランチに制限し、対象が曖昧なシェルコマンドはASKを返す。

カスタムポリシーはPythonの関数として書け、"ALLOW" / "DENY" / "ASK" のいずれかを返すか、None を返して判断を棄権できる。

サンドボックスはOSで別物——seatbelt・bwrap・Job Object

ポリシーが「何をさせないか」を決めるのに対し、サンドボックスは「実行そのものをどこに閉じ込めるか」を担う。ここはOSによって中身がはっきり違い、READMEもその差を隠していない。

・Linux——omnigent <harness> のネイティブターミナルラッパーと pi ハーネスは、各エージェントのターミナルを bubblewrap（bwrap）のOSサンドボックスで包む。READMEはこの隔離を「mandatory（必須）」と書いており、bwrap バイナリが無いと該当ターミナルは起動に失敗する。インストーラが導入を提案する
・macOS——OS内蔵の seatbelt を使うため追加インストールは不要
・Windows（ネイティブ）——READMEが「degraded mode」と明記。動くのは omnigent server・Web UI・SDKベースのハーネスで、エージェントは Job Object によるプロセスツリー封じ込めの下で動く。ただしファイルシステムとネットワークは隔離されないと明言されており、bwrap／seatbelt によるFS・ネットワークのサンドボックスとL7 egressプロキシは利用できない。tmux/PTYのネイティブターミナルラッパーも非対応（WSLかLinux／macOSを使うよう案内している）

自分の環境がどの経路になるかは、ローカルで確認できる。

# Linux: bwrap が入っているか（native harness ターミナルの必須条件）
which bwrap && bwrap --version

# macOS: seatbelt は OS 内蔵（sandbox-exec の存在で確認）
which sandbox-exec

# native ターミナルラッパーが要求する tmux
tmux -V

クラウド側で隔離したい場合は、Modal・Daytona・Islo・E2B・CoreWeave・Kubernetes・OpenShell・Boxlite・Databricks のサンドボックスにセッションを載せられる。CLIから起動する方法と、サーバーがセッションごとに払い出す方法（managed hosts）の2通りがある。手元のマシンを常時起動させておく必要がない構成だ。

サンドボックスそのものの設計思想をもっと深く知りたい場合は、microVMを使った別アプローチであるCubeSandbox解説：60ms起動MicroVMでAIエージェントを安全実行するTencentの設計思想が比較対象になる。Omnigentがホスト上のOS機能（seatbelt／bwrap）で包むのに対し、あちらは仮想マシン境界で隔離する。

類似ツールとの比較——何が違うのか

「複数のコーディングエージェントを束ねる」というジャンルはすでに混雑している。実測値（2026年8月2日時点のGitHub API）を添えて整理する。

Star数だけ見れば ruflo と oh-my-openagent が桁違いに大きい。ただし比べている軸が違う。ruflo は自身のGitHub説明で “The original agent meta-harness” を名乗っており用語としては最も近いが、実体はClaude Code／Codexにネイティブ統合するプラグインであり、ホスト側のハーネスに寄り添う設計だ。oh-my-openagent も OpenCode／Codex の上に載る。

対してOmnigentは、どのベンダーのハーネスも等距離に置く共通層を先に用意し、そこにポリシーとサンドボックスを持たせている。agent-governance-toolkit はポリシー強制とサンドボックスを主題にする点で近いが、あちらは各言語のSDKとして自作エージェントに組み込む部品であり、既存のClaude CodeやCodexを差し替える層ではない。AgentENV はさらに下のレイヤー、実行環境そのものを大量供給する基盤だ。

同じ土俵で「Claude CodeやCodexを並列で走らせる」ことを目指すものとしては、tmux上で複数エージェントを束ねてレビュー差し戻しまで担うTUI型のツール群もある。そちらは端末体験の統合が主眼で、ポリシーやOSサンドボックスは扱わない。Omnigentが引いている線は「端末をどう見せるか」ではなく「差し替えたときに何が変わるかを宣言し、測れるようにする」ところにある。

ハーネスを「自分で組む」側の発想を知りたい場合は、Claude Codeを自律ループで回す設計を扱ったRalph：Claude Codeを自律ループで動かすハーネスエンジニアリングOSS｜15,000スターが対になる。Ralphがひとつのハーネスを深く作り込むのに対し、Omnigentは複数のハーネスを浅く広く束ねる。

ベンチの設計——DRIFTをCIで捕まえる

このベンチが単なるドキュメント生成器で終わっていないのは、宣言と実挙動の食い違いを機械的に検出することを目的に据えているからだ。出力の凡例には !! DRIFT というセルが用意されており、READMEは「DRIFTセルが1つでもあれば終了コードは非ゼロになる」と明記している。つまりCIに載せれば、ハーネス側のアップデートで挙動が変わったときに宣言の更新漏れが失敗として現れる。

走らせ方も細かく制御できる。

# 官製ハーネスの一覧（名前・解決されたトランスポート・モデル）
python -m tests.harness_bench --list

# 1つのハーネスだけ、モデルを固定して測る
python -m tests.harness_bench --harness codex=system.ai.gpt-5-6-sol

# 特定の観点だけ（basic_turn は前提として自動追加される）
python -m tests.harness_bench --harness codex --dimension reasoning

# 4並列＋ライブ進捗テーブル、結果をMarkdownで保存
python -m tests.harness_bench --jobs 4 --rich --report matrix.md --markdown

--live / --no-live を指定しない場合、ゲートウェイのクレデンシャルが解決できればライブで、できなければ宣言のみのマトリクスを描画する、という挙動になる。プローブは basic_turn / tool_calling / streaming / reasoning / interrupt / cost_tracking / fork_replay / model_override / omnigent_mcp / policy_allow / policy_ask / policy_deny の12種類がファイルとして並んでおり、コミュニティが自前の BenchProfile を module:attr 形式で渡して独自ハーネスを測ることもできる。

CONTRIBUTINGにも「ハーネスのサポートを追加・変更するならベンチを走らせて能力マトリクスを実挙動と突き合わせよ」と書かれている。宣言型のマトリクスが陳腐化しないよう、貢献フローの側で担保しようとしている構成だ。

Omnigentを導入する前に知っておくこと

最後に、実際に検討する際の判断材料を挙げる。

alpha であることを前提にする。 READMEに status: alpha バッジがあり、リポジトリ作成から7週間、公開issueは812件（2026-08-02時点）。設計とドキュメントの密度は高いが、成熟したプロダクトではない。

能力マトリクスは自分で実測する。 本記事で示した宣言マトリクスは12列中6列がUNKNOWNだった。自分が使うハーネスとモデルの組み合わせで python -m tests.harness_bench --harness <name> を走らせれば、Fork replay・Reasoning・Policy ALLOW/ASK・Cost tracking の実際が埋まる。DRIFTセルが1つでもあると終了コードが非ゼロになる設計なので、CIに載せることもできる。

認証の持ち方を確認する。 24ハーネス中14は各ベンダーのログインを自前で持つ（own-auth）。Omnigent側のクレデンシャル管理に一本化できるのは7つだけで、「鍵の管理を統合したい」という動機で入れる場合は期待とずれる可能性がある。

Windowsでの隔離に期待しない。 ネイティブWindowsではファイルシステムとネットワークの隔離が効かない。隔離を前提にするならWSLかLinux／macOS、あるいはクラウドサンドボックスを使う。

テレメトリは既定でオン。 READMEによれば匿名化された利用データを既定で収集し、機微情報や個人識別情報は含まないとしている。オプトアウトの手順は公式ドキュメントに案内がある。マネージドサービス経由で使う場合は、その契約側の収集条件も確認するようREADMEが促している。

アンインストールは段階が分かれている。 omnigent uninstall は既定でCLIとPATHエントリの掃除内容をプレビューし、履歴・クレデンシャル・プロジェクトは残す。状態ごと消すには --purge、ワークスペースまで消すには --purge-workspace を明示する必要がある。

マトリクスは動く。 v0.7.0タグと main（d880afe）を比較したところ、24ハーネスの顔ぶれと主要な軸は一致していたが、fork_history 軸とベンチ用のシェルツール定義（shell_tool_name / shell_tool_prompt）はv0.7.0の後に main で追加されたものだった。週単位で軸そのものが増える段階にある、と考えておくのが安全だ。

差し替え可能性というのは、本来こうやって測るものだと思う。「ロックインを外せる」という主張を、外した先で何が失われるかまで含めて表にして、しかも読者が同じ表を手元で再現できる形で置いてある。alpha の粗さを差し引いても、その姿勢自体が参考になるプロジェクトだ。

参照ソース

・omnigent-ai/omnigent — GitHub公式リポジトリ（README、omnigent/harness_plugins.py、omnigent/harness_capabilities.py、tests/harness_bench/。本記事の数値は main d880afe および v0.7.0 タグを実読・実行して取得）
・Omnigent Policies ドキュメント（docs/POLICIES.md）（ポリシーの3値・3層構造・組み込みポリシーの仕様）
・Omnigent 公式サイト
・omnigent — PyPI（v0.7.0 / 2026-07-27公開 / Python 3.12以上）