# IT担当者がいない会社のWebサイト保守｜ドメイン・バックアップ・責任分界を自社で持つ

> IT担当者がいない中小企業のWebサイト運用を、ドメインの登録者と期限、DNS、CMS更新、バックアップの復元テスト、多要素認証の順に解説します。自社・外注先・事業者の責任分界表、退職時の引継ぎ表、運用台帳の雛形つきで、外注範囲と費用の決まり方も分かります。

- 公開日: 2026-11-09
- 著者: 友田 陽大
- タグ: Webサイト運用, セキュリティ, 中小企業, 発注, インフラ
- URL: https://tomodahinata.com/blog/no-it-staff-website-maintenance-outsourcing
- カテゴリ: Web集客・サイト運用
- 総合ガイド: https://tomodahinata.com/blog/website-no-inquiries-causes-solutions

## 要点

- IT担当者がいなくても運用はできる。ただしドメインの登録者、DNS、管理者アカウントの名義は自社に置き、外注しない
- JPドメイン名は廃止された後、一定期間で第三者が同じ文字列を登録できるようになる。サイトとメールの両方に影響するので、更新の連絡先と支払い方法を確認する
- バックアップは取るだけでは足りない。IPA のガイドラインも戻せるかの定期的な確認を挙げている。年に数回、復元を試して時間を記録する
- 障害のたびに揉めないよう、自社・外部の担当・サーバーなどの事業者の役割を表にして契約に入れる。委託先の不備でも、委託元の管理責任は問われる
- 一人の外注先はそれ自体が単一障害点になる。アカウントを自社名義にし、手順を文書にして、別の人が引き継げる状態を保つ

---

社内にIT担当者がいなくても、Webサイトの運用はできます。ただし、**作業は外注できても、持ち主であることは外注できません。** ドメインの登録者、DNSの管理画面、管理者アカウントの名義を会社に置いたうえで、更新と点検を外部に任せる形が基本です。

逆に、名義も連絡先も外部任せのまま何年も経った会社では、担当者の退職や制作会社との解約で、サイトやメールを動かせなくなることがあります。これは技術の問題より、誰が何を持っているか分からないことが原因です。

この記事では、まず自社の状態を1時間で棚卸しし、ドメインから順に誰が何を持つかを決めます。最後に、責任分界表、退職時の引継ぎ表、運用台帳の雛形を載せました。専門用語は出てきた場所で説明します。

## 最初の1時間でやる棚卸し

社内の誰かが、次の表を埋めてください。分からない欄は「不明」と書けば十分です。不明な欄がそのまま最初の課題になります。

| 対象 | 確認する場所 | 書き出すこと |
|---|---|---|
| ドメイン | JPRS WHOIS、契約書、請求書 | 登録者名、期限、契約先、管理画面にログインできる人 |
| DNS | 管理画面 | 誰が編集できるか、設定内容の控えがあるか |
| サーバー | 請求書、管理画面 | 契約名義、プラン、支払い方法 |
| CMS（更新用の管理画面） | 管理者一覧 | 管理者の人数、使っていない人のアカウント |
| メール | 契約、管理画面 | 請求や期限の通知が誰の受信箱に届くか |
| バックアップ | 契約、作業記録 | どこにあるか、最後に復元を試したのはいつか |
| 計測 | Search Console、GA4 | 自社のアカウントが所有者か |

見てほしいのは「期限の通知が届く先」です。退職した人の個人アドレスや、制作会社のアドレスになっていると、更新の案内も不審な変更の知らせも届きません。

## ドメイン：止まると最も困るのに忘れられやすい

ドメインは、Webサイトとメールアドレスの両方の土台です。止まると両方に影響します。

### 登録者と連絡先を分けて見る

| 用語 | 意味 | 確認すること |
|---|---|---|
| 登録者 | ドメイン名を登録した組織や人 | 自社の正式名称になっているか |
| 指定事業者（管理指定事業者） | 登録者の申請をJPRSに取り次ぐ事業者。1つのドメインに1社だけ | どの会社と契約しているか |
| 登録担当者・技術連絡担当者 | `co.jp` などの属性型JPドメイン名に登録される担当者 | 退職した人のままになっていないか |
| 公開連絡窓口 | 汎用JPドメイン名（`.jp`）で公開される連絡先 | 実際に受信できるか |

`.jp` や `co.jp` の情報は JPRS WHOIS で確認できます。汎用JPドメイン名は設定により登録者名が表示されないことがあります。その場合は契約している指定事業者に確認してください。`.com` などのドメインは JPRS の規則とは別の手続きと期間になるので、利用しているレジストラ（ドメインの登録事業者）の規約を確認します。

制作会社が代わりに登録して、登録者がその会社名になっていることがあります。良し悪しの問題ではなく、その会社との取引が終わったときに手続きが必要になるという点が問題です。

### 期限が切れると何が起きるか

JPRS の説明では、JPドメイン名の有効期限は登録日の1年後の月末で、期限までに廃止されなければJPRS上は1年間自動更新されます。ただし更新の手続きと料金は契約している指定事業者ごとに異なります。JPRS も、更新の期限を過ぎて意図せず廃止となる場合を案内しています。

| 状態 | 汎用JPドメイン名 | 属性型JPドメイン名（`co.jp` など） |
|---|---|---|
| 廃止後の期間 | 翌日から1カ月間（月末まで） | 翌日から6カ月間（月末まで） |
| 登録回復できる期間 | 廃止された状態になった月の1日から20日まで | 廃止申請から廃止された場合、その月の1日から20日まで |
| 回復しなかった場合 | 情報が削除され、同じ文字列を登録できるようになる | 情報が削除され、同じ文字列を登録できるようになる |

登録回復は通常手数料がかかり、扱いや受付期間は指定事業者ごとに違います。

[JPRS の注意](https://jprs.jp/registration/suspended/)によると、廃止されたドメイン名が第三者に登録されると、詐欺サイトに悪用されたり、同じメールアドレスを作られたりする可能性があります。さらに、そのメールアドレスでログインしていたサービスのパスワードを初期化され、アカウントを乗っ取られるおそれもあります。商標の侵害など紛争処理方針に該当する事由がない限り、第三者の登録や使用を差し止めることはできないとされています。

期限切れによる意図しない廃止は、更新の通知先と支払い方法を確認しておけば防げます。棚卸しの表で、この2つを最初に埋めてください。

### ドメインの乗っ取りを防ぐ

JPRS は [乗っ取りへの注意](https://jprs.jp/registration/domain-hijacking/)として、社内で管理の担当と手順を決めること、WHOIS で定期的に状態を確かめること、管理サービスからの変更通知を一元的に確認すること、強いパスワードと二要素認証を使うことを挙げています。

重要なドメインなら、[レジストリロック](https://jprs.jp/about/dom-rule/registry-lock/)という、登録情報の書き換えを制限するサービスもあります。ただし取り扱いは指定事業者によって異なり、提供していない場合もあります。

業者を変えるときは、[管理指定事業者の変更](https://jprs.jp/about/dom-rule/agent-change/index.html)の手続きをします。認証コードを変更元の指定事業者に確認して、変更先に申し込む流れで、完了まで数日かかることがあります。解約日ぎりぎりに始めないことです。

## DNS：作業の前に、今の設定を保存する

DNS は、ドメインとサーバーやメールの結びつきを決める設定です。Webサイトの置き場所を指すレコードと、メールの配送先を指すレコードは別に管理されていて、ここを触るときに事故が起きやすいです。

よくある失敗は、サーバーを移転するときに DNS の管理先ごと切り替えて、メール関連のレコードを引き継がなかった、というものです。Webは動いたのに、問い合わせの通知メールだけが届かなくなります。

筆者が DNS を変更するときは次の順で進めます。

1. 現在の全レコードを書き出して保存する
2. 変更する内容を、理由とあわせて文章にする
3. 戻すときの手順を先に決める
4. 変更後に Web の表示とメールの送受信の両方を確認する
5. 変更の記録を運用台帳に残す

DNS の編集権限を持つ人は最小限にします。外注先に渡すなら作業のときだけ、または担当者専用のアカウントにしてください。

## サーバーとCMSの更新：運営形態で範囲が変わる

IPA の[中小企業の情報セキュリティ対策ガイドライン 第4.0版](https://www.ipa.go.jp/security/guide/sme/about.html)は、Webサイトの運営形態ごとに、自社で行う対策が変わることを説明しています。

| 運営形態 | サーバーなどの対策 | 自社側で行うこと |
|---|---|---|
| 自社サーバー（オンプレミス） | すべて自社 | 全部 |
| レンタルサーバー・クラウド | 事業者が担当 | Webサイトの構築・運用に関わる対策 |
| ショッピングモール・ASP（機能をまとめて提供するサービス） | 事業者が担当 | コンテンツの更新と、認証情報の管理 |

自社がどの形なのかで、外注の範囲は変わります。Wix のような一括型のサービスなら、外注するのは主に文章の更新で、認証情報の管理は社内に残ります。WordPress をレンタルサーバーに置いているなら、本体とプラグインの更新、PHP のバージョン対応が保守の中心になります。

更新の進め方は、運用台帳に手順を書いておきます。

- 更新の前にバックアップを取る
- 可能ならステージング環境（本番と同じ構成の確認用環境）で試す
- 更新後に、トップページ、問い合わせフォームの送信、メールの受信、管理画面へのログインを確認する
- 不具合が出たら元に戻す方法を決めておく
- 使っていないプラグインとテーマは削除する

問い合わせフォームは、見た目が正しくても送信が届かないことがあります。更新の確認項目に必ず実際の送信テストを入れてください。IPA の[安全なウェブサイトの運用管理に向けての20ヶ条](https://www.ipa.go.jp/security/vuln/websecurity/sitecheck.html)は「定期的に確認する必要」があるチェックリストで、年に1度は外注先と一緒に見ることをおすすめします。独自開発のフォームや機能があるなら、[安全なウェブサイトの作り方](https://www.ipa.go.jp/security/vuln/websecurity/about.html)を開発者と確認してください。

## バックアップは、戻してはじめて役に立つ

IPA のガイドラインは「バックアップを取ろう！」を情報セキュリティ6か条に加え、「バックアップしたデータを戻せるか定期的に確認する」ことを挙げています。

保存するものは Web のファイルだけではありません。

| 対象 | 忘れやすい点 |
|---|---|
| CMS のデータベース | 記事や問い合わせ履歴はファイルではなくここにある |
| アップロードされた画像や添付 | 容量が大きく、対象外にされがち |
| 設定ファイル | 環境ごとの設定が入っている |
| DNS のレコード一覧 | 更新のたびに控える |
| メール | Web とは別の契約になっていることが多い |

サーバー会社のバックアップだけに頼るのは避けます。保存期間と復元の条件はプランによって違います。また、改ざんに長く気づかないと、保存している世代がすべて改ざん後のものになります。IPA の[クラウドサービス安全利用の手引き](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_cloudservice.pdf)は「バックアップに責任を持つ」として、重要情報を手元に確保し、複数世代を取ることを勧めています。

年に数回は、実際に復元してみます。

```text
復元テストの手順
1. テスト用の環境を用意する（本番を上書きしない）
2. バックアップからファイルとデータベースを戻す
3. トップページ、下層ページ、画像、管理画面ログイン、フォーム送信を確認する
4. 開始から完了までの時間を記録する
5. うまくいかなかった点と、次の変更点を運用台帳に書く
```

ここで大事なのは時間の記録です。障害が起きたときに「復旧まで何時間かかるか」を顧客や社内に説明できるからです。

## 多要素認証と権限の持ち方

総務省の[国民のためのサイバーセキュリティサイト](https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/security/business/staff/06/)は、知識情報・所持情報・生体情報のうち2つ以上を組み合わせる認証を多要素認証と説明し、設定できる場合は積極的に利用するよう勧めています。

設定する優先順位は、ドメイン管理、サーバー管理、CMS の管理者、Google アカウント、会計や請求の管理画面、の順です。ドメイン管理を奪われると、他の対策の前提が崩れます。

権限の持ち方は次の3点に絞ります。

- 人ごとにアカウントを作り、ID とパスワードを共有しない
- 外注先には作業に必要な権限だけを渡し、契約が終わったら削除する
- 四半期に1度、管理者の一覧を確認し、不要な人を外す

代表者のスマートフォンだけに認証を集中させると、機種変更や紛失で会社全体が締め出されます。復旧コードは印刷して施錠できる場所に保管し、可能なら2人目の管理者を登録します。

## 責任分界表：障害が起きる前に決める

次の表は、よくある分担の例です。実際の分担は契約で決めます。

| 事象 | 自社（発注者） | 外部の担当（制作・保守） | サーバーなどの事業者 |
|---|---|---|---|
| ドメインの期限切れ | 支払い方法の維持、通知の受信 | 期限を台帳で確認して連絡 | 更新の窓口 |
| DNS の誤設定 | 変更の承認 | 手順に沿った変更と切り戻し | DNS 基盤の稼働 |
| SSL 証明書の期限切れ | 通知の受信 | 更新設定の確認 | 自動更新の提供（プランによる） |
| サーバー障害 | 顧客への案内の判断 | 切り分けと事業者への連絡 | 復旧 |
| CMS の更新 | 停止時間と費用の承認 | 実施と動作確認 | 基盤の提供 |
| フォームが届かない | 不具合の連絡、受信の確認 | 原因調査と修正 | メール配送の稼働 |
| 改ざん・不正アクセス | 公開停止の判断、関係者への連絡、報告の判断 | 調査、復旧、記録の保全 | ログの提供、隔離 |
| アカウントの乗っ取り | 名義人としての回復手続き | 影響範囲の確認 | 本人確認の手続き |
| 個人情報の漏えいの疑い | 報告・通知の判断と実施 | 事実の調査と報告 | ログの提供 |
| バックアップと復元 | テスト結果の確認 | 取得と復元手順の維持 | 自動バックアップ（プランによる） |

この表を契約に入れる理由があります。IPA のガイドラインは「委託先の不備だったとしても、事故の影響を受ける者から委託元としての管理責任を問われる」と書き、契約書に委託先の責任と実施すべき対策を明記して合意する必要があるとしています。外注しても、説明責任はなくなりません。

インシデントが疑われるときは、まず慌てて消さないことです。IPA の[インシデント対応の手引き](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0_app_incidenttebiki.pdf)は、被害が広がるおそれがあるときはネットワークの遮断やサービスの停止を行いつつ、「対象機器の電源を切る等、不用意な操作でシステム上に残された記録を消さないように」と注意しています。

[個人情報保護委員会](https://www.ppc.go.jp/personalinfo/legal/leakAction/)は、たとえばWebサイトの改ざんで入力された個人情報が第三者に送信された場合を、報告対象の例に挙げています。発覚したら速やかに報告し、不正な目的で行われたおそれがある場合は発覚日から60日以内に報告することになっています。報告の要否と内容は、個別に弁護士などの専門家と個人情報保護委員会の案内で確認してください。

## 担当者が辞めるときの引継ぎ表

退職が決まったら、最終出社日の前に次の表を埋めます。

| 項目 | やること | 完了の確認 |
|---|---|---|
| ドメインの連絡先 | 登録担当者と通知先を更新する | WHOIS と指定事業者の画面で確認 |
| サーバーと各契約の名義・請求先 | 会社のアドレスに変更する | 請求メールが新しい宛先に届く |
| 管理画面のログイン情報 | 退職者のアカウントを停止する | 退職者がログインできない |
| 多要素認証の登録 | 退職者のスマートフォンを外し、別の端末を登録する | 新しい端末でログインできる |
| CMS の管理者 | 不要な管理者を削除する | 管理者一覧を確認 |
| Search Console | 所有者を更新し、未使用のトークンも確認する | 「ユーザーと権限」で確認 |
| GA4 | 管理者を更新する | 自社のアカウントでアクセスできる |
| メール | 転送先と共有の受信箱を決める | 通知が受け取れる |
| 外注先の連絡先 | 新しい窓口を伝える | 外注先から返信がある |
| 運用台帳 | 最新にして、次の担当が読む | 次の担当が一人でログインできる |

Search Console は、所有者を外しても確認トークンが残っていれば所有権を再確認できる仕組みです。詳しくは [月額運用の契約で確認する項目](/blog/monthly-seo-website-operations-5-10man)で扱っています。

## 一人の外注先は、それ自体が単一障害点になる

筆者自身が一人で受託しているので、率直に書きます。**一人の外注先には、その人が病気や事故で動けなくなると、すべてが止まるリスクがあります。** 連絡が早く、全体を一人が把握している利点の裏返しです。24時間の対応を一人に期待するのも現実的ではありません。

| 観点 | 一人の外注先 | 会社 |
|---|---|---|
| 窓口 | 本人に直接つながる | 担当者を介す |
| 休止時のリスク | 本人が動けないと止まる | 体制はあるが、担当が交代する |
| 引継ぎ | 文書がなければ本人の頭の中だけ | 社内にも文書があるとは限らない |
| 費用の傾向 | 会社の管理費が小さい | 組織の費用が加わる |

どちらを選んでも、やることは同じです。

- ドメイン、サーバー、CMS、計測ツールのアカウントは自社名義にする
- 手順書と構成の説明を、作業のたびに更新して受け取る
- 特定の人しか直せない独自の仕組みを増やさない
- 連絡が3営業日つかないときの手順と、代わりの依頼先の候補を決めておく
- 契約書に、解約時の引き渡し物と協力の範囲を書く

## 運用台帳の雛形

下の雛形をコピーして使ってください。パスワードそのものは書きません。保管場所だけを書きます。

```text
Webサイト運用台帳（雛形）
最終更新日：　　　　　更新者：

【1. 基本情報】
サイトURL／目的／社内の責任者／外部の担当者と連絡先

【2. ドメイン】
ドメイン名／登録者名／管理指定事業者／有効期限
更新の連絡先／支払い方法／管理画面のログイン先
ログイン情報の保管場所／多要素認証の登録先

【3. DNS】
管理している場所／最終変更日／レコード一覧の保管場所

【4. サーバー・CMS】
契約会社とプラン／名義／請求先／CMS の種類と管理者一覧
使用中のプラグイン一覧／最終更新日／更新の手順の保管場所

【5. バックアップ】
対象／頻度／保存先／世代数／最後の復元テスト日／所要時間

【6. 計測】
Search Console の所有者／GA4 の管理者／問い合わせの台帳の場所

【7. 連絡】
障害の連絡先／連絡の順番／連絡がつかないときの手順

【8. 変更履歴】
日付／作業者／内容／確認結果
```

## 外注の範囲と費用の決まり方

相場は条件で大きく変わるため、ここでは費用を決める要因を示します。

| 要因 | 費用に効く理由 |
|---|---|
| サイトの形態 | ASP型はCMS更新がなく、自社サーバーは範囲が広い |
| プラグインや独自機能の数 | 更新後の確認が増える |
| 更新の頻度 | 毎週か、月1度か |
| 対応時間帯 | 夜間や休日の対応を含むか |
| 復元テストの回数 | 年に何回試すか |
| 文書の整備 | 台帳を作って維持するか |

月額の見積もりを受けたら、月の作業時間の上限と、含まれない作業を書面で確認してください。月額を作業時間に割り戻す計算は[月額5万〜10万円のSEO・Webサイト運用で何を依頼できるか](/blog/monthly-seo-website-operations-5-10man)で解説しています。これからサイトを作る、作り直す段階なら、[中小企業がWeb制作を外注する際の費用と依頼方法](/blog/small-business-website-outsourcing-cost)も確認してください。

筆者が保守を受ける場合も、ドメインと権限の棚卸しから始め、月の作業時間の上限と対応範囲を書面で決めます。応答時間の保証はしていません。詳しくは[部分改修・小規模制作・保守](/services/website-development)をご覧ください。

## 今週確かめる3つのこと

今週、次の3つだけやってください。

1. 棚卸しの表を埋める
2. ドメインの登録者と、更新の通知先を確認する
3. バックアップの保存場所と、最後に復元を試した日を外注先または社内で確認する

3つとも答えられれば、外注範囲の話を始める準備ができています。