Claude Codeを使ってAI駆動開発を進めていますが、直近で開発フローを大きく変えたところ、劇的な効果を実感しているのでまとめておきます。

これまでのやり方

これまでは要求仕様書をもとに、要求仕様の確認、実装計画書の作成、実装、コードレビューという工程で開発を進めていました。

flowchart TD A[要求仕様書] --> B[要求仕様の確認] B --> H1(["人間が確認"]):::human H1 --> C[実装計画書の作成] C --> H2(["人間が確認"]):::human H2 --> D[実装] D --> H3(["人間が確認"]):::human H3 --> E[コードレビュー] E --> H4(["人間が確認"]):::human classDef human fill:#ffe0b2,stroke:#e65100

各工程はAIエージェントに任せていましたが、工程が終わるたびに人間が間に入って確認するようにしていました。

このやり方でも、AI駆動開発を始める前と比べると開発速度は3倍程度になっていました。

何がボトルネックだったか

多いときは8個くらいのタスクを並行でエージェントに依頼することがあります（40インチのウルトラワイドモニターに買い替えたのもこのためです）。

そうなると人間の確認が追いつかず、人間の返答待ちが長いときで数十分から1時間ほどありました。エージェント側は作業できる状態なのに、人間待ちで止まっていたわけです（エージェントの入力待ちについては以前の記事でも取り上げました）。

一連の作業をエージェントに一貫して任せる形に変更

そこで、要求仕様の確認からコードレビューまでを一貫してエージェント側に行わせる作りに変更しました。

flowchart TD A[要求仕様書] --> B[要求仕様の確認] B --> C[実装計画書の作成] C --> R{"リリース後の修正コストが
高い変更を含む？"} R -->|はい| H1(["人間がレビュー"]):::human H1 --> D[実装] R -->|いいえ| D D --> E[コードレビュー] E --> PR["ドラフトPR作成
スクショ・動画を添付"] PR --> H2(["人間が確認"]):::human classDef human fill:#ffe0b2,stroke:#e65100
  • 工程ごとにClaude Codeのサブエージェント（特定の役割を持たせた子エージェント）を作成し、それぞれの工程を担当させる
  • 各工程の成果物はMarkdownファイルに書き出し、次の工程のサブエージェントがそれを読んで作業する
  • 作業が完了するとドラフトPR（レビュー依頼前の下書き状態のプルリクエスト）が作成される
  • 画面に変更が加わるタスクの場合は、スクリーンショットや動画がPRに添付される

人間は基本的にドラフトPRが出来上がった段階で確認します。画面の変更はPRに添付されたスクリーンショットや動画を見れば確認できるので、手元で動かさなくても判断できることが多いです。

人間が介入するルール

すべてをエージェント任せにしているわけではありません。途中の工程は基本的にエージェントに任せ、あらかじめ決めたルールに該当する場合だけ人間が介入（レビュー）するようにしています。最終的なドラフトPRは毎回人間が確認します。

基準は リリース後の修正コストが高いものかどうか です。例えば以下のようなものです。

  • DBの変更
  • URLの命名規則

こういったものは一度リリースすると後から直すのが大変なので、人間がきちんと見るようにしています。逆に言えば、後からでも直しやすいものはエージェントに任せています。

結果

チケットの消化数で見ると、もともと3倍程度だった開発速度がそこからさらに2〜3倍向上しました。AI駆動開発を始める前と比べると6〜9倍程度になった計算です。

タスクの粒度は揃っていないので厳密な数字ではないですが、意図的に細かいチケットに分けて数を稼ぐようなことはしていません。体感としてもかなり速くなっています。

大きな要因は、人間が介入する頻度が減ったことでエージェント側の待ち時間が減ったことではないかと思っています。

ルールの整備が大事

最初からうまくいったわけではなく、ルールが十分に定義されていない箇所では意図しないものが出力されることもありました。

例えば、ビジネスロジックはサービスクラスに書くようにしているのですが、そのサービスクラスの作りが意図した形になっていないことがありました。そこで、ルールに具体的なサンプルコードを記載するようにしました。言葉で説明するより、サンプルコードを見せた方がエージェントには伝わりやすいようです。

このように、ズレが出るたびにルールを整備していった結果、今では大きくズレることはかなり減りました。

空いた時間でできるようになったこと

人間が介入する時間が減ったことで、これまであまり着手できていなかったリファクタリング系のタスクに時間を使えるようになりました。

機能開発に追われて後回しになりがちだったところに手を付けられるようになったのは、個人的にかなり嬉しい変化です。

まとめ

AI駆動開発で工程ごとに人間が確認していたやり方から、エージェントに一貫して任せ、リリース後の修正コストが高いものだけ人間が介入するやり方に変えたところ、開発速度がさらに2〜3倍になりました。

エージェントの性能を上げることばかりに目が行きがちですが、実際には人間がボトルネックになっていたのだと思います。どこで人間が見るべきかのルールを決めて、それ以外はエージェントに任せる。そのうえで、ズレが出たらルールを整備していく。これがかなり効果的でした。