Microsoft PurviewでSnowflakeを管理する場合、最初に押さえるべき結論は「Snowflakeソースを登録し、Key Pair認証を前提にスキャンを構成し、Unified Catalogでメタデータとライネージを確認する」という流れです。特に重要なのは、Snowflake側でパスワードのみの認証が段階的に制限されるため、Microsoft PurviewのSnowflake Data MapコネクタでもBasic認証を使い続ける構成は見直しが必要になっている点です。Microsoft Learnの公式ドキュメント「Connect to and manage Snowflake in Microsoft Purview」では、Snowflakeの登録、認証、スキャン、ライネージ確認、Private Link接続、トラブルシューティングまでが整理されています。(Microsoft Learn)
この記事では、Microsoft PurviewでSnowflakeを接続・管理する管理者向けに、2026年6月時点で確認すべき変更点、影響範囲、Key Pair認証への移行、スキャン設定の注意点を実務目線で整理します。
Connect to and manage Snowflake in Microsoft Purviewでできること
Microsoft Purviewでは、Snowflakeをデータソースとして登録し、Snowflake内のデータベース、スキーマ、テーブル、ビュー、ストアドプロシージャ、関数、ステージ、ストリーム、タスクなどの技術メタデータをスキャンできます。さらに、テーブル、ビュー、ストリーム、ストアドプロシージャ間の静的ライネージも取得できます。(Microsoft Learn)
実務上は、単に「Snowflakeに接続できるようにする機能」ではなく、次のような用途で使う機能と考えると分かりやすいです。
| 用途 | Microsoft Purviewでできること | 管理者が見るべきポイント |
|---|---|---|
| データ資産の可視化 | Snowflake上のテーブル、ビュー、列などをUnified Catalogに登録 | どのデータベース・スキーマを対象にするか |
| ガバナンス | 所有者、分類、用語、説明などをカタログ上で管理 | スキャン範囲とコレクション設計 |
| 影響分析 | ビューやストアドプロシージャを含むライネージを確認 | 複数DB・複数スキーマをまとめてスキャンする必要があるか |
| セキュリティ対応 | Key Pair認証やPrivate Link接続を使った安全な接続 | Basic認証からの移行計画 |
| 運用監視 | スキャン履歴、失敗原因、Query Historyの確認 | 認証、権限、Integration Runtimeの状態 |
Snowflakeスキャンでは、メタデータ抽出、フルスキャン、スコープ指定スキャンに対応しています。一方で、インクリメンタルスキャンは対応していません。更新頻度の高いSnowflake環境では、スキャン対象を絞る、スケジュールを調整する、不要なスキーマを除外するなど、フルスキャン前提の設計が必要です。(Microsoft Learn)
重要な変更点はBasic認証からKey Pair認証への移行
今回の公式情報で最も重要なのは、SnowflakeのBasic認証、つまりユーザー名とパスワードによる単一要素の認証を前提にした構成を見直す必要がある点です。
Microsoftのドキュメントでは、SnowflakeがBasic認証の非推奨化を発表しており、Microsoft PurviewでSnowflake Data Mapコネクタを利用している場合は、サービス中断を避けるためにKey Pair認証へ移行することが推奨されています。Microsoft側の案内では、既存ユーザーを一時的にLEGACY_SERVICEタイプへ更新することで移行期間を確保しつつ、Key Pair認証の設定と検証を進める流れが示されています。(Microsoft Learn)
Snowflake側の公式ドキュメントでも、人間ユーザーにはMFA、サービスユーザーにはパスワードを使わない強力な認証方式への移行が説明されています。特にサービスユーザーについては、SERVICEとLEGACY_SERVICEの扱いが段階的に変わるため、Microsoft Purviewのスキャン専用ユーザーを放置すると、将来的に接続失敗やスキャン停止につながる可能性があります。(スノーフレークドキュメント)
| 対象 | 影響 | 推奨対応 |
|---|---|---|
| Basic認証でSnowflakeをスキャンしている既存環境 | 将来的に認証失敗やスキャン停止のリスク | Key Pair認証へ移行する |
| Microsoft Purview用のSnowflakeサービスユーザー | ユーザータイプや認証方式の見直しが必要 | 移行期間中は必要に応じてLEGACY_SERVICEを確認し、最終的にはKey Pairへ移行 |
| 新規にSnowflake接続を作る環境 | 最初からパスワード前提で作ると再作業が発生しやすい | Key Pair認証を標準構成にする |
| 既存のスキャンスケジュール | 認証変更後に失敗する可能性 | テストスキャン後に本番スケジュールへ反映 |
既存ユーザーを一時的にLEGACY_SERVICEへ設定する場合、Snowflake側では次のようなコマンドを使用します。
ALTER USER <purview_user_name> SET TYPE = LEGACY_SERVICE;ただし、これはあくまで移行期間を確保するための対応です。長期的には、Microsoft PurviewのSnowflakeスキャン用ユーザーをKey Pair認証で動作させる構成へ切り替えるべきです。
影響を受ける担当者と確認範囲
この変更は、Microsoft Purviewの管理者だけで完結する話ではありません。Snowflake管理者、Azure管理者、セキュリティ担当、データ基盤の開発者がそれぞれ確認すべき項目があります。
| 担当者 | 主な確認項目 | 見落としやすいポイント |
|---|---|---|
| Microsoft Purview管理者 | 登録済みSnowflakeソース、スキャン、資格情報、コレクション | どのスキャンがBasic認証を使っているか |
| Snowflake管理者 | Purview用ユーザー、ロール、ウェアハウス、データベース権限 | デフォルトロールに必要権限が付いているか |
| Azure管理者 | Azure Key Vault、マネージドID、Integration Runtime | Key VaultのGet/List権限やファイアウォール |
| セキュリティ担当 | パスワード認証の廃止計画、秘密情報の保管方法 | 秘密鍵をAzure Portalで登録して形式を壊していないか |
| データ基盤・開発者 | スキャン対象DB、スキーマ、ストアドプロシージャ、ライネージ | 複数DBをまたぐビューのライネージ取得条件 |
特に注意したいのは、接続テストが成功してもスキャン全体が成功するとは限らない点です。接続には成功しても、デフォルトロールにウェアハウスやデータベースへの権限が不足していると、メタデータ取得や分類、ライネージ抽出で失敗します。Microsoftのトラブルシューティングでも、SnowflakeのQuery Historyを使って接続が届いているか、どのロールが使われているかを確認する方法が案内されています。(Microsoft Learn)
登録前に決めておくべき設計ポイント
SnowflakeをMicrosoft Purviewに登録する前に、少なくとも次の4点を決めておくと、あとから再設計になりにくくなります。
登録名とコレクション設計
Microsoft Purviewでは、Snowflakeソースを登録する際に、カタログ上で表示する名前と配置先のコレクションを指定します。コレクションは、部門、環境、データドメイン、機密度などの単位で分けることが多いため、単に「Snowflake」と登録するよりも、用途が分かる名前にするのがおすすめです。
例として、次のような命名にすると運用しやすくなります。
| 環境 | 登録名の例 | 意図 |
|---|---|---|
| 本番DWH | snowflake-prod-dwh | 本番データウェアハウスであることが分かる |
| 分析基盤 | snowflake-analytics | 分析用途のソースであることが分かる |
| 開発環境 | snowflake-dev | 本番と誤認しにくい |
| 部門別管理 | snowflake-sales | 営業部門の管理対象と分かる |
Server URLとAdditional hosts
Snowflakeソースの登録では、<account_identifier>.snowflakecomputing.com形式のサーバーURLを指定します。このURLは、Microsoft Purview内でSnowflakeアセットの完全修飾名を構成する要素にも使われます。(Microsoft Learn)
ここで重要なのが、Public EndpointからPrivate Endpointへ切り替える可能性がある場合です。公式ドキュメントでは、既にスキャン済みのSnowflakeソースで接続先エンドポイントを変えたい場合、別ソースを新規登録するのではなく、既存ソースにAdditional hostsを追加してスキャン時に選択する方法が案内されています。これにより、Microsoft Purview内のアセットの完全修飾名を維持しやすくなります。(Microsoft Learn)
新しいソースとして登録し直すと、同じSnowflake上のデータが別アセットとして扱われ、カタログ、分類、用語、ライネージの整理が複雑になることがあります。エンドポイント変更は「ソースの作り直し」ではなく「既存ソースへのホスト追加」を先に検討しましょう。
Integration Runtimeの選択
Snowflakeスキャンでは、シナリオに応じてAzure autoresolved Integration Runtime、Managed Virtual Network Integration Runtime、Self-hosted Integration Runtimeを選択します。Private Link経由でSnowflakeに接続する場合は、Managed Virtual Network IRとManaged Private Endpointの構成が必要です。Self-hosted Integration Runtimeを使う場合は、JDK 11やVisual C++ Redistributableなどの前提ソフトウェアも確認します。(Microsoft Learn)
| 接続方式 | 向いているケース | 注意点 |
|---|---|---|
| Azure autoresolved IR | インターネット経由でシンプルに接続する | ネットワーク制御が厳しい環境には不向きな場合がある |
| Managed Virtual Network IR | Private LinkでSnowflakeに接続したい | Managed Private Endpointの承認フローが必要 |
| Self-hosted IR | 社内ネットワークや独自制御下のVMから接続したい | JDK、IRバージョン、メモリ、OS側の保守が必要 |
Purview専用ユーザーとロール
Microsoft Purview用には、共有ユーザーではなく専用のSnowflakeユーザーと専用ロールを用意するのが基本です。理由は、権限の過不足を把握しやすく、Query Historyでトラブルシューティングしやすく、退職者や他システムの認証変更の影響を受けにくいからです。
公式ドキュメントでは、purview_readerロールを作成し、スキャン対象のウェアハウス、データベース、スキーマ、テーブル、ビュー、関数、プロシージャ、ステージなどに必要な権限を付与する例が示されています。既存オブジェクトだけでなく、将来作成されるオブジェクトに対するFUTURE権限も忘れずに設定する必要があります。(Microsoft Learn)
Key Pair認証への移行手順
Key Pair認証への移行は、いきなり本番スキャンを切り替えるのではなく、既存設定の棚卸し、Snowflakeユーザーの準備、Azure Key Vaultへの秘密情報登録、Microsoft Purviewでの資格情報作成、テストスキャンの順に進めると安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 既存設定の棚卸し | 登録済みSnowflakeソースとスキャンを確認 | Basic認証のスキャンを一覧化する |
| Snowflakeユーザー確認 | Purview専用ユーザー、ロール、ウェアハウスを確認 | デフォルトロールに必要権限があるか |
| RSAキー作成 | 秘密鍵と公開鍵を生成 | 暗号化された秘密鍵を使う構成を優先する |
| 公開鍵登録 | Snowflakeユーザーに公開鍵を設定 | RSA_PUBLIC_KEY_FPでフィンガープリントを確認 |
| Key Vault登録 | 秘密鍵とパスフレーズをAzure Key Vaultに保存 | 秘密鍵はAzure CLIまたはCloud Shellで登録 |
| Purview資格情報作成 | Key Pair credentialを作成 | 秘密鍵とパスワードのシークレット名を間違えない |
| テストスキャン | 接続テストと限定スキャンを実行 | カタログ、分類、ライネージを確認 |
RSAキーを作成してSnowflakeユーザーに公開鍵を設定する
Key Pair認証では、秘密鍵と公開鍵のペアを作成し、公開鍵をSnowflakeユーザーに割り当てます。Microsoftの手順では、OpenSSLでRSAキーを生成し、公開鍵のヘッダーとフッターを除いた中身をSnowflakeユーザーのRSA_PUBLIC_KEYに設定する流れが示されています。(Microsoft Learn)
設定イメージは次のとおりです。
ALTER USER purview_scanner
SET RSA_PUBLIC_KEY='MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...';設定後は、Snowflake側のDESC USERとローカルのOpenSSLコマンドでフィンガープリントが一致するか確認します。ここを省略すると、あとで「公開鍵と秘密鍵が対応していない」「古い鍵を参照している」といった原因の切り分けに時間がかかります。(Microsoft Learn)
秘密鍵はAzure PortalではなくCLIまたはCloud Shellで登録する
Key Pair認証で最も失敗しやすいのが、秘密鍵をAzure Key Vaultに登録する工程です。公式ドキュメントでは、秘密鍵はAzure CLIまたはAzure Cloud Shellを使って登録する必要があり、Azure Portalのテキスト入力で秘密鍵を作成しないよう明記されています。理由は、Azure Portalの入力欄では複数行のPEM形式が保たれず、改行がスペースに変換されて秘密鍵の形式が壊れる可能性があるためです。(Microsoft Learn)
登録例は次のとおりです。
az keyvault secret set \
--vault-name <key-vault-name> \
--name "snowflake-purview-cred-privateKey" \
--file rsa_key.p8パスフレーズは1行の値なので、Azure PortalまたはCLIで登録できます。なお、暗号化していない秘密鍵を使う場合でも、Microsoftの手順ではパスワード用のシークレットを空文字またはプレースホルダーで作成する必要があるとされています。(Microsoft Learn)
スキャン設定で失敗しやすいポイント
Snowflakeの登録と認証が正しくても、スキャン設定でつまずくことがあります。特に、名前の大文字指定、複数データベース指定、分類の制約、ストアドプロシージャの詳細設定は事前に確認しておきましょう。
| 設定項目 | 注意点 | 実務での判断基準 |
|---|---|---|
| Warehouse | スキャン設定画面ではウェアハウス名を大文字で指定 | Snowflake側の表示名と権限を確認する |
| Databases | 複数指定はセミコロン区切り | DB1;DB2のように指定する |
| Schema | 空欄ならすべてのユーザースキーマが対象 | 本番では対象スキーマを絞る |
| Database/Schema patterns | %を使ったパターン指定が可能 | A%、%B、%C%などを使う |
| Incremental scan | 非対応 | フルスキャン前提でスケジュールを設計する |
| Classification | 複数DB指定時はテーブルに分類が適用されない | 分類重視ならDB単位のスキャンを検討 |
| 特殊文字 | DB名、スキーマ名、テーブル名、ビュー名に特殊文字があると分類されない | 命名ルールを確認する |
| Stored procedure details | Signature、Code、Lineageなどを選択 | コード取得やライネージ取得の必要性で選ぶ |
| SHIRのメモリ | 目安として1,000テーブルあたり1GB | 大規模環境ではVMサイズを先に見積もる |
Microsoftのドキュメントでは、ストアドプロシージャの詳細取得について、Signature、Code、Lineageなどの選択肢が示されています。ただし、Self-hosted Integration Runtimeで既定以外の設定を使うには、指定バージョン以降が必要です。また、分類を利用する場合もSelf-hosted Runtimeのバージョン要件があります。(Microsoft Learn)
ストアドプロシージャのライネージは、Snowflake Scripting SQLとJavaScriptで定義されたものが対象です。一方、Java、Python、Scalaで定義されたストアドプロシージャや、EXECUTE IMMEDIATEで静的SQLを変数として扱うパターンはサポート対象外です。データエンジニアが「Purviewにライネージが出ない」と判断する前に、対象の実装言語とSQLの書き方を確認する必要があります。(Microsoft Learn)
ライネージ確認ではスキャン範囲の切り方が重要
Microsoft PurviewでSnowflakeのライネージを確認するには、スキャン後にUnified Catalogでアセットを開き、Lineageタブを確認します。ここで注意したいのは、ビューが異なるデータベースや異なるスキーマのテーブルを参照している場合、それらを同時にスキャンする必要がある点です。(Microsoft Learn)
例えば、ANALYTICS_DB.REPORTING.V_SALESというビューが、RAW_DB.PUBLIC.ORDERSとMASTER_DB.PUBLIC.CUSTOMERSを参照している場合、ANALYTICS_DBだけをスキャンしても、期待するライネージがつながらない可能性があります。この場合は、関係するデータベースやスキーマを同じスキャン範囲に含める設計が必要です。
ただし、分類を重視する場合は、複数データベース指定時に分類が適用されない制約もあります。つまり、ライネージを優先するスキャンと分類を優先するスキャンを分ける、という設計も現実的です。
| 優先したい目的 | スキャン設計 |
|---|---|
| 複数DBをまたぐライネージを確認したい | 関連するDB・スキーマを同時にスキャン |
| 機密情報の分類を確実に付けたい | DB単位でスキャンを分ける |
| スキャン時間を短縮したい | スキーマ名やDB名パターンで対象を絞る |
| 開発環境で検証したい | 小さいDBまたは一部スキーマで試す |
Managed Private EndpointでSnowflakeに接続する場合
Snowflakeへの接続をPrivate Link経由にしたい場合は、Microsoft Purview側でManaged Virtual Network Integration RuntimeとManaged Private Endpointを構成します。公式手順では、Snowflake側でSYSTEM$GET_PRIVATELINK_CONFIG()を実行して、Private Link用のエンドポイント情報やリソースIDを取得し、Microsoft Purview側のManaged Private Endpoint作成時に指定します。(Microsoft Learn)
大まかな流れは次のとおりです。
| 手順 | 作業内容 |
|---|---|
| Snowflake側で情報取得 | SYSTEM$GET_PRIVATELINK_CONFIG()を実行し、privatelink-pls-idなどを控える |
| Purview側でIR準備 | Managed Virtual Network Integration Runtimeを作成または確認 |
| Managed Private Endpoint作成 | Snowflake向けのManaged Private Endpointを作成 |
| Snowflake Supportへ承認依頼 | Managed private endpoint resource IDをSnowflakeへ伝える |
| 承認状態を確認 | Purview上でApproval stateがApprovedになっているか確認 |
| スキャン設定に反映 | Snowflakeスキャンで該当するManaged Virtual Network IRを選択 |
Private Endpointへ切り替える場合も、既存ソースを作り直す前にAdditional hostsの利用を検討してください。アセットの完全修飾名が変わると、過去の分類、用語、所有者情報、ライネージ確認に影響が出ることがあります。
管理者向け移行チェックリスト
本番環境で作業する前に、次のチェックリストを使って抜け漏れを確認してください。
| フェーズ | チェック項目 | 完了の目安 |
|---|---|---|
| 現状把握 | Basic認証のSnowflakeスキャンを洗い出した | 対象スキャン、資格情報、実行スケジュールが一覧化されている |
| Snowflake準備 | Purview専用ユーザーとロールを確認した | デフォルトロール、ウェアハウス、DB権限が確認済み |
| 認証移行 | RSAキーを作成し公開鍵をSnowflakeユーザーに設定した | フィンガープリント一致を確認済み |
| Key Vault | 秘密鍵とパスフレーズを登録した | 秘密鍵が複数行形式で保持されている |
| Purview設定 | Key Pair資格情報を作成した | Key Vault参照名に誤りがない |
| 接続確認 | Test connectionを実行した | 接続成功、またはQuery Historyで原因を特定済み |
| スキャン検証 | 小さい範囲でテストスキャンした | アセット、分類、ライネージを確認済み |
| 本番反映 | スケジュールスキャンをKey Pairへ切り替えた | 旧Basic認証を使うスキャンが残っていない |
特に本番切り替えでは、旧Basic認証の資格情報をすぐ削除しない方が安全です。Key Pair認証で数回のスケジュールスキャンが成功し、カタログやライネージに問題がないことを確認してから、旧資格情報の停止や削除を進めるとトラブルを抑えられます。
よくあるトラブルと切り分け方
Snowflakeスキャンで問題が起きた場合は、エラー画面だけで判断せず、Microsoft Purview、Azure Key Vault、Snowflake Query Historyの3か所を確認します。
| 症状 | 主な原因 | 確認・対応 |
|---|---|---|
| Test connectionが失敗する | 公開鍵未設定、Key Vault権限不足、シークレット名誤り | DESC USER、Key VaultのGet/List権限、秘密情報名を確認 |
| Invalid Private Key Formatが出る | 秘密鍵をAzure Portalで登録し、PEM形式が壊れた | CLIまたはCloud Shellで秘密鍵を登録し直す |
| 接続は成功するがスキャンが失敗する | Snowflake側の権限不足 | ウェアハウス、DB、スキーマ、テーブル、ビュー、FUTURE権限を確認 |
| Query Historyに何も出ない | アカウント識別子、認証情報、ネットワーク到達性の問題 | Server URL、Additional hosts、Private Endpoint、資格情報を確認 |
USE WAREHOUSEだけ見える | デフォルトロールやDB権限の問題 | Purview用ユーザーのDEFAULT_ROLEを確認 |
| 分類が付かない | 複数DB指定、特殊文字、IRバージョン要件 | スキャン単位、命名、Self-hosted IRのバージョンを確認 |
| ライネージがつながらない | 関連DB・スキーマを同時にスキャンしていない | 参照元と参照先を同じスキャン範囲に含める |
Microsoftのトラブルシューティングでは、Key Pair認証の失敗原因として、公開鍵未設定、Key Vaultアクセス権限、シークレット名の誤り、秘密鍵形式の破損、フィンガープリント不一致、パスフレーズ誤り、Snowflake権限不足などが挙げられています。特に秘密鍵の複数行形式が崩れる問題は起きやすいため、Azure Portalで秘密鍵を登録していないかを最初に確認すると効率的です。(Microsoft Learn)
まず実施すべき対応
Microsoft PurviewでSnowflakeを管理している組織が今すぐ実施すべきことは、次の3つです。
| 優先度 | 実施内容 | 理由 |
|---|---|---|
| 高 | Basic認証を使っているSnowflakeスキャンを棚卸しする | 将来的な接続失敗を避けるため |
| 高 | Key Pair認証の検証環境を作る | 本番切り替え前にKey Vault、権限、IRの問題を潰すため |
| 中 | スキャン範囲とライネージ要件を見直す | フルスキャン前提でコスト、時間、分類精度を調整するため |
| 中 | Private Link利用有無を確認する | エンドポイント変更時のアセット重複を避けるため |
| 中 | SnowflakeユーザーのロールとFUTURE権限を確認する | 新規テーブルがスキャン対象から漏れるのを防ぐため |
Microsoft PurviewとSnowflakeの連携は、一度接続できれば終わりではありません。認証方式、権限、スキャン範囲、ライネージ、分類、ネットワーク経路をセットで管理する必要があります。特に2026年以降は、Basic認証を前提にした構成をそのまま維持するリスクが高まるため、既存スキャンの棚卸しとKey Pair認証への移行を優先しましょう。
最初の一歩は、Microsoft Purviewの登録済みSnowflakeソースを開き、各スキャンの資格情報、対象データベース、Integration Runtime、実行スケジュールを一覧化することです。そのうえで、Snowflake管理者と連携し、専用ユーザー、ロール、Key Pair認証、Key Vault登録、テストスキャンまでを小さな範囲で検証してから本番へ展開すると、安全に移行できます。
コメント