resource-tagging

リソースのタグ付け

包括的なクラウドリソースのタグ付け戦略を適用し、マルチクラウド環境全体でコスト配分、所有者の追跡、コンプライアンスの適用、インフラストラクチャの自動化を実現します。

目的

リソースのタグ付けは、クラウドガバナンスの基盤となるメタデータレイヤーを提供します。タグを使うと、正確なコスト配分（未配分の支出を最大80％削減）、迅速な所有者の特定、コンプライアンス対象範囲の定義、自動化されたライフサイクル管理が可能になります。適切なタグ付けがなければ、クラウドコストを追跡できず、セキュリティインシデントの状況を把握できず、自動化ポリシーで対象リソースを効果的に絞り込めません。

使用する場面

次の場合にリソースのタグ付けを使用します。

• コスト配分と説明責任を実現するクラウドガバナンスフレームワークを導入する
• チーム、プロジェクト、または部門別の支出可視性が必要なFinOpsの取り組みを構築する
• 自動化ポリシーを通じてコンプライアンス要件（PCI、HIPAA、SOC2）を適用する
• リソースライフサイクル管理（バックアップ、監視、シャットダウン）を自動化する
• マルチテナントまたは複数プロジェクトのクラウド環境を管理する
• 重要度に基づいた災害復旧およびバックアップポリシーを導入する
• セキュリティインシデントへの対応に備えてリソースの所有者を追跡する
• 支出分析やショーバック／チャージバックを通じてクラウドコストを最適化する

最小限の実用的なタグ付け戦略

すべてのクラウドリソースに必須の**「ビッグシックス」**タグから始めます。

タグ	目的	値の例
Name	人が読みやすい識別子	prod-api-server-01
Environment	ライフサイクルの段階	prod | staging | dev
Owner	担当チームの連絡先	[email protected]
CostCenter	請求用の財務コード	CC-1234
Project	ビジネス上の取り組み	ecommerce-platform
ManagedBy	リソースの作成方法	terraform | pulumi | manual

特定のニーズに応じて追加する任意のタグ：

• Application：アプリケーション単位の分離が必要な複数アプリのプロジェクト
• Component：リソースの役割（web、api、database、cache）
• Backup：バックアップポリシー（daily、weekly、none）
• Compliance：規制上の対象範囲（PCI、HIPAA、SOC2）
• SLA：サービスレベル（critical、high、medium、low）

タグの命名規則

組織全体で命名規則を1つだけ選び、一貫して適用します。

規則	形式	例	最適な対象
PascalCase	CostCenter、ProjectName	AWS標準	AWS中心の組織
lowercase	costcenter、project	GCPラベル（必須）	GCP中心の組織
kebab-case	cost-center、project-name	Azure（大文字と小文字を区別しない）	Azure中心の組織
Namespaced	company:environment、team:owner	複数組織向けのタグポリシー	大企業

重要： 大文字と小文字の区別はプロバイダーによって異なります。

• AWS：大文字と小文字を区別します（Environment ≠ environment）
• Azure：大文字と小文字を区別しません（Environment = environment）
• GCP：小文字が必須です（environmentのみ）
• Kubernetes：大文字と小文字を区別します（environment ≠ Environment）

タグのカテゴリ

すべてのタグカテゴリの詳細な分類については、references/tag-taxonomy.mdを参照してください。

技術タグ

運用に関するメタデータ：Name、Environment、Version、ManagedBy

ビジネスタグ

コスト配分に関するメタデータ：Owner、CostCenter、Project、Department

セキュリティタグ

コンプライアンスに関するメタデータ：Confidentiality、Compliance、DataClassification、SecurityZone

自動化タグ

ライフサイクルに関するメタデータ：Backup、Monitoring、Schedule、AutoShutdown

運用タグ

サポートに関するメタデータ：SLA、ChangeManagement、CreatedBy、CreatedDate

カスタムタグ

組織固有のメタデータ：Customer、Application、Component、Stack

クラウドプロバイダーのタグ制限

プロバイダー	タグの上限	キーの長さ	値の長さ	大文字と小文字の区別	継承
AWS	ユーザー定義 50 個	128 文字	256 文字	あり	タグポリシー経由
Azure	50 ペア	512 文字	256 文字	なし	Azure Policy 経由
GCP	64 個のラベル	63 文字	63 文字	なし	組織ポリシー経由
Kubernetes	無制限	プレフィックス 253 文字 + 名前 63 文字	63 文字	あり	名前空間経由

タグの適用パターン

Infrastructure as Code（推奨）

Terraform/Pulumi を通じてタグを自動適用し、手動入力によるエラーを 95% 削減します。

# Terraform: Provider-level default tags
provider "aws" {
  default_tags {
    tags = {
      Environment = var.environment
      Owner       = var.owner
      CostCenter  = var.cost_center
      Project     = var.project
      ManagedBy   = "terraform"
    }
  }
}

すべてのリソースにこれらのタグが自動的に継承されます。リソース固有のタグはデフォルト値とマージされます。

Terraform、Pulumi、CloudFormation の完全な例については、examples/terraform/、examples/pulumi/、examples/cloudformation/ を参照してください。

ポリシーベースの適用

リソース作成時にタグ付けを適用します。

AWS：AWS Config ルールを使用してタグの準拠状況を確認します（警告または拒否）。 Azure：Azure Policy を使用してタグの継承と適用を行います。 GCP：組織ポリシーを使用してラベル値を制限します。 Kubernetes：OPA Gatekeeper または Kyverno を使用してアドミッション制御を行います。

適用パターンの実装については、references/enforcement-patterns.md を参照してください。

タグ準拠状況の監査

タグのないリソースを特定するため、定期的な監査（週次を推奨）を実施します。

AWS Config Query（SQL）：

SELECT resourceId, resourceType, configuration.tags
WHERE resourceType IN ('AWS::EC2::Instance', 'AWS::RDS::DBInstance')
  AND (configuration.tags IS NULL OR NOT configuration.tags.Environment EXISTS)

Azure Resource Graph Query（KQL）：

Resources
| where type in~ ('microsoft.compute/virtualmachines')
| where isnull(tags.Environment) or isnull(tags.Owner)
| project name, type, resourceGroup, tags

GCP Cloud Asset Inventory：

gcloud asset search-all-resources \
  --query="NOT labels:environment OR NOT labels:owner" \
  --format="table(name,assetType,labels)"

監査クエリとスクリプトの完全な内容については、references/compliance-auditing.md と scripts/audit_tags.py を参照してください。

タグを使ったコスト配分

コスト配分タグを有効にして、チーム、プロジェクト、または部門ごとの支出を追跡します。

AWS Cost Explorer

コスト配分タグを有効化します（有効化には最大 24 時間かかります）。

# Enable cost allocation tags via Terraform
resource "aws_ce_cost_allocation_tag" "environment" {
  tag_key = "Environment"
  status  = "Active"
}

resource "aws_ce_cost_allocation_tag" "project" {
  tag_key = "Project"
  status  = "Active"
}

タグごとにコスト異常検出を設定して、通常と異なる支出を検知します。

resource "aws_ce_anomaly_monitor" "project_monitor" {
  name         = "project-cost-monitor"
  monitor_type = "DIMENSIONAL"

  monitor_specification = jsonencode({
    Tags = {
      Key    = "Project"
      Values = ["ecommerce", "mobile-app"]
    }
  })
}

Azure Cost Management

Azure Cost Management のダッシュボードでタグごとにコストをグループ化します。タグ別の内訳を含むコストデータをエクスポートします。

az consumption usage list \
  --start-date 2025-12-01 \
  --query "[].{Cost:pretaxCost, Project:tags.Project, Team:tags.Owner}"

GCP Cloud Billing

ラベル別の内訳を含む請求データを BigQuery にエクスポートします。

SELECT
  labels.key AS label_key,
  labels.value AS label_value,
  SUM(cost) AS total_cost
FROM `project.dataset.gcp_billing_export_v1_XXXXX`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key IN ('environment', 'project', 'costcenter')
GROUP BY label_key, label_value
ORDER BY total_cost DESC

コスト配分の実装の詳細については、references/cost-allocation.md を参照してください。

判断基準：必須タグと任意タグ

作成時に適用するタグを決定します。

必須（強制拒否で適用）：

• コスト配分：Owner、CostCenter、Project
• ライフサイクル：Environment、ManagedBy
• 識別：Name

推奨（ソフトな適用 — 警告のみ）：

• 運用：Backup、Monitoring、Schedule
• セキュリティ：Compliance、DataClassification
• サポート：SLA、ChangeManagement

任意（適用なし）：

• カスタム：Application、Component、Customer
• 実験用：標準外のタグ全般

適用方法：

1. 強制適用（リソースの作成を拒否）：コスト配分タグに使用します

   • AWS：拒否モードの AWS Config ルール
   • Azure：拒否効果の Azure Policy
   • GCP：制約を設定した組織ポリシー

2. ソフトな適用（警告のみ）：運用タグに使用します

   • AWS：通知機能付きの AWS Config ルール
   • Azure：監査効果の Azure Policy
   • GCP：Cloud Asset Inventory レポート

3. 適用なし（ベストエフォート）：カスタムタグや実験用タグに使用します

タグ継承の方法

自動継承によって、手動でタグを付ける手間を削減します。

AWS Tag Policies

AWS Organizations のアカウント階層からタグを継承します。

{
  "tags": {
    "Environment": {
      "tag_key": {
        "@@assign": "Environment"
      },
      "enforced_for": {
        "@@assign": ["ec2:instance", "s3:bucket"]
      }
    }
  }
}

Azure のタグ継承

Azure Policy を使用して、リソースグループからタグを継承します。

resource "azurerm_policy_assignment" "inherit_environment" {
  name                 = "inherit-environment-tag"
  policy_definition_id = azurerm_policy_definition.inherit_tags.id

  parameters = jsonencode({
    tagName = { value = "Environment" }
  })
}

GCP のラベル継承

組織ポリシーを通じて、フォルダーやプロジェクトからラベルを継承します。

resource "google_organization_policy" "require_labels" {
  org_id     = var.organization_id
  constraint = "constraints/gcp.resourceLabels"

  list_policy {
    allow {
      values = ["environment:prod", "environment:staging"]
    }
    inherit_from_parent = true
  }
}

Kubernetes のラベル伝播

Kyverno を使用して、名前空間からラベルを自動生成します。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-labels
spec:
  rules:
  - name: add-environment-label
    match:
      resources:
        kinds: [Pod, Deployment]
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            +(environment): "{{request.namespace}}"

よくあるアンチパターン

アンチパターン 1：一貫性のないタグ名

問題：リソース間で同じタグに複数の表記揺れがある

# BAD: Tag sprawl
Environment: prod
environment: production
Env: prod
ENVIRONMENT: PROD

解決策：IaC とタグポリシーを通じて、単一の命名規則を適用します

# GOOD: Consistent naming
Environment: prod  # Single standard format

アンチパターン 2：タグなしでの手動リソース作成

問題：CLI／コンソールで作成されたリソースに必須タグが付いていません。

解決策：Config／Policy ルールでタグのないリソース作成をブロックするか、事前にタグを設定したテンプレートを使用する AWS Service Catalog／Azure Blueprints を利用します。

アンチパターン 3：タグの強制なし（任意のタグ付け）

問題：タグが任意のため、頻繁に設定が漏れ、支出の 35% が未割り当てになります。

解決策：IaC でプロバイダーのデフォルトタグを使用し、アカウント／サブスクリプションレベルでポリシーを適用します。

アンチパターン 4：タグの乱立（カスタムタグが多すぎる）

問題：リソースごとに 30 個以上のタグがあり、そのほとんどが使われず、コストレポートにノイズが生じます。

解決策：まず必須の「ビッグシックス」タグのみを使用します。明確なユースケースがある場合に限り、任意のタグを追加します。

アンチパターン 5：静的なタグが更新されない

問題：作成時に設定されたタグが更新されず、たとえばチーム変更後も Owner が古いままです。

解決策：自動タグ監査を毎週実施し、IaC でタグをプログラムから更新し、所有者の更新のために ID プロバイダーと連携します。

他のスキルとの連携

infrastructure-as-code：Terraform／Pulumi モジュールの default_tags／stackTags を使用してタグを自動適用します。

cost-optimization：タグにより、プロジェクト／チーム単位のコスト配分、ショーバック／チャージバック、予算アラートが可能になります。

compliance-frameworks：タグにより、監査証跡や自動ポリシー適用において PCI／HIPAA／SOC2 の対象範囲を証明できます。

security-hardening：タグでセキュリティポリシーを適用します（例：SecurityZone タグに基づいてパブリックアクセスと内部アクセスを区別します）。

disaster-recovery：タグでバックアップポリシーの対象リソースを特定します（例：Backup: daily によってスナップショットが自動作成されます）。

kubernetes-operations：ラベルをポッドのスケジューリング、リソースクォータ、ネットワークポリシー、サービス選択に使用します。

実装チェックリスト

リソースのタグ付けを実装する際は、次の項目を確認します。

• 許可値を定めた必須の「ビッグシックス」タグを定義する
• 命名規則を 1 つ選ぶ（PascalCase、lowercase、kebab-case）
• IaC にタグを実装する（Terraform／Pulumi プロバイダーの default_tags）
• 適用ポリシーを設定する（AWS Config、Azure Policy、GCP org policies）
• 請求コンソールでコスト配分タグを有効にする（AWS Cost Explorer、Azure Cost Management）
• タグコンプライアンス監査のプロセスを作成する（毎週を推奨）
• 組織の Wiki／ランブックにタグ標準を文書化する
• タグのないリソースに対する自動アラートを設定する
• 所有者への連絡に使えるよう、タグを監視／アラートと連携させる
• 非準拠リソースの修正手順書を作成する

クイックリファレンス

プロバイダー別のタグ適用ツール

プロバイダー	適用ツール	目的
AWS	AWS Config Rules	タグコンプライアンスの監視と修正
AWS	Tag Policies (Organizations)	アカウントレベルでタグを適用
Azure	Azure Policy	タグの適用と継承
GCP	Organization Policies	ラベルの制限と継承
Kubernetes	OPA Gatekeeper	ラベルのアドミッション制御
Kubernetes	Kyverno	ラベルの自動生成と検証

コスト配分ツール

ツール	目的
AWS Cost Explorer	タグベースのコスト分析と異常検知
Azure Cost Management	タグによるグループ化と予算管理
GCP Cloud Billing	ラベルベースのコスト内訳
CloudHealth	マルチクラウドのコスト最適化
Kubecost	ラベルによる Kubernetes のコスト配分

検証ツール（デプロイ前）

ツール	目的
Checkov	IaC のタグ検証（pre-commit）
tflint	タグルールに関する Terraform の静的解析
terraform-compliance	タグポリシーの BDD テスト

追加リソース

詳細な実装ガイダンスについては、以下を参照してください。

• タグの分類体系とカテゴリ：references/tag-taxonomy.md を参照
• 適用パターン（AWS、Azure、GCP、K8s）：references/enforcement-patterns.md を参照
• コスト配分の設定：references/cost-allocation.md を参照
• コンプライアンス監査クエリ：references/compliance-auditing.md を参照
• Terraform の例：examples/terraform/ を参照
• Kubernetes マニフェスト：examples/kubernetes/ を参照
• 監査スクリプト：scripts/audit_tags.py、scripts/cost_by_tag.py を参照

重要なポイント

1. まず必須の「ビッグシックス」タグから始めます：Name、Environment、Owner、CostCenter、Project、ManagedBy
2. 作成時に適用します：AWS Config、Azure Policy、GCP の組織ポリシーを使用して、タグのないリソースをブロックします
3. IaC で自動化します：Terraform／Pulumi のデフォルトタグにより、手動エラーを 95% 削減できます
4. コスト配分を有効にします：請求タグを有効にすると、未配分の支出を 80% 削減できます
5. 命名規則を 1 つ選びます：PascalCase、小文字、またはケバブケースを選び、一貫して適用します
6. 親からタグを継承します：リソースグループ、フォルダー、名前空間からタグが自動的に伝播されます
7. 定期的に監査します：週次のタグコンプライアンスチェックで、設定のずれを検出し、拡散を防ぎます
8. タグの継承で作業量を削減します：親リソースから共通タグを子リソースに伝播させます