Azure Monitorの「Application Insights OpenTelemetry observability overview」を読むときの結論は、Application Insightsの監視設計をOpenTelemetry中心に整理し直す必要があるという点です。すぐに全アプリを移行しなければならない、という単純な話ではありません。しかし、新規開発や監視方式の見直しでは、Azure Monitor OpenTelemetry Distro、接続文字列、Cloud Role Name、サンプリング、Microsoft Entra認証、AIエージェント監視を前提に設計する流れが強まっています。
特に管理者や開発者が最初に確認すべきなのは、現在のアプリが「コードベースのOpenTelemetry Distro」「自動インストルメンテーション」「Application Insights JavaScript SDK」「Azure FunctionsのOpenTelemetry設定」「旧Application Insights SDK」のどれで監視されているかです。ここを曖昧にしたまま展開すると、テレメトリの重複、Application Mapの見づらさ、ログ欠落、想定外の課金につながります。
Microsoft Learnの該当概要ページでは、Azure Monitor Application InsightsをAPM機能として位置づけ、サポートされるシナリオではOpenTelemetryでアプリをインストルメントし、収集したテレメトリをApplication Insightsで分析できると説明しています。概要ページ自体の表示上の最終更新日は2026年3月18日ですが、接続文字列やサンプリングなど関連ドキュメントには2026年5月6日更新のものがあり、本記事では2026年5月7日時点で確認できる公式情報として実務上の確認ポイントを整理します。(Microsoft Learn)
Azure Monitor Application InsightsとOpenTelemetryの関係
Application Insightsは、Azure Monitorに含まれるアプリケーションパフォーマンス監視機能です。OpenTelemetryは、トレース、メトリック、ログなどのテレメトリを標準化された形で収集するためのフレームワークです。今回のポイントは、Application Insightsが単独の独自SDKだけでなく、OpenTelemetryベースの収集・分析基盤として整理されていることです。(Microsoft Learn)
実務では、次のように考えると分かりやすくなります。
| 観点 | これまで意識しがちだったこと | 今後より重要になること |
|---|---|---|
| 監視SDK | Application Insights SDKを入れる | OpenTelemetry Distroや対応する自動収集方式を選ぶ |
| 宛先設定 | instrumentation key中心 | APPLICATIONINSIGHTS_CONNECTION_STRING中心 |
| 可視化 | 例外、要求、依存関係を個別に見る | Application Map、Live Metrics、Search、Failures、Performanceを横断して見る |
| サービス識別 | Azureリソース名や既定値に任せる | Cloud Role Name、Cloud Role Instanceを設計する |
| コスト管理 | 収集後に課金を見て調整 | サンプリングとログレベルを事前に設計する |
| セキュリティ | ikeyを秘密情報のように扱う | Microsoft Entra認証やローカル認証無効化を検討する |
重要なのは、「OpenTelemetryにすれば監視が自動的に良くなる」わけではない点です。OpenTelemetryは収集の標準化に強みがありますが、Application Insights上で見やすくするには、ロール名、接続先、サンプリング、ログ粒度を意図的に設定する必要があります。
今回の公式情報で押さえるべき変更点
今回の概要は、単なるApplication Insightsの紹介ではなく、OpenTelemetryを前提に「どのワークロードはどの収集方法を使うべきか」を整理している点が重要です。対象には、サーバー側Webアプリ、VM上のアプリ、ブラウザーJavaScript、Azure Functions、AKS、AIエージェントが含まれます。(Microsoft Learn)
サーバー側アプリではAzure Monitor OpenTelemetry Distroが基本線になる
コードベースで監視を組み込むサーバー側Webアプリでは、Azure Monitor OpenTelemetry Distroを使う流れが推奨されています。Azure Monitor OpenTelemetry Distroは、Azure Monitor向けの機能を含むOpenTelemetryディストリビューションで、トレース、メトリック、ログ、例外の自動テレメトリ収集や、カスタムテレメトリ、Live Metricsに対応します。対応言語としては.NET、Node.js、Python、Javaが示されています。(Microsoft Learn)
新規開発では、旧Application Insights SDKを前提にした設計を増やすより、最初からOpenTelemetry Distroで構成する方が将来の拡張や他ツール連携に向いています。一方で、既存アプリでは「今すぐDistroへ置き換える」より、現在のSDK、カスタムテレメトリ、ログ処理、依存関係収集を棚卸ししてから移行計画を立てるべきです。
ブラウザー telemetry はOpenTelemetryではなくJavaScript SDKを使う
誤解しやすいのが、ブラウザー側のテレメトリです。概要ページでは、ページビューやユーザー操作などのブラウザーテレメトリにはApplication Insights JavaScript SDKを使い、Application Insights JavaScript SDKはOpenTelemetryを使用しないと説明されています。(Microsoft Learn)
つまり、フロントエンドとバックエンドを同時に監視する場合、バックエンドはOpenTelemetry Distro、ブラウザーはJavaScript SDKという構成になることがあります。このとき、相関ID、CORS、プロキシ、認証、個人情報の扱いを別々に確認する必要があります。
Azure Functionsではhost.jsonと接続文字列を確認する
Azure FunctionsでOpenTelemetryを使う場合は、host.jsonでOpenTelemetryを有効にし、Application Insightsの接続文字列をアプリケーション設定に追加する流れが示されています。特に、"telemetryMode": "OpenTelemetry"とAPPLICATIONINSIGHTS_CONNECTION_STRINGの確認が重要です。また、C# in-processアプリではOpenTelemetryが現在サポートされていない点も見落としやすい注意点です。(Microsoft Learn)
{
"telemetryMode": "OpenTelemetry"
}運用中のFunctionsでこの設定を変更する場合は、設定後にテレメトリが数分以内にApplication Insightsへ表示されるか、リクエスト、例外、依存関係、ログが期待通りに出ているかを確認します。特に本番環境では、変更前後で同じKQLクエリを使ってテレメトリ量を比較すると安全です。
AKSの自動インストルメンテーションはプレビューとして扱う
AKS上のアプリについては、基本的には他のサーバー側アプリと同じく、Application Insightsリソースを作成し、接続文字列を取得し、OpenTelemetry Distroを追加して構成します。一方で、AKSの自動インストルメンテーションはパブリックプレビューとして示されています。(Microsoft Learn)
プレビュー機能は検証環境や限定的なワークロードで試すには有用ですが、本番標準に採用する場合は、サポート条件、変更リスク、ロールバック手順を確認してから展開する必要があります。特に、既にサイドカー、Collector、独自エージェントを使っているAKS環境では、二重収集に注意してください。
AIエージェントの可観測性がApplication Insightsの対象として明確になる
概要ページでは、AIエージェント向けの入口も整理されています。Azure AI Foundry、Copilot Studio、Microsoft Agent Framework、サードパーティ製エージェントなど、ホスティング形態に応じてAzure Monitorへテレメトリを送る方法が案内されています。さらに、Agent details viewでエージェントを確認できること、エージェントごとに区別しやすい名前を付けることも示されています。(Microsoft Learn)
AIエージェント監視で特に注意すべきなのは、プロンプトや会話ログの扱いです。公式情報では、EnableSensitiveDataのような設定で完全なプロンプト情報を収集する場合、Search viewやTransaction Details viewでプロンプト、アシスタントメッセージ、システムプロンプト、ツール利用状況を確認できると説明されています。これは障害解析には強力ですが、機密情報や個人情報が監視データに入るリスクもあります。(Microsoft Learn)
対象者別の影響範囲
今回の整理で影響を受けるのは、Azure管理者だけではありません。アプリ開発者、SRE、セキュリティ担当、AIエージェント開発チームまで関係します。
| 対象者 | 確認すべきこと | 放置した場合のリスク |
|---|---|---|
| Azure管理者 | Application Insightsリソース、接続文字列、Entra認証、ファイアウォール | テレメトリ未送信、不正な送信、リージョンや認証設計の不整合 |
| 開発者 | SDKの種類、OpenTelemetry Distro、カスタムテレメトリ、ログ出力 | 重要な例外や依存関係が見えない、二重送信が起きる |
| SRE/運用担当 | Application Map、Live Metrics、Failures、Performance、Alerts | 障害時に原因箇所を特定できない |
| セキュリティ担当 | Microsoft Entra認証、ローカル認証無効化、プロンプト収集 | 監視データの悪用、機密情報の混入 |
| AI開発チーム | Agent details、エージェント名、プロンプト保存範囲 | エージェント別の品質劣化や失敗原因を追跡できない |
Application Insightsでは、Application dashboard、Application map、Live metrics、Search view、Availability、Failures、Performance、Agents detailsなどの調査機能に加え、Alerts、Metrics、Diagnostic settings、Logs、Workbooks、Grafanaダッシュボード、SDK Statsなどの監視機能が整理されています。単にデータを送るだけでなく、どの画面で何を確認するかまで運用設計に含めることが重要です。(Microsoft Learn)
管理者が確認すべき設定
接続文字列は必ず確認する
OpenTelemetryベースの構成では、接続文字列がテレメトリの送信先を決める中心的な設定になります。Application Insightsの接続文字列は、複数のキーと値をセミコロンで区切った形式で、テレメトリを送るApplication Insightsリソースを指定します。公式ドキュメントでは、接続文字列に含まれるinstrumentation keyはセキュリティトークンや秘密鍵ではないと説明されていますが、リソースの誤用を防ぐにはMicrosoft Entra IDによる認証済み取り込みを検討すべきです。(Microsoft Learn)
最低限、以下を確認してください。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
APPLICATIONINSIGHTS_CONNECTION_STRING | App Service設定、Functions設定、Kubernetes Secret、VM環境変数 | 対象環境のApplication Insightsリソースを指しているか |
IngestionEndpoint | 接続文字列 | リージョン、ソブリンクラウド、プロキシ要件に合っているか |
LiveEndpoint | 接続文字列または既定構成 | Live Metricsを使う場合に通信できるか |
| 接続文字列の設定優先順位 | コード、環境変数、構成ファイル | 本番で意図しない値に上書きされていないか |
.NETでは、コード、環境変数、構成ファイルの順に接続文字列の優先順位が示されています。Javaでもシステムプロパティ、環境変数、構成ファイルの順に優先順位があります。環境変数で設定したつもりでも、コード側で別の接続文字列を指定していると、送信先が変わる可能性があります。(Microsoft Learn)
Cloud Role NameとCloud Role Instanceを設計する
Application Mapを実務で使いやすくするには、Cloud Role NameとCloud Role Instanceの設計が欠かせません。Azure Monitor OpenTelemetry Distroは既定値を自動検出しますが、チームにとって意味のある名前へ上書きすることが推奨されます。Cloud Role NameはApplication Mapのノード名として表示され、service.namespaceとservice.name、Cloud Role Instanceはservice.instance.idに基づきます。(Microsoft Learn)
例えば、次のような命名にすると、障害時に判断しやすくなります。
| アプリ構成 | Cloud Role Nameの例 | Cloud Role Instanceの例 |
|---|---|---|
| ECサイトの商品API | commerce.product-api | Pod名、VM名、インスタンスID |
| 認証サービス | identity.auth-service | App Serviceインスタンス名 |
| バッチ処理 | batch.invoice-worker | ジョブIDまたはホスト名 |
| AIエージェント | agent.customer-support | エージェント名またはデプロイID |
避けたいのは、すべてのサービスが同じApplication Insightsリソース名で表示される状態です。これではApplication Map上でノードが判別しづらく、障害時に「どのサービスが遅いのか」「どの依存関係で失敗しているのか」を追いにくくなります。
Microsoft Entra認証を検討する
Application InsightsはMicrosoft Entra認証をサポートしており、Microsoft Entra IDを使うことで、認証済みテレメトリのみをApplication Insightsリソースに取り込む構成を選べます。公式ドキュメントでは、ローカル認証をオプトアウトし、マネージドIDやMicrosoft Entra IDで認証されたテレメトリのみを取り込む選択肢が説明されています。(Microsoft Learn)
特に次の環境では優先度が高くなります。
| 環境 | Entra認証を検討すべき理由 |
|---|---|
| 本番API | 監視データがアラートやオートスケール判断に使われるため |
| 金融・医療・社内基幹系 | 不正または誤ったテレメトリ取り込みを防ぎたい |
| 複数チームで共有するAzure環境 | 接続文字列の使い回しや誤送信を抑えたい |
| AIエージェント監視 | プロンプトや会話情報を含む可能性があるため |
ただし、JavaScript SDKなど一部のSDKや機能はMicrosoft Entra認証による取り込みに未対応とされています。ブラウザーテレメトリでローカル認証を無効化する場合は、APIMなどを経由する構成も検討が必要です。(Microsoft Learn)
ファイアウォールとエンドポイントを確認する
概要ページでは、データが取り込みエンドポイントへ到達するにはファイアウォール設定の調整が必要とされています。閉域網、プロキシ、Private Link、送信制限のあるKubernetes環境では、Application Insightsリソースを作成してSDKを入れるだけではテレメトリが届かないことがあります。(Microsoft Learn)
展開前に、少なくとも次の通信を確認してください。
| 通信 | 確認内容 |
|---|---|
| テレメトリ取り込み | IngestionEndpointへ送信できるか |
| Live Metrics | Live Metrics用エンドポイントへ送信できるか |
| プロキシ | アプリ、SDK、エージェントがプロキシ設定を認識しているか |
| コンテナ環境 | Podから外部エンドポイントへ出られるか |
| 監視用内部メトリック | Statsbeatなどの内部メトリック送信ポリシーに合うか |
開発者が確認すべき移行ポイント
旧Application Insights SDKからの移行は「削除して入れ替え」だけではない
旧Application Insights SDKを使っているアプリでは、OpenTelemetryへの移行時にコードや構成の差分を確認する必要があります。公式の移行ドキュメントでは、.NET SDK 3.xは多くのTelemetryClientやTelemetryConfiguration APIを維持しつつ、Azure Monitor OpenTelemetry Exporterを使ってApplication Insightsへ送信すると説明されています。一方で、新規アプリやすでにAzure Monitor OpenTelemetry Distroを使っている場合はDistroを使い、Application Insights .NET SDK 3.xとAzure Monitor OpenTelemetry Distroを同じアプリで併用しないよう案内されています。(Microsoft Learn)
移行時に確認したい主なポイントは次のとおりです。
| 確認項目 | 実務上の見方 |
|---|---|
| SDKのバージョン | 2.x、3.x、OpenTelemetry Distroが混在していないか |
| カスタムイベント | 旧TrackEventが期待通り残るか、OpenTelemetry APIへ移すか |
| カスタムメトリック | 名前、namespace、集計方法が変わらないか |
| TelemetryInitializer / TelemetryProcessor | OpenTelemetryのResource属性、SpanProcessor、LogRecordProcessorへ置き換えられるか |
| サンプリング | 旧Adaptive Samplingと新しい設定の違いを確認する |
| テスト | ITelemetryChannelのモックではなく、OpenTelemetry向けの検証方法に変える |
移行で失敗しやすいのは、監視コードだけを見て、ログ設定や依存関係収集を見落とすケースです。実際には、アプリケーションログ、HTTP依存関係、SQL、キュー、例外、カスタムメトリックまで含めて比較する必要があります。
Node.js、Python、Javaではランタイム要件と制限を確認する
OpenTelemetry Distroは.NET、Node.js、Python、Javaで利用できますが、各言語で前提条件や制限が異なります。例えば、Node.jsではOpenTelemetryやAzure SDK for JavaScriptのサポート対象ランタイムを確認する必要があります。PythonではOpenCensusからOpenTelemetryへの移行時に、OpenCensus関連ライブラリを削除し、OpenTelemetry Python APIやSDKの違いを理解する必要があります。(Microsoft Learn)
特に長期運用中のアプリでは、監視移行がランタイム更新を伴うことがあります。古いNode.js、古いPython、古いJava Agentを使っている場合、監視だけの小変更では済まない可能性があるため、アプリ基盤の更新計画と合わせて進めるのが現実的です。
カスタムテレメトリはOpenTelemetry APIに寄せる
カスタムテレメトリを追加・変更する場合、公式ドキュメントではOpenTelemetry APIや言語固有のログ・メトリックライブラリを使う方法が案内されています。コミュニティのOpenTelemetry instrumentation libraryを追加して自動収集を広げることもできますが、Microsoftはコミュニティライブラリの品質や動作を保証しないと注意しています。(Microsoft Learn)
実務では、次の基準で判断すると安全です。
| やりたいこと | 推奨される考え方 |
|---|---|
| ビジネスイベントを記録したい | カスタムイベントまたはログとして明確な名前で送る |
| 処理時間の分布を見たい | Histogramなどのメトリックを使う |
| 外部API呼び出しを追いたい | 依存関係トレースとして収集できるか確認する |
| 例外を詳しく追いたい | 例外ログとトレースの相関を確認する |
| 未対応ライブラリを監視したい | コミュニティinstrumentationの安定性を検証環境で確認する |
「とりあえず全部ログに出す」は避けるべきです。ログ量が増えるほどコストが上がり、重要なシグナルが埋もれます。監視データは、障害対応、性能改善、利用状況把握、SLO管理のどれに使うのかを先に決めると設計しやすくなります。
展開時に注意すべきポイント
二重インストルメンテーションを避ける
App Serviceの自動監視、旧Application Insights SDK、OpenTelemetry Distro、Java Agent、OpenTelemetry Collectorなどを同時に有効にすると、同じリクエストや依存関係が重複して送信されることがあります。FAQでも、コードベースの現在のセットアップではAzure Monitor OpenTelemetryを使い、コード変更なしのApp Service監視を使う場合は別のパスとして扱い、移行検証時以外は同じアプリで重複させない考え方が示されています。(Microsoft Learn)
展開前に、アプリごとに「監視の入口」を1つに決めてください。
| アプリの状態 | 推奨される確認 |
|---|---|
| 新規アプリ | Azure Monitor OpenTelemetry Distroを基本にする |
| 既存App Service | ポータルの自動監視とコード内SDKが重複していないか確認 |
| Javaアプリ | Java Agentと手動instrumentationの役割を分ける |
| AKS | Collector、サイドカー、Distro、自動計装の重複を確認 |
| Functions | host.json、アプリ設定、言語固有ワーカー設定を確認 |
サンプリングはコスト対策だけでなく診断品質の設定
Application InsightsのOpenTelemetry Distroでは、サンプリングは既定で有効ではないため、テレメトリ量を管理したい場合は明示的に設定する必要があります。公式ドキュメントでは、固定率サンプリングとレート制限サンプリングが説明され、Live Metricsとの互換性やトレースの分断を避けるためにApplication Insightsのカスタムサンプラーが重要だとされています。(Microsoft Learn)
サンプリング設計では、次の失敗がよく起きます。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 本番でサンプリングなし | 取り込み量とコストが急増する | 事前にトレース量を見積もる |
| 取り込みサンプリングだけに頼る | トレースが分断されやすい | 可能ならアプリ側で制御する |
| ログを大量に出す | 重要な例外が埋もれ、費用も増える | ERROR中心、WARNは行動可能なものに絞る |
| メトリックまでサンプリングされると誤解する | アラート設計を誤る | メトリックはサンプリングされない前提で活用する |
| 日次上限を安全策として過信する | 上限到達後に監視ギャップが発生する | 日次上限は最後の防波堤として使う |
日次上限は予期しないコストを防ぐ手段ですが、上限に到達するとリセットまでテレメトリに空白が生まれます。コスト対策の主役は、サンプリング、ログレベル、不要なカスタムテレメトリの削減です。(Microsoft Learn)
オフラインストレージと再送の挙動を理解する
Azure Monitor OpenTelemetryベースの機能では、Application Insightsとの接続が切れた場合にテレメトリをキャッシュし、最大48時間再送を試みる仕組みが説明されています。ただし、高負荷環境では許容時間や最大ファイルサイズを超えるとテレメトリがドロップされることがあり、必要に応じて新しいイベントを優先します。(Microsoft Learn)
これは、ネットワーク障害に強くなる一方で、ローカルディスク容量やコンテナの一時領域にも影響するという意味です。特にKubernetesや短命なコンテナでは、オフラインストレージの保存先、永続性、容量制限を確認してください。
移行・展開前の実務チェックリスト
本番展開前には、次の順番で確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 合格基準 |
|---|---|---|
| 監視方式の棚卸し | 旧SDK、自動監視、Distro、Agent、Collectorの有無 | 1アプリ1方針になっている |
| 接続先確認 | APPLICATIONINSIGHTS_CONNECTION_STRING | 正しいリソースとエンドポイントを指している |
| ロール名設計 | Cloud Role Name / Instance | Application Mapでサービスを識別できる |
| テレメトリ比較 | 要求、依存関係、例外、ログ、メトリック | 移行前後で欠落や重複がない |
| サンプリング | 固定率またはレート制限 | コストと診断品質のバランスが取れている |
| セキュリティ | Entra認証、ローカル認証、機密データ | 本番ポリシーに合っている |
| ネットワーク | ファイアウォール、プロキシ、Private Link | 取り込みエンドポイントへ到達できる |
| AIエージェント | エージェント名、プロンプト収集範囲 | 機密情報を不要に収集していない |
| 運用確認 | Live Metrics、Failures、Performance、Logs | 障害時に見る画面とKQLが決まっている |
まず何から対応すべきか
最初にやるべきことは、全アプリの監視方式を一覧化することです。Application Insightsリソース単位ではなく、アプリ単位で「どのSDKまたはDistroで、どの接続文字列を使い、どのCloud Role Nameで送っているか」を確認してください。
次に、新規アプリや大きな改修を予定しているアプリから、Azure Monitor OpenTelemetry Distroを前提に設計します。既存アプリは、旧SDKを使っているからといって慌てて差し替えるのではなく、カスタムテレメトリ、ログ、サンプリング、認証、Application Mapの見え方を比較しながら段階的に移行するのが安全です。
最後に、監視データの品質を運用指標として扱いましょう。OpenTelemetryへの対応は、単なるSDK更新ではありません。障害時に原因を追えるか、コストを制御できるか、AIエージェントの動作を安全に観測できるかを左右する設計変更です。Azure Monitor Application Insightsを使っている環境では、今回の公式情報をきっかけに、監視方式、接続文字列、ロール名、サンプリング、認証をまとめて見直すことが次の一手になります。
コメント