AI駆動開発の実運用ノート

本編の目次 › 第3部 実装→検証イテレーション › 通し実装

AI駆動開発の実運用ノート No.83差戻し機能を起票から通常マージまで通しで作る

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第3部「実装→検証イテレーション」から、「通し実装」のお話です。

再現手順

差戻し機能を起票から通常マージまで

Keihi の承認フローには差戻しがまだない。起票からマージまでを、検証の階段を飛ばさずに通す。

手順
  1. git switch -c feature/reject でブランチを切る
  2. AI に依頼する——完了の定義は「理由必須・履歴に記録・不正な遷移は拒否」
  3. npx tsc --noEmitmake test-unitmake dev で healthy
  4. localhost:3000 で申請→差戻し→申請者画面まで通し、3点セットを残す
  5. PR 作成 → gh pr merge --merge(止まったら項目を満たしてから再実行)
確認できること
  • 各段が何を捕まえたか——上の段でしか出ないバグがあること
  • フックが途中で何回介入したか(ブランチ作成・コミット・マージ)

Keihi の承認フローには、差戻しがまだ実装されていないブランチがあります。 これを起点に、起票、ブランチ作成、AIへの依頼、検証の階段、PR、マージまでを通します。

番号付きの手順はスライド本体にあるので、ここではなぜその順序なのか、どこを見るべきかを補います。

依頼には「完了の定義」を必ず入れます。「理由が必須で、履歴に記録されて、許されない状態遷移は拒否される」。 定義を先に渡さないと、AIの言う「完了」と自分の考える「完了」がずれたまま進んでしまいます。

検証の階段を登る間は、一段ごとに検証の階段の表に戻り、「この段は何を捕まえる段だったか」を確認してください。

もう一つ、数えてほしいものがあります。フックが何回、作業を止めるか。 ブランチを切るとき、コミットするとき、マージするとき。最低3回は入るはずです。

つづく