コンテンツにスキップ

GitHub障害が相次ぐ2026年、いま取るべき対策と代替フォージの現在地

先に実装する順序

2026年8月17日のGitHub障害は7時間47分続き、Web/APIのピークエラー率は約20%、archiveとraw contentのdownloadは約50%に達した。1 GitHub障害への備えは、別フォージへの全面移行より先に、独立した復元経路とCI/CDの可搬性を作る。

技術リーダーの判断いま実装すること
コードを失わず作業を続けるオフサイトGit bundleまたは別remoteを定期検証する
緊急リリースを止めないGitHub外から起動できるCIまたは手動手順を保つ
依存取得を止めないproxy cacheと別registryからの復元を試す
代替フォージを評価する非重要repositoryでexportと復元まで試す

GitHub障害への備えをGit復元、CI可搬化、依存分離、代替フォージ検証の順に示す図

Status記録は単発事故ではない

GitHub Status APIには、同月初日からこの大規模障害までに15件のincident記録があるが、Copilotのmodel provider障害など軽微な記録も含むため、すべてをGitHub全体の停止と数えるのは誤りだ。 本稿ではこの異質な記録群を、GitHub全体が常時不安定だという証明ではなく、repository、Pull Request（PR）、Actions、認証、AI支援のどこかが利用できない場合を訓練するためのrisk signalとして扱う。2

ローカルGitは障害中の開発を継続できる

GitHubが利用できなくても、commit、branch作成、merge、diff、履歴参照、conflict解消はローカルGitで完結する。 障害時の開発ルールは「commitを止める」ではなく、「共有とreleaseを保留し、復旧後にpushする」でよい。

git switch -c outage/work
git status
git diff
git log --oneline
git commit

ただし、手元のcloneだけをbackupとは呼べない。 開発端末の故障、未取得branch、Git LFS object、Issue、PR comment、release asset、Actions secretは別問題である。 チームは「Git objectを復元する手順」と「GitHub固有dataを復元する手順」を分けて持つ必要がある。

Gitの復元経路は別remoteかbundleで作る

最小の復元経路には、独立した保管先へのremoteと、offlineで検証できるGit bundleが使える。

git remote add mirror <secondary-remote-url>
git push mirror --all
git push mirror --tags

git bundle create repository.bundle --all
git bundle verify repository.bundle

Git公式文書は、複数のpush URLを同じremoteへ設定する場合、push直後に同じ内容をfetchできる同一地点を指すべきだと説明している。 別フォージをoriginの追加push先に混ぜるより、mirrorのような別remoteとして成否を監視する方が、片側だけ成功した状態を検出しやすい。3

Git bundleは全refから到達できるobjectを一つのfileへ保存し、verifyとcloneで復元性を試せる。 ただし、working tree、index、stash、hook、repository設定は含まれない。4 backup jobの成功ではなく、隔離環境でcloneして既定branchとtagを確認できた時点を復旧可能と判定する。

保管先は、GitHubと同じ認証、同じcloud region、同じsecret storeへ依存しない構成にする。 異なるcloud名を選ぶだけでは障害domainは分かれないため、identity、DNS、network、artifact、deploy先まで依存関係を図にする。

セルフホストActionsだけでは退避経路にならない

GitHubのセルフホストランナーはActionsの制御面に依存するため、単独では退避経路にならない。 runner applicationはGitHubへ接続してjobを受け取る設計であり、Actionsのqueueやworkflow起動が止まれば、自社host上のrunnerも新しいjobを受け取れない。5

GitHub外から起動できるexternal CIまたは手動releaseを退避経路にする。

緊急releaseを残すには、次のどちらかを実際に動かしておく。

  • 外部CI：GitHub以外のtriggerとcontrol planeから、同じcontainer、test、deploy commandを実行する
  • 文書化した手動release：署名、承認、rollback、監査記録を省略せず、operatorがGitHub外から起動する

workflowの中身もGitHub Actions専用syntaxへ閉じ込めない。 buildとtestはrepository内のscriptやtask runnerへ寄せ、Actionsはそれを呼ぶ薄いadapterにする。 container image、package、SBOM、release artifactはGitHub Packagesだけに置かず、別registryまたはobject storageへ複製し、restoreを試す。

raw contentとstatus監視を分離する

build中にraw.githubusercontent.com、GitHub Releases、特定action repositoryから直接downloadする構成は、source codeが手元にあっても上流障害で止まる。 NexusやArtifactoryなどのproxy cache、社内registry、固定checksum付きのvendor directoryを経由させると、上流停止と供給網改ざんの両方を切り分けやすい。

GitHub StatusはAtomとRSSを提供している。6 監視通知に取り込み、自社deploy失敗とGitHub側incidentを同じtimelineで確認できるようにする。 Status通知は復旧策ではないが、原因不明の調査を早く打ち切る判断材料になる。

負荷増加をGitHubは構造課題として扱っている

今回のincidentの直接原因は、Central USでload balancerのnetworkが飽和し、service mesh sidecarのautoscaling設定が追従しなかったことだった。 retryが負荷を増幅し、複数serviceへ影響が波及した。1 「AI agentがこの障害を直接起こした」とはGitHubは説明していない。

一方、GitHubはagentic workflow、repository作成、PR、API、automation、大規模repositoryが急増し、容量設計を拡大する必要が生じたと公表している。 同社はGitとActionsの分離、単一障害点の削減、blast radiusの縮小、将来のmulti-cloud化を進めている。7

したがって、今回の障害を「AI agentが直接起こした」と一般化するのは正確ではない。 GitHubが説明する成長負荷への長期対策と、8月17日の直接原因は分けて評価する必要がある。 利用者側の対策は、GitHubの改善完了を待つことではなく、自社の復元時間と依存境界を管理することになる。

代替フォージは要件別に現在地が異なる

代替フォージはOriginを限定検証し、現行移行先はGitLab、Bitbucket、自社運用のForgejoを要件別に選ぶ。

候補現在の強み移行前に確認する境界
Cursor OriginEarly Betaでrepository、PR、code browsing、GitHub sync、agent連携を試せるmirrorではGitHubが正本で、Issues、Actions workflow、secretは移らない
GitLabSaaS、Dedicated、Self-Managedを選べ、push/pull mirrorを公式に備える双方向mirrorのconflict、CI、Issue、PR履歴、registryの移送を実地確認する
BitbucketCloudのPipelinesとAtlassian製品連携、Data Centerのself-managed構成があるActions workflowの変換と、Jira、identity、artifactを含むAtlassian依存を確認する
Forgejocodeとcontrol planeを自社の障害domainへ置けるdatabase、object storage、runner、upgrade、security responseを自社で運用する

Originは全有料plan向けのEarly Betaとして公開され、GitHub repositoryを同期したままcode browsing、PR、Cursor agentを利用できる。8 ただし、GitHubで始めたrepositoryはGitHubが正本であり、pushもGitHubへ流れる。 Issues、Actions workflow、secretはmirror対象外なので、GitHub障害の完全なfailoverではない。9

GitLabは外部repositoryとのpush/pull mirrorを公式に提供するが、双方向同期にはconflictの注意を明記している。10 BitbucketはCloudとData Centerを持ち、CloudではPipelinesを統合する。11 Forgejo Actionsはrunnerを別途用意し、GitHub Actionsに似た記法を使えるが、公式文書は互換を保証していない。12

代替フォージは障害耐性を自動では生まない

本稿は各forgeの長期可用性を同一条件で実測していない。 GitLab.comやBitbucket Cloudへ移すだけではSaaSの集中先が変わり、Forgejoをself-hostすれば運用責任が自社へ移る。 Originには本番運用の長期履歴と企業統制を比較できる公開材料がまだ少ない。 公式資料から復元設計の境界は確認できるが、各forgeの相対可用性は同条件で実測していないため、比較の確度は中程度である。

移行判断では、機能表より先に次を確認する。

  • Code custody：保存地域、暗号化、管理者access、subprocessor、契約終了時のexport
  • Identity：SAML/OIDC、SCIM、emergency access、認証provider停止時の復旧
  • Review data：Issue、PR、comment、approval、branch protection、audit logの移送
  • Delivery：runner、secret、OIDC、registry、artifact、environment approvalの再現
  • Exit test：代表repositoryをexportし、別環境でclone、build、releaseまで完了できるか

評価の主語は「GitHubより速いか」ではなく、「許容時間内に自社のreleaseを復元できるか」である。 vendorのthroughput demoはagent負荷への設計意図を示しても、SLA、data durability、incident response、review品質を証明しない。

現時点ではGitHubを使いながら出口を作る

全面移行を先に決める必要はない。 GitHubのnetwork effect、OSS contribution、Actions ecosystemを維持しながら、障害時にGitHubなしでcodeを復元し、testとdeployを起動できる状態を作る方が先である。

実装順は明確だ。

  • Platform teamが、別remoteまたはbundleの復元testとGitHub固有dataのexportを担当する
  • CI ownerが、repository内の共通build scriptとGitHub外の起動経路を担当する
  • Security teamが、mirror先のcode custody、identity、audit、exit条件を承認する
  • Pilot teamが、非重要repositoryで候補forgeのimportとexportを往復検証する

Originの正式機能や企業統制が固まれば、候補比較は更新できる。 それまでは「GitHubを捨てるか」ではなく、「GitHubがなくても復元できるか」を運用指標にする。

この記事をポスト リンクをコピー

関連記事

出典

  1. GitHub Status API「Incident with GitHub.com」（incident ID: zkxwbgr0cnmx）。影響時間、対象service、peak error率、直接原因、retryによる増幅を確認した。 ↩↩

  2. GitHub Status incidents API。公開時点のstarted_atが同月初日から大規模障害までに入るrecordを集計した。minorを含むStatus record数であり、全件をGitHub.com全体停止とは扱っていない。 ↩

  3. Git「git-remote Documentation」。push URLとfetch URLの意味、別地点へpushする場合の別remote利用を確認した。 ↩

  4. Git「git-bundle Documentation」。full backup、verify、clone、含まれないlocal stateを確認した。 ↩

  5. GitHub Docs「Self-hosted runners reference」。runner applicationがGitHubへ接続してjobを受け取る条件を確認した。 ↩

  6. GitHub Status。Atom FeedとRSS Feedの提供を確認した。 ↩

  7. GitHub「An update on GitHub availability」（2026年4月28日）。agentic workloadの増加、service分離、単一障害点の削減、multi-cloud方針を確認した。 ↩

  8. Cursor「Origin Code Hosting」（2026年8月17日）。Early Beta、有料plan、repository、PR、GitHub sync、agent連携を確認した。 ↩

  9. Cursor Docs「Mirror a GitHub repository」。同期対象、除外対象、GitHubが正本である条件、detach後の扱いを確認した。 ↩

  10. GitLab Docs「Repository mirroring」。提供形態、push/pull mirror、双方向同期のconflict注意を確認した。 ↩

  11. Atlassian「A brief overview of Bitbucket」、Bitbucket Pipelines。Cloud、Data Center、integrated CI/CDの範囲を確認した。 ↩

  12. Forgejo Docs「Forgejo Actions」。runner分離、workflow配置、GitHub Actionsとの非互換境界を確認した。 ↩