WordPress保守契約とSLAが経営課題になる理由

「止まる」「漏れる」「更新できない」は事業リスクとして扱う

WordPress＝CMS（CMS＝Webサイトのコンテンツを管理・更新する仕組み）の一種で、更新の容易さと引き換えに、継続的な運用が前提になります。
経営判断として重要なのは、サイト障害が「IT部門のトラブル」ではなく、売上・問い合わせ・採用の機会損失と、信用毀損（問い合わせ停止、応募離脱、取引先の不安）に直結する点です。みやあじよが制作を「問題解決」と位置づけるのと同様に、保守も“目的達成を止めないための仕組み”として設計すると、費用対効果の議論が整理しやすくなります。

もう一段、経営視点で厳しいのが「原因が複合しやすい」ことです。例えば、更新の先送り→脆弱性の放置→不正侵入→改ざん、のように、単発のミスが連鎖して大きな損失に変わります。脆弱性＝攻撃者に悪用され得る弱点です。逆に言うと、保守でやるべきことを分解しておけば、連鎖のどこかで止められます。

SLAは「できる／できない」を曖昧にしないための合意

SLA＝サービスの提供水準を、指標と条件で合意する取り決めです。
保守契約だけだと、「対応します」という文言が広くなりがちで、緊急時に“どこまで・いつまで・何を優先するか”が揉めやすくなります。特に、個人情報を扱うサイトでは、初動の遅れや判断の遅れが二次被害につながるため、SLAで初動・復旧・報告の基準を言語化しておくことが、リスクとコストの両方を抑える近道です。

SLAが効く場面は障害だけではありません。更新作業の事前検証や、バックアップの復元テストなど「平時にやると後回しになりやすい作業」も、SLAの対象として実施頻度と完了条件を合意すると、属人的な頑張りに依存しない運用になります。

属人化は、コストより先に「時間」と「判断」を奪う

属人化＝特定の担当者しか状況を把握しておらず、他の人が代替できない状態です。
「詳しい人が1人いるから大丈夫」は平時は低コストに見えますが、休暇・退職・兼務の逼迫で一気に回らなくなります。さらに深刻なのは、緊急時に判断材料が揃わないことです。
例として、どこにバックアップがあり、どう戻し、誰が承認するのかが曖昧だと、復旧の手前で止まります。経営者・情シス責任者が見たいのは担当者の努力ではなく、誰が変わっても回る運用の再現性です。保守契約とSLAは、その再現性を外部と共同で作るための枠組みになります。

保守契約の守備範囲を決める（監視／更新管理／バックアップ／復旧／セキュリティ対応）

「保守＝更新」だけだと、事故は防げない

保守で本当に差が出るのは、障害が起きた後ではなく“起きる前”と“起きた直後”です。更新作業は重要ですが、それ単体では、改ざん・不正ログイン・サーバ障害・設定ミスなどの発見が遅れます。
経営としては、まず守備範囲を分解し、どこを外部に任せ、どこを社内に残すかを決めるのが出発点です。外部ベンダー管理担当がいる場合も、守備範囲が整理されていないと、見積比較が金額だけになり、必要な作業が抜け落ちます。

検証環境＝本番同等で変更を試すテスト環境です。SSL証明書＝通信を暗号化し正当性を示す証明書です。WAF＝Webへの攻撃を検知・遮断する仕組みです。ログ＝操作の記録です。

保守契約で定義すべき対応範囲の一覧

項目	具体作業例	期待できる効果	契約時の確認ポイント
監視	稼働確認、通知設計	早期発見、初動の短縮	監視対象（サイト表示、データ保存、証明書期限等）、通知先、監視頻度
更新管理	WordPress更新、外観と拡張機能の更新、事前検証	脆弱性リスクの低減、改修の安全性	検証環境の有無、更新の頻度、元に戻す手順
バックアップ	世代を残す、保管先分離、復元確認	復旧の確実性、被害最小化	保管場所、保存期間、復元手順の文書
復旧支援	原因の特定、復元、一時的な回避	停止時間の短縮、再発防止	連絡手段、対応時間帯、復旧の優先順位
セキュリティ対応	権限設定、WAF設定、ログ確認	侵入抑止、検知、記録の確保	対象範囲、記録の保存、事故時の動き

監視：通知が鳴っても動けないなら意味がない

監視を設計するときは「何を監視するか」より先に「誰が、どの連絡手段で、何をもって着手とするか」を決めます。
SSL証明書の期限切れのように、予兆が事前に分かるものは、通知タイミングを早めるだけで事故を避けられます。一方で、深夜に通知が鳴る体制がないなら、24時間監視の価値は限定的です。監視と対応時間帯はセットで設計します。

更新管理：目的は「最新にすること」ではなく「壊さずに続けること」

更新はセキュリティの入口ですが、経営が気にすべきは「更新で止まる」リスクです。検証環境があると、更新による不具合を事前に潰せます。
また、更新対象を全て同じ扱いにしないことも重要です。例えば、緊急性の高い更新と、機能追加に近い更新を分け、承認フローや実施タイミングを変えると、現場の心理的負担が減り、更新が滞りにくくなります。

バックアップと復旧：復元テストがないと保険にならない

バックアップは「取得頻度」だけでなく「保管の分離」と「復元の手順」が価値を決めます。
保管先分離とは、サイトと同じサーバ内だけに置かず、別の場所にも保存することです。復元テストとは、実際に戻せるかを定期的に確認することです。ここまで合意しておくと、障害時に復旧できるかどうかの不安が減り、意思決定が速くなります。

セキュリティ対応：入口は「権限」と「ログ」

WAFの有無だけで安全が決まるわけではなく、管理画面の権限設定、アカウントの棚卸し、ログの確認が基礎になります。
個人情報を扱う企業ほど、事故が起きた後の説明責任が重くなります。だからこそ、契約で「誰が記録を確保し、どの形式で報告するか」まで決めておくと、経営判断の材料が揃います。

守備範囲を決めるときの実務ポイント

1つ目は「対象の明確化」です。例えば監視なら、サイト表示だけでなく、期限管理（証明書、サイトの住所）や管理画面への不審アクセスなど、何を異常と見なすかで実効性が変わります。
2つ目は「復旧可能性の担保」です。バックアップは“取得している”だけでは足りず、復元手順が文書化され、復元テストが行われて初めて投資価値が出ます。
3つ目は「変更管理」です。更新・改修のたびに品質が揺れると、現場は更新を避け、結果として脆弱性が溜まります。申請→作業→検証→反映→記録の流れを、外部ベンダー管理担当でも追える形に整えると、属人化が減り、経営報告もしやすくなります。

SLAで合意すべき指標と条件（対応時間・復旧方針・対象範囲・免責の考え方）

SLAは「時間」だけでなく「対象」「手順」「成果物」まで合意する

SLA＝サービスの提供水準を、指標と条件で合意する取り決めです。ここで言う指標は「何分で返事が来るか」だけでは足りません。経営としては、次の4点がセットになって初めて“実運用で効くSLA”になります。

• 対象：どの範囲を守るか（サイト表示、管理画面、送信フォーム、保存データなど）
• 時間：初動・暫定復旧・恒久対応の考え方（時間帯や休日条件も含む）
• 手順：連絡経路、優先度判断、復旧の順番、記録の残し方
• 成果物：報告（いつ、何を、どの粒度で）と、再発防止の提案

初動＝連絡を受けた後に、原因切り分けや復旧に着手すること。暫定復旧＝完全解決の前に、事業影響を抑えて最低限の機能を回復させること。恒久対応＝原因を除去し再発しにくい状態に戻すことです。
また、記録＝後から確認できる証跡のことで、事故対応の説明責任を支える材料になります。

優先度設計は「全部を緊急」にしないことがポイント

優先度＝対応の順番と深さを決める区分です。優先度が曖昧だと、軽微な不具合に作業時間を消費し、本当に止めてはいけない箇所の復旧が遅れます。個人情報を扱う企業では、判断基準に「漏えいの疑い」「改ざんの疑い」「フォーム停止」「トップページ表示不可」などを入れ、経営・情シス・外部の誰が判断するかまで決めておくと混乱が減ります。

指標の例はRTO/RPOと「報告の速さ」

RTO＝目標復旧時間（どれくらいの時間で事業を再開させるかの目標）です。RPO＝目標復旧時点（どこまでの時点のデータに戻せれば許容できるかの目標）です。
この2つは、バックアップ設計と復旧手順に直結します。さらに、経営判断に効くのが「報告の速さ」です。状況が不明な時間が長いほど、社内の判断が止まり、二次対応（問い合わせ対応、採用応募の案内、取引先説明）も遅れます。

SLAで合意する指標・条件のひな形

ドメイン＝サイトの住所です。拡張機能（プラグイン）＝サイトの機能を追加する部品です。

対象シーン	合意する指標	合意の書き方（段階）	注意点
サイトが表示できない	初動開始／暫定復旧／原因報告	受付時間内は優先対応、時間外は翌営業日扱い等	サーバ提供側の障害は「連携対応」になる場合を明記
不正ログイン・改ざんの疑い	被害拡大防止の判断／記録確保／復旧方針	緊急枠として扱う、関係者への連絡手順を固定	ログ保存期間と、報告フォーマットを決める
更新後に不具合が発生	戻し方の判断／復旧／再発防止	検証→本番の順、失敗時は直近の安定版へ戻す	検証環境の有無で実現可能な水準が変わる
証明書・ドメイン期限	期限監視／更新実施／完了報告	期限前に通知、承認後に更新、完了を報告	権限（管理者アカウント）の所在を明確化

免責と前提条件は「揉めないため」ではなく「止めないため」に決める

免責＝当事者が責任を負わない範囲のことです。免責は対立のためではなく、緊急時の判断を早めるために使います。
例えば、サーバ提供側の障害・外部サービス障害・第三者提供の拡張機能不具合など、外部要因が絡むと復旧の主導権が分散します。そのとき「どこまでが契約範囲で、どこからが連携対応か」が曖昧だと、社内の意思決定が止まります。SLAには、外部要因時の連絡・切り分け・暫定回避の範囲を明記しておくのが実務的です。

費用の考え方（料金の内訳・見積比較・コストが増えるポイント）

月額の中身は「待機コスト」と「運用コスト」に分けて見る

保守費用は、作業そのものだけでなく「すぐ動ける体制」を確保する待機コストが含まれます。
待機コストが小さい契約は、初動が遅い・対応時間帯が限定的・復旧がベストエフォート（ベストエフォート＝可能な範囲で対応するが達成を約束しない提供形態）になりやすい傾向があります。逆に、SLAで水準を上げるほど、体制維持分が費用に反映されます。

費用が上がりやすい要素を先に把握しておく

• 対応時間帯：夜間・休日対応、連絡を受け付ける窓口の有無
• 監視の深さ：表示監視だけか、異常検知の範囲を広げるか
• 検証環境：更新や修正を安全に行うための環境維持
• 復旧要件：RTO/RPOを厳しくするほど、バックアップ設計が重くなる
• セキュリティ運用：ログ確認、権限管理、ルール整備、報告の作成

見積比較はTCOとリスク低減の両面で行う

TCO＝導入後の運用費も含めた総コストです。月額だけで比べると、障害対応の追加費用、復旧にかかる社内負担、停止の影響などが見えなくなります。
比較の軸は「何が含まれているか」「含まれない場合に誰がやるか」「緊急時の初動と復旧はどうなるか」の3点に集約できます。ここが整理されると、保守費用は“固定費”ではなく“事業継続のための保険＋運用の外部化”として説明しやすくなります。

契約形態は3パターンを理解しておく

• 定額中心：監視・更新・バックアップ・軽微対応まで含める（範囲と上限条件が重要）
• 定額＋従量：基礎運用は定額、障害・修正は別見積（追加費用の発生条件を明確に）
• 監視・バックアップ分離：最低限を固定し、更新・改善は運用計画として別枠化（管理しやすいが設計が必要）

体制と進め方（社内役割分担・外部ベンダー管理・運用フロー・報告）

決めるべきは「誰が承認し、誰が実行し、誰に報告するか」

保守の失敗は、技術よりも意思決定の停滞で起きやすいのが実情です。緊急時に止まりやすいポイントは「権限がない」「承認が取れない」「連絡先が分からない」です。
社内は最小でも、経営（優先度とコスト判断）、情シス（システム前提と権限管理）、Web担当（要件とコンテンツ影響）、外部（実作業と報告）の役割を分け、連絡経路を一本化すると運用が安定します。

運用を止めないための情報（ドキュメント）を整備する

ドキュメント＝運用に必要な情報を、誰が見ても分かる形で残した資料です。最低限、次を揃えると属人化が下がります。

• 管理対象一覧（サイト、サーバ、ドメイン、メール送信等）
• 管理者アカウントと権限の管理方法（退職・異動時の手順含む）
• バックアップの保管先と復元手順
• 連絡網（緊急時の電話、平時のメールや依頼管理など）
• 変更履歴（更新・修正の実施日、影響範囲、戻し方）

月次報告は「安心材料」と「改善材料」に分ける

経営が読みやすい報告は、良いニュースと改善点が混ざっていません。
安心材料：稼働状況、重大障害の有無、セキュリティ上の重要イベントの有無。改善材料：更新計画の進捗、指摘事項、次月の運用提案。こう分けると、保守が“やっている感”ではなく、意思決定に使える情報になります。

リスクとトラブル時の論点（改ざん・停止・更新失敗・バックアップからの復旧）

インシデント対応は「封じ込め→復旧→再発防止」を契約に落とす

インシデント＝セキュリティや運用上の事故、または事故につながる兆候のことです。
実務で止まりやすいのは、技術よりも「判断待ち」「連絡迷子」「証跡不足」です。SLAと運用手順で、次の3点を先に固定すると、被害が拡大しにくくなります。

• 封じ込め：一時停止・遮断・権限停止など、拡大を止める暫定措置
• 復旧：いつの時点に戻すか（RPO）と、どこまで戻せば業務再開か（RTO）
• 再発防止：原因の特定と、次に同じ経路を通らせない対策

エスカレーション＝対応が難しい場合に、意思決定者や専門担当へ引き継ぐことです。エスカレーションの条件（優先度、疑いの種類、影響範囲）を決めておくと、初動の速度が安定します。

改ざん・不正侵入の疑いが出た時に決めておくこと

改ざんや不正侵入は「元に戻す」より先に「記録を残す」ことが重要です。ログや改ざん箇所の記録がないと、原因が特定できず、同じことが繰り返されます。契約上は、最低限次を合意しておくと運用が止まりにくくなります。

• 連絡の優先順位（経営・情シス・外部の順と同報のルール）
• 暫定措置（公開停止、フォーム停止、管理画面の権限停止など）の判断基準
• 記録の確保（ログの保存、改ざん箇所の控え、対応タイムライン）

対応タイムライン＝いつ何を行ったかを時系列でまとめた記録です。

サイト停止は「原因が外部でも動ける」設計にする

停止原因がサーバ側や外部サービス側にある場合、こちらが直接直せない時間が発生します。その間の価値は「状況を整理し、暫定の表示や連絡導線を用意する」ことにあります。
契約では、外部要因時に行う切り分け、連絡代行、暫定ページの設置可否までを決めておくと、問い合わせ・採用の機会損失を抑えやすくなります。

更新失敗は「戻せる前提」でしか安全に回らない

更新の失敗は、更新作業そのものより「戻し方が決まっていない」ことで長期化します。
検証環境、作業前バックアップ、切り戻し手順、影響範囲の確認ポイント（フォーム、検索、表示崩れ）をセットにし、更新を“作業”ではなく“工程”として契約に入れると、属人化が減ります。

バックアップからの復旧は「戻した後の確認」まで含める

復旧は戻した瞬間に終わりません。表示は戻っても、フォーム送信、会員機能、メール通知などが動かないケースがあります。
復旧支援の範囲に「戻した後の動作確認」と「必要な再設定」を含めると、事業側の実害が減ります。

成果とKPI設計（可視化の方法・レポート項目・改善サイクル）

KPIは「止めない」「早く戻す」「更新を滞らせない」を測る

保守の成果は、問題が起きていないほど見えづらくなります。そこで、結果指標（障害件数など）だけでなく、先行指標（予防や初動の質）をKPIに含めます。

• 安定性：重大停止の有無、監視の検知件数と対応完了
• 速度：初動開始までの時間、暫定復旧までの時間、原因報告までの時間
• 予防：更新実施の遅延数、バックアップ成功状況、復元テストの実施
• 品質：更新後の不具合件数、切り戻し発生の有無、再発防止の完了状況

月次レポートは「経営が判断できる粒度」にする

月次レポートで重要なのは、細かい作業記録ではなく、意思決定に必要な要点です。
例として「今月の重大事項」「次月のリスク」「改善提案」「追加予算が必要な理由」を固定フォーマットで出せると、保守が経営の管理対象になります。

改善サイクルは「運用→可視化→合意→実行」で回す

改善サイクル＝運用結果を可視化し、優先順位を合意して実行する繰り返しです。
保守契約とSLAは固定しつつ、改善項目（監視の強化、バックアップの見直し、権限整理など）は月次で優先順位を更新すると、現場の負荷を増やしすぎずに安全性が上がります。

契約前チェックリスト（比較観点・質問例・合意形成の進め方）

契約前に揃えるべき社内情報

比較を短時間で行うため、次の情報を先に棚卸しします。

• 管理対象（サイト、サーバ、ドメイン、メール送信、外部フォーム等）
• 個人情報の取扱い範囲（採用、問い合わせ、会員など）
• 現在の運用体制（兼務の有無、承認者、緊急連絡）
• 直近のトラブル履歴（停止、改ざん、更新失敗）

外部ベンダー向け比較チェック

比較観点	確認質問	回答の見極めポイント	証跡・納品物
監視	何をどの頻度で監視し、誰へ通知するか	監視対象と通知ルールが具体的	監視項目一覧、通知フロー
更新管理	更新の頻度と、検証・切り戻しはどうするか	工程と戻し方が決まっている	更新手順書、変更履歴
バックアップ	保管先、保存期間、復元テストの有無	分離保管と復元確認が含まれる	バックアップ設計書、復元手順
復旧支援	初動・暫定復旧・報告の扱い	SLAの水準が明文化されている	報告フォーマット、連絡網
セキュリティ	権限管理、ログ確認、事故時の動き	記録確保と再発防止まで含む	権限一覧、ログ保存方針
報告	月次で何を報告し、改善提案はあるか	経営向け要点と改善が分かれる	月次レポートサンプル
引き継ぎ	契約終了時の引き継ぎ方法	属人化を残さない設計	管理情報一式、手順書

合意形成は「水準を上げる前に優先順位を決める」

最初に全てを最高水準にすると、費用も運用負荷も上がり、長続きしにくくなります。
優先順位を「個人情報に関わる箇所」「止まると機会損失が大きい箇所」「後で改善できる箇所」に分け、段階的にSLAを引き上げる設計が、意思決定として現実的です。

まとめ

WordPressの保守契約は、更新作業だけでなく監視・バックアップ・復旧・セキュリティ運用まで含めて守備範囲を定義すると、見積比較と責任分界が明確になります。
SLAは初動・暫定復旧・報告を具体化し、属人化と判断待ちを減らすための合意です。
表のチェック観点を使って、対応範囲・手順・成果物が揃っている体制を選ぶと、止めない運用と説明可能な運用に近づきます。株式会社みやあじよでは、監視、更新管理、バックアップ設計、復旧支援、セキュリティ対策を一体で整理し、事業の目的（売上・問い合わせ・採用）を止めない運用設計を支援しています。