AIモデルの良し悪しは、実際に届くデータの質で決まる。そしてそのデータが、はじめからクリーンで中央集約され、新鮮であることはほとんどない。データは通常、CRM、複数のSaaSツール、いくつかのデータベース、そして今も誰かがメールで回しているスプレッドシートに散在している。

これらすべてをAIシステムが使える形に整えること自体が独立した専門分野であり、このカテゴリーはまさに本物の再編の波を経験したところだ。最大級の独立系2社が、数ヶ月のうちに相次いでより大きな企業に吸収されたのである。これは調達の問題にとどまらない。データを取り込むツールとデータを整形するツールが同じ傘下に入るとき、ベンダーがどのレイヤーを支配するのかという問いは、すべての購入者にとって戦略的な問題となる。以下に、現在企業内で実際にデータを動かしている10のプラットフォームを、独立系か否かを問わず紹介する。

Fivetran

Fivetranは、データ移動の煩わしさを完全に取り除くことで評判を築いた。700以上のソースからデータを取得する自動化パイプラインを提供し、ソースアプリケーションがフィールドを変更するたびにパイプラインが壊れるのではなく、スキーマ変更を自動的に処理する。

プラットフォームは完全マネージド型であり、これこそが専任のデータエンジニアを持たずカスタムスクリプトの面倒を見られないチームにとっての魅力だ。ただしその利便性には実際のコストが伴う。月間アクティブ行数に連動する従量課金制はデータ量の増加に伴って急速に上昇する可能性があり、2026年の価格改定では接続レベルでの課金も追加された。

より大きなニュースは、Fivetranが2025年10月に合併した相手だ。dbt Labsとのオールストック取引により、両社は合計で年間経常収益約6億ドルの企業となり、実質的にデータ取り込み層と変換層が単一のベンダー関係に束ねられた。両社のこれまでの顧客基盤の多くは異なるベンダーのツールを組み合わせて使っているため、合併後の会社が両製品を競合スタックに対して等しく開かれたままにするかどうか注視したい。

dbt Labs (dbt)

dbtはこのスタックの中で特定の狭い役割を担っており、意図的に「やらないこと」によってほぼ定義されている。データをまったく動かせないのである。dbtはETLツールではなく変換ツールであり、dbtのSQLとJinjaベースのモデリングが機能する前に、FivetranやAirbyteのような別の取り込み層が生データをウェアハウスに格納する必要がある。

その役割においてdbtは優れている。バージョン管理され、テストされ、文書化された変換ロジックにより、下流のすべてのBIツールでメトリクスの一貫性を保つ。AIアプリケーションが同じウェアハウスにクエリを発行し、基礎となる数値がどこでも同じ意味を持つことが必要になると、これは極めて重要になる。

Fivetranとの合併後、顧客は実質的に2つの契約ではなく1つのベンダー関係を持つことになり、すでに両社を併用していたチームにとっては本当の簡素化となる。

Airbyte

AirbyteはFivetranとは正反対の賭けに出た。完全マネージドのブラックボックスの代わりに、巨大なコミュニティ駆動のコネクタカタログを持つオープンソースのELTプラットフォームを構築し、チームが無料でセルフホストでき、行単位のベンダー料金ではなく自社のインフラのコストのみを支払うことを可能にした。

この開放性は、パイプラインの完全な制御を望み、単一ベンダーのロードマップへのロックインを避けたいエンジニアリング主導の組織にとって本当に魅力的であり、競合他社が統合を進める中でこの考慮はより切実なものになっている。Airbyteは最近、既存カタログにないソースの対応を加速するため、AI支援のコネクタビルダーを追加した。

トレードオフはオープンソースインフラに予想される通りのものだ。特にコミュニティ保守の統合ではコネクタの品質にばらつきがあり、うまく運用するには完全マネージドプラットフォームが吸収してくれるはずの本物のDevOpsの労力が必要になる。

Informatica (IDMC)

Informaticaは約20年にわたり、本物の複雑なデータ環境におけるエンタープライズ標準であり、そのIntelligent Data Management Cloudは、ほとんどの競合が手を出さないフルレンジを今もカバーしている。統合、データ品質、ガバナンス、マスターデータ管理を1つのプラットフォームで提供し、CLAIRE AIエンジンがその全体のメタデータ発見を担う。

より大きなニュースは技術的というより構造的なものだ。Salesforceが2025年後半に完了した80億ドルの取引でInformaticaを買収し、同社は独立した上場企業ではなく完全子会社となった。

コア製品はまだ変わっていないが、購入者は今後問わなければならない。Salesforceが非Salesforce顧客に資する機能を優先し続けるのか、それとも徐々に自社のData CloudやAgentforceの野心に資する方向へロードマップを傾けるのか。このロードマップの行方は、より広いデータスタックが最大のAIプラットフォームベンダーを中心にどう統合されていくかを占う初期シグナルにもなる。

MuleSoft

MuleSoftはウェアハウス取り込み側ではなく、このカテゴリーのAPI主導の側に位置する。Salesforceの統合の背骨として、一対一の個別接続ではなく、再利用可能でガバナンスされたAPIを通じて多数のシステムを接続する必要がある、非常に大きなSalesforce顧客基盤にサービスを提供している。

DataWeave変換言語が実際のデータ操作を担い、最近はModel Context Protocolのサポートを追加して、MuleSoftを人間向けの統合ツールにとどまらず、エージェント型AIワークフローが直接呼び出せるインフラとして位置づけている。

すでにSalesforceエコシステムに深く入っている組織にとって、この位置づけは自然な適合だ。そしてInformaticaもSalesforce傘下となった今、同社はデータ統合市場の隣接する2つの層を事実上握っている。エコシステム外の企業にとっては、MuleSoftのエンタープライズ価格と実装期間を正当化するのはずっと重い負担となる。

Databricks

Databricksは従来のETLベンダーとは異なる前提に基づいてアーキテクチャ全体を構築した。データエンジニアリング、アナリティクス、機械学習を1つのプラットフォームに統合するレイクハウスであり、「データを準備する」と「その上にAIを構築する」を、その間に独自の統合層を必要とする別々のシステムとして扱わない。

これはAIアプリケーションにとってますます重要になる。モデルのトレーニングや推論パイプラインは、アナリティクスとAIワークロードの双方に同じガバナンスされたデータを必要とすることが多く、接続されていない2つのプラットフォーム間でそれらを同期し続けるのは繰り返し起こる頭痛の種だからだ。

ポイントのELTツールより導入の負担は大きいが、本格的なMLワークロードをすでに運用している組織にとって、データ層とAI層が同じ基盤プラットフォームを共有することで、同期問題というカテゴリー全体が解消される。

Snowflake

Snowflakeの中核的な提案は常に、真に伸縮性があり独立してスケール可能なデータウェアハウスであり、そのCortex AI層は、AIアプリケーションがクエリを発行する前に別のエクスポート手順を必要とせず、同じガバナンスされたデータの上に直接構築される。

これが重要なのは、Databricksの統合アーキテクチャが重要なのとまったく同じ理由による。「ウェアハウス」と「AIシステム」の間でデータが余分に経由するホップごとに、鮮度の低下、権限の不整合、単純なデータドリフトが入り込む余地が生まれる。

SnowflakeとDatabricksはこのまさに一点で正面から競合するようになっており、ほとんどの購入者にとって、選択は両者の決定的な機能差よりも、既存のクラウドコミットメントとチームのスキルセットに大きく依存する。

Confluent

Apache Kafkaを基盤とするConfluentは、上記のバッチ指向ツールとはまったく異なるテンポで動く。不正検知や、数時間ではなく数秒以内にイベントへ反応する必要があるライブレコメンデーションエンジンのように、AIシステムが一夜がかりのバッチジョブを待てない状況のためのリアルタイムストリーミングである。

このリアルタイムの基盤は、AIエージェントの存在によって特に重要性を増している。AIエージェントはますます、昨日のスナップショットを分析するのではなく、システムの可能な限り新しい状態に基づいて行動する必要があるからだ。

マネージドELTツールより運用面の負担は重く、夜間レポートしか必要としない企業には明らかに過剰だが、1日前ではなく数秒前のデータをAIシステムに供給するという課題に対しては、代替となるものは実質的に存在しない。

Matillion

Matillionは、大手クラウドウェアハウス(Snowflake、BigQuery、Redshift)のいずれかを日常的に使うチームを中心にニッチを築いてきた。生のパイプラインコードを書くよりも視覚的なドラッグアンドドロップによるETL/ELT体験を提供しながら、重い変換処理を中間エンジンではなくウェアハウス自身のコンピュートに任せる。

このウェアハウスネイティブな設計こそ、よりソース非依存なFivetranやAirbyteに対する中核的な差別化要因だ。組織がすでにこの3つのウェアハウスのいずれかに標準化しており、その上に積み上げる変換ロジックのために扱いやすいインターフェースを求めているときに、Matillionの強みが発揮される。

Estuary

Estuaryは、このリストの大部分とは本当に異なるアーキテクチャの賭けを追っている。バッチELTとリアルタイムストリーミングを2つの別カテゴリーとして2つのツールを必要とするものとして扱う代わりに、Estuaryは単一プラットフォームで変更データキャプチャとバッチレプリケーションを同じシステムから処理し、その目的のためだけに完全なKafkaデプロイを運用するオーバーヘッドなしに、1秒未満の鮮度を目指している。

夜間のウェアハウスロードと、AI向けアプリケーションのためのほぼ即時の更新の両方を必要とし、かつ完全に分離した2つのパイプラインシステムを維持したくない企業にとって、この統合は、バッチツールかストリーミングツールのいずれかを選んで他方がカバーしていたギャップと付き合うよりも、意味のある異なる価値提案だ。

全体を通じて見える一貫したテーマは、データインフラの選定がますますAI戦略に従うようになっているという点だ。企業が1つのベンダーのスタックに統合するか、各層で最良のツールを組み合わせるかにかかわらず、取り込み、変換、ストレージ、AIの間のインターフェースこそが、再編活動の大部分と購入者リスクの大部分が今集中している場所である。

本記事 10 Enterprise Data Platforms Supporting AI And Analytics は Metaverse Post に最初に掲載された。