Azure DevOps：承認が「最低レビュー担当者数」に数えられない理由
ブランチ ポリシー Require a minimum number of reviewers（最低限のレビュー担当者数を必須にする）は承認を数えますが、どの承認でも数えるわけではありません。ポリシーのいくつかの設定が、どの投票を数えるかを決め、ソース ブランチへの push が承認を外すこともあります。承認の数は足りているのにポリシーが満たされないときは、たいていこの設定のどれかが理由です。
設定
Microsoft のページ Set and manage branch policies（英語・2026年7月更新）から：
- Allow requestors to approve their own changes（依頼者が自分の変更を承認できる）：これが無いと、プルリクエストの作成者も「承認」に投票できますが、最低数には数えません。
- Prohibit the most recent pusher from approving their own changes（直近にプッシュした人が自分の変更を承認するのを禁止）：ソース ブランチへ最後に push した人の投票は、ふだん自分の変更を承認できる人でも数えません。Microsoft は、職務の分離のための設定としています。
- Allow completion even if some reviewers vote to wait or reject（待機や却下の投票があっても完了を許可）：これが無いと、「作成者を待機」か「却下」が1つあれば完了できません。あっても、承認の最低数は要ります。
- When new changes are pushed（新しい変更が push されたとき）は、次のどれか：
- Require at least one approval on every iteration（すべてのイテレーションで少なくとも1つの承認を必須）：自分が push して誰も承認していない前のイテレーションには、自分の承認を数えないので、最後のものは別の人が承認する必要があります（Azure DevOps Server 2022.1 以降）。
- Require at least one approval on the last iteration（最後のイテレーションで少なくとも1つの承認を必須）：ソース ブランチの最新の push に、少なくとも1つの承認。
- Reset all approval votes (does not reset votes to reject or wait)（承認の投票をすべてリセット。却下と待機はリセットしない）：push で承認が外れます。
- Reset all code reviewer votes（レビュー担当者の投票をすべてリセット）：push で、承認も却下も待機も、すべての投票が外れます。
名前を決めたレビュー担当者は、別のポリシー Automatically included reviewers（自動的に含まれるレビュー担当者）です。Required にすると、追加した人は全員が、グループはそれぞれ少なくとも1人が承認する必要があり、最低数とは別に求められます。こちらにも Allow requestors to approve their own changes があります。
「At least 1 reviewer besides most recent pusher must approve the most recent iteration」
（「直近にプッシュした人以外のレビュー担当者が少なくとも1人、最新のイテレーションを承認する必要がある」）満たされていないポリシーは、プルリクエストに1行で出ます。検索されているのは、この行や「At least one reviewer must approve the most recent iteration」のような行です。行の部分は、それぞれ上の設定の1つです。
- 「At least 1 reviewer」：レビュー担当者の最低数。
- 「besides most recent pusher」（直近にプッシュした人以外）：Prohibit the most recent pusher from approving their own changes が入っています。ソース ブランチへ最後に push した人（直しを入れた作成者や、直しを push したレビュー担当者）は、数える承認を出せません。
- 「the most recent iteration」（最新のイテレーション）：最新の push への承認を求める設定（Require at least one approval on the last iteration か on every iteration）です。ソース ブランチへの push ごとに新しいイテレーションになるので、最新の push より前の承認では満たされません。
まとめると、最新の push の後に、その push をした人以外が承認します。ほかに承認できる人がいなければ、リポジトリの権限 Bypass policies when completing pull requests を持つ人がポリシーを上書きできます（ポリシーを回避する明示的なオーバーライド）。
よくある場面
- 自分で作ったプルリクエストを自分で承認した。ポリシーが依頼者の承認を許していなければ数えません。
- 同僚のプルリクエストに直しを push してから承認した。「直近にプッシュした人」の禁止があると、自分の承認は数えなくなります。別のレビュー担当者の承認が要ります。
- push の後に承認が消えた。ソース ブランチが変わると承認（またはすべての投票）をリセットする設定です。レビュー担当者が新しいコミットをもう一度承認します。
- 承認は足りているのに満たされない。数えない承認（作成者の、最後に push した人の）、最新の push への承認を求める設定、完了を許していない「却下」や「作成者を待機」を探します。
- 数は満たしているのに、完了が断られる。ほかのポリシーが通っていません。必須のレビュー担当者、ビルド、コメントの解決、作業項目のリンク。ポリシーを回避する明示的なオーバーライドへ。
スクリプトでは
Azure CLI では az repos policy approver-count create か update でこのポリシーを設定し、--creator-vote-counts・--allow-downvotes・--reset-on-source-push が上の設定にあたります。プルリクエストのポリシーが満たされない理由は、そのプルリクエストのポリシー評価（GET {project}/_apis/policy/evaluations?artifactId=…・プレビューの API）で、ポリシーごとの状態と設定が分かります。このポリシーの設定には minimumApproverCount・creatorVoteCounts・blockLastPusherVote・requireVoteOnLastIteration・requireVoteOnEachIteration・allowDownvotes があります。
IntelliJ IDEA と Rider で Azure DevOps のプルリクエストを
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。自分のレビューを待っているプルリクエストを IDE のツールウィンドウに並べます。Azure DevOps Services でも Azure DevOps Server でも使えます。プルリクエストのブランチ ポリシーを、状態つきの文で見せます。このポリシーなら、たとえば「2 人以上の承認。作成者自身の投票は数えない。直近にプッシュした人の承認は数えない。最新のプッシュへの承認が必要」。その横にビルド、コメントの解決、作業項目。1.0.44 からは、開いた後にソース ブランチへ新しいコミットが入っていたら、承認を送りません。承認はそのコミットにも効くためです。レビューの受け箱とブランチ ポリシーは無料、投票・コメント・完了・作成は Pro（30日間の無料試用つき）です。画面は日本語です。
Azure DevOps は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：5つの投票の意味 · 必須のレビュー担当者とパスの絞り込み · ポリシーを回避する明示的なオーバーライド · TF402455：このブランチへの push は許可されていない · IntelliJ IDEA で使える Azure DevOps のプルリクエストのプラグインの比較 · English