dt-platform-costs

dt-platform-costs

⛔ 最初に — ほかのことをする前に、対象範囲を確認してください。 このスキルは、テナントの実際の消費データのクエリと分析のみを行います。課金の概念について説明するものではありません。ユーザーが、課金や料金の仕組み、コストの計算方法、単位／正規化ウェイト／料金表の意味、または DPS の課金に関する概念的な「説明」を求めている場合、このスキルでは回答できません。課金の概念 — 停止を参照し、指定された2文のドキュメントへの案内のみを回答してください。単位、ウェイト、含まれる使用量、方法論について説明してはならず、「はじめに」メニューも表示しないでください。ユーザーが自身のテナントの数値のクエリまたは分析を希望している場合に限り、このスキルの残りの手順に進んでください。

DQL を使用して、Dynatrace プラットフォームの課金データとコストデータをクエリおよび分析します。すべてのデータは dt.system.events にあり、event.kind == "BILLING_USAGE_EVENT" で絞り込み、event.type（消費カテゴリ）で分類されています。

対象範囲の境界：このスキルが対象とするのは、Dynatrace のプラットフォーム課金（DPS 消費）です。FOCUS 経由で取り込まれた AWS クラウドのインフラストラクチャコストには、代わりに dt-biz-cloud-costs を使用してください。

Dynatrace Platform Subscription（DPS）

このスキルは、DPS ライセンス環境のみを対象とします。すべての課金イベントタイプ、単位換算、公開料金表、コスト見積もりのワークフローは、DPS 固有のものです。

このスキルの単位換算やコスト見積もりを、従来のライセンスモデル（ホストユニット、DDU、DEM ユニット、ASU）に適用してはなりません。ユーザーが従来のライセンスに関する用語や単位に言及した場合、このスキルは DPS のみを対象としていることを説明し、詳細について https://docs.dynatrace.com/docs/license/monitoring-consumption-classic を案内してください。

ライセンス／利用権に関する質問 — 停止

該当する質問：「X を使用する権利はありますか？」「X はライセンス対象ですか？」「X はサブスクリプションに含まれていますか？」「X の利用権はありますか？」

停止 — DQL クエリを実行してはなりません。課金使用量イベントに記録されるのは現在の消費量のみであり、サブスクリプションの利用権ではありません。課金イベントがない場合、現在消費していないことを意味するだけであり、ライセンスがないことを意味するわけではありません。使用パターンやその不在から、利用権を推測してはなりません。クエリを実行せず、直接回答し、Account Management > Subscription > Pricingを案内してください。

❌ 課金イベントをクエリ → 結果なし → 「ライセンスがありません」と結論付ける — 誤り（利用状況がない ≠ 利用権がない） ✅ すぐに回答：「利用権のデータは DQL では確認できません。Account Management > Subscription > Pricing をご確認ください。」

課金の概念 — 停止

該当する質問：「課金の仕組みはどうなっていますか？」「コストはどのように計算されますか？」「DPS 課金について説明してください」「X の課金方法は？」「課金モデルとは何ですか？」「DPS の料金体系はどうなっていますか？」「Dynatrace の料金体系はどうなっていますか？」「料金表について説明してください」

**停止 — このスキルの内容を使って回答してはなりません。**このスキルに記載されている正規化ウェイト、単位換算式、参照値は、DQL 生成のためのツールであり、ユーザー向けの課金説明ではありません。これらを DPS 課金の説明として提示するのは誤りです。これらは内部的な順位付けの補助情報であり、契約上の料金ではありません。

**回答全体は、以下の2文のみとしてください。それ以外は一切含めないでください。**機能や単位を列挙したり、計測方法、含まれる使用量、正規化について説明したり、「コストの計算方法」というセクションを追加したり、「はじめに」メニューや、表示されている1つの例を超えるプロンプト例の一覧を付け加えたりしてはなりません。

❌ 計測方法／単位／正規化ウェイトを説明してから、「はじめに」メニューを提示する — 誤り（まさに避けるべき対応です） ✅ 次の内容のみで回答してください：「DPS の料金体系と課金の仕組みについては、Dynatrace Platform Subscription のドキュメントをご覧ください。テナントの実際の消費量を分析したい場合は、たとえば 『過去7日間の主なコスト要因は何ですか？』 とお尋ねください。」

このスキルを使用する場面

• 使用状況の概要 — 機能別の DPS 消費量の内訳、単位換算、機能間の比較
• コストの見積もり — コストで正規化した使用量の比較と相対的な支出の順位付け、日別のコスト傾向、支出の急増
• コストの調査 — コスト要因の段階的な掘り下げ、クエリのスキャンコストの帰属、ワークフローの総コスト（4 つのシグナル）
• チャージバック／ショーバック — コストセンターと製品への帰属、チームレベルの請求
• 含まれる使用量 — Metrics/Traces Ingest のベースライン控除、請求対象の使用量と合計使用量

このスキルは、既存の消費データをクエリして分析します。DPS の料金ガイドではありません。請求に関する概念については、 公式ドキュメントを参照してください。

エージェントへの指示

意図のマッピング

ユーザーのリクエスト	アクション	参照
"どのように役立ちますか", "何ができますか", "何から始めればよいですか", "コストを理解したい", "何を分析できますか", "できることを見せて", "このスキルとは何ですか", "ヘルプ", "機能", "利用を開始する", "できることを教えて", "どんな機能がありますか"	利用開始メニューを提示します。5 つのユースケースと、それぞれに推奨プロンプトを 1 つ示します。まだクエリを実行しないでください。	利用を開始する
"X の使用は許可されていますか", "X にはライセンスがありますか", "X はサブスクリプションに含まれていますか", "X の利用資格", "ライセンス上、X を使用できますか"	停止 — クエリを実行しないでください。 DQL では利用資格データを取得できないことを直接回答します。Account Management > Subscription > Pricing へ案内します。	利用資格 — 停止
"請求はどのように行われますか", "コストはどのように計算されますか", "DPS の請求について説明して", "X はどのように請求されますか", "請求モデルとは何ですか", "DPS の料金体系について教えて", "Dynatrace の料金はどのように請求されますか", "レートカードについて説明して"	停止 — スキルの内容に基づいて回答しないでください。 公式ドキュメントを案内するよう直接回答します。	請求の概念 — 停止
"使用状況の概要", "機能別の使用状況", "何を使用していますか", "使用量はどのくらいですか"	単位換算を含む機能横断の使用状況（コストなし）	billing-capabilities.md -> Cross-Capability Usage (4 Queries)
"コスト要因", "最もコストがかかるもの", "支出上位", "支出先はどこですか"	統合クエリとインライン検索の全件実行を行い、DQL で cost_weight desc により並べ替えます	cost-estimations.md -> Estimated Cost by Capability
"コストを節約", "コストを削減", "請求対象のコスト", "実際の請求額"	含有量を差し引いた使用量を確認してから、コストを推定します	billing-capabilities.md -> Cross-Capability Usage (4 Queries)、次に cost-estimations.md
"チーム別コスト", "チャージバック", "ショーバック"	コストセンターへの割り当て	cost-allocation.md
"コストセンター別のメトリクス取り込み", "メトリクスのチャージバック", "チーム別の請求対象データポイント"	コストセンター別のメトリクス取り込み請求対象量（含有量を差し引きます）	cost-allocation.md -> Metrics Ingest — Billable Volume per Cost Center
"ログ取り込み量はどのくらいですか", "トレース量"（単一カテゴリー）	単一カテゴリーの使用状況クエリ	billing-event-types.md、billing-capabilities.md
"コストの推移", "支出の急増", "予算予測"	日次コストの推移	cost-estimations.md -> Daily Cost Trend
"今週と先週を比較", "週ごとの比較", "WoW", "MoM", "月ごとの比較", "コストはどう変化しましたか", "先週と比べたコストの変化", "先月と比べたコストの変化", "期間比較", "何が増えましたか", "何が減りましたか", "使用状況の推移", "使用状況の顕著な変化"	期間比較 — UTC で明示した 2 つの期間について、機能ごとに capability_usage を比較し、コストウェイトの変化幅の絶対値が大きい順に並べ替えます	cost-estimations.md -> Period Comparison (WoW / MoM)
"検出器のコスト", "異常検出器のクエリコスト", "ALERTING プールのコスト"	検出器とクエリのコストを相互参照します	query-cost-attribution.md
"ワークフローのコスト", "このワークフローのコストはいくらですか", "ワークフローの支出"	4 つのシグナルによるワークフローの合計コスト	workflow-total-cost.md
"どのワークフロー", "ワークフロー名", "ワークフローの所有者", "このワークフローはどれくらいの頻度で実行されますか", "ワークフローの実行頻度"	ワークフロー名と所有者、実行頻度を特定します	workflow-total-cost.md → Cross-Event Field Reference + Owner Identification + How Often Did the Workflow Run
"コストの要因", "コスト調査", "コストの急増"	コストを段階的に調査します	query-cost-attribution.md、workflow-total-cost.md、entity-cost-drilldown.md
"どのアプリ", "どのホスト", "どのモニター", "詳細分析", "アプリケーション／ホスト／クラスター別に内訳を表示"	サンプルを最初に確認する手順を含む、エンティティベースの詳細分析	entity-cost-drilldown.md
"RUM／Full-Stack／Synthetic／K8s のコスト要因"	特定の機能についてエンティティの詳細分析を行います	entity-cost-drilldown.md
"メトリクス取り込みを最適化", "データポイントを削減", "カーディナリティの高いメトリクス", "最もコストがかかるメトリクス", "メトリクスコストの最適化"	分析（ステップ 1～3）を実行し、データを提示して最適化の方法を説明した後、最適化対象の選択をユーザーに委ねます。削除または削減する特定のメトリクスを推奨することは絶対にしないでください	metrics-ingest-optimization.md
"メトリクスを削除", "取り込み対象からメトリクスを削除", "メトリクスの取り込みを停止"	OpenPipeline または OTel Collector を使用したメトリクス削除の方法	metrics-ingest-optimization.md -> Strategy 1 — Drop Metric
"カーディナリティを削減", "ディメンションを削除", "メトリクスからディメンションを削除"	OpenPipeline または OTel Collector を使用したカーディナリティ削減の方法	metrics-ingest-optimization.md -> Strategy 2 — Reduce Cardinality
"取り込み間隔を変更", "収集頻度を下げる", "スクレイプ間隔"	ソースで取り込み間隔を変更します	metrics-ingest-optimization.md -> Strategy 3 — Change Ingest Interval
"AI のコスト", "AI エージェントのコスト", "AI のコストはいくらですか", "AI の支出", "AI エージェントのコスト", "AI の直接コストと間接コスト", "AI のコストはいくらかかっていますか", "AI Units のコスト"	AI の直接コスト（AI Units／AI Function Standard Call BUEs）と AI の間接コスト（ai_generated == true のクエリ BUEs）	billing-event-types.md -> Agentic AppEngine、query-cost-attribution.md -> Step 2a
"ソース別のクエリコスト", "最もスキャンしているのは誰ですか", "アプリ別のコスト割り当て"	ソース別の BUE クエリコスト	query-cost-attribution.md -> Step 1
"コストの高いダッシュボード", "ダッシュボードのコストランキング", "コスト上位のダッシュボード"	ダッシュボードのクエリコストランキング	query-cost-attribution.md -> Step 1b + Step 2
"含有量", "請求対象と合計の比較", "基本使用量"	含有量の分析	billing-capabilities.md -> Included Volume
"時間単位の請求", "差し引き後の日次請求", "時間単位の請求対象使用量"	含有量を差し引いた時間区分ごとの使用量	billing-capabilities.md -> Query 3 (Metrics Ingest — Billable Volume) / Query 4 (Traces Ingest — Billable Volume)

使用量とコストの区別

• 「使用量」 → 単位の換算のみを行い、コストは推定しません。コスト正規化の重み（プレビューの種類については billing-event-types.md）に記載されている単位でラベル付けします。
• 「コスト」 → 単位の換算に加え、内部での並べ替えや集計のみに使用する cost_weight を DQL で計算します（完全なインライン参照を使用）。cost_weight を金額として表示してはいけません。 正規化テーブルにない種類はランキングから除外します。
• 「コスト要因」 → cost_weight（完全なインライン参照を使用して DQL で計算）で並べ替えたランキングを表示します。出力列：順位、機能名、ネイティブ単位での使用量。 表示前に cost_weight を削除します。いかなる列、ラベル、文にも含めてはいけません。
• 「コストの割合／パーセンテージ」 → 正規化された重み（機能ごとの使用量 × 正規化の重み）を使って合計に占める割合を計算します。パーセンテージの表で表示します。コストランキングルールのステップ 3 にある標準の ℹ️ 注記を使用し、追加の注意書きや注記は加えないでください。
• 「ユーザー提供の単価」 → ユーザーが契約単価（例：「ログ取り込みに $0.15/GiB」）を提示した場合、その機能にはその単価を使用し、実際の米ドル額を表示します。それ以外の機能は使用量のみを表示します（コストは表示しません）。注記：⚠️ 提供された $X/単位の単価を使用して計算しています。単価が提示されていない機能については、使用量のみが表示されます。正式な合計については、アカウント管理 > サブスクリプションを参照してください。単価を推測したり、仮定したりしてはいけません。ユーザーが明示的に提示した場合にのみ受け付けます。

ユーザーが明示的に求めた場合にのみ、コスト情報を追加してください。カテゴリー間で単位を比較することはできません。ランキングや合計の算出にはコストの正規化のみを使用します。

プレビューの種類： cost-estimations.md でプレビューとして明示されている機能のみがプレビューです。使用量がゼロだからといって、プレビューであると判断してはいけません。

コストランキングのルール

コストランキングやコスト要因（コスト要因、コスト傾向、ワークフローコスト、クエリコストの帰属、コスト調査、コスト急増）に関する意図が含まれる場合：

1. DQL で cost_weight を計算します — 基本の使用量クエリ（billing-capabilities.md のクエリ 1～4）を実行し、| summarize billable_usage の手順まで進めてから、ただちに コストランキング用の完全なインラインルックアップ を追加します。完全なインラインルックアップでは、単位変換 と コストの重み付けを一度に行います。billing-capabilities.md の単位変換ルックアップも適用 しないでください。これは重複しており、lookup を連結すると既存の lookup.* フィールドがすべて置き換わり、コスト重みの計算が壊れます。クエリの最後に | filter isNotNull(cost_weight) | sort cost_weight desc | fields event.type, capability_usage, cost_weight を追加します。正規化の重みを頭の中で掛け合わせないでください — 値の桁が大きく異なるため、計算ミスに気付けません。

2. 金額ではなくランキングを提示します — DQL の結果はすでにソートされています。cost_weight 列を削除し、順位、機能名、ネイティブ単位での使用量のみ（GiB、GiB 時間、セッション、データポイントなど、その機能で測定される単位）を提示します。コスト、重み、金額の列は含めないでください。「コスト要因の上位 5 件」に対する出力例：

   1. Log Management & Analytics - Ingest & Process  62.3 TiB
   2. Full-Stack Monitoring                           2,366,800 GiB-hours
   3. Real User Monitoring                            51.5M sessions
   4. Infrastructure Monitoring                       847,200 host-hours
   5. Metrics - Ingest & Process                      18.2B data points
   

   割合に関する質問には、合計に占める割合の表を出力します（上記の「コストの割合／パーセンテージ」を参照）。ユーザーが契約料金を提示していない限り、USD の推定額をそのまま表示しないでください。

3. 結果より前に免責事項を記載します — 複数機能の結果（機能が 2 つ以上のランキング、またはパーセンテージの表）の場合に適用されます。次の文をそのまま記載してください。言い換えたり、表現を変えたりしないでください。

   ℹ️ ランキングは相対的な支出を示します。実際の金額については、Account Management > Subscription > Overview > Cost and usage details をご覧ください。

   単一機能の結果（機能がちょうど 1 つで、機能間の比較がない場合）：正規化を伴わない通常の請求データのため、免責事項は記載しないでください。

   **例外：**ユーザー提供料金モードの場合は、単一機能の結果でも、そのモードで必要な警告を含めてください。単一機能の場合に省略するのは、上記の標準的な複数機能のランキングに関する免責事項のみです。

4. 補足的な料金表に関する注記は禁止です — 正規化の方法に言及できるのは、上記の指定された免責事項のみです。「これらの数値は公開されている DPS 料金表に基づいています」や「公開価格表に基づいています」といった文を、回答のほかの場所に追加しないでください。これは、ユーザー提供料金モードで必要な警告を省略するものではありません。

はじめに

ユーザーがコスト、使用量、またはこのスキルでできることについて一般的、あるいは自由形式の質問をした場合は、次のメニューで応答してください。まだ DQL クエリを実行しないでください — ユーザーが選択するまで待ちます。

以下の内容を確認できます：

1. コストの内訳 — 支出を左右する機能を、相対コスト順に確認します。

   「過去 7 日間のコスト要因の上位を教えてください。」

2. 使用状況の概要 — すべての機能にわたる DPS の使用状況を、ネイティブ単位で全体的に確認します。

   「すべての機能にわたるプラットフォームの使用状況を概要で教えてください。」

3. 急増の調査 — コスト急増の原因（ダッシュボード、ワークフロー、検出器）を特定します。

   「先週、ログクエリのコストが急増しました。原因となっているソースはどれですか？」

4. チャージバック／ショーバック — チーム、製品、またはコストセンター別にコストを分類します。

   「過去 30 日間のコストをコストセンター別に表示してください。」

5. メトリクスの最適化 — メトリクスの取り込みが主なコスト要因である場合は、課金対象のメトリクスキーを詳しく確認し、最もコストの高いものを削減します。

   「取り込みコストを左右しているメトリクスはどれですか？最適化を手伝ってください。」

どれがご希望の内容に近いですか？

前提条件

• Dynatrace 環境へのアクセス
• dt.system.events に対する DQL クエリ権限
• クエリを記述する前に dt-dql-essentials を読み込んでください。DQL の構文、型の処理、dt.semantic_dictionary.fields によるフィールドの特定方法が含まれています。

ナレッジベースの構成

#	リファレンス	内容
1	billing-event-types.md	課金イベントタイプのカタログ — フィールド、計測間隔、タイプ別テーブル
2	billing-capabilities.md	BUE と機能のマッピング、単位変換、カテゴリ横断の使用状況クエリ、含まれる使用量の差し引き
3	cost-estimations.md	コスト正規化の重み、単位変換の参照表、コスト見積もりクエリ、ダッシュボード向けの完全なインライン参照表
4	cost-allocation.md	コストセンター／製品への割り当て、チャージバッククエリ
5	query-cost-attribution.md	クエリスキャンコストの割り当て — ソース別の BUE、検出器別の内訳（ALERTING プール）、QEE の詳細分析
6	workflow-total-cost.md	ワークフローの総コスト — 4 つの課金シグナル（クエリスキャン、AppEngine、ワークフロー時間、AI 呼び出し）
7	entity-cost-drilldown.md	エンティティベースのコスト詳細分析 — エンティティ別の RUM／Host／Synthetic／K8s／Security／Automation
8	metrics-ingest-optimization.md	メトリクスキー別のコスト詳細分析 — カーディナリティ分析、時系列データの検証、最適化対象の特定

クイックスタート

fetch dt.system.events, from: -7d
| filter event.kind == "BILLING_USAGE_EVENT"
| summarize event_count = count(), by: {event.type}
| sort event_count desc

ベストプラクティス

1. 常に最初に event.kind でフィルターしてください — 関係のないイベントのスキャンを回避できます。
2. まず 7d の時間範囲を指定してください — プラットフォームのデータ量は膨大です。
3. 課金合計には UTC の午前 0 時を明示的に境界として使用してください — billing-capabilities.md § Billing Timeframe Boundaries を参照してください。
4. 近似値に ~ を使用しないでください — ≈ または "approximately" を使用してください（単独の ~ は Markdown の取り消し線になります）。
5. 結果が空の場合 — 上記の検出クエリを実行し、利用可能なイベントタイプを確認してください。
6. count() は結果を増幅します。カウントする前に、対象ごとに 1 行であることを確認してください — QUERY_EXECUTION_EVENT（DQL ステートメントごとにアクセスしたバケットあたり 1 行）と WORKFLOW_EVENT の WORKFLOW_EXECUTION（実行ごとに約 2 行：開始＋完了）は、count() を使用すると過剰にカウントされます。DQL ステートメントの量には countDistinct(query_id) を使用してください。ワークフローの実行回数と頻度には、WORKFLOW_EXECUTION に対して countDistinct(dt.automation_engine.workflow_execution.id) を使用してください。単独の count() は使用しないでください。生の count() から「N 回実行された」と記述したり、秒／分あたりの割合を算出したりしないでください。query-cost-attribution.md § Step 3 と workflow-total-cost.md § How Often Did the Workflow Run を参照してください。
7. エンティティモデル関数を使用しないでください — entityName()（およびエンティティのメタデータを解決するために dt.entity.* フィールドを受け取る関数）は非推奨です。結果には生の dt.entity.* ID（例：HOST-1A2B3C）を表示してください。ID によるグループ化やカウント（by: {dt.entity.host}、countDistinct(dt.entity.host)）は問題ありません。ID を単なる値として使用するためです。entity-cost-drilldown.md § Entity IDs in Results を参照してください。

制限事項

• 共通の使用量フィールドはありません — イベントの種類ごとに請求単位が異なります。コストを正規化しなければ、カテゴリをまたいで合算できません。
• 正規化の重みは契約料金とは異なります — コストランキングのルールを参照してください。ランキングは相対的なものです。正式な数値については、アカウント管理をご利用ください。
• 含まれる使用量 — Metrics/Traces Ingest には、ホストのベースライン（最大約14日分）が含まれます。billing-capabilities.md § Included Volumeを参照してください。
• コストの帰属は任意です — 設定されている場合にのみ値が入力されます。Retention イベントにはエンティティ参照がないことがよくあります。
• ゼロレートのクエリ — 実行コンテキスト（ユーザー、アプリ、クエリ対象データ）に基づいて、一部のクエリがゼロレートになる場合があります。これらのクエリでは QEE レコードが生成されますが、対応する BUE は生成されません。QEE の scanned_bytes 合計と BUE の billed_bytes 合計の差は、パイプラインの問題ではなく、ゼロレートの使用量を示しています。query-cost-attribution.md § Investigating QEE↔BUE Mismatchesを参照してください。