はじめに
oh-my-claudecode（以下 OMC）と oh-my-codex（以下 OMX）は、いずれも Yeachan-Heo 氏が設計した CLI 拡張レイヤーだ。作者が同じであれば設計も似るはずだが、実際にコードを見ると多くの部分で意図的に異なる判断が下されている。本記事の問いはシンプルだ。「同一作者がなぜ、同じ目的のツールを違うアーキテクチャで作ったのか」。
各ツールの概要・導入手順・基本的な使い方はそれぞれの入門記事が詳しい。本記事ではそちらを前提に、設計判断の違いと使用感への影響に絞って掘り下げる。
- oh-my-claudecode 入門 — Claude Code 向けマルチエージェント・オーケストレーション
- oh-my-codex 入門 — Codex CLI をチーム開発ワークフローに変える拡張レイヤー
注記: 本記事の情報は2026年4月時点のものであり、各リポジトリの機能・数値は変動する可能性がある。最新の情報は各リポジトリの README を参照してほしい。
共通の設計 DNA
差異を論じる前に、両ツールが共有する設計を確認しておく。共通部分が多いほど、差異の「なぜ」が際立つためだ。
どちらも 既存の CLI を置き換えない 拡張レイヤーとして設計されている。Claude Code や Codex CLI の挙動には手を加えず、既存のカスタマイズ（プロンプト設定、API キー管理、フック設定）をそのまま活かせる。
ワークフローの骨格も共通だ。team-plan → team-prd → team-exec → team-verify → team-fix という5段階パイプラインは両ツールで同一であり、team-verify で問題が検出されれば team-fix に戻るフィードバックループも両方に実装されている。「いきなり実装に入らない」構造（OMC の /deep-interview → /ralplan → /ralph、OMX の $deep-interview → $ralplan → $ralph）も、呼び出し形式が異なるが（OMC はスラッシュコマンド /、OMX はドルサインプレフィックス $）、発想は一致している。
基盤インフラも揃っている。tmux を使った複数エージェントの並列実行と SSH 切断後の継続、HUD によるリアルタイム状態表示、autopilot による自律実行、継続強制（Continuation Enforcement）による早期停止の阻止、OpenClaw ゲートウェイ連携、MCP サーバー経由の状態管理——これらはすべて両ツールに実装済みだ。
つまり、ユーザーが「CLI 拡張レイヤー」に求める核心的な機能は、どちらを選んでも手に入る。
分岐の起点 — なぜ設計が割れたか
両ツールの設計が分かれた最大の要因は、Claude Agent SDK の有無だと読める。
OMC は @anthropic-ai/claude-agent-sdk をコア基盤として深く統合している。SDK が提供するエージェント抽象、ツール管理、MCP サーバー構築 API（createSdkMcpServer）を前提に設計されているため、本番 npm 依存が多数になる。SDK のエコシステムに乗ることで、高度な機能を短期間で構築できる代わりに、SDK のリリースサイクルや API 変更に依存する関係になる。
OMX はそのような上位 SDK を持たない。Codex CLI に対してそれほど高水準な拡張 SDK が提供されていないという事情もあるが、それ以上に「必要最低限の依存に絞る」という設計方針が強く感じられる。本番 npm 依存は @iarna/toml（Codex の設定ファイル読み書き）、@modelcontextprotocol/sdk（MCP 標準）、zod（バリデーション）の3パッケージのみだ。その代わり、TypeScript だけではパフォーマンスが要求される処理——コードベース検索（omx-explore）、tmux 抽象化（omx-mux）、ランタイムコア（omx-runtime-core, omx-runtime）、シェルネイティブ検査（omx-sparkshell）——を Rust クレートで補っている。
この分岐は「どちらが正しいか」ではなく、対象とする CLI のエコシステム成熟度と設計思想の違いを反映していると考えるのが自然だ。
エージェント設計の違い
エージェントの設計方針は、両ツールの哲学的な差がもっとも表れている領域だ。
OMC は 静的レジストリ方式を採る。src/agents/definitions.ts に v4.11.5 時点で19種のエージェントが定義され、Build/Analysis、Review、Domain Specialists、Coordination の4レーンに分類されている。各エージェントは専用のプロンプトファイル（agents/*.md）、デフォルトモデル、品質保証指針（skininthegamebros-guidance）を持ち、タスク内容に基づいて自動ルーティングされる。重要なのは、モデルの選択まで OMC 側が制御する点だ。architect や critic のような重要役割には高位モデルを割り当て、軽微なタスクには低コストモデルを使う——この判断をツールが代行する。
OMX は 動的ロールプロンプト方式を採る。prompts/ ディレクトリに v0.12.5 時点で33種のロールプロンプト（analyst.md, architect.md, debugger.md 等）が格納されているが、これらはエージェントの事前定義ではなく、$team 起動時にタスク内容から動的に選択されるプロンプトカタログとして機能する。モデルの選択は Codex CLI 側の設定に委ねられる。OMX は「どのロールで考えるか」は管理するが、「どのモデルで計算するか」には介入しない。
この差の本質は「専門性の所在」にある。OMC はツール側に専門知識（どのタスクにはどのエージェントとモデルが適切か）を埋め込み、ユーザーはその判断に乗る。OMX はロールのカタログを提供するが、タスクとロールの組み合わせ判断はより柔軟に扱われ、モデル選択の責任をユーザー（または CLI 設定）に残す。
日常の使用感に効く差
設計の違いが実際の使用感に表れる場面を4つ取り上げる。
モデルルーティング（OMC 固有）
OMC の src/features/model-routing/ には、タスクの複雑度を3種の信号から評価するルーティングエンジンが実装されている。
- レキシカル信号: ワード数、ファイルパス数、キーワード、質問の深度
- 構造信号: サブタスク数、クロスファイル依存、影響範囲
- コンテキスト信号: 失敗回数、会話ターン数
ルールエンジンとスコアラーが独立して評価し、2段階以上乖離した場合は高い方の tier を採用する（under-provisioning 回避設計）。評価結果に応じて Haiku / Sonnet / Opus を自動選択する。README では30〜50%のトークンコスト削減を謳っているが、リポジトリ内に計測データはなく、理論的な推定値とみられる。
OMX ではモデル選択を CLI の設定に委ねることで、ユーザーが自身のコスト戦略を直接制御する設計を採っている。コスト最適化を拡張レイヤーに自動化させたいか、自分で管理したいかが選択の分かれ目になる。
セッション中のクロスCLI転送（OMC 固有）
team ワーカーとして Codex / Claude / Gemini の3 CLI を使える点は両ツール共通だ。しかし OMC にはもう一段階の機能がある。セッション中に動的に他の CLI へ問い合わせを転送できる /ask と /ccg（Tri-Model Synthesis）だ。
# 別CLIに単一の問い合わせを転送
/ask codex "このコードのアーキテクチャリスクを分析して"
# 複数CLIに並行で問い合わせ、結果を統合
/ccg "このPRをレビューして — アーキテクチャはCodexに、UIはGeminiに確認"
OMX は team モードでの協調実行に特化しており、セッション中の動的転送とは異なるアプローチで複数 CLI を活用する設計だ。
Rust ネイティブツールチェーン（OMX 固有）
OMX は TypeScript だけではパフォーマンスや安全性の要求を満たしにくい処理を、5つの Rust クレートに分離している。日常の使用感に直結するのは以下の3点だ。
コマンド出力の自動要約（omx-sparkshell）は、言語別のプラグインレジストリ（Python, Node.js, Go, Rust 等17種対応）でコマンドの stdout/stderr を監視し、行数が閾値を超えた場合にエージェント向けの要約を自動生成する。テスト出力やビルドログのノイズをユーザーが手動でフィルタリングする必要がなくなる。
マルチワーカーの競合制御（omx-runtime-core）は、AuthorityLease（分散ロック）と DispatchLog（イベント再生）で複数ワーカーの並行操作を管理する。障害時にはイベントログから状態を再構築し、中断した作業を再開できる。
tmux 操作の型安全な抽象化（omx-mux）は、ペイン検出・入力送信・出力キャプチャを Rust の代数的型で定義し、文字列連結による tmux コマンド構築の脆弱性を排除している。
状態永続化の設計差
OMC の /learner スキルは、セッションから得たデバッグパターンや解決手法を分析し、再利用可能なスキルファイルとして .omc/skills/ に保存する。「そのコードベース固有の知識」「デバッグに労力を要した解決手法」を条件として保存対象を絞り込む設計で、暗黙知の蓄積に特化している。スキルのスコープはプロジェクトレベルとユーザーレベルの2階層あり、チーム共有ルールと個人設定を分離できる。
OMX はすべての状態を .omx/ ディレクトリ以下にファイルとして保存する。
.omx/
state/ # ワークフローモード状態（MCP state-server 経由）
plans/ # $ralplan で生成した計画
logs/ # セッションログ
notepad.md # セッション間メモ
project-memory.json # プロジェクトメモリ（MCP memory-server 経由）
hooks/ # ユーザー定義プラグインフック（*.mjs）
plans/ をリポジトリにコミットすればチームで計画を共有でき、ファイルを読み書きするスクリプトで CI/CD パイプラインとの連携も組める。永続化の仕組みが透明なため、状態を外部から読んだり、特定時点に戻したりしやすい。
OMC は「何を学んだか」の蓄積に重点を置き、OMX は「何が起きているか」の可視性に重点を置いている——という対比で整理できる。
フック・拡張性の設計差
両ツールともフックによる拡張が可能だが、設計の思想が異なる。
OMC の src/hooks/ には v4.11.5 時点で約50のモジュールが内蔵されている。autopilot、ralph、ultrawork、team-pipeline、keyword-detector、learner、persistent-mode など、主要機能のほとんどがフックとして実装されている。拡張の主体は「OMC が提供する内蔵フック群を使う」であり、ユーザーは設定やキルスイッチ（DISABLE_OMC, OMC_SKIP_HOOKS）で有効化・無効化を管理する。マジックキーワードの検出は日本語・韓国語・中国語・ベトナム語を含む多言語対応で、コードブロック内のキーワードを誤検知しない設計になっている。
OMX のフックは二重レイヤー構造を持つ。Codex ネイティブフック（.codex/hooks.json 経由で SessionStart / UserPromptSubmit / PreToolUse / PostToolUse / Stop の5イベント）と、OMX プラグインフック（.omx/hooks/*.mjs、17種の名前付きイベント、HookPluginSdk）が独立して動作する。後者のプラグインフックは HookEventEnvelope 型でイベントをラップし、プラグイン側に tmux 操作、ログ記録、状態の読み書き、OMX セッション情報へのアクセスを提供する。
拡張の方向性が異なる。OMC は「内蔵の豊富なフック群を設定で調整する」スタイルで、すぐに使える反面、内蔵フック以外の挙動を追加したい場合の経路は限られる。OMX は「プラグインフック SDK で自由に処理を追加する」スタイルで、初期設定は少ないが拡張の自由度が高い。
開発体制・エコシステムの比較
実装規模と開発体制をまとめておく。
| 観点 | OMC | OMX |
|---|---|---|
| 分析時バージョン | v4.11.5 | v0.12.5 |
| 作成日 | 2026-01-09 | 2026-02-02 |
| Stars | ~2.9万（2026年4月17日時点） | ~2.4万（2026年4月17日時点） |
| 本番 TS ソースファイル | ~474本 | ~221本 |
| Rust クレート | なし | 5個（~29ファイル） |
| 本番 npm 依存 | 多数 | 3パッケージ |
| CI ジョブ数 | 5（2026年4月時点） | 12（2026年4月時点） |
| README 翻訳 | 12言語（2026年4月時点） | 16言語（2026年4月時点） |
| 配布形態 | プラグイン + npm | npm のみ |
CI ジョブ数の差（5 vs 12）は技術スタックを直接反映している。OMX は Rust の rustfmt、clippy、Rust カバレッジ、フルソースビルド（Rust + TypeScript）が追加される。加えて team コアとフック領域には明示的なカバレッジ閾値（行78%、関数90%、分岐70%）が設定されており、品質保証への投資が CI 構成に表れている。
CHANGELOG の分量も対照的だ。OMC は約30行、OMX は1,198行ある。OMX は2026年2月の作成以来、約2ヶ月半で PR #1473 まで到達しており、高頻度のリリースサイクルが CHANGELOG に記録されている。
配布形態も異なる。OMC は Claude Code プラグイン（marketplace 対応）と npm の二経路で配布されるが、OMX は npm のみだ。Claude Code の marketplace エコシステムに乗ることで OMC はより低摩擦なオンボーディングを実現している側面がある。
選択の判断軸
「今使っている CLI に合わせる」が最もシンプルな判断基準であることは変わらない。ただ、それを超えた観点で判断する場合のフレームを整理しておく。
設計哲学の好みを軸にするなら、SDK のエコシステムに深く統合し豊富な内蔵機能を享受したい場合は OMC が合う。外部依存を最小化し、必要な機能は自分でプラグインとして追加したい場合は OMX が合う。
拡張の方向性を軸にするなら、内蔵のフック群・スキル・エージェント設定を設定ファイルで調整するスタイルが好みなら OMC、SDK なしでプラグインフックを書いてゼロから積み上げるスタイルが好みなら OMX になる。
コスト管理を軸にするなら、モデル選択を自動化してトークン消費を最適化したいなら OMC のルーティングエンジンが選択肢になる。使用するモデルは自分で設定し管理したいなら OMX の設計の方が余計な介入がない。
クロスCLI連携の深度が重要なら、セッション中の動的転送（/ask, /ccg）が必要か否かで分かれる。team ワーカーとして複数 CLI を協調させるだけでよいなら両ツールともに対応している。
状態の透明性・CI 連携を優先するなら、.omx/ のファイルベース永続化は Git に馴染み、スクリプトとの連携が容易だ。OMX の設計はこの点で有利になる傾向がある。
まとめ
OMC と OMX は同一作者・共通の設計思想を持ちながら、対象 CLI のエコシステムの違いと設計思想の選択から、異なるアーキテクチャを持つツールに育っている。
差異の本質は3点に集約できる。
- SDK 統合 vs 軽量独立: OMC は Claude Agent SDK に深く統合した多機能路線。OMX は本番依存3パッケージに絞り、Rust クレートで性能を補う軽量路線
- 静的レジストリ vs 動的カタログ: OMC は v4.11.5 時点で19種のエージェントをモデル指定まで含めて事前定義。OMX は v0.12.5 時点で33種のロールプロンプトをタスク時に動的選択し、モデル判断はCLIに委ねる
- 内蔵充実 vs プラグイン拡張: OMC は約50の内蔵フックモジュールと多言語マジックキーワード対応で機能密度を高める。OMX は HookPluginSdk による17種イベントのプラグイン拡張で柔軟性を確保する
共通基盤（5段階 Team パイプライン、tmux 耐久性、HUD、autopilot、MCP 統合、継続強制、OpenClaw 連携）の多さは予想以上だ。どちらを選んでも、既存の CLI 運用を壊さずにマルチエージェント構成へ移行できるという根本的な価値は共通して得られる。
参考リンク
- oh-my-claudecode（GitHub） — Claude Code 向けマルチエージェント・オーケストレーション基盤
- oh-my-codex（GitHub） — Codex CLI 向け拡張レイヤー
- oh-my-codex 公式サイト — ドキュメント・ガイド
- oh-my-claudecode 入門（Qiita） — OMC の詳細な機能・導入手順
- oh-my-codex 入門（Qiita） — OMX の詳細な機能・導入手順
- Claude Agent SDK（npm） — OMC の基盤となる Claude Code 向けエージェント SDK