ソフトウェアへの犯罪：GitHubのインフラ劣化を分析

現代のソフトウェア開発の風景は、ほぼGitHubと同義語です。多くの開発者にとって、GitHubのプロフィールはプロとしての正当性の前提条件です。しかし、世界で最も人気のあるコードホストの洗練されたインターフェースの下には、インフラの劣化という増大するパターンが潜んでいます。サービスがグローバルなソフトウェア生産の中枢神経系になると、その信頼性とパフォーマンスはもはや単なる「ユーザー体験」の問題ではなく、システム的リスクとなります。

最近の障害やパフォーマンス低下は、しばしば「エージェント型開発ワークフロー」の成長痛として片付けられます。しかし、詳しく見ると、GitHubの現状は成長の偶然ではなく、派手なAI機能を根本的なエンジニアリングの卓越性よりも優先する意図的な方針の結果であることが示唆されます。

AI優先パラドックス

MicrosoftとGitHubは「AIエージェント」やCopilotをプラットフォームの至る所に積極的に導入しています。典型的なリポジトリのランディングページでは、ユーザーは画面の1つの象限にしばしば4つものAIボタンに出会います。この押し出しは単なるUXの選択ではなく、リソースの消耗です。

GitHubは最近の可用性の問題をエージェント型ワークフローの急速な加速に起因するとしています。しかし、この「負荷」は自らの戦略の直接的な結果です。これらのツールの採用を促進するために補助金を出すことで、GitHubは実質的に自社インフラに対する分散型サービス拒否（DDoS）攻撃を資金提供したことになります。

Microsoftが「可用性が最優先、次に容量、そして新機能」と主張する一方で、データはそれとは逆のことを示しています。30日間のGitHub公開変更ログをレビューすると、優先順位の顕著な対比が明らかになります：

Copilot の言及: 59
Agent の言及: 8
Performance の言及: 0
Reliability の言及: 0

膨張の定量化：比較実験

技術的劣化の程度を理解するために、GitHubとGitLab、Codeberg（Forgejo）のフロントエンドリソース使用量を比較する実験を実施しました。目的は、実世界の制約をシミュレートするためにスロットルされた「Fast 3G」接続を使用し、3つのサービスすべてで最小限かつ同一のリポジトリをレンダリングするコストを測定することです。

メモリとヒープ使用量

アクティブな処理がなくても、安定状態でのRAM消費は驚異的です。PlayStation 2が3Dグラフィックスをレンダリングするのに総RAM 32 MiBで動作していたのに対し、コードホスティングの最新ウェブフロントエンドはテキスト表示だけでもはるかに多くのメモリを消費しています。

サービス	安定状態ヒープ使用量
Codeberg	~14 MiB
GitLab	~68 MiB
GitHub	~69 MiB

実際のコンテンツをロードすると、無駄はさらに拡大します。高活動ページ（例：Rust言語のプルリクエスト）のヒープスナップショットでは、148 MiBを超えるスパイクが見られました—これは元のiPhoneが持っていたメモリ量を上回ります—リンクのリストをレンダリングするだけでです。

ネットワークペイロードとコード量

カスタム分析ツール（anhar）を使用して、空のリポジトリに対するネットワークリクエストを分解しました。その結果、クライアントに配信されるコード量に大きな格差があることが明らかになりました。

GitHub: 約300ファイル、合計約55万行のコードとデータをロードします。これを比較すると、元のDOOM（35千行）やMS-DOS 4.0全体（332千行）を構築するのに必要だったコード量を上回ります。
GitLab: 約7 MiB、70ファイル（約1万行）を取得します。
Codeberg: 約1 MiB、11ファイル（約1千100行）を取得します。

GitHubがチャンク化にWebpackに依存しているため、数百の独立したHTTPリクエストが必要となる断片化された配信システムが生まれ、かなりのオーバーヘッドが加わり「Time to Interactive」が許容できないほど遅くなります。いくつかのテストでは、スロットルされた接続で空白ページの完全ロードに21秒以上かかりました。

インフラの「エンシット化」

「エンシット化」と呼ばれる一般的な理論があります。これは、製品が最初はユーザーにサービスを提供し、次にビジネス顧客に、最終的には自社の株主だけにサービスを提供するというものです。しかし、GitHubの劣化はそれとは異なるように感じます。肥大化はユーザーだけでなく、Microsoftにも損害を与えます。Microsoftは帯域コストや、崩壊寸前のコードベースを維持するためのエンジニアリング時間を支払っています。

これは単なる技術的負債ではなく、プロフェッショナルな誠実さの失敗です。プラットフォームのフロントエンドがこれほど非効率であると、重要な疑問が浮かびます：もし「ダイニングルーム」（フロントエンド）がこのように放置されているなら、「キッチン」（バックエンドとデータベースアーキテクチャ）はどうなっているのでしょうか。

コミュニティの視点と代替案

開発者コミュニティの反応は分かれています。あるユーザーは満足しており、GitHubの規模がある程度の非効率を正当化すると主張します。別のユーザーは危機感を抱き、より軽量な代替サービスへ移行しています。

"その子犬（リポジトリ）を自分の tailnet に置き、Gitea をインストールし、すべてのプロジェクトで専ら使用しています。自由を感じます。" — @jodacola

他の人は、実際の「ロックイン」はコードではなく、ソーシャルキャピタル—GitHubのスター—であると警告しています。@ashishb が指摘したように、スターはプロジェクトの重要性を示す通貨として機能し、偽のスターを販売するサービスの存在はソフトウェア品質のシグナルをさらに腐敗させます。

成績の概要

サービス	成績	判定
Codeberg	C+	有望な基礎はあるが、圧縮と最小化が不足している。
GitLab	D+	未使用のJS/CSSが過剰で、ガベージコレクションが不十分なため苦戦している。
GitHub	F	滑稽なほど肥大化しており、基本的なパフォーマンスよりもAIプロンプトを優先している。

結論

ソフトウェアはユーザーの問題を解決するために存在します。世界のソフトウェアを構築するために使用するツールが浪費と無能さの例になると、それは単なる不良製品以上のもの—メディアへの犯罪です。業界が現在AI駆動の「エージェント」に執着していることは、腐食のフィードバックループを生み出しています。AI生成コードとAI駆動の負荷がそれらをホストするプラットフォーム自体を劣化させているのです。今後の道は、効率性、信頼性、そしてユーザーのリソースへの敬意という基本に立ち返ることが必要です。