Google Cloud APIs

解決する課題

コンソール画面を手で操作せずに、Google Cloud の機能をコードや自動化から一貫した方法で呼び出せます。

• VM やバケットなどを手作業ではなく自動で作成・管理したい → 各サービスの API を呼び出して操作する
• どのプロジェクトでどの機能を使えるかを制御したい → 必要な API だけをプロジェクトで有効化する
• 認証・認可の方式がサービスごとにバラバラだと困る → IAM とトークンに基づく統一された認証で扱える
• 過剰な呼び出しや暴走からシステムを守りたい → 割り当て（クォータ）で利用上限を管理する
• gcloud CLI や Terraform、各言語の SDK を使いたい → これらはすべて Google Cloud APIs の上に構築されている

主要概念と用語

• API（サービス）: 各 Google Cloud プロダクトが公開するプログラム的インターフェース。compute.googleapis.com のように、サービスごとに一意のサービス名（エンドポイント名）を持つ
• API ライブラリ: コンソール上で利用可能な API を検索・有効化する画面。AWS には直接の相当物がなく、GCP 特有の「サービスごとの有効化」モデルを支える
• API の有効化（Enablement）: そのプロジェクトで特定の API を使えるようにする操作。有効化していない API は呼び出せない。Service Usage が管理する
• Service Usage API: API の有効化・無効化・有効化状態の確認自体を行うメタ的な API。サービス名は serviceusage.googleapis.com
• API Discovery Service: 利用可能な API のメタデータ（メソッドやパラメータの定義）を機械可読な形で提供する仕組み。クライアントライブラリ生成の基盤
• 認証情報（Credentials）: API 呼び出し時の本人確認に使う。サービスアカウント、ユーザー認証（OAuth トークン）、API キーなどがある
• API キー: 呼び出し元プロジェクトを識別する単純な文字列。認可（誰が何をできるか）は行わないため、用途が限られる
• 割り当て（Quota）: API ごとの呼び出し回数やリソース量の上限。レート制限と容量制限を含む
• REST と gRPC: ほとんどの API は HTTP/JSON ベースの REST と、高性能な gRPC の両方で提供される

仕様・制限・クォータ

• API の有効化はプロジェクト単位。同じ API でもプロジェクトごとに個別に有効化・無効化する
• 一部の基盤的な API は、新規プロジェクトで既定で有効になっている。それ以外は使う前に明示的に有効化が必要
• API には依存関係があり、ある API を有効化すると、その動作に必要な別の API も併せて有効化されることがある
• 呼び出しには**割り当て（クォータ）**が課される。レート（一定時間あたりの回数）と容量（同時に持てるリソース数など）の両面で上限があり、必要に応じて引き上げを申請できる
• 認証は IAM と統合され、呼び出し元の権限（ロール）に基づいて操作の可否が判定される。API キー単体では認可されない
• ほとんどの API は REST（HTTP/JSON）と gRPC で提供され、エンドポイントは サービス名.googleapis.com の形式
• 具体的な既定有効 API の一覧や割り当て数値は変動するため、最新は公式ドキュメントで確認する

内部の仕組み

Google Cloud APIs は、各サービスの前段に共通のフロントエンド層を置き、認証・認可・割り当て・課金・ロギングを横断的に処理します。

1. クライアント（gcloud・SDK・直接の HTTP/gRPC）が サービス名.googleapis.com のエンドポイントへリクエストを送る
2. 共通基盤が認証情報を検証し、API が当該プロジェクトで有効化されているかを Service Usage で確認する
3. IAM で操作の認可を判定し、割り当てに照らして上限超過がないかをチェックする
4. 問題なければ各サービスの実装へ転送し、結果を返す。同時に監査ログや利用量が記録される

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

• 必要な API だけを有効化する: 使わない API は無効のままにし、攻撃面と想定外利用を減らす
• IaC で有効化を管理する: Terraform などで API の有効化をコード化し、プロジェクト構築時に再現性を持たせる
• 認証はサービスアカウントを基本に: 自動化処理ではユーザー認証ではなくサービスアカウントを使い、最小権限のロールを与える
• API キーは限定用途に: 認可しないため、ブラウザ向けマップ表示など限られたケースに留め、必ずキーの制限（参照元・対象 API）をかける
• 割り当てを監視し早めに引き上げ申請: 上限到達でエラーになる前に使用率を監視し、必要なら引き上げを申請する
• 再試行とバックオフを実装: レート超過や一時的エラーに備え、指数バックオフ付きの再試行をクライアントに組み込む

運用・監視

• API ダッシュボードで利用状況を把握: 有効化済み API ごとのトラフィック、エラー率、レイテンシ、割り当て使用率を確認する
• 割り当て使用率にアラート: 上限に近づいたら通知し、エラー多発の前に対処する
• Cloud Audit Logs で操作を追跡: 誰がいつどの API を呼んだかを監査ログで記録・調査する
• エラーコードを切り分ける: 認証エラー、API 未有効化、権限不足、割り当て超過は原因が異なるため、レスポンスを見て切り分ける
• 依存 API の有効化漏れに注意: 新機能でエラーが出たら、必要な API が有効化されているかをまず確認する

コスト

Google Cloud APIs という共通基盤の利用、すなわちAPI の有効化・認証・割り当て管理そのものには料金はかかりません。課金されるのは、API を通じて実際に作成・利用した各サービスのリソース（Compute・Storage など）の使用量です。つまり「API を呼ぶこと」自体ではなく「API で何をしたか」に対して費用が発生します。なお、一部のサービスは API 呼び出し回数や処理量に応じて課金されるため、具体的な課金単位は各サービスの料金体系に従います。

セキュリティ

• 未使用 API は有効化しない: 有効化した API は攻撃面になり得る。必要最小限に絞る
• IAM で認可を統制: 呼び出し元のサービスアカウント・ユーザーに最小権限のロールだけを付与する
• API キーは認可しないと理解する: API キーは呼び出し元の識別のみで、権限制御は IAM が担う。キーには必ず参照元・対象 API の制限をかけ、漏えい時の影響を抑える
• 認証情報を安全に保管: サービスアカウントキーの常用は避け、可能ならキーレス（ワークロード ID 連携など）の手段を選ぶ
• 監査ログを有効化: データアクセスを含む監査ログで、API 経由の操作を追跡できるようにする

関連サービス・比較

API の利用を本格的に「公開・運用」する段階では、API Gateway や Apigee といった API 管理製品が関わります。Google Cloud APIs がGoogle 自身のサービスを呼ぶための基盤であるのに対し、API Gateway / Apigee は自分たちが作った API を外部に公開・保護・収益化するための製品で、役割が異なります。

ハンズオン / CLI例

# 利用可能な API を検索（例: compute を含むもの）
gcloud services list --available --filter="compute"

# プロジェクトで Compute Engine API を有効化
gcloud services enable compute.googleapis.com --project=my-project

# 現在有効化されている API を一覧
gcloud services list --enabled --project=my-project

# API の有効化状態を確認（Service Usage 経由）
gcloud services list --enabled --filter="config.name:compute.googleapis.com"

# 不要になった API を無効化（依存関係に注意）
gcloud services disable cloudtrace.googleapis.com --project=my-project

# API キーを作成し対象 API を制限（認可は IAM が担う点に注意）
gcloud services api-keys create \
  --display-name="maps-frontend-key" \
  --api-target=service=maps-backend.googleapis.com