ホームページ保守管理費用まとめ｜相場／品質を落とさず節約するコツ

2025年8月11日2026年1月21日

「ホームページの保守管理費用って、結局いくらが普通なんだろう？」
制作会社や保守会社から月額プランを提案されても、内容が“保守一式”だと比較しにくく、モヤモヤしたまま契約してしまいがちです。

たとえば、こんな悩みはありませんか？

「月額5,000円〜5万円まで幅があるけど、何が違うの？」
「更新はほとんどないのに、毎月払う必要ある？」
「安いプランに変えたいけど、セキュリティやバックアップが不安…」
「WordPressの更新は自分でできそう。でも、失敗して壊れたらどうする？」
「見積が高いと言われたけど、それって適正？ぼったくり？」
「“緊急対応込み”って書いてあるけど、どこまでやってくれるの？」

保守管理費用は「月額の数字」だけで決まりません。
対応範囲（何をするか）×体制（いつ誰が対応するか）×サイト種別（止まった時の損失）で、適正価格も最適プランも変わります。

この記事では、初心者でも判断できるように、

保守管理費用の相場感と、価格帯ごとの“含まれやすい内容”
「高い／安い」を見抜くための内訳の考え方
品質を落とさず節約するコツ（削っていい所・ダメな所）
内製と外注の現実的な分け方
相見積もりで失敗しない比較ポイント

を、具体例とチェック観点つきで整理します。
読み終えるころには、「あなたのサイトに必要な範囲」と「ムダな支出」が言語化でき、納得して見積判断ができる状態を目指します。

【おすすめホームページサービス↓】

プロにまるっとお任せ！ホームページ製作0円から！【サクペジ】
ECサイト制作が補助金活用で、最大75%OFF！【ホームページDX】
初めてのホームページ作成なら、ホームページ.com！初期費オール０円キャンペーン実施中
月額9,900円コスパ最強【99ホームページ】
SEO重視かつモバイルファーストのレスポンシブデザインでWebサイトの制作を行います。【aruku】
オンライン完結×ハイクオリティ！【ホームページ制作ならアドバン】

結論：保守管理費用は「月額」だけで決まらない（範囲×体制×サイト種別）

「ホームページの保守管理費用」と聞くと、月額〇円だけに目が行きがちです。
でも実際は、次の3つの掛け算で決まります。

範囲：何をやるか（監視だけ／更新も／改善提案まで）
体制：誰がやるか（自社対応／制作会社／保守専門会社）
サイト種別：どれくらい壊れやすいか（静的／WordPress／EC・会員など）

まず「固定費」と「作業費」を分けて考える

保守管理費用は、大きく2層です。

① 固定費（サイトを“置いておく”ための費用）

サーバー代、ドメイン更新、SSL など
例：SSLは無料（Let’s Encrypt）で運用できるケースもあれば、有料証明書が必要なケースもあります。

② 作業費（サイトを“守り・回す”ための費用）

監視、バックアップ、セキュリティ対策、CMS更新、更新作業、問い合わせ対応など
ここが“月額の差”になりやすいポイントです。

ざっくり相場の見方（初心者向けの目安）

目安としては、上位記事でよく見られるレンジは次のイメージです（※内容・体制で上下します）。

スクロールできます

想定	何が含まれやすい？	月額のイメージ
最小構成（自社中心）	インフラ中心（サーバー・ドメイン・SSL等）	低め（作業費はほぼゼロ）
標準構成（外注あり）	監視・バックアップ・更新対応・CMS更新など	数千円〜数万円
強化構成（成果も意識）	セキュリティ強化＋解析レポート＋改善提案	数万円〜（サイト規模で上振れ）

ポイントは、「いくらか」より「何が入っているか」です。
同じ月額でも、範囲が違うと“守れるレベル”が全然変わります。

まず押さえる判断軸：どこまで外注し、何を内製するか

ここを最初に決めるだけで、見積もりのブレが激減します。
考え方はシンプルで、“事故ると致命傷”は外注寄り、“頻度が高い軽作業”は内製寄りが基本です。

外注寄りにしたい領域（失敗したときの損失が大きい）

セキュリティ（改ざん・不正ログイン・マルウェア）
バックアップ運用（復元できる体制まで）
障害対応（サイトが見られない／メールフォームが動かない等）
CMS更新の検証（更新→不具合の切り分け）

👉 ここは、担当者の属人化が起きると危険なので、ルール化・窓口一本化が効きます。

内製寄りにしやすい領域（ルール化しやすく、コストが膨らみやすい）

お知らせの追加、軽い文章修正、画像差し替え
よくある更新（営業時間・料金表・採用情報など）

👉 更新頻度が多いなら、外注すると月額が上がりやすいので、
「誰が」「どの画面で」「どんな手順で」更新するかを整えるほど得です。

判断を早くする“3ステップ”

ステップ1：やりたいことを「守る／回す／伸ばす」に分ける

守る：監視、バックアップ、セキュリティ
回す：更新対応、問い合わせ、軽微改修
伸ばす：解析、改善提案、SEO/広告の運用

ステップ2：社内で確保できる時間を決める

月に何時間までなら対応できるか
“できる”ではなく、現実に回せる時間で判断します

ステップ3：サイト種別でリスク係数を上げ下げする

静的サイト：比較的シンプル（ただし更新は外注寄りになりがち）
WordPress：更新しやすい反面、アップデート起因の不具合が起きうる
EC/会員/予約：外部連携が増えるほど保守は重くなりやすい

よくある失敗（避けるだけでコスパが上がる）

「更新も保守も全部込み」→ 範囲が曖昧で、結局追加費用
「月額が安い」→ 障害時の対応範囲が薄く、復旧が遅い
「ドメインやサーバーの管理が制作会社名義」→ 乗り換え時に揉める

最初に、作業範囲と責任分界（どこまでが誰の担当か）を言語化するのがコツです。

このページでわかること（相場／内訳／プラン比較／見積チェック／節約策）

この先を読むと、次のことができるようになります。

✅ 保守管理費用の“妥当ライン”を、サイト規模・目的別に判断できる
✅ 月額の中身（監視・バックアップ・セキュリティ・更新など）を理解し、見積の比較軸が持てる
✅ 固定プラン／従量／チケット／スポットの違いがわかり、自社に合う契約形態を選べる
✅ 「安いのに危ない見積」を避けるためのチェック項目が手に入る
✅ 品質を落とさずに費用を抑える、削っていい所／ダメな所が整理できる

結局のところ、保守管理費用の最適解は
「いくら払うか」ではなく、“何を守りたいか”を先に決めることで見えてきます。

保守・運用・更新・改善の違い：同じ“管理”でも中身が別物

「保守管理」とひとことで言っても、実務では中身が4種類に分かれます。
ここが曖昧だと、見積もり比較ができなかったり、「それは別料金です」が起きやすくなります。

保守：不具合やトラブルに備えて“正常を保つ”ための作業（点検・修正・安全対策など）
運用：日々のルール・手順で“回し続ける”ための作業（監視、定期作業、問い合わせ対応など）
更新：掲載内容を“差し替える”作業（テキスト・画像・お知らせ追加など）
改善：成果を“伸ばす”作業（導線・CVR・SEO・速度・UI改善など）

同じ月額でも、どこまで含むかで値段は大きく変わります。
そこで次の考え方が便利です。

「維持（止めない）」「守る（壊さない）」「育てる（成果を伸ばす）」に分けて考える

まず、目的を3つに分解すると迷いが減ります。

維持（止めない）

サイトを“稼働し続けさせる”領域です。最低限ここが弱いと、どんな施策も水の泡になります。

サーバー・ドメイン・SSLの期限管理
死活監視（落ちたら気づける仕組み）
バックアップ（「取る」だけでなく、戻せること）
障害時の連絡ルート（誰が・いつ・どう動くか）

✅ 初心者が押さえるコツ：「復旧」までの責任範囲を契約書・見積で明文化する

守る（壊さない）

“攻撃や不具合”から守る領域です。特にWordPressなどCMSはここが重要になります。

CMS／テーマ／プラグインのアップデート方針（即時か、検証後か）
不正ログイン対策（権限、二段階認証、アクセス制限）
改ざん・マルウェア対策（検知・隔離・復旧の流れ）
ログや設定の管理（原因追跡ができる状態）

✅ 初心者が押さえるコツ：「更新作業」と「セキュリティ対応」は別物。両方含むか確認する

育てる（成果を伸ばす）

集客や問い合わせなど、“ビジネス成果”に直結する領域です。ここから先は、保守というより「運用改善」に近づきます。

アクセス解析と課題整理（どこで離脱しているか）
導線・フォーム改善（問い合わせ率の改善）
SEO改善（構成・内部リンク・表示速度など）
施策の優先順位付け（やることを絞る）

✅ 初心者が押さえるコツ：改善は青天井になりやすいので、KPI（例：月◯件の問い合わせ）を置く

4つの違いが一目でわかる整理表

スクロールできます

区分	目的	具体例	見積でズレやすい点
保守	正常を保つ	不具合対応、点検、セキュリティ対応	「どこまでが保守？」が会社で違う
運用	回し続ける	監視、定期作業、問い合わせ一次対応	受付時間・対応速度が曖昧になりがち
更新	情報を最新に	文言修正、画像差し替え、ページ追加	回数上限／修正回数／納期で差が出る
改善	成果を伸ばす	解析→提案→実装、導線最適化	“保守費”に含めると高額化しやすい

あなたのサイトはどのタイプ？（名刺代わり／集客目的／採用／EC・予約）

同じ保守でも、サイトの目的によって「必須」が変わります。
ここを合わせると、過不足のない費用設計ができます。

名刺代わりサイト（会社案内・店舗情報が中心）

優先：維持 → 守る（最低限）
更新頻度が少ない分、止まったり改ざんされると信頼ダメージが大きいタイプです。

必須にしやすい：期限管理、バックアップ、最低限のセキュリティ
更新の考え方：月◯回ではなく、“必要時のみ”でも成立しやすい
注意点：フォームがあるなら、送信テストと迷惑メール対策は定期的に

集客目的サイト（問い合わせ・資料請求・SEO集客）

優先：維持 → 守る → 育てる
「動いているだけ」では足りず、改善が成果に直結します。

必須にしやすい：監視＋セキュリティ＋更新（新着・事例・ブログ等）
改善の考え方：解析→優先順位→小さく改善（大改修より効きやすい）
注意点：改善は範囲が広いので、月額固定に入れるか、別枠（チケット等）にするかを決める

採用サイト（応募につなげる・ブランディング重視）

優先：維持 → 守る＋更新（鮮度が命）
情報が古いだけで応募率が落ちやすいタイプです。

必須にしやすい：募集要項の更新、写真・実績の更新、フォーム稼働確認
改善の考え方：応募導線（募集→エントリー）を短く、わかりやすく
注意点：採用は季節要因があるため、繁忙期だけ手厚くする設計も相性が良い

EC・予約サイト（決済・会員・在庫・予約連携あり）

優先：維持と守るが最重要（強め）
止まる・漏れる・決済できないが直撃ダメージになるため、保守の密度が上がります。

必須にしやすい：強固なセキュリティ、監視、復旧体制、外部連携のチェック
更新の考え方：商品やプラン更新が多いなら、運用設計（手順化）がコスト削減に直結
注意点：障害時の対応を曖昧にしない（例：受付時間、一次対応、復旧目標の考え方）

迷ったときの決め方（初心者向け）

最後に、判断を早くするコツです。

止まったら困るもの（フォーム、予約、決済）を先に洗い出す
それに対して「維持」と「守る」を最低限固める
余力が出たら「育てる（改善）」を小さく回す

この順番にすると、費用も作業もブレにくくなります。

ホームページ保守管理費用の相場感：よくある価格帯と含まれる内容

保守管理費用は、ざっくり言うと 「固定費（サーバー等）＋作業費（保守・更新等）」 で構成されます。
相場を見るときは、月額の数字だけでなく 「その月額に何が含まれているか」 をセットで確認するのがコツです。

最小構成：止めないための最低ライン（監視・更新・バックアップ中心）

目安として多いのは、月額5,000円〜1万円台あたり（※サイト規模・体制で変動）。
このゾーンは「まず落とさない・戻せる」を優先します。

含まれやすい内容（例）

監視（最低限）
- サイトが表示できるかのチェック（死活監視）
- 異常時の通知（メール等）
バックアップ
- 自動バックアップ（頻度・保持世代は要確認）
- できれば「復元作業」まで範囲に入っているか確認
更新（限定的）
- CMS／プラグイン更新などの“技術的更新”が中心
- 文章修正などの“コンテンツ更新”は回数制限があることも

初心者がここで確認したいポイント

バックアップは「取っている」だけでなく「戻せる」か
障害時の対応が 連絡のみ なのか、復旧まで なのか
更新の対象が「WordPress本体だけ」なのか「プラグイン・テーマまで」なのか

標準構成：更新と軽微改修まで含むプランが多いゾーン

目安としてよく見かけるのは、月額1万円〜3万円前後（※更新頻度や範囲で上下）。
「最低限に＋日常運用」を足したイメージです。

含まれやすい内容（例）

最小構成の内容（監視・バックアップ・アップデート）
更新代行（ある程度）
- テキスト差し替え、画像差し替え、お知らせ追加
- 月◯回まで、または月◯時間まで、など上限が付くことが多い
軽微改修（小さな調整）
- バナー差し替え、導線の微調整、フォーム文言の修正など
- “デザイン変更”や“機能追加”は別料金になりやすい

ここで失敗しないコツ

上限の単位を確認（回数なのか、工数なのか）
「軽微改修」の定義を確認（どこまでが軽微？）
納期の目安（通常対応と緊急対応）を確認

強化構成：セキュリティ・改善提案・レポートまで含む場合

目安は、月額3万円〜10万円以上まで幅広い（サイト規模・要求水準で上振れ）。
このゾーンは「守る＋育てる」まで含めることが多いです。

含まれやすい内容（例）

標準構成までの内容
セキュリティ強化
- 改ざん検知／WAF等の導入、権限設計、ログ監視
- 脆弱性対応の手順化（更新・検証・ロールバック）
分析レポート・改善提案
- アクセス解析レポート（数値＋解釈）
- 改善案の提示（場合により実装まで含む）

注意点（ここが高額化しやすい）

「レポート」だけなのか、改善提案まで含むのか
提案は含むが、実装は別なのか
改善の優先順位付け（やることが増えすぎない設計）になっているか

高額になりやすいケース（EC/会員/多言語/複数サイト/外部連携）

同じ“保守”でも、次の条件があると費用は上がりやすいです。理由はシンプルで、壊れ方が複雑になり、確認範囲が増えるからです。

高額化しやすい代表例

EC・予約・会員サイト
- 決済、会員DB、予約枠など「止まると売上に直撃」しやすい
多言語対応
- 更新・確認箇所が言語分増える（翻訳管理も絡む）
複数サイト運用
- 管理対象が増え、監視・バックアップ・更新の工数が増える
外部連携が多い
- 予約システム、CRM、MA、チャット、フォーム連携など
- “相手側の障害”の切り分けが必要になる

見積でチェックしたいポイント

「外部連携の障害切り分け」は どこまで 対応してくれるか
本番反映前の 検証環境（ステージング） があるか
重要機能（決済・予約など）の 定期テスト が含まれるか

自社対応と外注の分岐点：社内工数を“金額換算”して決める

「外注は高い気がする…」というときは、社内工数を一度お金に直すと判断が速くなります。

考え方（ざっくり）

社内コスト（目安）＝月の作業時間 × 社内時給（人件費ベース）
さらに見落としがちなのが リスクコスト（障害・改ざん時の損失）

簡単な試算例

スクロールできます

項目	例
月の保守作業	3時間（更新1h＋確認1h＋バックアップ/更新周り1h）
社内時給（ざっくり）	3,000円
社内コスト	3時間×3,000円＝9,000円／月

ここに、次が乗ります。

担当者が休むと止まる（属人化）
緊急時に夜間対応できない
そもそも技術判断が難しく、復旧が遅れる可能性

判断の目安

「月1〜2回の更新だけ」＋「技術に強い人がいる」
→ 自社中心＋必要時スポット外注が相性◎
「更新が多い／担当が兼務で手が回らない」
→ 標準構成（1〜3万円帯）で窓口一本化が現実的
「売上直結（EC/予約）／セキュリティ要件が強い」
→ 強化構成も含め、復旧体制まで買うのが安全

内訳がわかれば高い・安いを判断できる：費用項目の全体像

保守管理費用は、会社によって「まとめ方（パッケージ）」が違います。
だから比較するときは、いったん “項目ごと”に分解して、見積を並べ替えるのがコツです。

① 何が 月額に含まれる？
② 何が 都度見積（追加料金）？
③ 緊急時は 連絡だけ？それとも 復旧まで？

この3点が見えるだけで、「安いけど危ない」「高いけど理由がある」が判断しやすくなります。

必須に近い項目（止まる・漏れるリスクを避ける）

ここは削りすぎると、事故の損失が月額差を超えやすい領域です。

サーバー/ドメイン/SSLの管理（更新・期限・DNS含む）

何をする？（主な作業）

サーバー契約・更新、障害時の一次切り分け
ドメイン更新、期限切れ防止（失効＝サイト/メール停止の原因）
DNS設定（A/CNAME/MX/TXTなど）の変更・管理
SSL/TLS証明書の更新・自動更新設定（HTTPS維持）

見積で必ず確認したいポイント

ドメイン・サーバーの 名義（契約者） は誰か
→ 可能なら 自社名義。移管トラブルを避けられます。
DNS変更が必要なとき、誰が・どこまで対応するか
→ メール（MX/SPF/DKIM/DMARC）まで触るのかも要確認。
SSLが「無料証明書前提」なのか「有料証明書を想定」なのか
→ 業種や要件で有料が必要なこともあるため、前提を揃えましょう。

監視（死活監視・改ざん検知・容量/速度の異常検知）

何をする？（主な作業）

死活監視：サイトが表示できるか、応答が遅すぎないか
改ざん検知：ファイル差分、怪しい挙動の検知
リソース監視：容量逼迫、CPU/メモリ、DB負荷の異常
通知：異常を検知したときの連絡（メール/チャット等）

見積で必ず確認したいポイント

監視間隔（例：5分/10分/1時間）と通知ルート
アラート後の対応が 「連絡のみ」か 「復旧まで」か
速度異常の扱い（「遅い」は障害？それとも調査は別料金？）

初心者が見落としやすい“監視の抜け”

フォーム送信が本当に届くか（表示できてもフォームが壊れていることがあります）
SSL期限切れ、リダイレクト不備、外部タグ（計測）エラー
→ “サイトは開くのに成果が落ちる”系の事故は、監視設計で防ぎやすいです。

バックアップ（頻度・世代管理・復元テストまで）

バックアップは「取っている」だけでは不十分で、戻せることが本体です。

何をする？（主な作業）

バックアップ取得（ファイル＋データベース）
世代管理（何日分残すか）
保管先（同一サーバー内か、別環境にも置くか）
復元対応（戻す作業）と、復元テスト（本当に戻せるか確認）

見積で必ず確認したいポイント

取得頻度：毎日 / 週次 / 更新時のみなど
保持期間：7日 / 14日 / 30日 / それ以上
復元が 月額内か 都度費用か
→ “復元は別料金”だと、いざというときに判断が遅れます。
復元テストの有無
→ 重要サイトほど、定期テストが安心です。

脆弱性対応（CMS/プラグイン/ライブラリの更新方針）

WordPressなどCMSでは、脆弱性対応が保守の中核になりやすいです。

何をする？（主な作業）

CMS本体・テーマ・プラグインのアップデート
更新前の検証（ステージング環境があると事故が減ります）
ロールバック（更新で崩れたときに戻す手順）
不正ログイン対策（権限、二段階認証、不要アカウント整理など）
必要に応じてWAF導入や設定見直し

見積で必ず確認したいポイント

更新方針が「即時」か「検証後」か（サイトの重要度で選びます）
不具合が出た場合の対応が 原因調査まで含むのか
“どこまでが保守で、どこからが改修（別料金）か”の境界

運用で差が出る項目（成果・工数・体験に効く）

ここは会社ごとの「含む/含まない」が最も分かれやすいゾーンです。

テキスト/画像の更新（回数上限・対応範囲・納期）

何をする？（主な作業）

文言修正、画像差し替え、PDF差し替え、お知らせ追加
画像の軽い最適化（容量圧縮、リサイズ、代替テキスト設定など）
更新反映（本番公開）までの手順対応

見積で必ず確認したいポイント

上限が「回数」か「工数（◯時間）」か
何を1回と数えるか（例：1ページ＝1回？ 1箇所＝1回？）
納期（例：通常は◯営業日、急ぎは追加料金）
原稿作成や画像制作が含まれるか（含まれないことが多い）

軽微改修（バナー差し替え、導線修正、フォーム微調整）

“軽微”の定義が曖昧だと、見積比較が一気に難しくなります。

何をする？（主な作業）

ボタン位置調整、リンク導線の変更、簡単なレイアウト調整
フォーム項目の追加/文言調整、エラーメッセージ調整
小さなCSS調整、既存パーツの組み替え

見積で必ず確認したいポイント

軽微改修の具体例が契約に書かれているか
対応工数の上限（例：月◯時間まで）
デザイン作成・コーディング・テストはどこまで含むか
→ テスト（動作確認）が含まれるかで品質が変わります。

解析レポート（見るだけ／改善提案込みで別料金になりやすい）

レポートは「数字を並べるだけ」と「次の打ち手まで出る」で価値が別物です。

何をする？（主な作業）

アクセス解析（GA4など）や検索状況（Search Consoleなど）の集計
定期レポート（PV/流入/検索クエリ/上位ページ等）
改善提案（課題→施策→優先順位→期待効果）

見積で必ず確認したいポイント

レポートが「集計のみ」か「解釈・提案付き」か
改善提案がある場合、実装は 月額内か別途か
目標（問い合わせ数・予約数など）に紐づける設計になっているか

任意・オプションになりやすい項目（必要なら付ける）

ここは“成果”に効く一方で、範囲が広いので 必要なものだけ選ぶのが基本です。

SEO/広告/コンテンツ改善の伴走（コンサル・制作）

含まれやすい内容（例）

キーワード設計、構成案、既存ページの改善提案
記事制作、LP改善、広告運用の設計・調整

見積で確認したいポイント

成果物（何を納品する？）が明確か
例：月◯本の改善提案／月◯本の原稿／月◯回の定例など
目的（問い合わせ、採用応募、予約…）に直結するKPIがあるか

表示速度改善（画像最適化、キャッシュ、CDNなど）

速度改善は「やれば速くなる」ではなく、どこがボトルネックかで打ち手が変わります。

含まれやすい内容（例）

画像圧縮・WebP化、遅延読み込みの調整
キャッシュ設定、不要スクリプト整理、DB最適化
CDN導入/設定（必要な場合）

見積で確認したいポイント

何をもって改善とするか（指標・目標値）
施策の優先順位（全部やると高額になりやすい）
サーバー増強が必要なケースは別費用になるか

メール/フォーム周り（到達保証、スパム対策、CAPTCHA）

フォームは“壊れて気づけない”と機会損失が大きいので、サイト目的によっては優先度が上がります。

含まれやすい内容（例）

迷惑メール対策（CAPTCHA、スパムフィルタ調整）
メール到達性の整備（SPF/DKIM/DMARCなど）
フォーム送信テスト、通知不達の検知（必要に応じて）

見積で確認したいポイント

「到達保証」なのか「ベストエフォート」なのか
フォーム不達が起きたときの一次切り分け範囲

法務・コンプラ対応（Cookie、個人情報、表記の見直し）

法務は“保守”というより、定期的な見直し・更新が必要な領域です。

含まれやすい内容（例）

プライバシーポリシー、個人情報の取り扱い文言の見直し
Cookie同意バナーや計測タグの整理
表記ルール（会社情報、特商法表記が必要な場合など）

見積で確認したいポイント

法的助言そのもの（弁護士判断）が含まれるか
→ 多くの場合は別対応なので、「どこまで支援するか」を明確に。

迷ったらこれだけ確認（初心者向けの要点）

保守の必須4点：契約更新（ドメイン/SSL含む）／監視／バックアップ（復元まで）／脆弱性対応
運用の差が出る3点：更新回数の数え方／軽微改修の定義／レポートの深さ
オプションは目的で選ぶ：集客・採用・ECなど、成果が必要なサイトほど検討価値が上がる

料金プランの型：月額固定／従量課金／チケット制／スポットの違い

保守管理費用は「月額いくら？」だけで比べると失敗しやすいです。
なぜなら、料金の決まり方（＝契約の型）によって “含まれる作業” と “追加料金になりやすい作業” が変わるからです。

ここでは代表的な4タイプを、初心者でも迷わないように整理します。

月額固定が向くケース（更新頻度が安定、窓口一本化したい）

月額固定は、毎月同じ金額で決められた範囲の作業を受けられるタイプです。
保守の「ベース（安心料）」を作るイメージに近いです。

向いているケース

更新が毎月発生する（お知らせ、実績、採用、価格改定など）
担当者が兼務で、社内で回す余裕がない
何かあったときの窓口を一本化したい（誰に連絡すべきか迷いたくない）

メリット

予算が立てやすい（月々の変動が小さい）
監視・バックアップ・更新などを“仕組み化”しやすい
相談先が固定され、トラブル時の初動が早くなりやすい

注意点（ここで差が出る）

「固定」の中身が会社ごとに違う（更新回数、対応時間、軽微改修の範囲など）
月額が安いプランは、緊急対応や復旧作業が別料金になりやすい
“改善（成果アップ）”まで含むと高額になりやすい（保守と運用改善は別物）

見積で確認したい項目

月額内の上限：回数 / 工数（時間） / 両方
障害時：連絡だけか、復旧までか
対応時間：平日昼のみか、時間外は別料金か

従量・時間課金が向くケース（更新が少ない、内容が読めない）

従量・時間課金は「やった分だけ払う」方式です。
作業が不定期・不確定なときに合理的です。

向いているケース

更新が少ない（月0〜1回程度）
今後どれくらい作業が出るか読めない（リニューアル直後、担当交代直後など）
社内で基本は回せるが、技術作業だけ外注したい

メリット

使わない月は支払いを抑えやすい
小さく始めやすい（まずはスポット的に試せる）

注意点

月によって費用がブレる（繁忙月に想定外になりやすい）
障害対応が「調査→復旧→再発防止」で膨らむと高額化しやすい
“最低工数（ミニマムチャージ）”が設定されていることがある

失敗しないコツ

月の上限（上振れ防止ライン）を決める
例：月◯時間を超えたら、月額固定へ切り替え検討
作業ログ（何に何分かかったか）を提出してもらう

チケット制が向くケース（毎月少しずつ改善したい）

チケット制は「月◯時間分」「◯ポイント分」を先に購入し、更新・軽微改修・改善を消化していく方式です。
保守の“運用”と“改善”を、無理なく回すのに向きます。

向いているケース

毎月少しずつ改善したい（導線、フォーム、UI、速度など）
更新＋軽微改修が一定量あるが、毎月の量は少しブレる
“やることが増えすぎる”のを防ぎたい（チケット分だけ進む）

メリット

改善が「やり放題」にならず、優先順位がつけやすい
月額固定より柔軟で、従量より予算管理しやすい

注意点

チケットでできる範囲の定義が重要（新機能開発は対象外になりがち）
有効期限・繰り越し可否で、実質コストが変わる

相性が良い運用例

「月額固定（守る・維持）」＋「チケット（更新・改善）」のハイブリッド
→ 事故に備えつつ、前進も止めない設計にしやすいです。

スポット依頼が向くケース（移管・改修・障害対応だけ頼みたい）

スポットは単発で依頼する方式です。
「今だけ必要」「この作業だけ任せたい」に向いています。

向いているケース

サーバー移管、CMS移行、SSL更新、DNS変更など“単発の技術作業”
既存の保守先があるが、特定分野だけ強い人に頼みたい
まずは相手の品質を見たい（お試し発注）

メリット

必要なときだけ頼める
得意分野の専門家に当てられる

注意点

継続監視がないと「壊れてから気づく」になりやすい
スポット先はサイト背景を知らないため、調査工数が増えやすい
緊急対応は割高になりやすい（時間外・休日・オンコールなど）

“安く見える”見積の注意（最低工数・夜間休日・緊急加算）

見積が安く見えても、次の条件で総額が跳ねることがあります。
初心者ほど、ここを先に押さえると安心です。

注意したい追加費用の典型

最低工数（ミニマムチャージ）
- 例：30分未満でも30分請求、1時間単位で切り上げなど
時間外・深夜・休日の割増（オンコール）
- 「夜間は別料金」「休日は割増」などの条件
緊急対応の範囲外
- 初動だけ月額内で、ログ解析・マルウェア駆除・再発防止は別料金になりやすい
“復旧”が含まれない
- 監視して通知するだけで、復元作業がオプション扱い

見積チェック用のミニ表（これだけ確認）

スクロールできます

チェック項目	確認のしかた
緊急時の対応範囲	連絡のみ／一次切り分けまで／復旧まで、どこまで？
追加料金の条件	夜間・休日・緊急・最低工数の有無は？
作業上限	月◯回／月◯時間／超過時単価は？
“軽微改修”の定義	具体例を契約に書ける？
バックアップ	取得頻度・保持期間・復元は月額内？

結論：おすすめの選び方（迷ったら）

更新が毎月ある → 月額固定
更新が少なく不定期 → 従量（時間課金）
毎月少しずつ改善したい → チケット制
単発の移管・改修だけ → スポット
一番バランスが良い形 → 月額固定（守る）＋チケット（進める）

サイト種別で変わる保守の難易度：WordPress/静的/EC/会員サイト

同じ「保守管理」でも、サイトの作り（仕組み）が違うと、事故の起き方と必要な対策が変わります。
初心者の方はまず、次の3つを押さえると判断がブレにくいです。

変化する部品が多いほど（CMS・プラグイン・外部連携・DBなど）保守は重くなる
止まった時の損失が大きいほど（売上・予約・応募）監視と復旧体制が重要になる
個人情報・決済が絡むほど セキュリティと運用ルールが必須になる

静的サイト：止めない保守は軽いが、更新作業が外注寄りになりやすい

静的サイトは、基本的に HTML/CSS/画像 など「出来上がったファイル」を配信します。
動的な処理（データベース・管理画面・ログイン機能など）が少ないため、一般に“壊れ方”がシンプルです。

保守が軽くなりやすい理由

データベースやプラグインがない（または少ない）ため、脆弱性ポイントが増えにくい
サイト表示は「ファイル配信」が中心で、監視もしやすい
サーバー側の構成がシンプルだと、障害時の切り分けも比較的容易

ただし、費用が出やすいポイント（落とし穴）

静的サイトは「守る」面は軽くても、「更新する」面で外注寄りになりがちです。

文章や画像の差し替えが、管理画面ではなくファイル編集になる
更新のたびに 担当者（制作会社・開発者） が必要になりやすい
Git/ビルド/デプロイなどの運用があると、更新が“作業”として成立するまでに整備が必要

静的サイトが向くケース

名刺代わり・会社案内など、更新頻度が低い
変更は「年に数回」「都度依頼」で十分
“管理画面で誰でも更新”が必須ではない

静的サイトでの見積チェック（初心者向け）

更新依頼は 回数上限 か 時間上限 か
更新手順は誰ができる状態か（社内に引き継げるか）
問い合わせフォーム等がある場合、送信テストやスパム対策が範囲に入るか

WordPress：更新は楽、ただしアップデート起因の不具合に備える

WordPressは管理画面で更新できるため、運用しやすい一方で、保守の難しさは「更新の連鎖」にあります。

WordPress本体
テーマ
プラグイン
PHPなどサーバー側の動作環境

この組み合わせで動くため、更新のタイミング次第で 表示崩れ・エラー・フォーム停止 が起きることがあります。
ここを仕組みで抑えるほど、保守は安定します。

WordPress保守の基本セット（最低限）

バックアップ（ファイル＋DB）と、必要なら復元までの手順
セキュリティ更新の継続（放置しない）
監視（落ちた／遅い／改ざんなどを早期検知）
権限とログイン管理（不要アカウント整理、二段階認証など）

テーマ/プラグインの更新ポリシー（即時 or 検証後）

更新方針は、ざっくり「速さ重視」か「安全重視」かの設計です。
正解はサイトの役割で変わります。

スクロールできます

更新ポリシー	向くサイト	特徴
即時寄り（自動更新も活用）	小規模・停止しても影響が小さい	セキュリティ面は強いが、まれに互換性トラブルが出る
検証後（ステージングで確認して反映）	重要サイト（集客・採用・予約・売上直結）	事故は減るが、検証の手間＝費用が増えやすい

初心者におすすめの考え方はこれです。

「セキュリティに直結する更新」は先延ばししない
「動作が変わりやすい更新」は検証してから反映（特に大きな変更が入るもの）
反映はアクセスの少ない時間帯にまとめ、ロールバック（戻す手順）を用意する

「更新をしない」のが最も危険で、次に危ないのが「更新を勢いで本番に当てる」です。
保守費用の差は、ここをどこまで仕組みにするかで出ます。

ステージング環境の有無で費用が変わる

ステージング環境は、簡単に言うと 本番サイトのコピー（非公開の検証用サイト） です。
これがあると、更新や改修を本番に当てる前に試せます。

ただし、ステージングには“作るだけ”ではなく運用が必要なので、その分コスト要因になります。

本番のコピー作成（ファイル・DB）
テスト項目の実施（表示・フォーム・決済など）
問題があれば修正／戻す
反映手順（差分反映の方法、ダウンタイム対策）

初心者がチェックすべきポイントは次の3つです。

ステージングは 標準で付くのか、オプションなのか
テストは 誰が・どこまでやるのか（“作るだけ”だと意味が薄い）
個人情報があるサイトは、コピー時の データ取り扱い（マスキング等）がどうなるか

EC/会員/予約：外部連携が増えるほど保守は高くなりやすい

EC・会員・予約サイトは、サイトが「表示できる」だけでは足りません。
注文できる／決済できる／予約が入る／メールが届くまでが“正常”です。

さらに、扱う情報が重いです。

決済情報（カード決済・決済代行との連携）
個人情報（会員DB、住所、購入履歴）
在庫・予約枠（整合性が崩れると事故になる）

そのため保守は、監視も復旧も「範囲が広く」なりやすく、費用も上がりがちです。

決済・在庫・会員DB・API連携の監視ポイント

EC/会員/予約で、初心者でも押さえやすい監視・点検ポイントをまとめます。
（全部やる必要はなく、“売上に直撃する順”に優先度を付けるのがコツです）

必須に近い監視・点検

決済が通るか（決済画面〜完了まで）※テスト決済やサンドボックス運用も含む
受注/予約メールが届くか（管理者・顧客向け両方）
在庫や予約枠が正しく減る/埋まるか（連携している場合は同期も）
会員ログイン/パスワード再発行が動くか
バックアップと復元（DBが主役なので、復元の実効性が重要）

トラブルが起きやすい“連携系”

API連携の失敗（外部サービス側の仕様変更・障害）
Webhook/定期処理（Cron等）の停止
プラグイン更新による決済・配送・税計算の不整合

運用設計で差がつくポイント

障害時の連絡だけでなく、復旧までの役割分担（誰が何をするか）
目標復旧時間（RTO）と、許容データ損失（RPO）の考え方
変更履歴（いつ何を変えたか）を残し、原因特定を早くする

EC/会員/予約は、保守＝保険ではなく、売上と信用を守る運用です。
このタイプは「安い月額」より、止まった時にどう復旧するかで選ぶと失敗しにくいです。

「保守管理費用が高い」と感じる原因：料金差が出る5つの理由

同じ「保守管理」と書かれていても、会社ごとに中身が違うため、金額差が出ます。
高い・安いの判断を正しくするには、月額そのものより「何に対して払っているか」を分解して見るのが近道です。

まず全体像として、料金差が出やすいポイントを一行でまとめるとこうです。

範囲（何をするか）
緊急対応の約束（いつ・どこまで）
体制（誰が・何人で）
品質担保の仕組み（事故を減らす装置があるか）
改善が入っているか（保守ではなく“伸ばす”領域）

対応範囲が曖昧（更新・改修・障害の線引きがない）

見積が高く見える最大要因は、「含まれる作業」の境界が曖昧なことです。
ここが曖昧だと、次のどれかが起きます。

安いと思ったら、後から追加費用が積み上がる
高いと思ったら、実は“広く含む”から高かった
比較できない（A社とB社で「保守」の意味が違う）

初心者が混同しやすい3分類

更新：文章・画像・お知らせ追加など「内容の差し替え」
改修：導線変更、フォーム項目追加、レイアウト調整など「作りを変える」
障害対応：表示できない、エラー、改ざん疑いなど「止まった・壊れた」を戻す

同じ作業でも、会社によって扱いが変わります。たとえば…

「フォームの項目追加」
- A社：軽微改修として月額内
- B社：機能追加扱いで別途見積
「WordPress更新で崩れたのを直す」
- A社：障害対応（月額内）
- B社：原因調査までは月額、復旧は別途など

失敗しないための書き方（見積依頼テンプレの考え方）

見積を取る前に、最低限これだけは文章で固定するとブレが減ります。

月額に含む作業（例：監視、バックアップ、セキュリティ更新、月◯回の更新）
別料金になる作業（例：ページ追加、デザイン変更、機能追加、大規模改修）
「軽微改修」の具体例（例：バナー差し替え、導線修正、フォーム文言調整は月額内など）

✅ コツ：口頭ではなく、見積書や契約書に具体例として残すとトラブルが激減します。

緊急対応の前提が違う（受付時間、一次切り分け、復旧目標）

次に大きい差は、緊急時の「約束」です。
同じ月額でも、困ったときの動きが違えば価値が別物になります。

まず用語をやさしく整理

受付時間：いつ連絡できるか（平日昼のみ／24時間365日など）
応答時間：連絡してから返事が来るまでの目安
一次切り分け：原因をざっくり分類し、次の手を決める初動
復旧目標：いつまでに戻すか（目標値として合意することが多い）

なぜここが高くなるのか

緊急対応は、裏側で次が必要になります。

当番（オンコール）や連絡網
手順書（どう直すかが決まっている）
監視・通知・ログの整備（原因を追える状態）
必要に応じて複数人の同時対応

つまり、緊急対応が手厚いほど 人と仕組みのコストが乗ります。

初心者向けの考え方：重要度で要求を変える

全部を24時間対応にすると高額化しやすいので、重要度で分けるのが現実的です。

スクロールできます

重要度	例	合意しておきたいこと
高	サイトが落ちた／決済や予約が止まった	受付、応答、一次切り分け、復旧目標
中	フォームの一部不具合／特定ページだけ崩れ	いつまでに仮復旧するか
低	文章修正／画像差し替え	通常納期でOK

✅ コツ：見積比較では「月額」ではなく、緊急時の“どこまで”が月額内かを並べてください。

体制コストが乗る（専任/複数人、レビュー、セキュリティ手順）

「高い保守」は、作業そのものより体制にお金が乗っていることが多いです。

体制が厚いと何が増える？

窓口担当＋実作業担当（分業）
作業前後のレビュー（ミスを減らす）
変更管理（いつ何を変えたかの記録）
セキュリティ手順（権限、ログ、対応フローが決まっている）

なぜ初心者ほど体制が重要か

担当者が1人だと、次が起こりがちです。

その人が休むと止まる（属人化）
引き継ぎができず、乗り換えが難しくなる
緊急時に判断が遅れる

一方、体制がある会社は、再現性（誰がやっても同じ品質）を作るためにコストがかかります。

見積で確認したいポイント

「担当は1人か、チームか」
「作業のレビューがあるか」
「作業履歴（変更ログ）を共有してくれるか」
「セキュリティ対応の手順が決まっているか」

✅ 目安：売上・信用に直結するサイトほど、体制に払う価値が上がります。

品質担保の仕組み（検証環境、復元テスト、ログ保全）が含まれている

費用差の中でも、見えにくいけど効くのがこの部分です。
ここにお金をかけている会社は、事故が起きにくく、起きても復旧が早い傾向があります。

代表的な「品質を上げる仕組み」

検証環境（ステージング）：本番に当てる前に試す
復元テスト：バックアップから本当に戻せるか確認
ログ保全：原因追跡に必要なログを残し、見られる状態にする
定期点検：権限の棚卸し、不要ページの整理、設定の見直し

なぜ高くなるのか（でも損しにくい）

これらは「何かを作る」より「事故を未然に防ぐ」コストです。
一度でも大きなトラブル（改ざん、長時間停止、フォーム不達）が起きると、月額差を超える損失になることがあります。

初心者向け：成果物で確認する

「やっています」と言われても判断しにくいので、証拠（成果物）をもらうのがおすすめです。

復元テストの実施記録（いつ、どの手順で、結果どうだったか）
月次の作業レポート（何をしたか）
変更ログ（反映内容・日時・担当）

✅ コツ：品質担保は“安心料”ですが、成果物が出る会社は信頼しやすいです。

“改善”が入る（解析→提案→実装）と別カテゴリの費用になる

最後の理由は、そもそも領域が違うパターンです。
「保守」と「改善（成果を伸ばす）」を一緒にすると、費用が高く見えます。

保守と改善の違い（ざっくり）

保守：止めない／壊さない／安全に保つ（守り）
改善：問い合わせ増、CVR改善、SEO強化、速度改善（攻め）

改善が入ると、裏側で次が必要になります。

データを見る（解析・計測の整備）
仮説を立てる（課題の特定）
施策に落とす（優先順位）
実装して検証する（A/Bや効果測定）

つまり、改善は“運用代行”ではなく、コンサル＋制作に近いので別カテゴリになりやすいです。

初心者が失敗しない設計

おすすめは「守る費用」と「伸ばす費用」を分けることです。

ベース：保守（月額固定で最低限の安心を確保）
追加：改善（チケット制／従量／月◯回の提案＋実装など）

✅ コツ：改善に払うなら、成果物を固定すると納得感が出ます。
例）月1回レポート＋月2件の改善提案＋月◯時間の実装など

見積書のチェックリスト：比較で失敗しないために見るべき項目

保守管理の見積は、会社ごとに「保守に含める範囲」が違うため、月額の数字だけで比べると高確率で失敗します。
初心者でもブレずに比較するコツは、見積を “項目分解して横並び” にすることです。

「月額に含む」✅
「別料金（都度見積）」💰
「そもそも対象外」🚫

この3つを項目ごとに明記してもらえば、価格差の理由が見えるようになります。

作業範囲（含む/含まない）を項目ごとに明記してもらう

見積書に「保守一式」とだけ書かれている場合は要注意です。
一式＝比較不能になり、後から追加費用が出やすくなります。

おすすめは、見積の段階で次のフォーマットに落としてもらうことです。

スクロールできます

項目	月額内	別料金	条件（上限・納期など）
テキスト修正	✅		月◯回まで／通常◯営業日
画像差し替え	✅		画像加工は軽微のみ等
フォーム修正		💰	項目追加は別途など
障害対応	✅		平日9-18時、一次対応まで等

「条件（上限・納期）」まで書いてもらうのがポイントです。

更新回数・工数上限・納期・修正回数

更新対応は、見積の“数字の見え方”が会社で変わります。
ここを確認しないと、「思ったより更新できない」「急ぎは全部追加料金」が起きがちです。

確認したいポイント（そのまま質問に使えます）

上限の単位：回数制？工数（時間）制？それとも両方？
“1回”の定義：1ページ？1箇所？1依頼？
例）「3箇所修正＝1回」なのか「3回」なのか
納期の基準：通常対応は何営業日？
急ぎ（当日・翌日）は可能？可能なら追加費用はいくら？
修正回数：確認後の微修正は何回まで含む？
「初回のみ」だと地味にコストが増えます
素材の扱い：文章・画像は誰が用意？
原稿作成や画像制作が含まれるかは要注意（多くは別料金）

小さなコツですが、更新は「回数」よりも「月◯時間まで」のほうが、実務では揉めにくいことが多いです。
（ただし、時間の切り上げ単位＝30分/1時間などは必ず確認してください）

障害対応：一次対応、原因調査、復旧、再発防止の範囲

障害対応は、同じ「対応します」でも中身が全然違います。
初心者がまず理解しておくと良いのは、障害対応は通常この4段階に分かれることです。

一次対応：状況把握、影響範囲確認、緊急度判定
原因調査：ログ確認、変更履歴確認、切り分け
復旧：元に戻す（復元、設定修正、ロールバックなど）
再発防止：原因の恒久対応、手順・監視の改善

見積で必ず明記してもらうべき項目

受付時間：平日だけ？土日祝も？夜間は？
応答の目安：連絡後、何分/何時間以内に返事が来る？
月額内の範囲：一次対応まで？復旧まで？再発防止まで？
復旧目標の考え方：
- どのくらいの時間で復旧させる想定か（目標復旧時間）
- どこまでのデータを戻せればOKか（復旧時点の目標）
対象外の例：外部サービス障害、決済会社側の不具合、仕様変更など

ここは「高い・安い」よりも、ビジネス上どこまで必要かで決めるのが安全です。
たとえばECや予約サイトなら、「連絡だけ」では足りず、復旧までの道筋が必要になります。

バックアップ：頻度、保管場所、保持期間、復元の可否

バックアップは、見積で最も誤解が起きやすい項目です。
なぜなら「バックアップしています」と言っても、“戻せる保証”がないことがあるからです。

見積で確認したいチェック項目

対象：ファイルだけ？データベースも含む？（WordPressや会員サイトはDBが重要）
頻度：毎日／週次／更新時のみなど
保持期間（世代）：何日分残る？（例：7日、14日、30日）
保管場所：同一サーバー内？別ストレージ？別拠点？
※同一サーバーだけだと、障害の種類によっては同時に失うリスクがあります
復元の扱い：復元作業は月額内？別料金？
復元テスト：本当に戻せるかのテストを定期的にするか（実施記録を出せるか）

初心者におすすめの質問

「復元は月額に含まれますか？含まれない場合、1回いくらですか？」
「復元テストは実施しますか？結果は共有されますか？」

バックアップは“安いプランほど薄くなりがち”なので、ここだけは丁寧に確認したほうが失敗しにくいです。

権限・所有の確認（将来の乗り換えで揉めない）

保守で揉めやすいのは、実は料金よりも所有と権限です。
将来の乗り換え（制作会社変更・移管）に備えて、最初にルールを決めておくと安心です。

ドメイン/サーバーの契約名義は誰か

原則として、ドメインとサーバーは自社名義が安全です。
制作会社名義のままだと、乗り換え時に次の問題が起きやすくなります。

移管や名義変更に手間がかかる（場合によっては手続きが進まない）
解約時に「引き渡し条件」で揉める
緊急時の管理画面ログインができず初動が遅れる

確認方法（初心者向け）

契約書・請求書で「契約者」が誰かを見る
可能ならレジストラ/サーバー管理画面で契約者情報を確認
ドメインはWHOIS情報で確認できることもあります（公開制限がある場合は、契約情報の画面提示を依頼）

制作会社が代行している場合は、次を事前に合意しておくと安心です。

名義変更（または権限移管）をいつ・どうやるか
変更に費用がかかるなら、いくらか
退会・解約時の手順と期限

管理画面ID、ソース、各種アカウントの引き渡し条件

「引き渡し」といっても対象が多いので、チェックリスト化が最強です。
最低限、次の“箱”は押さえてください。

引き渡し対象の例（チェック用）

サーバー管理（コントロールパネル、SSH/SFTP、DB）
ドメイン管理（レジストラ、DNS設定）
CMS管理（WordPress等の管理者ID）
メール関連（送受信設定、SPF/DKIM/DMARCなどのDNSレコード）
フォーム（設定画面、通知先、スパム対策設定）
解析（GA4、Search Console、タグ管理）
セキュリティ（WAF/CDN、改ざん検知ツール）
ソース一式（テーマ、プラグイン設定、独自コード、設定ファイル）
デザインデータ（必要なら：バナー元データ等）

引き渡し条件で必ず確認したいこと

いつ渡される？（契約開始時に渡すのか、解約時なのか）
解約時に“追加費用”が発生する条件は？
パスワードの取り扱い（共有方法、2段階認証、担当変更時の運用）

ここまで決めると、E-E-A-T観点でも「運用の透明性」が高まり、読者にも安心感が出ます。

レポートの中身（数字だけか、改善提案までか）

「レポート付き」と書かれていても、中身は大きく4段階あります。
料金差の理由がここに隠れていることが多いです。

スクロールできます

レベル	中身	ありがちな落とし穴
1	数字の共有のみ（PVなど）	見ても次に何をすべきかわからない
2	数字＋簡単な所感	所感が抽象的で行動につながりにくい
3	課題整理＋改善提案	実装が別料金で止まることがある
4	提案＋実装＋効果検証	実質“運用改善”なので費用が上がる

初心者が確認すべきポイント

どの指標を見ているか（問い合わせ・予約・応募など目的に合っているか）
「提案」が含まれるなら、実装はどこまでか
レポート頻度（毎月／四半期）と、打ち合わせの有無

「保守（守る）」と「改善（伸ばす）」を分けると、見積もりの納得度が上がります。

追加費用が出る条件（夜間休日、緊急、外部サービス起因）

最後に、総額が膨らみやすい“地雷ポイント”を潰します。
ここを明記してもらうだけで、予算の事故が激減します。

追加費用が出やすい代表例

最低工数（ミニマムチャージ）：30分未満でも30分請求、1時間単位で切り上げ等
夜間・休日の割増：オンコール費、時間外割増
緊急加算：当日対応、即時対応の加算
外部サービス起因：決済、予約、メール配信、API側の障害・仕様変更
仕様変更・機能追加：軽微改修を超える変更（境界が曖昧だと揉める）

見積に入れてもらうと安心な一文（例）

「時間外対応の単価」
「緊急時の定義（例：当日対応＝緊急）」
「外部サービス障害時の切り分け範囲」
「対象外作業の例」

“安く見える見積”ほど、ここが空欄のことがあるので要注意です。

契約前に決めるべき運用設計：保守を“仕組み化”して費用対効果を上げる

保守管理費用の「高い／安い」は、作業量だけでなく 運用の詰め方（＝ムダの少なさ） で大きく変わります。
契約前に“仕組み”を決めておくと、次の効果が出ます。

依頼の往復が減り、更新が速くなる
障害時の初動が揃い、復旧が早くなる
毎月の「なんとなく保守」を減らし、必要な作業に集中できる

更新依頼の流れ（誰が・何を・いつまでに）

更新が遅れる原因の多くは、技術ではなく「情報不足」と「承認待ち」です。
そこで最初に、更新依頼を“型”にしておきます。

最低限決めるべき4点

依頼者：誰が依頼できるか（窓口を1人にするか、複数にするか）
承認者：公開OKを出す人（誤掲載防止）
締切：いつまでに情報を出せば、いつ公開されるか
連絡手段：メール／チャット／管理ツール（バラけると漏れやすい）

更新依頼テンプレ（これだけ埋めれば作業が進む）

依頼がスムーズになる項目を、テンプレ化して共有しておくのが鉄板です。

スクロールできます

項目	記入例	目的
対象ページURL	https://〜	探す時間をゼロにする
変更内容	旧→新の差分で記載	誤解を防ぐ
素材	画像/PDF/原稿	追加のやりとりを減らす
公開希望日	1/25まで	優先度を揃える
校正回数	1回まで等	追加工数を抑える
影響範囲	フォーム文言変更あり等	テストの必要性判断
参考	参考URL/競合例	意図の共有

“更新”と“改修”の境界を先に引く

費用対効果を上げるには、更新の中に改修が混ざらないようにします。

更新：文言・画像・リンク差し替え、既存ページの追記
改修：フォーム項目追加、導線やレイアウト変更、機能追加

契約前に「月額内の更新」と「都度見積の改修」を例付きで合意しておくと、後から揉めにくいです。

公開前チェックの型（ミスを減らして手戻りを減らす）

公開前に最低限だけ見る“チェック項目”を決めておくと、品質が安定します。

誤字脱字（固有名詞・金額・電話番号）
リンク切れ／PDF差し替え漏れ
スマホ表示崩れ（重要箇所だけ）
フォームが絡む変更なら送信テスト（必要時）

障害時の連絡経路（一次窓口・責任分界・エスカレーション）

障害対応で一番の損失は「誰が動くか分からない時間」です。
契約前に、連絡経路と役割分担を紙一枚に落としておきましょう。

まず決めるのは“一次窓口”と“責任分界”

一次窓口：最初に連絡を受けて状況整理する人（社内or外注）
責任分界：どこから先は誰の担当か（サーバー／CMS／外部サービス等）

例として、よくある分け方はこんな形です。

サーバー障害：ホスティング会社（＋保守会社が切り分け）
WordPress不具合：保守会社（テーマ・プラグイン含む範囲を合意）
外部連携（決済/予約/メール配信）：原因切り分けまでは保守、相手側の復旧は先方…など

影響度で動きを変える（障害レベルの簡易ルール）

“全部緊急”にするとコストも疲弊も増えます。
レベルを決めておくと、判断が速くなります。

スクロールできます

レベル	状態の例	初動の目安	よく決める項目
重大	サイトが落ちた／決済・予約が止まった	即時	受付時間・応答目安・復旧の範囲
中	特定ページだけエラー／フォーム不達の疑い	早め	一次切り分けまで月額内か
軽微	表示崩れ／一部文言の誤り	通常	通常納期で対応

エスカレーション（上に上げる条件）を明文化する

エスカレーションは「誰が偉いか」ではなく「早く直す仕組み」です。

一次窓口で切り分けできない
影響が広がっている（予約/問い合わせが止まっている等）
セキュリティ事故の疑い（改ざん・不正ログイン等）
外部サービスが絡み、調整が必要

この条件が決まっているだけで、無駄な様子見が減ります。

記録を残す（“責めない記録”が再発を減らす）

障害後に残すのは、犯人探しではなく「次回もっと早く直すための情報」です。

いつ起きたか／何が影響したか
何をしたら直ったか（暫定と恒久）
次回の改善（監視追加、手順書更新、権限整理など）

この“振り返り”がある保守は、回すほど強くなります。

定例の有無（毎月／四半期）と見直し項目

定例は「会議を増やすため」ではなく、事故とムダを減らすためにやります。
サイトの目的に合わせて頻度を選ぶのがポイントです。

定例を入れた方が良いケース

更新が継続的に発生する（採用・集客・ECなど）
外部連携が多い（予約、決済、CRM、MA）
改善（解析→提案→実装）も回したい

逆に、名刺代わりで更新が年数回なら、定例なし＋半期レビューでも十分なことが多いです。

毎月の定例で見ると効果が出やすい項目

“見るだけ”にならないよう、意思決定につながる項目に絞ります。

今月の作業実績（更新・障害・軽微改修の一覧）
未完了のチケット／保留理由（素材待ち、承認待ち等）
セキュリティ関連（更新状況、注意喚起が必要な点）
バックアップ状況（異常の有無、必要なら復元テスト結果）
次月の予定（キャンペーン、採用、価格改定など）

四半期（または半年）で見直すと“コスパが上がる”項目

契約範囲の見直し（やっていない作業に払っていないか）
更新の型の改善（テンプレ不足、承認フローのボトルネック）
監視やアラートの調整（うるさすぎる／足りない）
権限棚卸し（不要アカウント削除、担当変更への追随）
外部サービスの整理（使っていないタグやツールの削除）

定例を有効にするコツ

事前にアジェンダ固定（毎回ゼロから考えない）
“次のアクション”を3つまでに絞る（やりっぱなし防止）
決めたことを1枚にまとめる（誰が、いつまでに）

費用を下げつつ品質を落とさない方法：削っていい所・ダメな所

保守管理費用を下げたいときにやりがちなのが、「とりあえず安いプランにする」「全部内製に寄せる」です。
でも、削る場所を間違えると“事故の損失”で結局高くつくことがあります。

ここでは、初心者でも判断しやすいように

削ってはいけない領域（守りの土台）
削りやすい領域（設計で調整できる）
内製化の現実ライン（最低限の体制）
相見積もりの揃え方（比較ミスを防ぐ）

を順番に整理します。

削ってはいけない：SSL・更新・バックアップ・セキュリティ監視

結論から言うと、ここは“コスト削減の優先順位が低い”です。
理由はシンプルで、止まる・漏れる・改ざんされると影響が大きいからです。

SSL（HTTPS）の運用

SSL/TLS証明書は無料で運用できるケースもありますが、「期限管理」「自動更新」「更新失敗時の復旧」ができていないと事故ります。
HTTPSが切れると、閲覧者の警告表示・フォーム離脱など、信頼面にも直撃します。

✅ コツ：証明書そのものの費用より、失効させない運用にお金を残す

更新（特にセキュリティ系アップデート）

WordPress等は、更新を放置すると攻撃対象になりやすいです。
逆に、更新を雑にやると表示崩れや機能停止が起きるので、方針（即時／検証後）が必要です。

✅ コツ：削るなら「更新作業」ではなく、後述の「更新回数設計」を見直す

バックアップ（復元まで）

“バックアップ取得”だけだと安心できません。重要なのは復元できることです。
さらに、保管場所が同一サーバーだけだと、障害の種類によっては同時に失う可能性があります。

✅ コツ：最低でも「頻度・保持期間・復元対応の可否」を固定で確保する

セキュリティ監視（改ざん・不正アクセス検知）

被害が拡大するのは「気づけない」時です。
小規模サイトでも、改ざんで第三者に迷惑をかけるリスクがあります（信用ダメージが大きい）。

✅ コツ：監視は“高機能”より、“気づける仕組み＋初動手順”が大事

削りやすい：レポート頻度、改善提案の深さ、更新回数の設計

品質を落とさずに削れるのは、主に「攻め」か「運用のムダ」です。
言い換えると、事故を防ぐ土台は残し、前進のペースを調整するのが安全です。

レポート頻度は落としても品質は落ちにくい

毎月レポートが必要なサイトもありますが、名刺代わりサイトや更新が少ないサイトは、四半期ごとでも十分なことが多いです。
“数字だけのレポート”なら、頻度を下げても実害が少ないです。

例：削り方の案

毎月 → 四半期
60分の定例 → 30分の定例＋議事メモだけ

改善提案は「深さ」を調整する

改善（解析→提案→実装）は、保守とは別カテゴリになりやすく、費用が上がります。
ただ、ゼロにするのではなく、ライトに残すとコスパが良いです。

おすすめの落としどころ

月1：提案3つ（優先順位付き）だけ
実装はチケット制（必要な月だけ）

更新回数は「依頼の設計」で減らせる

意外と効くのがここです。更新の依頼がバラバラだと、回数課金・工数課金が膨らみます。

効く工夫（品質を落とさず削れる）

更新を週1回にまとめる（緊急以外）
依頼テンプレ化（差分・素材・公開希望日を固定）
“軽微更新は内製、技術更新は外注”の役割分担

内製化の現実ライン（自社で回すなら最低限必要な体制）

内製化は「できる／できない」ではなく、回り続ける仕組みがあるかが重要です。
最低限、これが揃わないなら、全部内製は危険です。

内製で最低限必要なもの（チェックリスト）

担当者（主担当＋代替要員）
管理情報の保管場所（ID・2FA・復旧手順の置き場）
期限管理（ドメイン/SSL/サーバー）
バックアップ運用（頻度・保持・復元手順）
更新ルール（いつ更新し、更新後に何を確認するか）
障害時の連絡経路（誰に・どこまで・いつ連絡するか）

現実的なおすすめ配分（初心者向け）

内製：軽い更新（文言・画像差し替え、お知らせ）
外注：監視、バックアップ設計、セキュリティ更新、障害対応の一次切り分け

この形だと、月額を抑えながら「事故る領域」を外に出せます。

内製化で“詰みやすい”パターン

担当が1人で属人化（休むと止まる）
復元テストをしていない（戻せない）
何を変えたか記録がない（原因追跡ができない）

相見積もりで比較するコツ（同条件テンプレで揃える）

相見積もりで失敗する最大原因は、各社が違う前提で見積もることです。
そこで、先に「同条件テンプレ」を渡して揃えます。

見積テンプレに入れるべき項目（そのままコピペで使えます）

サイト概要：URL、サイト種別（静的/WordPress/EC/会員/予約）
規模：ページ数、月間更新回数の目安、フォーム有無
重要度：止まった時の影響（問い合わせ/予約/売上）
希望する必須範囲（例）
- 監視：死活監視＋改ざん検知（通知方法も）
- バックアップ：頻度・保持期間・復元可否
- 更新：月◯回 or 月◯時間、通常納期
- セキュリティ更新：対象（本体/テーマ/プラグイン）、更新方針（即時/検証後）
- 障害対応：一次対応/原因調査/復旧/再発防止のどこまでが月額内か
追加費用条件：夜間休日、緊急、外部サービス起因、最低工数（切り上げ単位）

“安く見える見積”をはじく質問（超重要）

「復元は月額に含まれますか？別なら1回いくらですか？」
「障害対応はどこまで月額内ですか？（一次対応だけ？復旧まで？）」
「時間外・緊急の定義と単価は？」
「更新の“1回”の数え方は？」

この質問に明確に答えられる会社ほど、後々のトラブルが少ない傾向があります。

まとめ：削る順番を間違えない

まず守る：SSL運用、セキュリティ更新、バックアップ（復元含む）、監視
次に整える：更新の依頼設計、レポート頻度、改善提案の深さ
内製は「担当・手順・代替」が揃ってから。無理ならハイブリッドが安全
相見積もりは、同条件テンプレで“比較可能な見積”にする

保守を怠ると何が起きる？ “費用より高い損失”の具体例

保守管理は「毎月の固定費」に見えますが、実際は トラブルの損失（売上・信用・復旧コスト）を抑える保険 に近い役割です。
ここでは、初心者でもイメージしやすいように「よくある事故」を具体例で整理します。

表示停止・証明書切れ・更新忘れで機会損失が出る

ホームページは、止まった瞬間に 問い合わせ・予約・応募が“ゼロ” になり得ます。しかも、止まっていることに気づくのが遅れるほど損失が膨らみます。

よくある例

サーバー障害・容量不足でサイトが表示されない
→ 「アクセスできない＝不安」になり、他社に流れやすい
SSL（HTTPS）証明書の期限切れ
→ ブラウザで警告が出て、フォーム送信を避けられやすい
CMS・プラグイン更新の放置
→ ある日突然ログイン不能／表示崩れ／不正侵入の入口になる

ポイントは、損失が「売上」だけでなく 対応に追われる人件費・機会損失 として跳ね返る点です。
「誰がいつ気づき、どこに連絡し、どう復旧するか」まで決めてあるかで被害が変わります。

セキュリティ事故（改ざん・情報漏えい・信用毀損）

保守を怠ると起きやすいのが、改ざん・不正侵入・マルウェア配布などのセキュリティ事故です。
サイトが“攻撃の踏み台”にされると、自社だけでなく 訪問者・取引先 にまで影響が及びます。

よくある例

不正ログイン → 見えない場所にスパムページ大量生成
→ 検索結果に怪しいページが出る／復旧後も評価回復に時間がかかることがある
改ざん → 別サイトへ誘導
→ 訪問者が詐欺サイトに飛ばされ、問い合わせが途絶える
フォーム経由の情報が漏えい（設定不備・脆弱性・不正アクセス等）
→ 調査・告知・再発防止など、対応が長期化しやすい

セキュリティは「完璧に防ぐ」よりも、更新・監視・初動（隔離/停止/復元）の体制で被害を小さくする発想が現実的です。

表示崩れ・速度低下で問い合わせが減る

サイトが“見えている”状態でも、保守不足で成果が落ちるパターンがあります。
代表が 表示崩れ と 速度低下 です。

よくある例

スマホでボタンが押せない／文字が重なる
→ 離脱が増える（「読めない」「使いにくい」で終了）
画像が重い／不要なスクリプトが増えて遅い
→ 体感ストレスで離脱、フォーム到達率が下がる
外部サービス（予約・地図・埋め込み）の仕様変更で不具合
→ 気づかないまま“機能していないフォーム”が放置されることも

「毎月の改善」をしなくても、最低限 崩れていないか・遅くなっていないか の点検だけで成果を守りやすくなります。

検索評価の低下（古い情報・品質低下・技術的問題）

保守を怠ると、検索からの流入が落ちる要因が積み上がります。
とくに影響が出やすいのは次の3つです。

古い情報の放置：料金・営業時間・制度・仕様が古いまま
→ ユーザー満足が下がり、指名・問い合わせにも悪影響
品質低下：リンク切れ、画像崩れ、404増加、重複ページの増殖
→ “読みにくいサイト”になりやすい
技術的問題：表示速度・モバイル体験・セキュリティ警告
→ UXが悪化し、結果的に成果が落ちやすい

SEOは「記事を書く」だけでなく、維持管理で“サイトの信頼性”を落とさないことが土台になります。

法改正・規約変更への未対応でリスクが増える

ここは見落とされがちですが、保守不足のリスクは「技術」だけではありません。
個人情報・計測タグ・外部送信（Cookie等）・利用規約など、ルールの変化に追随できないと事故になり得ます。

よくある例

プライバシーポリシーが実態と合っていない
（収集情報・利用目的・問い合わせ窓口・第三者提供等が曖昧）
アクセス解析や広告タグの“外部送信”説明が不足
→ 表示・通知の要否、説明内容の不足がリスクに
外部サービスの規約変更（解析・広告・フォーム等）を放置
→ 設定の見直しが必要でも気づかない

※法令対応はケースで変わるため、重要なサイト（EC・会員・予約・採用）は、必要に応じて専門家へ確認するのが安全です。

保守会社の変更・解約ガイド：乗り換えで失敗しない手順

保守会社の変更（乗り換え）は、やり方を間違えると サイト停止・メール不達・権限トラブル が起きやすい作業です。
逆に言えば、契約前に「引き継ぎの型」を作っておけば、スムーズに安全に移管できます。

ここでは、初心者でも迷わないように 必要な引き継ぎ物→起きやすい事故→安さだけで選ぶ注意点 の順でまとめます。

引き継ぎに必要なもの（アカウント、構成図、手順書、バックアップ）

引き継ぎで重要なのは、「ログイン情報を渡す」だけではなく “復旧できる状態”を渡す ことです。
最低限、次の4セットは揃えておくと失敗しにくいです。

1) アカウント一式（名義・権限まで確認）

名義が自社か、管理者権限が自社にあるかが最優先です。

ドメイン管理（レジストラ）
- ログインID/パスワード
- Admin/Registrantのメール受信ができる状態
- 認証コード（AuthCode）取得方法、移管ロック解除方法
- 有効期限（失効間近だと移管できない場合あり）
- WHOIS情報（公開/代理公開含む）
DNS管理（ネームサーバーの管理場所）
- どこでDNSを管理しているか（レジストラ／サーバー会社／CDNなど）
- 現在のDNSレコード一覧（A/CNAME/TXT/MX など）
サーバー（ホスティング）
- 管理画面（コントロールパネル）
- SSH/SFTP、DB、WAF、バックアップ機能の権限
- SSLの設定場所（サーバー側／CDN側）
CMS（WordPress等）
- 管理者ID（複数）／2段階認証の設定
- テーマ・プラグインの一覧と更新方針
メール（使っている場合）
- MX/SPF/DKIM/DMARC 等のDNSレコード
- 送受信サーバー設定、転送設定、問い合わせフォーム通知先
解析・計測
- GA4（アクセス管理の権限）
- Search Console（所有権または権限）
- タグ管理（GTM）、ヒートマップ等

✅ コツ：移管前に、新保守会社を「閲覧→編集→管理者」の順に権限付与して、ログイン確認までやっておくと安心です。

2) 構成図（「どこで何を管理しているか」を1枚で）

引き継ぎで一番怖いのは、「どこに設定があるか分からない」状態です。
凝った図は不要なので、次の要素だけでOKです。

ドメイン（レジストラ名）
DNS（どこで編集するか）
サーバー（ホスティング名、契約プラン）
CMS/アプリ（WordPress、EC、予約、会員など）
外部連携（フォーム、決済、予約、地図、SNS埋め込み、CDN/WAF）
メール（どこで運用しているか）

3) 手順書（“事故ったとき”に必要な最低限だけ）

ドキュメントは分厚くするより、緊急時に使えることが重要です。

バックアップからの復元手順（誰が・どこで・何を戻すか）
SSL更新/更新失敗時の対処
WordPress更新手順（検証→本番反映→確認項目）
障害時の連絡経路（一次窓口、エスカレーション先）

4) バックアップ（「取得」だけでなく「戻せる」状態）

引き継ぎ時に必ずやりたいのが 移管直前のフルバックアップ と 復元テスト です。

サイトファイル（画像・テーマ・アップロード等）
データベース（会員/予約/注文があるなら特に重要）
設定ファイル（.htaccess、リダイレクト、環境設定）
DNSレコードの控え
（可能なら）ステージング環境 or ローカル復元検証

移管時に起きやすいトラブルと回避策

移管トラブルはだいたい「権限」「DNS」「メール」「手順不足」に集中します。代表例と回避策をセットで整理します。

ドメイン・DNS系

認証メールが受け取れない（Adminメールが古い／制作会社のアドレス）
→ 移管前にメールアドレスを現行の自社受信に変更しておく
AuthCodeが取れない／移管ロックが解除できない
→ 手続き手順を事前に確認し、移管申請前に取得・解除まで実施
ドメイン期限が近くて移管できない
→ 先に更新して有効期限に余裕を作る
DNS切替で一時的に表示が不安定
→ 切替の24〜48時間前にTTLを短縮し、切替後は反映時間を見込む（数時間〜最大1日程度が目安のケースあり）

サーバー移転・SSL系

切替後にSSL警告が出る
→ SSLの管理場所を特定（サーバー/CDN）し、切替前に証明書を準備
旧サーバーを早く解約してしまい、戻せなくなる
→ 並走期間（例：2〜4週間）を設け、動作確認完了まで解約しない

メール・フォーム系

フォーム通知が届かない（MXやSPF/DKIMの不整合）
→ DNS切替前後で「フォーム送信→到達」をチェック。SPF/DKIM/DMARCも控えを残す
問い合わせ窓口が制作会社のメールのまま
→ 受信先を自社管理に変更し、旧アドレスは転送でしばらく残す

計測・SEO系（意外と忘れがち）

GA4/タグが引き継がれず、数字が空白になる
→ 事前にアクセス管理で権限付与し、計測タグの設置場所も確認
Search Consoleの所有権が引き継がれず、エラー通知が来ない
→ 新担当がプロパティにアクセスできるよう、所有権確認（または権限付与）を先に実施

連絡が取れない・情報がない（最難関）

制作会社と連絡が取れず、アカウント不明
→ まず「ドメイン管理がどこか」を特定し、所有者としての立証も含めて手続きを進める（時間がかかりやすいので早めに着手）

“月額だけ安い”移管の注意（引き継ぎ/復旧体制が薄い）

乗り換え先を「月額の安さ」だけで選ぶと、移管後に次の落とし穴にハマりがちです。

よくある落とし穴

引き継ぎ作業が別料金で、結局高くつく
監視はするが、復旧は別料金 or 対応が遅い
バックアップはあるが、復元は対象外
“更新は月◯回”でも、定義が曖昧で使いにくい
障害時の一次切り分けがなく、たらい回しになる

安いプランでも最低限確認すべき「4つの約束」

復元：バックアップからの復元は月額内か／1回いくらか
障害対応範囲：一次対応・原因調査・復旧のどこまでが月額内か
引き継ぎ成果物：アカウント一覧、DNS控え、手順書の提出があるか
権限の原則：ドメイン/サーバー/計測は自社名義・自社管理者が原則か

✅ おすすめ：乗り換えでは「移管費用（初期）」と「保守費用（月額）」を分けて考え、移管後に“復旧できる状態”が残るかをゴールに置くと判断がブレません。

よくある質問（FAQ）：相場・契約・作業範囲のモヤモヤを解消

保守管理費用は月額いくらが妥当？

「妥当な月額」は、サイト規模よりも 保守の範囲（何をやるか）×体制（いつ対応するか）×サイト種別（止まった時の損失） で決まります。

目安としては、よくある相場感は次のイメージです。

スクロールできます

ざっくり区分	月額の目安	だいたい含まれやすい内容
最低限（止めない中心）	5,000〜20,000円前後	監視、バックアップ、軽い更新、相談窓口など
標準〜しっかり（更新＋軽微改修まで）	1〜5万円前後	更新回数多め、軽微改修、セキュリティ運用が厚め
高め（EC/会員/複数サイト/高い緊急性）	5万円〜	外部連携監視、検証環境、復元テスト、緊急対応が厚い等

判断のコツは「月額いくらが正解か」ではなく、次の3点を先に決めることです。

必須：監視／バックアップ（復元含む）／セキュリティ更新
必要なら：更新回数（または時間）／軽微改修／レポート
重要サイトなら：緊急時の範囲（一次対応〜復旧まで）と受付時間

更新がほぼ無いサイトでも月額は必要？

更新が少なくても、“何もしない＝ゼロ円”にはなりにくいです。理由は、更新が無くても「期限」「障害」「攻撃」は発生するからです。

最低限かかるもの：サーバー／ドメイン／SSLの更新管理
起きると困るもの：表示停止、メール不達、フォーム不具合、改ざんなど

ただし、サイトの状況次第では「月額保守」を小さくできる（または月額なしでも回せる）ケースはあります。

月額を小さくしやすいケース

静的で機能が少ない（フォームも外部サービスで完結など）
社内に“担当と代替”がいて、期限管理とバックアップを回せる
障害時の連絡先・復旧手順が決まっている

月額を残した方が安全なケース

WordPress、予約、会員、ECなど「更新や連携がある」
担当が1人で属人化しそう（休むと止まる）
問い合わせ・採用・売上に直結していて、止まると痛い

迷うなら、月額の中身を「守り（監視・バックアップ・更新）」に寄せ、レポートや改善提案は薄くするのがバランス良いです。

WordPressの更新は自分でやっても大丈夫？

小規模サイトなら「自分でやる」ことは可能です。ただし、“更新すること”より“戻せること” が重要です。更新で不具合が出た時に戻せないと、結果的に高くつきます。

自分で更新しやすい条件

重要機能が少ない（EC/会員/予約がない）
プラグインが少なく、構成がシンプル
バックアップと復元手順があり、手元で確認できる

自分でやるなら最低限の手順（テンプレ）

更新前にバックアップ（ファイル＋DB）
更新対象の確認（本体／テーマ／プラグイン）
可能なら検証環境でテスト（なければ低アクセス時間帯に実施）
更新後チェック（表示、フォーム送信、主要導線、ログイン）
問題があれば「戻す」（復元 or ロールバック）

注意ポイント

自動更新は便利ですが、サイトによっては更新直後に崩れることがあります
「更新を止める」のはセキュリティ面でリスクが上がるため、止めるより“安全に回す仕組み”が現実的です

「更新は内製、障害対応だけ外注」など、ハイブリッドにすると費用も抑えやすいです。

緊急対応はどこまで含めるべき？

緊急対応は、サイトの役割で必要範囲が変わります。おすすめは「3段階」で決める方法です。

スクロールできます

レベル	向いているサイト	含めたい範囲の目安
最低限	名刺代わり・停止しても致命傷ではない	監視＋連絡＋一次切り分け（原因の当たりを付ける）
標準	問い合わせ・採用に直結	一次切り分け＋復旧（復元含む）まで
厚め	EC/予約/会員など売上直結	受付時間の拡張＋復旧目標の合意＋再発防止（恒久対応）まで

ここでいう「緊急対応」は、だいたい次の4つに分かれます。

一次対応（状況把握・影響確認）
原因調査（ログ確認・切り分け）
復旧（復元・設定修正）
再発防止（監視追加・手順改善）

見積比較では「緊急対応込み」と書かれていても、どこまでが月額内かを必ず線引きしてもらうのが安全です。

見積が高い/安いの判断基準は？

月額の大小ではなく、次の“差が出るところ”で判断すると失敗しにくいです。

1) 作業範囲が明文化されているか

更新回数（または時間）／納期／修正回数
軽微改修の定義（例があるか）
バックアップの頻度・保持期間・復元対応

「保守一式」は比較不能なので、項目ごとに 含む／別料金／対象外 を出してもらうのが基本です。

2) 障害時の前提が一致しているか

受付時間、応答目安
一次対応だけか、復旧までか
夜間休日・緊急加算の条件

安い見積で多いのは「監視はするが、復旧は別料金（または範囲外）」のパターンです。

3) 品質担保の仕組みが入っているか

検証環境の有無
復元テスト（実施記録があるか）
変更ログや作業レポートが残るか

ここが厚いほど高くなりやすいですが、事故が減りやすく、長期的にコスパが良くなることもあります。

4) 権限・所有が整理されているか

ドメイン／サーバー名義
管理画面IDの引き渡し条件
解約時の移管サポート範囲

この部分が曖昧だと、乗り換え時に想定外のコストやトラブルになりやすいです。

まとめ：あなたに最適な保守管理費用は「必要な範囲」を言語化すると決まる

保守管理費用で迷う最大の理由は、「月額◯円」という数字だけを先に見てしまい、中身（範囲・体制・前提）が比較できていないことです。
逆に言えば、必要な範囲を言語化できれば、見積はブレなくなり、過不足も減ります。

3ステップ：①目的整理 → ②必須項目確定 → ③契約形態を選ぶ

① 目的整理（“止めない”のか、“伸ばす”のか）

まず「このサイトで失いたくないもの」を決めます。ここが曖昧だと、保守が肥大化（高額化）しやすいです。

サイトの役割：名刺／集客／採用／予約／EC・会員
止まったときの損失：問い合わせが止まる／予約が崩れる／売上が止まる
守る対象：個人情報・会員DB・決済などがあるか
社内の現実：担当者は何人いるか、代替はいるか、緊急連絡は受けられるか

決めるゴール（例）

「平日昼に落ちていたら当日中に復旧したい」
「フォーム不達だけは絶対に避けたい」
「セキュリティ更新は止めないが、更新で壊れるのも避けたい」

② 必須項目確定（削ってはいけない土台を固定）

次に、見積の比較軸になる“最低ライン”を固定します。ここが揃うだけで、相見積もりが一気に見やすくなります。

多くのサイトで“必須に近い”

監視（落ちた/異常の早期検知と通知）
バックアップ（頻度・保持期間・復元可否まで）
セキュリティ更新（CMS/テーマ/プラグイン等の方針）
SSL/ドメイン/サーバーの期限管理（失効させない運用）
障害時の一次対応（状況整理、原因切り分けの入口）
権限・所有（ドメイン/サーバー名義、管理者IDの引き渡し）

サイトが重いほど追加で“必須寄り”

検証環境（ステージング）と更新後テスト
復元テスト（「戻せる」証拠）
外部連携の監視（決済/予約/API/メール到達）

③ 契約形態を選ぶ（ムダなく回る形にする）

最後に、目的と社内体制に合う「料金の型」を選びます。

スクロールできます

状況	合いやすい契約形態	考え方
更新が毎月ある／窓口を一本化したい	月額固定	予算を安定させて“守り”を仕組み化
更新が少ない／作業量が読めない	従量・時間課金	使った分だけ。ただし上振れ対策（上限）を
毎月少しずつ改善したい	チケット制	優先順位を付けて前進。期限・繰り越しは要確認
単発の移管や改修だけ頼みたい	スポット	“今だけ”に向く。継続監視は別途検討

現実的に一番バランスが取りやすいのは、「月額固定で守り」＋「チケット/従量で更新・改善」の二段構えです。

すぐ使えるチェックリスト（見積依頼テンプレ）

下をそのままコピペして、相見積もりを“同条件”で揃えるのに使ってください。
ポイントは、各項目を 「月額内／別料金／対象外」で必ず回答してもらうことです。

見積依頼テンプレ（コピペ用）

サイトURL：
サイト種別：静的 / WordPress / EC / 会員 / 予約（該当を残す）
規模：ページ数（約　）／月間更新回数（約　）／フォーム有無（有・無）
重要度：問い合わせ・採用・予約・売上への影響（高・中・低）
現状の課題：例）更新が滞る／担当が1人／障害時の連絡先が不明／速度が気になるなど

1) 作業範囲（含む/含まない）※必須回答

A. 監視

[ ] 死活監視（落ちたら通知）：月額内／別料金／対象外
[ ] 改ざん検知（必要なら）：月額内／別料金／対象外
通知方法：メール / チャット / 電話（該当を残す）
監視対象：サイト表示 / フォーム / 決済・予約 / API（該当を残す）

B. バックアップ

[ ] 取得対象：ファイル＋DB / ファイルのみ（該当を残す）
頻度：毎日 / 週次 / 更新時 / その他（　）
保持期間（世代）：（　）日分
保管場所：同一サーバー / 別ストレージ / 別拠点（該当を残す）
復元対応：月額内／別料金（1回　円〜）／対象外
復元テスト：実施有無、頻度、結果共有の有無

C. セキュリティ更新・運用

[ ] CMS本体更新：月額内／別料金／対象外
[ ] テーマ更新：月額内／別料金／対象外
[ ] プラグイン更新：月額内／別料金／対象外
更新方針：即時 / 検証後（該当を残す）
[ ] ログイン対策（2FA等）：月額内／別料金／対象外

D. 更新・軽微改修

更新の上限：月（　）回 or 月（　）時間
切り上げ単位：15分 / 30分 / 1時間（該当を残す）
通常納期：（　）営業日
修正回数：（　）回まで
「軽微改修」の定義：例）バナー差し替え、導線修正、フォーム文言変更…（具体例を記載希望）

E. 障害対応（必ず4段階で回答）

一次対応（状況把握・影響確認）：月額内／別料金／対象外
原因調査（ログ確認・切り分け）：月額内／別料金／対象外
復旧（復元・設定修正）：月額内／別料金／対象外
再発防止（監視追加・恒久対応）：月額内／別料金／対象外
受付時間：平日（　）時〜（　）時／土日祝（可・不可）
緊急加算：夜間休日・即日対応の条件と単価

2) 権限・所有（乗り換え前提で明文化）

ドメイン契約名義：自社 / 代行（該当を残す）
サーバー契約名義：自社 / 代行（該当を残す）
管理情報の引き渡し：契約開始時 / 解約時 / 随時（該当を残す）
引き渡し対象（必須）：
- [ ] レジストラ（ドメイン）
- [ ] DNS設定一覧（TXT/MX含む）
- [ ] サーバー管理画面
- [ ] CMS管理者ID
- [ ] バックアップ一式
- [ ] GA4 / Search Console 権限
WHOIS情報の確認方法（必要時）：開示範囲と手続き