ChatGPTとCodexの違いは？両方使って分かった、Codexへ切り替える境界

ChatGPTを仕事で使っていると、「Codexも使った方がいいのか？」と迷う場面があります。

私も最初は、ChatGPTは相談や調査、Codexは実作業、と考えていました。ところが両方を使い続けると、この分け方では足りなくなりました。

今のChatGPTは、私の環境ではGitHubやGoogle Drive、Gmailなど対応する接続サービスを扱えます。Workを使えば、長い複数ステップの仕事もかなり任せられます。一方のCodexも、単にコードを書くためのツールではありません。

結論から言うと、普段の仕事はChatGPTだけで十分な場面が多いです。Codexへ切り替える意味が出るのは、repositoryやworkspaceそのものを作業場所にして、変更・実行・検証を繰り返したい時です。

この記事では、OpenClaw＋Codex＋DiscordからChatGPT中心へ移った実体験も振り返りながら、2026年現在、どの時点でChatGPTからCodexへ切り替えているのかを整理します。

先に結論｜ChatGPTとCodexの違いは「相談か実行か」ではない

私が今見ている違いは、「考えるAI」と「実行するAI」ではありません。

違うのは、何を作業状態の中心に置くかです。

ここでいうrepository（リポジトリ）は、Gitで管理しているファイル群。workspace（ワークスペース）は、Codexが今開いて作業しているフォルダや環境、と考えると分かりやすいです。

私の使い分けは、ChatからWork、さらにCodexへと順番に進むものではありません。仕事の内容から第一候補を選んでいます。

• 相談・比較・短いやり取りならChatを選ぶ
• 調査や分析から成果物の作成までまとめて任せるならWorkを選ぶ
• コードや設定を変更し、テストや差分確認を繰り返すならCodexを選ぶ

小さな修正でも、実際にプログラムを直してテストするなら最初からCodexを使います。反対に、資料を集めて比較レポートを仕上げるならWorkです。どれが上位かではなく、仕事の種類と手間で決めています。

具体例｜この仕事なら何を第一候補にするか

• アイデア相談・比較・Web調査 → ChatGPT
• メール・短い記事の下書き → ChatGPT
• 複数の資料を調べ、比較レポートや表を完成させる → Work
• GitHub Issueの確認・更新 → ChatGPT
• プログラムの複数ファイルを修正する → Codex
• Pythonの処理を直してテストを回す → Codex
• Gitで変更差分を確認しながら設定を直す → Codex

もちろん、「ChatGPTにはできない」「Codexにしかできない」という意味ではありません。機能はかなり重なっています。できるかどうかより、その作業をどこで続けると自然かで選んでいます。

OpenAI公式ではChat・Work・Codexをどう分けているか

2026年10月に再確認したOpenAI公式ヘルプでは、Chatは日常的な質問や検索、ブレインストーミングなどの会話支援、Workは長い複数ステップの仕事と完成した成果物、Codexはソフトウェア開発や技術作業を中心に案内されています。

またOpenAIは、Workの利用量の仕組みはCodexと同じと案内しています。WorkやCodexではタスク内容やモデル、推論量などによって利用量が変わります。一方、通常Chatの利用量はWork/Codexの利用量表示とは別です。

そのため、「ChatGPTは考えるだけで、Codexが実行する」という説明は、今の実態には合いません。私の環境でも、ChatGPTからGitHub Issueを更新したり、Google Drive上のファイルを扱ったりできます。

逆にCodexも、ただコードを生成するだけではありません。repositoryの構造を読み、関連ファイルを変更し、コマンドやテストの結果を見て次の修正へ進む、といった反復作業が主戦場です。

なお、利用できる機能や外部サービスはプラン、権限、接続設定、提供状況によって変わります。

OpenClawからDesktop、そしてクラウド中心へ変わった

私の使い分けは、最初から今の形だったわけではありません。

OpenClawを使っていた頃は、Mac上のCodexをDiscordから呼び出す環境を作っていました。当時Codexを選んだ一番大きな理由は、「一番賢かったから」ではありません。

私の使い方では、ChatGPTのサブスクリプションの範囲でCodexを継続して使えたことが大きかったからです。一方、Claude Codeは当時の私の構成・利用条件では従量課金を意識する必要がありました。

何度も試して、失敗して、また直すエージェント作業では、1回あたりの性能差より「気にせず繰り返せるか」が運用上かなり重要でした。

その後はChatGPTのデスクトップアプリをMacに常駐させる運用へ移りました。ローカルのファイルや作業環境に近い場所にAIがいること自体に価値を感じていたからです。

しかし、ChatGPTのクラウド側でGitHub、Google Drive、Gmailなどを扱える範囲が増えるにつれ、Macを前提にしなくても終わる仕事が増えました。結果として、デスクトップアプリを常用する頻度も下がりました。

ローカル作業が不要になったわけではありません。ただし、Workもデスクトップ版では許可したローカルファイルを扱えますし、Codexにもクラウドで動く使い方があります。私がCodexに残したのは、主にコードや設定を変更し、テストや差分確認を繰り返す仕事です。

この移行の詳しい経緯は「OpenClaw＋Codex＋Discordを作って半年。結局ChatGPT中心の環境に乗り換えた理由」でまとめています。

私が通常Chatを優先する理由は、利用枠と運用の手軽さ

Workが出てきた時は、かなり使えると感じました。調査し、複数のステップを進め、ファイルやサービスをまたぎながら成果物まで作れます。

ただ、OpenAI公式ではWorkはCodexと同じ利用量の仕組みです。私の実利用でも、Workは通常Chatより利用枠を意識します。

通常Chatでは、少なくとも私の使い方ではWork/Codexの利用枠消費をほぼ気にせず使えています。そこで現在は、「WorkならできるからWorkを使う」のではなく、まずChatで終わらせられないかを考えています。

たとえば、GitHub Issueを読んで内容を整理し、そのIssueへ追記する。Google Docsの記事を作る。Gmailを確認して必要な情報を比較する。私の環境では、こうした作業はChatGPT側の接続だけで完了できることがあります。

普段の入口はChatですが、長い調査や成果物の作成ならWork、コードや設定の編集・テストが中心ならCodexを最初から選びます。WorkとCodexを上下関係にはしていません。

ChatGPTでもGitHubを触れる。それでもCodexを残す理由

ChatGPTからGitHubを扱えるなら、Codexはいらないようにも見えます。ここは「GitHubを触る」を分解すると分かりやすいです。

効率家ラボでは、GitHub Issueに現在の状態、判断したこと、次にやることを残しています。Issueを読む、検索する、コメントする、状態を更新する。こうした作業なら、私の環境ではChatGPTで十分です。

一方、repositoryの中にある複数のファイルを変更し、設定を合わせ、コマンドやテストを実行し、Gitのdiffを確認しながら直すとなると話が変わります。

この段階では「GitHubへアクセスできるか」ではなく、実際のworkspaceの状態を見ながら、変更→確認→修正を繰り返せることが重要です。私はここでCodexへ切り替えています。

つまり境界は、「GitHubを使うかどうか」ではなく、remote上の情報を扱うのか、workspaceそのものを作業場所として変更し続けるのか、です。

実際に失敗した｜workspaceが違えばCodexの検証にならない

この違いを強く意識したのが、Codexのrepo-local機能を試した時の失敗です。

GitHub上には、検証したいSkillのファイルが存在していました。ところが、Codex側で開いていたworkspaceは対象repositoryの実checkoutではありませんでした。

確認すると、git statusは「not a git repository」。つまり、Gitで管理された正しい作業フォルダにいない状態でした。

最初は「Skillの定義が悪いのか」「Codex側が検出できていないのか」と疑いましたが、そもそも検証する場所が違っていました。

この経験から、repositoryに紐づく作業を始める前に、少なくとも次を確認するようにしています。

• 今いるworkspaceが対象repositoryか
• git statusが成功するか
• 使いたいAGENTS.mdやSkillなどのファイルがworkspace上に存在するか

追加や変更の直後なら、必要に応じてセッションの再読み込みも確認します。なお、repo-local Skill自体は現在も検証中で、私は「完全に使いこなしている」という段階ではありません。

ここで得た一番大きな学びは、「Codexがrepositoryを扱える」ことだけでは不十分だということです。正しいworkspaceを作業状態として渡して初めて、変更・実行・検証をまとめて任せる強みが出ます。

Codexへ切り替えるのは「コードが出てきた時」ではない

私は、次の条件が複数重なった時にCodexへ移します。

• repositoryやworkspaceの現在状態そのものを読ませたい
• 複数ファイルを一貫して変更したい
• コマンド、build、lint、testなどの結果を見ながら修正したい
• Git diffを見ながら変更範囲を管理したい
• repository内のAGENTS.mdや設定を作業ルールとして使いたい

逆に、Pythonの処理方法を相談する、エラー原因の候補を考える、実装方針を比較する、といった相談だけならChatGPTで十分です。

私にとっての境界は、「コードかどうか」ではなく、「workspaceを継続的に変えながら検証する仕事かどうか」です。

ChatGPTだけで十分な人、Codexを試す意味がある人

ChatGPTだけで十分な人はかなり多いと思います。相談、調査、文章作成、ファイル確認、対応する外部サービスの操作までで仕事が終わるなら、わざわざCodexを増やす必要はありません。

Workも毎回使う必要はありません。通常Chatで終わるなら、その方が利用枠も運用も軽くなります。

一方、同じrepositoryの複数ファイルを頻繁に直す、修正のたびにコマンドやテストを回す、diffを見ながら変更する、といった仕事が増えてきたらCodexを試す意味があります。

OpenAIはCodexを今もソフトウェア開発・技術作業向けとして案内していますが、2026年6月にはCodex利用者の約20％が非開発者だとも公表しています。設定ファイル、Web制作、自動化、データ処理などでは、プログラマー以外にもworkspaceを直接扱う価値はあり得ます。

ただし、Gitやrepositoryの概念を持ち込むことで逆に面倒になるなら、無理に使う必要はありません。新しいツールを増やすこと自体が効率化ではないからです。

どのAIを使っても、作業状態はAIの外に残す

今の効率家ラボ運営では、最初の入口はほぼChatGPTです。それでも、作業状態そのものはAIとの会話だけに残さないようにしています。

進行状況や判断はGitHub Issue、コードや設定はrepository、記事本文はGoogle Docs、公開した内容はWordPressを正本にしています。

ChatGPTとCodexのどちらを使うかより、「どこに状態を残すか」の方が長期運用では重要でした。AIは入れ替わりますし、機能も変わります。正本までAIの会話に閉じ込めると、ツールを変えた時に引き継ぎが難しくなるからです。

ChatGPTのチャット整理やProjectsでの引き継ぎルールは「ChatGPTのチャットが増えすぎた。Projectsを長期利用して分かった整理・引き継ぎルール」で詳しく整理しています。

まとめ｜まずChat、workspace作業になったらCodex

ChatGPTとCodexを両方使ってきて、今は「どちらが高性能か」では選んでいません。

私の基本は、通常ChatでできることはChatで済ませる。まとまった調査や成果物の作成はWorkに任せる。コードや設定を変更して動作確認を繰り返す仕事はCodexを使う、という分担です。

OpenClawを使っていた時も、Codexを選んだ大きな理由は「継続して使いやすいコストだったから」でした。今も、機能を全部使い分けること自体を目的にせず、必要な道具だけを選ぶという考え方は変わっていません。

ChatGPTとCodexを選ぶときは、「どちらが何をできるか」だけでなく、自分の作業で必要なファイル操作、検証の回数、利用枠まで含めて考えると判断しやすくなります。

参考｜OpenAI公式

• ChatGPT Work and Codex
• Codex for every role, tool, and workflow