Google Cloudの再ログイン間隔をグループ別に決める

外部の制作会社や開発者にGoogle Cloudのプロジェクト権限を渡していて、その人たちのログイン状態がいつまで続くのかを把握していない。請求の管理者もデータ分析の担当者も、同じ組織部門（OU）にいるので同じ扱いになっている。これまでセッションの長さはOUに紐づいていたため、OUの構成と別に対象を決められませんでした。

Googleは2026年9月16日の公式ブログで、Google Cloudのセッション制御（一定時間ごとに再認証を求める設定）を、Googleグループ単位・アプリ単位で指定できるようにしたと発表しました。ブログとAccess Context Manager APIの仕様を読み、Workspace管理者が先に決めておくことを整理します。

9月16日の発表で変わったこと

ブログによると、自分でセッションの長さを設定していなかった組織には、16時間の既定値の適用が完了しています。そのうえで、セッション制御はContext-Aware Access（アクセスできる条件を絞る仕組み）の一部として、次のように細かく指定できるようになりました。

ブログは例として、請求の管理者やプロジェクトのオーナーなど権限の強い人には2時間、一般の開発者には16時間のセッションを、組織の階層とは関係なく割り当てる使い方を挙げています。アプリ単位の指定は、Cloud SDKに厳しい設定をかけたせいで、OAuthでつないだBIやダッシュボードまで止まる事態を避けるためと説明されています。

APIの仕様で見る設定の中身

設定の実体は、Access Context Manager APIの GcpUserAccessBinding です。Discoveryドキュメント（revision 20260916）とTerraformのGoogleプロバイダーのドキュメントから、セッションに関わる項目を抜き出しました。

• groupKey：対象のGoogleグループ。Terraformのドキュメントには「グループのメールアドレスやエイリアスは受け付けない」とあり、Directory APIで取得できるグループのIDを指定します
• sessionSettings：セッションの長さ（sessionLength）、切れたときの再認証の方法（sessionReauthMethod：LOGIN・SECURITY_KEY・PASSWORD）、操作の間隔の上限（maxInactivity、Google Cloudのアプリのみ）など
• scopedAccessSettings：アプリやプロジェクトを指定して、その範囲だけ別の設定を当てるための項目。アプリはOAuthクライアントIDか名前（例：「Cloud Console」）で指定します

sessionLength を0にする場合は、sessionLengthEnabled を false にする必要があります。sessionLengthEnabled を false にすると他の項目は無視され、セッションは事実上無期限になります。Terraformでは organization_id が必須で、Google Cloudの「組織」リソースがあることが前提です。

resource "google_access_context_manager_gcp_user_access_binding" "admins" {
  organization_id = "123456789"
  group_key       = "01d520gv4vjcrht" # グループID（メールアドレスは不可）
  session_settings {
    session_length         = "7200s"
    session_reauth_method  = "SECURITY_KEY"
    session_length_enabled = true
  }
}

上の例は、Terraformのドキュメントにある項目を組み合わせた記述例です。編集部は実際の組織に適用していません。session_length の書式（秒数の文字列）も、APIの Duration 型の一般的な書き方に合わせたもので、プロバイダーのドキュメントの例ではありません。

設定する前に決めること

ここからは編集部の整理です。

1. 権限の強い人をグループにまとめる。 請求の管理者、プロジェクトのオーナー、IAMを変更できる人です。OUと別に管理できるようになったので、部署の異動とは独立して見直せます。権限の棚卸しはContext-Aware Accessの考え方と同じ順序で進められます
2. 外部の協力者を別のグループにする。 制作会社や開発パートナーのアカウントは、社員と同じ設定にする理由がありません
3. 止めてはいけない連携を洗い出す。 OAuthでつないだBIツールやスクリプトが、セッションの切れ目で止まらないかを確かめ、必要ならアプリ単位で除外・調整します
4. 再認証の方法を決める。 SECURITY_KEY を選ぶなら、対象者全員がセキュリティキーを持っている必要があります

16時間の既定値がいつ自分の組織に適用されたかは、ブログに日付がありません。Google Workspace側の既定値の変更は2026年のセキュリティ既定値の変更でまとめています。

落とし穴

• グループをメールアドレスで指定する。 Terraformではグループのメールアドレスやエイリアスを受け付けません
• テスト運用（dry run）でセッションを試せると思う。 Terraformのドキュメントでは、アプリ単位の設定の dry_run_settings に「セッションの設定は含められない」とあります
• 0時間を「無効」のつもりで入れる。 sessionLength が0のときは sessionLengthEnabled を false にする必要があり、その場合はセッションの制限そのものがなくなります

2026年10月3日に、Google Cloud公式ブログ「Introducing new session management tools with native, granular controls」（2026年9月16日）、Access Context Manager API v1のDiscoveryドキュメント（revision 20260916）、hashicorp/terraform-provider-googleの google_access_context_manager_gcp_user_access_binding のドキュメントを直接開いて照合しました。公開前の2026年10月5日に、ブログ・Discovery・Terraformのドキュメントを開き直し、記載が変わっていないことを確かめました。管理コンソールのヘルプ「Set session length for Google Cloud services」も開けましたが、OU単位の設定手順の説明で、グループ単位の設定や対象エディションの記載は見当たりませんでした。対象エディションや料金、管理コンソールの画面は確認していません。実際の組織への設定は行っていません。

Google WorkspaceとGoogle Cloudの権限・ログインの設計は、IT・Google Workspaceのご相談からお問い合わせください。

Sources

• Introducing new session management tools with native, granular controls — Google Cloud Blog
• Access Context Manager API v1 — Discovery document
• hashicorp/terraform-provider-google — google_access_context_manager_gcp_user_access_binding