dd-product-recommender

Datadog 製品レコメンダー

ユーザーのコードベースや明示された目標にどの Datadog 製品が適しているかを提案します。次の2つのシグナルを製品に対応付け、優先順位を付けた、根拠のある簡潔な製品セットをまとめます。

1. 技術スタック → 製品（コードベースから推測できること）
2. ユースケース／意図 → 製品（明示された目標から推測できること）

対象範囲はレコメンデーションのみです。 セットアップ／インストール手順を生成したり、オンボーディング／MCP ツールを呼び出したり、ファイルを編集したりしないでください。出力するのはレコメンデーションとその根拠です。

中核となる考え方（まずお読みください）

基盤は前提とします。十分な根拠がある差別化要素があれば、まずそれを提示します。

Infrastructure Monitoring、Log Management、APM の3製品は、多くのバックエンド／コンテナ化サービスに適しています。これらは基盤です。スタックが対応していれば、基本として含めます。付加価値となるのは、一般的な製品リストでは見落とされがちな、ユースケース固有の製品（AI アプリ向けの LLM Observability、セキュリティ目標向けの Cloud SIEM など）を提示することです。

製品セットの判断は、次の2点を軸に行います。

• 十分な根拠がある差別化要素が存在する場合に限り、それを最初に提示します。 意図に明確に特徴付けられる決め手がない場合（一般的なインフラ／Kubernetes のパフォーマンスなど）は、基盤を先に提示するのが正しい対応です。見せかけの目玉を作らないでください。
• 上限は3製品です。 スタックと目標に最も合致する3製品を選びます。スタックが小規模、静的なもののみ、または対象範囲外であれば、3つ未満でかまいません。最低数はありません。0製品または1製品も有効な結果です。「すべて」という依頼でも、コードベースから最も強いシグナルが得られる上位3製品までに限定します。

ステップ 0 — 参照データ

このスキルでは、製品との対応付けに関する根拠を以下にまとめています。提案する前に、次の3つのセクションを確認してください。

• スタック → 製品 — 技術シグナル → 製品、基盤か状況依存か、検出の手掛かり
• ユースケース → 製品 — 意図 → 製品、差別化の段階と確信度
• 製品カタログ — 正式名称、別名、一般的な利用状況、提案してはいけない製品のリスト

ステップ 1 — 依頼を理解する

引数／プロンプトからユーザーの目標を読み取ります。該当するモードを判断してください。

• 明示されたビジネス目標（「LLM の使用状況を追跡する」「ログにエラーがある場合に把握する」「セキュリティを強化する」「クラウドコストを削減する」「MTTR を短縮する」「ツールを統合する」）→ 目標を主な提案の軸にします。以下の「ユースケース → 製品」セクションでテーマに対応付けます。
• 自由形式／「適切なものをすべて」 → スタックを軸にします。検出したスタックの基盤と、スタックから推測される最も有力な状況依存の製品を提案します。ただし、コードベースから実際にシグナルが得られる製品に限定します。

対話形式で、目標が本当に曖昧な場合は、確認の質問を1つだけしてもかまいません。ただし、非対話形式での実行を指示されている場合や、質問しないよう指示されている場合は、最善の推測に基づいて検出を進めてください。

ステップ 2 — 対象範囲を確認してから、スタックを検出する

ステップ 2a — 単一のプロジェクトか、プロジェクトの集合か？

何かを検出する前に、指定されたパスが単一のプロジェクトなのか、プロジェクトの集合（モノレポ、ワークスペース、または複数のアプリを含む親フォルダー）なのかを判断します。対象パスの直下の子（1階層のみ）にあるプロジェクトルートを調べます。子ディレクトリが独自のトップレベルのマニフェスト／ロックファイル（package.json、go.mod、requirements.txt／pyproject.toml、pom.xml／build.gradle、Gemfile、*.csproj、composer.json、または Cargo.toml）を持つ場合、そのディレクトリはプロジェクトルートです。1階層より深くは再帰せず、プロジェクトではないディレクトリ（docs/、scripts/、.github/ など）は無視します。

• 単一のプロジェクト — ルートにマニフェストがあり、兄弟プロジェクトルートがない → 通常どおり、パス全体を対象にステップ 2b に進みます。

• プロジェクトの集合（1階層下にプロジェクトルートが 2 つ以上） — それらを 1 つのスタックにまとめてはいけません。個別のプロジェクトを特定します。対象は最大 4 つです（それ以上ある場合は、代表的な 4 つを提示し、ほかにも存在することを伝えます）。それぞれについて、ディレクトリ名と 1 行のスタック概要（特定の根拠となったマニフェスト）を記載します。その後、停止してユーザーに 1 つ選んでもらいます。自動で選択してはいけません。推奨するのは、選択されたプロジェクトのみです。

  質問方法 — 利用できる場合は構造化 UI を優先します。

  • 対話型の Claude Code セッション — 単一の質問で AskUserQuestion を呼び出します。 question: "Which project would you like me to analyze?"、header: "Project" を指定し、プロジェクトごとに {label: <dir-name>, description: <one-line stack summary — manifest file>} の選択肢を 1 つずつ（最大 4 つ）用意します。「Other」から、一覧にないプロジェクトをユーザーが入力できます。
  • 非対話型／ツールが利用できない場合 — 番号付きリスト（1 行に 1 プロジェクト、ディレクトリ名とスタック概要）を提示して停止します。続行する前にユーザーの返信を待ちます。

  以下のすべて（スタックの検出、基盤／差別化のマッピング、ガードレールの表、アンカーの裏付け確認）は、選択されたプロジェクトのサブツリーのみに適用され、プロジェクト全体の統合には適用されません。

ステップ 2b — スタックを検出する（選択されたプロジェクト内）

選択されたプロジェクト（例：./project、選択したサブプロジェクト、または現在のリポジトリ）をスキャンします。以下を特定し、それぞれについて特定の根拠となったファイルを記載します。

• 言語／ランタイム — package.json、requirements.txt／pyproject.toml、go.mod、pom.xml／build.gradle、Gemfile、*.csproj、composer.json、Cargo.toml
• Web フレームワーク — Django／Flask／FastAPI、Express／Next.js／Nest、Spring Boot、Rails、Laravel、Gin／chi
• フロントエンド — React／Vue／Angular／Svelte／Next（クライアント）／vanilla、およびバンドラー（vite／webpack／esbuild）→ Source Maps
• モバイル — iOS／Android／React Native／Flutter／Unity
• データベース — Postgres／MySQL／SQL Server／Oracle／Mongo（ドライバーの依存関係、DATABASE_URL、compose サービス）
• データストア／メッセージング — Redis、Kafka、RabbitMQ、SQS／SNS、Elasticsearch
• デプロイ／プラットフォーム — Docker、Kubernetes、ECS／Fargate、Lambda、Vercel、Cloud Run、Azure、ベアメタルホスト
• クラウド — AWS／GCP／Azure（SDK、IaC の provider、環境変数）
• CI／テスト — .github/workflows、.gitlab-ci.yml、Jenkinsfile、pytest／jest／junit／playwright
• LLM／AI — anthropic／openai／langchain／langgraph／bedrock／vertexai／llamaindex など
• 既存の Datadog — datadog.yaml、dd-trace／ddtrace の依存関係、DD_* 環境変数、@datadog/* SDK → 不足している部分のみを推奨し、すでに組み込まれているものは再提案しません。

見つかったものだけを報告します。シグナル 1 つにつき箇条書き 1 つとし、根拠となったファイルを記載します。存在しないもの（「データベースなし」「フロントエンドなし」など）は列挙しないでください。シグナルについて何も記載しない場合は、検出されなかったことを意味します。リポジトリ全体で計測可能なものがほとんど、またはまったく見つからない場合は、その旨を簡潔に 1 行で記載します。

ステップ 3 — 推奨内容にマッピングする

1. 基盤レイヤー（スタックから判断）： 以下の「スタック → 製品」リファレンスにある「基盤となる基本構成」を適用します。バックエンドがある場合 → APM + ログ（+ プロファイラー）。フロントエンドがある場合 → RUM + エラートラッキング + セッションリプレイ（バンドルされている場合は + ソースマップ）。コンテナ／k8s がある場合 → インフラストラクチャーモニタリング。サーバーレスの場合 → サーバーレスモニタリング。LLM アプリの場合 → LLM オブザーバビリティ。データベースの場合 → APM の DB スパン。クエリパフォーマンスが対象範囲に含まれる場合は DBM も追加します。

2. 差別化レイヤー（意図から判断）： 目標が明示されている場合は、以下の「ユースケース → 製品」リファレンスで該当するテーマを確認し、各製品のティアと確信度を読み取ります。 確信度によって、最初に提示する製品を決めます：

   • 決定的で、十分に確立されている（または、機能から明らかに選ばれるもの）場合 → 最初に提示します。

   • 新興の場合 → 補完的な追加候補として含め、過度に軸にしないでください。

   • 逸話的な場合 → 明示的で曖昧さのない一致がある場合のみ言及し、決して見出しにはしないでください。

   • テーマに確信を持って支持できる差別化要素がない場合（すべて基盤製品、または幅広さだけの場合）は、基盤製品を最初に提示し、その旨を正直に伝えてください。軸となる製品をでっち上げないでください。

   • プラットフォーム機能（意図に基づく）： 目標が「いつ発生したかを知る」／アラートを受ける／通知を受けることであれば、モニターとアラートを最初に提示します（例：エラーパターンに対するログモニター）。これが直接的な回答です。同様に、「一元的な可視化」ならダッシュボード、「SLO／エラーバジェットの追跡」ならSLOです。

3. 意図に合う製品を提示するために、スタックをでっち上げないでください。最初に提示する前に、コードがその製品を裏付けていることを確認してください。 ユースケースの軸となる製品（Cloud SIEM、CSPM、CCM、LLM Obs、NDM、DBM、…）を最初に提示できるのは、コードベースが裏付けている場合のみです。該当する SDK／IaC／ライブラリ／設定が実際に存在する必要があります。ステップ 2a で単一のプロジェクトに絞り込んだ場合、「コードベース」とは選択したプロジェクトのサブツリーを指します。兄弟プロジェクトにある兆候は、選択したプロジェクトの製品軸を裏付けません。明示された目標がある製品を指していても、コードベースにその証拠がない場合（例：クラウド／IaC の要素がないリポジトリでのセキュリティ目標、クラウド SDK／IaC がない場合のコスト目標、LLM ライブラリがない場合の LLM 目標）は、その製品を最初に提示してはいけません。代わりに不一致を明示してください。スタックの証拠は意図との関連性より優先されます。ユーザーの言葉が製品の軸と一致しているだけでは、最初に提示する根拠になりません。

   • リポジトリ外のリソースを目標として述べても、コードベースの証拠にはなりません。 ユーザーが、コードからは確認できないリソース（「当社の AWS 請求額」「当社の AWS 設定」「当社の LLM サービス」など）を明示した場合は、その製品を中／低優先度の条件付き追加候補として、明確な但し書き付きで扱います（「このリポジトリ外で AWS インフラストラクチャーを運用している場合は、Cloud Cost Management／CSPM が該当します。このコードベースからは確認できません」など）。高優先度の最初の候補として提示したり、検出済みの情報として扱ったりしてはいけません。コードが実際に裏付ける製品を最初に提示し、ユーザーが述べた製品は次の条件付きステップとして提案してください。「Cloud: AWS（目標から判断）」のような検出済みスタックの記載は、捏造にあたります。

4. 組み立てて順位付けします。 各製品がスタックと目標にどれだけ直接役立つかに基づいて順序を決めます。各製品の確信度／優先度を示し、証拠に即したものにします。確信度の低い目標に基づく製品は、自動的に高優先度にせず、中／低優先度としてその旨を明記します。 目標に役立たない基盤製品は順位を下げるか、簡潔に触れるだけにします。上限は厳守し、製品は最大 3 つまでにしてください。最も適合するものを選びます（該当するものが少ない場合は、0～1 つでもかまいません）。

5. 精度に関するガードレールを適用し、裏付けのあるもののみを推奨します：

   推奨してはいけない製品…	…ただし、コードベースに以下がある場合を除きます
   RUM（ブラウザー）／セッションリプレイ	Web フロントエンド
   ソースマップのアップロード	バンドラー／ミニファイアを使用する JS フロントエンド
   リアルユーザーモニタリング（RUM）／エラートラッキング（モバイル）	モバイルアプリ
   LLM オブザーバビリティ	使用中の LLM／AI ライブラリ
   データベースモニタリング	データベース
   サーバーレスモニタリング	サーバーレス（Lambda／Vercel／Cloud Run／Azure Functions）
   ネットワークデバイスモニタリング	SNMP／物理ネットワークデバイス
   また、(Services / Non-Product) の項目や、SKU名・価格名をそのまま挙げることは絶対に推奨しないでください（カタログを参照）。

Step 4 — 推奨内容を出力する

この推奨内容が最終回答です。プロンプトに「Step 3 の後で停止」または 「製品の推奨後に停止」と指示されている場合は、この推奨内容を最終メッセージとして出力し、 その後で停止してください。セットアップやインストールの手順には進まないでください。前置き、 要約、締めくくりの文章は不要です。次の構成を厳密に守ってください。

プロジェクト (コレクションのみ) 対象がコレクションの場合のみ、プロジェクトのルートを最大4件まで一覧表示し、それぞれについて スタックの概要を1行で示し、判明の根拠となったマニフェストファイルを記載します。対話型セッションでは AskUserQuestion（Step 2a を参照）を使い、ラジオリストからユーザーに選択してもらいます。 非対話型の環境では、番号付きの説明文リストを使用してください。どちらの場合も、ここで停止して ユーザーの選択を待ちます。単一プロジェクトが対象の場合は、このセクション全体を省略します。

検出されたスタック 検出されたシグナルごとに1つの箇条書きを記載します。形式：- **ラベル：** 値 — 判明の根拠となったファイル 実際に検出できたシグナルのみ記載してください。検出されなかったシグナルには言及しないでください。 既存の Datadog インストゥルメンテーションがある場合は、推奨内容が不足分のみを対象とするよう、 ここに記載してください。計測可能なものがほとんど、または何も見つからなかった場合は、 その旨を1行で述べてください。

推奨製品 最大3製品のランキングを記載します。各項目は1行で、次の形式にします： N. **製品名** · 優先度 · 推奨理由を1文で この文では、検出されたスタックにある具体的なファイルまたはライブラリと、その製品が目的に 対応する機能を持つ理由を明記してください。製品ごとに複数の文を書かないでください。 根拠が薄い候補には 信頼度低 と記載してください。十分な根拠がある場合は、特に有用な製品を 先頭にし、基盤製品（Infra／Logs／APM）はその下に記載します。十分な根拠がある差別化製品がない場合は、 基盤製品を先頭にし、その旨を1行で述べてください。目的に実質的に合致する製品がほとんどない、 またはまったくない場合は、その旨を述べてください。製品リストが短くても、空でも構いません。

不一致に関する注記 (目的とコードベースに実際の不一致がある場合のみ) 明示された目標が、コードベースでは裏付けられない製品を示している場合にのみ、このセクションを含めます （例：LLM関連の目標だがLLMライブラリがない、コスト関連の目標だがクラウドSDKやIaCがない）。 不一致の内容と、確認に必要な根拠を1行で示してください。スタックに存在しない製品を列挙するために このセクションを使わないでください。推奨リストから製品を省けば十分です。

動作ルール

• 提案のみ — インストール手順、設定、MCP 呼び出しを出力してはなりません。コードベースを編集してはなりません。
• 推測せず、検出する — すべての製品は、コード内の実際のシグナルまたは明示された目標に根拠がなければなりません。 インテントアンカーを正当化するために技術スタックを捏造してはなりません。インテントとコードベースの不一致にはフラグを付けてください。
• 検出の前にスコープを定める — 対象に1階層下のプロジェクトルートが2つ以上ある場合、対象はコレクションです。 最大4つまで提示し、AskUserQuestion（対話形式）または番号付きの文章リスト（非対話形式）でユーザーに1つ選ぶよう促し、選択されるまで停止してください。自動選択してはなりません。複数のプロジェクトを1つのセットにまとめてはなりません。また、インテントアンカーは選択されたプロジェクトのサブツリー内でのみ照合し、兄弟プロジェクトは参照してはなりません。
• 確信度に応じて主役を決める — defining と well-established（または明らかに判別できる機能）のアンカーのみを先頭に提示してください。emerging は補足として追加し、anecdotal は明示的な一致がある場合にのみ言及し、見出しには使わないでください。
• 基盤を先頭にしてもよい — 十分に裏付けられた差別化要因がない場合は、Infra／Logs／APM を先頭にするのが適切です。それ以外の場合は、差別化要因の下に基盤を提示してください。
• 上限は厳守：製品は最大3つ — 最も適合するものを選んでください。最低数はありません。技術スタックが小規模、静的のみ、または対象外の場合、製品がごく少数でもゼロでも適切です。「すべて」という要望でも、実際のコードベースのシグナルに基づく上位3つまでに制限してください。
• 簡潔で予測可能な出力 — 前置き、要約、締めの文章は不要です。最大4つのセクション（Projects・Stack・Products・Mismatch）とし、該当しないセクションは省略してください。スタックのシグナルは1つにつき1項目、製品は1行につき1つ、不一致の注記は最大1行にしてください。
• Stack：肯定的な情報のみ — 検出したシグナルのみを列挙してください。欠如を説明してはなりません（「データベースなし」「フロントエンドなし」など）。あるシグナルについて触れていない場合は、検出されなかったことを意味します。既存のDatadogインストルメンテーションは、再提案ではなくギャップを補う提案ができるよう、必ず列挙してください。
• 規模ではなく、機能と根拠で正当化する — 製品ごとに、特定のファイル／ライブラリと、その製品がインテントに対して提供する機能を明記した1文を記載してください。数値、割合、順位を示す規模は挙げないでください。
• 網羅性より正確性 — 長い羅列より、絞り込まれた正確なセットを優先してください。根拠のない製品は省略するだけで十分です。省略理由を説明してはなりません。ガードレール表を守り、サービス名／イネーブルメント名／SKU名を推奨してはなりません。
• 確信度と抑制を最優先する — 製品には確信度低／任意のマークを付けてもかまいません。根拠の薄い目標アンカーは確信度を中／低とし、フラグを付けてください。自動的に高と判定してはなりません。「該当する製品はほとんどない／ない」という結論も有効です。

---

参考：Stack → Products

ユースケースとは直交する軸です。具体的な技術シグナルがある場合、明示された目標とは無関係に、どの製品が適用されるか。 2つの層があります。

• 基盤 — シグナルが存在する場合、ユーザーの目標に関係なく推奨してください。 これが基本となる最低ラインです。
• 状況依存 — ユースケース／インテントに応じてのみ推奨してください（下記の「Use Case → Products」を参照）。 シグナルが可能にすることを理解するためにここに記載しており、常に推奨するものではありません。

検出の手がかりは、各シグナルを特定するファイル／依存関係／パターンです。

バックエンド言語 → APM + プロファイラー + ログ（基盤）

GA 対応の 7 言語（Python から PHP）には、GA 対応の APM トレーサーと継続的プロファイラーが備わっています（プロファイラーはトレーサーに同梱）。これらは基盤となります。例外は Rust と C/C++ です。これらのトレース／プロファイリング機能はプレビュー版または手動での設定が必要なため、基盤ではなく状況に応じて検討してください。

シグナル	検出の手掛かり	製品	備考
Python	requirements.txt、pyproject.toml、Pipfile、*.py	APM + プロファイラー + ログ	GA 対応の ddtrace、幅広い自動計装
Node.js	package.json、*.js/*.ts	APM + プロファイラー + ログ	GA 対応の dd-trace
Java / JVM（Kotlin、Scala）	pom.xml、build.gradle、*.java/*.kt	APM + プロファイラー + ログ	GA 対応の -javaagent
Go	go.mod、*.go	APM + プロファイラー + ログ	GA 対応の dd-trace-go。計装には contrib/Orchestrion を使用（コンパイル型言語のため、ゼロタッチではありません）
Ruby	Gemfile、*.rb	APM + プロファイラー + ログ	GA 対応の datadog gem
.NET（C#/F#）	*.csproj、*.sln、*.cs	APM + プロファイラー + ログ	プロファイラーはAPM とともに自動で有効になりません。ARM64 および Lambda には対応していません
PHP	composer.json、*.php	APM + プロファイラー + ログ	GA 対応のトレーサー
Rust	Cargo.toml、*.rs	APM（プレビュー、OTel 経由の手動設定）+ ログ	自動計装には非対応。ddprof によるプロファイリング（プレビュー）。基盤ではなく、状況に応じて検討
C / C++	CMakeLists.txt、*.cpp/*.c	ddprof によるプロファイラー（プレビュー）	自動 APM には非対応。状況に応じて検討

Web フレームワーク → APM を強化し、AAP を有効化（状況に応じて）

Web フレームワークが存在すると、APM はすぐに HTTP ルート／リクエストのスパンを取得できます。また、サービスが Web に公開されるため、アプリケーションと API の保護も状況に応じた選択肢になります。

• Python：Django / Flask / FastAPI · Node：Express / Koa / Nest / Next.js(server) · Java：Spring Boot · Ruby：Rails · PHP：Laravel · Go：Gin / Echo / chi / Fiber · .NET：ASP.NET (Core)。

フロントエンドフレームワーク → RUM + エラートラッキング + セッションリプレイ（基盤）

ブラウザーのフロントエンドは、RUM バンドルの基盤となります。ソースマップアップロードは、バンドラー／ミニファイアーが存在する場合に基盤となります（それがないと、スタックトレースを読み取れません）。プロダクト分析は、ここでは**状況に応じた機能（明示的に一致する場合のみ）**であり、基盤の最低要件には含まれません。カタログとデジタルエクスペリエンスのテーマを参照してください。

シグナル	検出の手掛かり	備考
React	react/react-dom、*.tsx	専用の @datadog/browser-rum-react プラグイン
Vue	vue、*.vue	専用の browser-rum-vue プラグイン（3.5+）
Next.js（クライアント）	next、app/ または pages/	専用の browser-rum-nextjs プラグイン
Angular	@angular/core、angular.json	コア SDK + 手動での startView
Svelte/SvelteKit	svelte、svelte.config.js	コア SDK。hooks.client.ts で初期化
Vanilla JS	index.html + <script>	npm または CDN 経由のコア SDK
バンドラー／ミニファイアー	vite.config.*、webpack.config.js、esbuild、rollup、rspack	→ ソースマップアップロード（任意のフロントエンドとともに基盤となります）

モバイル → リアルユーザーモニタリング（RUM）+ エラートラッキング（基盤）

iOS（*.xcodeproj、Podfile、*.swift） · Android（build.gradle + AndroidManifest.xml、*.kt） · React Native（react-native + android/+ios/） · Flutter（pubspec.yaml、*.dart） · Unity（Assets/、*.unity） · Kotlin Multiplatform · Roku。

データベース → データベースモニタリング（状況に応じて）；APM DB スパン（基本、APM に含まれ無料）

DBM が公式にサポートしているもの：PostgreSQL、MySQL/MariaDB、SQL Server、Oracle、MongoDB（＋DocumentDB、 ClickHouse）。**重要な違い：**DB クライアントライブラリだけでも、APM クライアント側 DB スパン （アプリから見たクエリ）が無料で利用できます。DBM は、深い分析を行うオプトイン型の製品です（実行プラン、クエリサンプル、 ロック、エンジンメトリクス）。DB／クエリのパフォーマンスが懸念される場合に推奨し、すべてのサービスの基本構成には含めません。

検出の手がかり：pg/psycopg2/lib/pq/pgx（Postgres） · mysql/mysql2/go-sql-driver · pyodbc/Microsoft.Data.SqlClient（SQL Server） · cx_Oracle/ojdbc · mongoose/pymongo/mongo-go-driver · DATABASE_URL、compose 内の postgres/mysql/mongo サービス。

データストア／メッセージング → インテグレーション＋APM スパン；キューには DSM（状況に応じて）

Redis · Memcached · Elasticsearch/OpenSearch → APM キャッシュ／クエリスパン（基本）＋Agent インテグレーション（状況に応じて）。 Kafka · RabbitMQ · SQS · SNS · Kinesis · Pub/Sub · IBM MQ · Azure Service Bus · BullMQ → サービス間のエンドツーエンドのパイプライン遅延、コンシューマーのラグ、スループットを把握するための Data Streams Monitoring（状況に応じて）。DSM SDK：Java、Python、Node.js、.NET、Ruby（Kafka）、Go（Kafka）。 明示的なブローカー依存関係がなくても、イベント駆動型アーキテクチャの場合は適しています。たとえば、マイクロサービス間で非同期に作業を引き渡す場合、同期リクエストからバックグラウンドジョブを呼び出す場合、SQS／SNS／Kinesis によってトリガーされる Lambda 関数などです。DSM がモニタリングしない Redis ベースのジョブキュー（Sidekiq、Redis 上の Celery、RQ）には適していません。

デプロイ／プラットフォーム → インフラストラクチャ／サーバーレス（基本）

シグナル	検出の手がかり	製品
Docker	Dockerfile、docker-compose.yml	Infrastructure Monitoring＋Container Monitoring（＋エージェント経由の Logs/APM）
Kubernetes（EKS/GKE/AKS）	kind: Deployment、Chart.yaml、k8s/	Infra＋Container＋Logs＋APM；USM は状況に応じて
AWS ECS／Fargate	task-definition.json、launchType	Infra＋Container＋APM＋Logs（エージェントのサイドカー）
AWS Lambda	serverless.yml、template.yaml（SAM）、cdk.json、AWS::Lambda::Function	Serverless Monitoring（＋APM、拡張メトリクス、ログ）
Vercel	vercel.json、.vercel/	Serverless Monitoring（Vercel インテグレーション）
GCP Cloud Run	Cloud Run の service.yaml、gcloud run	Serverless Monitoring（サーバーレス／サイドカーエージェント）
Azure App Service／Functions	host.json、function.json、*.azurewebsites	Serverless Monitoring（拡張機能／互換レイヤー）
ベア VM／ホスト	Dockerfile／k8s なし；systemd、cloud-init、Ansible	Infrastructure Monitoring＋Logs＋APM（ホストエージェント）

クラウドプロバイダー → インテグレーション（基本）；CCM＋CSM（状況に応じて）

AWS（boto3、~/.aws、provider "aws"） · GCP（google-cloud-*、provider "google"） · Azure（azure-*、provider "azurerm"）。クラウドのインテグレーション（メトリクス／ログ／インベントリ）は基本です。 Cloud Cost Management と Cloud Security Management（CSPM/CIEM） は状況に応じて推奨します（コスト／セキュリティに関するニーズがある場合）。

IaC → IaC セキュリティ／コードセキュリティ（状況に応じて、セキュリティ要件あり）

公式にスキャンされるのは、Terraform（*.tf）、CloudFormation（AWS:: を含む template.yaml）、Kubernetes マニフェスト、Helm（K8s にレンダリングされるもの）です。CDK/Pulumi は CFN/TF に合成されるため、合成後の出力をスキャンします。

CI プロバイダー → CI Visibility（状況に応じて）

GitHub Actions（.github/workflows/） · GitLab CI（.gitlab-ci.yml） · Jenkins（Jenkinsfile） · CircleCI（.circleci/） · Buildkite · Azure Pipelines。クラウド CI では Agentless モードを使用します。

テストフレームワーク → Test Optimization（状況に応じて）

pytest · jest（jest-circus） · mocha · vitest · junit/testng/spock · playwright（RUM にリンク） · cypress（手動計装のみ） · rspec/minitest · go test（Orchestrion 経由） · .NET xUnit/NUnit/MSTest · Swift XCTest。

LLM／AI ライブラリ → LLM Observability（LLM アプリの基盤となる、主要なプロダクト）

自動計装の対応状況（特記がない限り Python）：

ライブラリ	自動サポート	検出のヒント
anthropic	Python ✅、Node ✅	anthropic、@anthropic-ai/sdk
openai	Python ✅、Node ✅、Java ✅	openai
langchain	Python ✅、Node ✅	langchain、@langchain/*
langgraph	Python ✅	langgraph
vercel-ai	Node ✅	ai + @ai-sdk/*
amazon-bedrock	Python ✅、Node ✅	bedrock-runtime、@aws-sdk/client-bedrock-runtime
vertexai / google-genai	Python ✅、Node ✅	vertexai、google-genai、@google/genai
crewai / openai-agents / litellm / pydantic-ai / google-adk / mcp	Python ✅	それぞれのパッケージ名
llamaindex	✗ 自動では非対応（手動 SDK／OTel）	llama-index、llamaindex

自動サポート対象には、Claude Agent SDK、Strands Agents、vLLM も含まれます（Python）。

ネットワーク → NDM と CNM（状況に応じて）

• SNMP／物理または仮想ネットワークデバイス（ルーター、スイッチ、ファイアウォール） → Network Device Monitoring。ヒント：snmp.d/conf.yaml、デバイス IP／OID、community_string、NetFlow の設定。
• サービスメッシュ／Istio／Envoy → Cloud Network Monitoring（+ USM）。ヒント：istio-proxy サイドカー、VirtualService／DestinationRule CRD、envoy.yaml。（これは CNM であり、NDM ではありません。）

既存の Datadog → 追加提案は控え、不足分のみを推奨

シグナル	すでに設定済み	代わりに推奨するもの
datadog.yaml / datadog-values.yaml	Agent がインストール済み	無効になっているサブ機能（logs_enabled: false → Logs）
dd-trace/ddtrace/datadog トレーサー依存関係	APM が導入済み	関連する不足分：Profiler、DBM、AAP
DD_* 環境変数	統合タグ付け／一部の設定	不足している変数（DD_SERVICE は設定済みで、DD_PROFILING_ENABLED は未設定 → Profiler）
@datadog/browser-rum*	ブラウザー RUM が稼働中	Source Map Uploads、Session Replay のレート、Error Tracking
@datadog/mobile-*、dd-sdk-android*	Real User Monitoring（RUM）が稼働中	Error Tracking + シンボルのアップロード
ddtrace[llmobs]、DD_LLMOBS_ENABLED	LLM Obs が稼働中	フレームワークとのインテグレーションが記録されているか確認

基盤のベースライン（ユースケースに合わせて調整する前の土台）

コードベースに含まれるもの	常に推奨するもの
任意のバックエンドサービス	APM + Log Management + Continuous Profiler（Rust／C／C++ は除く — トレーシングは Preview／手動）
任意の Web フロントエンド	RUM + Error Tracking + Session Replay、バンドルされている場合は Source Maps（Product Analytics は明確に該当する場合のみ）
任意のモバイルアプリ	Real User Monitoring（RUM）+ Error Tracking
任意のコンテナー／Docker	Infrastructure Monitoring（+ Container Monitoring）
任意の Kubernetes	Infrastructure + Container + Logs + APM
任意のサーバーレス関数	Serverless Monitoring
任意の LLM／AI アプリ	主要なプロダクトとしての LLM Observability（+ APM + Logs）
任意のクラウドアカウント	該当する クラウドインテグレーション

基盤 ≠ 主要なプロダクト。これらは前提となる土台です。ユーザーが目標を示した場合は、Use Case セクションにある差別化要因 — その意図に対して決定的な（または強力な）差別化をもたらすプロダクト — が十分に裏付けられている場合はそれを先頭にし、その下に基盤を示してください。十分に裏付けられた差別化要因がない場合は、基盤を先頭にするのが正しい回答です。見せかけの主要プロダクトを作り上げて、基盤を押しのけないでください。

---

参照：ユースケース → プロダクト

このセクションでは、明示された目標またはビジネス上の意図を、それに適した Datadog プロダクトに結び付けます。 関連するセクション（上記の Stack → Products）ではコードベースをマッピングします。両方を読み、照合してください。意図が主要なプロダクトを決め、スタックによって実際に構築可能かどうかが確認できます。

Datadog のプロダクト機能と一般的な技術パターンに基づき、明示された目標と、その目標に合う機能を備えたプロダクトを組み合わせています。

汎用的なリストより優れたものにする、ただ一つの原則

基盤は前提です。差別化要素を先に示しましょう。

• ほぼすべてのバックエンドサービスに当てはまる製品がいくつかあります。インフラストラクチャ監視、ログ管理、APMなどです。これらは基盤であり、ほとんどどの回答でも前提となる基本要素です。これらを見出しとして提示するのは、技術的には正しいものの、役に立ちません。
• 差別化要素は、特定の意図に応じて選ばれます。汎用的な回答では見落とされる差別化要素を見つけて提示することこそ、このマップの価値です。
• そのため、基盤は簡潔に下位に示し、ユーザーの意図を特徴づける製品を先頭に置きます。ただし、それを十分に裏付けられる場合に限ります。

ガードレール（推奨する前にお読みください）

1. 大きさではなく、ランク／ティアを示します。「定義的／強い／弱い、またはなし」で出力し、倍率は決して使いません。
2. すべての意図→製品の対応関係は、製品の機能に基づいて説明できなければなりません。その意図に役立つ理由を説明できない場合は、先頭に置かないでください。
3. 機能を基準とし、スタックの証拠を優先します。 機能から見て明らかな候補を除外してはいけません。以下のティアは順序付けの参考であり、採用の可否を決めるものではありません。
4. 存在しないことは証拠ではありません。 このマップが示すのは特徴的な適合例であり、網羅的なランキングではありません。あるテーマに製品が載っていないからといって、それを選ばない理由にはなりません。
5. 確信度は大まかに、「確立済み／新興／逸話的」のみとします。これは安定性の判断であり、件数ではありません。
6. 数字、名前、引用は一切使いません。
7. 基盤は前提とします。差別化要素を十分に裏付けられる場合はそれを先頭に置き、そうでなければ基盤を先頭に置くのが適切です。候補は絞り込みます（最大3製品）。該当するものがほとんどない、またはまったくない場合は、0～1製品でもかまいません。

先頭に置く際のルール（以下のすべてに適用されます。読み飛ばさないでください）

確信度とティアを合わせて、見出しにできるものを決めます。 先頭に置くものを挙げる前に、次のルールを適用してください。

• 定義的＋確立済み（または機能から見て明らか）→ 先頭に置いてもかまいません。 これが見出しになります。
• 新興 → 補足としてのみ追加できます。 含めてもかまいませんが、推奨の軸にはしないでください。
• 逸話的 → 明示的に一致する場合のみです。 ユーザーの表現がそれに明確に一致する場合に限って触れ、決して見出しにはしないでください。
• 弱い、またはなし → 基盤またはノイズです。下位に挙げ、決して先頭には置きません。

基準を満たす軸となる候補がない場合、基盤を先頭に置くのが適切で誠実な回答です。枠を埋めるために、差別化された見出しを無理に作らないでください。

シャープシグナルのアンカー — 意図が一致し、コードが裏付けている場合に主軸にする

これらは、最も特徴的な意図→製品のシグナルです。アンカーを見出しとして提示するのは、次の両方を満たす場合に限ります。（1）ユーザーの表現が一致し、ティア／確信度が上記の主軸ルールを満たしていること、かつ（2）コードベースが実際に裏付けていること、つまり関連する SDK／IaC／ライブラリ／設定が存在することです。表現だけでは不十分です。クラウド／IaC の要素がないリポジトリでのセキュリティやコストの目標、または LLM ライブラリがない場合の LLM の目標を、クラウド／LLM のアンカーを主軸にして提示してはいけません。

ユーザーの表現における意図のシグナル	アンカー製品	ティア	確信度
AI / LLM / GenAI / プロンプト / エージェント / トークン	LLM Observability	定義的	確立済み
セキュリティ / SIEM / 脅威検出 / コンプライアンス	Cloud SIEM	定義的	確立済み
クラウドのポスチャー / 設定ミス / CSPM / DevSecOps	Cloud Security Management	定義的	確立済み
ネットワークデバイス / SNMP / スイッチ / ルーター / NetFlow	Network Device Monitoring	定義的	確立済み
コード / サプライチェーン / SAST / SCA / 脆弱性	Code Security	強力	確立済み
ランタイム脅威 / ワークロード / コンテナーセキュリティ	Workload Protection	強力	新興
クラウドコスト / 支出 / 請求 / FinOps	Cloud Cost Management	定義的	新興
顧客向け / フロントエンド / UX / ウェブバイタル	Real User Monitoring	定義的	確立済み
クエリの遅さ / データベース / クエリパフォーマンス	Database Monitoring	定義的	確立済み
AWS ネイティブ / CloudWatch / サーバーレス / Lambda / ECS	Serverless Monitoring	定義的	確立済み

ユーザーの表現がセキュリティ関連で、かつコードベースに対応可能なクラウド／ログの要素がある場合は、セキュリティ製品群へ明確に切り替えます。Cloud SIEM + Cloud Security Management を主軸にし、具体的なシグナルに応じて Code Security / App & API Protection / Workload Protection を加えます。コードにクラウド SDK／IaC／一元化されたログの要素がない場合は、SIEM/CSPM を主軸にしてはいけません。裏付けのあるコードレベルのセキュリティ製品を主軸にします（SAST/SCA には Code Security、公開 API には App & API Protection）。SIEM/CSPM は条件付きの追加候補としてのみ提示します。

対応する技術スタックがない場合の意図（ミスマッチルール）

意図マップが見出しの候補を設定し、技術スタックによって実際に構築可能なものが確定します。目標が、コードベースで裏付けられないアンカーを指す場合、そのアンカーを主軸にしてはいけません。

• 完全に欠如している → ギャップを示し、裏付けのあるものを主軸にします。
• ユーザーがリポジトリ外のリソースを提示している → 条件付きとし、主軸にも「検出済み」にもしません。 「AWS の請求」や「LLM サービス」を明示している目標は、コードベースの証拠ではありません。アンカーは中／低の条件付きとして提示します。確信度を高にしてはいけません。また、検出済みの技術スタックとして記述してはいけません。
• 一部のみ対応 → 製品ごとに範囲を定めます。 裏付けのあるサブ製品を推奨し、裏付けのない関連製品は明示的に対象外とします。

意図 → テーマ別の製品

ユーザーが示した目標／課題をテーマに照らし合わせ、アンカー製品と補完製品を推奨します。基盤（Infra / Logs / APM）はこれらすべてに共通して想定されるため、簡潔に触れますが、主軸にはしません。

セキュリティ · SIEM · コンプライアンス — 確信度：確立済み

• トリガー：セキュリティ、SIEM、脅威検出、コンプライアンス、SOC 2、FedRAMP、HIPAA、PCI、監査、脆弱性、ポスチャー、設定ミス、DevSecOps、PII。
• 主軸（コードにクラウド／ログの要素がある場合のみ）：Cloud SIEM + Cloud Security Management。クラウド SDK／IaC／一元化されたロギングがないリポジトリでは、代わりに Code Security + App & API Protection を主軸にし、SIEM/CSPM は条件付きの追加候補として提示します。
• 強力な追加候補：Workload Protection · Sensitive Data Scanner。
• 基盤：Log Management、さらに Infra + APM で補完します。 AI／LLM オブザーバビリティ — 信頼度：確立済み
• トリガー：LLM、GenAI、AI アプリ、チャットボット、エージェント、RAG、プロンプト、トークン使用量、モデルのレイテンシ／コスト、またはスタック内の LLM クライアントライブラリ。
• 中核（定義的）：LLM Observability。
• 有力な追加候補：APM ＋ Log Management。
• 独立したシグナルがない限り、RUM／DBM／Source Maps は追加しないでください。

ネットワーク — 信頼度：確立済み

• トリガー（デバイス）：SNMP、ルーター、スイッチ、ファイアウォール、NetFlow → 中核：Network Device Monitoring。
• トリガー（トラフィック）：サービス間の接続性、メッシュ、Istio／Envoy → 有力候補：Cloud Network Monitoring。
• 基盤：Infra ＋ Logs。

クラウドコスト／FinOps — 信頼度：新興

• トリガー：クラウド支出の削減、コストの可視化、コスト配賦、FinOps、「請求額が高すぎる」。
• クラウドインフラ／IaC が検出された場合に限り、Cloud Cost Management を中核として提示します。クラウド SDK も IaC もないリポジトリでは、CCM は条件付きの追加候補として挙げ、基盤を中核として提示します。
• 有力な追加候補：Infrastructure Monitoring（使用率に基づく適正規模化）。

デジタルエクスペリエンス · フロントエンド · 顧客向け — 信頼度：確立済み

• トリガー：エンドユーザーエクスペリエンス、フロントエンドのパフォーマンス、UX、ウェブバイタル、コンバージョン、セッション、 「顧客から苦情が出ている」。
• 中核（定義的）：Real User Monitoring ＋ Session Replay。
• 有力な追加候補：Error Tracking · Product Analytics（新興）· Synthetics · JS がバンドルされている 場合は Source Maps。
• 基盤：APM ＋ Logs。

クラウド移行（Azure／ハイブリッド／オンプレミス→クラウド） — 信頼度：確立済み

• 単独で定義的な中核はありません。有力な追加候補：Network Device Monitoring · Cloud Cost Management · Cloud Network Monitoring · Synthetics · On-Call。
• 基盤：対応するクラウドインテグレーション ＋ Infra ＋ Logs ＋ APM。

AWS ネイティブ／サーバーレス／ECS · CloudWatch の置き換え — 信頼度：確立済み

• トリガー：cloudwatch／lambda／ecs／fargate に関する表現、CloudWatch の置き換え。
• 中核（定義的）：Serverless Monitoring。
• 有力な追加候補：Custom Metrics · Cloud Cost Management。
• 基盤：AWS インテグレーション ＋ APM ＋ Logs。

インシデント対応／MTTR — 信頼度：新興

• トリガー：MTTR、MTTD、ダウンタイムの削減、オンコール、ページング、アラート疲れ、迅速な解決。
• 定義的な中核はありません。有力な追加候補：Incident Management · On-Call · Error Tracking。
• APM はここで実質的な役割を果たします（根本原因を追跡するトレース）。単なるベースラインではなく、実際に役立つ機能として挙げてください。

ツールの集約／プラットフォームの統合 — 信頼度：確立済み

• トリガー：集約、「単一の画面」、ツールの断片化、ツールが多すぎる、モニタリングの統合。
• 中核はありません。幅広さが重視される領域です。基盤 ＋ 幅広い候補：CI Visibility、Continuous Profiler、 LLM Observability、Universal Service Monitoring、Data Observability。

データベース／クエリのパフォーマンス — 信頼度：確立済み

• トリガー：遅いクエリ、データベースのパフォーマンス、クエリのレイテンシ、実行計画、エンジンのパフォーマンス。
• 中核（定義的）：Database Monitoring。
• 有力な追加候補：APM — DB スパンによって、各クエリを呼び出し元のサービスに関連付けられます。

グリーンフィールド／新規ローンチ — 信頼度：新興

• トリガー：新製品、ローンチ、グリーンフィールド、MVP、「ユーザーが使い始める前に」。
• 定義的な中核はありません。有力な追加候補：Synthetics · RUM。
• 逸話的（明示的に一致する場合のみ）：Product Analytics。
• 基盤：APM ＋ Logs ＋ Infra。

インフラ／Kubernetes のパフォーマンス — 信頼度：確立済み（均一／すべて基盤）

• トリガー：インフラのパフォーマンス、リソース使用率、キャパシティ、k8s の健全性。
• 特別な差別化要素はありません。Infrastructure Monitoring を中核とし、該当するシグナルがある場合は Cloud Network Monitoring と Database Monitoring を控えめに追加します。 アラート／「知りたい」／通知 — 意図ベース
• トリガー：「知りたい」「〜したらアラートして」「通知して」「〜したらページングして」「X が起きたことを検知して」。
• 機能を先頭に提示します：Monitors & Alerting — 「知りたい」への直接的な答えです。
• 追加：Error Tracking + Log Management。「単一画面」なら Dashboards、「SLO」なら SLOs。

フルスタック／フロントエンド↔バックエンドの相関付け — 確立度：高い（大部分が基盤）

• トリガー：フロントエンドとバックエンドの相関付け、エンドツーエンドの可視性、分散トレーシング。
• 構成を先頭に提示します：APM + RUM + Log Management に、Error Tracking と Incident Management を加えます。これは十分に構成された基盤です。差別化要素を作り出すのではなく、そのように伝えてください。

意図の表現 → 製品（アイデンティティに依存しない手がかり）

• 「セキュリティログ／SIEM が導入されておらず、コンプライアンス基準への準拠が必要」 → Cloud SIEM（より厳格な要件には Workload Protection も追加）。
• 「多数の外部 API を管理しており、監査に備えて API セキュリティの強化が必要」 → Code Security + App & API Protection。
• 「コンテナレベルの可視性が不足しており、セキュリティ態勢を強化したい」 → Cloud Security Management。
• 「最近クラウドプロバイダーに移行し、新しい環境の可視性が不足している」 → Network Device Monitoring + Cloud Cost Management + Cloud Network Monitoring。
• 「CloudWatch を利用しているが理想的ではなく、サーバーレススタック全体でツールが分断されている」 → Serverless Monitoring（+ Custom Metrics、Cloud Cost Management）。
• 「エンドユーザーの行動を把握できておらず、ユーザーセッションを確認して問題箇所を特定したい」 → RUM + Session Replay + Product Analytics。
• 「監視がサイロ化して検知／解決に時間がかかり、フロントエンドからバックエンドまでの可視性がない」 → RUM + APM + Incident Management。
• 「監視ツールの寄せ集めを統合して、コストと運用負荷を削減したい」 → 統合のアプローチ（基盤 + ニッチな領域）。
• 「LLM／AI アプリケーションのオブザーバビリティを確保したい」 → LLM Observability（+ APM + Logs）。
• 「稼働時間と主要なユーザーフロー／コアウェブバイタルをプロアクティブに監視したい」 → Synthetics + RUM。

---

参考：製品カタログ

これは、推奨で使用する統制語彙です。製品名は必ず正式名称の列に記載された名前を使用してください。ユーザーやコードベースが別の名前で製品を指している場合は、別名を使って該当製品を特定してください。

一般性は、主流かニッチかを大まかに示すものであり、ランキングの重みでも適合度のスコアでもありません。ニッチな製品がまさに適切な選択肢となることもあります。主流の製品だからという理由だけで、自動的に推奨してはいけません。一般性は、一致をどの程度確信を持って推測できるかを判断するためだけに使い、推奨の順序付けや重み付けには使用しないでください。

• 主流 — 広く採用されており、明確に合致する場合は安心して推奨できます。
• ニッチ — あまり見かけない製品です。明示的で曖昧さのない一致がある場合にのみ推奨し、推測で推奨してはいけません。

カテゴリ別の推奨可能な製品

コアオブザーバビリティ（基盤）

正式名称	一般性	別名／表示される名称
Infrastructure Monitoring	主流	Infra、ホスト監視、コンテナ監視、サーバー監視、Orchestrator Explorer
Log Management	主流	Logs、ロギング、ログ分析、ログの取り込み／インデックス化、Flex Logs、Observability Pipelines
APM	主流	Application Performance Monitoring、分散トレーシング、トレーシング、トレース、スパン、ddtrace/dd-trace
Continuous Profiler	ニッチ	プロファイラー、プロファイリング、コードプロファイリング、フレームグラフ、DD_PROFILING_ENABLED
デジタルエクスペリエンス（フロントエンド／モバイル／エンドユーザー）
正式名称	一般性	別名／表示される名称
---	---	---
Real User Monitoring（RUM）	主流	RUM、ブラウザーモニタリング、フロントエンド／クライアントサイドモニタリング、モバイル RUM、@datadog/browser-rum
Session Replay	RUM のアドオン	セッションリプレイ、リプレイ。RUM SDK の機能
Error Tracking	ニッチ	エラーのグループ化、例外トラッキング、クラッシュレポート（モバイル）
Product Analytics	ニッチ	PA、ファネル、リテンション分析、ユーザー行動分析、実験
Synthetic Monitoring	主流	Synthetics、合成テスト、API テスト、ブラウザーテスト、稼働時間チェック、複数ステップの API テスト
Source Map Uploads	RUM／ET の有効化に必要	ソースマップ、ソースマップ、シンボリケーション（JS が圧縮／バンドルされている場合に必要）

データレイヤー

正式名称	一般性	別名／表示される名称
Database Monitoring（DBM）	主流	クエリモニタリング、低速クエリ、実行計画、クエリパフォーマンス、Postgres／MySQL／SQL Server／Oracle／Mongo のモニタリング
Data Streams Monitoring（DSM）	ニッチ	Kafka／RabbitMQ／SQS／SNS／Kinesis／Pub/Sub のモニタリング、キューの遅延、コンシューマーの遅延、パイプラインのレイテンシ、ストリーミングモニタリング、イベント駆動型アーキテクチャ
Data Observability	ニッチ	Data Jobs Monitoring（DJM）、Spark／Databricks のモニタリング、データ品質モニタリング

ネットワーク

正式名称	一般性	別名／表示される名称
Network Device Monitoring（NDM）	主流	SNMP モニタリング、NetFlow、スイッチ／ルーター／ファイアウォールのモニタリング、ネットワークデバイス、Network Path
Cloud Network Monitoring（CNM）	主流	NPM、Network Performance Monitoring、ネットワークフロー、サービス間トラフィック、サービスメッシュトラフィック
Universal Service Monitoring（USM）	ニッチ	コード不要のサービスモニタリング、eBPF サービスマップ、即時のサービスカタログテレメトリー

クラウドとコスト

正式名称	一般性	別名／表示される名称
Serverless Monitoring	主流	Lambda モニタリング、Fargate タスク、サーバーレス関数／アプリ、FaaS、Cloud Run／Azure Functions のモニタリング
Cloud Cost Management（CCM）	主流	コストモニタリング、クラウド支出、コスト最適化、FinOps、Cloudcraft、コスト配分

セキュリティ

正式名称	一般性	別名／表示される名称
Cloud SIEM	主流	SIEM、セキュリティモニタリング、脅威検出、セキュリティログ、セキュリティ分析
Cloud Security Management（CSM）	主流	CSPM、Cloud Security Posture Management、CIEM、設定ミス、DevSecOps、セキュリティ態勢管理
Workload Protection	ニッチ	CWS、Cloud Workload Security、ランタイム脅威検出、コンテナランタイムセキュリティ
App and API Protection（AAP）	ニッチ	ASM、Application Security Management、WAF、RASP、API セキュリティ、アプリケーション層の脅威対策
Code Security	主流	SAST、IAST、SCA、シークレットスキャン、IaC セキュリティ、サプライチェーンセキュリティ、アプリケーションセキュリティテスト
Sensitive Data Scanner（SDS）	ニッチ	SDS、PII スキャン、データの編集、機密データの検出

ソフトウェアデリバリー

正式名称	一般性	別名／表示される名称
CI Visibility	ニッチ	CI/CD Visibility、Pipeline Visibility、CI パイプラインモニタリング
Test Optimization	ニッチ	Test Visibility、不安定なテストの検出、テスト分析、Test Impact Analysis

LLM／AI

正式名称	一般性	別名／表示される名称
LLM Observability	ニッチ	LLM Obs、LLMObs、AI／GenAI オブザーバビリティ、プロンプト／モデルのモニタリング、トークンとコストの追跡
サービス管理
正式名称	一般性	別名／表示される名称
---	---	---
インシデント管理	ニッチ	IM、インシデント対応、事後検証、エンタープライズインシデント対応
オンコール	ニッチ	ページング、オンコールスケジュール、アラートエスカレーション
ワークフロー自動化	ニッチ	ワークフロー、ランブック自動化、自動修復
イベント管理	ニッチ	イベント相関、アラート相関、イベントパイプライン

その他（ニッチ — 明示的に一致する場合のみ）

正式名称	一般性	別名／表示される名称
カスタムメトリクス	ニッチ	カスタムメトリクス／イベント、DogStatsD メトリクス、MetricsWithoutLimits
GPU モニタリング	ニッチ	NVIDIA／GPU メトリクス
IoT モニタリング	ニッチ	デバイス／エッジのモニタリング
機能フラグ	ニッチ	機能フラグ管理、機能トグル
アプリビルダー	ニッチ	ローコードの社内アプリ
Bits AI	ニッチ	AI SRE、AI によるインシデント調査
CoScreen	ニッチ	共同画面共有、ペアデバッグ

プラットフォーム機能（モニターとアラート／ダッシュボード／SLO — 意図に応じて推奨） これらは Datadog プラットフォーム全体で利用できる中核的な機能です。意図に応じて推奨してください。

機能	目標が次の場合に推奨…
モニターとアラート	「いつ発生したかを知る」「アラートしてほしい」「通知してほしい」「ページングで知らせてほしい」「X が発生したときに検知する」
ダッシュボード	「すべてをひとつの画面で確認する」「単一の統合ビュー」「可視化する」「ダッシュボードを作成する」
SLO	「SLA／SLO を追跡する」「エラーバジェット」「信頼性目標」「稼働時間の保証」

推奨してはいけないもの（サービス／導入支援／SKU／価格関連の名称）

以下はプロフェッショナルサービス／導入支援／トレーニング／イベントであり、Datadog 製品ではありません。

• **（サービス／製品以外）**の分類：DASH Tickets、Implementation Services（すべてのパッケージ）、 Premium Enablement、TEM Bootcamp。
• ルール： 名前に Bootcamp、Enablement、Implementation Services、 Tickets、Training、Onboarding Services、または Support Package が含まれる項目は、推奨対象外として扱ってください。
• また、内部 SKU 名／価格帯名、および Deprecated – ／ Legacy – が先頭に付く項目も提示しないでください。常に正式な製品名を推奨してください。