Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

ロジックモニターブログ

可観測性とはツールのことではなく、真実のことなのだ。

APMツールはインフラストラクチャのエッジで止まってしまいます。インターネットパフォーマンスモニタリングは、制御できないネットワーク全体におけるAPI遅延の真の原因を明らかにします。

6〜9分
デントン千倉

ニュースレター

最新情報のメール配信を登録

最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

シェア

クイックダウンロード:

APIの遅延が企業の境界を越えると、従来のAPMツールでは可視性が失われ、根本原因を特定する唯一の方法はインターネットパフォーマンスモニタリング（IPM）になります。

  • 従来のAPM、RUM、およびログツールは、自社のインフラストラクチャ内部のみを監視するため、システムと顧客間のインターネット経路に重大な盲点が生じます。

  • 実際の事例では、複数のISPと都市を対象とした合成APIテストを実施した結果、わずか3時間と15回のテスト実行で、バックエンドアプリケーションの依存関係が根本原因であることが特定された。

  • チームが最適化の取り組みをスタックの適切なレイヤーに集中させるためのデータを入手できたことで、バックエンドのレイテンシはほぼ半減した。

  • LMインターネットパフォーマンスモニタリングを活用して、インターネットスタックのあらゆるレイヤーにおいて、ユーザーからオリジンまでのパス全体を可視化しましょう。


企業顧客からレイテンシの報告があった。ダッシュボードには問題なしと表示されている。顧客はあなたのせいだと言い、あなたは顧客のせいだと言い張る。どちらが正しいのか、誰も証明できない。

ほとんどのモニタリング活動はここで壁にぶつかります。議論はダッシュボードやツールに終始し、本当に重要なこと、つまり根本原因を迅速に突き止めるという点から逸れてしまうのです。

可観測性があれば、企業の評判や収益が危機に瀕している時に、問題を迅速に特定できるはずです。しかし、ほとんどのツールは自社のインフラストラクチャ内部で何が起こっているかしか把握できません。問題が自社システムと顧客システムの間のどこかに存在する場合、手探りで進むしかありません。

2つの企業が同じ問題を異なる視点で見た場合、何が起こるのでしょうか？

大手金融サービスプロバイダー（仮にA社としましょう）はプレッシャーにさらされていました。主要な企業顧客であるB社は、顧客向けアプリに組み込まれたAPIにアクセスする際に3～6秒の遅延が発生すると報告しました。

  • B社：「御社のAPIは動作が遅いです。顧客体験に悪影響が出ています。」
  • A社（ データドッグ APM：「我々の側ではすべて順調です。」

膠着状態であり、観測可能性の失敗の典型的な事例である。

なぜDatadogはこの問題を発見できなかったのか？

Datadogは優れたアプリケーションパフォーマンス監視（APM）ツールですが、自社のインフラストラクチャ以外を監視するようには設計されていません。

A社は堅牢なAPM（アプリケーションパフォーマンス管理）とログ記録システムを備えていたにもかかわらず、自社の外部の状況を把握することはできなかった。B社のインフラストラクチャにエージェントをインストールすることも、他社のコードベースにリアルユーザーモニタリング（RUM）スクリプトを組み込むこともできなかったのだ。

各ツールでできること（そしてできないこと）は以下のとおりです。

  • APM（Datadogなど）アプリ内では素晴らしいですが、トラフィックが発生すると問題が発生します。
  • ラムフロントエンドに関する洞察を得るのに非常に役立ちますが、アプリを所有している場合に限ります。
  • ログ既に発生した事象には役立ちますが、パケットが転送中に滞留した場所には役立ちません。

共通点は、彼らの誰も何が起こっているのか理解できないということだ。 の間に システム。理由は以下のとおりです。

なぜAPIは企業間の盲点を生み出すのか？

APIは企業間のインターフェースです。レストランの厨房に入ってシェフと直接話そうとしないのと同じように、企業同士もファイアウォールの向こう側を覗き見たりはしません。APIを介してやり取りを行い、相手側で何が起こっているのかを知ることなく、構造化されたリクエストとレスポンスを交換します。

そこに死角が現れるのです。

2つのシステムがAPIを介して通信する場合、どちらも相手の内部動作を把握することはできません。リクエストが自社のインフラストラクチャから送信された瞬間、それは「他者の問題」というブラックボックスに入り込み、自社が所有しておらず、計測もできないインフラストラクチャ、ネットワーク、依存関係などが含まれます。

根本的な問題は、インターネット自体が計測対象ではないということです。制御できないネットワークやインフラストラクチャにエージェントやRUMスクリプトをデプロイすることはできません。そのため、従来の監視ツールはエッジで止まってしまいます。それより先は、推測するしかないのです。

しかし、優れたデジタル体験を提供するには、複数のネットワーク、プロトコル、エージェント、サブシステムが連携して動作する必要があります。これらの依存関係が、インターネットスタックと呼ばれるものを構成します。

インターネットスタック

インターネットスタックとは、BGPなどのコアインターネットシステム、TCP/IPなどのネットワーク技術、SASEなどのセキュリティ技術、QUICやPOPなどのプロトコル、クラウドサービス、APIやWebサービスなどのサードパーティ依存関係、SaaSアプリケーションなど、あらゆるデジタルユーザーエクスペリエンスを可能にし、影響を与える技術、システム、サービスの集合体です。この用語は、パブリックインターネット、プライベートネットワーク、そしてその間のあらゆるものを含む、すべてのIPベースのネットワークを指します。

そのサプライチェーンのどこかでパフォーマンスが低下した場合、それがあなたの責任かどうかは関係ありません。顧客は必ずその影響を受けます。APIは効率性を重視して設計されたものであり、可視性を重視して設計されたものではありません。

これはどこですか？ LMインターネットパフォーマンスモニタリング （IPM）は不可欠なものとなります。IPMは、サービスに影響を与える可能性のあるインターネットのあらゆるレイヤーを詳細に可視化します。インターネットスタック向けのAPMと考えてください。自社で所有していないものの、依存しているシステムのために特別に構築されたソリューションです。

APMが不十分な場合、どのようにして真実にたどり着けばよいのでしょうか？

従来の監視ツールでは遅延を説明できなかったため、インターネットパフォーマンス監視（IPM）がそのギャップを埋めました。推測する代わりに、A社はIPMを使用して実行しました。 合成APIテスト 現実世界のネットワーク全体で：

  • ユーザー側のISP：米国の主要通信事業者および光ファイバープロバイダー
  • バックボーンとエンタープライズの観点から
  • A社自身のインフラ内部から

各テストでは、追跡可能なリクエストIDとタイムスタンプを含む、実際のAPI呼び出しをシミュレートした。結果は明白だった。

この図は、クライアントからAkamai、内部プロキシインフラストラクチャ、そしてアップストリームシステムに至るまでのAPI呼び出しの全経路を示しています。レイテンシが蓄積される箇所が示されています。

  • DNS、接続、SSLにかかる時間はごくわずかです。
  • Akamaiのエッジ処理は高速です（約48ms）。
  • サーバーインフラストラクチャ内部において、オリジンフェッチ（3,143ms）とプロキシフェッチ（2,364ms）の両方で大きな遅延が発生しています。
  • これは、問題がクライアントやCDNにあるのではなく、バックエンドの奥深くにあることを裏付けています。

都市別のレイテンシの内訳

このグラフは、米国の主要都市における平均応答時間と待ち時間を追跡したものです。重要なポイントは以下のとおりです。

  • 遅延パターンは、地域を問わず驚くほど一貫している。
  • 複数の地域にわたって単一のピークが見られることから、特定の地域に限った問題ではないことがわかる。
  • これは、ボトルネックが外部ネットワークではなく、オリジンインフラストラクチャ内部に存在するという結論を裏付けている。

ISPの内訳

ここでは、ISP（例：AT&T、Comcast、Verizon）ごとにパフォーマンスを分析します。

  • 多少のばらつきはあるものの、プロバイダー間の傾向は安定しており、一貫してパフォーマンスが悪いISPは存在しない。
  • これは、ISP側のルーティングや輻輳を根本原因として排除するのに役立ちます。
  • AT&Tの一時的な急増は、都市レベルのデータで見られるのと同じ時期と一致している。

結果： 内部および外部ともに、一貫して3～6秒の遅延が発生する。

そのデータがあれば、よくある容疑者を排除できるだろう。

  • インターネットサービスプロバイダ（ISP）のせいではなかった。
  • CDNが原因ではありませんでした。
  • DNSの問題ではなかった。
  • それは代理人（Envoy）ではなかった。

消去法は、適切な診断のように機能しました。各レイヤーを分離し、問題のない部分を排除し、原因を絞り込んでいきました。x-envoy-upstream-service-timeなどのレスポンスヘッダーを解析した結果、遅延はさらに上流、つまりA社のサービス環境の奥深くで発生していることが確認できました。これにより、エンジニアは膨大なログ行を精査することなく、正しい方向へ進むことができました。トレースIDとタイムスタンプは社内チームと共有され、アプリケーションの依存関係に関する問題の特定に役立てられ、それが根本原因であることが確認されました。

この体系的なアプローチは、最初の話し合いや準備を含めて、わずか3時間と約15回のテスト実行で完了しました。推測は一切なく、明確な結論が得られました。

内部検証後、各チームは改善作業を開始した。改善作業は現在も進行中だが、最も重要な部分では既に効果測定が可能となっている。

バックエンドのレイテンシが大幅に低下しました。アップストリームのサービス時間と全体の待ち時間は、ほぼ半減しました。これらの改善は、着実な最適化努力が正しい方向に進んでいることを示しています。

IPMが提供するもので、APMでは提供できないものとは？

Datadog、New Relic、Dynatraceは、インフラ内部の監視においては非常に優れています。しかし、インターネット自体を監視するために設計されたものではありません。

インターネットパフォーマンス監視はまさにそのために開発されました。その仕組みは以下のとおりです。

グローバルな代理店ネットワーク

  • ラストマイル、バックボーン、クラウド、エンタープライズ、オンプレミス環境にわたる3,000人以上のエージェント
  • クラウド専用のテストベッドではなく、実際のユーザーネットワークのエミュレーションが必要

全面合成被覆

  • HTTP/S、API、ブラウザ、DNS、SSL、BGP、MQTT、QUIC、カスタムスクリプト

高度な診断

  • パケット損失、ジッター、パス追跡、ホップ分析
  • 領域固有の劣化検出

フロントエンドの可視性

  • 詳細なフロントエンドパフォーマンス分析のためのWebPageTest
  • フロントエンドを計測できるチーム向けのブラウザおよびモバイルRUM SDK

シームレス統合

  • Datadog、Splunk、New Relic、Dynatraceに直接データを送信します。
  • 既存の可観測性スタックを置き換えることなく強化します。
  • リアルタイムの依存関係マップを通じて、インターネットスタック全体にわたるエンドツーエンドの可視性を提供します。

そしてなぜなら CatchpointはLogicMonitorプラットフォームの一部です。 並んで LMエンビジョン (NAIST) と エドウィン AIこれにより、チームはユーザーからコードまでを統合的に把握できます。インターネットのパフォーマンスデータは、インフラストラクチャ、クラウド、アプリケーションを網羅する同じテレメトリパイプラインとコンテキストグラフに流れ込み、運用チームは単一のシステムでデジタルパス全体にわたる問題を検知、理解、対処できるようになります。

チームが目的に合わないツールでも使い慣れたツールに固執する理由

使い慣れたツールは快適です。導入済みで広く理解されており、政治的にも安全です。しかし、特に大規模で成熟した組織では、ツールの決定が目的適合性よりも慣性によって左右されるため、快適さが能力を凌駕してしまうことがあります。一秒が重要で顧客に影響が出る場合、必要なのは 明瞭快適さではない。

APIの応答が遅い場合、誰が責任を負うべきでしょうか？

このケースでは、B社はA社を非難し、A社はB社を非難した。どちらも自らの主張を裏付けるデータは持ち合わせていなかった。

一方、ユーザーは動作の遅さを実感するばかりだった。

エンドユーザーは、API呼び出しが企業の境界を越えていることを知りません。彼らが目にするのは、自分がやり取りしているブランドだけです。もしAPIの応答が遅ければ、そのブランドに責任があると考えるでしょう。パフォーマンスの問題を迅速に解決することは、単なる技術的な問題解決にとどまりません。それは、ビジネス関係と顧客の信頼を守ることにつながるのです。

可観測性の本当の役割

可観測性があれば、真実に素早くたどり着けるはずだ。そして多くの場合、真実はあなたのオフィスの外にある。

AIが主流となる世界では、データが意思決定の原動力となります。しかし、データが不完全であったり、テレメトリデータが自社のインフラに限定されていたりすると、AIモデルは不完全な情報に基づいて動作することになります。

LMインターネットパフォーマンスモニタリング チームに以下の機能を提供する：

  • 外部から内部へとパフォーマンスを検証する
  • 独立したデータを用いて、内部仮説を証明または反証する
  • 原因を数分で特定、数日もかからない

可観測性の要点は、答えにたどり着くことです。LMインターネットパフォーマンスモニタリングは、自社環境内だけでなく、インターネット経路全体にわたってそれを可能にします。

インターネットスタック全体で、APIがどこで時間をロスしているかを確認してください。

LMインターネットパフォーマンスモニタリングは、ユーザーからオリジンサーバーまでのパス全体を可視化し、レイテンシーの問題を数日ではなく数時間で解決できるようにします。LM EnvisionおよびEdwin AIと組み合わせることで、デジタルパス全体を統合的に把握できます。

よくあるご質問

インターネットパフォーマンスモニタリングは、APMとどのように異なるのですか？

APMは、自社インフラストラクチャ内のアプリケーションパフォーマンスを監視します。インターネットパフォーマンス監視（IPM）は、システムとユーザー間のネットワーク、ISP、CDN、DNSレイヤーに可視性を拡張します。これら2つを組み合わせることで、コードから顧客まで、パス全体にわたる完全な可視性を実現します。

LM Internet Performance Monitoringは、DatadogやNew Relicといった既存のツールと連携して動作しますか？

はい。LM Internet Performance Monitoringは、Datadog、Splunk、New Relic、Dynatraceと直接統合します。既存のツールを置き換えることなく、外部ネットワークの可視性を追加することで、既存のオブザーバビリティスタックを強化します。

インターネットパフォーマンス監視は、境界を越える遅延の根本原因をどれくらいの速さで特定できるのか？

本稿で紹介する事例研究では、チームは約15回の合成テスト実行を用いて、約3時間で根本原因を特定しました。この体系的な診断アプローチにより、インターネットスタックの各レイヤーを系統的に除外することで、推測に頼る必要がなくなります。

デントン千倉著

テクニカルライター

デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。

免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。

関連ブログ

可観測性ROI：実際の導入による真のコスト削減
Blog

可観測性ROI：実際の導入による真のコスト削減

可観測性を高めることで、アラートのノイズを減らし、インシデント対応を迅速化し、ダウンタイムを削減し、エンジニアが計画的な作業に費やす時間を増やすことができます。LogicMonitorの顧客は、これらのメリットを活用してコストを削減し、より適切なインフラストラクチャの意思決定を行っています。
2026 年 9 月 9 日
さらに詳しく
HTTPSは中間者攻撃への解決策となるのか？
Blog

HTTPSは中間者攻撃への解決策となるのか？

合成監視によって隠れたHTTPリダイレクト攻撃がどのように明らかになったか、そしてHTTPS、HSTS、配信経路の可視化がユーザーを傍受から守る理由をご覧ください。
2026 年 9 月 9 日
さらに詳しく
古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法
Blog

古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法

権威サーバーは正しいIPアドレスを返しているにもかかわらず、ユーザーが古いIPアドレスにアクセスしてしまうケースがあります。ここでは、古いグルーレコードを見つけて、親ゾーンのリファラルを修正する方法をご紹介します。
2026 年 9 月 9 日
さらに詳しく