はい!おつかれさまです!
Omnigentって知ってますか!?メタハーネスです!(雑
嘘です!OmnigentというのはDatabricksで作ったOSSで、メタハーネスなのは嘘じゃないんですが、一言で言うならAI エージェントの「共通の土台」です!
Claude CodeやCodexなどハーネスを別々に使うのではなく、同じ場所で混ぜて、切り替えて、マネージできるようにするアプリケーションがOmnigentです!
今日はOmnigentを使って、複数ハーネスを使った自動開発用のエージェントを作ってみましょう!
Omnigentの開発スピードが異常に速いので詳しくは最新情報みてくださいね!
作りたいエージェント!
今回作りたいのは先程も言いましたが、自動開発のエージェント!こういう機能が欲しいって言うだけで、コードに機能を追加してくれるエージェントです!
具体的には、仕様作成ループ、実装ループ、レビュー、に分かれています。下記の図を参考にしてください!

Omnigentの全体像
次にOmnigentの全体像から簡単にお話していきまっしょい
Omnigentはハーネスを管理するために複数の層を持っています。大きく分けるとRunnerとServerに分かれています。
Runner – ハーネスを実際に起動して動かす実行層です。サンドボックスの中で走らせたり、落ちても立て直したりしてくれます(Sandboxing / Reliability)。
Server – 状態と統制をまとめる管理層です。会話履歴・エージェントのカタログ・ポリシー・MCP・成果物・スキルなどを一元管理して、ターミナルでもブラウザでもスマホでもREST API でも同じセッションに触れられるようにします。
これらが間に仲介する事で、種類の違うハーネスを1つのエージェントとして扱えるようになるわけです!
Omnigentのエージェントについて
ではそのエージェントについて説明していきましょう!
エージェントはディレクトリになっています。中身はYAMLとプロンプトとMarkdownを書いていました。Python等のコードは書いていません!
オーケストレータはClaude SDKを使い、実際にファイルを触るワーカー(今回ではClaude Code、Codex、Piなどのハーネス)も動かします
エージェントの実装ディレクトリはこんな感じです。

| パス | 役割 |
|---|---|
config.yaml | オーケストレータ。頭脳のハーネス、プロンプト、 サブエージェントの宣言、ポリシーなど |
agents/claude_code/config.yaml | 起草と実装を担うワーカー |
agents/codex/config.yaml | 批評とレビューを担うワーカー |
agents/{pi,cursor,opencode,hermes,agy}/config.yaml | 代替ワーカー5体。環境によって CLI の在否が変わるので全部宣言し、 事前チェックで判定させる |
skills/*/SKILL.md | 4本の手順書spec-loop / spec-implement / spec-review-merge / investigate |
オーケストレーターのconfig.yaml
ではそれぞれのファイルを軽く見ていきましょうまずはオーケストレーターのconfig.yamlです、これが大本のエージェント定義を行うものになります。
spec_version: 1name: spec_drivendescription: >- 仕様書ファーストのコーディング・オーケストレータ(完全自動)。…spawn: trueexecutor: type: omnigent context_window: 1000000 auth: type: databricks profile: databricks-test-workspace config: harness: claude-sdk smart_routing_harness: autoprompt: | (521 行の日本語)async: truecancellable: truetimers: trueos_env: type: caller_process cwd: . sandbox: type: noneterminals: shell: { command: bash, … } zsh: { command: zsh, … }tools: agents: [claude_code, codex, pi, cursor, opencode, hermes, agy]guardrails: ask_timeout: 86400 policies: { … 3 種 … }
ワーカーの config.yaml
次にワーカーのconfig.yamlです!各ワーカーの定義を入れていきます。
基本的な構造はオーケストレーターのconfig.yamlと同じですが、executorブロックだけかわっています。
# agents/claude_code/config.yamlexecutor: type: omnigent model: kuwano_test_catalog.ai.omnigent-claude-opus-5 config: harness: claude-native reasoning_effort: high permission_mode: auto
各ワーカーの例(一部)
| ワーカー | model | harness | effort | 権限フラグ |
|---|---|---|---|---|
| claude_code | kuwano_test_catalog.ai. | claude-native | high | permission_mode: auto |
| codex | kuwano_test_catalog.ai. | codex-native | xhigh | yolo: true |
| pi | databricks-claude-opus-5 | pi | — | — |
| cursor | grok-4.5 | cursor-native | — | yolo: true |
| opencode | (未指定) | opencode-native | — | — |
| hermes | (未指定) | hermes-native | — | — |
| agy | (未指定) | antigravity-native | — | — |
ガードレール=ポリシーの書き方
エージェントにやってほしいこと、やってほしくないことを定義するのがここです。
このエージェントには3つのポリシーを設定しています。
guardrails: ask_timeout: 86400 policies: blast_radius: type: function function: path: omnigent.policies.builtins.orchestration.blast_radius arguments: gate_pushes: false spawn_bounds: type: function function: path: omnigent.policies.builtins.orchestration.spawn_bounds arguments: max_dispatches_per_turn: 6 dispatch_tools: [sys_session_send, sys_session_create] headless_subagent_purpose_guard: type: function function: path: omnigent.policies.builtins.orchestration.headless_subagent_purpose_guard arguments: allowed_purposes: [spec, spec_review, implement, review, explore, search]
これによって、force-push、rm -rf /、リモート ref への hard-resetなどの取り返しのつかない操作をDenyしていたり、サブエージェントを無限に増やさない、想定外の使い方をさせない、などを設定してます。
プロンプト
プロンプトは521行あるので、ザックリ何をしているかを書くとこうなります。
- 役割を固定 — 誰が起草し、誰が批評し、誰が実装し、誰がレビューするか。「批評者 ≠ 起草者」「レビュアー ≠ 実装者」を崩さない様に、と明記
- 手順を定める — 調査 → 仕様の合意 → 実装 → レビューの4フェーズを、すっ飛ばさず先送りせずに動かします
- 止まらないように — 無人で走らせるので、行き詰まったら人間を待たず自分で決めるようにしています。「宣言した同じターンで行動する」「対象は一括で読む」といった、実際に失敗して足した規律も入ってます。
- 環境差の吸収 — 起動時に使える CLI を確認し、GitHub API が塞がれていれば PR を作らずブランチ push で完了するモードに切り替える
要は 「誰が何をするか」と「詰まったときどうするか」 を書いているだけで、コードの書き方は一切指示していません。そこは各エージェントの得意に任せます。
スキル
このエージェントが使うスキルを設定しています。スキル自体は普通に作ります。
---name: spec-loopdescription: フェーズ1 — claude_code に仕様書を起草させ codex に批評させ、 2者が合意するまでループする(周回上限なし)。行き詰まったら人間を待たず 自分で決めて記録を残し、実装フェーズに進む。---# spec-loop — コードを書く前に契約を書く(以下、手順の本文)
| スキル | 担当 |
|---|---|
spec-loop | フェーズ1。10 の手順に分かれ、 合意後のブランチpushまで含む |
spec-implement | フェーズ2。実装者1人、仕様書1つ、Git worktree1つ。 仕様書の全文を渡して実装 |
spec-review-merge | フェーズ3。判定と出荷。PRモードは自動マージ、 PRなしモードはpush済みブランチで完了 |
investigate | 読み取り専用の調査を委譲する 実装済みのレポジトリと判定したら必ず確認する |
エージェントの実行
Omnigentの画面に接続して、作ったエージェント[spec_driven]を指定して実行しましょう

この様な感じで実装依頼をなげていきます。

そうすると、フェーズ1から順に処理をしていきます。
Claude Codeがした仕様や実装を、Codexがチェックするような動きをしてくれて、もし問題があれば差し戻しをして、再度Claude Codeが実装し直す、ということを行っています。

最終的に結果をだしていきます。
PRが出せるならPRを出して完了します。


実行についても、DatabricksのOmnigentの場合はDatabricks Sandboxで行うことができますので、この様に自律的な実装からPR作成までをローカルPCを使わずに命令だけ出して使っていくことが面倒なセットアップなしに行えます!
説明することが多くて長くなりましたが、このBlogはほぼAIつかってませんw(画像とかは使いましたw)
是非Omnigent楽しいのでお使いいただけますと幸いです!




コメントを残す