oh-my-codex：Claude と Codex のための Agent 編成層
こんにちは、Lena です。初めて oh-my-codex のドキュメントをざっと読んだとき、私は何かを評価しようとしていたわけではありません。もっと単純なことが知りたかっただけ — Codex CLI が、他の agent 設定で見たように仕事を委譲できるかどうか。そして気がつくと、同じ一行を二度読んでいました："Your codex is not alone."
ツールの README の先頭にこの一文が来ているのは、かなり珍しい。ただ、oh-my-codex（OMX）が何になろうとしているかについては、これがいちばん正直な説明だと思います。
oh-my-codex（OMX）がやっていること
Claude Code と Codex CLI のための編成層
OMX は OpenAI Codex CLI の編成層として動き、Claude Code の能力と統合することでその実行上の制限を乗り越えます。非同期ジョブ システムを通じて tool call タイムアウトのような問題を解決し、長時間実行されるタスクを確実に完了させます。autopilot 開発、TDD、コードレビュー、戦略的プランニングといったタスクのための構造化されたワークフローを提供することで、OMX は Codex に、複雑な処理を Claude Code に効果的に委譲する方法を教え、自律的な実行を可能にします。
この説明は v1 の枠組みです。現在アクティブなのは OMX v2 で、アーキテクチャは大きく変わりました。OMX v2 は Codex ネイティブ です。v2 では Codex が第一級の実行者で、このリリースには Claude ブリッジはありません。以前のバージョンで使われていた Claude → Codex 委譲モデルは、Codex がセッションをネイティブに走らせ、マルチエージェント作業は spawn された tmux ワーカー経由で行われる構成に置き換わっています — ワーカーは Codex、Claude、Gemini のペインとして、並列で動きます。
このアーキテクチャ転換については、私自身まだ整理しきれていません。多くの人にとっての OMX の当初の魅力は、長時間タスクを Claude Code に非同期で委譲する仕組みだったはずで、その意味では v2 は別の製品とも言えます。
コア機能 — 委譲、autopilot、TDD 連携
OMX の標準的なワークフローは三つの入口を流れます：$deep-interview は何かを作り始める前の明確化、$ralplan はトレードオフを見ながらの合意プランニング、$ralph または $team が実行を担います。OMX は $skill-name 構文で呼び出す標準 skill を備えています：$team は協調的な並列実行、$ralph は「ゴールが検証済みで完了するまで回し続ける」永続モード、$ralplan は合意形成のプランニング（Planner → Architect → Critic）、$autopilot はアイデアから QA までの完全な自律実行。
永続状態のレイヤーは立ち止まって見る価値があります。OMX には永続状態と memory 用の MCP server が 5 本、agent 活動を監視するライブ HUD、主要ライフサイクル ポイントで振る舞いを拡張できる hook システムが同梱されています。Codex、Claude、Gemini のワーカーが並列に走る、混在プロバイダーのチームをサポートし、各ワーカーは独立した worktree を持ちます。
ドキュメントが記述する .omx/ ディレクトリ構造を改めて見ました：plans、logs、memory、sessions、state、team artifacts。初回の本番実行より前に理解しておくべき足場が、かなりあります。
OMX が変えたもの
タスク委譲 — 仕事を agent サイズの塊に切る
ここで OMX の設計思想が最もはっきり見えます。大きなタスクを一つ Codex に渡して、何十回ものファイル編集にわたって整合性を保たせようとするのではなく、OMX は実行が始まる前に、仕事を構造化されレビュー可能な塊に分解します。
公式デモで示されるコア パイプラインはこうです：まず意図分類と deep interview で曖昧さを減らし、そのうえで実行に入る。マルチエージェント編成は tmux を介して、独立した git worktree（.omx/team/<n>/worktrees/worker-N）内に並列ワーカーを spawn し、同時編集による書き込み競合を防ぎます。
worktree 隔離という細部は、見た目以上に効いてきます。並列 agent 実行で互いの変更を潰し合った経験 — 特に大規模リファクタリングで — がある人なら、これを真のエンジニアリング上の選択として一目で見抜けるはずです。マーケティング上の売り文句ではありません。
実際的な効果：一つの Codex セッションがコードベース全体の改変のコンテキストをすべて抱え込むのではなく、専門化されたワーカー群 — それぞれ隔離されたブランチ上で、境界のあるスライスを担当 — を得ることになります。リーダー agent が彼らの出力を統合し、競合を処理します。
Autopilot モード — 使うべきとき、使うべきでないとき
autopilot は、明瞭で低リスク、かつ巻き戻し可能な次の一歩に対しては自動的に進み、次の一歩が本質的に分岐するもの、破壊的なもの、あるいは好みに依存するものである場合のみ、質問のために立ち止まります。
autopilot の SKILL.md からのこのポリシー記述は、この種のモードがどう動くべきかについて、私が見てきた中でも正直な部類に入る表現です。「autopilot は永遠に走り続ける」ではなく、「autopilot は、人間の判断が要る決定点に当たるまで走る」です。
実際には、autopilot は仕様がはっきりしていて、コードベースを熟知している機能実装に向いている、ということになります。探索的な作業、要件が曖昧な場面、初めて触れるコードベースにはそれほど向きません。deep-interview のステップで未知が多く表面化するなら、それは autopilot が今は適切な入り口ではない、というサインです。
私の読みすぎかもしれませんが — このツール群は、ユーザーが「自分は何を欲しいか分かっている」と思っている場合でも、まず $deep-interview へ向かわせるように設計されている気がします。意図分類は実行の前に行われる。その強制的な間は、意図的に置かれています。
ガードレールとしての TDD — コードより先にテスト
OMX の TDD 連携は、単なるワークフロー提案ではありません。ハード コンストレイントに近い位置づけです。test-driven-development skill は、古典的な RED-GREEN-REFACTOR サイクルを強制します — 失敗するテストを書く、落ちるのを見る、最小限のコードを書く、通るのを見る、そして commit。Claude がテストより先にコードを書こうとすると、この skill はそのコードを削除してやり直させます。例外はありません。
これは、OMX をじっくり見たときに私がいちばん驚いた部分です。多くの agent セットアップはテストを「実装のあとに起こること」として扱います。OMX はテストを、実装を制約する仕様レイヤーとして扱います。 これは単なるワークフローの好みではなく、意味のあるアーキテクチャ上の差です。
実践的な含意：テスト基盤のないコードベースで作業している場合、OMX の TDD 強制は摩擦を生みます。すでにテスト スイートがあるなら、事後に付け足すものではなく、本物のクオリティ ゲートとして機能することになります。
OMX vs Superpowers
異なる射程 — 編成 vs 行動制約
これは開発者の議論でずっと出てくる問いで、「別のツールです」という曖昧な答えよりも、直接的な回答に値すると思います。
Superpowers は Jesse Luehrs による Claude Code プラグインで、セッション内での agent の 振る舞い を制約することに焦点を当てています。Superpowers Plugin は実行前にプランニング フェーズを導入します — モデルにすぐコードを書かせるのではなく、まず構造化されたプランを出させます：どのファイルに触れるか、どの変更を、どの順序で行うか。あなたはそのプランをレビューし承認したあとで、初めて書き始めます。
OMX のほうは、逆に ランタイム インフラ に焦点を当てています。HUD、worktree 隔離、MCP 状態 server、マルチプロバイダー チームの spawn — これらはすべて実行環境の機能であって、行動制約の機能ではありません。
違いを捉える一つの見方：Superpowers は一つの agent を、一つのセッションの中でより賢く、より規律あるものにする。OMX はマルチエージェント システムを、永続状態を持ちつつ複数セッションにわたって確実に走らせる。
併用できるか？
原理的には、たぶん可能です。構造的に非互換ではありません。ただ正直に言えば、二つの編成レイヤーを重ねると、ほとんどのワークフローでは必要ない複雑性が加わります。一つの agent が誤った方向に進んでしまう、というのが痛点であれば Superpowers が直接的に応じてくれます。複数 agent の並列作業を隔離状態付きで調整したい、というのが痛点であれば OMX が応じます。両方を同時に使うということは、両方を理解するということで、それ自体が運用コストです。
この点は、私もまだ結論を出す準備ができていません。組み合わせ構成を推薦する前に、もう少し複数セッションでの振る舞いを観察したいところです。
編成が解けない問題
memory なき委譲 — タスクは終わるが、学習は蒸発する
これは、予想以上に私の注意を引いた部分です。
OMX には永続 状態 があります — .omx/ ディレクトリはタスク グラフ、セッション産物、memory ファイルを保存します。しかし 永続状態は能力継承と同じではありません。状態は何が起きたかを記録します。難しい問題がどのように解かれたかを、別の agent — あるいは別プロジェクトの同じ agent — が継承できる形にパッケージ化する、ということはしません。
あるワーカーが複雑な認証のリファクタリングを完遂する。タスクは完了とマークされ、成果物はログに残る。次の agent が、別プロジェクトで、あるいは 3 か月後に同じコードベースで、似た認証問題に直面したとき — スタート地点は最初のワーカーとほぼ同じです。苦労して手に入れた推論経路は、再利用可能な資産として保存されていません。ログの中にあるだけです、もしあるとすれば。
委譲された agent 同士の間に能力継承はない
これは OMX を含め、現在のほとんどの編成ツールが解決できていない外側のギャップです。編成は 仕事がどう走るか を制御します。能力継承が扱うのは、成功した問題解決が時間を通じてどう積み重なるか です。
EvoMap の GEP プロトコル ドキュメント はこの区別を明示的に述べています — セッション ログに置き去りにせず、成功した実行経路を検証可能で共有可能な資産としてパッケージ化し、他の agent に採用させる。このアプローチが実践で持ちこたえるかは、私にとってはまだ開いた問いです。しかし、それが指している問題は実在のものです。
OMX は自分の範囲について正直です：より良いタスク ルーティング、より良いワークフロー、より良いランタイム。oh-my-codex の GitHub リポジトリ からのこの位置付けは、正確です。学習の転移を解くとは主張していません。実行をより確実で協調的にすると主張しているだけです。 それらは別の問題です。
限界とトレードオフ
インストール前に知っておく価値のあることをいくつか：
プラットフォーム制約。 OMX は主に Codex CLI を備えた macOS または Linux を前提に設計・調整されています。ネイティブ Windows と Codex App は既定の体験ではなく、壊れることがあり、挙動も一貫しないことがあり、サポートも現時点では薄いです。
学習曲線は本物です。 tmux への依存、.omx/ のディレクトリ構造、skill の構文、agent のロール — これは 10 分で手に馴染むツールではありません。ドキュメントは網羅的ですが、網羅的であることと取っ付きやすさは別物です。
コンテキスト オーバーヘッド。 AGENTS.md、skill プロンプト、MCP server コンテキストを各セッションに注入すると、実作業が始まる前にトークンを食われます。単純で局所的なタスクでは、このオーバーヘッドのコストが編成から得られる節約を上回ることがあります。OMX が本領を発揮するのは、複雑で複数ファイルにまたがる作業においてです。
v1 と v2 のアーキテクチャ差。 Claude Code を主要な実行エンジンとし、Codex が委譲するというような OMX の古い記述を読んだなら、それは v1 モデルです。現在のバージョンではこの関係が反転しています。セットアップに時間を投じる前に、公式 OMX ドキュメント で現行アーキテクチャを確認する価値があります。
FAQ
oh-my-codex（OMX）とは？
OMX は OpenAI Codex CLI のオープンソース編成レイヤーです。標準的な Codex の上に、マルチエージェント チームの協調、MCP server による永続状態、構造化ワークフロー（autopilot、TDD、プランニング）、ライブ監視 HUD を加えます。Codex を置き換えるのではなく、実行エンジンとして保持します。
oh-my-codex は Claude Code とどう連携する？
v2 では、関係性が v1 とは異なります。非同期ジョブ システムで長時間タスクを Codex から Claude Code に委譲するのではなく、OMX は現在、混在プロバイダーのチームをサポートします — Claude（または Gemini）のワーカーが、Codex ワーカーと並んで別々の tmux ペインで走ります。各ワーカーは独立した git worktree を受け取ります。アーキテクチャは姉妹プロジェクト oh-my-claudecode を介して Claude Code と互換で、同じ編成パターンを Claude Code に適用します。
oh-my-codex と Superpowers の違いは？
Superpowers はセッション内の agent の 振る舞い を制約します — コーディング前のプランニング、TDD の強制、構造化されたレビュー サイクル。OMX は ランタイム インフラ を提供します — worktree 隔離、マルチエージェント協調、永続状態、HUD 監視。Superpowers は一つの agent を賢くします。OMX は agent のシステムを確実に走らせます。射程が違いすぎるので、直接比較すると本質を取り逃します。
oh-my-codex は TDD ワークフローに対応している？
対応しています。TDD skill は red-green-refactor サイクルをハード コンストレイントとして強制します — 提案ではありません。テストは実装コードより先に書かれなければなりません。agent が先に実装を書こうとすると、skill はそれを削除して再スタートさせます。このルールは $tdd ワークフロー パスに対して特に適用されます。
oh-my-codex の agent は、学んだことを覚えていられる？
OMX は永続状態を保ちます — セッション ログ、タスク産物、プロジェクト memory ファイルは .omx/ 内にあります。同じプロジェクト内であれば、agent は過去のセッションからコンテキストを取り戻せます。OMX がやらないのは、成功した問題解決の経路を、別プロジェクトの別 agent が継承できる転送可能な能力としてパッケージ化することです。この区別 — 状態の永続化と能力の継承のあいだ — こそ、現在の編成ツールがおおむね止まる場所です。
v2 のアーキテクチャがどう落ち着くかは、見続けるつもりです。Claude 委譲モデルからの離脱が正しいトレードオフだったのか、それとも必要に迫られたものだったのか、私の中でもまだ、はっきりし切っていないところがあります。
Previous Posts:
👉 編成が agent スタックのどこに位置するかをよりクリアにしたいなら、こちら：OpenHarness and GEP: The Three Layers of the Agent Stack
👉 実行システムが学習転移を解決しない理由を掘るなら：ARC-AGI-3 and the Agent Learning Gap: What's Still Missing
👉 agent をまたいだ永続状態と、真の能力再利用を比較しているなら：Agent Skills vs GEP Assets: What Actually Transfers Between Agents
👉 memory システムと、本当のクロスセッション学習の違いを理解するには：Hermes Agent vs EvoMap: Memory vs Capability Inheritance
👉 agent が編成レイヤーを越えて進化し得るかを探っているなら：EvoSkills: Can Agents Actually Improve Themselves Over Time?
