![[2026年8月19日号]個人的に気になったModern Data Stack情報まとめ](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-4c47f61cc8c1b97c00c0efcc68eab01b/ebc4f0c0223a249eae2f9de257dedbcd/eyecatch_moderndatastack_1200_630.jpg?w=3840&fm=webp)
[2026年8月19日号]個人的に気になったModern Data Stack情報まとめ
さがらです。
Modern Data Stack関連のコンサルタントをしている私ですが、Modern Data Stack界隈は日々多くの情報が発信されております。
そんな多くの情報が発信されている中、この2週間ほどの間で私が気になったModern Data Stack関連の情報を本記事でまとめてみます。
※注意事項：記述している製品のすべての最新情報を網羅しているわけではありません。私の独断と偏見で気になった情報のみ記載しております。
Modern Data Stack全般
AIエージェント時代のコンテキスト・ガバナンスに関する考察が相次ぐ
「AIエージェントがデータ基盤とどう関わるべきか」という論考が業界的に盛り上がっていた印象です。切り口の異なる4本をまとめてご紹介します。
Data Engineering Weeklyでは、AIエージェントを支えるオントロジーについて、単なる用語集ではなく「システムとして機能するオントロジー」に本当に必要な要素は何かを論じる記事が公開されました。
オントロジー、ナレッジグラフ、セマンティックレイヤー、コンテキストグラフは近い概念ですが、担う役割は異なります。本記事では、意味の定義・実データ・実行時の文脈を分離しつつ、検証、版管理、権限制御まで備えた「運用可能な意味基盤」として設計すべきだと論じています。
Metadata Weekly（Atlan社CEOのPrukalpaさんが運営するContext & Chaos）では、AIエージェントは「コード」として扱うべきであり、文書のようなガバナンス手法を適用すべきではないと論じる記事が公開されました。
エージェントそのものは複製・改名・放置されやすく、台帳で追い続ける対象としては不安定です。代わりに、エージェントを構成するスキル、ツール、MCPサーバー、認証情報、ナレッジを管理対象とし、依存関係・所有者・変更履歴・コストを追跡すべき、という主張です。
Modern Data 101では、新しいAI専用の統制基盤を新設するのではなく、既存のデータプラットフォームの権限・ガバナンス機構を転用してAIエージェントを統制する方法を論じる記事が公開されました。
AIエージェントの信頼性は、LLM単体ではなく、その周辺の実行環境によって決まるという整理です。既存のセマンティックレイヤー、アクセス制御、データ品質、リネージ、監査ログ、コスト管理をエージェントの基盤へ転用できる一方、外部API実行などには別途の認可・監視レイヤーが必要になります。
phDataでは、エンタープライズ向けセマンティックレイヤーが無ければAIは意味理解を「推測」するしかない、という論調でメタデータ整備の重要性を説く記事が公開されました。
本記事がいうセマンティックレイヤーは、KPI定義だけではなく、データ間の関係、信頼できるソース、業務上の意味を明示する層です。「売上」や「顧客」といった言葉をテーブル名からLLMに推測させるのではなく、合意済みの定義を与えることで、システム横断でも一貫した回答を目指します。
4本とも切り口は異なりますが、共通して「AIエージェントに何をどこまで委ねるか」「その前提となるコンテキスト・メタデータをどう整備するか」という問題意識が根底にあると感じました。
Data Warehouse/Data Lakehouse
Snowflake
Cortex AI GatewayにDynamic Model Routingを追加、生成AIコストを最適化
SnowflakeがCortex AI Gatewayに「Dynamic Model Routing」を追加すると発表しました。タスクの複雑度、品質、速度、利用者の設定、コストなどを踏まえてAIモデルを自動選択する仕組みです。
一律に高性能モデルを使うのではなく、タスクごとに適したモデルを選ぶことで、品質と推論コストの両立を目指す機能です。モデル選定ロジックをアプリケーションごとに実装・保守する負担を抑えられるため、複数のAIモデルを業務利用する組織ほど恩恵が大きそうです。
あわせて、DeepSeek-V4-Flash 0731やGLM-5.3もSnowflake Cortex AIで利用可能なモデルへ追加予定とされています。利用量の追跡、チーム・エージェント単位のコスト配賦、クォータや支出上限の設定といった管理機能も強化されます。
Native Apps: Cortex AgentsとMCPサーバーがGA
Snowflake Native Apps内で、会話型体験を提供するCortex Agentsや、アプリのオブジェクトをツールとして公開するMCPサーバーをセットアップスクリプトで構築できる機能がGAになりました。
Native AppsでCortex Agentを定義し、Snowflake管理のMCPサーバーを構築できるようになりました。Cortex Searchサービス、セマンティックビュー、ストアドプロシージャ、UDFなどをMCPツールとして公開できるため、アプリに含まれるデータやロジックをエージェントから安全に利用する導線が整ってきています。
Native Apps自体にMCPサーバーを組み込めるようになったことで、Snowflake上で配布されるアプリが、そのままAIエージェントのツールとして使える設計になってきています。
Amazon S3 TablesのIcebergネイティブコネクタがGA
Amazon S3 TablesのIceberg RESTカタログへ直接接続できる機能がGAになりました。AWS Glue統合を経由せず、AWS Signature Version 4（SigV4）認証によりデータを発見・クエリできます。
Iceberg RESTカタログ統合とcatalog-linked databaseを利用することで、SnowflakeからAmazon S3 Tables上のテーブルを探索・参照できます。SnowflakeとAWSのメタデータ連携をより直接的に行えるため、Icebergを中心にデータ共有・相互運用を進める構成で有力な選択肢になりそうです。
また、プライベートエンドポイント経由のアウトバウンド接続にも対応しており、ネットワーク境界を厳格に管理する環境での利用も想定されています。
AIエージェント向け社内コンテキストレイヤーの構築事例を公開
Snowflake社内でAIエージェント向けに構築した「コンテキストレイヤー」の設計・運用について解説する技術ブログが公開されました。
Snowflake社内では、テレメトリや業務データが大量に存在していても、共通の意味づけがなければ「アクティブ顧客」のような基本指標ですら回答がぶれる、という課題があったそうです。データ量を増やす前に、セマンティクスを整備して人間・AI双方へ一貫した文脈を提供する重要性を示す事例です。
BigQuery
AI.SEARCH()が一般提供、構造化・非構造化データを統合検索
BigQueryで自然言語検索を実行できるAI.SEARCH()が一般提供となりました。構造化・非構造化データを横断して検索でき、単一クエリで最大133倍のスロット効率向上が見込めるとしています。
あわせて、埋め込み生成の自動管理機能もGAとなりました。データ更新に応じた埋め込みや検索インデックスのメンテナンスをBigQuery側で担うため、ベクトル検索を運用へ載せる際の実装・保守負荷を下げられます。
さらに、意味検索とキーワード検索を統合する「Hybrid Search」がパブリックプレビューで提供開始されています。RAGや社内検索では、意味的な近さだけでなく固有名詞・製品名・型番などの一致も重要になるため、実務上使いやすい方向の進化だと感じます。
Databricks
Unity AI GatewayにSmart Routingを追加、コストを30%以上削減
Unity AI Gatewayに「Smart Routing」機能が追加されました。タスクの複雑度に応じてモデルを自動選択し、フロンティアモデル相当の品質を保ちながら、タスクあたりのコストを30%以上削減できるとしています。
現時点ではBeta機能で、主にコーディングタスクを対象としています。セッション開始時の説明やメタデータからタスクの難易度を判定し、簡単な作業は低コストモデルへ、複雑な作業は高性能モデルへ振り分ける仕組みです。
また、単なるモデルルーティングではなく、Claude CodeやCodexといったコーディングエージェントでの利用を意識している点も特徴です。将来的には、モデルだけでなくエージェントの実行ハーネスも含めて最適化していく構想が示されています。
Genie OneがGoogle Sheets/Microsoft Excelから利用可能に
DatabricksのGenie OneがGoogle SheetsおよびMicrosoft Excelから利用できるようになりました。
Google Sheets向けのDatabricks Connector、およびDatabricks Excel Add-inから、自然言語でガバナンスされたDatabricksデータを問い合わせられます。結果はスプレッドシートのネイティブな行・列として取り込めるため、従来の業務フローを大きく変えずに利用できます。
普段の業務がスプレッドシートで回っている現場にとっては、かなりありがたいアップデートだと思います。分析の入口はExcelやGoogle Sheetsに残しつつ、裏側ではUnity Catalogなどによるデータ統制を維持できる点がポイントです。
マネージドIcebergテーブルの共有機能がGA
マネージドIcebergテーブルの共有機能がGAになりました。
Databricks間の共有とOpen Sharingに加え、外部のIcebergクライアントに対してもマネージドIcebergテーブルを共有できるようになりました。受け手のクエリエンジンをDatabricksに限定せず、Icebergエコシステムの利用者へデータを届けられる点が重要です。
Delta Sharingに続いてIcebergテーブルの共有もGAとなったことで、マルチエンジン・マルチクラウドでのデータ共有の選択肢がさらに広がった印象です。
DuckDB / MotherDuck
DuckDB v2.0のプレビューを公開
DuckDB v2.0に向けたプレビューが公開され、主要な変更点・新機能が紹介されました。正式版は2026年秋のリリース予定とされています。
v2.0は「Cyanoptera」という名称で、DuckDBをサーバーとして利用するための機能、トリガー、VARIANT型、非同期I/O、新しいSQLパーサー、新ストレージ形式などが大きなテーマとして挙げられています。
組み込み型の分析データベースとして支持されてきたDuckDBですが、より多様なデータ型、リモート実行、運用形態を視野に入れた進化に見えます。特に半構造化データや複数ユーザーでの利用における変化が気になるところです。
AIエージェントが自律的にMotherDuckアカウントを作成できる機能を発表
AIエージェントがシンプルなAPIリクエストのみで、MotherDuckアカウントを作成・利用できる新機能が発表されました。
新しいSignup APIでは、エージェントがMotherDuckアカウントをプロビジョニングし、データベース・ストレージ・コンピュートを利用できます。さらに、ホストされたPython実行環境「Flights」でパイプラインを構築し、クエリ実行や可視化までを行える設計です。
dltがこのAPIをテストしており、Lightdashも含めたAIエージェントによるデータスタック構築の取り組みが紹介されています。
Data Transform
Dataform
AIエージェント経由でデータ変換ワークフローを管理できる、Dataform remote MCPサーバーが一般提供となりました。
Dataformのリポジトリ、ワークフロー、コンパイル結果、実行状況などを、MCP対応のAIクライアントから扱えるようになります。自然言語での状況確認や、変換処理の調査・操作を行うための入口として活用できそうです。
Business Intelligence
Sigma
マルチテナント機能「Sigma Tenants」がGA
複数テナントを1つのワークスペースで管理できる「Sigma Tenants」がGAになりました。
Sigma Tenantsは、単に行レベルセキュリティでデータを分けるだけではなく、ユーザー、データ、コンテンツを持つ独立したSigma Organizationを親組織から統制する仕組みです。テナント単位でコンテンツや利用者を分離しつつ、親組織側では一元的な管理を行えます。
組み込み分析の提供、顧客ごとに分析環境を分けるSaaS、事業部別の運用などに向く機能です。配布ポリシー、テナントごとの利用状況、監査ログを扱えるため、運用面まで含めてマルチテナント化を進められます。
Webhooks・MCP経由でAIモデルと接続する新機能
WebhooksおよびModel Context Protocol（MCP）経由で、SigmaをAIモデルや外部システムに接続できる新機能が発表されました。
Sigma MCPサーバーでは、権限のあるSigmaドキュメントやデータを検索・説明・クエリできます。今後は、MCP対応ツールからSigmaワークブックを生成する機能も予定されており、対話型AIから分析成果物を作る流れが強化されそうです。
WebhookトリガーはPublic Betaで、外部システムからのPOSTリクエストを起点にSigma内のアクションを実行できます。AIの回答を、アラート、承認、業務システムとの連携など、分析の次のアクションへつなぐ用途が想定されます。
Omni
AIで指示を書くだけでツールを構築できる新機能「Omni Apps」がリリースされました。
Omni Appsは、AIが自由にSQLや独自ロジックを生成するのではなく、検証済みのセマンティックモデルを参照してアプリを構築する設計です。そのため、既存ダッシュボードと同じ定義・指標・ディメンションを使い、アプリとBIコンテンツの間で意味がずれることを防げます。
権限、ロール、行レベルセキュリティ、監査性も既存のOmniコンテンツと同様に引き継がれます。また、外部ネットワーク通信はデフォルトで制限され、必要な通信だけをアプリ単位で明示的に許可する仕組みです。
Appについては弊社でも検証記事を書いています。こちらも併せてご覧ください。
Data Catalog
OpenMetadata
開発中のメジャーバージョン2.0.0に向けたリリースキャンディデート第2版（2.0.0-rc2）が公開されました。DEV/TEST環境での検証・フィードバックが呼びかけられています。
