Codex呼び出しの方法｜CLI・アプリ・クラウドの使い分け

Codex呼び出しを理解する — 入口ではなく作業の形を選ぶ

Codexは、質問に答えるだけの画面としても、リポジトリ内のファイルを読み、変更を作り、手元のコマンドを実行する開発支援エージェントとしても使える。そのため「Codexを呼び出す」という言い方には、起動すること、最初の依頼を渡すこと、保存済みの会話を再開すること、作業結果をレビューすることが含まれる。入口を一つに決めてしまうと、対話が必要な場面で結果だけを求めたり、確認だけで済む場面に長い会話を持ち込んだりしやすい。

最初に見るべき境目は、対話の有無だ。codex はターミナルの画面を開き、同じセッションの中で質問を追加したり、方針を変えたり、差分を確認したりできる。反対に codex exec は、最初の依頼を引数または標準入力から受け取り、整形済みの出力やJSONLを返せる。OpenAIの公式CLIページも、ターミナルでコードを調べ、編集し、コマンドを実行する使い方と、codex exec による対話なしの呼び出しを分けて説明している（出典: Codex CLI公式ドキュメント）。

もう一つの境目は、作業を続けるのか、結果を判定するのかだ。前回の相談内容を引き継ぐなら codex resume、変更の妥当性を確認するだけなら codex review が適している。同じ「コードを見てほしい」という依頼でも、調査から修正まで進めたいなら通常の codex、すでにある差分の問題点だけを探したいなら codex review と入口が変わる。

呼び出しを考える三つの軸

Codexの呼び出しを決める前に、対象、会話の長さ、確認方法を一文で書くとよい。対象は「現在のリポジトリ」なのか、特定のフォルダーなのか。会話の長さは、質問を重ねるのか、一つの依頼で終えるのか。確認方法は、画面で差分を見るのか、標準出力を保存するのか、レビュー結果を読むのかである。

この三つが決まれば、コマンド名を覚える負担は小さくなる。たとえば「現在のリポジトリで原因を調べながら直し、差分を画面で確認する」は codex、「特定フォルダーのテスト結果を一度だけ受け取る」は codex exec、「作業済み差分に重大な問題がないか確認する」は codex review --uncommitted と考えられる。

2026年8月の更新で確認したいこと

Codex呼び出しを今整理する理由は、CLIの公開版が短い間隔で更新されているからだ。OpenAIの公開リポジトリでは、0.148.0-alpha.7 が2026年8月11日15時29分、0.148.0-alpha.8 が同日18時41分に公開され、いずれもプレリリースとして表示されている。alpha.8のページには配布物とコミット数は示されているが、利用者がそのまま読み取れる変更一覧は確認できない（出典: Codex CLI 0.148.0-alpha.8、Codex CLI 0.148.0-alpha.7）。

この状況では、版番号だけを見て「この呼び出し方なら必ず使える」と決めないことが大切だ。安定版を使っている人がalpha版の説明を混ぜると、手元に存在しないサブコマンドや、表示の異なるオプションを前提にしてしまう。まず codex --version で実際の版を確認し、次に公式の開発者コマンド一覧で、該当するコマンドの成熟度と引数を照合する。

更新直後に確認する項目は、起動、作業場所、依頼の渡し方、結果の表示の四つで十分だ。通常の codex が起動するか、--cd で意図した場所を指定できるか、短い依頼を渡したときに応答が返るか、codex exec の出力が読む予定の形式になっているかを小さなリポジトリで確かめる。新しい版の価値を推測するより、呼び出しの入口が従来どおり機能するかを先に確認すると、問題の切り分けがしやすい。

alpha版と安定版を同じものとして扱わない

alpha版は、次の更新を先に試すための版であり、通常利用の基準とは別に扱う必要がある。公式リリース一覧では安定版とプレリリースが同じ場所に並ぶため、数字が大きいという理由だけで選ばない。実際に使う版、確認した日、試した呼び出し方をメモしておけば、表示や結果が変わったときに原因を戻って確認できる。

コマンド別に見るCodexの呼び出し方

公式の開発者コマンドリファレンスでは、codex、codex exec、codex resume、codex review などが別の目的を持つコマンドとして整理されている（出典: Developer commands）。呼び出し時に大切なのは、長いオプションを一度に覚えることではなく、作業の状態と欲しい結果に近い入口を選ぶことだ。

codex — 会話を続けながら呼び出す

引数を付けずに codex を実行すると、現在の作業場所を基準にターミナル画面が開く。ここで「このプロジェクトの構成を説明して」と頼み、回答を読んでから「次に認証周りだけ詳しく」「変更はしないで候補を示して」と追加できる。依頼の途中で前提が変わる調査や、複数のファイルを見てから修正範囲を決める作業では、この入口が扱いやすい。

最初の依頼に短い指示を添えて起動することもできる。公式リファレンスでは、基本の codex コマンドに任意のプロンプトや画像を渡せると説明されている。画像を添える場合は --image、現在の設定を確認する場合はセッション内の /status を使うなど、最初の質問と後から確認する操作を分けると会話が読みやすくなる。

codex
codex "このリポジトリの構成を調べ、変更せずに主要な入口を説明してください"

codex exec — 対話なしで一つの結果を受け取る

短い依頼を一度だけ渡すなら codex exec が向いている。公式リファレンスでは、依頼文を文字列で渡すほか、- を指定して標準入力から受け取れるとされている。また、通常の表示に加えてJSONLを選べ、最後のメッセージをファイルへ書き出すオプションも用意されている。人が画面を見ながら相談するのではなく、結果を後で読んだり別の確認へ渡したりする場面に適する。

ただし、対話がないぶん依頼文の不足がそのまま結果に出る。「何を調べるか」だけでなく、変更してよいか、対象ファイルはどこか、完了とみなす条件は何かを短く書く。最初は読み取り中心の依頼にして、結果を見てから通常の codex で追加質問する流れが安全だ。

codex exec --cd path/to/project --sandbox read-only "テストの入口を調べ、実行せずに関連ファイルと確認方法を説明してください"

--cd は作業場所を指定し、--sandbox read-only はモデルが生成したコマンドの扱いを読み取り専用に限定する指定である。実際に使える値や既定値は版によって変わる可能性があるため、実行前に codex exec --help と公式リファレンスを確認したい。コマンドを短くすることより、対象場所と変更範囲を明記することのほうが結果の再現性に効く。

codex resume — 中断した会話へ戻る

途中で端末を閉じた、別の依頼を先に確認した、いったん考える時間を置いたという場合は codex resume を使う。codex resume --last は現在の作業場所から直近の会話を再開し、一覧を見てから選びたい場合は引数を省いて保存済みの会話を探せる。公式資料では、--all を付けると現在の場所の外にあるセッションも候補に含められると説明されている。

再開時の注意は、画面を開く場所と会話が保存された場所が違うことだ。複数のリポジトリを行き来する人は、--last がいつでも全体の最新になるとは考えず、まず現在の作業場所を確認する。目的の会話が見つからないときは、別の場所を検索する前にセッション名やIDで選び直すと、意図しない続きを開く事故を減らせる。

codex resume --last
codex resume --all

codex review — 変更を確認するために呼び出す

すでに変更がある場合、通常の codex に「見てください」と頼む方法もあるが、レビュー専用の codex review を使うと対象を明確にできる。未コミットの差分なら --uncommitted、基準ブランチとの差なら --base ブランチ名、特定コミットなら --commit SHA を指定する。公式リファレンスでは、これらの対象指定は互いに競合するため、一度の呼び出しで一つだけ選ぶよう案内されている。

codex review --uncommitted
codex review --base main
codex review --commit abc1234

レビューの依頼文は「問題があるか」だけで終わらせず、見てほしい観点を加える。たとえば公開APIの互換性、例外処理、テストの不足、画面表示の崩れなど、優先順位を付けたい観点を明示すると結果を読みやすい。レビューは変更を確認する入口であり、修正そのものを任せる呼び出しとは役割が違う。

実際の呼び出し手順

Step 1: リポジトリと目的を固定する

Codexを呼び出す前に、端末が意図したリポジトリの中にいるか確認する。別の場所から起動しても --cd で対象を指定できるが、相対パス、設定、読み込まれる指示ファイルの基準が変わるため、作業場所を曖昧にしないほうがよい。依頼文には、目的、対象、変更の可否、確認方法を一続きの文章で書く。

cd path/to/project
codex "src/profile の表示崩れを調べ、原因と変更候補だけを説明してください。ファイルは変更しないでください"

最初から「直して」とだけ書くと、調査と編集の境目が曖昧になる。原因を知りたいのか、修正案がほしいのか、実際にファイルを変更してテストまで進めたいのかを分ければ、同じCodexでも期待する動きが安定する。

Step 2: 対話型で前提を確認する

調査の範囲が見えていないときは、まず codex を起動し、リポジトリの構成、関連ファイル、再現条件を順に確認する。画面に表示されたコマンドや差分を読み、必要なら依頼を狭める。Codex公式ページも、プロジェクトの説明、焦点を絞った変更、問題の調査を最初の依頼例として示している（出典: Codex CLIのクイックスタート）。

この段階では、最初の一言を大きくしすぎないことがポイントだ。「全体を改善して」ではなく「ログイン画面の入力検証がどこで行われるかを説明して」のように、回答を読んで次の問いを決められる単位にする。対話型の利点は、最初の依頼を完璧に作らなくても、回答を材料にして方針を調整できる点にある。

Step 3: 一度の確認を codex exec に切り出す

依頼の条件が決まったら、毎回同じ観点で調べたい作業を codex exec に切り出す。たとえば「変更せずにテストの入口と関連ファイルを報告する」のように、読み取りと報告だけに限定した依頼を試す。結果を端末で読むなら通常表示、後で項目ごとに扱うなら --json、最後の回答だけ保存したいなら --output-last-message を検討する。

codex exec --cd path/to/project --sandbox read-only --output-last-message report.txt "変更は加えず、失敗しているテストの原因候補をファイル名と理由付きで報告してください"

この呼び出しでは、対象、禁止事項、出力先を一つの依頼にまとめている。結果が長くなりすぎる場合は、調査対象を一つのテストや一つの画面に絞る。作業を広げることより、同じ条件で結果を比較できることを優先すると、版を更新した後の確認にも使いやすい。

Step 4: 続きとレビューを別の入口で呼び出す

調査の途中で止めた場合は codex resume --last で続け、変更がまとまったら codex review --uncommitted で差分を確認する。続きの依頼とレビューの依頼を同じコマンドに詰め込まないことが大切だ。前者は文脈を引き継いで作業を進めるため、後者は現在の変更を独立した視点で点検するための呼び出しだからである。

レビュー対象がコミットや基準ブランチに変わる場合は、--uncommitted を残したまま別の指定を足さない。公式リファレンスが示すとおり、対象指定には排他関係がある。呼び出しの前に「何と何を比べるのか」を決めれば、レビュー結果を読み違えにくい。

Step 5: 画面やクラウドを使う場合も入口を分ける

ターミナルよりデスクトップ画面でプロジェクトを扱いたい場合は codex app が選択肢になる。公式資料ではmacOSまたはWindowsのデスクトップアプリを開くコマンドとして説明され、Windowsでは開く場所の案内が表示される。一方、クラウド上の会話を端末から扱う codex cloud は、同じ資料でExperimentalと記載されているため、通常のローカル作業と同じ前提で扱わない。

入口を変えても、最初に決めるべきことは対象場所と確認方法である。画面から始める場合も、ターミナルから始める場合も、対象リポジトリ、変更の可否、確認したい結果を先に書く。画面が違うだけで依頼の条件が不要になるわけではない。

目的別に選ぶCodex呼び出し

調査や設計なら codex

未知のリポジトリでは、最初から一度の出力だけを求めるより、回答を見ながら質問を変えられる codex が向いている。構成の把握、関連ファイルの特定、再現条件の確認、修正方針の比較という順に進めると、意図しない編集を避けやすい。依頼を小さく始め、回答に含まれるファイル名や前提を次の質問へ使うのがコツだ。

定型的な確認なら codex exec

「このフォルダーのテストを読んで、実行方法と注意点を報告する」のように、目的と出力が決まっている確認は codex exec に向いている。標準入力で依頼を渡せるため、長い文章を別の場所で用意してから呼び出すこともできる。対話がないぶん、変更の可否と出力形式を依頼に明記する必要がある。

中断した作業なら codex resume

前回の回答や調査結果をもう一度説明したくないなら、セッションを再開する。--last は現在の作業場所を基準にするので、リポジトリを移動した後に使う場合は場所を確認する。別の会話を続けたいときは、一覧またはセッションIDを使って明示的に選ぶほうがよい。

変更の確認なら codex review

実装済みの差分から問題を探すときはレビュー専用の入口を使う。未コミット、基準ブランチ、コミットのどれを対象にするかを決め、必要な観点を依頼文に加える。レビューの結果を見て修正が必要になったら、その修正は通常の codex で別の依頼として進めると、確認対象が混ざらない。

画面中心なら codex app、クラウド確認なら codex cloud

デスクトップ画面で複数の作業場所を扱いたい場合は codex app、クラウド上の会話を端末から確認したい場合は codex cloud を検討する。ただし、後者は公式リファレンス上の成熟度が異なる。普段のローカル作業を安定させたい場合は、まず codex と codex resume の使い分けを固め、必要性がはっきりしたときに別の入口を試すとよい。

呼び出し時に見直す設定

コマンドの前に、どの設定をその呼び出しだけ変えるのかを決める。公式リファレンスに掲載されている代表的な指定には、作業場所を変える --cd、モデルを選ぶ --model、生成されたコマンドの扱いを決める --sandbox、実行前の確認タイミングを決める --ask-for-approval がある。画像を最初の依頼へ添える --image や、最新情報を調べる必要があるときの --search も、目的が明確な場合だけ使う。

特に --sandbox と --ask-for-approval は、短く書けるからという理由で省略しないほうがよい。読み取りだけなら read-only、作業場所内の変更まで許可するなら workspace-write のように、依頼の範囲に合う値を選ぶ。許可の確認をどの場面で求めるかも、作業に入る前に決めておくと、途中で判断がぶれにくい。利用できる値は版ごとに codex --help と公式ページで確認する。

設定ファイルに保存した内容と、コマンドで一時的に指定した内容が異なる場合は、どちらが今回の呼び出しに効いているかを確かめる。公式リファレンスでは、-c key=value の指定がその呼び出しの設定を上書きすると説明されている。設定を変えたのに結果が変わらないときは、作業場所、プロファイル、コマンドライン指定の順に確認すると原因を見つけやすい（出典: Codex開発者コマンド）。

最初は読み取り中心で呼び出す

初回の呼び出しでは、構成説明、対象ファイルの特定、テスト方法の確認など読み取り中心の依頼から始める。変更を許可する前に、Codexがどの場所を見て、どの前提で判断しているかを回答で確かめる。これは慎重すぎるのではなく、作業場所と依頼文のずれを早く見つけるための準備である。

よくある呼び出しの間違い

codex exec に対話型の期待を持ち込む

codex exec は一つの依頼を渡して結果を受け取る入口なので、途中で前提を何度も変えたい場合には向かない。返ってきた結果に質問を重ねたいなら、最初から codex を使うか、結果を読んでから新しい依頼を渡す。対話なしの入口へ長い相談を押し込むと、出力の不足を後から補うための手戻りが増える。

作業場所を確認せずに resume する

codex resume --last は、公式資料の説明どおり現在の作業場所を基準に直近の会話を探す。別のリポジトリへ移動してから実行すると、思っていた会話が候補にならないことがある。再開前にパスを表示し、必要ならセッションを明示して選ぶだけで、この問題は避けられる。

レビュー対象を混ぜる

codex review --uncommitted、--base、--commit は同じ意味の別名ではない。未コミットの変更を見たいのか、特定の比較元との差を見たいのか、コミット単位で確認したいのかを先に決める。対象を曖昧にしたまま複数の指定を付けると、エラーになるか、意図と異なる確認になるため、一回の呼び出しでは一つの対象に絞る。

alpha版の機能を安定版の前提にする

公開直後のalpha版は、公式ページに変更一覧が少ない場合でも、安定版と同じものとは限らない。更新後に呼び出しが失敗したときは、依頼文を何度も書き換える前に codex --version と codex --help を確認する。版番号、実行したコマンド、表示されたエラーを一緒に記録すれば、公式リリースと手元の状態を比べられる。

まとめ — Codex呼び出しは目的から決める

Codex呼び出しで最初に覚えるのは、コマンドの数ではなく作業の形である。会話を続けながら調べるなら codex、一つの依頼を対話なしで処理するなら codex exec、中断した作業へ戻るなら codex resume、差分を点検するなら codex review を選ぶ。入口と目的が一致していれば、依頼文も短く書きやすい。

2026年8月13日時点では、Codex CLI 0.148.0-alpha.8が8月11日に公開されたばかりのプレリリースである。新しい版を試すときは、安定版との区別、実際の版番号、公式コマンドリファレンスの三点を確認する。変更一覧が十分でない版ほど、起動と短い読み取り依頼から小さく試すのがよい。

最後に、呼び出しの前へ「対象場所」「変更してよい範囲」「欲しい結果」「確認方法」を置く。画面、ターミナル、クラウドのどこから始めても、この四点が揃っていれば判断の軸は変わらない。公式情報を版ごとに照合しながら、作業に合う入口を一つずつ使い分けよう。