脆弱性が出た日に「うちは影響あるか」を5分で答える：構成と版の一覧（SBOM）の作り方と、問い合わせフォームの悪用対策

「○○に緊急の脆弱性」というニュースが出るたびに、制作会社や保守会社に問い合わせて、返事を待つしかない。総務や管理部門の方が情報システムを兼ねている会社では、珍しくない光景です。

この記事は、そうした会社が次の脆弱性がどの製品で出ても「うちは影響を受けるか」をすぐ答えられるようにするための、一覧の作り方と回し方をまとめたものです。後半では、版を最新にしても残る穴として、問い合わせフォームの悪用対策を扱います。どちらも、カトルセが2026年10月に自社で実際にやったことをもとにしています。

1. 脆弱性のニュースが出た日、「うちは大丈夫？」に何分で答えられますか

2026年10月21日、Webサイトの多くが使うPHPに緊急の脆弱性（通称php2shell）が出て、修正版が公開されました。同じ日に、Webサービスを動かす実行環境のNode.jsでも、セキュリティの修正版の知らせが届きました。PHPの対象版や更新手順はphp2shellの解説記事にまとめています。

正直に書くと、カトルセもこの日、すぐには答えられませんでした。カトルセは、自社で動かしている社内の業務システムなど、いくつかのWebサービスをNode.jsで動かしています。設定ファイルに書いた版の系列までは分かりました。ところが、本番でいま実際に動いている細かい版は、どのサービスについても即答できなかったのです。クラウドの実行環境が細かい版を自動で上げていて、その画面もすぐには確かめられなかったためです。

答えるべき問いは、実は3つしかありません。

この3つに、ニュースを見てから5分で答えられる状態を目標にします。5分は実測ではなく、目指す水準です。そのために必要なのが、次に説明する「構成と版の一覧」です。

2. SBOMとは：「部品表」をまず“表1枚”で考える

SBOM（エスボム、Software Bill of Materials）は、ソフトウェアの部品表です。製造業の部品表が「この製品はどの部品でできているか」を示すように、SBOMは「このシステムはどのソフトの部品の、どの版でできているか」を示します。目的の中心は、新しい脆弱性が見つかったときに、影響を受けるシステムをすぐ探し当てることです。

国も導入を後押ししています。経済産業省は、ソフトウェア管理に向けたSBOMの導入の手引を公表しています（経済産業省の発表）。最新の版と詳しい中身は、原文で確かめてください。

SBOMには機械で読むための決まった書式もありますが、従業員数十〜数百名の会社が最初から書式に合わせる必要はありません。この記事の立場ははっきりしていて、形式より先に「聞かれたら答えられること」です。まずはExcelやスプレッドシートの表1枚で始め、答えられるようになってから、必要に応じて道具を整えれば十分です。

3. 一覧に載せる範囲：自社のサイト・社内システム・SaaS・委託先・機器

一覧に載せるものは、次の3つの層で考えると漏れが減ります。

1. 自分で動かしているもの：会社のWebサイト、社内の業務システム、自社サーバーやクラウドで動くアプリ。
2. 預けているもの：SaaS（クラウドの業務サービス）、制作会社・保守会社が運用するサイト、フォーム作成サービス、メール配信サービス、予約・会員管理のサービス。
3. 機器：VPN装置、NAS（社内のファイルサーバー）、複合機、ルーターなど、ネットにつながる機械。

2の「預けているもの」を外さないでください。2026年は、利用しているサービスが攻撃を受け、そこに情報を預けていた多くの会社が一斉に事故を公表する例が続きました（情報漏えいの原因と事例2026）。自社で直せなくても、「どこに何を預けているか」が分かれば、事業者に確認を急げます。

もう1つ見落としやすいのが、社員が作ったツールです。カトルセが最近お会いした企業でも、社員が生成AIを使って業務アプリを作り始め、品質やデータ連携での漏えいを心配している例や、表計算のマクロで作った個別のツールが多数あって作った人にしか分からない、という例がありました。部署で動いているものは、作った人と使っている部品だけでも一覧に入れておきます。

部品の粒度は「ニュースになる単位」で

全部のライブラリを並べる必要はありません。載せるのは、OS、実行環境（PHP・Node.js・Javaなど）、CMSとプラグイン（WordPressなど）、主要なライブラリやフレームワーク（Next.jsなど）といった、脆弱性のニュースに名前が出る単位です。細かい部品まで追うのは、照合が回るようになってからで構いません。

表の見本です（行は記入の例です）。

※ PHP 8.2系のサポート期限はphp2shellの解説記事で紹介したPHP公式の情報です。

この表があると、取引先から届くセキュリティのチェックシートにも答えやすくなります。カトルセが最近お会いした商社でも、取引先から毎年チェックシートの提出を求められ、情報システム部門がシステムの運用で手一杯、という声を伺いました。一覧は、脆弱性の対応と報告の両方に使い回せます。

4. 落とし穴：「書いてある版」と「本番で動いている版」は違う

カトルセが10月21日に即答できなかった理由を調べると、版が3か所でずれていました。

• 設定ファイル：「この系列で動かす」と、1つ前の系列が書いてあった。
• 本番：クラウドの実行環境が版を自動で上げていて、実際には新しい系列で動いていた。
• 検査環境：変更のたびに自動で動かす検査（テストなど）だけが、古い系列のまま動いていた。

設定ファイルを見るだけでは、本番の版は分かりませんでした。しかも、検査と本番で違う版を使っていることにも、このとき初めて気づきました。そこでカトルセは、本番のシステム自身に「いま何の版で動いているか」を答えさせる仕組みを作り、検査環境の版も本番に揃えました。

これはカトルセに限った話ではありません。どこを見れば本当の版が分かるかは、動かし方によって違います。

版の情報は「社内の人だけ」が見られる形に

ひとつ注意があります。どの部品のどの版で動いているかは、攻撃者にとっても下調べの材料です。版を確かめるためのページを誰でも見られる形で公開してはいけません。カトルセが作った仕組みも、社内の担当者だけが聞ける形にしています。PHPのphpinfo()を表示するページを公開のまま作らない、という注意（php2shellの記事）と同じ考え方です。一覧そのものも、社内の限られた人だけが見られる場所に置きます。

5. 脆弱性が出たら：5分で答える照合の手順

一覧ができたら、脆弱性のニュースが出たときの動きを決めておきます。

1. ニュースから4つを抜き出す：部品名、対象の版、修正版、条件（どんな使い方のときに成り立つか）。
2. 一覧で部品名を引く：使っている場所と担当が分かります。使っていなければ、ここで「当てはまらない」と答えられます。
3. 本番で動いている版と比べる：「書いてある版」ではなく「動いている版」の列を見ます。
4. 使い方の条件に当たるかを確かめる：特定の機能や設定を使っているときだけ成り立つ脆弱性も多くあります。確かめ終わるまでは「当てはまる」扱いにします。
5. 担当と期限を決めて記録する：「当てはまる／当てはまらない／確認中」と、次に何をいつまでにやるかを一覧の横に残します。

判断の実例：全部が自社に当てはまるわけではない

10月に公開された、Webサービスを作るための部品Next.jsの脆弱性の修正では、条件の違う複数の重大な脆弱性がまとめて直されました。カトルセが4の「条件」を確かめると、画像の処理でSVG形式を扱う設定が条件のものと、特定のキャッシュ機能が条件のものは、どちらも使っていなかったので当てはまりませんでした。一方、サーバー側の処理（Server Actions）に細工した通信を送ってサービスを止める脆弱性（GitHubのアドバイザリ）は当てはまりました。そこで、同じ系列の修正版に上げて対応しました。

条件を確かめずに「全部当てはまる」と慌てるのも、「うちは関係ない」と決めつけるのも、どちらも外れます。条件まで見て、初めて正しく答えられます。

毎週の点検に組み込む

ニュースを待つだけでは、取りこぼしが出ます。カトルセは、設定ファイルやlockファイルから集めた版と、本番に答えさせた版を、公開されている修正の一覧と突き合わせる仕組みを作り、毎週の点検に入れました。毎週見るのは次の2つです。

• 取り込めていない修正：動いている版より新しい、セキュリティの修正版が出ていないか。
• サポート終了が近い版：系列ごとのサポート期限が迫っていないか。たとえばNode.jsは、20系のサポートが2026年4月30日に終わり、22系は2027年4月30日までです（Node.jsのリリース予定）。PHPは8.2系が2026年12月31日までです。

この仕組みも、一度で完成したわけではありません。サービスによって版の聞き方が少しずつ違い、動かしながら何度か直しました。最初から完璧を目指すより、毎週回して直すほうが早く形になります。

生成AIの使いどころ

照合の作業は、生成AIと相性がよい仕事です。ニュースや公式の発表文から「部品名・対象の版・修正版・条件」を抜き出す、一覧の表と照らし合わせて当てはまりそうな行を挙げる、委託先への問い合わせ文を下書きする、といった使い方です。カトルセも、版を集めて照合する仕組みを生成AIと一緒に作りました。ただし、最後に「当てはまる」と判断するのは人です。社内の一覧をAIに読ませるときは、会社で使ってよいと決めたサービスで行ってください。

コピーして使える：委託先・利用サービスへの問い合わせ文

いつもお世話になっております。
本日公表された「（脆弱性の名前・番号）」について、御社にお願いしている「（サイト名・サービス名）」への影響を確認させてください。

1. 該当の部品（（部品名））を使っていますか。
2. 使っている場合、本番で動いている版を教えてください。
3. 修正版の適用は済んでいますか。まだの場合、予定日を教えてください。
4. 適用までの間に、弊社で取るべき対応があれば教えてください。

社内の確認のため、（日付）までにご回答いただけますと幸いです。

6. 版を最新にしても塞がらない穴：問い合わせフォームの悪用

ここまでは「部品の版」の話でした。ところが、部品をすべて最新にしても塞がらない穴があります。代表的なのが、問い合わせフォームの悪用です。脆弱性ではなく、作り方や設定の問題なので、修正版は出ません。

よくある手口はこうです。攻撃者がフォームの「メールアドレス」欄に他人のアドレスを、「お名前」や「本文」に偽サイトのURLや広告文を入れて送信します。フォームが「お問い合わせありがとうございます。以下の内容で受け付けました」と入力内容をそのまま載せた自動返信を出すと、会社の名前で、見知らぬ人に迷惑メールが届くことになります。これを大量に繰り返されると、メールの送信上限を使い切ったり、送信元としての評判が落ちて、自社の正規のメールまで届きにくくなったりします。

カトルセの点検で見つかった「起こり得たこと」

カトルセも2026年10月に、自社の問い合わせフォームを点検しました。実際の被害は確認していませんが、次のことが起こり得る状態でした。同じ点は、多くの会社のフォームにも当てはまるはずです。

• 自動返信が、相手の入力（会社名・氏名・本文）をそのまま返していた。上で説明した手口に使われるおそれがありました。
• 送信の回数に上限がなく、同じ内容の送り直しも除外していなかった。連打されると、社内への通知メール・チャット通知・自動返信が際限なく出ます。
• 社内チャットへの通知に、入力値をそのまま入れていた。チャットの書き方の記号を入れられると、全員への一斉通知や、本物に見える偽のリンクを出させられるおそれがありました。
• 社内向けメールの件名に、相手が決められる値が入っていた。「【至急】お支払い口座の変更」のような件名の社内メールを出させられるおそれがありました。
• 相手が送った知らない値で、社内の分類の選択肢が勝手に増えていた。外から社内の設定を書き換えられる状態でした。

「reCAPTCHAを入れているから大丈夫」ではない

reCAPTCHAのようなボット判定は、機械による大量送信を減らすのに役立ちます。ただ、判定は「人らしさ」の見積もりで、人が手で送るものや、判定をすり抜けた送信は止められません。ボット判定は入口の1枚目と考え、その奥に「通っても悪用できない作り」を重ねます。

7. フォームの悪用対策チェックリスト（カトルセが入れたこと）

自社で作ったフォームでも、フォーム作成サービスやWordPressのプラグインの設定でも、確かめられる順に並べました。1〜5はカトルセが入れた対策です。

1. 自動返信は、相手の入力を1文字も載せない定型文にする。「お心当たりのない場合は、このメールを破棄してください」と添えます。同じ宛先に何通も送らないようにします。内容の控えが必要な方には、担当者から返信します。
2. 回数に上限を設け、同じ内容の送り直しは登録しない。同じ送信元からの回数と、同じメールアドレスでの回数の両方で数えます。具体的な回数は、自社の普段の問い合わせ件数から決めます。
3. 大量に届いたら、メールと通知だけを止め、受付の記録は続ける。本物の問い合わせを取りこぼさない側に倒します。止めたことは記録に残します。
4. 社内チャットの通知と件名に入れる値は、決まった書式にする。記号を無害化し、長さを区切ります。問い合わせ本文は通知に載せず、管理画面で読みます。通知の保存期間が、そのまま個人情報の保存期間になるためです。
5. ブラウザから裏のシステムに直接送らず、自社サイト側で一度受けて中継する。中継すると、裏のシステムからは全員が同じ送信元に見えるので、回数の上限の数え方に注意します。

対策は「副作用まで」で1セット

対策を入れたあと、2つの副作用が出ました。

• 送信の待ち時間が延びた：自動返信と社内通知を送り終えてから「送信しました」と返す作りだったため、送信ボタンを押してから完了までの待ち時間が長くなっていました。受付を記録したらすぐ応答し、メールと通知はその後に送る形に直しました。
• 本物の問い合わせが上限で止まりかけた：中継を入れると、裏のシステムからは全員が同じ送信元に見えます。そのままでは回数の上限にすぐ達してしまうため、本当の送信元を、中継から安全に引き継ぐようにしました。

守りを固めるほど、正しいお客様が使いにくくなることがあります。対策を入れたら、自分で実際にフォームから送ってみて、待ち時間と届き方まで確かめてください。

よくある質問

SBOMは中小企業にも必要ですか？

決まった書式のSBOMを作ることは必須ではありません。ただ、使っている部品と版の一覧は、規模に関係なく必要です。脆弱性が出た日に「うちは影響を受けるか」を答えられないと、制作会社や保守会社の返事を待つしかなくなるためです。まずは表1枚から始めてください。

Excelやスプレッドシートの表でもよいですか？

十分です。部品名・使っている場所・書いてある版・本番で動いている版・担当・サポート期限の6列があれば、照合して答えられます。大事なのは形式より、本番で動いている版を書き、毎週見直すことです。表は社内の限られた人だけが見られる場所に置いてください。

委託先が版を教えてくれないときは、どうすればよいですか？

「使っているか」「本番で動いている版」「修正版の適用日」の3点を、文書で問い合わせてください。答えが得られない場合は、契約の更新時に、脆弱性が出たときの報告の取り決めを入れるよう相談します。少なくとも、どの委託先に何を預けているかは自社の一覧に載せておきます。

reCAPTCHAを入れていれば、フォームは大丈夫ですか？

それだけでは足りません。reCAPTCHAのようなボット判定は機械による大量送信を減らしますが、人が手で送るものは止められません。自動返信に相手の入力を載せない、送信の回数に上限を設ける、社内通知の値を無害化する、といった「通っても悪用できない作り」を重ねてください。

自動返信は止めたほうがよいですか？

止めなくても構いません。相手の入力を1文字も載せない定型文にし、心当たりがなければ破棄するよう添え、同じ宛先へ何通も送らないようにすれば、悪用されにくくなります。問い合わせが届いたことをお客様に伝える役目は残せます。

まとめ ── 一覧は「照合して答える」までが仕事

1. 答えるべき問いは3つ。使っているか、本番で動いているのはどの版か、条件に当たるか。ニュースから5分で答える状態を目指します。
2. 一覧は表1枚・6列で始める。自分で動かしているもの、預けているもの、機器、社員が作ったツールまで載せます。
3. 「書いてある版」ではなく「動いている版」を書く。カトルセも設定・本番・検査環境で版がずれていました。版の情報は社内の人だけが見られる形にします。
4. 毎週、修正の一覧とサポート期限と照らし合わせる。照合と問い合わせ文の下書きは生成AIに任せ、判断は人がします。
5. フォームは版と別に点検する。自動返信の定型化、回数の上限、通知の無害化を入れ、副作用まで確かめます。

一覧づくりと照合を、仕組みにする

「どのシステムが、どの版の部品を使っているか」「どの委託先に何を預けているか」を一覧にし、新しい脆弱性や修正の情報と毎週照らし合わせる。カトルセのAI顧問では、こうした仕組みを生成AIで回すところまでご支援します。ご相談はお問い合わせからどうぞ。

情報システムを兼ねている方が、生成AIを照合や問い合わせ文の作成に使えるようになるには、自社の業務を題材に試すのが近道です。情シスの方向けの考え方は情シスこそ生成AI研修を受けるべき理由にまとめています。職種別AI研修シリーズ（全9講座・各11時間）。受講料は全講座共通で1名あたり36万円（税抜）。ライブ形式（対面／オンライン同時双方向）のため人材開発支援助成金の活用をご検討いただけます。支給の可否は都道府県労働局の審査で決まります。申請手続きは社会保険労務士の独占業務のため、必要な場合は提携社労士をご紹介します。

参考

1. 経済産業省「SBOMを活用してソフトウェアの脆弱性を管理する具体的手法についての改訂手引を策定しました」
2. GitHub Advisory Database「Next.js: Denial of Service in App Router using Server Actions」
3. Node.js Release Working Group（各系列のサポート予定）
4. カトルセ「PHPの緊急脆弱性「php2shell」とは」

※ 本記事は2026年10月24日時点で確認した情報にもとづいています。Node.jsのセキュリティ修正版の公開とサポート予定は、Node.jsの公式の配布一覧とリリース予定（2026年10月24日確認）で確かめました。Next.jsの脆弱性はGitHub Advisory Databaseの登録内容（2026年10月24日確認）によります。経済産業省の手引は、この環境から原文を開けなかったため、存在と題名の紹介にとどめています。カトルセの事例は、自社の作業記録にもとづき、攻撃の手がかりになる設定値や仕組みの詳細は伏せています。本記事に登場する製品名・サービス名は、それぞれの提供元の商標または登録商標です。