「AIを導入した」は出発点にすぎない——AI駆動開発が本当に要求するもの
CursorやGitHub Copilotを導入した。ChatGPTでコードレビューをさせている。「うちはもうAI開発をやっている」——そう言えてしまうのが、今の状況の厄介なところだ。
Qiitaに投稿されたエンジニア @Naoto7124 氏の記事が、この「ズレ」を丁寧に言語化している。要点を先に言うと、AI駆動開発の本質は「AIを導入すること」ではなく、「AIが自律的に開発を進められる環境を整備すること」にある。読めばあたり前に聞こえる。だが、それを実現するために何が必要かをリストアップし始めると、話は一気に重くなる。
「AIを使っている」と「AI駆動開発」は別の話
AI駆動開発（AIDD: AI-Driven Development）という言葉は、今やバズワードに近い。「AIエージェントを使った開発」くらいのニュアンスで使われることが多く、「コードを生成させた」「プルリクの要約をAIにやらせた」あたりで満足感が生まれやすい。
だが筆者が指摘するAIDDの本質は、もっと踏み込んだところにある。
「AIは『コードを書く補助者』ではなく、開発プロセスの一部を担うエージェントとして機能する」
具体的には、AIが次のような工程を反復的かつ自律的に回すフィードバックループ（Agentic Loop）を実現すること、と定義されている。
- 仕様をもとにしたドキュメント生成
- 実装コードの生成
- テストコード生成・実行
- 静的解析・セキュリティチェック
- 自律的なエラー修正（Self-Healing）
- Pull Request作成とレビュー結果の反映
ツールを「入れた」状態と、このループが「回っている」状態は、まったく別物だ。
成熟モデルで「自分たちの現在地」を確認する
記事では、AI活用の成熟段階を3つのレベルで整理している。
| レベル | スタイル | AIの役割 |
|---|---|---|
| Level 1: AI支援開発 | 人間主体、AIは補助ツール | コーディング支援・調査支援 |
| Level 2: AI協調開発 | 各工程で人とAIが協調 | 工程ごとの作業支援・品質向上 |
| Level 3: AI駆動開発 | AIを前提にプロセスを再設計 | 実装・検証・改善を自律的に実施 |
「現在、多くの企業が目指しているAI活用は、Level 2に位置付けられることが多い」と筆者は書いている。読んで納得感があった。CursorやCopilotを各工程に組み込んでいる状態は、確かにLevel 2だ。
ここからが重要なのだが、Level 2とLevel 3の間には、ツールの差ではなくプロセスの設計哲学の差がある。Level 2は「既存の開発プロセスにAIを適用する」。Level 3は「AIを前提として、開発プロセスそのものを再設計する」。この違いは小さく聞こえるが、実際の組織変革という意味では断絶に近い。
なお、このモデルは筆者が整理した概念モデルであり、業界標準ではない点も明記されている。類似のフレームワークとして、ELEKSの「AI-SDLC Maturity Model」（5段階）やCarnegie Mellon大学SEIとAccentureによる「AI Adoption Maturity Model（2026年）」などが存在するが、それらはガバナンスや組織戦略まで含んだより大規模なモデルだ。本記事のモデルは「現状把握とAIDD成立への道筋を分かりやすく示すための簡略版」として読むのが適切だろう。
AIが機能するための「地盤」が整っているか
ここが読んでいて一番刺さった部分だ。
自動テストが存在しない環境でAIを使うとどうなるか。筆者はこう説明する。
AIがコードを生成 → 人間が手動テスト → 修正箇所を判断 → AIが再生成 → 人間が再度手動テスト
AIの生成速度はどれだけ速くても、確認が人力に依存している以上、ボトルネックは消えない。AIを入れても開発全体のリードタイムは縮まらない。
同様の論理はCI/CDとDevSecOpsにも適用される。
- CI/CDがない場合：AIがコード修正案を数分で出せても、ビルド・テスト・デプロイが手作業なら、リリースまでのリードタイムはほぼ変わらない。
- DevSecOpsがない場合：AIが生成したコードに含まれる脆弱性を継続的に検証できなければ、AIは「品質保証の仕組み」ではなく「品質問題を高速に量産するエンジン」になりかねない。
「AIの本質は性能ではなく、AIが能力を発揮できる開発基盤とプロセスの成熟度にある」というのは、煽り文句ではなくエンジニアリングの話だ。
そしてもうひとつ重要な前提として、**機械可読な仕様（SSOT: Single Source of Truth）**がある。OpenAPI、データベーススキーマ、型定義、Terraform、Policy——これらが整備されていないと、AIへの入力が自然言語だけになり、解釈の揺れやコンテキスト不足が生じやすい。AIが再現性高く動くためには、「人間も厳密に解釈する仕様書」ではなく、「AIも厳密かつ一義的に解釈できる機械可読な仕様」が必要なのだ。
ウォーターフォールとAIDDの構造的摩擦
記事はウォーターフォール型開発を否定していない。「大規模システムや高い品質保証が求められる領域では、計画的な工程管理は現在でも重要」と明示している。ただし、構造的な摩擦があることは正直に指摘している。
従来型の工程管理では、要件定義 → 基本設計 → 詳細設計 → 製造 → 単体テスト、という分離した工程管理が行われる。Excelベースの詳細設計書、工程ごとの承認フロー、手動テストと手動デプロイ——これらは品質管理上必要な側面もあるが、AIの高速なフィードバックループとの間には「速度差」が生まれる。
AIが数分でコード修正案を出せても、レビュー・承認・環境反映に数日かかるなら、開発全体の速度は人間側のプロセスに律速される。
さらに、成果物の形そのものが変化するという指摘も重要だ。AI駆動開発では、詳細設計・製造・単体テストの境界が徐々に曖昧になり、一つの反復ループへ統合されていく傾向がある。従来の詳細設計書に書かれていた情報が、以下のような機械可読な成果物へ移行するイメージだ。
- OpenAPI定義
- データベーススキーマ
- 型定義
- テストコード
- Architecture Decision Record（ADR）
SIビジネスにおける人月工数・工程単位の見積もりとの相性が悪くなるのは、この構造上の変化が根っこにある。
実務への示唆：何を整えれば次のレベルに行けるか
ここからは、この記事を読んだあとの「自分ならどう考えるか」という話だ。
Level 2からLevel 3へ移行するために何が必要かを、記事は明確に列挙している。
- 機械可読な仕様（OpenAPI・スキーマ・型定義）の整備と標準化
- Infrastructure as Code（IaC）の導入
- 自動テストの整備
- CI/CDパイプラインの構築
- DevSecOpsの実装
- Platform Engineering（開発基盤のセルフサービス化）
- AIが利用可能なドキュメント・ナレッジの整備
これを見て「全部やる余裕はない」と思うのが正直なところだろう。ただ、優先順位のつけ方として考えると、「自動テストとCI/CD」が最初のボトルネックになるケースが多い。AIが生成したコードを人間が手動確認している限り、スピードの上限は人力に決まる。そこを自動化しないと、AIを入れるほど技術的負債と品質リスクが増えるという逆説に陥る。
開発者の役割変化についても、現実的に考えておきたい。記事では「コードを書く人」から「何を作るべきかを定義する」「仕様・制約を設計する」「AIの生成物を評価する」「システム品質を保証する」という役割へのシフトが語られる。
これは決して「エンジニアが不要になる」という話ではない。むしろ、コーディングの知識とシステム設計・品質保証の判断力を両方持つ人間の価値が上がる、という構造変化だ。AIが動く前提を設計できるかどうかが、エンジニアの差別化要因になっていく。
「ツールを入れたか」ではなく「ループが回っているか」を問う
AI駆動開発を評価するための判断軸を、ひとつ提示しておきたい。
「どんなAIツールを使っているか」ではなく、「AIが生成した成果物を自動的に検証・修正するループが存在しているか」を問うことだ。自動テストが走っているか、CI/CDが接続されているか、スペックが機械可読な形で管理されているか。これらが揃っているチームは、ツール名を問わずAIDDに近づいている。
逆に、最新のAIエージェントを導入していても、テストがなくCIもなく仕様書がExcelなら、それはLevel 1からLevel 2の間にいる。それ自体は悪ではないが、「AI駆動開発をやっている」と言うのは難しい。
次に同種の「AI開発手法」の話を見るとき、「そのAI、フィードバックループと接続されているのか」を確認する習慣が、この記事を読んだあとに残ると思う。
