AI駆動開発とは？変わる開発工程と、成果が出る組織の条件

AI駆動開発という言葉は聞いても、個人のコーディング効率化止まりで組織の体制まで落とし込めていない受託開発会社は多いです。AI駆動開発とは、要件定義から保守までの開発プロセス全体にAIを組み込む手法を指します。本記事のテーマは、工程別に何が変わるか、そしてレビュー体制や人材配置の見直し方です。読み終えたときには、自社の開発体制のどこから着手するかを判断する材料が手元に残ります。

目次

AI駆動開発とは

AI駆動開発の要点は、AIを個々のエンジニアの補助ツールとして足すのではなく、要件定義から保守までの各工程にAIが入る前提で開発プロセスそのものを組み直すところにあります。似た言葉に「バイブコーディング」がありますが、指している範囲はまったくの別物です。

バイブコーディングとの違い

「バイブコーディング」は、Andrej Karpathy氏が2025年2月2日にXへ投稿した文章が起点とされる言葉です。diffを読まずに生成結果を採用し続ける、本人のワークフローを指し、学術的な定義とは言えません。AI駆動開発は、設計・レビュー・テスト・保守を組織プロセスに組み込む開発手法を指す言葉として使い分けられています。「AIDD」という略語自体の提唱者は不明です。

仕様駆動開発との違い

「仕様駆動開発」という言葉は、要件や仕様書を明文化してからAIに実装させる進め方を指して使われることがあります。特定の団体による確立した定義は確認できておらず、AI駆動開発という大きな枠組みの中で、仕様の明文化を重視する進め方を指す呼び方として使われているのが実情です。要件定義や設計を先に明文化してから着手する考え方として捉えます。

個人のAI活用と組織のAI駆動開発の違い

個人がCursorやGitHub Copilotを使いこなすことと、組織でAI駆動開発を回すことは別の話です。個人利用は生産性向上で完結しますが、組織のAI駆動開発ではレビューフローや権限設計まで含めて設計し直す必要があります。当社は静的解析や自動テストによる機械的な検証を基本に置き、知見のない領域にAIレビュー、重要な機能に人の判断を入れる形で運用しています（2026年9月時点）。

出典：Andrej Karpathy氏 公式X投稿「vibe coding」

AI駆動開発で期待できる効果と、過大評価しやすい点

AI駆動開発の効果は、調査条件によって数値が大きく変わります。ここでは公表されている一次データを、限定条件つきで整理します。

効果として報告されていること

開発者生産性の計測を手がけるDXが2026年7月に公開したQ2レポートでは、500チーム超のデータをもとに、AIが計測可能な速度の向上をもたらしていると報告されました。同レポートによると、AIが生成したコードの割合は2026年Q1で34%、Q2では52%です。Google CloudのDORAチームが2025年9月公開時点でまとめた調査でも、AI利用はスループットや製品パフォーマンスと正の関係があると報告されています。

条件によっては効果が出ないこと

METRが2025年前半のモデルを対象に行った調査では、経験豊富なOSSの開発者16名による平均2時間の実務Issueで、AI利用によって完了までの時間が19%長くなったと報告されています。特定条件下で観測された結果であり、一般化はできないという留保つきの数値です。DORAが2026年4月に更新した最新レポートは、導入直後に生産性が一時的に落ち込む局面を前提に置き、投資判断の枠組みを示しています。着手直後の数字だけで打ち切る判断は避けます。

効果を測る指標の置き方

Stack Overflowの2025年調査（177カ国・49,000件超の回答）では、AIツールを使っている、または使う予定と答えた開発者が84%に達しました。一方で、出力の精度を信頼しないと答えた開発者は46%で、前年の31%から増えています。当社は実装の速さだけを見ず、各工程にかかっている時間とボトルネックを把握したうえで、開発全体で何を改善するかを決めています。

出典：DX「The State of AI Impact in Engineering: Q2 2026」

出典：DORA「ROI of AI-assisted Software Development report」

出典：Google Cloud Blog「Announcing the 2025 DORA report」

出典：METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」

出典：Stack Overflow「2025 Developer Survey」

AI駆動開発で変わる開発工程

要件定義から運用・保守まで、AI駆動開発では各工程の作業内容とレビューの重心が変わります。工程ごとに何が変わるかを整理します。

要件定義・設計

Google CloudのDORAチームが2025年9月に公開した調査では、疎結合なアーキテクチャと速いフィードバックループを持つチームが効果を得たという報告です。逆に、密結合で遅いプロセスのチームは、ほとんど効果を得られませんでした。AIに実装を任せる前提は、要件と設計をどこまで明文化・分割できているかです。当社は要求要件・設計書を一元管理し、受け入れ基準から実装・テストまで対応関係をたどれるようにしています。

実装

コード解析のGitClearが6億2,300万件の変更を調べた調査では、コミット内のコピー＆ペーストが2022年の9.4%から2026年上半期の15.7%へ上がりました。速度は上がる一方で、保守しにくいコードが積み上がる動きも起きています。実装では、レビュー観点を人の記憶に頼らず仕組み側へ置くことが要点です。当社はベストプラクティスや実装方法をSkills（AIが参照する再利用可能な手順・知見）として渡し、実装の段階から品質を高めています。

テスト

AI利用はスループットや製品パフォーマンスと正の関係がある一方、自動テストやバージョン管理体制が整っていない場合はデリバリーの安定性と負の関係になるというのが、DORA 2025の調査結果です。変更量の増加を安定性の低下に直結させない条件は、AIが生成したテストケースを既存の自動テストの代わりにせず、回帰テスト（改修の影響確認テスト）が落ちたらマージを止める運用まで用意しておくことです。

運用・保守

AI駆動開発では、各変更の背景・目的・影響範囲をプルリクエストへ記録し、設計ドキュメントと変更履歴を同時に更新する作業の重要度が増します。背景や時点の分からない情報が混ざると、AIが古い判断を取り込むコンテキスト汚染が起こりがちです。当社は情報を一元管理し、その決定が「なぜ・いつ行われたか」「現在どれが有効か」を追える状態づくりを進めています。意思決定はADR（アーキテクチャ決定記録）として蓄積します。

出典：Google Cloud Blog「Announcing the 2025 DORA report」

出典：GitClear「The Maintainability Gap: AI Code Quality in 2026」

AI駆動開発を組織で回すための3つの条件

工程ごとの変化を押さえても、承認権限とレビュー観点を決めないままでは手戻りが増えます。受託開発会社がAI駆動開発を回すには、レビュー体制・権限設計・人材配置という3つの観点を整備することが前提です。

レビュー体制と品質担保

AIが生成したコードをそのままマージする運用は、品質のばらつきを生む温床です。誰が・どの段階で・何を承認するかを、プルリクエストのテンプレートに承認者とレビュー観点として明記すると、レビュー体制が運用に乗ります。IPAの生成AI導入・運用ガイドラインでも、リスク管理体制の整備が論点に挙げられています。当社は品質基準をハーネスとして開発へ組み込み、機械的に検証できる範囲を広げ、重要な機能に人の判断を残す進め方です。

権限設計とセキュリティ・ガバナンス

AIツールに渡してよい情報は、顧客の機密区分ごとに可否を一覧化しておくと判断がぶれません。OWASPが公開するLLMアプリケーション向けのリスク一覧にも、プロンプトインジェクションや機密情報の漏えいが項目として並ぶのが実情です。CursorのプライバシーモードはFree・Proを問わず使え、有効にすると学習に使われません。GitHub Copilotもアカウント設定からいつでも学習利用を停止できます（2026年9月時点）。チーム契約では管理者の設定が新メンバーへ引き継がれるため、個人任せにせず組織側で既定値を決めておきます。

人材配置と見積・契約の考え方

AI駆動開発が進むと、要件定義とレビューを担える人材の配置が要点になり、プログラマーの人数を積み上げるだけでは対応しきれません。SESやフリーランス依存の体制では、AI生成コードを評価できる人材の不足がボトルネックになりやすい領域です。当社は工程・技術領域別の分業よりも、機能単位で担当し必要な領域をまたいで進めます。各人の知見はSkillsや共通の開発基盤へ残し、再利用できる形が前提です。見積も人月単位だけに頼らない算定をしています。

出典：IPA「テキスト生成AIの導入・運用ガイドライン」

出典：OWASP「OWASP Top 10 for Large Language Model Applications」

出典：Cursor「Security」

出典：GitHub「Copilot plans」

AI駆動開発を導入する前に決める3つのこと

AI駆動開発は、思いつきで全社導入すると混乱を招きます。当社が導入時にまず整理するのは、次の3点です。進め方そのものは各社の課題や体制に合わせて組み立てるため、共通の固定手順があるわけではありません。

推進担当者を決めて取り組む時間を確保する

最初に決めるのは、誰が推進役を担い、その人がどれだけの時間を取れるかです。通常業務の片手間で進めると、検証も振り返りも後回しになり、効果を判断できないまま立ち消えになります。担当と時間を先に確保しておくことが、以降の判断材料を残す前提になります。

学んだことを実践する対象プロジェクトを決める

次に決めるのは、学んだ内容を実際に試す対象です。対象は顧客案件に限らず、社内向けの開発でも構いません。実務で使わないとツールの評価だけで終わり、工程やレビューの設計まで踏み込めないためです。

現状の工程・工数を把握して成功基準を決める

最後に決めるのは、現状の工程と工数をどう把握し、何をもって成功とするかです。着手前の数字がないと、速くなったのか、どこが詰まっているのかを後から比較できません。工程ごとの時間を残しておくと、次にどこへ手を入れるかの判断がつきます。

AI駆動開発の体制づくりをLiacが支援できること

AI駆動開発を組織で回す段階で論点になるのは、ツールの導入よりも、レビュー体制や権限設計、人材配置まで踏み込んだ体制設計です。個人のAI活用や情報共有が進んでいても、共通の開発方法・品質基準・知見を蓄積する仕組みが整わなければ、組織としての成果にはつながりにくいままです。当社は、各社の課題や開発体制に合わせて実際のプロジェクトで使える仕組みを整え、その知見を組織に残すことを重視し、技術とビジネスの両観点から伴走しています。AI駆動開発の体制づくりについては、LiacのAIコンサルティングで支援しています。

AI駆動開発についてよくある質問

Q1. AI駆動開発とはどういう意味ですか？

AI駆動開発とは、コードを書く工程だけでなく、要件定義からレビュー、テスト、保守までの開発プロセス全体にAIを組み込む開発手法です。個人がツールを使いこなすことではなく、組織のプロセスとしてAIを運用する点が特徴です。似た言葉に「バイブコーディング」がありますが、指す範囲が異なります。

Q2. AI駆動開発とバイブコーディングの違いは何ですか？

バイブコーディングは、Andrej Karpathy氏が2025年2月2日にX投稿で語った、diffを読まずAIの生成結果を採用し続ける個人的なワークフローを指す言葉です。AI駆動開発は、設計・レビュー・テスト・保守を組織のプロセスに組み込む開発手法という点で、対象とする範囲が違います。両者を同じ意味で使うと、組織的な体制の議論が曖昧になります。

Q3. AI駆動開発の導入にはどのようなステップが必要ですか？

着手前に決めるのは、推進担当者と取り組む時間の確保、実践する対象プロジェクト、現状の工程・工数の把握と成功基準の3点です。進め方は各社の課題や体制によって変わるため、共通の固定手順はありません。詳しくは本記事の「AI駆動開発を導入する前に決める3つのこと」で解説しています。

Q4. AI駆動開発の課題やデメリットは何ですか？

AI駆動開発の課題は、レビュー工数の増加とセキュリティリスク、そして人材のスキルシフトです。METRが2025年前半のモデルを対象に行った調査では、経験豊富なOSSの開発者16名・平均2時間の実務Issueという条件で、AI利用によって完了までの時間が19%長くなったと報告されています。対象や条件によって結果は変わります。過信せず、レビュー体制とセキュリティ対策を整えることが欠かせない条件です。

Q5. AI駆動開発の導入は自社だけでも進められますか？

自社の体制やスキルセットによっては、要件定義やレビュー体制の整備を自社だけで進めるのが難しい場合もあります。当社では、AI駆動開発の体制構築そのものを支援しており、既存の開発体制を活かしながら伴走することも可能です。自社に合った進め方を知りたい方は、お問い合わせから相談できます。

出典：METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」

まとめ：AI駆動開発は組織の体制づくりから始めよう

AI駆動開発は、個人のツール活用ではなく、要件定義から保守までのプロセス全体にAIを組み込む組織的な取り組みです。工程ごとにレビューの重心が変わること、権限設計とレビュー体制が品質を左右すること、人材配置と見積の考え方まで見直す必要があることが、成果を出す組織に共通しています。まずは現行のレビュー手順・承認権限・データの持ち出しルールを棚卸しし、自社の開発体制のどこから着手するか整理してみてください。

自社に当てはめるとどうなるかは、状況によって変わります。Liacへのお問い合わせからご相談ください。