LGTMに猫画像を貼る文化はなぜ生まれた？

プルリクエストの承認欄に、ただ一言LGTMと打てば仕事は終わります。それなのに、わざわざ猫の画像を貼り付けて承認するエンジニアが少なくありません。

用語辞典を引けば、LGTMが承認の合図だという意味はすぐ分かります。ただ、そこにはなぜ猫なのかという文化の部分が抜け落ちています。この記事では、意味の解説では拾えない伝播と変異のプロセスを追いかけます。

私が気になるのは、この慣習が誰のどんな課題を解決していたのか、という点です。承認という無味乾燥な作業に、猫が差し込まれた理由を一緒にたどってみましょう。

このシーンは、コードレビューの現場でよく起きるすれ違いを切り取ったものです。承認そのものはLGTMという四文字で足りるのに、そこへ猫画像が差し込まれる。若手が抱く「なぜ猫か」という素朴な疑問には、単語の意味だけでは説明できない文化の層が隠れています。

コードレビューは、指摘が主目的である以上どうしても緊張をはらみます。文字だけのやり取りは冷たく受け取られやすく、承認の一言さえ素っ気なく感じられる場面があります。ここに猫画像が入ると、承認の場の空気そのものが少しやわらぐという現象が起こります。

4コマのオチは、猫を承認の潤滑油と位置づけています。これは私の見立てですが、機能ではなく空気づくりの側面こそ、この文化が長く続いてきた理由ではないかと考えています。以下で由来から順に読み解いていきます。

そもそもLGTMとはどんな意味の承認コメントなのか？

LGTMとは、Looks Good To Meの略で、コードレビューにおいてこの変更で問題ない、という承認の合図として使われる短い定型コメントです。日本語にすると私が見た限り良さそうに近い表現になります。

ソフトウェア開発では、ある人が書いたコードを別の人が確認してから本番に取り込む、コードレビューという工程があります。レビュアーが内容を確認し、取り込んでよいと判断したときに残す一言がLGTMです。プルリクエストのコメント欄で目にする機会が多く、承認のスタンプのような役割を担っています。

ここで押さえておきたいのは、LGTMがもともと効率化のための言い回しだったという点です。承認のたびに長い文章を書くのは手間がかかります。四文字で意思表示が済むこの略語は、レビューのやり取りをなめらかにする実務的な発明でした。

LGTMはどこで生まれGitHubにどう広まったのか？

LGTMの起源は諸説ありますが、Googleの社内コードレビューツールMondrianでの使用がルーツとされる説がよく知られています。確定した一次資料は乏しく、断定はできません。

広く引用されるのは、2006年11月30日にNiall Kennedy氏が公開したMondrianの解説記事です。同記事は、レビュアーが承認を伝える際にlooks good to me、略してlgtmと打つ様子を紹介した投稿として知られています。Mondrianは、Guido van Rossum氏らGoogleのエンジニアが関わったとされる社内向けのツールで、コードレビューをWeb上で行えるようにした環境として紹介されています。

その後、2008年4月に公開されたGitHubの普及とともに、LGTMは社外のオープンソースコミュニティへ広がっていきました。プルリクエストのコメント欄という共通の舞台ができたことで、承認の定型句としてのLGTMは一気に世界中の開発者へ伝わっていきます。

この流れを整理すると、LGTMは社内ツールの一言から、コミュニティ共通の作法へと立場を変えたことになります。単語の意味は変わっていないのに、使われる場所が広がるにつれて、そこに乗る文化も少しずつ膨らんでいきました。次の章で扱う猫画像は、その膨らみの中で生まれた独自進化だと言えます。

なぜLGTMの承認に猫画像を貼る文化が生まれたのか？

LGTMに猫画像を貼る文化は、承認の合図をテキストから画像へ拡張する遊び心と、ネット上の猫画像ミームが結びついて広まったものです。なぜ猫なのかは確定した記録が乏しく、見立てとして扱う必要があります。

きっかけの一つは、LGTMの文字を大きくあしらった画像を共有するサービスの登場です。代表例が、猫のLGTM画像を集めて共有できるLGTMeowで、GitHubにそのまま貼れるMarkdown形式でコピーできる仕組みを備えています。![LGTM](画像URL)のように書けば、コメント欄に画像が表示されます。同サービスは2025年時点でも画像投稿が続いており、現在も稼働しています。

猫が選ばれた理由については、断定できる資料が見当たりません。あくまで外から見ていた私の見立てですが、2000年代からインターネットに根付いていた猫画像ミームの土壌と、テキスト中心で少し無機質になりがちなコードレビューの文化が交差した結果ではないかと考えています。

文字のLGTMと猫画像のLGTMは何が違うのか？

両者は承認を伝える点では同じですが、果たす役割の重心が異なります。下の表で観点ごとに整理します。

比較観点	文字のLGTM	猫画像のLGTM
主な目的	承認を素早く伝える効率化	承認に場の空気づくりを重ねる
伝わる情報	取り込んで良いという判断	判断に加えて、やわらかい感情の温度
向いている場面	スピード重視の定型的な承認	緊張しがちなレビューをほぐしたい場面
手間	四文字で完結	画像を選んで貼る一手間がかかる

この対比から見えるのは、猫画像が効率とは逆方向の一手間だという事実です。速さだけを求めるなら文字で十分なのに、あえて手間を足す。その非効率の中にこそ、この文化の本質があるように思います。

文字のLGTMと猫画像のLGTM、そしてGitHubのApprove機能は、どれも承認に見えて、記録の残り方がまったく違います。承認の記録として効くのはApproveだけで、残る2つはあくまでコメントです。

比較観点	文字のLGTM	猫画像のLGTM	Approve（レビュー承認）
実体は何か	プルリクエストのコメント本文	コメントに貼った外部画像	レビュー機能の承認操作
承認の記録として残るか	残らない（コメント扱い）	残らない（コメント扱い）	残る（レビュー一覧に承認として記録される）
レビュー履歴に紐づくか	コメントの時系列に並ぶだけ	コメントの時系列に並ぶだけ	誰がいつ承認したかがレビュー単位で紐づく
ブランチ保護の必須承認数に数えられるか	数えられない	数えられない	数えられる
新しいコミットで無効化できるか	無効化の仕組みがない	無効化の仕組みがない	リポジトリ設定で自動的に無効化できる
後から中身が変わりうるか	投稿者が編集・削除できる	画像URLの中身が差し替わると、コメントを編集しなくても見え方が変わる	取り消しの操作自体が履歴に残る
監査証跡として使えるか	使えない	使えない	使える
向いている役割	軽い同意・温度感の共有	レビューの空気づくり	承認そのもの

この表から導かれる順番は単純です。まずApproveを押し、そのうえで猫画像を添える、という2段構えになります。

手順に落とすと3ステップです。第1に、承認の意思を記録として残す必要があるならApproveを押します。第2に、レビューの空気を和らげたい場合にかぎり、猫画像をコメントとして添えます。第3に、文字のLGTMだけで済ませてよいのは、承認の記録をそもそも必要としない場面に限られます。

猫画像のLGTMはレビュー文化に何をもたらすのか？

猫画像のLGTMがもたらすのは、承認という工程に心地よさと継続のしやすさを足す効果だと私は見ています。ここからは事実ではなく、私の解釈と仮説として読んでください。

私の持論として、技術も文化も、機能で選ばれて習慣で生き残ります。文字のLGTMは機能として優秀でしたが、それだけでは承認は義務的な作業のままです。そこへ猫が入ると、承認が少しだけ楽しみになる。続けたくなる仕掛けが加わることで、レビューという習慣そのものが回りやすくなるのではないでしょうか。

なぜこの慣習が定着したのかという問いに、私は時代とニーズのズレという角度から見立てを置いています。リモート化が進み、テキストだけのやり取りが増えるほど、感情の温度は伝わりにくくなります。あくまで外から見ていた私の推測ですが、その温度不足を補う潤滑油として、猫画像がちょうどよく機能したのだと考えています。

この先を考えると、AIがコードレビューの一次確認を担う場面は今後さらに増えていくはずです。機械的な指摘が自動化されるほど、人間が残す承認には、判断だけでなく気持ちを伝える役割が色濃くなるのかもしれません。歴史を知っている側が、こうした小さな文化の意味を汲み取れるのだと思います。いま自分のチームの承認は、無味乾燥な作業になっていないでしょうか。次にプルリクエストを承認するとき、その一言の温度を少しだけ意識してみてください。

猫のLGTM画像はどこで手に入れて、どれを選べばよいのか？

猫のLGTM画像は、LGTM画像の共有サービスを使うか、自分で画像をホスティングするかの二択になります。どちらを選ぶかは、かわいさではなく画像URLが何年もつかで決まります。

レビューコメントは、承認の記録ではないとはいえ、リポジトリが生きている間ずっと残ります。数年後に過去のプルリクエストを掘り返したとき、画像だけが壊れて意味の通らないコメントが並ぶかどうかは、この選択で決まってしまいます。

まず、何を見比べればよいのかを整理します。

比較軸	この軸が効く理由	確認せずに使うと起きること
猫限定か、画像全般か	猫限定なら探す手間が減る一方、選択肢は狭くなる	チームの好みと合わず、結局使われないまま終わる
ログインが要るか	閲覧だけで使えるか、アカウント作成が要るかで導入の敷居が変わる	チームに勧めた段階で、登録が面倒だと止まる
自分の画像をアップロードできるか	飼い猫の写真を使いたい場合、この可否が分岐点になる	アップロードした画像が第三者に公開される範囲を把握しないまま公開してしまう
Markdown形式でワンクリックコピーできるか	貼るまでの手数が、文化として定着するかを左右する	毎回URLを手で組み立てることになり、使う人が減る
画像URLの永続性	サービスが止まれば、過去のコメントの画像がすべて壊れる	数年前のプルリクエストが、壊れた画像アイコンだらけになる
商用・社内利用の可否	業務のリポジトリに貼る時点で、私的利用ではなくなる	利用規約や画像のライセンスに反したまま、社内に広まる
多言語対応	社外コントリビュータや海外拠点が読む場面で効く	画像内の日本語が読めず、承認の意図が伝わらない

そのうえで、候補ごとの現状は次の通りです。

比較観点	LGTMeow	LGTMoon	自分でホスティングする
猫限定か	要確認	要確認	自分が置いた画像だけになる
ログインが要るか	要確認	要確認	自分の管理下のため、要否も自分で決められる
自分の画像をアップロードできるか	要確認	要確認	できる
Markdownワンクリックコピー	要確認	要確認	用意されていないため、自分で記法を書く
画像URLの永続性	要確認（運営が続く限りという前提になる）	要確認（同上）	自分が保管費用を払い続ける限り残る
商用・社内利用の可否	要確認（利用規約の確認が必須）	要確認（同上）	自分が権利を持つ画像なら問題になりにくい
多言語対応	要確認	要確認	該当しない

要確認が並ぶことに、意味があります。LGTM画像サービスは個人開発のものが多く、仕様も稼働状況も変わりやすい領域です。どこかの記事に書いてあった仕様をそのまま信じて社内へ展開すると、確認していないことに気づかないまま運用が始まってしまいます。

選び方は、次の順で決めると迷いません。第1に、業務のリポジトリで使うなら利用規約の商用・社内利用の条項を先に読みます。第2に、数年単位で残るリポジトリなら、自分でホスティングする側に寄せます。第3に、社内の雑談用リポジトリのように壊れても困らない場所であれば、手数の少なさを優先して共有サービスを使えばよい、という判断になります。

猫画像のLGTMでよく起きるトラブルは何か？

猫画像のLGTMで起きるトラブルは、ほとんどが画像が自分たちの管理外にあることに由来します。コメント本文は自分のリポジトリにありますが、画像の実体はよそのサーバにあるためです。

起きること	そうなる構造	切り分けの起点
過去のプルリクエストの画像が壊れたアイコンになる	外部サービスの画像URLが失効すると、コメント側は何も変えていなくても表示できなくなる	画像URLをブラウザで直接開き、画像単体が取得できるかを見る
自分の環境では見えるのに、他の人には見えない	GitHubは本文中の外部画像を自前の画像プロキシ経由で配信する仕組みを持つ。プロキシ側が画像を取得できない条件だと表示されない	画像のURLが暗号化された通信のものかを確認する。プロキシを経由したURLに置き換わっているかも合わせて見る
社内からだけ画像が出ない	社内プロキシやCSPの設定が、その配信元ドメインを許可していない	社外ネットワークからも同じコメントを開き、表示が変わるかを比べる
チャット連携に画像だけが流れて、レビュー内容が追えない	コメント本文が画像1枚だけの場合、連携先には画像を指す情報しか渡らない	画像に一行のコメントを添える運用に変えて、流れ方が変わるかを見る

4つに共通するのは、貼った瞬間には誰も気づかない点です。壊れるのは数か月後か数年後で、しかも壊れたことを知らせてくれる仕組みはありません。

猫画像のLGTMを避けたほうがよいのはどんな場面か？

猫画像のLGTMを避けたほうがよいのは、そのコメントを承認の記録として誰かが読む可能性がある場面です。判断の軸は好みではなく、記録に残るかどうかの一点になります。

上から順に見ていくと、避けるべきかどうかが決まります。

確認すること	はいの場合	いいえの場合
1. そのリポジトリは監査や内部統制の対象か	Approveで承認を残し、画像は添えないか、承認とは別のコメントに分ける	2へ進む
2. 金融・医療・公共など、規制のある領域のコードか	組織のレビュー規程を先に確認する。規程が画像を想定していないなら足さない	3へ進む
3. 公開されたリポジトリで、社外の人がコメントを読むか	画像の権利と、読み手の言語・文化を確認したうえで判断する	4へ進む
4. 社外コントリビュータからのプルリクエストか	初回のやり取りでは文字で意図を伝える。画像は関係ができてからにする	5へ進む
5. チームがコメントのLGTMを承認の意思表示として運用しているか	まず運用をApproveへ寄せる。画像はその後で足す	猫画像を貼ってよい場面と判断できる

1から5のどこかで止まった場合でも、猫画像そのものが悪いわけではありません。止まる理由はコメントが承認の記録として扱われてしまっていることにあり、直すべきはそちらです。Approveを承認として運用し直せば、コメント欄は自由に使える場所として戻ってきます。

あくまで外から現場を見てきた私の見立てですが、猫画像を禁止したチームの多くは、画像を嫌ったのではなく、承認の所在が曖昧なまま運用を続けた結果、分かりやすい方を先に止めたのではないかと考えています。

この記事と一緒に知っておきたい用語

用語	この記事との関連
プルリクエスト	LGTMが承認として書き込まれる、コードレビューの主な舞台となる仕組み。
ウォークスルー	関係者で欠陥を見つけるレビュー手法で、承認文化の背景にある確認の考え方。
スニペット	LGTM画像をGitHubへ貼る際にコピーするMarkdownの短い断片と関わる用語。
インターネット老人会	猫画像ミームが根付いたネット文化の土壌を象徴する、世代的な背景。

【出典】参考URL

http://www.niallkennedy.com/blog/archives/2006/11/google-mondrian.html ：LGTMの初出とされる、Niall Kennedy氏が2006年11月30日に公開したMondrian解説記事の原典URL（現在は当該URLからの直接閲覧が難しく、下記LWN.netの2006年記事が参照元として同URLを記録）
https://lwn.net/Articles/213934/ ：Niall Kennedy氏の原記事URLの裏付け、およびMondrianがWebベースのコードレビュー・ストレージであることの根拠
https://knowyourmeme.com/memes/lgtm ：LGTMの初出（Niall Kennedy氏 2006年11月30日）とGitHub普及（2008年4月）という時系列の根拠
https://engtech.wordpress.com/2006/12/01/how-google-does-web-based-code-reviews-with-mondrian/ ：Mondrianのコードレビューの仕組みに関する2006年の技術的解説（Mondrianの背景説明の補足）
https://lgtmeow.com/en ：猫のLGTM画像共有サービスLGTMeowの機能・現在も稼働している状況の確認（猫画像文化の実例根拠）