データサイエンティスト・MLエンジニア向け Cloud Run IAM設定ガイド

Cloud Run は機械学習モデルの推論APIやバッチ処理パイプラインをデプロイするのに適したサーバーレスプラットフォームです。スケールアウト/インが自動で、GPUも利用可能になりました。

しかし、GCPのIAM（権限管理）はインフラ専門外のデータサイエンティストやMLエンジニアにとって分かりにくいポイントです。本記事では、デプロイに必要な設定を簡潔にまとめました。

想定ユースケース

• FastAPI + PyTorch/TensorFlow での推論API
• Hugging Face Transformers モデルのサービング
• 定期実行のバッチ推論パイプライン（Cloud Scheduler連携）
• Vertex AI Pipelines の代替としての軽量パイプライン

デプロイの仕組み

gcloud run deploy --source は内部で以下の処理を行います：

flowchart LR
    Source["ソースコード"] -->|アップロード| Build["Cloud Build"]
    Build -->|push| AR["Artifact Registry"]
    AR -->|デプロイ| CR["Cloud Run"]

各ステップで異なる権限が必要です。

注意点（2025年時点）

Cloud Build のデフォルト SA が変更された

2024年5月以降に作成されたプロジェクトでは、Compute Engine Default SA がデフォルトで使用されるようになりました（それ以前のプロジェクトでは PROJECT_NUMBER@cloudbuild.gserviceaccount.com が使われている場合があります）。

また、セキュリティ強化のため、新しいプロジェクトでは Compute Engine Default SA に Editor 権限が付与されていない ケースがあります。そのため、「デフォルトSAだから何でもできる」と思い込まず、後述のコマンドで明示的に権限を付与することが重要です。

必ず以下で現在の設定を確認してください：

gcloud builds get-default-service-account --project=YOUR_PROJECT_ID
# 出力例: 123456789-compute@developer.gserviceaccount.com (または @cloudbuild...)

Cloud Scheduler と アプリ認証は別物

Cloud Scheduler の OIDC 認証は Cloud Run の IAM を通過しますが、アプリケーション内の認証（Supabase JWT など）は通過しません。詳細は「Cloud Scheduler 連携」セクションを参照してください。

組織ポリシーによる制限

企業環境では allUsers への権限付与が組織ポリシーで禁止されていることがあります。この場合、--allow-unauthenticated は使用できず、OIDC 認証での連携が必要です。

---

サービスアカウントの確認

Cloud Build が使用するサービスアカウントを確認します：

gcloud builds get-default-service-account --project=YOUR_PROJECT_ID
# 出力例: 123456789-compute@developer.gserviceaccount.com

このサービスアカウント（Compute Engine Default SA）に権限を付与します。

権限設定

必要な権限一覧

設定コマンド

PROJECT_ID="your-project-id"
# Cloud Build が使用する SA を動的に取得
SA=$(gcloud builds get-default-service-account --project=$PROJECT_ID)

# プロジェクトレベル権限の付与
for ROLE in roles/logging.logWriter roles/run.admin roles/iam.serviceAccountUser \
            roles/storage.objectViewer roles/storage.objectCreator; do
  gcloud projects add-iam-policy-binding $PROJECT_ID --member="serviceAccount:$SA" --role="$ROLE"
done

# Artifact Registry 権限（リポジトリ単位）
# ※リポジトリが存在しない場合は、初回の gcloud run deploy --source で作成されます
gcloud artifacts repositories add-iam-policy-binding cloud-run-source-deploy \
  --location=asia-northeast1 --member="serviceAccount:$SA" \
  --role="roles/artifactregistry.writer" --project=$PROJECT_ID

デプロイ

認証必須（デフォルト）

gcloud run deploy SERVICE_NAME --source ./backend --region asia-northeast1 --port 8000

公開API

gcloud run deploy SERVICE_NAME --source ./backend --region asia-northeast1 --port 8000 \
  --allow-unauthenticated

注意: 組織ポリシーで allUsers が制限されている場合、--allow-unauthenticated はエラーになります。

Cloud Scheduler 連携

バッチ推論やモデル再学習の定期実行には Cloud Scheduler を使用します。認証には OIDC トークンを利用します。

PROJECT_ID="your-project-id"

# サービスアカウント作成
gcloud iam service-accounts create cloud-scheduler-invoker \
  --display-name="Cloud Scheduler Invoker"

# Cloud Run 呼び出し権限付与
gcloud run services add-iam-policy-binding SERVICE_NAME \
  --region=asia-northeast1 \
  --member="serviceAccount:cloud-scheduler-invoker@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/run.invoker"

# ジョブ作成
gcloud scheduler jobs create http JOB_NAME \
  --location=asia-northeast1 \
  --schedule="0 * * * *" \
  --uri="https://SERVICE_URL/api/endpoint" \
  --http-method=POST \
  --oidc-service-account-email="cloud-scheduler-invoker@$PROJECT_ID.iam.gserviceaccount.com" \
  --oidc-token-audience="https://SERVICE_URL"

IAM認証とアプリ認証の分離

Cloud Scheduler の OIDC トークンは Cloud Run IAM を通過しますが、アプリ内の JWT 認証は通過しません。Scheduler 専用エンドポイントを用意してください：

# 管理画面用（JWT必須）
@router.post("/api/admin/process")
async def admin_process(user = Depends(require_auth)): ...

# Scheduler用（IAM認証のみ）
@router.post("/api/scheduler/process")
async def scheduler_process(): ...

トラブルシューティング

IAM 変更の反映には最大7分かかります。

---

参考リソース

技術の進歩やセキュリティ仕様の変更が早いため、最新の情報については必ず以下の公式ドキュメントを参照してください。

• Cloud Build サービスアカウントの変更点
  • Cloud Build サービスアカウントの変更について
    ※2024年5月以降の新規プロジェクトにおけるデフォルトSAの変更内容と、組織ポリシーによる制限について詳しく解説されています。
• IAM ロールの詳細
  • Cloud Run の IAM ロール
    roles/run.admin や roles/run.invoker など、各ロールが持つ具体的な権限を確認できます。
• デプロイ方法の比較
  • ソースコードからのデプロイ（gcloud run deploy --source）
    本記事で紹介した「ソースから直接デプロイ」する場合の、裏側での Artifact Registry や Cloud Build の動きが詳しく説明されています。
• Cloud Scheduler 認証の仕組み
  • HTTP ターゲットによる認証の構成
    OIDC トークンを用いたセキュアなジョブ実行の構成方法についてのガイドです。
• 組織ポリシー
  • ドメイン制限付き共有（allUsers の制限）
    企業アカウントで --allow-unauthenticated がエラーになる根本的な理由である組織ポリシーについての解説です。