Microsoft Foundry authentication failedの原因と対処 — 401と403

「Microsoft Foundry authentication failed」は401か403の拒否を示す

Microsoft Foundry authentication failedは、Microsoft Foundryが401または403を返したときにClaude Codeが出すエラーです。リクエストに載せたAzureの資格情報が拒否されたか、その資格情報の持ち主がFoundryリソースにアクセスできないか、のどちらかを意味します。

重要なのは、/loginでは直らない点です。/loginはAnthropicのアカウント用で、Azureの資格情報は作れません。更新するのは、自分で設定した次の3つのうちのどれかです。

• ANTHROPIC_FOUNDRY_API_KEY(Foundryポータルから取ったAPIキー)
• ANTHROPIC_FOUNDRY_AUTH_TOKEN(Microsoft Entra IDが発行したベアラートークン)
• az loginで作るMicrosoft Entraのサインイン(Azure SDKの既定の資格情報チェーン)

この記事では、メッセージの読み方、3つの資格情報の優先順位、設定の置き場所と向き先の確認、401と403の切り分け、Azure RBACの確認を順に扱います。

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

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

Microsoft Foundry authentication failed · refresh your Foundry credential (ANTHROPIC_FOUNDRY_AUTH_TOKEN, ANTHROPIC_FOUNDRY_API_KEY, Azure sign-in for Entra, or your proxy token) and retry · if credentials are current, check access to the Foundry resource · API Error: 401 ...

中央のヒントは設定によって変わります。固定なのは先頭のMicrosoft Foundry authentication failedだけです。末尾のAPI Error:のあとに続くステータスが401か403かで、疑う場所が分かれます。

ヒントの前半は「資格情報を更新して再試行」、後半は「資格情報が最新ならFoundryリソースへのアクセスを確認」の2部構成です。前半が401寄り、後半が403寄りの原因に当たります。

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

3つの資格情報と優先順位

Foundryの認証方式は3つあり、同時に設定したときの優先順位が決まっています。

ANTHROPIC_FOUNDRY_AUTH_TOKENはAPIキーと既定の資格情報チェーンの両方に優先します。ANTHROPIC_FOUNDRY_AUTH_TOKENが使えるのはv2.1.203以降です。

この優先順位から、見落としやすい落とし穴が1つ出ます。シェルやsettings.jsonのenvに古いANTHROPIC_FOUNDRY_AUTH_TOKENが残っていると、az loginをやり直しても、Claude Codeは古いトークンを送り続けます。ベアラートークンは有効期限があるため、数時間前に取ったトークンを環境変数に入れたままにしている構成では、az loginが成功していても401が出ます。

Entra IDで運用するなら、2つの変数が未設定であることが前提です。

効いている資格情報と設定の置き場所を洗い出す

切り分けの前に、いま何が効いているかを確かめます。環境変数は、シェルと設定ファイルのenvの2か所に置けるためです。値そのものは画面に出さず、設定の有無だけを見ます。

Claude Codeを起動するのと同じシェルで、設定済みの変数を確認します。

env | grep -E '^(CLAUDE_CODE_(USE|SKIP)_FOUNDRY|ANTHROPIC_FOUNDRY)' | sed 's/=.*/=<set>/'

ANTHROPIC_FOUNDRY_AUTH_TOKENが出れば、それが最優先で送られています。

settings.jsonのenvで設定している場合、シェルには現れません。設定ファイルはスコープごとに次の場所にあります。

組織が配る管理設定は別系統で、手元のファイルを見ても確かめられません。トークンを入れた覚えがないのに古い値が送られているときは、管理者に問い合わせる選択肢があります。

3つのファイルは、キー名だけを出す次のコマンドでまとめて見られます。値は表示されません。プロジェクトのルートで実行します。

grep -o -H '"ANTHROPIC_FOUNDRY[A-Z_]*"' \
  ~/.claude/settings.json \
  .claude/settings.json \
  .claude/settings.local.json 2>/dev/null

ANTHROPIC_FOUNDRY_AUTH_TOKENやANTHROPIC_FOUNDRY_API_KEYが見つかったファイルが、古い資格情報の置き場です。直したあとの反映は置き場で変わります。settings.jsonのenvはファイルを保存すると実行中のセッションにも再適用されます。シェルでexportした値は起動時にしか読まれないので、claudeを起動し直します。

向き先のリソースを決める設定キー

資格情報が正しくても、権限を付けたのとは別のリソースにリクエストが向かっていれば拒否されます。向き先を決めるキーは次の3つです。

リソース名にURLやホスト名を入れると、Claude Codeはメッセージ送信時に別のエラーで拒否します。401・403とは別の文面なので、本記事のエラーとは見分けられます。401・403が出ているなら形式は通っていて、向き先が想定と違うか、そのリソースへの権限が無いかのどちらかです。

Claude Codeを起動して/statusを実行し、API providerがMicrosoft Foundryで、リソース名かベースURLが想定どおりかを見ます。取り違えが何番のステータスになるかは、一次ソースに記載がありません。ただ、エラーの定義に「資格情報の持ち主がFoundryリソースにアクセスできない」場合が含まれるため、別リソースに向いているときは403側の症状として現れる可能性があります。

取り違えやすい例は次のとおりです。

• ANTHROPIC_FOUNDRY_RESOURCEとANTHROPIC_FOUNDRY_BASE_URLの両方を設定していて、片方が古いリソースを指している
• APIキーを別のリソースのEndpoints and keysから取っている
• プロジェクトの.claude/settings.jsonが、ユーザー設定と別のリソースを指している

401と403を切り分ける順序

効いている資格情報と向き先が分かったら、上から問いに答えていくと、更新するものが決まります。

Azure RBACでアクセス権を確認する

資格情報が生きているのに拒否されるときは、その身元に役割(ロール)が付いていない可能性があります。Claudeモデルの呼び出しに必要な権限は、既定ロールのAzure AI UserとCognitive Services Userのどちらにも含まれています。

さらに絞りたいときは、次のカスタムロールを作ります。

{
  "permissions": [
    {
      "dataActions": [
        "Microsoft.CognitiveServices/accounts/providers/*"
      ]
    }
  ]
}

付与状況はAzure CLIで見られます。以下はAzure CLIの一般的なコマンドで、Claude Code側の仕様ではありません。<assignee>にはユーザーのメールアドレスかサービスプリンシパルのIDを入れます。

az account show --query "{user:user.name, subscription:name}"
az role assignment list \
  --assignee <assignee> \
  --all \
  --query "[].{role:roleDefinitionName, scope:scope}" \
  --output table

一覧にAzure AI UserかCognitive Services Userがあり、そのスコープが対象のFoundryリソースを含んでいればロールは足りています。ロールを付けた直後に403が続く場合は、付与先の身元とスコープが合っているかを、この一覧で見直します。

グループ経由の付与は--assigneeでは出ないことがあります。その場合はAzureポータルのアクセス制御(IAM)画面で、継承を含めて確認します。

ChainedTokenCredentialのエラーとの違い

似た見た目のエラーに、Failed to get token from azureADTokenProvider: ChainedTokenCredential authentication failedがあります。こちらはリクエストがFoundryに届く前に、ローカルで資格情報を取得できなかった失敗です。

後者はセットアップの不備で、手順はClaude Code Microsoft Foundry設定ガイドの認証の節にあります。前者はセットアップ後の運用中に出るエラーです。

プロキシやゲートウェイを挟む構成

自前のプロキシやゲートウェイがAuthorizationヘッダーを付ける構成では、CLAUDE_CODE_SKIP_FOUNDRY_AUTHを使います。これはAzureの認証を省き、ANTHROPIC_CUSTOM_HEADERSなどで渡したヘッダーをそのまま保つ設定です。

ここで401が出たなら、疑うのはAzureの資格情報ではなくプロキシ側のトークンです。メッセージのヒントにも「your proxy token」が入っています。

この変数は、ANTHROPIC_FOUNDRY_API_KEYかANTHROPIC_FOUNDRY_AUTH_TOKENが設定されていると無視されます。ゲートウェイ構成なのに古いAPIキーの変数が残っていると、意図しない資格情報が送られます。

IDE拡張で出るときの注意

ターミナルでは通るのに、VS CodeやJetBrainsの拡張で失敗することがあります。IDEのプロセスがシェルの環境変数を引き継いでいない可能性があります。公式の案内では、プロバイダー用の環境変数をIDE自身の設定に入れるか、変数をexport済みのターミナルからIDEを起動します。

ANTHROPIC_FOUNDRY_API_KEYやANTHROPIC_FOUNDRY_AUTH_TOKENが環境変数としてIDE側に渡っていないと、設定したはずの資格情報が使われず、別の経路(既定の資格情報チェーン)で認証することになります。

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

v2.1.273より前は、Foundryの401・403は汎用のPlease run /loginやFailed to authenticateとして表示されていました。この文面ではAzureの資格情報を更新できないため、/loginを案内されても役に立ちません。v2.1.273以降はMicrosoft Foundry authentication failedと表示されます。

古いバージョンでは原因が同じでも別の文面になります。まずバージョンを確かめます。

claude --version

また、Foundry利用時は/logoutが使えません。認証がAzureの資格情報で行われるためです。資格情報を外したいときは、環境変数を外します。

まとめ

Microsoft Foundry authentication failedは、Azure側が資格情報かアクセス権を拒否したという報告です。最初に見るのは、最優先で送られるANTHROPIC_FOUNDRY_AUTH_TOKENが残っていないかです。それが無ければ、更新した資格情報で再試行し、なお出るならAzure AI Userなどのロールを確かめます。Foundryの周辺情報はClaudeをMicrosoft Foundryで使うにあり、Claude自体のログイン方式はClaude Codeのログイン方法でまとめています。