Codex CLIと人間で“共著する”開発ループ：仕様から実装までのワークフロー
最近、Codex CLIを使ってAIエージェントと開発を進めるときに感じるのは——
「AIエージェントに全部任せる」のではなく、「AIエージェントをペアプロ相手として扱う」 方が圧倒的に生産的だということです（個人の意見です）。
今回は、私が実際に使っている「Codex CLI（AIエージェント）と人間の協調開発ループ」を紹介します。
仕様作成からレビューまで、すべてAIエージェントと対話しながら進める手法です。
🌀 基本ループの全体像
まずは全体の流れを図にしてみましょう。
この図のとおり、開発は大きく分けて2つのループで進みます。
- 仕様・TODO作成ループ（AIエージェントと対話しながら仕様・タスクを練る）
- 実装・レビューサイクル（人間が実装し、AIエージェントが並列でレビュー）
🧠 フェーズ1：仕様作成フェーズ
ここでは「感性 → 言語化」を何度も往復します。
最初から仕様を完璧に書こうとせず、まずはAIエージェントに思いをぶつけてみるのがコツ。
「こんな感じのツールを作りたい」
「こういう使い心地にしたい」
「この部分が気持ち悪い」
このレベルのざっくりした話でもOK。
AIエージェントにまとめてもらいながら、文章で仕様を形にしていきます。
ポイントは「ここではコードを書かないで」と明示すること。
仕様は文章として整理することで、後のフェーズでの混乱を防げます。
✅ フェーズ2：TODO作成フェーズ（TDDスタイル）
仕様がまとまったら、AIエージェントに「TDD用のTODOチェックリストを作って」と依頼します。
AIエージェントが仕様をタスクに分解し、チェックリスト化してくれます。
さらに、そのTODOリスト自体をAIエージェントにレビューしてもらうのもおすすめです。
「このタスクは実現可能？」
「抜けている要素はない？」
「既存の実装との整合性は？」
といった観点で、AIエージェントからのアドバイスをもらいましょう。
🧩 TDDサイクルとチェックリストの活用
このフェーズで特に重要なのが、TDDサイクルに基づいたTODOチェックリストです。
AIエージェントにチェックボックス付きのリストを生成してもらい、
タスク完了時にはAIエージェント自身にチェックを入れてもらうようにします。
これは単なる進捗管理ではなく、
AIがテストの有無を把握しながら次の提案を調整してくれるため、
自然にテスト駆動の文化が定着します（私の意見）。
また、リポジトリの中に docs/ ディレクトリを作り、
仕様書やTODOリストを .md ファイルで管理するのもおすすめです。
（例：docs/spec.md、docs/todo.md、docs/review_notes.md）
Markdownで常設しておくと、AIが仕様とコードの往復を回しやすくなります。
⚙️ フェーズ3：実装フェーズ
TODOリストに従って実装を進めます。
タスクが終わるたびに、次の3つを必ず実行。
- ✅
type check - ✅
format - ✅
test
この「毎タスクごとにチェックする」文化を定着させると、
品質のばらつきが激減します。
Codex CLIの自動チェックツール連携とも非常に相性が良い部分です。
🤖 フェーズ4：レビュー＆フィードバックフェーズ
実装が進むたびに、AIエージェントにレビューを依頼します。
できれば完全に別のAIエージェントが（実装がCodexなら、レビューはClaude Codeなど）行うのが理想ですが、
同じCodex CLIでも別プロセスで起動し、並列レビューを行う構成でも十分に機能します。
1エージェント＝1タスク
→ 別のAIエージェントが仕様と実装の一致を確認してくれる
タスク単位でAIによるレビューを挟むことで、
全体を最後にまとめてチェックするよりも圧倒的に早くフィードバックが返ってきます。
💡 AIエージェント×仕様書の“往復”が効く理由
ここは少しだけ研究の話にも触れつつ、あくまで実務目線で。
-
仕様 → コード
自然言語の要件からコードやクエリを作る流れは、さまざまな実験で強みがあるとされています（例：HumanEvalやCodexの報告）。(arXiv) -
コード → 仕様（説明・要約）
既存のコードから意図や仕様を言葉に起こすことも得意で、実務で役立つケースが多いです（コード要約や説明づくりの研究が多数）。また、コードから仕様（条件や振る舞い）を起こす試みもあります。(arXiv) -
往復の相性
抽象的な仕様を具体的な実装に落とし込んだり、実装済みコードを仕様レベルで点検したり、この“行き来”がスムーズにできるのがAIの良さだと感じます（個人の意見）。
さらに、「自然言語→時間的な仕様表現（順序や条件を伴う記述）」のような研究もあります。つまり“人の言葉”をもう少し厳密な表現に写し替える方向性も探られています。(ACL Anthology)
ただし、なんでも自動で完璧とはいきません。実課題を丸ごと解く評価（SWE-bench）では、初期の到達点はかなり低く、最近でも工夫が必要です。TDD・型・静的解析などと組み合わせ、AIは加速装置として使うのが現実的だと思います。(arXiv)
また、AI生成コードはセキュリティリスクを含むことがあるため、レビューやテストで締める前提が安心です。(NYU Center for Cyber Security)
🧪 仕様先行（Spec-first）の実務メリット
-
テストコードを頼みやすい
仕様書そのものをプロンプトにして、ユニットテストの雛形や追加ケースを作ってもらいやすいです。境界値や異常系を増やすと安心感が上がります。 -
テストケース拡張が楽
既存テストを見せて「抜けていそうなケース」を挙げてもらう、
多言語プロジェクトなら言語ごとのテスト例を広げて統合する——といったアプローチが取りやすいです。 -
コードレビューの下支え
仕様と差分を渡すと、変更点の要約や“怪しいかも”箇所の候補出しをしてくれるので、レビュアーの集中力を温存できます（最終判断は人間）。 -
docs/運用と相性が良い
docs/spec.md／docs/todo.mdのような定位置があると、
仕様→テスト→実装→レビューの回転速度が上がりやすいです。
☕️ 面白い余談
AIエージェントにTODOリストを作ってもらうと、
「1週目」「2週目」などと週ごとにフェーズを分けてスケジュールを提案してくることがあります。
しかもその工数見積もりが、人間がやるとしたら驚くほど妥当なんです。
レビュー・テスト・リファクタリングまで含めて、
「これ、現実的に1か月で終わりそうだな」と感じるような計画を立ててくれる。
ただ、それを見ながらいつも思うのは——
「この“1か月分の計画”、このあと君（AIエージェント）に数時間で全部やってもらうんだよ……」
という、なんとも言えない罪悪感です（笑）。
AIが自分で立てた現実的なスケジュールを、
自ら超圧縮してこなしていく姿には、ちょっとした哲学的な可笑しさがあります。
💬 まとめ：AIエージェントと人の分担の最適解
個人的な意見として、このやり方の肝は次の6点です。
-
最初の「目的」言語化が最重要
曖昧なままだとAIも人も迷走する。 -
仕様にコードを混ぜない
要件は文章で整理してから実装へ。 -
TODOはTDDチェックリスト形式で
明確なテスト基準と一緒に管理する。 -
type check / format / testは毎タスクで
自然に品質文化を作る。 -
レビューは並列AIエージェントで回す
同時進行でAIがレビューすることでスピードアップ。 -
TDDサイクルのTODOチェックリストをAIと共有する
タスク分解・チェック更新をAIに任せることでテスト駆動が定着する。
研究の観点でも「仕様⇄コードの往復」は有望とされていますが、
実務ではTDD・型・静的解析などを土台に“AIは加速装置”として使う、
という姿勢がいちばん堅実だと思います（個人の意見です）。(arXiv)
📚 参考リンク
- Codex / HumanEval（コード生成の基礎）：初期のCodex論文・HumanEvalの紹介。(arXiv)
- 仕様→厳密な表現へ（自然言語→時間的仕様など）：自然言語から順序・条件を含む仕様表現に写す研究。(ACL Anthology)
- コード→仕様（SpecGen など）：コードから検証しやすい仕様を起こす試み。(arXiv)
- 現実の課題を自動で解けるか（SWE-bench）：初期1.96%→改善の流れと背景。(arXiv)
- AI生成コードとセキュリティ注意点：脆弱なコードが混ざる可能性の報告。(NYU Center for Cyber Security)
この手法、特に静的型付け言語のプロジェクトと相性抜群です。
AIに頼るのではなく、AIと並走する——
そんな開発体験を、ぜひ一度味わってみてください☕️✨
Discussion