GitHub・プルリク・レビューの API・2026年10月24日に確認

GitHub：レビューが断られた・承認が数に入らない

レビューは POST /repos/持ち主/リポジトリ名/pulls/番号/reviews に、event を APPROVE・REQUEST_CHANGES・COMMENT のどれかにして送ります。GitHub の文書が挙げる答えは、作れたら 200、許されなければ 403、検証に通らないか送りすぎなら 422 です。422 の文は文書に載っていないので、以下は公開の報告にある文と、その裏にある GitHub の文書の決まりです（2026年10月24日に確認）。

422：GitHub の文と理由

Can not approve your own pull request（和訳：自分のプルリクは承認できません。変更の依頼では、GitHub CLI が Review Can not request changes on your own pull request と伝えます）：GitHub の文書は、プルリクの作者は自分のプルリクを承認できないとしています。あなたのアカウントが開いたか、トークンが開いたアカウントのもの（たとえば、開くのも承認するのも同じボット）です。
User can only have one pending review per pull request（和訳：保留中のレビューはプルリクごとに1つだけです。行のコメントへの返信では user_id can only have one pending review per pull request）：あなたのアカウントがこのプルリクでレビューを始め、まだ出していません。保留中の間は、別のレビューを作ることも、REST API で行のコメントに返信することも、この答えになります。
GitHub Actions is not permitted to approve pull requests.（和訳：GitHub Actions はプルリクを承認できません）：トークンがワークフローの GITHUB_TOKEN で、リポジトリが Actions にプルリクの作成と承認を許していません。個人のアカウントのリポジトリでは既定で許していません。組織のリポジトリは組織の設定を受け継ぎます。
body の無い変更の依頼やコメントのレビュー：GitHub の文書は、REQUEST_CHANGES と COMMENT には本文が要るとしています。event を付けないとレビューは保留中として作られ、保留中のレビューを event なしで出すと 422 です。

403・404

403 Resource not accessible by personal access token（または by integration）：トークンはプルリクを読めても、レビューはできません。細かい権限のトークンには Pull requests の読み書きが要ります（足す権限の見つけ方へ）。
404：このトークンにはリポジトリかプルリクが見えません。トークンが見られない非公開のリポジトリも、GitHub はこう答えます。

レビューは受け取られたのに、承認が数に入らない

どの承認が必要なレビューの数に入るかは、ブランチの保護で決まります（GitHub の保護されたブランチの文書）：

数に入るのは、リポジトリに書き込みの権限がある人か、指定されたコードの持ち主の承認です。読む権限があればだれでもレビューできますが、その承認は数に入りません。コードレビューの制限をオンにした公開リポジトリでは、明示されたアクセスの無い人はそもそも承認も変更の要求もできません（コードレビューの制限）。
Dismiss stale pull request approvals when new commits are pushed（新しいコミットが push されたら古い承認を取り消す）が有効なら、差分を変える push で承認は取り消され、もう一度だれかが承認する必要があります。
Require review from Code Owners（コードの持ち主のレビューを求める）が有効なら、持ち主のいるコードの変更には、その持ち主の承認が要ります。
Require approval of the most recent reviewable push（最後のレビュー対象の push の承認を求める）が有効なら、最後に push した人は、それを承認できません。
だれかが変更を依頼したら、そのレビュアーが承認するか、書き込みの権限のある人がそのレビューを取り消すまで、マージは Changes have been requested.（和訳：変更が依頼されています）で断られます（マージが断られた理由へ）。

直し方

自分のプルリク：ほかの人にレビューを頼むか、開いていないアカウントのトークンを使う。リポジトリの持ち主と管理者は、ルールが許す範囲で、承認なしにマージできます。
保留中のレビューが1つ：そのアカウントでブラウザでプルリクを開き、保留中のレビューを出すか捨ててから、もう一度試す。
GitHub Actions：リポジトリの Settings の Actions、General、Workflow permissions で、GitHub Actions にプルリクの作成と承認を許す（組織では、先に組織の持ち主が許す必要があることがあります）か、別のアカウントのトークンで承認する。
変更の依頼：body に何を変えてほしいかを書く。
承認が数に入らない：ブランチのルールを確かめ、最後の push の後にもう一度承認する。

IntelliJ IDEA では自分のプルリクに Approve が出ず、断られると「Failed to submit review」

IntelliJ IDEA に入っている GitHub の機能がレビューをどう送るか。ソース（2026年10月31日に確認・IntelliJ IDEA：GHPRSubmitReviewPopup.kt・GHPRSubmitReviewViewModel.kt・GHPRReviewViewModel.kt・GHPRReviewServiceImpl.kt・GHAPIExceptionUtil.kt）では：

Approve と Request Changes は、ログインしたアカウントがそのプルリクを開いた人ではないと GitHub が言うとき（viewerDidAuthor）だけ出ます。自分のプルリクでは Comment（「Submit general feedback without explicit approval」＝承認なしで全体への意見を送る）だけなので、「Can not approve your own pull request」は IDE からは出ません。
Request Changes と Comment は、何か書くか、まだ送っていないコメントがあるまで押せません。Approve はどちらも要りません。
送るのは GitHub の GraphQL の API で、上の REST の API ではありません。まだ送っていない自分の保留中のレビュー（未送信のコメント）を読み込んでいれば、それをボタンの種類で送ります（submitPullRequestReview）。無ければ、種類つきのレビューを1回で作ります（addPullRequestReview）。
GitHub が断ると「Failed to submit review」（レビューを送れなかった）と GitHub の文が出ます。必要なスコープの無いトークンは、代わりに「User authorization failed」です。書いた文は残るので、直してからもう一度送れます。

IntelliJ IDEA で GitHub のプルリクを見るなら

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。IDE のプルリクのページから、承認と変更の依頼ができます。変更の依頼では、GitHub が求めるので、先にコメントを聞きます。送るのは画面に出ていた先頭のコミットで、そのあとブランチが動いていたら何も送らず、読み直すように言います。GitHub が断ったときは GitHub の文を見せ、トークンの権限についての 403 なら、トークンに要るアクセスを言います。受信箱・差分・会話は無料、承認・コメント・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

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