【Google Cloud入門】認証で詰まったらまずADCを理解しよう

こんにちは！
KDDIアイレットの取り組みとして、8月17日から8月28日まで開催中の「Google Cloud 夏休み自由研究ブログリレー」、最終日の投稿です。
今回は「Application Default Credentials（ADC）」をテーマに、実際に検証してみた内容をご紹介します！

これまでの記事はこちらです。

記事一覧はこちら

はじめに

Google Cloudを利用した開発において、誰もが一度は直面する壁が「認証」です。

「ローカル環境では動いたのに、クラウド（Cloud RunやGKE）にデプロイしたら権限エラーになってしまった」という経験はありませんか？

この記事では、Google Cloudの標準的な認証メカニズムであるApplication Default Credentials（ADC）について、その仕組みや具体的なユースケース、メリット・デメリット、そして環境構築手順を分かりやすく解説していきます！

これからGoogle Cloudでの開発を本格化させたい方はもちろん、安全なキーレス・アーキテクチャの導入を検討している方も必見の内容です！✨

1. ADC（Application Default Credentials）とは？基礎知識と仕組み

そもそも「認証」の何が大変なのか？

Google CloudのAPIをプログラムから呼び出すには、「このリクエストは誰（どのアカウント・権限）からのものか」を証明する必要があります。

従来はその証明のために、サービスアカウントキー（JSONファイル） を発行してアプリケーションに読み込ませる方法が一般的でした。

しかしこれには大きな問題があります。

• ファイルをうっかり Git にコミットしてしまうリスク
• ローカル・ステージング・本番で、それぞれ別のキーを管理する手間
• キーが漏洩した場合の影響範囲が広大（最悪プロジェクト全体への不正アクセスにつながる）

ADCとは「認証情報を自動で見つけてくれる仕組み」

Application Default Credentials（ADC）は、こうした煩雑さを解消するために Google が用意した統一的な認証戦略です。

ひとことで言えば「実行環境を見て、適切な認証情報を自動で選んでくれる仕組み」です！

ADCとは「認証情報を自動で見つけてくれる仕組み」

Application Default Credentials（ADC）は、上記のような問題を解決するために Google が用意した仕組みです。

一言でいうと、「実行環境に応じて、適切な認証情報を自動で選んでくれる」 ものです。

イメージは社員証のカードリーダーです！

オフィスのゲートにかざすだけで「この人は社員だ」と判断してくれるように、ADC もアプリが動いている環境を見て「ここはローカルだからこの認証情報、ここは Cloud Run だからこっち」と自動で切り替えてくれます！

ADCが認証情報を探す優先順位

ADCは厳密に決められた優先順位に従って環境をスキャンします。

ADCを使い始めたときに躓いたこと

① 環境変数 GOOGLE_APPLICATION_CREDENTIALS が残っていて認証情報が上書きされていた

gcloud auth application-default login を実行して認証したにもかかわらず、権限エラーが続くことがありました。

原因は、過去にテスト用として .zshrc に設定した GOOGLE_APPLICATION_CREDENTIALS が残っていたことです。

ADCは環境変数を最優先で参照するため、再ログインしても古いキーファイルが読み込まれ続けていました。

認証がうまく切り替わらないときは、まず以下で環境変数の有無を確認するといいです。

echo $GOOGLE_APPLICATION_CREDENTIALS  # 何か表示されたら要注意
unset GOOGLE_APPLICATION_CREDENTIALS  # 不要なら削除

② ログイン後に「クォータプロジェクト未設定」の警告が出てAPIが動かなかった

gcloud auth application-default login でブラウザ認証まで完了したのに、API呼び出し時に以下の警告が出て処理が止まることがありました。

Your application has authenticated using end user credentials from the
Google Cloud SDK. We recommend that most server applications use
service accounts instead. If your application continues to use end user
credentials from the Cloud SDK, you might receive a "quota exceeded"
or "API not enabled" error.

これはクォータプロジェクト（課金・クォータの帰属先となるプロジェクト）が未設定のために出る警告です。

以下のコマンドでプロジェクトを明示的に指定することで解消できます。

gcloud auth application-default set-quota-project YOUR_PROJECT_ID

警告文が長いので読み飛ばしやすいですが、設定しないとAPIが動かないケースがあります。

gcloud auth application-default login を実行したらセットで打つようにするのがおすすめです。

環境ごとにJSONキーを発行してローカルPCで管理していましたが、Gitにコミットしそうになる場面が何度かありました。

ADCに移行してからはPC内に鍵ファイルを置く必要がなくなり、管理の手間もセキュリティリスクも大きく下がると思います！

2. なぜADCが必要なのか？主要なユースケース

ADCはアプリケーションの配置場所に応じて柔軟に機能します。

ローカル開発およびIaCの検証
手元の端末からCloud Storageなどにアクセスするコードをデバッグしたり、Terraformなどを実行したりする際に、開発者個人のアカウント権限や借用権限が適用されます。

サーバーレスおよびコンテナ化ワークロード（本番運用）
Cloud RunやGKE上で稼働するアプリが、他のGoogle Cloudリソースにアクセスする際、開発者は認証処理を実装しなくても、ADCが自動的に時限付きトークンの取得と更新を行います。

マルチクラウド環境・CI/CD連携
AWSやAzure、GitHub Actionsなどの外部環境から接続する際も、Workload Identity Federationを通じて、永続的なキーを持たずに連携することが可能です！

3. ADC導入のメリットと注意点

圧倒的なセキュリティ向上（メリット）

私が感じる１番のメリットは、永続的なサービスアカウントキー（JSONファイル）を開発端末やリポジトリに置く必要が完全になくなる点です！

短時間しか有効でないトークンへの移行が自然と促されるため、万が一の鍵漏洩リスクを根本から防止できます。

環境変数の優先度やコマンドの混同（注意点）

便利な反面、以下の点に注意が必要です。

• 開発端末に古いテスト用キーの環境変数が残っていると、意図しないプロジェクトへアクセスしてしまう可能性があります。

• CLIツール自体の認証（gcloud auth login）と、アプリ実行用ADCの認証（gcloud auth application-default login）の違いを正しく理解して使う必要があります。

4. 【実践】ADCの環境構築とセットアップ手順

本番マネージド環境（Cloud Run / Compute Engineなど）

1. Google Cloudコンソールの「IAMと管理」からサービスアカウントを作成します。
2. 必要最小限のロール（例：Cloud Storage閲覧権限のみなど）を割り当てます。
3. Cloud RunやCompute Engineの個別設定画面で、作成したサービスアカウントをアタッチ（紐づけ）します。

これだけで、コード内に鍵や環境変数を書くことなく、自動で権限が適用されます！

ローカル開発環境のCLI設定

ローカル端末で個人のGoogleアカウント権限を使ってADCを有効化するには、以下を実行します。

gcloud auth application-default login

ブラウザが立ち上がるので、画面の指示に従って認証を完了させれば設定ファイルが自動生成されます！

さらに安全な「サービスアカウントの権限借用（Impersonation）」

個人権限ではなく「本番環境と同じサービスアカウントの権限」を安全に試したい場合は、権限借用を利用します。

自身のアカウントに「サービス アカウント トークン作成者」ロールを付与した上で、以下のコマンドを実行します。

gcloud auth application-default login --impersonate-service-account=TARGET_SA@PROJECT_ID.iam.gserviceaccount.com

ローカルに鍵をダウンロードすることなく、一時的なトークンでサービスアカウントの挙動を再現することができます！

5. クライアントライブラリでの実装例

ADCを使えば、コード内に鍵の読み込み処理を書く必要はありません。

引数なしでインスタンス化するだけで自動的に認証情報を探しにいきます！

Pythonでの実装例

google.auth.default() が実行環境を自動判定します。

import google.auth
from google.cloud import storage

# ADCによる自動認証情報の取得
credentials, project_id = google.auth.default()

# クライアントの初期化（鍵ファイルの指定は不要）
client = storage.Client(credentials=credentials, project=project_id)

# API呼び出し
buckets = client.list_buckets()
for bucket in buckets:
    print(bucket.name)

Node.jsでの実装例

オプションを渡さずにインスタンス化することで、ライブラリが内部でADCを呼び出します。

const { Storage } = require('@google-cloud/storage');

// 引数なしで初期化するとADCが作動
const storage = new Storage();

async function listBuckets() {
  const [buckets] = await storage.getBuckets();
  buckets.forEach(bucket => {
    console.log(bucket.name);
  });
}

listBuckets();

6. まとめ

ここまでADC（Application Default Credentials）の基礎から実践まで解説してきました！

実務でさまざまなプロジェクトやクラウド開発に携わる中で、「事故を未然に防ぐ仕組み（キーレス化）」を初期段階から取り入れておくことが、開発のしやすさとチーム全体の安全性を両立する一番の近道だと強く実感しています！

改めて、チームでGoogle Cloudを活用する際は、以下の運用をセットで推進していくのがおすすめです！

• サービスアカウントキー（JSON）の発行・ローカル保存は原則禁止にする
• ローカル開発では gcloud auth application-default login を標準化する
• 本番と同等の権限で検証したい時は「権限借用（Impersonation）」を活用する

ADCをあらかじめ設定しておけば、「ローカルでは動いたのにクラウドに置いたら権限エラーで落ちた😭」という開発時のトラブルから解放され、本来の実装にしっかり集中できるようになります！

「認証周りをより安全に構成したい」「鍵の管理コストを減らしたい」という方は、ぜひこの機会にADCを取り入れた開発環境づくりにチャレンジしてみてください！

最後までお読みいただきありがとうございました！

参考ドキュメント

• Application Default Credentials (ADC) の仕組み – Google Cloud
• サービス アカウントの権限借用 – Google Cloud