リクルーティングサイト
テックブログ

Android月例パッチを読み解く：端末管理（MDMなし想定）でも事故らせない更新設計

Android月例パッチを読み解く：端末管理（MDMなし想定）でも事故らせない更新設計

会社でAndroid端末を業務利用しているのに、MDM（モバイルデバイス管理ツール）はまだ入っていない……という状況は珍しくありません。
その場合でも、月例パッチをちゃんと読み解き、壊さず・漏らさずに更新を回す設計をしておくと、事故リスクをかなり減らせます。

この記事では、

  • Android Security Bulletin（ASB）をどう読むか
  • MDMなしで「誰の端末がどこまで更新されたか」をどう把握するか
  • 壊さない段階ロールアウト（リング運用）の考え方
  • OEM/キャリア差や配信遅延をどう運用で吸収するか

といったポイントを整理します。
技術的な深掘りというより、運用設計に重心を置いて説明していきます。

1. 月例パッチの基礎：まず“何が出ているか”を正しく読む

1-1. Android Security Bulletin（ASB）の読み方

Androidのセキュリティ更新は、毎月の Android Security Bulletin（ASB） でまとめて公開されます。

ASBで最低限見ておきたいポイントは次の3つです。

  • どのコンポーネントが対象か（Framework / System / Kernel / Qualcomm / Google Play system など）
  • Severity（重要度）：Critical / High / Moderate / Low
  • CVE番号：具体的にどんな脆弱性なのか（リモートコード実行、権限昇格、情報漏えいなど）

運用の観点では、細かい技術内容を全部読むのではなく、

  • 「リモートコード実行（RCE）」や「権限昇格（EoP）」でCritical/Highが多い月は優先度高
  • 「カーネル」や「モデム」など、攻撃成功時の影響が大きいコンポーネントが多い月も注意

といった見方をすると、「どの月を急ぐべきか」が判断しやすくなります。

1-2. 2段階パッチレベルの意味

ASBでは、セキュリティパッチレベルがよく次のような2つの値で表現されます。

  • YYYY-MM-01（例：2025-12-01）
  • YYYY-MM-05（例：2025-12-05 / 2026-01-05 など）

ざっくりいうと、

  • YYYY-MM-01：OS共通部分（AOSP側）の修正を含む最低ライン
  • YYYY-MM-05：それに加えてベンダー（SoC / OEM）依存部分まで含んだ、より網羅的なパッチ

というイメージです。
ASBのページには、「パッチレベルがこの日付以上なら、ここに書かれた脆弱性は修正済みです」という説明があるので、運用では

  • 自社の要求ラインをどちらに置くか（01でよいのか、05まで必須か）

をあらかじめ決めておきます。

1-3. “Exploited in the wild”がある月の優先度

近年のASBでは、「Exploited in the wild（実際に悪用確認済み）」の脆弱性が明記されることがあります。
この表現がある月は、攻撃がすでに出回っていると考えられるため、次のような運用に寄せるのがおすすめです。

  • 通常の月：月次でまとめて更新（後述のリング運用を前提）
  • 悪用確認ありの月：
    ・業務端末は即日〜数日以内を目標
    ・BYOD（個人端末）でも「ほぼ例外なく早める」方針

ここを「だいたい同じ月内ならOK」で流してしまうと、攻撃が走っている月に穴が空いたままになります。
ASBを読みながら「優先度A（即日）」「B（1週間）」「C（通常月次）」のように、ざっくりランク付けしておくと判断しやすいです。

2. MDMなしで把握する：端末台帳と更新状況の集め方

2-1. 最低限の台帳項目

MDMがないと「どの端末がどの状態か」を自動で取れないので、少なくとも次のような項目を管理する台帳（スプレッドシートなど）が必要です。

  • ユーザー名 / 所属
  • 機種名（例：Pixel 8a, Galaxy Sシリーズなど）
  • Androidバージョン（例：14, 15）
  • セキュリティパッチレベル（例：2025-12-05）
  • Google Play システムアップデートの日付
  • キャリア / OEM（SIMフリー, docomo版など）

台帳は「1人1行」にしておくと、未更新の人を探しやすくなります。

2-2. 情報の集め方：手で回す現実解

MDMなしでは、どうしても人力の収集が必要になります。現実的なやり方としては、

  • Googleフォームや社内フォームで「スクリーンショット＋入力」を提出してもらう
  • Slack / Teams で「この週はパッチウィークです」と告知し、スクショを貼ってもらう
  • 月1回のリマインド（リーダー向け・全社向け）をテンプレ化

といった方法があります。
スクショで集めるときは、

  • 「設定」→「デバイス情報」→「Androidバージョン」→「セキュリティアップデート」

など、どの画面を撮ればいいかを画像付きで案内しておくと、ミスが減ります。

2-3. “更新できない端末”を早期にあぶり出す

集めた台帳を見ていると、必ず次のような端末が出てきます。

  • サポート期限切れで、そもそも最新パッチが降ってこない機種
  • ストレージ不足で、ダウンロードはできるがインストールできない端末
  • キャリア / OEM の都合で、毎回数週間遅れて配信される機種

これらを「例外扱いのまま放置」すると、会社全体のリスクが下がりません。
台帳を作る一番のメリットは、こういう「更新できない端末」を可視化できることです。

見つけた時点で、

  • 買い替え対象としてリストアップする
  • 業務アプリの利用を制限する（社内メールやチャットだけOKなど）
  • 一時的にクラウド側の権限を絞る

といった代替策を決めておくと、「危険なのは知っていたけどそのまま」という状態を防げます。

3. 更新ポリシー設計：いつ・誰が・どこまで更新するか

3-1. ルールの粒度：即日／1週間以内／月次

なんとなく「出たら早めに更新しましょう」だと、結局誰も動きません。
そこで、ASBの内容に応じて次のようなルールを決めておくと運用しやすくなります。

  • 即日〜数日以内：
  • 「Exploited in the wild」あり
  • CriticalのRCEや認証回りの脆弱性が目立つ月
  • 1週間以内：
  • Critical/High の件数が多いが、悪用確認までは出ていない月
  • 月次でまとめて：
  • 重要度がModerate中心の月

この「SLA（いつまでにやるか）」をざっくり決めておくと、
「今月はどれくらい急ぐべきか？」をASBを読みながら判断しやすくなります。

3-2. 適用対象の切り分け：業務端末とBYOD

会社によっては、「会社支給端末」と「個人端末（BYOD）」が混在しているケースもあります。
この場合、対象を次のように分けて考えると整理しやすくなります。

  • 業務アカウントを設定している端末（支給・BYOD問わず）：
  • パッチレベルの最低ラインを会社側で定める（例：YYYY-3ヶ月前まで など）
  • 一定期間未達なら業務アプリの利用を制限する方針を明記
  • 完全に個人用で、会社アカウント未連携の端末：
  • 推奨としての案内はするが、強制まではしない（範囲外）

「会社アカウントを入れた時点で、このポリシーに同意したものとみなします」といった合意をとっておくと、後からトラブルになりにくくなります。

3-3. “例外”の扱いを決めておく

どうしても「今月はアップデートできません」という人は出てきます。
このとき、毎回個別に判断すると運用が回らなくなるので、次のようなルールをあらかじめ決めておきます。

  • 猶予期限：
    ・例：通常は1週間以内、例外申請があっても最大2週間まで など
  • 代替策：
    ・業務アプリの利用制限（メールだけOKなど）
    ・リモートアクセスの禁止
  • 是正フロー：
    ・期限までに未更新の場合 → 上長と情報システムがセットでフォロー

「例外は出てもいいが、例外のまま放置しない」ための仕組みを作っておくことが大切です。

4. 段階ロールアウト（リング運用）：壊さずに進める

4-1. リング設計：パイロット → 一般 → 遅延組

OSアップデートは、たまに「特定機種で不具合が出た」ということがあります。
これを全部いきなり更新してしまうと、業務が止まるリスクが高くなります。

そこでよく使われるのが、リング運用（段階ロールアウト）です。

  • リング1：パイロット
  • 情報システムやITリテラシーが高めのメンバー
  • 新しいパッチを最初に適用して様子を見る
  • リング2：一般
  • 問題がなければ、社内の大半へ適用
  • リング3：慎重派・特殊端末
  • 業務アプリが特殊な端末など、少し遅らせて適用

「パイロットで数日〜1週間様子を見て、問題がなければ一般へ展開」という形にしておくと、
もしOS側のバグがあった場合も、影響範囲を小さくできます。

4-2. 告知テンプレ：毎月使い回せる形にする

毎月の更新案内は、テンプレ化してしまうのがおすすめです。含めたい内容は次のとおりです。

  • 対象端末（例：業務アカウントが設定されているAndroid端末）
  • 今回のパッチのポイント（Exploited in the wildの有無、Criticalの件数など）
  • いつまでに更新してほしいか（例：1週間以内）
  • 更新手順（設定 → システム → システムアップデート など、OSのメニュー）
  • 所要時間と注意点（Wi-Fi接続、充電、再起動が必要になる、など）
  • トラブル時の連絡先（情報システム窓口）

これを社内チャットやメールで毎月同じフォーマットで流しておくと、
「今月もいつものやつね」と認識してもらいやすくなります。

4-3. 失敗時の打ち手：一時停止と共有

パッチ適用後に、大きめの不具合が出ることもあります（例：特定機種で通信が不安定になるなど）。
その場合は、

  • 新規の更新を一時停止する（リング2以降を止める）
  • 起きている不具合と対象機種を社内チャットで共有する
  • OEMやキャリア側の情報（既知の問題かどうか）を確認する

という流れをあらかじめ決めておくと、現場が混乱しにくくなります。

5. “更新したつもり”を防ぐ検証：確認ポイントを固定する

5-1. 確認項目：パッチレベルの日付を揃える

「設定画面を開いただけで、実際にはインストールされていなかった」というケースもあります。
更新後に見るべきポイントを固定しておくと安心です。

  • Android セキュリティパッチレベルの日付が、目標としている日付以上になっているか
  • ASBの「このパッチレベル以上ならOK」という説明と一致しているか

「2026-01-01 のASBに対して、パッチレベルも 2026-01-01 以上になっている」など、
ASBとパッチレベルをセットで確認する運用にしておくと、「更新したつもり」を防げます。

5-2. OS更新とGoogle Playシステムアップデートの違い

最近のAndroidでは、「OSのセキュリティパッチ」と「Google Playシステムアップデート」が別物になっている場合があります。

  • OSのセキュリティパッチ：端末メーカー（OEM）やキャリア経由のアップデート
  • Google Play System Update：Google Play 経由で配信されるコンポーネント更新

運用としては、次の2つを両方見るようにします。

  • セキュリティパッチレベル（YYYY-MM-01 / 05）
  • Google Play システムアップデートの日付

「どちらか片方だけ古い」というパターンもあるので、
台帳にはこの2つを別の列として持つのがおすすめです。

5-3. 監視の代わりに“不達率”をKPIにする

MDMがないとリアルタイム監視は難しいので、代わりに未更新率（不達率）をKPIにするのが現実的です。

  • 月次の棚卸しで、「ターゲット日から2週間経っても未更新の端末の割合」を出す
  • 未更新者に個別フォローし、理由を確認する（サポート切れ・容量不足・意識の問題など）
  • 改善策（買い替え、容量確保の支援、教育）を次の月に反映する

数字で見えるようにしておくと、経営層や上長にも説明しやすくなり、「端末更新にもちゃんとコストを割くべきだ」という話につなげやすくなります。

6. OEM/キャリア差・遅延への備え：運用設計で吸収する

6-1. Pixelとその他で配信タイミングがズレる前提を置く

一般的に、Google Pixel などの「Google直系端末」は月例パッチの配信が早く、
他メーカー端末は数日〜数週間遅れることがあります。

そのため、運用としては最初から「メーカー別に配信タイミングがズレる」前提を置きます。

  • Pixel系：リング1（パイロット）に積極的に使う
  • その他メーカー：メーカーのセキュリティ更新ページを見ながら、配信を確認して進める

「Pixelだけ先に進めて、他は数日待つ」というルールを制度として決めておくと、
毎回「まだ来てないんですが大丈夫ですか？」という質問を減らせます。

6-2. メーカー別の情報源を決める

端末メーカーによっては、月例のセキュリティ更新情報をまとめて公開しています。
代表例として、Samsung などが専用ページを持っています。

運用では、

  • 社内で利用している主要メーカーごとに「情報を見る場所」をリスト化
  • 月次でASBと合わせてチェックする担当を決めておく

といった形にしておくと、「この機種にはいつ来るのか？」を調べる手間を毎回ゼロからやらずに済みます。

6-3. サポート切れ端末の出口戦略

どんなに頑張っても、OSサポートが切れた端末には新しいパッチは来ません。
これを「仕方ない」で終わらせると、そこから事故が起きます。

出口戦略として、次のようなルールを決めておきます。

  • 買い替え基準：
    ・「セキュリティパッチが12ヶ月以上古い端末は業務利用不可」など
  • 業務利用の制限：
    ・サポート切れ端末は、社内メールや社内ポータルなど、リスクの低い用途に限定
  • 計画的な更新：
    ・年度ごとに「何台買い替えるか」を予算化

「古い端末をいつまで許すのか」をルール化しておくことで、
止めやすいラインをチームで共有できます。

7. まとめ

7-1. MDMなし運用のコア3点

MDMがなくても、次の3つが回っていれば「とりあえず事故りにくい状態」には近づけます。

  • ASBで優先度を決める：Exploited in the wild や Critical/Highの多さを見て、即日／1週間／月次のバケツに分ける
  • 台帳で未更新を潰す：機種・パッチレベル・Google Playシステム更新日を人力で集め、未達者を把握する
  • リングで壊さない：パイロット → 一般 → 慎重組の順で段階ロールアウトし、不具合があれば途中で止める

7-2. 悪用確認・Critical多めの月は“例外なく早める”

最後に、運用の心構えとして大事なポイントをまとめます。

  • 「悪用確認あり」や Critical多めの月は、例外なく前倒しで対応する
  • それ以外の月は、月次で淡々と回すことで疲弊を避ける
  • 更新できない端末は「台帳であぶり出し → 代替策 → 出口戦略」までセットで考える

完璧な管理はMDMがあっても難しいですが、
「何を見て優先度を決めているか」「どこまで行けばOKとするか」をチームで揃えておくだけでも、事故る可能性はかなり減らせます。

8. 参考リンク

関連記事