レンタルサーバー契約前に確認すべきチェックリスト

契約前のチェックリストは、機能名へ印を付けるだけでは足りません。自社の要件を満たす根拠となる公式ページや回答を残し、担当者が替わっても同じ条件で判断できる状態にします。

新規契約でも、ドメインやメールをすでに使っている場合は移行です。現在の構成を確認してから候補の条件へ進むと、契約後にDNSやメールで作業が止まるのを防げます。

現在の契約と管理画面を先に確認する

ドメイン登録者・レジストラ・権威DNS・Webサーバー・メールサービスを一覧にします。請求書と管理画面へ実際にログインし、会社が変更権限を持つかを確認します。制作会社へ任せていても、会社名義とは限りません。

現在のサイト数・メール利用者・データ容量・外部フォームも記録します。見えているWebページだけを移しても、DNSや通知先が残る場合があります。契約を追加するのか置き換えるのかを明確にします。

不明な契約は、推測で新サービスへ置き換えません。請求元と現在の制作会社へ確認し、解約すると止まる機能を特定します。確認できない項目には担当者と期限を付けます。

会社案内・問い合わせ・採用・予約・注文のうち、停止すると業務へ影響する機能を決めます。代替連絡先と許容できる停止時間を確認します。この結果から監視、復元、サポートの必須条件を作ります。

WordPressを使うなら現行の推奨環境へ更新できることが必要です。メールを同じ契約へ置くなら、アカウント管理と送受信の制限を見ます。希望機能と必須機能を分け、候補を増やしすぎません。

必須条件には確認方法も添えます。「速いこと」ではなく、対象ページを一定条件で測ると書きます。「復元できること」なら、試験サイトを何時間で戻すかを合格条件にします。

取得対象にファイルとデータベースが含まれるかを確認します。保持期間・取得間隔・復元料金・依頼方法も見ます。管理画面から戻せる場合でも、サイト単位か契約全体かで影響が変わります。

自社が別の保存先へ書き出せるかも確認します。注文や問い合わせがあるサイトでは、古い時点へ戻した後の差分を扱う必要があります。試用できるなら、テストサイトを復元して所要時間を測ります。

復元手順の説明が契約後にしか見られない場合は、サポートへ事前に質問します。申請の締切や本人確認も含め、休日の障害で誰が依頼できるかを決めます。回答の確認日を残します。

サーバー会社が対応するのは基盤や管理画面までで、WordPress内部や制作物は範囲外の場合があります。DNS・メール・証明書・アプリケーションのどこを誰へ連絡するかを分けます。営業時間外の受付方法も確認します。

外部の制作会社へ保守を任せるなら、月次作業と障害対応を契約へ書きます。「サーバー保守一式」では完了条件が分かりません。緊急時の連絡先と、委託先が不在の場合の代替先も決めます。

契約前に想定障害を一つ示し、各社へ誰が何をするか質問します。サーバー会社と制作会社の回答に隙間があれば、自社の担当か追加保守で埋めます。連絡のたらい回しを契約後へ残しません。

初回割引ではなく通常更新後の料金を基準にします。ドメイン・証明書・バックアップ復元・追加アカウント・移行作業を含めます。契約期間と支払周期をそろえ、途中解約時の返金や違約条件も確認します。

自動更新の日付と支払手段を記録します。クレジットカードの期限切れや担当者退職で更新できない状態を避けます。請求書払いが必要なら、発行されることと後払いできることを混同せず、支払期限まで確認します。

比較期間は少なくとも通常料金へ戻る更新後を含めます。値上げ可能性があるため、金額の保証ではなく確認時点の前提として残します。予算の余裕と見直し時期を別に決めます。

データの書き出し・ドメイン移管・DNS変更・解約後の保存期間を確認します。独自機能を使う場合は、他社へ移ると失われる機能を記録します。移行時の並行契約期間も予算へ含めます。

最後に、必須条件を満たす根拠URLと確認日を候補ごとに残します。不明点は「たぶん対応」ではなく、サポート回答を得てから承認します。契約者、支払者、運用担当者が同じ判断資料を確認した時点で契約へ進みます。

承認後は、申込内容と判断資料が一致するかを再確認します。プラン名や契約期間を取り違えると、比較した条件が無効になります。契約完了日と次回確認日を管理台帳へ移します。