Azure Pipelines の「This pipeline needs permission to access a resource before this run can continue」：誰が Permit を押せるか、前もってパイプラインを許可する方法
失敗ではなく、実行が待っている状態です。YAML パイプラインが、まだそのパイプラインを許可していない保護されたリソースを使うと、ここで止まります。リソースは、サービス接続・エージェントプール・環境・変数グループ・セキュアファイル、Protect access to repositories in YAML pipelines が有効ならリポジトリです。そのリソースを管理する人が View、続けて Permit を押すと、実行が進みます（この文についての Stack Overflow の質問は3万回以上見られています）。
待っている実行がプルリクエストのビルド検証なら：JetBrains IDE のプラグイン Azure DevOps Pull Requests は、プルリクエストのブランチ ポリシーを状態つきで並べるので、まだ通っていない必須のビルドが、IDE の中でそのプルリクエストの横に出ます。JetBrains Marketplace で入れる
どう見えるか
- 実行の概要のページに
This pipeline needs permission to access a resource before this run can continue to <ステージ名>と View のボタンが出て、そのステージが待ちます。 - View を押すと Waiting for review が開きます。そこで Permit を押し、確かめの画面でもう一度 Permit を押します（Microsoft のサービス接続の手順）。
- Permit は、そのパイプラインをリソースの許可済みの利用者に加えるので、同じパイプラインがそのリソースでまた聞いてくることはありません。
- 実行がプルリクエストのビルド検証なら同じように待ち、誰かが許可するまで、そのプルリクエストのビルドのポリシーは通りません。
なぜ起きるか
- YAML パイプラインでは、サービス接続・エージェントプール・環境・リポジトリ・変数グループ・セキュアファイルが保護されたリソースです（Azure Pipelines のリソース）。それぞれにパイプラインの許可があり、プロジェクトのすべてのパイプラインに開くか、一覧に載せたパイプラインだけに絞るかのどちらかです。
- パイプラインは、作った人が少なくとも User の役割を持つリソースについてだけ、自動で許可されます（リソースの承認）。同僚が、自分は読むだけの環境へデプロイする新しいパイプラインを作ると、最初の実行で聞いてきます。
- Protect access to repositories in YAML pipelines（プロジェクトか組織の設定）が有効なら、Azure Repos の YAML パイプラインは、最初の実行で必ずリポジトリへのアクセスの許可を求めます（リポジトリへのアクセスを保護する）。GitHub のリポジトリにはこの設定は効きません。
誰が Permit を押せるか
Permit はリソースのパイプラインの許可を変えるので、必要なのはパイプラインの役割ではなく、そのリソースを管理する役割です。Microsoft のセキュリティの役割の表から：
- 環境：その環境の Administrator の役割です（「権限を管理できる」）。環境を作った人がこれを持ち、外せません。既定では Contributors は環境では Reader だけ、Project Administrators は Creator（環境を作る役割）だけなので、Project Administrators に入れただけでは、もうある環境で Permit は押せません。その環境で Administrator を付けます：Pipelines → Environments → その環境 → More actions → Security → User permissions。
- サービス接続：その Administrator の役割です（「サービス接続を使い、ほかのユーザーとグループの役割を管理できる」）。サービス接続を作った人と、[プロジェクト名]\Endpoint Administrators のグループが持っています。
- エージェントプール・変数グループ・セキュアファイル：そのプール・グループ・ファイルを管理する人、つまり Administrator の役割です（Project settings → Agent pools、または Pipelines → Library → Security）。
自分では押せず、ほかに押せる人もすぐいないなら、そのリソースを作った人に、待っている実行のリンクを送ってください。
前もってパイプラインを許可する
- リソースの Security のページの Pipeline permissions で、Restrict access なら一覧を持ち、+ でパイプラインを足します。Open access にすると、プロジェクトのどのパイプラインもそのリソースを使えます。環境で Open access にできるのは Project Administrators だけです。
- サービス接続とエージェントプールは Project settings → Pipelines、変数グループとセキュアファイルは Pipelines → Library、環境は Pipelines → Environments にあります。
- サービス接続には Grant access permission to all pipelines もありますが、Microsoft は勧めておらず、パイプラインごとに許可するよう書いています。
- REST API では、Pipeline Permissions - Update が、いくつかのパイプラインについて Permit と同じことをします。Microsoft の例のリソースはエージェントプールのキュー（
queueとその ID）です。パイプラインの ID は、パイプラインのアドレスのdefinitionIdです。
PATCH https://dev.azure.com/YOUR-ORG/YOUR-PROJECT/_apis/pipelines/pipelinepermissions/queue/QUEUE-ID?api-version=7.1-preview.1
{ "pipelines": [ { "id": 16, "authorized": true } ] }
見分け方
- 待たずに失敗し、
Could not find a <resource> with name <name>. The <resource> does not exist or has not been authorized for useと出る：Microsoft は、そのリソースで少なくとも User の役割があるかを確かめ、失敗した実行から許可して、新しく実行するよう書いています。 Environment <name> could not be found. The environment does not exist or has not been authorized for use.：環境がなく、Azure Pipelines が誰が作るのかを知らなかったので、パイプラインが作れなかった（YAML を Web のエディター以外で変えた、トリガーで実行が始まった）。先に環境を作ります（Microsoft の FAQ）。- 必須のビルドが動いていないか通っておらず、完了が断られる：「This pull request requires an explicit override to bypass policies that aren't currently passing」。
IntelliJ IDEA と Rider で Azure DevOps のプルリクエスト
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。組織・プロジェクト・リポジトリを git のリモートから読み、自分のレビューを待っているプルリクエストを IDE のツールウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも使えます。プルリクエストのブランチ ポリシーを状態つきで並べるので、まだ通っていない必須のビルドがそのプルリクエストの横に出ます。必須のポリシーが通っていないときは、完了の画面がまず自動完了を勧めます。レビューの受信箱は無料、投票・コメント・完了・作成は Pro（30日間の無料試用つき）です。画面は日本語です。
Azure DevOps・Azure Pipelines は Microsoft Corporation の商標、GitHub は GitHub, Inc. の商標、IntelliJ IDEA・Rider は JetBrains s.r.o. の商標です。このページは Microsoft・GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：Microsoft ホストの並列ジョブがまだない · 必須のポリシーが通っていない · Node.js 6・10・16 は2026年11月24日にエージェントから外される · English