Codexの使い方は4つの入口から選ぶ｜CLIとクラウドの違い

「Codexの使い方って、結局どこから触ればいいの？」
「Codexを最初の1回だけでも動かしてみたい！」

Codexを調べると、ターミナルの画面、ブラウザの画面、エディタの拡張機能と、まるで違うものが同じ名前で出てきます。この記事では、Codexの使い方を4つの入口に分けて整理したうえで、導入から最初の指示までの手順と、どこまで任せてよいかの線引きまでまとめました。

先に結論を書くと、手元のコードをすぐ直したいならCLI、時間のかかる調査を任せたいならクラウド。この2つを押さえておけば、残りは後から選べます。

Codexの使い方には4つの入口がある

Codexは、ひとつの画面だけで使う道具ではありません。入口が4つあり、それぞれ得意な作業が違います。

ここでは、4つの入口の性格と、どんな場面で選ぶといいのかを見ていきます。

ターミナルで動かすCodex CLI

いちばん使われているのがCLIです。ターミナルでcodexと打つだけで起動して、そのフォルダのファイルを直接読み書きします。

強いのは反応の速さ。指示を出してから結果が返るまでの往復が短く、直しては確認するという流れが途切れません。小さなバグ修正なら数分で片づきます。

その代わり、時間のかかる作業には向きません。ターミナルを開いたまま待つことになるので、他の作業ができなくなります。

もうひとつの利点が、実行結果をそのまま受け取れること。テストを走らせて失敗したら、その出力を見て自分で直しにいきます。人が結果をコピーして貼り直す手間が丸ごと消えるのは、CLIならではでした。

CLIそのものの初期設定はCodex CLIの使い方で細かく扱っているので、コマンド単位の話はそちらを見てみてください。

エディタに組み込むIDE拡張

Visual Studio Codeなどのエディタに拡張機能として入れる形です。コードを読みながら、その場で指示を出せます。

CLIとの違いは、変更が差分として画面に並び、1つずつ受け入れるか戻すかを選べるところ。何が変わったのかを目で追いながら進められます。

コードを書ける人ほど、この形が合うと思います。全部任せるのではなく、判断を自分で握ったまま速度だけ上げられるからです。

逆に、コードをまったく読まない前提で使うなら、CLIかクラウドのほうが手数は少なくなります。

もうひとつ、既存のプロジェクトに途中から入るときにも役立ちます。読んでいるファイルについてその場で質問できるので、コードを追いながら理解を埋めていけるのが大きいです。

クラウドで動かすCodex webとGitHub連携

3つ目はブラウザから使う形です。OpenAI側のサーバーで動くので、自分のパソコンを閉じても作業が進みます。

GitHubのリポジトリをつないでおくと、結果がプルリクエストとして返ってきます。レビューして、良ければマージするだけ。手元の環境を汚さずに済むのも利点です。

時間のかかる調査や、複数のタスクを並行して進めたいときに効きます。3つ投げておいて、あとでまとめて確認するという使い方ができます。

3つ目は見落としがちです。クラウド側の環境で動かすため、ビルドに必要なものが揃っていないと途中で止まります。

実際に使ってみると、待ち時間の感覚が変わります。CLIでは3分待つのが長く感じるのに、クラウドに投げた作業は30分かかっても気になりません。手元が空いているかどうかで、体感がまるで違うんですよね。

結果をまとめて見るCodexアプリ

4つ目はデスクトップアプリです。CLIとクラウドで動かした結果を、ひとつの画面で並べて確認できます。

役割としては司令塔に近いです。作業そのものより、進捗の確認と承認をまとめて片づけるための入口だと考えるとしっくりきます。

ひとりで1つのタスクを進めているうちは、正直なくても困りません。並行して何本も走らせるようになってから、必要性が出てきます。

4つ全部を使う必要はありません。まず1つ選んで、足りなくなったら足す。この順番で困ったことはないです。

迷ったときの目安は、いま自分がどこで作業しているか。ターミナルを開いている時間が長いならCLI、エディタに張りついているならIDE拡張、というふうにすでに開いている画面に合わせるのがいちばん自然でした。

入口が違っても、動いているのは同じCodexです。CLIで作った作業の続きをブラウザから確認する、といった行き来もできます。最初の選択に時間をかけるほどの違いはないと考えて大丈夫でした。

Codexを使い始めるまでの手順

ここからは実際に動かすまでの流れです。初めてでも、30分あれば最初の1回にたどり着けます。

ここでは、契約の確認からインストール、最初の指示までを5つの段階に分けて解説します。

【ステップ1】ChatGPTの有料プランを用意する

最初に確認したいのが契約です。Codexは単体で契約するものではなく、ChatGPTの有料プランに含まれています。

公式ドキュメントによると、Plus・Pro・Business・Edu・Enterpriseのいずれかに入っていれば使えます。個人ではPlusが入口になることが多く、執筆時点では月20ドルです。

もうひとつ、OpenAIのAPIキーで使う方法もあります。ただ、こちらは使った分だけ課金される仕組みなので、慣れないうちはおすすめしません。

どうしてもAPIキーで使うなら、先にOpenAIの管理画面で利用上限を設定してください。ここを飛ばすと、請求書を見るまで金額がわかりません。

最新の金額とプランの違いは変わりやすいので、契約前に公式の料金ページで確認しておくと確実です。

【ステップ2】Codex CLIをインストールする

契約が済んだら、CLIを入れます。方法は2つあり、どちらか好きなほうで構いません。
Node.jsが入っているならnpmが早いです。

npm install -g @openai/codex

macOSでHomebrewを使っているなら、こちらでも入ります。

brew install --cask codex

どちらも数十秒で終わります。Node.jsが入っていない場合は、Homebrewのほうが先に進めますから、エラーが出たら方法を切り替えてみてください。

2つ目は本当によくあります。インストール直後はパスが読み込まれていないので、開き直すだけで解決することが多いです。

入ったかどうかは、バージョンを表示させれば確認できます。数字が返ってくればインストールは成功しているので、次のサインインへ進んでください。

【ステップ3】サインインして起動を確認する

入ったら、ターミナルでcodexと打ちます。初回はサインインを求められます。

選ぶのは「Sign in with ChatGPT」。ブラウザが開いてログインすると、そのままターミナルに戻ってきます。公式もChatGPTアカウントでのサインインを推奨しています。

（出典：OpenAI Codex CLI 公式ドキュメント／2026年8月時点）

起動すると、使っているモデル名と作業ディレクトリが表示されます。ここが自分の意図した場所になっているかを最初に確認してください。

違う場所で起動していると、まったく関係ないファイルを読みに行きます。私も最初、ホームディレクトリで動かして首をかしげました。

【ステップ4】作業したいフォルダで指示を出す

いったん終了して、作業したいプロジェクトのフォルダに移動してから起動し直します。ここがCodexの前提になる場所です。

最初の指示は、小さく具体的に。「READMEを読んで、このプロジェクトが何をするものか3行で説明して」くらいから始めると、コードを壊す心配なく挙動を確認できます。

感触がつかめたら、実際の修正を頼みます。このときも範囲を絞るのがコツです。

どれもコードを大きく変えない指示です。読ませる作業から始めて、書かせる作業に移る。この順番だと安心して進められます。

【ステップ5】差分を確認してから反映する

指示を出すと、Codexが何を変えたのかを差分として見せてきます。ここで流さずに読むのが、いちばん大事な習慣です。

確認したいのは3つ。意図した範囲だけが変わっているか、余計なファイルに手が入っていないか、消してはいけないものが消えていないか。

変更が大きすぎると感じたら、その場で戻して指示を分け直してください。1回で全部やらせようとするほど、確認の負担が増えます。

3つ目が肝心です。読めない量の変更を受け入れると、あとで壊れたときに手が出せなくなります。

差分が長いと感じたら、その場で「変更を3行で要約して」と聞いてみてください。要約を読んでから差分に戻ると、どこを重点的に見ればいいかがわかります。

慣れるまでは、作業を始める前に必ずコミットしておいてください。変更前の状態が残っていれば、いつでも戻せるという安心感が、思い切って任せる余裕を作ってくれます。

Codexの使い方でつまずきやすい場所

動かせるようになったあと、たいていの人が同じところで止まります。先に知っておくと、そのぶん早く抜けられました。

ここでは、承認モード・指示の書き方・任せる範囲という3つのつまずきを扱います。

承認モードをどれにするかで迷う

Codexには、コマンドを実行する前に確認を求めるかどうかの設定があります。毎回聞かれると遅く、全部任せると怖い。ここで迷います。

判断の軸は「危ないかどうか」ではなく「元に戻せるかどうか」にしてください。危険度は主観ですが、可逆性は事実として判定できます。

Gitで管理していて、未コミットの変更がなく、書き換わるのがソースコードだけ。この条件が揃っているなら、自動で進めさせて最後に差分を見るほうが速いです。

逆に、本番のデータベースを触るときや、外部にリクエストを送るときは1つずつ承認する。コミットしておくだけで、選べるモードが変わるというのは覚えておく価値があります。

迷ったら承認を求める側から始めてください。手数は増えますが、何をしようとしているのかが毎回見えるので、任せてよい範囲の感覚が早く身につきます。

権限設計の考え方そのものはClaude Codeの権限設定と共通しているので、あわせて読むと整理しやすいです。

日本語の指示が長くなって意図がぶれる

日本語で指示を書けるのは大きな利点です。ただ、日本語だからこそ長くなりやすい、という副作用があります。

「〇〇したいんだけど、△△も気になっていて、できれば□□も」と書くと、どれが主目的なのかが伝わりません。結果として、頼んでいない部分まで手が入ります。

効くのは、1つの指示に1つの目的だけ入れること。それと、期待する結果を先に書くことです。

3つ目が意外と効きます。禁止事項を1つ添えるだけで、変更の範囲が目に見えて狭まりました。

長い説明を書くより、短い指示を2回に分けるほうが結果は安定します。1回目で調べさせて、返ってきた内容を見てから2回目で直させる。間に自分の判断を挟むと、そもそも大きくぶれません。

どこまで任せてよいかの線引きができない

慣れてくると、任せる範囲を広げたくなります。ここで一度、線を引き直しておくと後が楽です。

判断の基準は、自分がその結果を評価できるかどうか。読めないコードを大量に受け取っても、それは資産になりません。

だから最初のうちは、「自分でも書けるけれど時間がかかる作業」を任せるのが正解です。書けないものを任せると、動いていても検証できない状態が残ります。

3つ目は特に危ないです。壊れたことに気づく仕組みがないまま、大きく変えてしまうことになります。

順番としては、テストを足す作業から任せるのが安全でした。テストが増えるほど、次に任せられる範囲も広がっていきます。任せる力そのものを、任せて育てられるという関係になっています。

線引きは固定しなくて構いません。使いながら「ここは任せて大丈夫だった」を積み上げて、少しずつ広げていく。一気に広げて事故るより、そのほうが結局は速く進めます。

Codexをローカルとクラウドで使い分ける

入口を選べるようになったら、次は使い分けです。ここが決まると、作業の速度がはっきり変わります。

ここでは、手元で進める作業とクラウドに任せる作業、そして行き来するときの注意を整理します。

手元で進めたほうが速い作業

結果をすぐ見たい作業は、迷わずローカルです。画面を見ながら「ここをこう直して」と伝えられる速さは、クラウドでは出せません。

目安としては、5分以内に終わりそうな作業はすべてローカル。往復が短いぶん、思いついたことをそのまま試せます。

もうひとつ、環境に依存する作業もローカル向きです。自分のマシンにしか入っていないツールを使う場合、クラウドでは再現できません。

逆に言えば、これ以外はクラウドに逃がす候補になります。手元を占有しないという価値は、思っているより大きいです。

もうひとつ、ローカルには「途中で気が変わっても止められる」という利点があります。方向が違うと感じた瞬間に割り込めるので、探りながら進める作業とは相性がいいです。

クラウドに任せたほうがいい作業

時間がかかる作業ほど、クラウドの価値が出ます。投げておいて、別のことをしていられるからです。

典型は調査系。「このリポジトリで〇〇という機能がどこに実装されているか調べて」のような指示は、読む量が多いぶん時間がかかりますが、待つ必要がありません。

もうひとつが、独立した複数のタスク。3つのバグ修正を同時に投げておけば、順番に手をつけるより早く片づきます。

結果がプルリクエストで返ってくるので、レビューの形もそのまま作れます。ひとりで開発していても、この形は役に立ちました。

投げるときのコツは、成果物の形を先に指定すること。「調査結果をMarkdownの表でまとめて」のように書いておくと、戻ってきたものをそのまま次の作業に使えます。

両方を行き来するときの注意

ローカルとクラウドを併用すると、便利な反面ぶつかります。同じファイルを両方で触ると、変更が競合します。

避け方は単純で、同じファイルを同時に触らせないこと。クラウドに投げている間は、そのあたりのファイルをローカルで開かないと決めておきます。

もうひとつ、クラウドの結果を取り込む前に、ローカルの変更をコミットしておいてください。取り込みで上書きされる事故を防げます。

3つ目が起きたら、いったん全部コミットして状態を確定させてください。混乱したまま進めるより、確実に早く戻れます。

ブランチを分けておくのも有効です。クラウドに任せる作業だけ別ブランチにしておけば、手元の作業とぶつかりません。並行して動かすなら、置き場所を分けるのがいちばん確実でした。

それでも競合したときは、無理に手で解決しようとせず、片方を捨てて指示し直すほうが早い場面もあります。作り直しのコストが低いのは、AIに任せている作業ならではの利点です。

Codexの使い方をClaude Codeと比べる

同じ立ち位置のツールとして必ず比較されるのがClaude Codeです。どちらが優れているというより、性格が違います。

ここでは、動き方・料金・併用という3つの角度から違いを見ていきます。

動き方と得意な作業の違い

Codexはクラウドで動かせる仕組みを最初から持っていて、GitHubと組み合わせた非同期の作業に強みがあります。投げて待つ、という形が自然にできます。

一方のClaude Codeは、ターミナルで対話しながら進める形が中心。手元で会話を重ねながら詰めていく作業では、こちらのほうが噛み合います。

どちらも同じことができますが、自然に手が伸びる形が違うんですよね。作業のスタイルで選ぶのがいちばん納得できます。

機能の差は、追いかけても意味がないくらいの速さで埋まっていきます。半年前にできなかったことが、いまはどちらでもできる。比較するなら機能表ではなく、自分の作業の進め方と照らすほうが外れません。

詳しい比較はClaude CodeとCodexの違いにまとめてあるので、選定で迷っている方はそちらもどうぞ。

料金の考え方の違い

どちらも、サブスクリプションに含まれる形で使うのが基本です。単体で買うものではありません。

CodexはChatGPTの有料プラン、Claude CodeはClaudeの有料プランに含まれます。Claude Codeを使うには最低でもProプランへの加入が必要で、無料プランでは利用できません。

どちらもAPIキーを使う道はありますが、従量課金になるので初心者にはおすすめしません。上限を設定せずに使うと、金額が読めなくなります。

金額そのものより、すでにどちらのサブスクに入っているかで決めるのが現実的でした。両方に課金する必要はありません。

どちらにも利用量の上限があり、使いすぎると一時的に制限がかかります。重い作業を長時間まわす予定があるなら、上位プランを検討する場面も出てきます。

とはいえ、最初から上位プランを選ぶ必要はありません。制限に当たった回数を数えてから決めるほうが、自分の使い方に合った選択になります。

併用するときの分け方

両方使っている人もいます。ただ、なんとなく交互に使うと、どちらの設定がどうなっているかわからなくなります。

分けるなら、作業の種類で。調査と並行作業はCodex、設計を詰める対話はClaude Code、といった具合に役割を決めてしまうほうが混乱しません。

プロジェクト単位で分ける手もあります。このリポジトリはCodex、こちらはClaude Code、と決めておけば設定ファイルも混ざりません。

2つ目は地味に効きます。プロジェクトの前提を書いたファイルは、それぞれの形式で用意しないと読んでもらえません。

片方で決めたルールをもう片方にコピーしておくだけでも十分です。内容は同じでいいので、ファイル名だけ揃えて置いておいてください。

ここまで整理してしまえば、どちらを開いても同じ前提で動きます。ツールを増やすときにいちばん厄介なのは、前提がバラバラになって結果が読めなくなることでした。

Codexの使い方を一段引き上げる設定

基本が動くようになったら、精度を上げる工夫に進みましょう。どれも一度やれば効き続けます。

ここでは、前提の渡し方・指示の型・振り返りという3つを扱います。

AGENTS.mdでプロジェクトの前提を渡す

毎回同じ説明を書いているなら、それはファイルに置くべき情報です。Codexはプロジェクト直下の設定ファイルを読んでくれます。

書くのは、そのプロジェクト特有の決まりごと。使っているフレームワーク、命名の規則、触ってほしくないディレクトリ。この3つだけでも精度が変わります。

逆に、一般的なコーディング作法は書かなくて大丈夫です。知っていることを書いても、読む量が増えるだけでした。

2つ目を書いておくと、修正のあとに自分でテストを走らせて確認してくれます。これだけで往復が1回減りました。

書く量は多くて20行ほどで足ります。長く書くほど読む負荷が増えるので、「毎回説明しているか」を基準に取捨選択するのがちょうどいい塩梅でした。

よく使う指示を型として持っておく

毎回ゼロから指示を書くのは、時間の無駄です。よく使う頼み方は、メモに残して使い回してください。

効くのは目的・対象・禁止事項・確認方法の4点セット。この形さえ守れば、内容を差し替えるだけで使えます。

たとえば「〇〇のバグを直したい。触るのは△△.jsだけ」と、目的と対象を先に書きます。

そのうえで「他のファイルは変更しない。修正後にテストを実行して結果を報告して」と続ける形です。

3つ目は自分の書いたコードにも使えます。指摘を受けてから直すほうが、最初から完璧を狙うより速いです。

型を貯める場所は、テキストファイル1つで構いません。凝った管理をしようとすると続かないので、思いついたときにコピーして追記するくらいがちょうどいいです。

3つか4つ貯まれば、日常の作業はほぼ回ります。数を増やすことより、いちばん使う型を磨き込むほうが効果が出ました。

実行の記録を残して振り返る

うまくいった指示と、失敗した指示。この差を残しておくと、次から精度が上がります。

難しいことをする必要はありません。「この指示でこう返ってきた」を1行メモするだけで十分です。1週間分たまると、自分の癖が見えてきます。

私の場合、失敗の8割は「範囲を指定していなかった」ことが原因でした。気づいてからは、対象ファイルを必ず書くようにしています。

どれも直すのは簡単です。ただ、記録がないと自分では気づけません。

記録を残すもうひとつの効き目が、任せられる作業の広がりを実感できることです。1か月前には自分でやっていた作業が、いまは指示1回で終わっている——その変化が見えると、次に何を任せるかも決めやすくなります。

ほかのCLIツールとの比較も気になる方は、Gemini CLIの使い方もあわせて見てみてください。

Codexの使い方に関するよくある質問

ここでは、Codexを使い始めるときによく聞かれる疑問に答えます。

Q：Codexは無料で使えますか？

A：ChatGPTの有料プランに含まれる形で提供されているため、実質的には有料です。個人ではPlusが入口になります。OpenAIのAPIキーを使う方法もありますが、従量課金で金額が読みにくいので、慣れないうちは有料プランでの利用をおすすめします。

Q：Codexの使い方はCLIから覚えるべきですか？

A：コードを書いた経験があるならCLIかIDE拡張から、手元の環境を汚したくないならCodex webからで構いません。4つの入口は同じアカウントでつながっているので、途中で乗り換えても設定が無駄になりません。

Q：Codexに日本語で指示を出しても大丈夫ですか？

A：問題なく通ります。ただ、日本語は文が長くなりやすく、複数の目的が混ざると意図がぶれてしまうんですよね。1つの指示に1つの目的だけ入れて、触ってよいファイルを名指しすると精度が上がります。

Q：CodexとClaude Codeはどちらを選ぶべきですか？

A：すでにどちらのサブスクに入っているかで決めるのが現実的です。機能で選ぶなら、投げて待つ非同期の作業が多いならCodex、対話しながら設計を詰める作業が多いならClaude Codeが噛み合います。

まとめ

Codexの使い方でまず決めるのは、4つの入口のうちどこから触るかでした。手元をすぐ直したいならCLI、時間のかかる調査を任せたいならクラウド。この2つを押さえておけば十分です。

動かし始めてからは、承認モードの選び方が分かれ目になります。判断の軸を「危ないかどうか」ではなく「元に戻せるかどうか」に置き換えると、迷いがなくなります。

最初の1回さえ動けば、あとは自然と使う場面が増えていきます。難しいのは技術ではなく、どこまで任せるかを決めることでした。

そしてその線引きは、使いながら動かしていくものです。今日引いた線が半年後も同じである必要は、まったくありません。

いま手元にある作業のうち、失敗しても元に戻せるものはどれでしょうか。そこから1つ、任せてみてください。