95％が失敗するAI開発 「YouTube」チームが選んだ“常識破りの解決策”：なぜAI開発は頓挫するのか

AI技術の発展で開発の迅速化が進む一方、ほとんどのAI製アプリケーションが検証段階で立ち消えてしまう現実がある。「YouTube」開発チームはいかにしてこの壁を越え、開発のスピードと安全性を両立させたのか。

[TechTargetジャパン]

　LLM（大規模言語モデル）や自律的にタスクを遂行するAIエージェントの進化によって、開発者は数時間でアプリケーションのプロトタイプを構築できるようになった。しかし、企業内でこのプロトタイプを本番環境へ移行させようとすると、高い壁に直面する。マサチューセッツ工科大学（MIT:Massachusetts Institute of Technology）は2025年1〜6月、52の組織を対象としたインタビュー、153人のシニアリーダーからのアンケート回答、300件以上の事例分析を実施した。その結果、AI技術を活用して開発したプロトタイプが本番環境で生き残る割合はわずか5％に過ぎず、残りの95％は検証段階で立ち消えになっていた。

　個人プロジェクトであれば、エラーが発生してもプロンプトを書き換えて再起動すれば済む。しかし、数十億人のサービス利用者を抱え、20年の歴史を持つ堅牢（けんろう）なソースコード群を備えた企業では事情が異なる。予測不可能な技術的負債やエラーの連鎖を引き起こすリスクがあるため、経営陣やセキュリティの観点からブロックされやすい。

　この「スピードとリスクのパラドックス」を打ち破ったのが、動画共有サービス「YouTube」の開発チームが構築した独自のプロトタイピング用システムだ。インフラの設計思想を根本から見直すことで、アイデアの検証にかかる期間を数四半期から数週間へと大幅に短縮した。

　開発チームはどのようなアプローチで、安全かつ迅速なプロトタイプの検証を実現したのか。その具体的なアーキテクチャと開発の核となる方針を解き明かす。

本番環境から完全分離された「プロトタイピングスタック」

併せて読みたいお薦め記事

AI開発はなぜ失敗するのか

• 7割失敗する「AIでレガシーシステム刷新」の幻想　あの企業も選んだ現実解とは
• 95％が失敗する？　AIプロジェクトの「検証沼」を引き起こす8つの隠れコスト

　開発チームが直面していたのは、プロトタイプを現実的な条件でテストできない「白紙状態」の問題だ。これを解決するため、ベンジー・ベア氏を中心とするチームは、メインラインの本番環境サーバから実験用のシステムを完全に切り離した開発環境ツール群「プロトタイピングスタック」を構築した。

　プロトタイピングスタックは、大きく2つの技術的アプローチで成り立っている。

　1つ目は「データレイヤーの分離」だ。開発者は、生成AI向け開発環境「Google AI Studio」のテンプレートを利用してアイデアを立ち上げる。この設定は、プロトタイプ向けに承認された読み取り専用データを扱うプロキシサーバに接続されている。これによって、開発者はコアのデータベースを汚染したりクラッシュさせたりすることなく、再生リストや動画情報などのメタデータへのアクセス権を即座に得ることができる。本番環境のパラメータを用いた現実的なテストが、安全なサンドボックスの中で可能になる仕組みだ。

　2つ目は「ライブUI（ユーザーインタフェース）インジェクション」と呼ばれる手法だ。プロトタイプを実際のUIで検証できるよう、プロトタイピングスタックがクライアントサイドの拡張機能ラッパーを提供する。この仕組みによって、開発中の試験運用版の機能をYouTubeの画面に挿入できる。試験運用版のソースコードは、必要時に必要な部分（チャンク）を読み込む「コード分割チャンク」の保護対策によって本番環境から隔離されているため、更新を安全なステージング環境に数分で反映できる。

　プロトタイピングスタックを活用した結果、「YouTubeハイライト」や「YouTubeに相談」といった機能は、数週間でユーザー調査に回されるようになり、開発の高速化が実現した。

「使い捨てコード」を前提とする開発アプローチ

　プロトタイピングスタックを支えているのは、「使い捨てのソースコードを積極的に取り入れる」という、従来とは異なるAIコーディングの基本方針だ。

　一般的なソフトウェア開発では、ソースコードは永続的な資産として扱われ、完璧になるまでリファクタリングを繰り返す。しかし、生成AIが記述した無秩序なソースコードを既存システムに無理やり組み込もうとすると、アーキテクチャ上の問題を引き起こしやすい。

　Webブラウザ「Google Chrome」の開発を率いたエンジニアのアディー・オスマニ氏は、個人プロジェクトにおいて最大10個のAIコーディングエージェントを並行稼働させた際、十分な確認を怠ったことで技術的負債が蓄積し、アプリケーションを破壊してしまった経験を持つ。個人の開発であれば失敗は学習の糧になるが、企業インフラにおいては致命的な問題になり得る。

　そこでYouTubeの開発チームは、プロトタイプ段階のソースコードには技術的負債が含まれていることを前提として、プロトタイプの役割を「定量データを用いた市場適合性の検証」に割り切った。本番環境を模したシステムで検証を実施し、アイデアの成功が証明された後に、本番環境向けのソースコードを一から書き直す方針を採っている。

　この手法は一見すると非効率に思えるが、成功が実証されていないプロトタイプを磨き上げるよりも、検証済みの設計図をベースに実装を再構築する方が、結果的に費用や手間を抑えて迅速に開発を進められる。

開発プロセスの「民主化」とエンジニアの新たな役割

　プロトタイピングスタックは開発プロセスの民主化という大きな副産物をもたらした。かつては高度な技術力を持つ一部のエンジニアしか新機能を考案、構築できなかったが、本番環境における実データを参照するAPIにアクセスできる実験用インフラが整備されたことで、状況は一変した。プロダクトマネジャーやUX（顧客体験）リサーチャーなど、プログラミングを専門としないメンバーであっても、AIツールを活用してアイデアを形にし、定量的なデータに基づいて検証プロセスに参加できるようになったのだ。

　AI技術によって、ソースコード生成にかかる費用や手間は劇的に低下した。これに伴い、エンジニアの役割は単なる構文の管理者から、安全に失敗できるシステムを構築する「システムアーキテクト」へと変化しつつある。

　95％の失敗はシステムのバグではなく、アイデアを検証するための戦略的な過程だ。最も避けるべきリスクは、AIツールが生成したプログラムでサーバをダウンさせることではなく、検証サイクルが遅いために技術革新の機会を逃すことだ。本番環境から分離された安全な実験用インフラを設計することが、これからのアプリケーション開発においては競争力を生み出す源泉となる。

本稿は、Googleが2026年7月22日に公開した動画「Why AI apps fail in production (and how Google solved it)」と、7月30日に公開したブログエントリ「AIアプリが本番環境で失敗する理由とGoogleがそれらを解決した方法」を基に作成しました。