Azure DevOps Services・Server・REST API、Azure CLI、Git のツール、パイプライン・2026年10月30日にサインインなしで確認

Azure DevOps の「TF200016: The following project does not exist: …. Verify that the name of the project is correct and that the project exists on the specified Azure DevOps Server.」

「コロンの後ろの名前のプロジェクトを探したが、無かった」という意味です。まずその名前を読んでください。公開の報告では、プロジェクトの名前でないことがよくあります：DefaultCollection、_git、リポジトリの名前、メールアドレス、作業項目の番号、あるいは正しい名前の1文字が途中で変わったもの。Team Foundation Server では、同じ文が「…on the specified Team Foundation Server.」で終わります。

答えの全体

公開の報告（2019〜2026年）に出ている形です。ここではリポジトリの一覧を求めたとき：

GET https://dev.azure.com/{organization}/{name}/_apis/git/repositories?api-version=7.1

HTTP/1.1 404 Not Found

{"$id": "1", "innerException": null,
 "message": "TF200016: The following project does not exist: {name}. Verify that the name of the project is correct and that the project exists on the specified Azure DevOps Server.",
 "typeName": "Microsoft.TeamFoundation.Core.WebApi.ProjectDoesNotExistWithNameException, Microsoft.TeamFoundation.Core.WebApi",
 "typeKey": "ProjectDoesNotExistWithNameException", …}

Azure CLI はこの文に Operation returned a 404 status code. を足して出します。パイプラインでは YAML ファイルのパスの後ろに出ます。

サインインしていないと、サインインの画面になる

2026年10月30日に dev.azure.com の公開プロジェクトへ、サインインなしで確かめました。TF200016 は一度も返りませんでした。サインインしていない呼び出しには、Azure DevOps は公開プロジェクトのことしか答えません。

プロジェクトでない名前（no-such-project・DefaultCollection・_git）：302 でサインインの画面へ。トークンなしで公開プロジェクトを読むツールがサインインに送られたら、トークンが要るのではなく、無いプロジェクトを求めているのかもしれません。
プロジェクトの名前を大文字にしても、末尾に空白を付けても（public%20）、そのプロジェクトを読めました。大文字と小文字や末尾の空白は TF200016 の原因になりません。
すべて 0 のプロジェクト ID：400、The guid specified for parameter projectId must not be Guid.Empty.
{organization}.visualstudio.com では、プロジェクトの前の DefaultCollection はそのまま通ります：…visualstudio.com/DefaultCollection/{project}/_apis/… は …visualstudio.com/{project}/_apis/… と同じく 200。dev.azure.com で同じパスにすると HTML の「404 - Page not found」でした。DefaultCollection がプロジェクトの名前になるのは、ツールがそれをプロジェクトと取り違えたときだけです。
git ls-remote は、dev.azure.com/{organization}/{project}/_git/{repository}・{organization}.visualstudio.com/{project}/_git/{repository}・{organization}.visualstudio.com/DefaultCollection/{project}/_git/{repository} で、大文字にしてもサインインなしで通りました。URL にプロジェクトが無い形（{organization}.visualstudio.com/DefaultCollection/_git/{repository} や dev.azure.com/{organization}/_git/{repository}）では、git がユーザー名を求めました。この形は「プロジェクトと同じ名前のリポジトリ」を指し、このリポジトリのプロジェクトは別の名前だからです。プロジェクトと同じ名前の公開リポジトリでは、プロジェクトの無い3つの形（{organization}.visualstudio.com/_git/{repository}・{organization}.visualstudio.com/DefaultCollection/_git/{repository}・dev.azure.com/{organization}/_git/{repository}）が、どれも完全な URL と同じリポジトリを読みました。

公開の報告に出てくる原因

visualstudio.com の昔のクローンの URL。Visual Studio Team Services は、プロジェクトの前に DefaultCollection の付いた https://{account}.visualstudio.com/DefaultCollection/{project}/_git/{repository} を、プロジェクトと同じ名前のリポジトリにはプロジェクトの無い …/DefaultCollection/_git/{repository} や …/_git/{repository} を配っていました。その頃のクローンには今もこれが残っています。パスを位置で読むツールが DefaultCollection をプロジェクトと取り違えたり（エディターの拡張機能の Azure DevOps 連携＝2026年にリポジトリの名前をプロジェクトとして読むよう直った、デスクトップのコーディングアプリの Azure DevOps 拡張＝2026年）、プロジェクトの無い URL から _git をプロジェクトとしたり（依存関係の更新ツール、2019年）しました。DefaultCollection はプロジェクトではなく、URL にプロジェクトが無ければプロジェクトはリポジトリの名前です。
プロジェクトの場所にリポジトリの名前。IDE のプラグイン（2025年）と、Azure DevOps Server 2020 上のセキュリティスキャナー（2023年）が、リポジトリと同じ名前のプロジェクトを求めました。これで通るのは、プロジェクトと同じ名前のリポジトリだけです。
途中で変わった名前。IDE のプラグインが ™ の入ったプロジェクトを …!22 として送り（2025年）、Azure CLI のプロジェクト一覧は ë の入ったプロジェクトで失敗して ã« と出しました（2025年・未解決）。空白や ASCII 以外の文字の入った名前は、UTF-8 で1回だけエンコードします。空白は %20 です。
名前を変えたプロジェクト。Microsoft のプロジェクトの名前を変更するによると、古い名前のリンクは引き続き使えますが、プロジェクトの名前を覚えているクライアントは再起動するまで「プロジェクトが見つからない」で失敗し、Git のリモートは全員が新しい名前に直す必要があります。2023年には、名前を変えた後もツールが古い名前で問い合わせ続け、TF200016 になりました。
プロジェクトでないもの。ユーザーのリポジトリを求める呼び出しにメールアドレス（2026年）、プロジェクトとして渡された作業項目の番号（2026年）、Microsoft のリポジトリをフォークして別の組織で動かしたパイプラインの YAML が指す、Microsoft 内部のパイプラインのテンプレート（1ESPipelineTemplates、2024年）。

確かめること

生の答えからコロンの後ろの名前を写します。DefaultCollection・_git・リポジトリの名前、あるいは名前でないものなら、ツールが URL を組み違えています。ツールが読んだ git のリモートか設定を見てください。
自分のアカウントで見えるプロジェクトと比べます：GET https://dev.azure.com/{organization}/_apis/projects?api-version=7.1 が名前と ID を並べます。
プロジェクトの名前を変えたなら、クライアントを再起動し、リモートを直します：git remote set-url origin <「クローン」に出る URL>
ツールがどちらも受け取るなら、プロジェクトの ID を渡します。REST API は同じ場所で「Project ID or project name」を受け取ります。
文が「does not exist, or you do not have permission to access it」なら、それは VS800075 です。プロジェクトの ID とアカウントの権限の話で、TF200016 ではありません。

IntelliJ IDEA と Rider で Azure DevOps のプルリクエストを

Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。組織・プロジェクト・リポジトリを git のリモートから読み、自分のレビューを待っているプルリクエストを IDE のツールウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも使えます。Visual Studio Team Services の昔の URL も読みます。プロジェクトの前に DefaultCollection が付いた形も、1.0.71 からはプロジェクトの無い形も（プロジェクトと同じ名前のリポジトリとして）、1.0.72 からは dev.azure.com/{organization}/_git/{repository} も。レビューの受け箱と差分は無料、投票・コメント・完了・作成は Pro（30日間の無料試用つき）です。画面は日本語です。

JetBrains Marketplace で入れる

Azure DevOps は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：Git のリモート URL：どの形が通るか · VS800075：アカウントがプロジェクトを見られない · TF401019：リポジトリが無いか、許可が無い · TF400813：ユーザーに許可が無い · English