英語のコードレビュー返信例｜修正・質問・代案の伝え方

英語のコードレビューに返信するときは、「指摘をどう理解したか」「何を変更したか、これから変更するか」「何を確認したか」を分けると伝わりやすくなります。難しい単語を増やすより、相手が次に何を見ればよいか分かる返信を目指しましょう。

この記事では、学習時間を保存するアプリを題材に、修正したとき、意図を聞きたいとき、別の方法を提案したいときの英語を練習します。例文は編集部が作成した教材用の会話です。実際の授業記録や、受講生・講師の発言を紹介するものではありません。

英語のレビュー返信は、4つの状況から選ぶ

コードレビューは、変更内容を他の人に確認してもらう作業です。GitHubのプルリクエストでは、一般的なコメント、承認、変更を求めるレビューが区別されています。コメントがあることだけを理由に「不合格」と受け止めたり、英語で返事をしたことだけで承認されたと考えたりしないようにしましょう。出典：GitHub公式：Pull request reviews。

返事を書く前に、指摘の対象が変数名、動作、テスト、設計のどれかを確認します。そのうえで、「修正済み」「修正する予定」「判断に必要な情報がない」を日本語で整理してください。

I’ll test it.は「これから試す」、I tested it.は「試した」です。短い差ですが、レビューする人の判断を変えます。AIに英文を整えてもらうときも、予定が完了形へ変わっていないか確かめましょう。

修正したときは、変更点と確認結果を返す

変数名が分かりにくいという指摘に対して、修正したあとで返す例です。

単にDone.と書いても伝わる場面はあります。ただ、練習では「何を」「どう変えたか」を1文で足すと、変更箇所を相手が探しやすくなります。動作を変えていないなら、関係のない改善まで付け足さないでください。

変更前なら、最後の文をI’ll rename t to studyMinutes.へ変えます。対応するつもりというだけで、修正済みの文をコピーしないことが大切です。

動作の修正は、確認した入力と結果まで書く

次は、学習時間が空欄でも保存される問題を指摘された場面です。以下の返信は、書かれている操作を実際に確認できた場合に使う例文です。

Thanks for pointing this out.
I added a check for an empty duration before saving.
I tested an empty value and confirmed that no record was added.
I also checked that a valid value of 30 minutes can still be saved.
I haven’t tested other browsers yet.

意味は、「空欄の確認を保存前に追加した。空欄では記録が増えず、30分は保存できることを確かめた。他のブラウザは未確認」です。修正内容、問題の再確認、正常な入力の確認、確認していない範囲がそろっています。

ここでIt works perfectly now.と書くと、どこまで試したのか分かりません。アプリ全体の完成を宣言する代わりに、試した条件と結果を示しましょう。練習用アプリを使って確認するなら、AIで作ったアプリのテスト方法に、空欄・0・上限・再読み込みのチェック表があります。

意図の確認・別案・未確認を伝える英語の例文

レビューにPlease simplify this.と書かれていても、処理の分割を減らしたいのか、条件式を読みやすくしたいのかは確定しません。分からない点を絞り、候補を示して聞き返します。

上から順に、「入力チェックと保存関数のどちらか」「保存前へ移すという意味か」「空欄を保存せず案内すべきか」「想定する構成の例があるか」を聞いています。相手が答えやすいように、一度に何でも質問するより、判断を止めている1点から確認します。

理解できないままUnderstood.と返して作業すると、違う修正になりやすくなります。Googleの公開しているレビューコメントへの対応指針でも、要求を理解できていなければ確認し、意見が違うときは技術的な理由や選択肢を話し合う考え方が示されています。

別の方法を提案するときは、理由と影響を並べる

提案された変更に、別の制約があることもあります。たとえば、ブラウザだけで完結する練習アプリへ、サーバーへの保存を追加する案が出た場面を考えてみましょう。

I see why saving records on a server would be useful.
For this exercise, the goal is to practice storage in one browser.
Adding a server would also require an API and a different setup.
Could we keep browser storage in this version and discuss synchronization as a separate task?

「サーバー保存の利点は理解している。今回は1つのブラウザに保存する練習が目的で、サーバーを追加するとAPIや起動方法も変わる。この版ではブラウザ保存を維持し、同期を別の作業として相談できないか」という提案です。

理由が「自分がそうしたいから」だけにならないように、今回の目的、利用者への影響、実装や確認の範囲を示します。相手の指摘に新しい前提が含まれている可能性もあるため、最後は確認できる形にすると話を進めやすくなります。

一方で、要件として複数端末の同期がすでに決まっているなら、この返答だけでブラウザ保存へ変更できるわけではありません。例文の前提が自分の課題と同じか、先に確かめてください。

まだ調べているときは、未確認と次の作業を示す

すぐに答えが出ない場合も、調べている範囲と次に確認することは伝えられます。作業時間の約束は、守れる見込みがあるときだけ付け足します。

「今回試した操作では再現しなかった」と「不具合がない」は別の意味です。返答にOSやブラウザの情報を入れる際も、実際に把握している値を書きます。報告の構成を練習するなら、英語のバグ報告テンプレートを使えます。

練習｜対応前と対応後の返信を書き分ける

課題は、Please make it clear where the records are saved.というコメントです。「記録がどこに保存されるか、分かるようにしてください」という意味です。ここでは1つのブラウザのlocalStorageへ保存する教材を想定します。

まだ変更していない場合：

Thanks for the comment. I’ll add a note to the README explaining that records are stored in the current browser and are not synchronized across devices.

READMEに追記した場合：

Thanks for the comment. I added a Storage section to the README. It explains that records are stored in the current browser and are not synchronized across devices.

2つ目はREADMEの記載を変えたという報告です。保存機能そのものを変更したとは書いていません。実際の修正範囲に合っているか、英語でも確認してください。README全体の構成は、英語READMEの書き方で練習できます。

あわせて読みたい記事

英語のバグ報告の書き方｜例文・テンプレートと修正確認

2026-10-05

英語READMEの書き方｜伝わる構成とテンプレート

2026-10-05

よくある質問

毎回、長い英語で返さないと失礼ですか？

必要な情報がそろっていれば、短い返信で構いません。たとえば変数名の修正なら、感謝と変更点の1〜2文で伝えられます。動作や設計が変わる指摘には、理由や確認結果も足しましょう。

ThanksとSorryのどちらから始めればよいですか？

通常の改善提案なら、感謝から始められます。謝罪は、相手に実際の負担や迷惑をかけた場面など、状況に合わせて使います。すべてのレビューコメントを謝罪から始める必要はありません。

英語の返信をAIに作ってもらってもよいですか？

日本語で事実を整理してから、英文を整える補助として使えます。「実施済み・予定・未確認の区別を維持し、テスト結果や期限を追加しないでください」と条件を添えましょう。出てきた英文が自分の実際の作業と一致しているかは、送る前に確認します。

まとめ：相手が次に確認できる返信にしよう

指摘を理解する、必要なら質問する、変更する、確かめる。この流れに英語を当てはめると、返信の内容を決めやすくなります。最初は「変更点を1文」「確認結果を1文」から練習してください。