古いChromeでしか使えない業務、例外期限と移行計画の決め方

古いChromeでしか使えない業務、例外期限と移行計画の決め方。この記事は2026年10月21日に確認できた公式情報を起点に、古いChromeでしか使えない業務、例外期限と移行計画の決め方という疑問に答えるための確認手順を整理します。自社で対象か分からない項目は推測で埋めず、管理担当や提供元へ確認してください。

例外期限の設定基準とリスク評価

業務で必要なChromeバージョンの特定方法

業務で使用しているWebアプリや社内ポータルを一覧化し、各画面で利用しているChromeの機能（例：WebRTC、PDFビューア、特定のJavaScript API）を確認します。担当者には、利用中の機能がどのバージョンで初めてサポートされたか、または旧バージョンでしか動作しないカスタムスクリプトがあるかをヒアリングしてください。

取得した情報は、バージョン別の依存表としてまとめ、旧バージョンが必須になる業務とその根拠を明示します。これにより、例外対象となる業務範囲と、代替策検討の出発点が整理できます。

セキュリティリスクの定量的評価手順

JPCERT/CCの週報で指摘されたChromeの脆弱性情報を、対象業務の影響度と照合します。具体的には、脆弱性がリモートコード実行や情報漏洩につながるかを評価し、業務への直接的な被害シナリオを想定します。

担当者には、該当脆弱性が利用している機能に関係するか、リスクが顕在化した場合の業務停止時間や顧客への影響を数値化する質問を用意し、スコア化した結果をリスクマトリクスに落とし込みます。スコアが一定以上の場合は、例外期限の短縮や早期移行を推奨する根拠となります。

例外期限の上限設定と社内承認フロー

古いChromeを使い続ける必要がある場合は、対応できない業務と、その理由を先に明らかにします。単に「例外を認めた」と記録するのではなく、代替方法を検討する担当と、いつ状況を見直すかを決めてください。期限を延ばすこと自体が対策にはなりません。

期間や承認する相手は自社の影響と管理体制に応じて判断します。新しい注意情報が出た場合や、業務システム側の対応が進んだ場合は、予定していた見直しを待つ必要があるかも確認します。例外の対象端末と、通常の更新を進める端末を混同しないようにします。

移行対象業務の選定と優先順位付け

代替機能・ツールの有無を確認するポイント

まず、旧Chromeでしか利用できない機能が社内ツールや外部サービスにどれだけ含まれるかをヒアリングします。代替ツールが既に市場に出ているか、社内で開発可能かを担当者に確認し、代替案の導入コストや学習コストを概算で把握します。

代替が不可能な場合は、例外対象外として除外し、代替が可能であれば移行対象に含めます。代替案の有無は、機能要件シートや提供元のサポート情報と照らし合わせて判断します。

例えば取引先が提供する業務画面を利用している場合、自社だけでは互換性の問題を修正できないことがあります。その場合も、古いブラウザを残すことだけで対応を終えず、提供元へ対応状況と代替方法を確認します。個人判断で別の端末やサービスへ顧客情報を移すことは避け、会社として利用できる方法かを責任者へ確認してください。

業務重要度と利用頻度での優先順位付け

業務を「重要度（顧客影響、法令遵守）」「利用頻度（日次・週次・月次）」の二軸で評価し、4象限のマトリクスに配置します。高重要度・高頻度の業務は最優先で移行計画に組み込み、低重要度・低頻度の業務は例外期限を長めに設定しつつ、将来的な統合を検討します。

担当者には、各業務の利用統計と影響範囲を提示してもらい、評価結果をレビュー担当者が確認し、優先順位リストを確定します。

すぐに移行できない条件の確認

取引先が提供する業務システムなど、自社だけでは変更できない条件がある場合は、提供元へ対応状況と代替方法を確認します。特定のブラウザの版が法令で義務付けられているという、未確認の条件を作って例外の根拠にしないでください。

また、社内で独自に開発したレガシーアプリがChromeの特定バージョンに依存しており、代替が技術的に不可能な場合も除外対象です。担当者には、こうしたケースを文書で提出してもらい、情報セキュリティ部門が例外の妥当性を検証します。

例外が認められた場合でも、期限とリスク管理策を明確に設定し、定期的な見直しを行うことが求められます。

移行計画の策定と実行ステップ

移行スケジュール作成時のマイルストーン設定

古いChromeへ依存する業務を整理したら、計画の一例として、調査、検証、業務で使う環境への切り替えを分けて担当と確認時点を決めます。これは公式に決められた段階や期間ではなく、自社の移行を整理するための案です。

各段階ごとの確認点には、担当者が確認すべき項目（例：対象端末リストの確定、バックアップ完了の有無）をチェックリスト化し、完了サインを取得できるようにします。

次に、作業の各段階で、担当者と次の確認時点を決めます。注意情報の緊急度と業務の依存関係を踏まえ、移行を待つ間の扱いも責任者へ確認してください。今回の案内から一律の移行期間が決まるわけではありません。期限が近づいたらリマインダーを自動配信し、担当者が遅延なく作業を進められるようにサポート体制を整えておくことが重要です。

テスト環境での互換性検証手順

テストは本番環境と同等の構成を持つ本番とは別の検証環境で実施し、旧 Chrome 専用機能が新バージョンでも正常に動作するかを確認します。具体的には、対象業務で使用する Web アプリや社内ツールを新 Chrome に切り替えて操作し、エラーログや画面表示の差異を記録します。

検証で問題が見つかった場合は、ロールバック手順を事前に用意し、担当者が即座に旧バージョンへ戻せるようにします。ロールバックの可否はテスト開始前に確認し、失敗時の連絡先や対応フローをドキュメント化しておくと、トラブル時の混乱を防げます。

移行完了後の検収基準と報告方法

移行が完了したら、担当者は「動作確認レポート」を作成し、対象業務が新 Chrome で問題なく実行できることを証明します。レポートには、テスト項目一覧、実施結果、残課題の有無を明記し、承認者の完了の了承を取得します。

報告は社内の情報共有ツールに添付し、関係部門へメールで周知します。承認が得られたら例外設定を解除し、旧バージョンの利用停止手続きを実施します。検収完了後は、定期的なアップデート確認のスケジュールを再設定し、同様の課題が再発しないようにします。

担当者への質問と依頼、進捗管理のポイント

例外期限設定時に確認すべき質問リスト

例外期限を設定する際は、まず「対象業務はどの Chrome バージョンに依存しているか」を担当者に確認します。次に、代替ツールや機能が存在するか、導入コストや学習コストはどの程度か、という点を具体的に質問します。

さらに、脆弱性情報に基づくリスク許容度を尋ね、期限内に更新できない場合の影響範囲（例：顧客データの取り扱い、法令遵守）を明確にします。回答は文書化し、上長の承認を得たうえで例外期限を正式に設定します。

移行作業依頼時の指示書作成要点

作業依頼書には、対象端末リスト、実施範囲（Chrome のみ更新か、関連プラグインも含むか）を明記し、期待する結果（例：全端末でバージョン 119 以上に統一）を具体的に記載します。失敗時の連絡先と責任者への連絡先も必ず記載し、担当者が迅速に対応できるようにします。

完了報告の形式は、作業実施日時、実施者、確認項目のチェックリスト、問題があった場合の対策報告を含むレポートとします。これにより、上長や監査部門が作業の妥当性を容易に評価でき、次回以降の更新計画にも活用できます。

進捗遅延時のフォローアップと再スケジュール手順

進捗が遅延した場合は、まず担当者に遅延理由をヒアリングし、影響範囲を再評価します。理由が技術的課題であれば、追加リソースや外部提供元の支援を検討し、必要に応じて期限を延長します。

再スケジュールの際は、延長した期限と新たな段階ごとの確認点を文書化し、承認者の完了の了承を取得します。その後、関係者全員に改訂版スケジュールを共有し、進捗管理ツールでリアルタイムに更新状況を可視化することで、再度の遅延を防止します。