Codex npm版の確認方法｜安定版とalpha版の違い・戻し方

Codex npm versionで確認する対象

「Codex npm version」という検索語で知りたいのは、単純にnpmの数字だけではありません。Codex CLIは端末からコードを読み、変更し、コマンドを実行するコーディングエージェントで、公式リポジトリはnpmによる導入とGitHub Releasesからの配布を別の入口として案内しています。したがって、npmに残るパッケージ情報と、現在のPATHから起動する実行ファイルが同じ版を指すとは限りません。まず確認対象を三つに分けると、更新後に「入れたはずなのに古い」という混乱を避けられます（出典: OpenAI Codex公式リポジトリ）。

npmパッケージ版は導入経路の記録

@openai/codexはnpm上の配布名です。npm listで見える数字は、指定したnpmの場所に登録されているパッケージ版を示します。これは「どの配布物を入れたか」を記録するには便利ですが、別の方法で配置された実行ファイルの版を直接証明するものではありません。公式リポジトリでも、npm、Homebrew、プラットフォーム別のリリース配布物が案内されているため、入口を最初に確認する必要があります。

グローバルに入れた場合はnpm list -g --depth=0 @openai/codexを使い、プロジェクト内に入れた場合は対象フォルダでnpm list @openai/codexを使います。(empty)と表示されてもCodexが使えないとは限らず、インストーラや別の配布物をPATHに置いている可能性があります。表示された版と導入場所を、確認した日時とともに記録しておくと次の切り分けが楽になります。

CLI版は実際に起動した実体

最終的に作業で使われる版を知りたいなら、codex --versionを優先します。このコマンドはnpmの一覧ではなく、現在の端末がcodexという名前で見つけた実行ファイルに問い合わせます。複数の導入経路を試したことがある環境では、パッケージ一覧が新しくても、PATHの先頭にある古い実体が起動することがあります。

WindowsではGet-Command codexまたはwhere.exe codex、macOSやLinuxではcommand -v codexを使うと、どの場所のファイルを呼び出しているかを確認できます。codex --versionの結果と場所が想定と違う場合は、別の版を追加で入れる前に、不要な候補をPATHから外すか、現在の導入方法を一つに決めます。数字を合わせることより、起動対象を特定することが先です。

モデル名はCLI versionとは別

Codexの画面に表示されるモデル名や推論の設定は、CLIの版番号とは違う情報です。CLIが同じ版でも、利用する入口、契約している範囲、選択したモデルによって表示内容が変わることがあります。公式のCLIドキュメントでも、/statusで現在のセッション設定を確認し、/modelでモデルと推論の設定を選ぶ流れが案内されています（出典: Codex CLI公式ドキュメント）。

そのため、問い合わせや不具合の記録には「CLI 0.147.0」「モデル名」「推論設定」「OS」のように項目を分けて残します。「GPTの数字が新しいからCLIも新しい」とは限らず、逆にCLIを更新してもモデル名が同じこともあります。版番号は配布物の確認、モデル名は作業条件の確認、と役割を分けて読むのが基本です。

2026年8月16日に版を見直す理由

Codex CLIは安定版と先行版が並んで公開されるため、検索結果の更新日だけでは現在の基準を判断しにくい状態です。2026年8月7日には公式リポジトリで0.147.0が通常リリースとして公開され、その後8月14日に0.148.0-alpha.15が先行版として追加されました。直近の先行版を見つけたときに、すぐ安定版と置き換えるのではなく、公開区分と自分の導入経路を照合することが重要です。

この日付で確認する価値があるのは、既存記事や検索スニペットに古い版番号が残りやすいからです。公式ページには公開日、Pre-releaseの表示、版ごとの配布物が載っています。版の差を説明するときは、ブログの記述よりも、まず該当する公式リリースページと手元のcodex --versionを同じ日に照らし合わせます。

0.147.0は通常利用の基準、0.148.0-alpha.15は先行版

公式リリースページでは、0.147.0が通常のリリースとして扱われ、0.148.0-alpha.15にはPre-releaseが表示されています。alphaという名前は、次の変更を早く確認できる版であることを示しますが、日常利用での互換性や安定性が通常版を上回るという意味ではありません。数字が一つ進んでいることと、使うべき版であることを分けて考えます（出典: 0.147.0公式リリース、0.148.0-alpha.15公式リリース）。

先行版を試す理由がある場合も、普段使いの環境でいきなり置き換えず、版番号をメモしてから小さな確認用のフォルダで起動します。起動、ファイルの読み取り、変更の表示、テストの実行、終了後の再開という一連の動きを確認し、問題が出たときにどの版へ戻すかを決めておきます。リリースページに書かれていない性能差や機能差を、版番号だけから補わないことも大切です。

npmのlatestとGitHub Releasesは同じ列ではない

2026年8月16日にnpmの公開情報で確認できるlatestは0.147.0でした。一方、GitHubにはそれより新しい0.148.0-alpha.15が先行版として公開されています。npm install -g @openai/codexのように版を指定しない導入では、npm側のlatestを基準に考えるため、GitHubで先行版を見つけただけでnpmからその版が入るとは限りません（出典: @openai/codexのnpm公式ページ）。

先行版がnpmにも公開されているかを確かめたいときは、npm view @openai/codex versions --jsonやnpm view @openai/codex dist-tags --jsonを実行します。対象の版やタグが返らなければ、npmの導入コマンドを繰り返しても目的の先行版にはなりません。GitHubのリリースページにある配布物を使う場合は、OSとCPUに合うものを選び、実行後に必ずcodex --versionで確認します。

Codex npm versionを確認する手順

版を調べるときは、手元の登録情報、起動する実体、公開されている基準、作業中のモデルの順番で見ます。順序を入れ替えると、公開側の数字だけを見て更新したつもりになったり、モデル名をCLI版と誤認したりしやすくなります。次の確認は、更新前の記録を残すときにも、更新後に差を比較するときにも使えます。

1. npmで導入した版をnpm list -g --depth=0 @openai/codexで確認する。
2. 実際に起動するCLIをcodex --versionで確認する。
3. WindowsではGet-Command codexとwhere.exe codex、macOSやLinuxではcommand -v codexで場所を確認する。
4. npm公開側の基準をnpm view @openai/codex versionで確認し、公式リリースページの通常版・先行版と照合する。
5. Codex内で/statusを開き、CLI版とは別の欄にモデル名と推論設定を記録する。

Step 1: npmパッケージ版を確認する

最初にnpm list -g --depth=0 @openai/codexを実行し、npmのグローバル領域に登録された版を調べます。表示が@openai/codex@0.147.0のようになれば、その領域にあるパッケージ版は確認できました。プロジェクトごとに導入している場合は、該当フォルダでnpm list @openai/codex --depth=0を実行します。

ここで確認するのは「npmが管理している登録情報」です。codexコマンドが別の場所から見つかる場合、表示された版と実行版が一致しないことがあります。コマンドの結果だけを保存するのではなく、グローバルかローカルか、npm prefix -gが示す場所、確認時刻も一緒に残すと、後の比較で判断しやすくなります。

Step 2: 実行するCodex CLIの版を確認する

次にcodex --versionを実行します。これは、現在のPATH解決で実際に呼び出されるCLIが返す版です。npmで新しいパッケージを入れたのにここが変わらない場合は、古い実行ファイルが先に見つかっている、別の端末を見ている、シェルが以前の場所を保持している、といった可能性があります。

WindowsではGet-Command codex | Format-List Source,Versionで場所と表示上の版を確認し、where.exe codexで候補が複数ないかを見ます。macOSやLinuxではcommand -v codexとls -lで場所を照合します。複数の候補があるなら、まず先頭の一つを特定してから、どの導入方法を残すか判断します。

Step 3: npmが公開する版を照合する

公開側のlatestを知るにはnpm view @openai/codex versionを使います。この結果は自分の端末に入っている版ではなく、npmの公開情報です。手元のnpm listと同じ数字なら、少なくともnpmの登録情報と公開側の基準は一致しています。数字が違う場合は、更新前か、別のnpm領域を見ているか、先行版を使っている可能性を調べます。

先行版の存在を確認するときは、npm view @openai/codex versions --jsonで公開されている全版を確認し、npm view @openai/codex dist-tags --jsonでlatest以外のタグも読みます。表示された版がリリースページにある版と同じでも、配布経路が同じとは限りません。版番号、タグ、取得元URLを分けて記録すると、再現条件を説明しやすくなります。

Step 4: モデルと推論設定を別に残す

Codexを起動したら/statusを開き、モデル名、推論設定、対象フォルダなどを確認します。モデル名はCLIの版ではないため、0.147.0という記録の隣に同じ種類の情報として書くのではなく、別の欄に分けます。モデルを変更した場合も、CLIを再導入した場合も、それぞれの変更として記録できます。

問い合わせ時には「CLIの版」「モデル」「推論設定」「OS」「導入経路」の五つを並べると、状況が伝わりやすくなります。公式CLIドキュメントにも、セッションの状態を/statusで確認する入口が示されています。数字を一つにまとめて「Codexの版」と呼ばないことが、最初の誤解を減らします（出典: Codex CLI公式ドキュメント）。

安定版とalpha版の選び方

安定版とalpha版のどちらを選ぶかは、数字の大きさではなく、作業を止めずに続けたいか、直近の変更を先に確かめたいかで決めます。日常のコード変更やレビューを同じ条件で続けるなら、公式の通常リリースを基準にします。新しい表示や修正を検証したいなら、現在の版を記録し、対象を限定した環境で先行版を試します。どちらの場合も、更新前後に同じ確認コマンドを実行することが重要です。 版の選択を迷ったら、まず通常版へ戻せるか、確認対象を限定できるか、結果を比較できるかを先に決めます。

安定版を日常の基準にする

通常の開発で予測しやすさを優先するなら、2026年8月16日時点の基準は0.147.0です。版を固定して確認したい場合は、npm view @openai/codex versionで公開側を調べたうえで、必要に応じてnpm install -g @openai/codex@0.147.0のように明示します。更新前にcodex --versionと実行場所を残しておけば、更新後の差も追えます。

版を固定することは、常に固定し続けなければならないという意味ではありません。次に通常版が公開されたら公式リリースページで変更を読み、手元で確認する版を決めてから更新します。チームで同じ結果を再現したい場合は、各人のCLI版とモデル名を別々にそろえ、違いが出たときに一つずつ比較できる記録を用意します。

alpha版を確認用に分ける

0.148.0-alpha.15は公式ページで先行版と表示されるため、毎日の作業環境を置き換える基準ではなく、変更を確かめる対象として扱います。まずnpm view @openai/codex@0.148.0-alpha.15 versionを実行し、npmに同じ版が公開されているかを確認します。結果が返らない場合は、npmの版指定を繰り返さず、公式リリースページにある配布方法を読み直します。

先行版を試すときは、作業中の大切なフォルダではなく、戻しても影響が小さい確認用のフォルダから始めます。版番号、配布元、OS、モデル名を記録し、起動と基本操作を短い作業で確かめます。問題が出たときに通常版へ戻せるよう、元の導入経路と版番号を先に残しておくと、判断を急がずに済みます。

特定版を入れる前に配布元をそろえる

npmから入れたCLIをnpmで更新するなら、同じパッケージ名と同じ導入場所を使います。GitHubの配布物を使うなら、npmの一覧だけを見て更新済みと判断せず、展開した実行ファイルの場所とcodex --versionを確認します。導入経路を混ぜると、インストール成功の表示と、実際に起動する版が食い違いやすくなります。

特定版を入れる前に、現在のcodex --version、where.exe codexまたはcommand -v codex、npm prefix -gを保存します。作業後に同じ三つを再実行し、版と場所の両方が意図どおり変わったかを見ます。公式リポジトリは各プラットフォーム向けの配布物を案内しているため、自分のOSとCPUに合うファイルかどうかもリリースページで確認します（出典: OpenAI Codex公式リポジトリ）。

更新後に版が合わないときの切り分け

更新後の問題は、Codex本体の不具合とは限りません。npmのグローバル領域、PATHの検索順、開いている端末、モデルの選択が別々に変わるため、最初から再インストールを繰り返すと原因が見えにくくなります。まず更新前の記録と更新後の記録を並べ、数字、場所、導入経路、モデル名のどこが変わったかを一項目ずつ比較します。

公式リリースページにある版と手元の版が違うときも、通常版と先行版を混同していないかを確認します。安定版が古いから失敗しているとは限らず、先行版へ移ったことが原因の場合もあります。版に関する問題は、公開側の情報、実行側の情報、作業条件の情報を分けて調べると、必要な対応だけを選びやすくなります。

npmの一覧は新しいのに起動版が古い

npm list -g @openai/codexが新しい一方、codex --versionが古い場合は、PATHの先頭に別の実行ファイルがあります。Windowsならwhere.exe codex、macOSやLinuxならcommand -v codexで場所を表示し、npmのグローバル領域と一致するかを確認します。複数行が出たときは、一番上の候補が現在の端末で使われる可能性が高いため、順番と導入経路を調べます。

端末を開き直すだけで解決する場合もありますが、先に場所を記録してから行います。新しい版をさらに追加すると候補が増えるだけなので、不要な導入経路を整理し、残したい一つをPATHの先頭に置きます。整理後はcodex --versionを再実行し、npmの一覧ではなく実行側の数字が変わったことを確認します。

版は変わったのに挙動の差が分からない

CLI版が変わっても、選択中のモデルや推論設定が同じなら、すべての作業で違いが目立つとは限りません。逆に、モデルが変わっているとCLI更新の影響と混ざります。/statusの表示、codex --version、実行場所、OSを同時に記録し、同じ小さな作業で比較します。新しい版の特徴を、数字だけから推測してはいけません。

比較対象は、同じフォルダ、同じ入力、同じモデル、同じ推論設定にそろえます。確認する内容は、起動できるか、対象ファイルを正しく読めるか、変更を表示できるか、テスト結果を確認できるかに分けます。結果が同じでも異常ではなく、版番号は作業条件の一つにすぎないと理解しておくと、過度な期待や誤った切り戻しを避けられます。

先行版から通常版へ戻したい

先行版から戻すときは、まず公式リリースページで通常版を確認し、npm view @openai/codex versionでnpm側の基準も見ます。現在の導入経路がnpmなら通常版を明示して入れ直し、別の配布物ならその配布元の通常版へ戻します。作業後はcodex --versionと実行場所を再確認し、画面に残ったモデル名をCLI版と取り違えないようにします。

戻した後に設定や作業フォルダが消えると決めつける必要はありませんが、版の変更と設定の変更を同じタイミングで行わないほうが切り分けやすくなります。戻す前の版、戻した版、実行ファイルの場所、モデル名を残し、問題が再現するかを小さな作業で確かめます。公式の配布ページに記載がない方法で版を混ぜず、確認できる経路に戻すことを優先します。

Codex npm versionを記録するときの型

版確認を一度きりの作業にせず、次回も同じ情報を取れる形にしておくと、リリースが続く時期にも迷いにくくなります。記録の目的は数字を集めることではなく、どの入口から、どの版のCLIを、どのモデル条件で動かしたかを再現できるようにすることです。特に安定版と先行版が近い番号で並ぶときは、公開日と公開区分も重要な手掛かりになります。 記録の形を先に決めておけば、次の更新でも同じ項目を取り直せるため、数字の変化と環境の変化を切り分けやすくなります。

最低限残す五つの情報

最低限、確認日時、CLI版、実行ファイルの場所、導入経路、モデル名と推論設定を残します。CLI版はcodex --version、場所はWindowsならwhere.exe codex、macOSやLinuxならcommand -v codex、npmの導入版はnpm list -g --depth=0 @openai/codexで得られます。公開側の比較にはnpm view @openai/codex versionと公式リリースURLを使います。

この記録を文章だけで残す場合も、「0.147.0を使った」だけで終わらせず、「npmで導入」「Windowsのこの場所から起動」「モデルは画面表示の値」のように項目を分けます。あとから別の人が調べるとき、数字の意味が明確になります。社内やチームで共有する場合も、人の名前ではなく、版と確認事実を中心に書くと更新の差分を比べやすくなります。

公式情報を優先する読み方

版番号の最終確認は、公式リリースページ、公式リポジトリ、公式CLIドキュメントの三つを使い分けます。リリースページは公開日と通常版・先行版の区分、リポジトリは導入経路と対応環境、ドキュメントはコマンドや画面の役割を確認する場所です。npmの公開ページはパッケージ版とタグを確認するために使い、モデルの性能や利用条件まで一つの数字から推測しません。

記事や検索結果に古い版が残っていても、すぐに誤りと断定するのではなく、記載された確認日を見ます。今回のように0.147.0と0.148.0-alpha.15が同時期に見つかる場合は、公開区分を添えて書けば読者が判断できます。公式ページのURLと確認日を残すことが、版の変化が速いCodex CLIを正確に説明する近道です。

まとめ

Codex npm versionを確認するときは、npmのパッケージ版、実際に起動するCodex CLI版、Codex内で選択したモデル名を分けて調べます。npm list -g --depth=0 @openai/codexで手元の登録版を見たあと、codex --versionと実行場所を確認し、npm view @openai/codex versionと公式リリースページを照合します。モデル名と推論設定は/statusで別に記録します。

2026年8月16日時点では、0.147.0が通常利用の基準で、0.148.0-alpha.15は8月14日に公開された先行版です。先行版を試す場合も、現在の版と導入経路を残し、小さな確認から始めます。数字の大小ではなく、公開区分、起動する実体、モデル条件をそろえて読むことが、Codex CLIを安定して使い続けるための基本です。