Snowflake のパスワードだけのログインが使えなくなる（2026年8〜10月）｜BI・ETL・スクリプトの接続を、どれから切り替えるか

Snowflake は、パスワードだけのサインインをやめる最後の段階（第3段階）を、2026年8〜10月に、アカウントごとに順に適用しています（Snowflake Docs「Planning for the deprecation of single-factor password sign-ins」、2026年10月3日確認）。適用されると、人のユーザーはパスワードに加えて二要素が要り、人ではないユーザーはパスワードそのものが使えなくなります。LEGACY_SERVICE というユーザーのタイプはなくなり、既存のユーザーは SERVICE に移されます。

Tableau・Power BI・TROCCO・dbt・自作のスクリプトが、同じユーザーのパスワードで接続している会社では、通知を受け取っても、どの接続が止まるのかが見えにくくなります。この記事は、止まる条件をユーザーのタイプと接続している道具の組み合わせで見分け、切り替える順番と、止まった日の戻し方、社内に残す記録までを書いています。

この記事を書いているのは10月3日です。自社のアカウントは、すでに適用されているかもしれませんし、これからかもしれません。適用の日付は、Snowflake の資料でも「変わりうる」とされていて、この記事からは分かりません。自社の日付は、届いた通知と、Snowsight の Trust Center にある Strong Authentication Hub で確かめます。

日程：第3段階は2026年8〜10月、日付はアカウントごと

Snowflake の日程表では、第2段階が2026年5〜7月、第3段階が8〜10月です。第2段階と第3段階は、三か月の間に、アカウントを順に切り替えながら適用され、アカウントごとの日付は通知で届くとあります。この2つの段階は、月ごとの動作変更のまとまり（behavior change bundle）には紐づいておらず、日付が変わることがあると書かれています（Snowflake Docs）。

この変更が及ばないアカウントもあります。Snowflake は、リーダーアカウント、トライアルのアカウント、Snowflake Postgres を、この段階の対象外としています。それらは、パスワードだけのサインインを続けられます。

Strong Authentication Hub は、二要素に登録していない人のユーザーや、移す必要のある LEGACY_SERVICE のユーザーを、一覧にして見せる画面です。Power BI などのアプリから、直近90日にパスワードだけで入ったユーザーも拾います。適用の日程の表示と、適用日を延ばす操作もここにあります（Strong Authentication Hub）。見るには、ACCOUNTADMIN か、Trust Center の閲覧の権限が要ります。

接続の洗い出しだけを、先にお手伝いすることもできます。道具と持ち主の一覧ができれば、そのあとの切り替えは自社の作業にできます（データ基盤とBIの案内）。

まず数える：ユーザーのタイプと、接続している道具

Snowflake のユーザーには、TYPE というプロパティがあります。人のユーザーは PERSON で、TYPE を設定していない場合も人のユーザーとして扱われます。アプリやサービスのためのユーザーは SERVICE で、パスワードでも SAML のシングルサインオンでも入れません。LEGACY_SERVICE は、人が操作しないユーザーに、移行のあいだだけパスワードを許していた型で、廃止されます（Types of users）。

見落としやすいのは、TYPE を決めずに作った、機械のためのユーザーです。BI の定期更新やスクリプトの専用ユーザーを、TYPE を設定せずに作っていると、Snowflake からは人のユーザーに見えます。第3段階の後は、パスワードで入るなら二要素が要るので、二要素に答える人がいない接続は止まる、というのが私たちの読みです。数えるときは、名前や用途ではなく、TYPE と、実際のログインの記録で見ます。

数える手順は4つで、ほとんどが Snowflake の中で取れます。

ユーザーの一覧とログインの記録は、道具の名前までは教えてくれません。ログインの記録の REPORTED_CLIENT_TYPE と接続元のアドレスで見当をつけ、道具の側の設定画面で、どのユーザーを使っているかを確かめます。1つのユーザーを複数の道具で共有している場合は、このタイミングで、道具ごとにユーザーを分けておくと、あとの鍵の持ち主と更新日の記録が楽になります。

外から Snowflake に接続する道具を増やさずに、データの取り込みを Snowflake の中で組んだ例は、当社の公開記事「Snowflake 導入支援。GA4 取り込みのテーブルとロール設計」にあります。ロールと権限を分けて考える材料としても使えます。

切り替える順番：人が二要素に答えられない接続から

止まったときに、人が画面の前で直せるかどうかで、順番を分けます。人のユーザーの二要素は、本人が登録すれば済みます。ETL や定期更新のように、夜中に動く接続は、パスワードが使えなくなると、朝まで気づけません。そこで、機械が使うユーザーを先に切り替えます。

人のユーザーが BI から入る場合、二要素の確認は ODBC・JDBC のドライバーでも使えます。ただし、固定電話や電話の呼び出しを使った二要素の設定は、ODBC や JDBC などのドライバーでは使えません。接続のあいだに入力する回数を減らすための、二要素のトークンのキャッシュ（最長4時間）もあります（Multi-factor authentication）。

道具ごとの切り替え先と、できないときの相談先

パスワードの代わりに使う方式は、大きく3つです。キーペア、プログラムによるアクセストークン（PAT）、OAuth です。

機械が使うユーザーには、キーペアを基本にするのが当社の見立てです。PAT は、期限があるので、更新の日を記録して守る運用が要ります。OAuth は、Microsoft Entra ID などの認証基盤をすでに使っている会社なら、その設定を使えます。

道具ごとの切り替え先は、次のとおりです。道具の版や契約で、使えるものが変わります。

表の「使えない」に当たる接続や、道具の資料に切り替え先が載っていない接続は、切り替えの先が見つからないことがあります。その場合は、道具の提供元に、キーペアか OAuth の対応を確かめます。この確認は、適用の日付が来る前に済ませておくほうが、あとで困りません。

キーペアに変える作業そのものは、Snowflake の資料のとおりの手順です。流れを下に置きます。

止まった日の復旧：パスワードに戻さず、鍵かトークンを入れ直す

止まったときに最初に見るのは、ログイン履歴の失敗の行です。ユーザー名・クライアントの種類・エラーの文が出ます。ただし、この履歴は、反映が最大2時間遅れることがあります（LOGIN_HISTORY）。

パスワードに戻す道は、使えない前提で考えます。第2段階のあとは、LEGACY_SERVICE を指定できません。第3段階では、LEGACY_SERVICE のユーザーは SERVICE に移され、SERVICE のユーザーはパスワードを持てません（Snowflake Docs）。SERVICE のユーザーを PERSON に変えると、隠れていたパスワードは戻ります（ALTER USER）。ただし、人のユーザーに戻るので、パスワードで入るには二要素が要り、人が操作しない接続の戻し方にはなりません。これは当社の読みです。

PAT を使う場合は、ネットワークポリシーが既定で要ります。道具の接続元のアドレスが、許可の範囲に入っているかも確かめます。TROCCO のように、方式を一度ほかに変えるとパスワードに戻せない道具もあるので、変えるのは、移し先の準備ができてからにします。

適用の日付を延ばす機能は、Strong Authentication Hub にあります。適用されたあとにも使えるかどうかは、確かめられていません。時間が足りない接続があるなら、適用の前に、ハブで確認してください。

社内に残す記録：誰が鍵を持ち、いつ更新するか

Snowflake につなぐ BI が QlikView 12.90 の場合は、サポートが2026年10月31日に終わります。上げるか別の BI へ移すかをアプリの数で決める手順は「QlikView 12.90 のサポートが2026年10月31日に終わる」で解説しています。

切り替えたあと、いちばん困るのは、鍵やトークンの持ち主が分からなくなることです。ユーザーごとに1行で、次の欄を残します。

名前付きのキーペアなら、入れ替えのあとも古い鍵が既定で24時間残るので、道具の側を直す時間があります。PAT は、期限が切れる前に、Snowflake 側で発行し直して、道具の接続を更新します。この記録は、担当が代わるときの引き継ぎの資料にもなります。

接続の一覧づくりと、切り替えの順番の整理は、Aurant Technologies のデータ基盤とBIの案内から、困っている1点だけでも相談できます。