GCP組織ポリシーを開けっぱなしにしない｜タグ方式で最小権限を保つ認証設計【AI活用検証vol.78】

Google Drive APIを使う自動化を作ろうとすると、必ず認証で止まります。そして「動かないから組織ポリシーをOFFにする」という対処をしてしまうと、組織全体が開けっぱなしになります。

この検証では、その状態から最小権限を実現するタグ方式への移行方針を整理しました。あわせてWIF（キーレス認証）が使えるプラットフォームと使えないプラットフォームも切り分けています。

この検証の概要

結論：組織ONのまま、タグで個別に除外する

GCP組織ポリシーの階層と上書きルールを整理すると、こうなります。

組織レベルで Enforce=ON  → プロジェクト単位での上書きは不可能
組織レベルで Enforce=OFF → 全プロジェクトが解放される（開けっぱなし）
正解: 組織ON + タグ方式で特定SAのみ除外

「プロジェクト単位で解除すればいい」という発想は通りません。組織レベルで強制されている場合、プロジェクトからの上書きはできない仕様です。

結果として、動かすには組織レベルをOFFにするしかなく——そうすると全プロジェクトが解放されます。これが多くの人が陥る状態です。

正解はGoogleが公式に推奨するタグ方式です。組織全体はONに戻したうえで、必要なサービスアカウントだけをタグで個別に除外します。

なぜこの問題が起きるのか

背景には仕様変更があります。

2024/05/03: 新規作成組織で disableServiceAccountKeyCreation がデフォルトON（強制）に変更
2024/06/16: 漏洩キーの自動無効化もデフォルト化
→ この日以降に作ったGCP組織では初期状態でキー作成不可

この日以降に作られた組織では、サービスアカウントキーが最初から作れません。以前の手順書どおりに進めても止まります。

もうひとつ注意点があります。Double-lockです。

iam.disableServiceAccountKeyCreation（新）
iam.disableServiceAccountKeyCreation（legacy）
の2つが存在しており、両方解除しないと動かない場合がある

タグ方式の移行手順

前提として、組織レベルで次のロール付与が必要です（プロジェクトレベルでは付与不可）。

roles/orgpolicy.policyAdmin    （組織ポリシー管理者）
roles/resourcemanager.tagAdmin （タグ管理者）

1. タグキーとタグ値を作成 — キー: disableServiceAccountKeyCreation／値: enforced（禁止）と not_enforced（許可）
2. 組織にデフォルトタグ（enforced）を付与
3. 対象サービスアカウントに除外タグ（not_enforced）を付与
4. 組織ポリシーを条件付きルールに更新 — 条件付きルールで resource.matchTag(...) が not_enforced のとき「強制しない」、デフォルトルールで「強制する」
5. 組織レベルのポリシーをONに戻す

ここで最も重要なのが作業順序です。

❌ NG: 組織ON → タグ設定（この間に既存キーが無効化される）
✅ OK: タグ作成 → SAにタグ付与 → 条件ポリシー設定 → 組織ON

順序を間違えると、既存のキーが無効化されて動いていたものが止まります。セキュリティ設定の変更では、締める前に例外を通しておく順番が必要です。

WIFが使える環境・使えない環境

実行環境の選定に直結する切り分けです。

✅ 使える: GitHub Actions, GitLab CI/CD, AWS EC2, Azure VM
❌ 使えない: Render, Fly.io, Railway, Cloudflare Workers, その他一般PaaS

WIF（Workload Identity Federation）はOIDCトークンの発行が前提です。一般的なPaaSはOIDCトークンを発行しないため、使えません。

この事実が、実行環境の選定を左右します。

キーが存在しなければ、漏洩のしようがありません。WIFが使えるならそちらを選ぶのが基本です。

GitHub Actionsで使う場合、ワークフローに id-token: write の権限指定が必須になります。

permissions:
  contents: read
  id-token: write    # OIDCトークン発行に必須

サービスアカウントキーを使う場合の運用ルール

WIFが使えない環境では、キー方式になります。その場合に守るルールを整理しました。

1. 1 SA = 1キーのみ（複数キーを持たない）
2. スコープは drive.file のみ（drive 全体は付与しない）
3. JSONキーはコードに直書きしない（環境変数で管理）
4. .gitignore に *.json を追加してコミット防止
5. キーは90日でローテーション（GCPコンソールで有効期限設定）
6. 不要になったキーはすぐ削除
7. 漏洩検知の自動無効化設定（iam.serviceAccountKeyExposureResponse）を有効に保つ

スコープについて補足があります。drive.file スコープはアプリが作成したファイルのみアクセス可能です。既存のDriveファイルへの読み書きには drive または drive.readonly が必要になる場合があります。

クローリング側で分かったこと

認証以外の検証結果も記録しておきます。

• 対象サイトのHTML直接fetchが可能であることを実証（公式RSSがなくても対応可能）
• 一覧ページから記事URLを抽出し、個別記事本文を取得する二段構えfetchのロジックを設計
• 非公式RSSは実用不可 — 2025年11月以降更新停止、または403でアクセス不可
• Claudeのコンテナからの直接fetchは「Host not in allowlist」でブロックされる（実行環境の制約）

非公式RSSに依存する構成は壊れます。提供が止まっても誰も知らせてくれません。直接fetchのほうが、結果的に安定します。

Cloudflare Workersの無料枠を温存する

コスト設計の工夫も記録されています。

node-cronは使えない（常駐プロセスが存在しないため）
外部Cron（cron-job.org / GitHub Actions）が Worker の URL を HTTP GET で叩く
→ CronTrigger消費ゼロで同等の定期実行が実現できる

Cloudflare Workersの無料枠ではCron Triggerが5個/アカウントに制限されています。外部Cronから叩く形にすれば、この枠を消費せずに定期実行できます。

よくある質問

プロジェクト単位で組織ポリシーを解除できませんか？

できません。組織レベルで強制されている場合、プロジェクト単位での上書きは仕様上不可能です。組織をONにしたままタグ方式で個別に除外するのが正しい方法です。

サービスアカウントキーが作れません

2024年5月3日以降に作られたGCP組織では、キー作成がデフォルトで禁止されています。タグ方式で必要なサービスアカウントのみ除外してください。なお disableServiceAccountKeyCreation には新旧2つのポリシーが存在する場合があり、両方の対応が必要になることがあります。

WIFはどの環境で使えますか？

GitHub Actions、GitLab CI/CD、AWS EC2、Azure VMなどOIDCトークンを発行する環境です。Render、Fly.io、Railway、Cloudflare Workersなど一般的なPaaSでは使えません（2026年4月時点）。

タグ方式に移行する際の注意点は？

作業順序です。先に組織をONに戻すと、その時点で既存キーが無効化されます。タグ作成 → SAへのタグ付与 → 条件ポリシー設定 → 組織ON、の順で進めてください。

まとめ

• GCP組織ポリシーは組織レベルON時にプロジェクト単位での上書きが不可能。OFFにすると全プロジェクトが解放される
• 正解は組織ON + タグ方式で特定サービスアカウントのみ除外（Google公式推奨）
• 作業順序が重要。タグ作成 → SAにタグ付与 → 条件ポリシー設定 → 組織ON の順を守る
• WIF（キーレス認証）はOIDCトークン発行が前提。一般PaaSでは使えない
• キー方式なら1SA=1キー・drive.file スコープ限定・90日ローテーションを運用ルールにする
• 非公式RSSは壊れる。直接fetchのほうが結果的に安定する

自動化を作るとき、認証設定は「動けばいい」で済ませたくなる部分です。しかしそこで開けた穴は、全体に効いてきます。最小権限を保ったまま通す方法を先に確認しておくと、後から締め直す作業が不要になります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の業務自動化とセキュアな基盤づくりを支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。