はじめに
2025年10月、私は以下の記事を書きました。
Snowflake Optima、Adaptive Warehouse、Query Insightsを起点に、データエンジニアリングの未来を3つのフェーズで描いた妄想記事です。
それから約半年がたち、2026年4月30日にSnowflakeのエンジニアリングブログで以下が公開されました。
Snowflake Optima Metadata: Smarter Pruning Through Workload Intelligence
Optimaの第2弾、Optima Metadataの紹介ブログです。Optima Metadata自体は本文に "Earlier this year" と明記の通り2026年早期に既にリリース済みで、4月30日のブログは稼働実績の事例紹介でした。
このブログをもとに前回の妄想の振り返りと、 Snowflakeが残り2026年で何を仕込んでくるか を予想してみたいと思います。
第1部：半年での動き
Optima関連
| 日付 | 出来事 |
|---|---|
| 2025年8月 | Optima Indexing GA |
| 2025年9〜10月 | Optima Indexing 紹介ブログ公開 |
| 2026年早期 | Optima Metadata リリース |
| 2026年4月30日 | Optima Metadata 事例ブログ公開 |
Optima Metadataは2025年10月のブログ時点で既に予告されていました。
Optima Indexing is just the beginning for Snowflake Optima. Later this year, we'll also be launching Optima Metadata.
つまりOptimaはSnowflakeの計画通りに進捗しているということです。
Adaptive Warehouse
前回記事では「Adaptive Warehouseのパブリックプレビューを早く！」と書いたのですが、AP Northeast 1（東京） 含む3リージョンで、Enterprise Edition以上で既に試せる状態です。
早く！と言ってたくせに、色々仕事の幅が広がり、なかなか自分でじっくり検証する時間が取れていません。。
第2部：Optima Metadataとは
プルーニングと、その限界
Snowflakeはテーブルを マイクロパーティション という単位で分割し、各パーティションに列ごとの MIN/MAX メタデータを付けています。クエリ実行時にはこれを使って、ヒットしないパーティションをスキャン対象から外します。
Snowflakeの2025年SIGMOD論文では、 全顧客ワークロード平均で 99.4% のマイクロパーティションがプルーニングできている と報告されています。一方で、4月30日のブログはこう指摘しました。
スキャンされたマイクロパーティションのうち、40%は最終的なクエリ結果に1行も貢献していない
99.4%プルーニングで残った最後の0.6%の中に、まだ「読まなくてよかったもの」が4割含まれている。原因は、MIN/MAX だけでは扱えない以下のような述語にあります。
SELECT * FROM customers WHERE UPPER(email_domain) = 'SNOWFLAKE.COM'
SELECT * FROM logs WHERE error_message ILIKE '%connection timeout%'
SELECT * FROM events WHERE TO_DATE(timestamp_string) = '2026-01-30'
列の生の値ではなく、関数や変換を通した値を条件にしているクエリ。MIN/MAX は「UPPER() をかけた後の値域」を追えないので、安全側に倒してスキャンするしかなかった領域だと考えられます。
Optima Metadataの動作
Optima Metadataは、
- クエリ履歴を継続走査し、未活用のプルーニング機会を持つ述語を見つける
- 頻繁に登場する「ホット」な式を特定し、専用の軽量メタデータを動的に生成する
- 通常のmin/maxメタデータと併用してアグレッシブにプルーニングする
そしてワークロード変化で不要になったメタデータは自動破棄。設定不要、追加コストなしというかなり優れたサービスになっています。
Search Optimization Serviceとの関係
ILIKE '%pattern%' のような述語は、 SOSを手動設定すれば従来から効いていた領域 だったので、Optima Metadataはこれを「設定不要・追加コストなし」で自律化したものとなります。
Optima Indexingも公式ドキュメントに "built on top of the search optimization service" と明記されており、Optima系2機能はどちらもSOSの自律化ラッパーだと考えています。
ミッションクリティカル用途で、確実に性能を出したいときは、明示的にSOSを設定して使い続けることが公式に推奨されており、両者は共存する関係と言えます。
フォーチュン500に名を連ねる医療関連企業の事例
このブログの中では、クラウドネイティブのセキュリティ情報およびイベント管理（SIEM）プラットフォームの運用事例が紹介されていました。
事例規模とOptima Metadata 適用効果
- 対象：22 billion-rowのクラウドイベントログ（期間中に19.7→21.8 billionへ10%成長）
- 検知ルール例：
SOURCE ILIKE '%AWS CloudTrail%'、PROCESS_PATH ILIKE '%diskshadow.exe' - スキャン量：20.73 TB/日 → 5.36 TB/日（約74%削減）
- プルーニング数：0 → 1日あたり 約5.51億 マイクロパーティション
- 検知ルール実行時間：最大50%、少なくとも10%短縮
- ユーザー側の作業：ゼロ
これだけの規模のSIEMで、検知ルールに合わせたテーブル最適化を明示的に行わずに約7割のスキャン削減という結果は、ウェアハウスのコスト削減だけでなく、おそらくクエリスピードなども大幅に改善したのではないでしょうか？
第3部：Optimaの設計原理と経済モデル
IndexingとMetadataから抽出できる5原理
- 観測 → 生成 → 適用 → 回収の汎用ループ：手動MV/インデックスのような「最適化の墓場」を作らない
- ユーザー設定を一切要求しない：Simplicity思想の追求
- Gen2/Adaptive Warehouseに乗る：Gen2 → Adaptive → Optimaが今後の主軸
- Query Insightsで透明性レイヤーを必ずセットで提供
- ベストエフォート、手動オプションと共存：SOSやMVを置き換えない
5原理が成立する経済的根拠
予測を考える前に、もう一つ重要な視点を整理しておきます。Optimaが なぜ無償で提供できるか という経済モデルの話です。
公式ドキュメントには Optima Indexing についてこう書かれています。
There are no additional costs for Optima Indexing, and because it is fully integrated into Snowflake, no additional configuration or effort is required to benefit from improved performance.
「コンピュートもストレージも追加課金なし」。これは強い保証です。
ここで重要なのは、 Optimaが対象としている既存機能（SOS）は、本来課金されている機能 だということです。SOSは追加データ構造の生成と維持にストレージ・コンピュートが必要で、ユーザーが手動で設定すれば普通に課金される。Optima Indexingはそれを「無償の自律ラッパー」として包んでいます。
なぜ無償化が成立するのか。鍵は 対象機能の「重さ」 にあります。
| 機能 | 物理的な操作 | 維持コストの性質 | 課金 |
|---|---|---|---|
| SOS | 補助インデックス（軽量） | 限定的 | あり（手動利用時） |
| Optima Indexing | 補助インデックス（軽量） | 限定的 | なし |
| Optima Metadata | メタデータ拡張（極軽量） | ほぼなし | なし |
| Automatic Clustering | 物理データの再配置 | 継続的なコンピュート | あり（serverless課金) |
| Materialized View | 物理データの複製 + 追従更新 | 継続的なストレージ + コンピュート | あり（ストレージ + serverless課金） |
Optimaが現在カバーしているのは、 「軽量な補助構造」のカテゴリ だけです。実データを物理的に複製したり、並び替えたりはしない。だから内部負担として無償化できる。
一方で、Automatic ClusteringとMVは 物理データへの操作 を伴うので、Snowflakeは継続的なコンピュート/ストレージ課金を行っています。これらをOptimaの傘下に入れて無償化するのは、 収益モデルへの直接的な変更を意味する ため、構造的にハードルが高い。
この経済的視点は、第5部の予測で各候補の確度を評価する際の重要な軸になります。
第4部：業界の動向：オープンフォーマット対応が新たな主戦場
ここ数年、データプラットフォームの世界で Apache Iceberg を中心としたオープンフォーマット対応 が、各社の主戦場の一つになっています。Databricksも Snowflakeも、それぞれ自社の自律最適化機能をオープンフォーマットに広げる動きを見せており、 「データはオープン、最適化はプラットフォーム」 という構図が徐々に固まりつつあります。
Snowflakeは "It should be impossible to run inefficiently on Snowflake." という野心的な宣言を掲げており、Iceberg統合も継続的に強化しています。2026年4月には「Snowflake Storage for Apache Iceberg™ tables」をPublic Previewで提供開始するなど、Iceberg対応の拡張を続けています。さらにSnowflake-managed Icebergでは Automatic Clustering や Search Optimization Service も既に対応しており、ネイティブテーブルに近いパフォーマンスを実現しています。
ここに自律最適化機能（Optima系）が加わると、構図は一段強くなります。 オープンフォーマットを使いながら、ネイティブと同じ無償の自律最適化を受けられる。これはSnowflakeにとって守りでも単なる追従でもなく、 能動的な戦略カード として成立します。
| 機能 | Snowflake-managed Iceberg | Catalog-linked Iceberg |
|---|---|---|
| Automatic Clustering | 対応 | 未対応 |
| Search Optimization Service | 対応（半構造化・地理空間列除く） | 限定的 |
| Materialized View | 対応 | 限定的 |
| Optima Indexing / Metadata | 公式に明示されていない | 公式に明示されていない |
Iceberg側の自律化機能のカバー範囲はまだネイティブと完全には揃っていません。ここをOptimaで埋めにくる動きは、業界の流れの中で十分に説明がつくように思います。
第5部：Snowflakeの公約と、今後の予測
Snowflakeの公約と「ベクトル」の意味
4月30日のブログにこう書かれています。
Throughout the rest of the year, we will continue expanding Snowflake Optima to support even more complex expression types and introduce new autonomous optimization vectors.
公約は2方向です。
- 既存のOptima Metadataの 対象式の拡張
- 新しい自律最適化ベクトル の導入
公約1（対象式の拡張）は、REGEXP_LIKE、CAST、JSONパス参照などへの拡張として、今年中にほぼ確実に実現するでしょう。これは既存軸の深化なので、本記事ではこれ以上掘り下げません。
注目したいのは公約2、 「new autonomous optimization vectors」 の方です。Snowflakeが "vectors"（ベクトル）という表現を選んでいる点です。"features" や "capabilities" ではなく、 vector。これは「方向」や「軸」を意味する語で、新しい機能を1つ2つ足すという話ではなく、 新しい最適化の方向そのものを増やす というニュアンスを持ちます。
このレンズで現在のOptimaを見直すと、Indexing も Metadata も アクセスパス軸（プルーニング） という単一の軸の中で動いています。違いは「ポイントルックアップ向け」か「列式向け」かだけで、軸そのものは1本。「new autonomous optimization vectors」は 新しい軸への踏み出し を意味しています。
技術的・経済的に成立しうる新軸の候補を、フラットに洗い出します。
候補1：Optima Clustering
確度：★★（条件付き）
データ配置軸への踏み出し。観測 → 生成 → 適用 → 回収の汎用ループには乗ります。
- 自動クラスタリング（再クラスタリング）は既に自律的に動いている
- だがその入力であるクラスタリングキーは人間が選ぶ、という非対称な状態
- SOS → Optima Indexing と同じく、 既存の自動クラスタリングをラップする形 で実装される可能性
ただし第3部の経済モデルから見ると、無視できない課題があります。
- Automatic Clusteringはserverless課金されている：これを「無償化」するには収益モデルに穴が開く
- 失敗時のコスト：再クラスタリングは時間とコンピュートを消費する
- 回収の非対称性：インデックスやメタデータは消すだけで済むが、クラスタリングは物理的なデータ並び替えなので「やめる」コストが高い
来るとしても、 「キー推奨に留まる半自律」または「課金あり」 の形が現実的で、Optima Indexingと同じ「完全無償・完全自律」の形では出しにくいように思います。完全無償では難しいと思いつつも、これをブレイクスルーすると非常に大きな技術転換点になると考え、Snowflakeに期待も込めて、候補に挙げたいと思います。
候補2：Optima MV
確度：★
事前計算軸への踏み出し。観測 → 生成 → 回収のループ自体には乗りますが、
- MVはストレージ × 更新コンピュートの両方で継続的に課金される
- 元クエリの実行頻度とコストが十分に高くないと経済的に成立しない
- 収支判断はワークロード固有の経済性に依存しており、汎用的に自動判断するのは難しい
クラスタリングキーは「決まれば終わる設計判断」ですが、MVは「継続的な収支管理」が必要で、性格が違います。Optima軸として登場するとしても、候補1より相当に遅れると見ています。これもまた経済的価値を保証できるとすれば、ユーザーの最適化は一気に進むように思います。
候補3：Optima for Iceberg
確度：★★★
Iceberg対応をどう捉えるかは整理が必要です。単に既存機能をIcebergにも届かせる 「対象拡大」 であれば、それは新軸とは言いにくい。一方、Iceberg固有の構造（manifest file、snapshot、partition spec）を活用した Iceberg特有の最適化 であれば、それはネイティブテーブルには存在しない概念に対する自律最適化であり、 新しいvectorとして成立 します。
具体的に来そうなのは、
- Manifest pruning：Icebergのmanifest fileメタデータを使った自律的な高速プルーニング
- Partition spec aware optimization：Icebergのhidden partitioningを認識した自律最適化
- External writer-aware statistics：他エンジン（Spark、Trinoなど）が書いたファイルへの自律的な統計補完
- Catalog-linked optimization：外部catalogのメタデータと自律的に同期する最適化
これらはネイティブテーブルにはない概念で、Iceberg固有の最適化カテゴリ。新vectorとして打ち出せる素地があります。
経済モデルとの整合性も高い。第3部で見たとおり、Optimaの無償運用は 「軽量な補助構造」の対象機能で成立 しています。Iceberg対応の中身は manifest や statistics といったメタデータ操作が中心で、 物理データの書き換えを伴わない。SOSが既にIcebergに対応している事実を踏まえると、Optima IndexingがSOSラッパーとしてIcebergにも届くのは技術的に自然な延長で、 SOSとOptimaの同時対応として打ち出される ことが現実的です。
戦略的優先度も極めて高い。第4部で見たとおり、オープンフォーマット対応は業界の主戦場の一つで、Snowflakeはここで「ネイティブと同等の無償自律最適化」というカードを切れる位置にいます。Optima for Iceberg は、追従ではなく能動的な打ち手 として今年中に来てもおかしくないと考えています。
予測のまとめ
| 候補 | 経済モデル整合 | 新vector性 | 戦略的優先度 | 確度 |
|---|---|---|---|---|
| 候補1：Optima Clustering | △ | ◎ | ○ | ★★ |
| 候補2：Optima MV | × | ◎ | ○ | ★ |
| 候補3：Optima for Iceberg | ◎ | ○ | ◎ | ★★★ |
本命は候補3 になるのではないかと考えています。候補1、候補2もvectorとしては十分候補足り得ますが、完全無償の形にはなりにくく、経済モデルの課題が大きいと推測しています。
それを踏まえると、候補3は軸としての新規性、Snowflakeのオープンフォーマット戦略、そして「ネイティブと同等の自律最適化をIcebergにも届かせる」という打ち手の自然さを考えると、実に可能性が高いように思います。
ただ、そういう予想を超えてくるのがSnowflakeでもあり、全部リリースします！と突然言い出すのではないか？と妄想を膨らませています。
おわりに
候補のどれがどの順で来るかも楽しみですが、本質的な期待は別のところにあります。
前回記事で私は、自律化の進展がデータエンジニアの仕事を 「最適化のクラフトマンシップ」から「データ活用と品質向上」へ移していく と書きました。半年経った今、その方向への進捗は予想通りに進んでいると感じます。Optima Indexing、Optima Metadata、Adaptive Warehouseのパブリックプレビュー。アクセスパス軸とコンピュート軸の自律化が並行して進んでいて、ここに Iceberg軸が加わり、ネイティブとIcebergの両方が無償の自律最適化に包まれる ようになれば、フェーズ1はほぼ完成形です。
そこまで来れば、私たちのチームが時間を使う先は、 どのデータをどう活用するか、データの品質をどう担保するか、ビジネスとどうつなぐか という、本来やりたかった仕事の方に移っていきます。ジュニアは早い段階からデータの中身に向き合えるようになり、シニアは戦略的な判断に時間を使えるようになる。
とはいえ、Optimaの自律化はまだまだ点での着地。残り2026年、さらに進化していくはずで、今年の6月に開催される、Snowflake Summitでは、もっと驚くような新たな最適化機能の発表があるのではないかとワクワクしています。
（今年もSummit行けません！）
関連リンク
Snowflake データクラウドのユーザ会 SnowVillage のメンバーで運営しています。 Publication参加方法はこちらをご参照ください。 zenn.dev/dataheroes/articles/db5da0959b4bdd
Discussion