oh-my-codex解説：Codex向けのoh-my-zsh、韓国発OSS

今月のAIコーディング業界で、静かに面白いことが起きている。OpenAIがClaude Code向けのプラグインを出した。そしてプロシューマー・コミュニティ側は「Codex向けのoh-my-zsh」を出した——メンテナーは韓国の開発者Yeachan-Heo、オープンソース、リリースから2週間でGitHubスターが1万6千を超えた。両方ともオープンソース。両方とも、各メディアが「Codex vs Claude Code」の比較記事を書いている間に、静かに動いていた。

ライバル劇場は終わった、という話。今やClaude Code内からCodexを呼べる、OpenAI公式メンテナンスのコマンドで。そしてOMXというオーケストレーション層が、tmuxペインに複数のエージェントを立てて、oh-my-zshがシェルでやったこと——「スキャフォールディングそのものが製品」——をそのままCodexに持ち込んでいる。

今の一文が三つの言語に聞こえたなら、それがこの記事の出発点。両ツールが正確には何なのか、どうインストールするのか（各2分ほど）、そしてこの二つが合わさって語るストーリーが、個別のツール一つより重要な理由を整理する。

oh-my-codex（OMX）って何？

短く：OMXとCodex CLIの関係は、oh-my-zshとzshの関係そのもの。oh-my-zsh未経験なら、こう考えて。zshはターミナルのコマンドを実行するプログラム。oh-my-zshは、そのzshを「初めて快適に使える」ものに変えたテーマ、プラグイン、エイリアス、フックの詰め合わせ。OMXはそれをCodexに対してやる。

長く：Codex CLIはOpenAIのターミナル系コーディングエージェント——ChatGPTのより有能な従兄弟で、ターミナルに住み、テストを自分で回し、コミットまでやる。有能だけどミニマル。OMXはそのミニマル版に足りないものを一通り足す。tmuxペインで並列稼働するエージェントチーム、MCPサーバー経由の永続メモリ、33種類の専門プロンプト、TDDや計画フェーズなどのワークフロー系スキル、主要イベントすべてに対するフックシステム、そしてplan → PRD → exec → verify → fixのステージドパイプライン。

Yeachan-Heoがメンテナンスする人気forkは、4月第1週でGitHubスター1万6千を突破した。 4月5日にはtrending-repos系のトラッカーが「24時間で1,789個追加」と記録。MITライセンス。AI開発者界隈で有名なSwyxが、トレンド入り翌日にメンテナーのYeachan-Heoを作者として言及して推した。

技術寄り：エージェントは13個（$ultrawork, $deep-interview, $plan, $research, $team, $review, $tdd, $doctor, $hud, $trace, $autoresearch, $architect, $executor, $reviewer）。tmuxベースの並列ワーカーは各自が独立したgit worktreeに入る（だからマージ競合しない）。フックはSessionStart/PreToolUse/PostToolUse/UserPromptSubmit/Stopの5点。DiscordとTelegram連携、--yoloから--madmaxまでのランチプロファイル（慎重さと速度のトレードオフ）。

codex-plugin-ccって何？

短く：こっちはOpenAI本体が作ったもの。Claude Code用のプラグイン——つまりAnthropicのツールを拡張する——で、Claude Code内からCodexにタスクを委譲できる。ユーザーはClaude Codeから離れない。Codexは渡された仕事をやる。

長く：Claude Codeに「このリスクのある変更、セカンドオピニオン欲しい」と思ったことがあるなら、これがまさにそれ。重要なコマンド三つ：

/codex:review：現在のコミット前の変更に対して、Codex品質のレビューを回す
/codex:adversarial-review：設計判断そのものを圧力テストする。認証周り、インフラスクリプト、大規模リファクタなど「暗黙の前提が命取り」な領域向け
/codex:rescue：Codexにオープンエンドなタスクをバックグラウンドジョブとして渡す。再開、待機、フレッシュスタート、モデル選択、effort levelの設定まで、すべてフラグ

もう三つはジョブ管理用：/codex:statusで実行中・直近のジョブ、/codex:resultで最終出力とCodex側で続きを実行するためのセッションID、/codex:cancelで不要なジョブの停止。

内部はModel Context Protocol（MCP）プラグイン。ローカルのCodex CLIまたはCodexアプリサーバーと通信する。Codexをネイティブで走らせた時以上のデータがOpenAIに送られるわけではない。ChatGPTのサブスクリプション（Freeでも可）かOpenAIのAPIキー、それとNode.js 18.18以上があれば動く。

4月初頭のローンチ日、ある開発者が「Claude Code内からCodexが動かせる」と投稿したら、いいね2,243、リポスト177を集めた。反応のほとんどは「え、OpenAIがマジで出した？」だった。半年前なら冗談だった文が、いま現実になった。

OMXを2分でインストール

ターミナルを開く。

npm install -g @openai/codex oh-my-codex
omx setup
omx doctor

これで完了。1つ目のコマンドはnpmからCodex CLIとOMXパッケージを取ってくる。2つ目はインタラクティブなセットアップ——APIキーが未設定なら聞いてきて、プロジェクトに.omx/ステートディレクトリを作る。3つ目は診断で、tmux、git worktreeの権限、Codexの認証情報が揃っているかを確認する。

実際にセッションを始めるには：

omx --madmax --high

--madmaxは最もアグレッシブなランチプロファイル。tmuxペインにエージェントチームを立てて、各自独立したgit worktreeに入れる。慎重に始めたければ--high単体、もっと慎重なら--yolo（シングルエージェントモード、ガードレール控えめ）、フルで深くエージェンティックに行くなら--xhigh。

注意点：ChatGPT Plus（月20ドル）で--madmaxを回すと、使用上限が思ったより早く切れる。ある開発者はわずか6分で上限に達したと報告している。OMXでまじめに何かやるなら、100ドルのCodex Proティアを予算に入れるべき——5倍のレート制限が、並列エージェントを現実的に使える閾値。

codex-plugin-ccを2分でインストール

これはシェルからじゃなくて、Claude Code内で入れる。Claude Codeを開いて：

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

スコープを選ぶ：userならどこでも使える、projectなら現在のリポジトリ限定、localなら単一セッション限定。セットアップがCodex接続をガイドする——Codex CLIが未インストールなら促される。

セットアップ完了後、実変更に対して回してみる：

/codex:review --base main

mainとの差分をまるごとCodex品質でレビュー。認証やインフラ系の変更なら：

/codex:adversarial-review --background

adversarial reviewがバックグラウンドで走るので、自分は作業を続けられる。/codex:statusで確認、/codex:resultで結果を引き取る。レビューが致命的なら、少なくともマージ前に拾えた。

両方そろっての実運用パターン

コミュニティで繰り返し出てくるワークフローはこれ。

Claude Codeを開く。アーキテクチャと計画にはClaude Opus 4.7を使う。Claudeが慎重になりすぎる場面——静的HTML、CSSの調整、純粋なリファクタなのに煮え切らない類——に来たら、/codex:rescueでCodexのgpt-5.4-miniにバックグラウンドで押し切らせる。結果を引き戻してClaude Codeでレビュー、マージ。

大規模リファクタなら、両モデルをadversarialで回す。ブランチで変更を用意。/codex:adversarial-reviewに--focus "authentication and session handling"を付けて実行。Codexが別モデル視点でレビューする。二つのモデルで意見が割れた箇所こそが、本当にリスクがある箇所。

ターミナル側ではOMXが同じ3エージェントを並列で走らせる：APIレイヤーに1つ、フロントエンドに1つ、テストに1つ。各自tmuxペイン、各自git worktree。最後に$reviewエージェントが3本全部をチェックしてから、コーディネートされたマージ。

Xである韓国の開発者がこのパターンを一行にまとめていた：「開発はクロードコードに、レビューはコーデックスに」。日本の開発者はもっとシンプルに：「ClaudeとCodexのコラボ最高」。誰がどの会社のモデルを作ったかなんて、もう気にしていない。

oh-my-zshモーメント

OMXがこれほど急上昇した理由は、機能そのものじゃない。形（かたち）。oh-my-zshは、まともなシェルを「コミュニティ所有のプラットフォーム」に変えた。みんながプラグインを持ち、みんながテーマを持った。シェル自体は変わってない——周りのスキャフォールディングが製品になった。

AIコーディングエージェントにいま起きているのは、それ。Claudeにはobra/superpowersとui-ux-pro-maxのエコシステム。Codexには今やOMXと、4月17日にリリースされた90以上の公式プラグイン。両方とも「いいモデルを作る」時代から「いいモデルプラスオーケストレーション層を作る」時代に進化している。

本当に新しい部分：codex-plugin-ccのおかげで、そのオーケストレーション層同士が対話する。OMXをCodexの上で動かしつつ、Claude Codeがセッション途中でそこに委譲できる。モデル戦争が、ベンチマークではなく、周辺の配管工事によって片付きつつある。

日本の開発者視点で一つ：このプロジェクトの中心的メンテナーが韓国人であることは、興味深い事実。アジア発OSSがグローバル開発者エコシステムの配管工事に実質的な貢献をしている事例として、note、Qiita、Zennあたりで今後掘り下げられる題材だと思う。

うまくいかないこと（正直ベース）

安いプランだとレート制限に轢かれる。 並列エージェントは並列トークン。ChatGPT Plusの20ドルティアはシングルエージェントのCodexはこなせる。OMXの--madmaxモードはこなせない。並列で回したいなら、月100ドルのCodex Proを予算に入れる。

OMXはtmux前提。 WindowsだとpsmuxフォールバックがあるけどBattle-testedは薄い。Mac/Linuxが開発のメインライン。

codex-plugin-ccはローカルでCodex CLIが動いていることが必要。 クラウド間ブリッジじゃない。Codexをマシンに入れたくないなら、これは合わない。

両ツールとも、エージェントが昔から失敗する形で今も失敗する。 テストがループに捕まる、LLMが解決できないマージ競合、自信満々に書かれた微妙に間違ったドキュメント。オーケストレーションは失敗を早く検知するだけで、失敗そのものはなくならない。

トレンディングのスター数とbattle-testedは別物。 OMXはまだ数週間前のプロダクト。一部機能（MCPメモリサーバー、Telegram連携）はデモでは動くが、プロダクションで圧力テストされていない。リスク回避型なら、一か月見てからメインワークフローに組み込むのが無難。

「oh-my-codex」リポジトリは二つある。 Yeachan-Heo forkがツイートで一番引用される1万6千スターの方。staticpayload forkは別の、よりリーンなプロジェクト。インストール時に正しい方を選ぶこと。

4月17日以降、OMXの立ち位置に疑問を出す声も。 ある中国語圏の開発者が「Codex Desktopのcomputer-useプラグインが出た以上、OMXのオーケストレーション機能がネイティブと被り始めるのでは」と指摘した。1か月見る価値のある緊張点。今日時点では、OMXのフックとチームベースのワークフローはデスクトップアプリよりまだ先を行っている——が、ギャップが縮む可能性はある。

読者別、何を意味するか

Claude Codeのパワーユーザー： 今週末にcodex-plugin-ccを入れる。2分のセットアップで、あらゆる変更に対して無料のセカンドオピニオンが手に入る。Codexを使うことにコミットする必要はない——Claudeが自分でも分かるほど単純なことで煮え切らないとき、手元にある状態にしておくだけ。

すでにCodex CLIを使っている： タイムアウトする長時間タスクをよく回す、または並列マルチエージェントが欲しいならOMXを入れる。短いイテレーション中心で価格に敏感なら、素のCodex CLIのままで。

AIコーディングエージェントがまだ初めて： どちらも今はスキップ。Claude CodeかCodex Desktopをそのまま使う。シングルエージェントが「何を間違うか」を先に感じる必要がある。そうしないとオーケストレーション層の意味がピンと来ない。一か月後にまた来る。

チームでどちらに標準化するか決めている： もうその質問はnon-question。答えは「両方、オーケストレーション付き」。どのオーケストレーションスタック（OMX vs obra/superpowers vs 自作）で行くかを軸に決めて、どのモデルにコミットするかは二の次に。

この週末にインストールすべき人

OMXを今入れる： macOS/Linuxでtmux、Codex Pro（月100ドル）、日曜に流し放しにできる数時間タスクがある。
codex-plugin-ccを今入れる： 既にClaude Codeを使っていて、2分の投資でCodexをバックアップとして持ちたい。
両方入れる： 個人開発者またはインディーオペレーターで、同じ時間で throughput を増やすアイデアが尽き始めている。
今はスキップ： 主力ツールをまだ勉強中。オーケストレーション層は「既に上手いこと」を増幅する。まだ上手いことが何もない段階では、混乱を増幅する。

結論

OMXとcodex-plugin-ccは、同じストーリーの二つの半分：AIコーディングは「選択問題」から「構成問題」に変わりつつある。「どのモデルがベストか」の時代は終わりかけている。「どのオーケストレーション層が自分のモデル群を繋ぐか」の時代が始まっている。

両方とも無料。両方とも5分以内でインストールできる。両方とも、同じことを示している：モデルを出す会社が、競合と相互運用するためのツールを出している。開発者が本当に欲しかったのがそれだから。

OMXを入れる。codex-plugin-ccを入れる。1週間使う。最終的なスタックは、どちらとも完全には一致しないと思う——それでいい。スタック自体が製品になっていく、それが要点。