Snowflakeでマネージド型データウェアハウス（DWH）を運用し、内部監査でSLA遵守状況の説明を求められるデータ基盤担当者が本稿の対象読者だ。数百〜数千人規模の情報システム部門で、保守運用をSIerに委託し、障害時の一次対応をベンダーの公式サポートに依存しているチームほど、今回の教訓は重い。2026年7月11日16時35分から18時10分（UTC）、Snowflakeの内部基盤で発生した障害により、仮想ウェアハウス（WH、クエリを処理する計算クラスター）の起動が遅延・失敗した[1]。原因はSnowflake内部の「バイナリダウンロードサービス」のリソース枯渇で、WH起動時に必要なソフトウェアコンポーネントを取得できなかったことによる[1]。既に稼働中だったWHへの影響は限定的だったが、新規起動と再開だけが狙い撃ちされた点が特徴だ。マネージドDWHの可用性は、クラウドプロバイダー側の障害だけでなく、ベンダー内部の見えない配信基盤にも左右される。本稿はこの障害を材料に、SLAが実際に何を保証し何を保証しないかを整理し、日本企業のデータ基盤担当が点検すべき項目を示す。
予備知識
- ウェアハウス（WH）: Snowflakeでクエリを処理する仮想の計算クラスター。停止中は課金されず、必要なときに起動（レジューム）する。
- SLA（サービスレベル契約）: ベンダーが保証する稼働率や対応時間の契約条件。違反時は原則クレジット（利用料相殺）で補償される。
- 単一障害点（SPOF）: そこが止まると全体の機能が止まり、代替経路がない構成要素。
- エスカレーション: サポート対応が不十分と判断した場合に、上位の担当・組織へ問題対応を引き上げる手続き。
ベンダー起因障害の一次切り分けとエスカレーション手順を、社内向けに文書化したい担当者向け。
2026年7月のWH起動遅延障害は何が起きたのか
Snowflake公式ステータスページの記録によれば、7月のWH起動障害は1件ではなく2週間の間に2件発生している。いずれも「稼働中のWH」ではなく「これから起動・再開するWH」だけを狙い撃ちにした障害だった。
1件目は7月11日16時35分〜18時10分（UTC）、原因は内部のバイナリダウンロードサービスにおけるリソース枯渇[1]。WH起動時に必要なソフトウェアコンポーネントの取得が遅延し、複数リージョンでWHの再開・管理に遅延や断続的な失敗が生じた[1]。Snowflakeは同日19時36分（UTC）までに修正を適用し、復旧を確認した[1]。
2件目は7月25日07時45分〜15時05分（UTC）、原因は特定リージョンでの需要急増によるネットワーク容量超過とIPアドレス枯渇[2]。WHの再開が不能になったり、サーバーレスタスクで数時間規模の遅延が生じた顧客がいた[2]。
| 項目 | 7月11日の障害 | 7月25日の障害 |
|---|---|---|
| 発生時刻（UTC） | 16:35〜18:10 | 07:45〜15:05 |
| 継続時間 | 約1時間35分 | 約7時間20分 |
| 一次的な原因 | バイナリ配信基盤のリソース枯渇[1] | ネットワーク容量超過によるIPアドレス枯渇[2] |
| 影響範囲 | WHの起動・再開の遅延と断続的失敗 | WH再開不能、サーバーレスタスクの遅延 |
| 稼働中WHへの影響 | 限定的[1] | 別途影響を受けたケースあり[2] |
2件とも顧客側の設定やクエリ内容には起因しない。マネージドDWHの内部で、コンピュートを立ち上げる配信・供給の仕組みそのものが詰まった事例と言える。
ベンダーSLAの数値をそのまま信用せず、自社の可用性目標をどう定義し直すか考えたい人向け。
マネージドDWHの見えない依存関係はどこにあるか
結論を先に書くと、WH起動は顧客からは見えない内部の配信レイヤーを経由しており、そこが詰まるとクエリ以前の段階で処理が止まる。利用者が普段意識するのは「SQLを投げる」「WHが動く」という2層だが、実際にはその間にコンピュートノードを立ち上げるための内部制御層が挟まっている。
この制御層には、起動対象のノードへ必要なソフトウェアやパッケージを配る仕組みが含まれる。7月11日はこの配信の仕組みが枯渇した例、7月25日はネットワーク側のIPアドレス割り当てが枯渇した例だった[1][2]。7月11日はSnowflakeが自社で運用する制御プレーン内部の要因だが、7月25日についてはSnowflake自身が公式更新で「サードパーティのクラウド基盤がプロビジョニング要求をスロットリングしている」と説明しており、基盤側の上限も絡んでいる[2]。共通するのは原因の所在ではなく、利用者からは見えない層で起きている点である。
マネージドサービスを選ぶ理由の一つは、この内部の複雑さを利用者から隠すことにある。裏を返せば、内部で何が単一障害点になっているかは契約上も技術文書上も開示されない。利用者側にできるのは、稼働中WHと新規起動WHで障害の影響が分かれ得るという前提を持ち、後者への依存度が高い処理（夜間バッチでのWH自動起動など）を洗い出しておくことになる。
主要システムをAzureのWest US（米国西部）リージョン単一に集約し、複数リージョンへの分散やDR（災害復旧）計画をまだ具体化していない企業のインフラ担当者は、この障害の技術的経緯を無視できない。2026年7月23日14時44分（U[…]
SnowflakeのSLAはWH起動遅延を保証しているか
SnowflakeのSLAは「クエリがエラーを返す割合」を基準にしており、遅くても最終的に成功した起動は補償対象に入らない可能性が高い。Snowflake公式のサポート方針及びサービスレベル契約（2024年7月31日更新版）は、SLAの「利用不可」を1分間隔のエラー率で定義している[3]。
具体的には、失敗操作（内部エラーを返した有効操作）を有効操作の総数で除いたものを「エラー率」と呼び、閾値を超えた1分間を「利用不可」として積算する[3]。サービスレベルは、エラー率閾値10%で測定した場合は月平均稼働率99.99%、閾値1%で測定した場合は99.9%と定義される[3]。
| 月平均稼働率 | エラー率閾値 | サービスレベルクレジット |
|---|---|---|
| 99.0%以上99.99%未満 | 10% | 日平均クレジットの1倍 |
| 99.0%以上99.9%未満 | 1% | 日平均クレジットの1倍 |
| 95.0%以上99.0%未満 | 1% | 日平均クレジットの3倍 |
| 95.0%未満 | 1% | 日平均クレジットの7倍 |
| しきい値 | 月間稼働率 | クレジット倍率 |
|---|---|---|
| 10%（エラー率10%超で「利用不可」と判定） | 99.0%以上99.99%未満 | 日平均クレジットの1倍 |
| 1%（エラー率1%超で「利用不可」と判定） | 99.0%以上99.9%未満 | 日平均クレジットの1倍 |
| 1% | 95.0%以上99.0%未満 | 日平均クレジットの3倍 |
| 1% | 95.0%未満 | 日平均クレジットの7倍 |
しきい値ごとに別の表なので、上2行は横並びに比較できるものではない(出典: Snowflake サポート方針及びサービスレベル契約 表4)[3]。
このSLAの構造上の弱点は、起動が「遅い」だけで最終的に成功した場合、内部エラーを返す「失敗操作」に該当しない可能性がある点だ。Snowflake自身も、業界標準のこのSLA閾値方式は「ユーザー体験の良い指標とは言えない」とし、クライアントライブラリの挙動までは捉えられない構造だと認めている[4]。WH起動遅延のような「遅いが失敗ではない」障害は、この隙間に落ちやすい。
Grafana Cloud（ログ・メトリクス・トレースを一括管理するSaaS型オブザーバビリティ基盤）は、多くの企業のSRE（サイト信頼性エンジニアリング）チームが本番監視の中核に据えているサービスである。2026年7月、このGrafan[…]
サポートエスカレーションは何時間で動くのか
SnowflakeのサポートはPremier（標準）とPriority（追加購入の上位版）の2階層があり、エラーの緊急度は4段階の定義に沿って顧客側が申告する[3]。24時間365日対応の範囲はこの階層によって違い、Premierでは緊急度1だけ、Priorityでは緊急度1と緊急度2の両方が24時間年中無休の対象になる[3]。
| プレミア(標準) | 優先(上位版) | |
|---|---|---|
| 緊急度1の初期対応目標 | 1時間 | 15分 |
| 緊急度2の初期対応目標 | 2営業時間 | 2時間 |
| 24時間年中無休の対象 | 緊急度1のみ | 緊急度1と緊急度2 |
| 上記以外の対応時間帯 | 緊急度2〜4は地域の営業時間内 | 緊急度3〜4は地域の営業時間内 |
緊急度2の目標値はどちらも「2」だが、プレミアは営業時間を数えるのに対し優先は実時間で数えるため、夜間・休日をまたぐと差が開く(出典: 同表2・表3)[3]。
緊急度1は「本サービスが完全に稼働不能」または「重要機能が代替手段なく利用不能」と定義され、Premierで1時間、Priorityで15分の初期対応目標がある[3]。緊急度2以下は営業時間内対応が基準で、Premierでは緊急度2が2営業時間、緊急度3が1営業日、緊急度4が2営業日という目安になる[3]。
7月11日の障害のように「起動は遅いが稼働中WHは動く」状態は、顧客側の申告次第で緊急度1にも2にもなり得る。緊急度2以下と判定された場合、対応は地域ごとの営業時間内に限られ、対応が遅いと判断すれば顧客はコミュニティ記載のエスカレーション手続きで経営陣への引き上げを求められる[3]。
日本のSIer保守契約とAPACサポート営業時間が生む対応の空白
同じ障害が日本企業で起きた場合、現象は同じでも初動の速さが変わる。Snowflakeのサポート方針では、緊急度2〜4のPremierサポートはアジア太平洋地域で「オーストラリア東部標準時間の6時〜18時、月〜金」を営業時間と定める[3]。日本時間に換算するとおおむね午前4時台〜16時台に相当する（サマータイムの有無で1〜2時間変動する）。
日本の業務時間は夕方以降も続くことが多く、Premierサポートの緊急度2〜4はこの換算で日本時間午後4時台以降、翌営業日扱いになりやすい。Premierでは緊急度1だけが24時間体制なので、緊急度1として申告できるかがその日の対応を左右する。Priorityを購入していれば緊急度2まで24時間対応に入るため、この境界が1段ずれる[3]。
| 論点 | 一般的な想定 | 日本企業で起きること |
|---|---|---|
| 障害の一次検知 | 情報システム部門が直接監視 | SIerの保守契約範囲内かをまず確認 |
| 緊急度の申告 | IT部門が即座に技術判断 | SIer経由での代行申告に時間がかかる場合がある |
| 営業時間内対応 | 自社の業務時間で完結 | APAC営業時間はAEDT基準で日本時間夕方以降が対象外になりやすい[3] |
| エスカレーション | 契約担当者が直接実施 | 保守契約の範囲外作業として追加調整が必要な場合がある |
IT部門の判断は、SIerとの保守契約でSnowflakeサポートへの一次申告と緊急度判定を誰がどの時間帯まで代行するのかを書面で確認することに絞られる。決裁側の判断は、Priorityサポートへの追加投資が、緊急度1未満の障害でも事業影響を持つ処理の範囲で費用に見合うかの検討に絞られる。
まとめ
SnowflakeのSLAはクエリのエラー率が基準で、遅いが最終的に成功するWH起動遅延は補償の対象から外れやすい[3][4]。7月に2週間で2件、WH起動・再開だけを狙い撃ちにした障害が発生したことは、内部配信基盤やネットワーク割当という見えない依存関係が実運用のボトルネックになり得ることを示す[1][2]。
IT部門担当者の次の一手は、夜間バッチなどWH自動起動に依存する処理を棚卸しし、起動失敗時のリトライやフォールバック手順を検証することだ。決裁側の判断材料は、Priorityサポートへの追加投資と、SIer保守契約における緊急度判定の代行範囲を、年内の契約更新のタイミングで見直すかどうかになる。
マネージドサービスは運用の手間を減らすが、内部の単一障害点を見えなくすることとは別問題だ。SLAの数値だけで安心せず、契約書の定義を一度読み直す価値がある。
よくある質問（FAQ）
Q. Snowflakeは今も障害が起きやすい状態か。
2026年7月には11日と25日にWH起動・再開に関わる障害が公式ステータスページに記録されている[1][2]。個々の障害は数時間以内に復旧しており、恒常的な不安定さを示す情報ではない。
Q. WHが起動できないとき、既存のクエリ結果には影響するか。
7月11日の障害では、既に稼働中だったWHへの影響は限定的とされている[1]。影響は主に新規起動・再開の遅延と断続的な失敗に及んだ。
Q. SLA違反のクレジットはどう請求すればよいか。
サービスレベル不達成が発生した暦月から21日以内に請求する必要がある[3]。クレジットは翌暦月の利用分と精算され、現金への交換はできない[3]。
