公開後に脆弱性が見つかったら、まず何をしますか？
影響範囲を確認して記録を残し、制作会社へ連絡したうえで、契約書の検収日と期間制限の条項を確認します。責任の所在を先に決めようとすると、対応が遅れます。
順番に意味があります。誰の責任かを確定させるには時間がかかります。その間も脆弱性は残り続けます。記録を残しながら止血を優先してください。
最初の24時間で行うこと
作業は次の順で進めます。
- 指摘の内容を記録します。誰からいつ何と伝えられたかを残します。所要時間の目安は30分です。
- 該当する機能と画面を特定します。問い合わせフォームか、会員機能か、管理画面かを切り分けます。
- 実際に情報が漏れた可能性があるかを確認します。サーバのアクセスログを保全してください。
- 制作会社へ連絡します。連絡した日時と、相手の回答を文書で残します。
- 公開を続けるかを判断します。修正までに時間がかかる場合、該当ページを一時的に非公開にする選択もあります。
つまずきやすいのは3番目です。ログは保存期間を過ぎると消えます。漏えいの有無を後から確認できなくなるため、気づいた時点で保全してください。
指摘が外部の第三者から来た場合は、対応状況を相手に伝える窓口も決めておきます。返答がないと、公表に踏み切られる場合があります。
契約書のどこを見るか
契約書で見るのは3か所です。責任の切り分けは、この3つの記載で決まります。
| 見る箇所 | 確認すること |
|---|---|
| 検収の完了日 | 期間制限の起算点になります |
| 契約不適合責任の条項 | 期間が何か月または何年と書かれているか |
| 保守契約の対象範囲 | 脆弱性の修正が含まれているか |
検収の完了日は、検収書や請求書の日付から特定できます。契約書に期間の記載が見つからない場合は、発注書と提案書も確認してください。
3か所を確認したうえで、次の2つのどちらに当たるかを見ます。契約不適合責任の期間内であれば、その枠組みで求める余地があります。期間を過ぎている場合は、保守契約の範囲か、追加の費用が発生する対応になります。
それぞれの枠組みの中身は、このあとの見出しで順に扱います。まずは日付と条項の場所を押さえてください。
公開後の脆弱性はどれくらい起きていますか？
IPAへの脆弱性の届出は累計20,315件で、そのうちウェブサイトに関するものが13,599件と約7割を占めます。公開後に見つかることは珍しくありません。
この数字は、御社だけの問題ではないことを示します。同時に、見つかった後の対応が用意されていない状態が一般的だということも示しています。
届出の累計はウェブサイトが約7割
届出受付開始からの累計と、直近の四半期の件数は次のとおりです。
| 区分 | 累計 | 2026年第2四半期 |
|---|---|---|
| ソフトウェア製品 | 6,716件 | 182件 |
| ウェブサイト | 13,599件 | 65件 |
| 合計 | 20,315件 | 247件 |
出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月から6月）］」（https://www.ipa.go.jp/security/reports/vuln/software/2026q2.html ）
ウェブサイトの届出が多いのは、対象の数が多いことに加え、外部から不具合を確認しやすいためです。フォームや検索窓の挙動は、誰でも試せます。
修正の2割強はページ削除で終わっています
修正が完了したウェブサイトの対応方法を見ると、修正だけではないことがわかります。
2026年第2四半期に修正が完了したウェブサイトは18件でした。その内訳は、ウェブアプリケーションの修正が14件で78%、ページ削除が4件で22%、運用で回避が0件で0%です。ウェブサイトの修正完了の累計は8,956件です。
出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月から6月）］」
ページ削除が2割強あるという事実は、実務上の意味を持ちます。直すよりも、その機能や情報の公開をやめる判断が選ばれる場合があるということです。
たとえば、もう使っていない旧サービスの申し込みフォームが残っているとします。直す費用と、消す判断の手間を比べれば、消すほうが早いこともあります。前述のとおり、修正までに時間がかかる場合は該当ページを一時的に非公開にする選択もあります。
90日以内に修正が完了したのは83%
修正までにかかる期間も公表されています。
2026年第2四半期に修正が完了した18件のうち、90日以内に完了したものは15件で83%でした。逆に言えば、90日を超える案件も一定数あります。
出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月から6月）］」
この期間は、契約上の判断に影響します。修正に3か月近くかかる前提で考えると、契約不適合責任の期間が残り1か月しかない場合、通知だけ先に済ませておく必要があります。
期間制限の考え方は次の見出しで扱います。ここで押さえておきたいのは、修正は即日で終わるものではないという点です。
制作会社の契約不適合責任で直してもらえますか？
契約書に定めた期間制限の中であれば、契約不適合として求める余地があります。IPAのモデル契約書では、期間制限の起算点を検収完了時という客観的なものとする考え方が示されています。
契約不適合責任とは、納品されたものが契約の内容に合っていない場合に、受注側が負う責任のことです。以前は瑕疵担保責任と呼ばれていた枠組みが、民法の改正で整理されたものです。
なお、個別の事案が契約不適合に当たるかどうかは、契約書の記載と経緯によって変わります。本記事は公的資料で確認できる考え方の整理です。判断が必要な場面では、弁護士にご相談ください。
期間制限の起算点は検収完了時です
IPAが公開する「情報システム・モデル取引・契約書」からの見直しのポイントには、次のように記載されています。期間制限の起算点を検収完了時という客観的なものとする規律は維持する、というものです。
あわせて、モデル契約上の期間制限の表記は「〇ヶ月／〇年」とすると明記されています。
出典: IPA「「情報システム・モデル取引・契約書」からの見直しのポイント」（https://www.ipa.go.jp/digital/model/review-point.html ）
つまり、期間の長さそのものは決められていません。発注側と受注側が話し合って決める前提です。御社の契約書に何か月と書かれているかを、まず確認してください。
前述のとおり、検収の完了日は検収書や請求書の日付から特定できます。
通知は契約不適合を知った時から1年以内
同じ資料は、改正民法の内容として次のように説明しています。契約不適合を知った時から1年以内にその旨の通知をすればよいことになった、というものです。
ここで重要なのは、通知と修正が別だという点です。
- 通知は、契約不適合があることを相手に伝える行為です
- 修正は、そのあとに行われる作業です
- 修正に時間がかかっても、通知が期限内であれば手続きは踏めます
前述のとおり、修正が90日以内に完了したのは83%でした。修正の完了を待ってから通知しようとすると、期間を過ぎる可能性があります。気づいた時点で、文書で通知しておいてください。
制作会社に故意・重過失がある場合
同資料には、例外の扱いも明記されています。契約不適合がベンダの故意・重過失に起因する場合には、客観的な起算点からの期間制限を適用除外にする、というものです。
出典: IPA「「情報システム・モデル取引・契約書」からの見直しのポイント」
つまり、検収完了時から数えた期間を過ぎていても、故意または重大な過失があった場合は別に扱われる余地があります。
ただし、故意や重過失に当たるかの判断は容易ではありません。この点を持ち出す場合は、指摘された脆弱性の内容と、発注時にどのような要件を伝えていたかを揃えて相談してください。発注時の書面が残っているかどうかが、ここで効いてきます。
保守契約ではどこまでカバーされますか？
保守契約の対象は契約書の記載で決まり、脆弱性への対応が自動的に含まれるわけではありません。CMSやプラグインの更新までか、発見された脆弱性の修正までかを分けて確認します。
ここが曖昧なまま運用している契約は少なくありません。月額を払っているのに対応は別料金だった、という食い違いはここから起きます。
保守に含まれるものと含まれないもの
一般的な保守契約の記載を、対応の種類ごとに整理します。御社の契約書と突き合わせてください。
| 対応の種類 | 保守に含まれることが多いか |
|---|---|
| サーバやCMSの稼働監視 | 含まれることが多い |
| CMSとプラグインの更新 | 契約書に明記されていれば含まれる |
| 更新に伴う表示崩れの修正 | 明記がないと別料金になりやすい |
| 発見された脆弱性の修正 | 明記がないと対象外になりやすい |
| 改ざんされた後の復旧 | 別料金または別契約が多い |
判断の分かれ目は、作業が定期的なものか、都度発生するものかです。更新作業は定期的に予定できますが、脆弱性の修正は予定できません。予定できない作業は、含めるなら明記が必要になります。
つまずきやすいのは3行目です。更新そのものは保守に含まれていても、更新でレイアウトが崩れた場合の修正は範囲外という契約があります。
脆弱性対応を保守に含める書き方
含めたい場合は、契約書に具体的に書きます。曖昧な表現では運用時に解釈が分かれます。
書いておく項目は次の3つです。
- 対象の範囲。自社で作った部分か、CMSやプラグインも含むか
- 着手の期限。連絡から何営業日以内に着手するか
- 含まれる作業量の上限。月あたり何時間まで、または年間何件までか
3番目を書いておくと、双方が無理のない前提で合意できます。上限のない約束は、受注側が引き受けにくいためです。上限を超えた分は追加費用とする書き方が現実的です。
費用負担が変わる境目
費用の負担が変わる境目は、原因がどこにあるかです。
- 制作会社が作った部分に原因がある場合は、契約不適合責任の期間内であればその枠組みで扱えます
- CMSやプラグインの提供元が公表した脆弱性であれば、保守契約の更新作業の範囲になることが多いです
- 御社の運用に原因がある場合は、追加費用の対応になります
3番目の例は、管理画面のパスワードの共有や、権限の付けすぎです。この種の原因は、契約の枠組みでは救えません。
期間制限を過ぎており、保守契約にも明記がない場合は、通常の発注として見積もりを取ることになります。その際も、前述のとおり修正ではなくページ削除で対応する選択が残っています。実際に修正が完了したウェブサイトのうち、22%はページ削除で対応されていました。