GitHubのスター数と技術的負債の意外な関係

2026.05.28

執筆者：DigKnow株式会社 CTO 桑原脩

GitHubのスター数が多いリポジトリは、「良いコード」なのでしょうか。私もOSSを選ぶとき、まずスター数を見ます。正直に言えば、それが品質の指標だと無意識に信じている部分があります。でも最近、スターが何千もついたリポジトリのissueを覗いて、少し考え込むことが増えました。

GitHubのスター数は「品質」を測っているのか

GitHubのスターは、開発者にとって最も身近な評価指標のひとつです。新しいライブラリを選ぶとき、フレームワークを比較するとき、「スター数が多いほうが安心」という感覚は、ほとんどの開発者が持っているのではないでしょうか。
でも、冷静に考えると、スターが示しているのは「多くの人が関心を持った」という事実だけです。コードの品質でもなく、ドキュメントの充実度でもなく、メンテナンスの持続性でもありません。「面白そう」「便利そう」「話題になっていたから」——スターが押される理由は、そういった瞬間的な関心であることがほとんどです。
別にスターを押す行為を批判したいわけではなく、私だってそうしています。ただ、スター数という指標が実際に何を表しているのかを、もう少し正確に理解しておく必要がある気がしています。
そしてこの問いは、OSSの話に閉じません。私たちが日々の開発で「このコードは問題ない」と判断するとき、その根拠は本当に品質なのか、それとも単に「動いている」という事実なのか。スター数の問題は、ソフトウェア開発における「見かけの安心」と「実際の健全性」のギャップを映し出しているように思います。

技術的負債は「成功」の副産物でもある

技術的負債という言葉は、ネガティブな文脈で語られることが多いものです。でも、人気OSSの文脈で見ると、少し違う側面が見えてきます。
スターが集まるということは、多くの人がそのプロジェクトを「使いたい」と思ったということです。使われるから機能が増え、機能が増えるからコードが膨らみ、コードが膨らむから設計の一貫性が保ちにくくなります。つまり技術的負債は、ある意味では「成功の副産物」でもあるのです。
問題は、その副産物が蓄積したときに誰がコストを払うか、です。
OSSの場合、そのコストはメンテナーに集中します。スターを押した何千人もの開発者の大半は、コードを読みません。使うだけです。設計の経緯を理解しているのはごく少数のメンテナーで、彼らが離れたとき、リポジトリには「動くが誰も全体を把握していないコード」が残されます。
OSSの世界では、メンテナーの燃え尽きが繰り返し話題になります。その根底にあるのは、コードが増えるスピードと理解が共有されるスピードの非対称性です。issueは増え、PRは増え、でも設計の文脈を共有できる人は増えません。この構造が、静かにプロジェクトを蝕んでいきます。
社内プロジェクトでも構図は同じです。「あのシステムのことは○○さんしか知らない」という状態は珍しくありません。プロジェクトが成功して規模が大きくなるほど、理解の属人化は進みます。
考えてみると、私たちがOSSに依存するとき、暗黙のうちに「このプロジェクトは今後もメンテナンスされ続ける」と仮定しています。でも、その仮定を支えているのは組織でもプロセスでもなく、多くの場合は数人のメンテナーの善意と体力です。スター数が何万あっても、コアメンテナーが2〜3人というプロジェクトは珍しくありません。その2〜3人が抜けたとき、何千もの依存プロジェクトが一斉にリスクにさらされます。
スター数が多いリポジトリで起きていることは、あらゆるソフトウェアプロジェクトの縮図なのです。

GitHub人気リポジトリが映す「コードは読めるが理解できない」問題

シニアエンジニアなら、この感覚はわかるのではないかと思います。コードを読むことはできます。構文も、パターンも、処理の流れも追えます。でも「なぜこの設計になっているのか」がわからないコードは、読めても理解できません。
コメントやREADMEがあっても、そこに書かれているのは「何をしているか」であって、「なぜそうしているか」ではないことが多いものです。設計判断の経緯——「Aの方法もあったが、Bの制約があったからCにした」——こういった意思決定のプロセスは、コードにもコメントにも残りにくいのです。人気OSSのコードを深く読んだことがある方なら、この手がかりのなさを実感したことがあるはずです。処理は追えます。でも「なぜ」がわかりません。そしてその「なぜ」がわからないまま変更を加えると、思わぬところが壊れます。
「コードは残るが、仕様は誰も知らない」——この言葉は、企業の社内システムだけでなく、OSSの世界にもそのまま当てはまります。
AIコーディングの文脈で言えば、この問題はさらに加速していきます。AIが生成したコードには「なぜ」が最初から存在しません。人間が書いたコードなら、少なくとも書いた本人の頭の中には理由がありました。AIにはそれすらありません。「コードが読める」と「コードを理解できる」の溝は、AI時代にますます広がっていくのです。

私がこの問題に関心を持つのは、これがソフトウェア開発全体に通底する構造だと思うからです。OSSであれ、社内プロジェクトであれ、AIが書いたコードであれ、「動くコードの量」と「理解されているコードの量」のギャップは、時間とともに必ず広がります。GitHubのスター数はそのギャップを可視化してはくれません。でも、ギャップは確かにそこにあります。

まとめ

GitHubのスター数は人気の指標であって、品質やメンテナンス性の指標ではありません。人気リポジトリほど、設計意図が共有されないままコードが増え、理解の属人化が進みます。これはOSSに限った問題ではなく、AIコーディング時代のあらゆる開発現場で起きている構造と同じです。「コードが読める」と「コードを理解できる」の間にある溝は、ドキュメントなしには埋まりません。

あなたが依存しているOSSのリポジトリ、メンテナーが離脱したら何が起きるか、考えたことはありますか？

次回は、この問題の核心——「コードは残るが、仕様は誰も知らない」という構造を正面から掘り下げます。AIコーディング時代に最も深刻化する問題の全体像を描いていきます。