--- title: "Dynatraceとは？OneAgentとAI根本原因分析の仕組み・導入手順・料金とDatadogとの選び分け【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18310/" published: 2026-10-13 updated: 2026-10-13 categories: ["監視・オブザーバビリティ"] publisher: "株式会社一創" --- # Dynatraceとは？OneAgentとAI根本原因分析の仕組み・導入手順・料金とDatadogとの選び分け【2026年10月】 Dynatraceは、アプリケーション・インフラ・ユーザー体験の監視データを1つのプラットフォームに集め、AIで障害の根本原因まで絞り込む米Dynatrace社のSaaS型オブザーバビリティ製品です。この記事では、エージェント1本で構成を自動検出する仕組み、アラートが問題単位にまとまる条件、LinuxとKubernetesへの導入コマンド、2026年10月時点のレートカードに基づく料金を順に示します。最後に、Datadogとどちらを選ぶかを条件付きで言い切ります。 ## まとめ：Dynatraceを採用すべき大規模環境と見送る小規模チームの条件 Dynatraceの強みは、OneAgentを入れるだけでホスト・プロセス・サービスの依存関係（Smartscape）が描かれ、その構成図をもとにAIが「どこが原因か」を1件の問題にまとめて示す点です。数百台規模で、障害のたびに複数チームがログを突き合わせている組織ほど効果が出ます。 見送るのは、ホストが十数台でメモリの大きいサーバーが多い構成です。Full-Stack監視はメモリ量に比例する課金で、32GiBのホストは8GiBの4倍かかります。OpenTelemetryで計装を揃えたい、ツールの乗り換え余地を残したいという方針のチームにも向きません。 ## Dynatraceの仕組み：OneAgentの自動検出とSmartscapeの依存関係把握 監視とオブザーバビリティの違いから押さえたい場合は、先に[オブザーバビリティと監視・APMの違い](https://www.issoh.co.jp/column/details/3077/)を読むと、この章の位置づけがつかみやすくなります。 ### OneAgent1本でホスト・プロセス・サービスを自動ディスカバリする範囲 Dynatraceの計装は、ホストに入れるOneAgentが起点です。OneAgentはOS上で動くプロセスを検出し、Java・.NET・Node.jsなどのランタイムに自動でコードモジュールを差し込みます。アプリのソースにSDKを書き足さなくても、HTTPリクエストやDBクエリの呼び出しがトレースとして記録されます。 監視モードは`fullstack`・`infra-only`・`discovery`の3種類です。トレースまで取るのはFull-Stackだけで、Infrastructureはホストとプロセスの指標、Discoveryは構成の検出が中心になります。料金もモードで変わるため、全台Full-Stackにするか、DBサーバーなどはInfrastructureに落とすかを最初に決めます。 APMとしての計装方式の違い（エージェント型とOpenTelemetry型）は、[APMの仕組みとOpenTelemetry計装](https://www.issoh.co.jp/tech/details/15414/)で整理しています。 ### GrailとDQL：ログ・メトリクス・トレースを1か所に集める保管基盤 収集したデータは、Grailと呼ばれるデータレイクハウスに保管されます。ログ・メトリクス・トレース・イベントが同じ保管庫に入り、Dynatrace Query Language（DQL）で横断的に検索できます。 ログ用・メトリクス用で別々の製品やクエリ言語を覚える必要がない点は、運用担当者の学習コストを下げます。一方でGrailへのクエリは、ログやトレースではスキャンしたGiB単位の課金対象です。ダッシュボードを自動更新で大量に開いておくと費用が増える点は、料金の章で数字を示します。 ## AIによる異常検知と根本原因分析：Davisイベントが問題にまとまる流れ Dynatraceの差別化要素として語られる「Davis AI」は、2026年10月時点の公式ドキュメントでは分析エンジンを「Dynatrace Intelligence」、個々の検知を「Davisイベント」と呼び分けています。古い解説記事と名称が違っても、指しているものは同じ系統です。 ### 時間相関でなくトポロジーで原因を絞るフォルトツリー分析の考え方 公式の[Root cause analysis concepts](https://docs.dynatrace.com/docs/dynatrace-intelligence/root-cause-analysis/concepts)は、同じ時刻に異常が出たという時間相関だけでは根本原因の特定に足りないと明記しています。代わりに使うのが、Smartscape・OneAgent・クラウド連携から得た既知の依存関係です。 たとえばAPIの応答遅延とDBのCPU高騰が同時に起きた場合、呼び出し関係をたどって「DBが原因、APIは影響を受けた側」と順序を付けます。縦方向（ホスト→プロセス→サービス）と横方向（サービス間の呼び出し）の両方をたどるフォルトツリー分析です。依存関係の情報が欠けていると精度が落ちるため、OneAgentを入れていないホストが多い環境では効果が薄れます。 ### 90分・5分・3分の閾値：問題の統合とアラート送信が遅れる条件 同じ根本原因を持つDavisイベントは1つの「問題（Problem）」にまとまり、アラートの洪水を防ぎます。この統合には、運用設計に直結する閾値があります。 | 条件 | 公式ドキュメントの記載 | 運用への影響 | | ------------ | ------------ | ----------------- | | 統合できる期間 | 問題の開始から90分まで | 長引く障害の後半は別の問題になる | | 最初のイベント間隔 | 5分を超えると別の問題 | じわじわ広がる障害は分割されやすい | | Processing状態 | 作成後およそ3分 | この間はアラートが送られない | | 重複の扱い | 重複フラグがtrue | 即時通知を優先し重複を許容 | 表の重複フラグは`dt.davis.is_duplicate=true`を指します。「アラートが数分遅れて届く」という問い合わせの多くは、このProcessing状態が原因です。決済APIの停止など1分でも早く知りたい監視は、メトリックイベントによるカスタムアラートに分けると、解析待ちの遅延を0にできます。 ## Dynatrace導入：LinuxとKubernetesのOneAgent設定手順 ここからは公式ドキュメントに沿って、SaaS版の環境を作成済みという前提で、計装から確認までのコマンドを示します。環境IDは`abc12345`のような英数字で、URLは`https://<環境ID>.live.dynatrace.com`の形です。 ### Linuxホストへのインストールとホストグループ・監視モードの指定 インストーラーは、管理画面の「Discovery & Coverage」から「Install OneAgent」を選ぶと、ダウンロード用トークン入りのコマンドとして表示されます。[Install OneAgent on Linux](https://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/installation-and-operation/linux/installation/install-oneagent-on-linux)によると、インストールと更新には256MB以上の空きメモリが必要です。 取得したインストーラーを実行するときに、[Customize OneAgent installation on Linux](https://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/installation-and-operation/linux/installation/customize-oneagent-installation-on-linux)にあるパラメータでホストグループと監視モードを指定しておくと、後から台帳を整理する手間が減ります。 ``` # 管理画面で表示されたwgetコマンドでインストーラーを取得した後に実行 sudo /bin/sh Dynatrace-OneAgent-Linux.sh \ --set-host-group=web_prod \ --set-monitoring-mode=fullstack \ --set-host-tag=role=web # DBサーバーはトレース不要ならインフラ監視に落として費用を抑える sudo /bin/sh Dynatrace-OneAgent-Linux.sh \ --set-host-group=db_prod \ --set-monitoring-mode=infra-only ``` OneAgent 1.193以降は非特権モード（`NON_ROOT_MODE=1`）が既定です。インストール先は`/opt/dynatrace/oneagent`で、`INSTALL_PATH`で変えられます。Javaなどのプロセスへの差し込みは、インストール後にそのプロセスを再起動してから有効になります。 ### Dynatrace OperatorとDynaKube：Kubernetes監視設定 Kubernetesでは、ノードごとに手で入れるのではなくDynatrace Operatorに任せます。[Kubernetes向けFull-Stack監視の手順](https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/deployment/full-stack-observability)では、Kubernetes 1.35以上ならCSIドライバーを使わずイメージボリュームでコードモジュールを差し込む構成が推奨されています。 ``` helm install dynatrace-operator oci://public.ecr.aws/dynatrace/dynatrace-operator \ --set "csidriver.enabled=false" \ --create-namespace --namespace dynatrace --atomic kubectl -n dynatrace create secret generic dynakube \ --from-literal="apiToken=" \ --from-literal="dataIngestToken=" # dynakube.yaml apiVersion: dynatrace.com/v1beta6 kind: DynaKube metadata: name: dynakube namespace: dynatrace annotations: feature.dynatrace.com/mount-code-modules-via-image-volume: "true" spec: apiUrl: https://ENVIRONMENTID.live.dynatrace.com/api oneAgent: cloudNativeFullStack: {} activeGate: capabilities: - routing - kubernetes-monitoring resources: requests: { cpu: 500m, memory: 512Mi } limits: { cpu: 1000m, memory: 1.5Gi } kubectl apply -f dynakube.yaml kubectl get dynakube -n dynatrace ``` Helm 4.0以降では`--atomic`を`--rollback-on-failure`に置き換えます。Operator 1.8以前は`v1beta5`のマニフェストになるため、既存クラスタの更新ではOperatorの版を先に確かめてください。ActiveGateのPodは上の例で最大1.5Giのメモリを使うので、小さなノードしかないクラスタでは配置先を空けておく必要があります。 ### Metrics API v2とDQLで監視データを取り出して確認するコマンド例 計装できたら、データが届いているかをAPIで確かめます。[Metrics API v2](https://docs.dynatrace.com/docs/dynatrace-api/environment-api/metric-v2/get-data-points)は`metrics.read`スコープのトークンで呼べます。 ``` curl -X GET 'https://abc12345.live.dynatrace.com/api/v2/metrics/query?metricSelector=builtin:host.cpu.usage&resolution=10m&from=now-2h' \ -H 'Authorization: Api-Token dt0c01.XXXX' \ -H 'Accept: application/json' ``` ログの確認はNotebooksなどでDQLを書きます。[Use DQL queries](https://docs.dynatrace.com/docs/platform/grail/dynatrace-query-language/dql-guide)の例を基にした、直近2時間のエラーログを数えるクエリです。 ``` fetch logs, from:now() - 2h | filter loglevel == "ERROR" | summarize numErr = count() ``` パイプでつなぐ書き方はSQLよりもシェルに近く、`filter`で絞ってから`summarize`で集計する順番を守ると、スキャン量が減ってクエリ費用も下がります。 ## Dynatraceの料金：DPSのレートカードとホスト・Pod・ログ課金の見積もり方 Dynatraceの契約はDynatrace Platform Subscription（DPS）で、年間の最低利用額をコミットし、使った分をレートカードの単価で差し引く方式です。以下は2026年10月13日に[公式の料金ページ](https://www.dynatrace.com/pricing/)で確認した値で、ページ自体に時点の表記はありません。コミットを超えた分はペナルティなしで同じ単価の月次請求になります。 ### Full-Stack 58ドル・Infrastructure 29ドル：ホスト単価比較 | 項目 | 月額の目安 | 時間単価 | | ------------------------- | ------------ | -------------- | | 基盤・検出 | 7ドル／ホスト | 0.01ドル／ホスト時 | | Infrastructure Monitoring | 29ドル／ホスト | 0.04ドル／ホスト時 | | Full-Stack Monitoring | 58ドル／8GiBホスト | 0.01ドル／メモリGiB時 | | Kubernetes基盤監視 | 1.40ドル／Pod | 0.002ドル／Pod時 | | Code Monitoring | 3.60ドル／コンテナ | 0.005ドル／コンテナ時 | 表の「基盤・検出」はFoundation & Discovery、「Kubernetes基盤監視」はKubernetes Platform Monitoringの略記です。見落としやすいのは、Full-Stackだけがメモリ量で課金される点です。8GiBで月58ドルなので、32GiBのホストを1か月動かすと0.01ドル×32GiB×730時間でおよそ234ドルになります。メモリを多く積んだJavaのアプリサーバーやDBを全台Full-Stackにすると、ホスト数から想像する金額の数倍になるため、見積もりはホストごとのメモリ量の一覧から作ります。 ### ログ・トレースはGiB課金：取り込み0.20ドルとクエリ課金の増え方 ログは取り込み・処理が1GiBあたり0.20ドル、保持が1GiB・1日あたり0.0007ドル、クエリがスキャン1GiBあたり0.0035ドルです。1日10GiBのログなら、取り込みだけで月およそ60ドルになります。 クエリ課金を避けたい場合は、保持料にクエリを含めるBundled Queries（1GiB・1日あたり0.02ドル、保持10〜35日）も選べます。参照頻度の高い直近ログはBundled、監査用に長く残すログはPay-per-Queryという分け方が、費用の読みやすさでは有利です。AIによる調査はAgentic Operationsとして1AIユニット0.10ドルで、自律的な多段階調査は平均30ユニット（約3ドル）と案内されています。 ## DynatraceとDatadogの選び分け：自動化の深さと課金単位で判断する基準 Dynatraceの導入検討で比較相手に挙がりやすいのがDatadogです。Datadog側の機能構成は[Datadogの仕組みと料金](https://www.issoh.co.jp/tech/details/6476/)にまとめています。 ### 機能と課金単位の比較表：Full-StackホストとAPMホストの単価差 | 観点 | Dynatrace | Datadog | | ----------- | ---------------- | ------------------------- | | 計装の起点 | OneAgentが自動で差し込み | Agent＋言語別トレーサー | | 障害の束ね方 | 依存関係から問題を1件に統合 | モニター単位の通知が基本 | | APM込みのホスト単価 | 58ドル（8GiBホスト） | 46ドル（Infra Pro 15＋APM 31） | | メモリ量の影響 | 比例して増える | ホスト単価は一定 | | ログ取り込み | 0.20ドル／GiB | 0.10ドル／GB＋インデックス課金 | Datadogの単価は[Datadogの料金ページ](https://www.datadoghq.com/pricing/)の年払い価格で、APMはInfrastructure Monitoring併用時の値です。Datadogはログのインデックス件数やカスタムメトリクスで費用が膨らむ構造があり、その内訳は[Datadogで費用が膨らむ課金単位](https://www.issoh.co.jp/tech/details/16574/)で解説しています。単価表だけでどちらが安いとは言えず、メモリ量とログ量の実データで両方を試算するのが確実です。 ### Dynatraceを採用すべき条件：数百ホスト規模で依存関係が追えない環境 採用するのは、監視対象が数百ホスト・数十サービスを超え、障害時に「どのチームの持ち場が原因か」の切り分けに毎回1時間以上かかっている組織です。この規模では、Smartscapeで構成図が自動更新され、問題が1件にまとまることの価値が、単価の差を上回ります。 Java・.NETの業務系アプリが多く、ソースに計装コードを入れにくいパッケージ製品を抱えている場合も、OneAgentの自動差し込みが効きます。監視の設計から障害対応の体制づくりまでをまとめて見直したい場合は、[保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)として、ツール選定と運用ルールの整備から相談を受けています。 ### Dynatraceを見送る場面：ホスト十数台の小規模チームとOSS中心の計装 見送るのは、ホストが十数台以下で、1人か2人が全体を把握できている構成です。根本原因分析の恩恵が小さいわりに、年間コミット型の契約と、メモリ量に比例するFull-Stack課金の負担が残ります。 計装をOpenTelemetryで統一し、バックエンドを後から替えられるようにしたい方針のチームも、OneAgent中心のDynatraceとは相性がよくありません。その場合は[DatadogのOpenTelemetry連携の4方式](https://www.issoh.co.jp/tech/details/16564/)や、データ量課金の[New Relicの構成と課金設計](https://www.issoh.co.jp/tech/details/17247/)を並べて比べてください。製品の横並びの比較は[オブザーバビリティツールの選定軸](https://www.issoh.co.jp/column/details/16502/)で整理しています。 ## Dynatraceの導入前によくある質問：無料トライアル・料金・アラート Dynatraceの検討でよく出る質問に、2026年10月時点の公式ドキュメントと料金ページをもとに答えます。 ### Dynatraceの無料トライアルは何日使えますか？ 公式の料金ページには15日間の無料トライアルが案内されています。期間中に、OneAgentを数台のホストに入れてSmartscapeの構成図と問題の統合を確かめるのが現実的な使い方です。本番の見積もりでは、トライアルで取れたホストごとのメモリ量とログの日量を控えておくと、DPSのコミット額を算出しやすくなります。 ### Davis AIとDynatrace Intelligenceは別の機能ですか？ 同じ系統の機能です。2026年10月時点の公式ドキュメントでは、根本原因分析を担う分析エンジンを「Dynatrace Intelligence」と呼び、異常として検知された個々の事象を「Davisイベント」と呼んでいます。以前の資料で「Davis AIが原因を特定する」と書かれている箇所は、現在の名称ではDynatrace Intelligenceの根本原因分析を指します。 ### Dynatraceのアラートが数分遅れて届くのはなぜですか？ 問題が作成されてからおよそ3分間はProcessing状態になり、他のイベントと統合するかを解析している間はアラートが送られないためです。重複通知を減らすための仕様なので、即時性が要る監視だけをメトリックイベントのカスタムアラートに分けると、解析待ちの遅延を避けられます。 ### DynatraceとDatadogはどちらが安いですか？ 構成次第で逆転します。APM込みのホスト単価は、8GiBのホストならDynatraceが月58ドル、DatadogがInfrastructure Pro 15ドルとAPM 31ドルで月46ドルです。DynatraceのFull-Stackはメモリ量に比例するため、大きなホストが多いほど差が開きます。逆にDatadogはログのインデックス件数やカスタムメトリクスで増えるので、ログが多い環境では差が縮みます。 ### Dynatraceのログを長く保存すると料金はどう増えますか？ Pay-per-Queryの場合、保持は1GiB・1日あたり0.0007ドルです。1日10GiBを1年分（約3,650GiB）ため込んだ状態なら、保持料は1日あたりおよそ2.6ドル、月におよそ77ドルです。保持料そのものより、長期間のログを繰り返し検索するときのスキャン課金（1GiBあたり0.0035ドル）が膨らみやすいため、検索範囲を期間で絞る運用ルールを先に決めておきます。 ## 関連記事 - [Datadogとは？何ができるか・仕組み・料金とCloudWatch/Zabbixとの違い](https://www.issoh.co.jp/tech/details/6476/)：Dynatraceと最も比較される監視SaaSの機能と料金。 - [オブザーバビリティツール比較｜選定軸と課金モデル・体制別の選び方【2026年8月時点】](https://www.issoh.co.jp/column/details/16502/)：Dynatraceを含む主要製品を課金モデルと体制で選ぶ判断軸。 - [New Relicとは｜APM・インフラ監視の構成とデータ量課金の設計を実装目線で解説](https://www.issoh.co.jp/tech/details/17247/)：データ量課金の製品と比べるときの構成と費用設計。 - [APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説](https://www.issoh.co.jp/tech/details/15414/)：OneAgentの自動計装を理解する前提となるAPMの基礎。 - [オブザーバビリティ（可観測性）とは？監視・モニタリング・APMとの違いと使い分けを解説](https://www.issoh.co.jp/column/details/3077/)：Dynatraceが扱う領域全体の位置づけ。 --- 出典: [Dynatraceとは？OneAgentとAI根本原因分析の仕組み・導入手順・料金とDatadogとの選び分け【2026年10月】]()（株式会社一創）