Omnigent というメタ・ハーネス：AI エージェントのための OSS フレームワークを実現

Omnigent: Open-source AI agent framework and meta-harness

2026/07/06 HelpNetSecurity — 多くの開発者が、複数のコーディング・エージェントを手元に置いている。彼らは、あるタスクでは Claude Code を使い、次のタスクでは Codex や Cursor を使うという形で使い分けている。それぞれのツールは、独自のコマンドラインや、独自の認証情報の扱い方に加えて、作業ディレクトリに対して shell command を実行するための独自の方法を備えている。この分散により、エージェント操作が帰結する場所や、必要とされるコストなどについて、チーム・ガバナンス上の空白が生じている。

オープンソース・プロジェクトである Omnigent は、これらのツールの上位レイヤーに置かれる meta-harness として機能する。この共通レイヤーは、Claude Code／Codex／Cursor／OpenCode／Hermes／Pi などに加えて、チームが YAML で記述したエージェントを駆動するため、ユーザーは 1 行の変更のみで、それらを切り替えたり組み合わせたりできる。

Omnigent は、ファーストパーティ API key／Claude や ChatGPT のサブスクリプション／OpenRouter のような互換ゲートウェイを利用し、エージェントごとのデフォルト設定を備えており、ユーザーに対してセッション途中での切り替えも提供する。なお、1 つのセッションは、terminal／ browser／phone のユーザーを追跡し、message／sub-agent／terminal／file が同期される。

ハーネス・レイヤーで設定されるガードレール

このセキュリティ設計の中心にあるのは Policy である。この Policy は、shell command／file 編集／token 消費にわたってエージェントが実行する内容を規定し、すべての操作を検査して、許可／遮断を判断し、人間による承認のための一時的な停止についても判断する。

支出上限とアクセス制限がビルトインされているため、セッションに対しては緩やかな警告を出しながら、厳格なドル建て上限を持たせることができる。これらの検査は、ステートフルなデータ中心のルールとして meta-harness レイヤーで実行され、エージェントの操作を追跡する。これにより、エージェントが逸脱して通り過ぎる恐れのあるプロンプトではなく、その外側で強制力を維持する。

Policy は 3 層構造を持つ。アドミンはサーバ全体に適用されるルールを設定し、開発者はエージェントごとのルールを設定し、セッション内の利用者はセッションごとのルールを設定するが、最初には厳しいセッション・ルールが検査される。なお、チームとしては、チャット内の平文で Policy を記述し、それをエージェントが組み立てる。

sandbox 化／broker 化される認証情報

それぞれのエージェントは、ファイル・システムとネットワークにおける到達範囲を制限するための、OS サンドボックス内で実行される。Linux では、この分離は bubblewrap により実現され、ネイティブ terminal wrapper に対して必須となっている。macOS では、組み込みの seatbelt sandbox に依存する。

このサンドボックスは、エージェントから認証情報を隠し、それらへのアクセスを broker として実行するため、秘密情報を引き渡さない状態のユーザーが、エージェントに対して裁量を与えることが可能になる。Omnigent は、これを “Run YOLO (You Only Look Once) mode safely” の方法だと説明している。

Windows のサポートは、機能が制限された形で提供される。そこでのエージェントは、process tree の封じ込めとリソース制限のために Windows Job Object の下で実行されるが、ファイル・システムとネットワークの分離は存在しない。そのため、サンドボックス化を必要とする場合には、Linux／macOS／WSL が推奨される。

共有 session と host machine

コラボレーションは共有セッションを通じて実行される。そのリンクを開くチームメイトは、履歴／inline comment／code editor を並べて確認しながら、リアルタイムでエージェントを追跡できる。

2 つ目の mode である co-drive では、チームメイトが実行中のセッションに接続し、そのメッセージはホスト・マシン上で実行される。このモードは、pair 作業や調査の途中で、ドメイン・エキスパートに操作を引き渡す用途に適している。この構成では、共同作業者が引き起こした内容に対してホストが責任を負うことになり、共有セッションを範囲内に保つ制御として、Policy レイヤーとサンドボックスが機能する。アカウントは invite-only であり、Google／GitHub／Okta／Microsoft を通じて、展開済みサーバの sign-in をルーティングできる。

すべての diff に対する 2 社目のベンダー

2 つのサンプル・エージェントが repo に同梱されている。そのうちの Polly は、コーディング・オーケストレーターとして機能し、planning と delegation を処理する。彼女は、git worktree 内の並列化された coding sub-agent に作業を割り当て、それぞれの diff を、その diff を作成したベンダーとは異なるベンダーから選ばれたレビューに送り、merge はユーザーに委ねる。

もう一方の Debby は、2 つの頭脳を持つ brainstorming partner として機能する。一方は Claude であり、もう一方は GPT である。debate command は、両者が数ラウンドにわたり議論した後で収束するよう設定する。どちらのパターンも、同じ 1 つのアイデアに依拠している。すなわち、1 つの作業に対して複数ベンダーの model を投入するという考え方である。

どこで動作するのか

チームは、すべてをローカル PC 内に保持することが可能だ。また、Modal／Daytona／E2B／CoreWeave／Kubernetes といったプロバイダーが提供する、使い捨てのクラウド・サンドボックスへセッションを送ることもできる。したがって、コマンドラインからの起動も、マシンをオフラインに保つことも、セッションごとのプロビジョニングも可能となる。このプロジェクトでは、サーバがセッションごとにサンドボックスをプロビジョニングする構成を、マネージド・ホストと呼んでいる。その場合に、常時稼働するホストが作業を担う。

Omnigent は、GitHub 上で無償提供されている。

訳者後書：複数の生成 AI ツールを統合管理するオープンソース Omnigent が登場した背景には、各 AI の利用コストや操作権限の統制が難しく、開発チーム内でガバナンスの空白が生じてしまうという問題点があります。具体的に言うと、複数の外部サービスを使い分ける際の接続設定や命令の実行手順が分散し、システム全体の利用状況を監視する共通の枠組みが不足しています。もし適切な防護措置を取らずに放置すると、想定外の金銭的負担が発生したり、安全性の確認が不十分なコマンドを実行されたりするリスクがあります。対応策として、製品に組み込まれた 3 層のポリシー制御や OS サンドボックス機能を活用すれば、利用制限の上限設定や実行時における人間による承認ルールを厳格に適用／運用できるようになります。