ハクソク

世界を動かす技術を、日本語で。

GitHubとソフトウェアに対する犯罪

1日前原文(eblog.fly.dev)

概要

  • Githubの信頼性やパフォーマンス低下の深刻さを指摘
  • MicrosoftによるAI機能優先の方針への批判
  • フロントエンドや運用面での技術的欠陥の具体例
  • GitlabやCodebergとの比較によるGithubの問題点の浮き彫り
  • 利用者への影響と今後の懸念

Githubとソフトウェアへの犯罪

Efron Licht著（2026年5月）

  • Githubの障害多発 と 信頼性低下 は業界全体のインフラ劣化の象徴

  • AWSやGoogle Search など他の大手サービスにも同様の問題が拡大傾向

  • Githubアカウント未所持 ＝「本物のプログラマーではない」とされる社会的影響

  • 本来のGithubは 高性能・高可用性・高容量の分散システム であるべき存在

    • 信頼性・可用性だけでなく、多様な問題が山積
    • 公開バグリストやイシュー一覧非公開、問題の隠蔽体質
    • 稼働率や優先順位に関する虚偽説明 が常態化
    • SLA違反 が自社指標でも明らか
    • 派手なAI機能 を優先し、基本的な信頼性やユーザー体験を軽視
    • FirefoxやSafariでの動作不良 も頻発
    • フォロワー・スターの売買 や 偽装リポジトリの蔓延 を放置
    • プルリクエスト画面の遅延・メモリ消費過多 （512MB超のヒープスパイクも）
    • 危険な新機能のデフォルト有効化 による設定リセット
    • Github Actionsの設計不良・低速・ドキュメント不足
    • Actionsログのメモリリーク や 標準出力の不便さ
    • キャッシュ機能の無意味さ （無効なキャッシュが常態化）

Githubのフロントエンドの問題

  • フロントエンドの肥大化・低速化 が深刻
  • SafariやFirefoxでの動作不安定
  • UI/UXの頻繁な変更 と AI機能への誘導 が顕著

Githubの稼働率・優先順位に関する虚偽

  • 公式稼働率99.8% と主張するが、実態は「ゼロナイン」
  • The Missing Github Status Page などで実際の障害状況が可視化
  • MicrosoftによるAI推進 がGithubの負荷増大の主因
  • AI/Agentボタンの乱立 （1ページに4つも存在）
  • AI機能の利用促進のためのコスト補助 による自爆的負荷増加
  • パッチノートの内容もAI関連が大半、パフォーマンスや信頼性への言及なし
  • Visual Studio CodeもAI機能強化優先、基本機能の劣化が進行
  • 「可用性優先」との公式声明は虚偽、実態は新機能・AI優先

技術的課題と組織的問題

  • 分散システム設計の根本的な失敗 を認めざるを得ない状況
  • フロントエンドの設計・実装の質が低い ことがバックエンドの問題も示唆
  • GitlabやCodebergとの比較実験 でGithubの非効率性・技術的劣化を検証予定

Github、Gitlab、Codebergのフロントエンド比較

  • Githubのフロントエンド はリンクリストや基本的なUX要素中心のはず

  • Gitlab・Codebergも同様のUI/UX を模倣し、機能面はほぼ同等

  • Githubのみ肥大化・パフォーマンス低下が顕著

    • 実験的な比較 により、Githubのフロントエンドの非効率性・設計の悪さを可視化
    • リポジトリ作成・アップロード・ネットワークデータ収集 などの実験手順を提示
    • ヒープ/RAM使用量の比較 でGithubの異常なリソース消費を明らかに
    • 圧縮サポートやネットワークアーカイブ分析 も実施

総括と今後の懸念

  • Githubの信頼性低下 は単なる「エンシティフィケーション」ではなく、構造的な問題
  • ユーザーや開発者への具体的な悪影響 が拡大
  • MicrosoftのAI偏重路線 による本質的な価値の毀損
  • 競合サービスとの比較検証 による改善への示唆
  • 今後もGithubの品質劣化が続く可能性 が高い

利用者・開発者への提言

  • Githubの現状を正しく認識 し、依存度の見直しを推奨
  • 代替サービス（Gitlab、Codeberg等）の活用 も検討
  • 自分自身で実験・検証を行う重要性 の強調
  • サービス選定時はパフォーマンス・信頼性を最優先 に考慮

まとめ

  • Githubの現状はソフトウェア開発インフラ全体の警鐘
  • AI推進の裏で基本品質が犠牲
  • 利用者自身による情報収集と批判的検証 が今後ますます重要

Hackerたちの意見

「インセンティブの力を考えるべき時に、他のことを考えちゃダメだよ。」 — チャーリー・マンガー 編集: いい記事だね、ありがとう、OP。

GitHubの問題が多いから、GitLab.comとCodeberg.orgも追加するよ。設定はたったの3ステップ：1. 各サービスにサインアップ、できれば同じユーザー名で。2. 共有したいリポジトリごとに、空のリポジトリを同じ名前で作成；READMEは自動で作成しないでね。3. ローカルファイルの.git/configを編集してプッシュURLを追加、その後はいつも通りプッシュ。例: [remote "origin"] url = git@github.com:foo/bar.git pushurl = git@codeberg.org:foo/bar.git pushurl = git@github.com:foo/bar.git pushurl = git@gitlab.com:foo/bar.git fetch = +refs/heads/:refs/remotes/origin/

└

tangled.orgとradicle.devも追加したいな。最近、これらの新しい分散型フォージに注目してるんだ。

└

楽しみのために、VPSを立ち上げて、そこにいくつかのベアリポジトリを初期化してみて。

└

イシュー、プルリクエスト、ウィキ、ディスカッション、プロジェクトボード、その他のすべてはどこに保管してるの？（修辞的な質問ね。）最近のクラウドホスティングされたGitプラットフォームの問題は、コードをどこにプッシュするかじゃないんだ。複数のプロバイダー間でリポジトリを複製するのは比較的簡単で、Gitはそれが得意だからね。もっと難しいのは、成功しているチームはリポジトリの周りにソースコード以上のものをたくさん蓄積しちゃうこと。バグレポート、機能リクエスト、ドキュメンテーション、デザインディスカッション、コードレビュー、プロジェクト計画、CI/CD設定、そして何年もの歴史的な文脈が、GitHubのようなプラットフォームの中に存在することが多い。Gitリポジトリ自体はポータブルだけど、その周りのデータはクリーンに移行するのが難しいことが多い。特に、特定のプロバイダーの周りにワークフローや統合を構築しているチームにとってはね。これが、たくさんの企業がGitHubに依存している主な理由の一つだと思う。コードを他の場所に移すのは通常簡単だけど、すべての歴史、メタデータ、組織の知識を含む開発プロセス全体を移すのは難しい。GitHubがダウンすると、次のコミットをどこにプッシュするかよりも、チームが毎日頼りにしている環境をどれだけ簡単に再現できるかが問題になることが多い。

└

https://blog.nginx.org/blog/nginx-open-source-moves-to-githu...

└

https://finance.biggo.com/podcast/1c9f14e134095b87

└

だったら、自分でGiteaとかホストしちゃえばいいんじゃない？

└

最近、個人プロジェクトをCodebergに移したんだけど、めっちゃ満足してる。GitHubのごちゃごちゃしたバグだらけのインターフェースを何時間もさまよった後、クリーンで直感的なプラットフォームを使うのは最高だよ。数年前はGitLabの大ファンで、GitHubよりも優れてるっていつも言ってたんだけど、今は彼らもGitHubみたいに複雑で「企業向け」になろうと何年もかけて頑張ってるけど、成功してるとは言えないね。

└

そうだね、他のボランティアサービスを潰すために需要を3倍にして、キャパシティ不足を解決しようってことか。

このウェブサイトは色やフォントサイズのせいで、すごく読みづらい。

└

こういうウェブサイトにはFirefoxのリーダービューを使ってるよ。

└

同意！これはAIの完璧な使い方だね。「CSSを使って、このウェブサイトを読みやすくして、適切なカラースキームを使って」っていうプロンプトが見えるよ。

└

これは明らかにリーダーモードを知っている技術に詳しい人をターゲットにしてるね。カスタムCSSを読み込んだり、CSSを読み込まずにフォントやサイズを選んだりできるんだから。

└

耐えられるように150%にズームしなきゃならなかった。

└

いいね、これ。キャラクターがあって。

自己ホスティングの時代に戻ることになるね。自己ホスティングのGitLabは夢だよ、驚くこともなく、リポジトリがちゃんと動くんだから。

└

自己ホスティングのGitLabも、俺の経験では同じくらい遅いよ。

└

15GBのDockerイメージで、俺の経験ではかなり重い感じがする。俺も近いうちにGiteaに移行するつもり。

GitHubは公開バグリストやイシューのページを公開せず、問題をメールチェーンの奥深くに隠している どのメールチェーンのことを言ってるの？GitHub/communityはコミュニティの視点から見てもかなり活発だよ。GitHubはもうあまり見てないし、エンタープライズのロードマップを優先してる。 > GitHubはFirefoxやSafariでよく壊れる、何百万ものユーザーがいるブラウザで [[出典必要]]。Reactの書き換え以降、GitHubのフロントエンドのパフォーマンスにみんなと同じくらいイライラしてるけど、Firefoxで壊れたことはあまりないな。この主張は記事の中で何度か繰り返されてるけど、リンクはないね。

https://ashishb.net/tech/github-stars/

└

新しいプラットフォームがGitHubのスターをインポート時にミラーリングするのを止める理由って何かあるの？

└

彼らが移行したのは主に星のせいじゃなくて、Mercurialを使ってたからなんだよね。ほとんどの開発者はそれに慣れてないし。

俺はずっとGitHubのヘビーユーザーなんだ。昔、サンフランシスコでオクトキャットのサインを持ってる人たちを見たのを覚えてる。GitHubは最高だった。いい思い出だよ。でも、時代は変わってるし、いろんな理由で今はGitHubがクールじゃないし、「自分のため」って感じもしない。だから、新しいMac Miniを買ったんだ。セール中だったし、みんなOpenClaw用に買ってたから…それを自分のネットワークに入れて、Giteaをインストールした。今はすべてのプロジェクトでそれを使ってる。GitHubに何かプッシュしたのはもう数週間前だよ。自由を感じるね。

└

同じく、俺もForgejoとTangled Knot + Spindleを自分でホストしてる。今は雇い主のためにGitHubを使ってるけど、これから新しいコードはそこに置くつもりはないよ。

└

ねえ、シンプルなはずなんだけど、Mac Miniをサーバーとして使うアプローチについての詳細を書いてくれるチャンスはある？どうやってセットアップしたのか知りたいな。もしブログ記事を書いたら、絶対読むよ！

自分の会社のためにGitHubを広く使ってるけど、クライアントのプロジェクトではAzure DevOps（とその関連機能）もたくさん使ってる。GitHubの問題が「スケール」のためにAzureバックエンドに移行したせいだって言われてるけど、Azure DevOpsには全く問題がないんだ…本当に。素晴らしいよ。誰か、GitHubとDevOpsの体験がこんなに違う理由を知ってる？合併するはずなのに？それとも全然関係ないの？それとも単にAzureが「エンタープライズ」だから、マイクロソフトがそっちを重視してるの？

└

Azure DevOpsのUI/UXって、めっちゃ使いづらいと思う。作業アイテムがフロントエンドだけで読み込まれることもあれば、リフレッシュしたらブラウザのURLが見てる作業ツリーと違ったりするし。サインインする時にフリッカーやリダイレクトが多いのも気になる。WYSIWYGエディタは、開いた人のカラーテーマを保持することがあるみたいだし。Markdownエディタは、表示か編集だけだし。多分もっと問題に直面したけど、今は思い出せない。でも、問題がないとか、素晴らしいって言うのには共感できないから、ちょっと言わせてもらった。確かに動くけど、リソースを考えると、未完成な製品って感じがする。稼働時間はGitHubよりはいいけどね。

ここで作者です。カラースキームにこだわらない方のために、私のサイトには - ライトテーマ: https://eblog.fly.dev/githubbad-light.html - プレーンテーマ: https://eblog.fly.dev/githubbad-plain.html があります。この記事を提出したのと同じアップデートで追加したものです。どちらもPDFとしても利用可能です（.htmlを.pdfに置き換えてね）。もちろん、お気に入りのブラウザでリーダーモードを使うこともできます。

これはただの推測コメントだけど、GitHubの問題リストが妙に見覚えがある。これらの問題は、手がかりなしにエージェントが犯すミスや仮定に似ていて、コードベースを腐らせるんだよね。