チケットからマージまで──AI駆動開発の日常ループと多層ゲート

チケットからマージまで──AI駆動開発の日常ループと多層ゲート

AI駆動開発の導入は、2つのモードに分かれます。

立ち上げについては「既存リポジトリでAI駆動開発を始める順序」で扱いました。本記事は定常運用、つまり型ができた後に毎日どう回すかです。機動性はここで担保します。

日常ループ：チケットからマージまで

チケット
   ↓
PRD（なぜ・何を変えるか）                  ← 👤 承認ゲート①
   ↓
ユースケース／テストケース／ステート管理図 の更新   ← 👤 承認ゲート②
   ↓
実装                                      ← ⚙ Hooks（lint・型・関連テスト）
   ↓
テストの実施 ──（落ちたら実装へ戻す）
   ↓
マージ                                    ← 影響ドキュメントの更新が条件

各ステップの担当と判定基準を整理すると、こうなります。

このフローの肝は3つです。

1. 実装より前にテストケースが確定している

AIに渡すのは文章の仕様ではなく、通すべきテストです。「審判を先に決めてから書く」という順序を、チケット単位で強制する構造になっています。審判の作り方そのものは「Mockを「審判」にする」で扱っています。

2. ドキュメントは「作る」ものではなく「更新される」もの

チケットごとに影響範囲の差分が入るので、ドキュメント整備が開発と一体化します。 整備を別プロジェクトとして走らせると、必ず実装に追い越されて腐ります。

影響したドキュメントを更新したかをPRのチェック項目にして、マージ条件にするところまでやって初めて機能します。

3. ステート管理図を必ず通す

業務システムの事故は、状態遷移の抜け（この状態でこの操作をしたらどうなるかが未定義）から起きます。ここはエージェントが最も壊しやすい部分でもあります。

図を実装前に更新すると、抜けがコードになる前に見つかります。 逆に、実装後に図を更新する運用にすると、図は実装の写しになるだけで検出装置として機能しません。

重さはチケットの大きさで変える

固定費の高い工程を全チケットに課すと、機動性が死にます。

判断が分かれる場合は、「この変更は状態遷移に影響するか」で切ると実務的です。影響するならステート図を通し、しないなら省略します。

なぜこれで速くなるのか

各ステップの一次生成をAIが担えるからです。

• チケット → PRDのドラフト
• PRD → ユースケースとテストケース
• テストケース → 実装
• 実装 → テスト実行と修正

人間が入るのは承認ゲート2点（要件の合意／期待挙動の合意）と最終レビューだけになります。人の時間がレビューの物量ではなく、上流の合意に配分される。これが「人間の時間を前倒しする」の実務的な意味です。

多層の品質ゲート：速い→遅い、狭い→広い

審判は1つではなく段階防御にします。安いチェックを内側に、高いチェックを外側に。

AIの生成物
   ↓
① Hooks（編集直後・秒単位）      lint・型・関連テスト
   ↓
② LLM as judge（生成完了時・分）  ルーブリック採点・E2E確認
   ↓
③ CI/CD（PR時）                 静的解析＋全テスト＋build
   ↓
マージ
（どの段でも落ちたら修正ループへ戻す）

重いチェックはループの内側に入れない

ここに設計判断が1つあります。数秒で終わる型チェックは毎ループ回す価値がありますが、数分かかるビルドを各エージェントに自由に叩かせると渋滞します。

対処は、ビルドを1本のプロセスに直列化することです。エージェントはパッチを書くだけ、まとめてビルドして結果を返す。最も高い操作を並列化しないのが要点です。

ブランチ戦略を決め切らずに進む：v2方式

既存チームとブランチ戦略（GitFlowかトランクベースか、リリースブランチをどう切るか）を合意するのは、それ自体が調整コストです。しかも決まるまで着手できない。これも変数のひとつなので、減らします。

答えは、ブランチではなくコード上のパスで新旧を分けることです。

① 現状            /orders（v1）
② 並走で新画面     /orders（v1） ＋ /orders-v2（新）
                   ※API呼び出し層は v1 と共有する
③ ルーティング切替  /orders → v2 へ転送
④ 旧画面を削除     /orders（v2）
   ↺ 画面単位で繰り返す

得られるものが5つあります。

• ブランチ戦略の合意を待たずに始められる（変数がまた1つ減る）
• 長期featureブランチのマージ地獄を回避できる。 AIは大量に生成するので、長寿命ブランチを作るとコンフリクト解消に人間が張り付きます
• 未完成のまま本番に入っていて構わない。 ただしリンクを張らないだけでは不十分です。ファイルベースルーティングでは /orders-v2 自体が有効なURLになるため、直接入力・履歴・クローラーから未完成画面に到達できます。認可ガードかフィーチャーフラグで、v2への直接アクセス自体を塞いでください（合わせて noindex も）。そこまでやって初めて「本番に置いたまま隠す」が成立します
• AIに触ってよい範囲をパスで機械的に指定できる。 「-v2 配下だけ編集可」は、プロンプトの願いではなくHooksやCIで強制できるルールになります
• 途中で止まっても旧が生きている。 AI駆動開発は途中で止まることが普通にあるので、止まっても価値が出る構造にしておく

運用ルールは3つ。

1. 共通モジュール（API呼び出し層など）はv1と共有する。 コピーすると二重メンテになります
2. 「旧画面の削除」までを1チケットの完了条件にする。 期限を切らないとv2が永久に残り、そのまま負債になります
3. v1とv2を同時に修正しなければならない期間を短くする。 だから画面単位に小さく割ります

ブランチ戦略と排他ではありません。後でチーム全体の方針が決まったら、そこに乗せ替えれば済みます。決まっていないことを理由に止まらないための型です。

環境は月ごとに積み上げる

現行の本番・検証・開発環境は触りません。AI駆動開発用の系統を別に立て、月が進むごとに「テスト済みの状態」を1つずつ増やします。

目的は、各時点で「テストが完了している状態」を維持することです。リリース直前にマイグレーションをまとめて確認する、という状況を避けます。

最後に：コードを直すな、ループを直せ

大規模移行の事例から得られた一文が、この運用全体の背骨です。

コードを直すな。そのコードを産んだループを直せ。

判断基準は1つです。

この修正は、次に同じことが起きるのを防ぐか？

防がないなら、それは人間が発生させ続ける負債です。あわせて、運用上効く実務ルールを3つ挙げておきます。

• キューはリポジトリの実状態から毎回再構築する。 「どこまで終わったか」を別管理すると、中断で壊れます。成果物の有無から未処理を算出すれば、再開可能性が構造として保証されます
• モデルを使い分ける。 大量ファンアウトの実装は小さいモデル、レビュアーと「他のエージェントが従うルールを書く役」は大きいモデル
• 人間が見るのはコードではなく、失敗の分布。 個々の失敗はループの仕事です

よくある質問

Q. 承認ゲートが2つでは少なくないですか？ A. 多いほど安全に見えますが、承認が増えるとエージェントの待ち時間が増え、結局人間がボトルネックになります。要件（何を作るか）と期待挙動（どうなったら完成か）の2点が固まっていれば、実装過程の判断は機械的な審判に任せられます。

Q. PRDを毎回書くのは重すぎます。 A. チケットの性質で省略してください。表示崩れの修正にPRDは不要です。判断に迷う場合は「状態遷移に影響するか」で切ると実務的です。

Q. Hooksでは何を実行すべきですか？ A. 秒単位で終わるものだけです。lint、型チェック、変更ファイルに関連する単体テスト。フルテストやビルドを入れると編集ごとに待たされ、かえって遅くなります。

Q. v2方式でコードが重複しませんか？ A. 一時的に重複します。だから旧画面の削除までを1チケットの完了条件にします。共通モジュールを共有し、コピーするのは画面層だけに限定すれば、重複期間の負担は小さく収まります。

Q. AIの生成物をレビューする時間が結局かかります。 A. レビュー対象が「コード1行ずつ」になっている可能性があります。見るべきはループの出力分布（どのカテゴリの指摘が何回出たか）で、個別の指摘は審判とルールに落として自動化する対象です。同じ指摘を2回したら、それはルールに書くべき合図です。

最終確認日: 2026-07-26