AI駆動開発 2026年6月7日

AI駆動開発は「個人の腕前」じゃなく「チームの仕組み」で決まる——AIDD成熟度モデルLevel 0〜1を読んで考えたこと

「AIを使っている」と「AI駆動開発が機能している」は別物

Cursorを使い始めた、Claude Codeを試してみた——そこで止まっているチームは、正直なところ多い。ツールを入れた瞬間に「うちはAI開発をやっている」と言えてしまうから、現状認識がズレやすい。

zenn.devに掲載されたこの記事が整理しているAIDD（AI駆動開発）成熟度モデルは、その「ズレ」を言語化するのに役立つ。Level-nullからLevel-3まで段階が定義されているが、読んで最初に引っかかったのはLevel-nullとLevel-0の区別だった。

Level-nullは「ChatGPTに表示されたコードをそのままコピペしている」「AIにコードを書かせているが、開発環境やテストとは接続されていない」状態。これはわかりやすい。問題は、多くのチームが実はLevel-0にいることだ。

Level-0は「チーム内の各エンジニアが、それぞれのやり方でAIを使い始めている」状態。ある人はCursor、別の人はVS Code拡張、また別の人はClaude CodeやChatGPTを使う。自由でいいように見えるが、個人ごとにノウハウが閉じ、局所最適化が進み、成果物の品質にばらつきが生まれる。記事の著者はこの段階を「本当の意味でのAI駆動開発とは呼びにくい」と言い切っている。

なぜか。ソフトウェア開発はチームコラボレーションであり、AI活用もチームの開発プロセスに統合されて初めて大きな効果を発揮するからだ、と。これは正論だが、実際にこの状態を抜け出すには「誰かが泥をかぶる覚悟が必要」だとも書かれている。記事の著者（CEO）は「当社で一番泥をかぶったのはわたし」と書いていて、妙な説得力がある。

ハーネスエンジニアリングという概念が示すもの

この記事のキーワードが「ハーネスエンジニアリング」だ。Birgitta Bockeler氏による定義を参照しており、「AIコーディングエージェントが安全かつ効果的に開発できるように、ガイド・フィードバック・実行環境などの『囲い込み』を整備する考え方」とされている。

これをもう少し具体的に言うと、Guides（フィードフォワード）とSensors（フィードバック）の2軸で成り立っている。

Guidesは「AIに事前に与えるルールや前提情報」。CLAUDE.mdや開発ルール文書がその代表例だ。Sensorsは「AIが生成した成果物に対してフィードバックを返す仕組み」。テストコード、Lint、型定義、CI/CDの自動チェックがここに入る。

なぜこの概念が重要か。AIエージェントは強力だが、文脈なしでは暴走する。逆に言うと、文脈とフィードバックを整備すれば、エージェントの出力品質はコントロールできる。ハーネスエンジニアリングはその「コントロールの設計」を体系化しようとしている。

Level-1の9ステップ：順番に意味がある

Level-1は「個人のAI活用からチームとしてのAI活用へ移行する段階」であり、記事ではa〜iの9ステップに分解されている。この細かさが、記事のいちばんの実用的価値だと思う。

**1a（GuidesとツールのSTATIC整備）**から始まる。チーム共通のCLAUDE.mdの作成、devcontainerによる開発環境の統一、AIが開発DBやローカル環境を安全に参照できる状態にすること。「CLAUDE.mdを一度作って終わりにしない」「本当に大事なのは、その後にメンバーからCLAUDE.mdやルール改善のPRが上がる状態を作ること」という一文が刺さる。ドキュメントではなく、改善のループが目的だということだ。

1b（会議体とPDCAルーティン）。著者の会社では「AIDD推進会議」を月1回開いているが、初期は週1回が望ましいと書いている。議題は「AIレビューが指摘できなかった点」「テストで検知できなかった問題」「AIに読ませづらい設計ドキュメントの共有」「セキュリティ上の懸念」など。これはただの情報共有会ではなく、「ハーネスエンジニアリングを継続的に改善するためのPDCAルーティン」だと位置づけられている。

1c（設計ドキュメントのAI最適化）。ここが実務的に見て、多くのチームで最も後回しにされているポイントだ。「品質の低いコードが生成される原因が、コードではなく設計ドキュメント側にある」という指摘は、経験者には頷ける話だろう。具体的には、API設計書をOpenAPI/Swagger形式に、DB設計書をMarkdownやDDLベースに、UMLをMermaidで記述する、という変換だ。「人間が読みやすい設計書」から「人間とAIの両方が読みやすい設計ドキュメント」へと発想を転換することが求められる。

1d（Sensorsの強化）。AIが頻繁にテストを回すためには、テストの実行速度が遅すぎると詰まる。カバレッジが低ければAIのミスを検知できない。型が複雑すぎればAIが正しく扱えない。これらはAIDDを始める前から存在していた課題だが、AI駆動開発が進むと「従来のSensorsでは不十分」だと露わになる。著者はZodのように型とバリデーションを統合できるschemaの導入を例に挙げている。「この段階まで到達して初めて、チームにハーネスエンジニアリングが存在していると自信を持って言える」という表現が、目安として使いやすい。

1e〜1hでは、Guidesの再設計（CLAUDE.mdの分割、タスク特化エージェントの整備）、プロンプティングレビュー（PRに会話履歴を添付してレビュー対象にする）、ゼロトラスト前提のセキュリティ見直し（.envに機密情報を置かない、開発DBへのアクセス権限の最小化）、そしてコードベース自体のAI最適化リファクタリングが続く。

**1i（マルチエージェントとリソース制約）**が最後だ。「各エンジニアが複数のAIエージェントを同時に使いながら複数のタスクを開発するようになると、トークンが足りなくなり、開発PCのメモリが足りなくなる」。AI活用を本格的に進めると、インフラ投資の問題が避けられないことを示唆している。

ここからは見方だが——このモデルが示す構造的な意味

この成熟度モデルを読んで感じたのは、AI導入の主戦場が「ツール選定」から「組織能力の設計」に移りつつあるという現実の言語化だ。

Level-0からLevel-1に移行するには、技術的な整備よりも「誰かが泥をかぶる」という組織的な意思決定が先に必要になる。CLAUDE.mdを作るのは簡単だが、それをチームの改善ループに組み込む仕組みを作るのは、プロダクト開発と同じくらいの設計力が要る。

もうひとつ気になるのは、Level-1の後半で著者が触れている「AIによって実装速度が上がった結果、レビュー・テスト・リリース判断・プロダクトマネジメントが追いつかなくなる」という問題だ。これはAI導入の「次のボトルネック」として、すでに現実の問題として顕在化しつつある。速度が上がれば、必ずどこかが詰まる。Level-2以降のテーマが「アジャイルプロセスへのAI統合」とされているのは、そのボトルネックを解消するためだ。

ここで判断軸として渡しておきたいのは、「AI導入で何が速くなったか」より「何が新しいボトルネックになったか」を見る癖をつけることだ。実装が速くなったとき、詰まるのはレビューか、QAか、意思決定か。その答えが、次に整備すべきハーネスの場所を教えてくれる。

実務的な示唆：自分のチームのレベルを正直に診断する

このモデルの使い方として、まず自分のチームの現在地を正直に置いてみることを勧める。

「AIを使っている」と言えるチームでも、Sensorsがほぼ機能していない（テストが遅い、カバレッジが低い、型が緩い）状態のままAIエージェントに実装させているなら、実質はLevel-0に近い。GuidesとSensorsの両方が整って初めてLevel-1の中盤に達する、という基準は厳しいが妥当だ。

プロンプティングレビュー（1f）は、実装コストが低い割に効果が出やすい施策に見える。PRに会話履歴を添付してレビューするという運用は、すぐにでも試せる。プロンプトを「作業ログ」かつ「設計判断の痕跡」として扱う発想は、開発文化の変化として意味が大きい。

セキュリティ（1g）については、著者自身が「本来もっと早い段階で取り組むべき」と認めている。AIの利便性に意識が向きすぎてセキュリティが後回しになるのは、多くのチームで起きやすい問題だ。.envに機密情報を置かない、開発DBのアクセス権限を最小化する、といった対策はLevel-1の入口から意識しておくべきだろう。

Level-2以降（アジャイルプロセスへのAI統合、E2Eテストの自動化、マルチエージェント環境整備、最終的にはAIが自律してタスクを実施するLevel-3）は、続編記事で整理されるとのことで、現時点では予告にとどまる。ただ、Level-3の「完全スタンドアロンでのAIDD」まで見据えると、今のLevel-1の整備がどれだけ基盤になるかがわかる。土台が雑なまま自律エージェントを動かせば、何が起きるかは想像できる。