Andrew Tanによる
なぜ85%の企業がAIに対応できていないのか
Fivetranの2026年のベンチマークによれば、85%の企業がエージェンティックAIを動かすためのインフラが準備できていないことが判明しました。問題はモデルではなく、それにデータを供給するデータパイプラインです。
以下は多くの場所で見られるパターンです：
ある企業が6か月をかけてLLMを評価します。ベンチマークを行い、契約を交渉し、概念実証を構築します。モデルは素晴らしいものに見えます。そして、それを本番環境に展開すると、エージェントがモデルとは関係ない方法で幻覚を見始めます。
AI自体は問題ありませんが、それに供給されるデータが問題です。
これがFivetranのEnterprise Data Infrastructure Benchmark Report 2026が実際に測定していることであり、85%の企業がエージェンティックAIに対応できていないと言われる理由です。モデルが間違っているのではなく、パイプラインが間違っているのです。
「準備ができていない」とは実際に何を意味するのか
「AI対応インフラ」というフレーズは多くのものを売るために使われます。通常、それはクラウドのスケーラビリティに関する曖昧な意味を持ちます。それがFivetranレポートが測定しているものではありません。
彼らが特定した3つの具体的な問題：
古いデータ。 エージェントは昨日の状態を基に推論しています。カスタマーサービスエージェントの場合、それはすでに返金が行われたことを知らないことを意味します。詐欺検出エージェントの場合、それは18時間前のパターンを基に動作しています。毎時または毎晩実行されるバッチパイプラインは、現在起こっていることに基づいて行動する必要があるエージェントをサポートできません。
スキーマの強制がない。 ソースシステムは常に変化します。列が名前変更され、型が拡張され、新しいフィールドが現れます。パイプラインが下流でスキーマ契約を強制しない場合、エージェントは有効に見える不正なデータを受け取り、それに基づいて自信を持って行動することがあります。
可観測性がない。 ほとんどのパイプラインモニタリングはジョブが実行されたかどうかを教えてくれます。データが正しいかどうかは教えてくれません。エージェントは技術的には動作しているが、20%のイベントを静かにドロップしているパイプラインからデータを消費している可能性があります。誰かがエージェントが奇妙に動作していることに気付くまで、問題はわからず、その時にはすでに被害が出ています。
これらは新しい問題ではありません。これらは何年もアナリティクスチームを悩ませてきたデータ品質の問題です。変わったのは影響範囲です。BIダッシュボードでのデータ品質の問題は悪いチャートです。エージェンティックシステムでのデータ品質の問題は、誤った情報に基づいて行われた自律的な決定です。
スタックのミスマッチ
AI対応データスタックの問題は、アーキテクチャの仮定における深いミスマッチです。
ほとんどの企業データスタックはバッチ処理を中心に構築されていました。毎晩のETLジョブ。毎日のデータウェアハウスの更新。毎朝更新されるダッシュボード。システム全体が新鮮さよりもスループットを最適化していました。
AIエージェントには異なる要件があります。彼らは正確であるだけでなく、現在のデータが必要です。彼らは過去数秒または数分で起こっていることに基づいて行動する必要があります。そして、彼らが間違っている場合、システムはそれをキャッチする必要があります—ただログを記録して進むのではなく。
準備ができている企業—15%—は必ずしもスタック全体を置き換えたわけではありません。彼らの多くは、重要なところでリアルタイムにシフトし、意味のあるところでバッチを維持しました。顧客注文ストリームはリアルタイムで動作します。四半期ごとのコスト会計は依然として毎晩実行されます。違いは意図性です：どのデータが新鮮さを必要とするかについて明確な決定を下し、それに応じてパイプラインを構築しました。
実際に重要な3つの特性
「AI対応」インフラが必要とするものについては多くのノイズがあります。通常、それはベンダーの製品に便利にマッピングされるチェックリストです。ここでは実際の失敗モードにマッピングされるバージョンを示します：
新鮮さ。 単に「すべてのためのリアルタイム」ではありません—それは高価でしばしば不要です。しかし、エージェントが実際に行動するデータについては、遅延を知り、それについての保証を持つ必要があります。顧客データが4分古い場合、それで構いません—エージェントがそれを知っていて、それに基づいて行動する限り。エージェントがデータが現在のものであると仮定しているときにそれがそうでないときに問題が発生します。
一貫性。 エージェントはしばしば複数のソースからデータを組み合わせて決定を下します。それらのソースが異なるスケジュールで動作しているか、異なる新鮮さレベルで動作している場合、デバッグが難しい微妙な不整合が発生します。顧客の検索ではアカウントがアクティブであると言っていますが、トランザクションストリームは追いついておらず、保留中の閉鎖として表示されています。エージェントは各ソースに対して個別には正しいが、結合された状態に対しては間違った決定を下します。
イベントレベルでの可観測性。 パイプラインモニタリングはジョブについて教えてくれます。エージェントの信頼性には個々のイベントのモニタリングが必要です。イベントが処理されているのか、ドロップされているのか？スキーマはエージェントが期待するものと一致しているのか？下流の消費者を圧倒するバーストがあるのか？これはほとんどのチームが構築してきたものとは異なるクラスのモニタリングです。
ビルド対購入の決定にとっての意味
AIの波は、多くのエンジニアリング組織で蓄積されてきた請求書を表面化しています：データインフラを解決済みの問題として扱うことのコスト。
2年前にカスタムバッチパイプラインを構築し、それで終わりとしたチームは、今、厳しい選択に直面しています：リアルタイムを設計されていないシステムに後付けするか、再構築するか。どちらの選択肢も安くはありません。後付けは2つのパイプライン問題を生み出す傾向があります—履歴のためのバッチシステム、リアルタイムのためのストリーミングシステム、わずかに異なるロジックでほぼ同じことをしている2つのコードベースと、常に分岐する結果。
この問題をうまく処理しているチームは、その選択をする必要がないチームです。バッチとストリーミングが同じパイプラインとして同じツールで動作する場合、ワークフローを毎時からリアルタイムに切り替えるのは、書き直しではなく、設定変更です。可観測性、スキーマの強制、障害処理—それはプラットフォームと共に提供されるものであり、その上にカスタムビルドされるものではありません。
それがlayline.ioの構築の中心です。単にリアルタイムのためだけでなく、スタック全体でデータの新鮮さについて明示的で意図的な決定を下す能力を持つこと—2つの別々のシステムを維持することなくそれを実現することです。
考えるべき質問
85%という数字は衝撃的です。しかし、より興味深い質問は：その85%に属していることを知っている企業はどれくらいあるのでしょうか？
問題を抱えているチームは、通常、明らかに壊れたパイプラインを持っているチームではありません。彼らは、パイプラインが機能しているように見えるチームです—ジョブが実行され、ダッシュボードが読み込まれ、アクティブなインシデントがない—しかし、AIエージェントがデータに基づいて重要な決定を下し始めたときにのみ現れる静かな信頼性の問題を抱えています。
エージェントが奇妙に動作していて、すでにモデルを除外した場合は、データを見てください。
Andrew Tanは、バッチとリアルタイムの両方のワークロードをスケールで処理する企業データ処理インフラを構築するlayline.ioの創設者であり、連続起業家です。
