AI駆動開発 2026年7月2日

「コーディングはボトルネックじゃない」——Gartnerが突きつけるAI駆動開発の不都合な真実

𝕏 シェアする

AIを入れても生産性が上がらない本当の理由——Gartnerが語る「ゼロが1つでも成果はゼロ」の法則

AIコーディングツールを導入したのに、なぜか開発速度が上がらない。むしろコードレビューやテストに時間がかかるようになった——そんな現場の声が増えている。

2026年6月に開催された「ガートナーアプリケーション・イノベーション＆ビジネス・ソリューションサミット」で、GartnerのVPアナリスト、ヨアキム・ヘルシュマン氏は一刀両断にこう言い切った。

「コーディングはボトルネックだったためしがありません」

この一言に、今のAI駆動開発が抱える問題の本質がほぼ凝縮されている。

コーディングが速くなっても、開発は速くならない

多くの組織がまずAIを適用するのは「コーディング」だ。GitHub CopilotやCursor、各種コード生成AIが普及し、コードそのものを書くスピードは確かに上がっている。

しかしヘルシュマン氏が指摘するのは、コーディングはソフトウェア開発プロセス全体の「ほんの一部」に過ぎないという点だ。仮にコーディングで時間を節約できたとしても、テストやコードレビューに要する時間が10倍に膨らめば、開発全体のリードタイムはむしろ悪化する。

ここで同氏が引き合いに出すのが、エリヤフ・ゴールドラット氏の著書『ザ・ゴール』で有名な「制約理論（TOC）」だ。要するに、システム全体のスループットはボトルネックによって規定される。ボトルネック以外をいくら改善しても、全体は速くならない。

コーディングAIへの投資は、制約理論的に見れば「ボトルネックではない場所の最適化」に過ぎない可能性が高い。

本当のボトルネックはどこにあるのか

では、ボトルネックはどこか。ヘルシュマン氏は「たいていはテストや要件定義に根本原因があります。時には、不十分なドキュメンテーションがボトルネックになるケースもあります」と明言している。

これは現場感覚とも一致する。要件が曖昧なままAIにコードを生成させれば、作り直しが発生する。テストが手薄なままAI生成コードを積み上げれば、後工程での品質担保コストが跳ね上がる。ハルシネーションによる微妙なバグは、人間が書いたコードより発見しにくいケースすらある。

ただし、ここに希望がないわけでもない。ヘルシュマン氏が示すヒントは、複数のAIエージェントにタスクを分担させ、TDD（テスト駆動開発）やEDD（評価駆動型開発）と組み合わせてループを回すというアプローチだ。

興味深いのは、TDDが「何年も前から存在する開発手法でありながら、採用する組織は少数派だった」という指摘だ。エージェンティックAIという文脈でこれらの手法を再評価する時期に来ている、というわけだ。言い換えれば、AIは古くて正しい手法を採用する「ちょうどいい動機」になりうる。

「ゼロが1つでも成果はゼロ」——掛け算としてのAIプロジェクト

今回のGartnerイベントで特に印象的だったのが、AIプロジェクトを「掛け算」として捉えるフレームだ。人・AI・ワークフローなど複数の要素の積として成果が決まる構造において、ゼロが一つでもあれば全体がゼロになる。逆に、ゼロを排除していけば効果は倍々に大きくなる。

そして、その掛け算のなかで最も影響が大きいのが「人」の要素だという。

これはある意味では厳しい話だ。「AIを導入しました」で終わりにしたい組織には都合が悪い。ヘルシュマン氏はもっと直截的に言う。「ソフトウェアエンジニアリングの成熟度が低い組織がいくらAIを採用しても、優れた成果を出すことはできません」。

成熟度が低いとはどういうことか。レビュープロセスが形骸化している、テストが属人的で再現性がない、要件定義が口頭ベースで文書化されていない——そういった状態のことだ。AIはこれらの問題を解決しない。むしろ増幅させる。

ブラジルの大手銀行Itau UniBancoや、エンジニアリング業務にAIエージェントを展開したRevvityのような成功例は確かに存在するが、ヘルシュマン氏自身が「まだ少数派」と認めている。

AIが「ひび」を可視化した——これは脅威か、機会か

ここからは少し構造的な見方をしておきたい。

ヘルシュマン氏は「AI駆動開発によって生じたと言われているさまざまな問題は、以前から存在していたソフトウェア開発にまつわる"ひび"を白日の下にさらけ出しただけです」と述べている。ガバナンスやポリシーの欠如、テスト文化の未整備、ドキュメントの形骸化——これらは何年も前から存在し、「問題が提起されながらも目を背けられてきた」課題だ。

AIはそれを「残酷にも明るみに出している」のだという。

これを脅威と見るか機会と見るかは、組織によって違う。ただ一つ言えるのは、「ひびを見ないふりすること」のコストが、AIの普及によって急速に上がっているということだ。AIが入ってくることで、曖昧なまま回っていた開発プロセスが機能不全を起こしやすくなる。見えなかった問題が、見えるようになる。

セキュリティについても同様の構造がある。AIエージェントに大きな権限や認証情報を渡す場面が増えているが、開発環境が侵害された場合のリスクは現実のものになっている（実際にいくつかのインシデントが発生している）。ヘルシュマン氏の言葉を借りれば、「適切な方法を確立していない限り、AIに置き換えたからといってうまくいくものではない」。魔法のような対策はなく、ポリシーの整備と、どのエージェントにどの権限を渡すかの精査を地道に進めるしかない。

実務的な示唆——開発者・マネージャー・経営層それぞれへ

開発者へ

ヘルシュマン氏の言葉は率直だ。「この先も同じやり方を続けていくわけにはいきません。開発者はコードばかり書かなくてもよいというよりも、むしろ、コードばかり書いていてはならないのです」。

AIは何十倍、何百倍も速くタイピングでき、24時間働ける。人間が注力すべきは、「自分はこのコードを書いて何を開発し、どんな問題を解決したいのか」という問いを立て、AIに適切なコンテキストを与える役割へのシフトだ。これはスキルの話でもあるが、マインドの話でもある。

マネージャーへ

経営層が「AI活用で生産性50〜80%向上」という宣伝文句に乗っかり、現場が「現実的には十数%」と感じているギャップは、プレッシャーを生むだけで状況を改善しない。この期待値のズレを放置するのは、チームにとって有害だ。

加えて、「いろいろ試し、ある程度失敗を許容するカルチャーがなければ、安心して新たな技術にチャレンジする気になれない」というヘルシュマン氏の指摘は、マネジメント層への直接的なメッセージだ。技術を与えるだけで、誰もが使いこなせるようになるわけではない。

経営層・プロダクト責任者へ

「ガベージインガベージアウト」はAIにも当てはまる。インターネット上のコードを学習した汎用的なコーディングアシスタントは「そこそこのコードしかアウトプットできない」。自社・自組織のコンテキストを構造化し、検索可能な状態にしてモデルに反映させることが、競合との差異化につながる。これはデータ戦略の問題だ。