AIツール

oh-my-codex：Codex CLI にワークフロー、スキル、実行時ガードレールを追加する

Yeachan-Heo/oh-my-codex の位置づけ、インストール方法、主要ワークフロー、skills/agents 体系、プラグイン形態、プラットフォーム上の注意点、使いどころを整理する。Codex の代替ではなく、Codex CLI にプロセス、状態、実行時チェックを加えるためのレイヤーだ。

Yeachan-Heo/oh-my-codex、略して OMX は、OpenAI Codex CLI を中心にしたワークフローレイヤーだ。

プロジェクト：https://github.com/Yeachan-Heo/oh-my-codex

これは「もう一つの coding agent」を作ろうとしているわけではない。すでに Codex CLI を使っている人に、より安定した日常の作業方法を提供することが目的だ。セッション開始時にプロジェクト指示を読み込み、複雑なタスクでは計画前に意図を明確にし、実行中は durable goal と状態を記録し、最後は review と QA で結果を締める。

執筆時点で、GitHub ページ上の star は約 29.4k、最新 release は 2026 年 5 月 21 日公開の v0.18.1 だ。README では、公式プロジェクトは Yeachan-Heo/oh-my-codex、公式 npm パッケージは oh-my-codex であることも明示されている。第三者の “OMX v2” のような名前のプロジェクトを、このリポジトリの公式後継として扱うべきではない。

これは何か

OMX は Codex を置き換えない。

実際の実行エンジンとして Codex CLI を残し、その周りに主に三つのものを足す。

  1. より固定されたタスクフロー。
  2. 再利用できる prompts、skills、specialist agents。
  3. .omx/ 配下の計画、ログ、状態、実行時記録。

つまり、Codex が実作業を行い、OMX はその作業をよりエンジニアリングプロセスらしくする。通常の prompt 集との大きな違いもここにある。単に system prompt にルールを詰め込むのではなく、確認、計画、実行、検証、チーム連携、実行時診断を呼び出し可能な作業面として分解している。

推奨インストール

README と Getting Started はどちらも、OMX の推奨デフォルトが macOS または Linux 上の Codex CLI であることを強調している。ネイティブ Windows と Codex App は現時点で主な体験パスではなく、挙動が不安定だったり、サポートが限定的だったりする可能性がある。

すでに Codex CLI が入っている場合は、次のように始められる。

1
2
3
4

codex --version
npm install -g oh-my-codex
omx setup
omx doctor

まだ Codex CLI がなく、npm で管理したい場合は次の通り。

1
2
3
4

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

ここで一つ注意点がある。Homebrew がすでに codex バイナリを管理している環境では、@openai/codex と oh-my-codex を一つのグローバルインストールコマンドにまとめないほうがよい。README では、Homebrew 所有の codex バイナリと npm インストールが EEXIST で衝突する可能性があると説明されている。OMX が必要とするのは、PATH 上にあり、認証済みで動作する codex コマンドだけだ。Codex を npm で入れる必要はない。

インストール後は、実際の実行スモークテストも行う。

1
2

codex login status
omx exec --skip-git-repo-check -C . "Reply with exactly OMX-EXEC-OK"

omx doctor はローカルのインストール形状が概ね正常かを確認できるが、現在の shell/profile から Codex アカウント、プロキシ、base URL、認証経路を使って本当にモデル呼び出しができるかまでは証明しない。この違いは、HOME、コンテナ、リモート環境、ローカルの OpenAI 互換プロキシを切り替えるときに特に重要だ。

デフォルトワークフロー

OMX の主な流れはおおよそ次のようになる。

1
2
3
4

$deep-interview "clarify the authentication change"
$ralplan "approve the auth plan and review tradeoffs"
$prometheus-strict "stress-test the plan before durable execution"
$ultragoal "turn the approved plan into durable Codex goals"

よく使うのは次の三段階だ。

  • $deep-interview：要求がまだ曖昧なときに、境界、目標、非目標を確認する。
  • $ralplan：要求を計画にまとめ、アーキテクチャ視点と批判的視点で確認する。
  • $ultragoal：承認済みの計画を、より長く走れる目標とチェックポイントに変換する。

並行作業が必要なら Ultragoal story の中で $team を使う。一人の継続的な実行ループで十分なら $ralph を使う。名前はやや重く見えるが、考え方ははっきりしている。agent が要求を聞いた瞬間にファイルを編集し始めるのではなく、何をするか、どう進めるか、どう検証するか、いつ止めるかを先に明確にする。

skills と agents が提供するもの

OMX のドキュメントでは、スキルはいくつかのグループに分かれている。

Canonical Workflow には $deep-interview、$ralplan、$prometheus-strict、$ultragoal、$code-review、$ultraqa がある。これらは、確認、計画、実行、レビュー、QA まで含む完整なエンジニアリングタスク向けだ。

Execution Modes には $team、$ralph、$autopilot、$ultrawork などがある。タスクを単線で進めるか、チーム実行にするか、より強い自動ループにするかを決める。

Agent Catalog は役割ライブラリに近い。analyst、planner、architect、debugger、executor、verifier、security-reviewer、performance-reviewer、code-reviewer、test-engineer、designer、researcher などが含まれる。毎日これらを手動で呼び出す必要はないが、OMX が「巨大な万能 prompt」ではなく、エンジニアリング作業を再利用可能な役割と段階に分解しようとしていることは分かる。

これは長期プロジェクトで意味を持つ。AI コーディングの失敗の多くは、モデルがまったくコードを書けないからではない。要求確認、アーキテクチャ境界、テスト基準、最後のレビューを飛ばして、実行に入りすぎることから起きる。OMX は skills と roles でその手順を飛ばしにくくしようとしている。

プラグイン形態と実行時状態

README によると、このリポジトリには plugins/oh-my-codex に公式 Codex plugin layout も含まれ、marketplace metadata も付いている。

ただし、ドキュメントはこのプラグイン形態が npm install -g oh-my-codex と omx setup の代替ではないことも強調している。プラグインは hooks、skill surface、Codex のライフサイクル統合をまとめるものに近く、実際の実行時にはインストール済みの omx CLI に依存する。

最新の v0.18.1 release もこの領域に重点を置いている。プラグインインストールは pinned OMX launcher を使うようになり、hook 失敗時はより保守的に扱われ、Ultragoal の状態変更は直列化され、release packaging は crate-local の .omx runtime cache を除外し、npm、Cargo workspace、lockfile、プラグイン manifest のバージョンも同期される。

これらの変更から、OMX が単なる prompt リポジトリではなくなっていることが分かる。インストール形態、hook の安全性、状態書き込み、release パッケージ内容、実行時の一貫性をかなり真面目に扱っている。ツールチェーンでは派手ではないが、こういう細部が効く。

向いている人

OMX は、Codex CLI を本格的に使っている開発者に向いている。特に次のような場面だ。

  • Codex に複数ファイル、複数ステップのタスクをよく任せる。
  • agent にいきなりコードを書かせず、先に要求を確認させたい。
  • 計画、実行、検査、review、QA を分けて管理したい。
  • プロジェクト内に .omx/ の状態、計画、ログを残したい。
  • tmux/team runtime や、より強い長時間タスク実行を試したい。
  • チームの開発習慣を skills や prompts として蓄積したい。

Codex に設定を一行変えさせる、小さなスクリプトを生成させる、コード断片を説明させるだけなら、OMX は重く感じるかもしれない。初心者が最初に必ず入れるレイヤーというより、高頻度で AI コーディングを行う人向けのツールベルトに近い。

使うときの注意点

第一に、OMX を「無人で何でも完了してくれる保証」として扱わないこと。ワークフローは強化できるが、要求が妥当か、アーキテクチャを変えるべきか、リスクを受け入れてよいかは人が判断する必要がある。

第二に、プラットフォーム境界を確認すること。README は現在 macOS/Linux + Codex CLI を明確に推奨している。ネイティブ Windows の経路は存在するが、デフォルトの最適体験ではない。Windows で使うなら、通常は WSL2 のほうが安定しやすい。

第三に、omx doctor は最終検証ではない。実際に環境が使えることを示すのは、codex login status と omx exec のような実モデル呼び出しだ。

第四に、ワークフローが強いほど、タスク境界を明確に書く必要がある。$ultragoal、$team、$autopilot は、受け入れ基準があるタスクに向いている。要求自体がまだ曖昧なら、まず $deep-interview や通常の対話で境界を明確にしたほうがよい。

まとめ

oh-my-codex の価値は、Codex を別のツールに変えることではない。Codex CLI に、よりエンジニアリング寄りの作業レイヤーを加えることにある。

AI コーディングを「一言頼んで一回直す」から、「確認、計画、実行、検証、状態記録」へ少し進める。軽いタスクには重すぎるかもしれないが、Codex で実プロジェクトを頻繁に扱う人にとっては、安定したフロー、再利用可能なスキル、実行時診断、durable goal がかえって手間を減らしてくれる。

Codex CLI を日常の開発ツールとして使っているなら、OMX は試す価値がある。直接インストールしなくても、skills、agents、計画、受け入れフローの分解方法は、自分の AI コーディングワークフローを改善する材料になる。

参考資料

© 2022 - 2026 KnightLiブログ
记录并分享
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。