Service Usage

解決する課題

Google Cloud では、どのプロジェクトでも全 API が最初から使えるわけではありません。Service Usage は「このプロジェクトでどのサービス／API を使えるようにするか」を制御する基盤で、利用前の有効化、不要な API の無効化、有効状態の棚卸しを一元的に扱えます。

• ある API を呼び出したら「API が有効化されていない」というエラーになり、まず有効化が必要だった
• 多数のプロジェクトで、使う API だけを揃えて有効化し、不要なものは閉じておきたい
• 攻撃面を減らすため、使っていない API は無効化して呼び出せない状態にしたい
• どのプロジェクトでどのサービスが有効になっているかを一覧で把握し、棚卸ししたい
• 組織として「特定の API は有効化させない／このリストだけ許可する」と統制したい

主要概念と用語

• サービス（Service）: Google Cloud の各プロダクトが公開する API の単位。compute.googleapis.com のようにサービス名（多くは API エンドポイントのホスト名）で識別する
• 有効化（Enable）／無効化（Disable）: プロジェクトでそのサービスを呼び出せる状態にする／呼び出せない状態にする操作。有効化して初めて API リクエストが受け付けられる
• 有効化済みサービス（Enabled Services）: そのプロジェクトで現在有効になっているサービスの集合。一覧取得や棚卸しの対象になる
• 依存関係（Dependency）: あるサービスを有効化すると、その動作に必要な別のサービスも合わせて有効化されることがある。逆に無効化が依存先に波及する場合もある
• コンシューマー（Consumer）: サービスを利用する側の単位。通常はプロジェクトを指し、有効化やクォータはこのコンシューマー単位で管理される
• クォータ（Quota）: サービスごとに定められた利用上限。Service Usage はクォータの参照・管理の入り口にもなり、有効化はクォータ消費の前提になる
• Service Usage API: 有効化・無効化・一覧取得などをプログラムから行うための API。gcloud services コマンドや各種クライアントの裏側で使われる

仕様・制限・クォータ

• 操作単位はプロジェクト（コンシューマー）。サービスの有効化・無効化は各プロジェクトに対して行い、その範囲で効く
• API は有効化されて初めて呼べる。未有効のサービスへのリクエストは拒否され、有効化を促すエラーが返る
• 依存サービスが連動する。あるサービスを有効化すると依存先も自動で有効化され、無効化しようとすると依存している側との関係で制限がかかることがある
• 一度に有効化・無効化できるサービス数や、一覧取得時のページングなど、API 側の制約がある。正確な上限は変動するため公式ドキュメントで確認する
• 設定の反映は短時間で伝播するが、有効化直後はわずかに初期化の時間を要する場合がある。即時保証ではない前提で運用する
• Service Usage 自体は API を「使えるようにするゲート」であり、各サービスの実際の利用料金やクォータは個々のサービス側に従う

内部の仕組み

API 呼び出しが来ると、対象プロジェクトでそのサービスが有効化されているかが確認され、無効なら呼び出し自体がブロックされます。

1. クライアントが gcloud services enable などでサービスの有効化をリクエストする
2. Service Usage が対象サービスとその依存サービスを解決し、プロジェクト（コンシューマー）に対して有効化済みの状態として登録する
3. 以降、そのプロジェクト宛ての API リクエストは「有効化済みか」をチェックされ、有効ならサービス側へ通り、クォータ評価などへ進む。無効なら拒否される

設計パターン / ベストプラクティス

• 必要な API だけを有効化する: プロジェクト作成時に使うサービスを明示的に有効化し、不要なものは閉じておく。攻撃面と管理対象を最小化する
• IaC で有効化を宣言する: 有効化するサービス一覧をコード化（Terraform 等）し、プロジェクトの再現性とレビュー可能性を確保する
• 依存関係を前提に設計する: 依存サービスが連動して有効化される点を踏まえ、無効化時の影響範囲を事前に洗い出す
• 組織ポリシーで統制する: 「有効化を許可するサービスのリスト」「無効化を禁止するサービスのリスト」を組織ポリシーで縛り、各プロジェクトで勝手に危険な API を開かせない
• 棚卸しを定期化する: 有効化済みサービスを定期的に一覧し、使われていない API を整理する

運用・監視

• 有効化・無効化の操作は Cloud Audit Logs に記録される。誰がいつどのプロジェクトでどのサービスを開いた／閉じたかを監査できる
• 有効化済みサービスの一覧を定期取得し、想定と差分がないか棚卸しする。IaC の宣言とのドリフト検知にも使う
• API 呼び出しが「サービス未有効」で失敗する場合は、まず対象プロジェクトで該当サービスが有効化されているかを確認する。クォータ超過とは原因が異なる点に注意する
• 無効化に伴う障害を防ぐため、本番での無効化は依存関係の確認 → 影響範囲の特定の順で慎重に進める

コスト

Service Usage の利用自体（サービスの有効化・無効化・一覧取得・状態管理）は無料です。料金が発生するのは、有効化した各サービスを実際に使ったときの、そのサービス側の利用料です。有効化しているだけで使っていなければ、原則として Service Usage を理由とした課金は発生しません。

セキュリティ

• 使わない API は無効化する: 有効化された API は呼び出し可能な攻撃面になる。利用しないサービスは閉じ、必要最小限だけ開く
• 有効化・無効化の権限を絞る: サービスの有効化を行えるロール（roles/serviceusage.serviceUsageAdmin 系）は限られた管理者だけに付与し、勝手に危険な API を開かせない
• 組織ポリシーで予防的に統制: 有効化を許可／拒否するサービスのリストを組織ポリシーで定義し、人の注意力に頼らず構造的に制御する
• 監査で追跡可能にする: 有効化・無効化の変更を Audit Logs で追い、不正・誤操作を検知できる状態にしておく

関連サービス・比較

Service Usage は「API を使えるようにするゲート」、IAM は「誰がその API を呼べるか」を制御します。両者は別軸で、API 呼び出しが通るには両方を満たす必要があります。

ハンズオン / CLI例

# 現在のプロジェクトで有効化済みのサービスを一覧する
gcloud services list --enabled

# 有効化できるサービス（利用可能な API）を検索する
gcloud services list --available

# Compute Engine API を有効化する
gcloud services enable compute.googleapis.com

# 複数の API をまとめて有効化する
gcloud services enable run.googleapis.com artifactregistry.googleapis.com

# 使わない API を無効化する（依存先への影響に注意）
gcloud services disable compute.googleapis.com