7 日 / 30 PR / 70 Issue
5 月 19 日から 25 日までの 7 日間で、私が個人用に開発しているワークマネジメントアプリに対して、30 本の PR がマージされ、70 件の Issue が起票・処理され、130 件のコミットが積まれました。
開発しているのは Next.js + Prisma + SQLite で組まれた、アイデア・タスク・ワーク（作業実績）を一元管理するためのアプリです。要求仕様は A4 で 10 ページほどあり、自分の手で実装すれば 2〜3 ヶ月はかかると見込んでいたものです。
このうち、私が手を動かした作業は次の 3 つだけでした。
- 要求仕様書（
docs/requirements.md）の作成と最終承認 - 想定外の挙動に対する介入
- 手動 E2E テスト後の Codex によるヒアリングと Issue のトリアージ
実装、PR レビュー、マージ判断、テストコード修正は、Claude Code と Codex の 2 つの AI エージェントが分業で処理しました。
私が一切コードに触れずに、 7 日間でこれだけのアウトプットを出せた ことで、今回私が構築した半自動開発の仕組みがある程度実用に耐えうるものであると実証できたように思います。
この記事では、私が 7 日間で実践したことと、運用を通じて得られた学び・気づきを整理しておきます。
2 つのエージェントに「分業させる」
このアプリ開発で最初に決めたのは、機能開発とレビューを、Claude Code と Codex で分業させるための開発ワークフロー でした。
具体的には、以下のような役割分担としました。
- Claude Code：Issue 起票・Issue 実装・PR 修正・E2E スモーク実行
- Codex：Issue 詳細化・PR レビュー・マージ判定
両者ともベースのモデル能力は十分に高く、原理的にはどちらか 1 つに全工程を任せることもできます。それでもあえて切り分けたのは、自分の書いたコードを自分でレビューしても、まともなレビューにならない という、人間のチーム開発でよく知られた制約が AI エージェントにも当てはまると考えたからです。
実装と詳細化・レビューでは、求められる思考の方向が逆を向いています。
実装は「決められた仕様を最短距離でコードに落とし込む」プロセスであり、詳細化・レビューは「決められたつもりの仕様を疑い、抜け漏れを探す」プロセスです。
同じモデルに両方を担わせると、観点が混ざります。
実装した思考の延長線でレビューすると、当然ながら「実装時に見落としたもの」も同じ理由で見落とされる。
これは構造的な問題であり、モデル性能を上げても解消しないと考えました。
そこで、プロンプトと運用ルールを切り分けることで、2 つの「役割」を持った別エージェントとして動かす設計にしました。
モデルの性能が同じでも、 役割を明示的に分けることで観点を分離できる。半自動開発における品質確保の根幹は、ここに置きました。
4 時間サイクル × 6 回 / 日の発火構造
実際のワークフローは、以下のようなループで構成されています。
このループは 4 時間サイクル × 1 日 6 回（実装バッチのみ 5 回）で発火します。
ポイントは、バッチごとに発火時刻を 1 時間ずつずらしている ことです。
- 00:00 / 04:00 / 08:00 / 12:00 / 16:00 / 20:00：Codex Issue 詳細化バッチ
- 01:00 / 05:00 / 09:00 / 13:00 / 17:00 / 21:00：Codex PR レビューバッチ
- 02:00 / 06:00 / 10:00 / 14:00 / 18:00 / 22:00：Claude Code PR 修正バッチ
- 03:00 / 07:00 / 11:00 / 15:00 / 19:00：Claude Code Issue 実装バッチ
- 23:00：Claude Code E2E スモーク実行バッチ（1 日 1 回）
詳細化 → レビュー → 修正 → 実装 の順に 1 時間ずつずらしているため、同一サイクル内で前段の出力が次段のインプットになる 構造になっています。次のサイクルを待たずに処理が流れる、いわばパイプライン化です。
なお、最初の試験運用は各バッチを 1 日 1 回からスタートさせました。
2 日間ほど動かして滞留や暴走が起きないことを確認した時点で、3 日目から一気に 1 日 6 回まで増強しています。「安定すると判断した時点で頻度を一気に上げる」というのは、後から振り返って最も効いた意思決定の 1 つでした。
設計の核となった 4 つの判断
このワークフローを成立させるために、特に重要だった設計判断が 4 つあります。
ラベルに状態を集約する
Issue / PR の状態管理を 6 つのラベルだけに集約しました。
-
Issue 用：
needs-user-review/needs-codex-refinement/ready-for-cc-implementation/cc-implementing -
PR 用：
needs-codex-review/ready-for-cc-revision
各バッチは「該当ラベルが付いているか」だけを見て自分の仕事を判断します。
エージェント同士は直接通信せず、 GitHub のラベルを共有メモリとして使うことで状態を同期する 構造です。これにより、バッチ間の依存関係が消え、各バッチが独立して安全に動けるようになりました。
1 PR に 3 Issue を集約する
Claude Code の実装バッチは、ready-for-cc-implementation ラベルが付いた Issue から最大 3 件をピックして、 同じブランチ・同じ PR にまとめて実装します。
3 件を別ブランチ・別 PR で並列に進めると、同じファイルを触ったときに衝突が起きやすく、Claude Code 同士がそれを解決し合う追加コストが発生します。
同じブランチに 3 件分のコミットを積めば、PR 間の衝突はそもそも生まれません。マージ方式を merge commit に固定して squash / rebase を無効化することで、レビュー単位は「PR」、履歴単位は「コミット」に切り分け、 PR でオール or ナッシングの判定をしつつ、後から git log で Issue 由来のコミットを追える 構造にしています。
なお、3 件という数は試行用に保守的に置いただけで、トークン消費量や処理時間を見る限り一度に 10 件程度は捌けそうでした。
本文を不変にし、コメントで追記する
Codex の詳細化結果やレビュー結果は、Issue / PR の本文には書き込みません。すべてコメントとして追記し、冒頭に ## [Codex 詳細化 (2026-05-22)] のようなマーカー行を置きます。Claude Code はこのマーカーで最新の Codex コメントを機械的に検索します。
本文（最初に書いた要求仕様）は不変のままで、エージェント間のやり取りは時系列のコメント履歴として積まれていく。そうすることで、あとから私が Issue / PR を読み返したときに、実装・修正完了までの流れが追えるようになっています。
新規 Issue の起票を原則禁止する
エージェント側からの新規 Issue 起票は、原則として禁止しました。
実装中に発見した課題や改善案は、すべて当該 PR の description またはコメントに残し、Issue 化要否は私が判断します。
理由は、自動エージェントが新規 Issue を無条件に起票し続けると完了判定（Issue / PR の残件 0）が破綻し、ループが収束しなくなるためです。
これは地味なルールに見えて、ワークフロー全体の収束性を担保する根幹です。
「気付き」を Issue として吐き出す権利を人間に残す ことで、エージェントが自走しているのに完了判定が成り立つ、という閉じたループが成立しました。
「使いながら育てる」を組み込んだ 2 つの特例
新規 Issue 起票禁止のルールには、2 つの特例を設けています。
そして、この特例こそがワークフローを実用域に押し上げました。
特例 1: E2E スモーク失敗の自動起票
毎日 23:00 JST に、Claude Code が pnpm e2e で主要動線のスモークテストを実行します。
失敗を検知した場合は、テンプレートに沿って Issue を自動起票し、そのまま通常の詳細化 → 実装ループに乗せて修正します。
これは「日々の自動デグレ検知 → 修正 → 再検知」のサイクルを回すための仕組みです。
朝に GitHub を見ると、夜中のうちに E2E が失敗していて、それを起点に新しい Issue と PR が積まれている、という運用が成立しました。
特例 2: ヒアリング駆動の Issue 起票
もう 1 つは、ユーザーヒアリング駆動の起票フローです。流れは以下の通りです。
- 私が手動でアプリを触り、操作感を Codex に逐次フィードバックする
- Codex がそれを
docs/user-hearings/YYYY-MM-DD-*.mdにヒアリングシートとして保存する - 私が「このシートから Issue を起こす」と Claude Code に明示的に指示する
- Claude Code がシートから明示発言と推測インサイトの両方を抽出し、
[Hearing] ...タイトルの Issue として起票する
このフローで起票された Issue は、全 70 Issue 中 40 件、全体の半分以上を占める に至りました。
要求仕様書を起点に Claude Code が起票した Issue が大半を占めるだろうという当初の想定は外れ、実利用ベースのフィードバックがワークフローへの主要な供給源 となったのです。
仕様書は「作る前」の想像で書かれたものです。実際に動くものを触ると、想像していなかった違和感や改善要望が必ず見つかります。
この差分を適切に取り込むことがプロダクト開発における価値の源泉である という、それ自体は使い古された主張が、半自動開発の運用の中で改めて浮かび上がりました。
7 日間の運用から見えたこと
7 日間の運用を通じて、私に残った仕事は次の 3 種に集約されました。
- 仕様策定：何を作るか、なぜ作るか、優先順位をどう置くかを決める
- 例外対応：エージェントが想定外の動きをしたときに介入する
- ユーザーヒアリング：使い勝手に関するヒアリングを受け、改善 Issue を起票・トリアージする
実装・コードレビュー・テストコード修正・マージ判断・ブランチ整理は、すべてエージェント側に渡せました。半自動開発が実用に耐えうるものになったという感触は、この事実から得られたものです。
予想外だったのは、要求仕様書を起点に起票した Issue ではなく、 実利用ベースのヒアリングから生まれた Issue が全体の主流を占めた ことです。動かしてみないと出てこない違和感が、想定よりはるかに多くワークフローの供給源となりました。
仕様策定とトリアージは、机上で完結する仕事ではなく、 実際に動いているものに触れた上で行うべき仕事 なのだと、運用の中で改めて確認できました。
なお、本記事で触れた設計判断それぞれの根拠（ラベル設計の詳細、サイクル発火順の意図、コメント追記方式の運用 など）は、別記事『Claude Code と Codex の半自動開発ワークフローの設計詳細』に再現用リファレンスとしてまとめています。
仕組みの構築過程で踏んだ想定外のワナ（GitHub Free プランの制約、gh CLI への統一、worktree モードのブランチ命名 など）は、もう 1 本の別記事『Claude Code と Codex の半自動開発で踏んだ 6 つのワナ』に集約しました。
同じ仕組みを再現したい方は、本記事と併せて参照してください。