英語コードレビューコメントの書き方｜建設的で簡潔な30フレーズ
最終更新: 2026-05-24
目次
本記事はアフィリエイト広告を含みます。
「英語の Pull Request レビュー、どう書けばエンジニアの感情を逆撫でしない？」「nit, LGTM, WDYT… 略語の使い分けが知りたい」── 英語のコードレビューは、質問形式・suggestion・nit の使い分けと、業界で確立された略語の理解が鍵です。本記事では、建設的で簡潔な 30 フレーズを実例で解説します。
1. コードレビューの基本トーン
英語のコードレビューでは「コードを批評する、人を批評しない」が大原則。"You did this wrong" ではなく "This could be 〜" のように、コードを主語にします。
3 つの基本トーン
- Question（質問）— 意図を確認する。最も非対立的
- Suggestion（提案）— こうしたらどうか、と提示
- Nit（重箱の隅）— 細かい指摘、無視しても可
避けるべき書き方
- This is wrong.（これは間違い）— 断定的
- You should have used X.（X を使うべきだった）— 過去形で攻撃的
- Why did you do this?（なぜこうした）— 詰問口調
推奨書き方
- Could this be simplified using X?（X で簡潔にできますか）
- I'd suggest using X here — it handles edge case Y.（ここは X を提案、エッジケース Y を扱えるので）
- Curious — what was the reasoning behind this approach?（好奇心: このアプローチの理由は何でしたか）
レビュアー側が「自分も学んでいる」姿勢を見せるのが、英語圏のコードレビュー文化の特徴です。
2. よく使う略語の意味と使い方
英語のコードレビューには独自の略語文化があります。最頻出を押さえれば、レビューの読み・書きが一気にスムーズになります。
承認系
LGTM— Looks Good To Me（承認の意）LGTM with nits— 細かい指摘あるけど承認可SGTM— Sounds Good To Me（提案に賛成）+1— 賛成・同意
意見表明系
IMO— In My Opinion（私見では）IMHO— In My Humble Opinion（私見ですが、より控えめ）WDYT— What Do You Think?（どう思いますか）FYI— For Your Information（参考まで）TBH— To Be Honest（正直なところ）
指摘系
nit— nitpick（重箱の隅、無視可）nit:— コメント冒頭で「これは細かい指摘」と明示SSIA— Subject Says It All（タイトル参照）TIL— Today I Learned（今日学んだ）
使い方の例
- nit: missing trailing comma here.（nit: ここに末尾カンマがない）
- LGTM — minor nits, feel free to ignore.（LGTM、細かい指摘は無視 OK）
- IMO this should be a separate function. WDYT?（私見では別関数にすべき。どう思う？）
3. 質問形式（Question）で意図を確認する
レビュー初心者は「指摘する前に質問する」と覚えると、レビューの空気が良くなります。質問は誰も傷つけません。
意図を聞く質問
- Could you walk me through the logic here?（ここのロジック、流れを教えてもらえますか）
- Help me understand — why this approach over [alternative]?（理解したい、なぜ [代替案] ではなくこのアプローチ）
- Is there a reason for not using [X]?（X を使わない理由はありますか）
- What's the expected behavior when [edge case]?（[エッジケース] の時の期待動作は）
テスト・エッジケースの質問
- What happens if input is null?（入力が null の場合は何が起きますか）
- Have we tested this with empty arrays?（空配列でテスト済みですか）
- Does this handle the case when [condition]?（[条件] のケースを扱えますか）
設計判断の質問
- Curious about the choice to put this in [location] — what was the thinking?（[場所] に置いた選択について好奇心、考えは）
- Was there a reason for keeping this synchronous?（同期処理にしている理由は）
"Curious about" は「好奇心がある」の意で、相手を責めないフレーズとして頻出します。
4. Suggestion（提案）の言い回し
具体的な改善案を提示する時は、「これに変えて」ではなく「こういう方法もある」と選択肢として書くのが英語圏の作法です。
柔らかい提案の型
- What if we 〜?（〜したらどうですか）
- Could we 〜?（〜できますか）
- One option could be 〜（選択肢のひとつは〜）
- I'd suggest 〜（〜を提案します）
- Have you considered 〜?（〜は検討しましたか）
GitHub の suggestion block 機能
GitHub は```suggestion記法で具体的なコード変更案を提示できます。レビュアーが提案を書き、PR 作者がワンクリックで適用できる便利機能。
- Suggestion: extract this into a helper function.（提案: ヘルパー関数に抽出）
- Suggestion block below — feel free to apply if it makes sense.（下の suggestion block、納得感あれば適用してください）
強く推したい時
- I'd strongly recommend 〜 — it'll prevent [problem].（強く推奨、[問題] を防げます）
- This is a must-fix before merge.（これは merge 前の必須修正）
- Blocking on 〜 — please address before merge.（〜でブロックします、merge 前に対応をお願いします）
5. nit（重箱の隅）の使い方
"nit" は「指摘するけど無視しても OK」の意の魔法のラベル。これを付けるだけで、PR 作者の心理的負担がぐっと減ります。
nit の典型例
- nit: typo — "recieve" should be "receive".（nit: タイポ、"recieve" → "receive"）
- nit: missing space after comma.（nit: カンマの後にスペース欠落）
- nit: would prefer camelCase for consistency.（nit: 一貫性のため camelCase を希望）
- nit: this comment could be a one-liner.（nit: このコメントは一行で済むかも）
「nit: feel free to ignore」
本当にどうでも良い nit には「無視可」と明示すると、PR 作者は「直す/直さない」の判断負荷から解放されます。
- nit: feel free to ignore — minor style preference.（nit: 無視 OK、私のスタイル好みです）
- nit: not blocking, just personal preference.（nit: ブロックしません、個人的な好み）
- Optional nit: 〜（任意 nit: 〜）
nit の濫用に注意
1 つの PR に nit が 30 個並ぶと、PR 作者は疲弊します。「lint で機械的に直せる nit はそもそも書かない」のがマナー。フォーマッタや lint で自動化すべきです。
6. Approve / Request changes の言い回し
レビュー結果の伝え方は明示的・簡潔に。Approve するのか、Request changes なのかを曖昧にしないこと。
Approve（承認）
- LGTM!（Looks Good To Me、最頻出）
- Looks great — approved.（いい感じ、承認）
- Approving — left a few nits, none blocking.（承認、nit いくつか、ブロックしません）
- Ship it! 🚀（出荷しよう）
Approve with conditions（条件付き承認）
- LGTM after addressing the comments above.（上のコメント対応後 LGTM）
- Approving in advance — please address the nits before merge.（事前承認、nit は merge 前に対応をお願いします）
Request changes（変更要求）
- A few changes needed before this can merge.（merge 前にいくつか変更が必要）
- Need to address [X] before approving.（[X] への対応後に承認します）
- Blocking on [issue] — happy to discuss.（[課題] でブロック、議論歓迎）
Comment only（コメントのみ）
- Leaving comments — not blocking, but worth looking at.（コメントだけ、ブロックしないが見る価値あり）
- Some thoughts inline — feel free to take or leave.（インラインに考えを書きました、採用も無視もご自由に）
7. 長文 vs 短文の使い分け
英語のコードレビューは基本は短文。長文を書くべきタイミングは限られています。
短文で十分なケース
- nit: typo.（タイポ）
- Missing test case.（テストケース不足）
- Could be extracted to a helper.（ヘルパーに抽出可）
- WDYT about caching this?（これをキャッシュしたら？）
長文を書くべきケース
- 設計判断の議論（なぜこの構造ではなく別の構造を推すか）
- セキュリティ・パフォーマンスの重大懸念
- 初学者へのメンタリング目的の解説
長文の構成
1. 問題の指摘（1 文）
2. なぜ問題か（背景・理由）
3. 提案する代替案
4. トレードオフの議論
- This approach works, but I'm a bit concerned about scalability. When [scenario], we'd hit [limit]. One alternative could be [X], which would [benefit]. The trade-off is [Y]. WDYT?（このアプローチは動くがスケーラビリティが少し気になります。〜のシナリオで限界。代替案は X、利点は〜、トレードオフは〜。どう思う？）
長文を書く時は必ず最後に「WDYT?」を添え、相手の意見を引き出します。一方的な講義にしないこと。
英語コードレビュー力を鍛える練習法
ステップ1：OSS の PR を読む
React, Vue, TypeScript などの有名 OSS の closed PR を読むと、ネイティブのエンジニアがどんなトーンでレビューしているかが分かります。LGTM, nit, WDYT などの略語の自然な使い方も身につきます。
ステップ2：Sentence Builder で意見表現の SVO を反射的に
当サイトのSentence Builderで "Could we 〜?" "I'd suggest 〜" のような構文を組み立てる練習をすると、レビューコメントが瞬時に書けるようになります。
ステップ3：Speaking Instant で技術討論の定型を瞬発的に
Speaking Instantの business カテゴリには "What if we 〜?" "Have you considered 〜?" "I'd recommend 〜" のような提案系の定型が多数収録されています。口で言えるフレーズは書く時にも瞬時に手が動きます。
ステップ4：オンライン英会話で「PR レビューロールプレイ」
オンライン英会話で「私が書いた擬似コードを講師にレビューしてもらう／講師の擬似コードを私が英語でレビューする」というロールプレイを依頼すると、レビュアーとレビュイーの両側面が鍛えられます。受け放題プランで毎日 10 分繰り返せば、英語コードレビューの呼吸が身につきます。
英語コードレビュー力を、毎日のレッスンで磨く
英語のコードレビューは「コードを批評する・人を批評しない」「質問・提案・nit を使い分ける」「短く・建設的に」が原則です。この感覚は、毎日少しずつ英語ネイティブと技術的な対話を交わすことで身につきます。受け放題プランで 5〜10 分の短いレッスンを積み重ね、技術トピックを英語で議論する練習を繰り返すと、GitHub PR でも瞬時に手が動くようになります。
まずは 7 日間の無料体験で、英語での技術ディスカッションを試してみるのがおすすめです。
本記事はアフィリエイト広告を含みます。