AIコーディングエージェントがうまく動かないとき、原因はモデルの性能ではなく、たいてい指示の曖昧さです。
「タスク管理CLIを作って」とだけ頼むと、AIはデータモデルも優先度の付け方も永続化方式も、それらしく見える形で勝手に決めてしまいます。どれも「間違ってはいない」けれど、自分が意図したものではない。それに気づくのはレビューで3ファイル目を開いたときで、結局作り直すことになる——プロンプトを書く、推測される、作り直す、の繰り返しです。
Ouroboros はこの「出力」ではなく「入力」側の問題を直そうとするOSSのAgent OSです。Claude Code、Codex CLI、OpenCode、Gemini CLI、GitHub Copilot CLI、Kiro、Hermes、Pi、Zcode、Goose、GJC、Antigravity CLI、Grok Build CLIの前段に立つローカルファーストのランタイム層で、その場しのぎのプロンプトの代わりに、interview → seed → execute → evaluate → evolve という5段階の再生可能なワークフローを提供します。
何が問題で、何を直すのか
READMEにある整理がそのまま要点です。
| 問題 | 何が起きるか | Ouroborosの対処 |
|---|---|---|
| 曖昧なプロンプト | AIが推測し、あとで手戻りが発生する | ソクラテス式の対話で隠れた前提を洗い出す |
| 仕様がない | 実装が進むにつれて設計がぶれる | 不変のseed仕様が着手前に意図を固定する |
| 手動QA | 「良さそう」は検証ではない | 3段階の自動評価ゲート |
Ouroborosが賢くしているのは意図の入力側です。意図がはっきりするまで、コードは書かせません。
ループの構造
Interview -> Seed -> Execute -> Evaluate
^ |
+---- Evolutionary Loop ----+
- Interview — ソクラテス式の質問で、自分でも気づいていなかった前提を表に出す
- Seed — 対話の回答を、受け入れ基準・オントロジー・制約を含む不変の仕様として確定する
- Execute — Double Diamond(Discover → Define → Design → Deliver)でseedを実行に分解する
- Evaluate — Mechanical(無料・決定的チェック) → Semantic → Multi-Model Consensus の3段階ゲート
- Evolve — 評価結果が次世代のseedにフィードバックされ、これ以上学ぶことがなくなるまで繰り返す
このループは単純な繰り返しではなく、収束を前提にしています。しかも止める条件はタイマーでもステップ数でもなく、数値です。
インタビューが終わるのは「そろそろいいか」ではなく、数値がそう言うから
READMEの中でいちばん具体的だったのがここです。Ouroborosは曖昧さを、4つの観点(goal・constraints・success criteria、既存コードベースの場合はcontextも)の重み付き明瞭度の逆数としてスコア化します。
Ambiguity = 1 - Sum(clarity_i * weight_i)
READMEに載っているグリーンフィールドの例:
Goal: 0.9 * 0.4 = 0.36
Constraint: 0.8 * 0.3 = 0.24
Success: 0.7 * 0.3 = 0.21
------
Clarity = 0.81
Ambiguity = 1 - 0.81 = 0.19 <= 0.2 -> Seedを生成可能
seed(実行の元になる不変仕様)は、曖昧さが0.2を超えると生成が止まり、通り抜けるには強制(force)を渡します。断られるだけで、ロックはされません——画面には「それでも生成する(force)」がずっと出ていて、私はそれを残しました。自分のスコアで他人の作業を人質に取る道具にはしたくなかったからです。ゲートが壁ではなく減速帯になったのは、その代わりです。
出口側にも対になるゲートがあります。evolveループは連続する世代間のオントロジー類似度が0.95に達すると収束したとみなして停止します。停滞・振動・同じ論点の繰り返しをそれぞれ検知する仕組みも別途あるので、答えの出た問いをいつまでも回り続けることはありません。
収束ループの中身
このevolveループは今年3月から作り込んでいるもので、直近だと#1917というIssueで設計をまとめました。ooo runを「1回実行して結果を報告する」ものから「seedの隠しチェックリストが全部通るまで収束するループ」に変える話で、対処しているのは二つの構造的な問題です。
一つは「正解漏れ」——ワーカーにverify_commandや期待するアサーションの文字列をそのまま見せると、受け入れ基準を満たすことより、そのアサーション文字列を満たすことだけを狙う近道(reward hacking)を選んでしまう。もう一つは「行き止まりの失敗」——run・evaluate・evolveの部品はそれぞれ存在していたのに、失敗したrunが正式なevaluationに、rejectされたevaluationがevolutionに繋がっていなかった。
対処の原則はシンプルです。ワーカーには受け入れ基準の説明と期待される成果物だけを見せてアサーション文字列は見せない。失敗時のヒントはセッションの実際の行動ログから生成し、アサーション文字列は除去する。失敗したACだけを再実行対象にして、通ったACは凍結する。
試してみる
curl -fsSL https://raw.githubusercontent.com/Q00/ouroboros/main/scripts/install.sh | bash
対応しているAIコーディングエージェントのセッション内で:
> ooo interview "タスク管理CLIを作りたい"
インストーラーが使用中のランタイム(Claude Code、Codex CLI、GitHub Copilot CLI、OpenCode、Hermes、Gemini、Kiro CLI、Pi CLI、Zcode)を自動検出し、対応しているホストにMCPサーバーを登録します。ooo interview 以降——seed生成、実行、評価、evolveループ——は同じセッション内で完結します。ターミナルから直接操作したい場合は ouroboros CLI(ouroboros run seed.yaml、ouroboros status executions など)も用意されています。
セッションをまたいでevolveループを回し続けたい場合は ooo ralph があります。各ステップはステートレスで、イベントストアから系譜を再構築する仕組みのため、途中でマシンが再起動しても最初からやり直す必要はありません。
正直な感想
Ouroborosが残すのは、AIへの入力が自分の意図と一致していたという記録です。seed・ledger・評価の各段階として、あとから誰でも追跡できます。
次にAIエージェントへ曖昧な指示を出しそうになったら、その前に ooo interview を一度動かしてみてください。曖昧さスコアが0.2を超えるとseedの生成が止まり、通り抜けるには強制(force)を明示的に渡します — 上で見た通り、ロックではなく減速帯として。MITライセンス、Python 3.12以上。対応CLIごとのランタイムガイドも含めてリポジトリにまとまっています: github.com/Q00/ouroboros