未経験エンジニアが3ヶ月目で学んだ、GitHibにおけるプルリクエスト・セルフレビュー入門2026　〜悩めるレビュイーへ、私の屍を越えて行け

Posted at 2026-07-16

⚠️とても長い記事です。めんどい人はAIにURL渡して要約してもらってください。ただ本気で、自分の屍を越えていけの精神で書いてます。

未経験でエンジニアとして入社すると、知らない言葉が次々に登場する。
Git、GitHub、Issue、commit、branch、merge
そして、プルリクエスト(pull requests)。
私はこれまで、AIに助けてもらいながらプルリクエストを作ってきた。
しかし、ある日言われてしまった。
内容を簡単にまとめると、こうである。

私からレビューを依頼されたとき、モヤモヤする瞬間が多々ある。
それを完全に0にすることは難しいが、0に近づける努力はできる。
「PR セルフレビュー」で検索し、記事を読んで学んでほしい。

かなり柔らかく書かれている。
だが、要するにこういうことである。
私のプルリクエスト、レビューしづらいらしい。
心当たりはある。
むしろ、心当たりしかない。
でも、未経験で入社してレビューする側の気持ちなど考えている余裕などあるわけもない。そもそも人様のプルリクエストにレビューすることなんて、今の時点であるわけがないのだ。
そこで今回は、「PR セルフレビュー」で検索して見つけた8本の記事と、「心がけているPRの書き方とコードレビューについて」という記事を読み、未経験のレビュイー側として学んだことをまとめる。

プルリクエストに対しての以前の自分

以前の私は、プルリクエストを「作業完了報告書」だと思っていた。

Issueに書かれた作業をする。
AIにコードを修正してもらう。
テストを実行する。
AIが「問題ありません」と言う。
PRを作る。
レビューを依頼する。
はい、私の仕事は終わり。
あとはよろしくお願いします！

そんな感覚だった。

PRを作ること自体がゴールになっていた。
マージ先のブランチは合っているか。
余計な差分が含まれていないか。
変更の意図が伝わるか。
レビュワーが何を確認すればよいのか。
そこまで深く考えられていなかった。
PRの本文も、AIやSKILLが生成した文章をそのまま使うことが多かった。
内容をまったく読んでいなかったわけではない。
しかし、
「一応、それらしい文章になっている」
「Issueの番号も書いてある」
「テスト結果も載っている」
くらいの確認で終わっていた。
例えるなら、AIが詰めてくれた旅行カバンを、中身を確認せず空港へ持っていくようなものである。
たぶんパンツは入っている。
でも、パスポートが入っているかは知らない。

自分の個人開発でも同じだった。
シミュレーターで動かす。
画面が表示される。
ボタンも押せる。
「問題なく動いている！ヨシ！」
これで終わり。
現場猫も止めに入る確認方法である。

コードを全部読むことも、差分を見ることも、まだ難しい。
だから、動いていれば問題ないと思っていた。
しかし、画面が動くことと変更内容が適切であることは別の話だった。
余計なファイルを変更しているかもしれない。
他の機能へ影響しているかもしれない。
将来、修正しづらいコードになっているかもしれない。
AIがIssueの意図を勘違いしているかもしれない。
動作確認だけでは、そこまでわからない。
そして何より、以前の私は、レビューしてもらうことを「相手の作業」として考えていた。
PRを出した後は、レビュワーが問題を探してくれる。
何かあれば指摘してくれる。
私は直せばよい。
完全に受け身だった。
しかし、レビュワーは私の品質保証担当者ではない。
自分で確認できることまで相手に探してもらうのは、レビューではなく丸投げである。
コードはAIに丸投げ。
確認はレビュワーに丸投げ。
このままでは、私の仕事はPR作成ボタンを押すことだけになってしまう。

プルリクエストとは

プルリクエスト、通称PRとは
自分が作業したブランチの変更を、別のブランチへ取り込んでもらうための提案である。
たとえば、機能追加用のブランチで作業した内容を、developブランチへ反映したいとする。
一応書いておくと、私は「1つのissueを作業するにあたり、issue番号（例：287）の書かれたブランチをmainとかdevelopから切って作業し、PRまで仕上げ」ています。
そのときに、
「このような理由で変更しました」
「このファイルを変更しました」
「この方法で動作確認しました」
「問題がなければ取り込んでください」
と伝えるのがプルリクエストである。
ただし、単なる作業完了報告ではない。
変更の目的を共有する。
実装内容を確認する。
不具合や見落としを探す。
必要なら修正する。
チーム内で認識を合わせる。
成果物の品質を高める。
そのための、変更を中心としたコミュニケーションの場である。
今は生成AIがコードを書いてくれる。
Issueを読ませれば修正してくれる。
commitも作る。
PRの本文も書く。
簡単なレビューまでしてくれる。

では、人間によるレビューは不要になるのか。
おそらく、なくならない。
AIが書いたコードでも、最終的にその変更を採用し、運用するのは人間である。
要件を満たしているか。
余計な変更が含まれていないか。
他の機能を壊していないか。
チームの方針に合っているか。
今後も保守しやすいか。
ユーザーにとって不自然ではないか。
こうした判断には、プロジェクトの背景や、これまでの経緯、チーム内の共通認識が必要になる。
上の方も、自分のプロダクトで生成AIにコードを書かせた場合、必ずブランチを分けてPRを作り、成果物と差分を確認しているという。

AIが「完了しました」と言ったから完了。
テストが通ったから正解。
画面が動いたから安全。
そうとは限らない。
AIは自信満々に間違えることがある。
そして、間違えたAIは責任を取ってくれない。
最終確認をするのは、人間である。
つらい。
最後の責任だけ、しっかり人間に残されている。

記事8本と追加の記事から学んだこと

今回、「PR セルフレビュー」で検索して見つけた記事を8本読んだ。
さらに、「心がけているPRの書き方とコードレビューについて」という記事も読んだ。
合計9本である。
これだけ読めば、私もレビュー仙人になれるのではないかと思った。
もちろん、そんなことはなかった。
しかし、以前よりもセルフレビューが何のためにあるのかは理解できた。
なお、重要すぎる部分は危険マーク⚠️をつけた。マークが多ければ多いほど重要度が高いと踏んでもらって構わない。

セルフレビューは、コードの間違い探しだけではない⚠️

セルフレビューと聞いたとき、最初は「自分でコードを読み直すこと」だと思っていた。
しかし、私はまだコードを読むこと自体が難しい。
AIが書いたコードを見ても、
「英語がいっぱい書いてある」
「カッコがたくさんある」
「赤くなっていないから、たぶん大丈夫」
くらいしかわからないこともある。
それでも、セルフレビューで確認できることはある。
PRの目的が伝わるか。
変更内容が説明されているか。
関連Issueがわかるか。
不要なファイルが含まれていないか。
画面変更のスクリーンショットがあるか。
動作確認結果が書かれているか。
不安な点や未対応部分が隠されていないか。
レビュワーが確認しやすい状態になっているか。
セルフレビューとは、コードだけを見る行為ではない。
レビューを依頼できる状態まで、PR全体を自分で整えることでもある。

ブラウザの分割ビューを使うと、左でPC版、右でスマホ版など検証できてスクショも1枚で収まるよ。試してみてね。

レビュワーを憑依させる⚠️

読んだ記事の中で、特に印象に残ったのが「レビュワーを憑依させる」という考え方だった。
自分が作ったPRを見ると、どうしても都合よく読んでしまう。
自分は作業の経緯を知っている。
なぜ変更したか知っている。
どこで苦労したかも知っている。
AIと何十往復したかも知っている。
そのため、説明が多少不足していても、自分には理解できる。
しかし、レビュワーは初見である。
レビュワーが見られるのは、主に次の情報だ。

Issue
PRのタイトル
PRの本文
変更差分
commit
スクリーンショット
動作確認結果
コメント

私の頭の中にしかない情報は、レビュワーには見えない。
書かなければ、存在しないのと同じである。
私は以前、
「プロは差分の見方を知っている、だから何かあれば指摘がくるし大丈夫だろう。きっとわかってくれる。」
と思っていた。
わかるわけがない。
相手はエンジニアではあるが、エスパーではない。
自分のPRを、他人が作ったPRだと思って読み直す。
タイトルだけで内容が伝わるか。
本文を読めば目的がわかるか。
何を確認すればよいか明確か。
不安な部分が隠されていないか。
一度、自分をPRの作者から追い出して読む必要がある。
最初はまず、本文を読めば目的や作業内容がわかるところから始めてみるといいかも。

WhyとWhatを書く⚠️

追加で読んだ記事では、PRの説明に、少なくともWhyとWhatを書くことが紹介されていた。
Whyは、なぜこのPRが必要なのか。
Whatは、何を変更したのか。
たとえば、
ログイン画面を修正しました。
だけでは、変更した事実しかわからない。
これを次のようにする。
スマートフォン表示時にログインボタンが画面外へはみ出していたため、レイアウトを修正しました。
これなら、変更の背景と目的が伝わる。
さらに、

ボタンの横幅を修正
スマートフォン表示時の余白を調整
関連するテストを追加

と書けば、具体的な変更内容もわかる。
Issueへのリンクだけを貼って終わるのではなく、PR側にも最低限の概要を残す。
後からPRを見た人が、外部の管理サービスや過去の会話を探さなくても、変更の背景を追えるようにするためである。
以前の私は、Issue番号が書かれていれば十分だと思っていた。
説明責任をIssueへ全投げしていた。
ここでも丸投げである。

スクリーンショットは相手への思いやり⚠️⚠️

画面変更を含むPRでは、BeforeとAfterのスクリーンショットがあると確認しやすい。
変更前。変更後。
PC表示。スマートフォン表示。
ライトモード。ダークモード。
必要に応じて画像や動画を添える。
もちろん、スクリーンショットだけでレビューが終わるわけではない。
しかし、レビュワーが自分の環境で起動する前に、変更結果を視覚的に確認できる。
私は以前、
「手元で動いたから大丈夫」
と考えていた。
レビューをお願いしている側なのに、確認作業まで相手任せである。
今更ながら、過去のPRを見返すのが怖い。
スクリーンショットが必要な変更だったのに、何も添付せず、
「修正しました。確認お願いします」
だけで投げていた可能性がある。
レビュワーからすれば、
「何をどう確認すればいいんだ」
である。

再掲するが、スクショの枚数が多くなってもしんどいので分割ビューは使ったほうがいい。

PRを作る前にdiffを見る⚠️

PR作成前には、変更差分を確認する。
これは非常に基本的なことらしい。
私はその基本を、かなり後になって知った。
変更したつもりのないファイルが含まれていないか。
デバッグ用のコードが残っていないか。
関係のない整形が大量に入っていないか。
秘密情報が含まれていないか。
想定したブランチからPRを作っているか。
マージ先は正しいか。
AIが作業した場合は、特に重要である。
AIはこちらの依頼を広く解釈して、頼んでいないところまで「ついでに改善」することがある。
親切である。
親切だが、怖い。
掃除を頼んだら、壁紙まで張り替えているようなものである。
コードを完璧に理解できなくても、変更ファイルの一覧や、明らかに関係のない差分は確認できる。
「コードが読めないから見ても意味がない」ではない。
読める範囲だけでも見る。
わからないところは、AIに質問する。これ大事。
自分は最近、作業した元イシューの画面と、横に作成されたPRの画面の2タブで作業している。で、完了条件とか大丈夫かなーって見てる。それ見ながらPRに書き足したりしている。
ちょっとでも疑問があったら、「元イシューの完了条件に◯◯って書いてあったけど守ってる？」とかAIに聞けばいい。

PRは小さく分ける⚠️⚠️

記事の中で何度も出てきたのが、PRを小さくするという考え方だった。
一つのPRに複数の目的が入っている。
変更ファイルが多い。
リファクタリングと機能追加が混ざっている。
UI変更とロジック変更が同時に入っている。
こうなると、レビューが難しくなる。
差分が大きければ、見落としも増える。
そこで、**「困難は分割せよ」**である。
ただし、PRを適切に分割すること自体が技術である。
「次から小さくしてください」
と言われて、すぐ完璧にできる人は少ない。
私もまだ、どこを境目に分ければよいかわからない。
しかも、私の作業ではAIがIssueの実行からPR作成まで一括で行うことがある。
その場合、PRを小さくするには、Issueを作る段階から粒度を考える必要がある。
会社では、管理しやすさを考えて、基本的にIssue一つにつきPR一つになるよう意識しているという。
ただし、IssueやPRを細かくしすぎると、AIへ読み込ませる回数が増え、トークン消費も増える。
レビューしやすさ。
管理しやすさ。
AIのトークン消費。
作業効率。
これらのバランスを考える必要がある。
細かければ細かいほど正しいわけではない。
ケースバイケース。
エンジニアの世界、万能の正解がなさすぎる。

Draft PR と WIP を使い分ける⚠️⚠️

作業途中や、まだ正式なレビューを依頼できない状態では、Draft PRを使う方法がある。PRの画面で右側に、レビュワー選ぶところの下にDraft とか書いてあるボタンがある。

これ。Convert to draft。あ、もう無理あとで修正しよう！って思った時に押してる。

タイトルに[WIP]を付ける
タイトルに[Draft]を付ける
「下書き」と記載する
レビュワーをアサインしない
本文に「まだレビュー不要」と書く

といった方法で、作業途中であることを伝えられる。
私は参考記事を読んでGitHubでDraftへ変更できるボタンを見つけた時、怖くて押せなかった。
そのため、スクリーンショットを撮って上の人に確認した。
これは未経験者として、正しい判断だったと思う。
GitHubの共有画面にある、意味を完全に理解していないボタンを、好奇心だけで押してはいけない。
「押したらどうなるんだろう」は、個人リポジトリで試すべきである。
会社のPRは実験場ではない。

レビュー依頼は「お願いします」だけで終わらせない⚠️

レビューを依頼するときは、
レビューお願いします。
だけではなく、PRの概要を一言添える。
たとえば、
スマートフォン表示時のレイアウト崩れを修正しました。
特にログインボタン周辺の表示をご確認いただきたいです。
レビューをお願いします。
これだけでも、レビュワーはPRの目的と、重点的に見る箇所を理解できる。
レビュワーにはレビュワーの仕事がある。
自分の作業を止めて、こちらのPRを確認してくれている。
PRを開いて、Issueを探して、差分を読んで、ようやく目的を理解する状態では負担が大きい。
レビューを依頼することは、相手の時間を借りることでもある。
だからこそ、確認しやすい状態に整える必要がある。
とは言っても私はレビュワーリクエストボタンを祈り願いながら押しているだけである。特段チャットを飛ばしたりはしていない。

レビューコメントには対応内容を返す⚠️

レビューコメントをもらったら、コードを修正するだけでは足りない。
どのように対応したのか。
どのcommitで修正したのか。
対応しない場合は、なぜ対応しないのか。
意図が理解できない場合は、何を確認したいのか。
それをコメントで伝える。
たとえば、
ご指摘ありがとうございます。
指定いただいた方法へ修正しました。
あわせて動作確認も行い、問題がないことを確認しました。
または、
ご指摘ありがとうございます。
認識を確認したいのですが、こちらは〇〇の方法へ変更するという理解で合っていますでしょうか。
追加で読んだ記事では、可能であれば一つの指摘に対して一つのcommitにする方法も紹介されていた。
そうすれば、
〇〇するように修正しました。
対応commitはこちらです。
と伝えられる。
レビュワーは、そのcommitを中心に確認できる。
ただし、これもチームの運用ルールによる。
何でも細かくcommitすればよいわけではない。
大事なのは、レビュワーが「どこを直したのか」を追える状態にすることである。
ちなみに私はそれもcodexに投げてしまっている。codexが作業して作り上げたものなんだから、codexに回答させるのが早くて確実である。

返信したつもりがPendingだった⚠️⚠️⚠️⚠️⚠️

今回、私が特に気をつけなければならなかったのが、Pendingである。

レビューコメントに対して返信を書いた。
文章を入力した。
画面にも表示された。
私は相手へ送信できたと思っていた。
しかし、届いていなかった。
コメントがPendingのままになっていたからである。
Pendingとは、保留中という意味である。書き途中、とでもいうべきか。
GitHubでStart a reviewを使ってコメントを追加した場合、レビュー全体を送信するまで、そのコメントは相手へ公開されない。
自分の画面には表示される。
しかし、相手には見えていない。
私は返信したつもり。
相手から見れば無視されている。
私の返信は、インターネットの海へ出航することなく、GitHubの港で待機していた。
恐ろしい。
レビューコメントを書いた後は、次の点を確認する必要がある。

コメントにPendingと表示されていないか
Finish your reviewが表示されていないか
Review changesに未送信件数が出ていないか
最後にSubmit reviewを押したか
必要に応じて画面を再読み込みして確認したか

Add single commentであれば、コメントは単独ですぐに送信される。
一方、Start a reviewでは複数のコメントをためて、最後にまとめて送信できる。
複数箇所をレビューするときには便利である。
しかし、最後にレビューを送信しなければ、すべてPendingのままである。
コメントを書いたところで安心してはいけない。
遠足は家に帰るまで。
レビューはSubmit reviewを押すまで。

File changed から複数の行にコメントを入れるわけだが、緑のボタンをよく見てほしい。Start a reviewだ。これから始まるのだ。始まるだけなのだ。

画面右上のSubmit reviewを押し忘れてはいけない。押すとFinish your reviewってウインドウが出る。「書き終わったー？」って聞かれているだけなので、慌てずにSubmit reviewを押そう。これでPendingは消え去り、コメントはPRの大海原へ旅立つのだ。

Pendingのまま放置していた場合⚠️⚠️⚠️

Pendingに気づいたら、まずレビューを送信する。
その後、相手を待たせてしまった場合は、簡潔に説明する。
申し訳ありません。
レビューコメントへ返信したつもりでしたが、Pendingのままになっており、送信できていませんでした。
先ほどSubmit reviewを行いました。
確認が遅くなってしまい、申し訳ありません。
ごまかさない。
GitHubのせいにしない。
「なぜか送信されていませんでした」という、怪奇現象にしない。
自分が送信を完了できていなかったことを伝える。
必要な操作を済ませる。
そして、再発防止策を作る。知らなかったなら、今知る。
ミスを完全に0にすることは難しい。
しかし、0に近づける努力はできる。
慌てず、誰かのせいにせず、現実を受け止めてまず謝罪すること。
わからないことは悪いことじゃない。
今知って、あとでちゃんと活かせればいい。
それでも相手や上司へ待たせてしまった罪悪感が消えなくて夜眠れなくなったら、コメントください。一緒に飲みましょう。

Pendingの時は本当に知らなくて、本当に病んで、ずっと泣いてました。息子にずっと寄り添っててもらいました。

レビュワーから Approve が出たら⚠️⚠️

感謝の気持ちと共に全速力でマージしましょう。
でも慌ててはいけない。
私は先月、マージ先を間違えて大惨事を起こし、チェリーピック🍒とrevertで泣きながら作業していた。
古臭い方法だが、今は
①レビュワーからOKが出たか(右側レビュワー欄に緑のチェック✅がついたか)または承認します等のコメントがついたか
②作業ブランチ、マージ先ブランチの向きは正しいか
を指差し、声出し、確認してマージボタンを押している。
レビュワーは時間をかけてくれている。
承認(Approve)してくれたのにいつまでもマージされないとモヤるかもしれない。
慌てずに、一緒に始めよう。指差し確認。ヨシ！

コンフリクトしたら⚠️

私流、コンフリクトした場合の対処法
「PR#◯◯◯がコンフリクトしている。Approveは出てる。対処して」
と、codexに丸投げをする。これで解決。
新しいバージョンのcodexはとっても賢いので前後のPRやissue、直前にマージされたものなど全体を見渡して作業してくれる。
特段伝えたいことがあればプロンプトに入力すればいい。
「PR#♦︎♦︎番の内容を壊さないでほしい」とか。

まとめ

9本の記事を読んで、プルリクエストに対する考え方が変わった。
以前の私は、PRを作れば自分の仕事は終わりだと思っていた。
しかし、PRは完成報告書ではない。
変更内容について、レビュワーとレビュイーが会話し、成果物をより良い状態へ近づけるための場所である。
レビュイー側では、少なくとも次のことを確認したい。

マージ先のブランチは正しいか
PRのWhyとWhatが書かれているか
関連Issueがわかるか
不要な差分が含まれていないか
動作確認結果が書かれているか
必要なスクリーンショットがあるか
特に見てほしい箇所が伝わるか
不安な点や未対応部分を隠していないか
PRが大きすぎないか
レビューコメントへ返信したか
Pendingが残っていないか
Submit reviewを押したか
必要なら再レビューを依頼したか

セルフレビューは、コードの間違いを自分で探すことだけではない。
レビュワーが確認しやすい状態になっているか。
変更の目的が伝わるか。
余計な負担をかけていないか。
自分が責任を持って確認したと言えるか。
そこまで含めて見直すことだった。
そして、よいPRはレビュイーだけでは完成しない。
レビュワーから指摘をもらう。
レビュイーが修正する。
認識が違えば話し合う。
PRが大きければ分割を検討する。
お互いに遠慮せず、成果物を良くするために会話する。
よいPRは、レビュワーとレビュイーの両方で作るものなのだと思う。

今後の自分はこうでありたい

私はまだ、コードをスラスラと書けない。
現在の開発では、生成AIにコードを書いてもらうことが多い。
PRの本文も、AIに助けてもらっている。
それでも、
「AIが作ったから、自分にはわかりません」
では仕事にならない。
すべてのコードを完璧に説明できなくても、作業前に何をしたいのか、どこを変えたいのか確認する。
何のための変更なのかは理解する。
どのファイルが変更されたのか確認する。
画面がどう変わったのか確認する。
余計な差分がないか見る。
わからない部分は、わからないと伝える。
不安な点は隠さない。
AIが生成した文章も、自分の言葉として相手へ渡せる内容になっているか確認する。
そんなレビュイーになりたい。
また、レビューを「怒られる時間」と考えないようにしたい。
指摘を受けると、今でも怖い。
一つコメントがつくだけで、
「無能だと思われた」
「会社を追い出されるかもしれない」
「今から退職届を書いた方がいいのではないか」
と、脳内会議が始まる。
しかし、レビューの目的は、私を公開処刑することではない。
マージ前に問題を見つけること。
より良い方法を学ぶこと。
チーム内で認識を合わせること。
自分一人では気づけなかった視点をもらうこと。
そう考えたい。
そして将来、自分が誰かをレビューする立場になったときは、今の気持ちを忘れないようにしたい。
なぜこの指摘が必要なのかを書く。
相手の人格ではなく、コードや成果物について話す。
命令だけでなく、理由や提案を添える。
良かった部分も言葉にする。
相手が質問しやすい雰囲気を作る。
レビューを受ける側の不安を知っているからこそ、優しいレビュワーになれるかもしれない。
採用面接でも、
「チーム開発をしたことがありますか」
「レビューではどこを見ていますか」
「指摘を受けたとき、どう対応しましたか」
と聞かれることがあるらしい。
今の私は、まだ立派な回答をできない。
しかし、
「最初はPRを作れば終わりだと思っていました」
「レビューしやすい状態へ整えることも、レビュイーの仕事だと学びました」
「Pendingのまま返信を送れていなかった失敗から、確認手順を作りました」
とは答えられる。
失敗は恥ずかしい。できれば隠したい。
脳内の黒歴史フォルダへ移動し、二度と開きたくない。
それでも、失敗した後に調べ、仕組みに変え、次の行動を変えられたなら、完全な無駄ではない。
今後は、PRを作成する前にdiffを見る。
WhyとWhatを書く。
必要な画像を添える。
相手が確認しやすい状態へ整える。
レビューコメントには、対応内容を返す。
Pendingを確認する。
Submit reviewを押す。
そして不安になって、もう一度確認する。
石橋を叩きすぎて、橋が少しへこんでも構わない。
私の返信が、GitHubの港で永遠に出航待ちをするよりはマシである。