おすすめ欄に異変が

異様な光景だった。

おすすめに、同じ会社の記事がズラッと並んでいた。

研修生が書いているっぽい。
「データベース新卒研修まとめ」、「Pythonのリストって？」、「Pythonのまとめ」などなど。

これだけなら、よくある普通の記事だ。何の問題もない。

じゃあ何が異常なのか？

「いいね」が多すぎる

なんと、全ての記事でいいねが30以上もある。

数えてみたが、研修生記事は26記事ある。

その26記事全てで、いいね数が30以上。

Qiitaでは、30いいねは「バズ」だ。

そう簡単に26本もバズ記事を連発できるのか？

しかも、特別バズるような内容じゃない。

例えば、「Pythonのまとめ」。

申し訳ないけど、そのタイトルで30いいねも付くとは思えない。

でも、ちょっと待ってほしい。

さっき「30いいねはバズだ」と言い切ってしまった。
でも、それはただの感覚だ。データで確かめたわけじゃない。

30いいねが、思ったより大したことないかもしれない。
そうなると、例の研修生記事も全然おかしくないことになる。

なら、調べるべきはこれだ。

本当に30いいねはすごいのか？

どうやって確かめる？

30いいねが「バズ」なのか、それとも普通なのか。

一番分かりやすいのは、「30いいね以上の記事がどれくらいあるのか」を調べることだ。

もし30いいね以上の記事がいっぱいあるなら、珍しくない。

逆に、ごく一部しかなければ、30いいねはレアだ。つまり、「30いいねはすごい！」ということになる。

実際にデータを集めて確かめてみた。

データについて（読み飛ばし可）

Qiita記事のデータはQiita APIで集められる。

研修生記事の前後2週間、計4週間分の記事を使う。

項目	内容
取得期間	2026-05-03〜2026-05-31
取得日	2026-07-16
記事数	1万200件

余談：Qiitaの投稿日が信用できない

データ取得時に奇妙な問題が起きた。

研修生記事群の投稿日を見ると、5/25〜5/29になっている。

だから、間を取って27日を基準にしよう。そして、基準日から前後2週間を取得範囲にする。

それなら、研修生記事が全部範囲に入る。

しかし、実際に取得してみると、研修生記事が入っていない！

Qiita上の投稿日は5/25〜5/29。確実に範囲に入っているはず。

調べてみると、原因が分かった。

記事のQiita上の投稿日と、データ上の作成日（created_at）が違う。

例えば、「Pythonで電卓を作ったよ」という記事は、Qiitaで見ると「投稿日 2026年05月29日」になっている。

しかし、データ上の作成日は「2026-05-13」だ。

なぜこうなっているのかは分からない。

仮説としては「限定公開」がある。

限定公開日がデータ上の作成日になり、実際に公開した日がQiita上の投稿日になる、という仮説。ただし、確かめていない。

原因は何であれ、解決策としてはcreated_atを使えばいいだけ。

ざっと見た感じ、研修生記事群のcreated_atは5/13〜5/21。

だから、基準を5/17にした。

30いいねはすごいのか？

いいね数の分布を求める。

ただし、例の研修生記事群が入っていたら、結果が歪む。

なので、研修生のorganizationであるエニプラ（any-plus）の記事は除外した。

いいね数の分布がこれだ。

このグラフはどう読むのか。

例えば、一番左の「0」は62.4%になっている。これは、「いいね0の記事が62.4%」と言う意味。

つまり、「記事10本中6本は、誰からもいいねされていない」ということだ。

それはそれで恐ろしい結果だが、本題は別だ。

「30+」は1.0%。

30いいね以上の記事は、たったの1%しかない。

100本に1本のレア記事ということだ。

こう言っていいだろう。

30いいねは超すごい！

そもそも、なぜいいねを見るのか？

何かを選ぶときは評価を参考にする。

食べログなら星の数。

Amazonも星の数。

Qiitaなら、いいね数。

評価が高いものほど、良いものだと思う。

だから、30いいねもあったら、かなりの良記事だと判断する。上位1%だし。

30いいねの正体

ここで、最初に戻る。

26本の研修記事たちだ。

先ほど分かったように、30いいねは100記事に1記事しかない。バズ記事だ。

つまり、この26記事は本来なら「多くの人から評価された良記事」と考えるべきだ。

ここで種明かし。

Qiitaでは、「誰がいいねしたのか」を見ることができる。

適当な研修記事を1つ開いてみる。

いいね欄を見る。

1人目。

研修生だった。

まあ、1人くらいなら偶然かもしれない。

2人目。

また研修生だった。

3人目。

またまた研修生。

さらに確認する。

やっぱり研修生。

つまり、研修生同士でいいねし合っている。

おそらく、Qiitaに記事を書くことが研修の一環なんだろう。

そして、たぶん会社から「いいねし合ってね」という指示を受けているんじゃないか。

要するに、組織票だ。

いいねは信用できない

別に、それは悪いことじゃない。

お互いの記事を見てもらう。そして、いいねし合う。なかなかいい取り組みだと思う。

でも、問題が出てくる。

いいね数を信用していいのか？

いいねは投票だ。多くの人から投票された記事は、いい記事のはず。

しかし、その投票が偏っている。それだと何を信じればいいのか分からない。

悪いのは、組織票ではない。

組織票があるだけで歪んでしまう、「いいね」という評価指標の方だ。

まとめ

30いいねは価値がある。少なくとも本来は。

しかし、Qiitaには組織票がある。それでは本当にいい記事なのか分からない。

実は、問題は組織票そのものじゃない。

いいねという評価指標が組織票に弱いことが問題だ。

じゃあ、どうやって記事を評価すればいい？

実は、これと同じ問題に、ある企業が20年以上前に直面していた。

その企業とは、Googleである。

次回はその話を書く。

コード

Github