Icebergからインテリジェンスへ：SnowflakeとGoogle CloudによるAI-readyなボーダーレスレイクハウス

Iceberg：サイロから相互運用性へ

以前はすべてのデータベースが独自のデータを所有しており、組織が1つのアナリティクスエンジンしか持たない場合はそれで機能していました。今日のデータチームは、ジョブに応じてApache Spark™、BigQuery、Gemini Enterprise Agent Platform、Snowflake（SnowflakeのCoCoやCoWorkを含む）などのサービスを、多くの場合同じパイプライン内で組み合わせて使用しています。

これにより、柔軟性か一貫性のどちらかを選ぶという二項対立が生じました。

• 各チームに好みのエンジンを使用させ、システム間でデータを複製して、冗長性、不整合、リスクをもたらすこと
• 全員に1つのエンジンを強制し、マルチエンジンアーキテクチャが提供する専門性と自律性を犠牲にすること

業界には第3の選択肢が必要であり、それはデータローカリティの原則として知られる基本的な洞察から生まれました。ネットワーク経由で大量のデータを移動するよりも、データがすでに存在する場所に実行可能コードの小さな断片を移動する方が、より高速で、安価で、セキュアです。

これらのアイデアは、1つのパターンに収束します。データを各エンジンにコピーするのではなく、各エンジンのコンピュートをデータに持ち込むのです。すべてのデータはお客様自身のストレージバケットに保存され、すべてのエンジンがその物理的なレイアウトに同意するため、各エンジンが同じテーブルに対して直接読み書きできるようになります。

これには、すべてのエンジンが理解できる共通言語である、合意されたオープンなテーブルフォーマットが必要です。

業界は、そのフォーマットとしてApache Iceberg™に収束しました。ペタバイト規模のテーブル管理のためにNetflixで開発され、後にApache Software Foundationに寄贈されたIcebergは、Spark、Trino、Flink、BigQuery、Snowflakeなど、数十のエンジンでサポートされています。Icebergを共通言語とすることで、すべてのエンジンが独自の専用アダプターなしで参加できます。

カタログ：Icebergからレイクハウスへ

オープンフォーマットは相互運用性の問題をほぼ解決しますが、新たな疑問をもたらします。誰が管理を担うのかということです。複数のエンジンが同じファイルを読み書きできる場合、誰かがテーブルのメタデータを管理し、アクセスポリシーを適用し、同時書き込みを調整し、どのエンジンも古い状態や不整合な状態を参照しないようにする必要があります。その役割は、レイクハウスのガバナンスレイヤーとして機能するカタログが担います。カタログは、どのテーブルが存在し、そのスキーマがどのようなもので、誰がアクセスでき、データファイルが物理的にどこにあるかを把握している唯一の権威です。カタログがなければ、オープンデータはガバナンスの効いていないデータになってしまいます。

また、カタログは発行された認証情報を通じてストレージへのアクセスを制御します。エンジンがテーブルのデータを要求すると、カタログは永続的なバケット認証情報ではなく、短期間でスコープが限定されたストレージトークンを返すため、エンジンが基盤となるストレージレイヤーへの永続的なアクセス権を取得することはありません。

このモデルが異なるベンダーによって構築されたエンジン間で機能するためには、カタログに標準化された統合プロトコルが必要です。これがないと、すべてのエンジンがすべてのカタログとのカスタム統合を必要とすることになります。これを解決するオープンAPI仕様が、Iceberg REST Catalog（IRC）です。ここでは、クライアントが名前空間を検出し、テーブルのメタデータを読み込み、更新をコミットする方法を定義しています。すべてのカタログはIRCエンドポイントを公開し、すべてのエンジンはクライアントとして接続します。

発行された認証情報と標準プロトコルのこの組み合わせにより、エンジンがカタログの境界を越えること、つまり業界でフェデレーションと呼ばれることが現実的になります。SnowflakeのクエリがGoogle Cloudのレイクハウスのカタログに到達した場合や、BigQueryのジョブがSnowflake Horizonから読み取りを行う場合、各カタログは要求元のエンジンが実際に必要とする、限定的で期限付きのトークンのみを発行するため、どのエンジンがリクエストを開始したかに関係なくガバナンスが適用されます。真の相互運用性には、カタログ外部のエンジンが自社のIcebergテーブルを読み書きできるインバウンドフェデレーションと、自社のコンピュートが別のカタログで管理されているIcebergテーブルを読み書きできるアウトバウンドフェデレーションの双方向でこれが必要になります。

カタログと発行された認証情報が連携することで、セキュリティを適用し、アクセスを制御し、監査を一元化する、単一権威のガバナンスレイヤーが提供されます。これにより、お客様はカタログを越えてIcebergテーブルへの双方向アクセスを取得できるようになり、Iceberg互換エンジン間でゼロコピーアーキテクチャを実現できます。

そこで、アーキテクチャ上の重要な疑問が生じます。誰がカタログを管理するのかということです。お客様は、DIYのセルフマネージドカタログを展開することもできますが、マネージドのIceberg REST Catalogを使用する方が一般的です。

DIYを希望する企業は、SnowflakeとDremioが共同開発し、Apache Software Foundationに寄贈された、人気のあるオープンソースのIRC実装であるApache Polaris™を展開できます。これにより、組織は包括的な制御を得ることができますが、インフラストラクチャ、スケーリング、パッチ適用、可用性を含むすべての運用責任がお客様のチームに移行することにもなります。マネージドソリューションとは異なり、DIYカタログはサーバーレスではなく、使用していないときにゼロにスケールすることもないため、継続的な運用コストが発生します。

実際には、カタログの運用ではなくデータに集中できるよう、ほとんどの組織がマネージドIRCを選択しています。SnowflakeとGoogle Cloudの両方を利用している場合、それぞれが最適なソリューションを提供します。

• Lakehouse runtime catalog（Google CloudのマネージドIcebergカタログであり、Lakehouse for Apache Icebergの一部）は、データレイクハウスの信頼できる唯一の情報源として機能する、サーバーレスでスケーラブルなメタストアです。これにより、複数のエンジン（BigQuery、GoogleのマネージドSpark、Apache Spark、Trino、Snowflake）が、Apache Icebergなどのオープンフォーマット全体で同じデータのコピーにアクセスできるようになります。フェデレーションにより、Google Cloudのエージェントやエンジンは、Snowflake、Databricks、AWS Glueのカタログから境界を越えてデータにアクセスできます。
• Snowflake Horizon CatalogはApache Polarisを統合し、追加のセットアップなしで、標準に準拠したIRCエンドポイントをすべてのSnowflakeアカウントに組み込みます。基本的なカタログ運用にとどまらず、Horizonはエンタープライズガバナンスのレイヤーを追加します。これには、RBAC、列レベルのマスキング、行アクセスポリシー、データリネージ、監査ログが含まれます。これにより、Trino、BigQuery、Apache Flinkなど、Icebergに準拠した多くのエンジンが、SnowflakeのマネージドIcebergテーブルに対して読み書きできるようになります。

フェデレーション：レイクハウスからオープンレイクハウスへ

Lakehouse runtime catalog、Snowflake Horizon Catalog、およびその他のマネージドカタログのオプションは、相互に排他的なものではありません。これらはカタログフェデレーションを通じて同じ組織内で共存できるため、組織は単一のカタログから開始し、ニーズの変化に応じて段階的にフェデレーションを行うことができます。

各カタログは独自のテーブルを管理し、すべてのエンジンはIRCを通じてそれらにアクセスします。

Google CloudがLakehouse runtime catalogを介してカタログを管理する場合、Snowflakeは、IRCエンドポイントからテーブルを自動的に検出して同期するCatalog-Linked Database（CLD）を通じて接続します。Snowflakeユーザーは、標準SQL（SELECT、INSERT、UPDATE、DELETE）を使用するか、SnowflakeのCoCoやCoWorkを介して、Google CloudのLakehouse Icebergテーブルをネイティブテーブルであるかのように操作でき、その上にSnowflakeのガバナンス（RBAC、マスキング、リネージ）を適用できます。

同様に、SnowflakeがHorizonを介してカタログを管理する場合、Google CloudのサービスはLakehouseのカタログフェデレーションを通じてそれらのテーブルにアクセスします。BigQuery、Managed Service for Apache Spark、およびGoogle Cloud内のその他のIceberg互換エンジンは、HorizonのIRCエンドポイントに接続し、SnowflakeのマネージドIcebergテーブルに対して直接読み書きを行います。

その結果、オープンで相互運用可能なデータプラットフォームが実現します。すべてのエンジンは、システム間のETLなしで顧客のCloud Storageバケットから直接読み書きを行い、各チームは独自の好みに基づいて最適なツールを選択できます。一方、カタログレイヤーは、これらすべてにわたって統合されたガバナンスを適用します。

セマンティックコンテキスト：オープンレイクハウスからAI-readyへ

適切に設計されたレイクハウスは、データの相互運用性を大幅に解決しますが、相互運用性だけではデータがAIにとって有用になるわけではありません。「データにアクセスできること」と「AIが正確で信頼できる回答やアクションを生成すること」の間には、3つのギャップが存在します。

• プログラマティックアクセス
• セマンティックグラウンディング
• コンテキストインテリジェンス

プログラマティックアクセス
人間のアナリストは好みのエンジンを通じてテーブルにクエリを実行しますが、AIエージェントには独自のチャネルが必要です。Snowflakeは、MCP互換のクライアントがレイクハウスデータを検出し、クエリを実行し、推論できるようにするモデルコンテキストプロトコル（MCP）サーバーを公開しています。MCPは、AIアプリケーションとデータソース間のユニバーサルなインターフェイスを提供するオープンスタンダードです。つまり、Gemini Enterprise、コードアシスタント、カスタムエージェントフレームワークはすべて、個別の統合を必要とせず、同じプロトコルを通じて接続します。同様に、BigQueryもファーストパーティおよびサードパーティのAIエージェントの両方からアクセス可能なMCPサーバーを提供しており、Google Cloudおよびマルチクラウド環境全体のエージェントワークフローにおいて、レイクハウス資産へのプログラマティックアクセスを可能にします。

オーケストレーションフレームワーク、カスタムパイプライン、組み込みアナリティクスなど、直接的なプログラマティック制御を必要とするアプリケーションの場合、Cortex AgentsやGemini EnterpriseエージェントにはREST API経由でもアクセスできます。MCPとRESTを組み合わせることで、どのカタログが管理しているかに関係なく、人間のアナリストが持つものと同じ、ガバナンスが適用され認証されたIcebergテーブルへのアクセスをAIエージェントに提供します。

セマンティックグラウンディング
AIシステムは、データが何を表しているかを理解していない場合にハルシネーションを起こします。セマンティックモデルは、物理テーブルの上にビジネスロジック（計算ルールを伴うメトリクス、階層を持つディメンション、エンティティ間の関係、組織の知識をエンコードした検証済みのクエリパターン）を定義することで、このギャップを埋めます。重要な洞察は、ビジネスロジックはAIのプロンプトではなく、データレイヤーに属するということです。定義がデータ上のセマンティックモデルに存在する場合、すべてのAIシステムが同じ正しいロジックを継承し、ドリフト、不整合、推測を減らすことができます。

Horizon Contextの一部であるSemantic View Autopilotは、これを大規模かつサステナブルに実現します。アナリストが手動で何百ものセマンティックモデルを定義する代わりに、Autopilotは、クエリパターン、ユーザーの行動、テーブルの関係、BIツールの統合、レポートの使用状況から学習することで、それらを自動的に検出して維持します。自然言語でモデルを作成および改良したいチーム向けに、Semantic Studioの組み込みCoCoアシスタント（プライベートプレビュー中）は、Git統合を備えたビジュアルおよびYAMLエディターと連携して機能するため、セマンティック定義を他のコード資産と同様にバージョン管理およびレビューできます。データが進化してもセマンティックモデルは最新の状態に保たれるため、AIの精度が時間の経過とともに低下することはありません。その結果、ハルシネーションが減少し、精度が向上し、実際のデータに基づいたビジネスロジックが実現します。同様に、Google CloudのUniversal Semantic Layerを活用することもできます。これは、BigQuery GraphおよびSnowflakeセマンティックビューとの新しい統合を含む、データベース内アナリティクスモデルに対するLookerの新しいサポートを活用し、主要なエージェントジャーニーにおいてビジネスユーザーにグラフモデルの機能を提供します。

コンテキストインテリジェンス
コンテキストとは、データが何であるかだけでなく、それを正しく解釈する方法をAIシステムに伝える周辺知識です。Snowflake Horizon Contextは、このコンテキストレイヤーを作成して適用します。これには、ビジネス用語でのテーブルと列の説明、データ品質シグナル（鮮度、完全性、注意事項）、使用パターン（どの質問に対してどのテーブルが信頼できるか）、およびレイクハウス全体のドメイン関係が含まれます。このコンテキストはHorizon内に存在するため、データ自体と同じガバナンスを継承し、エージェントとユーザーは、表示が許可されているコンテキストと回答のみを受け取ります。同様に、Google Cloud LakehouseはKnowledge Catalogを通じて信頼できるコンテキストを提供し、レイクハウステーブルに対するGeminiを活用したインサイトを配信することで、AIエージェントのハルシネーションを軽減し、ユーザーがインサイトをアクションに変えられるようにします。このコンテキストは、Snowflakeネイティブ、CLDリンク、またはGoogle Cloudからフェデレーションされているかを問わず、あらゆるIcebergテーブルに適用されます。AIは、データを正しく解釈するために必要なコンテキストとともにデータを受け取ります。これが、一般的なLLMの回答（「収益は...かもしれません」）と、根拠のある回答（「信頼できるfinance.revenueテーブルから会計四半期の定義でフィルタリングした結果、第4四半期の収益は4,720万ドルでした」）を分ける要素です。

エージェント型AI：データからアクションへ

エンタープライズコンテキストとセマンティックビューが整備されることで、AIエージェントは構造化データと非構造化データ全体にわたって高い精度で動作します。Snowflake CoWorkは、すべてのナレッジワーカー向けのパーソナルワークエージェントです。深く推論し、ルーティンタスクを自動化し、アイデアから意思決定、そしてアクションに至るまでのプロセスを加速させます。CoWorkは指示を待つのではなく、プロアクティブに機能し、インサイトを提示し、バックグラウンドで分析を実行します。そして、ビジネスにおける実際のデータ定義に基づいた、ガバナンスが効いた追跡可能な回答を提供します。

Snowflake CoCoはこれを開発ワークフローに拡張し、エンタープライズデータのライフサイクル業務全体にわたるデータネイティブなコーディングエージェントとして機能します。パイプラインの構築と保守、Cortex AgentsやStreamlitアプリの作成、そして実際のカタログメタデータに基づいた検証済みのSQLやPythonの生成を行います。ナレッジワーカーとデータエンジニアの双方が同じセマンティックグラウンディングの恩恵を受け、人間とエージェントのアクション全体にわたってガバナンスとオブザーバビリティを維持しながら業務を遂行できます。

この同じフェデレーション基盤により、Google CloudのAI機能もネイティブに利用できるようになります。レイクハウスはGoogle Cloud上で稼働するため、Geminiはスタック全体でネイティブに利用可能です。Geminiのマルチモーダルな理解力（テキスト、画像、動画、コードを単一のコンテキストで理解）により、レイクハウスのデータは構造化テーブルに限定されません。GCS内のドキュメント、画像、非構造化コンテンツのすべてがAIワークフローに組み込まれます。その長いコンテキストウィンドウは、大規模なスキーマ、セマンティックモデルの定義、クエリ履歴を同時に取り込み、複雑な分析の質問に対する精度を向上させます。

Gemini Enterpriseは、Lakehouse for Apache Icebergを使用して、MCP（SnowflakeのMCPサーバーまたはBigQuery MCPサーバー経由）を通じてレイクハウスに接続します。Gemini Enterpriseを使用する従業員が自然言語で質問すると、Icebergテーブルのガバナンスが効いたデータを使用して回答が提供されます。その際、クエリはCortex Agentsとセマンティックモデルを経由してルーティングされ、根拠のある回答が担保されます。ユーザーがCoWork、Cortex Code、Gemini Enterprise、またはカスタムRESTエージェントのいずれを通じてやり取りする場合でも、同じセマンティックレイヤー、同じコンテキスト、同じガバナンスが適用されます。

その結果、単なるオープンなレイクハウスではなく、データが相互運用可能で、ガバナンスが効き、セマンティクスが豊富で、標準化されたプロトコルを通じて人間とAIエージェントの双方がアクセスできる、AI-readyなオープンレイクハウスが実現します。

関連情報

• Snowflakeで相互運用可能なレイクハウスを構築するための最新のプロダクト強化をご確認ください
• SnowflakeとGoogle Cloudによるクロスクラウドレイクハウス
• Google Cloud上のSnowflakeに関する詳細をご覧ください

注：Apache Iceberg、Apache Polaris、およびApache Sparkは、Apache Software Foundationの商標です。