【完全比較】APIキー方式とADC方式の違いと選び方｜GCP・Vertex AI・BigQueryでの最適解はどっち？
なぜ今「認証方式の選び方」が重要なのか
ゼロトラストや監査対応、最小権限の重要性が高まる中で、「長期的に漏えいしやすい鍵」から「短命トークン」へと移行する流れが明確になっています。
特に Google Cloud™では、ADC（Application Default Credentials）やWIF（Workload Identity Federation）を軸にした「鍵レス」「最小権限」の運用が推奨されています。
目次
目次
なぜ今「認証方式の選び方」が重要なのか目次用語の整理混同しやすい5つの認証方式認証方式ごとの仕組みと違い（ざっくり図解）APIキーADCセキュリティと運用の比較（一覧表）ユースケース別：認証方式の選び方早見表認証方法の選び方GCP主要サービスでの実装例ADC構成の選び方Cloud Run / GCE / GKEローカルPCでの開発CI/CDや他クラウド（GitHub Actionsなど）Vertex AIでの実装ポイントVertex AI 接続方法の選び方── API別 × 実行環境別での実務ガイド1. API別：どのVertex AIを使うか？2. 実行環境別：どこからアクセスするか？3. 実務上のNG例と推奨方針4. クイック判定ガイド（図のまとめ）BigQueryでの注意点APIキーは使えない認証は「ADCまたはOAuth」が基本ローカル開発は「権限借用型ADC」で安全に権限設計は「ジョブ」と「データ」を分離環境別：認証方式の置き換え例よくある落とし穴（実務での注意点）鍵レス運用・ガバナンスの定着へまとめGCP認証の実務ガイドAPIキー・鍵JSONの見直しとADC/WIF移行ステップ1. 現状把握（棚卸し）2. IAM設計（最小権限＋境界設計）3. 実装切替（どの環境で実行？に対応）4. 組織ポリシーで鍵作成禁止5. 監査ログと運用ルールの整備まとめよくある質問（FAQ）Q. サービスアカウントの鍵JSONを配るのはADCですか？Q. 短命トークンって短すぎて不安です。Q. フロントから直接GCP APIを叩きたいです。まとめ：最適な認証方式を選ぶための判断軸用語・公式サイトリンク集（Wikipedia/公式）参考リンク（公式中心・直リンク）導入に迷ったら関連記事サービス紹介採用
Vertex AIでの実装ポイント
Vertex AI 接続方法の選び方── API別 × 実行環境別での実務ガイド
1. API別：どのVertex AIを使うか？
- 通常の Vertex AI（SDK/REST）
- GCP上（Cloud Run / GKE / GCE など）
- 外部環境（GitHub ActionsやAWSなど）
認証方式は ADC（Application Default Credentials） または OAuth に対応しています。
実務では ADCが推奨です。短命トークンで安全性が高く、鍵不要で最小権限の設計がしやすいためです。
→ サービスアカウント経由で ADCが自動的に検出されます。鍵ファイルの配布は不要です。
→ WIF（Workload Identity Federation） を用いて OIDC トラストを構成。ADC＋一時トークンでアクセスします。JSON鍵は使用しません。
- Vertex AI Express Mode（プレビュー）
- 利用する場合は、APIの使用範囲や送信元（IP制限・HTTPリファラ）を厳密に制限し、キーのローテーションや漏洩検知も含めた設計が必要です。
このモードでは APIキー認証のみ対応しています。あくまで 学習・検証などの試験的な利用にとどめ、本番利用は非推奨です。
- 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トークンで鍵レス連携） |
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ファイルを生成できます。
⚠ GOOGLE_APPLICATION_CREDENTIALS に鍵JSONを指定する方法は 非推奨 です。
権限設計は「ジョブ」と「データ」を分離
BigQueryの権限は、実行権限（ジョブ）とデータ権限に分かれています。
- ジョブ権限（プロジェクト単位）
- 例：
- クエリを実行するために必要
- データ権限（データセット／テーブル単位）
- 例： /
- データの読み書きに必要
ポイント：
- 両方の権限が揃っていないとクエリは失敗します。
- プロジェクト全体に広く権限を与えず、データセット単位で絞る。
- 管理者ロールの配布は避け、実行と監査の役割を分ける。
環境別：認証方式の置き換え例
| 環境 | 認証方式 |
|---|---|
| Cloud Run / GKE / GCE | ADCを自動検出。鍵配布不要。 GKEなら Workload Identity で完全鍵レス。 |
| CI/CD・他クラウド（GitHub Actions など） | WIF（OIDC）＋ADC。 レポジトリやブランチごとに条件を絞る。 |
| ローカル開発 | を使う。 チームで鍵JSONを共有しない。 |
よくある落とし穴（実務での注意点）
- ジョブ権限だけあってもデータが読めない／書けない
→ ジョブ権限とデータ権限の両方を確認。
- リージョン不一致で失敗
→ クエリロケーションとデータセットロケーション（US/EU/asia-*）を一致させる。
- VPC Service Controls による制限
→ CLIやローカルからのアクセス時、VPC SCの境界内かどうかを確認。
- Storage Read API の権限不足
→ 使用する場合は などを追加。
- データ共有の設計ミス
→ 他プロジェクトと共有する際は、承認済みビュー／データセットACLを使い分ける。
鍵レス運用・ガバナンスの定着へ
- 鍵作成禁止の組織ポリシーを有効にし、新たなJSON鍵の発行を抑止。
- 監査ログの定期チェック：「誰が」「いつ」「何を」したかを確認。
- 障害時対応・権限ローテのランブックを整備（WIF構成変更・SA差し替えなど）。
- 機密データ列は、ポリシータグ／RLS／CLSで保護し、IAMと併用。
まとめ
- BigQueryではAPIキーは使えません。ADCまたはOAuthが必須。
- 実運用はADCが推奨（Cloud RunやCI/CDは鍵レス構成を）。
- ローカルでは で安全にADC運用可能。
- ジョブとデータの権限は分離して最小化。
- リージョン／VPC／Read API／共有設定など、構成レベルの注意点も要確認。
GCP認証の実務ガイド
APIキー・鍵JSONの見直しとADC/WIF移行ステップ
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. ローカル開発環境
- 開発端末では を実行して ADCファイルを生成します。
- チーム内の鍵共有や環境変数への鍵埋め込みは行いません。
4. 組織ポリシーで鍵作成禁止
移行と並行して、鍵の新規作成をブロックする組織ポリシーを有効化します。
- 2024年5月以降に作成された組織では既定で有効
- 例外が必要な場合は、期間・用途・責任者を明確化して運用
5. 監査ログと運用ルールの整備
移行後に運用の型を固めます。
- 監査ログ（誰が・いつ・どの権限で）を定期確認
- ローテーションと障害時の切替手順（ランブック）を整備
- CI/CDや外部連携はブランチ／環境単位で条件を絞る（最小権限の徹底）
まとめ
- 棚卸し → 最小権限設計 → 環境別のADC/WIF切替 → 鍵作成禁止 → 監査・運用整備の順で進める
- GCP環境はADCの自動検出で鍵レス化
- 外部（CI/CD等）はWIFで一時トークン、JSON鍵は使わない
- ローカルは でADCファイル生成
- 最後に鍵作成禁止の組織ポリシーと監査・ローテ運用で締める
まとめ：最適な認証方式を選ぶための判断軸
| 判断ポイント | 最適な方式 |
|---|---|
| サーバレス・基盤系（Run/GKE/GCE） | ADC（自動認証） |
| 他クラウド・CI/CD・オンプレ | ADC＋WIF（鍵レス） |
| フロント直叩き必須 （Maps等） | APIキー＋制限付き |
| 全体統制 | 鍵作成の制限ポリシーを有効にする （） |
用語・公式サイトリンク集（Wikipedia/公式）
| 用語 | 要点 | 参考リンク |
|---|---|---|
| APIキー | 簡易な識別子。必ず制限を。 | 公式: https://cloud.google.com/docs/authentication/api-keys |
| ADC | 実行環境に応じた認証情報の自動検出。 | 公式: https://cloud.google.com/docs/authentication/application-default-credentials |
| OAuth 2.0 | 認可フレームワーク。 | Wikipedia: https://ja.wikipedia.org/wiki/OAuth |
| サービスアカウント | アプリ用のID。鍵配布は非推奨。 | 公式: https://cloud.google.com/iam/docs/service-accounts |
| WIF | 外部IDから鍵レスでGCPへ。 | 公式: https://cloud.google.com/iam/docs/workload-identity-federation |
| Cloud Run | サービスIDでADC自動判定。 | 公式: https://cloud.google.com/run |
| GKE Workload Identity | GKEで鍵レス認証。 | 公式: https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity |
| Vertex AI | GCPの生成AI/ML基盤。 | 公式: https://cloud.google.com/vertex-ai |
| BigQuery | 企業向けDWH。APIキー非対応。 | 公式: https://cloud.google.com/bigquery |
参考リンク（公式中心・直リンク）
- Workload Identity Federation：https://cloud.google.com/iam/docs/workload-identity-federation
- Cloud RunのサービスIDとADC：https://cloud.google.com/run/docs/securing/service-identity
- Workload Identity for GKE：https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity?hl=ja
- APIキーの管理／ベストプラクティス：https://cloud.google.com/docs/authentication/api-keys 、https://developers.google.com/maps/api-security-best-practices
- Vertex AI Search for commerce の認証：https://cloud.google.com/retail/docs/authentication
- BigQueryの認証（APIキー非対応の明記あり）：https://cloud.google.com/bigquery/docs/authentication
- 鍵作成禁止ポリシー（org policy）：https://cloud.google.com/resource-manager/docs/organization-policy/restricting-service-accounts
（上記の要点は本文中でも出典に基づき解説しています。たとえばADCの探し方やは公式ドキュメント、APIキーの制限は公式ベストプラクティス、鍵作成禁止はResource Managerの組織ポリシーを参照。(Google Cloud Documentation)）