メインコンテンツへスキップ
Hero Image

AI 駆動開発メモ

AI-Driven-Development

結論

小規模プロダクト開発においては以下の点に留意するとよい。

  • ISO/IEC/IEEE 29148:2018 で仕様書を作る
  • テスト駆動開発で進める
  • 小さく進める

これらに留意することでほぼ全ての実装を AI に任せ、自分は最終的な受け入れ判断（要件・テストの妥当性確認）のみおこなっている。 具体的な手順は後述する。

前提

個人開発の小規模なプロダクトに限定した話であり、チーム開発や大規模サービスでは、異なる進め方を取るべきだと考えている。

現在の進め方

以下は、結論で述べた留意点（仕様・TDD・小ささ）を、実際の開発でどのような作業に落としているかをまとめたものである。

  • ISO/IEC/IEEE 29148:2018 形式の仕様書を作る
  • 最初にモックを作る
  • できるかぎり小さく(1 ファイルずつ)進める
  • テスト駆動開発で進める

後述のサンプルコードの実装で実際におこなった方法である。 なお、コーディングには Antigravity を使っている。

サンプルコード

https://github.com/gnkm/article-generator

コードについて簡単に説明しておく。 チャットUIで承認・修正指示をしながら、ブログ記事の仕様策定、構成、執筆を進める Human-in-the-Loop 型の LLM アプリケーションである。

ISO/IEC/IEEE 29148:2018 形式の仕様書を作る

要求定義に必要な項目や作成すべき成果物の構造を規定している国際規格として ISO/IEC/IEEE 29148:2018 というものがある。 要求工学で検証されてきた枠組みで、要件をテスト可能な形に落とし込みやすい。 ISO/IEC/IEEE 29148:2018 形式の仕様書に記載される内容の例として、以下のようなものがある。

  * **[REQ-FUN-020] 構成案の生成**
      * 概要: 承認済み仕様書に基づく構成作成。
      * 要件: システムは仕様書の内容に基づき、記事の見出し構成（H1, H2, H3）を生成し表示しなければならない。

これをアプリケーションコードとテストコードの中にも書いておく。 少なくとも、AI が変更対象ファイルだけ見て作業する状況でも要件が目に入るようになる。

最初にモックを作る

AI に実装を任せると、ユーザーインターフェイスよりも内部実装が先行しがちである。 動いていないと、仮にテストがパスしていてもそれが適切かどうかわからない。 最初にモックを作ることで、必要なものが明らかになり、実装を進めやすくなる。

できるかぎり小さく(1 ファイルずつ)進める

これは Antigravity を使っていてよくあることなのだが、複数の機能を続けて実装しようとすることがある。 個人的には 1 機能実装するごとに確認したい。 一度に確認すべきことが多くなると大きめのワーキングメモリが必要となり、効率が落ちてしまう。 とにかく小さく進めるよう注意している。 Antigravity にはあらかじめ実装計画を作らせておき、それに沿って進められるようにしておく。 そして以下のような指示を出す。

次に着手すべきタスクを教えて下さい。どのファイルにどのような機能を実装しますか？

こうすると実装を進めずに、質問に回答してくれる。

テスト駆動開発で進める

実装を始める際は以下のように指示を出す。

xxx の機能を実装します。テスト駆動開発で進めたいと思います。まずは red フェーズとして、テストを作成してください。
その際、 requirements.md に記載されている要件に対応する機能があれば、最初に、要件 ID と要件を記載してください。

このように指示しても、AI はテストコードとアプリケーションコードの両方を生成してしまう。 この段階で git commit をしておく。

続いて refactor フェーズに入る。

ここまでで red, green フェーズが完了しました。リファクタリングすべき点があれば教えて下さい。

計画を提示させ、問題なければ実装を始めるよう指示を出す。 終わったら git commit をしておく。

テストについては [REQ-xxx] に対応するテストコードも作る。 test_requirements.py にテストコードを記述する。 例えば以下のようなテストを作る。

async def test_req_fun_020_structure_generation_flow():
    """
    [REQ-FUN-020] 構成案の生成
    [REQ-FUN-021] 構成の承認アクション
    Spec -> Structure の遷移と、Structure フェーズでのループ動作を確認。
    """
    ...

このテストがパスしていれば、少なくとも要求仕様書で定義した受け入れ条件は満たしていることになる。

Antigravity(+ Gemini 3 Pro)を使う

Antigravity のアーティファクトが気に入っている。 一度に複数、行を指定してコメントできるのが良い。

Secure Mode にして、できるだけユーザーに承認を求めるようにしておく。 実装とは無関係だが、「Enable Telemetry」はオフにしておく。

Gemini はコンテキストサイズが大きいので、気にせずチャットを続けられる。 コンテキストサイズを気にしなくてよいのは嬉しい。

やめたこと

Claude Code

サブエージェントを使うことでコンテキストをわけられるのが良いということだったが、 サブエージェントがうまく機能しなかった。 サブエージェントには自律的に働いてほしいのだが、私が明示的に指示しないと働いてくれず、使いこなせなかった。

Vibe Kanban

並行して進められるのが良いのだが、タスクの作り方が悪いと、1 タスクでたくさん実装してしまい確認が大変で使うのをやめてしまった。 AI が実装しているところを監視して、細かく指示を出す方がやりやすい。

まとめ

AI に実装を任せるために重要なのは、実装そのものよりも「何を作るか（要件）」と「できたと言ってよいか（受け入れ条件）」を明確にすることだと考えている。 仕様を要件 ID に分解し、要件テストで受け入れ条件を固定し、小さく変更を刻むことで、AI にうまくコーディングさせることができる。 ただ、これがベストではなく、もっとうまく AI に任せる方法があると思う。 今後も試行錯誤を続けていきたい。