ここ最近、開発者コミュニティは OpenAI の Codex CLI の話題で持ちきりです。
これにより、AI プログラミングアシスタントが本格的にコマンドラインに進出し、ターミナル上で直接 AI と対話しながらコード作成、バグ修正、リファクタリングが可能になりました。数行の指示を叩くだけで、複雑なプログラミングタスクをこなしてくれるのです。
しかし、実際に使ってみると問題が生じます。会話が毎回ゼロから始まるため、前回の議論の続きを覚えていないのです。
プロジェクトが大きくなればなるほど迷走しがちになります。どのコードが変更済みで、どの落とし穴を回避済みか、どの案が議論済みかが分からなくなります。何より深刻なのは、複雑なタスクに対して一人で黙々と作業するだけで、分担して協業することができない点です。
まるで、非常に有能だが、記憶力がなく、自ら計画を立てることも、チームワークを理解することもできないアシスタントを任されたようなものです。
そんな中、数日前に GitHub で「oh-my-codex（略称：OMX）」というオープンソースプロジェクトを見つけました。そのキャッチコピーは「もはや Codex を孤独にさせない」というものです。
GitHub プロジェクトページ：https://github.com/Yeachan-Heo/oh-my-codex
わずか 2 ヶ月で、このプロジェクトはスター数が 16,000 を超え、爆発的な人気を博しています。
これは Codex を代替するものではなく、Codex にワークフローエンジンを追加するレイヤーです。これにより、単独で戦っていた AI アシスタントが、計画を立て、記憶し、協業する開発チームへと進化します。
┌─────────────────────────────────────────────────┐
│ Codex CLI (実行エンジン) │
│ ↑ │
│ OMX ワークフロー層 │
│ ├── 深層インタビュー ($deep-interview) │
│ ├── 計画の承認 ($ralplan) │
│ ├── 継続的実行 ($ralph) │
│ └── チーム協業 ($team) │
│ │
│ .omx/ 永続化ストレージ │
│ ├── 計画ドキュメント │
│ ├── インタビュー記録 │
│ ├── 実行ログ │
│ └── プロジェクトメモリ │
└─────────────────────────────────────────────────┘最も印象的だったのは、4 つの中核機能です。
1. 1 つ目は「$deep-interview（深層インタビュー）」システムです。
これまで Codex を使っていて最も頭を悩ませていたのは、要件が不明確な時です。曖昧な指示を出すと、AI は推測で動き始め、出来上がりの 8 割は期待外れという結果になりがちでした。
一方、OMX の深層インタビュー機能は、経験豊富なプロダクトマネージャーのように、能動的に要件の詳細を問い詰めてきます。
例えば「ユーザー認証機能を追加したい」と言うと、いきなりコードを書き始めるのではなく、「JWT とセッションのどちらを使いますか？」「サードパーティログインは必要ですか？」「セキュリティレベルの要件は？」「エッジケースの処理は？」と聞いてきます。
インタビューを繰り返すことで、曖昧なアイデアを明確な仕様へと変換し、認識の齟齬がない状態で実装に取り掛かれるのです。
# 深層インタビューの例
$ omx
> $deep-interview "システムにユーザー認証機能を追加する"
🤔 深層インタビューを開始...
Q1: 認証方式の選択
- JWT と従来のセッション、どちらを使用しますか？
- リフレッシュトークンの仕組みは必要ですか？
Q2: サードパーティログイン
- どのサードパーティログインをサポートしますか？(Google/GitHub/WeChat)
- OAuth 2.0 のフローはどう処理しますか？
Q3: セキュリティレベル
- パスワード強度の要件は？
- 多要素認証は必要ですか？
- セッションの有効期限は？
✅ インタビュー完了、要件ドキュメントを生成 → .omx/interviews/auth-2026-04-05.md2. 2 つ目は「$ralplan（計画承認）」フローです。
この機能は、計画なしに着手してしまい、作業途中で方向性の誤りに気づくという痛手を解決します。
OMX はインタビューで得た要件を、詳細な実装計画に変換します。変更対象のファイル、技術的なトレードオフ、想定されるリスク、予想工数などを列挙します。
さらに重要なのは、その計画をユーザーの承認に回す点です。疑問を呈したり、代替案を議論したり、優先順位を調整したりできます。
計画が正式に承認されて初めて、実行ステージに進みます。やみくもに作業するのではなく、都度すり合わせながら進めるのです。
> $ralplan "ユーザー認証実装計画の承認"
📋 実装計画を生成中...
=== ユーザー認証モジュール実装計画 ===
【アーキテクチャの決定】
✓ JWT + Redis 方式を採用
✓ フロントエンド・バックエンド分離アーキテクチャ
✓ Google/GitHub OAuth をサポート
【変更ファイル一覧】
- backend/auth/jwt.ts (新規作成、JWT 生成・検証)
- backend/routes/auth.ts (新規作成、認証ルート)
- backend/middleware/auth.ts (新規作成、認証ミドルウェア)
- frontend/pages/login.tsx (修正、ログインページ)
- database/migrations/001_users.sql (新規作成、ユーザーテーブル)
【技術的トレードオフ】
⚖️ JWT vs セッション
JWT を選択：分散処理対応、ステートレス、モバイルフレンドリー
コスト：能動的な無効化が不可、ブラックリストとの併用が必要
【リスク要因】
⚠️ XSS 攻撃 → HttpOnly Cookie を使用
⚠️ CSRF 攻撃 → CSRF トークンを実装
⚠️ 総当たり攻撃 → ログイン制限を追加
【予想工数】3-4 日
この計画を承認しますか？(y/n/修正提案)3. 3 つ目は「$ralph（継続的実行）」ループです。
「ralph」とは「relentless alpha（断念しない実行者）」に由来するネーミングです。
計画が承認されると、ralph が実装を引き継ぎます。実行して終わりではなく、継続的な検証、問題発見、修正を行い、完全なクローズドループを形成します。
例えば、コード変更後に自動でテストを実行し、失敗すれば原因を分析して修正、再度検証し、すべてのチェックポイントがパスするまで続けます。
仕事を任せれば、責任を持って完遂してくれる、頼れる部下を任されたような感覚です。
> $ralph "ユーザー認証実装計画の実行"
🔄 Ralph 継続実行ループを開始...
[Step 1/5] データベースマイグレーションファイルの作成
✅ 001_users.sql を作成
✅ マイグレーションを実行
✅ テーブル構造を検証
[Step 2/5] JWT ユーティリティクラスの実装
✅ jwt.ts を作成
🧪 単体テストを実行...
❌ テスト失敗：トークンの有効期限が設定されていません
🔧 修正：デフォルトの有効期限 24h を追加
🧪 再テスト... ✅ パス
[Step 3/5] 認証ルートの作成
✅ /login 接口を実装
✅ /register 接口を実装
✅ パラメータ検証を追加
🧪 統合テスト... ✅ パス
[Step 4/5] 認証ミドルウェアの実装
✅ トークン検証ロジック
✅ 権限チェック
🧪 ミドルウェアテスト... ✅ パス
[Step 5/5] フロントエンドログインページ
✅ UI コンポーネントの実装
✅ API 連携
🧪 E2E テスト... ✅ パス
✨ すべてのタスクを完了！計 3 の問題を修正、28 のテストを実行し、すべてパスしました。4. そして最もコアなアップグレードが「$team（チーム協業）」モードです。
従来の Codex はシングルスレッド・プログラムのように、一度に 1 つのことしかできません。一方、OMX の team モードでは、複数のエージェントを並列で動作させられます。
大規模モジュールのリファクタリングで、フロントエンド改修、バックエンド API 調整、DB マイグレーション、テスト追加が必要だとします。
team モードなら、3 つの executor ロールを一気に起動し、フロントエンド、バックエンド、DB の各ラインをそれぞれ担当させられます。各エージェントは独立した tmux セッションで、互いに干渉せず作業します。
さらに、これらのエージェント間は相互に連携も可能です。例えば、バックエンド API の改修が完了すれば、フロントエンドに連携準備を通知します。破壊的変更（breaking change）が発生したモジュールがあれば、影響を受ける他のメンバーへ自動で同期します。
> $team 3:executor "EC モジュールのリファクタリング"
🚀 3 つのエージェントチームを起動...
┌──────────────────────────────────────────────────────────┐
│ Team: refactor-ecommerce-2026-04-05 │
├──────────────────────────────────────────────────────────┤
│ Agent-1 [Frontend] tmux session: omx-team-1 │
│ ├─ 処理中：商品リストコンポーネントのリファクタリング │
│ ├─ 進捗：████████░░ 80% │
│ └─ 状態：バックエンド API の準備を待機中... │
├──────────────────────────────────────────────────────────┤
│ Agent-2 [Backend] tmux session: omx-team-2 │
│ ├─ 処理中：注文サービス API の改修 │
│ ├─ 進捗：██████████ 100% ✅ │
│ └─ メッセージ：Agent-1 へ API 準備完了を通知済み │
├──────────────────────────────────────────────────────────┤
│ Agent-3 [Database] tmux session: omx-team-3 │
│ ├─ 処理中：DB テーブル構造の最適化 │
│ ├─ 進捗：██████░░░░ 60% │
│ └─ 状態：マイグレーションスクリプトを実行中... │
└──────────────────────────────────────────────────────────┘
💬 チーム協業ログ:
[14:32] Agent-2 → Agent-1: "注文 API v2 完了。新フィールドはドキュメントを参照のこと"
[14:35] Agent-1 → Agent-2: "了解、新接口との連携を開始します"
[14:38] Agent-3 → All: "⚠️ 商品表に在庫フィールドを追加。既存クエリに影響の可能性あり"プロジェクトの全状態、進捗、ログは「.omx/」ディレクトリに記録されます。
このディレクトリは、チームの共有ブレインのようなものです。すべての計画ドキュメント、インタビュー記録、実行ログ、プロジェクトメモリが、ここに構造化されて保存されます。
次回プロジェクトを開く際、OMX はこれらのコンテキストを自動で読み込みます。過去の議論内容、決定事項、注意すべき落とし穴を把握した状態からスタートできます。
もはや毎回ゼロからの対話ではなく、プロジェクトレベルの連続した記憶を持つようになるのです。
📁 .omx/ # OMX ワークディレクトリ
├── 📋 plans/ # 実装計画
│ ├── auth-plan-2026-04-05.md
│ └── refactor-plan-2026-04-03.md
│
├── 💬 interviews/ # インタビュー記録
│ ├── auth-interview.md
│ └── feature-clarification.md
│
├── 📝 logs/ # 実行ログ
│ ├── ralph-auth-2026-04-05.log
│ └── team-refactor.log
│
├── 🧠 memory/ # プロジェクトメモリ
│ ├── decisions.md # 重要な決定事項
│ ├── pitfalls.md # 既知の落とし穴
│ └── conventions.md # コーディング規約
│
├── 👥 teams/ # チーム協業
│ └── refactor-ecommerce/
│ ├── status.json # チーム状態
│ ├── messages.json # 協業メッセージ
│ └── worktrees/ # Git ワークツリー
│
└── ⚙️ state/ # 実行時状態
└── current-mode.jsonさらに OMX には、ロール・エキスパート・システムも内蔵されています。
「omx --madmax --high」で起動すると、アーキテクト、エグゼキューター、レビュアー、テストエンジニアなど、一連の専門ロールが自動で読み込まれます。
アーキテクチャ設計が必要ならアーキテクトを、迅速な実装が必要ならエグゼキューターを、コードレビューが必要ならレビュアーを呼び出します。
各ロールは専門的なプロンプトとワークフローを持っており、汎用アシスタントとは比べ物にならない専門性を発揮します。
# OMX 内蔵の 30 以上の専門ロール
🏗️ アーキテクチャと設計
├─ $architect # システムアーキテクト - 技術設計
├─ $tech-lead # 技術リーダー - 技術的意思決定
└─ $database-designer # データベースデザイナー - データモデリング
⚡ 実行と実装
├─ $executor # 迅速実行者 - コーディング
├─ $refactor-specialist # リファクタ専門家 - コード最適化
└─ $debugger # デバッグ専門家 - 問題特定
🔒 品質とセキュリティ
├─ $code-reviewer # コードレビュアー - 品質管理
├─ $security-reviewer # セキュリティレビュアー - セキュリティスキャン
├─ $test-engineer # テストエンジニア - テストカバレッジ
└─ $performance-analyst # パフォーマンスアナリスト - 最適化
📚 ドキュメントとコミュニケーション
├─ $tech-writer # テクニカルライター - ドキュメント作成
├─ $api-designer # API デザイナー - 接口設計
└─ $oncall # オンコールエンジニア - 障害対応
# 使用例
$ omx --madmax --high
> $architect "ユーザー認証アーキテクチャの設計"
> $security-reviewer "ログイン接口のセキュリティ監査"
> $executor "JWT 認証ロジックの実装"さらに親切な機能として、モニタリング画面「omx hud --watch」も用意されています。
各エージェントの動作状況、実行進捗、エラー発生の有無などをリアルタイムで確認可能です。開発チームにタスクボードを設置したような感覚で、状況が一目で分かります。
$ omx hud --watch
╔════════════════════════════════════════════════════════════════╗
║ OMX リアルタイムモニタリングパネル ║
╠════════════════════════════════════════════════════════════════╣
║ 🎯 現在のタスク：EC モジュールのリファクタリング ║
║ 📊 全体進捗：████████░░ 78% ║
║ ⏱️ 実行時間：2h 15m ║
╠════════════════════════════════════════════════════════════════╣
║ エージェント状態 ║
║ ┌──────────────────────────────────────────────────────────┐ ║
║ │ 🟢 Agent-1 [architect] アーキテクチャ設計をレビュー中 │ ║
║ │ └─ ファイル：src/services/order.ts │ ║
║ │ └─ 操作：依存関係の分析 │ ║
║ ├──────────────────────────────────────────────────────────┤ ║
║ │ 🟢 Agent-2 [executor] コードリファクタリング中 │ ║
║ │ └─ ファイル：src/api/products.ts │ ║
║ │ └─ 進捗：15/20 関数最適化済み │ ║
║ ├──────────────────────────────────────────────────────────┤ ║
║ │ 🟡 Agent-3 [test-engineer] コード完了を待機中 │ ║
║ │ └─ 統合テストの実行を準備中 │ ║
║ └──────────────────────────────────────────────────────────┘ ║
╠════════════════════════════════════════════════════════════════╣
║ 📈 統計データ ║
║ ├─ ファイル変更：23 個 ║
║ ├─ コード行数：+487 / -312 ║
║ ├─ テストパス：156 / 160 ║
║ └─ API 呼び出し：1,247 回 ║
╠════════════════════════════════════════════════════════════════╣
║ 📝 最近のログ ║
║ [15:42:18] Agent-2: ProductService のリファクタ完了 ║
║ [15:41:55] Agent-1: 循環依存を発見、再設計を推奨 ║
║ [15:40:32] Agent-3: 単体テストカバレッジ 85% に到達 ║
╚════════════════════════════════════════════════════════════════╝
'q' で終了 | 'r' で更新 | 't' でチームビューへ切り替え多くの開発者が AI によるプログラミング支援に慎重になるのは、AI が弱いからではなく、制御不能になることを恐れるからです。
コードを誤って修正されること、要件を誤解されること、問題が起きた際に原因箇所の特定が困難になることを懸念しているのです。
OMX はこの点で強力な保証を提供します。すべてのインタビュー記録、計画ドキュメント、実行ログが永続化され、いつでも遡って確認可能です。
ある決定に問題が生じても、なぜその選択をしたのか、誰が承認したのか、実行中に何があったのかが明確に分かります。
さらに team モードの worktree 分離機能により、各エージェントは独立した git worktree で作業するため、互いに汚染されることはありません。万が一問題が起きても、迅速なロールバックが可能です。
🔒 セキュリティ保証メカニズム
1️⃣ Git Worktree による分離
main/ ← メインブランチ（保護対象）
├── .git/worktrees/
│ ├── agent-1/ ← Agent-1 の独立作業領域
│ ├── agent-2/ ← Agent-2 の独立作業領域
│ └── agent-3/ ← Agent-3 の独立作業領域
✅ 相互干渉なし ✅ 独立コミット ✅ 迅速なロールバック
2️⃣ 完全な監査ログ
.omx/logs/audit.log
├── [2026-04-05 15:30] Agent-2 が auth.ts を修正
├── [2026-04-05 15:32] npm test を実行 (終了コード：0)
├── [2026-04-05 15:35] "feat: add JWT auth" をコミット
└── [2026-04-05 15:37] main ブランチへマージ
3️⃣ 決定の追跡可能性
すべての重要な決定を記録：
- 💡 決定内容：なぜ JWT を選択したのか？
- 👤 承認者：ユーザーが $ralplan で確認
- ⏰ タイムスタンプ：2026-04-05 14:25:33
- 📄 影響範囲：auth.ts, middleware/auth.ts
4️⃣ 障害からの迅速な復旧
$ omx team rollback <team-name> --to-commit abc123
✅ すべてのエージェント作業ツリーを安全な状態へロールバック完了ワンクリック起動、开箱即用（インストールしてすぐ使用可能）
デプロイと使用は非常に簡単で、グローバルインストール後、1 行のコマンドで実行可能です。
npm install -g @openai/codex oh-my-codex
omx setup
omx --madmax --highその後は、Codex セッション内で標準ワークフローを使用してタスクを推進します。
$deep-interview "要件と境界の明確化"
$ralplan "実装計画とトレードオフの承認"
$ralph "完了するまで継続的に実行"
$team 3:executor "複雑なタスクの並列実行"プロジェクトでは詳細な構成要件も示しています。Node.js 20 以降、macOS/Linux では tmux、Windows では psmux が必要です。これらは標準的な環境であり、ほとんどの開発者がすぐに着手可能です。
📋 構成要件リスト
必須環境：
✅ Node.js >= 20
✅ Codex CLI (npm install -g @openai/codex)
✅ OpenAI API Key
チームモードの追加要件：
🍎 macOS → brew install tmux
🐧 Linux → sudo apt install tmux
🪟 Windows → winget install psmux
🐧 WSL2 → sudo apt install tmux
推奨構成：
- メモリ：4GB 以上
- ディスク：2GB の空き容量
- ネットワーク：安定した API 接続
ワンクリック検証：
$ omx doctor
[OK] Codex CLI: installed ✅
[OK] Node.js: v20+ ✅
[OK] Prompts: 30 installed ✅
[OK] Skills: 40 installed ✅
[OK] MCP Servers: configured ✅
結果：9 合格、警告 0、失敗 0最後に
現在の AI プログラミングアシスタント界隈において、ワークフロー、記憶、協業の機能を开箱即用（インストールしてすぐ使用可能）な形で提供しているプロジェクトは、本当に数えるほどです。
OMX のアプローチは明確です。Codex と覇を競うのではなく、より賢明な作業モードというレイヤーを付加するのです。
もしあなたが、すでに Codex を使ってさまざまな自動化開発に挑戦していたり、真に協業を理解し、記憶を持つ AI 開発チームを求めていたりするなら。
OMX は間違いなく試す価値があります。
単独作战からチーム協業へ。これは第一歩に過ぎません。
すべての開発者が低コストで、計画を立て、協業し、記憶する AI チームを編成できるようになれば、かつて数人がかりで 1 週間かかっていた要件が、たった 1 人で 1 日で納品できる日が来るかもしれません。
将来の競争力とは、どれだけ多くのコードを書けるかではなく、どれだけ多くの知的協業リソースを動員できるかにかかっているのです。
GitHub プロジェクトページ：https://github.com/Yeachan-Heo/oh-my-codex
本日の共有は以上となります。お時間をいただきありがとうございました。また次回お会いしましょう！