10月9日、Eric Avidonが「Security, cost benefits drive the rise of bringing AI to data」と題した記事を公開した。この記事では、データをAIモデルに送るのではなく、AIモデルをデータの保管場所に持ち込む「Bringing AI to Data」アプローチが、コストとセキュリティの両面で従来の分断されたパイプライン構成を上回る理由について詳しく紹介されている。

なぜ今、データをAIに送るアーキテクチャが見直されているのか

2022年11月のChatGPT登場後、多くの開発チームはRAG（Retrieval-Augmented Generation）パイプラインを構築した。データをベクターデータベースにエクスポートし、LLMと接続して類似検索で文脈を取得するという構成だ。だが、これには構造的な欠陥があった。

SanjMoのアナリストであるSanjeev Mohanはこう指摘する。「当時、最良のモデルはホスト型APIとしてしか利用できず、データをモデル側に送るしかなかった。データプラットフォームにはベクター検索機能がなく、緊急性が優先された。ガバナンスは後回しにされた。」

結果として何が起きたか。データを外部に移動させるたびに、ガバナンス情報・データリネージ・ビジネスロジックが失われる。開発者はそれを新しい環境で再構築しなければならず、時間もコストもかかる。さらに、本番環境に投入しようとした段階で、コンプライアンス要件を満たせないケースが続出した。

Snowflakeでヘッド・オブ・AI・プラットフォームを務めるPavan Pothukuchiはこう述べている。「『データを外部に送る』アプローチは、デモや実験ではうまく機能した。しかし、スケールを持って本番稼働させようとしたとき、ほとんどのエンタープライズ基準を満たせなかった。」

こうした課題はRAGに限った話ではない。データメッシュやフェデレーテッドクエリといった分散アーキテクチャも、データの所在を分散させることで組織横断のアクセスを容易にする思想を持つが、それらもまた「データを動かさずに処理する」という点では共通の哲学を持つ。「Bringing AI to Data」はその延長線上に位置づけられるアプローチであり、LLM時代における分散データ戦略の自然な発展形といえる。

「AI to Data」が解決する3つの問題

1. コストが半減する

McKnight ConsultingのWilliam McKnightが実施したベンチマークテストによると、「Bringing AI to Data」アーキテクチャは、データエグレス（クラウド外へのデータ転送）やETLワークロードを必要とする分断されたパイプライン構成と比較して、AIツールの3年間のTCO（総保有コスト）を約50%削減した。

さらに同テストでは以下の結果も示されている。

• 開発から本番までのタイムラインを300%超短縮
• 開発の複雑性を67%削減
• 保守の複雑性を38%削減
• エンジニアリング人件費を50%削減

コスト増大の主因は、AIアプリケーションごとにETLパイプライン・専用ストレージ・アクセス制御ポリシーを個別に構築しなければならないことにある。データエグレス料金も積み重なる。DatabricksのVP of AI ProductであるCraig Wileyは「複数のAIツールとモデルプロバイダーを使うエンタープライズでは、コストが急速に膨れ上がる」と述べている。

2. セキュリティが劇的に改善する

McKnight Consultingの同ベンチマークでは、統合型のインプレースプラットフォームは、データを外部クラウドエンドポイントに移動させるアーキテクチャと比較してデータセキュリティスコアが4倍高いという結果も出ている。この数値はMcKnight Consultingが設定した評価基準に基づくものであり、特定のセキュリティ標準との直接対比ではない点には留意が必要だ。

データをシステム間で移動させるたびに、攻撃対象領域（アタックサーフェス）が拡大する。暗号化・マスキング・ID管理を各ホップで再適用しなければならず、ネットワーク境界を越えたデータ転送はデータ漏洩リスクを高める。AIをデータの保管場所で動かすことで、ガバナンスをゼロから再構築する必要がなくなり、ペリメータ内での完全な封じ込めが実現する。

BARCのアナリストKevin Petrieはこう説明する。「AIモデルやエージェントがデータを消費するたびに、PII（個人識別情報）が不正なユーザーに露出しないよう、厳密なセキュリティ制御を維持しなければならない。AIをデータに持ち込む方が、その制御を維持するのははるかに容易だ。」

3. コンテキストが保持される

データが外部に移動されると、ガバナンスメタデータ・データカタログ情報・セマンティックレイヤーが失われる。AIをデータの保管場所に置くことで、既存のアクセスポリシーやリネージ情報をそのまま活用できる。これはハルシネーション（AIの誤った出力）を抑制する上でも有効だ。

主要プラットフォームの対応状況

この設計思想はすでに主要ベンダーに採用されている。

• Databricks: Unity CatalogをAI・ML・データの統合コントロールプレーンとして位置づけ、複数のLLMをプラットフォーム内でネイティブに提供
• Snowflake: Cortex AIを中心に、AnthropicやGoogleのモデルをネイティブ統合
• ハイパースケーラー: AWS、Google Cloud、Microsoft Azureも同様のアプローチを提供
• その他: Cloudera、MongoDB、Teradataなどのプラットフォームベンダーも対応

万能ではない：残る課題

ただし「Bringing AI to Data」はすべての問題を解決するわけではない。

AIツールが必要とするコンテキストは複数のシステムにまたがっている。たとえ一部が同一プラットフォーム上にあっても、残りはそうでない場合が多い。その場合、**MCPサーバー（Model Context Protocol）を通じたフェデレーテッドアクセスやゼロコピーデータ共有**が必要になる。MCPはAnthropicが策定したオープンプロトコルで、AIエージェントが複数のデータソースやツールに対して標準化された方法でアクセスできるようにする仕組みだ。データメッシュにおけるデータプロダクトの相互運用性や、フェデレーテッドクエリエンジンによるクロスソース結合と組み合わせることで、「データを動かさずにAIに文脈を与える」構成をより広い範囲で実現できる可能性がある。

また、組織内で「revenue（売上）」の定義が部門によって異なるような場合、AIエージェントはどの定義を使うべきか判断できず、自信を持って誤った結果を返す。データをAIの近くに置くだけでなく、ビジネス上の概念・メトリクス定義・権威あるデータソースの特定といった「ビジネス知識をAIが読める形で整備すること」が不可欠だ。

さらに根本的な問題として、アーキテクチャがどれだけ洗練されていても、基盤となるデータそのものが整備されていなければ意味がない。McKnightは「汚いデータや未整備のデータにAIを直接当てることは、パイプラインの問題よりもはるかに危険な問題を引き起こす」と警告している。データオブザーバビリティとヒューマン・イン・ザ・ループの監視体制が不可欠だ。

詳細はSecurity, cost benefits drive the rise of bringing AI to dataを参照していただきたい。