Codex CLI でつくる、Issue から merge までの開発フロー

「CyberAgent x OpenAI Codex User Community Event」（2026/03/24 開催）の登壇資料です。
https://cyberagent.connpass.com/event/386663/

Transcript

1. Codex CLI でつくる、 Issue から merge まで の開発フロー
2. 目指したもの 人間の開発体験を壊さない 自動開発フロー
3. ・AI エージェントを開発に入れるとできることは 増える ・その分、運用が複雑になりやすくなる ・そこで、新しい特別な開発プロセスは作らない ・普段の GitHub 上の開発フローの中に、自然に AI を組み込む ・開発者の行動を大きく変えず、既存のレビュー やマージの考え方を残したまま、自動化できる部 分だけ前に進める なぜ開発体験を重視すべきか
4. 全体のフロー ・Cursor のブラウザ自動開発事例を参考に、Planner, Worker, Judge を導入 　→ https://cursor.com/ja/blog/scaling-agents ・自動化されていても、開発者から見た体験は GitHub ネイティブに保たれる ・AI が閉じた環境で開発するのでなく、開発者が普段見ている GitHub 上で進む
5. ・PRD や design doc を中心にした spec driven development は採らない ・ドキュメントはどうしてもコードより先に古くなりやすい ・運用を続けるほど差分管理のコストが増える ・業務で SDD を導入し3ヶ月ほど運用したが、次第にコードとの乖離が増えて いった ・ドキュメントを増やすより、コードと GitHub 上の状態を中心に進める構成 を選んだ あえて採らなかった設計
6. ・AI が自律的に動けることより、人間がいつでも介入できることを最も重視 ・業務では他のコーディングエージェントや開発フローを試したが、経験的 に問題発生時の修正の導線が曖昧になる ・AI に流せるところは流しつつ、開発者が GitHub 上で状況を把握できる構成に ・必要であれば止めたり、修正したりできるように ・Codex による自動化の価値は、無人化そのものではなく、人間が関与しやす いままシームレスにすることにあると感じた 最重要視した設計原則
7. ・全ての変更を同じように扱うのではな く、ラベルで変更の規模を分類した ・small や medium ラベルの変更は自 動でマージまで進める ・large や特定ラベルが付いたもの は除外し、手動マージを必要とする ・自動 or 手動の2択でなく、変更の大きさやリスクに応じて段階化すること で、速度と安全性のバランスをとりやすく 自動化レベルの切り分け
8. ・既存の開発フローを大きく変えずに済んだ ・新しいルールやドキュメントを増やさず、GitHub 上の issue, PR, merge という見慣れた単位での自動化は、他メンバーにとっても理解しやすい ・機能を増やすことより、どれだけ普段の開発体験に自然に接続できるかが重要 ・Codex の価値は、この自然な組み込みやすさ シンプルさは導入しやすさ ・基本的に人間が関与する必要の無い品質で issue 化、実装、レビューなどを 行う点でもシンプルさに寄与
9. ・コンフリクト解消、DB マイグレーションファイルの順序関係などがハードルに ・変更が大きくなるほど、人間の判断が必要な場面が増える ・まず GitHub ネイティブで、人間がいつでも戻ってこれる形が現実的 ・AI を既存の開発プロセスに無理なく組み込むための現実的な境界線を設定で きるかどうか 複雑な変更やスケールに課題 ・今回の学びは、AI 開発フローは複雑に作るほど良いわけではない