2026年4月28日の Azure 公式ドキュメント更新「Add at-scale query execution via Run Command to Azure Arc SQL Server docs」でまず確認すべき点は、Azure Arc SQL Server の運用が「インベントリを確認する」だけでなく、Run Command を使って複数の Arc 対応サーバー上でカスタム T-SQL を実行し、結果を集中管理する運用パターンまで明文化されたことです。特に developers、cloud admins、solution architects、technical decision makers は、仕様追加そのものよりも、権限設計・監査・ネットワーク・Log Analytics 連携への影響を先に確認する必要があります。
この更新は、単なる説明文の追記ではありません。MicrosoftDocs/sql-docs の該当コミットでは、overview.md と security-overview.md の2ファイルが変更され、65行追加・3行削除されています。overview.md では ms.date が 2026年4月28日に更新され、Microsoft Learn の該当ページも最終更新日が 2026年4月28日になっています。(GitHub)
今回の更新で何が変わったか
今回の Azure 公式ドキュメント更新の要点は、Azure Arc enabled SQL Server における「at-scale query execution」、つまり複数環境にまたがる SQL Server へ横断的にクエリを実行する考え方が、Run Command と結び付けて説明された点です。
従来の Azure Arc SQL Server の説明では、インベントリ、ベストプラクティス評価、移行評価、Microsoft Defender for Cloud、Microsoft Purview などの管理・可視化機能が中心でした。更新後は、オンボード済みインスタンスに対して Run Command を使い、権限、構成、コンプライアンス状況などを確認するカスタム T-SQL スクリプトを実行し、その結果を中央に集約するユースケースが明記されています。(Microsoft Learn)
| 変更箇所 | 追加・強調された内容 | 実務で確認すべきこと |
|---|---|---|
| Overview | Run Command によるカスタム T-SQL の横断実行 | どの SQL Server に対して、誰が、どのクエリを実行できるか |
| Performance dashboards 周辺 | Logs Ingestion API で投入したカスタムテーブルを KQL ダッシュボードやアラートに活用 | Log Analytics のテーブル設計、保持期間、アクセス権 |
| Custom data collection pipeline | Automation Runbook、ARM API、Run Command、Logs Ingestion API を組み合わせた収集パイプライン | 自動化 ID、DCR/DCE、監査ログ、ネットワーク許可 |
| Security overview | Run Command は SQL Server 拡張機能そのものではなく、Microsoft.HybridCompute 経由の機能である点 | SQL Server 権限だけでなく、Arc-enabled server 側の RBAC を確認 |
| Best practices | Run Command を使う場合の最小権限、DCR/DCE の RBAC、カスタム Log Analytics テーブル監視 | 本番環境での一括実行前にガードレールを設計 |
重要なのは、今回の更新を「新しいボタンが Azure Portal に追加された」と読むのではなく、Azure Arc SQL Server の運用設計に、横断的なスクリプト実行とログ集約を組み込むための公式な参照材料が増えたと捉えることです。
Run Command は SQL Server 拡張機能ではなく Arc-enabled servers の機能
今回の更新で誤解しやすいのが、Run Command の位置付けです。
公式ドキュメントでは、Azure Extension for SQL Server が自動データ収集や構成コマンドを扱う一方、カスタムスクリプトを大規模に実行する場合は、別機能である Azure Arc-enabled servers Run Command がホストマシン上でスクリプトを実行すると説明されています。さらに、カスタム T-SQL の横断実行は SQL Server 拡張機能から直接実現されるのではなく、Microsoft.HybridCompute リソースプロバイダー経由で行われると明記されています。(Microsoft Learn)
この違いは、権限設計に直結します。SQL Server のログイン権限だけを見ても不十分で、Azure RBAC、Arc-enabled server の Run Command 権限、ホスト OS 上の実行コンテキスト、スクリプト内で使う SQL 認証方式までまとめて確認しなければなりません。
| 確認項目 | 正しい理解 | 見落とした場合のリスク |
|---|---|---|
| 実行基盤 | Azure Arc-enabled servers Run Command | SQL Server 側だけで権限制御したつもりになる |
| リソースプロバイダー | Microsoft.HybridCompute | Azure RBAC の対象を誤る |
| 実行対象 | Arc に接続されたホストマシン | OS 権限で想定外の操作が可能になる |
| SQL 実行 | スクリプト内で T-SQL を呼び出す | 接続先インスタンスや認証方式の管理が必要 |
| 結果集約 | Log Analytics やストレージなどへ送信 | 出力制限、機密情報、保持期間を見落とす |
仕様確認で最初に見るべきポイント
Run Command の対応範囲
Azure Arc-enabled servers Run Command は、Azure Arc に接続された VM に対して、RDP や SSH で直接接続せずにスクリプトやコマンドを実行する機能です。Azure CLI、PowerShell、REST API から利用でき、Windows と Linux、オンプレミス、VMware、AWS、GCP、OCI などの Arc 接続環境に対応すると説明されています。(Microsoft Learn)
ただし、Run Command のドキュメント上では preview とされており、Azure Portal からは現在利用できないという注意書きもあります。運用手順書を作る場合は、Portal 操作を前提にせず、Azure CLI、PowerShell、REST API のどれを標準手段にするか決めておく必要があります。(Microsoft Learn)
エージェントと拡張機能の前提
Run Command は Connected Machine agent に組み込まれており、公式ドキュメントでは version 1.33 以降から利用できると説明されています。SQL Server enabled by Azure Arc 側では、Azure Extension for SQL Server は直近1年以内にリリースされたバージョンのみがサポート対象とされています。(Microsoft Learn)
移行準備や運用展開の前に、次のように棚卸ししてください。
| 確認対象 | 確認内容 | 判断基準 |
|---|---|---|
| Connected Machine agent | Run Command を使えるバージョンか | 古い場合は検証環境で更新手順を確認 |
| Azure Extension for SQL Server | サポート対象の範囲内か | 本番適用前に拡張機能の更新計画を立てる |
| Arc-enabled server と Arc-enabled SQL Server | リージョン整合性 | 公式ドキュメントでは同一リージョン割り当てが重要とされる |
| OS と SQL Server | 対応構成か | Linux/Windows、SQL Server バージョン、接続方式を確認 |
| ネットワーク | Azure Arc と Log Analytics への送信経路 | プロキシ、Private Link、アウトバウンド443を確認 |
運用影響は「便利になる」より「強い権限をどう統制するか」が重要
Run Command は運用効率を大きく高めます。各サーバーに個別ログインせず、複数環境で構成確認、ヘルスチェック、コンプライアンス確認を実行できるからです。一方で、実行権限を広く付与すると、事実上のリモート管理権限になります。
公式ドキュメントでは、Run Command の実行は Windows では Local System、Linux では root として行われるため、OS と SQL Server インスタンスに対して強いアクセス権を持つと説明されています。また、Run Command のアクティビティは Azure Activity Logs に記録されるため、監査対象として扱うべきです。(Microsoft Learn)
| 影響領域 | 確認すべき内容 | 推奨アクション |
|---|---|---|
| Azure RBAC | 誰が Run Command を実行できるか | 専用カスタムロールまたは最小権限ロールを検討 |
| OS 権限 | Local System/root 実行の影響 | 実行スクリプトを読み取り専用から開始 |
| SQL 権限 | どのログインで T-SQL を実行するか | sysadmin 前提にしない。用途別の SQL 権限を設計 |
| 監査 | 実行履歴を追跡できるか | Azure Activity Logs と Log Analytics アラートを設定 |
| 機密情報 | クエリ結果に個人情報や認証情報が含まれないか | 収集項目をホワイトリスト化 |
| 変更管理 | 本番全台に一括実行してよいか | カナリア実行、段階展開、承認フローを用意 |
特に cloud admins は、Run Command の実行権限を「サーバー管理者なら全員に付与」で済ませないことが重要です。公式ドキュメントでは、Run Command の読み取りには Microsoft.HybridCompute/machines/runCommands/read、実行には Microsoft.HybridCompute/machines/runCommands/write が関係し、実行権限は Azure Connected Machine Resource Administrator 以上のロールで付与されると説明されています。(Microsoft Learn)
カスタム T-SQL 実行で向いている用途・向いていない用途
今回の更新は、Run Command で何でも一括実行することを推奨しているわけではありません。実務では、まず読み取り中心の確認から始めるのが安全です。
| 用途 | 向き・不向き | 理由 |
|---|---|---|
| 権限棚卸し | 向いている | ログイン、ロール、権限差分を中央で確認できる |
| バックアップ状況確認 | 向いている | 未バックアップ DB の検出に使いやすい |
| 暗号化状況確認 | 向いている | TDE などの状態を横断的に集約しやすい |
| 構成ドリフト検出 | 向いている | サーバー間の設定差分を可視化できる |
| 大量データ抽出 | 不向き | 出力制限、ネットワーク、Log Analytics コストの問題が出やすい |
| DDL/DML の一括変更 | 慎重に扱う | 影響範囲が大きく、ロールバック設計が必要 |
| 認証情報の配布 | 避けるべき | シークレット漏えいのリスクが高い |
たとえば、最初の検証では次のような読み取り専用の確認に絞ると安全です。
SET NOCOUNT ON;
SELECT
@@SERVERNAME AS ServerName,
name AS DatabaseName,
is_encrypted AS IsEncrypted,
state_desc AS StateDescription
FROM sys.databases
WHERE database_id > 4;このようなクエリでも、本番では「どのインスタンスで実行するか」「結果に機密情報が含まれないか」「失敗時にどう扱うか」を事前に決めてください。横断実行では、1台で問題ないクエリが100台では運用事故につながることがあります。
Log Analytics 連携で確認すべきポイント
今回の更新では、Run Command で得た結果を Azure Monitor Log Analytics に送るカスタムデータ収集パイプラインも説明されています。公式ドキュメントでは、Azure Automation Runbook で Arc-enabled SQL Server リソースを列挙し、Run Command で各ホスト上の T-SQL を実行し、結果を処理して、Data Collection Endpoint と Data Collection Rule を使い Logs Ingestion API 経由で Log Analytics に送る流れが示されています。(Microsoft Learn)
Logs Ingestion API は、REST API またはクライアントライブラリから Log Analytics ワークスペースへデータを送信でき、カスタムテーブルにも対応します。DCR は受信データの構造や変換、送信先ワークスペースを制御する役割を持つため、単なるログ送信先ではなく、データ品質とセキュリティの制御点として設計する必要があります。(Microsoft Learn)
カスタムテーブルを作る場合は、最初から分析しやすいスキーマにしておくと後工程が楽になります。
| カラム例 | 用途 |
|---|---|
TimeGenerated | 収集時刻 |
ArcMachineResourceId | Arc-enabled server の識別 |
SqlInstanceName | SQL Server インスタンス名 |
DatabaseName | 対象データベース |
CheckName | 権限確認、暗号化確認、バックアップ確認など |
Severity | Info、Warning、Critical など |
Finding | 検出内容 |
QueryVersion | 実行したクエリセットのバージョン |
ExecutionId | 一括実行単位の追跡 ID |
また、2026年3月1日以降、Logs Ingestion API では TLS 1.2 以上の接続が強制されると記載されています。古いプロキシ、古い OS、独自クライアントから送信している環境では、TLS 設定の確認も移行準備に含めるべきです。(Microsoft Learn)
実行結果の扱いで失敗しやすい点
Run Command の結果をそのまま標準出力で受け取る設計は、検証では便利ですが、本番の横断実行には向きません。Azure CLI の Run Command ドキュメントでは、instanceView の output と error は末尾4KBに制限されるため、完全な出力を得るには output blob や error blob への転送を使う方法が説明されています。(Microsoft Learn)
つまり、数十台・数百台の SQL Server から収集する設計では、最初から「結果をどこへ、どの形式で、どの権限で保存するか」を決めておく必要があります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 標準出力だけで結果を確認する | 出力が欠落する | Log Analytics または Blob への保存を設計 |
| JSON 形式を決めずに出力する | 後続の集計が困難 | スクリプト出力を JSON 化し、DCR で整形 |
| 機密情報をそのまま送る | ワークスペース閲覧者に漏れる | 収集項目を限定し、マスキングを行う |
| DCR/DCE の権限を広く付与する | 不正なログ投入や設定変更のリスク | DCR、DCE、Workspace の RBAC を分離 |
| 保持期間を未設定にする | コスト増や監査要件不備 | テーブル単位で保持期間を確認 |
| 失敗コードを監視しない | 一部サーバーの未収集に気付かない | 実行ステータスと未応答サーバーをアラート化 |
developers が確認すべき実装ポイント
developers が見るべきポイントは、Run Command の呼び出しそのものよりも、スクリプトと出力の品質です。
横断実行用のスクリプトは、通常の管理スクリプトよりも厳密に作る必要があります。対象サーバーが異なる OS、異なる SQL Server バージョン、異なるインスタンス構成を持つ可能性があるためです。
実装時は、次の基準でレビューしてください。
| 観点 | チェック内容 |
|---|---|
| 冪等性 | 同じスクリプトを再実行しても副作用がないか |
| 読み取り専用 | 初期段階では SELECT 系の確認に限定しているか |
| タイムアウト | 応答しない SQL Server で全体が止まらないか |
| エラー処理 | 接続失敗、権限不足、インスタンス不在を区別できるか |
| 出力形式 | JSON など、後続処理しやすい形式になっているか |
| バージョン管理 | クエリとスクリプトにバージョンを付けているか |
| シークレット | スクリプト内にパスワードやトークンを書いていないか |
Azure CLI で Run Command を実行する場合、公式ドキュメントでは az connectedmachine run-command create を使う例が示されています。実務では、以下のように検証用の読み取り専用スクリプトから始めると安全です。(Microsoft Learn)
az connectedmachine run-command create \
--resource-group "<resource-group>" \
--machine-name "<arc-enabled-machine>" \
--name "sql-readonly-check" \
--script "<read-only script that runs T-SQL and outputs JSON>"本番では、スクリプト本文をインラインで長く渡すより、レビュー済みのスクリプトを管理し、実行ログとバージョンを紐付ける設計が望ましいです。
cloud admins が確認すべき権限とネットワーク
cloud admins は、Run Command を「運用自動化機能」として許可する前に、リモート管理権限として扱う必要があります。公式セキュリティドキュメントでも、Run Command は直接 RDP や SSH を使わずに connected machine 上でスクリプトを実行できる一方、Local System または root の高い権限で動くため、意図しない権限昇格を避けるために厳格に認可を管理すべきとされています。(Microsoft Learn)
特に確認すべきネットワーク要件は、Arc の通信経路とログ投入経路です。SQL Server enabled by Azure Arc では Azure Arc Data Processing Service へのアウトバウンド通信が必要で、カスタムデータ収集で Azure Monitor Logs に送る場合は *.ingest.monitor.azure.com への接続も必要とされています。(Microsoft Learn)
| 領域 | 確認内容 |
|---|---|
| Azure RBAC | Run Command 実行権限を持つユーザー、グループ、サービス ID |
| ローカル制御 | Run Command が不要なサーバーではブロックリストや許可リストを検討 |
| プロキシ | Arc 通信と Logs Ingestion API の送信が通るか |
| Private Link | DCE が必要な構成か、既存 DCR が古くないか |
| Activity Logs | Run Command 実行履歴を監査できるか |
| Log Analytics | カスタムテーブルの閲覧権限と保持期間 |
| Key Vault | サービスプリンシパルを使う場合の資格情報保管 |
solution architects が設計すべき全体像
solution architects は、Run Command 単体ではなく、全体アーキテクチャとして考えるべきです。
推奨される構成は、次のような流れです。
| ステップ | 内容 | 設計上の判断 |
|---|---|---|
| 対象列挙 | ARM API で Arc-enabled SQL Server を取得 | サブスクリプション単位か、リソースグループ単位か |
| 実行 | Run Command で読み取り専用 T-SQL を実行 | 並列度、タイムアウト、対象除外条件 |
| 整形 | スクリプト出力を JSON 化 | DCR に合わせたスキーマ |
| 送信 | Logs Ingestion API で Log Analytics へ投入 | DCR endpoint か DCE か |
| 可視化 | KQL ダッシュボードとアラート | 運用チーム別のビュー |
| 監査 | Activity Logs と ExecutionId を突合 | 誰が、いつ、何を実行したか |
公式ドキュメントでは、自動化 ID について、Azure Automation Runbook ではサービスプリンシパル資格情報よりもマネージド ID を優先し、サービスプリンシパルを使う場合は Key Vault に資格情報を保存することが推奨されています。(Microsoft Learn)
technical decision makers が判断すべき導入価値
technical decision makers にとっての判断軸は、機能の新しさではなく、運用課題をどれだけ標準化できるかです。
Azure Arc SQL Server と Run Command の組み合わせは、次のような課題がある組織で価値が出やすいです。
| 課題 | 期待できる効果 |
|---|---|
| オンプレミス、マルチクラウド、エッジに SQL Server が分散している | 調査・監査の実行手順を統一しやすい |
| 権限棚卸しや構成確認が手作業 | 定期実行と Log Analytics 集約で可視化しやすい |
| 移行前の現状把握に時間がかかる | 移行評価に加えて、独自のチェック項目を補完できる |
| 監査証跡がサーバーごとに分散している | Azure Activity Logs と Log Analytics に集約しやすい |
| 運用チームごとにスクリプトが乱立している | クエリセットと実行権限を標準化できる |
一方で、Run Command は強力な遠隔実行機能です。導入価値を出すには、「誰でも便利に使える機能」ではなく、「承認されたスクリプトだけを、限定された対象に、監査可能な形で実行する仕組み」として設計する必要があります。
導入前の実務チェックリスト
本番適用前には、次の順序で確認すると抜け漏れを減らせます。
| 順序 | 作業 | 完了条件 |
|---|---|---|
| 1 | 対象 SQL Server と Arc-enabled server を棚卸し | 対象・除外対象・責任者が明確 |
| 2 | Connected Machine agent と SQL Server 拡張機能を確認 | サポート対象バージョンである |
| 3 | Run Command の RBAC を確認 | 実行権限が最小限に絞られている |
| 4 | SQL 側の実行権限を確認 | sysadmin 常用を避けた設計になっている |
| 5 | ネットワーク経路を確認 | Arc 通信と Logs Ingestion API が通る |
| 6 | カスタムテーブルと DCR を設計 | 収集データのスキーマが固定されている |
| 7 | 読み取り専用クエリで検証 | 小規模な対象で成功・失敗パターンを確認 |
| 8 | 監査とアラートを設定 | 実行者、対象、失敗、異常値を追跡できる |
| 9 | 段階展開 | 本番全体へ一括実行しない |
| 10 | 運用手順書に反映 | 実行条件、承認、ロールバックが文書化されている |
よくある誤解と注意点
Azure Extension for SQL Server だけで任意の T-SQL を横断実行できるわけではない
今回の更新では、カスタム T-SQL の横断実行は Azure Arc-enabled servers Run Command を使うと説明されています。SQL Server 拡張機能の通常のデータ収集や管理機能と、Run Command による任意スクリプト実行は分けて理解してください。(Microsoft Learn)
SQL Server の権限だけ見ても不十分
Run Command はホスト側で動くため、Azure RBAC と OS 上の実行権限が重要です。SQL Server のログイン権限が限定されていても、スクリプトの作り方や実行コンテキスト次第で想定外の操作につながる可能性があります。
Log Analytics に送るデータは監査データとして扱う
権限情報、構成情報、サーバー名、データベース名は、組織によっては機密性の高い情報です。カスタムテーブルに投入する前に、誰が閲覧できるか、どのくらい保持するか、アラート通知で外部に漏れないかを確認してください。
preview 表記の機能は運用前提を固定しすぎない
Run Command のドキュメントでは preview と表記されています。運用手順や自動化コードを作る場合は、API バージョン、サポート範囲、Portal 対応状況が変わる可能性を前提に、公式ドキュメントの更新を定期的に確認する運用にしてください。(Microsoft Learn)
まず取るべき次の行動
今回の Azure 公式ドキュメント更新で確認すべき結論は、Run Command による Azure Arc SQL Server の横断クエリ実行を、便利な自動化ではなく、強い権限を伴う運用基盤として設計することです。
最初の一歩としては、本番環境で一括実行するのではなく、次の3つを先に進めてください。
- 対象となる Arc-enabled SQL Server と Connected Machine agent の状態を棚卸しする
- Run Command の Azure RBAC、ローカル実行権限、SQL 実行権限を分けて設計する
- 読み取り専用の小さな T-SQL から始め、Log Analytics への集約と監査ログを検証する
この順序で進めれば、仕様確認、運用影響の整理、移行準備を同時に進められます。特にマルチクラウドやオンプレミスを含む SQL Server 環境では、今回の更新をきっかけに、Arc 経由の監査・可視化・自動化を標準化する価値があります。
コメント