AI駆動開発とは｜進め方と、チームで使うときの決めごと

AI駆動開発は、AIを開発の工程の中心に置き、要件の整理から設計、コード、テストまでの成果物をAIに作らせ、人は意図を伝え、計画を承認し、結果を検証する側に回る開発の進め方だ。コードの補完にAIを使うのとは、人の仕事の置き場所が違う。人が書いてAIが手伝うのではなく、AIが作って人が決める。

言葉として広まったきっかけの一つは、AWSが2025年7月31日に発表したAI-DLC（AI-Driven Development Life Cycle、AI駆動開発ライフサイクル）だ。日本語訳は2025年8月8日にAWSのブログに載った。ただ「AI駆動開発」という言葉は、会社や人によって指す範囲が違う。ここでは、AWSの方法論、開発者の調査、AIコーディングの道具の公式文書から、AI駆動開発の中身と、チームで使うときに決めておくことを整理する。

FDE（Forward Deployed Engineer）が顧客の現場で速く作れる理由の一つも、この進め方にある。職種そのものはFDEとは？Forward Deployed Engineerの意味と仕事内容で説明している。

AI駆動開発とは何か——AI支援型との違い

AWSのAI-DLCの発表は、ソフトウェア開発でのAIの使われ方を2つに分けている。一つはAI支援型で、ドキュメント作成、コード補完、テストなどの特定の作業をAIが強化する使い方。もう一つはAI自律型で、利用者の要件をもとに、人の介入なしにアプリケーション全体をAIが作ることを期待する使い方だ。AWSは、どちらも開発の速さとソフトウェアの品質の面で最適とは言えない結果を生んでおり、AI-DLCはその課題に対処するためのものだと書いている。

AI-DLCの中心にあるのは、AIが実行し、人が監視するという考え方だ。AIが詳しい作業計画を作り、意図のすり合わせのための質問をし、重要な決定は人に委ねる。人が検証したあとで初めて、AIが実装に進む。AWSはこの流れを、開始（Inception）、構築（Construction）、運用（Operation）の3つのフェーズで回すとしている。

AWSは、AIが計画、要件、設計の成果物をプロジェクトのリポジトリに保存し、フェーズをまたいで文脈を持ち続けるとしている。従来のスプリントは、週ではなく時間や日の単位で回る短い作業のサイクル「ボルト（bolts）」に置き換えるという。

私の見方では、3つの使い方の違いは、誰が作業を進め、誰が決めるかで整理できる。

AI駆動開発は、AIに任せきることではない。作業の量をAIに渡し、判断と検証を人が握り続ける進め方だ。

AIで開発は速くなるのか——調査の数字

AIを開発に使う人はすでに多い。Stack Overflowの2025年の開発者調査では、84%が開発でAIの道具を使っているか使う予定だと答え、前年の76%から増えた。GoogleのDORAが2025年9月23日に発表した「State of AI-assisted Software Development」は、世界の約5,000人の技術者への調査で、回答者の90%が仕事でAIを使い、80%以上が生産性が上がったと考えていると報告した。

一方で、出力への信頼は低い。同じStack Overflowの調査では、AIの道具の正確さを信頼していない開発者（46%）が、信頼している開発者（33%）より多かった。いちばん多い不満は「ほぼ正しいが、完全には正しくないAIの解答」で、66%が挙げた。DORAの調査でも、30%がAIの作ったコードをほとんど、あるいはまったく信頼していないと答えている。

速さそのものについては、逆の結果もある。研究機関のMETRは2025年7月10日、経験豊富なオープンソースの開発者16人が自分のリポジトリの実際の課題246件に取り組む無作為化比較試験の結果を公開した。AIの使用を許された課題では、完了までに19%長くかかった。開発者は事前にAIで24%速くなると予想し、終わったあとも20%速くなったと感じていた。METRは、これは2025年初めのAIの能力を一つの場面で切り取った結果だと断っている。

DORAの報告の中心にある見方は、AIはチームを直すのではなく、すでにあるものを増幅する、というものだ。AIの採用は、ソフトウェアのデリバリーのスループットやプロダクトの成果と正の関係があったが、デリバリーの安定性とは負の関係が続いた。DORAは、自動テスト、成熟したバージョン管理、速いフィードバックのような仕組みがないと、変更の量が増えて不安定になると説明している。

私の見方では、ここから言えるのは、AI駆動開発で速くなるかどうかは道具ではなく、AIの出力を速く確かめられる仕組みがあるかで決まる、ということだ。作る速さが上がるほど、確かめる側が詰まる。

AI駆動開発の進め方——5つの手順

AWSのAI-DLCと、Claude Codeの公式文書「Best practices for Claude Code」の推奨を、チームの手順に落とすと次の5つになる。並べ方は私の整理だ。

1. 意図を言葉にする

AIは書かれていないことを推測で埋める。何を作るか、何を作らないか、完成の条件は何かを、最初に文章にする。AI-DLCの開始フェーズで、ビジネスの意図を要件と作業の単位に分けるのはこのためだ。要件の決め方はAI開発の要件定義にまとめた。

2. 計画をAIに書かせ、人が確かめる

いきなりコードを書かせない。Claude Codeの文書は、すぐにコードを書かせると間違った問題を解くコードができることがあるとして、探索、計画、実装の順に進めることを勧め、そのためのplan mode（ファイルを読んで質問に答えるが、変更はしないモード）を用意している。AI-DLCも、AIが計画を作り、人の検証を受けてから実装する流れを中心に置いている。人が計画の段階で止めれば、間違った方向のコードを読む時間が減る。

3. AIが自分で確かめられる検証を用意する

Claude Codeの文書は、AIに自分の作業を確かめる手段を与えることを最初に挙げている。テスト、ビルドの終了コード、リンター、画面のスクリーンショットのように、合否を返すものがあれば、AIは作業し、確かめ、結果を読んで直す流れを自分で回せる。手段がなければ、人が検証の役を担うことになり、すべての間違いが人に気づかれるのを待つ。同じ文書は、検証できないなら出荷しない、とも書いている。

4. 別の目でレビューする

作った本人の文脈を持たない目で差分を見る。Claude Codeの文書は、作業を終える前に、新しい文脈のサブエージェントに差分をレビューさせ、足りない点を報告させる手順を勧めている。ただし、足りない点を探せと言われたレビュー役は、問題がなくても何かを報告しがちで、すべてを追うと作り込みすぎになるとも注意している。正しさと要件に関わる指摘だけを拾う、と先に決めておく。

5. 決めたことを指示ファイルに残す

同じ説明を毎回しないために、決めたことをファイルに残す。Claude Codeでは、CLAUDE.mdが会話の始まりに毎回読まれる。文書は、短く読みやすく保つこと、長すぎると大事なルールが埋もれて半分が無視されることを注意している。

チームで使うときの決めごと

個人で使うなら、自分の好みで道具を使えばよい。チームで使うと、人によってAIへの指示も検証の深さも違い、同じリポジトリに質の揃わないコードが入る。私の見方では、最初に次の6つを決めておく。

指示ファイルはリポジトリに入れて共有できる。Claude Codeの文書は、プロジェクトのCLAUDE.mdをバージョン管理を通じてチームで共有する指示と位置づけ、個人の好みは入れずにプロジェクトの標準に絞るよう勧めている。GitHubも、リポジトリの.githubディレクトリに置くcopilot-instructions.mdで、リポジトリ全体に効くCopilotへの指示を書けるようにしている。

DORAの報告は、組織が始めるところとして、AIの方針を明確にして広く共有すること、AIを社内の文脈につなぐこと、安全網を固めることなどを挙げている。上の表は、その3つをチームの単位に落としたものだと考えてよい。

AIに触らせてよい範囲と、入れてはいけない情報は、セキュリティの問題でもある。AIエージェントに渡す権限の考え方はAIエージェントのセキュリティに、社内の利用規程の作り方は生成AIの社内利用規程の作り方に書いた。

発注する側から見たAI駆動開発

開発を外に頼む会社にとっても、AI駆動開発は無関係ではない。受託の会社がAIで作るなら、作る速さは上がるかもしれないが、DORAの調査が示すように、検証の仕組みがなければ安定性が落ちる。私の見方では、発注の前に次の3つを聞くとよい。

1. AIが作ったコードを、どのテストとレビューで確かめているか
2. AIへの指示ファイルや設計の記録は、納品物に含まれるか
3. 自社のコードや資料を、どの道具に、どの設定で渡すか

2つ目は、内製化を考えるなら特に大事だ。指示ファイルと記録が残っていれば、自社のチームが同じ進め方を引き継げる。内製と外注の分け方はAI開発は内製か、開発会社に頼むかにまとめた。

AI駆動開発は、道具を入れれば終わる話ではない。意図を書く、計画を確かめる、検証を自動にする、決めたことを残す。この地味な仕組みを先に作ったチームほど、AIの速さを本番まで持ち込める、と私は考えている。業務のどこにAIを入れ、何を作るかから一緒に決める支援の中身はサービス詳細に書いた。