はじめに
2026年9月30日に、『Omnigentによるメタハーネス入門』の基礎編とチーム運用編が翔泳社から刊行されます。
これまで、Omnigentについて何本か記事を書いてきました。
- メタハーネスとは何か ― Databricks発のOSS『Omnigent』が解決しようとしていること
- Omnigentのアーキテクチャをステップバイステップで理解する ― サーバー・ランナー・2つのサンドボックス
1本目ではOmnigentが何をするのかを、2本目ではどういう部品でできているのかを説明しました。振り返ると、「そもそも、なぜこの層が必要なのか」は十分に書けていませんでした。「なぜ必要か」を飛ばして説明すると、メタハーネスという言葉は急に分かりにくくなります。
この記事では、コードや設定は出さず、メタハーネスが必要になるまでの流れを図で順番に追っていきます。
- Databricks 上の Omnigent
- Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents
出発点は、1つのプロバイダーだけに頼ることへの懸念
コーディングエージェントを1つだけ使っていても、たいていの作業はこなせます。小さな修正や調べものなら、それで十分です。
それでも複数のプロバイダーのモデルを使いたくなる理由は、大きく分けて2つあります。
品質の懸念
同じモデルにコードを書かせて、同じモデルにレビューさせると、見落としに気づきにくくなります。レビューするモデルが、自分の出した答えを前提にして読んでしまうためです。
別のベンダーのモデルにレビューさせると、書いたモデルとは違う観点でコードを読むことになります。実装とレビューを別のモデルに分けたい、という動機はここから来ています。
依存の懸念
1つのプロバイダーだけに頼っていると、そのプロバイダー側の変化の影響をそのまま受けます。
- 障害が起きると、作業が止まる
- 料金や利用条件が変わると、そのまま従うしかない
- 別のモデルのほうが得意な作業が出てきても、乗り換えにくい
どちらの懸念から出発しても、行き着く先は同じです。複数のプロバイダーのモデルを組み合わせて使う、という形になります。Databricksのブログでも、最良の結果はもはや1つのハーネス上の1つのモデルからは生まれない、と書かれています。
モデルを替えるだけなら、ハーネスの中でできる
ここで「ハーネス」という言葉を確認しておきます。ハーネスは、モデルに指示を渡し、モデルが呼び出したツールを実行し、その結果をまたモデルに返す、という繰り返しを回す仕組みです。Claude CodeやCodexはハーネスです。
ハーネスによっては、設定でモデルを切り替えられます。以前の記事で試したopencodeもその1つで、Databricks Model ServingのClaudeをモデルとして使えました。
つまり、モデルを差し替えるだけなら、ハーネスの中で済みます。ハーネスという仕組みが、モデルを差し替え可能にしたと言えます。
それでも各社のハーネスを並べて使う
ところが実際には、Claude CodeとCodexを両方開いて、並べて使っている人が少なくありません。
各社のハーネスは、自社のモデルと一緒に開発されています。そのモデルの力を一番引き出せるのは、そのモデルに合わせて作られたハーネスで使うときだ、というのが筆者の見方です。Claudeを使うならClaude Codeで、OpenAIのモデルを使うならCodexで、という選び方になります。
その結果、複数のモデルを組み合わせようとすると、ハーネスを並べて使うことになります。
ハーネスの間には境目がある
ハーネスを並べると、その間に境目ができます。Databricksのブログでは、ハーネスごとに操作方法が違うので、組み合わせたり入れ替えたりするのが難しい、と説明されています。
境目では、人が次の4つの作業を手でやっています。
- 出力の受け渡し
- コンテキストの説明し直し
- 権限とガードレールの設定し直し
- チームへの結果の共有
4つの作業を1枚の図にまとめると、次のようになります。
ハーネスが2つで作業が少ないうちは、これでも回ります。ハーネスが増え、並行する作業が増えるほど、人の手作業が増えていきます。
ここから1つずつ見ていきます。
作業1: 出力の受け渡し
Claude Codeが書いたコードの差分をコピーして、Codexに貼ってレビューを頼みます。レビューの指摘をまたコピーして、Claude Codeに戻します。1本目の記事では、このときの人の役回りを「エージェント間の伝言役」と書きました。
作業2: コンテキストの説明し直し
ハーネスごとにセッションが分かれているので、片方で説明した前提は、もう片方には伝わっていません。プロジェクトの方針や、どこまで作業が進んだかを、ハーネスを替えるたびに説明し直すことになります。
作業3: 権限とガードレールの設定し直し
どのコマンドの実行を許すか、どの操作に承認を求めるかは、ハーネスごとに設定します。同じルールを守らせたくても、ハーネスの数だけ設定が必要です。コストについても、複数のハーネスの合計に上限をかけたい場合は、ハーネスの外に仕組みが必要です。
作業4: チームへの結果の共有
エージェントの作業結果をチームに見せるには、Slackやドキュメントにコピーして貼ることになります。作業中のセッションそのものを見せるのではなく、結果を切り出して渡す形になります。
境目を1つ上の層で引き受けるのがメタハーネス
メタハーネスは、各社のハーネスを共通の方法で扱えるようにする層です。Databricksのドキュメントでは、Omnigentを次のように説明しています。
Omnigent は、Claude Code、Codex、Cursor、Pi、および自分で作成したエージェントの上に共通のレイヤーを提供します。
ハーネスそのものは置き換えません。Claude CodeもCodexも、そのままの形で動きます。メタハーネスは、その上で境目の作業を引き受けます。
前のセクションの4つの作業と、Omnigentの3つの機能の対応は次のとおりです。
| 境目での作業 | Omnigentの機能 | Omnigentがやること |
|---|---|---|
| 作業1: 出力の受け渡し | 組み合わせ (Composition) | 実装はClaude Code、レビューはCodex、という分担を1つの流れとして定義して動かす |
| 作業2: コンテキストの説明し直し | 組み合わせ (Composition) | 指示やスキルを1つのエージェント定義にまとめ、どのハーネスで動かすときも同じ定義を使う |
| 作業3: 権限とガードレールの設定し直し | 制御 (Control) | ポリシーを1か所に書き、どのハーネスにも同じように適用する |
| 作業4: チームへの結果の共有 | 共有 (Collaboration) | 動いているセッションをURLで共有し、チームで同時に見る |
制御については、コスト制御の記事で実際に確かめました。1つのサーバー設定で、Claude CodeとCodexの両方に同じ予算の上限がかかりました。一方で、ハーネスをネイティブのまま動かす場合には効かないポリシーもありました。すべてのポリシーがどのハーネスにも同じように効くわけではない点は、押さえておく必要があります。
層がもう1つ積み上がった
ここまでの流れを、層の積み上がりとして整理します。
- ハーネスが登場して、ハーネスの下でモデルを差し替えられるようになった
- メタハーネスが登場して、メタハーネスの下でハーネスを差し替えたり組み合わせたりできるようになった
メタハーネスは、ハーネスがモデルに対してやったことを、1つ上の層でハーネスに対してやっている、と言えます。こう整理すると、「ハーネスのハーネス」という言い方も素直に読めるようになります。
本で続きを読む
この記事では、メタハーネスが必要になるまでの流れだけを追いました。実際にOmnigentを動かして、エージェントを組み合わせたり、ポリシーをかけたり、チームで共有したりするところは、書籍で扱っています。
| 巻 | 扱う内容 | こんな方に |
|---|---|---|
| 基礎編 | メタハーネスを扱うための基本概念と、使い方のイメージの具体化 | メタハーネスという考え方をまず理解したい方 |
| チーム運用編 | 育てたエージェントや知見をチームで共有し、協業する方法 | 個人でのAIツール利用が属人化していて、チームに広げたい方 |
| エンタープライズ編 | 刊行予定 | 組織での統制や導入判断に関わる方 |
どちらも電子書籍 (EPUB) で、2027年初頭に大型アップデートが予定されています。先に購入した方も、更新された内容をダウンロードできます。
この記事で「なぜ」が腹に落ちた方は、基礎編から読むのがおすすめです。
まとめ
メタハーネスが必要になるまでの流れを整理すると、次のようになります。
- 出発点は、1つのプロバイダーだけに頼ることへの懸念。懸念には品質と依存の2種類がある
- モデルを差し替えるだけなら、ハーネスの中でできる
- それでも各社のモデルを活かすには、各社のハーネスを並べて使うことになる
-
ハーネスの間には境目があり、人が次の4つの作業を手でやっている
- 出力の受け渡し
- コンテキストの説明し直し
- 権限とガードレールの設定し直し
- チームへの結果の共有
- メタハーネスは、ハーネスを置き換えずに、その上で境目の作業を引き受ける層
- ハーネスがモデルを差し替え可能にしたのと同じことを、メタハーネスはハーネスに対してやっている
一番の収穫は、メタハーネスを定義から説明するより、境目で人がやっている作業から説明したほうが伝わる、と気づけたことでした。複数のエージェントの間でコピーと貼り付けを繰り返している方は、その作業がいくつあるかを一度数えてみると、この層の必要性が見えてくると思います。
参考リンク
- Databricks 上の Omnigent
- Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents
- メタハーネスとは何か ― Databricks発のOSS『Omnigent』が解決しようとしていること
- Omnigentのアーキテクチャをステップバイステップで理解する ― サーバー・ランナー・2つのサンドボックス
- Omnigentのコスト制御を設定して、予算が実際にどう効くか確かめた
- 『Omnigentによるメタハーネス入門』が9/30に刊行されます — 全3巻の構成と、どの巻から読むか