Codex CLIの版確認と導入判断を小さく検証して安全に決める

Codex CLIが2026年8月に確認し直す理由

Codex CLIは、同じ「更新」という言葉でも、安定版の修正を取り込む場合と、公開前の版を試す場合で意味が変わります。2026年8月13日（日本時間）に公式リリースを確認すると、通常版として0.147.0、プレリリースとして0.148.0-alpha.6が見つかります。前者は8月7日、後者は8月10日に公開されています。数日単位で版が動くため、検索結果の見出しや手元の記憶だけで判断せず、公開日と版番号を同じ記録に置くことが重要です。

0.147.0の公式ノートには、プラグインカタログを検索して導入する機能、会話を区切って整理する表示、承認に関するCLIオプション、Cursorからのスキル取り込み、MCPの新しい仕様への対応が記載されています。また、Windowsのバックグラウンドプロセスやファイルパス、日本語文字の表示、見慣れない作業場所への確認を整える修正も並んでいます。すべての利用者に同じ効果が出ると断定せず、自分が使う入口に関係する項目だけを拾う読み方が適切です。出典はCodex CLI 0.147.0の公式リリースノートです。

一方、0.148.0-alpha.6のページは、プレリリースであること、8月10日の公開、配布ファイルがあることを確認するためのページです。ページ上で変更一覧が十分に示されていないなら、alpha.6という番号から新機能や互換性を補ってはいけません。導入前に知りたい差分がある場合は、同じ小さな作業を手元で行い、再現できた結果だけを採用判断に使います。出典は0.148.0-alpha.6の公式リリースです。

安定版とプレリリースを同じ候補にしない

安定版は、日常の作業を継続しながら公開済みの修正を受け取りたい人の基準です。プレリリースは、特定の修正や対応を早く確かめたい人の候補ですが、作業の途中で表示や挙動が変わる可能性を含みます。alphaを選ぶ理由が「数字が大きいから」だけなら、採用の根拠として弱いでしょう。必要な変更を一つに絞り、その変更が確認できるテストを先に決めると、期待と結果を混ぜずに済みます。

公式リリースを版番号の基準にする

公式CLI案内は、インストール、サインイン、プロジェクトでの初回作業という使い始めの流れを説明しています。一方、特定の版がいつ公開されたか、安定版かプレリリースか、変更一覧に何が書かれているかは、公式リリースページで確認します。検索結果に表示された「最新」という言葉、パッケージ管理ツールが返す表示、起動画面のモデル名は、それぞれ役割が違います。三つを一つの最新版情報として扱わないことが、最初の切り分けです。

版番号とモデル名を別々に確認する

「Codexのバージョン」を調べるときは、CLI本体、選択中のモデル、入手経路の三つを分けて記録します。CLI本体の版はコマンドや画面の構成、利用できるオプション、接続処理などに関係します。モデル名は応答の傾向や推論の選択に関係し、CLIの版番号を更新しただけで同じ番号に変わるものではありません。npmで入れた版と、Windowsの別の場所にある実行ファイルが混ざると、更新したつもりでも古い版が起動することがあります。

最初の確認は読み取り中心にします。作業中のリポジトリを変更する前に、版番号、実行ファイルの場所、起動画面のモデル名、確認した日付を一つのメモへ残してください。OpenAIの公式CLI案内でも、プロジェクトディレクトリでCodexを起動し、最初の作業を説明する流れが案内されています。ここで「何が表示されたか」を保存しておけば、更新後に挙動が変わったとき、版の差なのかモデルの差なのかを追いやすくなります。

確認の順番は次のとおりです。

1. codex --version を実行し、codex-cli 0.147.0 のような出力をそのまま記録する。表示がない場合は、コマンドの場所と終了メッセージも残す。
2. where.exe codex または Get-Command codex を使い、実際に呼び出されているファイルの場所を確認する。複数の場所が返るなら、先にどれを使うかを決める。
3. codex をプロジェクトの複製や読み取り用の場所から起動し、画面に出るモデル名と作業場所を別欄へ写す。モデルの名前をCLI版の欄へ書き込まない。
4. OpenAIの公式リリースページで、安定版またはプレリリースのタグ、公開日、変更一覧を照合する。alphaのページに説明がない項目は「未確認」と記録する。
5. 更新後に同じ三つの表示を再確認し、版番号だけでなく実行ファイルの場所とモデル名が意図したものかを確かめる。

codex --versionで本体の版を固定する

版番号は短くても省略せず、接尾辞まで残します。たとえば0.148.0-alpha.6と0.147.0は、数字の大小だけでなく、公開段階が違います。alphaを落として「0.148.0」とだけ書くと、通常版と同じように見えてしまいます。複数の端末で確認するときは、OS、ターミナル、入手経路、実行ファイルの場所を版番号の隣に置き、別の環境の結果を一つにまとめないようにします。

/statusと表示モデルを別欄に残す

公式CLI案内には、現在のセッション設定を表示する /status、モデルや推論の設定を選ぶ /model、変更を確認する /review が例として示されています。これらは起動中のセッションを理解するための表示や操作であり、CLI本体のリリース番号を置き換えるものではありません。版番号の記録欄とセッション設定の欄を分けておけば、「更新したのに応答が違う」というときも、モデル変更、作業場所、許可範囲を順番に見直せます。

入手経路を固定して更新する

同じCodex CLIでも、公式のスタンドアロンインストーラ、npm、Homebrew、WindowsのPowerShell向けインストーラなど複数の入口があります。OpenAIの公式案内は、macOS/Linux向けのインストールと更新、Windows、npm、Homebrewを別の選択肢として示しています。いま使っている入口を確かめずに別の方法で更新すると、二つの実行ファイルが残り、画面に出る版番号と想定した更新先が食い違うことがあります。

公式リポジトリには、macOS/Linux向けのinstall.shとWindows向けのinstall.ps1があります。ファイルの内容と対象環境を確認し、配布元を混ぜずに一つの経路へそろえることが大切です。更新の成否を判断するときは、パッケージ管理ツールの完了表示より、実際に起動した codex --version を優先します。

安定版を日常利用へ更新する

日常用の端末では、まず安定版0.147.0を基準にします。更新前に現在の版と実行ファイルの場所を記録し、使っている経路に対応する更新方法を一つだけ選びます。npmならnpmの表示、Homebrewならcaskの表示、公式インストーラなら配布元と実行ファイルの場所を確認します。更新後は新しいターミナルを開き、古いプロセスや古いPATHの影響を残さないようにします。

1. いまの版番号と実行ファイルの場所を保存する。
2. 利用中の経路に対応する公式の更新方法を選び、別の経路を同時に実行しない。
3. ターミナルを開き直して codex --version を実行し、想定した版と一致するか確認する。
4. 小さな読み取り依頼を一つ行い、起動、作業場所、応答、終了までの状態を記録する。
5. 問題がなければ日常作業へ進み、問題があれば変更前の版へ戻す方法を確認してから原因を切り分ける。

プレリリースを目的を決めて試す

プレリリースを選ぶ場合は、試したい理由を一文で書きます。「新しい版を使いたい」ではなく、「0.147.0で確認したWindowsのパス表示が自分の環境でも改善するかを見たい」のように、観測できる目的へ変換します。0.148.0-alpha.6の公式ページで変更内容が判断できないなら、alphaの番号だけを根拠に採用を決めません。試す場所は日常の作業場所と分け、結果が悪ければ安定版へ戻せるようにします。

alpha版は小さな作業で検証する

先行版を試すときに大きな機能開発から始めると、版の差、作業の複雑さ、入力の違いが重なって原因を追えません。最初は、読み取り、変更、確認の三つを別の作業として扱います。読み取りでファイルを正しく見つけられるか、変更で差分が狙った範囲に収まるか、確認で既存のテストや表示が壊れていないかを個別に記録します。これなら「便利になった気がする」という印象を、再現できる結果へ置き換えられます。

比較には安定版0.147.0を基準にし、同じプロジェクトの複製、同じ指示、同じ確認方法を使います。アルファ版だけ別のモデルを選んだり、入力を長くしたりすると、版の違いを評価できません。モデル、作業場所、許可範囲、確認者、実施日を固定し、変更した項目があれば結果の横に書きます。公式リリースに書かれた変更は公開情報として引用し、手元でしか確認できない挙動は観測結果として分けてください。

比較対象を一つに絞る

基準版と先行版の二つだけを比べます。途中で別のalphaや別のモデルへ切り替えると、何が影響したのか分からなくなります。テスト用の複製を作り、最初の版で結果を記録してから先行版へ移ります。比較を終えたら、採用、保留、見送りのどれかを選び、理由を版番号と観測結果に結び付けます。

読み取り・編集・確認を分けて測る

読み取りが成功しても、編集やコマンド実行まで同じように成功するとは限りません。最初の作業はファイルの所在と内容の説明だけにし、次に一行の変更を依頼し、最後に差分と既存の確認を見ます。各段階で停止できるようにすると、先行版を試したことで変更範囲が広がった場合も、どの段階から症状が出たのかを説明できます。

Windowsで版の食い違いを見つける

WindowsではPowerShell、コマンドプロンプト、WSLが別のPATHを持つことがあります。PowerShellで更新したのにWSLで古いCodexが起動する、または複数の場所から同名の実行ファイルが見つかるという状況は、版そのものの不具合と区別しなければなりません。0.147.0の公式ノートにもWindowsのバックグラウンドプロセスとファイルパスを扱う修正が記載されているため、Windows利用者は版番号だけでなく、どの環境で起動したかを残す価値があります。

PowerShellでは Get-Command codex、コマンドプロンプトでは where.exe codex を使い、呼び出し先を確認します。結果が一つなら、その場所を更新経路の記録と照合します。複数の結果があるなら、PATHの順番を変更する前に、どのインストールが必要か、不要なものをどう扱うかを決めます。削除や移動を急がず、まず各ファイルの版を確認しておけば、戻すべき版を失わずに済みます。

PowerShellとWSLを混ぜない

PowerShellで表示された codex --version は、同じコマンド名でもWSLの結果を保証しません。記事やチームの記録には、PowerShellかWSLか、ターミナルを開いた場所、実行ファイルのパスを明記します。WSL側で使うならWSL側の入手経路を確認し、PowerShell側だけを更新して完了としないことが重要です。比較作業では片方の環境だけを使うと、版の差とOSの差を混同しにくくなります。

作業場所と許可範囲を確認する

Codex CLIを起動したら、表示される作業場所が意図したフォルダーかを確認します。公式案内は、プロジェクトディレクトリで起動し、モデル、推論の設定、許可範囲、コマンドを選べる流れを説明しています。Windowsではドライブ名やバックスラッシュの表示が変わるため、ファイルを一つ読む依頼から始め、対象外のフォルダーを見ていないことを確かめます。版を更新した直後ほど、機能の確認より先に作業場所を固定してください。

日常利用へ進める採用判断

採用判断は、リリース番号の新しさではなく、目的の作業を同じ条件で確認できたかで決めます。安定版0.147.0の変更が自分の課題に関係し、読み取り・編集・確認が問題なく再現したなら、通常利用の候補にできます。alpha.6に期待する差分が公式情報だけでは分からず、手元の小さな検証でも利点が確認できないなら、保留が妥当です。保留は失敗ではなく、公開情報と観測結果が足りない状態を正しく扱う判断です。

複数人で使う場合も、全員へ同じ先行版をすすめるのではなく、まず一人の確認担当が小さな作業で結果を残します。その記録に公式リリースのURL、版番号、公開段階、確認したOS、作業結果、見送った理由を含めると、あとから同じ条件で再確認できます。特定の担当者の経験だけを結論にせず、誰が読んでも再現できる事実と判断を分けることが、導入後の混乱を減らします。

まとめ：Codex CLIは版・経路・結果をそろえて選ぶ

2026年8月13日時点では、Codex CLI 0.147.0を通常利用の基準、0.148.0-alpha.6を先行確認の候補として分けて考えます。0.147.0の公式ノートにある機能やWindows向け修正が自分の作業に関係するかを確認し、alpha.6は公開段階と公式ページの記載範囲を超えて推測しません。まず codex --version、実行ファイルの場所、起動画面のモデル名、作業場所を記録し、同じ入手経路で更新します。その後、読み取り・小さな編集・確認を同じ条件で行い、結果が説明できた版だけを日常利用へ進めてください。最新版という一語に急がず、公式リリース一覧、公式CLI案内、手元の確認結果を三つの根拠としてそろえることが、Codex CLIを安全に使い続けるための近道です。