ゆめさくエンジニア研究所女性向けエンジニアスクール女性向けエンジニアスクール
ログイン

LGTM とレビューの略語

回 4-4　分野 4 Issue と PR とレビュー

LGTM は Looks good to me (私は良いと思う) の略で、コードレビューで「この変更を入れてよい」と承認を伝える言葉です。読み方はエル・ジー・ティー・エムです。GitHub では、コメントに LGTM と書くだけでは承認として数えられず、レビューで Approve を選んで初めて承認になります。

目安 30 分4-4 (4-1〜4-4 の中)

読み終えたらレビューの略語の意味と重さを読み分け、自分でも使える

この頁の流れ

  1. 1LGTM は「私は良いと思う」
  2. 2LGTM はどこから来て、何を約束するか
  3. 3レビューの略語の表
  4. 4動かして確かめる
  5. 5略語はどこで外れるか
  6. 6仕事でどう使うか
  7. 7よくある問い
  8. 8確認クイズ
  9. 9説明課題
  10. 10もっと深く
  11. 11一次資料
  12. 12次へ

LGTM の意味と出どころを一次の文書で確かめ、WIP、PTAL、nit、IMO、FYI などの略語を、承認を止めるか止めないかの重さで読み分けます。

文 ゆめさくコード編集部公開 2026年10月30日更新 2026年10月30日出典を確かめた日 2026年10月30日

LGTM は「私は良いと思う」

LGTM は Looks good to me の頭の字を並べた略語で、「私は良いと思う」という意味です。コードレビューで、変更を読んだ人が「この変更を入れてよい」と伝えるときに書きます。

大事なのは最後の to me です。「完全に正しい」ではなく、「私が読んだ範囲では良いと思う」と言っています。だから LGTM は、品質を保証する言葉ではありません。読んだ人が、自分の見た範囲で入れることに賛成したという印です。

レビューでは LGTM のほかにも、PTAL、WIP、nit、IMO、FYI のような略語が毎日出てきます。この回では、それぞれの意味と、承認を止める指摘なのか止めない一言なのかという重さを、公式の文書で確かめながら読み分けます。

LGTM はどこから来て、何を約束するか

2006 年の記事に残る出どころ

LGTM の使い方を書き残した古い記事の 1 つが、2006 年 11 月に Niall Kennedy が書いた、Google の中のレビューの道具 Mondrian の紹介です。記事には、Mondrian より前のレビューは主に e-mail で行い、相手から looks good to me、略して lgtm の返事をもらえば変更を入れられた、と書かれています。

出典 2006 年の記事の 1 文

When the developer receives
a response of “looks good to
me,” or looks good to me
(lgtm) for short, they could
proceed to checkin.

checkin は、変更をリポジトリに入れることです。LGTM は初めから「読んだので入れてよい」という、承認の返事でした。今も Linux カーネルの文書には、パッチへの looks good to me の返事を、承認の記録の行 (Acked-by:) に置き換えることがある、と書かれています。

Gerrit の点数の名前

オープンソースのレビューの道具 Gerrit では、レビューの人は Code-Review という欄に点を付けます。点の名前に、LGTM の元の英語がそのまま入っています。

点名前 (Gerrit の文書の英語)意味
+2Looks good to me, approved良いと思う。承認する。中身は +1 と同じで、プロジェクトの行く末に最後の判断を持つ人が付ける点
+1Looks good to me, but someone else must approve良いと思う。ただし承認は別の人が要る
0No score点を付けない
−1I would prefer this is not submitted as isこのままでは入れないでほしい
−2This shall not be submitted入れてはいけない

Gerrit の既定の設定では、最新のパッチセット (変更の最新の版) に +2 が付くまで入れられません。+1 が付いただけでは足りないので、「LGTM をもらった」と「入れてよくなった」は、道具の設定によっては別のことです。

一方、Chrome の元になる Chromium の手引きは、Gerrit の Code-Review +1 を「LGTM とも呼ぶ」と書き、コミッター (変更を入れる権限を持つ人) が出した変更なら、レビューの +1 はほかのコミッター 1 人で足りる、と決めています。ただし、触るディレクトリごとに、そのディレクトリの持ち主 (OWNERS) のレビューも別に要ります。同じ Gerrit でも、何点で入れられるかはプロジェクトの決まりで変わります。

Gerrit の文書は、Code-Review の欄の元の意味を「コードを読み、だいたい正しいと思う」と書き、それとは別に Verified の欄 (ビルドが通り、基本の試験が通る) を置いています。読んだ印と、動かして確かめた印は、初めから分けられています。

GitHub の 3 つの返事

GitHub では、レビューを出すときに 3 つの返事から 1 つを選びます。

返事GitHub の文書の説明意味
CommentLeaves general feedback without explicitly approving or requesting changes.承認も直しの依頼もしない、ふつうの意見
ApproveSignals that the changes are ready to merge.入れてよいという承認
Request changesFlags feedback that the author should address before merging.入れる前に直してほしい

LGTM と書いたコメントを Comment で出すと、文の意味は承認でも、GitHub の上では承認として数えられません。承認が要るように決めたリポジトリでは、Approve を選んだレビューが要ります。

LGTM With Comments

Google が公開しているレビューの手引き (eng-practices) には、「LGTM With Comments」という節があります。直してほしい点が残っていても、次のどれかに当たるなら、先に LGTM (承認) を出してよい、という決まりです。

  • 書いた人が、残りの指摘をきちんと直すと信じられる
  • 残りの指摘は、直さなくてもよい物である
  • 指摘が小さい (import の並べ替え、近くの打ち間違い、使っていない依存を消す など)

時差のあるチームで、承認を待つだけで書いた人が 1 日待たされるのを避けるための決まりです。同じ手引きは、LGTM を出すなら、その LGTM が「このコードは私たちの基準を満たす」という意味になるだけの時間をかけて読むように、とも書いています。

レビューの略語の表

レビューで毎日出てくる略語を、元の英語と、承認を止めるかどうかで並べました。元の英語は、Gerrit の文書と Wiktionary の各語の項で確かめた物です。

略語元の英語意味重さ
LGTMlooks good to me私は良いと思う。入れてよい承認
SGTMsounds good to me(聞いた案に) それで良いと思う案への賛成。コードの承認とは限らない
PTALplease take a look見てください。直したので、もう一度見てください頼む側の言葉
WIPwork in progress作業中。まだ入れない入れない印
nitnitpick細かい指摘止めない
IMOin my opinion私の意見では意見。決まりではない
FYIfor your information参考までに止めない
AFAIKas far as I know私の知る限りでは確かでない所に付ける
TL;DRtoo long; didn't read長い文の頭に置く要約説明の型

nit は英語の nitpick (あら探し、細かいことにこだわる) から来ています。nitpick の元の意味はシラミの卵 (nit) を取ることで、そこから「取るに足らない細かい点」の意味になりました。

Google の Nit、Optional、FYI

Google の手引きは、コメントの頭に重さの印を付けるよう勧めています。印が無いと、書いた人がすべての指摘を「必ず直す物」と受け取ってしまうからです。

出典 Google の手引きの 3 つの印

Nit: This is a minor thing.
Technically you should do it,
but it won’t hugely impact
things.

Optional (or Consider): I
think this may be a good
idea, but it’s not strictly
required.

FYI: I don’t expect you to
do this in this CL, but you
may find this interesting to
think about for the future.

日本語にすると次の通りです。CL は Google の中の言葉で、1 つの変更 (GitHub の PR に当たる) のことです。

  • Nit: は、小さなこと。直すのが望ましいが、大きな影響は無い
  • Optional: (または Consider:) は、良い案だと思うが、必ずではない
  • FYI: は、この変更で直さなくてよい。先のために知っておくと役に立つ話

Conventional Comments の形

コメントの頭の印を決まった形にそろえる提案に、Conventional Comments があります。形は <label> [decorations]: <subject> で、label が種類、decorations が付け足しの印です。

  • label は praise (ほめる)、nitpick、suggestion (提案)、issue (問題)、todo、question、thought、chore、note など
  • decorations の (blocking) は承認を止める、(non-blocking) は止めない、(if-minor) は直しが小さいときだけ直せばよい
  • nitpick と thought は性質として止めない物、note はいつも止めない物と、文書に書かれている

動かして確かめる

1 本目は、コメントの中の略語を見つけて、元の英語を出します。コメントは説明のために作った短い例です。

動かす 略語を見つけて元の英語を出す

python実行可能
出力

▶ 実行ボタンを押すと結果がここに表示されます

実行すると、次の通りに出ます

LGTM, thanks!
  LGTM looks good to me
nit: extra blank line.
  NIT nitpick
Done. PTAL
  PTAL please take a look
IMO this needs a test.
  IMO in my opinion

nit は小文字でも書かれるので、比べる前に大文字にそろえています。Done. PTAL は「直しました。もう一度見てください」で、レビューの指摘に応えたあとによく書く形です。

2 本目は、Conventional Comments の形のコメントを読み、承認を止めるかを出します。コメントは、Conventional Comments の文書に載っている例を使いました (長いので行を分け、文書の曲がった引用符 ’ はまっすぐな ' に替えています)。

動かす コメントの頭の印を読む

python実行可能
出力

▶ 実行ボタンを押すと結果がここに表示されます

実行すると、次の通りに出ます

nitpick []
  止めない
question ['non-blocking']
  止めない
issue ['ux', 'non-blocking']
  止めない
suggestion ['security']
  チームの決まり
形が違う LGTM

suggestion (security) には、止めるとも止めないとも書かれていません。Conventional Comments の文書は、印の無い指摘を止める物と読むか止めない物と読むかを、チームに任せています。だからこのコードも「チームの決まり」と出します。LGTM の 1 語は、この形に当てはまりません。

3 本目は、PR の題から下書きかどうかを見分けます。GitLab の文書は、題の頭に [Draft]、Draft:、(Draft) のどれかを付けると下書きになる、と書いています。GitLab の中の判定そのものではなく、文書に書かれた 3 つの印で見分ける練習です。

動かす 題の頭の下書きの印を見分ける

python実行可能
出力

▶ 実行ボタンを押すと結果がここに表示されます

実行すると、次の通りに出ます

True Draft: Add login form
True [Draft] Add login form
True (Draft) Add login form
False WIP: Add login form
False Add login form

WIP も「作業中」の印として題に書かれることがありますが、今の GitLab の文書が挙げる下書きの印に WIP は入っていません。GitHub も、題の文字ではなく、PR を作るときに選ぶ draft pull request (下書きの PR) で作業中を表します。GitHub の文書によると、下書きの PR は入れられず、コードの持ち主にレビューの依頼も自動では飛びません。

略語はどこで外れるか

コメントの LGTM は承認として数えられない

GitHub で LGTM と書いたコメントを残しても、レビューの返事が Comment なら承認ではありません。承認が要るように決めたリポジトリで「LGTM と書いたのに入れられない」と言われたら、Approve を選んでレビューを出し直します。

LGTM は、動かして確かめた印ではない

Gerrit が Code-Review と Verified を分けているように、LGTM は「読んで良いと思った」という印です。試験が通ったか、手元で動かしたかは、LGTM だけでは分かりません。確かめたことがあるなら、LGTM のあとに 1 行足すと、あとで読む人に伝わります。

例 確かめたことを足す

LGTM. I ran the migration
locally and it works.

承認のあとに直すと、承認が消えることがある

GitHub のリポジトリで、承認の必須と、古いレビューを外す設定 (stale review dismissal) の両方を入れていると、承認のあとにコードを変えるコミットを push した時点で、その承認は外れます。LGTM のあとに直しを足したら、もう一度見てもらう (PTAL) 必要があるかを、チームの設定で確かめます。

nit を全部「直せ」と読んでしまう

印の無い指摘が並ぶと、書いた人はどれも必ず直す物だと受け取りがちです。Google の手引きが重さの印を勧めるのは、この取り違えを防ぐためです。nit や Optional: が付いた指摘は、直すかどうかを書いた人が決めてよい物です。迷ったら、直さない理由を 1 行返せば十分です。

仕事でどう使うか

英語のレビューでよく使う言い方を、場面ごとに並べました。どれも説明のために作った短い例です。

例 承認するとき

LGTM, thanks!
LGTM with a couple of nits.
LGTM once CI passes.

with a couple of nits は「細かい指摘が 2 つほどある」、once CI passes は「CI が通ったら」です。Google の LGTM With Comments に当たる言い方です。

例 直したあと、もう一度頼むとき

Thanks! Addressed all
comments. PTAL.

Could you take another look?

例 指摘を柔らかくするとき

nit: extra blank line.

Optional: consider using a
dict here.

What do you think about
splitting this function?

指摘は、命令形 (Rename this.) より、疑問形 (Could you rename this?) や What do you think about で始めると柔らかくなります。IMO を頭に付けると「これは私の意見です」と伝わり、相手が反対しやすくなります。

よくある問い

LGTM はどう読みますか

エル・ジー・ティー・エムと、1 文字ずつ読みます。英語でも 1 文字ずつ読みます (Wiktionary の発音は /ɛl d͡ʒiː tiː ɛm/)。

小文字の lgtm でもいいですか

どちらも使われます。2006 年の記事も、小文字で lgtm と書いています。意味は変わらないので、チームの中でそろっていれば十分です。

LGTM と言われたら、どう返しますか

Thanks! や Thanks for the review! と返すのがふつうです。そのあと、チームの決まりに沿って自分で入れるか、入れる係の人を待ちます。nit が付いていたら、直したかどうかを 1 行で返すと、相手がもう一度読まずに済みます。

SGTM と LGTM はどう違いますか

SGTM は sounds good to me で、聞いた案や方針に「それで良いと思う」と返す言葉です。「この設計で進めて良いか」のような話し合いへの返事に使います。LGTM は、書かれたコードや文を読んで良いと言う言葉です。SGTM をもらっても、コードの承認をもらったことにはなりません。

LGTM の画像や、記事の LGTM は何ですか

PR のコメントに、LGTM の字を載せた画像を貼って承認を伝える遊びがあり、その画像を作る道具も公開されています。また、技術記事の共有サイトの Qiita は、2020 年 3 月に記事の評価のボタンの名前を「いいね」から「LGTM」に替えました。どちらも、レビューの LGTM から借りた使い方です。

確認クイズ

答えだと思う選択肢を押すと、その場で正誤と理由が開きます。4 問すべてに正しく答えると、この回は修了で、石が緑に変わります (この端末のブラウザに残ります)。間違えた問いは、あとから解き直せます。

1 問目

LGTM の元の英語はどれですか。

2 問目

GitHub で、PR に LGTM とだけ書いたレビューを、返事を Comment にして出しました。正しいのはどれですか。

3 問目

Google のレビューの手引きで、コメントの頭に Nit を付けるのはどんなときですか。

4 問目

このコードを動かすと何が出ますか。is_draft は、3 本目のコードの関数です。

print(is_draft("WIP: Fix typo"))

説明課題

GitHub で、レビューの人が LGTM with a couple of nits. とだけ書き、返事を Comment にして出しました。この PR をこのまま入れてよいかを、LGTM と nit の意味と、GitHub の Approve を使って 3 文で説明してください。書いたら、下の模範解答を開いて比べてください。

模範解答

自分の説明を書いてから開いて、比べてください。

この回の先の一歩

レビューの略語が読めると、海外のオープンソースの PR でも、直すべき指摘と参考の一言を取り違えずに済みます。いまの自分が転職までの道のどの段にいるかは、転職診断で確かめられます。

もっと深く

この回の続きを、ゆめさくのコースの章や道具で深められます。頁の中の確認クイズに答えたあと、手を動かす量を増やしたいときに使ってください。

一次資料

どれも 2026年10月30日に開いて、題と中身を確かめました。

次へ

前の回 4-3PR の説明を英語で書くwhat と why、テストしたこと準備中

分野 4 Issue と PR とレビューの回

  1. 4-1コミットメッセージの英語命令形の題、Conventional Commits準備中
  2. 4-2Issue を英語で書く再現の手順、expected と actual準備中
  3. 4-3PR の説明を英語で書くwhat と why、テストしたこと準備中
  4. 4-4LGTM とレビューの略語LGTM、WIP、PTAL、nit、IMO、FYIこの回

分野 4 の頁へ戻るほかの分野を見る