SQL Server enabled by Azure Arcで最初に押さえるべき結論は、SQL ServerをAzure Arcに接続すると、オンプレミスや他クラウド上のSQL ServerをAzureの管理対象リソースとして扱えるようになるという点です。単なる接続手順の変更ではなく、インベントリ管理、ライセンス管理、セキュリティ、移行評価、監視の入口がAzure側に集約されます。
特に管理者が注意すべきなのは、Azure Arcに接続済みのサーバーにSQL Serverがインストールされている場合、SQL Server用Azure拡張機能が自動的にインストールされ、SQL ServerインスタンスのAzureリソースが自動作成される点です。手動接続は「Arc接続済みだがSQL Server用拡張機能が自動展開されていない」ケースで使う手順として位置付けられています。(Microsoft Learn)
SQL Server enabled by Azure Arcとは何か
SQL Server enabled by Azure Arcは、オンプレミス、エッジ拠点、他社クラウド、ホスティング環境など、Azure外で動作しているSQL ServerをAzureの管理プレーンに接続する仕組みです。接続後は、SQL ServerそのものをAzureへ移行しなくても、Azureポータル上でSQL Serverの状態を確認し、運用・セキュリティ・移行評価に関する機能を利用しやすくなります。(Microsoft Learn)
重要なのは、これはAzure SQL DatabaseやAzure SQL Managed Instanceへ自動移行する機能ではないことです。既存のSQL Serverは引き続き現在の場所で稼働し、Azure Arcによって「Azureから管理できる状態」に拡張されます。
たとえば、次のような環境が対象になります。
| 環境 | Azure Arc接続後に期待できること |
|---|---|
| オンプレミスのSQL Server | Azureポータルからインベントリ、構成、ライセンス、セキュリティ状態を把握しやすくなる |
| AWSやGoogle Cloud上のSQL Server | マルチクラウド環境のSQL ServerをAzureの管理基盤に集約できる |
| エッジ拠点や小規模拠点のSQL Server | 拠点ごとの手作業管理を減らし、中央から可視化しやすくなる |
| Azure SQLへの移行を検討中のSQL Server | 移行評価や推奨構成の確認に使える |
SQL Server enabled by Azure Arcを導入する目的は、「今すぐクラウドへ移行すること」ではなく、分散しているSQL Serverを見える化し、管理・保護・移行判断をしやすくすることです。
今回のポイントは「自動接続」と「拡張機能」の扱い
公式情報で特に確認すべき変更点は、SQL Server用Azure拡張機能の扱いです。Azure Arcに接続されたサーバーにSQL Serverがインストールされている場合、Azure ArcはSQL Server用Azure拡張機能を自動的にインストールし、SQL ServerインスタンスをAzure上のリソースとして作成します。(Microsoft Learn)
これにより、管理者の作業は「SQL Serverごとに個別登録する」よりも、「サーバーをAzure Arcへ正しく接続し、拡張機能とライセンス設定を確認する」方向へ変わります。
何が変わるのか
| 観点 | 従来ありがちだった運用 | Azure Arc接続後に意識すべき運用 |
|---|---|---|
| SQL Serverの把握 | 台帳、Excel、監視ツールごとに情報が分散 | Azure上のSQL Server – Azure Arcリソースとして確認 |
| 接続作業 | サーバー単位・インスタンス単位で手作業になりやすい | Arc接続とSQL Server用拡張機能の展開状態を確認 |
| 新規インスタンス検出 | 管理者が追加インストールを把握する必要がある | 拡張機能が継続的に構成変更を検出し、登録する動作がある |
| ライセンス | 現場ごとの申告・管理になりやすい | PAYG、Paid、LicenseOnlyなどのライセンス種別をAzure側で設定 |
| 移行検討 | 別ツールで調査し直すことが多い | Azure SQLへの移行評価の入口として使える |
既にAzure Arc対応サーバーになっているマシンでSQL Server用拡張機能を手動インストールした場合、ArcマシンリソースにArcSQLServerExtensionDeployment = Disabledタグが作成される点も見落としやすいポイントです。自動展開を前提に運用するのか、手動管理にするのかを運用ルールとして決めておきましょう。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
SQL Server enabled by Azure Arcの接続は、DBAだけの作業ではありません。Azure管理者、ネットワーク管理者、セキュリティ担当、アプリケーション開発者にも影響します。
| 担当者 | 確認すべきこと |
|---|---|
| DBA | SQL Serverバージョン、エディション、インスタンス名、データベース状態、サービスアカウント権限 |
| Azure管理者 | サブスクリプション、リソースグループ、リージョン、リソースプロバイダー、RBAC |
| ネットワーク管理者 | outbound 443、プロキシ、許可URL、Azure Arc Data Processing Serviceへの接続 |
| セキュリティ担当 | Defender for Cloud、Microsoft Entra認証、最小権限、監査ログ、接続経路 |
| 開発者 | 接続後にアプリケーションの接続先が変わるわけではないが、移行評価や互換性確認の結果を確認 |
| 情シス・IT企画 | ライセンス種別、PAYG、Software Assurance、ESU、Azure SQL移行方針 |
特に大規模環境では、「接続できるか」よりも「接続後に誰がどのリソースを管理するか」が問題になります。リソースグループ、タグ、命名規則、権限設計を先に決めないと、Azure上に作成されたSQL Server – Azure Arcリソースが後から整理しにくくなります。
接続前に確認すべき前提条件
SQL Server enabled by Azure Arcを展開する前に、最低限以下を確認します。
| 確認項目 | 実務上のチェックポイント |
|---|---|
| Azureサブスクリプション | 有効なサブスクリプションがあるか |
| リソースプロバイダー | Microsoft.AzureArcDataとMicrosoft.HybridComputeが登録済みか |
| 権限 | サブスクリプションの読み取り権限、対象OSのローカル管理者権限、必要なAzure RBACがあるか |
| SQL Serverの状態 | 管理対象にしたいデータベースがオンラインかつ更新可能か |
| SQL Serverサービスアカウント | 各SQL Serverインスタンスで必要な権限を満たしているか |
| ネットワーク | Azure Arc関連エンドポイントへHTTPS 443でアウトバウンド接続できるか |
| プロキシ | プロキシ環境の場合、除外設定や許可URLを整理しているか |
| OSとSQL Serverバージョン | サポート対象のOS、64ビットSQL Server、SQL Server 2012以降か |
公式前提条件では、Azure Arc接続前にAzure Connected Machine Agentの前提条件、ネットワーク要件、Azure Arc Data Processing Serviceへの通信、リソースプロバイダー登録などを確認する必要があります。SQL Server enabled by Azure ArcはSQL Server 2012以降の64ビット版を対象とし、Windowsと一部Linux環境に対応しています。(Microsoft Learn)
リソースプロバイダーの登録確認
Azure側では、少なくとも次のリソースプロバイダーを確認します。
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.AzureArcDataAzure CLIを使う場合は、次のように登録できます。
az provider register --namespace Microsoft.HybridCompute
az provider register --namespace Microsoft.AzureArcData既存のサブスクリプションでも、これらが未登録だとオンボード時に失敗します。複数サブスクリプションを使っている企業では、検証環境だけ登録済みで本番環境は未登録、というケースもあるため注意してください。
ネットワークで失敗しやすいポイント
Azure Arc接続で最もつまずきやすいのは、SQL Server側の設定よりもネットワークです。
SQL Server enabled by Azure Arcでは、Azure Arc Data Processing Serviceへのアウトバウンド接続が必要です。公式前提条件では、リージョン別の*.<region>.arcdataservices.comへの443番ポート通信が必要とされています。US Government Virginiaでは別ドメインが使われます。(Microsoft Learn)
確認すべき代表例は次の通りです。
| 項目 | 確認内容 |
|---|---|
| outbound 443 | 対象サーバーからAzure関連エンドポイントへHTTPS通信できるか |
| プロキシ | 認証プロキシ、SSLインスペクション、例外設定がArc通信を妨げていないか |
| DNS | Azure関連FQDNを解決できるか |
| リージョン | Arc-enabled ServerとArc-enabled SQL Serverで同じリージョンを使う設計か |
| Private Link | Azure Arc Data Processing Serviceの該当エンドポイントではPrivate Link接続がサポートされない構成があるため、公式前提条件を確認する |
プロキシ配下のサーバーでは、ポータルで生成したオンボードスクリプトにプロキシ情報を含める運用が現実的です。ただし、プロキシを通さない通信先がある場合は、NO_PROXY環境変数などの扱いも含めてネットワークチームと事前にすり合わせてください。
接続手順の全体像
SQL ServerをAzure Arcに接続する流れは、大きく分けて2パターンです。
| パターン | 使う場面 | 主な作業 |
|---|---|---|
| サーバーがまだAzure Arc未接続 | オンプレミスや他クラウドのSQL Serverを初めてArc管理下に置く | Azureポータルでオンボードスクリプトを生成し、対象サーバーで実行 |
| サーバーは既にAzure Arc接続済み | Arc対応サーバーだがSQL Server用Azure拡張機能が入っていない | Azure Arc > Serversの拡張機能からSQL Server用Azure拡張機能を追加 |
公式手順では、サーバーが未接続の場合、Azureポータルからオンボードスクリプトを生成します。このスクリプトはAzure Connected Machine Agentをインストールし、サーバーをServer - Azure Arcリソースとして登録したうえで、SQL Server用Azure拡張機能によってSQL ServerインスタンスをSQL Server - Azure Arcリソースとして接続します。(Microsoft Learn)
新規にArc接続する場合の流れ
| 手順 | 作業 |
|---|---|
| 1 | AzureポータルでAzure Arcを開く |
| 2 | データサービスからSQL serversを選択し、SQL Serverインスタンスの追加へ進む |
| 3 | サブスクリプション、リソースグループ、リージョン、OSを指定する |
| 4 | 必要に応じてプロキシ、サーバー名、タグを設定する |
| 5 | SQL Serverエディションとライセンス種別を選択する |
| 6 | 登録から除外するSQL Serverインスタンスがあれば指定する |
| 7 | オンボードスクリプトを生成・ダウンロードする |
| 8 | 対象サーバーで管理者権限によりスクリプトを実行する |
| 9 | Azure Arc > SQL Serverで登録されたリソースを確認する |
Windowsでは、管理者権限のPowerShellでスクリプトを実行します。
& '.\RegisterSqlServerArc.ps1'Linuxでは、実行権限を付与してスクリプトを実行します。
sudo chmod +x ./RegisterSqlServerArc.sh
./RegisterSqlServerArc.sh本番環境では、いきなり全台に展開せず、代表的なOS、SQL Serverバージョン、ネットワークセグメントを選んで先行検証することをおすすめします。
既にAzure Arc接続済みのサーバーで確認すること
既にAzure Arcに接続されているサーバーにSQL Serverがある場合は、SQL Server用Azure拡張機能が展開されているかを確認します。拡張機能は、AzureポータルのServer - Azure Arcリソースの拡張機能タブから追加できます。(Microsoft Learn)
このとき特に重要なのが、リソースグループとリージョンです。SQL Serverインスタンスを表すSQL Server - Azure Arcリソースは、Arc-enabled Serverと同じリージョン、同じリソースグループを使う点に注意してください。(Microsoft Learn)
既存Arcサーバーでのチェックリスト
| 項目 | 確認内容 |
|---|---|
| 拡張機能 | WindowsAgent.SqlServerまたはLinux向けSQL Server拡張機能があるか |
| リソースグループ | Arc-enabled ServerとSQL Server – Azure Arcリソースが同じ管理単位にあるか |
| ライセンス種別 | PAYG、Paid、LicenseOnlyのどれを使うか |
| 除外インスタンス | 登録したくないインスタンスを明示できているか |
| 自動検出 | 新しいSQL Serverインスタンスが追加された場合の登録ルールを把握しているか |
| タグ | コスト管理、環境、本番・検証、担当部署などのタグを付けるか |
拡張機能はインストール後、SQL Server構成の変更を継続的に検出します。たとえば同じマシンに新しいSQL Serverインスタンスが追加された場合、拡張機能が検出してAzure Arcへ登録する動作があります。運用チームは「意図せずAzure側にリソースが増えた」と誤解しないよう、事前に説明しておくべきです。(Microsoft Learn)
ライセンス設定で注意すべき点
SQL Server enabled by Azure Arcでは、接続時にSQL Serverのエディションとライセンス種別を指定します。設定可能なライセンス種別として、公式手順ではPAYG、Paid、LicenseOnlyが示されています。(Microsoft Learn)
| ライセンス種別 | 考え方 |
|---|---|
| PAYG | Azure経由の従量課金を使う場合 |
| Paid | Software AssuranceやSQL Serverサブスクリプションなど、有償の権利を前提にする場合 |
| LicenseOnly | 既存ライセンスの把握・管理を主目的にする場合 |
ライセンス設定はコストとコンプライアンスに直結します。技術担当者だけで決めず、契約管理部門やライセンス担当と確認してから本番展開してください。
また、Azure Arc対応SQL Serverの一部機能は、Software Assurance付きライセンスやAzureの従量課金モデルなど、ライセンス条件によって利用可否が変わります。たとえばベストプラクティス評価、移行評価、Defender、Purview、自動更新などは、OS、SQL Serverバージョン、エディション、ライセンス種別の影響を受けるため、導入前に機能別の対応表を確認する必要があります。(Microsoft Learn)
管理者が展開前に確認すべき設定
本番展開前に、以下の項目を設計書やチェックリストに落とし込んでください。
| 分類 | 確認項目 | 失敗しやすいポイント |
|---|---|---|
| Azure設計 | サブスクリプション、リソースグループ、リージョン | 検証環境と本番環境で登録先が混在する |
| 権限 | Azure RBAC、ローカル管理者権限、サービスプリンシパル | Contributorを広く付けすぎる、または権限不足で失敗する |
| SQL Server | インスタンス名、エディション、バージョン、サービス状態 | 停止中・読み取り専用DBが管理対象に入らない |
| セキュリティ | NT AUTHORITY\SYSTEM、サービスアカウント、最小権限 | セキュリティ強化済み環境で拡張機能のプロビジョニングに失敗する |
| ネットワーク | outbound 443、プロキシ、DNS、許可URL | プロキシ配下で認証やSSL検査により通信できない |
| 運用 | 自動更新、拡張機能バージョン、監視 | 古い拡張機能を放置し、サポート対象外になる |
| ガバナンス | タグ、命名規則、コスト配賦 | 登録後にリソースが増え、所有者不明になる |
特にNT AUTHORITY\SYSTEMの扱いは、セキュリティ強化されたSQL Server環境で問題になりやすい項目です。公式前提条件では、Azure extension for SQL Server DeployerがLocalSystemアカウントで動作し、Windows統合認証でSQL Serverへ接続することが説明されています。ログインが無効化されていたり、CONNECT SQLが拒否されていたりすると、プロビジョニングに失敗する可能性があります。(Microsoft Learn)
開発者が知っておくべき影響
SQL ServerをAzure Arcに接続しても、通常はアプリケーションの接続文字列やDB接続先が自動的に変わるわけではありません。アプリケーションから見たSQL Serverは、引き続き同じ場所で稼働します。
ただし、開発者にも無関係ではありません。Azure Arc接続後は、移行評価、ベストプラクティス評価、クライアント接続サマリーなどにより、アプリケーション側の改修判断に必要な情報が見えやすくなるためです。
開発チームが確認すべきポイントは次の通りです。
| 項目 | 確認理由 |
|---|---|
| 利用中のSQL Serverバージョン | Azure SQL移行時の互換性判断に必要 |
| 利用機能 | SQL Server固有機能、エージェントジョブ、リンクサーバー、CLRなどの移行影響を確認 |
| 接続元アプリケーション | クライアント接続サマリーや監視情報を使い、依存関係を整理 |
| 認証方式 | Microsoft Entra認証を検討する場合、既存認証との違いを確認 |
| 移行評価結果 | Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VMのどれが適切か判断する材料にする |
Azure Arc接続は、移行プロジェクトの「調査フェーズ」を短縮するための土台になります。接続しただけで移行が完了するわけではありませんが、移行前の棚卸しと評価を継続的に行える点は大きなメリットです。
Azure SQLへの移行を見据えた使い方
SQL Server enabled by Azure Arcは、Azure SQLへの移行検討にも役立ちます。公式情報では、移行評価によりクラウド移行の準備状況、リスク、緩和策、Azure SQL構成の推奨などを確認でき、既定では週1回の継続的な評価が実行されると説明されています。(Microsoft Learn)
移行先を検討する際は、次のように使い分けると整理しやすくなります。
| 移行先候補 | 向いているケース |
|---|---|
| Azure SQL Database | データベース単位でPaaS化したい、運用負荷を減らしたい |
| Azure SQL Managed Instance | SQL Serverとの互換性を重視しつつPaaS化したい |
| SQL Server on Azure VM | OSやSQL Serverインスタンス単位の制御を残したい |
| 当面は現状維持 | すぐに移行せず、Arcで可視化・保護・評価だけ先に進めたい |
2026年時点のリリースノートでは、Azure extension for SQL Serverのバージョン1.1.3348.364以降でManaged Instance linkによる複数データベース移行を同時に行えるようになり、最大10データベースまで同時移行できるとされています。Azure SQL Managed Instanceへの移行を検討している場合は、拡張機能バージョンの確認が重要です。(Microsoft Learn)
拡張機能のバージョンと更新管理
SQL Server enabled by Azure Arcでは、Azure extension for SQL Serverのバージョン管理も重要です。公式リリースノートでは、拡張機能のバージョンは累積的であり、上位バージョンには以前の更新が含まれること、また直近1年以内にリリースされたバージョンのみがサポート対象とされています。(Microsoft Learn)
現在のバージョン確認には次のコマンドを使います。
azcmagent versionAzureポータルから確認する場合は、Machines - Azure Arcで対象マシンを開き、ExtensionsからSQL Server用拡張機能を確認します。手動更新も可能ですが、運用負荷を下げるには自動更新の有効化を検討してください。(Microsoft Learn)
更新管理で決めておくこと
| 項目 | 推奨する運用 |
|---|---|
| 更新方針 | 自動更新を基本にするか、検証後に段階展開するか決める |
| 検証環境 | 本番と同じOS・SQL Server構成の代表環境で先行確認する |
| 変更管理 | 拡張機能更新日、影響確認、ロールバック手順を記録する |
| 監視 | 更新後にSQL Server – Azure Arcリソース、ログ、監視状態を確認する |
| リリースノート確認 | 新機能だけでなく、利用停止バージョンやプレビュー機能も確認する |
拡張機能が古いままだと、新しい管理機能や移行機能を使えないだけでなく、サポート範囲から外れるリスクもあります。Azure Arcを導入した後は、接続完了で終わらせず、拡張機能のライフサイクル管理まで運用に含めましょう。
サポート対象外・注意すべき構成
展開前には、サポート対象外の構成も確認が必要です。公式前提条件では、SQL Server in containers、SQL Server 2008/R2以前、Azure VM上のSQL Server、同じホストOS上に同じインスタンス名の複数SQL Serverがある構成など、サポートされない構成が示されています。(Microsoft Learn)
実務で特に注意したいのは次のケースです。
| 構成 | 注意点 |
|---|---|
| Azure VM上のSQL Server | Azure ArcではなくSQL Server IaaS Agent extensionの管理対象になるケースがある |
| Windows Server 2012/2012 R2 | OSサポートやTLS、テレメトリエンドポイントの制約に注意 |
| コンテナ上のSQL Server | 現時点ではAzure Arc-enabled SQL Serverの対象外 |
| インスタンス名に特殊文字がある | #を含むSQL Serverインスタンス名などはサポート対象外 |
| データベース名の末尾に空白がある | 照合順序によって拡張機能の管理対象からスキップされる可能性がある |
| AVS上のSQL Server | Azure VMware Solution向けの専用手順を確認する |
「インストールできたからサポート対象」とは限りません。サポート対象外の構成で本番導入すると、後から監視、評価、移行、課金管理で問題が出る可能性があります。
本番展開の進め方
SQL Server enabled by Azure Arcは、1台ずつ試すだけなら難しくありません。しかし、本番展開では台数、権限、ネットワーク、ライセンス、タグ設計が絡むため、段階的に進めるべきです。
推奨する展開ステップ
| フェーズ | 作業内容 |
|---|---|
| 調査 | SQL Server台帳、OS、バージョン、エディション、設置場所、所有者を整理 |
| 設計 | サブスクリプション、リソースグループ、リージョン、タグ、RBACを決定 |
| 事前確認 | リソースプロバイダー、ネットワーク、プロキシ、権限、SQL Server状態を確認 |
| パイロット | 代表的な数台でオンボードし、リソース作成と監視を確認 |
| 評価 | ライセンス表示、移行評価、Defender、ベストプラクティス評価の結果を確認 |
| 段階展開 | 部門・拠点・環境ごとに展開し、例外を記録 |
| 運用化 | 拡張機能更新、タグ監査、コスト確認、セキュリティ推奨事項の処理を定常化 |
台数が多い場合は、Azureポータルで手作業するよりも、スクリプト、Configuration Manager、Ansibleなどの自動化と組み合わせる方が現実的です。公式のデプロイオプションでも、単一マシンの対話的な接続だけでなく、PowerShellスクリプトやConfiguration Managerを使った大規模展開が案内されています。(Microsoft Learn)
よくある失敗と対策
接続後にSQL Serverリソースが見えない
まず、Azure Arc > SQL Serverで登録済みリソースを確認します。次に、対象マシンのAzure Arc拡張機能でSQL Server用Azure拡張機能が正常に入っているかを見ます。SQL Serverサービスが停止している、対象データベースがオンラインでない、権限不足、ネットワーク遮断なども原因になります。
ライセンス種別を適当に選んでしまう
PAYG、Paid、LicenseOnlyはコストや利用権に関わります。検証では仮設定に見えても、本番登録後は課金やコンプライアンス確認の対象になり得ます。展開前にライセンス担当者と判断基準を決めてください。
プロキシ環境でオンボードが失敗する
Azure Arcはアウトバウンド通信を使いますが、企業ネットワークではプロキシ認証、SSLインスペクション、FQDN制限が原因で失敗することがあります。オンボードスクリプト生成時にプロキシ設定を含め、必要なURLとポートをネットワークチームに依頼してください。
自動登録されたインスタンスに驚く
SQL Server用Azure拡張機能は、インストール済みSQL Serverインスタンスを認識し、構成変更も検出します。新しく追加されたインスタンスがAzure Arc側に表示されることがあるため、除外インスタンスの指定や命名規則を決めておくことが重要です。
Azure SQLへの移行機能と混同する
Azure Arc接続は移行そのものではありません。移行評価や移行準備には役立ちますが、実際のデータ移行、切り替え、アプリ改修、性能検証は別工程です。Azure SQL Managed InstanceやAzure SQL Databaseへ移行する場合は、評価結果をもとに個別の移行計画を作成してください。
まず管理者が取るべき次の行動
SQL Server enabled by Azure Arcを検討しているなら、最初にやるべきことはオンボードスクリプトの実行ではありません。まず、管理対象にしたいSQL Serverの棚卸しと、Azure側の受け皿設計を行うことです。
実務では、次の順番で進めると失敗を減らせます。
| 順番 | やること |
|---|---|
| 1 | 管理対象のSQL Server一覧を作る |
| 2 | OS、SQL Serverバージョン、エディション、インスタンス名を確認する |
| 3 | サブスクリプション、リソースグループ、リージョン、タグ方針を決める |
| 4 | リソースプロバイダーとRBACを確認する |
| 5 | ネットワークとプロキシの疎通条件を確認する |
| 6 | 検証環境でオンボードし、SQL Server – Azure Arcリソースを確認する |
| 7 | ライセンス、拡張機能更新、監視、移行評価の運用手順を決める |
| 8 | 本番環境へ段階的に展開する |
SQL Server enabled by Azure Arcは、Azure SQL移行の前段としても、ハイブリッド環境の統制基盤としても有効です。接続作業そのものより、接続後のリソース管理、ライセンス判断、拡張機能の更新、移行評価の活用まで含めて設計することが、導入成功の分かれ目です。
コメント