← 2026-06-02 の一覧へ戻るホーム
GitHub とソフトウェアに対する犯罪

2026/06/02 3:54

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

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

元の要約は強力かつ包括的であり、主要な技術的問題、比較、および結論をすべて正確に反映しています。明確さを保ちながら曖昧な表現を避けており、必要以上に改善を加える必要はありません。望ましい場合の簡潔さのための軽微なスタイル調整を除けば、現在のバージョンは品質チェックポイントを効果的に満たしています。

本文

GitHub とソフトウェアに対する犯罪：技術的負債と倫理的腐敗について

著者: Efron Licht 更新日: 2026 年 5 月

はじめに

引用 家を焼いている状況であれば、関わる側はただ二つしかありえないだろう。一方は火を消そうと努め、もう一方はその家が燃え続けることを願うものだ。 — アブラハム・リンカーン

記事執筆時、GitHub はまたもやダウンしていた。多くのメディア（The Verge など）による報道は信頼性やセキュリティの問題を表面的なものであるとしており、実態を捉えていない。**GitHub の不具合は単なるインシデントではなく、大規模技術サービス業界全体のインフラストラクチャの腐朽を示す「指標」**である。この腐朽は AWS や Google 検索といった主要クラウドサービスにも見られるが、開発者の生態系という点でほぼ同義となる GitHub は特に深刻だ。

私は過去に「GitHub アカウントを持っていない」「本物のプログラマーではない」と見なされる経験から、高パフォーマンス・高可用性・高容量の分散システムとしての期待に対する失望を深く理解している。

主要な問題点

  • 頻発するインシデント: 公的に数十回報告されているが、実際は数百回の可能性がある（月次）。
  • 不透明な運営: 障害やバグリストを隠蔽し、優先順位を嘘をついて説明している。
  • SLA 違反: 自身での指標でも可用性の低下が確認できる。
  • AI 偏重: 基本的な信頼性よりも派手な AI 機能を明確に優先している。
  • 「エージェンティック」負荷: 親会社のマイクロソフトによる強引な AI/エージェント機能の導入により、システムへの過度な負荷が生じている。
  • ブラウザ互換性: Firefox や Safari で頻繁に動作しない。
  • コミュニティへの影響: 「フォロワー購入」「スター購入」を容認しており、Astroturfing（見かけ上の活発さ）を促す。
  • パフォーマンス劣化: プルリクエストページが重く、メモリー消費が多すぎる（ヒープスパイク）。
  • 危険な設定変更: 有害な機能をデフォルトでオンにし、ユーザーの環境を破損させる。
  • GitHub Actions の問題: 設計が悪く、ログからメモリーを漏洩させるリスクがある。

GitHub のフロントエンドは滑稽ほど肥大化しており、Safari や Firefox で頻繁に破綻する。以前有用だった機能を徐々に AI システムへのファンネルへ置き換えている。

GitHub はユーザーに対して稼働時間と優先順位について常に嘘をついている

公式ステータスページは 99.8% の稼働時間を謳っているが、実態は異なる。「9」が含まれていない（例：90%）という事実を The Missing GitHub Status Page などが示している。

マイクロソフトによる「エージェンティフィケーション」への強圧

Microsoft は「2025 年 12 月下旬からエージェンティックな開発ワークフローが劇的に加速しました」と主張するが、これは受動態での説明であり信用に欠ける。事実上、GitHub はマイクロソフト所有であり、AI ボタンが UI の隅々に溢れている。

重要な指摘 GitHub の「エージェンティック」負荷の増加は、彼ら自身および親会社であるマイクロソフトの行動による直接的な結果である。

  • 通常のリポジトリランディングページ右上だけでも、Copilot やエージェントを開始するボタンが 4 つもある。
  • エージェントを明示的に無効化していない場合、さらに追加ボタンが表示される（病的）。
  • GitHub はこれらのツールの利用費用を負担しており、実質的な自己 DDoS に資金を提供している状態だ。

明確な嘘：優先順位の変更宣言

Microsoft は「まず可用性、次に容量、そして新機能」と主張するが、これは嘘だ。

  • チェンジログの分析: 「Copilot」(59 回) と「agent」(8 回) に対し、「performance」(0 回) と「reliability」(0 回) が記載されていない。
  • 実例: Visual Studio Code はブランド新しい「エージェントウィンドウ」をプッシュし、基本的な埋め込みターミナルの機能を阻害した。

「私は盲目ではない……靴に小便をかけながら『雨が降っている』と話すな。」

フロントエンドコードの腐敗

パフォーマンス問題はアーキテクチャ（バックエンド）の問題だが、我々は**フロントエンドコード（HTML/CSS/JS）**を検証できる。ピザ店の厨房が汚れていると同様に、GitHub の前端コードの腐敗は裏方の大きな問題を指示する。

GitHub のフロントエンドコードは混乱しています：GitHub、GitLab、および Codeberg の比較

優れた実験において混乱変数を最小化するため、以下の条件で比較実験を行った。

  • ネットワーク: 3G 速度制限（地方在住者の体験）。
  • 環境: 同一のブラウザ（Firefox）、同一の機器（Apple MacBook Pro M5 Max, 48GiB RAM）。
  • 対象リポジトリ: 全てのサービスにアップロードした同一のミニマルなリポジトリ。

実験手法とプロセス

  1. データ収集:
    • HAR（ネットワークアーカイブ）の保存。
    • ヒープ RAM スナップショットの取得。
    • testcompress
      を用いた圧縮サポートの確認。
  2. 分析ツール: 
    • anhar
      で HAR ファイルを解析。
    • サードパーティサービス pagespeed.web.dev の利用。
#!/usr/bin/env bash

# リポジトリの作成
mkdir ghsucks && cd ghsucks
git init 
echo '# ghsucks' > README.md
git add README.md
git commit -m 'initial (and only) commit'

# 複数プラットフォームへの Push
git remote add github https://github.com/ef0xa/ghsucks && git push github master
git remote add gitlab https://gitlab.com/efronlicht/ghsucks && git push gitlab master
git remote add codeberg https://codeberg.org/efronlicht/ghsucks && git push codeberg master

負荷後のヒープ RAM 使用量比較

サービス使用 RAM評価
GitHub69 MiB⚠️ 過剰消費
GitLab68 MiB⚠️ 過剰消費
Codeberg14 MiB✅ 良好
eblog.fly.dev1.3 MiB✅ 極小化

歴史的比較: PlayStation 2(32MiB) や Wii(88MiB) もこれより少ない容量で動作可能だった。GitHub の空リポジトリ表示すらこの程度消費する状態は不条理である。

圧縮サポートの比較 (
testcompress
)

Zstd は Gzip よりも効率的だが、すべてのサイトがサポートすることは重要だ。

URLMIMEサポートバイト数 (原)バイト数 (Gzip)バイト数 (Zstd)
eblog.fly.devtext/htmlzstd, gzip575 KiB67 KiB60 KiB
github.comtext/htmlgzip224 KiB43 KiB37 KiB
gitlab.comtext/htmlgzip43 KiB11 KiB11 KiB
codeberg.orgtext/htmlなし43 KiB13 KiB12 KiB

HAR アナライズによる負荷時間比較 (
anhar
)

GitHub はメインページロードに約 21.33 秒を要するのに対し、競合は数秒以下である。

サービスコンテンツロードフルロード (HAR)レスポンササイズ
Codeberg2.93s3.17s-
eblog.fly.dev67ms200ms-
GitLab6.62s11.82s-
GitHub843ms21.33s-

コード多過剰: GitHub のフロントエンドには、DOOM や Windows OS よりも多い行数が含まれている。多くのファイルがチャンク化され、Webpack で分割されているが、その多くはキャッシュインvalidationやロード遅延の原因となっている。

GitHub、GitLab、および Codeberg の比較（詳細評価）

各プラットフォームの概要と提言を以下にまとめる。(script 評価および解析指標は pagespeed.web.dev の提供)

GitLab

  • 概要: コンテンツロード約 7s、ロード時間約 13s。推定バグ数 10。ステートレスなヒープ使用量 68MiB。
  • グレード: D+
  • 問題点:
    • コードが極端に肥大化している（70 ファイル、約 10,000 ライン）。
    • JavaScript/CSS のコード片断がシリアル処理によりパフォーマンスを阻害。
    • ページロード前に Garbage Collection に 200ms を費やす（アマチュア的レベル）。
  • 開発者への提言:
    • CSS/JS の大部分を廃棄し、必要最低限に縮小する。
    • テキストファイルを HTML 内に結合し、リクエスト数を最小化すること。
    • さらに圧縮（Gzip など）を行うことで速度向上を図る。

Codeberg / Forgejo

  • 概要: コンテンツロード約 2.9s、フルロード約 3.1s。推定バグ数 2。ステートレスなヒープ使用量 14MiB。
  • グレード: C+
  • 問題点:
    • HTML を圧縮していない（小さなミス）。
    • Gzip/Zstd の両方をサポートしていない（大きなミス）。
    • JavaScript/CSS が不要な部分を含んでおり、描画をブロックしている。
  • 開発者への提言:
    • ペイロードを結合し、リクエスト数を減らす。
    • Gzip および Zstd 圧縮のサポートを追加する（特に HTML の初期高速化）。
    • 使用されていない CSS/JS を削除する。

GitHub

  • 概要: コンテンツロード約 800ms、フルロード約 7s。ステートレスなヒープ使用量 69MiB。推定バグ数 550。
  • グレード: F
  • 問題点:
    • コード行数が極めて多すぎる（約 550,000 ライン）。
    • テーマやコンポーネントを無意味にフェッチしている。
    • LLM に生成されたような膨大なコード量があり、ページ速度に影響している。
  • 開発者への提言:
    • 過剰なコードを大胆に削除する（ランダムにテストして機能性を保つ）。
    • AI ボタンの強制機能を拒否または無効化する。
    • pagespeed.web.dev の指摘通り、使用されていない JS/CSS (528KiB) を除去。

eblog.fly.dev (参考基準として)

  • 概要: コンテンツロード 76ms、フルロード 1.1s。推定バグ数 0（推測）。ステートレスなヒープ使用量 1.3MiB。
  • グレード: A-
  • 問題点:
    • HTML が圧縮されているが肥大化している。
    • 5 つのリクエストが必要だが、単一ファイルで十分だった。
  • 開発者への提言:
    • 反復的なスタイルを少数の外部リソースに統一する。
    • カスタムフォントを省略または「optional」にする。
    • CSS をドキュメント内インライン化し、同期依存関係を削除する。

結論

「犯罪は常に疑わしくあり、病んだ人のように指を指すだけで震える。」 — チャールズ・サマナー、"Kansas に対する犯罪"

大企業がソフトウェアインフラストラクチャを管理する信頼性は急速に失われている。GitHub は単なるバグの蓄積ではなく、ソフトウェアに対する犯罪である。

  • 企業倫理: Microsoft と GitHub は「エンシフィケーション（enshittification）」と呼ばれるプロセスを経ており、ビジネス顧客への裏切りから自らの機能低下へ至っている。
  • 技術的負債: 膨大なエンジニアリングコストを埋もれさせている過剰なコードは、単なる計算ミスではなく、意図的でないが致命的な技術的誤りだ。
  • 選択の自由: GitHub に依存する必要はない。GitLab や Codeberg、あるいは自律的なホスティング（自前）の方が性能面でも信頼性でも優れているケースが多い。

業界全体が「無料」や「AI」という言葉で真実を隠蔽しているが、ソフトウェアはユーザーの問題を解決するためのツールであるという事実は忘れられていないはずだ。

最終提言 GitHub を使用する必要があれば、SLA 違反の報告と返金要求を検討すること。しかし根本的な解決には「乱暴的なコード削除」と「AI 依存からの脱却」が必要だ。 「私はあなたに請求せず、双方とも問題解決に確信している。」

付録

使用したツール

  • anhar: JSON パースによる HAR ファイル分析（ソースコード参照）。
  • testcompress: 圧縮サポートとデータサイズの比較（ソースコード参照）。

ボーナスコンテンツ：テスト結果

go run ./testcompress \
    'https://eblog.fly.dev/startingsystems3.html' \
    'https://github.com/ef0xa/ghsucks' \
    'https://gitlab.com/efronlicht/ghsucks' \
    'https://codeberg.org/efronlicht/ghsucks'

結果サマリー:

  • eblog.fly.dev: 圧縮率 Gzip 11.75%, Zstd 10.45% (最良のバランス)
  • github.com: 圧縮可能だが、データ量が膨大。Gzip 比 19.26%
  • gitlab.com: Gzip 比 26.64%, Zstd 比 26.32%
  • codeberg.org: 圧縮サポートなし（n/a）、Gzip 比 29.62%, Zstd 比 29.16%

Efron Licht - Software Talmud への招待状

同じ日のほかのニュース

一覧に戻る →

2026/06/02 1:31

最新のインスタグラムの「 exploits（バグ）」で最もユニークなのは私がこれまでに見た中で一番奇妙なものです。

## 日本語翻訳: 洗練されたセキュリティ上の不備により、ハッカーらは警報を触発することなく Instagram のアカウントを乗っ取り、@obamawhitehouse や @ocmssf のような高価値なユーザー名を対象に Meta の「Takeover Flow」を利用した。攻撃者は被害者のユーザー名を使用してプロセスを開始し、VPN または代理サーバーを介して請求をアカウントの報告された都市の近くから経路化することで、位置情報に基づくセキュリティを回避した。彼らは Meta の AI サポートチャットボットに連絡し、アカウントが侵害されたことをごりごしくれ、検証コードを受信するメールアドレスを任意で指定することを要求した。Instagram のシステムは、この要求されたメールアドレスが以前にそのアカウントと関連付けられていたかどうかを検証しなかった。AI がコードを送信すると、それはパスワードリセットリンクのトリガーとしての検証に使われ、完全な所有権が付与された。Meta のサポート AI はビデオでの自己撮影（生真面目）を身分証明として要求する可能性があるが、ターゲットのフィードから単純に AI でアニメーション化された公開写真は、このチェックを成功裡に回避した。回復フローは、そのリクエストを「本当の」所有者による完全なアカウントリセットとして扱い、2FA を完全に回避し、メール、テキスト、またはプッシュ通知を触発することなく進んだ。正当なユーザーのセッションは沈黙的に破棄され、連絡先情報が攻撃者の情報で置換されたため、標準的なチャネルでの回復は不可能になった。ブラックマーケットの Telegram グループが「アカウント乗っ取り」サービスを提供し始め、高価値なハンドルを利活用した。この脆弱性は数週間、あるいは数ヶ月間 Meta が修復するまで稼働していたと報告されており、その地下市場は一瞬で消え失せた。実験的な AI サポートグループに参加しているユーザーは、自動化されたアシスタンスを手動で無効化できないため、引き続き曝されている。この事象は、将来的な回復プロセスが人工知能や位置情報に基づく回避技術によって容易に操作されるのを防ぐためには、自動的なりすましおよびリモートスプーフィング攻撃に対するより強力な検証プロトコルの強化を強く示唆している。

2026/06/02 5:40

デバッグプロジェクト

## 日本語訳： Debug は、地球上で最も致命的な動物の一つである*Aedes aegypti*蚊の個体群を安全に抑制し、デング熱、ジカ熱、黄熱病、チクングニア熱といった致死性の疾患に対する革命的な対策を開拓しています。化学物質や遺伝子改変に依存する従来のアプローチとは異なり、当社の技術は自然存在する細菌*Wolbachia*を運ぶ雄性不稔の雌蚊を放出します。この生物は、これらの雄蚊が野生の雌蚊と繁殖することを妨げ、毒物を導入することなく個体群を自然に減少させます。吸血せず病気を媒介しない雄蚊であるため、「良い虫」としてこれを放出することは、立ち枯れた水の撤去や効果低下しつつ毒性が強まり過ぎる殺虫剤の使用といった陳腐な手法の持続可能な代替手段を提供します。現在、ほとんどの蚊媒感染症には効果的なワクチンがないことを考慮すると、この解決策は不可欠な新たなアプローチとなります。科学専門知識を国際パートナーと組み合わせ、Debug は地域コミュニティおよび政府との協力のもとで放出規模の拡大を目指しています。その最終的な影響は大きいです：刺す蚊の数を減らして病気の伝播率を下げ、安全でスケーラブルな生物学的制御戦略を通じて数百万人の人々がより長く健康な生活を送るのを支援します。 ## 元テキスト： ## Summary: Debug is pioneering a revolutionary method to combat deadly diseases like dengue, Zika, yellow fever, and chikungunya by safely suppressing populations of *Aedes aegypti* mosquitoes, which are among the deadliest animals on Earth. Unlike traditional approaches relying on chemicals or genetic modification, their technology releases sterile male mosquitoes carrying the natural bacterium *Wolbachia*. This organism prevents these males from reproducing with wild female counterparts, naturally causing population decline without introducing toxins. Since male mosquitoes do not bite or spread disease, releasing these "good bugs" offers a sustainable alternative to outdated methods like clearing standing water and using pesticides that are losing efficacy or becoming too toxic. Given that most mosquito-borne illnesses currently lack effective vaccines, this solution provides a vital new approach. By leveraging scientific expertise alongside international partners, Debug aims to scale up releases in collaboration with local communities and governments. The ultimate impact is significant: reducing biting mosquitoes to lower disease transmission rates, thereby helping millions of people live longer, healthier lives through a safe and scalable biological control strategy.

2026/06/02 1:41

スタンフォード大学CS336コース用 AI エージェントガイドライン

## 日本語翻訳: 本ドキュメントは、スタンフォード大学の CS336 コースにおいて AI コーディングアシスタントが従う厳格な倫理的境界線を設定する：すなわち、これらは何らかのコードを書いたり課題を直接解決したりしてはならない。むしろ、これらのエージェントは、学生による学習体験を維持することを目的とした教学補助手段としてのみ機能すべきである。本コースが手動作業としての Python と PyTorch の実装に大きく依存し、かつ支援枠組みが限られていることを考慮すると、AI の主たる役割は、公式の講義資料とデバッグツールの活用を通じて背後にある理論を説明し、エッジケースにおけるロジックを検証し、学生を導くことにある。 ユーザーから直接の修正、TODO 節の完了、またはリポジトリへの編集といった要請を受けた場合、エージェントはその要求を拒否し、概念の説明や、shape アサーションやアブレーションなどの健全性チェックを提案することで方向転換しなければならない。この方針は、学生がトラン스포ーマー、最適化アルゴリズム、トレーニングループなど複雑なコンポーネントの習得という核心的学習目標を回避することを防止するものである。システムはこの方針を強制するためには、明確な質問を投げかけ、公式ドキュメントを参照し、単に「如何做るか」を届けるのではなく、技術的決定の背後にある「なぜか」を説明することで、デバッグと概念的理解を通じて真の能力を確保するよう求める。