GitHubのHTTPS接続でSHA-1の利用終了が始まります。管理者がまず行うべきことは、GitHubに接続するブラウザ、Gitクライアント、API連携、CI/CD、プロキシ、古いOSを洗い出し、2026年7月14日の一時停止テスト前に影響範囲を確認することです。
2026年4月20日付のGitHub Changelog「GitHub starts sunsetting SHA-1 for HTTPS traffic」では、GitHub.comおよびCDNでHTTPS/TLSにおけるSHA-1利用を段階的に廃止する方針が示されました。影響するのは、GitHub Webサイトを閲覧するブラウザ、GitHub APIを利用するソフトウェア、HTTPS経由でpush/pullするGitクライアントです。GitHub Enterprise CloudとGitHub Enterprise Cloud with Data Residencyは対象ですが、GitHub Enterprise Serverは対象外とされています。(The GitHub Blog)
この記事では、IT管理者、運用責任者、展開計画担当者向けに、GitHub platform security and HTTPS connectivity の観点から、設定差分、確認手順、社内周知、展開順序をチェックリスト形式で整理します。
GitHub starts sunsetting SHA-1 for HTTPS traffic の要点
今回の変更は、GitHubのリポジトリ機能そのものの使い方を変えるものではありません。ポイントは、GitHubへHTTPS/TLSで接続するクライアント側が、SHA-1に依存している古い構成では接続できなくなる可能性があるという点です。
GitHubは、SHA-1を一時的に無効化する「brownout」を2026年7月14日 00:00〜18:00 UTCに実施予定としています。このbrownoutはCDNには影響しない予定です。その後、2026年9月15日にGitHubおよびパートナーCDNでHTTPS/TLSにおけるSHA-1を完全に無効化する予定です。(The GitHub Blog)
| 日付 | 内容 | 管理者が確認すべきこと |
|---|---|---|
| 2026年4月20日 | GitHubがSHA-1廃止方針を発表 | 影響範囲の棚卸し、担当者の割り当て |
| 2026年7月14日 00:00〜18:00 UTC | brownout実施予定 | 本番・開発・CI/CDで接続失敗がないか確認 |
| 2026年9月15日 | SHA-1 in HTTPS/TLSを完全無効化予定 | 未対応環境を更新または切り離し |
日本時間で運用している組織では、UTC表記のスケジュールをそのまま社内に流すと誤解が起きやすくなります。周知文では、UTCと現地時間を併記し、CI/CDの実行時間、夜間バッチ、海外拠点の勤務時間に重なるかを確認してください。
影響を受ける可能性がある接続パターン
GitHub platform security and HTTPS connectivity の管理では、「開発者のPCだけ」を見ても不十分です。GitHubへのHTTPS接続は、ブラウザ、Git、API、CI/CD、社内プロキシなど複数の経路で発生します。
ブラウザでGitHubを利用している端末
GitHubは、最新のブラウザを利用していればSHA-1より新しいアルゴリズムに対応できると説明しています。また、https://github.dev はすでにSHA-1が無効化されており、ブラウザで正常に読み込めれば、現代的なHTTPS構成に対応しているかを確認できるとしています。(The GitHub Blog)
管理者は、次のような端末を優先して確認します。
- 長期間更新されていない業務端末
- 共有端末、検証端末、工場・研究所などの固定端末
- 古いVDIイメージやシンクライアント
- セキュリティ例外でブラウザ更新が止まっている端末
- 海外拠点や委託先で管理ポリシーが異なる端末
確認時は「GitHubのトップページが開くか」だけでなく、github.dev、リポジトリ画面、認証後のページ、GitHub Enterprise Cloudの組織ページまで確認すると実務上の漏れを減らせます。
GitクライアントでHTTPS push/pullしている環境
GitHubは、HTTPS経由でpush/pullするGitクライアントも影響対象に含めています。GitはHTTPS接続のために複数のライブラリやバックエンドを利用する場合があり、LinuxではOpenSSLがTLSバックエンドとして使われる例が挙げられています。Git本体だけでなく、OSや関連コンポーネントも最新に近い状態であることが重要です。(The GitHub Blog)
確認対象は、開発者端末だけではありません。
| 対象 | 見落としやすいポイント |
|---|---|
| 開発者PC | Gitは新しくても、OSや証明書ストアが古い場合がある |
| CI/CDランナー | コンテナイメージやセルフホストランナーが古いまま残る |
| ビルドサーバー | OS更新が停止している長期運用サーバーが多い |
| 自動デプロイ環境 | 夜間・定期実行のため障害に気づきにくい |
| スクリプト実行端末 | 個人管理のツールや古いPortable Gitが残りやすい |
| プロキシ経由環境 | クライアントではなく中間装置側のTLS処理が原因になることがある |
特に、Windows、macOS、LinuxでGitのTLS処理に使われる仕組みは異なります。単に「Gitのバージョン番号」だけで判定せず、実際に対象環境からGitHubへ接続するテストを行うことが大切です。
GitHub APIを利用するアプリケーション
GitHub APIを利用する内製ツール、監視ツール、デプロイツール、GitHub Apps、OAuthアプリ、Webhook処理基盤も確認が必要です。GitHubは、API接続についても現代的なフレームワークやライブラリを利用するよう求めています。(The GitHub Blog)
次のような構成は優先的に棚卸ししてください。
- 古いJavaランタイムで動く連携アプリ
- 古いPython、Ruby、Node.js、PHP環境のスクリプト
- 長期間更新されていないDockerイメージ
- 社内ポータルからGitHub APIを呼び出す仕組み
- ChatOps、通知bot、Issue連携ツール
- GitHub Actions以外の外部CIサービス
- セキュリティ監査や棚卸しの自動化スクリプト
API連携は、利用者が直接画面を見ていないため、接続失敗が発生しても発見が遅れます。brownout前にログ監視、失敗通知、リトライ設計を確認しておくと、切り分けが速くなります。
管理者向けの導入・設定チェックリスト
ここからは、GitHub starts sunsetting SHA-1 for HTTPS traffic を受けて、管理者が実際に使えるチェックリストとして整理します。大きく分けると、棚卸し、検証、更新、展開、監視、周知の順で進めると混乱を抑えられます。
まず確認すべき設定差分
「どこを設定変更すればよいのか」と考えがちですが、多くの場合、GitHub側の設定変更ではなく、接続元環境の更新と標準化が中心になります。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| ブラウザの更新状態 | 端末管理ツール、MDM、利用者端末 | サポート中の最新系に更新されているか |
| Gitクライアント | 開発者PC、CI/CD、ビルドサーバー | 古い固定バージョンを使っていないか |
| OSと証明書ストア | サーバー、VDI、端末イメージ | OS更新が止まっていないか |
| TLSライブラリ | OpenSSL、curl、言語ランタイム | 古い暗号アルゴリズム前提の構成でないか |
| プロキシ・SSL検査 | ネットワーク機器、SASE、CASB | GitHub接続を中継して問題を起こさないか |
| APIクライアント | 内製アプリ、bot、連携ツール | 使用ライブラリが更新可能か |
| コンテナイメージ | CI/CD、ジョブ定義 | 古いベースイメージを使い続けていないか |
実務では、端末管理チーム、開発基盤チーム、ネットワークチーム、セキュリティチームで管理範囲が分かれます。最初に「誰がどの接続経路を確認するか」を明確にしないと、全員が「誰かが見ているはず」と考え、CI/CDやプロキシが抜け落ちます。
接続テストの手順
接続テストは、代表端末だけで終わらせず、利用パターンごとに分けて実施します。
| 手順 | 確認内容 | 合格基準 |
|---|---|---|
| 1 | ブラウザで https://github.dev を開く | 接続エラーなく表示できる |
| 2 | GitHub.comへログインして組織ページを開く | 認証後ページが表示できる |
| 3 | HTTPS URLでcloneする | リポジトリを取得できる |
| 4 | 既存リポジトリでfetch/pullする | 既存認証情報で成功する |
| 5 | テストブランチへpushする | push時のTLS接続で失敗しない |
| 6 | APIクライアントからGitHub APIを呼び出す | 200系または想定どおりのレスポンスが返る |
| 7 | CI/CDジョブを実行する | checkout、依存関係取得、デプロイが成功する |
| 8 | プロキシ経由と非プロキシ経由を比較する | 経路差による失敗がない |
github.dev の確認は有効な入口ですが、それだけで全環境が安全とは言い切れません。Gitクライアント、APIライブラリ、CI/CD、プロキシは別のTLS実装を使う場合があるため、それぞれ実際の業務フローでテストする必要があります。
CLIで確認する場合の例
開発者端末やサーバーでは、次のようなコマンドでGitと接続の基本確認を行えます。
git --version
git ls-remote https://github.com/github/docs.gitAPI接続を簡易的に確認する場合は、次のようにGitHub APIへリクエストします。
curl -I https://api.github.comただし、これらのコマンドはあくまで簡易確認です。実際の業務では、認証、プロキシ、社内証明書、CI/CDの実行ユーザー、コンテナ内のライブラリが絡みます。最終判断は、本番に近い環境でのリハーサル結果を基準にしてください。
展開順序は「影響が大きく、戻しにくい環境」から始める
更新作業は、全端末を一斉に変更するよりも、失敗時の影響を抑えながら段階的に進めるのが現実的です。おすすめの順序は次のとおりです。
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | CI/CD、ビルドサーバー、デプロイ環境 | 障害時に開発・リリース全体が止まる |
| 高 | API連携、bot、監視・棚卸しツール | 無人実行が多く、失敗に気づきにくい |
| 中 | 開発者PC、VDI、共有端末 | 利用者から申告されやすいが台数が多い |
| 中 | プロキシ、SSL検査、ネットワーク経路 | 一部拠点だけ失敗する原因になりやすい |
| 低〜中 | 検証環境、古い一時環境 | 放置されがちだが本番復旧時に問題化する |
特にCI/CDは、GitHub Actionsだけでなく、Jenkins、GitLab Runner、CircleCI、Azure DevOps、Bitbucket Pipelines、社内独自のビルド基盤なども対象に含めます。GitHubへの接続が「ソース取得だけ」だと思っていても、サブモジュール、パッケージ取得、リリースアセット取得、APIによるステータス更新などでHTTPS接続が発生していることがあります。
社内周知で伝えるべき内容
周知では、暗号アルゴリズムの詳細を長く説明するより、利用者が取るべき行動を明確にすることが重要です。開発者、運用担当、マネージャーでは知りたい内容が異なるため、1つの長文メールで済ませず、対象別に分けると伝わりやすくなります。
開発者向け周知
開発者向けには、手元で実行できる確認方法を入れます。
GitHubのHTTPS接続に関する変更に備え、以下を確認してください。
1. ブラウザで https://github.dev が開けるか
2. Gitのバージョンが極端に古くないか
3. HTTPS URLで利用しているリポジトリに対して fetch / pull / push が成功するか
4. エラーが出た場合は、OS、Git、利用ネットワーク、エラーメッセージを添えて連絡すること開発者には「SSH接続なら影響しないのか」という疑問が出やすくなります。今回の発表はHTTPS/TLSにおけるSHA-1廃止が対象であり、GitのHTTPS接続、ブラウザ、API連携が確認対象です。一方で、組織内でHTTPSとSSHの利用ルールが混在している場合は、この機会に認証方式、監査ログ、トークン管理の方針も整理しておくとよいでしょう。
運用・SRE向け周知
運用担当には、brownout期間中の監視とエスカレーションを明確にします。
2026年7月14日のbrownout期間中、GitHubへのHTTPS接続失敗が発生する可能性があります。
監視対象は、CI/CDジョブ、デプロイパイプライン、GitHub API連携、通知bot、夜間バッチです。
接続エラーを検知した場合は、対象ホスト、実行ユーザー、利用ライブラリ、プロキシ経路、ログを記録してください。brownoutは「障害」ではなく、廃止前の検出機会です。ここで失敗した環境を放置すると、2026年9月15日の完全無効化時に本番影響が出る可能性があります。
マネージャー・プロジェクト責任者向け周知
マネージャー向けには、作業目的と期限を短く伝えます。
GitHubのHTTPS接続で古いSHA-1利用が段階的に廃止されます。
古い端末、古いCI/CD環境、未更新のAPI連携では、GitHub接続に失敗する可能性があります。
2026年7月14日の一時停止テスト前に、担当チームごとの確認完了をお願いします。技術詳細よりも、リリース計画や開発停止リスクに結び付けて説明すると、期限内の協力を得やすくなります。
brownout当日の運用チェックリスト
2026年7月14日のbrownoutは、影響環境を見つけるための重要な機会です。事前に観測ポイントを決めておかないと、「一部のジョブが失敗したが原因が分からない」で終わってしまいます。
| 時点 | 実施内容 |
|---|---|
| 事前 | 対象システム、担当者、連絡チャネルを決める |
| 事前 | 代表的なCI/CDジョブを手動実行できる状態にする |
| 開始直後 | GitHub Web、Git操作、API連携の疎通を確認する |
| 実施中 | エラー内容を記録し、端末・OS・Git・TLSライブラリを紐づける |
| 実施中 | 海外拠点、在宅勤務、VPN、プロキシ経由の差分を見る |
| 終了後 | 失敗環境を一覧化し、9月15日までの対応計画に落とす |
当日のログでは、単に「GitHubにつながらない」と記録するのではなく、以下の情報を残すと後続対応が早くなります。
- 発生時刻とタイムゾーン
- 対象ホスト名または端末種別
- 実行したコマンドまたはジョブ名
- Git、curl、言語ランタイム、OSのバージョン
- プロキシ、VPN、SSL検査の有無
- エラーメッセージ全文
- 成功した別環境との差分
よくある失敗と対策
「開発者PCは問題ない」で終わってしまう
もっとも多い失敗は、数台の開発者PCでGitHubが開けたため、対応完了と判断してしまうことです。実際には、CI/CD、社内bot、古いサーバー、海外拠点のネットワークなど、利用者の目に見えない場所でGitHub接続が発生しています。
対策は、GitHubの監査ログ、CI/CD設定、リポジトリのWebhook、トークン発行状況、ネットワークログを組み合わせて接続元を棚卸しすることです。
コンテナイメージ内の古いライブラリを見落とす
ホストOSは更新済みでも、CI/CDで使うコンテナイメージが古いと、Git、curl、OpenSSL、言語ランタイムが古いまま残ることがあります。特に、数年前に作成した独自イメージをタグ固定で使っている場合は注意が必要です。
対策として、ベースイメージの更新日、パッケージ更新手順、再ビルド頻度を確認します。latest に任せるのではなく、更新対象と検証手順を明確にしたうえで、バージョン固定と定期更新のバランスを取ることが重要です。
プロキシやSSL検査装置を確認していない
企業ネットワークでは、GitHubへのHTTPS通信がプロキシ、SASE、CASB、SSL検査装置を経由することがあります。この場合、端末側が対応していても、中間装置のTLS処理や証明書処理が原因で失敗することがあります。
対策は、社内ネットワーク、VPN、在宅回線、海外拠点、クラウド上のCI/CDなど、経路を分けて疎通確認することです。失敗が一部ネットワークに偏る場合は、端末ではなく経路側の問題を疑います。
API連携の所有者が不明なまま残る
古いbotやスクリプトは、作成者が退職していたり、部署移管で所有者が不明になっていたりします。GitHub APIへの接続失敗が起きても、誰が直すのか決まっていないと復旧に時間がかかります。
対策は、APIトークン、GitHub Apps、OAuthアプリ、Webhook、CI/CDのサービスアカウントを棚卸しし、所有者、用途、更新方法、停止可否を台帳化することです。
管理者が作るべき対応台帳の例
今回のようなHTTPS接続変更では、単なるチェックリストだけでなく、対応状況を追跡できる台帳が役立ちます。以下の項目をスプレッドシートやチケット管理ツールに登録しておくと、brownout後の追跡が容易になります。
| 項目 | 記入例 |
|---|---|
| 管理番号 | GH-HTTPS-001 |
| 対象 | Jenkins本番ビルドサーバー |
| 所有チーム | Platform Engineering |
| 接続方式 | HTTPS Git clone、GitHub API |
| 環境 | Ubuntu、セルフホスト、社内プロキシ経由 |
| 利用コンポーネント | Git、curl、OpenSSL、Java |
| 確認状況 | github.dev疎通済み、API未確認 |
| brownout結果 | 成功 / 失敗 / 未実施 |
| 対応内容 | OS更新、Git更新、ベースイメージ更新 |
| 完了期限 | 2026年7月末 |
| 9月15日前の最終確認 | 未完了 |
台帳では、「確認済み」とだけ書くのではなく、何を確認したのかを具体化してください。たとえば「GitHub OK」ではなく、「HTTPS clone、push、API呼び出し、CI checkoutが成功」のように書くと、後から見ても判断できます。
グローバル組織での注意点
GitHub Enterprise CloudやGitHub Enterprise Cloud with Data Residencyを使うグローバル企業では、地域ごとに端末管理、ネットワーク、プロキシ、開発基盤が異なることがあります。GitHubの変更日は共通でも、影響の出方は拠点ごとに変わります。
グローバル向けに周知する場合は、次の点を入れてください。
- UTCと各地域の現地時間を併記する
- 地域別の問い合わせ窓口を明確にする
- 海外拠点のプロキシ、VPN、SASE構成を確認する
- 現地で使っている古い端末・VDI・ビルドサーバーを棚卸しする
- 委託先、開発パートナー、外部CI/CDサービスにも確認依頼を出す
- brownout期間中のエスカレーションルートを時差込みで設計する
特に、UTCのbrownout時間がある地域では業務時間外、別の地域では業務ピークに重なることがあります。開発停止リスクを見誤らないために、地域別の影響時間をあらかじめ整理しておきましょう。
9月15日の完全無効化までに完了すべきこと
2026年9月15日の完全無効化までに、管理者は次の状態を目指すべきです。
- GitHubへ接続する端末、サーバー、CI/CD、API連携の棚卸しが完了している
github.dev、Git操作、API呼び出し、CI/CDジョブの確認が完了している- 古いGit、OS、TLSライブラリ、言語ランタイム、コンテナイメージの更新計画がある
- brownoutで失敗した環境の原因と対応期限が明確になっている
- プロキシ、SSL検査、VPN、海外拠点の経路差分を確認している
- 開発者、運用担当、マネージャー向けの周知が完了している
- 完全無効化当日の監視、問い合わせ、切り戻し方針が決まっている
ここでいう切り戻しは、GitHub側のSHA-1廃止を戻すことではありません。自社側で、更新済み環境への切り替え、代替ランナーの利用、問題のあるプロキシ経路の回避、古い自動連携の一時停止などを行うための計画です。
次に取るべき行動
GitHub starts sunsetting SHA-1 for HTTPS traffic への対応は、暗号技術だけの問題ではなく、GitHubを使う開発基盤全体の可視化作業です。まずは、GitHubへのHTTPS接続が発生する場所を棚卸しし、CI/CD、API連携、プロキシ、古い端末から優先して確認してください。
最初のアクションとしては、次の3つで十分です。
- GitHub接続元の一覧を作る
- 代表環境で
github.dev、HTTPS clone、API接続、CI/CDジョブを確認する - 2026年7月14日のbrownoutまでに、失敗時の連絡先と記録方法を決める
この3点を早めに終えておけば、2026年9月15日の完全無効化に向けて、慌てずに更新・周知・展開を進められます。
コメント