GPTとCodexを分けて使う開発方法が注目
AIを使ったプログラミングでは、
「Codexに要件を渡せば、そのまま全部作ってもらえるのでは？」
と考えたくなる。
小さな機能追加や単純な修正なら、それでも十分なケースはある。
しかし、既存コードが大量にあり、複数の機能や外部サービスが絡むプロジェクトでは事情が変わる。
最初の要件が曖昧なまま実装を始めると、
- 必要以上に広い範囲を変更する
- 既存設計と合わないコードを追加する
- 本来の目的とは違う機能まで作る
- 巨大な変更になってレビューしにくくなる
- 途中で前提が崩れ、大量の手戻りが発生する
といった問題が起きやすい。
そこで考えられるのが、GPTとCodexを「考える役」と「実装する役」に分ける方法だ。
① まずGPTで「何を作るのか」を固める
最初からコードを書かせない。
まずGPT側で、プロジェクトの戦略を整理する。
特に明確にしておきたいのが、次の4点だ。
目標（Goal）
何を実現すれば、このプロジェクトは成功なのか。
境界（Scope / Boundary）
何を変更してよく、何を変更しないのか。
競合・参考実装（Competitors / References）
似たサービスやOSSは、どのような設計を採用しているのか。
受け入れ条件（Acceptance Criteria）
何ができれば「完成」と判断できるのか。
ここが曖昧な状態でCodexに実装を任せると、AI自身が不足している前提を補完しながら作業することになる。
それよりも、
「完成とは何か」を先に人間とGPTで決める
ことが重要になる。
② GPTにCodex向けの指示書を作らせる
次に、整理した要件をそのまま長文でCodexへ投げるのではなく、実装担当者が理解しやすい形に変換する。
たとえば、
この段階ではコードを変更しない。
まず既存リポジトリを読み取り専用で調査する。
関係するディレクトリ、主要クラス、依存関係、既存テストを確認する。
そのうえで変更候補とリスクを報告する。
という形だ。
ここでポイントになるのが、いきなり実装させないこと。
既存システムでは、仕様書よりも実際のコードのほうが正しい場合も少なくない。
そのため、
要件整理 → リポジトリ調査 → 実装計画 → コード変更
という順番にする。
③ Codexにリポジトリを調査させる
ここからCodexの出番になる。
Codexには実際のコードベースを調査させ、
「この機能を追加するなら、どこを変更する必要があるか」
を洗い出してもらう。
この段階では、コードを書くこと以上に、
既存システムを理解させること
が重要だ。
たとえばWebサービスなら、フロントエンドだけを変更すればよいと思っていた機能が、調査するとAPI、データベース、認証、キャッシュ、テストまで影響することがある。
先に調査レポートを作らせれば、こうした依存関係を実装前に確認できる。
④ 大きな開発を複数のPRに分解する
調査が終わったら、巨大な変更を一度に実行するのではなく、複数の小さなPR（Pull Request）へ分解する。
たとえば、
PR1：データモデル変更
↓
PR2：バックエンドAPI実装
↓
PR3：フロントエンド対応
↓
PR4：テスト追加
↓
PR5：ドキュメント・最終調整
といった具合だ。
これには大きなメリットがある。
変更内容をレビューしやすくなり、問題が起きたときも「どの変更が原因だったのか」を追いやすい。
AIコーディングでは、一度にAIへ渡す作業範囲を小さくすること自体が品質管理になる。
GPTは方向、Codexは実装
この開発方法を一言で表すなら、
GPTが方向を決め、Codexがコードベースと実装を担当する
という分業になる。
| 作業 | ChatGPT | Codex |
|---|---|---|
| アイデア・要件整理 | ◎ | ○ |
| ゴール・完成条件の定義 | ◎ | ○ |
| スコープ整理 | ◎ | ○ |
| アーキテクチャ検討 | ◎ | ◎ |
| リポジトリ調査 | ○ | ◎ |
| コード変更 | ○ | ◎ |
| テスト実行 | △ | ◎ |
| PR作成・レビュー支援 | ○ | ◎ |
これは「どちらのAIが優秀か」という比較ではない。
仕事のフェーズによってAIの使い方を変えるという考え方だ。
なぜ同じOpenAI系なのに分けるのか
ここで疑問になるのが、
「GPTとCodexは同じOpenAI系なのだから、一つに任せればいいのでは？」
という点だ。
しかし、人間のソフトウェア開発でも、
プロダクトマネージャー
→ アーキテクト
→ エンジニア
→ レビュアー
と役割を分ける。
同じ会社の人間だからといって、一人ですべての工程を担当する必要はない。
AIでも同様に、思考のフェーズと実装のフェーズを明示的に分離することで、それぞれの作業目的を明確にできる。
重要なのはAIそのものを分けることではなく、
「考える工程」と「コードを変更する工程」を分けること
にある。
小規模開発では、ここまで分けなくてもいい
もちろん、すべての開発でこの方法が必要なわけではない。
CSSを少し変更する、単純なバグを修正する、関数を一つ追加するといった作業なら、Codexへ直接依頼したほうが速いこともある。
一方、
既存コードが数万〜数十万行ある、複数サービスにまたがる、データベース変更を伴う、本番環境への影響が大きい、といった開発では、最初の設計が重要になる。
つまり、プロジェクトが大きくなるほど、
「AIにコードを書かせる能力」より「AIに何をさせるかを設計する能力」
の重要性が高まる。
AI開発で変わるのは「プログラミング」だけではない
生成AIによる開発というと、「人間の代わりにAIがコードを書く」という部分に注目が集まりやすい。
しかし、より大きな変化は別のところにある。
人間が、
要件を定義する
→ AIに調査させる
→ 作業を分解する
→ AIに実装させる
→ 人間が検証する
という、AIを含めた開発工程そのものを設計するようになることだ。
AIが高性能になるほど、巨大な指示を一度に渡す誘惑も強くなる。
それでも複雑なプロジェクトでは、
「まず考える」「次に調べる」「小さく分ける」「最後に実装する」
という従来のソフトウェア開発の基本が、むしろ重要になってくる。
GPTとCodexの役割分担は、その考え方をAI開発に持ち込んだ一つの方法と言えるだろう。