AI駆動開発 2026年7月19日

AI駆動開発の成熟度を「加点式」で測ると、Gitなしチームが70点になる話

成熟度診断ツールを作るとき、大半の人は加点式を選ぶ。チェック項目に点数をつけて、重み付けして足し上げ、合計でレベルを判定する。直感的に公平だし、実装も簡単だ。

問題は、この方式が「AI駆動開発の適性」という文脈では深刻な誤診を生むことにある。

Zennに公開されたこの記事は、AI駆動開発の準備度評価における採点設計の話だ。筆者は自作のOSS診断ツール「ai-dev-readiness」を題材に、なぜ加点式だけでは不十分なのか、そしてボトルネック方式（キャップ設計）という代替をどう実装したかを整理している。ツールの紹介記事ではなく、評価設計の考え方についての論考だ。

「Gitなしで70点」という診断結果は正しいのか

記事に登場する架空の2チームが、問題をよく示している。

5つの評価領域（各20点満点、計100点）で採点したとする。

評価領域	チームA	チームB
ドキュメント整備	20	12
開発プロセス	20	12
品質保証	0（テストなし）	12
AI利用体制	20	12
プロジェクト特性	20	12
合計	80	60

加点式では、テストが一切存在しないチームAが「80点＝優良」、全領域がそこそこのチームBが「60点＝改善余地あり」と判定される。

しかし筆者はこう指摘する。「AIが生成した変更を検証する手段を持たないチームAは、AIの出力速度が上がるほどリスクが加速する」。Gitがない状態で大量のコード変更をAIエージェントに流し込んだら何が起きるか——差分の追跡も巻き戻しもできない「取り消せない上書き」が積み上がるだけだ。

これを筆者は「優等生問題」と呼んでいる。ひとつの領域が壊滅的に弱くても、他の領域の高得点がそれを覆い隠してしまう。

なぜ加点式は「補完できない欠落」を見逃すのか

加点式の暗黙の前提は、「各領域の点数は互いに独立で、足りない領域は他の領域の強さで補完できる」というものだ。

だがAI駆動開発の実態は違う。一部の領域は他の領域の前提条件になっており、欠けると他の領域の点数自体が意味を失う。

重みを調整しても本質は変わらない。品質保証の重みを2倍にしたところで、他が満点ならチームAは依然として高得点になる。「重要度の差」は重みで表現できるが、「前提条件であること」は重みでは表現できない——これが加点式の構造的な限界だ。

ここが記事の核心だと思う。多くの評価設計者が「大事な項目の重みを上げる」という方向で問題を解決しようとする。でも前提条件の欠落は、重みの問題ではなくカテゴリが違う問題なのだ。

AI駆動開発に固有の「前提条件」6つ

筆者がキャップ（上限）の発動条件として選んだのは以下の6つだ。

前提条件	欠けると何が起きるか
バージョン管理（Git）	AIの変更が「取り消せない上書き」になる
人間によるレビュー／本番承認	AIの活用度を上げるほど事故確率が上がる
仕様の形式知化（ドキュメント）	AIに渡せるコンテキストがそもそも存在しない
タスク管理（チケット）	AIへの委譲範囲を制御できない
変更の検証手段（自動テストor確認項目）	AIの生成速度がそのまま劣化速度になる
AIに入力禁止情報のルール	活用が進むほど漏えいリスクが累積する

筆者がここで示す整理が鋭い。これらは「AIを速くする要素」ではなく、「AIの速さを安全に受け止める要素」だという点だ。

加点式の世界観では「テストがない分、ドキュメントで補えばよい」という取引が成立してしまう。でも実際には、ドキュメントがどれだけ充実してもテスト不在のリスクは1ミリも減らない。補完が効かない項目は、加算ではなく制約として扱う必要がある。

ボトルネック方式の実装はMath.minだけ

設計思想の話が続いたが、実装は拍子抜けするほどシンプルだ。

素点と上限値の Math.min を取るだけ。筆者のツールでは以下の6種類のキャップを定義している。

キャップ発動条件	総合スコア上限
Gitを使っていない	49点
仕様書がほぼ残っていない	49点
チケット等でのタスク管理をしていない	59点
人間によるレビュー／本番承認がない	59点
自動テストも変更時の確認項目もない	59点
AIに入力禁止の情報のルールが未定義	69点

複数のキャップが同時に発動した場合は「最小の上限」を採用する。最も深刻なボトルネックに律速される、という考え方だ。

重要なのは、これが加重平均の代替ではなく併用だという点。通常の改善度は加点式で連続的に表現し、致命的欠落だけを上限で表現する二層構造になっている。Gitがない状態で他の項目をどれだけ改善しても49点の壁を超えられないが、Gitを導入した瞬間にその壁が消える——この断絶が前提条件の本質を正確に表現している。

実務的な示唆──「スコアが高い」は「安全に進められる」ではない

ここからは見方の話だが、この記事が示している問題は診断ツールの話にとどまらない。

AI導入の意思決定場面でも同じ構造が起きている。「うちはAI活用度が高い」という自己評価が、実は特定の強みだけを見ていて、前提条件の欠落を見逃している——というパターンは実務でよくある。「プロンプトエンジニアリングは得意だけどAIの出力を検証する仕組みがない」「AIツールを積極的に使っているが入力情報のルールが曖昧」といったケースだ。

加点式評価に慣れた組織ほど、この見逃しが起きやすい。総合スコアが高いと「よくできている」という感覚になり、致命的な欠落への感度が鈍くなるからだ。

判断軸として持っておきたいのは、「AIを速くする要素」と「AIの速さを受け止める要素」の区別だ。プロンプトの精度、モデルの選定、ワークフローの自動化——これらはAIを速くする。一方、バージョン管理、人間のレビュー、テスト、情報管理ルール——これらはAIの速さを安全に受け止める側だ。前者だけが充実して後者が欠けていると、活用を加速するほど事故リスクも加速する。

次に同種の「AI活用度診断」「AI成熟度評価」を見るとき、その評価が加点式だけで設計されているか、ボトルネック的な欠落を検出する仕組みがあるかを確認してほしい。スコアの絶対値より、「何が欠けているとスコアが下がる構造になっているか」の方が診断の質を測る指標になる。

次の論点

この記事が扱っていない問題もある。

ひとつは「キャップの閾値をどう決めるか」だ。筆者はGitなし→49点上限、AIルールなし→69点上限と設定しているが、この数値設定は実務経験と判断に基づくものであり、「確立された評価理論」ではないと自ら明示している。組織の種類（スタートアップ vs 大企業）や開発の性質（内製 vs 受託）によって、この閾値は変わりうる。

もうひとつは「経時変化の扱い」だ。成熟度評価は一時点のスナップショットだが、組織のAI活用は動的に変化する。Gitを導入した翌日にキャップが外れてスコアが跳ね上がるような構造は、改善のモチベーションには使えるが、連続的な進捗管理には向かない。

いずれも、評価設計というテーマがまだ成熟途上であることを示している。