Claude CodeとBigQueryをMCPで繋ぐ設定をしていたとき、ユーザーから「認証がうまく動かなくなることがある」という相談を受けました。原因を調べてみると、gcloud auth application-default loginで作ったADCファイルをそのまま自動化スクリプトに使っていたことが根本にありました。この記事では、なぜOAuth ADCが自動化に向かないのか、サービスアカウント（SA）キーに移行する具体的な手順とともに解説します。
OAuth ADCの何が問題なのか
gcloud auth application-default loginで作成されるApplication Default Credentials（ADC）は、Googleアカウントでブラウザ認証したユーザーのOAuthトークンです。このトークンには1時間の有効期限があります。
リフレッシュトークンによって自動更新される仕組みになっていますが、長期間放置したり、特定の環境では更新に失敗するケースがあります。MCPサーバーや定期実行スクリプトのように「人間が操作していない状態でGCPにアクセスする」用途には、そもそも設計が合っていません。
また、gcloud auth application-default loginはブラウザが開いてGoogleアカウントでログインする操作を必要とします。CI/CDやlaunchdで自動実行する環境では、そもそも実行できません。
サービスアカウント（SA）キーが正解な理由
GCPのサービスアカウントは「人間ではなくアプリケーションのためのアカウント」です。SAキー（JSONファイル）は有効期限がありません。一度発行すれば、削除・無効化するまで使い続けられます。
さらに、IAMで権限を最小限に設定できます。たとえばBigQueryの読み取りしか必要ないスクリプトなら、「BigQuery データ閲覧者」と「BigQuery ジョブユーザー」の2つだけを付与すれば十分です。万が一キーが漏洩しても、被害範囲をそのプロジェクトのBigQuery読み取りに限定できます。
SAキーへの移行手順（5分でできる）
GCPコンソールで以下の操作をします。
- 対象のGCPプロジェクトを開き、「IAMと管理」→「サービスアカウント」へ移動
- 「＋サービスアカウントを作成」をクリック。名前は用途がわかるものに（例：
claude-bigquery） - ロールの付与画面で「BigQuery データ閲覧者」と「BigQuery ジョブユーザー」を追加
- 作成後、そのSAをクリック→「キー」タブ→「鍵を追加」→「新しい鍵を作成」→JSONを選択してダウンロード
- ダウンロードしたJSONを安全な場所に保存（例：
~/.config/gcloud/myproject-sa.json）
あとはスクリプトや環境変数の設定を変えるだけです。
# 変更前（OAuth ADC）
export GOOGLE_APPLICATION_CREDENTIALS="~/.config/gcloud/application_default_credentials.json"
# 変更後（SAキー）
export GOOGLE_APPLICATION_CREDENTIALS="~/.config/gcloud/myproject-sa.json"クライアントごとに認証を分離する考え方
複数のクライアント案件でBigQueryを使っている場合、1つのSAキーですべてのプロジェクトにアクセスできる状態は危険です。理由は2つあります。
- スクリプトのバグやLLMの誤動作で、無関係なクライアントのデータを読み書きしてしまうリスク
- キーが漏洩したとき、全クライアントのデータが一度に危険にさらされるリスク
これは「最小権限の原則（Principle of Least Privilege）」と呼ばれる業界標準の考え方です。クライアントAのSAキーはクライアントAのBigQueryにしかアクセスできないという設計にすることで、どちらのリスクも大幅に下げられます。
MCPサーバーでこれを実現するなら、クライアントごとに別のMCPサーバーエントリを作り、それぞれ専用のSAキーを指定するだけです。設定のオーバーヘッドはほとんどなく、安全性だけ上がります。
まとめ
GCPを自動化スクリプトで使うときの認証は、OAuth ADCではなくサービスアカウントキーが正解です。有効期限がなく、権限を最小化でき、ブラウザ不要で動きます。発行は5分もあればできるので、今すぐ切り替えることをおすすめします。複数クライアントを扱っている場合は、クライアントごとに別のSAキーを作ることで、セキュリティリスクをプロジェクト単位に封じ込められます。
コメント