Fivetran 2026年5月6日の公式ブログ解説: Open Data Infrastructure とデータ職種

Fivetran は 2026年5月6日、Why every data role needs Open Data Infrastructure を公開しました。analyst、data engineer、data scientist、ML engineer、agentic workflowが同じデータを別々の形で使う時代に、storageとcomputeを分離し、open table formatsを軸にした基盤が必要だという主張です。

要点

• Fivetran は、データ利用者ごとに必要なtoolやworkflowが異なるため、単一のwarehouseやengineへ閉じ込める設計は限界があると説明している
• AIやagentic workflowにより、データのコピー、断片化、同期遅延、governanceの複雑化がより大きな問題になる
• Open Data Infrastructureは、データを一度lakeに置き、IcebergやDelta Lakeのようなopen formatsで複数engineから使う考え方として示されている
• Fivetran Managed Data Lake Serviceは、ingestion、compaction、snapshot managementなどを自動化し、AI-readyなdata foundationを支える文脈で語られている

今回のブログ記事で語られていること

この記事の中心は、データチームをひとまとめに扱うと基盤設計を誤る、という問題提起です。analystは低レイテンシのSQLや安定したmetricsを求め、data engineerは信頼できるingestionやschema evolution、pipeline orchestrationを重視します。data scientistはstructured / semi-structured / unstructured dataをまたいで探索や実験を行い、ML engineerはproduction-gradeなAIやagentが最新で完全な業務コンテキストへアクセスできることを必要とします。Fivetranは、これらを単一のengineに押し込めると、ツールが特定用途に最適化されすぎたり、チームが別コピーや独自pipelineを作ったりして、コストと統制が崩れると説明しています。

AIの導入はこの問題をさらに大きくします。従来は人間がdashboardやnotebookからデータを読むだけでしたが、今後はLLM、agent、automationが継続的にデータを参照し、意思決定や業務実行に関わります。もしベクトルDB、feature store、notebook環境、warehouse、BI用martにデータが個別にコピーされていると、どれが正しいのか、どれが最新なのか、誰がアクセスしてよいのかが分かりにくくなります。記事は、この断片化を単なるストレージコストの問題ではなく、AIの信頼性とgovernanceの問題として扱っています。

Open Data Infrastructureの考え方は、データを一度open table formatで保存し、用途に応じて複数のcompute engineから直接使えるようにすることです。たとえばBIはSQL engineから、data scienceはnotebookやSparkから、agentic workflowはLLMやworkflow engineから、同じデータ基盤を参照できます。Fivetranは、その前段にあるingestionとmaintenanceをManaged Data Lake Serviceで担うという位置づけを示しています。この記事は製品紹介でもありますが、より実務的には、AI-ready data stackを作るときに「どのengineを選ぶか」だけでなく「データの正本をどこに置き、どう複数用途へ開くか」を考える材料になります。

対象になりそうなチーム

• Fivetran、Iceberg、Delta Lake、data lakehouseを検討しているdata platform team
• agentic AIやML workflow向けに、鮮度とgovernanceを両立したいAI / ML team
• warehouse中心の分析基盤から、複数engine前提の設計へ広げたいdata architects
• データコピー増加、pipeline乱立、権限管理の複雑化に悩むanalytics leaders

実務で確認したいポイント

1. analyst、data engineer、data scientist、ML engineer、agentの主要ワークロードを分けて棚卸しする
2. 同じデータがwarehouse、lake、vector DB、notebook環境などに複製されていないか確認する
3. IcebergやDelta Lakeなどopen table formatsを採用する場合のcatalog、権限、compaction、snapshot運用を整理する
4. Fivetran Managed Data Lake Serviceを使う場合、既存ELT、dbt、BI、ML基盤との責任分界を確認する

結局、今回のブログ記事をどう読むべきか

Fivetranの記事は、AI時代のデータ基盤を「全員が同じwarehouseを使えばよい」という発想から切り離すためのものです。重要なのは、職種ごとに違うtoolを許しながら、データの正本、governance、鮮度、コストを崩さないことです。agentic AIを進める組織ほど、データをどこへ何回コピーしているかを先に見直す価値があります。