えっ!!コードを読まずに開発を!?

2026/07/14 KAG AI Week Day2 で登壇した際の資料です
AI駆動開発で実装の速度が大きく上がり　人間によるコードレビューが開発速度・プロダクト品質の両面でボトルネックとなった
そんなチームがコードレビューをやめ，より効率的で高品質な開発フローを探す旅の記録

Transcript

1. えっ!! コードを読まずに開発を!? はなのうち
2. 2 KDDI Agile Development Center Corporation 花之内 広太郎 ロール 　スクラムマスター / エンジニア 好きなアーティスト 　福山雅治 　aiko そのほか 　KAGの新卒研修運営に関わったり 　社内コミュニティ「KAG-OST」を運営していたり 自己紹介
3. 3 KDDI Agile Development Center Corporation えっ!! コードを読まずに開発を!?
4. 4 KDDI Agile Development Center Corporation えっ!! コード読まずに開発を!? 出来らあっ！ 仕組みと合意があれば
5. 5 KDDI Agile Development Center Corporation 今日はAI駆動開発の取り組みを話します 話すこと 　AIに開発を任せて「人間によるコードレビューをやめた」こと 　コードレビューに代わる「プロダクトの品質を高める取り組み」 話さないこと 　What is AI駆動 / 仕様駆動 ? 　AI駆動における要件定義やリリースフロー等
6. 6 KDDI Agile Development Center Corporation 私たちのチーム（案件）の状況 お客さまの社内システムの更改案件を担当 - 現行運用中のシステムのリプレース - 運用移行のデッドライン(EOSL)がある すでに運用開始からN年経過している - システム／業務ロジックが巨大かつ複雑に スケジュール（納期）がとても厳しい - 従来の開発体制ではとても間に合わない （生成AIに頼らない） 　 辛いところ 案件がAI駆動/仕様駆動開発にとても向いていそう - PO（お客さま）がシステム要件に詳しい - API IF/ DB Entityレベルで要件定義 - システム更改のため仕様の整理がしやすい チーム組織前後でAIの性能が大幅に向上した - Claude Opus 4.6/ 4.7等 いいところ チームの方針： 　AIをフル活用で　高効率 x 高品質　なプロダクト開発！ 共感してほしい!!
7. 7 KDDI Agile Development Center Corporation AI駆動開発のフローを検討する
8. 8 KDDI Agile Development Center Corporation 開発フローをデザインする 要件定義 開発 動確 ・要件定義 ・ドメインナレッジの作成 ・JIRAチケットの作成 ・詳細設計書の作成 ・テストコードの作成 ・実装 ・自動テスト ・手動テスト ・開発環境へのデプロイ ・テスト計画の作成 ・テスト実行 受入試験 ・QAチーム（人間）検証 ローカル開発環境 開発環境(AWS) 検証環境(AWS) 商用リリース 商用環境(AWS) 仕様書 ・そして運用へ 既存の開発フローの一部をAI駆動に置き換えてみる
9. 9 KDDI Agile Development Center Corporation 開発フローをデザインする 要件定義 開発 動確 ・要件定義 ・ドメインナレッジの作成 ・JIRAチケットの作成 ・詳細設計書の作成 ・テストコードの作成 ・実装 ・自動テスト ・手動テスト ・開発環境へのデプロイ ・テスト計画の作成 ・テスト実行 受入試験 ・QAチーム（人間）検証 ローカル開発環境 開発環境(AWS) 検証環境(AWS) 商用リリース 商用環境(AWS) 仕様書 ・そして運用へ 既存の開発フローの一部をAI駆動に置き換えてみる 今回のスコープ （開発着手〜開発DONE）
10. 10 KDDI Agile Development Center Corporation 試しにPoCで実装してみた 仕様駆動開発（Open Spec）とプロジェクト相性がとにかく良かった 変更差分+/-約1000行のPRを ２時間でコーディングしました 人間の稼働時間は15分程度です 並列作業も どんとこいです 短時間でサクサク実装が進む ということはつまり...
11. 11 KDDI Agile Development Center Corporation 短時間で大量のPullRequestが作成され　レビュー待ちに 数時間で数百〜千行以上の差分のPRが作成される これをレビューするのは単純に時間がかかる 人間の集中力ではバグを見落とす可能性も高くなる（品質的リスク） 速度・品質両面で課題 どうやって改善しようか もはや日常
12. 12 KDDI Agile Development Center Corporation コードレビューをやめてみよう 条件： - コードレビューより効率的（短時間）である - コードレビューと同等以上に品質が担保できる この目標に向かって３ヶ月走ったチームが今どうなっているかを紹介 あくまで人間の稼働時間で考える
13. 13 KDDI Agile Development Center Corporation 俺たちの開発フロー
14. 14 KDDI Agile Development Center Corporation 開発〜動確をOpen Specのライフサイクルに当てはめる 要件定義 開発 動確 ・要件定義 ・ドメインナレッジの作成 ・JIRAチケットの作成 ・詳細設計書の作成 ・テストコードの作成 ・実装 ・自動テスト ・手動テスト ・開発環境へのデプロイ ・テスト計画の作成 ・テスト実行 受入試験 ・QAチーム（人間）検証 ローカル開発環境 開発環境(AWS) 検証環境(AWS) 商用リリース 商用環境(AWS) 仕様書 ・そして運用へ Explore/Propose ・調査・設計 ・詳細設計書の作成 ・テスト計画の作成 Apply ・実装 ・自動テスト ・手動テスト Review Phase ・検証環境へのデプロイ ・テスト実行 Sync/Archive Phase ・開発タスクのクローズ
15. 15 KDDI Agile Development Center Corporation Explore / Propose Changeを作成する際に以下のドキュメントを作成 　- proposal.md / design.md / task.md （Open Spec標準） 　- test-spec.md (独自に追加） test-spec.mdではproposal/designの内容を確認するために必要なテスト仕様を記述 - Unit Test のテストケース - E2E試験のテストシナリオ - 回帰試験のテストシナリオ Explore/Propose ・調査・設計 ・Changeの作成* ・テスト計画の作成 Apply ・各種実装 ・オーケストレーターから 　サブエージェントに委譲 Review Phase ・PR作成 ・検証環境の立ち上げ ・自動テスト実行 Sync/Archive Phase ・仕様書の統合/最新化 ・PR merge ・検証環境クローズ proposeの時点で実装内容と共にテスト内容も確認する Change: OpenSpecでの開発単位
16. 16 KDDI Agile Development Center Corporation Apply Explore/Propose ・調査・設計 ・Changeの作成* ・テスト計画の作成 Apply ・各種実装 ・オーケストレーターから 　サブエージェントに委譲 Review Phase ・PR作成 ・検証環境の立ち上げ ・自動テスト実行 Sync/Archive Phase ・仕様書の統合/最新化 ・PR merge ・検証環境クローズ いわゆる実装 タスクの種類ごとにサブエージェントを作成している(次スライドで詳しく） 　分散作業での効率化とコンテキストの肥大化防止が狙い オーケストレーターがPropose段階で分担を決める 基本は並列作業 実装に依存関係がある場合のみオーケストレーターが流れを制御
17. 17 KDDI Agile Development Center Corporation Apply - ３つのサブエージェントが並列で作業する 作業ディレクトリレベルで分離しているため実装時に競合は発生しない 基本他エージェントの作業待ちは発生しない 　実装仕様をchange documentとして先に定義しているため Apply Phaseの完了条件に Lint check, Unit Testの全pass, E2E試験のローカル実行成功を含む これを満たさないと後続のReviewフェーズに進めない App Developer ・アプリケーションコード実装 ・Unit Test実装／実施 Regression Test Developer ・回帰試験テスト作成 E2E Test Developer ・動作確認用E2E試験テスト作成 Explore/Propose ・調査・設計 ・Changeの作成* ・テスト計画の作成 Apply ・各種実装 ・オーケストレーターから 　サブエージェントに委譲 Review Phase ・PR作成 ・検証環境の立ち上げ ・自動テスト実行 Sync/Archive Phase ・仕様書の統合/最新化 ・PR merge ・検証環境クローズ
18. 18 KDDI Agile Development Center Corporation Review Explore/Propose ・調査・設計 ・Changeの作成* ・テスト計画の作成 Apply ・各種実装 ・オーケストレーターから 　サブエージェントに委譲 Review Phase ・PR作成 ・検証環境の立ち上げ ・自動テスト実行 Sync/Archive Phase ・仕様書の統合/最新化 ・PR merge ・検証環境クローズ Pull Request(PR)を作成→AWS環境へデプロイ 　AWS上にPR専用の環境（PR環境）を構築 　複数のPRレビューが並行で進行してもDEV環境を取り合わない仕組み PR環境上で受け入れ試験（E2E試験）を実行 　Playwrightを使っています 　→AWS上でも動作が保証される その後PR環境を使って人間が動確 　E2Eの操作をトレースしたり 　探索的試験をしたり コードベースのレビューをやめて デプロイされたアプリでレビュー（動作 確認）
19. 19 KDDI Agile Development Center Corporation Review Phaseの流れ 人間 Claude Code GitHub Actions（CI） /opsx:review ― PR 準備を自動実行 ・全実装タスクの完了チェック ・lint / 型チェック / go test を fail-fast で実行 ・Pull Request 作成 pr-ephemeral ― 自動起動 CI test Lint ＋ UT build コンテナイメージ作成 deploy PR 専用環境構築 受入試験（E2E）の CI をトリガー PR コメントにテスト名を書いて起動（{qa <テスト名>}） 受入試験 Workflow（pr-qa） プレビュー環境に対して Playwright 受入 E2E を実行 受入試験 NG？ pass NG 指摘対応 ― 修正を実装 ・試験ログを解析 → 原因を特定して修正 ・push で CI／受入試験を自動再実行 実機確認 プレビュー環境にブラウザでアクセスして動作確認 修正指摘 なし？ あり なし PR をマージ pr-ephemeral-destroy ― 自動起動 CI PR 専用プレビュー環境を自動破棄 Reviewフェーズを開始 人間が意思を持って実行
20. 20 KDDI Agile Development Center Corporation PR 環境 (Ephemeral 環境) GitHub Pull Request作成 GHA workflows レビュアー（人間） ブラウザで実機確認 AWS CodeBuild セルフホストランナー （CI ジョブ実行基盤） ECR backend / migrate / frontend VPC（qa-shared ― 常設・全 PR 共有） 共有 ALB PRのIDごとに URLを分ける PR Ephemeral環境（pr-{N}） PR open で自動構築 / PR close で自動破棄 ― 複数 PR 並行 app Service ― Fargate Task（アプリ本体） backend ― Go API サーバ db Service ― Fargate Task（PR 専用 DB） 使い捨てのプレビュー用データベース データは Task 内の一時ストレージ （環境破棄・再起動で消滅） image pull nginx ― SPA 配信＋ /api リバースプロキシ PRごとに個別の環 境を立ち上げる
21. 21 KDDI Agile Development Center Corporation Sync / Archive Explore/Propose ・調査・設計 ・Changeの作成 ・テスト計画の作成 Apply ・各種実装 ・オーケストレーターから 　各サブエージェントに委譲 Review Phase ・PR（Pull Request）の作成 ・検証環境の立ち上げ ・自動テスト実行 Sync/Archive Phase ・仕様書の統合/最新化 ・PR merge ・検証環境クローズ Open Specの Sync / Archiveほぼそのまま使用 追加でPullRequestのclose(merge)とJiraのチケットのステータス更新 最近は各change(PR)の作業時間の計測をしています 　Claudeと人間の作業比率が大体 2:1程度に落ち着いています (稼働時間ベース ) 人間の作業時間を 70%削減しました
22. 22 KDDI Agile Development Center Corporation 回帰試験 毎日夜間にE2Eベースの試験を実行 NG項目ある場合は翌日修正 GitHub Actions（CI）― 夜間に自動実行 cron 起動 毎晩 JST 01:00（月〜金） 試験環境を構築 試験時だけ環境を起動 回帰シナリオを実行 Playwright で 業務フローを再現した試験 結果を Slack へ通知 HTML レポートを公開し通知 環境を自動破棄 日中のコストはゼロ 開発チーム（人間） 結果を確認 Slack 通知とレポートをチェック NGな 場合 修正対応 原因を調査して修正 → PR をマージ 修正は夜間に自動で再検証
23. 23 KDDI Agile Development Center Corporation コスパの良いE2E試験 今まで：E2E試験の実装/メンテナンスコストは非常に高い 　→コスパの悪さから後回しorやらない　になりがち 以前は私も慎重派だった 今回の仕組みなら - E2E単独の開発時間はなし - 人間はテストシナリオの確認だけでOK - 失敗時の調査・修正もAIに依頼 （機能開発と並行で進められる） やらない理由が前よりぐっと減った 　（無条件にやるべき　ではないけど） App Developer ・アプリケーションコード実装 ・Unit Test実装／実施 Regression Test Developer ・回帰試験テスト作成 E2E Test Developer ・動作確認用E2E試験テスト作成 Apply ・各種実装 ・オーケストレーターから 　サブエージェントに委譲 再掲 Apply時にアプリ実装と並行して 回帰試験のメンテをしている
24. 24 KDDI Agile Development Center Corporation ここまで旅してみて 本当にこれで上手くいく保証はない 　でもなんとかなると信じています 　（今のやり方からは変わるかもしれないけど） 今回のスコープ外にも成功に必要な要素があると思っています 　AI駆動に優しい要件定義とか受入試験とか コードレビューが担っていた品質保証以外の側面に気づきました 　例えば 　　- 技術/スキルの継承（育成の観点） 　　- チームメンバー内の情報の共有 　今回の仕組みではこれらの観点は代替できていない 　　→いま課題に感じて取り組みはじめたところ