Claude Media
Google Cloud authentication failedの原因と対処 — Claude Codeの403
Claude CodeTips

Google Cloud authentication failedの原因と対処 — Claude Codeの403

「Google Cloud authentication failed」はAgent Platformが返す403です。IAMロール不足とモデル未有効化を、確認コマンド付きで切り分けます。

読了目安 約14分

「Google Cloud authentication failed」は認可の拒否を示す403

Google Cloud authentication failedは、Google CloudのAgent Platform(旧Vertex AI)が403を返したときにClaude Codeが出すエラーです。名前に「authentication」とありますが、403はAgent Platformが期限切れの認証情報ではなく認可の拒否に使うステータスです。

つまり、サインインし直せば直るとは限りません。多くの場合、原因は次の2つのどちらかです。

  • 認証に使っている身元(ユーザーやサービスアカウント)に、IAMの権限が足りない
  • 使おうとしているClaudeモデルが、そのプロジェクトで有効になっていない

認証情報の期限切れは、別のエラーとして401で報告されます。この記事は403側だけを扱い、切り分けの順序と確認コマンドをまとめます。

表示されるメッセージの読み方

実際の表示は次の形です。

Google Cloud authentication failed · refresh your Google Cloud credentials (application default sign-in, or the key file in GOOGLE_APPLICATION_CREDENTIALS) and retry · if credentials are current, check GCP IAM permissions and Vertex AI model access · API Error: 403 ...

中央のヒント部分は、設定に応じて変わります。固定なのは先頭のGoogle Cloud authentication failedだけです。

ヒントの後半に「認証情報が最新なら、GCPのIAM権限とVertex AIのモデルアクセスを確認する」という趣旨の案内が入っています。前半の「認証情報を更新して再試行」は、401と共通の定型句です。403のときは、後半のほうが本命です。

ヒントが「認証情報はこの環境が管理している」という趣旨のときは、話が変わります。Claude Codeを起動したアプリが認証情報を持っているため、以降の手順は当てはまりません。再試行するか、管理者に問い合わせます。

401と403は原因の層が違う

同じGoogle Cloud関連でも、401と403では見る場所が変わります。

項目Google Cloud credentials expired or invalidGoogle Cloud authentication failed
ステータスGoogle Cloud credentials expired or invalid401Google Cloud authentication failed403
Agent Platformでの意味Google Cloud credentials expired or invalid認証情報の期限切れ・拒否Google Cloud authentication failed認可の拒否
典型原因Google Cloud credentials expired or invalidADCの期限切れ、キーファイルの無効Google Cloud authentication failedIAMロール不足、モデル未有効化
まず試すことGoogle Cloud credentials expired or invalidgcloud auth application-default loginGoogle Cloud authentication failedロールとModel Gardenの確認

401側の詳細は、公式のエラーリファレンスのGoogle Cloud credentials expired or invalidの節にあります。AWS版の事情はAWS authentication failedの原因と対処に書いてあります。AWSではトークン失効も403で報告されるため切り分けが難しい一方、Google Cloudの403は認可の拒否として読めます。この違いが切り分けを軽くします。

切り分けの手順

次の順で確認します。上から順に、安くて確実なものです。

手順

403を切り分ける順序

  1. 1

    Claude Codeが見ているプロジェクトを確認する

    Claude Codeを起動して/statusを実行します。API providerがGoogle Vertex AIで、GCP projectとDefault regionが想定どおりかを見ます。

    Claude Codeは、Agent PlatformへのリクエストをANTHROPIC_VERTEX_PROJECT_IDのプロジェクト宛てに送ります。GCLOUD_PROJECTやGOOGLE_CLOUD_PROJECT、GOOGLE_APPLICATION_CREDENTIALSのキーファイル内に別のプロジェクトが書かれていても、この変数が優先されます。権限を付けたプロジェクトと、実際にリクエストが向かうプロジェクトが食い違う例が、ここで見つかります。

  2. 2

    認証情報が生きていることを確かめる

    401を除外するために、Claude Codeを起動するのと同じシェルで次を実行します。

    gcloud auth application-default print-access-token

    トークンが表示されれば、認証情報そのものは有効です。エラーが出るなら、403ではなく認証側の問題なのでgcloud auth application-default loginでADCを取り直します。

  3. 3

    使われている身元を確かめる

    どの身元で動いているかを見ます。ADCがユーザーのものか、サービスアカウントかによって、権限を付ける相手が変わります。GOOGLE_APPLICATION_CREDENTIALSが設定されていれば、そのキーファイルのサービスアカウントです。

    echo "$GOOGLE_APPLICATION_CREDENTIALS"
gcloud auth list

    GOOGLE_APPLICATION_CREDENTIALSが空なら、gcloud auth application-default loginで作ったユーザー認証のADCが使われます。

  4. 4

    IAMロールを確認する

    対象の身元にroles/aiplatform.userが付いているかを見ます。次章で詳しく扱います。

  5. 5

    モデルが有効かを確認する

    Model Gardenで、使うClaudeモデルが有効になっているかを見ます。これも後続の章で扱います。

IAMロールを確認する

公式が案内するロールはroles/aiplatform.userです。これに含まれる権限のうち、Claude Codeが必要とするのはaiplatform.endpoints.predictで、モデルの呼び出しとトークンのカウントに使われます。

もっと絞りたい場合は、この権限だけを持つカスタムロールを作る方法もあります。

付与状況はgcloudで確認できます。次のコマンドは、プロジェクトのIAMポリシーから、特定のメンバーに付いたロールだけを抜き出します。

gcloud projects get-iam-policy YOUR-PROJECT-ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:YOUR-ACCOUNT" \
  --format="table(bindings.role)"

YOUR-PROJECT-IDはANTHROPIC_VERTEX_PROJECT_IDと同じ値、YOUR-ACCOUNTはユーザーのメールアドレスかサービスアカウントのメールアドレスに置き換えます。一覧にroles/aiplatform.userか、同等の権限を持つロールがなければ、ここが原因です。グループ経由や組織レベルで付与している場合は、この出力に現れないことがあります。そのときはコンソールのIAM画面で継承も含めて見ます。

チームで展開する場合のロール設計は、Claude Code Vertex AI IAM設定とチーム展開ガイドにまとめています。

モデルが有効になっていないとき

IAMが正しいのに403になるなら、モデルの有効化を疑います。手順は次のとおりです。

  1. Agent PlatformのModel Gardenを開く
  2. 「Claude」を検索する
  3. 使いたいClaudeモデルへのアクセスを申請する
  4. 承認を待つ(公式は24〜48時間かかることがあると説明している)

申請した直後は、まだ403が続く可能性があります。承認の通知やModel Garden上の表示で、有効化されたことを確認してから再試行します。

Agent Platform APIそのものが有効かどうかも、見落としやすい点です。プロジェクトでaiplatform.googleapis.comを有効にしていなければ、モデルの申請以前に呼び出しが通りません。

gcloud config set project YOUR-PROJECT-ID
gcloud services enable aiplatform.googleapis.com

403ではなく404のとき

エラー文言がmodel not foundの404なら、別の原因です。公式のトラブルシューティングは、Model Gardenでモデルが有効かどうかに加えて、指定したロケーションでそのモデルが提供されているかの確認を挙げています。モデルによってはglobalか、eu・usのようなマルチリージョンだけで提供され、個別のリージョンにはありません。リージョン側の設定はClaude CodeでVertex AIのリージョンを設定するで扱っています。

起動時のモデル確認と、403の関係

Claude Codeは、Agent Platform構成で起動するとき、使おうとするモデルがプロジェクトで呼び出せるかを確認します。モデルを固定していない場合に、既定のモデルが使えなければ、そのセッションに限って以前のバージョンへフォールバックし、通知を出します。

この確認で、プロジェクトが呼び出せないモデルが見つかると、Claude Codeはその拒否をこのマシンで最大1日覚えます。覚えている間の起動では、そのモデルをAgent Platformに問い合わせ直さず飛ばします。現行の既定モデルについては、前回の確認から10分たつと起動時に確認し直します。管理者がモデルを再び有効にしたとき、既定のモデルが戻ってくる仕組みです。

固定したモデルを使っている場合は事情が違います。--modelやANTHROPIC_MODELで特定のバージョンを指定してセッションを始めると、そのモデルは固定された既定として扱われ、フォールバックしません。固定したモデルに権限がないときに403が表に出るのは、この構成です。

セッション中に管理者がモデルを無効にした場合も同じです。固定していない階層なら、Claude CodeはSwitched to <fallback> because <model> is not availableと表示して別のモデルへ切り替えます。固定したバージョンのセッションは切り替わらず、フォールバックのチェーンを設定していなければリクエストが失敗します。

gcpAuthRefreshでは直らない理由

gcpAuthRefreshを設定しているのに403が続くことがあります。これは設定の誤りではなく、仕様のとおりです。

gcpAuthRefreshは、認証情報が期限切れか、読み込めないとClaude Codeが判断したときに、設定したコマンドを実行します。実行前に現在の認証情報でアクセストークンを要求し、まだ有効ならコマンドを動かしません。

{
  "gcpAuthRefresh": "gcloud auth application-default login",
  "env": {
    "ANTHROPIC_VERTEX_PROJECT_ID": "your-project-id"
  }
}

IAM権限の不足やモデル未有効化が原因の403では、認証情報は有効なままです。したがってClaude Codeは、リフレッシュコマンドを自動では走らせません。ブラウザのログイン画面が開かないまま403が出続けるのは、このためです。再ログインでは直らないので、IAMとモデルの確認に進みます。

なお、この確認が5秒以内に終わらないときも、Claude Codeはコマンドを飛ばします。リクエストが認証エラーで失敗した後にだけ実行します。v2.1.261より前は、タイムアウトを期限切れとして扱い、認証情報が有効でも起動時にブラウザが開くことがありました。

バージョンによる表示の違い

v2.1.273より前は、Agent Platformの403は汎用のPlease run /loginやFailed to authenticateとして表示されていました。この文面ではGoogle Cloudの認証情報を更新できないため、/loginを案内されても無意味でした。v2.1.273以降は、設定とは無関係にGoogle Cloud authentication failedと表示されます。

古いバージョンでは、原因が同じでも別の文面になります。まずclaude --versionで版を確認します。

claude --version

切り分けの早見表

症状見る場所対処
print-access-tokenが失敗する見る場所ADC対処gcloud auth application-default login
想定外のプロジェクト名が/statusに出る見る場所ANTHROPIC_VERTEX_PROJECT_ID対処値を権限のあるプロジェクトに合わせる
ロール一覧にroles/aiplatform.userがない見る場所IAM対処ロールを付与する
ロールはあるのに403が続く見る場所Model Garden対処モデルのアクセスを申請・確認する
model not foundの404見る場所ロケーション対処モデルが提供されるリージョンに合わせる
再ログインしても変わらない見る場所全体対処IAMとモデルが原因。認証情報は有効

この表の「再ログインしても変わらない」が、403の特徴です。ログインを繰り返す前に、上から2行目までを確認してください。

組織の管理下にある環境のとき

ヒントが、認証情報はこの環境が管理していると示している場合は、組織の仕組みが認証情報を持っています。個人のgcloudで直そうとしても、Claude Codeが使っている身元を変えられません。この場合は、権限の付与とモデルの有効化を管理者に依頼します。何のロールが足りないかを伝えられるよう、/statusのGCP projectと、エラー全文のAPI Error: 403 ...以降を控えておくと話が早く進みます。

LLMゲートウェイ経由でCLAUDE_CODE_SKIP_VERTEX_AUTHを設定している場合、Google Cloud側の認証はスキップされ、トークンはANTHROPIC_AUTH_TOKENやANTHROPIC_CUSTOM_HEADERSで渡されます。そのときの401は、ゲートウェイのトークン更新が必要という意味になります。この記事の403とは別の経路です。

初めてAgent Platformを設定する場合は、/setup-vertexウィザードが、認証方法・プロジェクト・リージョン・モデルの固定までを順に案内します。ウィザードが確認するのはClaude側の設定です。GCP側のAPI有効化とモデル申請は、事前に済ませておく必要があります。

まとめ

403はAgent Platformが認可を拒否した合図で、認証情報の期限切れではありません。print-access-tokenで認証情報の生存を確かめ、/statusでプロジェクトを固定し、roles/aiplatform.userとModel Gardenのモデル有効化を順に見ます。再ログインを繰り返しても変わらないときは、IAMとモデルの側が原因です。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →