GitHubの神話が崩れた一週間 — Ghostty離脱・SAP npm侵害・Forge連邦化が示す「分散」への揺り戻し

はじめに

2026-04-23から28日にかけての6日間で、GitHubを中心とした開発者インフラに5つの異質なインシデントが重なった。Merge Queue障害、検索システム停止、Copilot課金ポリシー変更、CVE-2026-3854のRCE公開、そしてSAPのnpmパッケージ侵害。さらに同じ週、Mitchell Hashimoto氏がGhosttyのGitHub離脱を表明し、「Forge連邦化」を提唱するエッセイがHacker News上位に並んだ。

昨日の記事ではCVE-2026-3854そのものを深掘りした。本稿ではより一段引いた視点で、これら一連の事象が**「GitHub一極集中という暗黙の前提」をどう揺らしているのか**、そしてForge連邦化の動きが現実解になりうるのかをエンジニア視点で検証する。

何が起きたのか — 一週間で重なった5つの事象

カレンダー順に並べ直すと、構造的な歪みが見えやすい。

4/23: Merge Queue障害 — 658リポジトリ・2,092プルリクエストにマージ破損。CI/CDの根幹であるはずの機能が、企業ユーザーのリリースサイクルを直撃した。
4/27: 検索システム停止 + Copilot課金変更告知 — リポジトリ検索が広範に停止する一方、Copilotの料金ポリシーが事前周知ほぼなしで変更された。
4/28: CVE-2026-3854公開 — 認証済みユーザーがgit push一発でGHESインスタンス上の任意コード実行を狙えるRCE。GitHub.comは6時間で修正されたが、GHESインスタンスの88%が公開時点で未パッチだった。
4/28: SAP npm侵害（Mini Shai-Hulud） — @cap-js/db-service、@cap-js/sqlite、@cap-js/postgres、mbtの4パッケージが汚染。月間1.2M超ダウンロードされる。
同週: Ghostty離脱表明 + Forge連邦化提案 — Hacker News 3,244ポイントを集めたMitchell Hashimoto氏の記事と、Forge連邦化を提唱するTangledのブログがバズる。

これらを「個別の不運」と片付けるのは難しい。共通項は、コード・CI・パッケージ配布・検索・課金が単一プラットフォームに収斂してしまった結果、一つの綻びが全方位に波及することにある。

なぜ単一障害点になったのか — 構造的負債の正体

GitHubの一極集中は、Microsoft買収以降の機能拡張と、Actions・Packages・Codespaces・Copilotといった隣接領域への進出によって加速した。Gitホスティングという出発点から、CI実行基盤・パッケージレジストリ・AI開発環境までを内包する「開発者OS」へと変貌した結果、リスクの性質も変わった。

特に問題視されているのが**「依存連鎖の深さ」だ。SAPのnpm侵害ケースを掘り下げると、攻撃者は単純なtypo-squattingではなく、npmのtrusted publisher設定の運用ミスを突いている。@cap-js/sqliteは本来release-please.ymlからの公開のみを許可するはずが、設定上はcap-js/cds-dbsリポジトリの任意のワークフローを信頼**する状態になっていた。攻撃者は侵害した開発者クレデンシャルでワークフローを書き換え、OIDCトークンをnpmクレデンシャルへ手動で交換し、CIログ経由で持ち出した。

加えて、汚染パッケージはBunランタイムを正規のGitHubリリースURLからダウンロードして実行することで検出を回避し、.vscode/tasks.jsonを被害リポジトリに書き戻す自己拡散ギミックまで備えていた。GitHub Actions・GitHubリリース配布URL・npm trusted publisher・VS Code開発体験——すべてが同じ生態系の中で接続されていることが、この攻撃の伝播速度を生んでいる。

CVE-2026-3854も構造は似ている。babeld git proxyがX-Statヘッダーへのpush optionをセミコロンで区切って格納する際、ユーザー入力をサニタイズしていなかった——という単独の実装ミスが、マルチテナント構成と組み合わさって横断的なリポジトリ閲覧を可能にした。設計の単純なミスでも、集約されたインフラ上では「数百万リポジトリ規模」の影響に増幅される。

Ghostty離脱とForge連邦化 — 「分散」への揺り戻しは現実解か

Mitchell Hashimoto氏のエッセイは、技術論というより生産性と感情の決別表明だ。「ほぼ毎日GitHubの障害が仕事の妨げになっている」「PRレビューが2時間ブロックされた」という具体例を挙げつつ、Git本体ではなくIssues・PRs・Actionsといった「周辺インフラ」の信頼性こそが論点だと整理している。Ghosttyは段階的に依存を切り離し、現URLは読み取り専用ミラーとして残す方針だ。

これと連動して読まれているのがTangledの「Forge連邦化」提案だ。注目すべきはアーキテクチャ選択で、**コード転送はGit、イベント転送はAT Protocol（Blueskyの基盤）**という二層構造を採る。

[Knot A: Gitサーバ] ──Git──> [Knot B: Gitサーバ]
       │                         │
       └──── AT Protocol ────────┘
       (Issues / PRs / フォロー / スター)

ローカルのknot（Gitサーバ）でリポジトリをホストしつつ、Issue・PRといった協働イベントはAT Protocol経由で他knotへ伝搬する。クロスサーバへのPR送信はメール駆動開発の正統進化で、cgit + git format-patchを運用したことがあるエンジニアにはむしろ既視感のある設計だろう。

ただし連邦化には現実的な摩擦がある。ID・スパム対策・モデレーション・フォーク発見可能性といった、中央集権が暗黙に解決していた問題を再設計する必要がある。AT Protocolはアカウント可搬性とDIDによるID解決でこの一部に答えを出しているが、code reviewのUXやCIランナーの分散化は未解決領域だ。

エンジニアが今すぐ取るべき三つのアクション

「GitHubから移れ」と言いたいわけではない。むしろ、集中の便益を享受しつつ単一障害点リスクを減らす運用こそが現実的な解だ。具体的には三つ。

1. リポジトリのミラー戦略を引く — git remote add backupで別Forge（Codeberg、GitLab、自前Gitea/Forgejoなど）へ定期push。actions/checkoutから始まる依存ツリーが切れた瞬間、開発が完全停止することを避けられる。Hashimoto氏の「読み取り専用ミラー」はこの最終形だ。

2. CIサプライチェーンを「タグ参照禁止」へ移行 — SAPの事例で再確認されたが、Actions ワークフローでのuses: org/action@v1系のタグ参照は、攻撃者によるタグ書き換えで容易に乗っ取られる。uses: org/action@<commit-sha>への切り替え、Renovate/Dependabotでの自動pin更新、tj-actions系の組織ホワイトリスト化が三点セットになる。

3. trusted publisherとOIDC設定を月次で棚卸し — 「どのリポジトリのどのワークフローが、どのレジストリ/クラウドにOIDCで認証できるか」を一覧化する。SAPケースのようにワイルドカード信頼が残っていないか、特権のあるワークフローがmainブランチ限定になっているかを確認する。これは年次監査ではなく月次運用に組み込むレベルで効く。

加えて中期的には、Forge選定を「ロックイン度」で評価する視点を持つ価値がある。Issues/PRsデータのエクスポート可能性、CI設定の互換性（Forgejo Actionsがactions/互換を進めている）、依存パッケージレジストリの代替経路（npm + JSR、PyPI + 自前devpiなど）。

まとめ

4月最終週のGitHub関連インシデントは、障害・脆弱性・サプライチェーン侵害が同一プラットフォーム上で連鎖した点に新規性がある。
Ghostty離脱とForge連邦化提案は、感情論ではなく「単一障害点としての開発者インフラ」への構造的回答として読むべきだ。
AT Protocolを通信層に置くTangled型の連邦Forgeは、メール駆動開発の現代的再発明として現実味がある一方、UX・CI・モデレーションには未解決領域が残る。
エンジニアが今打てる具体策はミラー化・SHAピン留め・OIDC棚卸しの三点。集中の利便を捨てる必要はない。

「GitHubが落ちたら開発も落ちる」という状態を放置するか、復旧経路を用意しておくか。この一週間が問うているのはそこだ。