Azure Application Insightsは、Microsoft AzureのAPM（アプリケーションパフォーマンス管理）機能で、Webアプリやバックエンドの応答時間・エラー・依存関係・利用状況を収集し、可視化します。位置づけはAzure Monitorの一機能で、収集したデータはLog Analyticsワークスペースに保存されます。2024年から2025年にかけて「Classicリソースの廃止」「Connection Stringへの移行」「OpenTelemetryへの計装の切り替え」と前提が大きく変わり、古い手順のままでは動きません。この記事では、Azure Application Insightsとは何かという定義から、できること、メリットとデメリット、東日本リージョンの料金、Log AnalyticsやAzure Monitorとの違い、現行の導入手順、採用を決める条件までを、2026年10月時点の公式情報に沿って解説します。
まとめ：Azure Application Insightsの要点と導入可否を決める条件
先に結論を整理します。
- Azure Application InsightsはAzure MonitorのAPM機能で、リクエスト・依存関係・例外・トレース・カスタムイベント・メトリクスの6種のテレメトリを集めます。単体の製品ではなく、Azure Monitorの中の「アプリを見る層」です。
- 新規作成はworkspace-basedリソースが標準で、データはLog Analyticsワークスペースに入り、KQL（Kusto Query Language）で分析します。Classicリソースは2024年2月29日に廃止済みです。
- 接続はInstrumentation KeyではなくConnection Stringを使い（キー単体での取り込みは2025年3月31日にサポート終了）、計装はサーバー側ならAzure Monitor OpenTelemetry Distroが推奨です。ブラウザ側だけはJavaScript SDKを使います。
- 料金はLog Analytics側の取り込み従量課金で、2026年10月時点の東日本リージョンは1GBあたり3.34 USD、米国東部は2.30 USDです。毎月最初の5GBは無料で、費用はサンプリングと保持期間でほぼ決まります。
- 監視対象の大半がAzure上にあるなら第一候補です。AWSやオンプレミスが半分以上を占める構成では、商用APMとの併用か置き換えを検討します。
導入の判断条件は後半の独自章で、監視対象の比率とデータ量の2軸で具体的に示します。
Azure Application Insightsの定義とアプリ監視の対象
APMとしての定義とOpenTelemetry標準化で変わった計装の前提
Azure Application Insightsを正しくつかむ近道は、単体のツールではなく「Azure Monitorの一部」と捉えることです。Microsoftの公式概要ページは、Application InsightsをAzure Monitorのアプリケーションパフォーマンス監視（APM）機能と定義し、ベンダー中立の計装標準であるOpenTelemetryで収集したテレメトリを分析する場として説明しています。サーバーのCPUやメモリを見るリソース監視では分からない「どのAPIが遅いか」「どの外部呼び出しで失敗したか」を、アプリ内部から計測できる情報に変える層です。APMという監視の分類そのものを先に整理したい場合は、APM（アプリケーション性能監視）の仕組みと3種の監視データを解説した記事が前提知識になります。
対象はWebアプリ、バックエンドAPI、Azure Functions、仮想マシン上のアプリ、AKS上のマイクロサービス、ブラウザで動くフロントエンドなど幅広く、サーバー側は.NET・Java・Node.js・Pythonに対応します。計装の標準がOpenTelemetryに寄ったため、Application Insights専用の書き方を覚えるより、OpenTelemetry（OTel）の3つのシグナルとCollectorの考え方を理解しておくほうが、他社APMへ移るときにも知識が無駄になりません。
workspace-based標準化とClassic廃止後のリソース構造の違い
Classic Application Insightsリソースは2024年2月29日に廃止され、現在はworkspace-based（ワークスペースベース）が標準です。これは収集データをLog Analyticsワークスペースに保存する方式で、複数アプリのデータを1つのワークスペースに集約し、アクセス制御やコスト管理をLog Analytics側の仕組みで一元化できます。ワークスペースベースリソースの作成手順のとおり、新規作成すると自動的にこの方式になります。
実務で影響が大きいのは、テーブル名と保持期間の設定場所が変わった点です。Classic時代の手順書にある「Application Insights側で保持日数を選ぶ」操作は、workspace-basedではLog Analyticsのテーブル単位の設定に置き換わっています。古い社内手順を流用するときは、保持とエクスポートの章から見直すと手戻りが少なくなります。
Application Insightsの主な機能：収集できるテレメトリと可視化
機能の中心は「何を収集し、どう可視化するか」です。最初にテレメトリの種類を押さえると、画面の読み方と費用の増え方がつながって理解できます。
6種のテレメトリ（リクエスト・依存関係・例外・トレース・イベント・メトリクス）
収集データは大きく6種類に分かれます。リクエストはアプリへのHTTP呼び出し、依存関係はSQLや外部APIなど他サービスへの通信、例外はエラー、トレースはアプリ内の処理ログ、カスタムイベントは「購入ボタンのクリック」など任意の業務アクション、メトリクスは応答時間やCPU使用率などの数値です。実務でまず押さえるべきは「リクエスト・依存関係・例外」の3つで、応答遅延の原因がアプリ自身か外部依存かを切り分けられます。残りのトレース・イベント・メトリクスは、原因究明とビジネス指標の可視化を補強する位置づけです。
Log Analyticsに保存されると、それぞれAppRequests・AppDependencies・AppExceptions・AppTraces・AppEvents・AppMetricsといったテーブルに分かれます。費用の大半はAppTracesとAppDependenciesから生まれることが多いため、ログ出力の量と外部呼び出しの粒度は計装の段階で決めておきます。
アプリケーションマップとライブメトリックによる障害箇所の特定
アプリケーションマップは、Webアプリ・API・DB・外部サービスといった構成要素とその依存関係を図で表示する機能です。どのコンポーネントで応答時間が急増したかを一目で特定できます。ライブメトリックは、デプロイ直後のリクエスト数・失敗率・サーバー応答を秒単位で表示するため、リリース直後の異常検知に向きます。Azure Monitor Logsのコスト解説によれば、ライブメトリックの利用にはデータ量の課金がかかりません。障害対応では、マップで当たりを付けてから該当箇所のログへ降りる流れが効率的です。
1つのApplication Insightsリソースに複数のサービスから送る場合は、サービスごとにCloud Role Nameを設定しないとマップ上で1つの箱にまとまってしまいます。OpenTelemetry Distroでは環境変数OTEL_SERVICE_NAMEで指定でき、後述の導入手順のコード例にも含めています。
KQL（Kusto Query Language）による失敗リクエストの集計
収集データの抽出に使う言語はKQLです。SQLに似た構文で、ログとメトリクスに特化した集計・フィルタが数行で書けます。たとえば直近1時間で失敗したリクエストを多い順に並べるクエリは次のように書きます。
requests
| where timestamp > ago(1h) and success == false
| summarize failures = count() by name, resultCode
| order by failures desc結果はそのままグラフ化してダッシュボードにピン留めでき、エクスポートして分析資料にも使えます。KQLは後述のLog Analyticsでも同じ言語で、ワークスペース内の他ログと結合した分析にも応用できます。
AIエージェント監視とGrafanaダッシュボードなど追加された画面
2025年以降、Application Insightsに加わったのが、以下の新しい画面です。エージェントの詳細ビューは、Microsoft Foundry・Copilot Studio・他社フレームワークで作ったAIエージェントの呼び出しを1か所で追う画面で、LangChainやOpenAI Agents SDKで作ったエージェントもOpenTelemetry経由で送れます。プロンプト全文の収集は明示的に有効化したときだけ行われるため、個人情報を含む入力を扱うシステムでは有効化の判断を設計段階で決めておきます。
ほかにも、Azureポータル内でApplication InsightsのデータをGrafanaダッシュボードで表示する機能や、SDKの送信成功数・破棄数・再試行数を可視化するSDK Statsが公式概要ページに並んでいます（2026年10月時点）。従来のアプリケーションダッシュボード・失敗ビュー・パフォーマンスビューに加え、送信側の健全性まで同じリソースで確認できるようになりました。
Application Insights導入のメリットとデメリット・コスト超過の落とし穴
採用判断の本丸はメリットだけでなくデメリットの把握です。解説記事の多くがメリット偏重のため、ここではつまずきやすい点を具体的に示します。
メリット：Azure統合・低い導入コスト・コード変更なしの自動収集
最大の利点はAzureとのネイティブ統合です。Azure App ServiceやAzure Functionsでは作成時に有効化を選ぶだけで、コードを変更せずに基本的な監視が始まります。Log AnalyticsやAzure Monitorと監視基盤を共有するため、アラートや自動応答まで同じ画面で扱える構成です。サーバー単位では見えないアプリレベルのエラーや遅延を可視化できる点も、根本原因の特定で効きます。
デメリットと注意点：データ量課金・サンプリング・保持期間・学習コスト
注意すべき点は明確です。第一に、料金が取り込みデータ量に連動するため、トラフィックが増えると費用が想定より膨らみやすいことです。OpenTelemetry Distroには既定のサンプラーが組み込まれていますが、既定の方式と割合は言語とDistroの版で異なります。たとえばJavaエージェントは既定で1秒あたり5リクエストに制限してサンプリングするため、それを超える環境では一部のトレースが残りません。サンプリングは個別イベントの欠落を生むので、正確な件数集計が必要な指標はメトリクス（サンプリングの対象外）で取ります。
第二に、データ保持期間を長く取るほど保持コストが増えます。第三に、KQLとworkspace-basedの構成、Connection StringやOpenTelemetryの設定など、使いこなしに一定の学習コストがかかります。予算が読めない検証段階では、無料の月5GBの範囲で始め、サンプリングと保持期間を絞った状態から運用を広げるのが安全です。逆に、データ量を制御せず全テレメトリを長期保持する運用は、コスト面で推奨しません。
Log Analytics・Azure Monitorとの関係と計測・保存・分析の3層
「Application InsightsとLog Analyticsの違い」「Azure MonitorとApplication Insightsの違い」は混同されやすい論点です。三者は競合ではなく階層関係にあります。統合監視基盤としての全体像はAzure Monitorとは何かを解説した記事で整理しています。
| 名称 | 役割 | 関係 |
|---|---|---|
| Azure Monitor | 監視サービス全体の総称 | 上位の傘 |
| Application Insights | アプリ向けAPM機能 | Azure Monitorの一機能 |
| Log Analytics | ログの保存・KQL分析基盤 | 収集データの保存先 |
整理すると、Azure Monitorという傘の下にApplication Insightsがあり、そのApplication Insightsが集めたデータはLog Analyticsワークスペースに保存されます。つまり「Application Insightsで計測し、Log Analyticsに貯めて、KQLで分析する」という一本の流れです。workspace-based移行後はこの関係が前提になっているため、リソース作成時にどのLog Analyticsワークスペースを使うかを必ず指定します。複数アプリを同じワークスペースに集約すれば、横断的なクエリやコスト集約がしやすくなります。
課金の単位も、この収集先と保存先の関係に沿ったものです。workspace-basedのApplication Insightsはデータの取り込みと保持がワークスペース側で課金されるため、Log Analyticsの料金モデル（従量課金とコミットメントレベル）がそのまま適用されます。ワークスペースを本番と検証で分けるか、テーブルプランをどう選ぶかといった保存側の設計は、Log Analyticsの記事で詳しく扱っています。
Application Insightsの料金体系：東日本の取り込み単価と無料枠の実額
東日本リージョンと米国東部の従量単価・保持料金・無料取り込み枠の比較
料金はworkspace-based移行により、データを保存するLog Analyticsワークスペース側で課金されます。単価はリージョンごとに異なり、Microsoftが公開しているAzure Retail Prices APIで2026年10月1日に取得した値は次のとおりです。確定額はAzure Monitorの公式料金ページで確認してください。
| 項目 | 東日本 | 米国東部 |
|---|---|---|
| 分析ログの取り込み | 3.34 USD/GB | 2.30 USD/GB |
| 毎月の無料取り込み | 最初の5GB | 最初の5GB |
| 31日超の保持 | 0.15 USD/GB/月 | 0.10 USD/GB/月 |
分析ログの取り込み料金には31日分の保持が含まれ、それを超えて残す分に保持料金がかかります。たとえば東日本で月50GBを取り込む場合、無料の5GBを差し引いた45GBに3.34 USDを掛けて約150 USDが取り込み分の目安です。日本の利用者が多いシステムでもデータ所在の要件がなければ、ワークスペースのリージョン選択で単価が3割ほど変わる点は見積もり時に押さえておきます。
安定して大量に取り込むワークロード向けには、1日100GBから始まるコミットメントレベルがあり、従量課金より最大30%安くなります。ただし31日間は下位のレベルや従量課金へ戻せないため、取り込み量の実績が1か月以上たまってから選ぶのが無難です。
サンプリング・保持期間・日次上限による取り込みと保存費用の3つの設定
費用の管理で調整する設定は、次に示す3点です。1つ目はサンプリングで、OpenTelemetryのサンプリング解説によると、割合で間引く方式（固定割合）と1秒あたりのトレース数に上限を設ける方式（レート制限）の2つを選べます。OpenTelemetryの構成ページのとおり、標準の環境変数で次のように指定します。
# 1秒あたり最大5トレースに制限する場合
export OTEL_TRACES_SAMPLER="microsoft.rate_limited"
export OTEL_TRACES_SAMPLER_ARG=5
# 約10%だけ送る場合
# export OTEL_TRACES_SAMPLER="microsoft.fixed_percentage"
# export OTEL_TRACES_SAMPLER_ARG=0.1サンプリングの判断基準そのもの（ヘッドベースとテールベースの違い、割合の決め方）はトレースサンプリングの仕組みと率の決め方を解説した記事にまとめています。設定が効いているかは、次のKQLで種類ごとの保持率を見れば確認できます。保持率が100未満の種類は、サンプリングの対象となったものです。
union requests, dependencies, pageViews, browserTimings, exceptions, traces
| where timestamp > ago(1d)
| summarize RetainedPercentage = 100 / avg(itemCount) by bin(timestamp, 1h), itemType2つ目の設定対象は保持期間です。必要な日数だけを残し、監査目的の長期保存は低単価の長期保持へ回してください。3つ目は日次上限（daily cap）で、上限に達するとその日の取り込みが止まります。公式ドキュメントも日次上限をサンプリングの代わりではなく最後の安全弁と位置づけており、急増した日に監視の空白が生まれる点を理解したうえで設定します。
Application Insightsの導入手順：リソース作成からテレメトリ送信まで
手順は「リソース作成」「接続設定」「計装」「送信確認」の流れです。作成・接続・計装はそれぞれ判断点が異なるため分けて解説します。
workspace-basedリソースの作成とAzure CLIでの基本設定
Azureポータルで「Application Insights」を検索し、新規リソースを作成します。入力するのはリソース名・サブスクリプション・リソースグループ・リージョン、そして保存先となるLog Analyticsワークスペースです。新規作成時に自動的に選ばれる方式はworkspace-basedです。CLIで作成する場合は、保存先ワークスペースを明示してApplication Insightsコンポーネントを作ります。az monitor app-insights componentのリファレンスによると、このコマンドはapplication-insights拡張（Azure CLI 2.71.0以上）に含まれ、初回実行時に自動でインストールされます。
az monitor app-insights component create \
--app my-appinsights \
--location japaneast \
--resource-group my-rg \
--workspace my-loganalytics-workspace \
--application-type webリファレンス上、–retention-timeでの保持日数指定はワークスペースに接続していないリソースだけが対象です。workspace-basedでの保持期間の設定先は、Log Analytics側です。作成後にConnection Stringが生成されるので、これを計装側で使います。所要は数分で、作成直後からデータ受信の準備が整います。
Connection Stringの取得と旧キー廃止後の接続設定
接続にはConnection Stringを使います。かつて使われたInstrumentation Key単体でのグローバル取り込みは、2025年3月31日にサポートが終了しました。Connection Stringの公式解説によると、Connection Stringはセミコロン区切りのキーと値の組で、グローバルな取り込みエンドポイントへの依存をなくして信頼性を上げ、リージョン別エンドポイントとMicrosoft Entra IDでの認証付き取り込みに対応するための仕組みです。最大長は4,096文字です。
設定ファイルに直書きせず、CLIで取得した値を環境変数（やAzure Key Vault）経由で渡すと、漏洩リスクを抑えられます。
export APPLICATIONINSIGHTS_CONNECTION_STRING="$(az monitor app-insights component show \
--app my-appinsights --resource-group my-rg \
--query connectionString -o tsv)"
echo "$APPLICATIONINSIGHTS_CONNECTION_STRING"
# InstrumentationKey=...;IngestionEndpoint=https://japaneast-1.in.applicationinsights.azure.com/;...古い記事のInstrumentation Key前提の手順をそのまま使うと取り込みできないため、必ずConnection Stringで設定してください。公式ドキュメントは、コード内での指定をローカル開発とテストに限り、本番は環境変数で渡すよう推奨しています。
OpenTelemetry Distroの言語別パッケージとPython計装例
アプリへの組み込み（計装）は、従来のClassic API SDKではなくAzure Monitor OpenTelemetry Distroが推奨です。OpenTelemetry有効化の公式手順に載っている言語別のパッケージは次のとおりです（2026年10月時点）。
| 言語 | パッケージ | 導入方法 |
|---|---|---|
| ASP.NET Core | .NET向けDistro | dotnet add package |
| Node.js | Node.js向けDistro | npm install |
| Python | Python向けDistro | pip install |
| Java | Javaエージェント 3.7系 | JVM引数で指定 |
表のパッケージの正式名称は、ASP.NET CoreがAzure.Monitor.OpenTelemetry.AspNetCore、Node.jsが@azure/monitor-opentelemetry、Pythonがazure-monitor-opentelemetry、Javaがapplicationinsights-agent 3.7系です。表では言語ごとの短い表記を使っていますが、導入時には対応する正式名称を確認してください。
Pythonは3.10以上が前提です。最小構成は、パッケージを入れて起動時に1行呼ぶだけで、接続先は先ほどの環境変数から読み込まれます。
pip install azure-monitor-opentelemetry
export OTEL_SERVICE_NAME="order-api"
# app.py
import logging
from azure.monitor.opentelemetry import configure_azure_monitor
# APPLICATIONINSIGHTS_CONNECTION_STRING を読み込んで送信を始める
configure_azure_monitor(logger_name="orderapi")
logger = logging.getLogger("orderapi")
logger.warning("order failed: id=%s", 123)logger_nameを指定するのは、SDK自身のログまで収集してデータ量が膨らむのを防ぐためです。Node.jsはuseAzureMonitor()、ASP.NET CoreはAddOpenTelemetry().UseAzureMonitor()を起動時に呼ぶ形で、考え方は同じです。Javaはコード変更なしで、JVM引数に-javaagentでエージェントのjarを指定します。組み込み後は数分待ってからライブメトリックや概要画面でリクエストや例外が表示されるかを確認します。
Application Insightsの障害対応・自動化と他製品との連携
運用での使いどころと連携先を、KQLによる障害対応、Power Platformによる自動化、商用APMとの併用の3つの場面で示します。
KQLによる障害調査と応答時間・エラーを対象にしたアラート設定例
障害時の調査に有効なのが、KQLによるログの絞り込みです。特定時間帯に集中したエラーコードや、特定ユーザーがどの操作でエラーに至ったかをセッション単位で追跡できます。さらにメトリクスアラート（例：5分平均の応答時間が2秒超）やログアラートを設定し、メール・Webhook・Teams通知につなげると、常時監視なしで異常検知から対応開始まで自動化できます。メトリクスはサンプリングされないため、件数や応答時間のしきい値アラートはログよりメトリクスに置くと取りこぼしがありません。
Azure Functionsとの連携と通知・業務アプリ計測の自動化
Azure Functionsはアラートをトリガーに自動処理（スケールアウト、ログの保存、チケット登録）を実行でき、イベント駆動の運用を組めます。Functions自体を監視する場合は、host.jsonで”telemetryMode”: “OpenTelemetry”を指定し、アプリ設定にAPPLICATIONINSIGHTS_CONNECTION_STRINGを追加するのが、公式概要ページに示された手順です。Power Automateを使えば、アラート発生時にフローを起動して担当者へ通知したり、SharePointへ記録を残したりとノーコードで運用フローを構築できます。Power Appsで作った業務アプリも、画面遷移やボタン操作をカスタムイベントとして記録すればUX分析に使えます。
Datadog・New Relic等との比較と併用の切り分け方
Application InsightsはAzureネイティブで導入が容易・コスト効率が高い一方、DatadogやNew Relicはマルチクラウドや他ベンダー製品との統合、ダッシュボードの自由度に強みがあります。判断の目安はシンプルで、監視対象がAzure中心ならApplication Insightsで十分、AWSやオンプレミスを含む横断監視が必要なら商用APMの併用を検討する、という切り分けが実務的です。AWS側の同種機能はApplication Signalsの概要と基本機能が参考になります。可観測性ツール全般の比較軸はO11y Cloudの可観測性ガイドも合わせて確認してください。
Application Insightsの採用・見送り条件と監視対象・データ量
ここまでの機能と料金を踏まえ、採用の可否を条件で言い切ります。軸は「監視対象のうちAzure上にある割合」と「月あたりの取り込み量」の2つです。
採用する条件：Azure比率が高く月の取り込みが数十GBまでの構成
監視対象の大半がApp Service・Functions・AKS・Container AppsなどAzure上にあり、月の取り込み量が数十GBまでに収まる構成なら、Application Insightsが採用の第一候補です。追加のエージェント契約が不要で、無料の5GBを超えても東日本で1GBあたり3.34 USDの従量課金から始められるため、商用APMのホスト単位課金より初期費用を低く抑えられます。計装をOpenTelemetry Distroで行っておけば、将来ほかのAPMへ移るときもアプリ側のコードを大きく書き換えずに済みます。
採用を見送る場面：マルチクラウド横断とブラウザ計測が主目的の構成
一方、AWSやオンプレミスが監視対象の半分以上を占める構成では、Application Insightsを主役にしません。Azure以外のログを同じワークスペースへ集めることはできますが、ダッシュボードとアラートの作り込みが二重になり、運用担当者が見る画面が分かれてしまいます。この場合の選択肢は、商用APMを主役にしてAzure部分だけApplication Insightsを併用する構成か、OpenTelemetry Collectorで送り先を一本化する構成です。また、ブラウザ側の計測はOpenTelemetryではなくJavaScript SDKになるため、フロントエンドの体験分析が主目的なら専用ツールとの比較から始めます。
監視基盤の選定やワークスペース設計、OpenTelemetryでの計装を含むAzure環境の構築を外部に相談したい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）サービスで、既存構成の棚卸しから監視設計までを支援しています。
よくある質問
Azure Application Insightsについて、導入前によく寄せられる質問をまとめました。
Azure Application InsightsとLog Analyticsの違いは何ですか？
役割が異なります。Azure Application Insightsはアプリのテレメトリを収集・可視化するAPM機能、Log Analyticsはそのデータを保存しKQLで分析する基盤です。workspace-basedのApplication Insightsは収集したデータをLog Analyticsワークスペースに保存するため、両者は対立ではなく「収集役」と「保存・分析役」という連携関係にあります。保存側の設計（ワークスペースの分け方・テーブルプラン・保持コスト）はAzure Log Analyticsとは？ワークスペース設計・KQL検索・テーブルプラン別の保存コストにまとめました。
Instrumentation Keyはまだ使えますか？
Instrumentation Key単体でのグローバル取り込みは2025年3月31日にサポートが終了しました。現在はConnection Stringの利用が必須です。Connection Stringの中にもInstrumentationKeyという項目は残っていますが、これはリソースを識別するための値で、セキュリティ上の鍵ではありません。古い手順のままだとテレメトリが取り込まれない場合があるため、Connection Stringへの移行を済ませてください。
料金はどのくらいかかりますか？
取り込んだデータ量に対する従量課金で、2026年10月時点の東日本リージョンは1GBあたり3.34 USD、米国東部は2.30 USDです。毎月最初の5GBは無料で、31日を超えて保持する分には別途保持料金がかかります。1日100GB以上を安定して取り込むならコミットメントレベルで最大30%下げられます。サンプリングと保持期間の調整が費用を抑える鍵で、最新単価は公式の料金ページで確認してください。
導入にコードの変更は必要ですか？
App ServiceやAzure Functionsでは、作成時に有効化を選ぶだけでコード変更なしに基本監視を始められます。Javaもエージェントのjarを指定するだけで、コードの変更は不要です。詳細なカスタムイベントやトレースを収集する場合は、Azure Monitor OpenTelemetry Distroを組み込んで計装します。サーバー側の対応言語は.NET・Node.js・Python・Javaで、ブラウザ側はJavaScript SDKを使います。
Classicリソースを使っているのですが移行は必要ですか？
Classic Application Insightsリソースは2024年2月29日に廃止されました。Microsoftは自動移行も進めていますが、Continuous Exportなど一部機能はworkspace-basedでの代替（診断設定やLog Analyticsのデータエクスポート）に切り替える必要があります。保持期間の設定場所もLog Analytics側に移るため、残っているClassicリソースはworkspace-basedへの移行状況と保持・エクスポートの設定を確認してください。
関連記事
- Azure Monitorとは？監視の仕組み・Log AnalyticsとApplication Insightsの関係・料金モデルとDatadogとの違い：Application Insightsの上位にある監視基盤の全体像
- OpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説：Distroの土台になる計装標準
- Application Signalsとは何か？概要と基本機能をやさしく解説：AWS側で同じ役割を担うAPM機能
- AKS（Azure Kubernetes Service）とは｜できること・料金・始め方を解説【2026年版】：Application Insightsで監視する代表的な実行基盤
- Azure Container Appsとは？特徴・料金・デプロイ手順とAKS・App Serviceの違い：コンテナアプリを監視する場合の実行基盤
