はい!おつかれさまです!

Omnigentって知ってますか!?メタハーネスです!(雑
嘘です!OmnigentというのはDatabricksで作ったOSSで、メタハーネスなのは嘘じゃないんですが、一言で言うならAI エージェントの「共通の土台」です!

Claude CodeやCodexなどハーネスを別々に使うのではなく、同じ場所で混ぜて、切り替えて、マネージできるようにするアプリケーションがOmnigentです!

今日はOmnigentを使って、複数ハーネスを使った自動開発用のエージェントを作ってみましょう!

Omnigentの開発スピードが異常に速いので詳しくは最新情報みてくださいね!

作りたいエージェント!

今回作りたいのは先程も言いましたが、自動開発のエージェント!こういう機能が欲しいって言うだけで、コードに機能を追加してくれるエージェントです!

具体的には、仕様作成ループ、実装ループ、レビュー、に分かれています。下記の図を参考にしてください!

Omnigentの全体像

次にOmnigentの全体像から簡単にお話していきまっしょい

Omnigent architecture: CLI agents and custom agents run through a runner (on your machine, Modal, or Daytona), then a server that adds policies and history, reachable from a terminal, the web, native and mobile apps, and a REST API.

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.md4本の手順書
spec-loop / spec-implement / spec-review-merge / investigate

オーケストレーターのconfig.yaml

ではそれぞれのファイルを軽く見ていきましょうまずはオーケストレーターのconfig.yamlです、これが大本のエージェント定義を行うものになります。

spec_version: 1
name: spec_driven
description: >-
仕様書ファーストのコーディング・オーケストレータ(完全自動)。…
spawn: true
executor:
type: omnigent
context_window: 1000000
auth:
type: databricks
profile: databricks-test-workspace
config:
harness: claude-sdk
smart_routing_harness: auto
prompt: |
(521 行の日本語)
async: true
cancellable: true
timers: true
os_env:
type: caller_process
cwd: .
sandbox:
type: none
terminals:
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.yaml
executor:
type: omnigent
model: kuwano_test_catalog.ai.omnigent-claude-opus-5
config:
harness: claude-native
reasoning_effort: high
permission_mode: auto

各ワーカーの例(一部)

ワーカーmodelharnesseffort権限フラグ
claude_codekuwano_test_catalog.ai.
omnigent-claude-opus-5
claude-nativehighpermission_mode: auto
codexkuwano_test_catalog.ai.
omnigent-gpt-5-6-luna
codex-nativexhighyolo: true
pidatabricks-claude-opus-5pi
cursorgrok-4.5cursor-nativeyolo: 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行あるので、ザックリ何をしているかを書くとこうなります。

  1. 役割を固定 — 誰が起草し、誰が批評し、誰が実装し、誰がレビューするか。「批評者 ≠ 起草者」「レビュアー ≠ 実装者」を崩さない様に、と明記
  2. 手順を定める — 調査 → 仕様の合意 → 実装 → レビューの4フェーズを、すっ飛ばさず先送りせずに動かします
  3. 止まらないように — 無人で走らせるので、行き詰まったら人間を待たず自分で決めるようにしています。「宣言した同じターンで行動する」「対象は一括で読む」といった、実際に失敗して足した規律も入ってます。
  4. 環境差の吸収 — 起動時に使える CLI を確認し、GitHub API が塞がれていれば PR を作らずブランチ push で完了するモードに切り替える

要は 「誰が何をするか」と「詰まったときどうするか」 を書いているだけで、コードの書き方は一切指示していません。そこは各エージェントの得意に任せます。

スキル

このエージェントが使うスキルを設定しています。スキル自体は普通に作ります。

---
name: spec-loop
description: フェーズ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楽しいのでお使いいただけますと幸いです!

コメントを残す

Trending