GitHub 可用性レポート：2026 年 5 月

3 月と 4 月に、GitHub の可用性およびインフラ投資に関する更新情報を共有しました。その取り組みは継続しており、主要なマイルストーンに近づいていることから、今後は毎月の可用性レポートでより定期的な更新情報を提供していくことにします。5 月のインシデントの詳細に入る前に、GitHub をより信頼性の高いものにするための継続的な取り組みにおける進捗状況をご紹介します。 GitHub のレジリエンス向上に向けた進捗 要約すると：AI 支援型およびエージェント型の開発ワークフローに牽引され、GitHub のトラフィックは急速に増加しており、これに対応するためにインフラの転換を進めています。具体的には、弾力的なキャパシティを実現するために Azure への移行、モノリシックアーキテクチャを分離されたサービスへと分解し、過去のインシデントを引き起こしてきた共有障害ポイントの排除を行っています。 現在の状況は以下の通りです。現在、モノリシックトラフィックの 40% を Azure で処理しており（2 月は 8%）、Git トラフィックは 30%、リポジトリレプリケーションは 99% に達しています。有効キャパシティは 4 ヶ月間で倍以上に増加しました。同時に、主要なデータベースクラスターの分離も完了しつつあり、ユーザー、認証、認可を独立したドメインに分割することで、ある領域での問題がプラットフォーム全体に連鎖するリスクを排除しています。新しいユーザーサービスは完全に移行が完了し、トラフィックは 2 倍処理しながらも、大幅に低いデータベースコストで運用されています。また、ステートレスな認証トークンの展開も進んでおり、トラフィックの急増時に圧力を増幅させていたリクエストごとのデータベース参照を排除しています。 私たちは、永続的に障害モードを除去する構造的変更を行っています。取り組むべき課題があることを認識していますが、それを完了し、必要な時に必要な場所で GitHub が信頼できるようにすることにコミットしています。私たちの判断の根拠となる原則はシンプルです：可用性、次に容量、そして機能です。 GitHub の信頼性と回復力を構築し続ける中で、ご協力いただきありがとうございます。 5 月には、GitHub サービス全体のパフォーマンス低下を招くインシデントが 9 件発生しました。 5 月 4 日 15:45 UTC（継続時間 55 分） 2026 年 5 月 4 日、UTC 時間で 15:34 から 16:40 の間に github.com でサービス障害が発生し、広範な顧客向けサービスにおいてレイテンシの上昇とリクエスト失敗率の増加が引き起こされました。顧客への影響は合計で約 1 時間 6 分続きました。 最も深刻な影響を受けたのはプルリクエスト（Pull Requests）であり、ピーク時の影響期間中ずっとステータスが「Red」と表示されていました。Issues、Actions、Webhooks、Git オペレーションではレイテンシの上昇と断続的なエラーが発生しました。また、Codespaces、Pages、Packages、OAuth、GitHub Apps、Marketplace、Copilot といった多くの依存サービスも、共有データへの依存関係により、不同程度的なパフォーマンス低下を経験しました。ピーク時には約 1.3% のリクエストが 5xx レスポンスを返し、インシデント全体を通じて平均すると約 0.46% となりました。 この障害は、大規模かつ頻繁にアクセスされるデータベーステーブルに対して実行された通常のオンラインスキーママイグレーションによって引き起こされました。マイグレーションは数時間にわたり問題なく進行していましたが、週次ピークに向けてトラフィックが増加するにつれ、マイグレーションと通常のプロダクショントラフィックの負荷が組み合わさり、データベース接続容量を飽和させました。これにより、プライマリデータベースでクエリ競合が発生し、それに依存するサービス全体に連鎖的なタイムアウトが生じました。 影響の最初の兆候から約 3 分以内に、自動化された監視とオンコール担当者の観察を組み合わせた結果、このインシデントが検知されました。原因となったマイグレーションが特定されると即座に一時停止され、依存するサービスは直後に回復しました。緩和までの所要時間は約 33 分で、完全な解決にはさらに約 30 分かかりました フォローアップとして、同様の事象の発生確率と影響範囲を縮小するため、いくつかの改善策を実装しています。大規模かつ高トラフィックのテーブルに対するマイグレーションは、低トラフィックの時間帯により厳密に合わせるようになり、ライブクラスタ負荷に応じて動的にスロットリングを行うようになります。また、基盤となるデータベースのレイテンシや接続利用率が安全閾値を超えた際に、進行中のマイグレーションを一時停止する自動的なサーキットブレーカーを追加し、移行による圧力（すなわち書き込みレート、ロック時間、接続飽和）が顧客への影響が発生する前にアラートを発令できるよう監視機能を拡張しています。並行して、マイグレーション実行中に十分な余裕が維持されるよう、接続プールの容量を見直しています。 5 月 05 日 13:37 UTC（継続時間：3 時間 49 分） 5 月 06 日 07:19 UTC（継続時間：2 時間 25 分） 5 月 5 日および 5 月 6 日に、GitHub Actions はホストランナーに影響を与える 2 つの関連するインシデントにより機能低下が発生しました。この 2 つの事象は相互に関連しており、5 月 5 日のインシデント後の復旧作業で導入された設定不備が、5 月 6 日のインシデントを引き起こすトリガーとなりました。 2026 年 5 月 5 日、UTC 時間 13:22 から 17:05 の間、GitHub Actions が提供するホストランナーが米国東部リージョンで性能低下を起こしました。標準ランナーを要求したジョブの約 13.5% が失敗し、米国東部に固定されたプライベートネットワーク機能を備えた大型ランナーの要求では約 16% が失敗するか、5 分以上遅延しました。Copilot のコードレビューリクエストも影響を受けました。この期間中に約 8,500 件のコードレビューリクエストがタイムアウトしました。影響を受けたユーザーはプルリクエストにエラーコメントが表示され、レビューを再依頼することで再試行が可能でした。ほとんどのランナー要求は他のリージョンによって自動的に引き継がれましたが、依然として米国東部へルーティングされる一部の要求には影響が残りました。 これは米国東部リージョンにおけるホストランナー VM のスケールアップ操作に起因するものです。この操作自体は定期的に行われるものですが、VM 作成時の負荷がストレージからのイメージ取得時に内部レート制限に達しました。この場合のレスポンスコードにより、既存のバックオフロジックが発動しませんでした。レート制限と VM 作成の失敗は、回復を可能にするために負荷を軽減し、キューされた作業の処理を許可することで緩和されました。UTC 時間 15:34 までに、キューされていたジョブや失敗したジョブの割り当ては主に解消され、15:34 から完全復旧となる 17:05 の間、ランナー割り当てへの影響は 0.5% 未満となりました。 2026 年 5 月 6 日、UTC 時間 06:45 から 09:15 の間、GitHub Actions の標準 Ubuntu ホストランナーが再び劣化し、標準ランナーを要求したジョブの約 17.1% が失敗しました。この問題は、前日のインシデントに対する修復作業中に導入された予期せぬ設定データが原因で、日中の負荷が増加するにつれて新しい割り当てがブロックされたことによるものです。問題のあるデータは UTC 時間 08:51 に削除され、割り当ての再開とランナープールの拡大および回復が可能となりました。 私たちは、制限が発生した際のシステムのスロージング（速度制御）動作を改善し、同様の状況をより迅速に緩和するための制御を強化し、類似のオペレーションに関するすべての制限をエンドツーエンドで見直す取り組みを行っています。さらに、この割り当てデータに対するフィルタリングロジックを更新して異常なデータ形状に対して耐性を持たせ、割り当てがブロックされた際にアラートが鳴るよう監視を改善することで、顧客への影響が始まる前にチームが対応できるようにします。 5 月 6 日 UTC 11:21（38 分間継続） 2026 年 5 月 6 日、UTC 時間 11:02 から 11:13 の間、ユーザーは Copilot クラウドエージェント（Copilot cloud agent）やリモートセッションを開始または表示することができませんでした。この期間中、セッション API へのすべてのリクエストがエラーを返し、新規セッションの作成や既存セッションの閲覧が阻止されました。この問題は、サービスのネットワークルーティングに対する設定変更により、意図せずしてサービスのイングレスパス（ingress path）が削除されたことが原因でした。チームは UTC 時間 11:13 にその変更を元に戻し、サービス復旧を果たしました。完全な回復を確認するまで、このインシデントは UTC 時間 11:59 まで継続しました。今後、同様の設定変更が生産トラフィックに影響を与えないよう、デプロイメント検証プロセスの改善に取り組んでいます。 2026 年 5 月 6 日 UTC 15:25（3 時間 39 分間継続） 2026 年 5 月 6 日、UTC 時間 15:12 から 19:02 の間に、github.com における新規プルリクエストレビュースレッドの作成に失敗しました。これには、プルリクエストに対する新規行コメントおよびファイルコメントが含まれます。既存のプルリクエストや以前に作成されたコメントへの影響はありませんでした。 このインシデントは、プルリクエストスレッド作成時に使用される Vitess ルックアップテーブル内の 32 ビット整数キーが最大値に達したことが原因でした。プライマリテーブルは 64 ビット整数キーへ移行されましたが、Vitess ルックアップテーブルは 32 ビットのまま残っていました。プライマリテーブルの値が利用可能な 32 ビット ID スペースを超えたことで、新しいレビュースレッドの作成試行が失敗し、結果として新規スレッド作成リクエストのほぼ 100% が失敗する事態となりました。この問題は、影響を受けたすべてのシャードにおけるルックアップテーブル定義を 64 ビット整数カラムタイプへ更新して利用可能な ID リンジを増やし、正常な運用を回復させることで緩和されました。スキーマ変更がグローバルに完了した時点でサービスは完全に復旧しました。 同様のインシデントを防ぐため、データベースカラムの既存監視を Vitess ルックアップテーブルにも拡大し、いずれのカラムサイズ制限に近づいているテーブルについても早期検出を可能にする措置を講じています。 5 月 7 日 05:02 UTC（継続時間：1 時間 54 分） 2026 年 5 月 7 日の 04:12 から 06:13 UTC の間、Copilot cloud エージェントおよび Copilot コードレビューエージェントのセッションがプルリクエストに対して遅延したり、開始できなかったりしました。 影響を受けた期間中、プルリクエストによってトリガーされた新しい Copilot コーディングエージェントセッションは作成されず、レビューエージェントセッションはベースラインから約 50% 減少しました。 この問題は、別のプルリクエストインシデントからのフォローアップ復旧作業に起因していました。その復旧の一環として大規模なデータベースマイグレーションを実行した結果、いくつかのレプリカホストでレプリケーション遅延が発生しました。 これらのレプリカはユーザートラフィックを処理していませんでしたが、安全装置が正しく機能し、増大したレプリケーションラグを信号として検知して、影響を受けたデータベースクラスターへの書き込み速度を低下させました。その結果、一部のプルリクエストのバックグラウンド処理が一時的に遅延しました。この処理は Copilot エージェントが作業を開始するために使用する内部イベントを送信する役割を担っているため、影響を受けたエージェントはデータベースレプリカが追いつくまで起動しませんでした。 システムはレプリケーションラグが正常値に戻り、プルリクエストの処理が再開されたことで復旧しました。現在、バックグラウンド処理の耐性を高めており、レプリケーションラグに対してより堅牢に動作させ、負荷下でも重要なイベントの流れを維持して、将来の復旧作業中に同様の二次的な影響が発生する可能性を低減しています。 5 月 15 日 08:13 UTC（継続時間：35 分） 2026 年 5 月 15 日、UTC 時間 07:43 から 08:48 の間、GitHub Actions で障害が発生し、一部の顧客においてワークフローの実行が失敗したり、開始が遅延したりしました。このインシデントは、GitHub Actions が使用するサポート用インフラの計画的なフェイルオーバー（切り替え）によって引き起こされました。その操作中に、自動化されたサービスディスカバリの更新が正しく伝播せず、トラフィックが誤ってルーティングされる結果となり、ワークフローオーケストレーションの中核となる依存関係においてリクエストタイムアウトが増加しました。 最大影響時には、Actions の実行の 42% が失敗しました。Actions ワークフローの実行に依存する下流サービスも影響を受け、GitHub Pages や Copilot クラウドサービスが含まれていました。UTC 08:12 にレスポンダーが手動でサービスディスカバリのルーティング問題を修正しました。タイムアウトと失敗率は直後に回復し、影響を受けたすべてのサービスで完全な安定化が確認されるまで監視を継続しました。インシデントは UTC 08:48 に解決済みとしてマークされました。 再発防止のため、私たちはいくつかの措置を講じています。まず、フェイルオーバー操作を完了する前にサービスディスカバリの状態を検証するフェイルオーバーガードレールを実装します。次に、検証チェックを強化します。最後に、インフラストラクチャイベント発生時のタイムアウトのカスケード（連鎖）を減らすために依存関係のレジリエンスを向上させます。 5 月 26 日 10:57 UTC（継続時間：2 時間 21 分） 2026 年 5 月 26 日、UTC 時間 10:40 から 12:56 の間に、GitHub Actions のジョブに障害が発生しました。UTC 時間 10:40 から 12:16 の間は、新たにキューされたすべての実行が開始されませんでした。UTC 時間 12:16 から 12:56 の間は、ワークフローでアクションのダウンロードを必要とする実行が引き続き失敗しました。GitHub Pages、Copilot コードレビュー、Copilot コーディングエージェント、Octoshift、および GitHub Enterprise Importer も、GitHub Actions への依存関係により影響を受けました。 これは、GitHub Actions がワークフローの実行を認証し、アクションをダウンロードするために使用するサービスアカウントを、自動化されたアカウント審査システムが誤って停止させたことが原因です。 対策として、UTC 時間 12:16 にアカウントを復元し、12:20 にさらに自動審査の対象外とマークし、キャッシュされたアカウント状態をクリアするために関連するサービスを 12:48 に再デプロイしました。完全な回復は UTC 時間 12:56 に確認されました。 今回のインシデント中、サービスアカウントが無効化された際に、少数の課題（issues）、プルリクエスト、コメント、およびディスカッションが非表示としてマークされました。データが失われることはありませんでした。このインシデントのために非表示にされていたすべてのコンテンツは復元され、完全な検索インデックスの復元も完了しました。 再発を防ぐため、自動化システムによって停止できないすべてのサービスアカウントをホワイトリストに登録し、これらの保護措置がすべてのアカウント管理ツールで一貫して適用されるようにしました。また、アカウント用の診断ツールの改善とキャッシュ伝播遅延の短縮を行い、将来的に同様のインシデントが発生した際の対応時間を短縮することを目指しています。 5月28日 19:01 UTC（1時間40分間継続） 2026年5月28日の18時27分から20時41分の間、GitHub Copilot サービスが、上位プロバイダーのResponses API の不具合により低下しました。この影響はGPT-5.2、GPT-5.3-Codex、GPT-5.4、およびGPT-5.5モデルに及んでいます。Responses API を経由してこれらのモデルへルーティングされたリクエストでエラー率が上昇し、Copilot コーディングエージェントやCopilotコードレビューにも影響が出ました。他のモデルへの影響はありませんでした。 私たちは、上位プロバイダーが修正を適用している間、影響を受けたモデルからのトラフィックを迂回させることで事態を収束させました。 GitHub は、影響を受けたモデルに対する自動フェイルオーバーの改善と、同様の事象を防ぐための監視強化に取り組んでいます。 ステータスページで、ステータス変更に関するリアルタイム更新や事後報告をご覧ください。私たちが取り組んでいる内容の詳細については、GitHub Blog のエンジニアリングセクションをご参照ください。 本記事「GitHub availability report: May 2026」は、The GitHub Blog に最初に投稿されました。

GitHub 可用性レポート：2026 年 5 月

背景や根拠まで確認しますか？

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

ニュースの次に確認する

調べる

選ぶ

サイト