Microsoft Azure Data API builderのMCP修正を解説：release/2.0で確認すべき設定と影響範囲

Microsoft Azureの「Microsoft Azure documentation update: Cherry-pick MCP fixes (#3508, #3544, #3425) to release/2.0」は、Azure Data API builderのMCP関連不具合をrelease/2.0へ取り込む更新です。結論から言うと、影響が大きいのは、Data API builder 2.0でSQL MCP Serverを使い、dab start --mcp-stdio、MCPエージェント、ストアドプロシージャ実行を運用・検証している管理者や開発者です。REST APIやGraphQLだけを使っている場合の影響は限定的ですが、MCPを使ってAIエージェントからデータ操作を行う環境では、ログ設定、エージェントによるログレベル変更、describe_entitiesの戻り値を必ず確認しておきましょう。

まず押さえたい結論

今回の更新は、Azure Data API builderのmainブランチに入っていた3つのMCP関連修正を、release/2.0ブランチへバックポートするものです。公式PR #3606は2026年5月20日にrelease/2.0へマージされ、対象修正として#3508、#3544、#3425の3件が明記されています。(GitHub)

重要なのは、単なる表示改善だけではない点です。MCP stdioモードのログ出力、ログレベルの優先順位、ストアドプロシージャのパラメーター検出という、AIエージェント連携の安定性に直結する部分が修正されています。

変更点	主な影響	確認すべき人
MCP CLIログが設定ファイルの`log-level`を反映	`--LogLevel`を付けない起動時のログ挙動が変わる	DAB CLIでMCP stdioを使う開発者
ログレベルの優先順位が`Agent > CLI > Config`に整理	エージェントが実行時にログレベルを上書きできる	運用監視・セキュリティ担当者
`describe_entities`がストアドプロシージャのパラメーターを正しく返す	エージェントによる`execute_entity`失敗が減る	ストアドプロシージャをMCP公開している開発者

この更新はAzure全体ではなくData API builderのMCP機能が対象

Data API builderは、SQL Server、Azure SQL、Azure Cosmos DB、PostgreSQL、MySQLなどのデータベースに対してREST APIやGraphQL APIを生成するオープンソースのエンジンです。公式ドキュメントでは、Data API builderがMCPサーバーを含み、AIエージェント連携にも対応することが説明されています。(Microsoft Learn)

今回の「Cherry-pick MCP fixes」は、Azureの全サービス設定が一斉に変わるような更新ではありません。対象は、Azure Data API builderのrelease/2.0系でMCPを使う環境です。Data API builder 2.0はパブリックプレビューとして扱われており、MCPやAI統合を中心に強化されているバージョンです。(Microsoft Learn)

そのため、次のいずれかに当てはまる環境では確認が必要です。

dab start --mcp-stdioでローカルのMCPサーバーを起動している
VS Code、GitHub Copilot、MCP InspectorなどのMCP互換クライアントからDABを呼び出している
Data API builder 2.0 previewを検証・導入している
ストアドプロシージャをMCPツール、またはexecute_entity経由で使っている
runtime.telemetry.log-levelや--LogLevelでログレベルを制御している

一方で、MCPを無効化しており、REST APIやGraphQLのみを本番利用している場合は、今回の修正による直接的な挙動変更は限定的です。ただし、将来的にAIエージェント連携を追加する予定があるなら、今のうちにMCP設定とログ設計を整理しておく価値があります。

変更点：MCP stdioモードのCLIログが設定を正しく反映する

1つ目の修正は、MCP stdioモードでのCLIログ出力です。PR #3508では、dab start --mcp-stdio実行時に、CLIの起動ログが色付きで表示されない問題と、--LogLevelを指定しない場合にdab-config.jsonのruntime.telemetry.log-levelが反映されない問題が修正されています。(GitHub)

実務上のポイントは、設定ファイルでログレベルを明示している環境です。これまでは、設定ファイルにログレベルを書いていても、MCP stdioモードのCLI起動ログが抑制されるケースがありました。修正後は、CLIフラグがない場合でも、設定ファイル側のlog-levelが有効な最小ログレベルとして扱われます。

{
  "runtime": {
    "telemetry": {
      "log-level": {
        "Azure.DataApiBuilder.Core": "information",
        "default": "warning"
      }
    }
  }
}

Data API builderのruntime.telemetry.log-levelは、.NETのロギング慣例に沿ってnamespace単位でログの詳細度を制御する設定です。公式ドキュメントでは、log-levelは本番環境でもホットリロード可能なプロパティとして説明されています。(Microsoft Learn)

管理者が見るべきポイント

MCP stdioでは、標準入出力をJSONメッセージの通信路として使います。そのため、ログが不用意にstdoutへ混ざると、MCPクライアントとの通信を壊す原因になります。今回の修正は、CLIログの整合性を高めるものですが、運用側では「どのログを、どこに、どの粒度で出すか」を改めて決めておく必要があります。

確認すべき設定は次の3つです。

確認項目	見る場所	判断基準
設定ファイルのログレベル	`runtime.telemetry.log-level`	開発では`information`や`debug`、本番相当では`warning`以上を基本にする
起動時の一時的な上書き	`dab start --LogLevel Warning`など	障害調査時だけ詳細化し、恒常的な`debug`運用は避ける
MCP stdio起動	`dab start --mcp-stdio`	`mcp.enabled`が有効で、JSON通信を邪魔する独自出力がないか確認する

DAB CLIのstartコマンドでは、--LogLevel <level>でログレベルを指定でき、--mcp-stdioを使うとHTTPポートを開かず標準入出力でMCPサーバーとして起動します。(Microsoft Learn)

変更点：ログレベルの優先順位がAgent > CLI > Configになる

2つ目の修正は、MCPエージェントが実行時にログレベルを変更する場合の優先順位です。PR #3544では、MCPのlogging/setLevelがCLIや設定ファイルで指定されたログレベルに阻まれて反映されない問題が修正されました。修正後の優先順位は、エージェント、CLIフラグ、設定ファイルの順です。(GitHub)

優先順位	指定元	例	主な用途
1	MCPエージェント	`logging/setLevel`で`debug`へ変更	実行中の調査、MCP Inspectorでの確認
2	CLI	`dab start --LogLevel Error`	起動単位の一時的な制御
3	設定ファイル	`runtime.telemetry.log-level`	環境ごとの標準ポリシー
4	既定値	host modeやstdioの既定	明示設定がない場合

ここで注意したいのは、--LogLevel Errorを付けて起動しても、MCPエージェントが後からdebugへ変更できる点です。PR #3544の説明では、修正後もCLIがConfigより優先される点や、既定値は変更されない点が明記されていますが、エージェントによる実行時変更は最上位として扱われます。(GitHub)

運用で失敗しやすいポイント

ログレベルの優先順位が変わると、障害調査はしやすくなります。一方で、次のような運用ミスが起こりやすくなります。

失敗例	起きること	対策
CLIで`Error`にしたので詳細ログは出ないと思い込む	エージェントが`debug`へ変更すると詳細ログが流れる	エージェント側の操作ログとDAB側の監査ログを確認する
検証中の`debug`設定を残したまま本番相当に展開する	ログ量が増え、機密性の高い値が出るリスクも増える	本番用configを分離し、CIで差分確認する
複数エージェントから同時に調査する	どの操作でログレベルが変わったか追いにくい	調査手順を決め、変更前後の時刻を記録する

MCPエージェントによるログレベル変更は便利ですが、運用監視の観点では「誰が、いつ、なぜ詳細ログを有効にしたか」を追える状態にすることが重要です。Azure Log Analytics、Application Insights、OpenTelemetry、ファイル出力など、利用中のテレメトリ設定と合わせて確認しましょう。Data API builderのランタイム設定には、Application Insights、OpenTelemetry、Azure Log Analytics、ファイル出力の項目が用意されています。(Microsoft Learn)

変更点：describe_entitiesがストアドプロシージャのパラメーターを正しく返す

3つ目の修正は、MCPエージェントがエンティティ情報を取得するdescribe_entitiesの応答です。PR #3425では、ストアドプロシージャのパラメーターが設定ファイルに完全には書かれていない場合、describe_entitiesが空または不完全なparametersを返し、結果としてエージェントのexecute_entity呼び出しが失敗する問題が修正されました。(GitHub)

修正後は、ストアドプロシージャのパラメーター検出において、実行時のデータベースメタデータが信頼できる情報源として扱われ、設定ファイルは上書き情報として使われます。PR #3425では、パラメーター名はデータベース由来、requiredは既定でtrue、defaultとdescriptionは設定ファイル由来と整理されています。(GitHub)

項目	修正後の扱い	実務での確認ポイント
パラメーター名	データベース側の定義を使用	configで名前を変えたつもりでもDB定義が基準になる
`required`	既定は`true`、明示指定時のみconfigで上書き	任意パラメーターはconfigに明示する
`default`	config側の情報を使用	DB側の既定値だけに頼らず、エージェント向けに補足する
`description`	config側の情報を使用	エージェントが誤解しない説明文を入れる
configにないDBパラメーター	`required: true`として表示	追加したDBパラメーターがエージェントに見えるか確認する

この修正は、ストアドプロシージャをMCPツールとして公開している環境では特に重要です。AIエージェントは、describe_entitiesやtools/listで得た情報をもとに、どの入力を渡すべきか判断します。必要なパラメーターが見えていなければ、エージェントは正しい呼び出しを組み立てられません。

ストアドプロシージャ公開時の確認例

ストアドプロシージャをMCPのカスタムツールとして公開する場合は、--source.type stored-procedureと--mcp.custom-tool trueを使います。公式ドキュメントでは、custom-toolはストアドプロシージャエンティティでのみ有効であり、ツール名はエンティティ名からsnake_caseへ変換されると説明されています。(Microsoft Learn)

dab add GetProductById \
  --source dbo.get_product_by_id \
  --source.type "stored-procedure" \
  --permissions "authenticated:execute" \
  --mcp.custom-tool true

この例では、MCPツール名としてはget_product_by_idのようなsnake_case名を使う前提で確認します。あわせて、エージェントに渡したい説明をdescriptionとして追加しておくと、AIがツールの用途を誤解しにくくなります。

dab update GetProductById \
  --description "指定した商品IDに対応する商品詳細、価格、在庫情報を返します"

影響範囲：特に確認すべき環境

今回の更新はMCP関連の修正なので、すべてのAzure利用者が対応を迫られるわけではありません。影響範囲は、Data API builderの使い方によって大きく変わります。

利用状況	影響度	確認内容
Data API builder 2.0 previewでMCPを検証中	高	`release/2.0`相当の修正が取り込まれているか確認
`dab start --mcp-stdio`を使う	高	`--LogLevel`、`runtime.telemetry.log-level`、stderrログの挙動
MCPエージェントからログレベルを変更する	高	`logging/setLevel`後のログ量と監査ログ
ストアドプロシージャを`execute_entity`で実行する	高	`describe_entities`に全パラメーターが出るか確認
MCPをHTTPでホストしている	中	ログレベル変更とツール表示を確認
REST/GraphQLのみ利用	低	直接影響は限定的だが、将来のMCP導入に備えて設定を把握
Azureインフラ管理のみ担当	低	Container Apps、App Service、CI/CDで使うDABイメージやCLIの更新有無を確認

SQL MCP Serverは、ホスト用途ではHTTP、ローカル開発や直接的なエージェント連携ではstdioを使える構成です。公式ドキュメントでは、stdioはローカル開発、VS Code with GitHub Copilot、CI/CDやスクリプト化されたエージェント自動化に向くと説明されています。(Microsoft Learn)

管理者・開発者が確認すべき設定

今回の修正を受けて、まず見るべき設定はruntime.mcp、runtime.telemetry.log-level、エンティティ権限、ストアドプロシージャ定義です。

MCPランタイム設定

MCPを使う場合、runtime.mcp.enabledとdml-toolsを確認します。Data API builderのランタイム設定では、runtime.mcp.enabledの既定値はtrue、pathの既定値は/mcp、dml-toolsは全体または個別ツール単位で制御できます。(Microsoft Learn)

{
  "runtime": {
    "mcp": {
      "enabled": true,
      "dml-tools": {
        "describe-entities": true,
        "create-record": true,
        "read-records": true,
        "update-record": true,
        "delete-record": false,
        "execute-entity": true,
        "aggregate-records": {
          "enabled": true,
          "query-timeout": 30
        }
      }
    }
  }
}

本番相当の環境では、すべてのDMLツールを無条件に有効化するよりも、エージェントに必要な操作だけを有効化する方が安全です。たとえば、読み取りとストアドプロシージャ実行だけで十分な業務エージェントに、delete-recordを公開する必要はありません。

ログ設定

ログ設定は、環境ごとに分けて管理します。開発環境ではinformation以上を出して調査しやすくし、本番相当ではwarningを基本にして、障害調査時だけCLIやエージェントで一時的に詳細化するのが現実的です。

{
  "runtime": {
    "telemetry": {
      "log-level": {
        "Azure.DataApiBuilder.Core": "information",
        "default": "warning"
      }
    }
  }
}

ただし、今回の更新後はエージェントがログレベルを上書きできるため、設定ファイルだけで最終的なログ粒度を固定できるとは考えない方が安全です。運用手順として、MCPエージェントによるlogging/setLevelの使用タイミング、調査後に戻す手順、ログ保存先の確認をセットで決めておきましょう。

stdio起動時のrole指定

--mcp-stdioでは、ロールを省略するとanonymousとして動作します。公式ドキュメントでは、role:<role-name>を指定でき、指定したロールはエンティティ設定のpermissionsに存在する必要があると説明されています。(Microsoft Learn)

dab start \
  --mcp-stdio role:authenticated \
  --config ./dab-config.json \
  --LogLevel Information

ここで失敗しやすいのは、ロール名の指定漏れです。ローカル検証でanonymousのまま成功していた構成を、業務データに近い環境へ持ち込むと、意図せず広い権限で動かしてしまう可能性があります。MCP用の検証ロールを作り、読み取り専用、実行専用など、役割ごとに権限を切り分けると安全です。

展開前に行うべき検証手順

修正を取り込んだData API builderを展開する前に、最低限次の順序で確認しましょう。

手順	確認すること	失敗時の見直しポイント
1	`dab validate`で設定ファイルを検証	JSON構造、権限、DB接続、ストアドプロシージャのパラメーター
2	`dab start --mcp-stdio`で起動	MCPが有効か、role指定が正しいか
3	`--LogLevel`なしで起動	`runtime.telemetry.log-level`が期待どおり効くか
4	`--LogLevel Warning`などで起動	CLI指定がConfigより優先されるか
5	MCPエージェントから`logging/setLevel`を送る	Agent指定がCLIより優先されるか
6	`describe_entities`を実行	ストアドプロシージャの全パラメーターが返るか
7	`execute_entity`またはカスタムツールを実行	必須パラメーター不足で失敗しないか

dab validateは、設定ファイルを起動前に検証するコマンドです。公式ドキュメントでは、スキーマ、構造、権限、接続、メタデータを順に確認し、CI/CDでも使えると説明されています。(Microsoft Learn)

dab validate --config ./dab-config.staging.json

ストアドプロシージャを使っている場合は、dab validateだけで終わらせず、MCPクライアントから実際にdescribe_entitiesと実行系ツールを呼び出してください。今回の修正は、エージェントが見るメタデータの正確性に関わるため、CLI上の構文チェックだけでは確認が不十分です。

移行・展開時の注意点

今回のPRは、MCP関連の不具合修正をrelease/2.0に取り込むものです。そのため、大きな設定移行が必要になる更新というより、既存設定が意図どおり効くようになる更新と捉えると分かりやすいです。ただし、「これまで偶然動いていた運用」が変わって見える可能性があります。

ログが増えたように見える場合

設定ファイルのruntime.telemetry.log-levelが以前より正しく反映されることで、更新後にログが増えたように見える場合があります。これは不具合というより、設定済みの意図が反映されるようになった可能性があります。

確認する順序は次の通りです。

dab-config.jsonのruntime.telemetry.log-levelを見る
起動コマンドに--LogLevelが付いているか確認する
MCPエージェントがlogging/setLevelを送っていないか確認する
ログ保存先の容量、保持期間、転送先の料金影響を確認する

ストアドプロシージャ呼び出しが変わったように見える場合

describe_entitiesがDBメタデータを基準にパラメーターを返すようになるため、これまでエージェントから見えていなかったパラメーターが見えるようになる場合があります。DB側で追加したパラメーターをconfigに反映していなかった環境では、エージェントの入力候補が増える可能性があります。

特に次のケースは注意してください。

ケース	起きやすい問題	対応
DB側に必須パラメーターを追加した	エージェントが新しい入力を要求する	configに説明文を追加する
任意扱いしたいパラメーターがある	既定で`required: true`として見える	configで`required: false`を明示する
パラメーター名をconfig側で変えたい	DB名が基準になる	エージェント向け説明で用途を補う
DBの既定値に依存している	MCPメタデータ上のdefaultが不足する	configにdefaultやdescriptionを明示する

次に取るべき行動

今回の「Microsoft Azure documentation update: Cherry-pick MCP fixes (#3508, #3544, #3425) to release/2.0」は、Azure Data API builder 2.0でMCPを使う環境にとって、ログ制御とストアドプロシージャ実行の安定性を高める更新です。特に重要なのは、MCP stdioのログが設定ファイルを反映すること、エージェントによるログレベル変更が最優先になること、describe_entitiesがストアドプロシージャのパラメーターをより正確に返すことです。

まずは、利用中のDAB CLIまたはコンテナイメージがrelease/2.0系の修正を取り込んでいるか確認します。そのうえで、dab validate、dab start --mcp-stdio、logging/setLevel、describe_entities、execute_entityをステージング環境で順に確認してください。

MCPを使ったAIエージェント連携では、「エージェントが何を見て、どの権限で、どのログ粒度で実行しているか」が運用品質を左右します。今回の更新を機に、MCP設定、ログポリシー、ストアドプロシージャの説明文とパラメーター定義を見直しておくと、将来の本番展開や障害調査でつまずきにくくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Azure Data API builderのMCP修正を解説：release/2.0で確認すべき設定と影響範囲

まず押さえたい結論

この更新はAzure全体ではなくData API builderのMCP機能が対象

変更点：MCP stdioモードのCLIログが設定を正しく反映する

管理者が見るべきポイント

変更点：ログレベルの優先順位がAgent > CLI > Configになる

運用で失敗しやすいポイント

変更点：describe_entitiesがストアドプロシージャのパラメーターを正しく返す

ストアドプロシージャ公開時の確認例

影響範囲：特に確認すべき環境

管理者・開発者が確認すべき設定

MCPランタイム設定

ログ設定

stdio起動時のrole指定

展開前に行うべき検証手順

移行・展開時の注意点

ログが増えたように見える場合

ストアドプロシージャ呼び出しが変わったように見える場合

次に取るべき行動

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft Azure Data API builderのMCP修正を解説：release/2.0で確認すべき設定と影響範囲

まず押さえたい結論

この更新はAzure全体ではなくData API builderのMCP機能が対象

変更点：MCP stdioモードのCLIログが設定を正しく反映する

管理者が見るべきポイント

変更点：ログレベルの優先順位がAgent > CLI > Configになる

運用で失敗しやすいポイント

変更点：describe_entitiesがストアドプロシージャのパラメーターを正しく返す

ストアドプロシージャ公開時の確認例

影響範囲：特に確認すべき環境

管理者・開発者が確認すべき設定

MCPランタイム設定

ログ設定

stdio起動時のrole指定

展開前に行うべき検証手順

移行・展開時の注意点

ログが増えたように見える場合

ストアドプロシージャ呼び出しが変わったように見える場合

次に取るべき行動

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル