Elcamy
ブログ一覧に戻る
#ビジネス2025.11.07

【完全比較】APIキー方式とADC方式の違いと選び方｜GCP・Vertex AI・BigQueryでの最適解はどっち？

認証方式の選択が重要であり、APIキーから短命トークンへの移行が推奨されている。特にGoogle Cloudでは、ADCやWIFを利用した鍵レス運用が推奨され、セキュリティや権限管理が向上する。BigQueryではAPIキーが使用できず、ADCまたはOAuthが必須である。各環境に応じた適切な認証方法の選択が求められ、鍵作成禁止の組織ポリシーが重要である。

なぜ今「認証方式の選び方」が重要なのか

ゼロトラストや監査対応、最小権限の重要性が高まる中で、「長期的に漏えいしやすい鍵」から「短命トークン」へと移行する流れが明確になっています。

特に Google Cloud™では、**ADC（Application Default Credentials）やWIF（Workload Identity Federation）**を軸にした「鍵レス」「最小権限」の運用が推奨されています。

👉 公式ガイド：鍵作成制限ポリシー

目次

用語の整理

混同しやすい5つの認証方式

用語説明
APIキーランダムな文字列による簡易な認証。主にMaps APIなどで使用。
必ずIPやAPI制限を併用すること。
OAuth 2.0ユーザーまたはサービスの同意に基づいて一時トークンを発行しアクセスを許可する仕組み。
サービスアカウントアプリやバッチ処理の「身元」。
鍵ファイルの配布は非推奨。
ADC実行環境に応じて、最適な認証情報を自動検出して使う仕組み。
WIFGitHub ActionsやAWSなど外部からGCPに鍵なしでアクセスできる仕組み。

認証方式ごとの仕組みと違い（ざっくり図解）

APIキー

クライアントが固定キー（x-goog-api-keyなど）を送信 → 利用元やAPI単位で制限して悪用を抑える。

📎 APIキーのベストプラクティス

ADC

Cloud RunやGCEなどのメタデータサーバから自動で認証情報を取得 → 短命トークンを払い出し → IAMロールでアクセス制御。

📎 ADCの仕組み（日本語）

セキュリティと運用の比較（一覧表）

比較項目APIキーADC（＋WIF）
秘密管理鍵が漏れると即悪用される鍵レス／短命トークンで安全性高
権限管理API単位の制限が中心IAMロールで細かく制御可能
鍵の更新手動更新が必要でミスも起きやすい自動更新が前提の設計
利用者の特定共有キーでは追跡困難サービスアカウント単位で監査可
ガバナンス統制組織全体での制御が難しい鍵作成制限ポリシーで一括管理
主な用途Mapsなど外部向けフロントバックエンド・基盤系・CI/CD全般

ユースケース別：認証方式の選び方早見表

認証方法の選び方

flowchart TD
  B{どこからアクセス?}

  C1[外部公開フロントエンド - Google Mapsなど]
  D1[APIキーを使用<br/>（※制限必須）]
  B --> C1 --> D1

  C2[社内システム - Cloud RunやGKEなど]
  D2[ADC<br/>（環境で自動認証）]
  B --> C2 --> D2

  C3[CI/CDや他クラウド - GitHub Actions等]
  D3[ADC + WIF<br/>（鍵レス運用）]
  B --> C3 --> D3

  C4[ローカル開発環境]
  D4[gcloud auth application-default loginを使用]
  B --> C4 --> D4

  %% 着色定義
  classDef start fill:#fdf6e3,stroke:#aaa,stroke-width:1px;
  classDef decision fill:#e3f2fd,stroke:#42a5f5,stroke-width:2px;
  classDef yellow fill:#fffde7,stroke:#fbc02d;
  classDef green fill:#e8f5e9,stroke:#66bb6a;

  %% ノードへの着色適用
  class A start;
  class B decision;
  class C1,C2,C3,C4 yellow;
  class D1,D2,D3,D4 green;
アクセス元／シーン推奨認証方式
外部公開フロントエンド
（Google Mapsなど）**APIキー
**※ドメイン・IP・API制限を必ず併用
社内システム
（Cloud Run / GCE / GKE）**ADC
**※メタデータサーバで自動認証されるため鍵不要
CI/CDや他クラウド環境
（GitHub Actions等）**ADC＋WIF
**※OIDCトークンによる鍵レス認証が推奨
ローカル開発環境gcloud auth application-default loginでADCファイル生成／利用可能

GCP主要サービスでの実装例

ADC構成の選び方

flowchart TD
  B{実行環境は？}

  C1[Cloud Run / GCE / GKE]
  D1[メタデータサーバから<br/>ADCが自動検出]
  B --> C1 --> D1

  C2[ローカルPC]
  D2[gcloud auth application-default loginで構成]
  B --> C2 --> D2

  C3[CI/CDや他クラウド<br/>（GitHub Actionsなど）]
  D3[WIFを使用してADC連携<br/>（OIDCトークン）]
  B --> C3 --> D3

  %% 着色定義
  classDef start fill:#fdf6e3,stroke:#aaa,stroke-width:1px;
  classDef decision fill:#e3f2fd,stroke:#42a5f5,stroke-width:2px;
  classDef yellow fill:#fffde7,stroke:#fbc02d;
  classDef green fill:#e8f5e9,stroke:#66bb6a;

  %% ノードにスタイルを割り当て
  class A start;
  class B decision;
  class C1,C2,C3 yellow;
  class D1,D2,D3 green;

Cloud Run / GCE / GKE

→ サービスアカウントにIAMロールを付けてデプロイ。ADCが自動検出されるため鍵不要。GKEはWorkload Identityを活用すれば完全に鍵レスで運用可能。

📎 Cloud Runの認証設計

ローカルPCでの開発

→ gcloud auth application-default login を実行すれば、ローカルにADC情報が作成され、クライアントライブラリがそれを自動利用。

CI/CDや他クラウド（GitHub Actionsなど）

→ JSON鍵は使わず、WIFを使ってOIDCトラストを構成。トークンは都度払い出しされるため安全。

📎 WIFの設定ガイド

Vertex AIでの実装ポイント

Vertex AI 接続方法の選び方── API別 × 実行環境別での実務ガイド

flowchart TD
  A{使うAPIは？}

  C1[通常のVertex AI<br/>（SDK/REST）]
  D1[ADC または OAuth<br/>（ADC推奨）]
  A --> C1 --> D1

  C2[Vertex AI Express Mode<br/>（プレビュー）]
  D2[APIキー認証<br/>（試験的利用に限定）]
  A --> C2 --> D2

  C3[Vertex AI Search<br/> for commerce]
  D3[ADC または gcloud認証]
  A --> C3 --> D3

  D1 --> E
  D2 --> E
  D3 --> E

  E{どの実行環境？}

  F1[GCP上のランタイム<br/>（Run/GKEなど）]
  G1[ADCが自動検出]
  E --> F1 --> G1

  F2[GitHub Actionsなど外部]
  G2[ADC + WIF<br/>（OIDCトークン）]
  E --> F2 --> G2

  %% 着色定義
  classDef start fill:#e3f2fd,stroke:#2196f3,stroke-width:2px;
  classDef decision fill:#fffde7,stroke:#fdd835;
  classDef result fill:#e8f5e9,stroke:#43a047;

  %% スタイル割り当て
  class A start;
  class C1,C2,C3,E,F1,F2 decision;
  class D1,D2,D3,G1,G2 result;

1. API別：どのVertex AIを使うか？

  • 通常の Vertex AI（SDK/REST） 認証方式は ADC（Application Default Credentials） または OAuth に対応しています。

実務では ADCが推奨です。短命トークンで安全性が高く、鍵不要で最小権限の設計がしやすいためです。

  • GCP上（Cloud Run / GKE / GCE など） → サービスアカウント経由で ADCが自動的に検出されます。鍵ファイルの配布は不要です。

  • 外部環境（GitHub ActionsやAWSなど） → WIF（Workload Identity Federation） を用いて OIDC トラストを構成。ADC＋一時トークンでアクセスします。JSON鍵は使用しません。

  • Vertex AI Express Mode（プレビュー） このモードでは APIキー認証のみ対応しています。あくまで 学習・検証などの試験的な利用にとどめ、本番利用は非推奨です。

    • 利用する場合は、APIの使用範囲や送信元（IP制限・HTTPリファラ）を厳密に制限し、キーのローテーションや漏洩検知も含めた設計が必要です。

  • Vertex AI Search for commerce 認証は ADC または gcloud資格情報 に対応。

運用面では、サーバサイドは **ADC（サービスアカウント）**を使い、管理端末の一時作業では gcloud 認証での代用が安全です。

2. 実行環境別：どこからアクセスするか？

  • GCP上のランタイム（Cloud Run / GKE / GCEなど） → ランタイム内のメタデータサーバから ADCが自動的に検出されます。

サービスアカウントには必要最小のIAMロールのみを付与し、鍵ファイルは一切使わない構成がベストプラクティスです。

特にGKEでは Workload Identity を活用することで完全な鍵レス運用が可能になります。

  • 外部環境（GitHub Actions、他クラウド、CI/CDなど） → ADC＋WIF構成を使って OIDC 経由で一時トークンを払い出します。

リポジトリ・ブランチ・環境単位で条件を細かく制御し、権限も最小限に抑えることが重要です。

JSON鍵の配布や環境変数での埋め込みはセキュリティ上のリスクが高く、避けるべきです。

3. 実務上のNG例と推奨方針

  • 🚫 NGなパターン
    • JSON鍵ファイルを使ってサービスアカウントを認証
    • 長期トークンや秘密鍵をそのまま環境変数に埋め込み
    • APIキーを制限なしで使い回す
  • ✅ 推奨される構成
    • ADCによる短命トークンを前提に設計
    • 外部連携やCI/CD環境では WIFで安全に一時トークンを払い出し
    • 必要に応じて、組織ポリシーで鍵ファイルの作成自体を禁止

4. クイック判定ガイド（図のまとめ）

シーン推奨認証方式
SDK/REST APIを利用✅ ADC（本命）またはOAuth（補助）
Vertex AI Express Modeを試す✅ APIキー（ただし試験利用に限定）
Vertex AI Search for commerceを使う✅ ADCまたはgcloud資格情報
GCPランタイム（Run/GKE等）で実行✅ ADC（メタデータから自動検出）
CI/CDや他クラウドからアクセス✅ ADC＋WIF（OIDCトークンで鍵レス連携）

📎 Vertex AIの認証詳細

[Google Cloud Vertex AIついてのお問い合わせ]

BigQueryでの注意点

APIキーは使えない

BigQuery は APIキーによる認証をサポートしていません。

アクセスには、OAuth2（ユーザー認証） または ADC（サービスアカウント認証） が必須です。

  • フロントエンドから直接呼び出すことは 原則非推奨。
  • どうしても実施する場合は、OAuthによるエンドユーザー認可フローが必要で、運用・セキュリティの負荷が高くなります。
  • 基本はサーバーサイド経由でアクセスさせましょう。

認証は「ADCまたはOAuth」が基本

ユースケース認証方式
実運用／ジョブ実行ADC（推奨）：短命トークン中心で、鍵レス・最小権限がしやすい
手動操作／UI／検証用途OAuth（ユーザーの同意による一時的なアクセス）
GCP環境（Cloud Run/GKE/GCE）ADCを自動検出（メタデータサーバから）
外部環境（CI/CDなど）WIF＋ADC（一時トークン発行、鍵JSONは使わない）

ローカル開発は「権限借用型ADC」で安全に

ローカルで開発する際も、鍵JSONを使わずに、サービスアカウントの権限を借りたADCファイルを生成できます。

# (1) ユーザー認証しつつ、サービスアカウントのADCを生成
gcloud auth application-default login \
  --impersonate-service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com

# (2) トークン取得や動作確認も可能
gcloud auth application-default print-access-token
bq query --use_legacy_sql=false 'SELECT 1'

⚠ GOOGLE_APPLICATION_CREDENTIALS に鍵JSONを指定する方法は 非推奨 です。

権限設計は「ジョブ」と「データ」を分離

BigQueryの権限は、実行権限（ジョブ）とデータ権限に分かれています。

  • ジョブ権限（プロジェクト単位）
    • 例：roles/bigquery.jobUser
    • クエリを実行するために必要
  • データ権限（データセット／テーブル単位）
    • 例：roles/bigquery.dataViewer / roles/bigquery.dataEditor
    • データの読み書きに必要

ポイント：

  • 両方の権限が揃っていないとクエリは失敗します。
  • プロジェクト全体に広く権限を与えず、データセット単位で絞る。
  • 管理者ロールの配布は避け、実行と監査の役割を分ける。

環境別：認証方式の置き換え例

環境認証方式
Cloud Run / GKE / GCEADCを自動検出。鍵配布不要。
GKEなら Workload Identity で完全鍵レス。
CI/CD・他クラウド（GitHub Actions など）WIF（OIDC）＋ADC。
レポジトリやブランチごとに条件を絞る。
ローカル開発gcloud auth application-default login を使う。
チームで鍵JSONを共有しない。

よくある落とし穴（実務での注意点）

  • ジョブ権限だけあってもデータが読めない／書けない → ジョブ権限とデータ権限の両方を確認。
  • リージョン不一致で失敗 → クエリロケーションとデータセットロケーション（US/EU/asia-*）を一致させる。
  • VPC Service Controls による制限 → CLIやローカルからのアクセス時、VPC SCの境界内かどうかを確認。
  • Storage Read API の権限不足 → 使用する場合は roles/bigquery.readSessionUser などを追加。
  • データ共有の設計ミス → 他プロジェクトと共有する際は、承認済みビュー／データセットACLを使い分ける。

鍵レス運用・ガバナンスの定着へ

  • 鍵作成禁止の組織ポリシーを有効にし、新たなJSON鍵の発行を抑止。
  • 監査ログの定期チェック：「誰が」「いつ」「何を」したかを確認。
  • 障害時対応・権限ローテのランブックを整備（WIF構成変更・SA差し替えなど）。
  • 機密データ列は、ポリシータグ／RLS／CLSで保護し、IAMと併用。

まとめ

  • BigQueryではAPIキーは使えません。ADCまたはOAuthが必須。
  • 実運用はADCが推奨（Cloud RunやCI/CDは鍵レス構成を）。
  • ローカルでは -impersonate-service-account で安全にADC運用可能。
  • ジョブとデータの権限は分離して最小化。
  • リージョン／VPC／Read API／共有設定など、構成レベルの注意点も要確認。

📎 BigQueryの認証方式

GCP認証の実務ガイド

APIキー・鍵JSONの見直しとADC/WIF移行ステップ

flowchart TD
  A[鍵JSONからの安全な移行]
  B1[① APIキーや鍵JSONの<br/>利用状況を棚卸]
  B2[② サービスアカウントに<br/>最小権限を付与]
  B3{どの環境で実行？}
  A --> B1 --> B2 --> B3

  C1[Cloud Run / GKE など<br/>GCP環境]
  D1[ADCに置き換え<br/>（メタデータ認証）]
  B3 --> C1 --> D1

  C2[GitHub Actionsなど外部]
  D2[WIF構成で鍵レス化]
  B3 --> C2 --> D2

  C3[ローカル開発環境]
  D3[gcloud loginで<br/>ADCファイル生成]
  B3 --> C3 --> D3

  D1 --> E
  D2 --> E
  D3 --> E
  E[④ 組織ポリシーで<br/>鍵作成禁止を有効化]
  F[⑤ 監査ログ・ローテーションルールの整備]
  E --> F

  %% スタイル定義
  classDef start fill:#f3e5f5,stroke:#ba68c8,stroke-width:2px;
  classDef step fill:#fff8e1,stroke:#fbc02d;
  classDef result fill:#e8f5e9,stroke:#66bb6a;

  %% スタイル適用
  class A start;
  class B1,B2,B3,C1,C2,C3,E,F step;
  class D1,D2,D3 result;

1. 現状把握（棚卸し）

まずは APIキー／鍵JSONの利用状況を可視化します。

  • どの**システム／環境（本番・検証・ローカル・CI/CD）**で使っているか
  • どの**リポジトリ／ジョブ（例：CI/CD）**から参照しているか
  • 紐づくサービスアカウントと付与ロール、呼び出すGCP API
  • 影響範囲（停止リスク・移行優先度）の整理

2. IAM設計（最小権限＋境界設計）

サービスアカウントに最小限のロールだけを付与し、プロジェクトやフォルダ単位の境界を明確化します。

  • “できるだけ小さく始めて、必要に応じて足す”設計にする
  • 共有アカウントを避け、用途ごとに分離（監査しやすくする）

3. 実装切替（どの環境で実行？に対応）

A. GCP環境（Cloud Run / GKE など）

  • ADCへ置き換えます。
  • ランタイムのメタデータサーバから ADCが自動検出されるため、鍵ファイルの配布は不要です。
  • GKEは Workload Identity を使うと完全鍵レス運用が可能です。

B. 外部（GitHub Actions など）

  • **WIF（Workload Identity Federation）**でOIDCトラストを構成し、ADC＋一時トークンでアクセスします。
  • JSON鍵は使わない前提に切り替えます。

C. ローカル開発環境

  • 開発端末では gcloud auth application-default login を実行して ADCファイルを生成します。
  • チーム内の鍵共有や環境変数への鍵埋め込みは行いません。

4. 組織ポリシーで鍵作成禁止

移行と並行して、鍵の新規作成をブロックする組織ポリシーを有効化します。

  • 2024年5月以降に作成された組織では既定で有効
  • 例外が必要な場合は、期間・用途・責任者を明確化して運用

5. 監査ログと運用ルールの整備

移行後に運用の型を固めます。

  • 監査ログ（誰が・いつ・どの権限で）を定期確認
  • ローテーションと障害時の切替手順（ランブック）を整備
  • CI/CDや外部連携はブランチ／環境単位で条件を絞る（最小権限の徹底）

まとめ

  • 棚卸し → 最小権限設計 → 環境別のADC/WIF切替 → 鍵作成禁止 → 監査・運用整備の順で進める
  • GCP環境はADCの自動検出で鍵レス化
  • 外部（CI/CD等）はWIFで一時トークン、JSON鍵は使わない
  • ローカルは gcloud auth application-default login でADCファイル生成
  • 最後に鍵作成禁止の組織ポリシーと監査・ローテ運用で締める

よくある質問（FAQ）

Q. サービスアカウントの鍵JSONを配るのはADCですか？

A. いいえ。**ADCは「探す仕組み」**であり、鍵配布はレガシー方式です。ADC/WIFを使えば鍵レス運用が可能です。

Q. 短命トークンって短すぎて不安です。

A. 短命だからこそ安全。漏えいしても被害が限定的で、自動更新されるため運用もシンプルです。

Q. フロントから直接GCP APIを叩きたいです。

A. 原則NG。MapsなどAPIキーが前提の一部のプロダクトを除き、バックエンド経由にすべきです。

まとめ：最適な認証方式を選ぶための判断軸

判断ポイント最適な方式
サーバレス・基盤系（Run/GKE/GCE）ADC（自動認証）
他クラウド・CI/CD・オンプレADC＋WIF（鍵レス）
フロント直叩き必須
（Maps等）APIキー＋制限付き
全体統制鍵作成の制限ポリシーを有効にする
（iam.disableServiceAccountKeyCreation）

用語・公式サイトリンク集（Wikipedia/公式）

用語要点参考リンク
APIキー簡易な識別子。必ず制限を。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com
ADC実行環境に応じた認証情報の自動検出。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com
OAuth 2.0認可フレームワーク。Wikipedia:
ja.wikipedia.org

ja.wikipedia.org

リンク先の情報を読み込み中...

https://ja.wikipedia.org
サービスアカウントアプリ用のID。鍵配布は非推奨。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com
WIF外部IDから鍵レスでGCPへ。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com
Cloud RunサービスIDでADC自動判定。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com
GKE Workload IdentityGKEで鍵レス認証。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com
Vertex AIGCPの生成AI/ML基盤。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com
BigQuery企業向けDWH。APIキー非対応。公式:
cloud.google.com

cloud.google.com

リンク先の情報を読み込み中...

https://cloud.google.com

参考リンク（公式中心・直リンク）

（上記の要点は本文中でも出典に基づき解説しています。たとえばADCの探し方やgcloud auth application-default loginは公式ドキュメント、APIキーの制限は公式ベストプラクティス、鍵作成禁止はResource Managerの組織ポリシーを参照。(Google Cloud Documentation)）

導入に迷ったら

Elcamyでは、Google Cloud Vertex AI の導入を総合的にサポートしています。

「どの業務に AI を適用できるのか分からない」「PoC から始めたい」「既存システムと連携させたい」など、導入前の課題整理から、要件定義・開発・運用まで一貫してご相談いただけます。

自社での活用可能性を知りたい段階でも大歓迎です。まずはお気軽にお問い合わせください。

elcamy.com

elcamy.com

リンク先の情報を読み込み中...

https://elcamy.com

関連記事

elcamy.com

elcamy.com

リンク先の情報を読み込み中...

https://elcamy.com

elcamy.com

elcamy.com

リンク先の情報を読み込み中...

https://elcamy.com

記事一覧を見る