Snowflake「Network policy does not allow this IP」エラーの原因と解決手順

Snowflake「Network policy does not allow this IP」エラーの原因と解決手順のサムネイル Snowflake
2026.05.22
この記事をシェアする𝕏B!FacebookLINEPocket

このエラーが出る時、原因はだいたい3パターン

朝イチでSnowsightを開いた瞬間、ログインボタンを押した先に赤い帯。あるいは、いつも通り走らせていたバッチがある日突然認証で弾かれる。エラー本文はだいたいこれです。

IP xxx.xxx.xxx.xxx is not allowed to access Snowflake. Contact your local security administrator.
Network policy does not allow this IP.

このメッセージを見て、まず疑うべき原因は3つしかありません。(1) 自分のグローバルIPが変わった、(2) ネットワークポリシーのALLOWED_IP_LISTに最新IPが入っていない、(3) 誰かが間違ったCIDRを上書きした。この記事ではこの3パターンを順番に切り分け、最短で復旧できる手順までまとめます。

Snowflakeで「Network policy does not allow this IP」エラーが発生する3つの原因を整理した図解。グローバルIP変更、ALLOWED_IP_LIST未更新、誤ったCIDR上書きという切り分けポイントとネットワークポリシーの評価フローを示した概要

エラーが起きる本当の理由

Snowflakeにはネットワークポリシーという仕組みがあり、アカウント全体・ユーザー単位・セキュリティ統合単位で接続元IPを制御できます。設定されたポリシーは認証より前段で評価されるため、パスワードもMFAもSSOも、IPで弾かれた時点で先に進めません。

注意したいのは、Snowflakeから見えるのは「クライアントのグローバルIP」だという点です。社内LANのプライベートIPではありません。VPNを経由していればVPNゲートウェイの出口IP、自宅から繋いでいればISPが払い出すIPが見えます。家庭用回線のIPは数日〜数週間で勝手に変わることもあり、昨日まで通っていたのに今日いきなり弾かれる、という現象の犯人はだいたいこれです。

もう一つ、エラーメッセージにIPが出力されていればその値こそがSnowflake側の認識しているIPです。VPNがフェイルオーバーして別ゲートウェイ経由に切り替わると、見慣れないIPが表示されることがあります。実務でSnowflakeを触っていると、「IPが社内のはずなのに違うセグメントから出ていた」という落とし穴を一度は踏むはずです。

原因切り分けチェックリスト

復旧を急ぐ前に、まずは事実関係を5秒で確定させます。

  • エラー文の末尾に表示されているIPアドレスをメモする
  • そのIPが自分の現在のグローバルIPと一致するか確認する (確認はブラウザで ifconfig.me を叩けば一発)
  • VPN/プロキシを使っているなら、今どのゲートウェイ経由か確認する
  • 同僚も同じエラーかをSlackで聞く (全員ならポリシー側、自分だけならクライアント側)
  • 直近で誰かが ALTER NETWORK POLICY を実行していないかQUERY_HISTORYで確認する

「自分だけ」「全員」の切り分けが最重要です。これで原因がほぼ半分絞れます。

パターン別の解決方法

パターン1: 自分のIPが変わっただけ

もっとも多いのがこれです。在宅勤務でルーターが再起動した翌日、IPがガラッと変わっているケース。この場合は新しいIPをALLOWED_IP_LISTに追加すれば終わりです。

SnowsightにACCOUNTADMINロールで入れる別経路の管理者がいるなら、その人に頼んで次のSQLを実行してもらいます。

-- 現在の設定を確認
SHOW NETWORK POLICIES;
DESC NETWORK POLICY my_policy;

-- 既存リストに新IPを足して上書き
ALTER NETWORK POLICY my_policy
  SET ALLOWED_IP_LIST = (
    '203.0.113.10/32',
    '203.0.113.11/32',
    '198.51.100.42/32'  -- 今日変わった自分のIPを追加
  );

ここでハマりがちなのが、SET ALLOWED_IP_LIST は完全上書きだという挙動です。差分追加ではないため、既存のIPを一つでも書き忘れると他の人が一斉に弾かれます。実行前に必ずDESCで現状をコピーしておくのが鉄則です。

パターン2: 自分も含めて全員ロックアウト

これが一番怖いやつです。ACCOUNTADMINを持つ管理者まで全員が同じネットワークポリシーで縛られていて、誰もログインできない状態。落ち着いてください、復旧経路はあります。

Snowflakeのサポート窓口に連絡すれば、ネットワークポリシーを一時的に解除してもらえます。連絡時はアカウント識別子(orgname-accountname)と、現象を起こした時刻を伝えるとスムーズです。社内に複数のACCOUNTADMINユーザーを作っておく、かつそのうち1人はネットワークポリシーを適用しない運用を組んでおくと、こうした事故を未然に防げます。

パターン3: ユーザー単位ポリシーが優先されている

意外と見落とされるのが、ネットワークポリシーにはアカウントレベルとユーザーレベルがあり、ユーザーレベルが優先される仕様です。

-- ユーザーに紐づくポリシーを確認
SHOW PARAMETERS LIKE 'NETWORK_POLICY' IN USER my_user;

-- ユーザー単位のポリシーを解除
ALTER USER my_user UNSET NETWORK_POLICY;

アカウント側のALLOWED_IP_LISTを正しく直したのにまだ弾かれる時は、ユーザー側に古い別ポリシーがくっついていないかを必ず疑ってください。

Snowflakeのネットワークポリシー階層を示す図解で、アカウントレベルよりユーザーレベルのNETWORK_POLICYが優先される仕様と、ALLOWED_IP_LISTの確認・解除手順をSnowsight操作前に整理したイメージ

Snowsightからの操作手順

SQLが苦手なら、SnowsightのUIからも編集できます。Admin → Security → Network Policies と辿り、対象ポリシーをクリックすると編集画面が開きます。Allowed IP addressesの欄にCIDR表記でIPを追加し、保存するだけです。

一点だけ気をつけたいのは、SnowsightのワークシートからALTER NETWORK POLICYを実行してロックアウトしてしまうと、Snowsight自体も再接続できなくなる、ということ。編集はブラウザを開きっぱなしのまま、別タブで動作確認するのが安全です。タブを閉じてしまうと数十分後にセッションが切れ、戻る手段が消えます。

再発防止の運用Tips

一度踏むと地味に響くエラーなので、こんな運用を仕込んでおくと安心です。

  • 緊急用ACCOUNTADMINユーザーを1人別出しし、そのユーザーにはネットワークポリシーを適用しない (パスワードは金庫に)
  • 家庭用IPで運用しているメンバーには固定IPのVPNを経由してもらう
  • ポリシー変更前にDESC NETWORK POLICYの出力を必ずどこかにコピペしておく
  • 監査の意味でも、誰がいつポリシーを変更したかをSnowflakeの監査ログ(Account Usage / Information Schema)で追えるようにしておく
  • ログイン失敗が止まらないときは、MFA・IP・SSOの切り分けガイドを上から順にチェック

あと小ネタですが、エラー画面に表示される対象オブジェクト名は大文字に化けて見えることがあります。my_policyで作ったつもりが画面ではMY_POLICY。Snowflakeの識別子は引用なしで作ると自動で大文字になる仕様なので、驚かなくて大丈夫です。

まとめ

「Network policy does not allow this IP」は、クライアント側のグローバルIPの変化とALLOWED_IP_LISTの設定漏れの合わせ技でほぼ説明がつきます。エラー本文に書かれているIPと、現在の自分のIPを照合するところから始めれば、迷うことはありません。万一全員ロックアウトしてもサポート経由で戻せるので、慌てず緊急ユーザーの整備を進めておきましょう。

参考リンク

関連記事

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