保守契約を結ばないままサイトを公開した…最低限やっておきたい6つのことと、後から困らないための備え

2026年8月31日2026年10月9日

予算の都合で保守契約を結ばずにサイトやシステムを公開したものの、「このまま放っておいて大丈夫なのか」「最低限、何をしておけばいいのか」と不安になっていませんか。公開後に予算がつかなかった小規模サイトでは、とてもよくある状況です。

「保守契約を結んでいないサイトで、最低限何をしておけばいいか分からない」

先に結論をお伝えします。保守契約がなくても、「連絡先と資料の整理」「バックアップ」「更新の確認」「期限の管理」「異常に気づく仕組み」「いざという時の連絡先」の6つを押さえておけば、リスクは大きく減らせます。どれも専門知識は不要で、半日ほどの作業で始められます。

この記事では、保守契約を結んでいない小規模サイトの担当者向けに、最低限やっておきたいことをチェックリストと開発会社への質問例とあわせて解説します。なお、契約を結べば安心というわけではなく、結ばなくても最低限の備えはできる、という考え方でまとめています。

保守契約がないと、何が起きやすいのか

まず「なぜ放っておくと困るのか」を押さえておきましょう。理由が分かると、優先順位も決めやすくなります。

システムやサイトは、公開した時点で完成ではありません。使っている部品（ソフトウェアやライブラリ）には、あとから不具合や弱点が見つかり、修正版が公開されます。また、ドメインやサーバーには更新期限があります。保守契約は、こうした「公開後に必ず発生する作業」を誰が担当するかを決めておく仕組みです。

保守契約がない場合に起こりやすいのは、次のようなことです。

起きやすいこと	具体例
更新されない	部品の修正版が出ても反映されず、弱点が残ったままになる
期限切れに気づかない	ドメイン・SSL証明書・サーバーの契約が切れてサイトが見えなくなる
壊れても気づかない	問い合わせフォームが動かなくなっても、数週間誰も気づかない
誰に頼めばいいか分からない	障害時に、担当した会社に連絡がつくのか、費用はいくらか分からない

保守費用の内訳そのものについては、システムの保守費用は何に払っている？月額保守費の内訳と見直す前に確認したいことで詳しく解説しています。

最低限やっておきたい6つのこと

1. 「誰が何を持っているか」を1枚にまとめる

最初にやるべきは、サイトを構成するものの持ち主と連絡先の整理です。障害が起きたときに一番時間を取られるのが、「ドメインはどこで契約したか」「サーバーのログイン情報は誰が知っているか」の確認だからです。

ドメイン：契約している会社、名義、更新日、ログイン情報の保管場所
サーバー・クラウド：契約している会社、契約者、プラン、更新日
サイト・システムの管理画面：管理者のアカウントと担当者
作った開発会社：担当者名、連絡先、納品物（ソースコードや設計資料）の保管場所

ログイン情報は、メールに貼りつけず、社内で決めた方法（パスワード管理ツールなど）で保管しましょう。名義が開発会社になっている契約があれば、その点も1行メモしておくと、後で引き継ぐときに役立ちます。

2. バックアップを取り、「戻せる」ことを一度確かめる

最低限の備えの中で、最も効果が大きいのがバックアップです。IPA（情報処理推進機構）の「中小企業の情報セキュリティ対策ガイドライン」は、2026年3月公開の第4.0版で「バックアップを取ろう！」が追加され、基本の対策が5か条から6か条になりました（2026年10月時点）。

📰 出典：IPA「中小企業の情報セキュリティ対策ガイドライン」

確認したいのは、次の3点です。

サイトのファイルとデータベースの両方が対象になっているか
バックアップが、サイトと同じ場所だけに置かれていないか
実際に戻す手順があり、一度は試したか

「取っている」と「戻せる」は別の話です。復元テストの進め方は、「バックアップは取っています」と言われたけれど、本当に戻せる？復元テストを誰がどう行うか、発注者が確認する5つのことを参考にしてください。

3. 更新が必要な部品を洗い出し、更新の担当を決める

次に、サイトが何でできているかを把握します。WordPressなら本体・テーマ・プラグイン、そのほかのシステムならフレームワークやライブラリが該当します。バージョンの一覧を残しておくだけでも、脆弱性（＝悪用されうる弱点）のニュースが出たときに「うちは該当するのか」をすぐ確認できます。

大事なのは、更新を自分たちでやるのか、誰かに頼むのかを決めておくことです。更新は、反映したことで画面が崩れることもあるため、実施前にバックアップを取る、できれば本番と別の環境で試すといった手順が必要です。自信がなければ、更新作業だけを単発で頼める相手を探しておきましょう。

4. 期限のあるものをカレンダーに入れる

ドメイン、SSL証明書（＝通信を暗号化するための証明書）、サーバーの契約、ライブラリやOSのサポート期限は、切れるとサイトが突然見えなくなったり、修正が受けられなくなったりします。

更新日の1か月前と1週間前に通知が来るよう、カレンダーに登録する
通知メールの宛先が、退職した担当者個人のアドレスになっていないか確認する
自動更新に設定できるものは、支払い用のカードの有効期限も合わせて確認する

5. 「壊れたことに気づく仕組み」を無料でも作る

保守がないと、障害に気づくのは「お客様からの連絡」になりがちです。次のような簡単な仕組みで、気づくまでの時間を短くできます。

外形監視（＝外からサイトが見えるかを定期的に確認する仕組み）を無料プランなどで設定し、異常時にメールが届くようにする
問い合わせフォームは、月に一度は自分でテスト送信して届くか確認する
管理画面やサーバーからの通知メールを、見える場所に転送する

6. いざという時の連絡先と費用の考え方を決めておく

障害が起きてから相談先を探すと、対応が遅れます。事前に、次のことだけ決めておきましょう。

最初に相談する相手（作った開発会社、サーバー会社のサポートなど）
連絡が取れなかったときの次の相手
スポット（＝単発）で頼んだ場合の対応可否と、費用の決まり方（時間単価か、1件ごとの見積もりか）
社内で緊急対応の費用を承認できる人

作った開発会社に単発で相談できるかは、会社によって異なります。公開後に一度、「保守契約なしでも、障害時に単発で相談できますか」と聞いておくと安心です。

やりがちな失敗

「何も起きていないから大丈夫」と考える：弱点は外から見えません。何も起きていないのは、気づいていないだけの場合もあります
ログイン情報が担当者の頭の中にしかない：異動や退職で、誰も管理画面に入れなくなります
更新を怖がって何年も止めてしまう：古くなるほど、更新時の作業量と費用が大きくなります。部品のバージョンが古くなったときの考え方は、保守契約に脆弱性対応は含まれる？緊急パッチで追加費用が出る場合の見分け方と、開発会社への質問も参考になります
バックアップを同じサーバーの中だけに置く：サーバー自体に問題が起きると、サイトとバックアップが同時に失われます