はじめに

2026年9月30日に、『Omnigentによるメタハーネス入門』の基礎編とチーム運用編が翔泳社から刊行されます。

『Omnigentによるメタハーネス入門』が9/30に刊行されます — 全3巻の構成と、どの巻から読むか

これまで、Omnigentについて何本か記事を書いてきました。

1本目ではOmnigentが何をするのかを、2本目ではどういう部品でできているのかを説明しました。振り返ると、「そもそも、なぜこの層が必要なのか」は十分に書けていませんでした。「なぜ必要か」を飛ばして説明すると、メタハーネスという言葉は急に分かりにくくなります。

この記事では、コードや設定は出さず、メタハーネスが必要になるまでの流れを図で順番に追っていきます。

出発点は、1つのプロバイダーだけに頼ることへの懸念

コーディングエージェントを1つだけ使っていても、たいていの作業はこなせます。小さな修正や調べものなら、それで十分です。

それでも複数のプロバイダーのモデルを使いたくなる理由は、大きく分けて2つあります。

品質の懸念

同じモデルにコードを書かせて、同じモデルにレビューさせると、見落としに気づきにくくなります。レビューするモデルが、自分の出した答えを前提にして読んでしまうためです。

別のベンダーのモデルにレビューさせると、書いたモデルとは違う観点でコードを読むことになります。実装とレビューを別のモデルに分けたい、という動機はここから来ています。

依存の懸念

1つのプロバイダーだけに頼っていると、そのプロバイダー側の変化の影響をそのまま受けます。

障害が起きると、作業が止まる
料金や利用条件が変わると、そのまま従うしかない
別のモデルのほうが得意な作業が出てきても、乗り換えにくい

どちらの懸念から出発しても、行き着く先は同じです。複数のプロバイダーのモデルを組み合わせて使う、という形になります。Databricksのブログでも、最良の結果はもはや1つのハーネス上の1つのモデルからは生まれない、と書かれています。

モデルを替えるだけなら、ハーネスの中でできる

ここで「ハーネス」という言葉を確認しておきます。ハーネスは、モデルに指示を渡し、モデルが呼び出したツールを実行し、その結果をまたモデルに返す、という繰り返しを回す仕組みです。Claude CodeやCodexはハーネスです。

ハーネスによっては、設定でモデルを切り替えられます。以前の記事で試したopencodeもその1つで、Databricks Model ServingのClaudeをモデルとして使えました。

ローカルのopencodeから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の両方に同じ予算の上限がかかりました。一方で、ハーネスをネイティブのまま動かす場合には効かないポリシーもありました。すべてのポリシーがどのハーネスにも同じように効くわけではない点は、押さえておく必要があります。

Omnigentのコスト制御を設定して、予算が実際にどう効くか確かめた

層がもう1つ積み上がった

ここまでの流れを、層の積み上がりとして整理します。

ハーネスが登場して、ハーネスの下でモデルを差し替えられるようになった
メタハーネスが登場して、メタハーネスの下でハーネスを差し替えたり組み合わせたりできるようになった

メタハーネスは、ハーネスがモデルに対してやったことを、1つ上の層でハーネスに対してやっている、と言えます。こう整理すると、「ハーネスのハーネス」という言い方も素直に読めるようになります。

本で続きを読む

この記事では、メタハーネスが必要になるまでの流れだけを追いました。実際にOmnigentを動かして、エージェントを組み合わせたり、ポリシーをかけたり、チームで共有したりするところは、書籍で扱っています。

巻	扱う内容	こんな方に
基礎編	メタハーネスを扱うための基本概念と、使い方のイメージの具体化	メタハーネスという考え方をまず理解したい方
チーム運用編	育てたエージェントや知見をチームで共有し、協業する方法	個人でのAIツール利用が属人化していて、チームに広げたい方
エンタープライズ編	刊行予定	組織での統制や導入判断に関わる方

どちらも電子書籍 (EPUB) で、2027年初頭に大型アップデートが予定されています。先に購入した方も、更新された内容をダウンロードできます。

この記事で「なぜ」が腹に落ちた方は、基礎編から読むのがおすすめです。

まとめ

メタハーネスが必要になるまでの流れを整理すると、次のようになります。

出発点は、1つのプロバイダーだけに頼ることへの懸念。懸念には品質と依存の2種類がある
モデルを差し替えるだけなら、ハーネスの中でできる
それでも各社のモデルを活かすには、各社のハーネスを並べて使うことになる
ハーネスの間には境目があり、人が次の4つの作業を手でやっている
- 出力の受け渡し
- コンテキストの説明し直し
- 権限とガードレールの設定し直し
- チームへの結果の共有
メタハーネスは、ハーネスを置き換えずに、その上で境目の作業を引き受ける層
ハーネスがモデルを差し替え可能にしたのと同じことを、メタハーネスはハーネスに対してやっている

一番の収穫は、メタハーネスを定義から説明するより、境目で人がやっている作業から説明したほうが伝わる、と気づけたことでした。複数のエージェントの間でコピーと貼り付けを繰り返している方は、その作業がいくつあるかを一度数えてみると、この層の必要性が見えてくると思います。

参考リンク

はじめてのDatabricks

はじめてのDatabricks

Databricks無料トライアル

Databricks無料トライアル