はじめに
最近は、Codexを使えばかなりの範囲まで自動で実装してくれます。
ただ、実装が終わるたびに人間が確認して、次の指示を出していては「自動開発」とは言いにくいです。
そこで今回は、ChatGPT Workに開発管理、Codexに実装を担当させて、できるだけ放置して開発を進める方法を紹介します。
実際に試している方法なので、まだ改善中の部分もありますが、かなり人間の作業を減らせています。
1. 設計書の作成
最初に、作りたいアプリの設計書を作成します。
ここが曖昧だと、WorkもCodexも「次に何を作ればいいのか」を正しく判断できません。
最低限、次の内容を決めておきます。
- アプリの目的
- 必要な機能
- 画面や操作方法
- 完了条件
- AIが勝手に実行してはいけないこと
設計書はGitリポジトリ内の docs などに保存し、**これを開発の正本（canonical仕様）**として扱います。
後から仕様を変更する場合も、基本的にはこの設計書を更新します。
ポイントは、WorkやCodexとの会話を正本にしないことです。
「前のチャットでこう決めた」ではなく、設計書を見れば現在の仕様が分かる状態にしておきます。
2. AGENTS.mdの作成
次に、リポジトリ直下へ AGENTS.md を作成します。
AGENTS.md は、Codexに毎回守ってほしい開発ルールを書くファイルです。Codexは作業前にこのファイルを読み、プロジェクト固有のルールとして利用できます。
たとえば、こんな内容を書いておきます。
- 設計書を優先する
- 変更前に既存コードを確認する
- テストを実行する
- ユーザーのファイルを勝手に削除しない
- 本番環境へ勝手に反映しない
- 管理者権限が必要な操作は停止する
重要なのは、毎回Codexへ同じ注意事項を書かなくて済むようにすることです。
設計書が「何を作るか」なら、AGENTS.md は**「どう開発するか」**を決めるファイルとして使います。
3. Workのスケジュールを作成
Workには、開発状況を定期的に確認する役割を持たせます。
たとえば1時間ごとに、
- Gitの最新状態を確認
- 設計書と実装を比較
- Codexの作業結果を確認
- 完了したタスクを判定
- 次に実装する1タスクを決定
- Codex用の指示書をGitへ保存
という処理を実行させます。
Workには実装をさせず、進捗管理と次の指示作成に集中させるのがポイントです。
危険な操作や仕様判断が必要になった場合は、自動で進めず停止するよう指示しておきます。
4. Codexのスケジュールを作成
Codexには、Workが用意した指示を実装する役割を持たせます。
定期実行では、
- Gitの最新状態を取得
- Workが作成した指示書を確認
- 指示された1タスクだけ実装
- テストを実行
- 作業結果を記録
- commit / push
まで行わせます。
ポイントは、Codex自身に次のタスクを決めさせないことです。
Codexは実装に集中し、次に何をするかはWorkに任せます。
また、1回の実行で複数タスクを進めさせず、1タスクずつ処理させると、問題が起きたときに原因を追いやすくなります。
5. WorkとCodexの役割
WorkとCodexは、同じことをさせるのではなく役割を分けて使います。
Workは開発全体を確認して「次に何をするか」を決め、Codexはその指示に従って実装します。
Work = 開発管理
Codex = 実装担当
Gitを間に置くことで、お互いの作業結果を引き継げるようにします。
ポイントは、Codex自身に次のタスクを決めさせないことです。
「何を作るか」はWork、「どう実装するか」はCodex、と分けることで自動開発を安定させます。
6. Gitを共有ストレージにする
WorkとCodexの間で情報を受け渡すために、Gitを共有ストレージとして使います。
設計書、実装状況、次の指示、作業報告をすべてGitに置いておけば、両方が同じ情報を参照できます。
たとえば、
docs/：設計書AGENTS.md：開発ルールagent/NEXT_TASK.md：WorkからCodexへの指示agent/LAST_REPORT.md：Codexの作業報告src/：実際のソースコード
という形です。
チャットの内容を記憶に頼るのではなく、Gitを見れば現在の状態が分かるようにするのがポイントです。
これによって、WorkとCodexが直接会話しなくても、Gitを通して作業を引き継げます。
7. たまにChatGPTに確認する
自動開発を始めても、完全に放置しっぱなしにはしません。
たまにChatGPTからGitの状態を確認して、
- 開発が止まっていないか
- 同じ処理を繰り返していないか
- 設計書と実装がズレていないか
- ユーザー判断待ちになっていないか
- 全体でどこまで完成しているか
を確認します。
普段はWorkとCodexに任せて、人間は必要なときだけ介入するイメージです。
うまく回れば、毎回細かく指示を出さなくても、少しずつ開発が進んでいきます。
まとめ
今回の方法では、Workに開発管理、Codexに実装を担当させます。
そして、設計書・指示・作業結果をGitにまとめることで、AI同士が同じ状態を見ながら開発を続けられるようにします。
最初に仕組みを作る必要はありますが、一度回り始めれば、毎回細かく指示を出す必要はかなり減ります。
「AIにコードを書かせる」から、「AIに開発を回してもらう」へ。
まだ完全放置ではありませんが、うまく使えば、人間は確認と判断に集中できるようになります。
