Azure SQL に AI エージェントを接続する場合、最大の確認ポイントは「SQL の監査ログに誰が実行者として残るのか」です。2026年7月1日に Microsoft が公開した「Audit Frontier AI Agents with SQL MCP Server」では、SQL MCP Server と Data API builder 2.0 の On-Behalf-Of（OBO）認証により、エージェントや中間サーバーではなく、実際にサインインしたユーザーの ID を Azure SQL 側で監査できることが示されました。(Microsoft for Developers)
結論から言うと、今回の更新は「全環境で急いで移行が必要な破壊的変更」ではありません。むしろ、AI エージェントが Azure SQL のデータを読み書きする本番環境で、監査・コンプライアンス・責任追跡を強化するための重要な設計選択肢です。特に、顧客情報、社内機密、業務データを MCP 経由で扱う場合は、OBO 認証を採用するかどうかを早めに判断すべきです。
Azure SQL の「Audit Frontier AI Agents with SQL MCP Server」とは何か
「Audit Frontier AI Agents with SQL MCP Server」は、AI エージェントが SQL MCP Server を通じて Microsoft SQL、特に Azure SQL にアクセスする際の認証と監査の考え方を整理した公式ブログです。
SQL MCP Server は Data API builder に含まれる MCP サーバー機能で、AI エージェントがデータベースに直接接続するのではなく、MCP ツールとしてテーブル、ビュー、ストアドプロシージャなどを扱えるようにします。Data API builder は Azure SQL を含む複数のデータベースに REST、GraphQL、MCP サーバーを提供できる仕組みです。(Microsoft Learn)
今回の要点は、AI エージェントがデータ操作を実行したときに、Azure SQL の監査ログへ「エージェント名」や「MCP サーバーのサービス ID」だけでなく、操作を依頼した実ユーザーを残せる点です。Microsoft はこれを OBO、つまり On-Behalf-Of 認証またはパススルー認証として説明しています。(Microsoft for Developers)
なぜ今この更新が重要なのか
AI エージェントの導入が進むと、「誰がデータを見たのか」「誰の権限で更新されたのか」が曖昧になりやすくなります。従来のアプリケーション連携では、アプリケーション用のマネージド ID や接続文字列で SQL に接続する構成が一般的でした。この場合、監査ログにはアプリケーションやサービスアカウントが残り、実際に指示したユーザーまでは SQL 側だけでは追いにくくなります。
OBO 認証を使うと、DAB が受信したユーザートークンを Azure SQL 用の下流トークンに交換し、データベースが実際の呼び出し元ユーザーとして認証します。これにより、SQL 側の権限チェック、行レベルセキュリティ、監査ログをユーザー単位に近づけられます。(Microsoft Learn)
今回確認すべき更新ポイント
2026年7月1日の公式ブログで押さえるべきポイントは、単に「新しい認証方式が増えた」という話ではありません。AI エージェントを業務データへ接続する際の、監査境界が変わる点が本質です。
| 確認項目 | 内容 | 管理者への影響 |
|---|---|---|
| 対象 | Data API builder 2.0 の SQL MCP Server と Microsoft SQL / Azure SQL | MCP 経由で SQL を使うエージェント構成を棚卸しする |
| 主要機能 | OBO 認証により、Azure SQL が実ユーザーとして認証できる | 監査ログ、RLS、権限設計をユーザー単位で見直せる |
| 認証基盤 | Microsoft Entra ID | アプリ登録、JWT、トークン交換、API 権限の確認が必要 |
| 接続文字列 | OBO では Authentication=、User ID、Password を含めない裸の接続文字列が必要 | 既存の接続文字列をそのまま流用できない場合がある |
| キャッシュ | OBO 構成ではキャッシュを無効化する必要がある | パフォーマンス設計とコスト見積もりを再確認する |
| 監査ログ | database_principal_name、server_principal_name、obo_middle_tier_app_id などを確認 | Log Analytics クエリや SIEM 連携の更新が必要 |
Microsoft Learn では、SQL MCP Server は Data API builder 1.7 以降で利用できる一方、SQL MCP Server の最新機能や修正には最新の 2.0 リリースを使うよう案内されています。また、OBO 認証は Data API builder 2.0 以降の機能として説明されています。(Microsoft Learn)
認証方式ごとの違いを整理する
SQL MCP Server から Azure SQL に接続する方式は、大きく分けて SQL ユーザー・パスワード、マネージド ID、OBO 認証の3つで考えると分かりやすくなります。
| 方式 | SQL から見える実行者 | 向いている用途 | 注意点 |
|---|---|---|---|
| SQL ユーザー・パスワード | 接続文字列に指定した SQL ユーザー | 開発、検証、一部の既存システム | 秘密情報の管理が必要。実ユーザー単位の監査には不向き |
| マネージド ID | MCP サーバーやアプリケーションの ID | Azure 内のサービス間接続、本番運用 | パスワード管理は不要だが、操作した実ユーザーは SQL 監査だけでは追いにくい |
| OBO 認証 | サインインした実ユーザー | AI エージェント、行レベルセキュリティ、監査重視の業務システム | Entra ID、アプリ登録、キャッシュ無効化、接続文字列の見直しが必要 |
Microsoft の説明では、ユーザー・パスワード方式やマネージド ID 方式では、監査ログ上の実行者は接続に使われた ID になります。一方、OBO ではユーザーが Entra ID で認証し、そのトークンが MCP サーバーを経由して Azure SQL 用トークンに交換されるため、SQL が実ユーザーを認識できます。(Microsoft for Developers)
OBO 認証を選ぶべきケース
OBO 認証は、すべてのシステムで必須ではありません。たとえば、社内の単純な参照 API で、操作主体がアプリケーション単位で十分な場合は、マネージド ID の方がシンプルです。
一方で、次のような環境では OBO 認証を優先的に検討すべきです。
- AI エージェントが顧客情報、契約情報、財務データ、人事データなどを参照または更新する
- 「誰がそのデータを取得したか」を監査証跡として残す必要がある
- ユーザーごとに見える行を変える行レベルセキュリティを SQL 側で使いたい
- エージェント、MCP サーバー、API ゲートウェイをまたいでもユーザー ID を維持したい
- 監査ログを Log Analytics、Event Hubs、SIEM に連携している
Microsoft Learn でも、OBO は行レベルセキュリティ、ユーザー単位のコンプライアンス監査、MCP での透過的なユーザー識別が必要な場面に適した選択肢として整理されています。(Microsoft Learn)
影響範囲：どの管理者が確認すべきか
今回の更新で直接影響を受けるのは、Azure SQL そのものだけではありません。AI エージェント、Microsoft Entra ID、Data API builder、監査ログ基盤を横断して確認が必要です。
Azure SQL 管理者
Azure SQL 管理者は、監査ログに残したい主体が「サービス ID」でよいのか、「実ユーザー」であるべきなのかを判断する必要があります。
特に確認すべきなのは、次の3点です。
| 確認対象 | 確認内容 |
|---|---|
| 監査設定 | Azure SQL Auditing が有効か、出力先が Storage、Log Analytics、Event Hubs のどれか |
| 監査項目 | database_principal_name、server_principal_name、statement を分析できるか |
| OBO 用フィールド | obo_middle_tier_app_id をログ分析や SIEM 側で扱えるか |
Azure SQL Auditing は、データベースイベントを監査ログとして Storage、Log Analytics、Event Hubs に書き出せます。監査ログ形式には、実行時のデータベースユーザー、ログイン、T-SQL ステートメント、OBO で接続した中間層アプリの ID などのフィールドが含まれます。(Microsoft Learn)
Entra ID 管理者
OBO 認証では Microsoft Entra ID の設計が重要になります。Entra ID アプリ登録、クライアント ID、テナント ID、クライアントシークレット、JWT の audience / issuer、Azure SQL へのトークン取得権限などが関係します。
確認すべきポイントは、単に「サインインできるか」ではありません。エージェントから MCP サーバー、DAB、Azure SQL まで、どのトークンがどの audience に対して発行され、どこで交換されるかを明確にする必要があります。
AI / アプリケーション開発者
開発者は、AI エージェントが呼び出す MCP ツールの権限を最小化する必要があります。SQL MCP Server では、REST、GraphQL、MCP を同じ DAB ランタイムから公開できますが、公開するエンティティや権限を広げすぎると、エージェントが本来不要な操作まで実行できる可能性があります。(Microsoft for Developers)
読み取り専用で足りるユースケースでは、read のみに絞ります。更新、削除、ストアドプロシージャ実行を許可する場合は、承認フロー、監査、テストデータでの検証をセットで行うべきです。
セキュリティ・監査担当者
セキュリティ担当者は、AI エージェント経由の操作を従来のアプリ操作と同じ粒度で追えるか確認します。
たとえば Log Analytics では、SQL 監査イベントのカテゴリとして SQLSecurityAuditEvents を使い、ユーザー名、ステートメント、中間層アプリ ID を確認する設計が紹介されています。(Microsoft for Developers)
OBO 認証の設定変更で見るべきポイント
OBO 認証を有効化する場合、設定変更は主に Data API builder の data-source と runtime.cache に入ります。
代表的な構成は次のような形です。
{
"data-source": {
"database-type": "mssql",
"connection-string": "@env('SQL_CONNECTION_STRING')",
"user-delegated-auth": {
"enabled": true,
"provider": "EntraId",
"database-audience": "https://database.windows.net"
}
},
"runtime": {
"cache": {
"enabled": false
}
}
}この構成では、database-type は mssql、user-delegated-auth.enabled は true、provider は EntraId、database-audience は Azure SQL 用の https://database.windows.net を指定します。Microsoft Learn では、OBO 構成時にキャッシュを無効化する必要があることも明記されています。(Microsoft Learn)
接続文字列は「裸の接続文字列」にする
OBO で失敗しやすいのが接続文字列です。OBO を有効にした場合、接続文字列には Authentication=、User ID、Password を含めない構成が求められます。
例としては、次のような形です。
Server=tcp:<server>.database.windows.net,1433;Database=<db>;Encrypt=true;TrustServerCertificate=falseMicrosoft Learn では、OBO が有効な状態で接続文字列に Authentication= キーワードが含まれていると、SQL クライアント側で AccessToken と接続文字列認証が衝突する可能性があると説明されています。(Microsoft Learn)
既存環境でマネージド ID 用の接続文字列を使っている場合、次のような指定が残っていないか確認してください。
Authentication=Active Directory Managed Identityまた、古い SQL 認証の名残として次の指定が残っている場合も、OBO 用には見直しが必要です。
User ID=<user>;Password=<password>環境変数の管理も変更点になる
OBO のトークン交換では、DAB が Entra ID アプリ登録の情報を使います。Microsoft Learn では、次の環境変数が示されています。(Microsoft Learn)
| 環境変数 | 用途 |
|---|---|
DAB_OBO_CLIENT_ID | Entra ID アプリ登録のアプリケーション ID |
DAB_OBO_TENANT_ID | Entra ID テナント ID |
DAB_OBO_CLIENT_SECRET | アプリ登録のクライアントシークレット |
本番運用では、これらをアプリ設定に直書きせず、Azure Key Vault、マネージド ID、CI/CD のシークレット管理などと組み合わせて扱うのが現実的です。特にグローバル環境では、テナントごと、リージョンごと、環境ごとにアプリ登録やシークレットの所有者が分かれることがあるため、更新責任者を明確にしておく必要があります。
Azure SQL の監査ログで確認すべき項目
OBO 認証を導入しただけでは、監査運用が完成したとは言えません。実際に Azure SQL の監査ログに期待どおりのユーザー ID が残るかを確認する必要があります。
Microsoft の公式ブログでは、Log Analytics で SQLSecurityAuditEvents を確認し、database_principal_name、server_principal_name、obo_middle_tier_app_id、statement などを見る例が示されています。(Microsoft for Developers)
AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| project
event_time_t,
action_name_s,
database_principal_name_s,
server_principal_name_s,
obo_middle_tier_app_id_s,
statement_s
| order by event_time_t descこのクエリで見るべきポイントは、単にログが出ているかどうかではありません。
| ログ項目 | 確認すること |
|---|---|
database_principal_name_s | SQL が認識したデータベースユーザーが期待どおりか |
server_principal_name_s | ログイン主体が想定どおりか |
obo_middle_tier_app_id_s | OBO 経路で接続した中間層アプリを識別できるか |
statement_s | AI エージェントが実行した SQL が追跡できるか |
action_name_s | 読み取り、更新、権限変更などのイベント種別が分析できるか |
WhoAmI ビューで事前検証する
本番導入前には、SQL が誰として認識しているかを確認する簡単なビューを用意すると便利です。公式ブログでは、SUSER_NAME() を返す WhoAmI ビューで、SQL 側から見えるユーザーを検証する例が紹介されています。(Microsoft for Developers)
CREATE VIEW [dbo].[WhoAmI] AS
SELECT SUSER_NAME() AS [UserName];このような検証用ビューを認証済みユーザーだけに公開し、複数ユーザーで MCP ツール呼び出しを行うと、ユーザーごとに SQL 側の認識が変わっているか確認できます。
ただし、検証用ビューを本番環境に残す場合は注意が必要です。ユーザー名やプリンシパル情報は監査・運用上は有用ですが、不要な情報露出になる可能性もあります。検証後に削除するか、管理者限定にするのが安全です。
移行期限はあるのか
2026年7月1日の公式ブログおよび関連する Microsoft Learn の情報を見る限り、今回の内容は「既存の SQL MCP Server 構成を特定日までに OBO へ強制移行する」という告知ではありません。少なくとも、今回確認できる公式情報では、廃止日、強制移行日、既存認証方式の終了期限は示されていません。(Microsoft for Developers)
そのため、管理者が取るべき対応は「期限対応」ではなく「リスクに応じた優先順位付け」です。
| 環境 | 推奨アクション |
|---|---|
| 検証環境で SQL MCP Server を試している | DAB 2.0 の最新構成で OBO を試し、監査ログを確認する |
| 社内データを読み取る AI エージェントを運用中 | ユーザー単位の監査が必要かを判断し、OBO 移行計画を作る |
| 個人情報・機密情報を扱う本番環境 | OBO、行レベルセキュリティ、監査ログ保存、SIEM 連携を優先的に検証する |
| マネージド ID で十分な内部バッチ処理 | 既存構成を維持しつつ、監査要件に変更がないか確認する |
実務上は、AI エージェントの利用範囲が広がってから認証方式を変えるより、初期設計の段階で OBO を含めた監査モデルを決めておく方が安全です。
グローバル運用で特に注意したい点
グローバル企業で Azure SQL と AI エージェントを使う場合、技術的に接続できることと、監査・法務・運用の要件を満たすことは別問題です。
テナントとユーザー ID の扱い
OBO 認証は、ユーザーの ID を維持することに価値があります。そのため、複数の Entra ID テナント、B2B ユーザー、地域別テナントを使っている企業では、どのユーザー ID を Azure SQL の監査上の正とするかを決める必要があります。
たとえば、日本法人、米国法人、欧州法人で異なるテナントを使っている場合、同じ氏名のユーザーでも UPN やオブジェクト ID は異なります。監査レポートで「同一人物」として扱うのか、「テナントごとの別主体」として扱うのかを決めておかないと、後からログ分析が難しくなります。
ログ保存先とデータ所在
Azure SQL Auditing は Storage、Log Analytics、Event Hubs などに出力できます。(Microsoft Learn)
グローバル運用では、ログ保存先のリージョン、保持期間、アクセス権限、エクスポート先を確認してください。監査ログには SQL ステートメントやユーザー情報が含まれる場合があるため、国や地域ごとのデータ保護要件に合わせた設計が必要です。
エージェントの権限を「便利さ」で広げない
AI エージェントは、自然言語で操作できるため、利用者から見ると非常に便利です。しかし、MCP ツールとして公開した操作は、エージェントが計画の一部として実行できる可能性があります。
そのため、最初から広い更新権限を与えるのは避けるべきです。読み取り、作成、更新、削除、ストアドプロシージャ実行を分け、業務ごとに必要な操作だけを公開します。Foundry の MCP 認証ガイドでも、共有認証と個別認証、OAuth identity passthrough、承認要求などをセキュリティ要件に応じて選ぶ考え方が示されています。(Microsoft Learn)
管理者が確認すべきチェックリスト
OBO 認証を採用するかどうかにかかわらず、SQL MCP Server を Azure SQL と組み合わせて使う管理者は、次の順番で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | AI エージェントがアクセスする Azure SQL を棚卸しする | 本番データ、個人情報、機密情報を含むか |
| 2 | 現在の接続方式を確認する | SQL 認証、マネージド ID、OBO のどれか |
| 3 | 監査ログに残る主体を確認する | サービス ID でよいか、実ユーザーが必要か |
| 4 | DAB のバージョンを確認する | OBO が必要なら Data API builder 2.0 以降を前提にする |
| 5 | Entra ID アプリ登録を確認する | client ID、tenant ID、secret、API 権限が適切か |
| 6 | 接続文字列を確認する | OBO では Authentication=、User ID、Password を含めない |
| 7 | キャッシュ設定を確認する | OBO 構成ではキャッシュを無効化する |
| 8 | MCP ツールの権限を確認する | read / create / update / delete / execute を最小化する |
| 9 | 監査ログの出力先を確認する | Storage、Log Analytics、Event Hubs の運用責任を明確にする |
| 10 | 複数ユーザーで検証する | ユーザーごとに SQL 側の認識と監査ログが変わるか確認する |
このチェックリストで特に重要なのは、3番目の「監査ログに残る主体」です。OBO を導入する目的が曖昧なまま設定だけ変えると、キャッシュ無効化による性能影響や認証設定の複雑さだけが増えてしまいます。
失敗しやすいポイントと回避策
既存のマネージド ID 接続文字列をそのまま使ってしまう
OBO では、DAB がユーザーごとのアクセストークンを SQL 接続に注入します。そのため、接続文字列に Authentication=Active Directory Managed Identity が残っていると、期待どおり動作しない可能性があります。OBO 用には、サーバー、データベース、暗号化設定を中心とした接続文字列へ見直します。(Microsoft Learn)
キャッシュを有効にしたままにする
OBO ではユーザーごとに SQL 接続と権限が異なるため、あるユーザーの結果を別ユーザーへ返すリスクを避ける必要があります。Microsoft Learn では、OBO 構成時にキャッシュを無効化する必要があると説明されています。(Microsoft Learn)
パフォーマンスが気になる場合は、キャッシュでごまかすのではなく、インデックス、クエリ、ビュー設計、取得件数制限、MCP ツールの粒度を見直す方が安全です。
監査ログの「出力」だけで満足してしまう
監査ログを Log Analytics に送っていても、必要なフィールドを見ていなければ意味がありません。OBO 導入後は、少なくとも次の観点でクエリやダッシュボードを見直してください。
- ユーザー別の実行件数
- エージェントまたは中間層アプリ別の実行件数
- 更新・削除・ストアドプロシージャ実行の検出
- 失敗した権限チェック
- 通常時間外や通常業務外のアクセス
- 特定テーブルや機密データへのアクセス
Azure SQL の監査機能は、コンプライアンスや不審なアクティビティ分析に役立ちますが、監査を有効にするだけでコンプライアンス達成を保証するものではありません。また、高負荷時には監査対象イベントがすべて記録されるとは限らない点も公式ドキュメントで注意されています。(Microsoft Learn)
MCP ツールを広く公開しすぎる
AI エージェントに便利なツールを渡したくなるほど、権限は広がりがちです。しかし、MCP 経由で更新や削除を許可する場合、自然言語の誤解、プロンプトの曖昧さ、意図しないツール選択がリスクになります。
最初は読み取り専用から始め、更新系ツールは承認、監査、ロール分離、テストケースを整えてから段階的に公開するのが現実的です。
実務での導入順序
本番環境でいきなり OBO 認証へ切り替えるのではなく、次の順序で進めると安全です。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 検証 | DAB 2.0、SQL MCP Server、OBO 認証を検証環境に構成 | 複数ユーザーで WhoAmI 結果が変わる |
| 監査確認 | Log Analytics で SQLSecurityAuditEvents を確認 | 実ユーザー、中間層アプリ、SQL 文を追跡できる |
| 権限設計 | MCP ツールの read / update / execute を整理 | 不要な操作が公開されていない |
| 性能確認 | キャッシュ無効化後のレスポンスと DB 負荷を確認 | 業務上許容できる性能を満たす |
| セキュリティ確認 | Entra ID、シークレット、ログ保存先、RBAC を確認 | 運用責任者とローテーション手順が明確 |
| 段階展開 | 限定ユーザー、限定データ、限定エージェントから展開 | 監査ログと問い合わせ対応が回る |
この順序で進めれば、「AI エージェントをつなげたが、誰の権限で何が実行されたか分からない」という状態を避けやすくなります。
まとめ：Azure SQL に AI エージェントを接続するなら、監査主体を最初に決める
Azure SQL の「Audit Frontier AI Agents with SQL MCP Server」で最も重要なのは、AI エージェント時代の監査設計です。SQL MCP Server と Data API builder 2.0 の OBO 認証を使うと、エージェントや中間サーバーではなく、実際に操作を依頼したサインインユーザーを Azure SQL 側で認識し、監査ログに残せます。(Microsoft for Developers)
一方で、OBO は万能の標準設定ではありません。接続文字列、Entra ID アプリ登録、キャッシュ無効化、ログ分析、MCP ツール権限の見直しが必要です。単純な社内 API ではマネージド ID が適している場合もあります。
管理者が次に取るべき行動は明確です。まず、現在の AI エージェントや MCP サーバーが Azure SQL にどの ID で接続しているかを確認してください。そのうえで、監査ログに「サービス ID」が残れば十分なのか、「実ユーザー」が必要なのかを判断します。実ユーザー単位の追跡が必要なら、DAB 2.0 と OBO 認証を検証環境で構成し、Log Analytics で期待どおりの監査証跡が残ることを確認してから本番展開へ進めるべきです。
コメント