Azure DevOps の「VS30063: You are not authorized to access https://dev.azure.com.」
「https://dev.azure.com にアクセスする権限がない」という意味で、送った資格情報を Azure DevOps が HTTP 401 で断ったときに出ます。直すのに要ることは書いてありません。住所はたいてい組織を含まない https://dev.azure.com だけで、トークンの期限切れなのか、別のテナントの物なのか、違う ID の物なのか、そもそも送っていないのかも言いません。2026年10月までの公開の報告は、Azure Pipelines のエージェント、Azure DevOps のクライアント ライブラリで作った .NET の道具、Azure CLI、Visual Studio Marketplace への公開、Azure DevOps の MCP サーバーからこの文を引いています。
この文はどこから来るか
- VS30063 は、Azure DevOps の .NET クライアント ライブラリが、サインインを断られたとき(
VssUnauthorizedException)に使う言葉です。あるオープンソースのプロジェクトが2026年9月に公開した分析によると、このクライアントは、Basic 認証を求める 401 を受けると、黙ってやり直したあとで VS30063 に置き換え、サーバー自身の文は渡しません。 - 2026年10月24日に、非公開の組織へ、トークンなし・正しくない個人用アクセス トークン・正しくない Bearer トークンで送ったとき(ヘッダー
X-TFS-FedAuthRedirect: Suppressつき)、サーバー自身の答えは3つとも HTTP 401 と、匿名の IDaaaaaaaa-…の TF400813 でした。ヘッダーなしでは、サインインのページへの 302 でした。 - つまりこのコードからわかるのは「資格情報が断られた」ことだけです。どれが、なぜかは、下のやり方で調べます。
何が断られたかを調べる
- 組織はどのテナントにあるか。
curl -sI https://dev.azure.com/<組織>
2026年10月24日には、2つの組織が 401 と一緒にヘッダーX-VSS-ResourceTenant: <テナント ID>を返し、同じ ID がWWW-Authenticate: Bearer authorization_uri=https://login.microsoftonline.com/<テナント ID>にもありました。Git Credential Manager も、どこでサインインするかをこの2つのヘッダーで決めています。そのコードでは、ID がすべて0なら、Microsoft Entra ではなく Microsoft アカウントの組織です。 - 自分のトークンはどのテナントの物か。Azure CLI なら
az account show --query tenantId。Microsoft Entra のトークンなら、その中のtid。2つの ID が違えば、それが理由です。 - 組織はそのトークンを誰として受け取るか。
curl -u ':<トークン>' -H 'X-TFS-FedAuthRedirect: Suppress' \ 'https://dev.azure.com/<組織>/_apis/connectionData'
Microsoft Entra のトークンなら、-uの代わりに-H 'Authorization: Bearer <トークン>'を送ります。authenticatedUser.providerDisplayNameを見て、自分の名前なら受け付けられています。401 と TF400813 なら断られています。公開プロジェクトのある組織では、2026年10月24日、正しくないトークンでも 200 が返り、名前はAnonymous、ID はaaaaaaaa-…でした。状態のコードではなく名前を見てください。
公開の報告が挙げる原因
- 長い実行の途中でトークンが切れた。Azure Pipelines のエージェントについての2026年4月の報告では、セルフホストのジョブを
timeoutInMinutes: 0で4日以上動かしたところ、約24時間後からログの送信とタイムラインの更新がis not authorized. VS30063で失敗しました。Microsoft の答えは、0 だとジョブのアクセス トークンはタイムアウトに合わせた長さではなく既定の長さになるので、timeoutInMinutesをジョブより長く(4日なら 5760)する、でした。報告した人はそれで直ったと書いています。Microsoft の Docker のエージェントの例への変更(4月に出て、2026年8月に取り込み)では、スクリプトが開始時にクライアント ID とシークレットで Microsoft Entra のトークンを取り、数時間〜数日後の後片付けが VS30063 で失敗していました。変更は、後片付けの前にトークンを取り直します。 - 正しいトークンだが、別の Microsoft Entra テナントの物。Azure DevOps のホストされた MCP サーバーについての2026年9月の報告では、組織のテナントにゲストとして入っている人が、一部のクライアントから自分のホームのテナントのトークンを渡され、Azure DevOps が VS30063 で断っていました。同じアカウントでも VS Code からは使えました。Microsoft の npm のサインインの道具(ado-npm-auth)への2026年4月のプルリクエスト(10月の時点でまだ開いている)は、そのトークンの道具が既定で Microsoft 自身のテナントに聞くので、ほかのテナントの組織では VS30063 になる、と説明し、テナントの指定を足しています。
- 資格情報のチェーンが違う ID を選んだ。.NET のビルドのパイプラインでの2026年4月の直しでは、仮のトークン
unsetを渡された道具がDefaultAzureCredentialに頼り、それがビルドのエージェントの上で、Azure CLI のサインインより先にエージェントのマネージド ID を試していました。そのマネージド ID は組織のメンバーではありませんでした。直しは、Azure CLI にトークンをはっきり頼んで道具に渡す、です:az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798(この ID は Azure DevOps を指します)。 - Visual Studio Marketplace への公開。このときの住所は
https://marketplace.visualstudio.comです。2026年8月の報告では、トークンは All accessible organizations(すべての組織)で、Marketplace (Manage) のスコープつきで作る必要があり、どちらかが欠けたトークンには VS30063 しか返りませんでした。なお Microsoft は、Azure DevOps Services ですべての組織用のトークンを廃止します。 - 資格情報をまったく送っていない。2026年8月の報告では、Marketplace のトークンをわざと設定していないリリースのジョブが、毎回 VS30063 で失敗していました。
- 自社のサーバーの Azure DevOps Server・TFS。Microsoft のパイプラインのトラブルシューティングは、エージェントの構成中の
VS30063: You are not authorized to access http://<SERVER>:8080/tfsを挙げ、サーバーの IIS で TFS の 匿名認証(Anonymous Authentication)が有効になっているかを確かめるように書いています。
どうするか
- 個人用アクセス トークンなら:User settings の Personal access tokens で期限を見て、この組織用に、道具が要るスコープで作り直します。
- テナントが違うなら:組織のテナントのトークンを取ります:
az login --tenant <テナント ID>、またはaz account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --tenant <テナント ID>。代わりにサインインしてくれる道具には、たいていテナントの指定があります。 - パイプラインなら:長いジョブは
timeoutInMinutesをジョブより長く。トークンを持ち続けるスクリプトは、使う手順の前に取り直す。資格情報のチェーンなら、トークンをはっきり渡す。
IntelliJ IDEA と Rider で Azure DevOps のプルリクエストを
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE(2024.1 以降)と Android Studio のプラグインです。自分のレビューを待っているプルリクエストを IDE のツールウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも使えます。.NET のクライアントは使わないので、Azure DevOps 自身の答えを読みます。断られた個人用アクセス トークンは「Azure DevOps が個人用アクセス トークンを受け付けませんでした」と、確かめる所と 設定を開く のリンクつきで出ます。断られた Azure CLI のサインインは、この組織を開けるアカウントでの az login を求めます。組織がまだ知らない Entra のアカウントは、そうと名指しします(TF401444)。1.0.39 からは、組織と別の Microsoft Entra テナントの Azure CLI のトークンが断られたとき(ゲストのアカウントなど)、組織のテナントのトークンを Azure CLI に頼み直して送り直し、Azure CLI がそこにサインインしていなければそのテナントを名指しします。レビューの受け箱は無料、投票・コメント・完了・作成は Pro(30日間の無料試用つき)です。画面は日本語です。
Azure DevOps・Microsoft Entra・Visual Studio は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに:git の「fatal: Authentication failed」:git での同じ拒否 · TF400813:トークンが受け付けられなかった · TF401444:組織がまだ Entra のアカウントを知らない · English