ザハリア氏によると、AIエージェントが動くことと、企業が安心してAIエージェントを使えることは別問題だという。さらに、「ハーネス」の乱立が新たな課題になっていると指摘する。

　ハーネスとは、大規模言語モデル（LLM）を外部の世界に接続するためのソフトウェア層を指す。例えば「Claude Code」は、Claudeというモデルに、ファイル操作、ユーザーインタフェース、権限管理などを組み合わせたハーネスだ。同様に、OpenAIの「Codex」や、各社が独自に構築する業務エージェントにも、それぞれ固有のハーネスが存在する。

　AIエージェントの開発が容易になったことで、各チームや各ベンダーが独自のハーネスを作るようになった。だが、その結果として、AIエージェント同士が分断され、業務利用に必要な共通機能を個別に作り込まなければならない状態が生まれている。ここで問題になるのは、個々のエージェントの性能ではなく、複数のエージェントを組織として使いこなすための運用基盤である。ザハリア氏は、主な課題を3つ挙げている。

課題1．複数のAIエージェントをどのように組み合わせるか

　エンジニアがある開発環境でコーディングエージェントを使う場合、1つだけを使うとは限らない。あるコーディングエージェントが行き詰まれば別のコーディングエージェントに聞き、複数のコーディングエージェントに異なる作業を並行して任せることもある。さらに、安価で高速な小規模モデルに作業を進めさせ、難しい判断だけ高性能なモデルに相談させる「アドバイザー」型の使い方も広がりつつある。

　こうした構成は、単一のハーネス内では実現しやすい。しかし、Claude CodeとCodexのように、異なるハーネスをまたいで利用する場合、連携は難しくなる。コーディングエージェントの活用が進むほど、「どのモデルを使うか」だけでなく、「異なるハーネスをどう組み合わせるか」が重要になる。

課題2．人間とAIエージェントがどのように協働するか

　現在のAIエージェント利用では、複数のエージェント画面、Slack、Google Docs、開発環境などを開き、利用者が手作業で情報をコピー＆ペーストする場面が多い。AIエージェントごとにアプリケーションや画面が分かれているため、作業のコンテキストを共有しにくい。

　例えば、あるエンジニアがコーディングエージェントとのやりとりを進めていたとする。その作業を別のエンジニアに引き継ぎたい場合、本来であれば、会話履歴、変更ファイル、判断の経緯を含めてセッション全体を共有できるべきだ。しかし、ハーネスが分断されていると、コンテキストの引き継ぎは簡単ではなくなる。

　AIエージェントを個人の補助ツールとして使う段階では、この問題は見えにくい。だが、チーム開発や業務プロセスに組み込む段階になると、AIエージェントと人間が同じ文脈を共有できる仕組みが必要になる。

課題3．セキュリティとコストをどう統制するか

　AIエージェントは、プロンプトインジェクション攻撃によって不正な指示を実行してしまう可能性がある。攻撃を受けていなくても、誤ってデータベースを削除するなど、重大なミスを起こす恐れもある。さらに、AIエージェントは処理内容によって利用コストが膨らむ。

　従来のAIエージェントツールにおいて、権限制御は「許可する」「拒否する」「ユーザーに確認する」といった静的な仕組みにとどまりがちだ。だが、ザハリア氏は、単純な確認ダイアログに頼るだけでは不十分だと指摘する。例えば、ユーザーに「100行のPythonスクリプトを実行してよいか」と尋ねても、実際に内容を精査できる人間は限られる。

　企業利用では、AIエージェントが過去にどの情報へアクセスしたか、現在どの作業をしているか、どれだけコストを使ったかに応じて、権限や予算を動的に制御する必要がある。

Databricksが提案する「メタハーネス」

　こうした課題に対してDatabricksが提案するのが、ハーネスの上位に置く共通レイヤー「メタハーネス」だ。Omnigentは、このメタハーネスを実装するオープンソースプロジェクトとして位置付けられる。

　Omnigentは、既存のエージェントやカスタムエージェントをそのまま置き換えるものではない。Claude CodeやCodexなどの既存ハーネスの上に共通インタフェースを提供し、メッセージの送受信、イベントの取得、ツール呼び出しなどを統一的に扱えるようにする。

　構成要素は大きく2つ。1つは、各AIエージェントを包み込み、サンドボックスや監視、セキュリティ制御を適用する「ランナー」だ。もう1つは、必要に応じて接続するサーバで、セッション履歴の一元管理、共同作業、中央ポリシー、MCPやスキルの管理、成果物の共有などを担う。

　OmnigentはDatabricks専用ではなく、コンテナ関連ツール「Docker」、リレーショナルデータベース管理システム（RDBMS）「PostgreSQL」、システムの稼働状況を監視するためのデータを一元的に収集するための標準仕様群「OpenTelemetry」といった標準的な技術を使って動作する。ザハリア氏は、AIエージェントの活用には単一ベンダーや単一SDK（ソフトウェア開発キット）を超えた共通レイヤーが必要であり、そのためにはオープンな仕組みが重要だと説明する。

実行中のAIエージェントを切り替え、複数エージェントを束ねる

　Omnigentの特徴の1つは、異なるハーネス上で動く複数のエージェントを組み合わせ、1つの作業フローとして扱える点だ。

　ザハリア氏は、Claude CodeをOmnigent経由で起動し、そのセッションをWeb UIから操作する様子をデモで紹介している。さらに、同じセッションをCodexに引き継がせ、履歴を保ったまま別のAIエージェントで作業を継続する様子も示している。

　これは、あるAIエージェントが作業に詰まった場合に、別のAIエージェントへ切り替えて続きを任せる使い方を想定したものだ。さらに、Omnigentでは「YAML」形式で記述されたファイルで複数エージェントを組み合わせる構成も定義できる。デモでは、Claude CodeとCodexを下位エージェントとして使い、上位の監督エージェントがそれぞれに作業を依頼する例も示されている。

　このような仕組みにより、単一エージェントに閉じた自動化ではなく、複数エージェントを役割分担させる構成を取りやすくなる。

作業セッションをチームで共有する

　Omnigentのもう1つの特徴は、エージェントとの会話履歴や作業内容、変更ファイルを複数の利用者で共有し、レビューや引き継ぎをしやすくする機能だ。

　ザハリア氏は、自分が進めているAIエージェントのセッションを別のエンジニアに共有し、レビューやコメントを依頼する様子をデモで示している。共有された側は、同じ会話履歴や変更内容を確認し、コメントを残したり、エージェントに追加指示を出したりできる。

　これにより、AIエージェントとのやりとりが個人のローカル環境に閉じなくなる。エンジニア、プロダクトマネジャー、デザイナーなどが、同じセッションを見ながら作業を進めることが可能だ。

文脈に応じた権限制御とコスト管理

　Omnigentは、セキュリティとコストの制御にも重点を置いている。

　従来のAIエージェントツールでは、ツールごとに許可・拒否・確認を設定する静的な制御が中心だった。これに対してOmnigentは、エージェントの過去の行動や現在の状態に応じて権限を変える「コンテキスト依存型」だ。

　例えば、AIエージェントが機密文書を読んだ後であれば、社外へのメール送信を制限する。一方、公開済みのマーケティング資料だけを扱っている場合は、外部送信を許可する。このように、アクセスした情報の状態を踏まえて制御できる点が特徴だ。

　また、AIエージェントの利用コストに対するポリシーも設定できる。デモでは、セッションごとに予算上限を設定し、一定額を超えそうになった場合にユーザーへ確認を求める例を紹介している。チーム単位で中央ポリシーを設定すれば、個々のユーザー任せにせず、AIエージェント利用のコストを管理しやすくなる。

AIエージェント活用は「個人ツール」から「業務基盤」へ

　Omnigentの発表が示すのは、AIエージェント活用の焦点が変わりつつあるということだ。

　これまでの関心は、どのモデルが賢いか、どのエージェントが作業を自動化できるかに集まりがちだった。しかし、企業利用が広がるにつれて、複数エージェントをどう組み合わせるか、作業時のコンテキストをどのように共有するか、セキュリティとコストをどう統制するかが重要になる。

　AIエージェントは、単独で動く便利な補助ツールから、チームや組織の業務基盤へ移行しつつある。その段階では、エージェントそのものだけでなく、エージェントを束ね、監視し、協働可能にする共通レイヤーが欠かせない。

　DatabricksがOmnigentをオープンソースとして公開した狙いもそこにある。特定のハーネスやSDKに閉じた仕組みではなく、エージェント間の相互運用性を高める共通基盤を作ることで、AIエージェント活用を次の段階へ進めようとしている。

本稿は、Databricksが2026年6月25日に公開した動画「Introducing Omnigent: an open meta-harness - Matei Zaharia, Co-founder and CTO, Databricks」を基に作成しました。