複数のAIエージェントを「束ねる」という発想
Claude Code、Codex、Pi、Gemini。コーディングや調査に使えるAIエージェントが一気に増えました。便利になった一方で、こんな状態に心当たりはないでしょうか。
エージェントを4つも5つも同時に開いて、片方の出力をコピーしてもう片方に貼り、その結果をさらにSlackやドキュメントに転記する。気づけば自分が「エージェント間の伝言役」になっている。
Databricksが2026年6月にオープンソース(Apache 2.0)で公開した Omnigent は、まさにこの「エージェントが増えたのに、それらを束ねる仕組みがない」という課題に向き合うツールです。そしてその中心にあるのが「メタハーネス(meta-harness)」という考え方です。本記事では、Omnigentが解決しようとしていることと、メタハーネスの考え方を整理します。
ハーネスとメタハーネス
まず「ハーネス」を押さえます。
Claude CodeやCodexのようなコーディングエージェントは、LLMの能力を「エージェントハーネス」という形で包んだものです。ハーネスの本質的な仕事は、LLMとの対話ループそのものです。会話履歴やファイルを組み立ててLLMに渡し、返ってきたツール呼び出しを実行し、その結果をまた次のループに食わせる。この「ぐるぐる回すループ」がハーネスで、Claude CodeやCodexはこれを完成品として持っています。
問題は、ハーネスごとにインターフェースがバラバラなことです。LLMの能力が各ハーネスの中に閉じ込められていて、それぞれ独自のコンテキスト、独自の制御、独自の実行方法を持つ「サイロ」になっている。だから組み合わせたり入れ替えたりが難しく、ツールを切り替えると何も引き継がれません。
メタハーネスは、その個々のハーネスのさらに「上」に立つ層です。Omnigentの説明を借りると、「エージェントハーネスはモデルを差し替え可能(swappable)にした。次の抽象化レイヤーがメタハーネスであり、それはあらゆるハーネスの上に位置し、合成・制御・協働が行われる層だ」という位置づけになります。
層の関係を図にするとこうなります。
LLM
└ ハーネス(対話ループ本体) ← Claude Code / Codex / 自作SDK
└ メタハーネス(統一窓口 + 運用層) ← Omnigent
ここで誤解しやすいのが、メタハーネスはハーネスを「提供」するわけではない点です。Claude CodeやCodexは依然として外から持ち込みます。メタハーネスが提供するのは、それらを包む共通の窓口(統一API)と、その周りの運用機能だけです。
なぜこの層が要るのか。Omnigentは、KubernetesやTerraformとの類比で説明しています。エンジニアはかつてサーバーを一台ずつ手で管理していたが、今はクラウドのオーケストレーション層で艦隊全体をまとめて扱う。同じ「一段上から管理する」発想が、エージェントの世界にもやってきた、という主張です。合成・セキュリティ・協働といった問題は、本質的に複数のハーネスにまたがる。だから単一のハーネスより上に、それらを引き上げる層が必要になります。
Omnigentが解決しようとしていること
Omnigentがメタハーネスとして提供する価値は、大きく3つに整理できます。
合成 (Composition)
複数のモデル・ハーネス・技法を、コードを書き換えずに組み合わせる。Claude Code、Codex、Pi、自作エージェントの間を設定一行で切り替えられる。
この背景には「最良の結果はもはや単一ハーネス上の単一モデルからは生まれない」という観察があります。実装は得意なモデルに、レビューは別ベンダーのモデルに、計画はまた別のモデルに、と役割分担させる。そういう使い方を、ハーネスをまたいで実現するのが合成です。
制御 (Control)
エージェントの行動を、プロンプトではなくメタハーネス層のポリシーで縛る。例えば「100ドル使うごとに一時停止して確認」「npmで新しいパッケージを入れた後のgit pushは人間の承認を必須にする」「自分が作成したファイルにしか書き込めない」といった、状態を追跡する文脈依存のガードレールを、サーバー全体・特定エージェント・個別チャットの単位で効かせられます。
協働 (Collaboration)
ライブのエージェントセッションをURLで共有し、チームで一緒に見て、コメントし、操作する。さらにOmnigentの売りとして、同じセッションをターミナル・ブラウザ・モバイル・デスクトップアプリのどこからでも開ける、という点があります。ノートPCで始めた作業を、外出先でスマホから続ける、といった使い方を想定しています。
動かしてみる: インストールとUI
インストールはワンライナーです。
curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh
Python 3.12以上が前提で、Claude Code等のハーネスを動かすにはNode.js 22 LTS以上とtmuxが必要です(インストーラが不足を検出して導入を促してくれます)。モデルプロバイダーは、APIキー、Claude/ChatGPTのサブスク、互換ゲートウェイ、Databricksワークスペースから選べます。
既存のClaude Codeをそのまま包んで起動するなら、
omnigent claude
これで、いつものClaude CodeがOmnigentのセッションとして立ち上がります。起動時に、そのセッションをブラウザで開くためのローカルURLが表示されます。
ここがメタハーネスらしい点で、ターミナルで動かしているセッションを、表示されたURLからブラウザで開くと、同じセッションがそのままWeb UIにも映ります。ターミナルとブラウザは別物を見ているのではなく、サーバー上の一つの生きたセッションを別の窓から覗いている関係です。
Web UIの構成はシンプルです。左にセッション一覧、中央にチャット欄(下部に現在のバックエンドのモデルが表示される)、右に3つのパネルがあります。
- Files: エージェントが作成・変更したファイルを一覧・閲覧できる
- Agents: 動いているエージェント(と、束ねられたサブエージェント)の一覧
- Shells: シェルセッション
右上の「Share」が、説明した協働機能の入口です。ここからセッションを共有すると、他の人がそのエージェントの作業をライブで見られます。
リポジトリには、メタハーネスらしさを体感できるサンプルエージェントが同梱されています。
omnigent run examples/polly/ # マルチエージェントのコーディング・オーケストレーター
omnigent run examples/debby/ # ClaudeとGPTの2つの頭で答えるブレスト相手
Polly は自分ではコードを書かず、テックリードとして振る舞います。タスクを計画し、実装を別々のworktreeで動くコーディング・サブエージェント(Claude Code / Codex / Pi)に振り分け、各diffを「実装したのとは別ベンダー」のレビュアーに回す。マージは人間が行う。これがブログで読んだ「合成」の、最もわかりやすい実演です。実際に動かすと、一行の指示が詳細な「受け入れ契約」に展開され、サブエージェントが起動していく様子を、Agentsパネルで観察できます。
現状はアルファ
正直に書いておくと、Omnigentはステータスが明示的に alpha です。コンセプトの中核である「単一のハーネスをUIやモバイル・共有から扱う」あたりは触れて確認できますが、Pollyのような「複数サブエージェントを束ねて実装からクロスレビューまで非同期で完遂する」部分は、環境によってはまだ素直に最後まで通らないことがあります。これはOmnigent自身も「現状は表面をなぞっただけで、自動最適化やより多くのハーネス対応はロードマップ」と認めている領域です。
裏を返せば、メタハーネスという抽象化が「正しい方向」かどうかを、思想と実装の両面から早い段階で覗ける、ということでもあります。モデルやハーネスはこれからも入れ替わり続ける。その上で「自分が作業する層」を一段上げておけば、下のモデルやハーネスが変わっても、セッション・ポリシー・スキルは手元に残る。Omnigentが賭けているのは、その一点です。
おわりに
Omnigentそのものを使うかどうかは別として、「メタハーネス」という抽象化の置き方は、エージェント開発の今後を考えるうえで示唆に富んでいます。個々のエージェントを賢くする競争の一段上に、それらを束ねて合成・制御・協働させる層がある、という見立て。Kubernetesがプロセス管理の一段上の層として定着したように、エージェントにも同じ抽象化の波が来るのか。少なくともDatabricksは、そこに張っています。
参考リンク:
- Databricksブログ: Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents
- GitHub: omnigent-ai/omnigent
- 公式サイト/ドキュメント: omnigent.ai