2025.06.10 プラットフォーム

Application Insightsとは？機能・料金・導入手順とLog Analyticsとの違い【2026年版】

Application Insightsは、Microsoft AzureのAPM（アプリケーションパフォーマンス管理）機能で、Webアプリやバックエンドの応答時間・エラー・依存関係・利用状況を自動で収集し、可視化します。位置づけはAzure Monitorの一機能で、収集したデータはLog Analyticsワークスペースに保存されます。2024年以降「Classicリソースの廃止」「Connection Stringへの移行」「OpenTelemetryへの計装の切り替え」と前提が大きく変わりました。この記事は、何ができるか・メリットとデメリット・料金・Log AnalyticsやAzure Monitorとの違い・最新の導入手順までを、2026年6月時点の公式情報に沿ってまとめます。

目次

まとめ：Application Insightsの要点と導入判断

Application InsightsはAzure MonitorのAPM機能で、SDKやエージェントを組み込んだアプリから、リクエスト・依存関係・例外・トレース・カスタムイベント・メトリクスの6種のテレメトリを収集します。現在の標準はworkspace-basedリソースで、データはLog Analyticsワークスペースに入り、KQL（Kusto Query Language）で横断的に分析できます。接続はInstrumentation KeyではなくConnection Stringが必須になり（旧キー取り込みは2025年3月31日にサポート終了）、計装は従来のSDKではなくAzure Monitor OpenTelemetry Distroが推奨です。料金は取り込んだデータ量に対する従量課金（約2.30 USD/GB、無料枠5GB/月）で、サンプリングと保持期間がコスト管理の要になります。Azure中心の構成なら導入は数分で始められて費用対効果が高い一方、データ量が増えると課金が読みにくく、マルチクラウドではDatadog等の方が一元管理しやすい場面もあります。以下で機能・違い・料金・導入手順を順に見ていきます。

Application Insightsとは：Azure MonitorのAPM機能としての位置づけ

Application Insightsを正しくつかむ近道は、単体のツールではなく「Azure Monitorの一部」と捉えることです。アプリケーション可観測性（Observability）を担う層で、サーバーのリソース監視では見えないアプリ内部の挙動を、外から計測できる情報に変えます。対象はWebアプリ、バックエンドAPI、Azure Functions、Kubernetes上のマイクロサービスなど幅広く、.NET・Java・Node.js・Pythonに対応します。

重要な前提として、2024年2月29日にClassic Application Insightsリソースは廃止され、現在はworkspace-based（ワークスペースベース）が標準です。これは収集データをLog Analyticsワークスペースに保存する方式で、複数アプリのデータを1つのワークスペースに集約し、アクセス制御やコスト管理をLog Analytics側の仕組みで一元化できます。新規作成すると自動的にこの方式になります。

Application Insightsの主な機能：収集できるテレメトリと可視化

機能の中心は「何を収集し、どう可視化するか」です。GSCでも「insights 機能」での流入が多く、収集項目の理解が読者の最初の関心になります。

6種のテレメトリ（リクエスト・依存関係・例外・トレース・イベント・メトリクス）

収集データは大きく6種類に分かれます。リクエストはアプリへのHTTP呼び出し、依存関係はSQLや外部APIなど他サービスへの通信、例外はエラー、トレースはアプリ内の処理ログ、カスタムイベントは「購入ボタンのクリック」など任意の業務アクション、メトリクスは応答時間やCPU使用率などの数値です。実務でまず押さえるべきは「リクエスト・依存関係・例外」の3つで、応答遅延の原因がアプリ自身か外部依存かを切り分けられます。残りのトレース・イベント・メトリクスは、原因究明とビジネス指標の可視化を補強する位置づけです。

アプリケーションマップとライブメトリックによる可視化

アプリケーションマップは、Webアプリ・API・DB・外部サービスといった構成要素とその依存関係を図で表示する機能です。どのコンポーネントで応答時間が急増したかを一目で特定できます。ライブメトリックストリームは、デプロイ直後のリクエスト数・失敗率・サーバー応答をほぼリアルタイム（秒単位）で表示するため、リリース直後の異常検知に向きます。障害対応では、マップで当たりを付けてから該当箇所のログへ降りる流れが効率的です。

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でも同じ言語で、ワークスペース内の他ログと結合した分析にも応用できます。

導入のメリットとデメリット（注意点・コスト超過の落とし穴）

採用判断の本丸はメリットだけでなくデメリットの把握です。GSCでも「insights デメリット」での表示があるのに、解説記事の多くがメリット偏重のため、ここを具体的に示します。

メリット：Azure統合・低い導入コスト・コード変更なしの自動収集

最大の利点はAzureとのネイティブ統合です。App ServiceやAzure Functionsでは作成時に有効化を選ぶだけで、コードを変更せずに基本的な監視が始まります。Log AnalyticsやAzure Monitorと監視基盤を共有するため、アラートや自動応答まで同じ画面でつながります。サーバー単位では見えないアプリレベルのエラーや遅延を可視化できる点も、根本原因の特定で効きます。

デメリットと注意点：データ量課金・サンプリング・保持期間・学習コスト

注意すべき点は明確です。第一に、料金が取り込みデータ量に連動するため、トラフィックが増えると費用が想定より膨らみやすいことです。対策として、Application Insightsは既定で適応型サンプリング（送信量に応じて取り込み割合を自動調整）を行いますが、サンプリングは個別イベントの欠落を生むため、正確な件数集計が必要な指標では無効化やカスタムメトリクス併用の検討が必要です。第二に、データ保持期間（既定はLog Analytics側の設定に従う）を長く取るほど保持コストが増えます。第三に、KQLとworkspace-basedの構成、Connection StringやOpenTelemetryの設定など、使いこなしに一定の学習コストがかかります。小規模で予算が読めない検証段階では、まず無料枠5GB/月の範囲で始め、サンプリングと保持期間を絞った状態から運用を広げるのが安全です。逆に、データ量を制御せず全テレメトリを長期保持する運用は、コスト面で推奨しません。

Log Analytics・Azure Monitorとの違いと関係

「application insights log analytics 違い」「azure monitor application insights 違い」は混同されやすく、検索でも一定数あります。三者は競合ではなく階層関係です。

名称 役割 関係
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移行により、データを保存するLog Analyticsワークスペース側で課金されます。基本は従量課金で、2026年6月時点で取り込んだデータ量1GBあたり約2.30 USD（リージョンにより変動）、Log Analyticsの無料枠として5GB/月が請求アカウント単位で付きます。安定して大量に取り込むワークロード向けには、固定日額と割引単価のコミットメント階層（100GB/日〜）も選べます。最新の単価は変動するため、確定額は公式の料金ページで確認してください。

コスト最適化の実務は3点に集約されます。送信量を抑える適応型サンプリングを適切に設定すること、必要な保持期間だけを残すこと、そして不要なテレメトリ（冗長なトレースや過剰なカスタムイベント）を計装段階で間引くことです。取り込み量を日次で監視し、上限（日次キャップ）を設定しておくと、予期しない急増による課金を防げます。

導入手順：リソース作成からテレメトリ送信まで

GSCで最も表示が多いのが「insights 導入」（imp290）です。手順は「リソース作成」「接続設定」「計装」「送信確認」の流れで、作成・接続・計装はそれぞれ判断点が異なるため分けて解説します。

workspace-basedリソースの作成と基本設定

Azureポータルで「Application Insights」を検索し、新規リソースを作成します。入力するのはリソース名・サブスクリプション・リソースグループ・リージョン、そして保存先となるLog Analyticsワークスペースです。新規作成は自動的にworkspace-basedになります。CLIで作成する場合は、保存先ワークスペースを明示してApplication Insightsコンポーネントを作ります。

az monitor app-insights component create \
  --app my-appinsights \
  --location japaneast \
  --resource-group my-rg \
  --workspace my-loganalytics-workspace \
  --application-type web

作成後にConnection Stringが生成されるので、これを計装側で使います。所要は数分で、作成直後からデータ受信の準備が整います。

接続設定：Connection Stringの利用（Instrumentation Keyは廃止）

接続にはConnection Stringを使います。かつて使われたInstrumentation Keyベースのグローバル取り込みは、2025年3月31日にサポートが終了しました。Connection Stringはリージョン別エンドポイントと認証付き取り込みに対応するための仕組みで、現在はこちらが必須です。設定ファイルに直書きせず、次のように環境変数（やAzure Key Vault）経由で渡すと、漏洩リスクを抑えられます。

export APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=00000000-0000-0000-0000-000000000000;IngestionEndpoint=https://japaneast-1.in.applicationinsights.azure.com/"

古い記事のInstrumentation Key前提の手順をそのまま使うと取り込みできないため、必ずConnection Stringで設定してください。

計装：Azure Monitor OpenTelemetry Distro（.NET／Node.js／Python／Java）

アプリへの組み込み（計装）は、従来のClassic API SDKではなくAzure Monitor OpenTelemetry Distroが推奨です。Classic SDKは多くの言語でメンテナンスモードに入っており、新規構築はOpenTelemetryベースが標準になりました。対応言語は.NET・Node.js・Python・Javaで、各言語のパッケージマネージャー（NuGet・npm・pip・Maven）でDistroを導入し、Connection Stringを設定します。既存の.NET SDK 2.x環境はSDK 3.x経由でOpenTelemetry実装へ移行でき、TelemetryClientなどのAPIをおおむね維持したまま切り替えられます。組み込み後はライブメトリックストリームでリクエストや例外が表示されるかを確認します。

運用シナリオと他サービス連携（KQL・Power Platform・商用APM）

「insights 活用」やDatadog・Power Automate・Azure Functionsとの組み合わせも一定の検索があります。運用での使いどころと連携先を具体例で示します。

KQLによるトラブルシュートとアラート設定

障害時はKQLでの絞り込みが効きます。特定時間帯に集中したエラーコードや、特定ユーザーがどの操作でエラーに至ったかをセッション単位で追跡できます。さらにメトリクスアラート（例：5分平均の応答時間が2秒超）やログアラートを設定し、メール・Webhook・Teams通知につなげると、常時監視なしで異常検知から対応開始まで自動化できます。スマート検出は通常パターンからの逸脱を自動で見つけるため、しきい値を決めにくい指標の補完に向きます。

Azure Functions・Power Automate・Power Appsとの連携

Azure Functionsはアラートをトリガーに自動処理（スケールアウト、ログの保存、チケット登録）を実行でき、イベント駆動の運用を組めます。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の可観測性ガイドも合わせて確認してください。

よくある質問（FAQ）

Application InsightsとLog Analyticsの違いは何ですか？

役割が異なります。Application Insightsはアプリのテレメトリを収集・可視化するAPM機能、Log Analyticsはそのデータを保存しKQLで分析する基盤です。workspace-basedのApplication Insightsは収集したデータをLog Analyticsワークスペースに保存するため、両者は対立ではなく「収集役」と「保存・分析役」という連携関係にあります。

Instrumentation Keyはまだ使えますか？

Instrumentation Keyベースのグローバル取り込みは2025年3月31日にサポートが終了しました。現在はConnection Stringの利用が必須です。古い手順のままだとテレメトリが取り込まれない場合があるため、Connection Stringへの移行を済ませてください。

料金はどのくらいかかりますか？

取り込んだデータ量に対する従量課金で、1GBあたり約2.30 USD（リージョンにより変動）、無料枠は5GB/月です。安定して大量取り込みがある場合はコミットメント階層で単価を下げられます。サンプリングと保持期間の調整が費用を抑える鍵で、最新単価は公式の料金ページで確認してください。

導入にコードの変更は必要ですか？

App ServiceやAzure Functionsでは、作成時に有効化を選ぶだけでコード変更なしに基本監視を始められます。詳細なカスタムイベントやトレースを収集する場合は、Azure Monitor OpenTelemetry Distroを組み込んで計装します。対応言語は.NET・Node.js・Python・Javaです。

Classicリソースを使っているのですが移行は必要ですか？

Classic Application Insightsリソースは2024年2月29日に廃止されました。Microsoftは自動移行も進めていますが、Continuous Exportなど一部機能はworkspace-basedでの代替（診断設定によるエクスポート）に切り替える必要があります。残っているClassicリソースはworkspace-basedへの移行を確認してください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る