命名規則・タグ設計のベストプラクティス：後から効くやつ（コスト / 棚卸 / 権限）

はじめに

命名規則とタグ設計は、立ち上げ初期ほど軽く見られます。
台数も少ない。担当者も見えている。構成も頭に入っている。だから「あとで揃えればいい」で進みがちです。

でも、クラウド各社の一次情報をちゃんと読むと、名前やタグは単なる見た目のルールではなく、コスト管理・ガバナンス・自動化・アクセス制御の基礎部品として扱われています。Azure Cloud Adoption Framework は「命名規則を先に定義し、その上でタグ戦略を補完的に設計する」と明言しています。AWS は cost allocation tags、tag policies、ABAC guardrails を別の論点として整理しています。Google Cloud は labels、Resource Manager tags、network tags を明確に分けています。つまり、「名前とタグ」はクラウド横断で同じ意味ではありません。ここを雑にまとめると、後で必ず破綻します。

この記事は、単に「タグを付けましょう」で終わる話ではありません。
命名規則・labels/tags・権限制御用の属性をどう分離し、どう統制し、どうコスト/棚卸/権限に効かせるかを、現場の泥臭さも含めて整理します。

先に結論

アーキテクト視点で整理すると、設計対象は4層あります。

①Hierarchy

AWS の account / OU、Azure の management group / subscription / resource group、GCP の organization / folder / project のような管理境界。大きな責任分界、課金責任、ポリシー適用境界はまずここで切る。

②Name

変わらない識別子。人間にも機械にも使うが、役割はあくまで「識別」。説明文ではない。

③Metadata

コスト配賦、棚卸、検索、運用自動化のための属性。ここに labels/tags を使う。

④Policy Attribute

権限制御や組織ポリシーの条件に使う属性。これはメタデータではなく、実質的にセキュリティ境界。

この4層を混ぜないことが、後から効く設計の本質です。
現場で死ぬのは、だいたい次のどれかです。

名前に可変情報を詰め込む
コスト用タグと権限用タグを同じノリで運用する
各クラウドのタグ仕様差分を吸収せず、共通ルールだけ作って終わる
手入力前提で「運用で頑張る」設計にする

なぜ後から効くのか

コストで詰む

月末、Finance からこう言われます。

「この 180 万円、どのプロダクト持ちですか？」
「たぶん共通基盤です」
「“たぶん”では締められないです」

この時点で env=prod しかなければ、ほぼ負けです。
AWS の白書でも、cost allocation tags は showback / chargeback のためのデータを作る前提として説明されています。誰が使ったコストか、どの workload / application / environment が費用を生んだかを見える化するのが役割です。

棚卸で詰む

現場の棚卸は、だいたい次の5問に答えられるかどうかです。

これは何の資産か
どの環境か
誰の責任か
どこに配賦すべきか
消してよい条件は何か

名前だけでこれを全部背負わせると壊れます。
db-new-final は、半年後には「何が new なのか」誰も説明できません。

権限で詰む

一番事故りやすいのはここです。

「project=payments が付いてるものだけ触れるようにしています」
「その属性、誰が更新できます？」
「開発チームでも更新できます」
「じゃあ、それ権限境界じゃなくて自己申告ですよね」

AWS は ABAC がタグ依存である以上、意図しないアクセスを防ぐ guardrail が必要だと書いています。Google Cloud も tags を IAM allow/deny や organization policy に使えます。つまり、権限に効く属性は「ただのタグ」ではありません。運用メタデータとは別レーンで守る必要があります。

クラウド差分を雑に混ぜると事故る

Azure：タグは便利だが、言い切り方を間違えると危ない

まずよくある誤解から。
「Azure はタグが case-insensitive」だけで終わらせるのは不正確です。

Azure の公式仕様では、タグ名は“操作上” case-insensitive です。つまり取得や更新は大文字小文字を区別せず扱われます。一方で、タグ値は case-sensitive です。さらに、リソース プロバイダーはタグ名の元の表記を保持することがあり、その casing はコストレポートにも現れます。なので、「完全に case-insensitive」と覚えると、実運用では誤解が出ます。

さらにややこしいのがクエリです。Azure Resource Graph のサンプルでも、タグ検索に =~ を使う case-insensitive match と、== を使う case-sensitive match が明確に分かれています。つまり、管理 API のふるまいとクエリの書き味は同じではありません。ここを雑にまとめると、検索条件やレポートの差異でハマります。

継承も誤解されやすいです。Azure では、resource group や subscription に付けたタグは、resource にネイティブ継承されません。ただし、Azure Policy には「Inherit a tag from the resource group」「Inherit a tag from the subscription」といった built-in があり、modify と remediation を使えば実質継承として運用できます。さらに Cost Management の tag inheritance は、リソースではなく usage records に対して billing / resource group / subscription のタグを反映します。設定変更や継承タグ更新の反映対象は current month で、24時間程度で usage records が更新されます。タグによる cost rollup 自体も、タグ付与前の usage には遡及しません。

タグ対応状況も「昔よりかなり改善した」が正解です。現在の Azure は広くタグ対応していますが、classic resources は未対応ですし、resource type ごとの制約や例外も残っています。たとえば一部リソースは PATCH ベースでポータルからタグ更新できず、また一部の Azure リソースは 15 タグまでしか持てません。なので設計上は「Azure はほぼタグ前提でよい。ただし例外リストは必須」と考えるのが安全です。

権限面では、Azure にも ABAC はあります。ただし、現行の公式ドキュメントでは、conditions を付けられるのは blob storage / queue storage の data actions を持つ role assignments です。また、conditions では明示 deny はできません。つまり Azure は、AWS のように「リソースタグを一般的な横断 ABAC の中心に置く」設計とは少し違い、基本は RBAC を主軸にして、必要なところだけ ABAC 条件で絞り込む設計になります。

AWS：Tag Policies だけでは設計は閉じない

AWS でよくある誤解は、Tag Policies を入れれば required tags まで全部片付くという思い込みです。

AWS Organizations の tag policies は、タグが付いたときにキーの大文字小文字、許容値、標準化ルールを統制できます。非準拠の tagging operation を対象 resource type で防ぐ enforcement もあります。ですが、公式ドキュメントは同時に、untagged resources や tag policy に定義されていないタグは評価対象にならないとも書いています。つまり Tag Policies は「標準化と準拠確認」には強いですが、全ての未タグ付け作成をそれ単体で潰す前提にはできません。

ここは最近のドキュメントのニュアンスも大事です。現行の AWS ドキュメントでは Tag Policies に “Basic compliance rules” と “Required tag key” の2機能があると説明されています。ただし同じページで、Basic compliance rules はタグなしで作成されたリソースの missing keys を強制しない、required / mandatory tag keys を確実に resource creation 時に保証するものではない、と明記しています。そして、タグなしリクエストを防ぐには SCP を使うよう書かれています。EC2 の IAM ドキュメントでも、作成時タグを強制するには aws:RequestTag や aws:TagKeys を resource-creating action 側に掛ける必要があるとされています。設計としては、Tag Policies = 標準化と可視化、IAM/SCP = create-time hard enforcement と分けるのが正解です。

ABAC については AWS が最も本格的です。aws:ResourceTag、aws:RequestTag、aws:TagKeys を使って resource / request / principal の各側面で条件を書けます。一方で、AWS 自身が「ABAC authorization model depends on tags」である以上、SCP 等でタグ変更に guardrail を入れろと書いています。タグで権限を制御するなら、タグ変更権限の設計までが本体です。

コスト面も Azure / GCP と少し違います。AWS の user-defined cost allocation tags は、付けるだけでは billing に出ません。Billing and Cost Management 側で activation が必要で、反映には最大24時間程度かかります。また、現行仕様では management account から最大12か月の backfillも可能です。ただし backfill は「その期間に実際にそのタグが resource に付いていた」ことが前提です。つまり AWS は、コストタグの運用開始タイミングが設計に効きます。

GCP：labels / tags / network tags を混ぜると設計が壊れる

GCP は、ここを一番雑に説明してはいけません。
GCP の “tag” は1種類ではありません。

まず labels は、リソースに付けるメタデータです。コスト管理、検索、フィルタ、Billing Export to BigQuery の分析に使います。labels は resource ごとに最大64個、キー/値は lowercase letters・numbers・underscores・dashes に制約されます。Google は label strategy を簡単にするため、10個を超えない程度の標準ラベルセットを推奨しています。これは制限ではなく運用ガイドです。また labels は billing system に渡され、BigQuery export でも usage と一緒に出せます。一方で、labels は policy condition には使えず、子リソースにも継承されません。

次に Resource Manager tags です。こちらは labels と違って、tag key / tag value / tag binding が独立したリソースとして扱われます。タグは親から子へ継承され、IAM allow/deny 条件やorganization policy conditional constraintsで参照できます。さらに現行ドキュメントでは Cloud Billing integration にも言及されていて、chargeback や audit 用の cost analysis に使えます。つまり、GCP の tags は「IAM 条件専用」と言い切るのも今は不正確です。正しくは、labels より強い統制・継承・ポリシー連携を持つ属性です。なお、タグは1キー1値で、resource あたり最大50 key-value pairs です。

ただし mandatory tags の enforcement は万能ではありません。Resource Manager tags には custom organization policy を使った mandatory tags enforcement の仕組みがありますが、現時点では Preview で、対応 resource types も限定されています。GCP でも universal required-tag enforcement を最初から期待しすぎず、IaC 側の注入と標準化を主軸に置くのが現実的です。

さらに別物として network tags があります。これは Compute Engine VM に付ける文字列で、VPC firewall rules や routes の target / source 条件に使います。1 VM あたり最大64個、文字種にも制約があります。重要なのは、Cloud NGFW のドキュメントが network tags を “character strings without access controls” と明記している点です。つまり network tags は権限統制のための secure tags とは別物で、ファイアウォール適用対象を選ぶためのネットワーク属性です。コンプライアンスやデータ分類の中核ラベルとして流用すると、あとで意味が壊れます。

アーキテクトとして押さえる設計原則

1. 名前は「識別子」、タグは「属性」、権限タグは「境界」

名前に可変情報を入れない。
担当者名、チケット番号、new、final、migration、日付、フェーズ名を入れ始めると、運用が始まった瞬間に腐ります。Azure CAF も、多くの resource name は作成後に変更できないので、名前には変わらない情報だけを入れ、その他は tags に持たせるとしています。さらに resource type ごとに naming rules が違うので、「全部同じ見た目」に執着しすぎるのも危険です。

2. グローバル辞書を持つ。自由入力にしない

prod / production / prd / 本番 が混ざった時点で、コスト集計も棚卸も壊れます。
GCP は formal labeling policy を作り、programmatically に labels を適用し、標準キー/値を持つことを推奨しています。AWS も tag policy で case treatment や allowed values を統制する前提です。タグはメモ帳ではなく、業務コード体系として扱うべきです。

3. lower_snake_case に寄せる

これは多クラウド運用ではかなり効きます。
GCP labels は lowercase 前提で文字種もかなり制約が厳しいです。Azure はタグ名が操作上 case-insensitive ですが表示ケースは保持され、AWS では capitalization enforcement を使うと CostCenter と costcenter は別キーとして扱われます。さらに AWS の policy conditions では key names が case-insensitive で、service によっては case だけ違うキーを作れてしまいます。だからこそ、キーは lower_snake_case、値も原則 lowercase、列挙値は固定が一番事故りにくいです。

4. コスト/運用タグと権限タグを分離する

project=alpha をコスト配賦にもアクセス制御にも使い始めると、運用者とセキュリティ担当が同じ属性を別の目的で引っ張るようになります。
AWS は ABAC 用タグの guardrail を明示していますし、GCP tags は allow/deny policy や organization policy に入ってきます。Azure も ABAC 条件はありますが適用範囲が限定的です。つまり、権限に効く属性は変更権限も含めて別レーンにすべきです。コスト配賦属性と同じ運用手順にしないこと。

5. 人名ではなく“チーム”を持つ

owner=taro.yamada は便利そうに見えて、異動した瞬間に死にます。
GCP も labels に sensitive information や PII を入れないように言っていますし、Azure は tags が plain text でさまざまな経路から露出しうると警告しています。AWS も cost allocation tags で sensitive information を避けるべきだとしています。責任の単位は個人ではなく、owner_team / support_group / cost_center のような組織単位に寄せたほうが強いです。

6. 必須キーは少なく、しかし意味は強く

GCP は label strategy を簡素にするため 10 個を超えない程度を推奨しています。Azure は 1 resource あたり最大 50 tags ですが、一部 resource は 15 tags までです。GCP の Resource Manager tags も 1 resource あたり最大 50 key-value pairs です。だから設計としては、必須 6〜8 個、条件付き 2〜3 個くらいが一番回ります。たくさん付けるほど統制できるわけではなく、例外対応と漏れが増えるだけです。

7. 高カーディナリティ属性は、自動化が読む時だけ持つ

ticket_no=...、build_id=...、timestamp=... を好き放題に入れると、タグ辞書は一気にゴミ箱になります。
GCP も「大量の unique labels」や頻繁に変わる値は、フィルタやレポートを壊すので推奨していません。delete_after=2026-09-30 のような属性は、自動削除ジョブや期限切れ検知が実際に読むときだけ持つべきです。

参照実装としてのタグ辞書

まずはこのくらいから始めるのが現実的です。

key	必須	例	役割
service	必須	billing	何のための資産か
environment	必須	dev / stg / prod	環境識別
owner_team	必須	platform	運用責任
cost_center	必須	cc0421	会計・配賦
allocation_group	推奨	product-a / shared-platform	共通費の扱い
managed_by	必須	terraform / manual	変更経路の判定
lifecycle	必須	permanent / temporary / sunset	削除判断
data_class	推奨	public / internal / confidential / restricted	データ分類
compliance	条件付き	pci / sox	統制要件
auth_scope	条件付き	payments-prod	権限制御用。コスト用途と兼用しない
delete_after	条件付き	2026-09-30	自動処理が読む時だけ使う

ポイントは3つです。

service, environment, owner_team, cost_center は棚卸の最小四点セット
allocation_group は共通基盤費の逃げ道
auth_scope は別レーン管理

サンプルはこんな感じです。

service: billing
environment: prod
owner_team: platform
cost_center: cc0421
allocation_group: shared-platform
managed_by: terraform
lifecycle: permanent
data_class: confidential
compliance: pci

命名テンプレートは「見た目統一」より「部品統一」

おすすめは、論理名を統一し、物理名は各クラウド/各 resource type に合わせてレンダリングする方式です。

論理パターンの例:

----

例:

billing-prod-jpe-web-01
billing-prod-jpe-db-01
platform-stg-jpe-batch-02

ただし、物理名はそのまま強制しません。
Azure でも resource type ごとに文字種・長さ・区切り文字の制約が違います。なので、揃えるべきは見た目ではなく、構成要素です。たとえば storage account では区切り文字を落とす、global uniqueness が必要な resource だけ suffix を足す、といったレンダリング層を作るほうが長持ちします。

実装アーキテクチャは Git / IaC / Policy / Cost / Inventory を一本にする

ここがアーキテクト記事として一番言いたいところです。
命名規則とタグ設計は、Wiki に書いて終わりではありません。制御の連鎖として設計しないと機能しません。

1. Source of Truth を Git に置く

最低限、次を YAML か JSON で持ちます。

キー一覧
allowed values
必須 / 任意
所有者
変更手順
廃止予定値

ここが人の記憶に乗っていると、3チーム目が入った瞬間に終わります。

2. IaC モジュールで name と metadata を同時生成する

Terraform / Bicep / CloudFormation / Pulumi で、name だけ別実装、tag だけ各チーム自由、にしない。
命名レンダリングと共通 metadata 注入を同じ module 層に寄せます。GCP も labels は programmatically に適用することを勧めています。Azure は Policy で追加/継承/修正できますし、AWS は Tag Policies と IAM/SCP を組み合わせます。

3. 統制は3段階で入れる

1つ目は report。

今どれだけ揃っていないかを可視化する。

2つ目は auto-attach / remediate。

Azure Policy の modify / remediation や、IaC の共通 module で漏れを潰す。Azure の built-in policies には Add / Append / Inherit が揃っています。

3つ目は deny on create。

新規ドリフトを止める。
Azure は Policy の deny、AWS は IAM/SCP の aws:RequestTag / aws:TagKeys、GCP は IaC・policy constraints・supported resources での mandatory tags enforcement を組み合わせる。AWS と GCP は特に、“全部の resource type で同じように効く” と期待しないのが大事です。

4. コスト分析基盤に必ず流す

ここをやらないと「タグは付いているのに、使っていない」になります。

Azure: Cost Analysis / Exports / usage records
AWS: Cost Explorer / cost allocation report / CUR
GCP: Cloud Billing Export to BigQuery

Azure は tags が cost rollup に遡及しません。AWS は activation が必要で、必要なら backfill を検討します。GCP は labels が billing system と BigQuery export に流れます。タグを付けること自体が目的ではなく、配賦できることが目的です。

5. 棚卸は billing だけでなく inventory と突き合わせる

コストだけ見ていると、「金額は小さいが危ない資産」が漏れます。
逆に inventory だけ見ていると、「台数は少ないが金額がでかい資産」を見落とします。

なので、運用上は

inventory coverage
tagging coverage
spend coverage

を分けて見たほうがいいです。
現場感では、件数 coverage より spend coverage のほうが痛みと一致します。

現場で本当に危ないアンチパターン

Name タグだけで管理した気になる

Name=payment-prod-main は見やすいですが、配賦・棚卸・権限制御のどれにも直接は効きません。
Name はラベルではなく、ほぼ別名です。

owner に個人名を入れる

異動、退職、兼務、外部委託で壊れます。
責任は team で持つ。個人は CMDB や PagerDuty 側で引く。

Azure で「RG につけたから子にも付いてるはず」と思う

付いていません。
Policy を入れて初めて “実質継承” です。Cost Management の tag inheritance も usage records に効くだけで、resource そのものにタグが付くわけではありません。

AWS で Tag Policies だけ入れて満足する

標準化はできます。
でも、タグなし create を確実に潰す話は別です。そこは IAM / SCP 側です。

GCP で network tags を権限属性のつもりで使う

network tags は firewall / route の適用対象を選ぶための VM 属性です。secure tags とは別です。
ここを混ぜると、ネットワーク設計と IAM 設計が変な形で癒着します。

policy attribute をアプリチームが自由変更できる

これが一番危ない。
auth_scope=prod をコストタグと同じ権限で編集できるなら、設計は最初から破綻しています。

既存環境にどう入れるか

現実には、既に汚れている環境に入れることのほうが多いです。
その場合の順番は、だいたいこれです。

辞書を先に決める

まず allowed values を決める。運用で吸収しない。

高コスト / 本番 / 外向き / データ持ちから直す

ここにタグがないと、説明コストが高すぎる。

IaC module に共通注入を入れる

新規ドリフトを止める。

report を先に出す

いきなり deny しない。まず痛みを可視化する。

auto-remediation を入れる

Azure Policy modify、共通 module、定期補正ジョブ。

最後に deny を入れる

ここで初めて強制力を上げる。

この順番を逆にすると、現場から「また platform チームが開発を止めた」と言われます。
タグ設計で大事なのは、正しさより先に導入可能性です。

まとめ

命名規則とタグ設計は、きれい好きのためのルールではありません。
クラウドの責任分界を、運用可能な形に落とすための設計です。

整理すると、後から効くのはこの切り分けです。

・Hierarchy は管理境界
・Name は安定した識別子
・Metadata はコスト・棚卸・運用自動化
・Policy Attribute は権限境界

そして、クラウド差分はちゃんと別物として扱う。

・Azure はタグ名が操作上 case-insensitive、値は case-sensitive。継承はネイティブではなく Policy / Cost Management で補う。ABAC はあるが適用範囲は限定的。
・AWS は Tag Policies で標準化できるが、create-time guarantee は IAM / SCP まで含めて設計する。ABAC は強力だが guardrail 前提。
・GCP は labels、Resource Manager tags、network tags が別物。labels はコスト/検索、tags は継承・IAM/deny・org policy、network tags は firewall/routes。

現場で一番強いのは、凝った命名ではありません。
半年後に、別チームの誰が見ても迷わない設計です。