1. はじめに (結論)

Google Tag Manager (GTM) の運用において、最大の懸念事項の一つが「ユーザー権限の管理」です。代理店、外部協力会社、社内各部署が入り乱れる現場では、「権限の付与・剥奪漏れ」は避けられないヒューマンエラーとなっていました。

本プロジェクトでは、この課題を解決するために GTM 権限管理に特化したカスタム Terraform プロバイダと、それを取り巻くエコシステム を構築しました。

得られた成果

• 有効期限の自動制御: valid_from / valid_until をコードで定義し、期限が来れば自動的に権限を一時停止（PAUSED）。
• 強力な監査性: Git のレビュー・コミットログがそのまま「誰がいつ、なぜ権限を操作したか」の証跡になる。
• 安全な IaC 化: 既存の膨大な権限設定を 1 コマンドでエクスポートし、そのまま import 可能なツールにより、ダウンタイムゼロで IaC 移行を実現。

2. GTM 運用における課題と IaC 化の動機

現場で起きていた「権限管理の負債」

GTM の管理画面（GUI）は直感的ですが、プロジェクトがスケールするにつれて以下の課題が顕在化します。

1. 期間限定アクセスの「剥奪忘れ」: 短期プロジェクト用の付与が、半年後も残されたままになっている。これを手動で追い続けるのは不可能に近い。
2. 監査の困難さ: 「今、誰がどのコンテナにアクセスできるか」を一覧化するには、全アカウント・全コンテナを GUI でポチポチと確認する必要があり、人的コストが非常に高い。
3. 誤設定リスク: GUI での変更は「前の状態」を正確に記録できないため、万が一誤った権限を付与しても気づきにくい。

これらの課題に対し、「適切な技術を使って、最小限の労力で最大限の効果（ガバナンス）を生む」 というエンジニアリング的アプローチで挑みました。

3. 具体的な技術構成とアーキテクチャ

単に Terraform を使うだけでなく、周辺ツールを Go で実装することで「運用に耐えうる IaC」を実現しました。

システム概要図

システムを支える「4 つの柱」

1. Custom Terraform Provider (Go)

• HCL 上で valid_until を指定すると、プロバイダが現在時刻と比較して、裏側で API 経由で権限を一時停止（コンテナアクセス権の削除）します。

2. HCL Generator (エクスポートツール)

• GTM API から既存の全設定を取得し、モジュール形式の HCL を自動生成。Terraform 1.5+ の import ブロックにも対応しています。

3. Plan Validator (validate_plan)

• 「一度 PAUSED になったユーザーを、管理者がこっそり日付を変えて ENABLED に戻す」といった不正な状態遷移を Plan JSON の段階で検知します。

4. Emergency Stop (緊急停止ツール)

• 指定したユーザーの権限を HCL ファイルレベルで即座に書き換え、最短で適用まで繋げるファストパスです。

4. 技術的な検討点とハマりどころ

1. GTM API の二段階構造

ユーザー権限の変更にはアカウント管理者権限が必要です。過剰権限リスクに対し、プロバイダ側で 「操作可能なコンテナをホワイトリスト形式で制限する」 機能を実装しました。

2. CustomizeDiff で実現する「将来のステート予測」

Terraform は通常「今の状態」を管理しますが、今回は「未来の期限切れ」を扱う必要があります。CustomizeDiff を使い、期限が切れる場合に status を PAUSED として Plan 上に表示させます。

3. インポート時の ForceReplace 回避

API データと HCL 定義の微小な差によるリソース作り直しを防ぐため、ImportState での ID 正規化と DiffSuppressFunc を多用しました。

4. リザレクション（勝手な復活）防止

過去に無効化したユーザーの設定ミスによる再有効化を防ぐため、CI に独自のバリデーターを組み込みました。

5. 完成したシステムでの運用フロー

• 権限変更: 管理者が GitHub で PR を作成。自動 Plan と validate_plan によるチェックを経てマージ・適用。
• マルチアカウント管理: ディレクトリを増やすだけで GitHub Actions が自動検出し並列実行。
• 棚卸しの自動化: audit_report で有効な権限と期限切れ間近のユーザーを Slack 通知。

作成されたコードの例

実際に管理されるGTMアカウントは以下のtfファイルとして作成されます。

terraform {
　　required_providers {
　　　　gtmgovernance = {
　　　　　　source = "local/kiyono/gtm-governance"
　　　　　　version = "1.0.0"
　　　　}
　　}
}

provider "gtmgovernance" {
　　account_id = "100000000"
　　allowed_containers = ["GTM-ABCDEF0"] # ここで指定されたコンテナにのみ操作を実施
}

module "user_test_gtm_pxb89mng" {
　　source = "../../../modules/user_permission"
　　email = "test@kiyono-co.jp"

　　gtm_access = {
　　　　container_id = "GTM-ABCDEF0"
　　　　role = "publish"
　　}
}

6. 次にやりたいこと (今後の展望)

• GA4 への対応: Google Analytics 4 のプロパティ権限も一元管理。
• Slack 連携の強化: 期限切れ直前のユーザー本人への自動通知。
• 自動削除サジェスト: 期限が大幅に過ぎたコードを自動で削除する PR 作成ボット。

7. おわりに：技術者が担うべき役割

私たちが目指すべきなのは、適切な技術（IaC や自動化）を駆使することで、現場の労力を最小限に抑えつつ、最大限の統制効果を得る ことです。「管理されている安心感」がありながら、変更はこれまで以上にスムーズに行える。そんなシステムを構築することこそが、エンジニアとしての醍醐味だと感じています。

最後までお読みいただきありがとうございました。