AIに350億ドルを注ぎ込んで、得られたものはほぼゼロだった
電話がかかってきたのは火曜の夜だった。私たちが助言してきた中堅のヘルスケア企業が、旗艦AIプロジェクトを打ち切ったばかりだという。9か月の作業。6桁ドルの支出。CTOの声は怒りではなく、疲れ切っていた。「デモでは完璧に動いたんです」と彼は言った。「毎回、必ず。それを実際の患者データにつないだ途端、保険コードをハルシネーションし始めた」
私は何と言えばいいのか分からなかった。その四半期だけでも、この話の別バージョンを何度も聞いていたからだ。会議室では目を奪い、本番環境では崩れ落ちるAI。初月には熱狂を生み、6か月目には予算見直しを生むパイロット。生成AIが約束するものと、実際に提供するものとの、現実の企業のなかでのギャップこそが、いまのテクノロジーにおける決定的な緊張関係だ。
そしていま、それを証明する数字がある。MITのNANDAイニシアチブが2025年半ばに発表した調査は、手榴弾のように着弾した。企業が生成AIに注ぎ込んだと推定される300億〜400億ドルのうち、およそ95%のパイロットが損益計算書に測定可能なインパクトをもたらせていない。マッキンゼー自身の2025年の調査もそれを裏づけている——88%の組織がどこかでAIを使っていると答える一方、EBITへの影響を少しでも示せるのはわずか39%にすぎない。
私はVeriprajnaを経営しており、企業向けにディープなAIシステムを構築している。ここで私は中立な観察者ではない。しかし、その残骸にも——そして稀な成功例にも——十分近い距離で接してきたので、実際に何が間違っているのかについては明確な像を持っている。そしてそれは、多くの人が思っているものとは違う。
デモは素晴らしかった。そこへ現実がやってきた。
あのヘルスケア企業のCTOの経験は、珍しいものではなかった。むしろほぼ中央値の結果だった。
MITのデータは残酷なファネルを描き出す。80%の組織が生成AIツールを探索する。パイロットまで到達するのは20%だけ。そして測定可能なビジネス成果を伴って本番稼働に至るのは、わずか5%にすぎない。研究者たちはこれを「学習ギャップ」と呼ぶが、これは要するに、ほとんどの企業が自分たちが何を買ったのかを理解していない、という婉曲な言い方だ。
MITのレポート全文を読んだあと、オフィスで共同創業者と、95%という数字は劇的すぎるのではないかと議論したのを覚えている。そんなことはなかった。むしろ問題を過小評価していたほどだ。というのも、「成功した」5%の多くは成功の定義を下方修正しており、実際の収益インパクトではなく、利用率やユーザー満足度を測っていたからだ。
私が繰り返し目にするパターンはこうだ。チームが主要なLLMを使ってPoCを作る。サンプルの10クエリを見事に処理する。経営陣が沸き立つ。予算が承認される。そしてシステムが現実世界に出会う——雑然としたデータ、エッジケース、曖昧な入力、「だいたい合っている」が訴訟を意味する規制要件——そして崩壊する。
デモ対応のAIと本番対応のAIの間にあるのはギャップではない。峡谷だ。そしてほとんどの企業は、すでに飛んでしまうまで、自分が間違った側に立っていることに気づかない。
MITの調査では、60%のユーザーがモデルは時間をかけてフィードバックから学習できないと報告した。55%は、プロンプトのたびにコンテキストを与えるのに過大な労力を費やしていると答えた。40%は、非標準の入力に当たるとモデルが単に「壊れた」と述べた。これらは風変わりな障害モードではない。これは、ごくありふれた火曜日の出来事だ。
なぜ企業は流砂の上に建てているのか？
いま企業市場が「AI製品」と呼んでいるもののほとんどは、ラッパーだ——GPT-4やClaude、GeminiへのAPIコールの上に載った薄いユーザーインターフェースにすぎない。何かを入力すると、それがモデルに送られ、モデルが応答し、ラッパーがそれをきれいに整形する。
ある売り込みの場を、生々しく覚えている。見込み客が「AI駆動のコンプライアンス・エンジン」を見せてくれた。私は、プロバイダーのアップデートで基盤モデルの挙動が変わったらどうなるのかと尋ねた。部屋が静まり返った。彼らは考えたことがなかったのだ。彼らの製品はまるごと、プロンプトのテンプレートときれいなダッシュボードだった。彼らが売っていた「知能」は、すべて借り物だった。
これがラッパーの誤謬であり、いたるところに存在する。このアプローチは、業界で「メガプロンプト」と呼ばれるものに依存するのが典型だ——ルール、データ、コンテキスト、指示を一つの巨大なやり取りに詰め込み、モデルがうまく整理してくれることを願う。このアーキテクチャ上の問題については、当社リサーチのインタラクティブ版でより深く論じたが、要点はこうだ——メガプロンプトは3つの致命的な問題を生む。
監査できない。モデルが正しい順序で指示に従ったことを検証する方法が存在しない。コンプライアンス負荷の重い業界では、これは論外だ。
経済的に脆い。長いコンテキストウィンドウとリトライはトークンを食い尽くす。そして、初めて見たとき衝撃を受けた数字がある——効率的なトークナイザーと非効率なトークナイザーの違いは、450%のコスト差を同じワークロードで生みうる。1日10万件の顧客問い合わせを処理する企業は、多言語ユースケースで誤ったモデルを選ぶだけで、年間コストが36,500ドルから164,000ドル超へ跳ね上がりかねない。
壊れやすい。プロンプトの3語を変えれば、まったく違う出力が返ってくる。その上にSLAを構築してみるといい。
経済的な罠は、技術的な罠よりもさらに厄介だ。OpenAIやAnthropicがAPI価格を引き下げれば——そして彼らは引き下げ続けるだろう——ラッパー企業のマージンは蒸発する。彼らはデータを所有していない。ワークフローも所有していない。他人の知能に上乗せして再販しているだけであり、大家が全員の家賃を下げた瞬間、又貸し人の商売は成り立たなくなる。
「ディープAI」とは実際に何を意味するのか？
この概念が腑に落ちた瞬間をお話ししよう。
私たちは物流クライアント向けのドキュメント処理システムに取り組んでいた。当初のアプローチは単純だった。出荷書類をLLMに送り、該当フィールドを抽出させ、結果を返す。標準的な帳票では機能した。ところが、東南アジアの港から届いたコンテナ・マニフェストにぶつかった。複数言語が混在した注記、手書きの訂正、学習データのどれとも一致しないフォーマット。モデルは自信満々にゴミを返してきた。
リードエンジニアは、新たな障害モードを次々に生み出すばかりのプロンプトエンジニアリングに一週間費やして苛立ち、ついにこう言った。「一つの脳に七つの仕事をさせようとしているんです。それぞれの仕事を専門家に任せたらどうでしょう？」
それがディープAIを一文で言い表したものだ。LLMをすべてを処理する神託として扱うのではなく、より大きなシステムのなかの一つの部品として扱う。問題を分解するのだ。あるエージェントはクエリの理解を担う。別のエージェントは構造化データベースからデータを取得する。三つ目は既知のルールに照らして出力を検証する。四つ目は応答を整形する。各エージェントには定義された責務があり、それらの間のワークフローは決定論的だ——つまり、順序、ロジック、チェックポイントを自分で制御できる。
ディープAIは、言語モデルをCEOではなく、優秀なインターンとして扱う。統治された構造のなかで具体的なタスクを与えるのであって、建物の鍵を渡すわけではない。
これを成立させるエージェンティックな設計パターンは、机上の空論ではない。すでに現場で展開されている。
たとえば、リフレクション・パターン——エージェントが自らの出力をユーザーに送る前に批評する。また、ツール使用パターン——エージェントが記憶から答えを計算しようとする代わりに、外部の計算機やAPI、データベースを呼び出す。さらに、プランニング・パターン——複雑な目標を順を追ったステップに分解する。そして、オーケストレーション・パターン——スーパーバイザー・エージェントがワークフロー全体を管理し、適切な専門エージェントにタスクを振り分ける。
あの物流システムをマルチエージェント・オーケストレーションで作り直したとき、非標準ドキュメントでの抽出精度はおよそ60%から95%超へ上がった。さらに重要なのは、実際に失敗したときには、どこでなぜ失敗したのかを正確に把握できたことだ——システムがもはやブラックボックスではなくなったからだ。それは観測可能で監査可能なステップを持つパイプラインだった。
なぜトークンコストが企業AIのROIを殺すのか？
ここは十分に注目されていない部分だ。
誰もがモデルの精度について語る。しかし、これらのシステムを大規模に運用するときのユニットエコノミクスについて語る人はほとんどいない。だが私は、それ以外は完璧に動いていたAIプロジェクトのビジネスケースを、トークンコストが静かに殺していくのを何度も見てきた。
計算は単純だが残酷だ。モデルによってテキストのトークン化の仕方は異なる——とくに非英語のテキストや複雑な文字体系ではそうだ。あるモデルで800トークンで済むクエリが、別のモデルでは4,500トークンかかることもある。それを1日数十万件のやり取りに掛け合わせれば、AIがもたらすはずだった効率化の効果を丸ごと吹き飛ばすほどのコスト差になる。
タミル語と英語で事業を行うクライアントのためにトークン化の分析を実施したとき、本気で肝を冷やした。現行モデルとより効率的な代替モデルとのコスト差は4.5倍だった。彼らはやり取りのたびに資金を失い続けており、予算上ではそれを「インフラコスト」に計上していた。トークナイザーを見てみようと考えた人は誰もいなかったのだ。
ディープAIシステムは、高価なLLMトークンを使うタイミングを外科的に絞り込むことで、これに対処する。大量かつ低複雑度のタスクは、より小さなモデルや決定論的ロジックが処理する。高価な推論能力は、それが本当に効くステップにだけ温存される。すべての電話にシニアコンサルタントを出させるのか、それとも判断を要する意思決定に集中してもらうのか——その違いだ。
誰も守らない10-20-70の法則
AIプロジェクトがなぜ停滞したのかを経営幹部と話すと、彼らはほぼ必ずテクノロジーを指さす。モデルが十分でなかった。データがきれいでなかった。統合が複雑すぎた。
そのどれもが間違ってはいない。しかし彼らは本当の比率を見落としている。実際にEBITへのインパクトを出している企業は——そしてマッキンゼーによれば、AIによってEBIT全体の5%超を得ている企業はわずか6%だ——多くの技術者を驚かせるであろうリソース配分に従っている。
労力の10%はアルゴリズムの選定とチューニングに充てられる。20%はデータと技術インフラの構築に充てられる。70%は人、プロセス、そして文化的変革のマネジメントに充てられる。
70パーセント。テクノロジーにではない。人間が働き方を変えるように仕向けることに、である。
私はこの考えを、必要以上に長く拒んでいた。私は本能的にエンジニアだ。より良いシステムを作れば、利用は後からついてくると信じたかった。それを内面化するには、痛みを伴うプロジェクトが必要だった——技術的には優れたソリューションを納品したのに、その周りのワークフローを誰も再設計しなかったために3か月間まったく使われずに終わった、というプロジェクトだ。テクノロジーこそが簡単な部分なのだ。
10-20-70の原則に従う中堅企業は、24か月以内にEBITDAを160〜280ベーシスポイント改善する。70%をテクノロジーに、10%をチェンジマネジメントに費やす企業が手に入れるのは、高価な棚ざらしソフトウェアだ。
その勝ち筋は華やかではない。レベニューサイクル管理。入金消込の自動化。クラウドコストの最適化。退院済み未請求（DNFB）クレームのバックログ削減について、息をのむようなLinkedIn投稿を書く人は誰もいない。しかしInova Health Systemはそのバックログを50%削減し、年間130万ドルを節約した。OSF HealthCareのAIバーチャルアシスタントは120万ドルを節約すると同時に、増収としてさらに120万ドルをもたらした。UPSはAIベースのルーティングによって年間4億ドルを節約している。
これらはパイロットの結果ではない。大規模に稼働している本番システムであり、ラッパーには手の届かない種類の深い統合によって構築されたものだ。
AIエージェントが自ら行動し始めたら何が起きるのか？
AIが質問に答えるものから、行動を起こすものへと移行することで、セキュリティの計算式は根本から変わる。
私はこれについてかなり考えてきた。ひとつには、テスト中にヒヤリとした出来事があったからだ。私たちは、在庫データを取得するためにクライアントのERPにアクセスする必要のあるエージェンティックなシステムを構築していた。テスト実行中、そのエージェントは——技術的には筋が通っているが文脈的には誤った推論の連鎖をたどって——発注書をただ読むのではなく、変更しようと試みた。セーフガードは用意してあった。実行はされなかった。しかし私はその後デスクに座り、もし自分たちがもっと不注意だったら何が起きていただろうと考えていた。
だからこそ、Model Context Protocol（MCP）やNANDAフレームワークのような標準がこれほど重要になる。Anthropicが開発したMCPは、AIエージェントと企業のデータソースの間の標準化された統合レイヤーとして機能する。人はこれを「AIのUSB-C」と呼ぶが、それは的を射ている——接続のたびにカスタムで壊れやすい統合を作る必要がなくなるということだ。NANDAはガバナンスのレイヤーを提供する——暗号学的に検証可能なケイパビリティ証明（エージェントに何が許され、何が許されていないかを証明できるということ）、自律エージェントにまで拡張されたゼロトラスト・アクセス制御、そして集中管理された監査証跡だ。
これらのアーキテクチャ・パターンと、それらがどのように組み合わさるのかの完全な技術的解説については、当社の研究論文をご覧いただきたい。
要点は、エージェンティックAIは危険だからスピードを緩めるべきだ、ということではない。要点は、ラッパー型アプローチ——モデルが何をなぜしているのかへの可視性がほとんどない——は、モデルが現実世界で行動を起こせるようになった途端、本当に無謀なものになる、ということだ。観測可能で統治されたワークフローを備えたディープAIシステムは、単に優れたエンジニアリングというだけではない。企業で自律エージェントを展開する、唯一の責任ある方法なのだ。
「とりあえずGPTを使えばいい」とその他の高くつく助言
モデルが良くなるのを待てばいいのではないか、と私はいつも聞かれる。「GPT-5がこれを解決してくれる」と、ある投資家が夕食の席で言うのを聞いた。「次のモデルバージョンがネイティブに処理してくれるのに、なぜこんなインフラを全部作るんだ？」
この議論の魅力は理解できる。すっきりしている。難しい作業を必要としない。そして、間違っている。
より優れたモデルはラッパーの問題を解決しない。悪化させる。メガプロンプト・アーキテクチャにより強力なモデルを載せるのは、ハンドルのない車にF1のエンジンを積むようなものだ。間違った方向へ、より速く進むことになる。企業AIを殺す問題——監査可能性の欠如、脆いプロンプト、フィードバックループの不在、欠落したビジネス文脈、制御されないコスト——は、アーキテクチャの問題であって、能力の問題ではない。
シャドーAIエコノミーがそれを証明している。従業員の90%超が、会社の公式AIツールが硬直しすぎているために、すでに個人のChatGPTやClaudeのアカウントをこっそり仕事に使っている。モデルは十分に有能だ。その周りのシステムが有能でないのだ。
より優れたモデルが、悪いアーキテクチャを救うことはない。ただ、より速く、より自信たっぷりにハルシネーションするだけだ。
もうひとつよく聞かれるのは期間についてだ。「実際どのくらいかかるのか？」正直な答えは、散発的な実験からP&Lを動かすAIに至るまで12〜18か月、である。最初の3か月はディスカバリー——規制上のエクスポージャーを生まずにAIが価値を生み出せる場所を特定する。3〜6か月目はデータの準備で、CXOの58%がここで行き詰まると答えている。6〜12か月目はマルチエージェントのプロトタイプを構築し反復する期間——ここで言う反復とは、磨き上げたデモを3本作ることではなく、実世界のデータに対して30回以上の反復サイクルを回すことだ。最終フェーズは、ドリフト検知、バイアス監視、コストガバナンスといった完全な運用サポートを伴う本番展開である。
速くはない。簡単でもない。しかしそれをやり切る企業こそが、実際のEBITインパクトを伴ってマッキンゼーの6%に名を連ねている企業なのだ。
この分断は選択の結果だ
MITが特定した「GenAIディバイド（生成AIの分断）」は、テクノロジーのギャップではない。意思決定のギャップだ。
一方の側には、生成AIを買うべき製品、展開すべきラッパー、取締役会に見せるデモとして扱った企業がいる。彼らが95%だ。彼らは本物の資金を使い、プレスリリースを手に入れた。
もう一方の側には、AIをアーキテクチャ上の課題として扱った企業がいる——問題を分解し、ワークフローを統治し、プロセスを再設計し、モデルを企業データの雑然とした現実につなぐという華のない仕事をやり切ることを要求される課題として。彼らが5%だ。彼らは同じくらいの資金を使い、EBITへのインパクトを手に入れた。
私はときどき、あのヘルスケア企業のCTOのことを考える。火曜日に、疲れ切った声で、AIプロジェクトを打ち切ったばかりだと電話をかけてきた人物だ。彼は4か月後にもう一度電話をくれた。彼のチームはマルチエージェント方式でシステムを作り直していた——データ抽出、コード検証、コンプライアンスチェックをそれぞれ別のエージェントが担い、その間の受け渡しは決定論的に行われる。当初のデモほどエレガントではなかった。構築にはより時間がかかった。ワークフロー設計と障害モードについて、より多くの事前の思考を要した。
それは機能した。完璧にではない——完璧なものなど存在しない——が、展開し、監査し、改善するには十分な信頼性があった。損益計算書に姿を現すには十分な信頼性が。
AIを手品のように扱う時代は終わった。次に来るものは、より難しく、より遅く、写真映えもしない。そしてそれが、実際に機能する唯一のものでもある。
