Azure Data Explorer（ADX）クラスターで Model Context Protocol（MCP）Server を使うと、GitHub Copilot、Cline、Claude DesktopなどのAIクライアントから、自然言語でADXのデータ分析・スキーマ確認・KQL実行を行いやすくなります。2026年5月6日に更新されたMicrosoft Learnでは、この機能が プレビュー として案内されており、既存のADX運用を置き換えるというより、AIエージェントや開発環境からリアルタイムデータへ安全に接続するための新しい選択肢と捉えるのが適切です。(Microsoft Learn)
特に確認すべきなのは、MCP Serverの種類、接続先ADXクラスター、認証とRBAC、KQL実行権限、プレビュー機能としての運用範囲です。管理者は「誰がどのデータにAIクライアント経由でアクセスできるか」を明確にし、開発者は本番データへ接続する前に検証環境でプロンプト、クエリ、権限、ログ出力を確認しておく必要があります。
ADXクラスター向けMCP Server対応で何ができるようになるのか
今回のポイントは、Azure Data ExplorerとMCP Serverを組み合わせることで、AIエージェントがADXのデータソースにアクセスしやすくなる点です。Microsoft Learnでは、MCP ServerがAIエージェントやAIアプリケーションに対してツールを提供し、ADXクラスターへのクエリや分析を支援すると説明されています。(Microsoft Learn)
これにより、従来はKusto Query Language（KQL）を直接書いていた作業の一部を、自然言語の指示から始められるようになります。たとえば、次のような使い方が想定されます。
- 「直近1時間のエラー件数をサービス別に集計して」
- 「このデータベースにあるテーブル一覧を出して」
- 「StormEventsテーブルから10件サンプルを見せて」
- 「このKQLは重そうか、実行前に確認して」
- 「ADXクラスターのヘルスや容量面で問題がないか確認して」
ただし、自然言語で指示できるからといって、すべてをAI任せにしてよいわけではありません。特に本番環境では、AIが生成・実行するKQLの対象テーブル、抽出件数、集計条件、アクセス権限を人間が確認できる運用設計が重要です。
変更点の要点：ADXがAIエージェントの操作対象に入りやすくなった
2026年5月6日更新の公式情報で重要なのは、ADXクラスターをMCP Server経由でAIエージェントから扱う構成が明示されたことです。Microsoft Learnでは、Azure Data Explorer向けに利用できるMCP Serverとして、Fabric RTI MCP ServerとAzure MCP Serverが紹介されています。(Microsoft Learn)
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 機能の位置付け | プレビュー | 本番全面展開より先に検証・限定利用が前提 |
| 対象 | Azure Data Explorerクラスター、Fabric Real-Time Intelligence Eventhouseなど | リアルタイム分析基盤をAIエージェントから扱いやすくなる |
| 主な利用者 | 開発者、データエンジニア、SRE、運用担当、データ分析者 | KQLやADX操作に慣れていないメンバーも初期調査しやすい |
| 主な機能 | スキーマ探索、メタデータ確認、KQL実行、自然言語による分析支援 | 障害調査、ログ分析、IoTデータ分析、運用レポート作成に使える |
| 注意点 | 認証、RBAC、実行クエリ、機密データ、プロンプト管理 | AIクライアント経由の過剰アクセスを防ぐ設計が必要 |
この変更は「ADXの仕様が大きく変わる」というより、「AIエージェントからADXを扱うための公式な導線が整理された」と見ると分かりやすいです。既存のKQL、Azure Portal、ADX Web Explorer、SDKをすぐに置き換えるものではなく、調査・分析・開発支援の入口が増えたと考えるべきです。
利用できるMCP Serverは大きく2種類ある
公式情報では、Azure Data Explorerと連携するためのMCP Serverとして、主に次の2つが示されています。
| MCP Server | 向いている用途 | 主な確認ポイント |
|---|---|---|
| Fabric RTI MCP Server | ADXクラスターやFabric Real-Time Intelligence Eventhouseに対するリアルタイムデータ分析 | Kusto系ツール、Eventhouse、Eventstreams、Fabric連携を使いたい場合 |
| Azure MCP Server | AzureリソースとしてのADXクラスター、データベース、テーブル、クエリ操作 | Azure全体の運用・開発ツールとしてADXも扱いたい場合 |
Fabric RTI MCP Serverは、ADXクラスターやFabric RTI Eventhouseに対して、AIエージェントがKQLクエリ、スキーマ確認、サンプル取得、診断などを行うための実装です。GitHub上のMicrosoft公式リポジトリでは、Public Previewであり、一般提供前に実装が大きく変わる可能性があると明記されています。(GitHub)
一方、Azure MCP Serverは、Azureリソースを自然言語で操作・確認するためのMCP Serverです。Azure Data Explorer向けツールでは、クラスター一覧、クラスター詳細、データベース一覧、テーブル一覧、テーブルスキーマ取得、サンプルデータ取得、KQLクエリ実行などが案内されています。(Microsoft Learn)
Azure MCP ServerでADXに対してできる主な操作
Azure MCP ServerのAzure Data Explorer向けツールでは、管理・調査・クエリ実行に必要な基本操作がまとまっています。特に、開発者が「どのクラスターにどのデータベースがあり、どのテーブルをどう分析すればよいか」を把握する初期調査に向いています。
| 操作 | できること | 活用例 |
|---|---|---|
| クラスター一覧取得 | サブスクリプション内のADXクラスターを一覧表示 | 複数環境のADX棚卸し |
| クラスター詳細取得 | 指定したADXクラスターの情報を確認 | 検証環境と本番環境の設定確認 |
| データベース一覧取得 | クラスター内のデータベースを確認 | 分析対象DBの特定 |
| テーブル一覧取得 | データベース内のテーブルを確認 | ログ、メトリック、イベントテーブルの探索 |
| テーブルスキーマ取得 | カラム名や型を確認 | KQL作成前の構造把握 |
| サンプルデータ取得 | 指定テーブルから少量のデータを取得 | データ形式、値の傾向、欠損の確認 |
| KQLクエリ実行 | 指定したKQLをADXに対して実行 | エラー分析、利用傾向分析、性能調査 |
Azure MCP Serverでは、ADXツールの条件付きパラメーターとして、クラスターURIを指定する方法、またはクラスター名とサブスクリプションを指定する方法が示されています。クラスターURI、クラスター名、サブスクリプションをすべて同時に渡すと入力が競合するため、接続情報の指定方法をチーム内で統一しておくと混乱を防げます。(Microsoft Learn)
Fabric RTI MCP Serverで使えるKusto系ツール
Fabric RTI MCP Serverでは、Eventhouse（Kusto）向けに複数のツールが用意されています。MicrosoftのGitHubリポジトリでは、kusto_query、kusto_command、kusto_list_entities、kusto_describe_database、kusto_sample_entity、kusto_show_queryplan、kusto_diagnosticsなどが紹介されています。(GitHub)
実務で特に便利なのは、次のような用途です。
KQLを書く前にスキーマを確認する
自然言語で「このデータベースのテーブル構成を教えて」と依頼し、テーブルやカラムを確認してからKQLを作れます。初めて触るADX環境では、テーブル名やカラム名を推測して間違えることが多いため、最初にスキーマを確認するだけでも作業ミスを減らせます。
サンプルデータで値の形式を確認する
ログ分析では、同じ「ユーザーID」でも UserId、user_id、PrincipalId など名前が異なる場合があります。サンプルデータを確認してからクエリを組むことで、条件ミスや集計ミスを防ぎやすくなります。
実行前にクエリプランを確認する
kusto_show_queryplan は、KQLを実行せずにクエリプランを確認する用途として説明されています。重いjoin、広範囲スキャン、フィルター不足などを事前に見つけるのに役立ちます。(GitHub)
クラスター診断を運用調査に使う
kusto_diagnostics は、容量、ノード、権限、内部診断、ワークロードグループ、取り込み失敗などをまとめて確認するツールとして紹介されています。障害調査や「重い分析ジョブを流してよいか」の事前確認に使えます。(GitHub)
影響範囲：管理者、開発者、データ分析者で見るべき点が違う
ADXクラスター向けMCP Serverの導入は、単なる開発ツール追加ではありません。AIクライアントがデータベースやKQL実行に関与するため、管理者、開発者、データ分析者それぞれに確認すべきポイントがあります。
| 立場 | 影響 | 確認すべきこと |
|---|---|---|
| Azure管理者 | AzureリソースやADXクラスターへのアクセス経路が増える | RBAC、サブスクリプション、テナント、監査ログ、利用端末 |
| ADX管理者 | KQL実行やスキーマ参照がAIクライアント経由で行われる | データベース権限、テーブル権限、クエリ負荷、取り込み影響 |
| 開発者 | GitHub CopilotやVS CodeからADXを調査しやすくなる | 接続先、MCP設定、KQLレビュー、検証環境の利用 |
| データ分析者 | 自然言語から分析を始められる | 集計条件、期間条件、サンプル件数、結果の妥当性 |
| セキュリティ担当 | 機密情報がAIツールの文脈に入る可能性がある | 秘密情報、個人情報、プロンプト、ログ、外部送信ポリシー |
特に重要なのは、MCP Serverが「AIに権限を与える」のではなく、実際には利用者の資格情報やマネージドID、RBACに基づいてAzureリソースへアクセスする点です。Azure MCP Serverのツール説明では、Azureユーザー資格情報またはマネージドIDを使い、Azure RBACでアクセスを制御すること、ローカルMCP Serverは組織内の開発者用途を意図していることが説明されています。(Microsoft Learn)
管理者が最初に確認すべき設定
管理者は、MCP Serverを導入する前に「便利になる作業」よりも「許可してよい操作」を先に整理するべきです。ADXにはログ、セキュリティイベント、IoTデータ、顧客行動データなど、機密性の高い情報が入っていることがあります。
RBACとADX側の権限を最小化する
まず、MCP Server経由で利用するユーザーやマネージドIDに、必要以上のロールを付けないことが重要です。検証では、最初から広い権限を付与するのではなく、読み取り中心の権限から始めます。
確認すべき項目は次のとおりです。
- 対象サブスクリプションを限定しているか
- 対象リソースグループを限定しているか
- ADXクラスター単位で権限を絞っているか
- データベースやテーブルレベルの権限が適切か
- 本番データに不要な開発者がアクセスできないか
- 管理コマンドを実行できるユーザーを制限しているか
自然言語で操作できる環境では、ユーザーが「軽い確認」のつもりで広範囲のクエリを実行する可能性があります。AIクライアントの利便性を前提に、権限はより厳しく見直すべきです。
読み取り専用運用から始める
Azure MCP Serverには、起動パラメーターとして読み取り専用モードが用意されています。Azure MCP Server toolsの説明では、Read only を有効にすると書き込み操作を許可しない設定として扱われます。(Microsoft Learn)
初期導入では、次の順序が現実的です。
| フェーズ | 推奨設定 | 目的 |
|---|---|---|
| 検証初期 | 読み取り専用、検証ADXクラスターのみ | MCP設定と接続確認 |
| チーム検証 | 読み取り専用、本番に近いサンプルデータ | プロンプトとKQLの品質確認 |
| 限定運用 | 読み取り専用、本番の一部データ | 実業務での有効性確認 |
| 拡張検討 | 必要な操作だけ許可 | 管理操作や自動化の可否を判断 |
最初から管理コマンドや書き込み操作まで許可すると、誤操作の影響が大きくなります。特に .drop、.alter、データ取り込み、Eventstream更新などに関わる操作は、利用者と用途を限定するべきです。
「ユーザー確認を無効化」しない
Azure MCP Serverの起動パラメーターには、機密情報を扱う高リスク操作のユーザー確認を無効化するオプションがありますが、Microsoft Learnでは推奨されない設定として説明され、本番環境や信頼できない入力を扱う場合に使わないよう注意されています。(Microsoft Learn)
自動化環境では確認プロンプトが邪魔に見えることがあります。しかし、MCPとAIエージェントを組み合わせる場合、ユーザー確認は事故を防ぐ最後の防波堤になります。特にKey Vaultのシークレット、接続文字列、証明書、認証情報が関係する操作では、確認を省略しない設計が安全です。
開発者が確認すべき導入手順
開発者は、いきなり本番ADXクラスターに接続せず、サンプルまたは検証環境でMCP Serverの挙動を確認するのが基本です。GitHub CopilotのAgent mode、VS Code、Cline、Claude Desktopなど、利用するAIクライアントによって設定ファイルや起動方法が異なります。
Azure MCP Serverを使う場合の確認
Azure MCP Serverは、AI対応のコードエディター、GitHub Copilot関連ツール、Docker、Python、.NETなどから接続できると案内されています。また、NuGet、NPM、PyPIのパッケージも紹介されています。(Microsoft Learn)
開発者が確認すべき流れは次のとおりです。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Azure CLIや開発環境の認証を確認 | 想定したテナント・サブスクリプションにログインしているか |
| 2 | MCP対応クライアントを準備 | VS Code、GitHub Copilot、Clineなどの対応状況 |
| 3 | Azure MCP Serverを接続 | 必要なnamespaceやtoolだけを公開できるか |
| 4 | ADXクラスター一覧を取得 | 余計なサブスクリプションが見えていないか |
| 5 | データベース・テーブルを確認 | 権限が過不足なく反映されているか |
| 6 | 短いKQLを実行 | 件数制限、期間条件、応答時間を確認 |
| 7 | チーム用のプロンプト例を整備 | 誰が使っても安全な依頼文にする |
重要なのは、AIクライアント上で「見えてしまうリソース」がないか確認することです。ユーザーが意図せず別サブスクリプションや本番クラスターを指定できる状態は、運用上のリスクになります。
Fabric RTI MCP Serverを使う場合の確認
Fabric RTI MCP Serverは、PyPIの microsoft-fabric-rti-mcp パッケージを使った導入方法が案内されています。VS Codeでは MCP: Add Server からPipインストールを選び、パッケージ名を指定する流れが示されています。(GitHub)
設定例では、KUSTO_SERVICE_URI、KUSTO_SERVICE_DEFAULT_DB、FABRIC_API_BASE などの環境変数が使われています。リポジトリでは、KUSTO_SERVICE_URI と KUSTO_SERVICE_DEFAULT_DB は既定のクラスターとデータベースを指定するための任意設定として説明されています。(GitHub)
実務では、次のような設定方針にすると安全です。
| 設定項目 | 推奨方針 | 理由 |
|---|---|---|
KUSTO_SERVICE_URI | 検証用ADXクラスターから設定 | 誤って本番へ接続するリスクを下げる |
KUSTO_SERVICE_DEFAULT_DB | サンプルDBまたは限定DBを指定 | AIが意図せず広い範囲を探索しないようにする |
KUSTO_KNOWN_SERVICES | チームで許可したクラスターを明示 | 接続先の統制に役立つ |
KUSTO_ALLOW_UNKNOWN_SERVICES | 本番利用では慎重に検討 | 未許可クラスターへの接続を避ける |
AZ_OPENAI_EMBEDDING_ENDPOINT | semantic searchを使う場合のみ設定 | 不要な外部依存や認証設定を増やさない |
失敗しやすいポイントと対策
MCP ServerとADXの連携は便利ですが、導入時に失敗しやすいポイントがあります。多くは、AIの問題というより、接続先・権限・クエリ設計・運用ルールの問題です。
| 失敗例 | 起きる原因 | 対策 |
|---|---|---|
| 本番クラスターに誤接続する | 既定のサブスクリプションや環境変数が曖昧 | 接続先URI、DB名、サブスクリプションを明示する |
| 想定外のテーブルが見える | RBACやADX権限が広すぎる | 最小権限に見直し、検証ユーザーで確認する |
| 重いKQLが実行される | 期間条件や件数制限を指定していない | where Timestamp > ago(...) や take を標準プロンプトに入れる |
| AIの回答をそのまま信じる | 生成されたKQLや集計条件を確認していない | 実行前レビュー、結果のサンプル確認を習慣化する |
| 機密データがプロンプトやログに残る | テーブル内容や接続情報をそのまま入力 | プロンプトルール、ログ保管、マスキング方針を決める |
| チームで使い方がばらつく | 各自が独自にMCP設定を作る | 共通の設定テンプレートと利用手順を配布する |
特に避けたいのは、「自然言語で聞けるからKQLを理解しなくてよい」と考えることです。AIが生成したKQLの妥当性を判断するには、最低限のKQL知識、ADXのデータ構造、業務上の集計条件を理解している必要があります。
本番展開前のチェックリスト
本番環境でADX向けMCP Serverを使う場合は、次の項目を事前に確認しておくと安全です。
| チェック項目 | 確認内容 |
|---|---|
| 機能の位置付け | プレビュー機能として、利用範囲を限定しているか |
| 接続先 | 本番・検証・開発のADXクラスターを明確に分けているか |
| 認証 | 利用者のAzure資格情報またはマネージドIDが適切か |
| RBAC | サブスクリプション、リソースグループ、ADXで最小権限になっているか |
| ADX権限 | データベース、テーブル、管理コマンドの権限が適切か |
| MCP設定 | 不要なnamespaceやtoolを公開していないか |
| 読み取り専用 | 初期運用は読み取り専用で始めているか |
| クエリ制御 | 期間条件、件数制限、クエリプラン確認のルールがあるか |
| 機密情報 | 個人情報、シークレット、接続文字列を扱う方針があるか |
| ログ | MCP Server、AIクライアント、ADX側のログ確認方法が決まっているか |
| 教育 | 利用者に安全なプロンプト例と禁止事項を共有しているか |
| ロールバック | 問題発生時にMCP設定を無効化できるか |
このチェックリストを満たしていない場合は、まず検証環境だけで使うのが現実的です。MCP Serverは便利な入口ですが、データアクセスの責任は従来と同じく管理者と利用者側にあります。
活用シーン別のおすすめ構成
ADX向けMCP Serverは、目的によって使い方を変えると効果が出やすくなります。
障害調査やSRE業務で使う場合
障害調査では、ログやメトリックを短時間で絞り込む必要があります。MCP Serverを使うと、「直近30分でエラーが増えたサービスを出して」「この例外が最初に出た時刻を探して」といった初動調査を自然言語で始められます。
ただし、障害時は焦って広範囲のクエリを実行しがちです。標準プロンプトに「期間は直近1時間」「まず件数だけ集計」「必要ならサンプル10件」といった制限を入れておくと、安全に使いやすくなります。
データ分析の入口として使う場合
データ分析者が初めて触るADXデータベースでは、テーブル構成の理解に時間がかかります。MCP Serverでスキーマ確認、サンプル取得、基本集計を行えば、分析の初速を上げられます。
一方で、AIが提案する集計軸が業務定義と一致するとは限りません。売上、アクティブユーザー、失敗率、遅延時間などの定義は、プロンプトに明示する必要があります。
開発チームのKQLレビューで使う場合
Fabric RTI MCP ServerのKQL Copilot Skillでは、KQLの構文、join、datetime、メモリ安全なクエリパターン、時系列、地理空間、ベクトル類似検索などに関する支援が説明されています。(GitHub)
開発チームでは、KQLをそのまま生成させるだけでなく、次のようなレビュー用途に使うと効果的です。
- このKQLのボトルネック候補を説明して
- joinの順序を見直して
- 期間条件が正しいか確認して
- 結果件数が多くなりすぎないように改善して
- 本番実行前にクエリプランを確認して
AIに「答え」を出させるだけでなく、「確認役」として使うと、誤ったクエリを本番に流すリスクを下げられます。
移行は必要か：既存ADX環境はすぐに変えなくてよい
今回の情報は、既存のADXクラスター利用者に対して強制的な移行を求める内容ではありません。KQL、ADX Web Explorer、Azure Portal、SDK、既存の監視基盤を使っている場合、それらをすぐに置き換える必要はありません。
むしろ、次のような段階的導入が向いています。
| 段階 | やること | 判断基準 |
|---|---|---|
| 情報収集 | MCP Serverの種類と機能を把握 | 自社のADX用途に合うか |
| 検証 | サンプルDBまたは検証DBで接続 | スキーマ確認や簡単なKQLが使えるか |
| 限定利用 | 特定チームで読み取り専用運用 | 誤操作や過剰クエリが起きないか |
| ルール化 | プロンプト例、権限、ログ確認を整備 | チーム内で再現性があるか |
| 拡張 | 本番の一部業務に適用 | 既存運用より効果があるか |
移行ではなく「AIエージェントからADXを扱う追加ルート」として導入するのが安全です。
まず何をすべきか
ADXクラスターでMCP Serverを使う場合、最初にやるべきことはツールのインストールではなく、利用範囲の定義です。
まず、次の3つを決めてください。
- どのADXクラスターを対象にするか
- 誰がMCP Server経由でアクセスできるか
- 読み取り専用で何を確認できれば十分か
そのうえで、検証環境にMCP Serverを接続し、クラスター一覧、データベース一覧、テーブルスキーマ取得、サンプルデータ取得、短いKQL実行の順に確認します。問題がなければ、標準プロンプト、禁止事項、ログ確認手順を整備し、限定されたチームで利用を開始するのが現実的です。
Azure Data Explorer向けMCP Serverは、リアルタイムデータをAIエージェントから扱いやすくする強力な仕組みです。一方で、プレビュー段階であること、AIクライアント経由のデータアクセスであること、KQL実行が実データとクラスター負荷に影響することを忘れてはいけません。便利さより先に、接続先、権限、読み取り専用、クエリ制御を固めることが、安全な導入の第一歩です。
コメント