Webシステム保守とは？まず押さえたい基本
Webシステム保守とは、公開済みのWebサイトや業務システム、ECサイト、予約システムなどを安全かつ安定して使い続けるための運用・点検・修正対応を指します。
中小企業では「開発が終われば一段落」と考えられがちですが、実際には公開後のほうが重要です。サーバー障害、セキュリティ更新、バックアップ、外部APIの仕様変更、問い合わせ対応など、日常的に発生する作業を継続的に管理しなければ、売上機会の損失や情報漏えいリスクにつながります。
なお、実務では「保守」と「運用」をまとめて扱うことも多いですが、厳密には次のように分けて考えると理解しやすくなります。
| 区分 | 主な内容 | 具体例 |
|---|---|---|
| 保守 | 不具合修正・更新・予防対応 | 脆弱性対応、バグ修正、ライブラリ更新、障害原因の調査 |
| 運用 | 日常的な管理・継続利用のための作業 | 監視、バックアップ、アカウント管理、定期レポート、問い合わせ一次対応 |
本記事では、実務上まとめて語られることの多い「Webシステム保守」を、中小企業が外注先を選ぶ際に確認すべきポイントに絞って解説します。
中小企業が知るべき4つの作業内容
1. 監視・障害対応
最も基本となるのが、システムが正常に動いているかを確認する監視と、異常発生時の初動対応です。Webシステムでは、サーバー停止だけでなく、アプリケーションエラー、メール送信失敗、ディスク容量不足、証明書期限切れなど、さまざまな障害が起こります。
- 死活監視（サイトにアクセスできるか）
- リソース監視（CPU、メモリ、ディスク容量など）
- ログ監視（エラー増加、不正アクセス兆候など）
- 障害発生時の一次切り分け
- 復旧作業、または関係ベンダーへのエスカレーション
「24時間監視」と「24時間復旧対応」は別物です。監視は自動化されていても、実際の作業着手は営業時間内のみという契約も珍しくありません。
2. セキュリティ更新・脆弱性対応
Webシステム保守で特に重要なのがセキュリティ対応です。OS、ミドルウェア、CMS、プラグイン、フレームワーク、ライブラリなどは継続的に脆弱性情報が公開されるため、放置すると攻撃対象になりやすくなります。
- OS・ミドルウェアのセキュリティパッチ適用
- PHP、Node.js、Javaなど実行環境の更新
- WordPress等CMS本体・プラグイン更新
- フレームワークや依存ライブラリの更新
- WAF、アクセス制御、認証設定の見直し
ただし、更新作業は「適用するだけ」で終わりではありません。更新によって画面崩れや機能不具合が起きることもあるため、事前検証・バックアップ・ロールバック手順まで含めて確認する必要があります。
3. バックアップ・復元体制の維持
バックアップは多くの保守契約に含まれますが、見落とされやすいのが「復元できるかどうか」です。バックアップファイルが存在していても、復元テストをしていなければ、障害時に使えない可能性があります。
- データベースの定期バックアップ
- アプリケーションファイルのバックアップ
- 保存世代数の管理
- 保存先の分離（同一サーバー外への保管など）
- 復元テストの実施
RPOやRTOの考え方とも関係しますが、たとえば日次バックアップなら、障害発生時に最大で直近24時間分のデータが失われる可能性があります。受注や予約など更新頻度が高いシステムでは、日次だけで十分かを検討すべきです。
4. 不具合修正・小規模改善対応
Webシステム保守には、公開後に見つかった不具合の修正や、軽微な改善対応が含まれることがあります。たとえば、フォーム送信エラー、表示崩れ、管理画面の不具合、軽微な文言修正などです。
ただし、ここで注意したいのは、「保守」と「追加開発」の境界が曖昧になりやすいことです。新機能追加、画面設計変更、外部サービス連携の追加などは、通常は別途見積もりになることが多いです。
| 作業内容 | 保守に含まれやすい | 要確認 | 別料金になりやすい |
|---|---|---|---|
| 監視・アラート通知 | ○ | ||
| 軽微な不具合修正 | ○ | ||
| セキュリティパッチ適用 | ○ | ||
| バックアップ取得 | ○ | ||
| バックアップ復元 | ○ | ||
| 新機能追加 | ○ | ||
| 画面デザイン全面改修 | ○ | ||
| 外部APIの大幅改修対応 | ○ | ○ |
外注先を決める前に明確にすべき「対応範囲」
保守契約に含まれる作業・含まれない作業を明文化する
保守契約で起こりやすいトラブルの多くは、対応範囲の認識違いです。「当然やってくれると思っていた」「それは保守外ですと言われた」という行き違いを防ぐため、契約前にインスコープとアウトオブスコープを文書化しましょう。
特に確認したいのは、作業の有無だけでなく、頻度・上限工数・対応時間帯・対象環境です。
| 確認項目 | 確認すべき内容 |
|---|---|
| 対象システム | 本番のみか、ステージング・開発環境も含むか |
| 対象範囲 | アプリ、サーバー、DB、ネットワーク、外部APIのどこまでか |
| 対応時間 | 平日日中のみか、夜間休日も含むか |
| 工数上限 | 月額内で何時間まで対応可能か |
| 報告方法 | 月次報告、障害報告、定例会の有無 |
| 除外事項 | 追加開発、他社製品障害、第三者起因障害などの扱い |
追加費用が発生するケースを事前に把握する
月額固定の保守契約でも、条件次第で追加費用が発生することは珍しくありません。見積もり比較では月額だけに注目しがちですが、実際には追加費用の条件が総コストを左右します。
- 月間対応工数の超過：契約内の時間を超えた問い合わせ・調査・修正対応
- 夜間・休日対応：営業時間外の緊急出動や復旧作業
- メジャーバージョンアップ：PHP、DB、フレームワーク、CMSの大規模更新
- サーバー移行・構成変更：クラウド移行、スケール変更、ネットワーク再設計
- 第三者診断：脆弱性診断、ペネトレーションテスト、監査対応
- 外部API仕様変更への追従：決済、配送、地図、SMS、認証などの改修
「何をしたら追加費用になるのか」を契約前に一覧化してもらうと、予算超過のリスクを減らせます。
対応システム・環境の範囲を確認する
保守対象は、システムそのものだけではありません。どのクラウド、どのOS、どのミドルウェア、どの外部サービスまで見てもらえるのかを確認する必要があります。
たとえばAWS、Google Cloud、Microsoft Azureなど主要クラウドに対応していても、実際には特定サービスのみ得意というケースがあります。また、外部API連携は「障害切り分けまでは対応するが、相手側仕様変更への改修は別料金」という契約も一般的です。
なお、クラウド事業者自体のSLAと、保守会社のSLAは別です。クラウド側が高い可用性を掲げていても、自社システム全体の可用性が同じ水準になるとは限りません。
SLA（サービスレベル合意）の読み方と注意点
応答時間・対応開始時間・復旧目標時間を分けて確認する
SLAで誤解が起きやすいのが、「応答」と「対応開始」と「復旧完了」が混同されることです。たとえば「1時間以内に対応」と書かれていても、実際には受付連絡のみを指す場合があります。
| 指標 | 意味 | 確認ポイント |
|---|---|---|
| 一次応答時間 | 障害連絡に対して受領連絡を返すまでの時間 | 自動返信のみで満たすのか、人手対応か |
| 対応開始時間 | 実際に調査・復旧作業へ着手するまでの時間 | 営業時間外でも開始されるか |
| RTO | 目標復旧時間 | 暫定復旧か完全復旧か |
| RPO | 目標復旧時点 | どの時点までデータを戻せるか |
RTOとRPOはBCPやDRの文脈でも使われる一般的な指標ですが、契約書では定義が曖昧なことがあります。「何をもって復旧とみなすか」まで確認することが重要です。
※RTO・RPOの適切な水準は、業種、売上影響、法令対応、顧客契約によって異なります。一律の正解はありません。
稼働率保証（99.9%など）の意味を正しく理解する
「稼働率99.9%」は高く見えますが、許容ダウンタイムに換算すると意外に長く感じることがあります。また、計算対象が月間か年間か、計画停止を含むか除くかでも意味が変わります。
| 稼働率 | 年間許容ダウンタイムの目安 | 月間許容ダウンタイムの目安 |
|---|---|---|
| 99.0% | 約87.6時間 | 約7.3時間 |
| 99.9% | 約8.76時間 | 約43.8分 |
| 99.95% | 約4.38時間 | 約21.9分 |
| 99.99% | 約52.6分 | 約4.4分 |
この数値自体は現在でも通用する一般的な計算値ですが、実際のSLAでは小数点以下の扱いや計測単位が異なる場合があります。必ず契約書や約款の算定方法を確認してください。
また、保証対象がインフラのみなのか、アプリケーションを含むのかも重要です。サーバーは稼働していても、ログインできない、注文できない、といった状態は利用者にとっては「停止」と同じです。
SLA違反時の取り扱いを確認する
SLAに基準値が書かれていても、違反時の扱いが定められていなければ、実質的に努力目標に近いことがあります。サービスクレジットや料金減額の有無、申請期限、適用除外を確認しましょう。
- サービスクレジットの有無
- 申請しないと適用されないのか
- 対象外となる障害の範囲
- 計画メンテナンスの扱い
- 第三者サービス障害時の扱い
なお、SLA違反時の返金があっても、実際の事業損失を十分に補填できるとは限りません。SLAは重要ですが、それだけでリスク対策が完結するわけではない点に注意が必要です。
保守契約書で確認したい責任範囲と法務上の注意点
ここからは契約面の話です。実際の契約条件は個別事情で大きく変わるため、重要案件では法務確認をおすすめします。
障害発生時の責任範囲を明確にする
保守会社が責任を負うのは、通常、保守会社の過失や契約違反が原因と認められる範囲に限られます。すべての障害について無制限に責任を負う契約は一般的ではありません。
- 保守会社の設定ミスや更新ミスによる障害
- 自社担当者の誤操作による障害
- クラウド事業者や外部API提供元の障害
- ゼロデイ脆弱性など予見困難な事象
- 保守対象外システムで発生した障害
上記のどこまでを誰が負担するのかを曖昧にしないことが重要です。特に、複数ベンダーが関与する環境では、「切り分け責任を誰が持つか」を決めておくとトラブルを減らせます。
情報漏えい・データ損失時の賠償上限を確認する
多くの契約では、損害賠償額に上限が設けられています。たとえば「直近○か月分の受領保守料を上限とする」といった条項です。これは珍しいものではありません。
そのため、月額10万円で上限が6か月分なら、最大でも60万円までという設計になり得ます。実損がそれ以上でも、契約上は回収できない可能性があります。
- 賠償上限額の確認
- 故意・重過失時に上限が外れるか
- 個人情報漏えい時の通知・調査協力範囲
- 保険加入の有無（サイバー保険、賠償責任保険など）
なお、日本では個人情報保護法に基づく対応が問題になることがありますが、具体的な報告義務や対応要否は事案によって異なります。漏えい事故が疑われる場合は、自己判断せず専門家へ相談してください。
契約解除・乗り換え時の引き継ぎ条件を確認する
保守会社の変更時に困るのが、ドキュメントや認証情報、ソースコード、設定情報が十分に引き継がれないケースです。契約開始時から出口条件を決めておくことが大切です。
- 解約予告期間：1〜3か月前通知が多いが、個別契約で異なる
- 引き継ぎ対象物：ソースコード、設計書、手順書、認証情報、証明書、バックアップ情報、監視設定など
- 引き継ぎ費用：月額内か、別料金か、上限はあるか
- 知的財産権：改修コードや成果物の権利帰属
- アカウント管理：クラウドやドメインの契約主体が自社かどうか
特にクラウド、ドメイン、SSL証明書、外部SaaSの契約主体が保守会社側になっていると、乗り換え時の難易度が上がります。可能な限り、自社名義で管理できるものは自社名義にしておくと安全です。
信頼できる外注先を見極める実践的な選び方
見積もり依頼時に確認したい質問リスト
保守会社の質は、契約前の説明の明確さに表れやすいです。以下の質問に具体的に答えられるかを確認しましょう。
- 月額費用に含まれる作業と、含まれない作業を一覧で提示できますか？
- 月額内の対応工数上限は何時間ですか？超過時の単価はいくらですか？
- 障害時の一次応答時間、対応開始時間、復旧目標時間はそれぞれ何ですか？
- 夜間・休日対応は可能ですか？追加費用はいくらですか？
- セキュリティパッチはどの範囲まで、どの頻度で適用しますか？
- バックアップの取得頻度、保存期間、復元テストの有無を教えてください
- 月次報告書や障害報告書のサンプルはありますか？
- 担当者が変わる場合の引き継ぎ体制はどうなっていますか？
- 契約終了時に引き渡される資料・認証情報の一覧はありますか？
技術力・対応品質を見極めるポイント
価格だけで選ぶと、後から対応品質で苦労することがあります。次の観点で総合的に判断しましょう。
- 同じ技術スタックの実績：言語、フレームワーク、CMS、クラウド、DBの経験
- セキュリティ体制：社内ルール、権限管理、ログ管理、委託先管理の有無
- ドキュメント文化：手順書、構成図、変更履歴を残す運用か
- コミュニケーション品質：回答の速さ、説明の具体性、専門用語のわかりやすさ
- 属人化の少なさ：担当者依存ではなく、チームで対応できるか
ISMSなどの認証取得は一定の参考になりますが、認証の有無だけで品質を断定することはできません。実際の運用手順や報告体制まで確認することが大切です。
複数社比較で使えるチェックシート
複数社を比較する場合は、感覚ではなく評価項目をそろえて比較すると判断しやすくなります。
| 評価項目 | A社 | B社 | C社 |
|---|---|---|---|
| 月額費用と対応範囲のバランス | |||
| 対応時間帯の広さ | |||
| SLAの明確さ | |||
| セキュリティ更新体制 | |||
| バックアップ・復元体制 | |||
| 同技術スタックの実績 | |||
| 報告・定例・連絡体制 | |||
| 契約終了時の引き継ぎ透明性 | |||
| 見積もり回答の丁寧さ |
最安値の会社が最適とは限りません。停止時の損失、社内にどこまで知見があるか、将来の拡張予定があるかまで含めて選ぶことが重要です。
保守契約でよくある失敗例
- 対応範囲を確認していなかった：障害調査は含まれるが、修正は別料金だった
- SLAの意味を誤解していた：「24時間対応」が実際は24時間受付のみだった
- バックアップだけ見て復元体制を見ていなかった：復元テストがなく、障害時に復旧できなかった
- 契約終了時の条件を見ていなかった：引き継ぎ資料が不足し、乗り換えコストが膨らんだ
- クラウドやドメインを他社名義で契約していた：移管に時間と費用がかかった
これらはどれも珍しい失敗ではありません。契約前に質問し、書面に残すだけで防げるものが多いです。
よくある質問（FAQ）
保守を依頼したのに対応が遅い場合はどうすればいいですか？
まず、契約書やSLAにある一次応答時間、対応開始時間、復旧目標時間と、実績を比較してください。遅延が継続しているなら、記録を残したうえで改善要請を行いましょう。SLA違反時のサービスクレジットや是正手順がある場合は、その条件も確認してください。
ただし、単発の遅延だけで即座に契約違反と断定できるとは限りません。障害の重大度、原因の所在、営業時間外かどうかなども影響します。
保守契約の期間はどのくらいが一般的ですか？
1年契約の自動更新は一般的ですが、6か月や月次更新のケースもあります。初回は短めに契約して、対応品質を見てから更新する方法も有効です。長期契約は単価が下がることがありますが、乗り換えにくくなる点には注意しましょう。
開発会社以外に保守を依頼しても問題ありませんか？
問題ありません。実際、開発と保守を別会社に依頼するケースはあります。ただし、仕様書、ソースコード、インフラ構成情報、認証情報、運用手順書などが十分にそろっていることが前提です。
なお、成果物の権利帰属や利用許諾の扱いは契約によって異なります。「当然自社のもの」と思い込まず、契約書で確認してください。
Webシステム保守の費用相場はどのくらいですか？
費用はシステム規模、対応時間帯、監視範囲、セキュリティ要件、月間工数によって大きく変わるため、一律の相場を断定するのは適切ではありません。小規模なサイト保守と、業務システムやECの24時間体制では前提がまったく異なります。
そのため、月額だけで比較せず、何時間分の対応が含まれるのか、障害時の体制はどうか、追加費用条件は何かをセットで確認してください。
まとめ：Webシステム保守は「月額料金」より「契約の中身」で選ぶ
Webシステム保守は、単なるトラブル対応ではありません。監視、セキュリティ更新、バックアップ、不具合修正を通じて、事業を止めないための土台を支える重要な業務です。
中小企業が特に押さえたいのは、次の4点です。
- 監視・障害対応
- セキュリティ更新・脆弱性対応
- バックアップ・復元体制
- 不具合修正・小規模改善対応
そして外注先選びでは、対応範囲、SLA、追加費用条件、責任分界、引き継ぎ条件を契約前に確認することが欠かせません。
曖昧な説明のまま契約すると、後から「それは対象外です」と言われやすくなります。逆に、質問への回答が具体的で、文書化に前向きな会社は、保守運用でも透明性が高い傾向があります。
保守会社を選ぶときは、価格だけで決めず、自社に必要な保守内容を言語化し、それに合う体制を持つ会社かどうかで判断してください。
