はじめに
Google Cloudを使い始めた開発者が最初につまずきやすいポイントの一つが 認証 です。
「ローカルでは動くのに、Cloud Runにデプロイしたら動かない」
「サービスアカウントのJSONキーはどこに置けばいいの？」
「本番用と開発用で認証のコードを書き分けるべき？」
こうした疑問を抱えたことはありませんか？
実は、これらの悩みを一発で解決してくれる仕組みが ADC（Application Default Credentials） です。この記事では、ADCの仕組みを理解し、ローカルでも本番でも同じコードで動くアプリケーションを作る方法を解説します。
対象読者
- Google Cloudを使い始めた開発者
- 認証周りで混乱している方
- 環境ごとに認証処理を書き分けている方
前提知識
- Google Cloudの基本的な概念（プロジェクト、サービスアカウントなど）
- 任意のプログラミング言語でのAPI呼び出し経験
ADCとは
ADC（Application Default Credentials） を一言で表すと、「認証情報の自動探索システム」 です。
プログラムがGoogle Cloud APIを呼び出す際、ADCは 「今どこで動いているか」を自動的に判別 し、その環境に適した認証情報を自動的に取得します。
ADCが重要な理由
ADCを理解し活用することで、以下のメリットが得られます。
- コードの共通化: ローカルと本番で認証処理を書き分ける必要がない
- セキュリティの向上: JSONキーをコードに埋め込む必要がない
- 運用の簡素化: 環境変数や設定ファイルの管理が最小限で済む
ADCの核心は「プログラムをどこに持っていっても、その場所（環境）が用意してくれる認証情報をADCが勝手に見つけてくれる」ということです。
環境ごとの認証の違い
ADCが裏側で動くおかげで、ソースコードは 全く同じまま 動作環境を切り替えられます。
以下のPythonコードを見てください。
from google.cloud import storage
# 認証情報を明示的に指定しない
client = storage.Client()
# バケット一覧を取得
buckets = list(client.list_buckets())
for bucket in buckets:
print(bucket.name)
このコードは、ローカルでもCloud Runでも そのまま動きます。なぜでしょうか？
環境別の認証フロー
| 環境 | 認証の主体 | ADCがどうやって見つけるか |
|---|---|---|
| ローカル開発 | あなた自身（Googleアカウント） |
gcloud auth application-default login で作成されたローカルファイル |
| クラウド本番 | サービスアカウント | 実行リソース（Cloud Run等）に紐付けられた メタデータサーバー |
ローカル開発環境での認証
ローカルで開発する際は、以下のコマンドを実行します。
gcloud auth application-default login
このコマンドを実行すると、ブラウザが開きGoogleアカウントでログインするよう求められます。認証が完了すると、認証情報が以下のパスに保存されます。
-
macOS/Linux:
~/.config/gcloud/application_default_credentials.json -
Windows:
%APPDATA%\gcloud\application_default_credentials.json
ADCはこのファイルを自動的に検出し、あなたのGoogleアカウントの権限でAPIを呼び出します。
クラウド本番環境での認証
Cloud Run、Compute Engine、GKEなどのGoogle Cloud上のリソースでは、メタデータサーバー から認証情報が提供されます。
コードを変更する必要は一切ありません。ADCが自動的にメタデータサーバーを検出し、そこから認証情報を取得します。
クラウド移行時の「アタッチ」の仕組み
クラウド環境では、「サービスアカウントをリソースにアタッチする」 という設定を行います。これがクラウドでの認証の核心です。
サービスアカウントの「アタッチ」とは
アタッチ とは、リソースに 「サービスアカウントという名の身分証」 を持たせることです。
アタッチの3つのポイント
1. 身分証の付与
アタッチにより、Cloud Runなどのリソースは「私は my-app@project.iam.gserviceaccount.com です」と名乗れるようになります。
2. 権限の紐付け
サービスアカウントに IAMロール を付与することで、リソースがその権限を行使できるようになります。
例えば、「Storage閲覧者」ロールを付与すると、Cloud Storageのオブジェクトを読み取れるようになります。
3. 安全性の確保
秘密鍵（JSONファイル）をサーバーに置く必要がないため、鍵の流出リスクがゼロ になります。これが最も重要なポイントです。
メタデータサーバーの役割
クラウド環境でADCが認証情報を取得する際に使われるのが メタデータサーバー です。
メタデータサーバーとは
メタデータサーバーは、Google Cloudが各リソース内に用意している特別なエンドポイントです。http://metadata.google.internal/ というアドレスでアクセスできます。
ADCの検索順序
ADCは以下の順序で認証情報を探します。
- 環境変数
GOOGLE_APPLICATION_CREDENTIALSに指定されたファイル -
gcloud auth application-default loginで作成されたファイル - メタデータサーバー（クラウド環境の場合）
クラウド環境では3番目が該当するため、何も設定しなくても認証が機能します。
運用のベストプラクティス
ADCを最大限に活用するためのベストプラクティスを紹介します。
1. JSONキーは極力使わない
サービスアカウントキー（JSONファイル）の利用は 非推奨 です。鍵の漏洩リスクがあり、ローテーション管理も煩雑になります。
クラウド内では「アタッチ」による認証（メタデータサーバー経由）を使用しましょう。
例外的にJSONキーが必要なケース:
- オンプレミス環境からGoogle Cloudにアクセスする場合
- GitHub ActionsなどのCI/CD環境（Workload Identity連携が推奨）
2. 最小権限の原則
サービスアカウントには、そのアプリが 必要とする最小限のロール だけを付与します。
❌ roles/owner（全権限）
❌ roles/editor（編集者）
⭕ roles/storage.objectViewer（Storageオブジェクト閲覧のみ）
3. コードのポータビリティを保つ
クライアントライブラリを初期化する際、認証引数を空に保つ ことで、どこでも動くコードを維持できます。
# ⭕ 推奨: 認証情報を指定しない
from google.cloud import storage
client = storage.Client()
# ❌ 非推奨: JSONキーをハードコード
from google.cloud import storage
client = storage.Client.from_service_account_json('/path/to/key.json')
ベストプラクティスまとめ
| 項目 | 推奨 | 非推奨 |
|---|---|---|
| クラウド内認証 | サービスアカウントのアタッチ | JSONキーの配置 |
| ローカル認証 | gcloud auth application-default login |
JSONキーのダウンロード |
| 権限付与 | 最小限のIAMロール | Owner/Editorロール |
| コード記述 | 認証引数なし | JSONパスのハードコード |
まとめ
この記事では、Google Cloudの認証の核心である ADC（Application Default Credentials） について解説しました。
ADCの核心
「プログラムをどこに持っていっても、その場所（環境）が用意してくれる認証情報をADCが勝手に見つけてくれる」
これがADCを理解する上での一番の核心です。
覚えておくべきポイント
- ADCは認証情報の自動探索システム である
- ローカルとクラウドでコードを書き分ける必要はない
- クラウドではサービスアカウントを「アタッチ」する
- JSONキーは極力使わず、メタデータサーバー経由の認証を使う
参考リンク