システムやホームページが公開されてほっとしたのも束の間、「アップデートのお知らせ」「SSL証明書の期限」「ドメイン更新のご案内」といったメールが届き始めます。ところが社内の誰に聞いても、開発会社とサーバー会社のどちらがやることなのか、はっきりしない。公開後の運用・保守の役割分担が決まっていないのは、実はとてもよくある状態です。
「公開後のアップデートや監視を、開発会社と自社のどちらがやるべきなのか分からない。会社のホームページもWordPressだけど、誰が更新しているのか、最新版なのかも分からない…」
先に結論をお伝えします。公開後の作業は「誰がやるか」を1枚の役割分担表にしておけば、ほとんどの不安は整理できます。正解の分け方は会社ごとに違いますが、どの作業にも「実際に手を動かす人」と「やったことを確認して決める人」が必要です。そして、後者は多くの場合、発注者側に残ります。
この記事では、公開後に発生する作業の一覧と、発注者・開発会社・サーバー会社の役割分担表の例、技術に詳しくなくてもできる現状の確かめ方、保守契約や運用手順書への書き方、保守契約がないサイトの最低限の運用プランを解説します。
公開後の運用・保守を「誰がやるか」が曖昧になる3つの理由
まず、なぜ役割分担が曖昧になりやすいのかを押さえておきましょう。理由が分かると、どこを確認すればいいかが見えてきます。
理由1：開発の契約は「公開まで」で終わっていることが多い
開発の契約は、多くの場合「システムを作って納品する」ところまでが範囲です。公開後の更新や監視は、別途「保守契約」を結ばないと、開発会社の仕事には含まれていないのが一般的です。発注者は「作った会社が面倒を見てくれるもの」と思い、開発会社は「保守のご依頼はいただいていない」と考えている——この認識のずれが、よくある出発点です。
理由2：関わる会社が3者以上いる
Webサイトや業務システムには、たいてい次のような関係者がいます。
- 発注者（自社）：サイトの持ち主。内容や方針を決める
- 開発会社（制作会社）：システムを作った会社。保守契約があれば更新作業も担当
- サーバー会社（レンタルサーバー・クラウド事業者）：システムが動く場所を貸している会社
- ドメインの登録事業者：「〇〇.co.jp」などの住所の管理を取り次ぐ会社
サーバー会社がどこまで面倒を見るかは、プランによって大きく違います。レンタルサーバーなら土台のOS（＝サーバーを動かす基本ソフト）の更新はサーバー会社がやってくれることが多い一方、クラウドを借りて自由に構成している場合は、OSの更新も利用者側の仕事になることがあります。
理由3：担当者の異動・退職で「知っている人」がいなくなる
公開当時の担当者が異動・退職すると、「管理画面のパスワードを誰が持っているか」「ドメインの更新案内がどのメールアドレスに届くか」が分からなくなります。WordPressのサイトで「誰が更新しているのか分からない」という状態は、多くがここから生まれます。
IPA（情報処理推進機構）は、ウェブサイトを安全に運用するためのチェックポイントの中で、ソフトウェアの脆弱性対策やログの確認に加えて、クラウドなどのサービスを使う場合には責任範囲を把握して必要な対策をとることを挙げています。
📰 出典：IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」
つまり「誰がどこまでやるか」を把握すること自体が、セキュリティ対策の一部だということです。
公開後に発生する主な作業と役割分担表の例
公開後に発生する作業を一覧にし、発注者・開発会社・サーバー会社の役割分担の例を表にしました。
表の記号は次の意味です。
- 実：実際に作業する（手を動かす）
- 決：実施の判断・承認をする、結果を確認する（最終責任を持つ）
- 相：相談を受ける、情報を提供する
- 知：結果の報告を受ける
| 作業 | 内容（ひとことで） | 発注者 | 開発会社 | サーバー会社 |
|---|---|---|---|---|
| OS・ミドルウェアの更新 | サーバーの土台のソフトを新しくする | 知 | 相 | 実（レンタルサーバーの場合） |
| CMS・プラグインの更新 | WordPress本体や追加機能を新しくする | 決 | 実 | ― |
| SSL証明書の更新 | 「https」の鍵マークの証明書を期限前に更新する | 決 | 実 or 相 | 実（自動更新の場合） |
| ドメインの更新 | 「〇〇.co.jp」の利用料を払い続ける | 実・決 | 相 | ― |
| バックアップ | 元に戻せるようにデータを保存しておく | 決 | 実 | 実（自動バックアップがある場合） |
| 死活監視 | サイトが止まっていないか自動で見張る | 知 | 実 | 実（プランによる） |
| 脆弱性情報の確認 | 使っているソフトの弱点が見つかっていないか調べる | 知 | 実 | 相 |
| ログの保管・確認 | アクセスや操作の記録を残し、異常がないか見る | 決 | 実 | 実（保管のみの場合も） |
| 障害時の対応・連絡 | 止まったときに原因を調べて復旧する | 決 | 実 | 相 |
| 問い合わせ対応 | サイト経由の問い合わせに答える | 実 | ― | ― |
| コンテンツ更新 | お知らせ・商品情報などを書き換える | 実 or 決 | 実（依頼時） | ― |
| アカウントの管理 | 管理画面に入れる人を追加・削除する | 決 | 実 or 相 | ― |
これはあくまで一例で、実際の分け方は契約やサーバーのプランによって変わります。ただ、表を眺めると分かるとおり、「決」の多くは発注者に残ります。作業を外部に任せても、「いつ、何が行われたか」を把握して判断する役割までは任せきれないからです。
「ドメインの更新」は発注者が持つのがおすすめ
ドメインは会社の住所のようなもので、更新を忘れると期限切れでサイトやメールが使えなくなるおそれがあります。登録事業者のアカウントや更新案内の届け先は、開発会社の担当者個人ではなく、自社の共有メールアドレスにしておくと、担当者が変わっても困りません。
SSL証明書は「更新の頻度が上がる」ことを前提に
SSL証明書（＝通信を暗号化し、サイトの持ち主を証明する電子的な証明書）には有効期限があります。フィッシング対策協議会の解説によると、業界団体の決定により、証明書の最大有効期間は2026年3月15日以降に発行されるものから200日に短くなり、2027年3月15日以降は100日、2029年3月15日以降は47日へと段階的に短縮されます。
📰 出典：フィッシング対策協議会「SSL/TLSサーバー証明書の有効期間短縮化について」
同協議会は、手作業での更新は失敗やサービス停止のリスクがあるとして、更新の自動化の重要性を指摘しています。「年に1回、担当者が手で更新している」という運用なら、自動更新にできるかどうかを開発会社やサーバー会社に確認しておきましょう。
技術に詳しくなくてもできる「今の状態」の確かめ方
役割分担表を作る前に、まず今の状態を確かめます。技術的な知識は不要です。
ステップ1：契約書と請求書を集める
開発会社との保守契約、サーバー会社・ドメイン登録事業者からの請求書（またはクレジットカードの明細）を集めます。「誰に毎月（毎年）お金を払っているか」を見れば、誰が何を担当しているかの手がかりになります。保守費用の中身の読み解き方は、次の記事で詳しく解説しています。
システムの保守費用は何に払っている？月額保守費の内訳と見直す前に確認したいこと
ステップ2：管理画面に「入れる人」を確認する
WordPressの場合、管理者のアカウントを持っている人に、管理画面の「ユーザー」一覧を見せてもらいます。確認するのは次の3点です。
- 管理者の権限を持つアカウントは何個あり、それぞれ誰のものか
- すでに退職した人や、取引が終わった会社のアカウントが残っていないか
- 自社の中に、管理者として入れる人が少なくとも1人いるか
IPAのチェックポイントでも、不要なアカウントが登録されていないかは確認項目の1つになっています。
ステップ3：WordPressが最新版かどうかを確認する
WordPressの公式ドキュメントでは、常に最新版に更新することを勧めています。新しいバージョンがあると、管理画面に更新のお知らせが表示され、「ダッシュボード」の「更新」画面で状況を確認できます。プラグイン（＝WordPressに機能を追加する部品）やテーマ（＝デザインのひな形）に更新があるときも、管理画面のメニューに通知が表示されます。
📰 出典：WordPress.org「Updating WordPress」
発注者がやることは、この画面に更新待ちが何件たまっているかを見るだけで十分です。更新によって表示が崩れることもあるため（次のステップで触れます）、更新ボタンを押すかどうかは担当者と相談してからにしましょう。
ステップ4：「自動で更新されているもの」を確認する
WordPressは、小さな修正やセキュリティの更新を自動で適用できる仕組みを持っています（大きな機能追加の更新は手動）。また、プラグインやテーマも、1つずつ自動更新をオンにできます。自動更新が行われると、サイトの管理者宛てにメールで通知されるのが初期設定です。
📰 出典：WordPress.org「Plugin and themes auto-updates」
ここで確認したいのは、その通知メールが誰に届いているかです。辞めた担当者や開発会社の個人アドレスに届いていると、自動更新の失敗に誰も気づけません。一方、自動更新は便利ですが、更新によって表示が崩れることもあります。公式ドキュメントも、自動更新をオンにする前に、元に戻せる状態（バックアップ）を用意しておくよう勧めています。
保守契約・運用手順書に書いておきたいこと
現状が分かったら、役割分担を文書に残します。開発会社と保守契約を結ぶ（見直す）場合も、社内で運用する場合も、次の項目を押さえておくと安心です。
| 項目 | 書いておく内容の例 |
|---|---|
| 対象範囲 | どのサイト・システムか、WordPress本体・プラグイン・サーバーのどこまでを含むか |
| 更新の頻度とタイミング | 定期更新は月1回、緊急のセキュリティ更新は連絡のうえ速やかに、など |
| 更新前後の確認 | 更新前にバックアップを取る、更新後に主要なページ・フォームを確認する |
| 報告の方法 | 実施日・更新した内容・確認結果を毎月メールで報告する |
| 監視と連絡 | 停止を検知したら誰に何分以内に連絡するか、夜間・休日はどうするか |
| 含まれない作業 | 大きな改修、プラグインの入れ替え、コンテンツの更新などは別見積もり |
| アカウントと資料 | 管理者アカウント・ドメイン・サーバーの契約名義は発注者、など |
契約の条文そのものは、弁護士など専門家に確認したうえで決めてください。ここで大切なのは、表の「決」にあたる部分——報告を受け取る人と、緊急時に判断する人の名前を、発注者側で決めておくことです。
運用手順書は「A4で1〜2枚」から始める
運用手順書というと大げさに聞こえますが、最初は次の内容をまとめた1〜2枚のメモで十分です。
- 関係者の一覧（会社名・窓口・連絡先・契約の種類）
- 上の役割分担表
- 管理画面・サーバー・ドメインの管理者が誰か（パスワード自体は書かず、保管場所だけ書く）
- 期限のあるもの（ドメイン・SSL証明書・サーバー契約）の更新月
- サイトが止まったときに最初に連絡する先
保守契約がないサイトの「最低限の運用プラン」
「保守契約は結んでいない」「予算の都合ですぐには結べない」というサイトもあるでしょう。その場合でも、次の最低限のプランを回すだけで、放置よりずっと安全になります。
| 頻度 | やること | 担当の例 |
|---|---|---|
| 毎月 | 管理画面で更新待ちの件数を確認し、たまっていれば対応を依頼する | 自社の担当者 |
| 毎月 | バックアップが取れているか確認する（サーバーの自動バックアップ機能など） | 自社の担当者 |
| 緊急時 | WordPressなどの重大な脆弱性のニュースを見たら、スポットで更新を依頼する | 自社の担当者 → 開発会社など |
| 半年ごと | 管理者アカウントの棚卸し（退職者・不要なアカウントの削除） | 自社の担当者 |
| 年1回 | ドメイン・SSL証明書・サーバー契約の期限と自動更新の設定を確認する | 自社の担当者 |
更新作業そのものに不安があれば、スポット（単発）での作業依頼ができるか、開発会社やサーバー会社に相談してみてください。また、使っていないプラグインや、もう公開する必要のないページが残っていれば、削除を検討しましょう。IPAのチェックポイントでも、不要になったページやサイトを公開したままにしないことが挙げられています。
公開後の運用でやりがちな失敗
- 「保守費を払っているから全部やってくれている」と思い込む：契約の範囲にWordPressの更新が含まれていないこともあります。報告がないなら、一度内容を確認しましょう
- ドメインやサーバーを開発会社の名義のままにしている：取引が終わったときに手続きが複雑になりがちです。名義や管理者を確認しておきましょう
- 更新ボタンを自己判断で押してしまう：バックアップなしで更新して表示が崩れると、元に戻すのに手間がかかります。まず担当者に相談を
- 通知メールの届け先が個人のアドレス：担当者が変わると、期限切れや更新失敗の通知に誰も気づけなくなります
発注者がやることチェックリスト
- ☐ 開発会社・サーバー会社・ドメイン登録事業者との契約書と請求書を集めた
- ☐ 公開後の作業について、役割分担表（実・決・相・知）を作った
- ☐ 管理画面の管理者アカウントを確認し、不要なアカウントの削除を依頼した
- ☐ 自社に管理者として入れる人を少なくとも1人確保した
- ☐ WordPressの更新待ちの件数と、自動更新の通知メールの届け先を確認した
- ☐ ドメイン・SSL証明書・サーバー契約の更新月と、自動更新の有無を確認した
- ☐ 報告を受け取る人と、緊急時に判断する人を社内で決めた
- ☐ 関係者と役割を1〜2枚の運用手順書にまとめた
開発会社への質問例
- 「今の保守契約では、WordPress本体・プラグイン・サーバーの更新のうち、どこまでが含まれていますか？」
- 「更新や監視の作業は、どのくらいの頻度で行い、結果をどのように報告してもらえますか？」
- 「サーバー会社側でやってくれている作業（OSの更新・バックアップなど）と、御社がやる作業の境目を教えてください」
- 「重大な脆弱性が見つかったとき、こちらへの連絡と更新はどのような流れになりますか？」
- 「保守契約を結ばない場合、スポットでの更新作業や、こちらで最低限やっておくべきことを教えてください」
まとめ：公開後の運用は「役割分担表」と「決める人」から始める
公開後のアップデートや監視は、開発会社・サーバー会社・自社の誰か1社がすべてを担うものではありません。大切なのは次の3つです。
- 公開後の作業を一覧にし、「誰が手を動かし、誰が確認して決めるか」を表にする
- 契約書・請求書・管理画面から、今の状態（誰が入れるか、最新版か、期限はいつか）を確かめる
- 保守契約や運用手順書に、範囲・頻度・報告・緊急時の連絡を書いておく
保守契約がなくても、毎月の確認と年1回の期限チェックから始めれば十分な一歩になります。まずは手元の請求書を集め、役割分担表の空欄を埋めるところから始めてみてください。
あわせて読みたい関連記事
