gcloud auth login とは、人の Google アカウントでブラウザから認可し、gcloud CLI が使う資格情報を手に入れるコマンドです。
- gcloud auth login と gcloud auth application-default login（ADC）が、それぞれ誰の資格情報をどこに置くかの違い
- gcloud auth list で口座を確かめ、gcloud config set account で切り替える手順
- AI の席を無人で回す当社で、人の口座の認証が切れた・空のトークンで別の口座が通っていた記録と、今の確かめの台本
当社は AIエージェント の席を何台もの機体で、人が見ていない間も回しています。席が Google Cloud を触るとき、人が端末で打つ前提の gcloud auth login は、何度も席を止めました。この頁は、その記録から、無人の作業で gcloud の認証をどう持つかをまとめた物です。席に秘密の値を渡す線そのものは Claude Code のセキュリティ の頁にあります。
gcloud auth login と gcloud auth application-default login の違い
2 つのコマンドは、名前は似ていても置く場所と使う物が違います。gcloud auth login は gcloud CLI 自身が使う資格情報を取り、終わると今の構成の有効な口座をその口座にします。gcloud auth application-default login は、Google のクライアントライブラリが使う ADC（Application Default Credentials）の置き場に資格情報を置きます。公式の文書は、後者は gcloud auth login で作った口座に影響しないとしています。
| 見る所 | gcloud auth login | gcloud auth application-default login |
|---|---|---|
| 使う物 | gcloud CLI のコマンド | クライアントライブラリ（自分で書いたコードや道具） |
| 置き場 | gcloud CLI の資格情報。gcloud auth list に並ぶ | ADC の決まった置き場。Linux・macOS は $HOME/.config/gcloud/application_default_credentials.json、Windows は %APPDATA%\gcloud\application_default_credentials.json |
| 有効な口座 | 終わると今の構成の有効な口座になる（--no-activate で止められる） | gcloud auth login の口座には影響しない |
| 互いへの影響 | --update-adc を付けたときだけ ADC にも書く。そのとき前の ADC は上書きされる | gcloud の文脈から割り当てのプロジェクト（quota project）を探して ADC に書く |
| ブラウザの無い機体 | --no-browser（ブラウザの在る別の機体と組む）・--no-launch-browser（URL を出すだけ） | こちらも web での認可の流れで資格情報を取る |
出典: gcloud auth login・gcloud auth application-default login・How Application Default Credentials works（いずれも 2026-11-01 に見た）。
どちらも「人がブラウザで認可する」事が前提です。席のように人のいない作業から撃つと、ここが先に崩れます（下の節）。
ADC が資格情報を探す順と、gcloud の資格情報の優先
ADC は次の順に資格情報を探します。
- 環境変数
GOOGLE_APPLICATION_CREDENTIALS gcloud auth application-default loginで作った資格情報のファイル- メタデータサーバーが返す、付けたサービスアカウント
gcloud CLI の側では、環境変数 CLOUDSDK_AUTH_ACCESS_TOKEN が、アクセストークンのファイル（auth/access_token_file）や保存された口座より先に見られます。公式の文書は、これを強く切り離した自動の作業や共有の機体向けとし、人の口座のアクセストークンの寿命は既定で 1 時間としています（Authorize the gcloud CLI・2026-11-01 に見た）。この環境変数が空になったときに何が起きたかは、当社の記録の 2 つ目にあります。
gcloud auth list で確かめ、gcloud config set account で切り替える
gcloud アカウントの切り替えは、資格情報が取り込み済みの口座の間なら、ログインし直さずにできます。
| やりたい事 | コマンド | メモ |
|---|---|---|
| 取り込み済みの口座と、有効な口座を見る | gcloud auth list | 有効な口座は 1 つだけ。環境変数や構成の上書きはこの一覧に出ない |
| 有効な口座だけを出す | gcloud auth list --filter=status:ACTIVE --format="value(account)" | 台本で比べるときに使える |
| 有効な口座を切り替える | gcloud config set account 口座 | 前にログインを済ませた口座だけに切り替えられる |
| 今の構成の口座を見る | gcloud config get-value account | 当社の台本はこれで「誰で撃つか」を測る |
| 口座を指してトークンを取る | gcloud auth print-access-token 口座 | 口座を省くと有効な口座のトークンになる |
| 口座を機体から外す | gcloud auth revoke 口座 | 人の口座は Google の側でトークンを取り消し、機体から資格情報を消す。サービスアカウントは機体の中だけで、鍵は消えない |
| サービスアカウントになりすます | --impersonate-service-account（1 回ごと）・gcloud config set auth/impersonate_service_account（既定） | なりすます側に「サービス アカウント トークン作成者」（roles/iam.serviceAccountTokenCreator）が要る |
出典: gcloud auth list・Authorize the gcloud CLI・gcloud auth print-access-token・gcloud auth revoke・Use service account impersonation（いずれも 2026-11-01 に見た）。
当社の記録 1: 朝に通った gcloud が、約 45 分後に再認証で落ちた
人の口座でログインした gcloud を、席（人のいない AI の作業）から撃ちました。朝に通った IAM の読み取りと秘密の操作が、約 45 分後には次の文で落ちました（出典: 社の実測 2026-09-17）。
Reauthentication failed. cannot prompt during non-interactive execution.人の口座は、ある時間がたつと人に認証し直しを求めます。端末の前に人がいれば打ち直せますが、席には聞く相手がいません。ここから当社は 2 つの決まりを作りました（出典: 社の実測 2026-09-17）。
- 「さっき通ったから今も通る」は成り立たない
- 無人で撃つ手順は、人の口座の認証に頼らない経路を先に探す
別の機体でも同じ再認証切れが起き、その機体では社の MCP（席の道具）が起動しなくなりました。直すには、本人に端末で gcloud auth login を 1 回してもらう手が要りました（出典: 社の実測 2026-10-14）。人の口座に寄りかかる限り、席が止まるたびに人を呼ぶ事になります。
当社の記録 2: 空のトークンで、思っていない口座が通っていた
席の台本は、ADC のトークンを取り出して CLOUDSDK_AUTH_ACCESS_TOKEN=$(…ADC のトークン…) の形で gcloud を撃っていました。ところが ADC の資格情報は再認証切れで、取り出したトークンは空（長さ 0）でした。空の変数では上書きが効かず、gcloud は既定の有効な口座（別のサービスアカウント）へ黙って落ちて、そのまま通っていました（出典: 社の実測 2026-09-21）。
| 思っていた事 | 実際に起きていた事 |
|---|---|
| ADC の口座で撃っている | トークンが空で、既定の有効な口座（別のサービスアカウント）で撃っていた |
| 通ったので、認証は生きている | ADC は再認証切れ。通ったのは別の口座だったから |
| 権限が足りないのは、口座の取り違え | この診断は逆さまだった。他の席へ渡した診断に訂正を送った |
出典: 社の実測 2026-09-21。
「通った」は「思っていた口座で通った」とは限りません。撃つ前に、トークンが空でない事と、誰で撃つかを別々に確かめる形は、下の台本の節に入れました。
席の都合で gcloud auth login を撃たせない
gcloud auth login は、認証の主体を変える操作です。gcloud CLI の認証は機体の中のファイルなので、1 つの席が撃てば、その機体で動く全部の席の主体が変わります。当社はこれを決まりにしました（出典: 社の決まり 2026-08-20）。
- 席の都合で gcloud auth login を撃たせない
- 人の口座での再ログインが要るときは、人が端末で 1 回だけ行う（上の記録 1 のとおり）
同じ機体で複数の席を動かす形は self-hosted runner の頁にも出てきます。機体を分け合う限り、機体の中のファイルは全部の席の物です。
人の口座を外し、席用のサービスアカウント 1 件にした
機体の gcloud に残っていた人の口座 3 つを gcloud auth revoke で外し、gcloud auth list に残るのを席用のサービスアカウント 1 件だけにしました。外した後は、2 つの対照で確かめました（出典: 社の実測 2026-09-19）。
| 対照 | 確かめた事 | 結果 |
|---|---|---|
| 陽性対照 | 今使う口座（席用のサービスアカウント）が一覧に残っている | 1 件 |
| 陰性対照 | 外した人の口座が一覧に無い | 0 件（3 口座とも） |
出典: 社の実測 2026-09-19。
revoke で消えるのは機体の資格情報で、口座そのものは消えていません。人の口座は gcloud auth login で戻せます（出典: 社の実測 2026-09-19。revoke の効き方は gcloud auth revoke・2026-11-01 に見た）。
逆の向きの記録もあります。新しい機体に移ったとき、gcloud auth list は「No credentialed accounts」で、ADC のファイルもありませんでした。本番の読み取りは、別の機体を経由して迂回しました（出典: 社の実測 2026-09-26）。機体を移ったら、まず gcloud auth list と ADC のファイルの有無を見ます。
人の ADC を持つ 1 台に寄せると、その 1 台が寝たら全部止まる
本番に手を出せるのが、人の ADC を持つ 1 台の機体だけでした。その 1 台が寝ると、本番の手が全部止まりました。止まったのは 15 時間・9 件の作業です（出典: 社の記録 2026-09-22〜24）。
そこで、鍵を作らない専用のサービスアカウントを作り、複数の機体から借りる形に変えました。IAM を書く権限は人に残しています（出典: 社の記録 2026-09-22〜24）。借りる形は、Google Cloud の文書のサービスアカウントのなりすまし（短い寿命の資格情報を求める形）に当たります。なりすます側には「サービス アカウント トークン作成者」の役割が要ります（Use service account impersonation・2026-11-01 に見た）。
| 見る所 | 前（人の ADC を持つ 1 台） | 今（鍵なしの専用サービスアカウントを借りる） |
|---|---|---|
| 本番に手を出せる機体 | 1 台だけ | 複数の機体 |
| その 1 台が寝たとき | 本番の手が全部止まった（15 時間・9 件） | 他の機体から借りられる |
| 人の再認証 | 切れたら人を呼ぶ | 人の口座の認証に頼らない |
| IAM を書く権限 | — | 人に残す |
出典: 社の記録 2026-09-22〜24。
今の形: 席の起動の前に撃つ確かめの台本
今は、席を起動する前に確かめの台本を撃ちます。要は、「誰で撃つか」と「トークンが取れるか」を別々に測る事です。トークンが取れても、別の口座なら駄目とします（出典: 社の台本・2026-10-09 に人の ADC へ落とす口を退役）。
| 順 | 確かめる事 | 使うコマンド | 駄目なとき |
|---|---|---|---|
| 1 | 有効な口座が席用のサービスアカウントか | gcloud config get-value account | 3 へ |
| 2 | その口座のトークンが取れるか（中身は印字しない） | gcloud auth print-access-token --account=… | 3 へ（1 と 2 は別々に測る） |
| 3 | 席用のサービスアカウントが取り込み済みなら、切り替えるだけ | gcloud config set account … | 切り替えて駄目なら、元の口座に戻す |
| 4 | それでも駄目なら | — | 止まって報告する |
出典: 社の台本（2026-10-09 に人の ADC へ落とす口を退役）。コマンドの意味は gcloud auth print-access-token・Authorize the gcloud CLI（2026-11-01 に見た）。
台本で決めている線は次の 3 つです（出典: 社の台本・2026-10-09）。
- 人の口座の ADC が生きていても、そこへ落とさない（2026-10-09 にその口を退役した）
- 台本は gcloud auth login を撃たない。駄目なら止まって報告する
- トークンと鍵の中身は印字しない
よくある質問
gcloud auth login と gcloud auth application-default login はどちらを使えばよいですか？
gcloud のコマンドを撃つなら gcloud auth login、自分のコードやクライアントライブラリから Google Cloud を呼ぶなら gcloud auth application-default login です。後者は gcloud auth login の口座に影響しません（gcloud auth application-default login・2026-11-01 に見た）。
gcloud アカウントの切り替えはどうしますか？
gcloud auth list で取り込み済みの口座を見て、gcloud config set account 口座 で有効な口座を切り替えます。切り替えられるのは、前にログインを済ませた口座だけです（Authorize the gcloud CLI・2026-11-01 に見た）。
「Reauthentication failed. cannot prompt during non-interactive execution.」と出ます
人の口座の認証が切れ、認証し直しを求められたのに、聞く相手のいない実行だったため落ちた文です。当社では朝に通った操作が約 45 分後にこれで落ちました（社の実測 2026-09-17）。端末で人が 1 回ログインし直せば戻りますが、無人で撃つ作業は人の口座に頼らない経路に替える方が止まりません。
gcloud auth list が「No credentialed accounts」になります
その機体の gcloud に、資格情報が取り込まれた口座が 1 つも無い状態です。当社では新しい機体に移った直後にこうなり、ADC のファイルもありませんでした（社の実測 2026-09-26）。機体を移ったら、gcloud auth list と ADC のファイルの有無を先に見ます。
gcloud auth revoke をすると口座が消えますか？
消えません。人の口座なら機体の資格情報を消し、トークンを取り消します（gcloud auth revoke・2026-11-01 に見た）。当社が外した人の口座 3 つも、gcloud auth login で戻せます（社の実測 2026-09-19）。
出典
- Google Cloud「gcloud auth login」 https://docs.cloud.google.com/sdk/gcloud/reference/auth/login（2026-11-01 に見た・ブラウザでの認可・有効な口座になる事・
--update-adcと ADC の上書き・--no-browser・--no-launch-browser） - Google Cloud「gcloud auth application-default login」 https://docs.cloud.google.com/sdk/gcloud/reference/auth/application-default/login（2026-11-01 に見た・ADC の置き場に置く事・gcloud auth login の口座に影響しない事・quota project）
- Google Cloud「How Application Default Credentials works」 https://docs.cloud.google.com/docs/authentication/application-default-credentials（2026-11-01 に見た・ADC の探す順・資格情報のファイルの置き場）
- Google Cloud「Authorize the gcloud CLI」 https://docs.cloud.google.com/sdk/docs/authorizing（2026-11-01 に見た・
gcloud config set account・CLOUDSDK_AUTH_ACCESS_TOKENの優先・人の口座のアクセストークンの既定の寿命 1 時間） - Google Cloud「gcloud auth list」 https://docs.cloud.google.com/sdk/gcloud/reference/auth/list（2026-11-01 に見た・有効な口座は 1 つ・
--filter=status:ACTIVE） - Google Cloud「gcloud auth print-access-token」 https://docs.cloud.google.com/sdk/gcloud/reference/auth/print-access-token（2026-11-01 に見た・口座を省くと有効な口座）
- Google Cloud「gcloud auth revoke」 https://docs.cloud.google.com/sdk/gcloud/reference/auth/revoke（2026-11-01 に見た・機体の資格情報の削除・サービスアカウントは機体の中だけで鍵は消えない）
- Google Cloud「Use service account impersonation」 https://docs.cloud.google.com/docs/authentication/use-service-account-impersonation（2026-11-01 に見た・短い寿命の資格情報・トークン作成者の役割・
--impersonate-service-account） - 社の決まり 2026-08-20（席の都合で gcloud auth login を撃たせない）
- 社の実測 2026-09-17（人の口座の再認証切れ・約 45 分後に落ちた）
- 社の実測 2026-09-19（人の口座 3 つの revoke・陽性対照と陰性対照）
- 社の実測 2026-09-21（空のトークンで既定の口座へ落ちていた・診断の訂正）
- 社の記録 2026-09-22〜24（人の ADC を持つ 1 台が寝て 15 時間・9 件が止まった・鍵なしの専用サービスアカウント）
- 社の実測 2026-09-26（新しい機体で No credentialed accounts・ADC のファイル無し）
- 社の台本（2026-10-09 に人の ADC へ落とす口を退役・起動の前の確かめ）
- 社の実測 2026-10-14（別の機体の再認証切れで社の MCP が起動しなくなった）