Azure Monitor Application InsightsでAPIキーを使ってデータをクエリしている場合、対応の結論は明確です。2026年9月30日までに、Application Insightsのクエリ認証をMicrosoft Entra ID認証へ移行する必要があります。 2026年4月21日の更新では、Application Insightsのデータ取得に使う認証方式をAPIキーからMicrosoft Entra IDへ切り替える方針が改めて示されました。対象になるのは、アプリからテレメトリを送信する設定ではなく、api.applicationinsights.io などを使ってApplication Insightsのデータを検索・取得する処理です。(Microsoft Azure)
セキュリティ管理者、ID基盤チーム、コンプライアンス担当者が最初にやるべきことは、既存のAPIキーの棚卸しです。ダッシュボード、監査レポート、ETL、SIEM連携、PowerShellスクリプト、独自運用ツールのどこかにApplication Insights APIキーが残っていると、期限後にクエリ取得が失敗するリスクがあります。
Azure Monitor Application Insightsの2026年4月更新ポイント
今回の更新で重要なのは、「Application Insightsそのものが使えなくなる」という話ではありません。APIキーでApplication Insightsのデータをクエリする方式をやめ、Microsoft Entra IDベースの認証へ移行するという変更です。
| 確認項目 | 内容 | 実務上の判断 |
|---|---|---|
| 対象サービス | Azure Monitor Application Insights | Application Insightsのデータ取得APIを使っている環境を確認する |
| 対象の認証 | Application Insights APIキーによるクエリ認証 | x-api-key やAPI Accessのキー利用を探す |
| 移行先 | Microsoft Entra ID認証 | アプリ登録、マネージドID、サービスプリンシパル、RBACを設計する |
| 期限 | 2026年9月30日 | 期限直前ではなく、検証・並行稼働・キー廃止まで逆算する |
| 直接の対象外 | Instrumentation Key、Connection Stringによる通常のテレメトリ送信 | ただしローカル認証無効化を進める場合は別途影響確認が必要 |
Application InsightsのQuery APIは、https://api.applicationinsights.io/v1/apps/{appId}/query のようなエンドポイントでAnalyticsクエリを実行します。Microsoft Learnでは、GETとPOSTの両方のクエリ実行APIが説明されており、appId はAzure portalのAPIアクセス設定ブレードで確認できるApplication InsightsのアプリケーションIDです。(Microsoft Learn)
何が変わるのか：APIキーからMicrosoft Entra ID認証へ
従来は、Application Insightsの「APIアクセス」で発行したAPIキーを、外部ツールやスクリプトに持たせてクエリを実行しているケースがありました。今後は、この方式をMicrosoft Entra IDで認証されたアクセストークンに置き換える必要があります。
| 観点 | APIキー認証 | Microsoft Entra ID認証 |
|---|---|---|
| 認証の主体 | 共有されやすいキー | ユーザー、アプリ登録、サービスプリンシパル、マネージドID |
| 権限管理 | キー単位の管理になりがち | RBAC、APIアクセス許可、IDライフサイクルで管理 |
| 監査 | 誰が使ったか追いにくい | IDベースで説明しやすい |
| 運用リスク | キーの放置、漏えい、所有者不明が起きやすい | 権限棚卸し、資格情報ローテーション、無効化がしやすい |
| 推奨される用途 | 期限までの暫定利用 | 本番運用の標準方式 |
Microsoft Learnでは、Application InsightsのクエリをMicrosoft Entra IDで実行するには、Microsoft Entra IDにクライアントアプリを登録し、Application Insights APIへのアクセス許可を設定し、Application Insightsリソース側でIAMロールを割り当てる流れが示されています。クライアント資格情報フロー、認可コードフロー、暗黙的フローがサポートされ、クエリ実行時はBearerトークンを Authorization ヘッダーに入れて呼び出します。(Microsoft Learn)
影響を受けやすい利用シーン
次のような用途でApplication Insightsのデータを外部から取得している場合、移行対象である可能性が高いです。
- 障害分析用の社内ダッシュボード
- 月次・週次のSLAレポート作成バッチ
- PowerShell、Python、C#などで作った運用スクリプト
- SIEM、ITSM、監査基盤へのログ連携
- BIツールやデータウェアハウスへの取り込み
- 複数のApplication Insightsリソースを横断して検索する独自ツール
- 退職者や旧プロジェクトが作成した「所有者不明」のAPIキー
特に注意したいのは、Application Insightsリソースの管理者がAPIキーの存在を知っていても、実際にどのシステムが使っているか分からないケースです。APIキーは一度コピーされると、Key Vault、CI/CD変数、アプリ設定、ローカルスクリプト、外部SaaSの接続設定などに散らばります。Azureポータル上のキー一覧を見るだけでは、利用実態までは把握できません。
まず確認すべき棚卸しポイント
Application InsightsのAPIキーは、Azureポータルの「APIアクセス」から確認できます。Azure CLIでは az monitor app-insights api-key show により、Application Insightsリソースに関連付けられたAPIキーを取得できます。Microsoft LearnのCLIリファレンスでも、APIキーの作成、削除、表示コマンドが案内されています。(Microsoft Learn)
az monitor app-insights api-key show \
--app <Application Insightsリソース名> \
--resource-group <リソースグループ名>棚卸しでは、次の検索観点を使うと見落としを減らせます。
| 探す場所 | 検索キーワード・確認内容 |
|---|---|
| ソースコード | api.applicationinsights.io、x-api-key、Application Insights API、/v1/apps/ |
| CI/CD | GitHub Actions、Azure DevOps、Jenkinsなどのシークレット変数 |
| Azure設定 | App Serviceのアプリ設定、Function App設定、Automation Account変数 |
| Key Vault | appinsights、applicationinsights、ai-api-key などを含むシークレット名 |
| 外部ツール | BI、SIEM、監視SaaS、社内ポータル、レポート生成基盤 |
| ドキュメント | 運用手順書、障害対応手順、監査レポート作成手順 |
棚卸し結果は、単なる一覧ではなく「誰が所有しているか」「どのクエリを実行しているか」「停止すると何に影響するか」まで記録します。APIキーが見つかっても所有者が分からない場合は、期限まで放置せず、ログ取得先のレポートや実行スケジュールから逆引きしてください。
Microsoft Entra ID認証への移行手順
移行は、単にAPIキーをBearerトークンに置き換えるだけではありません。ID、権限、資格情報の保管、監査証跡まで含めて設計する必要があります。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 利用元を分類する | 人が使うツールか、無人バッチか、Azure上のワークロードかを分ける | 無人処理はサービスプリンシパルやマネージドIDを優先 |
| IDを用意する | Microsoft Entra IDでアプリ登録、サービスプリンシパル、マネージドIDを設計 | Azure上で動く処理はマネージドIDが扱いやすい |
| APIアクセス許可を設定する | Application Insights APIのData.Readなど、必要な権限を設定 | 最小権限を基本にし、過剰なReader権限を避けられるか検討 |
| RBACを割り当てる | Application Insightsリソースまたは適切なスコープにロールを付与 | リソース単位、リソースグループ単位、サブスクリプション単位を使い分ける |
| 呼び出し方式を変更する | APIキーではなく、取得したアクセストークンをBearerトークンとして送る | 401、403、テナント不一致、期限切れトークンをテスト |
| 並行稼働する | APIキー方式とEntra ID方式の結果を比較する | クエリ結果、実行時間、エラー率、スケジュール処理を確認 |
| APIキーを廃止する | 利用停止後にキーを削除し、証跡を残す | コンプライアンス監査用に削除日、担当者、影響確認を記録 |
検証用には、次のようにアクセストークンを取得してApplication Insights APIを呼び出す流れを確認できます。実運用では、ユーザーの手動ログインではなく、マネージドID、サービスプリンシパル、証明書、フェデレーション資格情報など、組織のID運用ルールに合わせて実装してください。
ACCESS_TOKEN=$(az account get-access-token \
--resource https://api.applicationinsights.io \
--query accessToken \
-o tsv)
curl -X POST "https://api.applicationinsights.io/v1/apps/<APP_ID>/query" \
-H "Authorization: Bearer ${ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{"query":"requests | take 10"}'Microsoftのドキュメントでは、Application Insights API向けのトークン取得時に https://api.applicationinsights.io を使い、API呼び出しでは Authorization: Bearer <access token> を付ける例が示されています。(Microsoft Learn)
APIキーとInstrumentation Keyを混同しない
今回の変更で特に誤解が多いのが、Application Insights APIキーとInstrumentation Key、Connection Stringの違いです。
| 項目 | 主な用途 | 今回の直接対象か |
|---|---|---|
| Application Insights APIキー | Application InsightsのデータをAPI経由でクエリ取得する | 対象 |
| Microsoft Entra ID認証 | APIキーの代替としてクエリAPIを認証する | 移行先 |
| Instrumentation Key | テレメトリを特定のApplication Insightsリソースに関連付ける識別子 | 直接の対象ではない |
| Connection String | アプリがテレメトリ送信先を指定するための設定 | 直接の対象ではない |
Microsoft Learnでは、Connection Stringは送信先Application Insightsリソースを指定するための設定であり、Instrumentation Keyはインジェストサービスがテレメトリを特定リソースに関連付けるための一意識別子で、セキュリティトークンやシークレットとは見なされないと説明されています。(Microsoft Learn)
ただし、「今回のAPIキー廃止」と「ローカル認証の無効化」は分けて考える必要があります。Microsoft Entra ID認証を有効にした後、Application Insightsでローカル認証を無効化すると、APIキーなどを含むデータアクセスにも影響します。また、Application InsightsのMicrosoft Entra認証によるテレメトリ取り込みには、JavaScript Web SDKなど一部サポート対象外のシナリオがあります。(Microsoft Learn)
つまり、クエリAPIの移行を進めることは重要ですが、同じタイミングでローカル認証を無効化する場合は、テレメトリ送信側のSDKや実装も必ず確認してください。順序を誤ると、ログ検索ではなくログ収集そのものが止まる可能性があります。
セキュリティ、ID、コンプライアンス担当が分担すべき作業
この変更は開発チームだけの作業ではありません。APIキーの廃止は、認証方式、権限管理、監査証跡に関わるため、複数チームで役割を分けたほうが安全です。
| 担当 | 主な作業 | 成果物 |
|---|---|---|
| セキュリティ管理者 | APIキーの棚卸し、漏えいリスク評価、キー削除方針の策定 | APIキー台帳、廃止計画、例外管理表 |
| ID基盤チーム | Microsoft Entra IDアプリ登録、サービスプリンシパル、マネージドID、RBAC設計 | ID設計書、ロール割り当て一覧、資格情報管理方針 |
| コンプライアンス担当 | 監査証跡、期限管理、移行完了証明、例外承認 | 監査用エビデンス、コントロール記述、承認履歴 |
| 開発・運用チーム | コード修正、接続テスト、クエリ結果比較、ジョブ監視 | 修正済みコード、テスト結果、切り戻し手順 |
特にグローバル組織では、各リージョンや事業部が独自に作ったApplication Insights連携が残っていることがあります。中央のAzure管理チームが「APIキーは使っていない」と判断しても、現場のレポート自動化や古い監視ツールに残っているケースは珍しくありません。
移行時に失敗しやすいポイント
App ID、リソースID、Instrumentation Keyを取り違える
Application InsightsのクエリAPIで使う {appId} は、Azure portalのAPIアクセス設定ブレードで確認できるアプリケーションIDです。Instrumentation KeyやAzureリソースIDとは用途が違います。取り違えると、認証以前にクエリ対象が解決できません。(Microsoft Learn)
RBACを割り当てた直後の403を誤判定する
Microsoft Entra ID認証では、RBACの反映に時間がかかる場合があります。Microsoft Learnでは、Azure Application Insights REST APIが新しいRBAC権限を認識するまで最大60分かかる可能性があり、その間は403で失敗する場合があると説明されています。(Microsoft Learn)
権限を付与してすぐに403が出た場合は、設定ミスと決めつけず、テナント、対象リソース、ロール、APIアクセス許可、反映待ちを順番に確認してください。
期限直前にAPIキーを削除する
APIキーの削除は最後の工程です。先にキーを削除すると、どのジョブが失敗したかを本番障害で発見することになります。まずMicrosoft Entra ID方式で並行稼働し、同じKQLで同じ結果が得られるか、スケジュール実行が成功するか、エラー時の通知が動くかを確認してから削除します。
ローカル認証無効化を一括で進める
セキュリティ強化の観点ではローカル認証の無効化は魅力的ですが、Application Insightsのテレメトリ取り込み側に影響する場合があります。クエリAPIの移行と、テレメトリ送信の認証強制は、同じ「Entra ID対応」でも影響範囲が異なります。段階的に進め、SDKや自動インストルメンテーションの対応状況を確認してください。
2026年9月30日までの現実的な対応スケジュール
期限まで余裕があるように見えても、APIキーの利用箇所が複数部門に散っている環境では、棚卸しに時間がかかります。2026年9月30日を本番切り替え日ではなく、APIキー利用が残っていない状態の完了期限として扱うべきです。
| 時期 | 推奨アクション |
|---|---|
| 2026年4〜5月 | APIキー棚卸し、所有者特定、新規APIキー発行の抑制 |
| 2026年6月 | Microsoft Entra ID設計、権限設計、移行対象の優先順位付け |
| 2026年7月 | 主要バッチ、ダッシュボード、外部連携の実装修正 |
| 2026年8月 | 並行稼働、クエリ結果比較、403・401・トークン更新の検証 |
| 2026年9月前半 | 低リスクなAPIキーから削除、監査証跡の整理 |
| 2026年9月30日まで | 全APIキー依存の解消、例外ゼロまたは承認済み例外の明文化 |
コンプライアンス部門が関わる場合は、単に「移行しました」では不十分です。APIキーの一覧、移行先ID、ロール割り当て、検証結果、削除記録、残存リスクを証跡として残しておくと、監査対応がスムーズになります。
まとめ：最初の一手はAPIキーの棚卸し
Azure Monitor Application Insightsの2026年4月更新では、Application Insightsのクエリ認証を2026年9月30日までにMicrosoft Entra IDへ移行する方針が明確になりました。影響を受けるのは、主にApplication Insights APIキーを使ってデータを取得しているダッシュボード、スクリプト、外部連携、監査レポート基盤です。
まずは、Application InsightsリソースごとにAPIキーの有無を確認し、api.applicationinsights.io や x-api-key を使う実装を探してください。そのうえで、利用元ごとにマネージドID、サービスプリンシパル、ユーザー認証のどれを使うかを決め、Microsoft Entra ID認証での並行稼働とキー削除まで進めます。
期限対応として見るのではなく、長年残っていた共有キー認証をIDベースのアクセス管理へ整理する機会として進めるのが、セキュリティ、運用、監査のいずれにとっても現実的です。
コメント