🌊

持続可能な開発を実現するために、個人的に実践しているAI 駆動開発フロー(Cursor)

に公開2

結論

はじめに

最近、AI コーディングツールが爆発的に普及し、「AI がコードを全部書いてくれる!」「プログラマー不要論」なんて声もチラホラ聞こえてきます。SNS やブログでは「AI にプロンプトを入力したらテトリスが作れた!」「小規模なウェブサイトが 30 分で完成!」といった成功体験が溢れています。

しかし、Web 上で見かけるのはワンショットでテトリスを作る程度の小規模なプロジェクトの話がほとんどで、驚けるものの、正直あまり実用性は無いように感じる。

俺たちが本当に知りたいのはテトリスの作り方じゃねえ!現実の中規模以上のシステム開発で、いかに楽に良いものを作れるかだろ!

https://note.com/kmagai/n/n9c78650645f9

全くその通りです。

そこで今日は、そこそこの規模のコードベースで持続的な開発を行うために、私なりに実践している AI 駆動開発のフローをシェアしたいと思います。

私の「AI 駆動開発」フロー(2025 年春バージョン)

私の AI 駆動開発スタンスの基本は、次の 2 点に集約されます:

  1. コンテキストの質を高める: AI に与える情報を精選し、ノイズを減らすことで精度を上げる。
  2. 厳密かつ検証可能な仕組みで品質を担保する: AI の生成物を厳密かつ検証可能な仕組み(自動テスト)で評価することで、品質を担保する。(※Lint ルールなど他の仕組みもありますが、この記事では自動テストに焦点を当てます。)

この 2 つの原則を実践するために、開発プロセスを「設計フェーズ」「実装フェーズ」の 2 つに分け、以下の具体的な方法を取り入れています。

  • Issue/PR を活用したコンテキスト管理:
    • 各フェーズの区切りとして GitHub の IssuePull Request (PR) を活用します。
    • Issue には、人間がレビュー・承認した明確な設計情報とテスト要件を記述します。これが AI が参照すべき質の高いコンテキストとなります。実装時には、大量のチャット履歴ではなく、この整理された Issue を AI に与えることで、コンテキストの質を高めます。
    • PR は、Issue に基づく変更内容を示します。人間がレビューすることで品質を保証します。
  • 自動テスト中心の実装サイクル:
    • 実装フェーズでは、AI にコードだけでなくテストコードも生成させます。
    • 自動テストを実行し、その結果に基づいて AI が自律的にコードを修正するサイクルを回します。これにより、人間が常にコードを確認しなくても、一定の品質を担保できます。

このように、人間が保証した Issue/PR を明確な情報源とし、自動テストによる検証サイクルを回すことで、AI 駆動開発の効率と品質の両立を目指します。特に、人間によるレビューを Issue と PR という明確な成果物に集中させることで、膨大なやり取りを確認する手間を省き、品質の高いコードを効率的に生成することができます。

では、具体的に各フェーズでどのように進めるかを見ていきましょう。

設計フェーズ:理解 → 方針検討 → Issue 作成

まずは「何を作るか」「どう作るか」を決める設計フェーズです。

  1. 理解: AI に関連コードやドキュメントを読んでもらい、「このファイルの要点は?」「既存機能はどう動いてる?」と質問して理解を深めます。
  2. 方針検討: 「こういう機能を追加したいけど、どんな実装が良いだろう?」と AI と相談し、選択肢を出してもらって議論します。
  3. Issue 作成 & 設計レビュー: 固まった方針を GitHub Issue にまとめます。ここには「どういうテストをクリアしたら完成とするか」というテスト要件も具体的に記載します。人間がこの Issue をレビュー・承認することで、AI が参照すべき、人間が保証した設計情報が完成します。

実装フェーズ:コード生成 → テスト → 修正サイクル → PR 作成

次に、設計情報に基づいてコードを形にする実装フェーズです。

  1. コード・テスト生成: 承認された Issue をもとに、AI に「この Issue の仕様でコードとテストを書いて」と指示します。テストコードを早い段階で書いてもらうことが重要です。
  2. テスト実行 & 修正サイクル: Cursor などの AI エディタは、生成したコマンドを自律的に実行できます。AI はテストを実行し、失敗した場合は結果を分析して自律的に修正を行い、再度テストを行います。この一連のサイクルをAI が自律的に繰り返すことで、効率的な開発を実現します。
  3. レビュー: この段階で、テストが通過しなかったり、コードがおかしいと感じたら、適宜指示を出します。
  4. PR 作成:: レビューをクリアしたら、AI に「ここまでの変更内容で PR を作って」と依頼し、Pull Request を作成します。

テストの自動実行と修正サイクルは、AI 駆動開発の効率性を大きく高める要素です。AI が自分で書いたコードのテストを行い、失敗したら自分で修正する—この自己完結的なサイクルによって、人間の介入なしに実装の質を高めることができます。

実例:既存のコードベースに対するバグ修正

スクリーンショットは、最近開発している web アプリケーションの画面です。このページから、見積内容マスタを登録すると、500 Internal Server Error が発生するという不具合が報告されています。今回は、このエラーを解消してみます。
(ネタバレすると、参考単価が未入力の場合の処理を実装していないことがエラーの原因でした。)

注意:ここから先に登場するスクリーンショットは、今回の記事のために、当時のやりとりを再現したものです。そのため、スレッドのやり取りや実装内容に矛盾がある可能性があります。

1. 設計フェーズ

まずは、バグの原因を調査します。


コードベースからはエラーの原因がわからなかったようで、エラーメッセージの共有を求められました。
AI の要望通り、エラーメッセージを共有してみます。


GitHub MCP Server を使うことで、AI が自分で Issue を立てました。

テストの実装計画が含まれていないため、再度指示を出します。

Issue のコメントとしてテスト実装計画が追記されました。

2. 実装フェーズ

GitHub Issue にバグの概要と原因、さらに修正方針とテストの実装計画が記述されました。
ここで、Cursor のスレッドを新しいものに切り替えます。
そして、Issue のリンクとともに指示を出します。

Issue の内容を読み込めていることが確認できます。
それでは実装に入ります。



全てのテストが通過したため、PR を作成します。

まとめ

これまで説明してきた AI 駆動開発フローは、「コンテキストの質を高めること」と「自動テスト(厳密なアルゴリズム)で品質を担保すること」という 2 つの原則に基づいています。これらを成功させるために私が実践している内容を改めて紹介します。

1. Issue/PR を信頼できる情報源にする

これは、原則 1「コンテキストの質を高める」ための具体的な方法です。AI から良い回答を引き出すための最大のコツは、「AI が参照すべき情報を明確で信頼できる形にする」ことです。

本記事で紹介した開発フローでは、Issue と PR がその「明確で信頼できる情報源」になります:

  • Issue: 背景・目的・要件をノイズなく正確に記述し、テスト要件を明確に定義
  • PR: Issue に基づき、変更内容をわかりやすく整理して示す

これらを人間がレビューして保証した信頼できるドキュメントとして扱うことで、AI は的確なコード生成や提案ができるようになります。

また、長いチャット履歴ではなく、Issue や PR という形で情報が整理されることで、AI が参照すべきコンテキストが短くなり、性能低下も防げます。

2. 自動テストを効果的に活用する

これは、原則 2「厳密かつ検証可能な仕組みで品質を担保する」ための具体的な方法です。

  • テストで検証可能な実装: AI に「テストを通過する実装を行う」という明確な目標を与えます
  • テスト要件を明確に: 「このテストがパスすれば完了」という明確な判断基準を設けることで、AI の自律的な実装が可能になります
  • 自動テストの活用: AI が自分で書いたコードをテストし、必要に応じて修正するサイクルを回せるようにします

自動テストを活用することで、実装の品質が向上するだけでなく、AI が自律的に作業を進められるようになります。

おわりに

今日は私の AI 駆動開発フロー、特にコンテキストを区切ること自動テストの活用という二つの柱を中心に紹介しました。

この記事で紹介した考え方やフローが、皆さんの開発プロセスをより良くするためのヒントになれば幸いです。皆さんも色々試して、「自分の開発をもっと効率的にする方法」を見つけてみてください!

Discussion