Omnigentとは？Databricks発OSSメタハーネスの仕組みと導入方法・対応ハーネスを解説

Omnigent（オムニジェント）は、Databricksが2026年6月13日にApache 2.0ライセンスで公開したオープンソースの「メタハーネス」です。Claude CodeやCursor、Codexなど既存のAIエージェントの上位に立ち、それらを組み合わせ、ポリシーで制御し、チームで共有する共通レイヤーを提供します。この記事では、Omnigentの定義と公開の背景、メタハーネスが従来のエージェントハーネスと何が違うのか、合成・制御・協働という3つの中核機能、runner/serverのアーキテクチャ、OSS版とマネージド版の違い、そしてcurl1行やuv tool installから始める実際の導入手順までを一次情報にもとづいて整理します。公開時点はalpha版で、本稿執筆時点の最新はv0.5.1（2026年7月10日）です。

まとめ：Omnigentの位置づけと早期に押さえる3つの要点

Omnigentの結論は「個々のエージェントを置き換えるツールではなく、複数のエージェントを束ねる一段上のレイヤー」という点にあります。コーディングエージェントが普及した一方で、ツールごとにセッションも制御方法も分断されている課題に対し、Databricksはその上位に共通インターフェースを置くアプローチを選びました。

早期に押さえる要点は3つです。第一に、2026年6月13日にApache 2.0で公開されたalpha版で、最新はv0.5.1（2026年7月10日）とまだ実験的な段階にあること。第二に、合成・制御・協働という3機能で、ハーネス単体では解けない問題を狙っていること。第三に、無償のOSS版とは別に、ワークスペースのIDプロバイダー統合などを備えたDatabricksマネージド版（beta）があることです。検証や自社カスタマイズが目的ならOSS版を、組織での統制まで求めるならマネージド版を視野に入れる、という使い分けが出発点になります。導入はcurl1行またはPython 3.12+のuv tool install omnigentで始められ、後半で実コマンドを示します。

Omnigentの定義とDatabricksが2026年6月に公開した背景

まずOmnigentが何であり、なぜこのタイミングで登場したのかを整理します。製品名や公開日は時間で変わらない事実ですが、登場の文脈を押さえることで、後述する機能の意味が理解しやすくなります。

Apache 2.0で公開されたメタハーネスとしてのOmnigentの定義

Omnigentは、Databricksが「メタハーネス（meta-harness）」と呼ぶ新しいソフトウェアの種類です。Claude Code、Codex、Cursor、Pi、あるいは自作のカスタムエージェントといった既存のエージェントの上位に位置し、それらを相互運用可能な部品として扱えるようにします。2026年6月13日にApache 2.0ライセンスのもとでオープンソース公開され、ソースコードはgithub.com/omnigent-ai/omnigentで管理されています。ライセンスがApache 2.0である点は、商用利用や改変・再配布の自由度を判断するうえで重要です。各ライセンスの違いはオープンソースライセンスの概要と重要性で整理しているため、自社利用の可否を検討する際に参照すると判断が早まります。

Data + AI Summit 2026でMatei Zaharia氏が示した開発動機

Omnigentは、米サンフランシスコのモスコーンセンターで2026年6月15〜18日に開催されたDatabricksの年次カンファレンス「Data + AI Summit 2026」のキーノートで、共同創業者でありCTOのMatei Zaharia氏が本格的に紹介しました（OSS本体とブログは同月13日に先行公開）。著者にはZaharia氏に加え、Kasey Uhlenhuth氏とCorey Zumar氏が名を連ねています。開発の動機は、Databricks自身がエージェントを大量に使い・作る中で感じた「使いにくさ」にあります。利用者は4〜5個のエージェントを同時に開き、それらとドキュメントやチャットツールの間でテキストをコピー＆ペーストし続けている、という具体的な不便が出発点でした。各ハーネスのインターフェースが異なるため、組み合わせや乗り換えが難しいという構造的な問題を、上位レイヤーで解こうとしています。提供元のDatabricksは、Apache Sparkの開発者が設立し、Delta LakeやUnity Catalogなどをオープンソース化してきた企業です。同社の全体像はDatabricksとは？できること・DBU課金の料金・導入効果で整理しており、Omnigentが同社のOSS戦略の延長線上にあることが分かります。

メタハーネスがエージェントハーネスと根本的に異なる理由と必要性

Omnigentを理解する鍵は「メタハーネス」という言葉です。多くのニュース記事はこの語を紹介するだけで通り過ぎますが、なぜハーネスの上にもう一層必要なのかを押さえると、製品の狙いが明確になります。

Claude Code・Cursor・Piが抱えるハーネス分断という課題

エージェントハーネスとは、LLMの能力をツール呼び出しやプロンプト、実行環境とともに包んだ「エージェントの殻」です。Claude Code、Codex、Cursor、Piはそれぞれ独自のハーネスを持ちますが、各ハーネスは自分のセッションしか理解しません。そのため、複数のエージェントを組み合わせる・横断的に統制する・他人と一緒に作業する、といった操作のたびに分断が生じます。Databricksも、最良の成果がもはや「単一モデル×単一ハーネス」からは生まれにくくなっていると指摘し、オープンソースのワーカーモデルにフロンティアモデルを助言役として組み合わせる構成が、品質とコストの両面で単一モデルを上回りうると論じています。

KubernetesやTerraformになぞらえた抽象レイヤーの発想

Databricksは、業界の大きな転換が「新しい抽象レイヤーへの移行」から生まれてきたと整理しています。かつて技術者は個々のサーバーやプロセスを直接管理していましたが、KubernetesやTerraformによって多数のリソースをまとめて管理できるようになりました。エージェントも同じ地点にあるという見立てです。各ハーネスがそれぞれのコンテキスト・制御・実行方法を持つサイロである以上、合成・セキュリティ・協働といった「本質的にハーネスをまたぐ問題」は上位の共通レイヤーでしか解けません。Omnigentは、モデルやハーネスが移り変わっても、セッション・ポリシー・スキルが利用者の手元に残るレイヤーを目指しています。

マルチエージェント・オーケストレーションとの目的上の棲み分け

メタハーネスは、いわゆるマルチエージェント・オーケストレーションのフレームワークとは目的が異なります。複数エージェントを協調させる枠組みは、主に「アプリケーションを作る側」がエージェント同士の連携ロジックを設計するためのものです。一方Omnigentは、開発者がすでに使っているハーネスを書き換えずに横断利用し、コスト・権限・共有といった運用レイヤーの課題を解くことに軸足を置きます。つまり「どのエージェントを動かすか」より「動いているエージェント群をどう束ね、統制し、共有するか」を担う点が棲み分けの境界です。この違いを理解せずに既存の開発フレームワークの代替と捉えると、導入目的を見誤りやすくなります。

合成・制御・協働というOmnigentの3つの中核機能の中身

Omnigentが提供する価値は、Composition（合成）・Control（制御）・Collaboration（協働）の3つに集約されます。それぞれが「ハーネス単体では止まってしまう」領域を補う設計です。

複数ハーネスを書き換えず組み合わせる合成（Composition）

合成は、複数のモデル・ハーネス・手法をコードの書き換えなしに組み合わせる機能です。Claude Code、Codex、Cursor、Pi、自作エージェントの間を、設定の1行変更で切り替えられます。カスタムエージェントは短いYAMLファイルで定義でき、ツール・プロンプト・スキル・ポリシーを共通に保ったまま、ハーネスやモデルだけを差し替えられます（具体的なYAMLは後半で示します）。異なるハーネスを使うサブエージェントを1つのエージェント内で組み合わせることも可能です。これにより、最新のハーネスやSDK、モデルを取り込み続ける「改善のいたちごっこ」を、書き換えコストを抑えながら回せます。

コスト上限や権限を文脈に応じ動的に管理する制御（Control）

制御は、エージェントの挙動を追跡し、ガードレールを強制する機能です。特徴は、プロンプトで指示するのではなく、メタハーネスのレイヤーで状態をもとに判断する点にあります。具体的には、セッションごとのLLMコストを動的に追跡し、たとえば「100ドル使うごとに一時停止して継続可否を尋ねる」といった設定が可能です。セキュリティポリシーも、単純な「Xを許可・Yを拒否」を超えて文脈を見ます。たとえば「エージェントがnpmから新しいパッケージをダウンロードした後は、git pushに人間の承認を必須にする」「自分が作成したドキュメントにだけ書き込みを許可する」といった、状態に応じた制御を組めます。これは野良化やコスト暴走を防ぐうえで実務的な意味を持つ仕組みです。

ライブセッションをURL共有する協働（Collaboration）

協働は、実行中のエージェントセッションをURL経由で共有し、その作業ディレクトリのファイルを複数人で確認できる機能です。共有された側は、リアルタイムでレビューやコメントを行い、エージェントに指示を送ることもできます。結果として、セッションと作業ディレクトリそのものが共同作業の中心になります。従来のように成果物をチャットやドキュメントへコピー＆ペーストして共有する手間を省き、エージェントが動いている現場で直接協働できる点が、この機能の狙いです。

runnerとserverで構成されるOmnigentのアーキテクチャ

3つの機能を支えるのが、runnerとserverという2層の構造です。仕組みを押さえておくと、どこで何が制御されるのかを把握でき、導入時の設計判断に役立ちます。

各エージェントをサンドボックス化するrunnerと統一API

Omnigentの中核的な発想は、ハーネスが内部でLLMをどう呼び出していても、利用者から見たインターフェースは同じ（入力はメッセージとファイル、出力はテキストストリームとツール呼び出し）だという点です。runnerは、任意のエージェントをサンドボックス化されたセッションで包み、この統一APIを与えます。対象はターミナル型のコーディングエージェント（Claude Code、Codex、Cursorなど）だけでなく、OpenAI Agents SDKやClaude Agents SDKといったSDKもカバーします。

ポリシーと共有を担い複数経路で公開するserverとOSサンドボックス

serverは、ポリシーの適用とセッションの共有を担い、すべてのセッションをターミナル・アプリ・Web APIで公開します。一度Claude CodeをOmnigentサーバーに接続すれば、Web・モバイル・macOSネイティブアプリ・APIのいずれからも同じエージェントへアクセスできます。さらにDatabricksのセキュリティチームによる柔軟なOSサンドボックスを内蔵し、OSアクセスの制限やネットワークリクエストの傍受・変換が可能です。象徴的な例として、エージェントにGitHubのセキュリティトークンを一切見せず、承認されたリクエストにのみegress（送信）プロキシでトークンを注入する制御が挙げられています。秘匿情報をエージェントの手の届く場所に置かないこの設計は、情報漏えいリスクを抑える具体策です。

OSS版とマネージド版の違いと本番採用を見極めるための判断軸

Omnigentを評価するうえで見落とされがちなのが、無償のOSS版とDatabricksマネージド版という2系統の存在、そしてalpha版という成熟度です。ここを区別しないと、採用判断を誤ります。

Apache 2.0のOSS版とDatabricksマネージド版の機能差

OSS版は、Apache 2.0ライセンスのもとで誰でも入手・改変・再配布できる本体で、ポリシーをYAMLで自由に書ける柔軟性が持ち味です。一方Databricksは、フルマネージド版（beta）も提供します。マネージド版はDatabricksが運用するOmnigentサーバーを含み、ワークスペースのIDプロバイダーと統合され、モデルアクセスはFoundation Model APIとAI Gateway経由になります。ただしポリシーは組み込みの文脈型ポリシーに限定され、OSS版のような自由なカスタムポリシーは書けません。両者の位置づけは次のように整理できます。

検証や自社カスタマイズが目的ならOSS版、組織横断での運用とID統制まで求めるならマネージド版、という切り分けが現実的です。なおマネージド版は、サーバーレスのegress制御（SEG）を有効化した環境では利用できない制約がある点も、事前に確認しておきたいところです。

alpha版という公開時点の現状を踏まえた本番利用の判断基準

OSS版のOmnigentは、公開時点でalpha版であり、本稿執筆時点の最新もv0.5.1（2026年7月10日）とバージョン番号は0系にとどまります。これは、機能やAPIが今後変わりうる実験的な段階であることを意味します。したがって、業務クリティカルな本番システムへ即座に組み込むより、まずは隔離した環境での評価や、影響範囲の限定された用途から試すのが妥当です。判断軸としては、対応ハーネスが自社の利用ツールと一致するか、コスト・セキュリティポリシーが自社の統制要件を満たせるか、APIの変更に追従できる運用体制があるか、の3点を確認すると過不足がありません。逆に言えば、これらが整わない段階で全社展開を急ぐのは、alpha版という前提と噛み合いません。

エージェントの野良化・コスト暴走を抑えるガバナンス観点での価値

Omnigentが情報システム部門にとって意味を持つのは、エージェントの「野良化」とコスト暴走を抑える統制を、プロンプトではなくレイヤーで効かせられる点にあります。ガートナーは、2027年末までにエージェント型AIプロジェクトの4割超が、コストの高騰やリスク管理の不足を理由に中止に追い込まれると予測しました。前述のコストポリシーや文脈型セキュリティポリシー、セッションの可視化・共有は、こうした中止リスクを下げる方向に働く要素です。ただしOmnigent単体でSaaS全体の利用状況まで可視化できるわけではないため、組織全体の統制は別途のIT資産・SaaS管理と組み合わせて設計する必要があります。

Omnigentのインストールと最初のエージェント起動

ここからは実際に触り始める導線を、公式のquickstartにもとづく実コマンドで示します。alpha版なので、まずは手元の環境で小さく動かして挙動を確かめるのが現実的です。

curl1行またはuvで導入する具体的なインストール手順

最短はインストールスクリプトを実行する方法です。手動導入する場合はPython 3.12以上を用意し、uvでツールとして入れます。

# インストールスクリプトで導入
curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh

# もしくは uv で導入（Python 3.12+）
uv tool install omnigent
# Databricks や Modal 連携を使う場合は extras を付ける
uv tool install "omnigent[databricks,modal]"

導入後は、次のCLIで最初のエージェント起動からモデル切り替え、ローカルWeb UIの起動までを確認できます。

omnigent              # 最初のエージェントを起動
omnigent claude       # 特定のランタイム（Claude）を指定して起動
omnigent setup        # 利用するモデルを選択・切り替え
omnigent server start  # ローカルのWeb UI（server）を起動
omnigent run examples/polly/  # 同梱のサンプルエージェントを実行

つまずいた点は、リポジトリのIssueや公式ドキュメントを参照しながら進められます。

YAMLでカスタムエージェントを定義する設定例

Omnigentのカスタムエージェントは短いYAMLで定義します。executor.harnessを書き換えるだけで、ツールやプロンプト、ポリシーを保ったままハーネス（実行系）を差し替えられるのが合成機能の実体です。

name: my_agent
prompt: You are a helpful data analyst.
executor:
  harness: claude-sdk   # ここを codex や cursor などに変えるだけで実行系を差し替え
tools:
  word_count:
    type: function
    callable: mypackage.mymodule.word_count
  docs:
    type: mcp
    url: https://example.com/mcp
  researcher:
    type: agent
    prompt: Search for relevant information and summarize it.

このように、ツールを関数・MCPサーバー・サブエージェントとして宣言的に束ねられます。ハーネスやモデルの差し替えを1行の変更に閉じ込められる点が、書き換えコストを抑えつつ最新ツールへ追従できる理由です。MCPの位置づけはFAQで後述します。

対応ハーネス・SDKと複数インターフェース

v0.5.1時点でOmnigentが束ねられるハーネスは、ターミナル型のコーディングエージェントであるClaude Code、Codex、Cursor、OpenCode、Hermes、Pi、そして自作のカスタムエージェントです。加えて、OpenAI Agents SDKやClaude Agents SDKといったSDKベースのエージェントもラップできます。接続後は、Web・モバイル・macOSネイティブアプリ・APIのいずれからも同じセッションへアクセスできるため、ローカルで起動したエージェントの作業を外出先のモバイルから確認する、といった使い方が可能です。

デプロイ先・LLMプロバイダーと今後のロードマップ

Omnigentは幅広いインフラへデプロイしやすいよう設計されています。対応するデプロイ先はDocker Compose、Render、Railway、Fly.io、Hugging Face Spaces、Modal、Cloudflare、Databricks Appsなど多岐にわたり、ModalのようなホストサンドボックスやCloudflareクイックトンネル・Tailscale経由の限定公開にも対応します。LLMプロバイダーはAnthropic・OpenAIのAPIキーに加え、Claude Pro/MaxやChatGPTのサブスクリプション、OpenAI／Anthropic互換のbase_urlを持つOpenRouter・LiteLLM・Ollama・vLLM・Azure、さらにDatabricksワークスペースを利用できます。今後のロードマップには、メタハーネス層での自動最適化（GEPA）、コードベースな内省（MemEx／RLM）、エージェントがセッションをまたいで動くためのOmnigent Server MCP、対応ハーネスの追加などが示されており、コミュニティからの貢献も歓迎されています。

よくある質問

Omnigentについて検索されることの多い疑問を、一次情報にもとづいて簡潔に整理します。

OmnigentはClaude CodeやCursorの代替になりますか？

いいえ、代替ではありません。Omnigentは個々のエージェントを置き換えるものではなく、Claude CodeやCodex、Cursorなど既存のハーネスの上位に立つメタハーネスです。むしろこれらのツールを書き換えずに組み合わせ、横断的に制御・共有するためのレイヤーとして機能します。既存ツールを手放すのではなく、その上に1層足すイメージが近いといえます。

Omnigentはどこからインストールできますか？

GitHubリポジトリ（github.com/omnigent-ai/omnigent）から入手できます。最短はcurlのインストールスクリプト、もしくはPython 3.12以上の環境でuv tool install omnigentです。導入後はomnigentコマンドで最初のエージェントを起動し、omnigent server startでローカルのWeb UIを立ち上げられます。詳細は本文「インストールと最初のエージェント起動」を参照してください。

Omnigentの利用に料金はかかりますか？

OSS版はApache 2.0ライセンスで無償公開されており、ライセンス費用はかかりません。ただし、接続するLLMの利用料や、自前でサーバーを運用する場合のインフラ費用は別途発生します。一方、Databricksが運用するマネージド版を利用する場合は、その提供条件に従う形になります。なおOmnigent自体に、セッション単位の支出を追跡・制限するコストポリシー機能が備わっています。

Omnigentは個人開発者でも使えますか？

はい、オープンソースとして公開されているため、個人開発者でもGitHubからクローンして利用できます。自分のマシン上でエージェントを起動して試すことも可能です。ただし公開時点ではalpha版（最新v0.5.1）であり、機能やAPIが変わりうる点には留意してください。まずは小規模な検証から始めるのが安全です。

OmnigentとMCPはどう違いますか？

MCP（Model Context Protocol）は、エージェントが外部のツールやデータへアクセスするための接続規格です。これに対しOmnigentは、エージェントのハーネスそのものを束ねる上位レイヤーであり、目的の層が異なります。実際、OmnigentのYAMLではツールをtype: mcpとして宣言でき、両者は競合ではなく組み合わせて使う関係にあります。ロードマップにも、セッションをまたいで動くための「Omnigent Server MCP」が挙げられています。

関連記事

• Databricksとは？できること・DBU課金の料金・業種別の導入効果を2026年版で解説：Omnigentの提供元であるDatabricksの全体像を押さえると、同社のOSS戦略の中でのOmnigentの位置づけが理解できます。
• Databricks DQXとは？PySparkデータ品質検証フレームワークの機能と使い方【2026年最新】：Omnigentと同じくDatabricksが公開したOSSで、同社のオープンソース戦略をあわせて把握できます。
• オープンソースライセンスの概要と重要性：Apache 2.0で公開されたOmnigentを自社利用する際、商用利用・改変・再配布の可否を判断する前提知識になります。