アプリケーションパフォーマンス監視（APM）とは何ですか？

アプリケーションパフォーマンスモニタリング（APM）は、実行中のソフトウェアからテレメトリデータ（メトリクス、トレース、ログ、イベント）を収集、相関、分析してパフォーマンスの劣化を検出し、根本原因を特定し、サービスレベル目標を検証する手法です。 APMツールは言語特有のエージェント、SDK、またはOpenTelemetryのようなオープンスタンダードを介してアプリケーションを計測し、そのデータをバックエンドに送信して、ダッシュボード、アラート、トレースレベルの診断で可視化します。

APM、アプリケーションパフォーマンス管理、アプリケーションポートフォリオ管理は同じではない

APMの略語は3つの異なる分野で使われます。これらを初めに区別することでベンダーのドキュメントを読む際の混乱を防ぎます。

アプリケーションパフォーマンスモニタリングは計測レイヤーであり、実行中のアプリケーションからテレメトリを収集し、メトリクス、トレース、ログとして表面化します。これは「このアプリケーションは現在健康か？問題があればどこか？」に答えます。

アプリケーションパフォーマンス管理はより広義で、SLOの定義、パフォーマンス予算の作成、負荷テストの実施、コードの計測、モニタリングスタックの運用、及びそれに基づく対応を含みます。モニタリングは管理の一要素です。

アプリケーションポートフォリオ管理はビジネスアーキテクチャ層に位置し、組織が管理するアプリケーション全体の在庫を追跡し、投資、モダナイズ、統合、廃止を決定します。モニタリングデータを入力に使いますが、性能管理そのものではありません。

本記事で「APM」と単独で言う場合はアプリケーションパフォーマンスモニタリングを指します。

アプリケーションパフォーマンスモニタリングとオブザーバビリティの違い

APMはオブザーバビリティのサブセットです。APMはアプリケーションレイヤーのパフォーマンス（応答時間、スループット、エラー率、トランザクションフロー）に焦点を当てます。オブザーバビリティは、システムが吐き出すテレメトリから任意の内部状態に関する質問を行えるより広範なプラクティスであり、インフラ、ネットワーク、ビジネスイベントデータも含みます。

実用的には：

• APMツールは14:02のデプロイ後に/checkoutエンドポイントのp95レイテンシが180msから1.4秒に上昇したことを教えてくれます。
• オブザーバビリティスタックは、同じ時間帯にあったKubernetesノードのメモリプレッシャーイベント、Postgresのロック待ち増加、機能フラグの展開とそれを関連付けられます。

Datadog APM、New Relic、Dynatrace、Elastic Observability、Grafana Cloud、Splunk Observability Cloudなどの最新APMプラットフォームは、オブザーバビリティの範囲を広く包含しているため境界が曖昧になっています。最もわかりやすい考え方は、オブザーバビリティがゴールであり、APMはそこへ到達するために必要なアプリケーションに特化したデータのスライスです。

アプリケーションパフォーマンスモニタリングの仕組み

APMは計測（Instrumentation）、収集（Collection）、送信（Transmission）、相関（Correlation）の4段階で動作します。

1. 計測（Instrumentation）

計測はアプリケーションコードに測定ポイントを加えてテレメトリを収集可能にします。主に3種類のアプローチがあります：

• 自動計測エージェント。言語固有のランタイムエージェント（Javaのバイトコード計測、.NETプロファイラ、PythonやNode.jsのOpenTelemetry自動計測ライブラリ）がHTTPハンドラ、データベースドライバー、メッセージキューなどのフレームワークのエントリーポイントにログコード変更なしでフックします。
• SDKによる手動計測。開発者がAPMやOpenTelemetry SDKを直接呼び出してスパンの開始・終了、属性の添付、カスタムメトリクスの送信を行います。エージェントが認識しないビジネス固有トランザクション用に必要です。
• eBPFおよびエージェントレス収集。カーネルレベルのプローブがシステムコール、ネットワーク、プロセスデータをアプリケーション修正なしでキャプチャします。エージェントインストールが制限される環境（コンプライアンス制約のあるワークロードやサードパーティサービス）で有用です。

OpenTelemetry（OTel）はこれら3アプローチすべてにまたがる事実上のオープンスタンダードです。ワイヤープロトコル（OTLP）、スパンやメトリクスの命名に関するセマンティック規約、Java、Go、Python、Node.js、.NET、Ruby、PHP等の言語SDKを定義しています。ErlangやElixirは公式のopentelemetry-erlangライブラリでカバーされます。Rustはトレースが安定、ログとメトリクスは進行中です。Swiftはコミュニティが保守するSDKが利用可能です。

2. 収集（Collection）

計測されたアプリケーションは主に以下の3種類の信号を発します：

• メトリクス：ある時点の数値計測（リクエスト数、レイテンシヒストグラム、CPU使用率）。
• トレース：サービス間を渡る単一リクエストの経路を表す順序付けられたスパンサンプル。
• ログ：タイムスタンプ付きテキスト記録で、理想的にはJSON構造化され、トレースIDやスパンIDで相関可能。

新しい信号タイプとして連続プロファイル（CPU、メモリ、ロックプロファイルを本番環境でサンプリング）や、ユーザーのブラウザやデバイスで動作するJavaScriptやモバイルSDKによるリアルユーザーモニタリング（RUM）イベントがあります。OpenTelemetryのProfiles信号は2024年にOTEPとして採用され、2025～2026年時点でまだ成熟過程にありバックエンド対応は部分的です。

3. 送信（Transmission）

テレメトリは次の2つのいずれかの経路でアプリケーションからバックエンドへ流れます：

• エージェントやSDKからAPMベンダーの受信エンドポイントに直接エクスポート（OTLP、HTTP、独自プロトコルで）。
• コレクター経由（OpenTelemetry Collectorや、Datadogエージェント、SplunkのOpenTelemetry Collector配布版などベンダー特有のもの）がデータをバッチ処理、フィルタリング、サンプリング、ルーティングします。Fluent BitやVectorのようなログ指向のフォワーダーはトレースデータのOTelコレクターと並行してログやメトリクスを処理できます。コレクターは計測とバックエンドの結合を解消するため、コードの再計測なしにベンダー変更が可能になります。

4. 相関（Correlation）

バックエンドはトレースID、スパンID、サービス名、ホスト、コンテナID、ユーザーIDといった識別子で信号を結合し、どの信号から調査を始めても他にピボットしていけるようにします。典型的なワークフローは、エラー率増加のアラート発生→影響サービスのトレース参照→代表的な失敗トレースの詳細調査→遅いスパンからログへジャンプ→問題のデータベースクエリの特定→データベースホストのメトリクス確認、という流れです。このピボットパスこそがAPMプラットフォームを単なるポイントツールの集合から差別化します。

APMスタックの主要コンポーネント

完全なAPM導入には以下が含まれます：

Dotcom-Monitorで合成モニタリングをカバーする方法。 Dotcom-Monitorは4つの合成モニタリング製品を持ち、共通のアラートおよびレポートワークフローを共有します。40以上のブラウザ・デバイス組み合わせでシングルページロード時間を取得するBrowserViewを使用。マルチステップトランザクション（ログイン、検索、チェックアウト）を計測するUserViewを使用。REST、SOAP、GraphQL API監視にはWebViewを使用。TCP、DNS、SMTP、FTP、ICMPなどネットワークプロトコルチェックにはServerViewを使用。ファイアウォール内の内部アプリケーションにはネットワーク内のサーバにPrivate Agentをインストールします。これはプラットフォームへのアウトバウンド接続を開始する単一バイナリで、インバウンドのファイアウォールルールは不要、内部エンドポイントは非公開のままです。

重要なAPMメトリクス

多くのチームが計測・アラート設定する主要メトリクスです。定義は適用可能な場合OpenTelemetryのセマンティック規約に沿っています。

コード計測なしでこれらのメトリクスを取得する方法。 表の一部はエージェントやSDKなしでアプリ外部から計測可能です。Dotcom-Monitorの合成チェックはp50、p95、p99の分布付き応答時間、HTTPステータス別のエラー率、TTFB、DNS解決時間、TLSハンドシェイク時間、リクエストごとの完全なウォーターフォールタイミングを返します。エンタープライズプランではデータを最大3年保持し、年次SLIベースライン計算のために外部時系列DBへ輸出する必要がありません。

GoogleのSRE本では4つのゴールデンシグナルをレイテンシ、トラフィック、エラー、飽和度と定義。REDメソッド（レート、エラー、期間）、USEメソッド（利用率、飽和度、エラー）は一般的で、それらを扱いやすいダッシュボードにまとめます。

APMのメリット

技術的メリット（エンジニアリング）

• 根本原因分析の高速化。分散トレースは複数サービス調査を数時間から数分に短縮し、遅延やエラーの発生個所を特定します。
• 本番安全なデバッグ。連続プロファイラーと構造化ログでデバッガ非接続での本番障害診断が可能です。
• 劣化検知。デプロイ単位のベースラインでパフォーマンス劣化を伝播前に警告。
• 容量計画材料。飽和度とスループットメトリクスは現実的なオートスケール閾値とリソース適正化を導きます。

運用メリット（DevOps、SRE、NOC）

• SLO施行。APMデータはエラーバジェット計算とリスキーなデプロイのゲートに使われます。
• アラート疲労の軽減。ゴールデンシグナルに基づく症状ベースのアラートがホスト単位の騒音閾値アラートを置き換えます。
• チーム横断の共通参照。トレースビューの共有で「ネットワークかアプリか？」の問答を終わらせます。
• 記録されたインシデントタイムライン。トレースとログ保持で事後解析証拠を再現不要で提供。

ビジネスメリット

• ダウンタイムとレイテンシによる収益損失の削減。コンバージョン率、カート完了率、セッション時間はp95レイテンシに依存します。
• クラウド支出の削減。リソース適正化と非効率クエリの特定で無駄を抑制。
• 監査およびコンプライアンス証拠。SLAレポートとインシデントタイムラインが契約や規制対応を支援。

APMの利用者と求めるもの

APMとセキュリティ：検知に特化し防御はしない

APMはセキュリティツールではありませんが、そのテレメトリは有用なセキュリティシグナルになります。APMで表面化可能なパターンは：

• 特定エンドポイントへの突然のトラフィックスパイク（クレデンシャル詰め込み、不正スクレイピング）。
• 認証や決済エンドポイントの異常なエラーパターン。
• 侵害されたサービスからの予期せぬ宛先へのアウトバウンドコール。
• デプロイ後にトレースデータに現れる新しい依存関係。

最新のAPMはSIEMやSOARプラットフォーム（Splunk Enterprise Security、Microsoft Sentinel、Elastic Security、Datadog Cloud SIEM）と連携して、注釈付きログやトレースを転送します。一部のプラットフォームはAPMエージェントに乗るIASTやランタイムアプリケーション自己防御（RASP）アドオン（Contrast Security、Datadog Application and API Protection、New RelicのVulnerability Management内のIAST機能）も提供しています。

APMは検知レイヤーであり、WAF、脆弱性スキャナー、EDRを補完するもので代替するものではありません。

クラウドネイティブおよびマイクロサービスワークロード向けAPM

クラウドネイティブアーキテクチャはAPMに4つの変化をもたらします：

データ量。モノリシックは1セットのメトリクスを出しますが、50サービスのマイクロサービス展開はそれを複製数と各トレースのすべてのスパンで掛けた量を送ります。適応型サンプリング（ヘッドベース、テールベース、確率的）が不可欠です。OpenTelemetry Collectorのテールサンプリングプロセッサーが標準解です。

短命性。コンテナやサーバーレス関数は秒から数分の寿命です。従来のホストベース監視はポッドの再起動でコンテキストを失います。サービスレベルの識別子（サービス名、名前空間、デプロイ）がホストベースIDに代わり主要な集約キーになります。

サービス間の複雑性。レイテンシ増加の根本原因は人間の記憶に頼れない依存グラフの歩行が必要です。トレースデータから生成するサービスマップ（Jaegerの依存ビュ、Grafana Tempoのサービスグラフ、Datadogのサービスマップ）が実用的な解決策です。

異種ランタイム混在。1つのリクエストはNode.js BFF、Goサービス、Javaレガシーバックエンド、サーバーレス関数を横断します。OpenTelemetryのクロスランゲージトレースコンテキスト伝播（W3C Trace Contextヘッダー）がこのシングルトレースを可能にします。

データセンター外部から各リージョン検証。分散システムはリージョン単位で障害が起きがちです。CDNノードの誤ルーティング、DNS伝播遅れ、リージョン証明書更新失敗はデータセンター内は正常でもサンパウロやシンガポールからは到達不能になることがあります。これを検知するには、重視する各リージョンから別のターゲットリストに同じ合成チェックを実行します。Dotcom-Monitorではモニター設定のターゲットリストごとに監視ロケーションを割り当て、ダッシュボードで自動的に地域別のレイテンシ・可用性差異を分離します。これによりAWSリージョン障害、Cloudflare障害、BGPルートフラップを内部ツールより先に検出可能です。

Kubernetes固有の課題には独自の対応が必要です。Pod再起動数を先行指標、kube-state-metricsでクラスター信号、Horizontal Pod Autoscalerの応答性、ノードレベル圧力信号をクラウドネイティブAPMダッシュボードに含めます。

AIおよびLLMワークロード向けAPM

LLM支援機能は従来のAPMメトリクスで捉えられない新しい障害モードがあります：

• 最初のトークンまでの時間（TTFT）とトークン間レイテンシはストリーミング応答で総リクエスト時間より重要。
• トークンコスト/リクエストはビジネス指標であり容量指標でもあります。
• プロンプトと出力内容（サンプリング・編集済み）は幻覚、プロンプトインジェクション、品質低下の診断に必須。
• モデルドリフト（出力分布の時間変化の計測）はレイテンシとともに評価が必要。
• エージェントワークフローのツール呼び出し・検索トレース：ベクターストアクエリ、関数呼び出し、下流APIリクエストのスパン。

OpenTelemetryのGenAIセマンティック規約（2024年導入、2026年時点で開発中）はLLM呼び出しの標準スパン属性（gen_ai.provider.name、gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.usage.output_tokens）を定義します。LLM特化オブザーバビリティツール（Langfuse、Arize Phoenix、Helicone、LangSmith）は、GenAI対応を追加した汎用APM（Datadog LLM Observability、New Relic AI Monitoring、Dynatrace AI Observability）と共存します。

Dotcom-MonitorでLLMエンドポイントを監視する方法。LLMエンドポイント（例：POST /v1/chat/completions）を指すWebViewモニターを作成します。リクエストボディに固定テストプロンプトを、ヘッダーにAPIキーまたはベアラートークンを配置。3つのJSONPathアサーションを設定：choices[0].message.contentが空でないこと、usage.total_tokensが妥当な範囲内であること（暴走トークンバグ検出）、応答時間がTTFT予算以下であること。この構成はクオータ枯渇、モデル非存在応答、プロバイダ障害、地域レート制限を検知します。Langfuse、Helicone、LangSmithなどの内部LLMオブザーバビリティツールはアプリが受け取るもののみ計測するためこれら障害を検知できません。

アプリケーションパフォーマンスモニタリングのベストプラクティス

• 標準はOpenTelemetryで計測。ロックインを避ける。ベンダー固有のエージェントにOTelにない機能があれば、OTelに重ねる形にして置き換えない。
• ダッシュボードより前にSLOを定義。ユーザー目線で「健康」とは何かを定義し、それを測るアラートやダッシュボードを構築する。
• 症状でアラート、SLO燃焼時にページング。ホスト単位の閾値アラートは騒音の原因。SLOのエラーバジェットが持続不能に燃えている時に火災報知器のようにアラートが発生する方式がオンコールの正気を保つ。
• 合成とリアルユーザーモニタリングを組み合わせる。合成チェックは制御された場所から定期的に障害を検知。RUMは実際のユーザー体験とネットワーク、デバイスの変動を計測。どちらかが他方の代わりにはならない。
• スパンとメトリクスの命名を標準化。OpenTelemetryのセマンティック規約を使い、チームごとの命名不統一を避ける。
• トレースIDでログ・キュー・DBクエリをエンドツーエンドで相関。ログ、キューメッセージ、DBクエリにトレースコンテキストを注入（例：SQLコメントをsqlcommenterで）。全ログ行にトレースIDを付与するのは最高のオブザーバビリティ投資。
• 知的サンプリングを行う。高負荷サービスで1～10%のヘッドサンプリング、エラーや遅いトレース保持にはテールサンプリング。エラートレースは100%保持する。
• コレクターを本番インフラとして扱う。OpenTelemetry Collectorを冗長化、監視、容量余裕をもって運用する。
• 四半期ごとにレビューとチューニング。メトリクスのカードリナリティ、ログ量、トレース保持は積み上がる。不要になったものは積極的に削除してリソースを節約する時間を確保。
• ゲームデイ演習を実施。定期的に障害注入（Chaos Mesh、Gremlin、AWS Fault Injection Serviceなど）を行いAPMスタックが検出できることを検証。未テストのオブザーバビリティは未検証。

APM用語集

エージェント。アプリケーションと並行してインストールされるソフトウェアでランタイム呼び出しを自動計測しテレメトリを送出。

Apdex。Application Performance Index。レイテンシ閾値に基づく0～1の満足度スコア。

カードリナリティ。メトリクスに付くラベルや属性の固有組み合わせ数。高いと保存とクエリが高コスト。

分散トレース。単一リクエストを複数サービスにまたがって追跡する手法。トレースIDを伝搬。

エラーバジェット。SLOが一定期間容認する不安定度の量。インシデントで消費される。

エグザンプラー。メトリクス異常点に添付される特定トレースID。メトリクス異常から代表的トレースにジャンプ可能。

ゴールデンシグナル。レイテンシ、トラフィック、エラー、飽和度。全サービスが公開すべき4つのメトリクス。

計測（Instrumentation）。実行中アプリケーションからテレメトリを生成するコードまたは設定。

OpenTelemetry（OTel）。CNCFのオブザーバビリティフレームワーク。API、SDK、OTLPプロトコル、セマンティック規約を定義。

OTLP。OpenTelemetry Protocol。トレース、メトリクス、ログの送信用ワイヤーフォーマット。

REDメソッド。レート、エラー、期間。サービスレベルメトリクスのフレームワーク。

リアルユーザーモニタリング（RUM）。ユーザーのブラウザやデバイスから取得されるパフォーマンスデータ。

SLI / SLO / SLA。サービスレベル指標（SLI）、目標（SLO）、契約（SLA）。

スパン。トレース内の単一操作。開始時間、期間、属性を持つ。

合成モニタリング。制御された場所からユーザー行動を模倣するスクリプト化された定期チェック。

テールサンプリング。完成後にトレースのエラー状態や期間に基づきサンプリング。

テレメトリ。システムが自己について発するデータ。APMではメトリクス、トレース、ログ、プロファイル、イベントを指す。

トレースコンテキスト。サービス境界を越えてスパンを単一トレースに紐付けるメタデータ。W3C Trace Contextとして標準化。

USEメソッド。利用率、飽和度、エラー。リソースレベルのメトリクスフレームワーク。

Frequently Asked Questions