Snowflake「Statement reached its statement timeout」エラーの原因とタイムアウト調整方法

Snowflakeの「Statement reached its statement timeout」エラー解説アイキャッチ。発生原因とSTATEMENT_TIMEOUT_IN_SECONDSパラメータによるタイムアウト調整方法を初心者向けに整理した技術解説のビジュアル Snowflake
2026.05.20
この記事をシェアする𝕏B!FacebookLINEPocket

はじめに:そのクエリ、途中で打ち切られていませんか?

こんにちは!Snowflakeで分析クエリを走らせていたら、突然こんなエラーが出てびっくりした経験はありませんか?

Statement reached its statement timeout of 3600 seconds and was canceled.

これは「クエリが制限時間に達したので、Snowflake側で強制的にキャンセルされましたよ」というお知らせです。クエリ自体が壊れているわけではないため、対処法を知っていれば落ち着いて解決できます。この記事では、初心者の方に向けて原因の見極め方とタイムアウト値の調整方法をやさしく解説していきます。

そもそもステートメントタイムアウトとは?

Snowflakeには、1つのSQL文(ステートメント)が実行できる最大時間を決める STATEMENT_TIMEOUT_IN_SECONDS というパラメータがあります。デフォルトは 172800秒(=48時間) ですが、アカウント・ウェアハウス・セッション・ユーザーの各レベルで上書き設定が可能です。

ウェアハウスに設定されている値とセッションに設定されている値のうち、小さい方の値が適用されるルールになっています。たとえばウェアハウス側で 3600秒(=1時間)に絞られていれば、セッションでいくら大きく設定してもクエリは1時間で打ち切られます。

SnowflakeのSTATEMENT_TIMEOUT_IN_SECONDSにおける適用ルールを示す図解で、ウェアハウス側とセッション側に設定された値を比較し、小さい方の秒数がクエリの強制キャンセル時間として採用される仕組みを矢印で表現

よくある原因3パターン

1. クエリ自体が重い・非効率

JOINの組み方が悪い、巨大テーブルにフィルタが効いていない、ウィンドウ関数が膨大な行に対して走っている、などが典型例です。

2. ウェアハウスサイズが小さすぎる

XSウェアハウスで数十億行のスキャンを走らせると、計算リソース不足でいつまでも終わりません。

3. タイムアウト値が短く設定されている

運用都合で「暴走クエリを早めに止めたい」とウェアハウス側に短いタイムアウトを設定しているケースもあります。

現在のタイムアウト値を確認しよう

まずは今いくつに設定されているかを確認しましょう。Snowsightのワークシートで以下を実行します。

-- セッションレベル
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN SESSION;

-- ウェアハウスレベル
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN WAREHOUSE MY_WH;

-- アカウントレベル
SHOW PARAMETERS LIKE 'STATEMENT_TIMEOUT_IN_SECONDS' IN ACCOUNT;

タイムアウト値を調整する方法

たとえば「このセッションだけ30分まで延長したい」場合は、次のように一時的に変更できます。

-- セッションのみ:1800秒 = 30分
ALTER SESSION SET STATEMENT_TIMEOUT_IN_SECONDS = 1800;

-- ウェアハウス単位で変更したい場合
ALTER WAREHOUSE MY_WH SET STATEMENT_TIMEOUT_IN_SECONDS = 3600;

ただし、安易に延ばすとコストが膨らみます。長時間動かすほどクレジット消費は増えていくので、まずはクエリ改善やウェアハウスのスケールアップを試してから、それでも足りない場合に延長するのが鉄則です。

SnowflakeでALTER SESSIONやALTER WAREHOUSEを用いてSTATEMENT_TIMEOUT_IN_SECONDSを1800秒や3600秒に変更し、タイムアウト調整とクレジット消費のバランスを検討するイメージを示す図解

クエリ側から見直すアプローチ

タイムアウトを延ばす前に、まずは原因の切り分けをしてみましょう。Snowsightのクエリ履歴(Query History)からプロファイルを開くと、どのステップで時間を食っているか視覚的にわかります。

  • スキャン行数が多すぎないか?(WHERE句の見直し、クラスタリングキー追加)
  • JOINのカーディナリティ爆発が起きていないか?
  • 大量のRemote Disk I/Oが発生していないか?(キャッシュ活用、ウェアハウスサイズ拡大)

具体的なチューニング手順については、Snowflakeクエリ最適化ベストプラクティス10選もあわせてご覧ください。同時実行クエリが多くて詰まる場合は、マルチクラスタウェアハウスの検討も有効です。

Snowsightのクエリ履歴からプロファイルを開きStatement timeoutが発生したクエリの実行ステップごとの所要時間やスキャン行数、JOINのカーディナリティ、Remote Disk I/Oを確認しボトルネックを切り分けるチューニング画面のスクリーンショット

注意したいポイント

  • キュー待機にも別パラメータがある: 実行待ち時間の上限は STATEMENT_QUEUED_TIMEOUT_IN_SECONDS で制御されます。混同しないように気をつけましょう。
  • 長時間クエリはコストに直結: タイムアウトを延ばす場合は、ウェアハウス使用状況の可視化でクレジット消費を必ずモニタリングしてください。
  • 本番運用ではアカウント単位で適切な上限を: 暴走クエリ対策として、アカウントレベルで現実的な値(例: 7200秒)に絞っておくと安全です。

まとめ

「Statement reached its statement timeout」エラーは、クエリの限界時間に到達してSnowflakeが安全装置を働かせた結果です。まずは SHOW PARAMETERS で現在値を確認 し、必要に応じて ALTER SESSION / ALTER WAREHOUSE で調整、そして根本的にはクエリやウェアハウスの見直しを行うのが王道です。タイムアウトは敵ではなく、コストと品質を守ってくれる味方だと思って、上手に付き合っていきましょう!

参考リンク

関連記事

この記事をシェアする𝕏B!FacebookLINEPocket