サポート対象外 macOS 500台の撲滅対応

はじめに

IT本部 IT戦略部エンプロイーエクスペリエンスグループの佐藤と申します。
DeNAグループにおけるPC等の端末管理、トラブル対応などを担っています。

DeNA では Mac だけでも2,000台以上を管理しています。
基本的に最新の macOS を3世代までサポートしており、毎年対象外の古いOSで稼働している端末はアップデートや交換を行うことで、それらが使われ続けないよう取り組んでいます。これを行う最大の理由はエンドポイントセキュリティソフトのサポート期間にあります。OS のリリースライフサイクルに合わせて、1年ごとに旧世代の OS が終了（EOL）を迎えるためです。セキュリティレベルを維持するためにも、古い OS は計画的に撲滅していく必要があります。

撲滅対応を担当するようになって今年で2年目になります。本記事では、毎年恒例の取り組みから新たな取り組みまでをざっくりと紹介したいと思います。

毎年恒例の対応

対象端末の特定

本作業を実施していた2025年時点では、macOS 13 Ventura を対象として撲滅対応を進めました。（EOLの期限は2025年いっぱい）
2025年6月末から対応を始め、その時点で対象端末の台数は500台程度ありました。
管理対象の Mac は全て Jamf の管理下のため、一覧をフィルターすることで対象端末の特定は容易です。
500台もあると、その中には古いモデルも含まれます。Ventura 以降にアップデートできない端末も出てくるため、アップデートを依頼する端末と機種交換が必要な端末を分けて管理しました。

ターゲットバージョンの決定

アップデートを行なってもらうターゲットのバージョンをあらかじめ決めておきます。
撲滅対応を始めた時点では macOS 26 Tahoe はリリースされていなかったため、今回は macOS 15 Sequoia をターゲットに設定しています。これが例えば Ventura の次の世代である Sonoma などに上げてしまうと、翌年に再度アップデート依頼をする必要が出てきてしまいます。そのため、基本的には最新か、最新の1つ前の世代をターゲットにしています。

アップデート手順書の作成

できるだけ簡潔な手順書を用意し、手順に沿って対応すればターゲット OS へのアップデートが完了しているようにする必要があります。幸いにも Jamf の Self Service アプリが全端末にインストールされているため、OS のインストーラーを Self Service 経由でダウンロードし、アップデートする手順で構成しています。

交換アンケートの作成と回答依頼

すでにアップデートができないモデルを所有しているユーザー向けに、交換希望を募るアンケートを作成し、希望するモデルを回答してもらいます。すでに使っていない等のケースは「返却予定」という形で回答してもらいます。その情報をもとに在庫を確保したり、来季予算策定時の参考にしたり、EOL までに交換が完了できるスケジュールを組み立てます。

アナウンス対応

アップデートパターンと交換パターンに分けて、それぞれアナウンスを行い、対応を依頼します。まずは対象者に対して対応マニュアルを含めたメールを送付します。さらに Slack の DM などを組み合わせることで、できるだけ見落とされにくいよう通知が届くように工夫しています。

新たな取り組み

毎年恒例とはいえ、数百台ある端末をすべてアップデート・交換し切るのには、それなりに時間がかかります。特に追い込みの過程ではユーザーコミュニケーションやサポートが多く発生するため、いかに効率的に進めるかという方法を模索しながら取り組んでいます。今回新たに実施した取り組みを紹介します。

インベントリ情報の収集頻度を変更

課題
Jamf では端末の様々なインベントリ情報（ハードウェア・OS・アプリケーション・ストレージ）を保持しており、稼働中の OS バージョンなどもこの中に含まれています。端末側への負荷（CPU・メモリ等のリソース消費やトラフィック）を考慮して通常は1週間に1度の頻度でインベントリ情報の更新を行う設定になっています。追い込みを行う中で、ユーザー側ではすでにアップデートが完了している一方、Jamf 上にはその情報が反映されていない、という状況が多々発生していました。「アップデートは完了していますか？完了している場合は Self Service から手動でインベントリ情報を更新してください」というユーザーコミュニケーションを都度行う必要があり、そこに工数を取られてしまう課題がありました。

解決策
通常は1週間に1度の収集頻度となっていましたが、対象となる端末のみに絞って日次でインベントリ収集を行うポリシーを作成しました。これにより、影響範囲を限定しつつ、課題となっていたユーザーコミュニケーションの頻度を減らすことができました。端末への負荷に関しては、Jamf のサポートチームにも相談しつつ、1日1回の実行に問題がないのかの確認をしたり、チームメンバーの端末へ先行してポリシーを適用し、様子を見ることで問題がないことを確認しました。

ソフトウェアアップデート機能を使う

課題
アップデートのタイミングがユーザー側の都合に合わせる形になるため、期限を設けて依頼してもなかなかアップデートが完了しない端末も多く出てきます。何度かリマインドはするものの、なかなか対応は進まずコミュニケーションにコストがかかってしまうという課題がありました。

解決策
Jamf の「ソフトウェアアップデート」機能を使うことで、対応が必要な端末の台数を減らすことができ、個別のコミュニケーションを行わずともアップデートさせることができました。この機能は特定の端末を含むグループに対して、強制的にソフトウェアアップデートをトリガーできる機能です。インストールアクションにはいくつかパターンが用意されていますが、今回は「ダウンロードとインストール」を選択しています。設定当時190台程度ありましたが、そのうち50台程度を強制的にアップデートすることができました。台数だけ見ると大きな効果とは言い難いですが、少しでも工数をかけずにアップデートできたことは大きいと言えます。

今回の学び

学んだこと①：短期集中対応よりも日々の地道な活動が重要

今回の対応を通じて、短期間で一気に追い込みをかける対応は非常に大変で、多くの工数がかかるということを改めて実感しました。ユーザー側にも都合があり、すぐに対応ができるわけではありません。まとめて対応を進めようとしても、期限が近づくほど対応が集中し、我々とユーザー双方に負担がかかってしまいます。そのため、日頃からサポートしている最新の OS でアップデートしてもらうよう促す対応や、定期的にリマインドを行うことで、地道に数を減らしておく活動が必要です。来期は早い段階で Slack やメール等のアナウンス・Jamf からのメッセージ通知などを組み合わせてユーザーに通知していくことで、EOL 付近に対応が集中しないよう取り組んでみたいと思います。

学んだこと②：Bot よりも人からの連絡の方がレスポンスがよい傾向

ユーザーへの対応依頼の方法についても1つ学びがありました。 Bot などのシステムアカウントから機械的に連絡するよりも、担当者からなど人に紐づいたアカウントから連絡したほうが明らかにレスポンスがよいという傾向がありました。特に台数が少なくなってきた段階で、個別の声掛けやフォローをすることで対応が進むというケースが多かったです。もちろんこれらの対応は最小限に抑えるべきだと考えていますが、最後の追い込み手段としてはより効果的な手段であると感じました。また、弊社ではコミュニケーションの手段が主にSlackとメールになっているため、その両方で連絡を取ることで見落としなどを減らし、対応率を上げることができました。来期はよりユーザーの目に入る手段として、対象端末に対して Jamf からメッセージを表示したりという方法も試してみたいと思います。

まとめ

本記事では古い OS の撲滅対応に関する取り組みを紹介しました。毎年大変な対応になりますが、IT 管理者として組織全体のセキュリティを担保する上で欠かせない取り組みであると感じています。一方で対応のたびにユーザーの手を止めてしまうのも事実です。今後も、できるだけユーザーに負担をかけない形で、安全な環境を維持できるよう運用や仕組みを工夫していきたいと思います。