FirefoxとThunderbirdの脆弱性情報、会社で確認する製品と版

FirefoxとThunderbirdの脆弱性情報、会社で確認する製品と版。この記事は2026年10月21日に確認できた公式情報を起点に、FirefoxとThunderbirdの脆弱性情報、会社で確認する製品と版という疑問に答えるための確認手順を整理します。自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

対象製品とバージョンの特定方法

社内資産一覧から対象を抽出

社内で管理している資産一覧（IT資産管理システムやスプレッドシート）に、ソフトウェア名とインストール状況の項目を追加します。まず、資産管理担当者が「Firefox」および「Thunderbird」の文字列を検索し、該当端末を抽出します。

抽出結果は、端末ID、OS、設置部署、インストール日を含む表形式で保存し、関係部門へ共有します。次に、抽出した端末リストを元に、実際に利用中のバージョンが最新かどうかを確認する作業へと移ります。リスト化した情報は、定期的なレビュー時に更新できるよう、バージョン管理用のフォルダに保存しておくと、過去の変更履歴が追跡しやすくなります。

バージョン情報取得の標準コマンド

FirefoxやThunderbirdの利用版を調べる方法は、端末の管理方法や導入形態によって異なります。会社で管理している配布と、社員が個別に導入したものを分け、どこまで確認できるかを担当者へ聞いてください。

報告では、製品名、対象端末、稼働中の版、確認日を揃えます。調べられない端末や、管理情報と実際の表示が一致しない端末は、確認済みと混ぜないようにします。経営者自身が設定ファイルや権限を変更する前提ではなく、管理できる相手へ照合を依頼します。

ESRと通常版の区別基準

Firefox ESR（Extended Support Release）は、長期サポートが前提のバージョンであり、通常版と比べて更新頻度が低く、企業向けに安定性が重視されています。

区別基準としては、インストール時のインストーラ名に「esr」が含まれるか、設定画面の「About Firefox」ページで「ESR」の表記があるかで判定します。資産管理表には「製品種別」列を設け、ESRか通常版かを明示的に記録します。

管理対象外とする例外端末（テスト環境やレガシー端末）は、別シートに一覧化し、除外理由と担当者名を必ず記載しておくことで、後日の監査時に説明が容易になります。

脆弱性情報の取得と整理

Mozilla公式アドバイザリの取得手順

担当者は、Mozilla が提供する MFSA（Mozilla Security Advisory）ページを週次で自動取得するスクリプトを設定します。取得失敗時は、手動でページを確認し、取得ログにエラー内容と再取得日時を記録します。

取得したアドバイザリは、HTML 版を社内のセキュリティ共有フォルダに保存し、ファイル名に「MFSA2026-106」などの識別子と取得日を付与します。さらに、アドバイザリの要点（影響製品、脆弱性概要、修正バージョン）を要約したサマリシートを作成し、関係部門へメールで配布します。

このサマリは、次回の脆弱性対応ミーティングで議論材料として利用できるよう、過去のサマリと同様のテンプレートで管理します。

影響範囲の社内マッピング方法

取得したアドバイザリの「影響製品・バージョン」情報と、資産一覧表のバージョン列を照合します。照合は、Excel の VLOOKUP 関数やスクリプト言語のマッピングロジックを用いて自動化し、影響がある端末を抽出したリストを作成します。

抽出結果には、端末ID、担当部署、現在のバージョン、必要な更新バージョンを記載し、優先度（高・中・低）を付与します。優先度は、業務重要度やインターネット接続の有無で判断し、上位の端末から順に更新作業を計画します。マッピング結果は、定期的にレビューし、追加インストールやバージョンアップがあった場合は随時反映させます。

例外端末の除外条件と記録方法

例外端末は、テスト環境やレガシーシステム、サードパーティ製アプリとの互換性が確認できない端末などが該当します。除外条件は、①本番業務に直接関与しない、②更新に伴う重大なリスクが予測される、③代替手段が確保できない、の三点で定義します。

除外対象となった端末は、別シートに「例外端末リスト」として記録し、除外理由、担当者、除外期間、再評価予定日を必ず記入します。記録は社内のコンプライアンスフォルダに保存し、定期レビュー時に再評価の有無をチェックします。除外が解除された場合は、速やかに通常の脆弱性対応フローに組み込み、更新作業を実施します。

修正プログラム適用の手順と確認

修正版番号の取得と比較方法

担当者は、Mozilla が公開しているアドバイザリページ（例：mfsa2026-106）から修正版番号を取得し、社内資産管理表に記載された Firefox／Thunderbird のバージョンと照合します。まず、管理表の「製品名」「バージョン」列を抽出し、取得した修正版番号と一致しないエントリをリスト化します。

照合ツールが利用できない場合は、Excel の VLOOKUP などで手作業でも同様の比較が可能です。照合結果は、未適用端末リストとして CSV 形式で保存し、次工程の自動更新設定確認に引き渡します。

なお、カスタムビルドや提供元独自のパッチが適用されている端末は、修正版番号が公式と異なるため、別途担当者がコメント欄に理由を記載し、例外として管理します。

自動更新設定の有無確認

自動更新が有効かどうかを確認する際は、実際に端末の設定画面で「更新」に関する項目を見て判断します。画面上の表示だけで判断できない場合は、管理ツールで取得できる情報と照らし合わせ、一覧にまとめると全体像が把握しやすくなります。

更新が無効になっている端末については、最新のパッチを適用する手順を作成し、担当者に配布する必要がありますが、まずは「更新が無効」と判断した根拠を明確にしておくことが重要です。設定ミスの可能性がある場合は、実際に更新操作を試みて結果を記録し、問題が再現できるかを確認します。

また、テスト環境や古いOS上の端末は手動での更新が前提になることがあるため、例外として扱う端末のリストを別途用意しておくと管理がしやすくなります。

担当者に確認すべきポイント

1. 各端末で「更新」設定が有効かどうか、実際に画面を確認した結果を教えてください。
2. 管理ツールで取得した情報と端末の画面表示に食い違いがないか、具体的にどの端末で差異があったかを教えてください。
3. 更新が無効と判断した端末について、最新パッチを適用する手順を作成する際に必要な情報（例：担当者の連絡先、配布方法）を教えてください。
4. 設定ミスが疑われる端末で、更新操作を実施した結果とその記録の保存方法を確認したいのですが、どのように対応すればよいか教えてください。
5. 手動更新が前提となるテスト環境やレガシーOSの端末リストはありますか。あれば、一覧を共有してください。

これらの質問に対する回答をもとに、全体の更新状況を正確に把握し、必要な対応を計画できます。

適用後の動作検証と受入基準

更新を適用した後は、主要な機能が正常に動作しているかを確認する必要があります。まず、Firefox でページの表示やスクリプトの実行、拡張機能の起動が問題なく行えるかを確認してください。Thunderbird については、メールの送受信やアドオンの有効化、検索機能が期待通りに動くかをチェックします。

このとき、エラーログに異常が記録されていないかを確認することが重要です。

確認結果は、どの端末でどの項目をテストしたか、合格か不合格か、そして必要に応じた備考をまとめた一覧に整理すると、後からの追跡がしやすくなります。もし不合格となった場合は、原因を特定したうえで、以前の状態に戻す手順や再度更新を行うかどうかを検討します。全ての端末で合格と判断できた時点で、次の工程へ進む旨を報告できるようにしてください。

担当者に確認すべきポイント

1. 現在使用している Firefox と Thunderbird のバージョンは何か、そして脆弱性修正が適用された最新版に更新したか。
2. 各機能（ページ表示、スクリプト実行、拡張機能、メール送受信、アドオン、検索）の動作確認を実施したか。その結果はどこに記録しているか。
3. エラーログに異常が記録されていないか、確認方法と保存場所はどこか。
4. 不合格となった端末がある場合、原因の一次的な分析結果と、復旧手順（以前のバージョンに戻すか、再度更新を試みるか）についての方針は決まっているか。

これらの質問に対する回答を得ることで、更新後の動作確認が適切に行われているか、次の工程へ進む判断材料が揃うことになります。

報告・記録・フォローアップ体制

脆弱性対応結果の報告書作成

担当者は、対応結果をまとめた報告書を作成します。必須項目は「対象製品」「対象バージョン」「修正版番号」「適用日時」「自動更新設定の有無」「検証結果」「例外端末一覧」「次回対応予定」の８項目です。報告書は PDF 形式で保存し、社内の情報セキュリティ部門と経営層へメールで共有します。

例外端末については、理由と今後の対策を別表に記載し、リスク評価と併せて提示します。報告書の承認フローは、担当 → 部門長 → 情報セキュリティ統括の順で電子署名を取得し、最終版を社内文書管理システムに格納します。

未対応端末のエスカレーション基準

未対応の端末が残った場合は、利用していない端末なのか、更新が失敗しているのか、業務上の理由で保留しているのかを分けます。同じ未対応でも、次に必要な作業は異なります。

更新できない理由と、注意情報の影響を管理担当と責任者へ共有し、対応の優先順位を決めます。一律の時間を基準にせず、利用状況と公式案内を踏まえて判断してください。端末を停止したり接続を制限したりする必要があるかも、業務への影響を含めて個別に確認します。

定期レビューと次回対応計画

対応完了後は、定期レビューを実施し、プロセスの改善点を抽出します。レビューは、担当者、部門長、情報セキュリティ統括の３名で構成し、以下の項目を議題とします：① 脆弱性情報取得の遅延有無、② 自動更新設定の適用率、③ 検証不合格の原因分析、④ 責任者への連絡の適切性。

議事録は文書化し、次回の脆弱性対応計画に反映させます。次回計画では、取得スケジュールの自動化や、例外端末の事前把握手順を追加し、同様の脆弱性が発生した際の対応時間短縮を目指します。