Webサイトは「作って終わり」ではなく、公開後も継続的に守り続ける必要があります。特に顧客情報や採用応募など個人情報を扱う企業では、事故が起きたときの影響が売上だけでなく信用や採用にも波及しやすく、予算の決め方が経営課題になりがちです。

保守運用は、サイトを安全に動かし続けるために更新・監視・障害対応を継続して行うことです。サーバーは、Webサイトのデータやプログラムを置き、閲覧者の要求に応答するコンピュータ環境です。監視は、サイトやサーバーの状態を継続的に確認し、異常の兆候を早期に検知する取り組みです。ここを「単発の対策」ではなく「毎月・毎年の事業活動」として捉えると、対策費はブレにくくなります。みやあじよでは制作も運用も目的から逆算し、問題解決として設計する姿勢を重視しています。

セキュリティ対策費の予算がブレる理由

理由1：単発改修だけだと毎年ゼロ起点になる

サイトの安全性は、ある時点の改修だけで固定されません。CMSは、Webページの作成・更新を管理するための仕組みです。CMSやサーバー、外部サービスは日々更新され、脆弱性はソフトや設定にある攻撃に悪用され得る弱点のことです。脆弱性対応を「必要なときに必要な分だけ」積み上げる運用だと、年度ごとに費用が乱高下しやすく、経営判断も属人的になります。

理由2：担当者依存で見えない作業が増える

少人数の企業ほど、管理画面の権限、外部ベンダーの連絡網、復旧手順が特定の担当者の頭の中に残りがちです。権限管理は、誰がどの操作をできるかを決めて管理することです。整理されていない状態では「何かあったら詳しい人が対応する」になり、平時の手戻りや緊急対応の負担が膨らみます。

理由3：事故対応の緊急費が最も高くなりやすい

インシデントは、セキュリティ上の事故やその兆候を指す出来事です。インシデント対応は時間制約が強く、夜間・休日対応や突貫の調査が発生しやすいため、平時に整備するより高くつく傾向があります。予算を「事故が起きたら出す」にすると、結果的に経営として最も不確実な支出構造になります。

ここまでのポイントは、費用の話の前に「何を守り、どこまでの被害を許容するか」を言語化しないと、見積もりも運用も安定しないという点です。みやあじよが大切にしているのも、依頼者が整理しきれていない前提を言語化し、伝わるストーリーに落とし込むことです。

守る対象を棚卸しする：情報・機能・取引

予算設計の出発点は、ツール選定ではなく「守る対象の棚卸し」です。棚卸しの粒度をそろえると、経営と情シス、Web担当、外部ベンダーの会話が噛み合います。情シスは、情報システムを統括する部門・担当を指す略称です。外部に任せる場合でも、守る対象と優先順位は社内の意思決定として残しておくと、委託先の変更や担当交代でも運用が止まりにくくなります。

まずは情報の種類を分ける

例として、問い合わせの氏名・メール、採用応募の履歴書データ、会員のログイン情報、購買や予約の履歴などは、漏えい時の影響が異なります。影響が大きいほど、監視と復旧の手厚さが必要になります。

次に入口と権限を洗い出す

攻撃の入口になりやすいのはフォーム、ログイン、管理画面、外部連携のAPIなどです。APIは、システム同士がデータをやり取りするための接続口です。入口が増えるほど、更新管理や監視の対象も増え、運用コストに直結します。更新管理は、CMSや周辺ソフトの更新を計画的に行い、影響確認まで含めて反映する運用です。

重要度は高・中・低で十分に始める

最初から完璧な分類を目指すより、影響の大きい順に優先順位が付く状態を作ることが重要です。従業員10〜500名規模では、まず「止まったら困る」「漏れたら困る」を短時間で決め、後から精度を上げる方が現実的です。棚卸し結果は、1枚の一覧にして共有し、更新や追加開発のたびに追記できる形にすると管理しやすくなります。

守る対象（サイト/データ）	重要度（高・中・低）	想定インシデント	許容停止時間
採用応募フォーム（応募者情報）	高	情報漏えい、フォーム改ざん	半日以内
お問い合わせフォーム（氏名・メール）	中	スパム送信、改ざん	1日以内
会員ログイン（認証情報）	高	不正ログイン、なりすまし	数時間以内
会社概要ページ（公開情報）	低	改ざん	数日以内

表Aの4列が埋まるだけでも、見積の前提がそろい、委託先との「どこまでやるか」のすり合わせが早くなります。加えて、社内で見ても運用の引き継ぎ資料になり、属人化の解消に効きます。

リスクから逆算する：被害シナリオと許容停止時間

棚卸しができたら、次は「起きたら何が困るか」をシナリオで具体化します。ここで初めて、対策費の優先順位が経営判断として整理できます。

被害シナリオは漏えい・改ざん・停止に分ける

情報漏えいは、顧客や応募者などの情報が外部に流出することです。改ざんは、ページ内容やリンク先が不正に書き換えられることです。停止は、障害や攻撃でサイトが表示できない状態になることです。自社にとって致命的なのがどれかで、投資の重点が変わります。

許容停止時間を決めると対策の深さが決まる

許容停止時間は、事業としてサイトが止まっても許容できる最大の時間です。例えば採用や問い合わせが主要な獲得経路なら、停止の影響は売上だけでは測れません。決める際は、機会損失だけでなく、問い合わせ対応の増加、信用低下、復旧に必要な社内工数まで含めて整理すると、意思決定が進みます。許容停止時間が短いほど、監視の頻度、バックアップの設計、復旧支援の体制にコストを配分する必要があります。バックアップは、障害時に元に戻すためのデータの複製です。

予算を予防・検知・復旧に分けて考える

予防は、更新や設定で事故の確率を下げることです。検知は、監視によって異常の兆候を早期に見つけることです。復旧は、バックアップや手順により元の状態へ戻すことです。3つを分けると、経営として「どこに厚みを持たせるか」を説明しやすくなり、定額で持つ領域と作業発生時に備える領域が整理できます。

予算の立て方3モデル：最低限・標準・強化

予算の立て方は、守る対象の重要度と許容停止時間に合わせて「どこまでを定常運用として持つか」を決める作業です。TCOは、導入後の運用費も含めた総コストです。対策費をTCOで捉えると、単発の改修だけに偏らず、運用の継続性まで含めて判断しやすくなります。

3モデルを作ると経営判断が早くなる

現場は「できることを全部やりたい」になりやすく、経営は「費用と効果の説明がほしい」になりやすい構図があります。そこで、最低限・標準・強化の3モデルを用意し、差分を言語化すると合意形成が進みます。モデルは金額ではなく、対応範囲と応答条件で区切るのが実務的です。守る対象が増えたり、許容停止時間が短くなったりした場合は、モデルを一段上げるだけで方針が決まりやすくなります。

最低限モデル：止血できる運用を先に作る

最低限は「事故が起きても致命傷になりにくい」状態を目指します。具体的には、管理画面の権限を整理し、更新の手順と担当を決め、バックアップが取得できる状態を作ります。復旧の連絡網と一次対応の手順が用意されているだけでも、緊急時の判断が早くなります。監視は、稼働確認と主要エラーの検知から始め、対象を段階的に増やします。加えて、外部ベンダーが変更になっても困らないよう、アクセス情報や構成情報を台帳として残します。

標準モデル：予防と検知を回すための枠を持つ

標準は「定常運用で事故の確率を下げ、異常を早期に見つける」ことに軸を置きます。更新管理を月次のリズムに組み込み、更新前の検証時間も予算に入れます。ステージング環境は、本番反映前に更新を検証するための検証用環境です。ステージング環境があると、更新による不具合を事前に減らしやすくなります。監視は死活監視だけでなく、改ざん兆候や負荷上昇など「復旧に繋がる兆候」を拾う設計に進めます。レポートは、実施内容と未対応の理由を残し、先送りのリスクが見える状態にします。

強化モデル：短い停止許容に合わせて復旧力を上げる

強化は、許容停止時間が短い事業に向くモデルです。RTOは、復旧に要する時間の目標値です。RPOは、復旧時にどこまでのデータを戻せるかの目標値です。RTOとRPOを定義し、バックアップの世代管理や復旧手順の検証まで含めて運用します。WAFは、Webアプリへの攻撃を検知・遮断する仕組みです。多要素認証は、パスワード以外の要素も組み合わせて本人確認を強める認証方式です。管理画面への多要素認証適用やWAFの運用を組み合わせると、入口対策に厚みが出て重大事故の確率を下げやすくなります。

対策メニュー別に見る費用の考え方（保守運用／監視／バックアップ設計／復旧支援／更新管理）

対策費は、項目ごとに「定額に向くもの」と「作業発生時に備えるもの」を分けると、運用が破綻しにくくなります。定額は、毎月発生する監視・更新・レポートなどに向きます。従量は、調査・復旧・大規模改修など発生頻度が読みにくいものに向きます。費用区分を先に決めると、社内稟議や委託先との契約の組み立てもスムーズになります。

対策項目	目的	実施頻度	費用の持ち方
更新管理（CMS・周辺ソフト）	脆弱性低減と機能維持	月次〜四半期	定額＋例外は従量
監視（稼働・改ざん兆候・負荷）	早期検知と初動短縮	常時	定額
バックアップ設計・運用	復旧の成功率を上げる	日次〜週次	定額
復旧支援（障害・改ざん対応）	停止時間の最小化	発生時	従量＋優先対応枠
小改修（文言・軽微な追加）	運用の停滞を防ぐ	随時	月一定時間の定額

保守運用は「作業」ではなく「仕組み」への支払いにする

保守運用の予算は、担当者の頑張りに依存しない仕組みを作る費用として扱うと、意思決定が安定します。具体的には、連絡経路、アクセス権限、変更履歴の管理、月次報告のフォーマットなど、運用を回すための基本設計が含まれます。ここが整うと、緊急対応時も誰が何を判断するかが揃い、復旧までの遠回りが減ります。

監視は「気づく」だけでなく「動ける」条件が重要

監視を入れても、通知が多すぎたり、夜間に誰も見ていなかったりすると効果が出にくくなります。SLAは、稼働率や応答時間など運用品質を数値で取り決める合意のことです。SLAに合わせて、通知の優先度、一次対応の範囲、連絡の所要時間を決めると、監視費が事業の安心に直結します。監視項目は最初から盛りすぎず、運用できた項目から増やす方が長続きします。

バックアップは取得より復旧が本体になる

バックアップは取れているが復旧できない状態は避けたいポイントです。復旧支援の予算を抑えるためにも、復旧手順の整備と定期的な復旧テストを運用に組み込みます。復旧テストは、バックアップから実際に戻せることを確認する検証作業です。復旧テストを実施して初めて、バックアップの頻度や保存期間が事業の要件に合っているか判断できます。

効果をどう説明するか：損失回避と運用品質の指標

経営への説明は「事故が起きないこと」だけに寄せると、投資判断が曖昧になります。損失回避は、事故時に発生する復旧費や停止による機会損失を減らす考え方です。加えて、運用品質の指標を置くと、対策が回っているかを平時から確認できます。

指標は3群に分けると伝わりやすい

1つ目は予防の指標で、更新適用までの所要日数や、更新対象の消化率が該当します。2つ目は検知の指標で、MTTDは、異常発生から検知までの平均時間を表す指標です。3つ目は復旧の指標で、MTTRは障害検知から復旧までの平均時間を表す指標です。MTTDとMTTRが短縮していれば、運用の投資が効いている説明になります。

レポートは「安心材料」と「次の打ち手」を同時に出す

月次の報告は、実施した更新、検知した異常、実施した改善を、経営が読める粒度で整理します。数字だけでなく、次に優先する改善と、その理由を添えると、予算の継続判断がしやすくなります。改善は大きな改修だけではなく、権限の見直しや通知ルールの調整など小さな積み重ねも含めます。

体制設計：内製・外部委託・分担の現実解

体制は「誰が触れるか」と「誰が判断するか」を分けて設計すると破綻しにくくなります。運用は、平時の小さな作業よりも、緊急時の判断と復旧に差が出ます。そこで、内製・外部委託・分担の3パターンを比較し、向く条件を先に整理します。

体制	向く条件	強み	つまずきやすい点
内製	更新頻度が高い／社内に実装・運用の経験者がいる	意思決定が速い、改善を回しやすい	退職・兼務で属人化しやすい、夜間対応の負荷
外部委託	体制が薄い／許容停止時間が短い／複数サイトを統制したい	監視・復旧の専門性を使える、運用が平準化する	責任分界が曖昧だと「相手待ち」になる
分担	社内で意思決定はできるが、実作業や監視を外に寄せたい	コストとスピードのバランスを取りやすい	連絡経路が増えると初動が遅れやすい

まず「判断」と「作業」を切り分ける

責任分界は、どの範囲を誰が責任を持って対応するかを決めることです。社内は「優先順位と停止の判断」を持ち、外部は「監視・一次対応・復旧作業」を担う形が、従業員10〜500名規模では回りやすい傾向があります。逆に、判断まで外に預けると、緊急時に社内承認が追いつかず復旧が遅れがちです。

属人化を減らす最低条件は「台帳」と「手順」

台帳は、アカウント・権限・契約・構成など運用に必要な情報を一覧にしたものです。最低限として、ドメイン管理、サーバー契約、管理画面のアカウント、バックアップの保存先、緊急連絡先を1枚にまとめます。手順は、平時の更新手順と、異常検知時の一次対応手順を先に整え、復旧の判断が迷子にならない状態を作ります。

進め方とベンダー管理：契約・責任分界・運用設計

外部ベンダー管理で揉めやすいのは「何をやってくれるか」より「どこまでが定額か」「連絡と判断のルートはどれか」です。ここを契約と運用設計で先に固定すると、コストの見通しが立ち、インシデント時の初動も速くなります。

契約で決めておきたい3点

1つ目は対象範囲です。サイト本体だけでなく、フォーム、外部連携、サーバー周辺まで含むかを明確にします。2つ目は応答条件です。夜間・休日の扱い、一次対応の範囲、エスカレーションの時間を決めます。3つ目は変更管理です。変更管理は、更新や設定変更を記録し、影響と責任を追える状態にする運用です。変更履歴が残るだけで、復旧の成功率が上がります。

見積と運用を安定させる「事前の整理項目」

相談や委託の前に、次の情報がそろうと見積の前提が揃い、無駄な追加費用も起きにくくなります。

• サイト一覧（URL、用途、関係部門）
• 利用中のCMSと主要機能（会員、予約、採用、決済など）
• サーバー/クラウドの契約先と管理者情報
• 直近の更新履歴（いつ、何を更新したか）
• バックアップの取得方法と保存期間
• 連絡先（社内判断者、外部ベンダー、休日の連絡）
• 許容停止時間と優先復旧順位（表Aの更新版）

月次運用を「回る形」に落とす

月次の定例で、更新の実施状況、検知した異常、残課題と優先順位を共有します。KPIは、目標達成度を測るための重要指標です。KPIは更新消化率、MTTD、MTTRなど少数に絞り、未対応の理由もセットで残します。判断材料が揃うと、年度の予算も「去年の踏襲」ではなく「リスクと体制の変化」に合わせて調整できます。

まとめ

セキュリティ対策費の予算は、相場探しより先に「守る対象」「許容停止時間」「体制」の3点をそろえることでブレにくくなります。対策を予防・検知・復旧に分け、定額で持つ領域と発生時に備える領域を整理すると、経営として説明できる形になります。内製・外部委託・分担は優劣ではなく条件で選び、台帳と手順で属人化を抑えることが、長期的なコストとリスクを下げる近道です。