SONAE KNOWLEDGE / 会社の備え

パソコンの更新、社員任せになっていませんか?端末台帳と更新確認の始め方

AI技術確認日:2026-10-23/編集確認は未了

AIを用いて初稿を作成し、技術確認もCodex(AI)が実施しています。一次資料との対応、記述とひな型の整合性を確認しました。専門家による監修ではありません。運営者の判断で先行公開しています。本人による編集確認は未了です。確認範囲は運営と編集のページをご覧ください。

社員2人がパソコンの更新画面と端末台帳を確認する場面のイラスト
更新したことまで、確かめる。SONAE / AI生成のイメージ

「自動更新をオンにした」から、更新されたことを会社で確かめる運用へ。

更新の設定と、完了の確認を分ける

IPAの「中小企業の情報セキュリティ対策ガイドライン 第4.0版」は、情報セキュリティ6か条の一つとして、OSやソフトウェアに修正プログラムを適用する、または最新版を使うことを示しています。会社ではその方針に加え、誰が更新状態を確認するかまで決める必要があります。以下はSONAEの運用例です。自動更新が有効でも、長期間電源が入っていない端末や、再起動が保留された端末がないかを確かめます。更新済みと判断する根拠を、社員の記憶だけに頼らない形にしましょう。

SONAE KNOWLEDGE / 図解 01

未完了を、ひとまとめにしない。

  1. 再起動待ち

    更新の処理が残っている

    利用者と実施時期を確認。

  2. 未確認

    状態を把握できていない

    調べる担当と方法を決める。

  3. 更新できない

    互換性・サポートなどの課題

    理由・代替策・解消期限を記録。

社内台帳の分類例です。実際の更新状態は、製品の管理画面や記録で確かめます。

まずは使っている端末とソフトを一覧にする

会社で管理するパソコン、持ち出す端末、業務に使うスマートフォンなどを挙げ、利用者と管理する人を結びつけます。OSだけでなく、ブラウザー、業務アプリ、周辺のネットワーク機器なども確認対象になり得ます。製品名、バージョン、サポートの状態、確認日、情報の取得方法を記録してください。一度に全部調べられない場合は対象範囲を明記し、未確認を空欄のまま放置せず分類します。台帳にパスワードやライセンスキーを貼る必要はありません。

SONAE KNOWLEDGE / 図解 02

設定した後に、適用と業務を確かめる。

設定した後に、適用と業務を確かめる。自動更新がオンでも完了の証拠にはなりません。再起動が必要か、業務で使えるかは製品ごとに確認します。対象を特定製品・版・管理担当更新を計画承認・時期・影響結果を確かめる適用・再起動・業務互換性・支援終了の制約例外と期限を別管理設定した後に、適用と業務を確かめる。自動更新がオンでも完了の証拠にはなりません。再起動が必要か、業務で使えるかは製品ごとに確認します。対象を特定製品・版・管理担当更新を計画承認・時期・影響結果を確かめる適用・再起動・業務互換性・支援終了の制約例外と期限を別管理
自動更新がオンでも完了の証拠にはなりません。再起動が必要か、業務で使えるかは製品ごとに確認します。
図の内容を文章で読む

対象を特定:製品・版・管理担当 / 更新を計画:承認・時期・影響 / 結果を確かめる:適用・再起動・業務。自動更新がオンでも完了の証拠にはなりません。再起動が必要か、業務で使えるかは製品ごとに確認します。 互換性・支援終了の制約:例外と期限を別管理。

定期確認と、緊急の確認を分けておく

通常の更新については、利用者への連絡、業務を止められる時間、更新後に確認する操作を決めます。一方、利用中の製品に緊急の注意喚起が出た場合に誰が内容を読み、対象か判断し、対応を依頼するかも用意します。次の定例日まで必ず待つ、といった一律のルールは避けます。優先度や適用方法は、製品提供元の情報と自社の利用状況から判断してください。具体的な脆弱性の影響や対応期限を、この記事だけで決めることはできません。

更新できない端末を、例外として管理する

業務アプリとの互換性やサポート終了などが理由で、すぐ更新できないこともあります。その場合は理由、業務への影響、責任者、代替策、解消する期限を記録します。更新をずっと先送りする承認にはせず、交換や業務の移行も含めて検討してください。外部事業者が管理する機器なら、変更できる範囲と作業の窓口を先に確認します。更新前のバックアップや戻し方、更新後の動作確認も、製品と業務に合った方法で準備します。

一台の完了記録から始める

架空の例として、持ち出し用PC一台の更新を確認するなら、対象の管理番号、OSと業務アプリの状態、確認日、実施者、再起動や業務の動作確認、残った課題を記録します。「全台対応済み」と書くのは、合意した範囲をすべて確認してからです。管理ツールがある場合はその記録を活用し、ない場合も小さな台帳から始められます。未確認や未完了の件数を経営・管理部門と共有し、対応する人と次の確認日を決めることが、継続するための一歩です。

社内で使う記録のひな型

SONAEの運用例・架空データです。実際の秘密情報をこの画面へ入力する欄ではありません。

対象の特定
架空管理番号 PC-001/利用部署と管理担当
確認した状態
OS・業務アプリの状態、確認日、情報の取得方法
未完了と例外
再起動待ち・未確認・更新不可を区別し、担当と期限を記録
完了の根拠
更新結果・業務の動作確認・残課題・確認者

CASES / 2026年10月23日確認

実際の事例から、備えを考える。

以下は公表資料をもとにした要約です。SONAEの診断実績ではありません。自社への適用は、下の問いと分けて考えます。

公的機関の調査

国内Webサービスへの攻撃とAI利用の調査

公表・更新
2026年10月15日
発生・観測
2026年10月8日の注意喚起に関連する調査。各攻撃の日時を一律に示すものではありません。

JPCERT/CCは、攻撃元サーバーの調査で、AIを使った脆弱性探索やAPI経由の攻撃を確認したと報告しています。

確認範囲:すべての国内事案が同じ攻撃者・手口・AIによるものと示す報告ではありません。

自社で確かめたいこと / SONAEの整理

自社の公開サービス、管理用画面、APIの管理担当と更新状況を把握できていますか。

一次資料:JPCERT/CC ↗

被害企業の調査結果

アサヒグループ:侵入・暗号化と業務影響

公表・更新
2026年2月18日
発生・観測
障害・暗号化の発生:2025年9月29日。侵入はその約10日前と推定。

アサヒグループは、ネットワーク機器経由の侵入、管理者権限の奪取、複数システムの暗号化などの調査結果を公表しました。

確認範囲:発生年は2025年です。公表されていない機器の詳細やAI利用、MFAの状態を推測していません。

自社で確かめたいこと / SONAEの整理

侵入後の影響範囲、管理者権限、業務を戻す順番と判断する担当を把握していますか。

一次資料:アサヒグループホールディングス ↗

相談前の確認表

  • 端末・利用者・管理担当が一覧になっている
  • OSと業務ソフトの状態を確認する方法が決まった
  • 緊急の注意喚起を見る担当と連絡先がある
  • 未更新の理由・担当・解消期限を記録できる

参考資料(確認日:2026年10月22日):IPA:中小企業の情報セキュリティ対策ガイドライン 第4.0版(本文20ページ) ↗

一般的な説明とSONAEの運用提案です。製品の公式条件と自社の管理責任者の判断を確認してください。

端末と業務環境の点検内容を見る →