GitLab が承認を断った理由
API でマージリクエストを承認するとき（POST /projects/:id/merge_requests/:iid/approve）、GitLab は 403・409・401 のどれかで断り、401 には理由が書いてありません。承認の取り消し（…/unapprove）は、取り消すものが無いと 404 を返します。以下はすべて GitLab のソース（lib/api/merge_request_approvals.rb と承認の処理）を 2026年10月24日に読んで確かめたものです。
承認：答えの意味
- 403
{"message":"403 Forbidden"}：このプロジェクトでは、あなたのアカウントはそもそも承認できません。ソースでは、承認にはプロジェクトのメンバーとしてマージリクエストを更新できる権限が要ります。Premium と Ultimate では、承認のルールに指定されたグループのメンバーも承認できます。 - 409
SHA does not match HEAD of source branch: …（和訳：SHA がソースブランチの先頭と一致しません）：レビューしたコミットをshaで送ったが、ソースブランチの先頭が別のコミットになっています（コロンの後ろに新しい先頭が付きます）。見た後に誰かが push しました。 - 401
{"message":"401 Unauthorized"}：GitLab が承認そのものを見て断りました。期限切れや取り消されたトークンも 401 ですが、そのときの答えにはinvalid_tokenと書いてあります。トークンに何が起きたかへ。
api の権限が無いトークンも 403 で断られますが、そのときの答えには insufficient_scope と書いてあります。足す権限の見つけ方へ。
401 の理由
ソースでは次の場合があり、文はどれも同じです：
- もう承認している。承認は 1 人 1 回です。
- もうマージされている。
- あなたが作成者で、プロジェクトの Prevent approval by merge request creator (author)（作成者による承認を防ぐ）が入っている。Premium と Ultimate では、GitLab の説明によると、初めから作成者は承認できません。
- あなたがコミットを足した人で、プロジェクトの Prevent approvals by users who add commits（コミットを足した人による承認を防ぐ）が入っている。
- 承認の前にもう一度サインインするよう求めるプロジェクト（Require user re-authentication to approve）で、要求に正しいパスワードが
approval_passwordとして入っていない。グループかインスタンスが SAML での認証を求めているときは、この方法での承認は必ず失敗する、と GitLab の説明にあります。
承認の取り消し：404
…/unapprove の {"message":"404 Not found"} は、マージリクエストが無いという意味ではありません。ソースでは、取り消すあなたの承認が無いという意味です。承認していない（またはもう取り消した）、マージ済み、または GitLab がマージしている最中でロックされている、のどれかです。
いまどうなっているか
curl -H "PRIVATE-TOKEN: your-token" "https://gitlab.com/api/v4/projects/group%2Fproject/merge_requests/42/approvals"
承認の状態の答えには、user_has_approved（あなたが承認済み）・user_can_approve（あなたが今承認できる）・approved_by があります。Premium と Ultimate では、approvals_left と require_password_to_approve もあります。
直し方
- 409：新しいコミットを見てから、新しい先頭を承認する。
- 401：承認の状態を読む。
user_has_approvedが true なら、あなたの承認はもう入っています。作成者かコミットを足した人で、プロジェクトがそれを防いでいるなら、別のレビュアーに頼む。もう一度のサインインを求めるプロジェクトなら、それを尋ねてくれる GitLab の画面で承認する。 - 403：メンテナーに、承認できる役割か、承認のルールへの追加を頼む。
- 取り消しの 404：更新する。取り消せるあなたの承認は、もう残っていません。
IntelliJ IDEA の「Missing reviewer」「Waiting for review from …」「… approved review」「… is waiting for updates」
IntelliJ IDEA に入っている GitLab のマージリクエストの機能は、マージリクエストの状態にレビュアーを1人1行で並べます。ソース（2026年10月30日に確認）では、この行はマージリクエストのレビュアーだけから作られ、GraphQL がレビュアーごとに返す2つの値 approved と reviewed で決まります（GitLab の説明「UserMergeRequestInteraction」・IntelliJ IDEA：GitLabMergeRequestReviewFlowViewModel.kt・userReviewer.graphql・GitLabMergeRequestDetailsStatusChecksComponentFactory.kt・CodeReviewDetailsStatusComponentFactory.kt・ReviewDetailsUIUtil.kt）：
- 「Missing reviewer」（レビュアーがいない）は、マージリクエストにレビュアーが1人もいないときに出ます。レビュアーでない人が承認していても変わりません。
- 「… approved review」（承認した）は、そのレビュアーがマージリクエストを承認したとき。
- 「… is waiting for updates」（更新を待っている）は、承認しておらず
reviewedが true のとき。GitLab のソースでは、reviewedが true なのはレビュアーのレビューの状態がREVIEWED（レビューした）のあいだだけです（GitLab の説明「MergeRequestReviewState」・merge_request_interaction.rb・merge_request_reviewer_state.rb）。 - 「Waiting for review from …」（レビュー待ち）は、それ以外のすべて：まだレビューしていない人のほか、変更を求めた人（
REQUESTED_CHANGES）、承認を取り消した人（UNAPPROVED）、レビューを始めて出していない人（REVIEW_STARTED）も入ります。つまり IntelliJ IDEA では、変更を求めたレビュアーは「まだレビューしていない人」と同じに見えます。
承認していないレビュアーの行には、そのレビュアーを外す操作が付きます。
IntelliJ IDEA で GitLab のマージリクエストを見るなら
Lesstep の Merge Request Inbox for GitLab は、JetBrains IDE（2024.1 以降）のプラグインです。画面に出ていた先頭のコミットを承認し、承認した後は、代わりに承認の取り消しを出します。変更の依頼もできます。GitLab が承認を断ったときは、そう言います。409 ならソースブランチが変わったので更新するように、401 か 403 なら GitLab の文を添えて、プロジェクトでの役割か設定が許していない可能性がある、と。ほかの断りは GitLab の文で伝えます。見るのは無料、承認・コメント・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。
GITLAB は GitLab Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitLab Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：GitLab のマージの断り（405・409・422） · GitLab の「insufficient_scope」 · GitLab の 401「invalid_token」 · GitLab の 404「Project Not Found」 · GitLab のコメント・スレッドの断り（400・403） · GitLab のマージリクエストが作れない（409・422・400） · GitLab のリベースの断り・失敗（403・409） · GitLab の MR の一覧の断り（400・404） · GitLab の MR の変更が欠ける（「1000+」・too_large） · GitLab の 429「Retry later」（回数の上限） · GitLab の「compare_timeout」（差分の上限） · JetBrains の IDE で GitLab のマージリクエストを扱う · English