Microsoft Purview で Azure Synapse Dedicated SQL Pool（専用 SQL プール）をスキャンしてデータカタログ化したいのに、Synapse が VNet 配下のプライベート構成だと接続が通りません。本記事では、Purview から到達させる2つの現実解と設計の落とし穴を具体的に解説します。
結論：VNet 内の専用 SQL プールを Purview でスキャンする現実的な選択肢
Azure Synapse Dedicated SQL Pool がプライベート エンドポイント（Private Endpoint）前提、または外部から到達できない VNet 配下にある場合、Microsoft Purview のスキャンで取り得る経路は大きく2つです。
| 方式 | 概要 | 向いている状況 | 注意点 |
|---|---|---|---|
| Self-hosted Integration Runtime（SHIR） | VNet 内（または到達できるネットワーク）に実行基盤を置き、Purview のスキャン通信を中継する | ネットワーク要件が複雑／Private Endpoint 以外も混在／確実性重視 | VM（またはサーバー）の運用が必要 |
| Azure Integration Runtime + Managed VNet + Managed Private Endpoint | Purview 側のマネージド VNet から Private Link で Synapse に到達させる（VM不要） | Private Endpoint を承認できる／運用を軽くしたい／サーバーレス寄り | 「特定VNetのみ許可（Selected networks）」のような設計だと詰まりやすい |
以降では、なぜ詰まるのかという原理から、2方式それぞれの構成と手順、ハマりどころ、判断基準、トラブルシューティングまでまとめます。WordPress にそのまま貼れるよう、できるだけ手順を具体化しています。
なぜ「VNet 内の専用 SQL プール」は Purview スキャンでつまずくのか
Purview のスキャンは、対象データソースへメタデータ取得のための接続を行います。Synapse Dedicated SQL Pool の場合、基本的には SQL エンドポイントに対して接続し、システムカタログ（テーブル、ビュー、列、型、説明、リレーションなど）を読み取ります。
ところが、Synapse が次のようなネットワーク構成だと、Purview の「標準の到達経路」では接続できません。
- Public network access を無効化している（または極端に絞っている）
- Private Endpoint のみでアクセスさせている
- ファイアウォールで特定ネットワーク（VNet/オンプレ）からしか許可しない設計にしている
重要なのは、Purview のスキャン実行は「Purview の管理平面（UI）」ではなく、Integration Runtime（IR）という実行基盤が担う点です。つまり、Purview でデータソースを登録できても、IR が Synapse に到達できなければスキャンは失敗します。
前提整理：Purview のスキャンに必要な要素
スキャンが成立するためには、少なくとも次の3点が揃う必要があります。
| 要素 | 何が必要か | つまずきやすいポイント |
|---|---|---|
| ネットワーク到達性 | IR から Synapse の SQL エンドポイントへ接続できる | Private Endpoint/DNS/ルーティング/NSG/ファイアウォール |
| 認証情報 | SQL ログイン、または Azure AD 認証などでログインできる | SQL 認証禁止、条件付きアクセス、MFA、資格情報の保管方法 |
| 権限 | メタデータ閲覧に必要な権限が付与されている | 「接続はできるが一覧が空」「一部だけ見えない」 |
本記事の焦点は主にネットワーク到達性ですが、実務では「つながったのに何も取れない」が頻発します。後半で権限設計とトラブルシューティングも扱います。
方式A：Self-hosted Integration Runtime（SHIR）でスキャンする
SHIR は、あなたが管理する VM/サーバー上で稼働し、Purview のスキャン処理を実行します。Synapse がプライベート構成でも、SHIR を Synapse に到達できる場所へ置けば、スキャン経路を作れます。ネットワークの自由度が高く、最も“外れにくい”方法です。
SHIR が向いているケース
- Synapse だけでなく、Storage/SQL/オンプレなど複数の閉域データソースを一括でスキャンしたい
- Private Endpoint を使えない／使いたくない要件がある
- 社内の DNS・プロキシ・FW 制約が強く、Purview 側の Managed VNet では吸収できない
- 監査や運用ポリシー上、スキャン通信を自ネットワーク境界内に閉じたい
SHIR の代表的な構成イメージ
Purview（管理）
│（スキャン指示）
▼
Self-hosted IR（あなたのVM / VNet内）
│（TCP 1433 などで接続）
▼
Synapse Dedicated SQL Pool（Private Endpoint / VNet内）ポイントは、Synapse 側へ向かう通信の起点が「SHIR が稼働するマシン」になることです。よって、Synapse のファイアウォールやルーティング、NSG の許可先も SHIR に合わせて設計します。
実装手順（具体例）
- SHIR を置く場所を決める 最優先は「Synapse の SQL エンドポイントへ到達できること」です。同一 VNet が理想ですが、VNet ピアリング、VPN/ExpressRoute、ハブスポークなどでルーティングできるなら同一 VNet に限りません。
- VM/サーバーを用意してネットワークを整える
- Synapse が Private Endpoint の場合、名前解決（DNS）が要です。
<workspace>.sql.azuresynapse.netがプライベートIPに解決されるよう、Private DNS ゾーンや DNS フォワーダーを整備します。 - NSG/Firewall で、Synapse 側（通常は 1433/TCP）への到達を許可します。
- SHIR から Purview サービスへは基本的にアウトバウンド HTTPS（443/TCP）が必要になります。プロキシ配下の場合はプロキシ設定も検討します。
- Synapse が Private Endpoint の場合、名前解決（DNS）が要です。
- SHIR をインストールし、Purview に登録する Purview Studio（管理画面）で Self-hosted IR を作成し、表示されるキーを使って VM 上の SHIR を登録します。複数ノード（2台以上）に同じ IR を登録すると冗長化できます。
- 接続テスト（VM から Synapse）を先に行う Purview の画面で試行錯誤する前に、VM から SQL 接続できる状態を作るのが最短です。Windows なら次のようなテストが有効です。
Test-NetConnection <workspace>.sql.azuresynapse.net -Port 1433到達しない場合は DNS/ルート/NSG/ファイアウォールを疑います。到達するのにログインできない場合は認証（SQL/AAD）や権限を疑います。 - Purview に Synapse データソースを登録し、スキャンで SHIR を選択する Purview のデータソース登録で Azure Synapse を選び、接続先（SQL エンドポイント）と資格情報を設定します。スキャン作成時に Integration Runtime として Self-hosted IR を選びます。
SHIR 運用のコツ（現場視点）
SHIR は「確実性」と引き換えに運用要素が増えます。とはいえ、次の工夫で運用負荷をかなり抑えられます。
| 観点 | おすすめ | 狙い |
|---|---|---|
| 可用性 | SHIR を2台以上で構成（同じ IR に登録） | VM障害やメンテナンス時もスキャンを止めない |
| 配置 | ハブVNet（共有サービスVNet）に置く | 複数のスポーク/データソースへ横断的に到達 |
| 権限 | 専用のスキャン用アカウント/グループを作る | 監査しやすく、不要権限の混入を防ぐ |
| 監視 | ログ（イベントログ/エージェント状態）とアラートを用意 | 「いつから落ちてた？」を防ぐ |
方式B：Azure Integration Runtime（Managed VNet）＋ Managed Private Endpoint でスキャンする
もう1つの選択肢が、Purview 側でManaged Virtual Network（マネージド VNet）を有効にした Azure Integration Runtime を使い、そこからManaged Private Endpoint（マネージド プライベート エンドポイント）で Synapse に Private Link 接続する方式です。
この方式の魅力は、SHIR のような VM 運用が不要で、スキャン経路の多くを Purview 側に寄せられる点です。言い換えると「スキャンのための閉域アクセスを、Private Link でサービス間接続として構成する」アプローチです。
この方式がサポートされる条件
- Synapse 側がPrivate Endpoint 接続を受け入れられる（作成・承認が可能）
- Purview 側でManaged VNet を有効にした Azure IRを利用できる
- 組織のセキュリティ要件として「サービスが管理する VNet」からの接続を許容できる
ここで重要なのは、Managed VNet はあなたの VNet に参加する仕組みではないことです。Purview（正確には IR）が持つ Microsoft 管理のネットワーク空間に Private Endpoint を作り、Private Link を介して Synapse に到達させます。したがって「特定の自社 VNet からしか許可しない」型の制御とは相性が悪い場合があります（後述）。
実現手順（要点）
- Purview で Azure Integration Runtime を作成し、Managed VNet を有効化する Purview Studio 側で統合ランタイムを追加し、Managed Virtual Network を利用する設定を選択します。これがスキャン実行の基盤になります。
- IR から Synapse（専用 SQL プール）へ Managed Private Endpoint を作成する 接続先は Synapse の SQL エンドポイント（Dedicated SQL 用）に相当するリソース/サブリソースを選びます。Dedicated SQL Pool のメタデータ取得が目的なら、主に SQL エンドポイントへ到達できることが焦点です。
- Synapse 側で Private Endpoint 接続を承認する Private Link は「作って終わり」ではなく、受け側で承認して初めて有効化されます。承認待ちのままだとスキャンは当然失敗します。
- 承認後に Purview スキャンを実行する スキャン設定で Azure IR（Managed VNet）を選択し、実行します。VM（SHIR）は不要です。
関係者が分かれる場合の“やること分担”
Managed Private Endpoint は、Purview 側で「作る人」と、Synapse 側で「承認する人」が分かれることが多いです。作業が止まりやすいポイントなので、分担を明確にしておくとスムーズです。
| 担当 | 作業 | 見落としがちな点 |
|---|---|---|
| Purview 管理者 | Azure IR（Managed VNet）作成、Managed Private Endpoint 作成、スキャン設定 | エンドポイント作成後、承認待ちの状態で放置されがち |
| Synapse 管理者 | Private Endpoint 接続の承認、必要に応じたネットワーク設定 | 承認後も「対象サブリソースが違う」と到達しない |
| ネットワーク管理者 | ポリシー確認、Private Link の利用許可、監査要件整理 | 「自社VNet限定アクセス」要件が残っていると衝突 |
設計上の注意（Managed VNet 側で詰まりやすいポイント）
- Private Endpoint を作る対象（サブリソース）を取り違えると、承認しても接続できません。Dedicated SQL Pool のスキャンが目的なら「SQL エンドポイントへ到達できること」を優先します。
- DNSは「FQDN が Private Link 側に解決される」ことが本質です。環境によっては、社内 DNS の上書きやプロキシが影響することがあります。
- ガバナンス観点では、Managed Private Endpoint の新規作成を誰が許可するか（申請・承認フロー）を決めておくと、運用が破綻しません。
補足：Selected networks のような“自社VNet限定”設計で難しくなる理由
「ネットワークは閉じたいが、Private Endpoint はまだ使っていない」という過渡期の設計でよくあるのが、特定の VNet からのアクセスだけを許可する（Selected networks 相当）という発想です。
この設計では、アクセス元が「あなたの VNet（またはオンプレ）」であることが前提になりがちです。しかし Purview の Managed VNet は、その VNet に参加できません。結果として、
- Managed VNet からは「許可された VNet」として認識されない
- IP ベース許可も、Managed VNet 側の固定 IP を前提にしづらい
といった理由で詰まりやすくなります。
回避策はシンプルで、次のどちらかに寄せるのが現実的です。
| 回避策 | 何を変えるか | メリット | デメリット |
|---|---|---|---|
| SHIR を VNet 側に置く | アクセス元を自社VNet内に固定する | 設計変更が最小で済む | VM運用が増える |
| Private Endpoint 前提に寄せる | Synapse を Private Link 接続で受ける設計へ移行する | サービス間接続として閉域化でき、将来の拡張にも強い | 承認フロー/DNS など追加の設計が必要 |
どちらを選ぶべきか：判断基準を“実務の言葉”に落とす
最後に、現場で迷うポイントを意思決定しやすい形に整理します。重要なのは「どちらが正しいか」ではなく、あなたの組織のネットワーク・運用・ガバナンスに合うかです。
| 判断軸 | SHIR | Azure IR（Managed VNet + MPE） |
|---|---|---|
| 成功しやすさ | 高い（到達できる場所に置けばよい） | 条件が揃えば高い（Private Endpoint 承認が鍵） |
| 運用負荷 | VM/パッチ/監視が必要 | 低い（VM不要） |
| ネットワーク自由度 | 高い（オンプレ含め柔軟） | Private Link 前提で設計する必要がある |
| ガバナンス（承認フロー） | 比較的シンプル（自社内で完結しやすい） | Managed Private Endpoint の作成・承認フローが必須 |
| 横展開 | 複数データソースへ到達できるなら一台（または少数）でまとめられる | Private Endpoint を増やす設計になる（きれいだが管理は必要） |
ケース別のおすすめ
- 「まず確実にカタログ化したい」：SHIR（最短で通す）
- 「Private Endpoint 前提で Azure を標準化している」：Azure IR（Managed VNet + MPE）
- 「オンプレや他クラウドも含む閉域が混在」：SHIR（ルーティング設計に寄せる）
- 「運用人員が少なく VM を増やしたくない」：Azure IR（ただし承認プロセス整備が前提）
スキャン成功率を上げるチェックリスト
「設定は合っているはずなのに失敗する」を減らすため、実務で効くチェック項目をまとめます。
| カテゴリ | チェック項目 | 確認のコツ |
|---|---|---|
| 到達性 | IR（SHIR/Managed VNet）から SQL エンドポイントへ疎通できる | まずは OS/ネットワークレイヤーで 1433 が通るか確認 |
| DNS | FQDN が Private Link 側（プライベートIP）に解決される | nslookup で解決結果を確認。誤ってパブリックIPを引いていないか |
| 承認 | Managed Private Endpoint を作った場合、Synapse 側で承認済み | 「承認待ち」のまま止まりやすい。運用フローに組み込む |
| 認証 | SQL/AAD いずれの方式でもログイン可能 | MFA/条件付きアクセスが絡むと自動スキャンが失敗しがち |
| 権限 | メタデータ閲覧に必要な権限を付与 | 「接続OKだがテーブルが出ない」は権限不足の典型 |
トラブルシューティング（よくある症状 → 原因 → 対処）
| 症状 | ありがちな原因 | 対処 |
|---|---|---|
| タイムアウト／到達不可 | DNS がパブリックに解決、NSG/FW で遮断、ルート不足 | まず IR 起点で 1433 疎通と DNS 解決を確認。Private DNS/ルート/許可設定を見直す |
| Managed Private Endpoint を作ったのに接続できない | 承認待ち、対象サブリソース違い | Synapse 側の Private endpoint connections を確認し承認。Dedicated SQL 用の接続先を再確認 |
| 接続できるがスキャン結果が空/一部欠落 | メタデータ閲覧権限不足 | 最小権限で試すなら VIEW DEFINITION 等を検討。まずは広めに付与して原因切り分け→絞り込み |
| 認証エラー（ログイン失敗） | 資格情報の誤り、SQL 認証禁止、AAD設定不一致 | 手動の接続テストを優先。認証方式を統一し、スキャン用アカウントを明確化 |
権限設計の考え方：スキャン用アカウントをどう作るか
Purview スキャンは「データを大量に読む」よりも「メタデータを読む」側面が強いですが、メタデータも情報資産です。運用で揉めやすいので、スキャン専用のアカウント（または Azure AD グループ）を用意し、目的に応じて権限を付与するのがおすすめです。
- 切り分け優先：最初は広めの権限（例：db_owner 相当）でスキャン成功を確認し、成功後に必要最小限へ絞る
- 最小権限優先：接続（CONNECT）＋メタデータ閲覧（VIEW DEFINITION 等）から始め、見えないオブジェクトがある場合に段階的に追加
どちらを採っても、最終的には「Purview で何を可視化したいか（テーブル名だけでよいのか、列情報まで必要なのか）」で必要権限が変わります。組織の情報区分と合わせて設計してください。
運用のヒント：スキャン設計を“長持ち”させる
- スキャン頻度は、更新頻度と運用コストのバランスで決めます。まずは日次/週次から開始し、結果の鮮度要求に応じて調整します。
- 変更管理として、Synapse 側のネットワーク設定変更（PE 再作成、DNS 変更、FW 変更）が入るとスキャンが止まりやすい点を共有しておきます。
- 失敗通知を運用に組み込みます。特に Managed Private Endpoint は承認フローの遅延が起きやすいため、「承認待ちのまま日が過ぎる」を防ぐ仕組みが有効です。
まとめ
Microsoft Purview で VNet 内の Azure Synapse Dedicated SQL Pool をスキャンする際は、到達経路をどう作るかがすべてです。最も堅いのは SHIR を VNet 内（または到達できるネットワーク）に置く方法で、ネットワーク要件が複雑でも通しやすいのが強みです。一方、Private Endpoint を前提にできるなら、Azure IR の Managed VNet と Managed Private Endpoint で VM なしの構成も現実的になります。
迷ったら、まずは「Synapse に Private Endpoint を張れるか（承認できるか）」と「自社VNet限定アクセス要件が残っていないか」を確認し、条件が揃うなら Managed VNet、難しければ SHIR で確実に進めるのが、実務では最短ルートです。
コメント