ホームページ制作の見積もりで「保守」「管理」「運用」「更新」という言葉が並んでいても、含まれる作業は会社や仕組みによって異なります。金額だけでなく、何を守り、問題が起きたらどこまで戻し、誰が判断するかを確認することが大切です。

まず、保守はサイトを安全・安定した状態に保つための確認や復旧準備、更新は営業時間や写真などの内容を変える作業、改善は伝わり方や導線を見直す作業、と分けて考えると整理しやすくなります。実際の契約では名称ではなく作業内容を確かめます。

保守・更新・改善は、目的が違う

区分主な目的確認したい例
保守止まりにくく、戻せる状態を保つバックアップ、復旧、脆弱性、ドメイン・SSL、権限
更新掲載内容を現在の事業に合わせる営業時間、サービス、写真、採用条件、お知らせ
改善読者が理解・行動しやすくする説明の順番、検索意図、問い合わせ導線、表示速度

たとえば「月2回更新」が含まれていても、セキュリティ確認や復旧作業まで含まれるとは限りません。反対に、保守契約があっても、原稿作成や新しいページの追加は別になる場合があります。

最初に、サイトの仕組みを確認する

必要な保守は、WordPressなどのCMS、静的なHTML、予約・決済を含むWebサービスで変わります。難しい名称を覚えるより、次の質問に答えられる状態にします。

  • ページを表示しているサーバーやサービスは何か
  • 自社でログインして更新する管理画面があるか
  • フォーム、予約、決済、外部SNSなど何とつながっているか
  • ドメインの契約者と更新方法は誰が管理しているか
  • 元のHTML、CSS、画像、原稿などをどこに保管しているか

CMSでは本体や追加機能の更新が必要になる一方、静的サイトでもドメイン、SSL、ホスティング、外部フォーム、バックアップは無関係ではありません。「WordPressではないから保守不要」とも、「毎月同じ作業が必ず必要」とも一律には言えません。

契約前に確認したい7項目

  1. ドメインとSSL:契約名義、更新日、期限切れ時の連絡先は誰か。
  2. サーバー・公開環境:障害時に誰が状況を確認し、どこへ問い合わせるか。
  3. ソフトウェア:更新対象、確認頻度、更新前後のテスト範囲はどこまでか。
  4. バックアップ:何を、いつ、どこに保存し、実際に戻せるか。
  5. 権限:退職者や外部担当者のアカウントを誰が見直すか。
  6. 内容修正:文字・写真・ページ追加の回数や範囲、別費用になる条件は何か。
  7. 緊急時:改ざん、表示停止、フォーム不達の連絡方法と初動はどうするか。

「バックアップあり」だけでは、データベースを含むのか、画像や原稿を含むのか、何日前へ戻せるのかが分かりません。復元する手順と担当まで確認して、初めて役割が見えます。

保守範囲を決める判断軸

会社情報が中心で、更新が少ないサイト

少なくとも、ドメイン・SSL・公開環境の管理、バックアップと復元元、連絡先を確認します。更新頻度が低くても、担当者や契約情報が分からなくなるリスクは残ります。

管理画面から頻繁に更新するサイト

ソフトウェア更新、権限、テスト、バックアップの手順がより重要です。更新したあとに表示やフォームが動くかを、どの範囲で確かめるかも決めます。

予約・問い合わせ・採用応募を受けるサイト

フォームが表示されるだけでなく、通知先、入力内容の扱い、送信失敗時の案内、個人情報を必要以上に保存しない設計を確認します。実際の予約や応募をテストする場合は、送信先への事前共有も必要です。

写真や求人条件がよく変わるサイト

技術的な保守とは別に、誰が変更内容を集め、誰が公開を確認するかを決めます。詳しくは更新担当と引き継ぎの整理で確認できます。

ドメイン・サイト・メールは、管理先を分けて確かめる

制作会社を変えたり、公開環境を移したりするとき、ホームページのデータだけを受け取っても準備が終わるとは限りません。サイトで使う名前、ページの置き場所、会社のメールを、別の役割として確認します。同じ会社にまとめて契約している場合も、何を残し、何を変えるかを分けて書きます。

担当変更の前に使う、管理先の確認表
役割確認すること
ドメインの契約契約者、更新期限、更新通知を受ける担当、契約を確かめる資料の場所。推測で名義を埋めない。
行き先の設定(DNS)誰が管理し、誰が変更できるか。Web・メール・外部サービスの設定を、担当者が照合できるか。
サイトの公開環境現在の公開サービスと契約、受け取れるデータ、復元手順、フォーム等の外部機能。
会社のメール利用サービス、残すアドレス、送受信・過去メール・転送の扱い、確認担当。Web公開だけで完了にしない。

DNSは、ドメイン名に対してWebやメールなどの行き先を案内する設定です。メールを届けるためのMXレコードなど、Webの表示とは別の設定も関わります。Cloudflareの公式資料でも、DNSを切り替える前に既存の設定を確認し、メール関連の値は利用するメール事業者に照合するよう案内されています。DNS変更前の公式確認事項、メールを含むDNSレコードの説明(2026年10月20日確認)。

ここでは設定値の変更を勧めているのではありません。仕組みと契約で手順が異なるため、分からない項目は「未確認」として管理担当へ戻します。管理画面を見つけたことだけを理由に、ネームサーバーの変更や旧契約の解約を先に進めないでください。

仮の例:Webだけを移し、今のメールは残したい

店舗のサイトを新しい公開環境へ移す一方で、会社のメールは現在のサービスを使い続けたいとします。新サイトの表示が確認できても、旧契約にメールが含まれていれば、その解約で何が止まるかは別に確かめる必要があります。これは説明用の架空の状況で、GRAVIの顧客事例ではありません。

  • 残すもの:今のドメインとメールアドレス、必要な過去メール、継続する契約。
  • 変えるもの:Webの公開環境と、そのために担当者が変更すると確認した設定だけ。
  • 公開前の条件:旧契約に含まれる機能、変更前の設定、戻し方、切替・メール確認の担当を把握する。
  • 完了の条件:Webの表示、問い合わせ経路、必要なメールの送受信を担当者が確認する。実送信の試験は相手と方法を先に決める。

確認が終わるまで残す旧環境と、終了してよい契約も記録します。停止時間や移行可否を一律に約束せず、現在の契約先と新しい担当者が扱える範囲を照合してください。

秘密の情報ではなく、「確認できる人と場所」を引き継ぐ

最初の相談メモにパスワード、認証コード、メール本文、取引先の個人情報を書く必要はありません。契約を確認する資料の種類、管理担当、社内での安全な保管場所が分かれば、調査に必要な権限や共有方法を先に相談できます。実際の権限の付与・変更・削除は、対象と承認者を確かめてから行います。

ホームページの移行を検討するときは、今のURLと上の四つの役割で「分かること・未確認」をまとめ、公開後の管理と引き継ぎをご相談ください。ページの改修範囲は残す・直す・つくるの整理、日常の文章や写真の変更担当は更新の役割分担で分けて考えられます。

制作会社だけに残さず、自社でも持ちたいもの

  • ドメインや主要サービスの契約名義と更新先
  • 現在の公開ソース、HTML・CSS・JavaScript・画像・原稿などの復元材料
  • どのバックアップから、どう戻すかの記録
  • 管理者・編集者・外部担当者の権限一覧
  • 障害、改ざん、フォーム不達が起きたときの連絡順

制作会社やサービスが変わっても、サイトを失わずに移行できる状態を目指します。ただし、使っている仕組みやライセンスによって、渡せるデータや移行方法は異なります。契約前に「解約・移行時に何を受け取れるか」を確認してください。

セキュリティは、一度の検査で終わらない

IPA(情報処理推進機構)は、ウェブサイトの運用管理について、公開すべきでないファイル、不要なページ、脆弱性対策などを定期的に確認する必要があると示しています。また、簡易な診断で問題が見つからなくても、それだけで安全を保証するものではないと説明しています。

参考:IPA「安全なウェブサイトの運用管理に向けての20ヶ条」、IPA「安全なウェブサイトの作り方」(2026年10月12日確認)

保守契約の有無だけで安全を断定せず、対象、頻度、記録、問題が起きたときの対応を具体化します。

次にすること

現在の契約書や見積書を開き、「保守」「管理」「更新」と書かれた項目の横に、対象・頻度・担当・復旧範囲・別費用になる条件を書き足してみてください。空欄になったところが、制作会社や管理担当へ確認する質問です。

GRAVIでは、ホームページ制作と合わせて、公開後に必要な更新・保守の範囲を整理します。契約条件や料金はサイトの仕組みとご希望を確認して個別にご案内し、ここで一律の内容や成果を約束するものではありません。