シリーズ AI駆動開発実践入門 Part 1 / 4

AI駆動開発のはじめ方

AI駆動開発 開発プロセス

AI駆動開発は、AIにすべての実装を丸投げすることではありません。

むしろ重要なのは、人間が目的、制約、判断基準を整理し、AIを開発プロセスの中に組み込むことです。

AIをうまく使えると、設計のたたき台、実装案、テストケース、リファクタリング案、ドキュメント作成などを高速に進められます。一方で、前提が曖昧なまま使うと、もっともらしいけれど要件から外れたコードが出てくることもあります。

この記事では、AI駆動開発を始めるときに意識したい基本を整理します。

AI駆動開発とは何か

AI駆動開発とは、開発の各工程でAIを活用しながら、設計・実装・検証・改善を進める開発スタイルです。

たとえば、次のような場面でAIを使えます。

  • 要件の整理
  • 仕様の抜け漏れ確認
  • 実装方針の比較
  • コード生成
  • テストケース作成
  • レビュー観点の洗い出し
  • リファクタリング案の作成
  • READMEや設計メモの作成

ポイントは、AIを「実装担当者」としてだけ使わないことです。

AIは、壁打ち相手、レビュー補助、調査補助、文章化補助としても使えます。

まずAIに渡すべき情報

AIに依頼するときは、いきなり「この機能を作って」と伝えるよりも、前提を渡した方が精度が上がります。

最低限、次の情報を整理して渡すとよいです。

目的:
何を実現したいのか

背景:
なぜその機能が必要なのか

制約:
使っている技術、既存仕様、避けたい変更

期待する成果物:
コード、設計案、テストケース、レビュー観点など

完了条件:
何ができればOKか

AIは文脈があるほど、判断しやすくなります。

逆に、前提が不足していると、AIは一般論で補完します。その補完がプロジェクトの実態とズレると、後から修正が大きくなります。

良い依頼は「作業」ではなく「判断基準」を含む

AIにコードを書かせる場合でも、単に作業を依頼するだけでは不十分です。

たとえば、次のような依頼は曖昧です。

ログイン機能を作ってください。

この依頼では、認証方式、画面構成、バリデーション、エラー表示、セッション管理、テスト方針が分かりません。

もう少し具体化すると、AIの出力は安定します。

Next.jsでログインフォームを作成してください。
認証APIは既存の /api/login を使います。
入力項目は email と password です。
バリデーションは必須チェックのみで、エラーはフォーム下部に表示してください。
既存の Button コンポーネントを使い、新しいUIライブラリは追加しないでください。

このように、判断基準や制約を含めると、AIは余計な実装をしにくくなります。

AIに任せる前に分割する

大きな機能を一度に依頼すると、AIの出力も大きくなり、レビューしづらくなります。

AI駆動開発では、作業を小さく分けることが重要です。

たとえば、1つの機能を次のように分割できます。

  1. 既存コードの構成を説明してもらう
  2. 実装方針を3案出してもらう
  3. 影響範囲を洗い出してもらう
  4. 最小変更で実装してもらう
  5. テストケースを作ってもらう
  6. レビュー観点を出してもらう

この流れにすると、人間が各ステップで判断できます。

AIを使うほど、人間のレビュー責任は軽くなるのではなく、むしろ重要になります。

AIの出力は必ず検証する

AIが生成したコードは、見た目が自然でも正しいとは限りません。

特に次の点は確認が必要です。

  • 既存仕様と矛盾していないか
  • エラーケースを考慮しているか
  • セキュリティ上の問題がないか
  • 不要な依存関係を追加していないか
  • 命名や設計が既存コードと合っているか
  • テストで確認できるか

AIの出力は、あくまで提案です。

最終的にマージしてよいかを判断するのは人間です。

AI駆動開発とPLの相性

AI駆動開発は、PLの仕事とも相性がよいです。

PLは、タスクの分解、仕様の整理、レビュー観点の洗い出し、認識合わせを行います。これらはAIに相談しやすい領域です。

たとえば、次のような依頼ができます。

この機能追加について、実装前に確認すべき仕様の抜け漏れを洗い出してください。
画面、API、DB、権限、テストの観点で整理してください。

また、レビュー前にAIに観点を出してもらうことで、確認漏れを減らせます。

以下の変更差分をレビューする前に、重点的に見るべき観点を整理してください。
特に既存仕様への影響、例外ケース、テスト不足に注目してください。

AIは、PLがチームを前に進めるための補助役として使えます。

最初に作るとよいプロンプトテンプレート

AI駆動開発を始めるなら、毎回ゼロから依頼文を書くより、テンプレートを用意すると安定します。

あなたは開発チームの技術アシスタントです。
以下の前提をもとに、実装方針を提案してください。

目的:

背景:

既存仕様:

制約:

変更してよい範囲:

避けたいこと:

出力してほしいもの:
- 実装方針
- 影響範囲
- 確認すべき仕様
- テスト観点

このテンプレートを使うと、AIとの会話が作業依頼ではなく、開発の整理になります。

まとめ

AI駆動開発で大切なのは、AIに丸投げすることではありません。

人間が目的、制約、完了条件を整理し、AIに適切な単位で依頼し、出力を検証することです。

AIは、実装を速くするだけでなく、設計の壁打ち、仕様の抜け漏れ確認、レビュー観点の整理にも役立ちます。

最初は、小さなタスクから始めるのがおすすめです。

いきなり本番機能を丸ごと任せるのではなく、既存コードの理解、実装方針の比較、テストケース作成など、レビューしやすい範囲からAIを開発プロセスに組み込むと、効果を感じやすくなります。

FROM KNOWLEDGE TO PRODUCT

この知識を使ったWorks

この記事の最新差分を見る
前回更新との差分
 追加: AI駆動開発は、AIにすべての実装を丸投げすることではありません。
 追加: むしろ重要なのは、人間が目的、制約、判断基準を整理し、AIを開発プロセスの中に組み込むことです。
 追加: AIをうまく使えると、設計のたたき台、実装案、テストケース、リファクタリング案、ドキュメント作成などを高速に進められます。一方で、前提が曖昧なまま使うと、もっともらしいけれど要件から外れたコードが出てくることもあります。
 追加: この記事では、AI駆動開発を始めるときに意識したい基本を整理します。
削除: AI駆動開発のはじめ方追加: AI駆動開発とは何か
 追加: AI駆動開発とは、開発の各工程でAIを活用しながら、設計・実装・検証・改善を進める開発スタイルです。
 追加: たとえば、次のような場面でAIを使えます。
 追加: 要件の整理仕様の抜け漏れ確認実装方針の比較コード生成テストケース作成レビュー観点の洗い出しリファクタリング案の作成READMEや設計メモの作成
 追加: ポイントは、AIを「実装担当者」としてだけ使わないことです。
 追加: AIは、壁打ち相手、レビュー補助、調査補助、文章化補助としても使えます。
 追加: まずAIに渡すべき情報
 追加: AIに依頼するときは、いきなり「この機能を作って」と伝えるよりも、前提を渡した方が精度が上がります。
 追加: 最低限、次の情報を整理して渡すとよいです。
 追加: 目的:
 追加: 何を実現したいのか
 追加: 背景:
 追加: なぜその機能が必要なのか
 追加: 制約:
 追加: 使っている技術、既存仕様、避けたい変更
 追加: 期待する成果物:
 追加: コード、設計案、テストケース、レビュー観点など
 追加: 完了条件:
 追加: 何ができればOKか
 追加: AIは文脈があるほど、判断しやすくなります。
 追加: 逆に、前提が不足していると、AIは一般論で補完します。その補完がプロジェクトの実態とズレると、後から修正が大きくなります。
 追加: 良い依頼は「作業」ではなく「判断基準」を含む
 追加: AIにコードを書かせる場合でも、単に作業を依頼するだけでは不十分です。
 追加: たとえば、次のような依頼は曖昧です。
 追加: ログイン機能を作ってください。
 追加: この依頼では、認証方式、画面構成、バリデーション、エラー表示、セッション管理、テスト方針が分かりません。
 追加: もう少し具体化すると、AIの出力は安定します。
 追加: Next.jsでログインフォームを作成してください。
 追加: 認証APIは既存の /api/login を使います。
 追加: 入力項目は email と password です。
 追加: バリデーションは必須チェックのみで、エラーはフォーム下部に表示してください。
 追加: 既存の Button コンポーネントを使い、新しいUIライブラリは追加しないでください。
 追加: このように、判断基準や制約を含めると、AIは余計な実装をしにくくなります。
 追加: AIに任せる前に分割する
 追加: 大きな機能を一度に依頼すると、AIの出力も大きくなり、レビューしづらくなります。
 追加: AI駆動開発では、作業を小さく分けることが重要です。
 追加: たとえば、1つの機能を次のように分割できます。
 追加: 既存コードの構成を説明してもらう実装方針を3案出してもらう影響範囲を洗い出してもらう最小変更で実装してもらうテストケースを作ってもらうレビュー観点を出してもらう
 追加: この流れにすると、人間が各ステップで判断できます。
 追加: AIを使うほど、人間のレビュー責任は軽くなるのではなく、むしろ重要になります。
 追加: AIの出力は必ず検証する
 追加: AIが生成したコードは、見た目が自然でも正しいとは限りません。
 追加: 特に次の点は確認が必要です。
 追加: 既存仕様と矛盾していないかエラーケースを考慮しているかセキュリティ上の問題がないか不要な依存関係を追加していないか命名や設計が既存コードと合っているかテストで確認できるか
 追加: AIの出力は、あくまで提案です。
 追加: 最終的にマージしてよいかを判断するのは人間です。
 追加: AI駆動開発とPLの相性
 追加: AI駆動開発は、PLの仕事とも相性がよいです。
 追加: PLは、タスクの分解、仕様の整理、レビュー観点の洗い出し、認識合わせを行います。これらはAIに相談しやすい領域です。
 追加: たとえば、次のような依頼ができます。
 追加: この機能追加について、実装前に確認すべき仕様の抜け漏れを洗い出してください。
 追加: 画面、API、DB、権限、テストの観点で整理してください。
 追加: また、レビュー前にAIに観点を出してもらうことで、確認漏れを減らせます。
 追加: 以下の変更差分をレビューする前に、重点的に見るべき観点を整理してください。
 追加: 特に既存仕様への影響、例外ケース、テスト不足に注目してください。
 追加: AIは、PLがチームを前に進めるための補助役として使えます。
 追加: 最初に作るとよいプロンプトテンプレート
 追加: AI駆動開発を始めるなら、毎回ゼロから依頼文を書くより、テンプレートを用意すると安定します。
 追加: あなたは開発チームの技術アシスタントです。
 追加: 以下の前提をもとに、実装方針を提案してください。
 追加: 目的:
 追加: 背景:
 追加: 既存仕様:
 追加: 制約:
 追加: 変更してよい範囲:
削除: この記事で伝えたいこと追加: 避けたいこと:
削除: AI駆動開発は、AIに丸投げする開発ではありません。 
削除: 人間が目的、制約、確認観点を決め、AIを実装や整理の補助として使う開発スタイルです。 
削除: 最初に決めること 
削除: AIに依頼する前に、以下を決めます。 
削除: 何を作るのかなぜ作るのかどこまでを今回作るのか既存コードのどこを触ってよいのか完了条件は何か 
削除: ここが曖昧だと、AIの出力も曖昧になります。 
削除: 良い依頼の例 
削除: WordPressテーマの管理画面に、GitHubリポジトリ一覧を表示するページを追加したい。 
削除: まずはpublic repositoryのみ対応でよい。 
削除: 既存のportfolio投稿タイプにWorks下書きを作成できるようにしたい。 
削除: 目的、範囲、制約が入っているため、実装に進みやすくなります。 
削除: AIに任せすぎない 
削除: AIはコードを書けますが、プロダクトの意図や運用上の判断は人間が持つ必要があります。 
削除: 特に以下は人間が確認します。 
削除: セキュリティ既存仕様との整合性データが壊れないかUIが運用しやすいかテストや確認方法 
 追加: 出力してほしいもの:
 追加: - 実装方針
 追加: - 影響範囲
 追加: - 確認すべき仕様
 追加: - テスト観点
 追加: このテンプレートを使うと、AIとの会話が作業依頼ではなく、開発の整理になります。
変更なし: まとめ変更なし: まとめ
削除: AI駆動開発では、AIに何をさせるかよりも、人間が何を決めるかが重要です。追加: AI駆動開発で大切なのは、AIに丸投げすることではありません。
削除: 良い前提を渡すほど、AIの出力は実用的になります。 
 追加: 人間が目的、制約、完了条件を整理し、AIに適切な単位で依頼し、出力を検証することです。
 追加: AIは、実装を速くするだけでなく、設計の壁打ち、仕様の抜け漏れ確認、レビュー観点の整理にも役立ちます。
 追加: 最初は、小さなタスクから始めるのがおすすめです。
 追加: いきなり本番機能を丸ごと任せるのではなく、既存コードの理解、実装方針の比較、テストケース作成など、レビューしやすい範囲からAIを開発プロセスに組み込むと、効果を感じやすくなります。

この記事は役に立ちましたか?