0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Naoto7124

AI駆動開発とは、単にAIを使うことではない

0
Posted at

【背景】

昨今のAIエージェントの流行に伴い、組織や現場内でも「AI駆動開発」という言葉がバズワード的に使われるようになってきました。しかし、実際にAIを用いた開発を実践していると、「AIツールを導入するだけ」の表面的な理解に対して強い違和感を覚える場面が多々ありました。
本稿は、その「もやもや」の正体について自身の持っている知識をもとに生成AIと壁打ちしながら紐解き、AI駆動開発が成立するために本当に必要な開発基盤・プロセスの前提条件について、実践者の視点から考察・言語化し、レポート化したものです。
（本稿は文書の推敲について生成AIを活用しておりますが、内容の考察・意見は私自身の一意見となります。）

― AI駆動開発（AIDD）成立のための前提条件と成熟プロセス ―

注記
本稿で用いる「AI支援開発」「AI協調開発」「AI駆動開発」の成熟モデルは、現時点で業界標準として確立された分類ではなく、AI活用の成熟段階を整理・説明するために筆者が定義した概念モデルである。
また、本稿はAI駆動開発をソフトウェア工学および開発プロセスの観点から整理し、その成立要件と今後の方向性について考察したものである。
なお、類似の目的を持つ成熟度モデルとして、ELEKSの「AI-SDLC Maturity Model」やCarnegie Mellon大学SEIとAccentureによる「AI Adoption Maturity Model」などが提唱されている。本稿のモデルはこれらを参考にしつつ、状況把握とAI駆動開発の考え方をわかりやすく伝えることを目的として、独自に簡略化・再構成したものである。

1. エグゼクティブサマリー

近年、「AI駆動開発（AI-Driven Development: AIDD）」という言葉が急速に浸透しつつある。しかし、AIコーディングツールやAIエージェントを導入するだけで、開発プロセス全体がAI駆動開発へ移行できるわけではない。

AI駆動開発の本質は、「AIを導入すること」ではなく、「AIが自律的に開発を進められる環境を整備すること」 にある。

AIは曖昧な自然言語だけでは安定した成果を出しにくい。一方で、機械可読な仕様（スペック）、十分なコンテキスト、自動テスト、CI/CDパイプラインなどが整備された環境では、高い再現性をもって実装・検証・改善を繰り返すことができる。

したがって、AI駆動開発は独立した新しい開発手法ではなく、アジャイル開発、CI/CD、クラウド、クラウドネイティブ、DevOps、DevSecOps、Platform Engineeringなど、これまで積み重ねられてきたソフトウェア開発技術・開発プロセスの進化の延長線上に位置付けられる。

本稿では、AI駆動開発の本質を整理するとともに、その成立要件、ウォーターフォール型開発との関係、そして企業がAI駆動開発へ至るまでの成熟プロセスについて考察する。

2. AI駆動開発とは何か

AI駆動開発とは、単にAIを用いてコードを補完・生成することではない。

目指す姿は、人間が定義した仕様をもとに、AIが計画・実装・検証・修正を自律的に繰り返すフィードバックループ（Agentic Loop） を実現することである。

具体的には、AIは次のような工程を反復的に実行する。

  • 仕様をもとにした各種ドキュメント生成
  • 実装コード生成
  • テストコード生成・実行
  • 静的解析
  • セキュリティチェック
  • リファクタリング
  • エラー修正（Self-Healing）
  • Pull Request作成
  • レビュー結果の反映

AIは生成結果やテスト結果を継続的にフィードバックし、自律的に改善を繰り返す。つまり、AIは「コードを書く補助者」ではなく、開発プロセスの一部を担うエージェントとして機能する。

そのためには、人間の解釈に依存する曖昧な仕様書ではなく、AIも厳密かつ一義的に解釈できる機械可読な仕様（構造化データ・型・制約） が必要となる。

3. 開発手法の位置付け

現在議論される各種開発手法は互いに競合するものではなく、それぞれ異なるレイヤーの課題を解決するためのアプローチである。

手法 主な関心事 本質的な役割
ドメイン駆動設計（DDD） ビジネス領域 「何を作るか」を整理し、ビジネスロジックをモデル化する
仕様駆動開発（Specification-Driven） 振る舞い・仕様 要件を検証可能な形で表現する（BDD・TDDの発展）
スペック駆動開発（SDD）※ 機械可読な仕様（SSOT） AI・システム双方が解釈可能な仕様・型定義を境界として固定する
AI駆動開発（AIDD） 自律化・高速化 スペックをもとにAIが実装・検証・改善を高速に繰り返す

※本稿では、OpenAPI、データベーススキーマ、型定義、Terraformなど、機械可読な仕様をSingle Source of Truth（SSOT）として開発を進めるスタイルを便宜上「スペック駆動開発（SDD）」と呼ぶ。

AI駆動開発の基本構成

【人間】
要件定義・アーキテクチャ設計・制約定義
  │
  ▼
【Spec（Single Source of Truth）】
OpenAPI / Database Schema / Type Definition / Terraform / Policy
  │
  ▼
【AI Agent（Agentic Loop）】
  ┌─────────────────────────────────────────┐
  │ コード生成                               │
  │   │                                     │
  │ テスト実行                               │
  │   │                                     │
  │ 静的解析                             　  │
  │   │                                     │
  │ セキュリティチェック                      │
  │   │                                     │
  │ 自律修正（Self-Healing）                 │
  │   │                                     │
  │ Pull Request作成                 　　　  │
  │   │                                     │
  │ レビュー結果反映           　　　 　      │
  └─────────────────────────────────────────┘
  │
  ▼
【人間】
レビュー・承認・マージ

このモデルでは、人間は要件・設計・制約・品質基準を定義し、AIはその仕様に基づいて実装・検証・改善を反復する。

つまり、人間は「何を作るか」と「品質を保証するか」を担い、AIは「定義された仕様と制約の範囲内で、実装・改善サイクルを高速化する役割」を担うという役割分担となる。このように、人間とAIがそれぞれ得意とする領域を分担することで、開発速度と品質の両立を目指すことがAI駆動開発の本質である。

4. AI駆動開発に至る技術の進化

AI駆動開発は突然誕生したものではない。ソフトウェア開発は長年にわたり、「より短いサイクルで、より安全に、より高品質なソフトウェアを提供する」という課題を解決するために進化してきた。AI駆動開発は、その進化の延長線上に位置付けられる技術・開発プロセスである。

ウォーターフォール
  │
  ▼
アジャイル開発
  │
  ▼
継続的インテグレーション（CI）
  │
  ├──────────────┐
  ▼              ▼
クラウド      Infrastructure as Code（IaC）
  │              │
  ▼              ▼
クラウドネイティブ│
  └──────┬───────┘
         ▼
       CI/CD
         │
         ▼
       DevOps
         │
         ▼
      DevSecOps
         │
         ▼
 Platform Engineering
         │
         ▼
   AI駆動開発（AIDD）

各技術は、それぞれ異なる課題を解決してきた。

技術 解決した課題
アジャイル リリースサイクルの短縮と変化への迅速な追従
CI ビルド・テストの自動化と早期品質保証
クラウド インフラ調達・環境構築時間の大幅短縮
クラウドネイティブ スケーラブルで変更容易なアプリケーションアーキテクチャの実現
Infrastructure as Code (IaC) インフラのコード化、再現性、構成管理
CI/CD ビルド・テスト・デプロイまで含めたリリース工程全体の自動化
DevOps 開発と運用の分断解消、継続的改善
DevSecOps セキュリティを開発ライフサイクルへ統合（Shift Left）
Platform Engineering 共通開発基盤をセルフサービス化し、Developer Experience（DX）を向上
AI駆動開発 AIによる実装・検証・改善サイクルの自律化

AIはこれらの自動化基盤の上で初めて最大限の能力を発揮できる。言い換えれば、AI駆動開発は「AIだけ」で成立するものではなく、自動化された開発基盤と標準化されたプロセスを前提として初めて成立する。

5. AI駆動開発への成熟モデル

（AI Development Maturity Model）

AI駆動開発は、一足飛びに実現できるものではない。実際の企業では、既存プロセスの中でAIを活用する段階から始まり、開発基盤やプロセスの成熟とともに、徐々にAI主体の開発へ移行していく。

本稿では、この成熟過程を以下の3段階として整理する。

【Level 1: AI支援開発 (AI-assisted Development)】
人間主体 / AIは補助ツール
（Copilot, ChatGPT, Cursor, GitHub Copilot など）
  │
  ▼
【Level 2: AI協調開発 (AI-enabled Development)】
既存プロセスを維持したまま各工程で人とAIが協調
（要件定義, 基本設計, 詳細設計, 製造, テスト, レビュー等、すべての工程で「人＋AI」）
  │
  ▼
【Level 3: AI駆動開発 (AI-driven Development)】
AIを前提としてプロセスそのものを再設計
（Spec → AI Agent → Generate → Test → Analyze → Fix → Review）

各成熟レベルの特徴

レベル 開発スタイル AIの役割
Level 1: AI支援開発 既存プロセスを維持し、AIを補助ツールとして利用 コーディング支援、レビュー支援、調査支援
Level 2: AI協調開発 各工程にAIを組み込み、人とAIが協調して開発を進める 工程ごとの作業支援・品質向上
Level 3: AI駆動開発 AIを前提として開発プロセスを再設計する 実装・検証・改善を自律的に実施
  • Level 1では、人間が主体であり、AIはあくまで作業効率を高めるための支援ツールとして利用される。
  • Level 2では、AIは各工程へ組み込まれ、人と協調しながら開発を進める。現在、多くの企業が目指しているAI活用は、この段階に位置付けられることが多い。
  • Level 3では、AIを既存プロセスへ適用するだけではなく、AIが最も能力を発揮できるよう、開発プロセスそのものを再設計する。

ここでは、機械可読な仕様（SSOT）を中心として、AIが自律的なフィードバックループ（Agentic Loop）を構成し、人間は要件・アーキテクチャ・品質保証・ガバナンスを担う。したがって、Level 1およびLevel 2はAI駆動開発を否定するものではなく、AI駆動開発へ至るための重要な成熟段階である。一方で、Level 3は単なるAIツールの導入ではなく、開発プロセス自体の変革を伴う点に本質的な違いがある。

AI駆動開発へ移行するために必要な要素

成熟レベルを上げるためには、AIツールの導入だけでは不十分である。次のような基盤整備が並行して求められる。

  • 機械可読な仕様（SSOT）の整備
  • OpenAPI・スキーマ・型定義の標準化
  • Infrastructure as Code（IaC）
  • 自動テスト
  • CI/CDパイプライン
  • DevSecOps
  • Platform Engineering
  • ナレッジの標準化
  • AIが利用可能なドキュメント整備

つまり、「AIを導入すること」と「AI駆動開発を実現すること」は同義ではない。AI駆動開発とは、AIが能力を最大限発揮できるよう、開発プロセス・開発基盤・組織を継続的に成熟させる取り組みそのものである。

参考：類似の成熟度モデルについて
本稿で定義したLevel1~3のモデルは業界標準ではなく、あくまで現状の把握とAI駆動開発への道筋を分かりやすく示すための簡略モデルである。類似の目的を持つ既存フレームワークとして、以下のようなものが挙げられる。

  • AI-SDLC Maturity Model (ELEKS)：Tradition(従来型)からAI-Autonomous(AI自律型)まで5段階で整理し、エンタープライズにおけるガバナンスや組織変革の観点を重視するモデル。
  • AI Adoption Maturity Model (Carnegie Mellon大学SEI・Accenture, 2026)：組織戦略、ワークフロー再設計、リスク・ガバナンス、エンジニアリングなど8つの能力領域から成熟度を評価する、より汎用的・エンタープライズ向けのフレームワーク。
  • Five Levels (Dan Shapiro)：自動運転のレベル分野を援用し、AIがどこまで人間の関与なしに開発を完遂できるかという「自律性」の観点から段階を定義するモデル。

これらは評価軸や粒度が異なるため一概に比較はできないが、いずれも「AIツールの導入」と「組織・プロセスの成熟」を区別して捉えている点で、本稿の問題意識と一致する。

6. AI駆動開発を支える前提条件

AIが高速にコードを生成しても、その成果を継続的かつ自動的に検証・改善できなければ、開発全体の生産性向上にはつながらない。AI駆動開発では、AI自身が生成結果を評価し、修正するためのフィードバックループを成立させる必要がある。

例えば、自動テストが存在しない場合、以下のような状態になる。

【自動テストが存在しない場合】

  1. AIがコード生成
  2. 人間が手動テスト
  3. 修正箇所を判断
  4. AIが再生成
  5. 人間が再度手動テスト

この場合、AIの生成速度に対して人間による確認作業がボトルネックとなり、AIの能力を十分に活用できない。同様に、以下の要素が不足している場合、AI駆動開発の効果は限定的となる。

  • CI/CDが存在しない場合
    AIが高速にコードを生成しても、ビルド・テスト・デプロイが手作業であれば、リリースまでのリードタイムは短縮されない。AIによる開発速度向上と、リリースプロセスの速度が一致して初めて価値が発揮される。
  • DevSecOpsが存在しない場合
    AIによって生成されたコードに含まれる脆弱性やライブラリリスクを継続的に検証できなければ、品質問題やセキュリティリスクを高速に拡大させる可能性がある。AIは品質保証の仕組みではなく、品質保証プロセスの上で動作する高速な生成エンジンである。
  • 機械可読な仕様が存在しない場合
    AIが自然言語のみを入力として開発を行う場合、解釈の揺れやコンテキスト不足が発生しやすい。一方で、OpenAPI, Database Schema, Type Definition, Policy, Infrastructure Definition などの機械可読な仕様をSingle Source of Truthとして管理することで、AIはより正確かつ再現性の高い開発を実行できる。

つまり、AI駆動開発の本質は「AIそのものの性能」ではなく、「AIが能力を発揮できる開発基盤とプロセスの成熟度」にある。

7. ウォーターフォール型開発との関係と構造的摩擦

AI駆動開発は、ウォーターフォール型開発の歴史的意義や有効性を否定するものではない。大規模システム開発や高い品質保証が求められる領域では、計画的な工程管理やレビュー体制は現在でも重要な役割を持つ。

一方で、工程ごとの明確な分業や、多数の中間成果物を前提としたプロセスでは、AIによる高速なフィードバックループとの間に構造的な摩擦が発生する。

7.1 プロセス・ツール面の摩擦

従来型の開発では、以下のような作業が存在する。

  • Excelベースの詳細設計書作成
  • 工程ごとの承認フロー
  • 手動テスト
  • 手動デプロイ
  • 個別環境ごとの設定作業

これらは品質管理上必要な場合もある一方で、AIによる高速な生成・修正サイクルとは速度差が発生する。例えば、AIが数分でコード修正案を生成できても、レビュー・承認・環境反映が数日必要であれば、開発全体の速度は人間側のプロセスによって制約される。

7.2 工程の統合と成果物の変化

従来のウォーターフォール開発では、要件定義 → 基本設計 → 詳細設計 → 製造 → 単体テスト のように工程を分離して管理する。

一方、AI駆動開発では、詳細設計・製造・単体テストといった工程の境界は徐々に曖昧となり、一つの反復的なフィードバックループへ統合される傾向がある。例えば、Spec定義 → AI実装 → テスト生成 → 検証 → 修正 → 再検証 というサイクルを高速に繰り返す。

その結果、従来の詳細設計書に記載されていた情報は、以下のような、より機械可読な成果物へ移行していく。

  • OpenAPI
  • Database Schema
  • Type Definition
  • Test Code
  • Architecture Decision Record（ADR）
  • ソースコード

7.3 商習慣・管理手法とのギャップ

従来のSI開発では、人月工数や工程単位での見積もり・管理が広く利用されてきた。しかし、AI駆動開発では、以下のような差が大きくなる。

  • AIによって高速化される作業
  • 人間による判断が必要な作業
  • 設計や品質保証など経験依存の作業

そのため、単純な作業量ではなく、「どのような価値を提供するか」「どのような品質を保証するか」「AIを含めた開発能力をどう管理するか」という観点への移行が求められる。

8. 結論

AI駆動開発は、単にAIコーディングツールやチャットAIを導入することでは実現できない。その本質は、機械可読な仕様（SSOT）、AIによる自律的な実装・検証・改善ループ、自動テスト、CI/CD、IaC、DevSecOps、Platform Engineeringといった、これまでソフトウェア業界が積み重ねてきた開発プラクティスの上に、AIという新たな自律化エンジンを組み込むことである。

また、AI駆動開発への移行は一足飛びに実現されるものではない。現実的には、以下の成熟プロセスを経て進化していく。

AI支援開発 → AI協調開発 → AI駆動開発

各工程へAIを導入する取り組みは、AI駆動開発を否定するものではなく、その実現へ向けた重要な第一歩である。一方で、最終的な到達点では、AIを既存プロセスへ適用するだけではなく、AIを前提として開発プロセスそのものを再設計することが重要となる。

今後、開発者の役割は「コードを書く人」から、「何を作るべきかを定義する」「適切な仕様・制約を設計する」「AIの生成物を評価する」「システム品質を保証する」 という、より上位の設計・判断・監査を担う役割へ変化していく。

AIの性能向上だけに期待するのではなく、AIが最大限の能力を発揮できるプロセス・基盤・組織を整備してこそ、真のAI駆動開発が実現する。

では、何から始めるべきか。

一足飛びにLevel 3（AI駆動開発）を目指す必要はない。むしろ重要なのは、自組織が現在どのレベルにあるかを正確に把握することである。

  • 自社の仕様書はAIが解釈可能な形式か、それとも自然言語やExcelに依存しているか
  • 自動テスト・CI/CDは、AIの生成速度に見合う速さでフィードバックを返せているか
  • レビューや承認プロセスは、AIによる修正サイクルのボトルネックになっていないか

こうした問いに答えることが、AI駆動開発へ至る成熟プロセスの出発点となる。AIツールの導入はゴールではなく、開発プロセスと組織を継続的に成熟させていくための、長い旅の最初の一歩に過ぎないと考える。

参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?