---
title: "GCP組織ポリシーを開けっぱなしにしない｜タグ方式で最小権限を保つ認証設計"
excerpt: "Google Drive APIを使う自動化で認証が通らず、組織ポリシーをOFFにして全プロジェクトが解放される——という状態から、Google公式推奨のタグ方式へ移行する設計を整理しました。作業順序を間違えると既存キーが無効化される点、WIF（キーレス認証）が使える環境と使えない環境の切り分けもまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-04-28T00:00:00+00:00
verified_at: 2026-04-28T00:00:00+00:00
tools: ["Google Cloud", "GitHub", "Cloudflare"]
tasks: ["開発・エンジニアリング", "ツール検証"]
canonical_url: https://ai-katsu.jp/articles/gcp-auth-security
---
# GCP組織ポリシーを開けっぱなしにしない｜タグ方式で最小権限を保つ認証設計

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

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

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2026年4月28日〜（検証中） |
| 上位の目的 | ニュースサイトを自動クローリングし、記事タイトル・本文・URLをGoogle Drive / Docsに自動格納するシステムを構築する |
| この検証の焦点 | APIキー直書き運用を脱し、セキュアな認証方式へ移行する／GCP組織ポリシーの正しい運用方法を理解する |
| 技術要素 | GitHub Actions / Render / Google Drive API v3 / GCP IAM / Workload Identity Federation |
| ランニングコスト見込み | **ほぼ$0**（各サービスの無料枠内） |
| 状況 | 設計整理完了・実作業は未実施 |

## 結論：組織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トークンを発行しないため、使えません。

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

| 実行環境 | 認証方式 | セキュリティ |
| --- | --- | --- |
| **GitHub Actions** | **WIF（キーレス）** | **JSONキー不要で最もセキュア** |
| Render | サービスアカウントJSON | キーの管理・ローテーションが必要 |

**キーが存在しなければ、漏洩のしようがありません。**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活用の検証を日々行い、企業の業務自動化とセキュアな基盤づくりを支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。