Omnigentのアーキテクチャをステップバイステップで理解する ― サーバー・ランナー・2つのサンドボックス

Posted at 2026-07-03

前回まで、Omnigentを実際に動かしてPollyのクロスレビューをスモークテストで通しました。ただ、動かしているうちに「結局どのコンポーネントがどこで動いているのか」が分かりにくいと感じました。特に「サンドボックス」という言葉が2つの別物を指していて、混乱の元になります。

この記事では、Omnigentの構成要素を1つずつ積み上げて理解し、最後にローカル実行とDatabricks Managedで配置がどう変わるかまでを、順を追って追いかけます。1ステップにつき1つずつ部品を足していくので、最後まで読むと全体像が頭の中で組み上がるはずです。

ステップ0: メタハーネスは何を1段上げるのか

まず土台の確認です。ハーネスとは、モデルを包んでエージェントに仕立てる層のことです。ファイルを読み、ターミナルコマンドを実行し、ツールを呼べるようにする。Claude Code、Codex、Pi はいずれもハーネスです。

メタハーネスは、その1段上に位置し、それぞれのハーネスを交換可能な部品として扱います。なぜこれが成立するかというと、内部実装は違っても、すべてのハーネスはユーザーから見て同じインターフェースを持つからです。メッセージとファイルが入り、テキストのストリームとツール呼び出しが出る。この共通インターフェースがあるおかげで、単一の層で任意のハーネスを包めます。以下で見ていくコンポーネントは、この「共通の層」を実現するための部品だと思って読んでください。

ステップ1: 一番外側 — UIとサーバー

あなたが最初に触れるのはUIです。CLI、Web UI (localhost:6767)、モバイル、デスクトップアプリ。ここで大事な事実が1つあります。これらのUIはすべてサーバーと通信し、後述するランナーとは直接やり取りしません。

サーバーは中央の調整役です。管理するものは、セッション履歴 (すべての会話・メッセージ・ツール呼び出しを Postgres か SQLite に永続化)、成果物 (ファイルやアップロード)、カタログ (登録済み・組み込みのエージェント定義)、MCPプロキシとポリシー強制、スキル、認証 (組み込みアカウントまたは OIDC/SSO) です。そしてWeb UIを配信し、WebSocketでやり取りします。

つまりサーバーは「状態と入口」を持つ層です。何が起きたかの記録も、誰がアクセスできるかも、どのUIから見えるかも、ここに集約されます。

ステップ2: 実行を担う — ホストとランナー

サーバーは記録と配信を担いますが、実際にコードを動かすのは別の部品です。ここでホストとランナーが登場します。

ホスト (デーモン) は、コード実行が実際に起きるマシンで動きます。ノートPCでも、クラウドのコンテナでもよい。サーバーへの安全なトンネルを張り、ランナーを起動して、そのライフサイクルを管理します。omnigent host がこれです。

ランナーは、セッションごとに立ち上がるプロセスです。Omnigentのループを実行し、ハーネス (Claude Code, Codex, Claude SDK など) を管理し、ツールを動かし、イベントをWebSocketでサーバーへ流します。サーバーがホスト上でランナーを起動する、という関係です。

このホスト/ランナーの分離が、「手元のClaude CodeやCodexがそのまま動く」理由です。ノートPC上で起動したランナーは、そのマシンのツール・ファイル・認証情報に直接アクセスできるからです。

ステップ3: ランナーの中身 — 脳とサブエージェント

ランナーの中をもう一段開きます。ランナーが管理するハーネスこそが、これまで「脳」と呼んできたものの実体です。Pollyの場合、脳は claude-sdk ハーネスで動くオーケストレーターです。

Pollyのようなオーケストレーターは、自分ではコードを書かず、サブエージェント (claude_code / codex / pi) に仕事を振ります。各サブエージェントはそれぞれ専用の git worktree で動きます。ここを整理すると、脳はランナー内で動く指揮役のハーネス、サブエージェントは脳が起動する別のCLIプロセス、という関係になります。前回スモークで見た「claude_codeがsubtractを、codexがmultiplyを、別worktreeで並列実装」は、まさにこの層の話でした。

ステップ4: 安全装置 — Omnibox (1つ目のサンドボックス)

ここで1つ目のサンドボックスが出てきます。Omnibox は、Databricksのセキュリティチームが作ったOSレベルのサンドボックスです。

仕組みはカーネルレベルの強制です。Linux では bubblewrap + seccomp、macOS では Seatbelt を使い、ファイルシステムアクセスをロックダウンし、外向きの通信を egress プロキシ層で傍受します。実際の効果として、エージェントはGitHubトークンのような秘密情報を直接見ることがありません。トークンは承認された通信時にプロキシ側でのみ注入されます。「認証情報を共有するな」とプロンプトで指示するのとは根本的に違い、OS層での強制になっている点が肝です。

そして重要なのは、これはローカルでも常に効いていることです。前回のスモークでも、あなたのMacでは Seatbelt が claude_code / codex の各ターミナルを包んでいました。

ステップ5: ここまでを1枚に — ローカル実行の配置

部品が出そろったので、omni run で起動したローカル実行の配置を1枚にまとめます。1つのコマンドで、サーバー・ホスト・ランナーが全部あなたのMacの上に立ち上がり、localhost:6767 にWeb UIが開いて、同じセッションがブラウザやスマホにも同期されます。

上の図がローカル実行の全体像です。あなたのMacの中に、サーバー (SQLiteにセッション履歴とファイル。前回見つけた mlflow.db はトレース用の別DB)、Web UI、ホストデーモン、ランナーが載ります。ランナーの中に脳 (Pollyのオーケストレーター) があり、その下の Omnibox の中でサブエージェントが worktree ごとに動きます。Macの外に出るのはモデル呼び出しだけで、今回はローカルの claude / codex サブスク経由でした。

ここまでが「全部あなたのMac上」という素直な構成です。

ステップ6: もう1つのサンドボックス — クラウド実行

2つ目のサンドボックスは、まったくの別物です。クラウドサンドボックスホストは、ランナーをノートPCからリモートのコンテナに移す仕組みです。ノートPCを閉じてもエージェントが動き続け、クラウドの計算資源を持つ隔離環境で実行されます。Modal、Daytona、そして後述するDatabricks Sandbox などが該当します。

ドキュメント自身がこの2つをはっきり区別しています。クラウドサンドボックスホストのページには「エージェントがファイルシステムやネットワークで何にアクセスできるかを制限したいなら、それはOmniboxです」という注記があります。整理するとこうです。

Omnibox は、エージェントが「何を触れるか」を制限します。OSレベルで、ローカルでもクラウドでも常時効いています。クラウドサンドボックスは、ランナーが「どこで動くか」を決めます。リモートの実行環境、つまり置き場所の話です。この2つを混同しないことが、Omnigentの構成を理解する一番のコツです。

ステップ7: Databricks Managed の配置

最後に、Databricks Managed で配置がどう変わるかを見ます。結論から言うと、ローカルでは全部Mac上にあった部品のうち、サーバーとランナーがDatabricks側へ移ります。

Databricksはフルマネージド版を提供しており、ワークスペースのIDプロバイダーと統合されたDatabricks運用のOmnigentサーバー、Foundation Model APIとAI Gateway経由のモデルアクセス、そして安全な協調作業のためのDatabricks Sandboxが含まれます。

上の図がこれにあたります。あなた側はブラウザ (/omnigent) だけになり、実質UIクライアントです。Databricks側に、Databricks運用のOmnigentサーバー (SSO連携) とWeb UIがあり、ランナーの置き場は2択になります。Databricks Sandbox (Databricksが用意するマネージドクラウドホスト。隔離された再現可能な環境で、ノートPCがスリープしても動き続ける) を host picker で選ぶか、自分のマシン (ノートPCやDatabricks VM) をホストとして登録するか、です。

モデルアクセスも変わります。ワークスペースのFoundation Model APIをAI Gateway経由で自動ルーティングするため、管理するAPIキーが無く、モデル利用はAI Gatewayのガバナンスと制御を継承します。ただし制約もあります。Databricks Sandboxホストは常にAI Gateway経由でモデルにアクセスし、独自のモデルAPIキーは持ち込めません。組み込みのコンテキストポリシーのみ対応で、カスタムYAMLポリシーは使えません。Unity AI Gateway対応リージョンと、ワークスペースでのSandboxプレビュー有効化が前提です。

まとめ: 頭の中に置く地図

Omnigentの構成は、次の地図を頭に置くと迷いません。

構成要素そのもの (サーバー / ホスト / ランナー / UI / Omnibox) は、ローカルでも Managed でも同じです。変わるのは2つだけ、「置き場所」と「モデルの入口」です。ローカルでは全部あなたのMac上にあり、モデルはローカルCLIサブスク経由。ManagedではサーバーとランナーがDatabricks側に移り、モデルはAI Gateway経由になります。

そして「サンドボックス」という言葉は2つの別物を指します。Omnibox はエージェントが何を触れるかを制限するOSレベルの安全装置で、常時効いています。クラウド (Databricks) サンドボックスは、ランナーがどこで動くかを決める実行環境です。この2つを分けて考えれば、ローカルからManagedへ視点を移しても、どの部品がどこにあるかを見失わずに済みます。