Oh My Codexの使い方｜Codex CLI拡張の特徴と導入の注意点

Oh My Codexとは何か

Oh My Codexは、OpenAIのCodex CLIを中心に使う人へ、依頼の分け方や作業の見通しを加えるオープンソースの拡張です。コードを読んだり、ファイルを編集したり、端末の道具を呼び出したりする中心部分はCodex CLIが担当し、Oh My Codexはその周りにプロジェクトの案内、役割ごとの作業、進み具合の確認を置きます。単独で使う新しいモデルではなく、すでに使えるCodexを日々の作業に合わせて整えるもの、と考えると理解しやすいでしょう。

Oh My Codexの公式ドキュメントでは、Codex CLIを実行部分として使うこと、作業を分ける仕組み、設定範囲、診断コマンドが説明されています。製品名が似た別リポジトリや派生版も見つかるため、導入先を決めるときは検索結果の説明だけでなく、公式ドキュメントとそこから案内されるパッケージを照合してください。

Oh My Codexを足しても、Codexのモデル、ログイン状態、利用中のプラン、作業フォルダーの権限が別のものに変わるわけではありません。Codex CLIが正しく動くことが前提であり、拡張を入れれば認証や実行環境の問題まで消えるわけではないのです。OpenAIのCodex CLI公式案内も、端末からコードを調べ、変更し、実行する道具としてCodex CLIを説明しています。

Codex CLIとの役割分担

Codex CLIは、プロジェクトを読み、必要な変更を考え、ファイルを編集し、確認用のコマンドを実行する入口です。Oh My Codexは、その入口へ渡す依頼を整理し、複数の作業を別々に扱い、同じ基準で結果を読むための補助を担います。たとえば、画面の修正とデータ処理の調査を別の依頼に分け、最後に人が差分を比べるという進め方ができます。

この分担を理解していないと、Oh My Codexがすべての問題を解決するように期待してしまいます。実際には、対象フォルダーが違う、Codex CLIの版が古い、ログインが切れている、端末の道具が不足している、といった問題は基礎側で直す必要があります。まず素のCodexで小さな読み取りを試し、その結果を確認してからOh My Codexを加えると、どこで問題が起きたのかを追いやすくなります。

「拡張」と「別のAI」の違い

新しいモデルを選ぶ話と、作業の整理を加える話は分けて考えます。モデルは文章やコードを考える能力、Codex CLIはローカルのプロジェクトを扱う入口、Oh My Codexは依頼の組み立てと作業の見通しを補う層です。役割が違うので、Oh My Codexの導入だけで回答の正しさが保証されるわけではありません。

また、作業を分けるほど確認する結果も増えます。担当を増やすこと自体に価値があるのではなく、互いに干渉しない調査や修正を並べられるときに効果が出ます。小さな変更を一つだけ任せる場合や、完成したコードを短く確認したい場合は、Codex CLIだけの方が分かりやすいこともあります。

なぜ今、Oh My Codexを調べるのか

2026年9月14日時点でOh My Codexを確認する理由は、拡張側だけでなく、土台となるCodex CLIの更新も速いからです。OpenAI Codexの公式リリース一覧では、0.155.0-alpha.3.10が2026年9月11日15時52分UTCに公開されています。日本時間では9月12日0時52分に当たり、その前後にも複数のアルファ版が並びます。これは安定版の機能一覧ではなく、検証途中の版が短い間隔で公開されているという事実です。

さらにOpenAIは9月8日の公式事例で、GPT-5.6 SolをCodexにつなぎ、研究用ソフトウェアで測定、結果の分析、次に試す内容の選択を支援した例を紹介しました。ここで重要なのは、AIが人の判断を完全に置き換えたという主張ではありません。決められた手順を長く進められる場面と、信号が曖昧で人の助言が必要な場面を分けて説明している点です。

このように、Codexが一回の質問への回答から、複数の確認を含む長い作業へ広がるほど、依頼を整理する層にも目が向きます。Oh My Codexはその流れに合う一方、Codex本体の版が変われば、連携する部分の挙動も確かめなければなりません。新機能の数だけを見て導入を決めるのではなく、土台の版、対応OS、戻し方を先に確認することが大切です。

版番号と拡張の相性を分けて確認する

公式リリース欄に新しい番号があっても、それだけでOh My Codexとの組み合わせが保証されるわけではありません。アルファ版は公開事実と版番号を記録し、変更内容が十分に説明されているか、日常の作業に関係するかを分けて読みます。安定した環境を優先する場合は、先行版を試す場所を普段のプロジェクトと分け、変更前の状態を残しておくと安心です。

公式ドキュメントの更新も同じように読みます。2026年9月3日公開のv0.21.4では、終了済みの作業を再び起こす挙動を抑え、長い応答を端末の履歴に残しやすくする修正が案内されています。インストール方法、対応するNode.jsの版、OSごとの注意書き、Codex CLIとの組み合わせが変わっていないかを、導入前と更新後に確認します。版番号が新しいからといって、Windowsでの制約や端末の違いまでなくなるわけではありません。

対応環境を先に判定する

Oh My Codexは、入れるコマンドだけを覚えれば終わる道具ではありません。Codex CLI、Node.js、端末、プロジェクトの場所が一つの環境としてそろっている必要があります。公式ドキュメントの要件を先に照合し、使いたい機能が自分のOSで十分に確認されているかを見てから導入します。次の表は、最初に確認する項目を短くまとめたものです。

上のどれか一つでも曖昧なら、まずCodex CLIだけを起動して、プロジェクトの説明を求める読み取り中心の依頼を試します。基礎の動作が確認できれば、Oh My Codexを追加した後の変化も比べやすくなります。

macOS / Linuxで始める場合

公式ドキュメントが推奨しているのはmacOS/Linuxです。Node.js 20以上とCodex CLIを用意し、Codexが対象プロジェクトで動くことを確かめてから、Oh My Codexを追加します。複数の作業を端末上で扱う場合はtmuxが案内されていますが、最初から複数の画面を使う必要はありません。まず一つの作業を最後まで確認し、必要になった段階で分ける方が失敗を見つけやすいでしょう。

シェルの種類やパスの扱いは、同じmacOS/Linuxでも利用者の設定で変わります。インストール後にコマンドが見つからないときは、Oh My Codexの機能を疑う前に、npmのグローバルコマンドが現在の端末から見えるか、Codex CLIを単体で呼べるかを確認します。端末を開き直して状態が変わる場合もあるため、実行した場所と版を記録しておきます。

Windowsで始める場合

Oh My Codexの公式ドキュメントは、ネイティブWindowsとCodexアプリを既定の体験として扱わず、macOS/Linuxを主な対象にしています。Windowsで基本的なコマンドが動く場合でも、複数作業の表示や端末の切り替えで差が出る可能性があります。Windowsだけで完結させたい場合は、最初に単一の小さなプロジェクトで、インストール、ログイン確認、読み取り、差分確認の順を試してください。

複数作業を含む使い方をWindowsで試すなら、公式ドキュメントにあるpsmuxの案内を確認し、対応が十分でない部分を前提にします。別の選択肢としてWSL2を使う方法もありますが、OSをまたぐとファイルパス、Node.js、Codexのログイン先が別になることがあります。Windows側で通った設定がそのままWSL2側へ移ると決めつけず、各環境で版とログイン状態を確認しましょう。

導入手順

インストールは、Codex CLIの確認、Oh My Codexの追加、プロジェクト範囲の選択、診断、最初の小さな依頼という順に進めます。既存プロジェクトの指示ファイルをいきなり書き換えるのではなく、何が変わるかを読める状態にしておくことが重要です。公式ドキュメントの手順を現在の環境へ合わせるときも、以下の順番を崩さないでください。

1. まずCodex CLIの版とログイン状態を確認します。

   codex --version
   codex login status
   

   codexが見つからない、またはログイン状態を確認できない場合は、Oh My Codexを先に入れず、Codex CLI側を整えます。OpenAIのクイックスタートでも、プロジェクトの場所でCodexを起動し、サインインしてから最初の依頼を出す流れが案内されています。

2. Oh My Codexをnpmから追加します。

   npm install -g oh-my-codex
   

   Codex CLIもnpmで管理する場合は、公式パッケージとOh My Codexを別々に扱います。すでにHomebrewなどがcodexを管理している端末へ、同じ名前の実行ファイルをnpmから重ねて入れると衝突することがあります。いまどの方法でCodexを入れているかを確認し、複数の導入方法を混ぜないのが安全です。

3. プロジェクト単位で使うか、利用者単位で使うかを選びます。

   omx setup --scope project --merge-agents
   

   プロジェクト単位の設定は、そのフォルダーで作業するときだけ有効にしたい案内を置く方法です。既存のAGENTS.mdがある場合は、追加された範囲と元の指示が混ざっていないかを必ず読みます。全体へ影響する場所から始めるのではなく、対象プロジェクトの中で試す方が、思わぬ設定の広がりを抑えられます。

4. 診断を実行し、必要なら実際の依頼まで確認します。

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

   omx doctorはファイルや前提条件の形を確認しますが、実際のCodexへの依頼が通ることまで同じ意味ではありません。公式ドキュメントも、診断が通った後に、現在の端末から実際の実行を試す手順を示しています。返答が違う場合は、版、ログイン状態、対象フォルダーを分けて確認します。

5. 最初の作業は読み取り中心にします。

   このプロジェクトの構成と起動方法を読み取り、変更はせずに説明してください。
   関係するファイル、確認できたこと、まだ分からないことを分けてください。
   

   いきなり大きな修正を依頼せず、返ってきた説明と実際のファイルを比べます。問題がなければ、次の依頼で対象を一つの画面や関数に絞り、変更後にどの確認を行うかを指定します。

npmで管理しているCodexを確認する

Oh My Codexの導入で大切なのは、パッケージの追加よりも、現在呼ばれているcodexがどの場所のものかを把握することです。Homebrew、npm、別の配布方法を同じ端末で使うと、更新した版と実際に呼ばれる版がずれることがあります。codex --versionの結果と、導入に使った方法を一緒に記録し、更新後にもう一度照合しましょう。

Codex CLIをまだ入れていない場合は、公式ドキュメントが示すとおり、@openai/codexを先に単独で入れてからOh My Codexを追加します。反対に、すでに別の方法でCodexが動いているなら、動作するものを無理にnpm版へ置き換える必要はありません。土台を固定してから拡張だけを更新すると、変化の原因を追いやすくなります。

既存のAGENTS.mdを扱う

AGENTS.mdは、プロジェクトの構成、確認方法、守るべき方針をCodexへ伝えるテキストです。Oh My Codexの案内を追加する場合も、既存の説明を消して一つにまとめるのではなく、どの行が元からあり、どの行が追加されたかを確認します。プロジェクト固有の指示と、利用者全体へ適用する指示を混ぜないことが、別の作業で予想外の判断を避けるポイントです。

導入直後に挙動が変わったら、AGENTS.mdと設定範囲を読むところから始めます。Codexが見ているフォルダーと、Oh My Codexが案内を置いたフォルダーが違う場合、指示が届かない、または広く届きすぎることがあります。ファイルを変更する前に内容を保存し、必要なら設定を一つずつ戻して差分を確認してください。

日々の使い方

Oh My Codexを入れた後も、仕事の頼み方の基本は変わりません。目的、対象、触らない範囲、完了条件、確認方法を短く伝え、まず調査の結果を読んでから変更へ進みます。拡張は依頼の整理を助けますが、曖昧な目的を自動的に正しく解釈するものではありません。人が判断する場所を先に決めておくと、作業が長くなっても結果を追いやすくなります。

一つの依頼に多くを詰め込まず、独立した仕事だけを分けます。画面の見た目を調べる作業と、データ取得の原因を調べる作業は、同じプロジェクトでも確認方法が違います。一方、同じ設定ファイルや同じ関数を複数の作業が触ると、どの変更が必要だったのか分かりにくくなります。分けた後の統合と確認を誰が行うかも、開始前に決めておきましょう。

結果を受け取ったら、変更ファイル、確認したコマンド、通った確認、実施できなかった確認、残る注意点を分けて読みます。成功したという文章だけで判断せず、実際の差分と出力を見ます。OpenAIのCodex CLI案内でも、変更を確認するためのレビュー機能や、作業を分ける機能が紹介されています。機能の名前より、結果を検査できるかを基準に使いましょう。

最初の依頼を小さくする

初回は「プロジェクトを説明する」「原因候補を三つに分ける」「一つのテストを追加する」など、終わりを判断しやすい依頼を選びます。次のように、変更前の調査と完了条件を一つの文章へ入れると、返答を読みやすくなります。

目的: 商品一覧で読み込みに失敗したときの表示を分かりやすくする
対象: 商品一覧の表示処理と、その画面に関係する確認処理
最初にすること: 変更せず、原因候補と関係するファイルを説明する
完了条件: 変更案、確認方法、触らない場所が分かる

この段階で説明が不十分なら、変更を許可せず、対象や確認方法を補います。最初から成果物を大きくするより、依頼と結果の対応を確かめる方が、Oh My Codexの作業分けを安全に使い始められます。

独立した作業だけを分ける

複数の役割を使う場合は、調査対象と出力形式をそれぞれ固定します。たとえば一つは既存コードの読み取り、もう一つはテストケースの候補整理というように、互いの結果を待たずに進められる仕事を選びます。同じファイルを触る二つの作業を同時に始めると、変更の順番や採用する案を人が判断しにくくなるため、最後にまとめる仕事として扱いましょう。

作業名にも目的を入れると一覧を読んだときに迷いません。「画面の調査」「入力値の確認」「テスト候補」のように短く名付け、終わったら結果と未確認点を残します。数を増やすことより、各作業を単独で読めること、不要になった作業を止められることを優先します。

Windowsで使うときの注意点

Windows利用者が最初に覚えておきたいのは、Oh My CodexがWindowsを主な推奨対象として説明していないことです。公式ドキュメントには、ネイティブWindowsとCodexアプリは既定の経路ではなく、現在は対応が薄いという注意書きがあります。Windowsで動く例があっても、macOS/Linuxと同じ動作を保証する記述ではありません。導入の可否は、必要な機能を小さなプロジェクトで実際に確認して判断します。

Windowsで問題が出たときは、まずOh My CodexとCodex CLIを分けて調べます。codex --version、codex login status、単純な読み取り依頼の順に実行し、Codex単体が動くかを見ます。単体が動いてからomx doctorを確認すれば、パッケージの導入、端末のパス、ログイン、プロジェクトの指示のどこに差があるかを絞れます。

ネイティブWindowsで試す範囲

まずは一つのフォルダーで、版の確認、ログイン状態の確認、読み取り、変更、差分確認を一周させます。複数の端末画面や役割を使う機能は後回しにし、Codexの結果を人が読めるかを先に確かめます。公式ドキュメントにあるpsmuxを使う場合も、導入した版と端末の種類を記録し、複数作業が止まったときに基礎側へ戻れるようにします。

Windows固有のパス、PowerShellの挙動、npmのコマンド検索先が原因になることもあります。エラーメッセージだけで拡張の不具合と決めつけず、同じプロジェクトをCodex CLI単体で開き、同じ依頼が通るかを比べてください。認証情報や内部の設定内容を公開場所へ貼らず、必要な情報は版番号と再現条件に絞って記録します。

WSL2を使う場合

WSL2へ移すと、Linux向けの案内に近い環境を用意できますが、Windows側と同じ環境になるわけではありません。Node.js、Codex CLI、Oh My Codex、プロジェクトのパス、ログイン状態をWSL2側で確認します。Windowsのエディタから開いたフォルダーと、WSL2の端末で開いたフォルダーが同じ内容を指しているかも確かめましょう。

移行の判断は、使いたい機能と確認しやすさで決めます。単一作業がネイティブWindowsで問題なく進むなら、無理に構成を変える必要はありません。複数作業の端末表示やLinux向けの案内を使いたいなら、WSL2を別環境として小さく試し、結果を比べてから普段の場所を決めるのが安全です。

Codex・Cursor・GitHub Copilotとの使い分け

Oh My CodexはCodex CLIを中心に使う人向けの拡張なので、CursorやGitHub Copilotと同じ種類の製品として単純比較するものではありません。Codex CLIは端末でプロジェクトを調べ、編集し、確認する流れに向きます。Cursorはエディタの中でコードとAIの対話を続けたい人向けで、GitHub Copilotは既存のエディタやGitHubの開発画面へAI機能を足したい人に向きます。詳しい提供範囲はCursor公式とGitHub Copilot公式で確認できます。

料金、対応モデル、保存場所、組織の利用方針はそれぞれ違います。Oh My Codexを入れるかどうかは、機能の多さではなく、普段の作業場所と確認方法に合うかで決めます。Codex CLIをすでに使い、同じ種類の依頼を複数に分けたいなら試す価値がありますが、エディタの中で完結したい人には別の道具が自然なこともあります。

ターミナル中心ならCodexを軸にする

端末でリポジトリを読み、変更をまとめ、確認用のコマンドまで同じ場所で扱う人は、Codex CLIとOh My Codexの組み合わせを検討しやすいでしょう。特に、調査、テスト候補の整理、修正案の比較など、独立した仕事を分けたい場合に整理の効果が出ます。ただし、分けた結果を読む時間も必要なので、短い作業まで複数にしないことが大切です。

IDE中心ならCursorやCopilotも比べる

コードを編集している画面の横で提案を受けたい、入力中の補完を重視したい、GitHub上の変更と一緒に確認したいという人は、CursorやGitHub Copilotの方が導入しやすい場合があります。現在のエディタ、拡張機能、チームの確認方法を保てるかを見て、同じ小さな課題をそれぞれで試します。名前の印象ではなく、変更前後を比べられるかで選ぶと判断が安定します。

うまく動かないときの切り分け

Oh My Codexの不調に見えても、実際にはCodex CLI、Node.js、npmのコマンド検索先、ログイン、プロジェクトの指示のどこかが原因かもしれません。いきなり再インストールを繰り返すのではなく、確認できる範囲を一層ずつ狭めます。エラーが出た時刻、実行した場所、版番号、再現する依頼を残しておくと、同じ問題を何度も説明せずに済みます。

1. omxが見つからない場合は、npmのグローバルインストール先が現在の端末の検索先に入っているかを確認します。端末を開き直し、omx --versionが通るかを見ます。
2. omx doctorが失敗する場合は、Node.jsの版、Codex CLIの有無、プロジェクトの場所、既存のAGENTS.mdを順に読みます。診断が示した項目を一つずつ直し、まとめて複数の設定を変えないようにします。
3. omx doctorは通るのに依頼が失敗する場合は、codex login statusとCodex単体の読み取り依頼を試します。拡張の問題か、ログインやモデルへの接続の問題かを分けるためです。
4. 更新後に挙動が変わった場合は、Codex CLIとOh My Codexの両方の版を記録し、直前の変更と公式ドキュメントを照合します。先行版を試した場合は、安定した版の環境と混ぜずに結果を比べます。

コマンドが見つからない

WindowsでもmacOS/Linuxでも、npmで追加したコマンドがすぐに見えないことがあります。npm自体がどのNode.jsに付属しているか、グローバルパッケージの場所がどこか、現在の端末がその場所を検索しているかを確認します。複数のNode.js管理方法を使っている場合は、インストールした端末と実行している端末が同じ版を見ているかを照合してください。

コマンドが見えるようになった後も、codex --versionとomx doctorを続けて確認します。Oh My Codexだけが見つかっても、Codex CLIが別の場所にある、またはログイン状態が異なるなら実際の依頼は進みません。二つの版番号と実行場所を一組で記録するのがポイントです。

設定と版が合わない

拡張を更新した後、作業の分け方や表示が以前と違うときは、まずプロジェクトのAGENTS.mdと設定範囲を確認します。次にCodex CLIの版、Node.jsの版、Oh My Codexの版を一つずつ照合します。複数を同時に更新していると原因が見えにくいため、次回からは一つずつ更新し、同じ小さな依頼で結果を比べます。

戻す必要がある場合に備え、変更前のファイルと版番号を残します。設定ファイルを手で消して解決しようとせず、公式ドキュメントの削除や更新の案内を確認してから、対象を限定して戻します。認証情報を含むファイルを共有せず、公開できる範囲の診断結果だけを使って相談することも忘れないでください。

使うべき人と見送る人

Oh My Codexは、Codex CLIをすでに使っていて、複数の開発作業を同じ基準で整理したい人に向いています。何を任せたか、どのファイルが変わったか、どの確認が済んだかを毎回読める形にしたい場合は、補助層を追加する意味があります。反対に、まだCodex CLIの単体動作を確認していない人や、一回だけ短い質問をしたい人は、先に基礎の使い方を覚える方が近道です。

対応OSも選定条件です。公式ドキュメントがmacOS/Linuxを推奨しているため、ネイティブWindowsで複数作業を主な目的にする場合は、機能が必要な範囲で動くかを先に試します。会社やチームで使うなら、追加された設定を誰が読み、作業結果を誰が確認するかまで決めてから導入します。道具を入れることが目的にならないよう、解決したい手作業を一つに絞りましょう。

向くケース

端末で開発し、同じ種類の調査や修正を何度も行う人には試しやすい道具です。画面修正、テスト候補の整理、コードの読み取りのように、互いに独立した作業を分け、最後に人が確認する流れを作りたい場合に合います。プロジェクトの指示を文章で残し、作業の結果を後から読み返したい人にもメリットがあります。

見送るケース

Codex CLIをまだ使ったことがなく、Node.jsや端末の準備から始める段階なら、まず公式のCodex CLIクイックスタートを終える方が安全です。単一ファイルの短い修正だけなら、追加の役割や確認画面はかえって負担になります。ネイティブWindowsで公式の注意範囲を超える機能が必要な場合も、別の道具やWSL2を比較してから決めましょう。

まとめ

Oh My Codexは、Codex CLIを別のAIへ置き換える製品ではなく、作業の分け方、プロジェクトの案内、結果の読み方を整える拡張です。公式ドキュメントを導入先の基準にし、まずCodex CLI単体の版とログイン状態を確認してから、Node.jsの条件とOSの注意書きを照合します。

2026年9月はCodexのアルファ版が短い間隔で公開され、OpenAIの公式事例でもCodexを長い研究作業へつなぐ利用が紹介されています。新しい番号や機能の多さだけで判断せず、Oh My CodexとCodex CLIの版を分けて記録し、対応環境と変更前の状態を確認してください。

導入後は、小さな読み取りから始め、独立した仕事だけを分け、同じファイルを同時に触らないようにします。最後に差分、確認結果、未確認点を人が読むことまで含めて一つの作業と考えれば、Oh My Codexを便利さと慎重さの両方を保ちながら使い始められます。