
目次
はじめに
社内でホームページ(Webサイト)の保守管理をする場合、「更新ができれば十分」と思っていたのに、ある日突然「表示されない」「警告が出る」「ログインできない」といったトラブルに直面したというWEB担当者の方もいらっしゃるのではないでしょうか。
外注していたときは制作会社が裏側でおこなっていてくれていた作業が、内製化した瞬間に自分たちの責任範囲になります。
保守管理での「最低限必要なスキル」は、難しい開発ができることではなく、止まらない・壊れない・漏れない状態を保ち、もし起きても戻せる状態にするための実務スキルです。
本記事では、社内でホームページの保守管理をおこなうために最低限必要なスキルはどのようなスキルかを分かりやすくご説明したいと思います。
「最低限のスキル」は「復旧できるスキル」
社内保守で一番怖いのは、トラブルが起きたときに「どこを触れば戻るのか」「戻せるバックアップがあるのか」が分からない状態です。
WordPress公式も、データベースは定期的に、そしてアップグレード前には必ずバックアップするよう求めています。
逆に言えば、バックアップと復元手順が手元にあり、期限切れや更新漏れを防げる運用があれば、最低限はかなりの部分を満たせます。
保守は属人化しやすいので、「詳しい人が一人でやる」としていると、その人の異動や退職で一気に破綻してしまうことがあります。
最初から、誰が・どこまで・どんな手順でを決め、外部に頼る境界線も含めて運用にしておくのがよいでしょう。
保守管理で守るべき範囲
社内保守を始める前に、保守管理として必要な作業を整理しておくと、どのようなスキルが必要なのかが分かりやすくなります。
特に「運用(更新・改善)」と「保守(安定稼働・安全性)」が混ざると混乱してきますので、まずは「運用」と「保守」の違いをご説明します。
運用と保守の違い
運用は「より良くするための作業」、保守は「ちゃんと動き続けるための作業」です。
どちらも大切ですが、最低限スキルを考えるときは、まず保守側(安定稼働・安全・復旧)の作業が必要になります。
| 観点 | 運用(例) | 保守管理(例) | 失敗すると |
|---|---|---|---|
| 目的 | 集客・問い合わせ増、情報発信 | 安定稼働、安全、復旧性 | 404/表示崩れ、改ざん、停止、信用低下 |
| 主な作業 | 記事更新、導線改善、SEO改善 | 更新(アップデート)、バックアップ、権限管理、期限管理、障害対応 | サイト停止、情報漏えい、警告表示 |
| 頻度 | 週次〜日次 | 週次〜月次+緊急対応 | “ある日突然”が起きやすい |
(※「運用」と「保守」の違いに関しましては『ホームページの「運用」と「保守」は何が違いますか?』のページで詳しくご説明していますので、ご参照ください。)
保守の対象は「中身」と「土台」に分かれる
保守で見ている対象は、大きく分けて「サイトの中身(CMSやプラグイン等)」と「土台(サーバー・ドメイン・SSL・DNS)」です。
土台は普段意識していないことが多いと思いますが、期限切れや設定ミスがあった場合、一気に止まりますので注意が必要です。
例えば、JPドメインは、JPRSのルール上、登録日の1年後の月末が有効期限として設定される仕組みになっており、期限という概念自体を運用に組み込む必要があります。
社内で出来るようにする作業
社内で保守するなら、「更新しても壊さない」だけでなく、「壊れたら戻す」「期限を切らさない」「不正ログインを防ぐ」といった作業が出来ることが必須になります。
特にDNS(ネームサーバ)の設定は、誤りがあると接続性に影響が出たりメールが失われたりする可能性があり、JPNICも設定内容の誤りによる影響は設定依頼者側の責任になる旨を明記しています。(※参考:IPv4ネットワークにおけるドメインネームサーバの設定手続きについて(IPアドレス管理指定事業者用))
最低限必要な5つのスキル
「最低限」を実務に落とすために、スキルをできることのチェックとして定義しておくと、社内教育や採用要件も作りやすくなります。
ここでは、保守に必要な5つのスキルと「最低限できてほしい状態」をご紹介します。
| スキル | 最低限できてほしい状態 | 典型作業 | 公式・一次情報の根拠 |
|---|---|---|---|
| バックアップ/復元 | 定期バックアップがあり、アップグレード前にも取得し、復元手順が分かる | DB/ファイルのバックアップ、復元テスト | WordPressはDBを定期的に、アップグレード前にも常にバックアップを推奨。 |
| アップデート運用 | 更新の重要性を理解し、更新後の確認ができる(自動更新の扱い含む) | コア/プラグイン更新、更新後の動作確認 | WordPressは自動更新を“最新かつ安全に保つ方法の一つ”として、無効化を強く非推奨。 |
| アカウント・認証管理 | 長く複雑で使い回さないパスワード+多要素認証を基本にできる | 権限設計、退職者アカウント削除、MFA設定 | IPAは長く複雑で使い回さないパスワード、多要素認証を推奨。 |
| インフラ期限管理(ドメイン/SSL/DNS) | 期限と更新方法を把握し、更新失敗に気づける | ドメイン更新、証明書更新、DNS変更時の影響把握 | JPドメインは有効期限が設定される。/Let’s Encryptは90日有効で自動更新を推奨、今後短縮予定。 |
| 最低限のセキュリティ判断 | パッチを速やかに適用の判断ができ、不要公開を減らせる | 脆弱性対応、管理画面の公開範囲見直し | IPAは対策として脆弱性対策済みパッチを速やかに適用などを挙げる。 |
この表の「最低限できてほしい状態」にすることで、社内で保守をおこなう最低限の環境がととのうイメージです。
逆に、どれかが欠ける場合は、そこだけ外注する(あるいは最初から外注前提にする)という判断も必要かと思います。
更新作業を安全に行う習慣
日々の更新で求められるのは、凝った実装力よりも「公開してよい状態かの確認力」です。
WordPressなどのCMS運用では、更新そのものは画面操作でできますが、更新後に以下のような点を確認する習慣にしておくと大きなトラブルになりにくくなります。
- 表示が崩れていないか
- フォームが動くか
- リンクが切れていないか
また、更新が怖くて止めてしまうと、逆にセキュリティ面で危険が増えます。
保守では、見た目の修正よりも、脆弱性に直結するシステムの「更新」が重要です。
WordPressは自動更新をサイトを最新かつ安全に保つ方法の一つと位置づけ、無効化を強く非推奨としています。
バックアップは「取る」より「戻せる」が重要
バックアップがあっても、いざというときに戻せないと意味がありません。
WordPress公式でも、データベースを定期的に、そしてアップグレード前には常にバックアップするよう推奨しています。
「復元テストを一度やっておく」を足すだけで、社内保守の安心感が段違いになります。
バックアップの保管方法は、IPAが紹介する「3-2-1ルール」(データを3つ、2種類の媒体、1つはオフサイト)が分かりやすい基準です。
サイトのバックアップでも、「サーバーの中だけに置く」状態だと、サーバー障害や侵害時に一緒に失われる可能性があるため、保管場所の分離はできるだけ早い段階で取り入れたいところです。
アカウント管理とセキュリティの基本
社内保守で最初に整えるべきセキュリティは、難しいツール導入よりも「認証と権限」です。
IPAは不正ログイン対策として、推測されにくい長いパスワード、使い回しをしないことに加え、多要素認証の設定を推奨しています。
実務としては、管理者権限を必要最小限にし、退職・異動時にアカウントを確実に無効化できる運用にしておくと、事故の多くを未然に防げます。
安全に保守管理をするための手順と体制
必要なスキルを揃えたら、次に必要なのが「運用の形」です。
社内保守は、正しい手順があるだけでトラブルが激減しますし、いざというときも落ち着いて戻すことができます。
社内の役割分担
社内で全部を一人に背負わせると、更新が止まるか、事故が起きるかのどちらかになりがちです。
現実的には、更新(中身)と土台(インフラ・認証・復旧)を分け、少なくとも二重化しておくと安心です。
特にサーバー・ドメイン・SSL・DNSといった土台側は触れる人を限定し、手順化するのが安全です。
「変更」する際の基本手順
更新や設定変更は、手順が逆になるだけで事故が増えます。
おすすめは「バックアップ→変更→確認→記録」の流れを崩さないことです。
WordPressはアップグレード前のバックアップを推奨しています。
また、自動更新を使う場合でも、更新後に不具合が起きたときに戻せるよう、バックアップと復旧手順が前提になります。
月次点検のルール
点検は気が向いたらだと必ず抜けます。
表にして担当と頻度をルール化すると、兼務でも回りやすくなります。
| 点検項目 | 目安頻度 | 具体的に見るもの | 根拠になる考え方 |
|---|---|---|---|
| バックアップが取れている | 週1〜月1 | 直近のバックアップ日時、保存先(オフサイト含む) | IPAは定期バックアップと3-2-1ルールを紹介。 |
| アップデート状況 | 月1 | コア/プラグイン/テーマ更新の有無、更新後の表示確認 | WordPressは自動更新を安全維持に有効とし無効化を強く非推奨。 |
| 管理者アカウント | 月1 | 不要アカウント削除、権限過多の見直し、MFA | IPAは長いパスワードと多要素認証を推奨。 |
| ドメイン期限 | 月1 | 管理画面で期限確認、更新通知の受信先確認 | JPドメインの期限(ライフサイクル)を理解して運用に組み込む。 |
| SSL証明書期限 | 月1 | 有効期限、更新の自動化、更新失敗の検知 | Let’s Encryptは90日有効で更新自動化を推奨、今後短縮予定。 |
社内対応と外注の境界線
内製化の満足度は、「社内で全部やれる」よりも「社内でやるべきことが滞りなく回り、危ないところだけ外部に頼める」状態で上がります。
判断のポイントは、失敗したときの影響と、復旧までに許される時間です。
内製で回しやすい領域
社内で回しやすいのは、手順化でき、失敗しても影響が限定されやすい領域です。
たとえば更新作業、軽微な文言修正、画像差し替え、月次点検、期限確認などは、手順とバックアップがあれば内製向きです。
WordPressのバックアップ推奨や、IPAの認証・バックアップの基本に沿って運用できるなら、十分現実的です。
外注を検討したい領域
外注を検討したいのは、失敗時の影響が大きい領域です。
代表例は「改ざん・マルウェア疑い」「サーバー移行」「大規模なテーマ改修」「DNSの大きな変更」などで、復旧の判断が遅れると被害が拡大しやすいです。
また、脆弱性への対応は速やかにパッチ適用が基本姿勢になるため、社内で追い切れない場合は外部の支援が安全です。
仕分け表
| タスク | 失敗時の影響 | 社内でやる条件 | 外注推奨の目安 |
|---|---|---|---|
| プラグイン/コア更新 | 表示崩れ〜侵害リスク | バックアップ+動作確認ができる | 更新後の障害対応に不安がある |
| バックアップ運用 | 復旧不能 | オフサイト保管+復元手順あり | 復元手順がない/担当が固定できない |
| SSL更新 | 警告表示・閲覧不能 | 自動更新+失敗検知がある | 手動更新で回している/監視がない |
| DNS変更 | サイト・メール影響 | 手順化+影響範囲が分かる | 影響範囲が読めない/担当が不在 |
| 改ざん疑い対応 | 情報漏えい・信用失墜 | 連絡体制と切り分け手順がある | 原因調査や封じ込めができない |
まとめ
社内でホームページの保守管理をするための「最低限必要なスキル」は、作れる・直せるといった制作力よりも、安全に更新し、期限を切らさず、もしものときに戻せるという運用力に寄っています。
WordPressがアップグレード前のバックアップを推奨していることや、IPAが不正ログイン対策として長いパスワードと多要素認証を推奨していることは、その方向性を裏付けています。
最低限の保守管理のスキルは以下の5つです。
- バックアップと復元
- アップデート運用
- 認証と権限
- ドメイン/SSL/DNSの期限管理
- 脆弱性対応の判断
まずは「月次点検表」を作り、バックアップの保管先と復元手順を紙1枚にしておくと、内製化の不安がかなり減ります。
社内で抱え切れない部分は外注の委託も含めて、安心して自社のサイトが運営できるようにしましょう。
お問い合わせはこちら

当社ではホームページの制作と管理をおこなっています。
ホームページの管理費は月額換算で3,300円です(年払い税込39,600円)。
ホームページの管理をさせて頂いているお客様には、ブログ記事の書き方に関するご相談なども受けております。
これから作るホームページの制作、現在お持ちのホームページのリニューアルや保守管理に関してなど、ホームページに関することはなんでもお気軽にご相談ください。


