Databricks Managed OmnigentをSandboxホストで試す ― 起動からテスト完走、共有まで

Posted at 2026-08-25

はじめに

2026年7月に、Databricks上のOmnigentのドキュメントが公開されました。OmnigentのOSS版はこれまでの記事で何度か動かしてきましたが、Databricksがフルマネージドで提供する版は、ドキュメントを読んで配置図を描いたところで止まっていました。

マネージド版の売りは、Databricksが運用するOmnigentサーバーにワークスペースIDでそのままサインインできること、モデル呼び出しがFoundation Model APIとAI Gateway経由に自動でなること、そしてエージェントの実行環境としてDatabricks Sandboxを選べることです。ノートPCの外でエージェントが動き続ける、という体験がどのくらい手軽なのかを確かめたかったので、東京リージョンのワークスペースで実際にSandboxホストのセッションを起動し、小さなタスクを完走させるまでを記録します。承認まわりの挙動や、ドキュメントと実機で違っていた点も含めて書いていきます。

なお、Omnigentは2026年8月時点でベータです。画面や挙動は今後変わる可能性があります。

前提条件

必要なものはクイックスタートに書かれているとおりです。

ワークスペースでOmnigentプレビューが有効になっていること
Unity AI Gatewayをサポートするリージョンのワークスペースであること
Sandboxをホストにする場合は、Databricks Sandboxもサポートするリージョンで、Sandboxプレビューも有効になっていること

プレビューはワークスペース管理者がワークスペースレベルのプレビュー管理から有効化します。プレビュー一覧に「Databricks Sandbox (ベータ版)」の項目があり、これをオンにします。

今回はAWSの東京リージョン(ap-northeast-1)のワークスペースを使いましたが、両方のプレビューが有効化でき、ホストピッカーにDatabricks Sandboxが表示されました。東京リージョンでSandboxが使える、というのがまず1つ目の確認事項です。

制限事項として押さえておくべきものが1つあります。Databricks SandboxはServerless Egress Control(SEG)と統合されていないため、SEGを有効にしているワークスペースではSandboxを使わないように、とドキュメントに明記されています。検証用ワークスペースを選ぶときは先に確認しておいた方がよいです。

Databricks Sandboxでセッションを起動する

/omnigent を開く

マネージド版のUIは、ワークスペースURLに /omnigent を付けた場所にあります。ローカル版で見慣れた localhost:6767 のWeb UIと同じ見た目ですが、右上にワークスペース名とDatabricksのアカウントメニューが乗っていて、ログインはDatabricksのIDそのものです。別途Omnigentのアカウントを作る手順はありません。

入力欄の下にホストピッカーがあり、選択肢は3つでした。

Databricks Sandbox
以前 omni host で登録した自分のMac (OFFLINE表示)
Connect new host

前回のアーキテクチャ記事で「マネージド版ではランナーの置き場が2択になる」と書いた箇所が、そのままこのピッカーに現れています。ローカルホストはMacで omni host --server <workspace-url> を起動していないのでOFFLINEになっているだけで、起動すれば同じ画面からMac側を選べます。今回はDatabricks Sandboxを選びます。

ハーネスの既定値はClaude Codeで、隣にRepositoryとMCPsのセレクタもあります。今回はどちらも触らず、空のワークスペースから始めます。

最初のタスクを投げる

タスクは、ローカル版の記事と比較しやすいように小さなものにしました。

Python で加減乗除の関数とテストを書いて pytest を通して

送信すると、左のセッション一覧に項目が増え、Sandboxの起動を待つ間もなく最初のツール呼び出しが始まりました。空の画面を撮ったのが15:16、最初のツール呼び出し(859ms)と承認待ちの画面が出たのが15:18です。タスクの入力時間を含めて2分半以内なので、ドキュメントの「数秒で起動」は実感として正しいです。

右ペインにはWorking folderとして /home/sandbox-agent/workspace が表示され、この時点では「No files in workspace」でした。

承認はハーネスのプロンプトがそのまま出る

最初に止まったのは、Claude CodeがBashを呼ぼうとした場面です。

「Approval required · Claude Code」というカードに、実行しようとしているコマンドと、Approve / Approve & don't ask again for Bash / Reject の3つのボタンが並びます。入力欄は「Respond to the pending request above to continue」となり、承認するまで先に進めません。

ここで一度整理しておきます。ガードレール入門の記事で扱ったOmnigentのポリシーは、エージェント設定のguardrailsブロックで定義し、ポリシーエンジンがALLOW / ASK / DENYを返す仕組みでした。一方でこのカードは、後述するとおりClaude Code自身の許可プロンプトをOmnigentがWeb UIに描き直したものです。同じ「承認待ち」に見えて、レイヤーが違います。マネージド版では組み込みのコンテキストポリシーのみ対応でカスタムポリシー関数は使えない、という制限がありますが、ハーネス側のこの許可プロンプトはそれとは独立に働いています。

今回は1回目をApproveで通し、その後の承認はそのまま流しました。

2分でテストが通った

承認から2分ほどで、エージェントがまとめを返してきました。

作られたのは calculator.py (四則演算の4関数) と test_calculator.py (parametrizeで各演算5ケース、浮動小数点は pytest.approx、ゼロ除算は pytest.raises) で、右ペインのファイルブラウザにも .venv/ .pytest_cache/ __pycache__/ と一緒に並びました。さっきまで空だった作業フォルダに、エージェントが実際に書き込んだことが一目で分かります。

環境について1点、エージェントが自分で報告してきた内容が興味深かったです。

システムの Python は PEP 668 で保護されていて pip install が拒否されたため、.venv/ を作って pytest を入れました。

SandboxのシステムPythonはexternally-managedになっていて、直接の pip install は通りません。エージェントはそれを検知してvenvを切り、その中にpytestを入れています。裏を返すと、SandboxからPyPIへのアウトバウンド通信は通っている、ということです。Free Editionのようにegressが絞られた環境では別の結果になる可能性があるので、環境依存の話として書いておきます。

ターミナルビューの正体はClaude CodeのTUI

セッションのヘッダーには、チャットビューとターミナルビューを切り替えるトグルがあります。Sandboxのシェルが開くものと思って >_ を押し、確認のつもりで .venv/bin/pytest -v と打ちました。

出てきたのは、シェルではなくClaude CodeのTUIそのものでした。打ち込んだ文字列はプロンプトとして解釈され、「Bash command: .venv/bin/pytest -v 2>&1 | tail -40 / Do you want to proceed? 1. Yes 2. Yes, and don't ask again for: ... 3. No」という、手元のターミナルで見慣れた許可プロンプトが表示されます。「Cogitated for 51s」や「Esc to cancel · Tab to amend · ctrl+e to explain」まで、そのままです。

ここで、先ほどのApproval requiredカードの正体がはっきりします。Web UIの3つのボタンは、このTUIの1 / 2 / 3を描き直したものです。マネージド版が「手元のClaude Codeがそのままクラウドで動く」と言っているのは比喩ではなく、TUIごとSandbox上で動いていて、それをOmnigentが2種類の窓から見せている、という構造でした。

どちらの窓で答えても同期される

TUI側で 1 を押して承認し、チャットビューに戻りました。

チャット側には「Resolved elsewhere · Claude Code」というカードが出て、そのまま「21 passed in 0.02s — 全テスト成功です。」と続きました。TUIで答えた承認がチャット側に「別の場所で解決済み」として同期されています。チャットとターミナルは同じセッションの2つの窓で、どちらから操作しても状態は1つです。

シェルからエージェントの成果物を確かめる

素のシェルは、右ペインのアイコン列から開けます。開くと bash · u-b0rv4o というタブができ、プロンプトは sandbox:~/workspace$ でした。

ls -la
.venv/bin/pytest -q
cat calculator.py

ls -la の結果は、すべてのファイルの所有者が sandbox-agent で、シェルのユーザーも同じです。エージェントが書いたファイルを、人間が同じユーザー・同じファイルシステムでそのまま触れる、ということです。人間側から叩いた .venv/bin/pytest -q も21 passedで、エージェントの「全テスト成功です」を自分の手で確認できました。

細かい点として、タイムスタンプが Aug 25 06:20 になっています。JSTの15:20なので、Sandboxの時刻はUTCです。ログを突き合わせるときに9時間ずれることは頭に置いておいた方がよいです。

Sandboxのスペックはドキュメントによると4コア、16 GB RAM、最大100 GBストレージで固定、1ユーザーあたり最大40個です。ストレージはセッションをまたいで永続化されるので、ツールを一度入れてSandboxを停止し、後で同じ状態に再接続できるとされています。今回のvenvも次回そのまま使える想定です。

セッション共有はReadのみ

マネージド版ならではの機能として、Shareボタンからセッションを別のワークスペースユーザーに共有できます。

ダイアログを開いて、ここが今回一番ドキュメントと違っていた点です。「This server allows read-only sharing — invite others to view this session.」と明記されていて、Levelのプルダウンには Readしかありません。IDとアクセスのドキュメントにはReadとEditの2段階が表で載っていますが、少なくとも今回のワークスペースのサーバーではEditは選べませんでした。

Editは、付与されたユーザーがエージェント経由でシェルコマンドを実行したりホスト上のファイルを書き換えたりできる強い権限で、ドキュメント自身も「Grant Edit carefully」と警告しています。マネージド版がまずReadだけを開けているのは、ベータの段階としては妥当な判断に見えます。共有された側は、リアルタイムでセッションを追える閲覧者になります。

ダイアログの下には「Copy link」と「Open in mobile app」(QRコード)があり、モバイルアプリからの接続の入口はここです。なお、ワークスペースにIPアクセスリストを設定している場合、モバイル端末も許可されたIPから接続する必要があり、ドキュメントでは社内VPN経由で許可済みのegress IPに寄せる運用が示されています。

ローカル実行との違い

今回動かして見えた、ローカルの omni run との違いをまとめます。

サーバーとランナーがDatabricks側に移り、手元はブラウザだけになる。ログインはDatabricksのIDで、Omnigentのアカウント管理はない
モデル呼び出しはFoundation Model APIをAI Gateway経由で自動ルーティングする。APIキーの管理はなく、利用はAI Gatewayのガバナンスと課金に乗る。Sandboxホストでは独自のモデルAPIキーは持ち込めない
ポリシーは組み込みのコンテキストポリシーのみ。任意コードを実行するカスタムポリシー関数は非対応
ハーネス側の許可プロンプト(Claude CodeのYes / No)はそのまま生きていて、Web UIから答えられる
セッション共有はワークスペースユーザー向けで、現時点ではReadのみ

構成要素そのもの(サーバー / ホスト / ランナー / UI)はローカルと同じで、変わるのは置き場所とモデルの入口だけ、という前回の整理は、実機でもそのまま当てはまりました。

まとめ

Databricks上のOmnigentをDatabricks Sandboxホストで動かして分かったことをまとめます。

東京リージョン(ap-northeast-1)のワークスペースで、OmnigentプレビューとSandboxプレビューの両方が有効化でき、Sandboxホストが選べた
タスク送信から最初のツール呼び出しまで2分半以内、小さなコーディングタスクは承認込みで4分ほどで完走した
承認カード(Approve / Reject)は、Claude Code自身の許可プロンプトをOmnigentがWeb UIに描き直したもの。Omnigentのガードレールポリシーとはレイヤーが違う
ターミナルビューはSandboxのシェルではなくClaude CodeのTUI。TUIで承認するとチャット側に「Resolved elsewhere」として同期される
素のシェルは右ペインから別途開ける。エージェントと同じ sandbox-agent ユーザーで同じファイルシステムを触れる
SandboxのシステムPythonはPEP 668で保護されていて、エージェントは自分でvenvを切った。PyPIへのアウトバウンドは通る
Sandboxの時刻はUTC
セッション共有は現時点でReadのみ。ドキュメントにあるEditはダイアログに出てこない

一番の収穫は、承認まわりの構造が見えたことでした。Web UIに出る承認カードをOmnigentのポリシー機能だと思い込んでいると、なぜ設定していないのに止まるのか、なぜカスタムポリシーが使えないのに承認が効くのか、で混乱します。TUIを開いて同じプロンプトが出た瞬間に、ハーネスの許可とメタハーネスのポリシーが別の層にあることが腹落ちしました。マネージド版は「手元のエージェントをそのままクラウドに置く」体験としてはかなり素直で、次はRepositoryセレクタでリポジトリを持ち込んで、ローカル版で通したPollyのクロスレビューをSandbox上で回してみるつもりです。