Chrome更新を止めずに段階配信、管理者が決める三つの幅

組織のChromeは、自動更新を全社一律に止めるのではなく、端末群ごとの配信順、更新チェックを止める時間帯、許可する対象バージョンという三つの幅で段階配信する。これはGoogleが定めた三分類ではなく、更新経路を残しながら帯域と互換性リスクを管理するための運用上の整理である。

管理者は、端末を即時適用群、短期検証群、期限付き例外に分け、自動更新を基本設定とする。そのうえで各群の更新時期と到達可能なバージョンを調整し、例外には復帰期限を設け、更新の完了条件をブラウザの再起動後まで含める。

第一の幅：端末群ごとに配信順を変える

最初に決めるのは、どの端末が新しいリリースを先に受け取るかである。業務上の役割と障害時の影響が異なる端末を同じ設定にまとめず、群ごとに目的、対象条件、解除条件を記録する。

• 即時適用群：標準的な業務環境やIT部門の端末など、更新を早く受け取り、組織内で問題を早期に把握する群。
• 短期検証群：認証、印刷、会議、基幹システムなど、主要な業務経路との互換性を確認してから進める群。検証項目と判断者を事前に定める。
• 期限付き例外：更新後の具体的な不具合が確認され、代替手段をすぐに用意できない端末だけを一時的に保留する群。対象、理由、責任者、復帰期限を必須情報とする。

Chrome Enterprise Coreの更新管理手順 は、WindowsとmacOSの管理対象パソコンについて自動更新を推奨し、メジャー更新とマイナー更新の双方で「ロールアウト開始時」「Googleの段階的ロールアウト」「ロールアウト完了後」の選択肢を示している。即時適用群を開始時、通常の端末を段階的、短期検証群を完了後に割り当てるのが基本形になる。

ただし「完了後」は組織内の検証完了を意味する設定ではない。Google側のリリースが全面的な安定版展開に達するまで待つ選択肢なので、業務アプリの試験、合否判定、例外解除は組織側の手順として別に管理する必要がある。

第二の幅：更新チェックを止める時間帯を限定する

帯域対策では、自動更新そのものを無効にせず、更新チェックを行わない時間帯だけを限定する。始業直後、全社会議、店舗の繁忙時間などを避ければ、それ以外の時間には更新経路が残る。停止時間はダウンロードを永久に避ける設定ではなく、通信ピークを移すための幅である。

拠点や勤務帯が異なる場合は、一律の時間を配るより、それぞれの通信ピークに合わせて停止時間をずらす。設定後は代表端末のポリシー状態を確認し、停止時間の終了後に更新確認が再開することまで検証する。

利用できる設定はOSごとに同じではない。Googleの自動更新ポリシー一覧 では、自動更新の有効化と無効化は管理コンソール、Windows、Mac、Linux向けに案内される一方、業務時間外のスケジュールは管理コンソール、Windows、Mac、帯域削減のための更新タイミング調整は管理コンソールとWindowsが対象として示されている。複数OSを運用する組織では、一つの設定値を全端末へ適用できると想定せず、プラットフォームごとに実装を分ける。

第三の幅：対象バージョン制限は短期検証に使う

対象バージョンの制限は、自動更新を許可しながら、進める上限を一時的に定めるために使う。メジャーバージョンのプレフィックスを指定する方式なら、その系列の新しい更新を受けつつ、次のメジャーへの移行を待たせられる。正確なバージョンへの固定は、その一点より先へ進ませないため、より限定的に扱う必要がある。

この幅を適用するのは、短期検証群と不具合が確認された例外端末に絞る。設定票には検証対象の業務、判断者、確認予定日、解除期限を記載し、固定の解除作業も当初の変更計画に含める。期限に達しても問題が残る場合は、固定を惰性で継続せず、延長理由、対象端末、代替策、残るリスクを再評価する。

メジャー系列への固定と、厳密なビルド固定を同じものとして扱ってはいけない。前者は同じ系列内の更新を受けられるが、後者は修正版への移行も止め得る。互換性問題を避けるために必要な最小限の幅を選び、広い端末群へ厳密な固定を適用しないことが要点となる。

緊急修正では例外の範囲と期間を縮める

悪用が確認された脆弱性に対する修正など、適用の緊急性が高い場合は、平常時と同じ長さの検証期間を機械的に維持しない。即時適用群を先行させ、短期検証群では認証や基幹処理など停止できない経路に確認項目を絞る。これは設定値ではなく、脆弱性の深刻度と業務影響を比較して管理者が決める運用判断である。

更新を一時的に無効化する必要がある場合は、影響を受ける端末だけに限定し、設定変更と同時に復帰日時を登録する。代替ブラウザの利用、問題のある機能の停止、外部アクセスの制限といった暫定策が可能かも併せて判断する。期限のない無効化は例外ではなく、セキュリティ修正を受け取れない恒久設定になりかねない。

優先順位は、新しいメジャーバージョンかどうかだけでは決められない。修正の緊急性、端末の権限、外部サイトへのアクセス、影響する業務、代替手段の有無を同じ記録にまとめれば、例外を残す理由と解除条件を追跡できる。

更新の完了は再起動後に判定する

更新が端末に届いても、Chromeが再起動されるまでは保留中の更新が適用されない。配信計画には、ユーザーへの通知、猶予期間、自動再起動を行う時間帯まで含める。管理指標もダウンロード済みの台数ではなく、新しいバージョンで再起動した端末の台数を基準にする。

Googleの再起動通知手順 によると、管理対象のWindows、Mac、Linux版Chromeでは、再起動を推奨する通知または一定期間後の自動再起動を設定でき、管理コンソール上の通知期間は1～168時間、未設定時は168時間である。自動再起動では実行する時間帯も指定できるため、即時適用群は短い猶予、通常群は業務への影響が小さい時間帯、例外群は復帰期限と連動させる。

強制的な再起動は、未保存の作業や長時間稼働する処理に影響する。通知だけで十分な端末と、期限後の自動再起動が必要な端末を分け、例外端末についても再起動を無期限に先送りしない。

三つの幅を適用する順番

設定同士の目的を混同しないため、端末の分類から更新完了の確認までを一つの変更計画にまとめる。

1. 管理対象を即時適用群、短期検証群、期限付き例外に分類し、所属条件と責任者を決める。
2. 全群で自動更新を基本的に有効にし、無効化が必要な例外は対象端末と復帰期限を記録する。
3. 群ごとの配信順を選び、対応するOSでは通信ピークを避ける停止時間を拠点または勤務帯ごとに設定する。
4. 短期検証群と例外端末だけに、必要最小限の対象バージョン制限と解除期限を設定する。
5. 再起動通知、猶予期間、必要に応じた自動再起動時間帯を設定し、新しいバージョンでの稼働を完了条件にする。

配信順だけでは通信ピークを避けられず、停止時間だけでは互換性を検証できず、バージョン固定だけでは例外が放置される。自動更新を土台に、誰を先に進めるか、いつ更新を確認するか、どこまで進めるかを期限付きで組み合わせることが、Chrome更新を止めない段階配信の設計となる。