コードレビューのnits・IMO・LGTMの意味と使い方

nits の意味と由来

nits（ニッツ）は英語の nitpick を縮めた言葉です。ChromiumOS のドキュメントでは、nit を「nitpick の略で、スタイルの問題のような些細な提案」と説明しています。nitpick はもともと髪についたシラミの卵（nit）を取り除く作業から来ており、日本語の「重箱の隅をつつく」に近い意味です。

コードレビューでは、次のような指摘に付けます。

• [nits] recieve は receive のタイポです。
• [nits] デバッグ用の console.log が残っています。
• [nits] import の順番をアルファベット順にそろえると読みやすいです。

Google のコードレビューガイドも、細かい指摘には「Nit:」を付けて、無視してもよいことを作成者に伝えるよう勧めています。nits は「細かい話ですが」という前置きで、作成者の心理的な負担を下げる役割もあります。

nits は nitpick の略で、タイポ、空行、import の順番のように動作に影響しない細かい指摘を表します。多くのチームでは直すかどうかを作成者に任せる任意の指摘として扱い、修正しないままマージしても問題ありません。

日本のチームでよく使われるプレフィックス

コメントの頭に [MUST] や [nits] のようなプレフィックスを付けて温度感を示す方法は、日本の開発チームで広く使われています。種類や意味はチームごとに少しずつ違いますが、公開されている記事でよく見るものは次のとおりです。

DevelopersIO の記事では must、want、imo、imho、nits、info、ask の 7 種類を、Zenn の記事では must、should、nits、imo の 4 種類を優先度順に紹介しています。どちらも「一部は自分たちのルール」として紹介されているとおり、決まった標準があるわけではありません。

プレフィックスが特に効くのは [ask] です。質問のつもりで「なぜこの書き方なんですか？」と書くと、作成者が「直せ」という意味に受け取って不要な修正をしてしまうことがあります。[ask] を付ければ、純粋に知りたいだけだと伝わります。

LGTM などレビューでよく見る略語一覧

LGTM は「完璧」という意味ではありません。Google のガイドは、変更がコード全体の健全性を確実に良くするなら、完璧でなくても承認すべきだとしています。細かい指摘を残したまま、後で直してくれる前提で LGTM を出すこともあり、その場合はどちらの意図かをはっきり書いておきます。

プレフィックスのルールをチームで決める

プレフィックスは、全員が同じ意味で使って初めて役に立ちます。ある人の [IMO] が「直してほしい」で、別の人の [IMO] が「好きにしていい」だと、かえって混乱します。導入するときは次の 3 点を決めておきます。

1. 種類を絞る。 まずは [MUST]、[IMO]、[nits]、[ask]、[FYI] の 5 つ程度で十分です。増やすほど使い分けに迷います。
2. マージを止めるかどうかを決める。 どのプレフィックスが付いた指摘が残っていたら承認しないのかを明文化します。多くの場合、止めるのは [MUST] だけです。
3. 書き方をそろえる。 [MUST] か must: か、大文字か小文字かを決め、CONTRIBUTING.md やプルリクエストテンプレートに載せます。

英語圏では Conventional Comments という形式も使われています。suggestion (non-blocking): … のように、praise、nitpick、suggestion、issue、question などのラベルに、マージを止めるかどうかを示す (blocking) や (non-blocking) を組み合わせます。海外のメンバーがいるチームでは、こちらに合わせる選択肢もあります。

きつく聞こえないレビューコメントの書き方

日本語のテキストは、短く書くほど冷たく見えがちです。対面なら何でもない「ここ違います」も、コメントでは責められているように読めます。次の点を意識すると、指摘の内容を変えずに角を立てずに済みます。

• 人ではなくコードについて書く。 「あなたは〜していない」ではなく「この関数は〜」と、コードを主語にします。
• 理由を一文添える。 「なぜ影響があるのか」が書いてあれば、作成者は納得して直せますし、反論もしやすくなります。
• 好みの問題は好みと書く。 「好みの問題ですが」と書けば、修正は必須でないと伝わります。
• 代案を示す。 代案がないときは、違和感があることだけを正直に伝えます。
• 既存コードの問題は前置きする。 「既存コードの問題だと思いますが」と書き、範囲が大きければ別のプルリクエストにすることを提案します。
• 良い点も伝える。 指摘だけが並ぶと萎縮します。良い書き方を見つけたら、理由と一緒に伝えます。

立場の差や面識の有無も受け取り方を変えます。先輩から新人へのコメントは、意図より強く響きがちです。テキストでこじれそうなときは、ビデオ通話で画面を共有しながら話したほうが早く片付きます。

きつく聞こえないレビューコメントは、コードを主語にし、理由を一文添え、プレフィックスで温度感を示します。「[ask] ここを同期処理にした理由を教えてください」のように書けば、同じ疑問でも責める調子にならず、作成者は質問なのか修正依頼なのかを迷いません。

nits を受け取ったとき

作成者の側は、[nits] や [IMO] の指摘をすべて直す必要はありません。すぐに直せるものは直し、意図があってその書き方にしているなら一言理由を返します。スケジュールが厳しいときに後回しにしても、失礼にはあたりません。直さないと決めたら、その旨を返信してスレッドを閉じると、レビュアーも状況がわかります。

AI レビューの深刻度

AI コードレビューでも、指摘の温度感を示す考え方は同じです。HeyDeer は、指摘ごとに緊急・高・中・低の 4 段階の深刻度を付け、見出しに「🟠 高（信頼性）：リトライが 404 で止まらない」のように深刻度、カテゴリ、タイトルを並べます。カテゴリは正確性、信頼性、セキュリティ、パフォーマンス、保守性の 5 つです。

このうち低は、マージを止める必要のない指摘です。

深刻度は指摘が本当だった場合の影響の大きさで、HeyDeer がその問題の存在をどれだけ確信しているか（確信度）とは別です。どの指摘を投稿するかは、この 2 つを組み合わせたフィードバックの範囲で決まります。「簡潔」にすると低の指摘は原則として投稿されず、nits に当たるコメントを減らせます。

チームにとっての深刻度は REVIEW.md で指定できます。「命名やリファクタリングの提案は低」「後方互換でないマイグレーションは高」のように書けば、プレフィックスのルールと同じ感覚で AI レビューの温度感をそろえられます。レビューの言語を日本語にすると、指摘も日本語で投稿されます。投稿内容の見方は レビューの読み方、観点の整理は コードレビューの観点とチェックリスト、HeyDeer のレビュー全体は AI プルリクエストレビューで紹介しています。

参考資料

1. BioErrorLog Tech Blog: コードレビューにおける"NITS"は何の略か
2. Zenn: コードレビューでよく見る略語（LGTM、IMO…）の意味、知ってますか？
3. DevelopersIO: よく使うレビューコメントのプレフィックス
4. Zenn: コードレビューをする時に心がけている3つのこと
5. Google Engineering Practices: How to write code review comments
6. google-eng-practices-ja: コードレビューの基準
7. Conventional Comments
8. レバテックLAB: 伊藤淳一が考える「コードレビューの観点とアプローチ」