GitHub 2026年6月可用性レポート解説｜6件の障害と対応要否

2026年7月9日時点で確認できるGitHub公式情報では、2026年6月にGitHub platformで6件の性能劣化インシデントが発生しました。GitHub Blog上の公開日表記は2026年7月8日です。(The GitHub Blog)

結論から言うと、「GitHub publishes its June 2026 availability report covering six degraded-performance incidents」は、新機能の提供開始やAPIの破壊的変更を知らせるアップデートではありません。既存のGitHub API、GitHub Actions、Webhookを一律に修正する必要はなく、移行作業や追加契約も不要です。

ただし、単発の401エラーでユーザーをログアウトさせる実装、匿名アクセスでGitHub Releasesに依存するワークフロー、Webhookの遅延を想定していないシステム、特定のGitHub Copilotモデルだけを前提にした業務フローは見直す価値があります。本記事では、6件の障害内容だけでなく、仕様差分、既存実装への影響、対応要否、テスト時の注意点まで具体的に整理します。

GitHub 2026年6月可用性レポートの結論

今回のGitHub 2026年6月可用性レポートを、利用者側の対応という観点で整理すると次のようになります。

確認項目	結論
アップデートの種類	月次の障害報告と内部基盤の改善状況
APIやActionsの仕様変更	レポート内に変更告知なし
必須の移行作業	なし
既存実装との互換性	原則として維持される
見直しを推奨する領域	APIの401・5xx処理、Actionsの再実行、Webhookの遅延対策、Copilotのモデル切り替え
一般利用者の対応	GitHub Statusの通知設定を行えば十分
システム管理者の対応	障害時の再試行、重複防止、代替経路をテストする

本件を単に「GitHub platformのAI更新」と分類するのは正確ではありません。6件のうち3件はGitHub Copilot関連ですが、残り3件はgithub.comの匿名アクセス、REST・GraphQL APIの認証、バックグラウンドジョブに関する障害です。AI機能だけでなく、CI/CDや外部連携を含むGitHub platform全体の運用課題として捉える必要があります。(The GitHub Blog)

6件の性能劣化インシデントを日本時間で整理

公式レポートのUTC表記を日本時間に換算すると、6件のインシデントは次のとおりです。

発生日時・日本時間	継続時間	主な対象	利用者への影響
2026年6月5日 2時30分	1時間25分	Copilot code review	コードレビュー要求の平均81.6％、最大93.9％が失敗
2026年6月8日 15時30分	2時間6分	未ログイン状態のgithub.com、関連するActions	対象リクエストの約17％で504、ピーク時は約34％
2026年6月11日 0時5分	1時間20分	REST API、GraphQL API	約9％で認証失敗が発生し、誤った401を返却
2026年6月17日 2時20分	55分	CopilotのOpus 4.8	一部リクエストが失敗
2026年6月17日 12時50分	54分	Copilotの複数のチャットモデル	モデルが選択画面から消える、または利用不可エラー
2026年6月26日 2時33分	23分	PR、push、Actions、Webhook	バックグラウンド処理が最大7分遅延

数値、継続時間、原因はGitHubの公式レポートに基づいています。(The GitHub Blog)

Copilot code reviewの依存関係更新で大量のレビューが失敗

6月4日17時30分から18時55分までのUTC時間帯に、github.com上のCopilot code reviewで障害が発生しました。

障害時間中は平均81.6％、ピーク時には93.9％のレビュー要求が失敗し、失敗件数は約3万6,800件です。影響を受けたPull Requestでは、「Copilot ran into an error」と表示されました。GitHub Enterprise Cloud with data residencyは、この障害の影響を受けていません。(The GitHub Blog)

原因は、Copilotのレビュー処理で使用していた依存コンポーネントの新しいリリースです。処理環境との互換性が不十分なバージョンを自動的に取り込んだため、レビュー処理が開始できなくなりました。さらに、一部のジョブが即時に失敗せず、タイムアウトまで動作し続けたことで復旧後も処理が残りました。

GitHubは再発防止策として、依存バージョンの固定、互換性チェック、早期失敗の改善、タイムアウト短縮、監視強化を挙げています。(The GitHub Blog)

利用者側でGitHubの内部依存関係を変更する必要はありません。ただし、Copilot code reviewをマージ判断の唯一の条件にする運用は避けるべきです。レビューに失敗した場合は、人によるレビューへ切り替えるか、復旧後に再実行するルールを決めておきましょう。

匿名アクセスへの集中で504エラーが発生

6月8日の障害では、未ログインの利用者がPull Request、Issue、Release、パッチ差分などを開いた際に、HTTP 504エラーが発生しました。

影響を受けた対象への匿名リクエストのうち、平均約17％がタイムアウトしました。ピーク時は約34％です。Releaseのダウンロードや関連するgithub.comのエンドポイントに依存していたGitHub Actionsも、一部で影響を受けました。一方、この障害ではログイン済みユーザーは影響を受けていません。(The GitHub Blog)

原因は、特定のエンドポイントに向けられた大量の不正な自動アクセスです。匿名リクエスト用のWebアプリケーションサーバー群が過負荷になり、待ち行列がタイムアウト時間を超えました。

次のようなワークフローは優先的に確認してください。

GitHub Releasesから匿名でビルドツールをダウンロードしている
curlやwgetの1回の失敗でビルド全体が終了する
GitHub上の配布物を社内デプロイの唯一の入手元にしている
ダウンロードしたファイルのチェックサムを確認していない

認証を利用できるアクセスは認証済みに切り替え、重要なツールは社内のパッケージ管理基盤やキャッシュにも保持すると耐障害性が高まります。ただし、認証済みアクセスにすれば、あらゆるGitHub障害を回避できるわけではありません。

REST・GraphQL APIが誤った401を返却

6月10日の障害では、REST APIとGraphQL APIの約9％で断続的な認証失敗が発生しました。

同じクライアントでも、あるリクエストは成功し、次のリクエストでは401 Unauthorizedになる状態でした。GitHub側のゲートウェイが認証処理を再試行していたため、影響を受けたリクエストには約800ミリ秒の遅延も加わっています。(The GitHub Blog)

原因は、内部API基盤に展開されたmemcachedプロキシサービスの設定です。認証サービスが誤った接続先を参照し、一部の認証情報を取得できなくなりました。

この障害で特に問題になりやすいのが、401を受け取った時点で次の処理を実行するシステムです。

保存済みトークンを即時削除する
ユーザーセッションを終了する
OAuth認証画面へ強制的に戻す
GitHub Appの認証情報を直ちに無効扱いにする

単発の401だけで永続的な認証失敗と判断しない設計が重要です。安全な読み取りリクエストであれば、短い待機時間とランダムな揺らぎを加えて1回程度再試行し、連続して失敗した場合にトークンの有効期限、権限、失効状態を確認します。

ただし、401を無制限に再試行してはいけません。本当にトークンが失効している可能性もあるため、再試行回数には上限を設けます。

Copilotモデルで上流障害と設定ミスが連続

6月16日には、CopilotのOpus 4.8モデルで性能劣化が発生しました。原因は上流のモデルプロバイダーです。他のCopilotモデルは利用できたため、利用者は別のモデルへ切り替えることで作業を継続できました。(The GitHub Blog)

翌日の6月17日には、GitHub Copilotの複数の主要チャットモデルが全リージョンで一時的に利用できなくなりました。対象モデルはWeb、エディター、CLIのモデル選択画面から消えるか、選択時に「model not available」を返しました。

こちらの原因は、GitHubの本番環境が無効と判断した設定変更です。GitHubは設定を元に戻し、モデルを復旧させました。今後は段階的な設定展開、利用可能モデル数の急減を検知するアラート、自動ロールバックを強化する方針です。(The GitHub Blog)

特定モデルを業務手順に組み込んでいる場合は、次の2通りから運用方針を決めます。

出力の一貫性を優先する場合は、固定モデルを維持し、障害時は人による作業へ切り替える
継続利用を優先する場合は、Autoまたは承認済みの代替モデルへ切り替える

GitHub CopilotのAuto model selectionは、リアルタイムの稼働状況やモデル性能を基に利用モデルを選択します。全Copilotプランで利用できますが、選択対象は契約プランや管理者ポリシー、データ所在地に関するポリシーなどに制限されます。(GitHub Docs)

Autoへ切り替える場合は、可用性だけでなく出力品質もテストしてください。モデルが変われば、コードの提案内容、説明の詳しさ、レビュー指摘の傾向も変わる可能性があります。

バックグラウンドジョブの障害で最大7分の遅延

6月25日の障害では、GitHubのバックグラウンドジョブ処理が劣化しました。Pull Request、リポジトリへのpush、GitHub Actions、Webhookなどに遅延が発生し、最大遅延は7分です。(The GitHub Blog)

原因は、ハイパーバイザーの問題と受信トラフィックの急増が重なったことです。サービスのタイムアウトから接続が集中し、継続的な再接続と再配置が発生しました。

この種の障害では、「処理されていない」のか「遅れているだけ」なのかを利用者側から判別しにくくなります。次のような処理では、安易な手動再実行が重複につながります。

pushを契機とした本番デプロイ
Webhookを契機としたチケット作成
Pull Request作成時の外部テスト
リリースイベントを契機とした配布処理
課金やアカウント作成を伴う外部連携

障害中にイベントが見えない場合でも、一定時間は遅延を待ち、その後にGitHub上の状態と自社システムの処理履歴を照合してください。

仕様差分と既存実装への互換性

今回のレポートには、REST APIやGraphQL APIのスキーマ変更、認証方式の変更、GitHub ActionsのYAML構文変更、Webhookペイロードの変更は記載されていません。

つまり、公開仕様の差分ではなく、同じ仕様を提供する内部基盤で一時的な障害が起きたという位置付けです。

対象	公開仕様の変更	既存実装への影響	推奨対応
REST API・GraphQL API	変更告知なし	単発401や遅延を正しく扱えない実装は影響を受ける	認証失敗の判定と再試行を確認
GitHub Actions	YAML構文などの変更告知なし	起動遅延や外部ファイル取得失敗が起こり得る	再実行手順と重複防止を整備
Webhook	ペイロード仕様の変更告知なし	配信・処理の遅延で後続処理との時間差が生じる	冪等性と照合処理を追加
GitHub Copilot	新しい必須設定なし	固定モデルが一時的に利用できない場合がある	Autoまたは代替モデルを検証
github.comの画面	UI仕様変更ではない	匿名アクセスだけが失敗するケースがある	重要処理で匿名取得への依存を減らす

互換性が維持されているからといって、対策が不要とは限りません。公開仕様どおりの正常系だけを想定したシステムは、APIやジョブキューの一時障害に弱いためです。

今回のレポートで確認すべきなのは、「APIの使い方が変わったか」ではなく、「APIが一時的に仕様どおり応答できない場合でも、自社システムが安全に動くか」です。

GitHubの内部基盤では何が変わったのか

GitHubは6件の障害報告に加え、可用性向上を目的とした内部基盤の進捗も公開しています。

主な変更点は次のとおりです。

内部基盤の取り組み	2026年6月時点の状況
モノリス処理のAzure移行	Central USで最大45％のトラフィックを処理
Git処理のAzure移行	HTTPとSSHを合わせて30％から最大43％へ増加
Pull Request読み取りサービス	新サービス`pullsd`が匿名読み取りの100％を処理
リポジトリサービス	`reposd`がAzureからREST読み取りトラフィックの最大50％を処理
ユーザー関連サービス	ピーク時に毎秒約50万クエリを主要DBから分離
APIレート制限	約97％をゲートウェイで処理
DB負荷制御	本番トラフィックの5％でクライアント側負荷遮断を運用
本番変更管理	対話的な本番アクセスとChatOps変更で2名確認を必須化

GitHubは、5月21日の安定性問題を受けてAzureへのトラフィック移行を約1カ月停止し、6月17日に再開しました。現在はトラフィックを増やす各段階で、環境の健全性を確認するゲートを設けています。Git処理については6月の50％という目標を達成できず、当面は45％前後にとどめる方針です。(The GitHub Blog)

これらは利用者が有効化する機能ではありません。APIエンドポイントやGitの接続先を変更する必要もありません。

一方で、バックエンドの段階的な分離や移行が続いていることは理解しておくべきです。正常時のレスポンスだけでなく、経路の切り替え、容量不足、設定ロールバックが発生した場合も想定してテストする必要があります。

対応要否を判断する基準

GitHubから利用者に対する強制的な変更要求はありません。自社対応の優先度は、GitHubへの依存度と障害時の影響で判断します。

利用状況	対応優先度	判断理由
401を1回受けただけでトークンやセッションを削除する	高	一時障害で認証ループや大量ログアウトが起こる
Webhookでデプロイ、課金、アカウント作成を実行する	高	遅延や重複実行が業務障害につながる
ActionsからGitHub Releasesを匿名取得する	高	504でビルドやデプロイが停止する
Actionsが失敗した際の再実行手順がない	高	復旧後も処理を再開できない
Copilot code reviewを必須工程にしている	中～高	Copilot障害だけでマージ作業が停止する
特定のCopilotモデルだけを利用している	中	モデル単体の障害で作業を継続できない
GitHubをブラウザと通常のGit操作だけで利用している	低	コード修正より通知設定と運用手順が重要
GitHubへの依存が開発時だけで、本番処理に含まれない	低	業務への直接的な影響が限定的

高優先度に該当するシステムは、次回の通常メンテナンスを待たずに、エラー処理と再実行方法を確認した方が安全です。

対策を利用するための条件

今回のレポート自体に導入作業はありません。ただし、復旧手段としてGitHubの機能を利用する場合は、権限や制約を確認する必要があります。

対策	利用条件	注意点
Actionsワークフローの再実行	リポジトリへのwrite権限	最初の実行から30日以内
失敗したジョブだけの再実行	リポジトリへのwrite権限	元の実行者の権限、同じSHA・refで動作
Webhookの手動再配信	リポジトリ管理者、組織所有者、GitHub App所有者など	過去3日分が対象
CopilotのAuto model selection	すべてのCopilotプラン	管理者ポリシーや契約プランで対象モデルが変わる
GitHub Status通知	GitHub Statusから登録	メール、SMS、Slack、Webhook、Atom、RSSを選択可能

GitHub Actionsは、失敗したワークフロー全体、失敗したジョブ、特定ジョブを再実行できます。再実行では、再実行を指示した人ではなく、最初にワークフローを起動した実行者の権限が使われます。また、GITHUB_SHAとGITHUB_REFも元の実行と同じです。(GitHub Docs)

GitHub CLIを使用する場合、失敗したジョブだけを再実行する基本コマンドは次のとおりです。

gh run rerun RUN_ID --failed

Webhookは、失敗した配信をGitHubが自動で再配信する仕組みではありません。過去3日以内であればWeb画面またはREST APIから再配信できます。重要なWebhookでは、配信失敗を検知して再配信する自動処理も検討してください。(GitHub Docs)

API連携で見直すべきエラー処理

単発の401で認証情報を削除しない

401には、トークン失効、権限不足、認証情報の誤りなどの原因があります。しかし今回の障害では、GitHub内部の一時的な認証参照失敗でも401が返されました。

実装では、次の順序で処理します。

トークンの有効期限をローカル情報から確認する
読み取りリクエストであれば、短い待機後に1回だけ再試行する
連続して401になる場合は、権限や失効状態を確認する
確認できるまで保存済み認証情報を削除しない
ユーザーには「認証切れ」ではなく「GitHubへの接続を確認中」と表示する

本当に無効なトークンを何度も再試行しないよう、回数と総待機時間には上限を設けてください。

5xxとタイムアウトではジッター付き再試行を使う

GitHub APIが500番台のエラーやタイムアウトを返した場合は、即時に同じリクエストを集中させないことが重要です。

例えば、1秒、2秒、4秒と待機時間を増やし、各待機にランダムな揺らぎを加えます。すべてのクライアントが同時刻に再試行する「再試行の集中」を防げます。

GitHubのREST API公式ドキュメントでも、retry-afterがある場合は指定時間まで待つこと、レート制限時は指数的に待機時間を増やすこと、繰り返される4xx・5xxを無視しないことが案内されています。(GitHub Docs)

更新系APIを無条件で再送しない

POST、PATCH、DELETEなどの更新系リクエストは、タイムアウト後に処理済みかどうか判断できないことがあります。

無条件で再送すると、Issueの二重作成、コメントの重複、デプロイの二重起動などが起こります。再送前に対象リソースを取得し、最初の処理が反映済みか確認してください。

クライアント側でも処理IDを発行し、同じ業務処理を二重に実行しない仕組みを持たせると安全です。

GitHub Actionsで見直すべきポイント

外部ダウンロードを再試行可能にする

GitHub Releasesなどからファイルを取得するステップでは、次の対策を組み合わせます。

一時的な504や接続失敗を限定回数だけ再試行する
ダウンロード後にハッシュ値を検証する
重要なツールは社内キャッシュにも保存する
最新版を毎回取得せず、使用バージョンを固定する
取得失敗と検証失敗を別のエラーとして記録する

再試行だけを追加し、ファイル検証を省略するのは危険です。途中まで取得したファイルや、想定外の内容をそのまま実行しないようにします。

起動遅延と実行失敗を区別する

Actionsのジョブが開始されない場合、ワークフロー自体の不具合とは限りません。GitHub側でキューやバックグラウンド処理が遅れている可能性があります。

開始待ちに対する監視時間を短くしすぎると、正常に待機しているジョブを失敗扱いにしてしまいます。逆に無期限で待たせると、障害検知が遅れます。

自社のデプロイ要件に合わせ、例えば次のように段階を分けます。

5分経過：警告
10分経過：GitHub Statusを確認
15分経過：担当者へ通知
復旧確認後：失敗ジョブだけを再実行

時間は公式の推奨値ではありません。通常の待ち時間と自社の復旧目標を基に調整してください。

再実行による二重デプロイを防ぐ

ワークフローを再実行する前に、対象環境へのデプロイが完了していないか確認します。

特に、GitHub上ではジョブが失敗と表示されていても、外部のクラウド環境では処理が完了している可能性があります。デプロイ先のリリース番号やコミットSHAを確認してから再実行しましょう。

Webhook連携で見直すべきポイント

遅延を欠損として扱わない

Webhookが数分届かないだけで、同じ処理を手動起動すると、後からWebhookが届いた際に重複処理が発生します。

受信システムでは、次の状態を分けて管理します。

未受信
受信済み・未処理
処理中
処理済み
失敗
再処理待ち

GitHub側のイベント時刻と、自社システムの受信時刻も別々に記録してください。遅延がGitHub側、ネットワーク、自社キューのどこで発生したか判断しやすくなります。

同じイベントを複数回処理しても結果を変えない

Webhook処理は冪等にします。同じ配信を2回受信しても、チケット、デプロイ、通知を二重に作成しない状態が理想です。

例えば、リポジトリ、イベント種別、対象番号、コミットSHAなどを組み合わせて処理済みキーを作ります。すでに処理したキーであれば、成功扱いで終了させます。

定期的な照合処理を用意する

Webhookだけに依存すると、配信失敗や長時間の障害で状態が欠落する可能性があります。

1時間ごと、または1日ごとにGitHub APIから最新状態を取得し、Webhookで受信した情報と照合する処理を用意すると安全です。リアルタイム処理はWebhook、欠損修復は定期照合という役割分担が有効です。

Copilot運用で見直すべきポイント

固定モデルとAutoの違いを理解する

固定モデルは出力傾向を揃えやすい一方、そのモデルが停止すると作業を継続できません。

Autoは利用可能なモデルへ切り替えやすい反面、選択されるモデルによって出力傾向が変わります。品質基準が厳しいコードレビューやセキュリティ確認では、Autoへ切り替えた後も人による確認を省略しないでください。

モデルが利用できない場合の手順を文書化する

次のような簡単な切り替え基準を決めておくと、障害時に迷いません。

状況	推奨する行動
固定モデルだけが利用不可	承認済みの代替モデルへ切り替える
複数モデルが利用不可	Autoを試す
Copilot code reviewが失敗	人によるレビューへ切り替える
モデル変更後に品質が低下	元モデルの復旧を待つか、人による作業を継続する
管理ポリシーで代替モデルを選べない	管理者へ連絡し、手動フローを使用する

テスト時に確認すべき障害シナリオ

通常の成功パターンだけでなく、GitHub側の障害を模したテストを行います。

テストシナリオ	テスト方法	合格基準の例
APIが単発で401を返す	モックで最初の1回だけ401を返す	トークンを削除せず、限定再試行で復旧する
APIが連続して401を返す	すべての応答を401にする	無限再試行せず、再認証へ誘導する
APIが500・504を返す	数回失敗後に成功させる	ジッター付きで再試行し、上限後は安全に停止する
更新APIがタイムアウトする	処理完了後に応答だけ失わせる	状態照会を行い、二重作成しない
Actionsの開始が10分遅れる	テスト用ゲートで開始を遅延させる	不要な二重実行を起こさず、警告を通知する
Release取得が失敗する	ダウンロード先を一時的に失敗させる	再試行後に検証し、破損ファイルを実行しない
Webhookが7分遅れる	テストイベントをキューで保留する	手動処理との重複を防ぎ、後着イベントを処理する
Webhookが重複する	同じイベントを2回配信する	業務処理が1回だけ実行される
Webhookが欠損する	1件を意図的に破棄する	定期照合で欠損を検出して修復する
Copilotモデルが消える	利用モデルを切り替えられない状態を想定する	Auto、代替モデル、人による作業へ移行できる
Copilot code reviewが失敗する	レビュー結果をエラーにする	エラーを承認扱いにせず、人へ割り当てる

テストでは、最終的に成功したかだけでなく、次のログが残るかも確認してください。

最初に失敗した時刻
HTTPステータスコード
再試行回数と待機時間
GitHub側のリクエスト識別情報
実行対象のリポジトリとコミットSHA
重複処理を抑止した記録
代替処理へ切り替えた理由
復旧後に再処理した結果

障害対応で失敗しやすいポイント

失敗しやすい対応	起こり得る問題	改善方法
1回の401でログアウトさせる	認証ループ、大量ログアウト	連続失敗を確認してから認証切れと判断
エラー直後に全クライアントが再試行する	GitHubと自社基盤の負荷を増幅	指数バックオフとジッターを使用
更新系APIを無条件で再送する	Issueやデプロイが重複	現在状態を照会してから再送
Webhook遅延時に手動処理する	後着イベントと重複	処理済みキーと待機時間を設ける
Copilotレビューのエラーを無視する	未レビューの変更をマージ	人によるレビューへ切り替える
Actions全体をすぐ再実行する	完了済み処理も再度動く	失敗ジョブだけを再実行
Status確認を担当者の手作業にする	障害の発見が遅れる	SlackやWebhookへ自動通知
正常系だけをテストする	本番障害時に初めて問題が判明	401、504、遅延、重複を定期テスト

GitHub Statusを運用へ組み込む

障害が疑われる場合、コードや認証情報を変更する前にGitHub Statusを確認します。

GitHub Statusでは、メール、SMS、Slack、Webhook、Atom、RSSによる通知を利用できます。GitHub Enterprise Cloudについては、日本を含む地域別ステータスページも用意されています。(GitHub Status)

実務では、次の運用が分かりやすいでしょう。

GitHub StatusのWebhookまたはSlack通知を登録する
API、Actions、Pull Requests、Webhooks、Copilotを監視対象にする
自社アラートとGitHubの障害時刻を照合する
GitHub側の障害なら不要な設定変更を止める
復旧後に失敗ジョブ、Webhook、外部連携を再確認する
重複処理がないことを確認してインシデントを終了する

GitHub側の障害中に、トークンの再発行、権限変更、ワークフロー修正を繰り返すと、復旧後に別の不具合を残すことがあります。まず外部サービスの状態を確認し、自社設定の問題と切り分けてください。

まず実施すべき対応

GitHub 2026年6月可用性レポートによって、すべての利用者にコード変更が必要になったわけではありません。対応が必要なのは、GitHubの一時障害がそのまま認証障害、デプロイ停止、重複処理、業務停止につながるシステムです。

最初に、GitHub API、Actions、Webhook、Copilotへの依存箇所を一覧化してください。次に、単発401で認証情報を削除していないか、匿名ダウンロードが失敗するとビルドが止まらないか、Webhookの遅延や重複を処理できるかを確認します。

問題が見つかった場合は、限定的な再試行、処理の冪等化、定期照合、Copilotの代替手順を追加します。最後に401、504、7分程度の遅延、Webhook重複、Copilotモデル停止を模したテストを実施し、GitHub Statusの通知を運用チャンネルへ接続しましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。