In Silico

データ基盤

Snowflake Well-Architectedとは？5つの柱で自分の判断を見直す

2026/11/2 （更新: 2026/11/3） シリーズ「Snowflake 入門」 第13回 / 全13回

🤖 AIを使用して執筆

シリーズSnowflake 入門全13回
  1. 第1回Snowflakeとは？仕組み・料金・使い方をわかりやすく解説
  2. 第2回Snowflakeのウェアハウスとは？サイズとクレジット・自動停止
  3. 第3回Snowflakeの料金の仕組みとは？計算・保存・転送とコスト管理
  4. 第4回Snowflake マイクロパーティションとは？プルーニングとクラスタリング
  5. 第5回Snowflake VARIANTとは？JSONを扱う半構造化データの仕組み
  6. 第6回Snowflake Time Travel（タイムトラベル）とは？保持期間と復元
  7. 第7回Snowflake レプリケーションとは？別リージョンに複製して切り替える
  8. 第8回Snowflake ロールとは？権限をロールに与えて階層で渡す仕組み
  9. 第9回Snowflake Dynamic Tablesとは？SELECTだけで結果の表を最新に保つ
  10. 第10回Snowflake データ共有とは？コピーせずに取引先と同じ表を使う
  11. 第11回Snowflake Icebergテーブルとは？同じデータを他のエンジンでも読む
  12. 第12回Snowflake Cortexとは？データを外に出さずにSQLでAIを使う
  13. 第13回Snowflake Well-Architectedとは？5つの柱で自分の判断を見直す

このシリーズの紹介へシリーズ一覧へ

  • Well-Architected
  • Snowflake
  • 5つの柱
  • Adaptive Compute
  • コストの最適化
  • 信頼性
  • パフォーマンス
  • オペレーショナルエクセレンス
  • セキュリティとガバナンス
  • レンズ
  • リソースモニター
  • 予算
  • 責任共有モデル
  • 囲い込み
  • データ基盤
目次
背景・問い・要点
背景

Snowflake の創業者らは、2016 年の論文で、利用者が調整するつまみは無いと書いた。同じ論文は、調整の項目は一つ、利用者がどれだけの性能を望み、いくら払うかだけだとも書いた1。実際には、ウェアハウスの大きさと止め方、データの並べ方、履歴を保つ期間、権限の組み方、データの形式のように、利用者が決めることがある。

Snowflake は、こうした判断を見直すための指針を、Well-Architected Framework として公開している2。2025 年 11 月には、Snowflake の技術者がブログでこの指針を紹介した3。

問い

Snowflake の Well-Architected Framework とは何か。

要点

Well-Architected Framework は、Snowflake の使い方を、セキュリティやコストなど 5 つの柱と 2 つのレンズで見直すための Snowflake の指針である。柱ごとの原則が、利用者が決める設定のどれを見るべきかを示す。

Snowflake が自動にするところが増えても、利用者が決めることは無くならない。問い合わせに合わせて計算資源を割り当てる Adaptive Compute でも、性能の上限と、費用の見張り方は利用者が決める。

モデル・例示

コストの最適化の柱で、アカウントを点検する

※ この節の例は、説明のために作った架空のものです。

Well-Architected Framework を使うと、困ったことが起きてから原因を探す代わりに、柱ごとの項目でアカウントを先に点検し、手を付けていなかった設定を見つけられる。ここでは、コストの最適化の柱で点検する場面を示す。

コストの最適化の柱は、見えないものは抑えることも最適にすることもできないとし、費用を見張る仕組みとして予算とリソースモニターを挙げる4。Snowflake の計算の費用は、クレジットという単位で数える5。予算は、月に使うクレジットの上限を決めておき、超えそうになると知らせる仕組みである。上限の値は知らせるためだけに使い、ウェアハウスを止めたいときは、利用者が定義した手順（ストアドプロシージャ）を予算に自動で呼ばせる6。リソースモニターは、決めた量のクレジットを使ったウェアハウスを止める仕組みである7。

柱で点検しないとき： あるチームは、データベースへの問い合わせ（クエリ）が遅いと、ウェアハウスを大きくしてきた。ウェアハウスは、問い合わせを動かす計算の単位で、大きさを一段上げると、動いている 1 時間あたりのクレジットがおよそ 2 倍になる5。費用がどれだけ増えたかは、月末の請求で初めて分かる。

  1. 管理者Snowflake1. 問い合わせが遅いので、ウェアハウスを大きくする
  2. Snowflake管理者2. 月末に、増えた費用を請求する
  3. 管理者3. 何が費用を増やしたのかを、後から探す

柱で点検するとき： Snowflake-Labs は、Snowflake の AI アシスタント Cortex Code（CoCo）に、アカウントを 5 つの柱で点検させるスキルを、GitHub で公開している。項目ごとに「順調」「改善が要る」「対応が要る」の 3 段で返す8。コストの最適化の柱には、アカウント全体の予算とは別に、ウェアハウスなどのまとまりを見張る予算が一つ以上あれば「順調」、一つも無ければ「対応が要る」とする項目がある9。

  1. 管理者Snowflake1. コストの最適化の柱の項目で、アカウントを点検させる
  2. Snowflake管理者2. アカウント全体の予算のほかに予算が無いので「対応が要る」と返す
  3. 管理者Snowflake3. ウェアハウスを対象に、月の上限を 1,000 クレジットにした予算を作る
  4. Snowflake管理者4. 月の途中で、上限を超えそうだと知らせる
  5. 管理者5. 月末の前に、何が費用を増やしたのかを調べる

違いは、何を確かめるかが、柱の原則から先に決まっていることである。管理者は、遅さという目の前の困りごとだけでなく、まだ表に出ていない費用の見張りにも、月末より前に手を付けられる。このスキルは、ほかの 4 つの柱にも同じように項目を持つ。ただし、網羅的な監査ではなく、結果は選んだモデルで変わりうると断っている8。

Well-Architected Framework とは：5 つの柱と 2 つのレンズ

Snowflake は、Well-Architected Framework を、Snowflake を大規模に使う企業のための、設計の標準としている。5 つの柱と、目的ごとのレンズからなり、柱とレンズは、それぞれ Snowflake の具体的な設定に結び付くとしている2。

5 つの柱は、セキュリティとガバナンス、オペレーショナルエクセレンス、信頼性、パフォーマンス、コストの最適化である10。レンズは、柱の指針を採ったうえで、特定の場面にだけ重ねて当てる指針である。AI とデータガバナンス、オープンと相互運用の 2 つがある211。

柱ごとの原則の一つと、利用者が決めることは、次のとおりである。

柱原則の一つと、利用者が決めること
セキュリティとガバナンスネットワーク、ID、ポリシーで守りの境界を作る12。ロールの組み方、多要素認証、ネットワークポリシー
オペレーショナルエクセレンス構成とパイプラインをコードで管理し、手作業をなくす13。取り込みと変換の作り方
信頼性障害は起きるものとして設計する14。Time Travel の期間、レプリケーション
パフォーマンス設計の前に、測れる性能の目標を決める15。データの並べ方、ウェアハウスの分け方
コストの最適化見えないものは、抑えることも最適にすることもできない4。大きさと止め方、予算、リソースモニター

信頼性とセキュリティの柱は、責任共有モデルを土台にしている。クラウドの事業者、Snowflake、利用者のそれぞれの責任を分ける考え方である14。セキュリティとガバナンスの柱は、勧めることを、利用者の責任の範囲に絞っている12。

2016 年の約束と、Adaptive Compute

Snowflake の創業者らの 2016 年の論文は、Snowflake の特徴の一つ目に、純粋なサービスとしての使い心地を挙げた。利用者が調整するつまみも、物理的な設計も、保存領域の管理もないとしている1。同じ論文は、つまみを避け続けた結果、調整の項目は一つ、利用者がどれだけの性能を望み、払うかだけになったと書いた1。

2020 年の Snowflake と Cornell 大学の論文は、2018 年 2 月の 14 日間に動いた約 7,000 万件の問い合わせの記録を分析した16。その 14 日間に、仮想ウェアハウスの 82% は、大きさを変える機能を一度も使っていなかった16。論文は、その理由を、利用者がシステムの中を見通せず、必要な量も見積もれないので、ウェアハウスの大きさを正しく変えられないからだと考えた16。論文は、データを取った後に自動の伸縮の改善が進んだと断ったうえで、一つの問い合わせの中での伸縮と、細かい課金を備えるサーバーレスに近い基盤を、次の課題に挙げた16。

Adaptive Compute は、問い合わせに合わせて資源を割り当て、利用者の調整を不要にするとしている17。仕組みの上では、論文が挙げた見積もりの難しさを、利用者から Snowflake へ移す形になっている。

ふつうのウェアハウスを Adaptive Warehouse に変えると、大きさ、クラスタの数、止め方は Snowflake が決める。利用者が決めるのは、一つの問い合わせの性能の上限と、同時に回せる量の倍率である。性能の上限は、XSMALL から X4LARGE までのウェアハウスの大きさの名前で表し、変えたときの最初の値は Snowflake が元の大きさなどから計算する17。費用は、ふつうのウェアハウスと同じく、予算とリソースモニターで見張る4。

Snowflake は、大きさや増やし方を自分で決めたいなら、Adaptive Warehouse に変えずに、第 2 世代（Gen2）の標準のウェアハウスを使うよう書いている17。Well-Architected Framework の柱のうち、Adaptive Compute を扱うのは、今のところコストの最適化の柱である4。

2016 年の論文が挙げた一つの調整の項目、どれだけの性能を望み、いくら払うかは、Adaptive Compute では、性能の上限と費用の見張り方として利用者が決めることになったと考えられる。ただし、同時に回せる量の倍率という二つ目の設定もあり、Snowflake は Adaptive Compute を 2016 年の論文の実現とは書いていない。

囲い込みの評価はまだ定まらず、予算の知らせは最大 6.5 時間遅れる

Snowflake の自動化が進んでも、Snowflake の資料自身が限界や注意を書いているところがあり、外の書き手が評価を保留しているところもある。

独自の形式とオープンな形式（囲い込み）： Snowflake の技術者は、2026 年のブログで、Snowflake は「壁に囲まれた庭」の典型と見られてきたと書いた22。2026 年 6 月には、新しい表を Apache Iceberg の形式で作るのを既定にできる設定が一般提供になった23。一方で、Snowflake のオープンと相互運用のレンズは、複数のエンジンで使う具体的な必要がないのにすべての表を Iceberg にすることを、避けるべきこととしている11。カーネギーメロン大学の Andy Pavlo は、Snowflake と Databricks の争いはデータベースのまわりの生態系に広がったとし、Iceberg の表のカタログである Polaris の採用がどう進み、互換を長く保てるかは、まだ分からないとした24。

費用の予測しやすさ： Snowflake の料金は、使った分だけ払う形である。予算は、月の上限を超えそうなときに知らせるが、既定では最大 6.5 時間ごとに見直される。見直しを 1 時間ごとに縮めることもでき、その場合は予算そのものの費用が 12 倍になる6。リソースモニターは、ウェアハウスにしか使えず、1 時間単位で厳密に抑えるためのものではない7。Snowflake のコストの最適化の柱は、リソースモニター、予算、割り当て、タグの組み合わせで、予算の予測しやすさを保てるとしている4。

出典24件

  1. Benoit Dageville ほか「The Snowflake Elastic Data Warehouse」SIGMOD 2016、2016年6月. https://info.snowflake.net/rs/252-RFO-227/images/Snowflake_SIGMOD.pdf — 1 節の特徴と、6 節の教訓。 ↩ ↩2 ↩3

  2. Snowflake「Well-Architected Framework」日付なし、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/product/use-cases/well-architected-framework/ ↩ ↩2 ↩3

  3. Marcin Kulakowski、Snowflake「Introducing the Snowflake Well-Architected Framework」2025年11月5日、2026年10月30日取得（アーカイブ、題と筆者と日付のみ）. https://www.snowflake.com/en/engineering-blog/well-architected-framework/ ↩

  4. Snowflake「Cost Optimization」2026年7月30日更新、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/developers/guides/well-architected-framework-cost-optimization-and-finops/ ↩ ↩2 ↩3 ↩4 ↩5

  5. Snowflake「Understanding compute cost | Snowflake Documentation」日付なし、2026年10月30日取得. https://docs.snowflake.com/en/user-guide/cost-understanding-compute ↩ ↩2

  6. Snowflake「Monitor credit usage with budgets | Snowflake Documentation」日付なし、2026年10月30日取得. https://docs.snowflake.com/en/user-guide/budgets ↩ ↩2

  7. Snowflake「Working with resource monitors | Snowflake Documentation」日付なし、2026年10月30日取得. https://docs.snowflake.com/en/user-guide/resource-monitors ↩ ↩2

  8. Snowflake-Labs「WAF Assessment」coco-skills、日付なし、2026年10月30日取得. https://github.com/Snowflake-Labs/coco-skills/tree/main/skills/well-architected-framework-assessment ↩ ↩2

  9. Snowflake-Labs「WAF Cost Optimization — 11 Controls」coco-skills、日付なし、2026年10月30日取得. https://github.com/Snowflake-Labs/coco-skills/blob/main/skills/well-architected-framework-assessment/references/controls/cost_optimization.yaml ↩

  10. Snowflake「SnowflakeのWell-Architected Framework」日付なし、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/ja/product/use-cases/well-architected-framework/ ↩

  11. Snowflake「Open and Interoperable Lens」2026年6月1日更新、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/developers/guides/interoperable/ ↩ ↩2

  12. Snowflake「Security & Governance Pillar」2026年6月17日更新、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/developers/guides/well-architected-framework-security-and-governance/ ↩ ↩2

  13. Snowflake「Operational Excellence」2026年6月17日更新、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/developers/guides/well-architected-framework-operational-excellence/ ↩

  14. Snowflake「Reliability」2026年6月17日更新、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/developers/guides/well-architected-framework-reliability/ ↩ ↩2

  15. Snowflake「Performance」2026年6月17日更新、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/developers/guides/well-architected-framework-performance/ ↩

  16. Midhul Vuppalapati ほか「Building An Elastic Query Engine on Disaggregated Storage」NSDI 2020、2020年2月、2026年10月30日取得. https://www.usenix.org/system/files/nsdi20-paper-vuppalapati.pdf ↩ ↩2 ↩3 ↩4

  17. Snowflake「Adaptive Compute | Snowflake Documentation」日付なし、2026年10月30日取得. https://docs.snowflake.com/en/user-guide/warehouses-adaptive ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  18. Snowflake「Jun 16, 2026: Adaptive Compute (General availability) | Snowflake Documentation」2026年6月16日、2026年10月30日取得. https://docs.snowflake.com/en/release-notes/2026/other/2026-06-16-adaptive-compute-ga ↩

  19. Snowflake「Adaptive Compute: Now GA Across Select AWS, Microsoft Azure and Google Cloud Regions」2026年、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/blog/adaptive-compute-ga-azure-google-cloud/ ↩

  20. Snowflake「適応型コンピューティング | Snowflake Documentation」日付なし、2026年10月30日取得. https://docs.snowflake.com/ja/user-guide/warehouses-adaptive — 2026 年 10 月時点でプレビューの説明のまま。 ↩

  21. Snowflake「Snowflake Service Consumption Table」2026年10月15日発効、2026年10月30日取得. https://www.snowflake.com/legal-files/CreditConsumptionTable.pdf ↩

  22. Michael Collado ほか、Snowflake「Apache Polaris Graduates to Top-Level Project」2026年2月19日、2026年10月30日取得（アーカイブ）. https://www.snowflake.com/en/blog/apache-polaris-top-level-project/ ↩

  23. Snowflake「June 5, 2026: Default metadata write format for Apache Iceberg™ tables (General availability) | Snowflake Documentation」2026年6月5日、2026年10月30日取得. https://docs.snowflake.com/en/release-notes/2026/other/2026-06-05-iceberg-default-metadata-format-ga ↩

  24. Andy Pavlo「Databases in 2024: A Year in Review // Blog // Andy Pavlo - Carnegie Mellon University」2025年1月1日、2026年10月30日取得. https://www.cs.cmu.edu/~pavlo/blog/2025/01/2024-databases-retrospective.html ↩

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。