AI駆動開発の成熟度モデル｜コード補完から自律実装までの4段階

同じAIコーディングツールを導入していても、開発者が一行ずつ提案を採用するチームと、要件を渡して実装完了を待つチームでは、仕事の流れが異なります。 契約した製品や利用率だけでは、AI活用の現在地を判断できません。

差が表れるのは、生成AIへ任せる作業の範囲と、正しさを確かめる仕組みです。 補完から自律実装までを四段階に分けると、次へ進むために何が足りないかを確認できます。

AI活用の成熟度は、導入したツールではなく「任せる範囲」で決まる

ここでいう成熟度は、特定製品の機能数や、生成AIが書いたコードの割合ではありません。 一回の依頼でどこまで仕事を渡し、その途中で人間がどれだけ細かく介入し、完了を何で判定できるかを表します。

本稿の四段階は、業界標準ではなく、チームの運用を診断するための実務的なモデルです。 段階が高いほど常に優れているわけでもありません。 事故の影響が大きい変更や、正解を機械的に判定できない探索では、意図的にレベル2やレベル3へ人間の確認を戻す判断が必要です。

安全装置を整える順序は、この四段階とは別の軸です。 シークレット管理、破壊的操作の制御、テスト、権限をどう積み上げるかは、ハーネスエンジニアリングの8段階で整理しています。

段階が上がるほど、人間が確認する回数は減ります。 その代わり、仕様、テスト、実行環境、権限、停止条件を先に整える必要があります。 これは人間の責任が減る変化ではなく、責任を行使する位置が作業の途中から境界へ移る変化です。

AI駆動開発（AIDD）の解説では、生成AIを工程の主役に置いたときの全体像を整理しています。 この成熟度モデルは、その状態へ一度に移るのではなく、監督と検証の範囲を順に変えるための道筋です。

レベル1：コード補完でAIの生成能力を確かめる

レベル1では、コードを書く主導権を人間が持ちます。 開発者がエディタで入力している途中に生成AIが続きを提案し、一件ずつ読んで採用するか捨てるかを決めます。

この段階で確かめるのは、派手な機能を一度に作れるかではありません。 生成AIが既存コードの命名や型をどの程度読み取り、どの場面で自然な提案を返し、どの場面で誤った推測を混ぜるかをチームが把握します。 定型的な変換、テストデータ、既存パターンに沿った数行の追加は試しやすい対象です。

Cursorのように補完とエージェントの両方を持つ製品でも、最初は提案を細かく確認できる使い方から始められます。 機能や操作方法は更新されるため、導入時点のCursor公式ドキュメントを確認してください。 製品に依存しない補完型とエージェント型の違いは、AIコーディングエージェントの解説で整理しています。

提案の採用率だけを成果指標にすると、不要な提案まで受け入れる動機が生まれます。 この段階で見るべきなのは、採用したコードを開発者自身が説明できるか、既存のレビューとテストを省かずに使えるか、修正時間を含めて負担が減ったかです。

レベル1の出口は、生成AIの提案へ慣れることだけではありません。 提案を止める場面と、自分で書く場面を開発者が判断できる状態です。

レベル2：小さな機能を任せ、人間が動きを見ながら進める

レベル2では、依頼の単位が数行から一つのタスクへ広がります。 人間が「入力欄へ文字数制限を追加する」「既存APIのエラー表示を修正する」と依頼し、AIコーディングエージェントが関連ファイルの調査、計画、編集、コマンド実行を進めます。

ただし、人間はまだ継続的な監督を外しません。 エージェントが立てた計画を読み、変更差分を追い、想定外のファイルへ触れたら止め、テスト結果を確認します。 曖昧な指示を追加の会話で補いながら、一つの変更を共同で完成させる段階です。

対象には、影響範囲が狭く、失敗しても元へ戻せる変更を選びます。 初めから認証方式の変更や大規模なデータ移行を任せると、生成AIの能力ではなく、チームの監督方法と権限設計を同時に試すことになります。 何が原因で失敗したかを切り分けられません。

この段階では、一時的に人間の負担が増えることがあります。 自分で書く代わりに、生成AIの計画、差分、説明を逐次確認するためです。 それでも、小さなタスクを通じて誤りの型と必要な指示を把握しないまま、監督を外すわけにはいきません。

レベル2の出口は、生成AIが一度で正しいコードを書けることではありません。 一つのプルリクエストに収まる変更を任せ、人間が差分と挙動を説明でき、問題があれば安全に取り消せる状態です。

レベル3：自動テストを整え、AIの出力を挙動へ収束させる

レベル2までの速度は、人間が画面と差分を確認できる量で頭打ちになります。 生成AIが実装を数分で終えても、そのたびに人間が操作して正しさを確かめるなら、検証の待ち時間は縮まらないからです。

レベル3では、期待する挙動を自動テストや静的な検査で表します。 AIコーディングエージェントは変更後に検査を実行し、失敗結果を読み、修正して再実行できます。 人間が毎回「ここが違う」と会話で返していたループの一部を、機械が返す結果へ置き換える段階です。

ここでいう収束は、生成AIが正解を自力で発見するという意味ではありません。 あらかじめ与えた検査に合格するまで、実装と修正を繰り返せるという意味です。 テストに書かれていない業務ルールや、誤って定義した期待結果まで正しくなるわけではありません。

したがって、実装コードとテストコードを同じ曖昧な指示から同時に作らせるだけでは不十分です。 生成AIが一つの解釈で実装とテストをそろえると、要求を取り違えたままテストに合格することがあります。 人間が受け入れ条件と代表的な例外を先に決め、既存の回帰テストと組み合わせて、検査の基準を実装から独立させます。

必要な検査は、単体テストだけとは限りません。 変更の性質に応じて、結合テスト、E2Eテスト、型検査、Lint、セキュリティ検査を組み合わせます。 再現できるテストデータと実行環境もなければ、失敗結果が毎回変わり、エージェントは修正の方向を定められません。

レベル3になると、人間の役割は差分を一行ずつ直すことから、検証可能な条件を設計し、合格した証拠を評価することへ移ります。 テスト基盤がAI駆動開発の速度を決める理由は、AI駆動開発におけるテスト基盤の解説で詳しく扱っています。

レベル4：要件と受け入れ条件を渡し、完了までループさせる

レベル4では、人間が途中の各操作を指示せず、タスクの境界で生成AIを監督します。 要件と受け入れ条件を渡すと、AIコーディングエージェントがコードベースを調査し、計画を作り、実装し、検査に失敗すれば修正し、完了の証拠をまとめます。

「要件だけ渡せばよい」と解釈すると、この段階は成立しません。 自然言語の要求には複数の実現方法があり、完了の判定基準がなければ、エージェントはもっともらしい位置で作業を止めるからです。 少なくとも、次の情報を開始時に渡します。

• 目的と対象範囲：誰のどの問題を解き、どこを変更対象外とするかを示します。
• 受け入れ条件：入力、出力、例外、性能など、完了を観察できる条件にします。
• 制約：利用する既存機能、守る互換性、変更してはいけない公開仕様を示します。
• 検証方法：実行するテスト、静的解析、確認する画面やログを指定します。
• 権限と停止条件：触れてよい環境、承認が必要な操作、試行回数や費用の上限を決めます。

完了までのループにも終端が必要です。 同じ失敗が続く、判断材料が足りない、許可されていない操作が必要になる、といった条件では、人間へ状況を返して止まらなければなりません。 無制限に再試行する仕組みは、自律性ではなく、費用と変更範囲を制御できない仕組みです。

人間は最終承認まで手放しません。 データ削除、権限変更、本番への反映、外部契約に影響する変更などには個別の承認点を残し、エージェントの完了報告には変更差分、検査結果、未解決のリスクを含めます。 レベル4は実装の自律化であり、事業判断と説明責任の自動移譲ではありません。

要件、計画、タスク、実装を文書でつなぐ方法は、SDD（仕様駆動開発）の解説で確認できます。 仕様を生成AIへの入力として残すと、開始時の意図と完了時の成果を同じ基準で比較できます。

自動テストという分水嶺を飛び越えてはいけない

レベル2からレベル3への移行は、任せる量が少し増えるだけの変化ではありません。 正しさを返す主体が、人間の目視から実行可能な検査へ変わります。

自動テストがないままレベル4へ進むと、生成AIは自分の変更が正しいかを確かめられません。 人間が最後に巨大な差分を確認するか、動作を十分に確認しないまま取り込むかのどちらかになります。 前者では速度が失われ、後者では誤りが蓄積します。

一方、テストの本数だけを増やしても分水嶺は越えられません。 重要な業務ルールが検査され、失敗が再現可能で、結果から修正箇所を絞れる必要があります。 権限、決済、個人情報など事故の影響が大きい領域では、正常系のテストとは別に、認可と異常系の確認も必要です。

既存システムにテストが少ない場合は、主要な利用経路と変更予定の箇所から現状の挙動を固定します。 すべてを整備してから始めるのではなく、任せる範囲と検査できる範囲を一致させて少しずつ広げます。

次のレベルへ進むかは、速度ではなく検証可能性で判断する

生成AIが一度うまく機能を作れたことは、次のレベルへ進む根拠になりません。 偶然の成功と、同じ条件で再現できる運用を区別する必要があります。

任せる範囲を広げる前に、次の条件を確認します。

• タスクの対象と対象外を短く説明できるか。
• 完了条件をテストや観察可能な結果で表せるか。
• 代表的な正常系、異常系、回帰箇所を検査できるか。
• 生成AIが人間と同じ検査を実行できるか。
• 失敗結果から修正の方向を判断できるか。
• 変更を元へ戻せるか。
• 権限の上限と、人間へ戻す停止条件があるか。
• 担当者が最終成果物の挙動と判断理由を説明できるか。

一つでも欠ける場合は、生成AIの性能より先に、仕様、テスト、環境、権限の不足を直します。 モデルを変更すると一時的に成功率が上がることはありますが、完了を判定できない問題は残ります。

導入効果も、生成コードの行数やAI機能の利用率では測れません。 変更が完了するまでの時間、レビュー待ち、手戻り、本番での不具合を対で見ます。 測定方法は、AI時代の開発生産性の解説で整理しています。

四段階の到達点は、人間が開発から消えることではありません。 コード補完では一件ごとの採否を判断し、自律実装では目的、制約、停止条件、最終結果を判断します。 生成AIへ任せる範囲は、チームが証拠をもって確認できる範囲まで広げるのが安全です。