GitHub 2026 年 4 月可用性レポート：10 件のインシデントでサービス性能が低下

4 月、GitHub サービス全体のパフォーマンス低下を引き起こすインシデントが 10 件発生しました。 透明性を高めるため、4 月末に 4 月 23 日および 4 月 27 日の主要なインシデントを網羅したブログ記事を公開しました。また、GitHub ステータスページ（status page）により詳細情報を提供できるよう措置を講じています。 近未来および長期的な投資に取り組んでいる間、ご辛抱いただきありがとうございます。 4 月 1 日 15:02 UTC（継続時間：8 時間 43 分） 2026 年 4 月 1 日の UTC 14:40 から 17:00 の間、GitHub のコード検索サービスが完全に利用不可となり、検索クエリの 100% が失敗しました。サービスは UTC 17:00 に劣化状態（degraded state）で復旧し、一時的に古い結果が表示されましたが、UTC 23:45 には最新データを含む完全な復旧を果たしました。 完全に利用不可となった 2 時間 20 分の間、コード検索リクエストの 100% が失敗しました。UTC 17:00 の初期復旧後、検索結果は返されるようになりましたが、その日の UTC 約 07:00 以降にリポジトリで行われた変更を反映していませんでした。完全なインデックス処理は UTC 23:45 に追いつきました。 コード検索をサポートするメッセージングシステムへの通常のインフラストラクチャアップグレード中に、自動化された変更が過度に適用され、内部サービス間の調整失敗を引き起こしました。これにより検索インデックスの作成が停止し、検索結果が古くなり始めました。チームがメッセージングインフラの復旧に取り組んでいる間、意図しないサービスのデプロイによって内部ルーティング状態がクリアされ、古くなる問題が完全なアウトエージ（outage）へとエスカレートしました。 制御された再起動によりメッセージングインフラを復旧させ、サービス間の調整を再確立しました。その後、検索インデックスを障害発生前の時点にリセットしました。レポジトリデータが失われることはありませんでした。検索インデックスは Git レポジトリから派生した二次インデックスであり、Git レポジトリ自体には全く影響がありませんでした。再インデックス化が完了すると、すべての検索結果がレポジトリの現在の状態を反映するようになりました。 問題が連鎖する前に検出できるよう、より段階的なアップグレードと健全性チェック（ヘルスチェック）を追加しています。また、アクティブなインシデント中に意図しない変更が発生しないようデプロイ safeguards を導入し、サービスの復旧時間を短縮するための高速な回復ツールを備え、障害発生時の予期せぬトラフィックの急増による連鎖的な影響を防ぐためのより効果的なトラフィック分離を実現します。 4 月 1 日 16:06 UTC（継続時間：4 分） 2026 年 4 月 1 日の 15:34 UTC から 16:02 UTC の間、認証情報のローテーション失敗により、監査ログサービスがバックアップデータストアとの接続を失いました。この 28 分間の期間中、API と Web UI を通じて監査ログの履歴にアクセスできませんでした。その結果、4,297 人の API アクターと 127 人の github.com ユーザーで 5xx エラーが発生しました。さらに、この期間中に作成されたイベントは、github.com およびイベントストリーミングにおいて最大 29 分遅延しました。監査ログイベントが失われることはありませんでした。すべての監査ログイベントは最終的に正常に書き込まれ、ストリーミングされました。データ居住性を備えた GitHub Enterprise Cloud を利用している顧客には、このインシデントの影響はありませんでした。 インフラの障害については UTC 15:40 に検知され（発生から 6 分後）、影響を受けた環境をリサイクルすることで対応し、UTC 16:02 までに全サービスが復旧しました。今回のインシデントを受け、再発リスクの低減と検知能力の向上のため、いくつかのフォローアップ措置を実施しました。チームは、将来同様の障害を防ぎ、レジリエンスを高めるために、認証情報のローテーションプロセスを更新・強化しました。並行して、監視構成を改善し、ページング閾値をより敏感に設定することで、類似事象への検知速度とオペレータの可視性を向上させました。 UTC 4 月 9 日 09:50（25 分間継続）および UTC 16:20（4 時間 16 分間継続） 2026 年 4 月 9 日、UTC 09:05 から 19:05 の間と、UTC 16:05 から 20:36 の間に 2 つのインシデントが発生し、Copilot コーディングエージェントサービスが低下し、ユーザーは新しいエージェントセッションを開始する際に著しい遅延を経験しました。4 回の別々の停止波全体で、新しいエージェントセッションリクエストの約 84% が遅延し、キュー待ち時間がピーク時には 54 分に達しました（通常時のベースラインは 15〜40 秒）。平均的なエラー率は 83.9% で、サービスへのリクエストに対して最大 97.5% に達しました。インシデント中、約 22,700 のワークフロー作成が遅延または失敗しました。 これは、レート制限ロジックにバグがあり、制限をトリガーした個々のインストールにスコープを限定するのではなく、すべてのユーザーに対してグローバルに適用してしまったことが原因でした。寄与要因として、クライアントアップデートによる API トラフィックの急増があり、内部エンドポイントへのリクエスト数が 3〜4 倍に増加し、レート制限の枯渇が加速しました。2 つ目の同様のインシデントも、内部サービスが API レート制限を超えたことが原因であり、さらにキャッシュバグによってレート制限状態が実際の制限ウィンドウを超えて永続化してしまったことで、再発する障害を引き起こしました。 当チームは 15 分以内に問題を検知し、直ちに調査を開始しました。インシデントの緩和策として、機能フラグを介して誤ったレート制限キャッシュメカニズムを無効化し、サービスを更新して API 呼び出しにインストールごとの認証情報を使用するようにしました。これにより、レート制限が個々のインストールに対して正しくスコープされるようになりました。サービスは UTC 20:36 に完全に復旧しました。インシデント中に遅延していたジョブはキューに入れられ、サービス再開後に処理されました。 以降、この障害モードを事前に検知するための自動監視とアラートを追加し、キャッシュの改善を通じて不要な API トラフィックを削減する修正をデプロイしました。また、同様の問題を将来防止するために、クライアントタイプ間でのレート制限のスコープ分離をさらに強化する作業を継続しています。 4 月 13 日 UTC 19:56（39 分間継続） 2026 年 4 月 13 日、UTC 時間 18:53 から 20:30 の間、GitHub Pages サービスでエラー率が上昇しました。平均的なエラー率はリクエストの 10.58% で、ピーク時には 12.77% に達し、HTTP 500 エラーを返す約 1,750 万件のリクエストが失敗しました。 このインシデントは、自動化された DNS 管理ツール（DNS management tool）が、アップストリームのデータソースが一時的にレコードの取得に失敗した際、そのレコードを古くなったものとして誤って判断し、GitHub Pages のバックエンドストレージホストの DNS レコードを削除してしまったことが原因です。システム全体でキャッシュされたコピーの有効期限が切れると、GitHub Pages サーバーは影響を受けたストレージホストに到達できなくなり、一部のリクエストでエラーが発生しました。 問題が特定されると、チームは直ちに欠落した DNS レコードの特定を行い、再作成を行いました。サービスは UTC 時間 20:30 までに通常状態に戻り、インシデントは 20:35 までに完全に解決されました。エラー増加が漸進的であったことと、この種のエラーに対するアラート機能に隙があったため、検知に予想より長い約 53 分を要したことを認識しています。 私たちは将来同様の事態を防止するために、3 つの重要な改善を行っています。GitHub Pages フロントエンドに可用性ゾーン耐性ルーティングを実装し、解決不能なバックエンドホストが発生した際にエラーを返すのではなく健全なホストへのフェイルオーバーをトリガーするようにします。また、他のシステムが所有する DNS レコードの自動化された削除を防ぐためのセーフガードを追加し、GitHub Pages 配信パスにおける DNS 解決失敗に対するログ記録とアラート機能を強化しています。 2026 年 4 月 16 日 15:06 UTC（継続時間：3 時間 22 分） 2026 年 4 月 16 日の UTC 9:30 から 17:15 の間、VS Code エディタを介して GitHub Codespaces に接続しようとしたユーザーが障害を経験しました。この期間中、コードスペースの起動操作の約 40% が失敗しました。SSH を経由して接続したユーザーへの影響はありませんでした。 この問題は、コードスペース起動時に VS Code サーバーを取得できなくするアップストリームサービスの障害が原因でした。主要エンドポイントが劣化している場合に代替ダウンロードパスを使用するワークアラウンドを実装することで影響は軽減されました。並行して、ダウンロード失敗の根本原因に対処するため、アップストリームの依存関係チームと調整を行いました。 私たちは将来同様のアップストリーム障害の影響を低減するためにフォールバックメカニズムを改善し、同種の変更の展開を加速させるプロセスを合理化しています。 2026 年 4 月 20 日 13:28 UTC（継続時間：15 時間 36 分） 2026 年 4 月 20 日、UTC 時間 10:28 から 15:04 の間に、GitHub はコードスキャンのデフォルト設定、コード品質分析、およびプロジェクトボードにおいてサービスが低下しました。影響を受けたプロジェクトボードの復旧は、さらに UTC 時間 4 月 21 日の 05:04 まで続きました。 この間、新たに開かれたプルリクエストに対してコードスキャンのデフォルト設定とコード品質分析がトリガーされませんでした。また、新たに作成された課題（issues）はプロジェクトボードに表示されませんでした。 原因は、コードスキャン、コード品質分析、およびプロジェクトボードの更新を適切にトリガーできなくするシリアライズエラーでした。 私たちは約 40 分以内に問題を特定し、修正プログラムをデプロイして対応しました。これにより、コードスキャンとコード品質に関するイベント公開が復元されました。プロジェクトボードについては、イベントコンシューマーを更新するための追加のコード変更をデプロイし、影響を受けたプロジェクトアイテムの再インデックス化を行いました。 再発を防ぐため、スキーマ検証を強化し、重要なトピックにおける公開の低下に対する監視を改善しています。さらに、システム内の他の部分も監査し、同様の制限が他になくことを確認しています。 4 月 22 日 15:35 UTC（継続時間：3 時間 43 分） 2026 年 4 月 22 日、UTC 時間 15:16 から 19:18 の間に、github.com 上の Copilot Chat および Copilot Cloud Agent とのやり取りにおいてユーザーがエラーに遭遇しました。この間、ユーザーは Copilot Chat や Copilot Cloud Agent を使用できませんでした。Copilot Memory（プレビュー版）も、この期間中は Copilot エージェントセッションで利用不可でした。 この問題は、データベースとの接続に問題を引き起こすインフラ構成の変更によって発生しました。チームは原因を特定し、データベースへの接続を復旧させました。Copilot Chat および github.com 用の Cloud Agent は UTC 18:16 までに復旧しました。残りの地域デプロイメントは段階的に復旧され、完全な解決は UTC 19:18 に達成されました。 今後同様のインフラ構成変更がデータベース操作を引き起こさないよう、防止策を講じました。 4 月 23 日 16:12 UTC（継続時間：1 時間 18 分） 2026 年 4 月 23 日の UTC 16:03 から 17:30 の間、GitHub Copilot、Webhooks、Git Operations、GitHub Actions、Migrations、Deployments において、エラー率の上昇とパフォーマンスの低下がユーザーに報告されました。影響を受けたのは約 1 時間 27 分の期間で、全体のトラフィックの約 5〜7% が影響を受けました。Copilot の場合、AI モデルリクエストの約 7% が失敗し、Copilot Cloud Agent セッションの約 10% に影響があり、Copilot Insights ダッシュボードへのリクエストの約 9% でエラーが発生しました。Webhooks ではピーク時に API リクエストの約 0.35% でエラーが返され、最大でトラフィックの 10% が遅延（3 秒超）を経験しました。Git Operations はインシデント期間中平均して 1.25% のエラーがあり、ピーク時は 2.07% に達しました。GitHub Actions ではワークフローの実行ステータス更新に最大約 8 秒の遅延が発生しました。Migrations ではアクティブなリポジトリ移行の 0.88% が失敗し、79% で実行時間の増加が見られました。Deployments はインシデント期間中一時的にブロックされました。 あるデータセンターの DNS インフラストラクチャが劣化状態に入り、サービスアドレスの解決を断続的に失敗し始めました。これにより連鎖的な影響が発生し、内部 API や外部プロバイダー、ストレージシステムとの通信に名前解決を依存するすべてのサービスで同時にエラーが発生しました。 根本原因は、成長に対応するために段階的に展開された最近導入されたトラフィック分散メカニズムでした。特定の負荷パターン下でこのメカニズムが DNS リゾルバの失敗を引き起こしたのです。既存の DNS キャッシュが部分的な保護を提供しており、最近キャッシュエントリを保持しているサービスは通常通り稼働し続けたため、全体の影響は完全な停止ではなく約 5〜7% のトラフィックに限定されました。 初期の設定ロールバックでは問題が解決しなかったため、影響を受けた DNS インフラストラクチャを再起動しました。サービスは数分以内に回復を開始し、17:30 UTC までにすべて通常状態に戻りました。データの損失はなく、すべてのリポジトリ、データベース、ワークフローデータに影響はありませんでした。 将来同様のインシデントを防止するため、DNS インフラの耐障害性を強化し、単一データセンターでの障害がサービス全体に連鎖するのを防ぎます。また、本番環境に近いトラフィックに対してインフラ変更を検証するための専用環境を導入して、より安全なロールアウトと検証を実施します。さらに、DNS 解決失敗に対する自己修復メカニズムを備えた高速な自動検出と復旧への投資を行い、共有インフラコンポーネント上のサービス依存関係をレビューすることで、影響範囲（ブラスト・レイジ）を縮小します。 2026 年 4 月 27 日 16:31 UTC（継続時間：6 時間 15 分） 2026 年 4 月 27 日の UTC 16:15 から 22:46 の間、GitHub の検索サービスは、検索インフラの手前に展開されたロードバランシング層の飽和により接続性が低下しました。これにより、Issues（課題）、Pull Requests（プルリクエスト）、Projects（プロジェクト）、Repositories（リポジトリ）、Actions（アクション）、Package Registry（パッケージレジストリ）、Dependabot Alerts（依存関係アラート）など、検索データに依存するサービスで断続的な障害が発生しました。影響は検索対象によって異なり、UTC 16:15 から 18:00 の間に検索の最大 65% がタイムアウトするかエラーを返す状況となりました。 継続的なモニタリングを通じて検索結果の低下を検知し、UTC 16:21 にインシデントを宣言しました。このインシデントは UTC 21:33 までに緩和されたと記録し、システムを監視して UTC 22:46 にインシデントが解決されたことを宣言しました。 飽和状態は、公開 API のレート制限を回避するように設計された、大規模な匿名分散スクレイピングトラフィックの流入によって引き起こされました。このスクレイピングトラフィックは当日の検索トラフィック全体の 30% を占めていましたが、その大部分が 4 時間の期間に集中していました。トラフィックは 60 万を超える一意の IP アドレスから発生しており、すべてのリクエストで一致するアクター情報が確認できました。既存の監視システムはこのスクレイピング増加をリスクとして分類しておらず、このインシデントの側面は緩和措置を講じている最中に初めて発見されました。 緩和策として、私たちは即座にロードバランサーへの負荷軽減に注力すると同時に、ロードバランシング層のスケーリング作業を行い、異常なトラフィックをブロックしてバランサーのチューニングを適用し、インシデントを完全に解決しました。 今後に向けて、ロードバランサー層のスケーリングだけでなく、接続処理と再利用の最適化も実施し、このような飽和イベントが再発する可能性を低減させました。また、登録ユーザーへの影響を緩和するために匿名トラフィックを制限できる新しいモニターと制御機能をプラットフォーム内に追加しました。私たちは引き続き、この種の大規模な自動化された悪用に対する防御体制の強化を進めています。 ステータスページをフォローして、ステータス変更やインシデント後の要約に関するリアルタイム情報を入手してください。私たちが取り組んでいる内容の詳細については、GitHub Blog のエンジニアリングセクションをご覧ください。 本記事「GitHub availability report: April 2026」は、The GitHub Blog に最初に投稿されました。

GitHub 2026 年 4 月可用性レポート：10 件のインシデントでサービス性能が低下

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

関連記事

調べる

選ぶ

サイト