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で「この変更はリスクが高いから、セカンドオピニオンが欲しい」と思った瞬間がまさにこれだ。覚えておくべきは以下の3コマンド：

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

残り3つはジョブ管理用だ：/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 reviewで回す。ブランチに変更を用意し、/codex:adversarial-reviewに--focus "authentication and session handling"を付けて実行。Codexが別モデルの視点でレビューを返してくる。二つのモデルで意見が割れた箇所こそが、本質的なリスクポイントだ。

ターミナル側ではOMXが同じ3エージェントを並列で走らせる。APIレイヤー用、フロントエンド用、テスト用。それぞれ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フォールバックがあるが、実証データは薄い。Mac/Linuxが開発のメインラインだ。

codex-plugin-ccはローカルでCodex CLIが動いていることが必須。 クラウド間ブリッジではない。Codexをマシンにインストールしたくないなら、このプラグインは対象外。

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

トレンディングのスター数と実戦耐性（battle-tested）は別物。 OMXはまだ数週間前のプロダクトだ。一部機能（MCPメモリサーバー、Telegram連携）はデモでは動くが、本番環境での負荷テストはまだ不十分。リスク回避型なら、1ヶ月様子を見てからメインワークフローに組み込むのが無難だろう。

「oh-my-codex」リポジトリが二つある。 ツイートで最多引用され、1万6千スターを誇る方がYeachan-Heo fork。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をそのまま使え。シングルエージェントが「何を間違うか」を先に体感しておく必要がある。そうしないと、オーケストレーション層の価値はピンと来ない。1ヶ月後にまた来ればいい。

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

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

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

結論

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

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

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