はじめに
snow connection test がエラーになったとき、それが「認証の問題」なのか「ネットワークの問題」なのか分からず困った——という方向けの記事です。Snowflake 公式の接続診断ツール SnowCD を使い、認証情報なしでネットワーク層だけを先に切り分ける方法をまとめます。
私はデータ基盤の運用保守に携わっており、主にバッチ処理まわりの保守や追加開発を担っています。
シリーズ第1回「Snowflake CLI で並列接続を安全に動かすための実践ガイド」では、snow connection test を使った接続確認まで触れました。今回はその続編として、snow connection test がエラーになったときに 「認証の問題か、ネットワークの問題か」を切り分ける ための公式ツール SnowCD（Snowflake Connectivity Diagnostic Tool） をまとめます。
結論から言うと、私は snow connection test が落ちたときの一次切り分けに SnowCD を使っています。SnowCD は認証情報なしでネットワーク層（DNS・TCP・OCSP）だけを検査してくれるため、「そもそも経路が通っているのか」を先に確定できます。ここが通っていれば認証設定を、通っていなければファイアウォールやプロキシを疑う、という順序で原因を絞り込めます。
SnowCDとは
SnowCD は、Snowflake が公式に提供する接続診断ツールです。SYSTEM$ALLOWLIST() または SYSTEM$ALLOWLIST_PRIVATELINK() 関数が返すホスト名とポートの一覧をもとに、Snowflake への接続経路を一連のチェックで検査します。検査結果は「All checks passed（正常）」か、「どのチェックが失敗したか＋対処の示唆」のいずれかで返ってきます（公式ドキュメント）。
公式ドキュメントでは、次のようなユースケースが挙げられています。
- 自動デプロイスクリプトへの組み込み
- Snowflake に接続するサービスをデプロイする前の事前チェック
- 新しいマシンを立ち上げたときの環境チェック
- 稼働中マシンへの定期チェック
なお SnowCD はステージ（一時データ置き場）への基本的な到達性は確認しますが、ステージには追加の認証が必要なため、HTTP レスポンスコードの厳密なチェックまでは行いません。公式も「SnowCD でステージへの到達を確認できたら、続けて PUT コマンドで実際にファイルを置けるか確認する」ことを推奨しています。SnowCD はあくまで一次切り分け、と捉えるのが正確です。
snow connection test との使い分け
| 観点 | snow connection test |
SnowCD |
|---|---|---|
| 目的 | 認証込みの疎通確認 | ネットワーク層の診断 |
| 認証情報 | 必要 | 不要 |
| 主なチェック | ログイン可否 | DNS / TCP / OCSP などの経路到達性 |
| 実行環境 | Snowflake CLI が必要 | 単体の実行ファイル |
| 向いている場面 | 設定後の動作確認 | インフラ起因の問題の切り分け |
💡 私のルーティンは、snow connection test でエラーが出たら、それが認証の問題かネットワークの問題かを分けるために SnowCD を回す、という流れです。
ℹ️ なお
snow connection test自体にも、--enable-diagオプションで診断レポートを出力する機能があります（公式）。CLI が入っている環境ではこちらも併用できますが、本記事では「CLI に依存せず単体で経路だけを見たい」ケースを想定して SnowCD を扱います。
インストール
SnowCD は SnowCD Download ページ から OS 別のパッケージを入手します。手順は公式の SnowCD ドキュメント に準拠します（バージョン番号やチェックサムは配布ページの最新値に読み替えてください）。
Windows
- Download ページから Windows 用インストーラ（MSI）をダウンロードする。
- MSI を Windows インストーラーで実行する。
- インストール先のディレクトリ（
snowcd.exeが置かれる場所）を環境変数PATHに追加すると、snowcdコマンドが通ります。
macOSやLinuxなどは公式をご確認ください。
使い方の手順
Step 1：allowlist を取得してファイルに保存する
SnowCD は、Snowflake が返す接続先ホスト一覧（allowlist）を入力として受け取ります。公式の手順は「Web インターフェースで SELECT SYSTEM$ALLOWLIST(); を実行し、結果をファイル（例 allowlist.json）に保存する」です。
-- 通常環境
SELECT SYSTEM$ALLOWLIST();
-- PrivateLink 環境
SELECT SYSTEM$ALLOWLIST_PRIVATELINK();
私は自動化フローに寄せたいので、手元では snow コマンドで取得してそのままファイルに落としています（前回の記事の続きで snow を使っているため）。
snow sql -q "SELECT SYSTEM\$ALLOWLIST()" --format json \
| jq -r '.[0]["SYSTEM$ALLOWLIST()"]' > allowlist.json
allowlist.json の中身は、公式ドキュメントの例ではこのような形式です（値はリダクト済み）。
[
{"type": "STAGE", "host": "<storage_location>.s3.<region_id>.amazonaws.com", "port": 443},
{"type": "SNOWSQL_REPO", "host": "<repository_name>.snowflakecomputing.com", "port": 443},
{"type": "OUT_OF_BAND_TELEMETRY", "host": "<telemetry_subdomain>.snowflakecomputing.com", "port": 443},
{"type": "OCSP_CACHE", "host": "ocsp.snowflakecomputing.com", "port": 80},
{"type": "OCSP_RESPONDER", "host": "ocsp.digicert.com", "port": 80}
]
ℹ️ 入力は JSON のほか CSV / TSV 形式も受け付けます。Web UI の結果をダウンロードする際に CSV / TSV を選んでもかまいません。
Step 2：snowcd を実行する
snowcd allowlist.json
Windows では snowcd.exe allowlist.json のように実行します。
Step 3：結果を確認する
すべてのチェックが通った場合は、検査したホスト数・チェック数とともに All checks passed が表示されます。
Performing 30 checks on 12 hosts
All checks passed
失敗した場合は、失敗したチェックごとに対象ホスト・ポート・種別・失敗したチェック内容・エラー・対処の示唆が表示されます。公式ドキュメントの例は次の形式です。
Check for 1 hosts failed, display as follow:
==============================================
Host: www.google1.com
Port: 443
Type: SNOWFLAKE_DEPLOYMENT
Failed Check: DNS Check
Error: lookup www.google1.com: no such host
Suggestion: Check your configuration on DNS server
⚠️ All checks passed 以外が出た場合、その Host と Port への経路がファイアウォールやプロキシで遮断されている可能性が高いです。表示されたホスト名・ポート・Suggestion をそのままインフラ担当に共有すると、確認依頼がスムーズになります。
PrivateLink 環境での注意点
⚠️ PrivateLink（AWS PrivateLink / Azure Private Link / Google Cloud Private Service Connect）を使っている場合は、必ず SYSTEM$ALLOWLIST_PRIVATELINK() を使ってください。通常の SYSTEM$ALLOWLIST() が返すのはパブリックエンドポイント向けのホストなので、PrivateLink 環境で使うと診断対象が実態とずれてしまいます。
SYSTEM$ALLOWLIST_PRIVATELINK() を使うと、SNOWFLAKE_DEPLOYMENT や OCSP_CACHE のホストが privatelink.snowflakecomputing.com を含むプライベート用のドメインで返ってきます。つまり「診断したいのはプライベート経路なのに、パブリックのホストを検査してしまう」事故を避けられる、ということです。どちらの関数を使うべきかは、自分のアカウントがプライベート接続を使っているかどうかで判断します（SYSTEM$ALLOWLIST_PRIVATELINK の公式ドキュメント）。
実体験：プロキシ起因の接続不良を切り分けた話
最後に、私が実際に SnowCD で助けられたケースを紹介します。
本記事では Snowflake CLI を使った例で説明しましたが、別の場面で .NET ドライバーを使った接続がうまくいかない ことがありました。
SnowCD で確認したところ、複数のチェックが失敗しており、その内容から 原因がネットワーク環境、またはプロキシサーバー側にある と切り分けられました。結果的には、プロキシ経由の接続だったため、プロキシ関連の接続パラメータの設定が必要でした。
「はじめに」で書いたとおり、SnowCD で「ネットワークの問題」と先に確定できたおかげで、原因究明と解決まで素早くたどり着けました。アプリ側（ドライバー）の設定をいくら見直しても解決しなかった問題が、経路の診断で一気に前進した好例でした。
まとめ
- SnowCD は 認証情報なしでネットワーク層（DNS / TCP / OCSP）だけを検査 する公式ツール。
snow connection testが落ちたときの一次切り分けに向く。 - 使い方は3ステップ。①
SYSTEM$ALLOWLIST()で allowlist を取得 → ②snowcd allowlist.jsonを実行 → ③結果を確認。 -
PrivateLink 環境では
SYSTEM$ALLOWLIST_PRIVATELINK()を使う。ここを間違えると診断対象がずれる。 - SnowCD はあくまで一次切り分け。ステージは到達確認止まりなので、最後は
PUTなどで実利用を確認する。
「ネットワーク → 認証」の順に確定させていくと、原因不明の「繋がらない」に振り回される時間をかなり減らせます。