余計なものが一切ないGitHub風サービス「GitClassic」、JavaScriptの使用を最小限に抑えてファイルサイズはわずか14KB未満

「プルリクエスト」って何？コードを変更した時に何か申請する手続きってこと？

プルリクエストは、ざっくり言うと「自分が変更したコードを本体に反映させてもいい？」と申請する手続きですね。 流れとしては、共有のコード（リポジトリ）に対して、まず自分だけの作業用ブランチをつくる。そこで好きに改造して、完成したら「ここまでやりました、確認してください」と本体の管理者に知らせる。それがプルリクエストです。 大事なのは、この申請段階で他の人が「このコード、本当に大丈夫？」とレビュー（査読）できるという点。質問や修正の指示を出せるし、承認する前に議論もできる。つまり品質保証のゲートみたいなものになってるんです。 記事で「大規模なプルリクエスト」という話が出るのは、100個以上のファイルを一度に変更するような申請のこと。そういう時にGitHubが遅くなるというわけです。変更箇所が膨大だから、ブラウザが全部の差分を表示しようとして処理しきれなくなる。GitClassicはその点を徹底的に削ぎ落とすことで、大規模な変更でも軽快に見られるようにした、と言えそうです。

GitHubが遅いって話だけど、自分がコード書いてるわけじゃない場合、このニュースって関係あるの？

大規模プロジェクトのリポジトリを眺めることはありますよね。 そういうときにGitHubが遅いというのは、実は結構な損失なんです。 たとえば「このライブラリの最新の変更を確認したい」とか「バグ報告で誰かが上げたプルリクエストの修正内容を見たい」というシーン。 100ファイルを超える大きな修正だったら、GitHubだと数秒から数十秒待たされることがある。 一回の待機は短くても、日々の調べ物のなかで何十回も繰り返されば、年単位では相当な時間ロスになります。 また、セキュリティアップデートやフレームワークの新バージョンを評価するとき、 どんな変更が入ったのかを素早く把握したいのに遅延してしまうと、 判断が後ろにずれる。GitClassicのような軽量な代替なら、その時間を短縮できる。 記事で注目すべきは、GitClassicが「既存のGitHubリポジトリと連携しながら」動作する点です。 つまり、わざわざGitHubを完全に乗り換えなくても、 遅い場面だけGitClassicを使うといった使い分けができるかもしれません。 開発者でなくても、コードを「読む側」として恩恵を受ける余地はありそうです。

GitHubって2008年から変わってないわけじゃなくて、ずっと機能を足し続けてきたから今こんなことになってるってこと？

そうですね。GitHubは始まった当初、シンプルなコードホスティング機能だけを提供していたサービスです。それが時間とともに、プルリクエスト機能が加わり、CI/CDの自動実行環境が加わり、セキュリティスキャンが加わり、果ては AI による提案機能まで積み重ねられていった。企業が大きくなるにつれて、顧客のニーズに応えるために機能を足し続けたというのが実際のところなんですよね。 ただ興味深いのは、この「足し続けた」ことが、実は本来は長所だったはずなんです。一つのプラットフォームで開発に必要なことが全部できるというのは、確かに便利。でも DOMノードが膨らみ、JavaScript が肥大化し、複数の処理が並行実行されるようになると、ブラウザはその複雑性に耐え切れなくなった。特に数百ファイルの大規模プルリクエストだと、その負荷は何百倍にも跳ね上がる。 つまり、ビジネスとして成長するために「全部入り」を目指したことが、実際には開発者にとって使いづらくなるという、ジレンマが生じてしまったわけです。GitClassic はこの矛盾を見抜いて、逆張りで最小限に絞ったと言えそう。

これって『最初はシンプルで速かったものが、機能を増やし続けると必ず遅くなる』っていう、サービス全般に共通する宿命みたいなもの？

そう見えるかもしれませんが、実は「増やし続けたら遅くなる」というより「増やし方の問題」なんだと思います。 GitHubの場合、新しい機能を足すたびに、既存のコード上に重ねていった。だから古い部分と新しい部分が複雑に絡み合って、全体が重くなった。典型的には「すべてのページで全機能を読み込む」という非効率な構造ですね。 一方、うまく設計されたサービスなら機能が増えても速度を保つことはできます。Amazonが機能を増やし続けているのに、昔より遅くなった感覚がない人も多い。それは機能ごとに最適化を細かく進めたり、不要なものを定期的に削ったりしているから。 GitClassicが指摘してるのは、むしろ「包括性を重視した設計思想が選択肢を奪ってしまった」という話です。GitHubはコードレビューのページで「ビルドステータスも、セキュリティスキャンも、Copilotの提案も、全部見せよう」と考えた。その判断が、結果として拡張を難しくしてしまった。 つまり「機能を増やすこと自体は悪くない。ただしそれを支える設計がないと、後からの最適化では追いつかない」という、より厳しい現実が見えてくるのかもしれません。

GitClassicが高速だからって、みんなGitClassicに乗り換えたらGitHubの立場ってどうなるの？GitHubはわざと遅いままにしておきたいのかな？

GitHubが遅いのは、わざとではなく、成長の過程で避けられなかった選択の結果だと言えそうです。 考えてみると、GitHubが今ある地位を築いたのは、まさにその「多機能さ」のおかげなんですよね。プルリクエスト、Issues、Actions、セキュリティスキャン、Copilot連携——こうした機能を次々と追加することで、「コードを置いとく場所」から「開発全体の統合プラットフォーム」へと進化した。その過程で速度の代償を払ったわけです。 ただ、GitClassicのような軽量ツールが出現しても、GitHubが急いで身軽になる理由は薄いと見えます。なぜなら、重い機能こそが、GitHubの収益源だからです。GitHub Copilot、Enterprise向けのセキュリティ機能、AI統合——こうした高付加価値サービスは、プラットフォームの複雑性があるからこそ成り立つ。軽量化してコア機能に絞れば速くなる一方で、差別化の源泉も失われます。 多くのユーザーにとって「ちょっと遅い」というストレスと、「便利な統合プラットフォーム」というメリットは、まだ天秤が後者に傾いているということなのかもしれません。GitClassicは確かに快適ですが、それは「何をあきらめるか」を決めた結果でもあります。