AIを入れても開発が速くならない現場、3つの共通点

こんにちは、大平です。

「AIコーディングツールを導入したのに、開発が速くならない」という相談を受けることが増えました。Stripe が5,000万行のコードベースを1日で移行したというニュースが流れる一方で、自社では既存仕様とバッティングしたバグだらけのコードが増えただけ——このギャップは、ツールの性能差から来るものではありません。AIは増幅器であって、増幅するのは現場の規律です。この記事では、AIがワークしない現場に共通する3つの特徴と、どこから手をつけるべきかを書きます。

成功事例と自社のギャップは、どこから来るのか

AI開発の成功事例は毎月のように出てきます。Anthropic の発表によれば、Stripe は5,000万行の Ruby コードベースの移行を1日で完了させました。チームで2ヶ月以上かかる見積もりの作業です。Airbnb は約3,500のテストファイルの移行を6週間で終えています。手作業なら1.5年の見積もりでした。Amazon は Java のバージョンアップで4,500人年分の作業を削減したと公表しています。

一方で、僕が現場で聞く話はこうです。「AIを入れたのに開発が速くならない」「既存の仕様とバッティングしてバグだらけになり、結局使い物にならなかった」。同じ技術を使っているのに、なぜここまで結果が分かれるのか。

AIは増幅器である——差はモデルではなく、現場につく

結論から言うと、AIはどこまでいっても増幅器です。開発に関する規律がある現場はきちんと速くなり、ない現場はハルシネーションだらけの間違ったコードが量産されて、散らかるのが速くなるだけです。

これは僕の現場での実感であると同時に、データでも裏付けられています。Google の DORA 2025 レポートは、約5,000人のエンジニア調査から「AIは増幅器（アンプリファイア）であり、強い組織は強みが、機能不全を抱えた組織はその機能不全が増幅される」と結論づけました。

では、何が増幅の向きを決めるのか。ワークしない現場には、次の3つの共通点があります。

共通点1：AIに食わせる情報がない

プロダクトのあるべき姿や仕様が、AIが参照できる形で言語化されていない現場です。テキストファイルに落としてある必要はありません。今は Notion にもGoogle スプレッドシートにも MCP 経由で接続できます。問題は、そこにすら書かれておらず、仕様が創業者の頭の中にしかない「○○さんに聞いてください」状態が維持されていることです。○○さんに聞くというアクションは、AIには実行できません。判断材料を渡せない以上、ワークしようがないのです。

もう一段具体的に言うと、「良い設計・良いコード」に関するコンセンサスがチーム内にない場合も同じです。AIの出力は現状レビューが必要ですが、良し悪しの判断基準がなければ誰もジャッジできません。この状態でAIに任せてプロダクトのコードを直していくのは、かなりリスクの高い賭けになります。

共通点2：AIが動ける足場がない

二つ目は、AIエージェントが実際に手を動かすための環境の問題です。

まず、Git を導入していない現場。僕の感覚では「令和にまだあるのか」というレベルですが、実際にあります。昨今の開発ツールは Git を大前提にしているので、ファイル管理や SVN のままでは、AIが間違えたときに作業前の状態へ戻すことも、worktree を使った並列作業もできません。並列で動かせないと、高性能モデルの実行中にエンジニアがただ待つだけになります。

次に、開発環境の構築手順が煩雑な現場。環境構築に3日かかるようなプロジェクトは、環境を量産できないので並列開発ができません。AIは試行錯誤しながら進むため、壊したデータをすぐ再現できない環境では手が止まります。

そして CI/CD の未整備。小さくリリースできない現場では、デプロイの複雑なフローがボトルネックになり、AIが生み出した速度が本番に届く前に死にます。

モデルが1年前で止まっている会社——技術ではなく、調達の問題

足場の問題の中でも、決裁者のみなさんに直接関わるものを一つ取り上げます。社内で使えるAIモデルが、最新を追従できる仕組みになっていないことです。

特に大企業で聞くのが、「古いモデルでしか稟議が通っておらず、いまだに Claude 3 Sonnet しか使えない」「Microsoft Copilot の古いモデルだけ」というケースです。Claude 3 Sonnet は 2025年7月に提供終了したモデルです。つまりこの会社は、1年前に引退したモデルを使って「AIは使えるかどうか」を評価していることになります。

AIモデルは半年で別物になります。冒頭の Stripe の事例を動かした Claude Fable 5 も、2026年7月に出たばかりの GPT-5.6 も完成形ではなく、これからも更新され続けます。バージョンを指定して稟議を通す体制は、この速度に構造的に追従できません。「モデル個別に稟議」ではなく、「プロバイダ単位・予算単位で承認し、モデル更新は現場判断」に変える必要があります。これは技術の問題ではなく調達プロセスの設計、つまり経営マターです。

共通点3：AIの出力を検証する仕組みがない

三つ目が、出てきたコードの正しさを機械的に確かめる手段がないことです。

まず自動テスト。これがないと、いくら最新モデルを使ってもハルシネーションは止まりません。AIの出力は「確率的にありそうなもの」であって、正しさはテストが担保するからです。AIを開発に組み込む上で最初にやるべきことは、自動テストを書くこと、もしくは書ける環境を作ることです。幸い、テストを書く環境さえ整えれば、テスト自体をAIに書かせることができるので、整備コストはかつてより大きく下がっています。

次に検証サイクル。その機能がユーザーの課題を本当に解決したのかを、指標で確かめて回す仕組みです。これがないと「よくわからないシステムの量産」が始まります。ユーザーに刺さっていないので大して儲からないのに、システムだけが膨張してエンジニアの認知負荷と保守コストが増えていく——AI導入で最も避けたい失敗パターンです。

最後にレビューサイクル。誰が責任を持って本番に出すのか、レビュアーはどの観点を見るのか。AIによってコードの絶対量が増えた今、人間だけが書いていた時代と同じレビューをまともにやったら負けます。検証すべきポイントを絞り、品質への責任の持ち方を決め直す必要があります。

共通の根っこ：レガシーな現場への「ポン入れ」は効かない

3つの共通点の根っこは一つです。前提条件が満たされていないレガシーな現場に、AIを外から持ってきて「ポン入れ」してもワークしない。逆に、モダンな開発現場はこれらをAI以前から当たり前にやってきているので、同じツールを入れるだけでかなりワークします。

試金石として、こう問うてみてください。「優秀な新人が明日入社したら、1週間で戦力になれる現場か？」。なれないなら、その理由——仕様が誰かの頭の中にある、環境構築に3日かかる、正解を確かめる手段がない——は、AIがワークしない理由とまったく同じです。

今までは人力のコミュニケーションと属人的な運用で、牧歌的になんとかなってきたかもしれません。しかしAIによって、現場間の生産性の差は開く一方です。組織文化から変えて、プロダクトを安定させる基盤づくりに向き合わないかぎり、その差は縮まりません。

全部を一度にやる必要はない

ここまで耳の痛い話をしてきましたが、すべてを一度に整備する必要はありません。必要なのはロードマップです。

着手の順序としては、まず自動テスト、すなわちAIの出力を検証できる環境からが定石です。最初のうちはAIに触らせる範囲を区切り、ヒューマンインザループで人間が伴走しながら、できる範囲から足場を整えていく。インクリメンタルな改善でも、増幅の向きは確実に変わります。

まとめ

AIは増幅器である：規律のある現場は速くなり、ない現場は散らかるのが速くなるだけ
ワークしない現場の共通点は3つ：食わせる情報がない、動ける足場がない、出力を検証する仕組みがない
モデルの調達は経営マター：プロバイダ単位・予算単位の承認に変えないと、引退したモデルでAIを評価し続けることになる

AI導入投資の正体は、開発基盤整備への投資です。テスト、ドキュメント、CI——昔からの宿題だったものが、AIの登場で一気に利回りの高い投資に変わりました。やるなら、今が一番割に合います。