API Gateway / Apigee

解決する課題

API 用のサーバーやプロキシを自前で運用したくない
認証（APIキー / JWT）・レート制限を共通の玄関で処理したい
Cloud Run / Cloud Functions などのバックエンドを安全に公開したい
社外・パートナー向けに API を製品として提供し、利用状況の可視化や収益化まで行いたい（→ Apigee）

主要概念と用語

API Gateway（軽量版）: OpenAPI 2.0（Swagger）仕様で API を定義し、Google が管理する Extensible Service Proxy V2（ESPv2 / Envoy ベース） を通してバックエンドへルーティングする
API / API Config / Gateway: API Gateway の3階層リソース。論理的な API に、OpenAPI で定義した API Config（イミュータブル）を紐づけ、リージョンに Gateway をデプロイする
APIキー: 呼び出し元アプリの識別・流量制御に使う。x-google-api-key などで検証
JWT 認証: securityDefinitions で発行者（issuer）と JWKS URI を指定し、Firebase / IAP / 自前 IdP などの JWT を検証
Apigee: フルスタックの API 管理。API プロキシ、ポリシー（Spike Arrest / Quota / OAuth など）、プロダクト、開発者ポータル、マネタイゼーションを備える
Apigee の Environment / Environment Group: プロキシのデプロイ先（dev/prod 等）と、ホスト名をまとめる単位

仕様・制限・クォータ

API Gateway はフルマネージドで自動スケール。バックエンドは Cloud Run / Cloud Functions / App Engine / 任意の HTTP(S) バックエンド
API Config は作成後に変更不可（イミュータブル）。更新時は新しい Config を作って Gateway に紐づけ直す
API Gateway は リージョナルリソース（Gateway はリージョンごとにデプロイ）。OpenAPI は 2.0 のみ対応（3.0 非対応）
既定のクォータ（プロジェクトあたりの API 数・Gateway 数など）があり、引き上げ申請が可能
Apigee は Pay-as-you-go と Subscription の課金体系があり、規模・SLA に応じてプロビジョニングする本格基盤

内部の仕組み

クライアント → API Gateway → バックエンド、という流れで、玄関で認証（APIキー / JWT）・流量制限・ルーティングを行います。API Gateway の実体は Google がマネージドで動かす **ESPv2（Envoy ベースのプロキシ）**で、開発者は OpenAPI 仕様を書くだけでプロキシの設定が生成されます。

API Gateway は軽量・低コストで、サーバーレス API の入口に向く
Apigee はプロキシの前後にポリシーを差し込めるパイプライン型。リクエスト/レスポンスの変換、OAuth トークン発行、メディエーション（REST↔SOAP 等）、キャッシュ、Spike Arrest（瞬間流量の平準化）など高度な制御が可能
バックエンドへの認証は、API Gateway のサービスアカウントを使って Cloud Run 等を IAM で保護した状態で安全に呼び出せる

API Gateway と Apigee の使い分け

シンプルにサーバーレス API を出すだけなら安価で軽量な API Gateway。収益化・開発者ポータル・高度なポリシー・大規模なライフサイクル管理が要るならApigee。両者は別プロダクトで、価格帯も大きく異なります。

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

API Gateway + Cloud Run / Cloud Functions でサーバーレス API を最短公開
バックエンドの Cloud Run は未認証アクセスを禁止し、Gateway のサービスアカウントにのみ roles/run.invoker を付与（玄関以外からは叩けないようにする）
認証は玄関に集約。社内向けは JWT、外部アプリ識別は APIキーを併用
グローバル配信や WAF が必要なら、前段に 外部 HTTP(S) ロードバランサ + Cloud Armor を併用
大規模・製品化フェーズに入ったら Apigee へ移行し、プロダクト/開発者ポータルでセルフサービス化

運用・監視・トラブルシュート

Cloud Monitoring / Cloud Logging でメトリクス（リクエスト数・レイテンシ・エラー率）とログを監視
API Gateway は Cloud Logging にアクセスログを出力。429（Too Many Requests）はクォータ/流量制限を確認
認証エラー（401 / 403）は OpenAPI の securityDefinitions、issuer/JWKS URI、APIキーの有効化状態を点検
Apigee は Analytics ダッシュボードでトラフィック・エラー・レイテンシ・デベロッパー別利用を分析できる

コスト

GCP では公開する規模で2つのプロダクトを使い分け、コストを最適化します。

プロダクト	課金の考え方	向いている用途
API Gateway	API 呼び出し回数に対する従量課金（安価）	サーバーレス API の軽量な公開
Apigee Pay-as-you-go	処理した API コール量に応じた従量課金	本格的な API 管理を小さく始める
Apigee Subscription	年間サブスクリプション（容量・SLA でプラン選択）	大規模・収益化・エンタープライズ

セキュリティ

APIキーで呼び出し元アプリを識別・制御、JWT（Firebase Auth / IAP / 自前 IdP）で利用者認証
バックエンドは IAM で保護し、Gateway のサービスアカウント経由でのみ呼び出す（直叩きを禁止）
通信は TLS。前段の外部 HTTP(S) LB と Cloud Armor で WAF・DDoS 緩和・IP 制限
Apigee では OAuth 2.0 / Spike Arrest / Quota などのポリシーで認可・流量を細かく制御

アンチパターン

バックエンドの Cloud Run / Cloud Functions を未認証（allUsers）で公開したまま Gateway を前に置くのは NG。玄関を迂回して直接叩かれます。バックエンドは IAM で閉じ、Gateway のサービスアカウントにのみ invoker 権限を与えてください。

観点	GCP	AWS
軽量なAPI公開	API Gateway（ESPv2 / Envoy）	Amazon API Gateway（HTTP API）
高機能なAPI管理	Apigee	Amazon API Gateway（REST API）+ 周辺
API定義	OpenAPI 2.0（Swagger）	OpenAPI 3.0 / コンソール
主なバックエンド	Cloud Run / Cloud Functions / App Engine	Lambda / HTTP 統合
利用者認証	JWT（Firebase/IAP/IdP）	オーソライザー（Cognito/Lambda）
呼び出し元識別	APIキー	APIキー / 使用量プラン
前段のWAF/配信	外部HTTP(S) LB + Cloud Armor	CloudFront + WAF

ハンズオン / CLI例

# 1) API（論理リソース）を作成
gcloud api-gateway apis create orders-api --project=PROJECT_ID

# 2) OpenAPI 2.0 仕様から API Config を作成（イミュータブル）
gcloud api-gateway api-configs create orders-config-v1 \
  --api=orders-api \
  --openapi-spec=openapi2.yaml \
  --backend-auth-service-account=gw-sa@PROJECT_ID.iam.gserviceaccount.com \
  --project=PROJECT_ID

# 3) Gateway をリージョンにデプロイして公開
gcloud api-gateway gateways create orders-gw \
  --api=orders-api \
  --api-config=orders-config-v1 \
  --location=asia-northeast1 \
  --project=PROJECT_ID

# 公開された Gateway のデフォルトホスト名を確認
gcloud api-gateway gateways describe orders-gw \
  --location=asia-northeast1 --project=PROJECT_ID \
  --format="value(defaultHostname)"