Datadogダッシュボードの作り方｜ウィジェット選定とテンプレート変数の設計手順

Datadogのダッシュボードは、ウィジェットを置くだけなら10分で形になります。困るのはその先です。サービスが5つ10つと増えたときに画面をコピーで増やし続け、指標名の揺れとタグの不統一で誰も開かない画面が積み上がる。この記事では、レイアウト種別の選び分け、ウィジェットの割り当て基準、テンプレート変数によるサービス横断化、ゴールデンシグナル4指標の配置例、JSONとTerraformでの管理までを実装の手順で整理します。作らない判断の条件まで含めて示します。

まとめ：Datadogダッシュボード設計で先に決める4つの土台

結論から言うと、最初に決めるのは次の4点です。第一にレイアウト種別（orderedかfree）。第二に各ウィジェットの担当（推移か現在値か上位N件か）。第三にテンプレート変数の粒度（envとserviceとversionを変数にするか）。第四に設定の正をどこに置くか（画面編集かコードか）。この4点を決めずに作ると、2枚目を複製した時点で破綻します。

実務で効くのは3番目です。テンプレート変数を先に切っておけば、サービスが増えても画面は増えません。逆に変数なしで作った画面はサービスの数だけ複製され、指標を1つ足すたびに全枚数へ同じ編集を繰り返すことになります。以降の各章では、この4点をDatadog公式ドキュメントとTerraform providerのリファレンス（いずれも2026年8月時点）に沿って設定項目名まで落とします。

レイアウト種別orderedとfreeの違いと画面数を増やす前のタブ設計

ダッシュボードは以前Timeboard／Screenboardという2つの製品名で分かれていましたが、現在は1つのダッシュボードに統合され、違いはレイアウト種別として残っています。この種別名はTerraformの引数名と同じです。

orderedとfreeの使い分けとreflow_typeのautoとfixedの差

orderedは上から順にウィジェットが積まれるレイアウト、freeは座標を指定して自由に置くレイアウトです。orderedのときだけreflow_typeが効き、autoなら各ウィジェットに明示的な座標を持たせずDatadog側が詰めて配置し、fixedなら全ウィジェットに位置指定が必要になります。

障害対応で開く画面はordered＋autoにします。理由は単純で、指標を1本足したときに他ウィジェットの座標を計算し直さずに済むからです。freeが向くのは、経営report向けに体裁を固定した画面や、背景画像の上に構成図を模して並べる画面に限られます。製品全体の機能構成はDatadogとは何か？機能やメリット、導入の背景で整理しています。

1ダッシュボードに最大100タブという制限を前提にした画面分割

2026年8月時点の公式ドキュメントでは、1つのダッシュボードにタブを最大100まで置け、タブ名は100文字までとされています。画面を新規に増やす前に、まずタブで束ねられないかを検討してください。

目安はこうです。同じサービスの別レイヤ（アプリ／DB／キュー）はタブで分ける。別サービスは画面ではなくテンプレート変数で切り替える。別チームが持つ別ドメインのときだけ画面を分ける。タブで足りる分割を画面の複製で処理すると、管理対象だけが増えていきます。

チーム5件・削除後30日という運用制約から決める命名と保管方針

1つのダッシュボードに紐づけられるチームは最大5件、削除したダッシュボードは30日間保持されてから完全に削除される、と公式ドキュメントに記載があります。棚卸しで消しすぎても1か月は取り戻せる、という前提で整理を進められます。

命名は「サービス名 環境 用途」の3要素で固定します。checkout prod overviewのように並べておけば、一覧の検索で用途から引けるはずです。説明欄はMarkdownが使え、[[suggested_dashboards]]と書くと関連ダッシュボードの一覧が差し込まれます。

指標の性質から選ぶウィジェット5種と1画面に並べる数の上限目安

ウィジェットの種類はtimeseries、query value、top list、table、heat map、distribution、change、hostmap、treemap、geomap、SLO、service map、funnel、note、free text、iframeなど20種類以上あります。ただし監視画面で常用するのは5系統です。

時系列の推移はtimeseries・現在値はquery valueという割り当て

timeseriesは時間軸に沿った推移を見るための基本形で、レイテンシ、リクエスト数、CPU使用率のように「上がったか下がったか」を判断する指標に割り当てます。query valueは指定期間の集計値を数字1つで出すウィジェットです。

使い分けの基準は「その数字を見て即座に行動が決まるか」。稼働ホスト数、直近1時間のエラー件数、SLOの残りエラーバジェットは行動が決まるのでquery value。CPU使用率は推移を見ないと判断できないのでtimeseries。この線引きだけで画面上部の構成はほぼ決まります。

上位N件はtop list・多次元の比較はtableとheat mapで受ける

top listは「遅いエンドポイント上位10件」「メモリを食っているコンテナ上位5件」のように、ランキングで絞り込む用途に使います。tableは1行に複数の集計列を並べられるため、サービス別にp95レイテンシとエラー率とスループットを横に並べる比較に向きます。

heat mapは値の分布を色の濃淡で示すウィジェットで、ホスト数が数十を超えたときに真価が出ます。10台程度ならtimeseriesの重ね描きで足り、heat mapに置き換える判断は「線が多すぎて個別の線を追えなくなったとき」です。

group・note・free textで文脈を残す構成と読み手への引き継ぎ

groupウィジェットは複数のウィジェットを1つの枠に畳むためのもので、「アプリ層」「データ層」といった見出し単位でまとめます。畳んだ状態で保存できるため、初期表示を軽く保ちつつ詳細を残せます。

noteとfree textは説明文を画面内に置くウィジェットです。ここに書くべきなのは指標の説明ではなく判断基準です。「このグラフが3分続けて赤ならDBのコネクション数を確認」といった一文を置いておくと、当番が交代しても同じ手順で動けます。グラフだけの画面は、作った本人以外には読めません。

スクロールせず見える範囲を上限に置くウィジェット数の決め方と基準

1画面に並べる数の目安は「障害対応中にスクロールしないで済む範囲」です。状態を判断する指標だけを置き、原因を掘る詳細グラフは同じ画面の下部ではなく別タブへ送ります。

順序としては、まず4指標（後述のゴールデンシグナル）を上部に固定し、次にサービス固有の指標を2〜4本足して一度止める。追加したい指標が出たら、既存のどれかを外せないかを先に検討してください。この制約を運用ルールにしないと、画面は必ず縦に伸びます。

テンプレート変数によるサービス横断化と候補値48時間ルックバックの制約

テンプレート変数は、ダッシュボード上部のドロップダウンで絞り込み条件を切り替える仕組みです。1枚の画面を複数のサービス・環境で使い回すための中核で、ここの設計が画面枚数を決めます。

envとserviceとversionを変数化して1枚を全環境で使い回す設計

変数はタグのキー部分（<KEY>:<VALUE>形式のKEY）か、ログ・トレースのファセットから作れます。統合サービスタグ付けで揃えているenv、service、versionの3つを変数にするのが基本形です。

作成手順は、変数の追加を選び、推奨候補から選ぶかタグを検索し、適用するウィジェットを選択して保存します。この「適用するウィジェットを選択する」工程を飛ばすと、変数を切り替えても一部のグラフが追従しません。追加後は必ず全ウィジェットが切り替わるか確認してください。

既定値の全件指定と候補値(all)から決める初期表示の絞り込み

既定値はダッシュボードを開いたときに自動で入る値で、初期状態ではアスタリスク（全件）です。候補値の一覧も初期状態では(all)で、常に全件を指すアスタリスクを含みます。

本番環境の画面では、この既定値をenv:prodに固定します。全件のままだと開くたびにステージング環境のノイズが混ざり、クエリの対象も広がるためです。開いた瞬間に見たい状態が出ている画面と、毎回2回クリックしてから見る画面では、障害時の初動が変わります。

変数参照の$name・$name.valueという記法の違いと使う場面

ウィジェットのクエリからは$<変数名>で参照します。キーとバリューを分けて出したいときは$<変数名>.keyと$<変数名>.valueを使い、イベントのオーバーレイ指定では<TAG_KEY>:$<変数名>.valueの形で書きます。

タイトルにも変数は展開できます。グラフの見出しを$service のp95レイテンシとしておけば、切り替えたときに何を見ているかが画面上に残り、対象の取り違えを防げます。

メトリクス系の候補値が48時間以内に限られる制約と保存ビューの併用

候補値の取得期間はデータソースで異なります。公式ドキュメントによると、メトリクスとクラウドコストを元にした変数は「現在から48時間」の範囲でタグ値を集め、それ以外のソースはダッシュボードの時間枠に従います。停止して2日以上経ったホストやサービスのタグは、メトリクス由来の変数では候補に出てきません。

この挙動は、退役したサービスが一覧から自動で消える利点と、たまにしかデータを送らない対象が選べない欠点の両面を持ちます。後者に当たる場合は、ログやトレースのファセットを変数の元にするのが回避策です。よく使う組み合わせは保存ビュー（Saved views）として名前を付けて保存でき、「本番の決済サービス」のような選択状態をワンクリックで呼び戻せます。

ゴールデンシグナル4指標を1画面に並べるサービス別ダッシュボードの構成例

置く指標に迷ったら、SREのゴールデンシグナル（レイテンシ・トラフィック・エラー・サチュレーション）を骨格にします。指標そのものの定義とアラート設計はGolden Signals（4つのゴールデンシグナル）とは？SREの監視指標と実装・アラート設計で扱っているため、ここでは画面上の配置に絞ります。

レイテンシとトラフィックを上段へ横並びに置く2列構成の並べ方と根拠

上段左にレイテンシ（p50とp95、p99を1枚のtimeseriesに重ねる）、上段右にトラフィック（リクエスト数の推移）を置きます。この2つを横に並べる理由は、レイテンシの悪化が負荷起因かどうかを視線の移動だけで判断するためです。

平均値は置きません。平均レイテンシは外れ値に鈍く、数%の遅いリクエストを覆い隠します。パーセンタイルを3本重ねておけば、p99だけが跳ねている（一部の重いクエリ）のか全体が持ち上がっている（容量不足）のかを1枚で切り分けられます。

エラー率とサチュレーションを同じ時間軸に重ねて読む中段の配置の型

中段にはエラー率とサチュレーションを並べます。エラー率は件数ではなく比率で持つのが基本で、トラフィックが減った時間帯に件数だけ見て「エラーが収まった」と誤読する事故を防げます。

サチュレーションに何を置くかはアーキテクチャで変わります。コンテナならCPUスロットリング率とメモリ使用率、データベース接続を持つアプリならコネクションプールの使用率、キューを持つ構成なら滞留メッセージ数。「詰まったときに最初に振り切れる値」を1つ選び、残りは別タブへ回します。

サービス別に複製する前に共通化しておく指標名とタグの前提条件

この4指標構成を全サービスで使い回すには、前提が2つあります。1つはメトリクス名がサービス間で揃っていること。もう1つはserviceタグが全テレメトリに付いていること。どちらかが崩れていると、変数を切り替えた瞬間にグラフが空になります。

先に手を付けるのはタグ側です。APMの計装でserviceが入っていれば、トレース由来のレイテンシとエラー率は変数だけで切り替わります。逆にホストメトリクスはhost単位で入るため、サービスとホストの対応をタグで持たせない限り横断できません。画面を作る前に、この対応表を先に埋めてください。

ダッシュボードJSONの複製とTerraform管理へ切り替える判断基準

ダッシュボードは画面上の編集だけでなく、JSONとしての持ち出しとコードでの定義ができます。どちらを正とするかを決めないまま両方を使うのが、いちばん壊れる運用です。

ダッシュボードJSONのエクスポートと貼り付けによる複製の手順

画面からはJSONのエクスポート（ファイルとしてのダウンロード）、クリップボードへのコピー、そしてインポートができます。インポートはダッシュボードの内容を全て上書きする動作で、コピーしたJSONはCtrl+V（MacはCmd+V）で貼り付けられます。

複製の手順はこうです。雛形となる画面を1枚だけ丁寧に作り、JSONをコピーし、新しい画面へ貼り付けてタイトルと変数の既定値だけを変える。これならウィジェット構成に差分が出ません。プログラムから同じことをする場合のエンドポイント仕様はDatadog APIの実装手順｜2種類のキーの権限分離とモニター操作にまとめています。

datadog_dashboardで必須のtitleとlayout_typeの指定方法

Terraform providerのdatadog_dashboardリソースは、必須引数がtitleとlayout_typeの2つだけです。layout_typeにはorderedかfreeを渡します。任意引数としてwidget、template_variable、template_variable_preset、reflow_type、tags、description、notify_list、dashboard_listsが並びます。

移行するときは、画面で作った完成形のJSONを見ながらHCLへ写すのが早道です。ゼロからHCLで組み立てるとウィジェットのネスト構造で必ず時間を取られます。providerの認証設定やモニター側のコード化はTerraformでDatadogを管理する方法｜Provider設定・モニター・AWSインテグレーションで解説しています。

template_variable_presetで表示条件を固定する運用と非推奨項目

template_variable_presetは、変数の組み合わせに名前を付けて保存する引数です。画面側の保存ビューに相当する状態をコードで持てるため、「本番の決済」「ステージングの検索」といった定型の見え方をレビュー対象にできます。

権限まわりでは注意点が1つ。is_read_onlyは非推奨かつ機能しない状態で、編集権限の制御はrestricted_roles（ロールのUUIDを渡す）で行います。古い記事の設定例をそのまま写すと、読み取り専用にしたつもりの画面が誰でも編集できる状態になります。

UI編集とコード管理が競合する場面の切り分けと反映順序の決め方

コード管理へ移した画面をUIから編集すると、次のapplyで巻き戻ります。ここは運用ルールで割り切るのが確実です。切り分けの基準は「その画面が壊れたときに困る人数」。

チーム全体が障害対応で開く画面はTerraform管理にし、UI編集を禁止する。個人が調査中に作る画面はUIのまま置き、コード化しない。中間の「チームで使うが試行錯誤中」の画面は、固まった時点でコードへ移す。最初から全画面をコード化すると、探索のたびにプルリクエストが要り、誰も画面を作らなくなります。

ダッシュボードを増やさない運用ルールと作らない方が早い3つの場面

ダッシュボードの失敗は、作り方より増やし方で起きます。ここでは判断を言い切ります。

1サービス1枚を上限にする運用ルールと四半期ごとの棚卸し手順

常設の画面は1サービスにつき1枚を上限にします。レイヤ別の詳細はタブ、環境やバージョンの切り替えはテンプレート変数で受ける。この2つで大半の「もう1枚ほしい」は消えます。

棚卸しは四半期に1回、閲覧されていない画面を削除候補にします。削除しても30日は復元できるため、迷ったら消す側に倒して構いません。運用画面の設計と当番の引き継ぎまで含めて外部の手を借りるなら、保守運用・内製化支援で監視設計から運用移管までを請け負っています。

モニターの通知で足りる監視をダッシュボード化しない判断の線引き

「異常を知りたい」だけならモニターの通知で足ります。ダッシュボードが要るのは「通知を受けた後に、原因の当たりを付けるために複数の指標を突き合わせたい」場面だけです。

この線引きを外すと、アラートと同じ内容を表示するだけの画面が量産されます。判断基準は単純で、その画面を「通知が来ていないときに開く理由」を1つ挙げられるかどうか。挙げられないなら、モニターだけ作って画面は作らない。

作らない方が早い3つの場面：単一ホスト・短期検証・共有前提なし

次の3つに当てはまるなら、ダッシュボードを作らずMetrics Explorerの画面で用が足ります。第一に監視対象が単一ホストで、インテグレーションの既定ダッシュボードで事足りる場合。第二に2週間以内に終わる検証で、終了後にその画面を誰も開かない場合。第三に自分しか見ない調査で、共有する前提がない場合。

逆に、当番制で複数人が見る、障害時に手順を追って読む、月次で同じ指標を比較する——このどれかに当たるなら常設の画面を作る価値があります。作る／作らないの境目は指標の数ではなく、読み手が自分以外にいるかどうかです。

よくある質問：Datadogダッシュボードの設計と運用でつまずく点

設計と運用の現場で実際に詰まりやすい5点を、公式ドキュメントの記載に沿って整理します。

ダッシュボードとモニターはどちらを先に作るべきですか？

モニターが先です。ダッシュボードは異常を知らせてくれないため、通知の仕組みがないまま画面だけ作っても障害には気づけません。ホスト死活とエラー率のモニターを先に置き、その通知を受けた後に見る画面としてダッシュボードを設計する順序にすると、置くべき指標が自然に決まります。

テンプレート変数を追加したのに既存ウィジェットに反映されないのはなぜですか？

変数の作成時に、適用するウィジェットを選択する工程があるためです。変数を追加しただけでは既存の全ウィジェットに自動では入りません。追加後は変数を切り替えて全グラフが追従するか確認し、追従しないものはウィジェット側のクエリに$<変数名>が入っているかを見てください。後から手で書き足した場合は、変数名のタイプミスも典型的な原因です。

ダッシュボードを社外の関係者へ共有できますか？

可能です。公開リンクによる共有、グラフの埋め込みコード、ウィジェットの画像としての共有、定期メールレポートという方法が用意されています。公開済みの内容は組織設定のPublic Sharingにある共有ダッシュボードの一覧で確認でき、そこからアクセスを止められます。公開範囲の管理を怠ると意図しない指標が外部に出るため、共有を有効にしたら一覧を定期的に見る運用をセットにしてください。

誤って削除したダッシュボードは復元できますか？

2026年8月時点の公式ドキュメントでは、削除されたダッシュボードは30日間保持されてから完全に削除されるとされています。この期間内であれば取り戻せる前提で棚卸しを進められます。ただし恒久的に残したい画面は、JSONをエクスポートしてリポジトリへ置くか、Terraformでコード管理へ移すほうが確実です。

Terraformで管理を始めた後にUIから編集してよいですか？

避けてください。コードが正である画面をUIで編集すると、次のapplyでコード側の定義に戻り、編集内容が消えます。急ぎで変えたいときは、UIで試して意図した表示になることを確認したうえでJSONを取り出し、その差分をHCLへ反映してからapplyする手順にします。コード化する画面と、UI編集のまま残す画面をあらかじめ分けておくと、この衝突自体が起きません。

関連記事

• Datadogの使い方｜アカウント作成からAgent導入と最初の監視までの手順：ダッシュボードを作る前段となる初期導入とAgent配置の手順を扱っています。
• Datadog運用のベストプラクティス｜タグ設計・監視対象の絞り込み・アラート・コスト抑制：テンプレート変数の前提となるタグ命名規約と、収集量を絞る設計を解説しています。
• Datadogの料金体系と費用が膨らむ課金単位：画面を増やす前に押さえるカスタムメトリクスとログの課金構造をまとめています。
• Datadog APM導入の実装手順：レイテンシとエラー率をサービス単位で取るための計装側の設定を扱っています。
• Datadog OpenTelemetry連携の実装方式：他ツールと併用しながら同じ指標を1枚の画面へ集めたい場合の入口になります。