こんにちは、大平です。
最近、「AI を開発に本格導入したのにリリースは早くならない」「むしろ不具合が頻発している」という相談をいただくことが増えてきました。世の中には「AI で生産性が 350% 向上」のような景気のいい数字も並んでいますが、現場の手触りはそれほど一様ではありません。
結論から書きます。AI 駆動開発で生産性が出るかどうかは、ツールの選定でもエンジニアのスキルでもなく、自動テストが回せているかどうかです。そして「動けばいい」で人手フォローを重ねてきた組織ほど、AI 駆動開発の導入から半年〜1 年でスタックします。今回はその構造と、CXO・VPoE が今打つべき手を整理します。
AI を入れたのに、なぜリリースは早くならないのか
「ベンダーから提案された AI ツールを導入した」「現場のエンジニアにも Claude Code や Cursor を配った」。それでも、リリース速度が想定どおりに伸びない。むしろレビュー待ちと不具合修正が増えた——。こうした相談が増えています。
導入したツールの問題ではありません。導入「以前」の組織の足腰、もっと言えば自動テストがどれくらい整備されているかで、AI 駆動開発の伸び方は決定的に変わります。これは僕自身が現場で AI 駆動開発を回してきた中で、最も再現性の高い経験則です。
答えは「テストを書いていないから」
なぜテスト整備度合いがそこまで効くのか。仕組みはシンプルです。
AI が書いたコードは、誰かが「実際に動くか」を検証しないと、ただの「もっともらしい文字列」のまま終わります。自動テストが整備されていない現場では、その検証を人間の打鍵テストに頼ることになる。AI が書いたコードを AI 自身が検証する仕組みがないので、LLM が出力した「こうなんじゃないかな」というコードを 1 回打って終わり、というワークフローになります。当然、大抵の場合は動きません。
逆に、単体テストが書けていれば、AI に「コードを書いた後にテストを実行して、失敗したら直して」と指示するだけで、検証ループが閉じます。AI が自分で間違いに気づいて、自分で直します。AI 駆動開発において、自動テストは一丁目一番地、生命線です。これは比喩ではなく、検証ループが閉じている組織と閉じていない組織では、AI 駆動開発の生産性は数倍〜場合によっては桁違いに変わります。
これは「コードを一切読まなくてよくなる」話でも、「常に人が指示し続けないと使い物にならない」話でもありません。検証ループを仕組み化して、人と AI の役割分担を設計できるかどうかが肝です。
「動けばいい」で通ってきた時代が終わる
僕はエンジニアを 10 年以上やってきて、スタートアップから大企業まで色々な現場を見てきましたが、はっきり言って、テストが必要十分に書けている現場はほとんどありませんでした。テストを書かない理由はいくらでもあります。
- リリースが間に合わない
- テストを書いても顧客の価値にならない
- スタートアップだからスピード優先
これらの言い訳で「なあなあ」で通ってきた時代があったのは事実です。AI 駆動開発が出てくる前は、人手のフォローで吸収できる速度だったので、それでも回っていた。
しかし、AI が開発する時代には、この「動けばいい」運用は早期に明確なボトルネックになり、開発が短期で止まります。なぜか。理由は次の章で書きます。
AI が壊す「人手で吸収する」品質保証
AI はコードを書くのが圧倒的に早い。コード生産自体を 2〜3 倍、ハマれば 5 倍、10 倍にするのは難しくありません。つまり、コードベースの肥大化速度も同じ倍率で跳ね上がるということです。
ここで、テストが整備されていない現場を考えてみてください。仕様変更・仕様追加が今までの数倍の速度で積み上がっていく状態で、品質担保を人の打鍵テストで全部やる——絶対に無理です。回帰バグの検知が間に合わなくなり、触れないコード領域が短期で増え、最終的にデプロイが怖くて新機能が止まります。
「だったら AI を使わなければいいのでは」という声もあります。原始時代に戻る、という選択です。しかしこれも成立しません。AI を使いこなせている競合に、シェアを奪われて終わるからです。今の時代、AI を使わないという選択肢は経営判断として取りえない。だから、使いこなせるようにしないといけない。退路はありません。
テストコードも AI が書く時代の意思決定
ここまで読んで「やっぱりテストを書く時間がない」と感じた方に、もう一つ伝えたいことがあります。テストコード自体を AI に書かせるのは、本体コードを書かせるよりはるかに簡単です。
理由は二つあります。
一つは、テストコードはプログラムコードとして冗長な書き方が多いから。テストコード自体に複雑なロジックを組むとメンテナンス性が下がるので、愚直に、多少重複してでも書き下す方が得策です。この「愚直に書き下す」作業は AI が一番得意とするタイプの仕事です。人間がやるべきことは、自然言語でテストケースを考えて、それを指示として渡すだけ。
もう一つは、テストフレームワークの方言（BDD、各言語ごとの単体テストランナー、E2E ツール等）も AI がよく学習しているから。「このフレームワークでこういうケースを書きたい」と聞けば、かなり高い精度で書き方を返してくれます。テストツールの学習コストを言い訳にできない時代になりました。
つまり**「時間がない」「スタートアップだから」「テストの書き方が分からない」という、テストを書かない理由として今まで通用していた言い訳は、AI 駆動開発の時代にはほぼ全て消えた**ということです。残るのは、書くか書かないかの経営判断だけです。
ハーネスエンジニアリングは経営判断である
ここで誤解されやすいポイントを一つ。「AI ツールを次から次へと導入すれば、テスト基盤整備も自動でついてくるのではないか」——これは違います。
開発から検証までのサイクルにボトルネックを作らず、AI だけで回せる状態にするためには、プロダクトのテスト基盤を整備する必要があります。巷ではこの領域を「ハーネスエンジニアリング」と呼んだりします。テスト戦略、CI/CD パイプライン、E2E 基盤、データセットアップ、フィクスチャ管理——こうした足回りは、AI ツールを買ってきて入れるだけでは絶対に整いません。ここは人間が向き合って設計しないといけない領域です。
経営層がここで判断ミスをすると、コードを書くスピードに対して品質保証が追いつかなくなり、既存開発がストップします。そして、この構造に先に気づいて手を打った競合のプロダクトに、市場シェアを奪われていく。プログラマティックに解決できる領域はプログラマティックに解決しきる、という意思決定を経営側から下ろさないと、現場は「目先のリリース」に追われて基盤整備が後回しになります。
ハーネスエンジニアリングは、エンジニアリング部門の細部の話ではなく、経営判断です。いきなり全領域を整備する必要はありません。まず 1〜2 か月で主要導線の自動テストと CI を整え、そのうえで半年単位の基盤投資に広げていく。この順序で意思決定できるかどうかで、AI 時代の競争力が分岐します。
まとめ：あなたの組織は「動けばいい」側か
要点を整理します。
- AI 駆動開発の生産性は、自動テストが回せているかで決まる：ツールでもスキルでもなく、検証ループが閉じているかどうかが分岐点
- 「動けばいい」運用は人手フォロー前提で成立していた：AI による生産速度の跳ね上がりが、この吸収機構を破壊する
- テストを書かない言い訳は、AI 時代に消えた：テストコード自体を AI が書ける今、残るのは経営判断だけ
- ハーネスエンジニアリングは経営判断である：ツール導入では解決しない領域に、半年単位で投資する腹を決められるか
僕は、来たるべき時代が来たと思っています。これまで「動けばいい」で何とかなってきた組織にとっては逆風ですが、テスト基盤に向き合ってきた組織にとっては、自社の足腰がそのまま競争優位として機能する時代です。
CXO・VPoE の方に問いたいのは、たった一つです。あなたの組織は今、「動けばいい」側ですか、それとも「テスト基盤が回っている」側ですか。半年後、その答えが事業の伸び方を決めます。