AI駆動開発とは？AI時代に何をどこまで任せるべきか
AI駆動開発とは、生成AIを一部の補助ではなく開発工程全体の推進力として活用する考え方です。 Appli Parkでの「何食べたい」の実装例をもとに、AIへ渡した条件、人間が決めた範囲、実装後の確認を個人的な視点から整理します。
CONTENTSこの記事の目次7項目
設計、実装、テスト、レビュー、文章作成。 生成AIに任せられる仕事は、コードを書くことだけではなくなりました。 Appli Parkでも、アイデアの整理から仕様づくり、実装、確認、改善まで、すべての工程でAIを活用しています。 では、開発者は何をAIへ任せ、何を自分で担うべきなのでしょうか。
AI駆動開発とは何か
この記事での定義
- AI駆動開発
- 生成AIを単発の補助ツールとして使うだけでなく、企画・設計・実装・テスト・レビュー・運用改善といった開発工程全体の推進力として組み込む進め方。
AI駆動開発という言葉に、業界で完全に統一された境界があるわけではありません。 コード補完だけを指す場合もあれば、AIエージェントが複数工程を連続して進める形まで含める場合もあります。 この記事では、AIが実作業を広く担い、人間が目的・制約・合格条件を決めて成果を確認する進め方として扱います。
Appli Parkでは、すべての工程でAIを使っている
Appli Parkでは、実装だけをAIへ依頼しているわけではありません。 作りたい体験を言葉にするところから、仕様の整理、リスクの洗い出し、コード作成、テスト、画面確認、記事作成、運用改善まで、各工程でAIと対話しながら進めています。 もちろん、AIが自動的に正解を知っているわけではありません。 工程ごとに目的と確認項目を渡し、出てきた成果を次の判断材料にしています。
- 何を、誰のために作るのかを整理する
- 仕様・制約・リスク・完了条件を言語化する
- AIに実装や文章作成を任せる
- テストや画面確認で、目的を満たしたか確かめる
- 結果を見て方針を修正し、もう一度AIへ伝える
実例：「何食べたい」を企画から確認まで
公開中の「何食べたい」は、昼か夜を選び、10回の2択に答えると主候補と代替候補を出すアプリです。最初に管理人が決めたのは、料理を断定することではなく、「なんでもいい」で止まった会話を少し進めることでした。AIへ渡した条件も、この目的から逆算しています。回答を保存しない、外部のAI APIへ送らない、同じ質問内で料理を重複させない、戻る・やり直す操作を用意する、といった条件です。
| 工程 | リポジトリで確認できる内容 | 管理人が決めたこと・確認したこと |
|---|---|---|
| 目的 | 昼／夜を選び、10回の2択から現在の気分に近い料理を提案する。 | 正解を断定せず、ごはん会議を進める補助にする。 |
| 条件 | 回答と結果はブラウザのメモリ内だけに置き、URL・端末・DBへ保存しない。実行時に外部AI APIも呼ばない。 | 保存・共有・注文や予約連携は初期範囲に入れず、まず選択体験を完成させる。 |
| 実装 | 料理には6つの味・食感軸を持たせ、選んだ料理と選ばなかった料理の差から候補を計算する。 | 単純な平均だけで中央寄りの料理に集めず、重み付き中央値と料理系統の評価を採用する。 |
| 見直し | 初版公開後、料理候補を100件から118件へ増やし、料理系統の評価を追加した履歴が残っている。 | AIの出力を完成扱いせず、候補の偏りを見直して仕様と実装を更新する。 |
| 確認 | 118件のID・画像・プロフィール、10問20枠の重複なし、各食事1024通りの回答経路を自動確認。画面遷移と提案理由はブラウザでも確認。 | テスト成功だけで公開可否を決めず、文言が断定的でないか、料理名と画像が一致するか、未確認事項が残っていないかを見る。 |
人間の役割は、方針を決めて実現できたか確認すること
AIへ作業を任せるほど、人間の仕事は「手を動かすこと」から「どこへ進むかを決めること」へ移ります。 何を作るかだけでなく、なぜ作るのか、誰にどうなってほしいのか、何をしてはいけないのかまで決める。 そのうえで、完成した画面やテスト結果を見て、狙った体験が実現できているかを確認します。
方針をAIへ伝えるには、抽象語を確認可能な条件へ変える
「使いやすくして」「安全にして」「いい感じに作って」だけでは、AIは人間の頭の中にある完成像を共有できません。 方針を具体化するときは、次の4点に分けると伝わりやすくなります。
- 背景と目的：誰の、どんな困りごとを解きたいのか
- 求める結果：利用後に、何ができる状態なら成功か
- 制約と優先順位：守ること、しないこと、迷ったときに優先すること
- 確認方法：どの画面、テスト、数値、文章を見れば完成と判断できるか
たとえば「入力画面を使いやすくする」ではなく、「スマートフォンで片手操作する人を想定し、主要操作を3ステップ以内にする。入力エラーはその場で理由を示し、入力済みの内容を消さない。幅375pxの画面とキーボード操作で確認する」と伝えます。 実装方法を細かく指定する前に、目的と合格条件を具体化するのがポイントです。
AI駆動開発に必要なのは、ゴールと手段を考える力
AIを使うために最初からすべての技術を知っている必要はありません。 ただし、目指すゴールを見失わない人と、そのための手段を合理的に選べる人は必要です。 AIの提案をそのまま採用するのではなく、 「この方法は目的に対して過剰ではないか」 「もっと小さく安全に試せないか」 「確認可能な形になっているか」 と問い続けます。
- 作りたい機能ではなく、解決したい問題から考える
- 完成条件と中止条件を先に決める
- AIの提案を比較し、理由を説明させる
- 小さく実行し、テストや画面で事実を確認する
- うまくいかなければ、指示ではなく前提や方針から見直す
AIが増えても、確認はなくならない
AIは速く、多くの案を出し、疲れずに見直せます。 一方で、前提を取り違えたまま説得力のある答えを返すこともあります。 だからこそ、確認は「AIの文章を信じるか」ではなく、動く画面、テスト結果、一次情報、実際の利用状況といった事実に寄せます。AIがレビューしたコードを別のAIが再確認する場合でも、同じ思い込みを引き継がないよう、役割や観点を変えることが大切です。
人間がすべてのコードを一行ずつ読むことだけが品質保証ではありません。 自動テスト、型チェック、静的解析、画面確認、失敗時の切り戻しを組み合わせ、問題を検知できる仕組みを作ることも人間の重要な仕事です。 任せる範囲が広がるほど、検証方法と停止条件を先に設計する必要があります。
まとめ：AIと張り合うのではなく、仲良くしていこう
AI駆動開発で大切なのは、人間の価値をAIとの作業量の勝負で証明することではないと思います。 AIが得意な実作業は積極的に任せ、人間はゴール、優先順位、制約、合格条件を決める。 そして、できあがったものが本当に目的を満たしているかを確かめる。 この分担ができれば、個人開発でも挑戦できる範囲は大きく広がります。
AIに勝とうとするのではなく、AIへ丸投げするのでもなく、うまく力を借りる。 そのために、自分の考えを具体化して伝える力と、結果を事実で確認する力を磨いていきたいです。 Appli Parkも、これからさらにAIと仲良くしながら、面白そうを形にしていきます。