ChatGPTでエラーの原因を聞くのは数分で済むのに、同じ修正を手元のリポジトリに落とそうとすると型が合わなかったり既存のテストが落ちたりする——そんな経験は多くの開発者にあるはずです。問題は「回答の質」ではなく、タスクが必要とする文脈が丸ごとプロジェクトの中にあることが多いからです。ChatGPTとCodexは入り口が違うだけで、どちらが優れているかという話ではありません。本稿では、成果物をどこに置くかを軸にした選び分け方を整理します。
ChatGPTとCodexの違いは「どこで作業するか」
両者の能力には重なりがありますが、設計上の重心が違います。まずは具体的なタスク種別で対応先を揃えておきます。
| タスクの性質 | ChatGPT 向き | Codex 向き |
|---|---|---|
| 問題を整理したい | 概念の説明、方針の比較、資料の要約 | リポジトリ内の呼び出しチェーン追跡、実装位置の特定 |
| 成果物を出したい | 下書き、レポート、表データの分析 | リポジトリ内のドキュメント・設定・コード編集と diff 確認 |
| コードを扱う | エラーの説明、サンプルの提示 | 認可されたプロジェクト内でのファイル編集、コマンド・テスト実行 |
| 検収の仕方 | 事実・出典・数値の照合 | ファイル差分、テスト出力、未検証範囲の確認 |
要するに、素材が会話ウィンドウや数個のファイルで完結するなら ChatGPT、プロジェクト全体に広がっているなら Codex が妥当です。OpenAI の ChatGPT ガイド は Q&A と資料処理の両方を扱っており、「会話専用」ではありません。OpenAI の Codex ドキュメント は、Codex を開発環境内でプロジェクトタスクを扱うツールとして位置付けています。実際に何ができるかは、提供する入口・権限・コンテキスト次第です。
ChatGPTの使い方:問いを立て、資料を整える
先に状況を整理したいときは、ChatGPT に場面を直接書き込みます。
「この API ログに考えられる失敗要因を、根拠の強さ順に並べてください。続いて、追加で集めるべき情報を教えてください。」
ファイルを渡して要約・比較・分析・下書きをさせることもできます。使える成果物を得たいときは、入力素材・処理ルール・出力形式・受入基準を一度のメッセージで指定しておくと手戻りが減ります。結果を受け取ったら、必ずファイルを開いて数値・引用・形式を自分で突き合わせます。ChatGPT が特定のファイル・ウェブページ・外部ツールにアクセスできるかどうかは、現在使っている入口、アカウントの権限、実際に許可した範囲に依存します。
コードについても議論できますし、関数のサンプルを書くこともできます。ただし「使えそうに見えるスニペット」と「自分のプロジェクトでマージされテストが通るコード」は別物です。前者は会話内で済みますが、後者には本物のプロジェクト文脈と実行結果が必要です。
Codexの使い方:プロジェクトの中で変更と検証を回す
Codex は、目的が明確で開発環境内での実行が必要なタスクに向いています。例えば次のような指示です。
「ログイン API はユーザー名が空のとき 500 を返します。まず再現経路を特定し、現行のレスポンス形式を保ったまま修正、関連テストを追加して実行してください。最後に変更ファイルと未検証の部分を列挙してください。」
この書き方は、挙動・範囲・制約・受入基準を一度に伝えています。Codex は認可されたプロジェクト環境でファイルを読み、コードを編集し、既存ツールを実行して差分とテスト結果を返します。OpenAI はデスクトップアプリ、CLI、IDE 統合という形で Codex を提供しており、実際にできることはアカウントと環境に依存します。
コードを書かない場面でも Codex は使えます。ドキュメントや設定がリポジトリにあり、変更がビルドチェックを通る必要があるなら、diff とコマンド実行だけで価値があります。ただし、差分が出たからといって正しいとは限りません。「テスト成功」「テスト未実行」「人間レビュー未実施」は別々の状態として記録してからマージを判断します。
ChatGPTとCodexを同じタスクでつなぐ例
「ログイン API がユーザー名空で 500 を返す」件を例にとると、私は次のように分担させます。
-
先に ChatGPT で期待挙動を整理します。本来返すべきステータス、既存のレスポンス形式、見落としがちな境界条件を書き出します。すでに手元に資料があるなら飛ばして構いません。
-
次に Codex に境界を明示した指示を渡します。
空ユーザー名が 500 を引き起こすパスを特定してください。現行のレスポンス形式を保持し、関連バリデーションとテストだけを変更します。先に問題を再現するテストを追加し、関連テストを実行してください。最後に変更ファイル、実行したコマンド、未検証の部分を列挙してください。
-
最後に自分で diff を確認します。新しいテストは元の問題を本当に捉えているか、他のログイン分岐に意図しない変更が入っていないか。テストが実行されなかった場合は「未実行」と残し、「修正済み」で検収を代替しないようにします。OpenAI のプロンプトガイド も、目的・文脈・明示的要件の重要性を強調しています。
ChatGPT・Codex・モデルAPIは別のレイヤー
ChatGPT は資料や問いと対話する入口、Codex はタスクとプロジェクトに向き合う入口、API はプログラムがリクエストを送って応答を受け取るチャネルです。API 呼び出しが成功したからといって、Codex がリポジトリの修正を終えたことにはなりませんし、ChatGPT が共有していないローカルファイルを読んだことにもなりません。
2026 年 10 月 29 日、https://api.crazyrouter.com/v1/chat/completions に対して gpt-4o-mini を指定した中国語要約リクエストを非ストリーミングで送りました。応答は HTTP 200、応答モデルは gpt-4o-mini-2024-07-18、finish_reason は stop、入力 53 tokens、出力 15 tokens。ただしタスクは「漢字 20 文字以内」でしたが、実際の出力は 22 文字でした。この記録が示すのはその 1 回の API 呼び出しが成功したこと、および文字数制約を満たしていないことだけです。ChatGPT と Codex の比較試験ではなく、両製品のふるまいも推定できません。Crazyrouter の Chat Completion ドキュメント にリクエストフィールドとレスポンス形式があります。
Codex をまだ入れていなければ、OpenAI の Codex ページ から環境に合う入口を選び、小さく明確なプロジェクト課題で試すと良いです。実際に Codex CLI をサードパーティ API と接続する必要が出てきたら、Crazyrouter の Codex CLI 連携ガイド を参照してください。サードパーティ API の設定は、OpenAI プロダクトアカウントの権限や使用量とは別物です。
初めてChatGPTとCodexに依頼するときのテンプレート
ChatGPT に資料分析を頼むときの型です。
目的: 3 件の見積を比較し、調達判断を提案する。
入力: アップロード済みの 3 件の見積 PDF。
ルール: 通貨と税基準を揃える。欠損項目は推測せず、別途一覧化する。
成果物: 比較表 1 点、300 字以内の提案文。
受入: 主要な数値ごとに、どの見積が出典かを明示する。
Codex にプロジェクトタスクを頼むときの型です。
目的: ログイン API がユーザー名空のとき 500 を返す問題を修正する。
範囲: エンドポイント、バリデーション、関連テスト。
制約: 現行のレスポンス形式を保持する。無関係モジュールには触れない。
受入: 問題を再現するテストを追加、関連テストを実行、変更内容と未検証部分を列挙する。
両テンプレートに共通する柱は目的・素材・制約・受入基準の 4 点です。Codex のタスクでは、プロジェクトパス・再現手順・関連ファイルも可能な限り具体化します。でなければ最初の数ステップが文脈探しに消えます。
迷ったら最初に二文書き出すのが近道です。成果物はどこに置くのか、どうやって検収するのか。文字寄りなら ChatGPT から、プロジェクト寄りなら Codex から。両方にまたがるタスクは、名前の格ではなく段階ごとの受け渡しで分担するほうが結局速く済みます。