バージョンアップ影響調査｜更新前後の出力を全件突き合わせる

更新の報告に貼られた開発元の変更点の一覧は開発元が変えた箇所を並べたもので、自社のサイトで何が変わったかは更新前後の出力を全件突き合わせた差分の件数でしか分かりません。報告に足りないのは、更新の前と後で何を比べたかという範囲と、比べて出た差分の件数です。次の更新の前に外注先へそのまま頼める報告の項目を、当社のサイトで差分を数えた更新1回分の記録とあわせて示します。

当社の記録は自社のウェブサイト1つの更新1回分で、他の構成や業務システムにそのまま当てはまる結果ではありません。外部の記述は2026年10月30日に開いたIPA・JPCERT/CC・NISTの資料の範囲です。

バージョンアップの影響調査とは、更新したあとも以前と同じに動いていると言えるかを、更新前後の出力を比べて確かめる作業である

バージョンアップの影響調査とは、ソフトウェアを新しい版に上げたあとも以前と同じに動いていると言えるかを、更新の前と後の出力を比べて確かめる作業です。ここでいう出力は閲覧者や検索エンジンが受け取るもので、ウェブサイトならページの本文・タイトル・説明文・構造化データ（ページの種類や中身を検索エンジンが読める形で書いたデータ）・画像の参照を指します。業務システムなら、画面・帳票・書き出したファイルが出力に当たります。上げるかどうかを決める作業ではなく上げたあとの状態を確かめる作業なので、合否は更新前後の差分の件数で決めます。

IPA（独立行政法人情報処理推進機構）の「安全なウェブサイトの運用管理に向けての20ヶ条」は、（9）の項目でOS・サーバソフトウェア・ミドルウェアのバージョンアップをセキュリティ対策の基本としています。修正プログラムが公表されたら適用して脆弱性を解消するよう求めたうえで、バージョンアップするとそれまで動いていたウェブアプリケーションが正常に動かなくなる場合があるので事前の検証が必要だとしています（IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」／2026年10月30日閲覧）。影響調査は、この事前の検証を差分の件数という形で残す作業です。

図は影響調査を6つの段に分けて左から右へ並べ、各段の下に次の段へ進んでよい条件を書いたものです。外注先からの報告で発注側が確かめるのも、それぞれの段で何を比べて何件の差分が出たかです。報告が「動作に問題はありません」の一文だけなら、6つの段のどこまでを通ったかは分かりません。

まず更新の根拠を、開発元の更新情報と、旧版と新版に該当する公開済みの脆弱性情報の件数で確かめる

根拠とは、なぜいま上げるのかを説明する材料で、開発元が出した更新情報と公開されている脆弱性情報の2つから取ります。開発元の更新情報は何が直ったかを教え、脆弱性情報は自社の版が対象に入っているかを教えます。脆弱性情報は旧版と新版の両方で引き、旧版に該当があって新版に無いことを確かめます。新版にも該当が残るなら、その更新で作業は終わりません。

国内で使われているソフトウェアの脆弱性を調べる入口には、JPCERT/CC（JPCERTコーディネーションセンター）とIPAが2004年7月から共同で運営するJVN（Japan Vulnerability Notes）があります。JVNに載るのは脆弱性が確認された製品とバージョン、脆弱性の詳細や分析結果、製品開発者が出した対策や関連情報へのリンクなどです（JPCERT/CC・IPA「JVN とは？」／2026年10月30日閲覧）。

自社の版と照らすのは、脆弱性レポートの「影響を受けるシステム」の欄です。この欄には影響を受けるシステム・製品・ライブラリなどの名称とバージョン番号が並びます。「公開日」はJVNで公開した日付で、同じ脆弱性の情報が開発元や海外の調整機関から出ていても一致しないことがあるため、JVNは必要に応じて開発元の情報も確かめるよう案内しています。開発元ごとの「ステータス」は「該当製品あり」「該当製品あり（調査中）」「該当製品なし」「該当製品なし（調査中）」「脆弱性情報提供済み」の5種類で、たとえば「該当製品なし」は開発元が調べた結果として該当する製品が無いことを表します（JPCERT/CC・IPA「脆弱性レポートの読み方」／2026年10月30日閲覧）。

海外の製品も含めて引くなら、米国のNIST（国立標準技術研究所）が持つNVD（National Vulnerability Database）があります。NISTによると、NVDは標準に基づいて表した脆弱性管理のデータを集めた米国政府のリポジトリです。中身にはセキュリティ関連のソフトウェアの欠陥・設定の誤り・製品名・影響の指標などのデータベースが含まれます（NIST「National Vulnerability Database (NVD)」／2026年10月30日閲覧）。製品名の書き方にはCPE（Common Platform Enumeration）という標準があり、個々にインストールされたものではなく製品の種類に名前を付けるので、ツールが同じ製品を一貫して見分けられます（NIST CSRC「Common Platform Enumeration (CPE)」／2026年10月30日閲覧）。旧版と新版を引き比べるときは、製品名と版を正確に書くことが前提になります。

20ヶ条は（4）で、日々公開されるソフトウェアなどの脆弱性対策情報を集めて蓄積したデータベース「JVN iPedia」を情報収集に使えると紹介しています（IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」／2026年10月30日閲覧）。IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版も自社診断の解説で、使っているソフトウェアに脆弱性が無いかをMyJVNバージョンチェッカで確かめることと、脆弱性があれば手順に沿って修正パッチを当てることを対策例に挙げています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月30日閲覧）。

2026年10月30日時点ではJVN iPediaとMyJVNがシステムメンテナンスのため停止中で（IPA（JVN iPedia）「サービス停止中」・JPCERT/CC「JVN iPedia、MyJVNサービスの一時停止のお知らせ (2026-10-22)」／2026年10月30日時点の記載）、その間はJVNの脆弱性レポートと開発元の更新情報を直接読んで旧版と新版のそれぞれが対象に入るかを確かめます。

当社の記録では、サイトの土台のフレームワーク（ページの組み立てや配信の仕組みをまとめた部品の集まり）の開発元がセキュリティ更新を出していました。10月24日の調査では、公開されている脆弱性情報のデータベースで旧版に該当する情報が20件あり、新版に該当する情報は0件でした。当社が更新の根拠として記録したのは、この開発元の更新情報と件数の2つです。

上げるべきかの判断と自社の何が対象かの見分け方は、PHPの脆弱性php2shellの記事に動いている環境から確かめる順番として書きました。この記事は、上げると決めたあとの確かめ方だけを扱います。

更新の前と後で同じものを作り、出力を全件突き合わせて差分の件数を数える

影響調査の中心は、同じ元のデータと同じ手順のまま版だけを変えて2回作ることです。ウェブサイトなら記事や設定は更新前のままにして土台の版だけを変え、サイトを組み立て直して出来上がったファイルを1つずつ比べます。業務システムでも考え方は同じで、同じ入力のデータを旧版と新版に通して画面・帳票・書き出したファイルを突き合わせます。

全件にするのは、土台の部品の変化がどのページに出るかを前もって言えないからです。抜き取りで何ページか見て差分が無くても、見ていないページについては何も言えません。変更点の一覧（開発元が出す更新内容の説明）が教えるのは、開発元が変えたつもりの箇所までです。

ウェブサイトで突き合わせる項目は、閲覧者と検索エンジンが受け取るものに絞れます。

• 本文: 見出しと段落の文字が欠けたり、順番が入れ替わったりしていないか
• タイトル: ブラウザのタブや検索結果に出るページの名前が前と同じか
• 説明: 検索結果に出る説明文が前と同じか
• 構造化データ: 記事の日付や会社名などを機械向けに書いた部分が前と同じか
• 画像の参照: 読み込む画像の場所と大きさの指定が前と同じか

比べる前に、日付や組み立てた時刻のように毎回変わる値を除く決まりを書いておきます。除く決まりを後から足すと、出た差分を消すための決まりになりやすいからです。出た差分は1件ずつ、意図した変更か・説明のつく変化か・説明のつかない変化かに振り分けます。説明のつかない差分が残っているうちは、次の段に進みません。

構造化データは中身が本文と合っているかを別に点検する作業があり、その方法は構造化データの監査の記事に書きました。影響調査で見るのは、更新の前と後で同じものが出ているかだけです。

当社は10月24日の更新で、更新前と更新後のそれぞれでサイトを組み立てました。出来上がった全110ファイルについて本文・タイトル・説明・構造化データ・画像の参照を突き合わせ、差分は0件でした。

非推奨になった設定や仕組みの名前は、動いているうちに新しい名前へ移しておく

非推奨とは、いまの版ではまだ動くものの、開発元が先の版で外すと告知している状態です。動いているうちに移せば、移したあとの出力にも前の段と同じ突き合わせをかけられます。外されるまで待つと名前の移し替えと版の更新が同じ日に重なり、差分が出たときにどちらが原因か分けられません。

当社も10月24日の更新で、非推奨になった仕組みの名前を新しい名前へ移しました。どの名前かは構成によって違うので、自社のサイトでは開発元の更新情報に非推奨と書かれた項目を一覧にし、該当する名前が残っていないかを確かめます。

非推奨の告知は、その製品がいつまで支えられるかを読む材料でもあります。IPAのガイドラインはコラム「脆弱性対策について」で、使っている製品のホームページを定期的に確かめてセキュリティパッチなどに注意し、製品を最新の状態にアップデートするよう勧めています。製品を選ぶときは機能などに加えて、脆弱性が見つかったときに対応してくれるかとサポートの手厚さやサポート期限も考えるよう求めています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月30日閲覧）。サポートが切れる部品を更新するか止めるかの決め方は、ホームページの改ざん対策の台帳の節にまとめています。

出力の突き合わせで分からない動きは、起動して確かめる

出来上がったファイルを比べても、要求を受けてその場で応える動きは見えません。ログインしていない人を入口へ回す仕組みや入力を確かめて不正なものを断る仕組み、画像をその場で変換する仕組みは、サイトを起動して実際に要求を送らないと確かめられません。

この3つに共通するのは、壊れても画面の見た目には出にくいことです。保護が外れても会員向けのページは普通に開き、検証が外れても問い合わせは普通に届くので、利用者からの指摘で気づくことは期待しにくい動きです。起動して確かめる動きは、見られてはいけないものを守る動き・受け付けてはいけないものを断る動き・許した形式だけを通す動きから先に選びます。

IPAの20ヶ条は（3）で、「安全なウェブサイトの作り方」に挙げた脆弱性への対策ができているかを確かめるよう求めています。既存のページを変えるときや新しいページを公開する前にも、その都度確かめるよう求めています（IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」／2026年10月30日閲覧）。土台を上げたあとに守るための動きが前と同じかを確かめ直すのも、この都度の確認と同じ考え方で行えます。

当社は10月24日の更新で手元のサイトを起動し、主要なページが開くことと会員向けのページにログイン前に入ると入口へ回されることを確かめました。問い合わせの受付が不正な入力を断ることと画像の変換が許した形式だけを通すことも、同じ場で確かめています。

本番に出したあとは、全URL・転送・ヘッダーを本番で確かめる

手元で確かめた結果は、本番の配信の設定までは含みません。旧いアドレスから新しいアドレスへ回す転送（リダイレクト）とブラウザに渡すセキュリティのための指示（ヘッダー）は配信する側の設定で決まる部分があり、本番に出してからでないと確かめられません。

IPAの20ヶ条は（19）で、クラウドやホスティングのサービスでウェブサイトを運営していると20ヶ条の（1）〜（18）と（20）の対策をサービス事業者が提供していることがあるとしています。そのため、事業者側の作業範囲とセキュリティ対策を把握したうえで足りない対策は自組織で対応することを検討するよう求めています（IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」／2026年10月30日閲覧）。本番で確かめる項目は、この作業範囲の境目に当たるところから選びます。

• 全URL: 公開しているURLの一覧を全件開き、開かないページが無いか
• 転送: 旧いアドレスや別の名前のアドレスから、正しい先へ回るか
• ヘッダー: 更新前に付いていたセキュリティのための指示が、更新後も同じに付いているか

URLも出力と同じ理由で全件にします。当社は10月29日に、本番の全98URLが開くことと旧い入口からの転送とセキュリティのためのヘッダーを確かめました。

本番で何かが動かなくなったときに誰が直して再開させるかは、更新の前に決めておきます。更新前の版へ戻す手順があるかも、同じときに確かめておきます。

外注先から更新の報告を受けたら、根拠・突き合わせた範囲・差分の件数・起動して確かめた動き・本番での確認を聞く

外注先に作業を任せていても、何を確かめれば同じに動いていると言えるかは発注側が持っておく項目です。IPAのガイドラインは「３原則」の2つ目で、委託先に渡した情報が漏えいしたり改ざんされたりしたときは委託先の不備でも、事故の影響を受ける人から委託元としての管理責任を問われるとしています。同じガイドラインは点検の方法に5つを挙げ、委託先の管理者などに直接聞く「質問（インタビュー）」と、文書や記録・設定画面など対策を実行した証拠を確かめる「閲覧（レビュー）」を分けています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月30日閲覧）。

「動作に問題はありません」という答えは質問の結果です。報告に比べた範囲と差分の件数が書かれていれば、閲覧で確かめられる証拠になります。報告の形を先に決めておけば、外注先も何を書けばよいか迷わずに済みます。

表は横にスクロールできます。

委託先を狙った攻撃への警戒も、公的な資料に出ています。IPAの「情報セキュリティ10大脅威 2026」で組織向けの2位は「サプライチェーンや委託先を狙った攻撃」で、2019年に初めて選ばれてから8年連続8回目の選出です。組織向けの順位は、約250名からなる「10大脅威選考会」の審議と投票で決めています（IPA「情報セキュリティ10大脅威 2026」／2026年10月30日閲覧）。

報告の項目は、更新のたびに頼み直すより契約や発注の書面に入れておくほうが続きます。IPAのガイドラインは取引先や外部の情報サービスの管理として、自社の資産がつながる他組織の主要な情報システムを把握する仕組みを整えるよう求めています。そのうえで、契約内容とセキュリティ要件が今の状況に合っているかと、問題が起きたときに誰に何を確認すべきかをはっきりさせるよう求めています。委託や外部サービスを利用する際の責任を明確にする取組では、業務の一部を外部に委託する場合は契約書に委託先の責任と実施すべき対策を明記して合意する必要があるとしています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月30日閲覧）。その前提として管理画面の名義と引き継ぎの段取りを発注側で持っておく話は、ベンダーロックインの対策に書きました。

全件の突き合わせが向かないのは、更新と同時に見た目や中身を意図して変えるときで、そのときは変えた箇所の一覧と照らして説明のつかない差分だけを数える

更新と同じ回でデザインの変更や文章の差し替えを入れると差分が多く出るので、差分0件を合格の条件にできません。そのときは変えるつもりの箇所を先に一覧にし、出た差分を一覧と1件ずつ照らして一覧に無い差分だけを数えます。一覧を後から作ると、出た差分に合わせて一覧を書くことになり照らす意味がなくなります。

できるなら、版の更新と中身の変更は別の回に分けます。分ければ版の更新の回は差分0件を条件にでき、中身の変更の回は一覧との照合だけで済みます。自社で版を選べない外部サービスの更新では、更新前のものを作り直せないので全件の突き合わせはできません。そのときは更新の前に出力を保存しておき、更新のあとに同じ操作をして比べます。

差分が出なくても脆弱性が無いとは言えず、更新前から残る弱点は外部の検査と監査で洗い出す

突き合わせで言えるのは、更新の前と後で同じに動いているということまでです。更新の前から残っていた弱点は前と後の両方に同じ形で入っているので、差分としては現れません。

IPAの20ヶ条は（20）で、組織の中で対策を確かめたうえで外部の組織による脆弱性の検査（診断）やセキュリティ監査を受けることを、対策の漏れを洗い出す効果的な手段としています。公開や運用のあとも、定期的な検査と監査を続けることが重要だとしています（IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」／2026年10月30日閲覧）。影響調査は検査や監査の代わりではなく、更新のたびに入る確認の1つです。

バージョンアップの影響調査についてよくある質問

Q. 影響調査は外注先に任せてよいですか？

作業は任せてよく、確かめる項目と報告の形は自社で持ちます。IPAのガイドラインは「プラットフォームセキュリティ」の項で、ハードウェア・OS・ソフトウェアへのセキュリティパッチとアップデートの適用について手続などを決めて実行するよう求めています。セキュリティに関するアップデートを速やかに適用する運用を定めることも勧めています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月30日閲覧）。手続を決めるのが発注側で手を動かすのが外注先という分け方なら、報告の項目は外注先に聞く項目の表をそのまま使えます。

Q. 差分が出たら、更新をやめるべきですか？

セキュリティの修正を含む更新なら、やめるより差分の原因を直して上げるほうを先に考えます。やめても、直るはずだった弱点は旧版に残ったままだからです。原因を直したら、本番に出す前に更新前の出力ともう一度全件を突き合わせます。

Q. 検証用の環境が無い場合はどうすればよいですか？

本番とは別の場所で更新前と更新後を作れれば、突き合わせはできます。ウェブサイトなら、手元のパソコンでサイトを組み立てて比べる方法があります。業務システムで別の場所を用意できないなら、検証用の環境を作れるかと作れない場合は本番に出す前に何で確かめるかを外注先に聞きます。

Q. 更新しないまま使い続けると何が起きますか？

IPAのガイドラインは「情報セキュリティ６か条」の1つ目にOSやソフトウェアを常に最新の状態にすることを置いています。古いまま放置するとセキュリティ上の問題点が解決されず、それを悪用したウイルスに感染する危険があるとしています（IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）／2026年10月30日閲覧）。影響調査の手間を理由に更新を先送りしても、旧版に該当する脆弱性情報はそのまま残ります。更新されないまま動く部品がサイトの改ざんの入口になりうることと、その止め方はホームページの改ざん対策に書きました。

SAIの視点：当社のサイトの更新で合否を決めたのは、変更点の説明ではなく、更新前後の出力の差分の件数だった

当社が10月24日の更新のあとも同じに動いていると言えた根拠は、変更点の説明ではなく、更新前後の出力の差分が0件だったことです。旧版に20件・新版に0件という脆弱性情報の件数は上げる理由を説明しますが、上げたあとに何も崩れていないことまでは説明しません。2つの件数は別の問いに答えていて、10月29日の本番の確認は差分0件という答えが配信の設定を通っても変わらないかを見る作業でした。

発注側が報告で読むのも、変更点の説明の長さではなく比べた範囲と差分の件数です。

次の更新の日程が決まったら、作業を頼む連絡に外注先に聞く項目の表を添えて、報告の見本として渡せます。5行が埋まって返ってきた報告は、その次の更新からもそのまま見本に使えます。自社の構成では何を確かめてもらえば「同じに動いている」と言えるかを詰めたいときは、FDE伴走開発のページからご相談ください。更新の対象がサイトか業務システムか・いま受けている報告の形（報告が無ければそのこと）・本番に出したあとに確かめている項目を添えていただくと、表のどの行を足してどの行を削るかから話せます。

出典と確認日

外部の出典はいずれも2026年10月30日閲覧で、JVN iPediaとJPCERT/CCの告知は同日時点の記載。当社の数値は自社サイトのセキュリティ点検の記録（10月24日の調査と更新・10月29日の本番の確認）から取ったもので、顧客案件の数値ではない。

• IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」（最終更新日 2019年3月6日）
• IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（PDF）
• IPA「情報セキュリティ10大脅威 2026」（2026年1月29日公開・最終更新日 2026年5月21日）
• IPA（JVN iPedia）「サービス停止中」（2026年10月30日更新の告知）
• JPCERT/CC「JVN iPedia、MyJVNサービスの一時停止のお知らせ (2026-10-22)」
• JPCERT/CC・IPA「JVN とは？」
• JPCERT/CC・IPA「脆弱性レポートの読み方」
• NIST「National Vulnerability Database (NVD)」
• NIST CSRC「Common Platform Enumeration (CPE)」