ところが、複数の要因が重なったことで、企業はAIワークフローの構築方法を見直すようになった。

　従来のRAGパイプラインは、AIツールを本番稼働させるのに十分な精度を引き出すためのコンテキストをうまく提供できなかった。自律型エージェントの普及に伴って、リアルタイムデータも必要になった。一方でデータ管理サービスベンダーが、自社のシステムにベクトルデータベース機能を組み込み始めていた他、AI投資に見合う効果を得られていない企業が現れ始めたことで、費用の抑制とセキュリティへの懸念が顕著になったのだ。

　その結果、費用が高くてリスクを伴うETL（データの抽出、変換、書き出し）パイプラインは徐々に廃止され、代わりにAIモデルをデータの保管場所に持ち込む手法が選ばれるようになった。

　調査会社BARC U.S.のアナリスト、ケビン・ペトリー氏も幾つかの要因を挙げる。データ管理システムの急速な進化、事前にベクトル検索をせずに非構造化データを解釈できるLLMの性能向上、セキュリティや規制要件の厳格化などだ。

データを動かさずにコンテキストを維持する

　「AIモデルをデータの場所に持ち込む」（Bringing AI to data）とは、AIモデルの推論、ベクトル検索といった機能を、データベースなどのデータ管理システム内に配置することを意味する。

　この構造のメリットは、データを本来の生成・保管場所にとどめておけることだ。こうした構造では、データカタログやセマンティックレイヤー（物理的なデータ構造を業務上の意味に翻訳・統一する共通定義層）などを通じて適用されているガバナンス、データの来歴、コンテキストが損なわれない。これらの情報が、AIモデルを用いてツールを開発する際にもそのまま維持されるようになる。

　DatabricksでAI製品担当バイスプレジデントを務めるクレイグ・ワイリー氏は、「AIモデルをデータの場所に持ち込むことは、企業の最も重要な情報の保存場所で、AIモデルを動かすことを意味する」と説明する。セキュリティやアクセス方針を維持したまま、企業の統制下にあるシステム内で運用することで、データ移行やパイプラインが不要になる。

　これとは対照的に、パイプラインを通じてデータをコピーしてAIモデルに渡すと、データのバージョン管理が必要になり、その過程でガバナンスやビジネスロジックが失われてしまう。その結果、開発者やエンジニアは新しいシステム構成ごとにガバナンスとセキュリティを再構築しなければならず、時間と費用がかかる。

　ワイリー氏は、データやMCP（Model Context Protocol）サーバ、AIモデルが全て異なるシステムにある状態で、それぞれ異なるガバナンスや制御が適用されている場合の問題を指摘する。この状態では、AIモデルやエンドユーザーが目的のコンテキストを探し出すだけで、余計なトークンと時間を消費することになる。検索、アクセス制御、監視を1つのシステムに集約することで、開発を加速させ、時間とトークンにかかる費用を削減できる。

　企業がAIモデルをデータの場所に持ち込むためのサービスを提供しているデータ管理サービスベンダーの例は以下の通りだ。

• Databricks
• Snowflake
• Amazon Web Services（AWS）
• Google
• Microsoft
• Cloudera
• MongoDB
• Teradata

　SnowflakeのAIシステム担当責任者であるパバン・ポツクチ氏は、AIモデルをデータの場所に持ち込むことの利点として、業務コンテキストが欠落しない点を挙げる。これによって、AIモデルがハルシネーション（幻覚）を起こさず、意図した通りに動作する可能性が高まるという。「この構造であれば、AIツールごとに個別のデータソースを用意せずに、自社のビジネスデータとAIモデルを連携させられる」と同氏は説明する。

　2023年に起きた生成AIブームの初期、企業はまずデータを外部のベクトルデータベースやLLMに流し込んだ。これはデモや実験ではうまく機能したが、いざアプリケーションを本番稼働させる段階になると、企業の厳しい基準を満たせなくなるケースが多発した。

　「コンプライアンスを順守しながら顧客データをAIモデルに読み込ませる課題に向き合ったとき、企業は『データを外部に送る』手法が通用しないことに気付いた」とポツクチ氏は言う。独自のデータを使って実運用レベルの本格的なAIシステムを構築するには、ガバナンスやアクセス制御、監査性が不可欠であり、これらを新しいツールで簡単に再現することはできない。