Snowflake にログインできなくなった経験は、私自身もこれまでに何度かありました。原因の多くはパスワード以外の場所にあり、特に MFA・IPアドレス制限・SSO まわりは「Snowflake 固有の落とし穴」と呼べる挙動があります。データエンジニアとして6年触ってきた中で、深夜に SSO が壊れて慌てた経験も、出張先の Wi-Fi だけ弾かれた経験もあります。ここでは Snowflake にログインできない時に確認すべき原因を、発生頻度の高い順に切り分け、コマンド・画面操作・管理者向け対処までまとめて解説します。
結論早見表 — 症状別 → 確認すべき項目
急いでいる方のために、まず症状から原因の当たりを付ける早見表を置きます。Snowflake のログイン障害は、出ている画面・エラーメッセージで原因系統がほぼ決まるため、ここで該当する行のセクションへ飛んでください。
| 症状 / エラー文言 | 疑うべき系統 | 担当セクション |
|---|---|---|
| Incorrect username or password | パスワード / 期限切れ / ユーザー名(LOGIN_NAME)違い | ケース1 |
| パスワードは合うのに通らない / Duo通知が来ない | MFA(多要素認証)系 | ケース2 |
| IP address is not allowed to access Snowflake | ネットワークポリシー / IPアドレス制限 | ケース3 |
| SAML エラー / IdP リダイレクト失敗 / User does not exist or has been deactivated | SSO(SAML2 連携) | ケース4 |
| User account is locked / Your user account has been disabled | アカウントロック / ユーザー無効化 | ケース5 |
| Authentication token has expired | SDK/コネクタのトークン期限切れ | ケース6 |
| ログインは通るがクエリが出ない / No active warehouse selected | ロール / ウェアハウス系(別問題) | 関連: 権限切り分け記事 |
大きく分けると、ログイン画面でエラーが出るか、認証は通るのにその先で詰まるかで方向性が分かれます。前者は本記事で扱うケース1〜6、後者はロールやウェアハウス権限の問題で、こちらは別の切り分けが必要になります。
ケース1: パスワードが間違っている / 期限切れ
最も発生頻度が高いのがパスワード起因のエラーです。Web コンソール(Snowsight)で「Incorrect username or password.」と赤帯が出る場合、ほぼここに該当します。
ユーザー名(LOGIN_NAME)とアカウント名は別物
初心者がつまずきやすいのは、Snowflake のログインに 3 つの要素が必要な点です。アカウント識別子(例: xy12345.ap-northeast-1.aws)、ユーザーのログイン名(LOGIN_NAME)、パスワードの 3 点セットで、このうち LOGIN_NAME はメールアドレスとは限らず、管理者が作成時に設定した文字列です。SHOW USERS の login_name カラムが正解で、name カラム(=ユーザー名)とは別物として扱われます。
パスワード期限切れの落とし穴
Snowflake のパスワードはデフォルトで 90 日後に失効します。期限が切れると次回ログイン時にパスワードリセット画面に飛ばされ、新しいパスワードを設定するまで先に進めません。久しぶりにログインしようとして弾かれる場合、ほぼこの 90 日タイマーに引っかかっています。
管理者によるパスワードリセット手順
セルフサービスのリセットメールが届かない時は、SECURITYADMIN ロールを持つ管理者が直接書き換えます。次のような形です。
-- 管理者(SECURITYADMIN以上)で実行
USE ROLE SECURITYADMIN;
-- 一時パスワードを設定し、初回ログイン時に強制変更させる
ALTER USER taro_yamada
SET PASSWORD = 'TempPass!2026'
MUST_CHANGE_PASSWORD = TRUE;
-- 設定確認
DESC USER taro_yamada;
-- 期待出力(抜粋):
-- property value
-- --------------------------- --------------
-- MUST_CHANGE_PASSWORD true
-- PASSWORD_LAST_SET_TIME 2026-05-10 ...
-- DISABLED false確認用の SQL として、SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY ビューで直近の失敗理由を見るのも有効です。監査ログまわりの全体像は Snowflake 監査ログ入門 でまとめています。
-- 直近24時間で自分のログインが失敗した理由を一覧化
SELECT event_timestamp,
user_name,
client_ip,
reported_client_type,
is_success,
error_code,
error_message
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE user_name = 'TARO_YAMADA'
AND event_timestamp > DATEADD(hour, -24, CURRENT_TIMESTAMP())
ORDER BY event_timestamp DESC;
-- 期待出力例:
-- ... | NO | 390101 | Incorrect username or password.
-- ... | NO | 390114 | Authentication token has expired.ケース2: MFA(多要素認証)が原因
パスワードは正しいのに通らない、入力後に固まる、Duo Mobile に通知が来ない場合は MFA 系を疑います。Snowflake の MFA は Duo Security と統合されており、ユーザー側で EXT_AUTHN_DUO = TRUE が立っていると、パスワード認証後に Duo のプッシュ通知またはコード入力が求められます。基本設計は Snowflake MFA と SSO 設定入門 も参照してください。
確認手順 — Duo・端末・時刻
切り分けは以下の順で進めます。Duo Mobile アプリが起動しているか、機内モードや「おやすみモード」で通知が止まっていないか、スマートフォンの時刻が NTP 同期されているか(TOTP コードは時刻ずれに弱い)、機種変更でデバイスが変わっていないか。とくに新端末への移行直後にトラブルが多発します。
管理者による MFA 解除コマンド
ユーザー本人がデバイスを失った時は、管理者が一時的に MFA を無効化して再登録させる流れになります。
-- 管理者で実行(MFA を一時的にバイパス)
USE ROLE SECURITYADMIN;
ALTER USER taro_yamada SET DISABLE_MFA = TRUE;
-- ユーザーが再ログインし、Snowsight 右上のプロフィール → MFA Setup から再登録
-- 再登録完了を確認したら、管理者側で再度 MFA を有効化
ALTER USER taro_yamada SET DISABLE_MFA = FALSE;
-- 一時的にロックアウトを解除する用途
ALTER USER taro_yamada SET MINS_TO_BYPASS_MFA = 30;
-- 期待動作: 30分間だけ MFA を要求せずパスワードのみで通せるMFA バイパスコードはどう取得しますか?
Snowflake には MINS_TO_BYPASS_MFA プロパティがあり、これを管理者がセットすると指定分数だけ MFA を一時バイパスできます。ユーザー自身に「ワンタイムのバイパスコード」を渡す仕組みではなく、あくまで管理者がアカウント単位でバイパス時間を切り替える設計です。緊急時は数十分単位で切って、再登録が終わり次第ゼロに戻す運用が安全です。
ケース3: ネットワークポリシー / IPアドレス制限に弾かれている
「自宅やオフィスからは入れるのに、出張先・カフェ・別の VPN だけ弾かれる」場合、ほぼ ネットワークポリシー による IP アドレス制限が原因です。エラーには IP address X.X.X.X is not allowed to access Snowflake. のようなメッセージが出ます。設定の基礎は Snowflake ネットワークポリシー入門 も合わせてどうぞ。
ネットワークポリシー設定の確認方法
アカウントレベル・ユーザーレベルの両方で設定できるため、両側を見る必要があります。
| 確認したいこと | SQL | 見るべき項目 |
|---|---|---|
| 登録済みポリシー一覧 | SHOW NETWORK POLICIES; |
name, created_on |
| アカウントに紐付くポリシー | SHOW PARAMETERS LIKE 'NETWORK_POLICY' IN ACCOUNT; |
value 列 |
| ユーザーに紐付くポリシー | SHOW PARAMETERS LIKE 'NETWORK_POLICY' IN USER taro_yamada; |
value 列 |
| ポリシーの中身(IP一覧) | DESC NETWORK POLICY corp_default; |
ALLOWED_IP_LIST / BLOCKED_IP_LIST |
-- 管理者で実行: 出張先のIPを暫定的に追加する
USE ROLE SECURITYADMIN;
-- 既存ALLOWEDの一覧を確認
DESC NETWORK POLICY corp_default;
-- 期待出力例:
-- name value
-- ALLOWED_IP_LIST 203.0.113.0/24,198.51.100.10
-- BLOCKED_IP_LIST (空)
-- 出張先IPを追加(既存リストを必ず引き継ぐ)
ALTER NETWORK POLICY corp_default
SET ALLOWED_IP_LIST = ('203.0.113.0/24','198.51.100.10','192.0.2.45');
-- 反映確認
DESC NETWORK POLICY corp_default;ALLOWED_IP_LIST は完全上書きで、過去の値はマージされない点に注意してください。差分追加のつもりで実行すると、それまで許可していた拠点が落ちます。
自分の IP がどれか分からない時の確認方法は?
クライアント側で「いま Snowflake に見えている自分の IP」を知りたい場合、ブラウザで https://ifconfig.me や https://api.ipify.org を開けば確認できます。VPN を使っているなら、VPN 接続後 / 切断後で値が変わるか比較してください。Snowflake 側のログで見たい場合は、認証成功時の LOGIN_HISTORY.client_ip がそのまま記録されているので、過去入れた時の IP を逆引きできます。
-- 直近成功ログインで使われた自分のIPを調べる
SELECT event_timestamp, client_ip, reported_client_type
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE user_name = CURRENT_USER()
AND is_success = 'YES'
ORDER BY event_timestamp DESC
LIMIT 5;ケース4: SSO(シングルサインオン)経由で失敗
SAML2 連携で IdP(Okta、Entra ID、Google Workspace など)を経由するログインは、便利な反面、IdP 側の設定変更でいきなり全社が入れなくなる事故が起きます。「Snowsight のログイン画面で SSO ボタンを押したら IdP に飛ばず白画面」「リダイレクト後に User does not exist or has been deactivated」が代表的な症状です。
SECURITY INTEGRATION の状態を見る
SSO 障害は、Snowflake 側のセキュリティインテグレーションが ENABLED = false になっている、IdP 側で証明書がローテーションされて Snowflake に登録された証明書と不一致、IdP 側で Snowflake への AppAssignment が外れた、のいずれかで起きます。確認は次の SQL です。
| 確認したいこと | SQL | 見るべき項目 |
|---|---|---|
| 登録済みインテグレーション一覧 | SHOW SECURITY INTEGRATIONS; |
name, type, enabled |
| SAML設定の中身 | DESC SECURITY INTEGRATION my_saml; |
SAML2_ISSUER, SAML2_SSO_URL, SAML2_X509_CERT |
| ユーザーのログイン名 | SHOW USERS LIKE 'taro%'; |
login_name, email, disabled |
-- 管理者で実行: SSO設定の健康状態を確認
USE ROLE ACCOUNTADMIN;
SHOW SECURITY INTEGRATIONS;
-- 期待出力例:
-- name type enabled comment
-- MY_SAML SAML2 true Okta SSO
DESC SECURITY INTEGRATION MY_SAML;
-- 期待出力(抜粋):
-- property value
-- ENABLED true
-- SAML2_ISSUER http://www.okta.com/exk...
-- SAML2_SSO_URL https://example.okta.com/app/.../sso/saml
-- SAML2_X509_CERT MIID....(IdPの証明書)
-- SAML2_SNOWFLAKE_ACS_URL https://xy12345.ap-northeast-1.aws.snowflakecomputing.com/fed/loginIdP が返してくる NameID と Snowflake ユーザーの LOGIN_NAME または EMAIL が一致していないと「User does not exist or has been deactivated」を返します。メールアドレス一字違いや、大文字小文字の差で落ちることが多々あります。
SSO が壊れた時に管理者が緊急で入る方法は?
SSO 経由ログインが死んでいても、Snowflake の標準ログイン経路(LOGIN_NAME + パスワード)は別経路として生きています。手順としてはブラウザで Snowsight URL を開き、画面の「Sign in using a different method」または「Use your password」リンクを押すと、SSO ボタンを迂回してパスワード認証画面に遷移できます。さらに直接 URL でアクセスする場合は https://<account>.snowflakecomputing.com/console/login にアクセスし、LOGIN_NAME とパスワードでサインインします。このため SSO を有効化する時も、最低 1 名はパスワード+MFA で入れる ACCOUNTADMIN を残しておくのが鉄則です。
ケース5: アカウントロック / ユーザー無効化
User account is locked. や Your user account has been disabled. が出る場合は、ユーザーオブジェクト側に何かフラグが立っています。状態は SHOW USERS で 1 行見れば分かります。
-- 管理者で実行: ユーザーの状態を1行で確認
USE ROLE SECURITYADMIN;
SHOW USERS LIKE 'TARO_YAMADA';
-- 期待出力(抜粋):
-- name disabled locked_until_time days_to_expiry has_password
-- TARO_YAMADA false 2026-05-10 14:22:00.000 UTC null true
-- 解除: ロック解除
ALTER USER taro_yamada UNLOCK;
-- 解除: 無効化フラグ解除
ALTER USER taro_yamada SET DISABLED = FALSE;
-- 解除後の再確認
DESC USER taro_yamada;LOCKED_UNTIL_TIME は連続失敗時に自動セットされる時刻で、その時刻を過ぎれば自然解除されます。すぐ通したい場合は UNLOCK で即時解除できます。DISABLED = TRUE は管理者が明示的に無効化した状態で、退職処理や長期休暇の運用フラグとして使われることが多いです。
ケース6: SDK / コネクタからのトークン期限切れ
Web ブラウザでは入れるのに、Python の snowflake.connector や JDBC/ODBC から繋ぐと Authentication token has expired. The user must authenticate again. が返ってくるパターンです。Python コネクタの基本は Snowflakeコネクタ Python 入門 でも触れています。
| クライアント | トークンの寿命 | 切れた時の挙動 |
|---|---|---|
| Python connector(Session token) | 4時間で expire / Master 4日 | 同コネクション再利用時に上記エラー。conn.close() 後に再 connect |
| JDBC | 同上(Session 4h / Master 4d) | 長時間アイドルのコネクションプールで頻発 |
| ODBC | 同上 | BI ツールから繋ぎっぱなしのダッシュボードで朝一エラー |
| OAuth(External) | IdP 設定に従う(短い) | refresh token の取り直しが必要 |
-- Python例: トークンが切れたら再connectする最小実装
import snowflake.connector
def get_conn():
return snowflake.connector.connect(
user='TARO_YAMADA',
password='...' ,
account='xy12345.ap-northeast-1.aws',
warehouse='WH_DEV',
role='ANALYST',
)
conn = get_conn()
try:
cur = conn.cursor()
cur.execute('SELECT CURRENT_TIMESTAMP()')
print(cur.fetchone())
except snowflake.connector.errors.ProgrammingError as e:
if e.errno == 390114: # Authentication token has expired
conn = get_conn() # 取り直して継続長時間動かすバッチや常駐サービスでは、パスワード認証より キーペア認証(JWT) や OAuth、あるいは比較的新しい PAT(Programmatic Access Token) を使うほうが運用が楽です。キーペア認証は秘密鍵でトークンを毎回生成するため、セッション切れの再ログインフローを実装する必要がなくなります。
最短デバッグ手順チェックリスト
原因不明で詰まった時は、上から順に潰すと 5 分で原因系統が絞れます。
- Web コンソール(Snowsight)から入れるか確認する。Web で入れるなら認証情報自体は生きており、問題はクライアント側(SDK / コネクタ / トークン期限)に切り分けられます。
- Web も入れない場合、別ネットワーク(モバイル回線テザリング)から試す。これで入れたら IP / ネットワークポリシー側、入れなければ認証情報側です。
- 管理者に
SHOW USERS LIKE '...'を叩いてもらい、disabled/locked_until_time/has_password/days_to_expiryを確認する。 - 該当ユーザーの
NETWORK_POLICYパラメータと、紐付くポリシーのALLOWED_IP_LISTをDESC NETWORK POLICYで確認する。 - MFA を一時的に
DISABLE_MFA = TRUEで外して切り分け、原因が MFA 側か、純粋なパスワード側か分離する。原因確定後は必ず元に戻す。
FAQ — Snowflake ログインできない時のよくある質問
Snowflakeのパスワード期限は何日ですか?
デフォルトは 90 日です。アカウントパラメータ PASSWORD_POLICY またはユーザーへ PASSWORD POLICY オブジェクトを割り当てることで変更でき、最大日数や履歴再利用禁止数を細かく指定できます。期限を 0(無期限)にすることも技術的には可能ですが、後述の予防策セクションの理由から推奨しません。
Snowflakeにログインできない時、まず何を確認すればいいですか?
第一に Web コンソールから入れるかを確認し、第二に別ネットワークから試します。この 2 ステップだけで「認証情報の問題」「ネットワーク制限の問題」「クライアント側の問題」のどこに原因があるか、ほぼ三択まで絞れます。エラーメッセージの英文を完全一致でコピペし、本記事の早見表に当てはめると最短です。
MFAコードが届かない時はどうすればいいですか?
Duo Mobile アプリ起動・通知許可・端末時刻同期を順に確認し、機種変更直後ならデバイス再登録が必要です。管理者に依頼して ALTER USER ... SET MINS_TO_BYPASS_MFA = 30; で一時バイパスをかけてもらうと、再登録の作業時間を確保できます。
SSO が使えない時、ローカルパスワードで入る方法はありますか?
ユーザーに HAS_PASSWORD = true が立っていれば、SSO 画面の「Use your password」リンクや、コンソール直接 URL からパスワード認証で入れます。SSO 専用ユーザー(パスワード未設定)の場合はこの経路が使えないため、緊急時は管理者にパスワードを発行してもらう必要があります。
管理者(ACCOUNTADMIN)もログインできなくなった場合は?
別の ACCOUNTADMIN ロールを持つユーザーがいれば、そちらから ALTER USER で復旧できます。誰一人入れない状態になった場合は Snowflake サポートへの問い合わせが必要で、契約者本人確認の上での復旧手続きとなります。これを避けるため、緊急用の ACCOUNTADMIN を 1 名別途確保しておく運用が鉄則です。
VPN を使うとログインできないのはなぜですか?
ネットワークポリシーの ALLOWED_IP_LIST に、その VPN の出口 IP が登録されていないためです。VPN は IP が変わる場合があるため、レンジ(CIDR)で許可するのが運用的に楽です。逆に、VPN 接続を必須にしてオフィス回線・自宅 IP は外す、というポリシーも取れます。
パスワードリセットメールが届かない時はどうすればいいですか?
ユーザーオブジェクトに登録された EMAIL が古い、または受信側の迷惑メールフィルタに弾かれているケースがほとんどです。DESC USER で email を確認し、間違っていれば ALTER USER ... SET EMAIL = '...'; で更新後にもう一度リセットを実行します。
一定回数失敗するとロックされますか?
はい。連続して認証失敗が続くと LOCKED_UNTIL_TIME が自動セットされ、一定時間ログインできなくなります。時刻経過で自然解除されますが、急ぐ場合は管理者が ALTER USER ... UNLOCK で即時解除できます。
私が普段やっているログイン関連の予防策
パスワード期限を 90 日 → 無期限に変更しない。 「面倒だから」で無期限化したくなりますが、漏えい時の被害が止まらなくなるため、私はこのデフォルトを動かさない方針で運用しています。期限切れは事故ではなく、設計上の安全装置だと割り切ります。
MFA は必ず複数デバイスに登録する。 スマートフォン 1 台だけに紐付けていると、機種変更や紛失で一気にロックアウトされます。私が Snowflake にログインする時は、メイン端末の Duo に加えて、ハードウェアトークン(YubiKey 等)もしくは予備端末を必ずセカンダリとして登録しておきます。
緊急用 ACCOUNTADMIN を 1 名別に確保しておく。 普段使いの管理者アカウントとは別に、SSO に依存せず・パスワード+MFA で入れる「壊れた時専用」のアカウントを作り、認証情報は金庫的な場所に厳重保管します。SSO が落ちた、IdP の証明書がローテートされた、IP ポリシーをミスしたなどの一撃で全員締め出される事故を防げます。
IP ポリシーは段階的に厳しくする。 いきなり全社向けに ALLOWED_IP_LIST を書き換えると、想定外の経路で入っていた誰かが落ちます。私はまずテスト用ユーザーで ALTER USER ... SET NETWORK_POLICY = ... を当て、業務影響がないことを確認してからアカウント全体に広げる順序を取ります。
SSO 設定を変更する前に、LOGIN_NAME ログイン経路を残しておく。 SAML 連携の証明書ローテートや IdP の URL 変更は、思った以上に頻繁に発生します。私は変更前に必ず「パスワード+MFA だけで入れる管理者ユーザー」が動作することを確認し、SSO 側の作業は最後に回します。これだけで深夜のロールバック作業の確率が大きく下がります。
参考リンク(Snowflake 公式ドキュメント)
関連記事
- Snowflake MFAとSSO設定入門|認証を強化する2つの仕組み – MFA と SSO の基本設計を導入観点で解説
- Snowflakeネットワークポリシー入門|IPでアクセスを制限する方法 – 本記事ケース3の前提となる IP 制限の作成手順
- Object does not exist or not authorized エラーの正体 – ログイン後にテーブルが見えない時の権限切り分け
- Snowflake監査ログ入門|Account UsageとInformation Schemaの違い – LOGIN_HISTORY を含む監査ログの全体像
- Snowflakeカスタムロール作成とGRANT/REVOKE入門 – 認証後にロール起因で詰まった時に
- Snowflakeコネクタ Python入門 – SDK 経由トークン期限切れの実装観点
