Approve（レビュー承認）とは

定義と意味

Approveとは、Pull Request（PR）レビューにおいて「この変更は問題ない」と判断したレビュアーが行う正式な承認操作のことです。
主にGitHubやGitLabなどのコードホスティングサービスにおいて、レビューコメントとは別にUI上の専用操作として提供されています。

この機能は、単なる「LGTMコメント」以上に強い意味を持ち、CIやマージポリシーと連動してマージ可否を制御する鍵となります。

背景：なぜ「Approve操作」が導入されたのか

PR文化が広まった当初、多くのレビュー承認は単にコメントで行われていました。
たとえば：

LGTM！（Looks Good To Me）
OKです、マージして大丈夫だと思います

しかしこうしたコメントベースでは、CIとの連携やマージ条件の自動判定が難しく、レビューの完了基準が曖昧になる問題がありました。

その課題を解決するため、GitHub（2016年）などが明示的なレビュー操作としての Approve／Request Changes／Commentの3区分を導入しました。

UI上の位置と操作（GitHub）

GitHubでは、Pull Request の「Files changed」タブ → 「Review changes」ボタンから以下の3つのレビュータイプを選択できます：

実務での使われ方

例1：明文化されたマージ条件

多くのチームでは以下のようなルールを設定しています：

• PRには最低2件の Approve が必要
• レビュー担当外の Approve は無効
• Approve 前に CI チェックがパスしている必要がある

GitHubのBranch protection rulesと併用することで、これらの条件を機械的に enforce（強制）できます。

例2：Approve操作とLGTMコメントの併用

現場では以下のような両方を使うケースが多いです：

approve ボタンで正式に承認しつつ、「LGTMです！」というコメントで人間的なフィードバックも示す

この二重構成によって、レビュイー（レビューされる側）が心理的に確認しやすくなるメリットもあります。

会話例

ReviewerA:
  approveしました。命名と処理の分岐、特に問題ありません。
  LGTM！
ReviewerB:
  コメントのみですが、処理の順序について一応確認しておきたい点があります。

よくある注意点と落とし穴

🔸 Approve後の変更に気づかない

Approveしたあとにコードが書き換えられても、GitHubは自動で取り消さないため、意図しないコードがマージされるリスクがあります。

対策：

• 「Approveは最後に行う」運用を徹底する
• dismiss stale reviews を有効にして、PR更新時に自動で無効化する

🔸 Approveの重みがレビュアーによって違う

レビュー慣れしている人と新人では、Approveの「目の粗さ」に差が出ることも。
このため、「レビュー観点の明文化」「経験に応じたレビュー分担」などの対応が推奨されます。

まとめとナレッジの持ち帰り

• Approve はレビュー完了を明示する正式操作であり、マージ条件に直接関わる
• コメントと違い、CIやブランチ保護ルールと連携できるのが大きな特長
• 使用時は、操作のタイミング・レビューポリシー・通知の有無に注意

関連用語

• Pull Request
• LGTM
• Request Changes