タグ付け

予約キーの地図で見る、タグがつなぐもの

タグは key:value 形式の文字列で、キーが分類の軸、値が具体的な中身を表します。タグ付けの真価は単なる整理ではなく、メトリクス・トレース・ログという別種のデータを同じ札で結びつけ、画面間を行き来できるようにする点にあります (2026 年 8 月時点・出典: Getting Started with Tags)。この結びつけの中心にいるのが予約キーです。

公式は、コンテナやクラウドのようにホストが頻繁に入れ替わる環境では、サーバー A・サーバー B を個別に見るのではなく、service 単位で集約して見ることを推奨しています。タグの概念そのものは用語辞典のタグの項でも整理しています。

付け方は 4 経路、そして継承がある

タグの付与方法は 4 つあり、併用できます。Agent やインテグレーションの設定ファイルに書く方法、Datadog の UI で付ける方法、API 経由で付ける方法、DogStatsD でメトリクスを送るときに付ける方法です (2026 年 8 月時点・出典: Getting Started with Tags)。ここで見落とされがちなのが継承の仕組みで、ホストレベルで付けたタグは、そのホスト名に紐づくメトリクス・ログ・トレースすべてに自動的に受け継がれます。継承は便利な一方、複数の出どころから同じキーが継承されると混乱の種になります。公式ドキュメントは、ホストに service:my-host、その上で動くポッドに service:my-service を設定すると、データが両方のタグを継承してしまう例を挙げ、ホスト側の役割には infra_service のような別のキー名を使うことを勧めています。「どの経路で付けたタグか」を説明できる人がチームに 1 人はいる状態を保つことが、タグの重複や矛盾を早期に見つける実質的な防波堤になります。

統合サービスタグ付け - env・service・version の 3 点セット

予約キーのうち env・service・version の 3 つを全テレメトリーに一貫して付ける構成は、統合サービスタグ付け (Unified Service Tagging) という名前が付くほど特別扱いされています (2026 年 8 月時点・出典: Unified Service Tagging)。この 3 点が揃うと、version で絞ったトレースとコンテナメトリクスからデプロイの影響を特定する、同じタグ条件のままトレース・メトリクス・ログを行き来する、といった芸当が可能になります。version はデプロイのたびに変わることが期待されるタグで、異なるコードには異なる version を付けます。これが効いてくるのは障害対応のときです。「リリース直後からエラー率が上がった」という仮説は、version タグがあれば新旧バージョンのエラー率を並べるだけで数分で検証できますが、無ければデプロイ時刻とグラフを目視で突き合わせる手作業になります。APM を使う予定が少しでもあるなら、この 3 点セットだけは最初から整えておく価値があります。

規約はなぜ後から張り替えられないのか

タグの規約を後から直せばよいと考えるのは危険です。理由はメトリクスの構造にあります。時系列は「メトリクス名とタグ値の組み合わせ」で識別されるため、タグを変更した瞬間、それは別の時系列になります。つまり規約変更前の履歴と後の履歴はつながらず、過去 1 年の傾向グラフは変更日で断絶します。モニターやダッシュボードのクエリもタグ名を直接参照しているので、張り替えは全クエリの棚卸しとセットです。だからこそ、書式の制約を踏まえた規約を最初に決めます。タグ文字列は英字で始まり、使える文字は Unicode 文字・数字・アンダースコア・マイナス・コロン・ピリオド・スラッシュで、それ以外はアンダースコアに変換されます。長さはキーとコロンと値を合わせて 200 文字までです。さらにスパンタグとメトリクスタグは小文字に正規化されるため、キャメルケースは避けるのが安全です。クラウド事業者側の正規化も揺れており、公式ドキュメントは AWS が TestTag を testtag に、Alibaba Cloud が test_tag に変換する例を挙げています (2026 年 8 月時点・出典: Getting Started with Tags)。規約はシンプルに「すべて小文字・単語間はアンダースコア・キーの語彙は一覧表で管理」から始めるのが、後悔の少ない初期設定です。

カーディナリティと課金への跳ね返り

タグ設計は使い勝手だけでなく請求額に直結します。ただし、跳ね返り方はデータの種類で違います。カスタムメトリクスは「メトリクス名とタグ値の一意な組み合わせ」を 1 個と数えて課金対象にするため、値の種類が多いタグ (ユーザー ID・コンテナ ID・リクエスト ID など) をメトリクスに付けると、時系列の本数が掛け算で膨らみます (2026 年 8 月時点・出典: Custom Metrics)。これがいわゆるカーディナリティ事故です。一方、ログは取り込み量とインデックスされたイベント数、トレースのスパンは取り込み GB を単位に課金されるため、タグを増やすこと自体が課金の主因にはなりません。この非対称を規約に翻訳すると、「ログとトレースには調査に役立つタグを惜しまず付けてよい。ただしメトリクスに付けるタグのキーは、値の種類が有限で少ないものに限る」という 1 行になります。高カーディナリティの分析がしたい場合は、メトリクスにタグを足すのではなく、生データを保持するログを受け皿にするのが正攻法です。ログの課金は取り込み量ベースで、タグの種類数には依存しないからです。ここでカスタムメトリクスの DISTRIBUTION 型を受け皿と考えるのは危険です。DISTRIBUTION もメトリクス名とタグ値の組み合わせで計数され、しかも既定でその 5 倍のカスタムメトリクスを生成するため (パーセンタイル集計を有効化するとさらに増加)、高カーディナリティタグの置き場所にすると課金はむしろ膨らみます (2026 年 8 月時点・出典: Custom Metrics Billing)。料金の全体像は料金の読み解きで扱っています。

チームで運用するためのルール 3 つ

最後に、規約を絵に描いた餅にしないための運用ルールを 3 つ提案します。第一に、タグのキー一覧を 1 枚のドキュメントで管理し、新しいキーの追加はレビューを通すことです。タグは誰でもどの経路からでも付けられるため、放置すると env と environment と stage が並存する語彙の無政府状態に向かいます。第二に、team タグを全リソースに義務付けることです。公式の予約キーにも入っているこのタグは、障害時の「これ誰の持ち物?」を一掃し、コスト配賦の基礎にもなります。Datadog の課金レポートは選んだタグ (最大 3 つ) で使用量を分解できるため (2026 年 8 月時点・出典: Getting Started with Tags)、team を軸にすればチーム別の Datadog 費用が機械的に出ます。第三に、四半期に一度、実際に付いているタグキーの一覧を眺める棚卸しです。規約から外れたキーは増殖の初期に摘むほど安く済みます。タグ付けは一度整えば空気のような存在になりますが、その空気を維持しているのは仕組みではなく、こうした小さな運用です。