法人向けレンタルサーバーに必要なのは、個人向けより大きな容量とは限りません。会社の契約として所有でき、担当者や制作会社が替わっても、サイトとメールを止めずに管理を続けられることが重要です。
機能表を比較する前に、契約者と日常運用者を決めます。障害時の判断者も別に確認します。この体制を載せられるサービスが法人向けの候補になります。
契約名義と更新通知を会社へ寄せる
契約者は会社とし、請求先と登録メールも組織で管理します。代表者や担当者の個人アドレスだけを使うと、退職後の本人確認や更新通知で止まります。少なくとも二人が契約情報へ到達できる状態を作ります。
制作会社が申し込む場合でも、契約名義・ドメイン登録者・支払者を確認します。作業用の権限と契約変更権限を分けます。委託終了時に会社へ返す情報と、削除するアカウントを契約へ含めます。
法人確認に必要な書類と変更手続も見ます。社名変更や事業譲渡のときに、名義を移せるかを確認します。契約番号と問い合わせに必要な本人確認情報は安全な場所へ保管します。
Webとメールの停止影響を分ける
同じサーバーでWebとメールを運用すると、管理をまとめられます。一方で移転や契約停止の影響が両方へ及びます。メール利用者が多い会社では、外部メールサービスへ分ける構成も含めて検討します。
分離してもドメインとDNSは共有します。Webの向き先だけを変える作業で、MXや送信認証のTXTを残せるか確認します。構成図にはWeb、メール、DNSの事業者と問い合わせ先を別々に書きます。
メールをサーバー付属機能で使う場合は、利用者追加と退職者停止の手順も見ます。保存容量だけでなく、端末故障時にメールを再設定できる情報を会社が持てるかを確認します。
権限は担当業務ごとに分ける
契約変更・DNS編集・ファイル転送・WordPress投稿では必要な権限が違います。一つの管理者アカウントを全員で共有せず、利用者ごとに発行できるサービスを選びます。操作履歴を確認できると、誤変更の調査にも役立ちます。
外部委託先には作業期間と対象を限定します。二要素認証の受取先を個人端末だけへ固定しない運用も必要です。担当交代時には、新しい人を追加して操作確認を行い、旧担当者を停止する順序で進めます。
権限変更の履歴には、承認者と終了日を残します。緊急用の管理者アカウントは日常作業に使わず、利用したときに通知される状態にします。定期的にログイン可能かも確認します。
復旧時間からバックアップと監視を選ぶ
自動バックアップの有無だけでなく、何日前まで戻せるかを確認します。復元担当と所要時間も見ます。ファイルとデータベースを同じ時点へ戻せることが必要です。別の保存先へ持ち出せるかも確認します。
監視はサーバー稼働だけでなく、利用者が主要ページを開けるかを確認します。フォームや予約が重要なら送信処理も別に点検します。停止を検知した後の連絡順と告知方法まで決めて、復旧目標を現実の運用へつなげます。
候補サービスでは、試験サイトを一度復元します。復元申請の受付から確認完了までの時間を測り、業務が求める時間と比べます。満たせなければ外部保存や保守契約を補います。
サポートと保守契約の境界を確認する
サーバー会社のサポートが、WordPress内部や制作物の不具合まで直すとは限りません。契約・基盤・メール・DNS・アプリケーションのどこまで問い合わせられるかを確認します。不足する範囲は制作会社や保守会社へ割り当てます。
受付時間だけでなく、緊急時の経路と本人確認に必要な情報を見ます。障害情報を公開するページがあるかも確認します。自社側は契約番号・発生時刻・対象URL・画面の状態を集めて連絡できるようにします。
問い合わせの回答は管理台帳へ残します。同じ問題が起きたときに一から説明せず、以前の受付番号と対応結果を参照します。未解決の課題は月次確認へ戻します。
一年後の変更と移行まで条件にする
事業が増えたときにプランを変更できるか、変更に停止があるかを確認します。データを書き出せず、独自機能から離れられない構成は将来の選択肢を狭めます。ドメイン移管と解約後のデータ削除条件も契約前に見ます。
最終判断には、契約主体・権限・Webとメールの構成・復旧目標・サポート境界・移行方法を一枚にします。会社が所有し、非専任の担当者でも外部支援を使いながら維持できる候補を選びます。
承認資料には採用しなかった候補と理由も残します。要件が変わったときに再利用でき、単なる価格差で選び直すのを防げます。次回見直し月を契約更新より前に設定します。