デフエンジニアの会アドベントカレンダー１６日目に参加しています。
AI駆動開発とは何か
― 「AIに書かせる」から「AIと設計する」へ ―
はじめに
生成AIの登場によって、開発現場は一気に変わりました。
コード補完、テスト生成、リファクタリング、設計相談。
もはや「AIを使わずに開発する」方が珍しくなりつつあります。
そんな中でよく聞くようになった言葉が AI駆動開発（AI-driven development） です。
ただし、ここで言うAI駆動開発は
「AIにコードを書かせる開発」ではありません。
意識すべきなのは、開発の意思決定プロセスにAIを組み込むこと だと思っています。
Claude、GPT、Geminiなどの最新の大規模言語モデル（2025年12月現在はClaude Sonnet 4.5、GPT-5.2など）は、単なるコード生成を超えてシステム設計の壁打ち相手としても実用レベルに達しています。ただし、その分「何を聞くか」「どう判断するか」の重要性も増しました。
この記事では、
- AI駆動開発の考え方
- 実務での使いどころ
- ハマりがちな落とし穴
このあたりを整理してみます。
本記事について
本記事は、以前投稿した「AI時代に強いエンジニアとは① ー生成AIのハルシネーションとどう向き合うかー」の続編的な位置づけです。
前回の記事では、「AIがあるからエンジニアは不要になるのか？」 という問いに対して、生成AIのハルシネーション（もっともらしい嘘を生成する現象）を通じて、むしろ 「コードが書けて、AIの出力を評価できるエンジニアの価値が高まる」 という結論を示しました。
本記事では、その前提を踏まえて、「では、そのAIをどう使いこなすのか？」 という実践編として、AI駆動開発の具体的な考え方と手法を解説したいと思います。
※私なりの解釈です
AI駆動開発を一言で言うと
AIを「作業者」ではなく「思考補助エンジン」として使う開発スタイル
これが一番しっくりくる定義だと思います。
よくある誤解
- AIが全部コードを書く
- 人間はレビューするだけ
- 楽して爆速開発
現実はそんなに甘くありません。
AI駆動開発では、人間の役割はむしろ増えます。
- 何を作るのか
- どういう制約があるのか
- 出力は正しいか
- 保守できるか
この判断を より高い粒度で 行うためにAIを使う、という発想になるのではないでしょうか。
従来開発との違い
従来の流れ（ざっくり）
- 要件定義
- 設計
- 実装
- テスト
- 修正
AI駆動開発の流れ
- 要件を言語化
- AIに仮設計をぶつける
- 違和感を見つける
- 設計を詰め直す
- 実装をAIと分担
- テスト観点をAIに洗い出させる
ポイントは 往復回数が増えること です。
一発で正解を出すのではなく、「仮説→検証→修正」を高速で回すということだと思います。
中級者にとっての一番の価値
私なりの感想としては、
初級者よりも中級者の方がAIの恩恵は大きいのではと感じます。
理由はシンプルです。
- 知識があるから、ある程度「おかしさ」に気づける
- 設計の良し悪しを判断できる
- 出力をそのまま信じない
AIは「それっぽいもの」を出すのが得意です。
だからこそ、それを疑える人 が一番強いです。
ということで、やはり「AIがあればエンジニアなくなるのでは」ということに対しては「NO」だと思います。
ただ、いつかAIが完全に人間と同じように思考し、ハルシネーションも完全になくなったら・・・？とも思いますよね。
それについては、後編でまとめているのでそれを読んでいただけると嬉しいです。
実務で使えるAI駆動開発の具体例
① 設計レビュー役として使う
コードを書かせる前に、まず聞きます。
実際の使い方:
ChatGPTやClaudeに以下のように相談してみます。
このユーザー認証の設計レビューをお願いします。
【あなたの設計内容をここに貼り付け】
例:
- JWTトークンをlocalStorageに保存
- トークンの有効期限は24時間
- リフレッシュトークンは使わない
- ログイン失敗は3回まで許容
特に以下の観点で:
- この設計の問題点は？
- 保守で辛くなりそうな点は？
- 想定される変更に弱い部分は？
ここで出てくる指摘は、
「全部正しい」わけではありませんが、論点の洗い出しとしては非常に優秀です。
特に「自分では気づかなかった観点」が出てくることが多いです。
② 実装方針の比較をさせる
例えば、
- パターンAとBの違い
- パフォーマンス面の差
- テストしやすさ
実際の使い方:
ChatGPTやClaudeに以下のように相談します。
キャッシュ戦略について相談したい。
状況:
- ユーザー情報APIのレスポンスが遅い
- 更新頻度は低い（1日数回程度）
- 同時アクセスは多い
以下の3つのアプローチについて、
トレードオフを整理してほしい:
1. インメモリキャッシュ（例: Redis）
2. アプリケーション内メモリキャッシュ
3. CDN活用
特に「運用面での辛さ」に注目してほしい。
人間が1つずつ考えると時間がかかる部分を、
AIに横並びで出させます。
決めるのは人間。
考える材料を集めるのがAIという風に考えます。
③ テスト観点の抜け漏れチェック
これはかなり実用的です。
- 境界値
- 例外ケース
- 想定外入力
実際の使い方:
以下のバリデーションロジックのテストケースを洗い出してほしい。
特に「見落としがちな境界値」と「例外パターン」に注目して。
[コードを貼り付け]
「自分が書いたコード」をAIに説明して、
「壊しに来て」 と頼みます。
嫌なところを的確に突いてくることが多いです。
④ アーキテクチャの代替案検討
実際の使い方:
ChatGPTやClaudeに以下のように相談します。
新規サービスのアーキテクチャ選定で迷っている。
要件:
- 初期は小規模だが、急成長の可能性あり
- チームは3名、全員フルスタック
- インフラ運用コストは抑えたい
以下の選択肢のトレードオフを整理してほしい:
1. モノリス（例: Rails on HerokuなどのPaaS）
2. マイクロサービス（例: Kubernetesなどのコンテナオーケストレーション）
3. サーバーレス（例: AWS Lambda + DynamoDBなどのFaaS構成）
特に「後から後悔しそうなポイント」を重点的に。
「どっちが正解？」ではなく、
「トレードオフは何？」 をAIに整理させます。
AI駆動開発の落とし穴
① プロンプト依存症
いい結果が出ると、
「この聞き方じゃないとダメ」になりがちです。
でも本質はプロンプトではなく、
問いの立て方そのもの です。
改善策:
プロンプトを磨くより、
「自分が本当に知りたいことは何か」を明確にする方が重要です。
② 正解っぽさに騙される
AIの一番怖いところです。
- 動く
- それっぽい
- 文章も綺麗
でも、
- 将来の変更に弱い
- 意図が不明
- なぜそうしたのか説明できない
というコードが量産される危険があります。
改善策:
AIの出力に対して必ず「なぜ？」を問い返します。
説明できないコードは採用しません。
③ 思考停止
AIが優秀すぎると、人間が考えなくなります。
これは一番やってはいけません。
AI駆動開発は、
考えなくていい開発ではなく、より考える開発 です。
改善策:
「AIに丸投げ」ではなく「AIと壁打ち」。
最終判断は必ず自分の頭で行います。
では、どう付き合うのが正解か
個人的な結論はこれです。
AIは「即答マシン」ではなく「壁打ち相手」
- 速く否定してくれる
- 別視点をくれる
- 思考を整理してくれる
その代わり、
最終責任は必ず人間が持ちます。
具体的な実践例
Before（従来の開発）
「このAPIのエンドポイント設計、どうしようかな...」
→ ドキュメントを漁る、過去の実装を見る、試行錯誤
→ 数時間かけて1つの案を作る
→ レビューで問題が発覚
After（AI駆動開発）
ChatGPTやClaudeに以下のように相談:
ユーザー管理APIのエンドポイント設計について相談したい。
要件:
- ユーザーCRUD
- 認証機能
- 将来的にロール管理を追加する可能性
RESTful設計での問題点と、代替案を教えて。
特に『後から変更しづらい部分』に注目してほしい。
結果:
→ 3つの設計案 + それぞれのトレードオフが即座に返ってくる
→ 論点が明確になり、判断に集中できる
→ 30分で複数案を比較検討できる
AI駆動開発は、
エンジニアを不要にするものではありません。
むしろ、
- 設計力
- 判断力
- 言語化力
こうした 「人間側のスキル」を
より強く要求する開発スタイル だと思っています。
AIと競争するのではなく、
AIを使って思考の質を上げる。
これがAI駆動開発の面白さだと思います。
おわりに
AI駆動開発で実感する「エンジニアの価値」
前回の記事「AI時代に強いエンジニアとは① ー生成AIのハルシネーションとどう向き合うかー」では、AIのハルシネーション（誤情報生成）を例に、なぜAI時代でもエンジニアが必要なのか を論じました。
本記事でAI駆動開発の実践を通じて改めて実感するのは、まさにその点です。
AI駆動開発を実践すればするほど、人間の判断が重要になります。
- AIが出した3つの設計案、どれを選ぶ？
- この実装は保守しやすいか？
- 将来の変更に耐えられるか？
- セキュリティリスクはないか？
これらの判断には、技術的知識、経験、そして責任 が必要です。
前回の記事で述べた「コードが書けて、AIの出力を評価できる人」が強いという話は、
AI駆動開発の現場でまさに現実のものとなっています。
つまり
AI駆動開発の時代は、
「手を動かすエンジニア」から「思考するエンジニア」への転換点です。
AIが優秀になるほど、
- 深く考えられる
- 適切に判断できる
- チームを導ける
こうしたエンジニアの希少価値は上がり続けます。
だからこそ、AI駆動開発を学ぶことは、
自分の市場価値を高める投資になります。
AIに仕事を奪われるのではなく、
AIを使いこなして、より価値の高い仕事をする。
それが、これからのエンジニアの生き方だと私は考えています。