Codex helpの使い方とヘルプの読み方・エラー時の確認手順

Codex helpで調べられることと確認の範囲

「codex help」という検索語で知りたいことは、大きく二つあります。一つはCLIの書き方を知ること、もう一つは操作が失敗した理由を知ることです。前者にはヘルプ表示が役立ちますが、後者にはエラー本文や現在の設定も必要です。ヘルプを表示できたからといって、サインインやモデルへのアクセスまで確認できたとは考えないようにしましょう。

OpenAIの公式CLIリファレンスは、コマンドと各種指定を整理し、個別コマンドのヘルプも確認するよう案内しています。オンラインの資料は現在公開されている機能の説明、手元のヘルプはインストールされた版の構文を調べる資料として使うと、情報の役割を整理できます。

たとえば、手元のヘルプにコマンドが見つからない場合、名前の入力違い、導入している版の違い、調べている操作画面の違いが候補になります。一方、引数として受け付けられた後にモデルの利用を断られた場合は、構文よりもモデルの提供状況を確認する方が適切です。表示されている情報の種類によって、次に読む資料を変えます。

ヘルプを表示する基本の手順

最初から長い起動例を試すと、どの指定が問題なのか分かりにくくなります。全体のヘルプで名称を確認し、個別のヘルプで値の形を確認する順序が有効です。以下は読者が自身のターミナルで確認する例です。記事中の確認用コマンドは、作業の依頼文を付けずに使います。

確認の間は、ヘルプに書かれた操作名を実際に動かす必要はありません。とくに履歴を消す操作や設定を変える操作は、説明を読むことと実施することを分けます。目的に合う説明が見つかったら、必要な値と結果を理解してから次の作業へ進みましょう。

Step 1: 全体のヘルプを開く

まず codex --help を入力し、CLI全体の案内を表示します。検索するときの「codex help」という語を、そのまま作業依頼として送る必要はありません。コマンドの一覧と、基本の呼び出し形式が見えるかを確認します。codex が見つからないというエラーになった場合は、ヘルプの読み方へ進む前に、CLIが導入されているか、ターミナルがその場所を見つけられるかを確かめます。

codex --help

Step 2: 目的のコマンドの説明に絞る

全体の一覧から目的のコマンドを選び、名前の後ろに --help を付けます。たとえば履歴を再開する操作なら codex resume --help、変更内容のレビューなら codex review --help です。全体の説明に掲載された指定が、すべての個別コマンドで同じように使えるとは限りません。そのコマンド自身の説明にあるUsageとOptionsを確認します。

codex resume --help
codex review --help

Step 3: 表示結果と導入している版を記録する

案内と手元の表示が食い違う場合に備え、codex --version の結果を記録します。版、調べたコマンド名、問題になった指定を一緒に残すと、後から情報を照合できます。公式ページ内の画面例に表示された版は、その画像を作った時点の例である可能性があります。ページ上の画像だけを根拠に、自分の版が古いか新しいかを決めないようにします。

codex --version

Usage・Commands・Optionsの読み方

ヘルプの見出しは、情報の種類を表しています。Usageには呼び出しの骨組み、Commandsには選べる操作、Optionsにはその操作に渡せる指定が並びます。すべての行を覚える必要はありません。自分がしたい操作を先に決め、その操作に必要な行だけを読むと、長い説明でも使う部分を見つけやすくなります。

以下の表は、ヘルプでよく使われる表記の読み方です。実際のラベル、順序、省略形は導入した版やコマンドによって変わるため、表示されている説明を優先してください。とくに、例示された値と、自分が入力する値を取り違えないことが大切です。

値を取る指定と、付けるだけの指定を区別する

公式リファレンスでは、--model は文字列、--cd はパスを受け取る指定として説明されています。一方、--search は付けることで検索の設定を変える指定です。この違いを見落とすと、次に書いた単語が前の指定の値として解釈されたり、不要な値を付けてエラーになったりします。名前だけでなく、TypeやValuesに相当する説明も読みましょう。

入力例の記号をそのまま写さない

説明にある <path> や <model> は、通常は自分のフォルダやモデル名に置き換えるための印です。たとえばパスに空白が含まれる場合は、ターミナル側で一つの値として渡せる引用符を使います。記事の例を写す際には、操作名、置き換える値、説明用の記号を区別してください。全角のダッシュや見た目が似た引用符も、コマンド用の文字と同じとは限りません。

起動前のヘルプと会話中の操作を使い分ける

ターミナルに入力するCLIの指定と、Codexの会話画面で入力するスラッシュコマンドは、入力する場所が異なります。起動前の構文を調べたい場合はターミナルのヘルプを使い、進行中の会話の状態を確認したい場合は、その会話の操作を使います。入力場所を取り違えると、正しい文字列でも意図した機能になりません。

OpenAIのCLI案内は、会話中の /status を現在の状態の確認、/model をモデルと推論の労力の選択として紹介しています。たとえば「起動時にモデルを指定する書き方」を調べるなら --model の説明、「いま選べるモデル」を確認するなら利用中の画面のモデル選択が適しています。

会話画面の表示は、契約、利用する端末、組織の設定によって変わることがあります。ターミナルのヘルプにモデル指定の機能があっても、すべてのモデルを選べるとは限りません。まず文字列の形式をヘルプで確認し、その後に利用する画面で候補と現在の選択を確かめると、調べる順番が明確になります。

エラーが出たときは構文・場所・利用条件を順に確認する

エラーが出たら、表示された文章を残してから原因を絞ります。「コマンドが見つからない」「引数が認識されない」「モデルを利用できない」は、同じ失敗ではありません。原因が違えば必要な対処も変わります。問題がある指定を一度にいくつも変更すると、何が効いたか分からなくなるため、一つずつ比較するのが適切です。

次の表は確認の入口です。文言はターミナルや版によって異なります。表の言葉と完全に一致するかより、CLIを呼び出す前に止まったのか、構文の解釈で止まったのか、利用開始の段階で止まったのかを判断してください。

Step 1: 問題の指定を最小限にする

長い入力例のうち、問題として示された指定を抜き出し、その指定が目的のコマンドのヘルプに掲載されているかを確認します。別のコマンド向けの例を混ぜていないか、短い指定を誤記していないかも見ます。公式リファレンスは、共通の指定でも引き継がれ方には例外があると説明しているため、全体の一覧だけで判断せず個別の説明に戻ります。

Step 2: 導入済みのCLIを取り違えていないか調べる

同じPCに複数の導入方法が残っていると、想定と違う場所のCLIが呼ばれることがあります。WindowsのPowerShellなら Get-Command codex、macOSやLinuxの一般的なシェルなら command -v codex で、コマンドとして認識される場所を確認できます。これらはOS側の確認例です。得られた場所と版を照合し、使っているCLIを特定してから更新を検討します。

Step 3: 更新で解決する問題かを判断する

公式資料にある指定が手元にない場合は、公式更新履歴で変更の内容を確認します。更新すればすべてのエラーが解消するとは限りません。利用条件や提供終了が原因なら、CLIの更新とは別にモデルの選択を見直す必要があります。導入方法に合った更新案内を使い、更新後も同じ個別ヘルプで指定の有無を確かめます。

GPT-5.5提供終了を前に、ヘルプだけでは分からない点

2026年10月13日時点の公式更新履歴では、GPT-5.5は10月14日にChatGPT、ChatGPT Work、Codexのすべてのプランで提供を終了する予定です。この終了はOpenAI APIには適用されないと説明されています。既存の起動例に gpt-5.5 が残っている場合は、自分の利用方法がどちらに当たるかを確認する必要があります。出典は9月14日付の公式告知を含む更新履歴です。

ここで大切なのは、--model が文字列を受け取ることと、その文字列に対応するモデルが利用可能なことを分ける点です。ヘルプはモデル名を渡す方法を示せても、契約や組織設定を踏まえた利用可否までは保証しません。古い例の指定が構文上は正しくても、提供状況が変われば利用時に問題が起きる可能性があります。

同じ更新履歴には、9月29日のGPT-6.1 Sol提供と、10月8日のUltrafast対応も掲載されています。ただし高速モードには対象プランなどの条件があります。ヘルプに指定があることを理由に、高速モードや新しいモデルが誰にでも使えるとは判断しないでください。公式料金・利用条件と、利用する画面の選択肢を合わせて確認します。

実際の見直しでは、起動例のモデル名、手元の版、サインイン方法、画面に表示される候補を記録すると比較しやすくなります。モデルの置き換えが必要な場合も、単に名前を変更して終えるのではなく、普段の小さな開発課題で結果と利用量を確かめます。ヘルプで入力の形を確認し、公式案内で条件を確認する組み合わせが、変更時の判断材料になります。

問い合わせに残すと役立つ情報

自分で解決できない場合は、調べた内容が相手にも伝わる形で残します。必要なのは、CLIの版、試したコマンドの形、エラーの文章、参照した個別ヘルプです。フォルダ名や会社のプロジェクト名は一般的な表記に置き換え、同じ問題が再現する最小限の情報に絞ります。長い会話履歴を丸ごと渡すより、どの段階で止まったかが分かる記録の方が調査しやすくなります。

記録例としては「WindowsのPowerShellで、記載した版のCLIを使い、個別ヘルプに載っていない指定を付けると未知の引数と表示された」と書けます。モデルに関する失敗なら「指定の構文はヘルプにあり、利用開始時にモデルへのアクセスを断られた」と区別します。こうした情報があれば、入力方法、導入状態、利用条件のどこを調べるべきか共有できます。

ヘルプを読む習慣は、指定を暗記するためのものではありません。いま使っている版が受け付ける操作を確かめ、古い例との違いを見つけるために役立ちます。全体の案内から目的の個別ヘルプへ進み、構文が正しいことを確かめた後に、モデルやプランの条件を照合すると、必要な修正を絞り込めます。