COLUMN
コラム
2026年10月04日
Cursor・Claude Codeの導入率は84%。なのに"安心して本番に出せる"のはわずか3%という現実
衝撃のデータ ― 導入率84%、でも「安心して本番に出せる」のはわずか3%
Cursor、Claude Codeをはじめとするコーディングエージェントは、この1〜2年で一気に現場に浸透した。もはや「使うかどうか」ではなく「どう使うか」を議論する段階に入っている、というのが多くのエンジニアの実感だろう。
しかし、その"浸透"の裏側で、見過ごされがちな数字がある。Stack Overflowが実施した開発者調査によると、AIコーディングツールを利用している、または利用予定のエンジニアは84%に達した一方で、AIの出力を高いレベルで信頼すると答えたのはわずか3%にとどまっている（stackoverflow.blog）。むしろ「信頼していない」と答えたエンジニア(46%)が「信頼している」(33%)を上回っているというから、AI駆動開発は導入が進むほど、現場の"信頼"とは逆方向に進んでいるようにも見える。
この「導入率84%、高信頼度3%」というギャップこそが、AI駆動開発のPoC（個人やチームの試行）がうまくいっても、組織として安心して本番に出せる状態にたどり着けない、という多くの現場の悩みの正体だ。
なぜ"ほぼ合っている"コードが一番やっかいなのか
AI駆動開発の信頼性を語るうえで、興味深いのは「どこで信頼が崩れるか」だ。同じStack Overflowの調査では、AIコーディングツールに対する最大の不満として、66%のエンジニアが「ほぼ合っているが、微妙に違う（almost right, but not quite）」コードを挙げている。さらに45%は、AIが生成したコードのデバッグに、自分で書くより時間がかかると回答している（stackoverflow.blog）。
これは直感に反する結果かもしれない。「全く動かないコード」であれば、すぐに書き直せば済む。しかし「一見すると正しそうで、実際に動いてしまう」コードは、レビュアーが一行ずつ丁寧に検証しない限り、不具合を見抜けない。AI駆動開発が信頼性の壁にぶつかる本当の理由は、ここにある。
この問題は、業務システムのような"厳密さ"が求められる開発では一段と深刻になる。日経クロステックの記事では、生成AIによるコード生成はプロトタイプや個人利用には有効だが、長期的な保守性やセキュリティまで考慮したコードを安定して出力させるには限界があり、「まず脆弱性がどこに生まれるのかを把握していなければ、AIコーディングエージェントにタスクとして渡すこともできない」と指摘されている（xtech.nikkei.com）。
序盤から学びの重要性に触れておきたい。こうした"ほぼ合っている"コードを見抜く目や、AIへの指示の出し方を体系的に押さえておくことは、我流では身につきにくい。AI駆動開発セミナーのような場で、最初につまずきやすいポイントを押さえておくことが、遠回りを避ける近道になる。
動くコードと、本番に出せるコードの間にある溝
「動くコードが書けること」と「チームとして安心して使えること」の間には、もう一段の溝がある。
AI駆動開発の実践知を発信するFindy Team+のブログでは、優れたコーディングツールを導入しても、利用ルールやレビュー体制が整っていなければ個人の試行にとどまり、組織全体には広がらないと指摘されている。いわゆる"バイブコーディング"をそのままチーム開発に持ち込むと、品質のばらつき・レビュー負荷の増大・知見の属人化が起きやすいという（jp.findy-team.io）。
Claude Codeの提供元であるAnthropic自身も、この"信頼"の設計に正面から向き合っている。同社が公開した「信頼できるエージェント」の5原則は、人間による制御の維持、価値観への適合、セキュリティ、透明性、プライバシー保護を軸に、ユーザーが各アクションの許可レベルを設定できる仕組みや、実行前に計画を確認できる「Plan Mode」のような設計を重視している（anthropic.com）。裏を返せば、こうした「人間がどこで確認し、どこまで任せるか」という設計そのものを学ばない限り、AI駆動開発は個人の感覚（バイブ）に依存したままになりやすい。
AIと"協働"するという発想は、コーディングに限った話ではない。業務プロセス全体でAIエージェントと働くという考え方は、Captain.AIが掲げる「AIを"ご利用する"から"働かせる"時代へ」という思想にも通じている。コーディングであれ業務プロセスであれ、信頼の設計を学ぶという本質は変わらない。
「導入した」と「使われている」は別物という現実
組織規模でAI駆動開発を広げようとすると、別の壁にもぶつかる。「導入した」ことと「実際に使われ、成果につながっている」ことは、まったくの別物だという壁だ。
ある企業がClaude Max、続いてClaude TeamやCoworkを全社員に導入した事例を紹介したカンファレンス登壇資料では、トップダウンで導入したものの「誰が・どう使っているのかが見えない」という課題に直面したことが報告されている。数百人規模の組織では個別ヒアリングは現実的でなく、ログを集約して定量的に利用実態を観測する仕組みを整えて初めて、導入効果を経営判断に結びつけられるようになったという（docswell.com）。
GitHubが公式に公開しているOctoverseレポートでも、AIコーディングツールの利用は急速に拡大している一方、コーディングエージェントによるプルリクエストは、既に成熟した一部のプロジェクトに偏って活用されている傾向が報告されている（github.blog）。導入の広がりと、現場への本当の定着との間には、まだ距離があるということだ。
国内のDX動向を見ても傾向は一致する。独立行政法人情報処理推進機構（IPA）が2026年に公表した調査では、AI導入は広がっているものの、期待どおりの効果を実感している企業は限定的で、業務効率化にとどまり企業価値創出まで展開できているケースは少ないと報告されている（ipa.go.jp）。
トラストギャップを埋めるには ― どこで学ぶべきか
ここまで見てきたトラストギャップ――導入率84%と高信頼度3%の差――は、一人のエンジニアの努力だけで埋まるものではない。AIの出力をどう検証し、どこまで任せ、どう組織のルールに落とし込むかという「設計」を、体系的に学ぶ必要がある。
Hexabaseが提供するAI駆動開発セミナーは、「入門（2日）」「AI活用（1日）」「リスキリング（3ヶ月）」「アーキテクト養成（2〜3ヶ月）」という4つのコースで構成されており、つまずいている段階に応じて学ぶ内容を選べる。まず"ほぼ合っているコード"を見抜く基礎を押さえたいチームには入門コースが、チーム全体のレビュー体制やガバナンス設計まで踏み込みたいチームにはアーキテクト養成コースが適している。
研修コストが気になる場合は、厚生労働省の「人材開発支援助成金」の対象になりうる点も押さえておきたい。DX・デジタル関連のリスキリングを目的とした研修であれば、経費の一部が助成される制度が用意されている（mhlw.go.jp）。
「ツールをどう使うか」ではなく「組織としてどう信頼を設計するか」という観点で研修・AI駆動開発セミナーを比較検討することが、トラストギャップを埋める最初の一歩になる。
まとめ ― "動く"から"任せて安心"へ
AI駆動開発の導入率84%、高信頼度3%というデータは、裏を返せば「正しく検証・設計を学んだ現場は、このギャップを埋められる」ことを示してもいる。本番導入を阻むのはAIモデルの性能そのものではなく、"ほぼ合っている"出力をどう検証し、個人の感覚をどうチームの標準に変えるかという設計の学びの不足だ。
AIを"使う"フェーズはすでに多くの現場が通過している。これから問われるのは、AIの出力とどう向き合い、どこまで任せ、どう協働する設計を組織として学べるかだ。
自社のAI駆動開発がPoCや個人の試行で止まっていると感じるなら、まずはAI駆動開発セミナーで自社に合った学び方を確認してみてはどうだろうか。どのコースが合うか判断に迷う場合は、無料相談から現状を相談することもできる。