サーバー契約から1年後に見直すべき項目

サーバーを一年使うと、契約時には分からなかった実績が集まります。アクセスは想定より少なかったかもしれませんし、問い合わせやメールだけが増えたかもしれません。更新案内が届いてから料金を比べるのではなく、この実績を次の一年の条件へ変えます。

年次の保守点検が現在の資産や設定を確かめる作業なら、一年後の見直しは契約が事業に合っているかを決める作業です。確認しただけで終わらせず、現状維持・プラン変更・移行のいずれかへ理由を付けます。

契約時の想定を実績で置き換える

最初の見積書や要件表を開きます。月間アクセス・保存容量・サイト数・メール利用者を現在値と比べます。平均値だけでなく、最大値と増え方を見ることが大切です。一時的なキャンペーンの山と、毎月続く増加を分けて記録します。

使っていない容量が大きくても、すぐ最小プランへ下げるとは限りません。バックアップ領域や繁忙期の余裕が含まれている場合があります。反対に空き容量があっても、同時処理やデータベース制限が原因で遅いことがあります。

メールボックスやログが継続して増えているなら、次の一年後までの量も見積もります。削除でしのぐ前に、業務上残す期間を確認します。

基本料金に、バックアップ・セキュリティ・作業代・ドメイン・証明書などを加えます。障害や更新のたびに外部作業が発生したなら、その費用と社内の対応時間も実績です。月額が安くても、手作業が多ければ運用費は下がりません。

次年度の更新価格と支払期限を確認し、自動更新の有無を記録します。割引終了や契約期間の変更があれば、現在と同じ条件で比較しません。請求先が退職者や古いカードのままになっていないかも、この時点で直します。

移行候補の初期費用や並行契約期間も一年の総費用へ含めます。価格差だけでなく、社内作業を減らせる機能の効果も見ます。

表示停止・メール不達・バックアップ復元・サポート問い合わせを時系列にします。件数だけでなく、検知までの時間と復旧までの時間を見ます。問題が少なかったのは安定していたからか、監視がなく気づかなかったからかを切り分けます。

サポートを利用した場合は、返答の速さより解決まで進められたかを評価します。緊急時に必要な連絡方法が契約プランに含まれるか、営業時間が自社の運用と合うかも確認します。一年分の実体験は、比較表より確かな判断材料です。

同じ障害を繰り返した場合は、原因と恒久対応が記録されているかを見ます。問い合わせ番号を並べるだけでなく、未解決の課題を次年度へ持ち越します。

契約者・管理者・制作会社・通知先を一覧にし、在籍者と一致するか確認します。使っていないFTPアカウントや古い検証サイトは、容量だけでなく攻撃される入口になります。必要性を確認して停止し、削除前に保管要否を決めます。

WordPressのサイトヘルスでは、ソフトウェアの更新状態やサーバー情報を確認できます。ただし診断結果だけで契約の良否は決まりません。実際のサイト一覧・DNS・メール・外部サービスを含む構成図と照合します。

契約には残っているのに構成図へないサイトは、停止前に所有者と用途を調べます。通知先が一人だけなら、組織の共有窓口も追加します。

「自動バックアップあり」という契約表示だけでは、必要な時点へ戻せるか分かりません。ファイルとデータベースの対象、保存日数・別の場所への保管・復元申請の条件を確認します。問い合わせや注文があるサイトでは、古い時点へ戻した後の差分処理も必要です。

一年の間に復元を試していなければ、影響の少ない環境で手順を確認します。所要時間と担当者を記録し、契約を変えた場合も同じ復旧目標を満たせるか比べます。容量だけを移行条件にすると、復旧能力が下がることがあります。

現状維持なら、現在の契約が実績と復旧要件を満たす理由を書きます。プラン変更なら、変更で解消する制限と実施日を決めます。移行なら、更新期限から逆算して検証・DNS切替・旧契約の解約までの時間を確保します。

判断できない項目を放置せず、確認先と期限を付けます。結論を承認した人と次回の見直し月も記録すれば、契約更新が担当者個人の判断になりません。

一年後の見直しで大切なのは、新しい会社へ替えることではありません。契約時の想定を実績へ置き換え、費用・障害・権限・復元を同じ判断に集めることです。結論と次回確認日を残せば、更新のたびに最初から調べ直さずに済みます。