静的CMSの保守範囲：障害時に戻せる責任分担と点検表

静的CMSで障害が起きたときに慌てないためには、平常時から戻せる範囲を決めておきます。一般的な動的CMSに比べて攻撃面やサーバー負荷を抑えやすい構成にできても、保守対象は残ります。

静的CMSでも、記事データ、テンプレート、ビルド、配信の保守は残ります。ドメイン、SSL、フォーム、計測タグも運用対象です。外部サービス、秘密情報、バックアップまで含めて、静的だから安心と考えないことが大切です。どの層で問題が起きたら誰が見つけ、誰が戻すのかを決めておきます。

静的CMSでも記事以外の保守は残る

静的CMSでは、公開されるページが静的なHTMLやファイルとして配信されるため、動的な管理画面やデータベースを常時動かす構成より軽くできます。けれども、サイト運用に必要な周辺要素はなくなりません。

Markdownのfront matterが壊れれば一覧に出ないことがあります。テンプレートを変えれば、多くのページに影響します。フォームや通知は外部サービスとつながっている場合があります。DNSやSSLの問題が起きれば、記事本文が正しくてもサイトへ到達できません。

静的CMSの保守では、「本文を直せるか」だけでなく、「公開された状態を維持できるか」「障害時に戻せるか」まで見ます。

保守範囲は記事データから配信まで層で分ける

保守範囲は、層ごとに分けると整理しやすくなります。どの層に問題があるか分かると、担当者と復旧方法を決めやすくなります。

たとえば、記事データの層では、Markdown、front matter、画像を見ます。内部リンクと公開状態も同じ層で確認します。テンプレートの層では、記事一覧、記事詳細、ヘッダー、フッターを見ます。OGP、サイトマップ、robots指定は、検索エンジンや共有時の見え方に関わる要素として確認します。ビルドや公開の層では、生成処理、デプロイ、キャッシュ、ファイル権限を見ます。

配信の層では、ドメイン、DNS、SSL、リダイレクト、404を見ます。問い合わせや計測の層では、フォーム送信、通知、スパム対策、GA4や広告タグの発火を見ます。秘密情報の層では、APIキー、Webhook URL、環境変数、権限を扱います。

責任分担も、層ごとに置くと見落としにくくなります。記事データの異常なら、変更履歴と元ファイルが戻す材料になります。テンプレートの異常なら、変更差分とプレビューが必要です。ビルドや公開の異常なら、ログと直前の公開状態を見ます。配信の異常なら、DNS、SSL、リダイレクト、404の設定履歴を確認します。フォームや計測の異常なら、テスト手順と通知先、タグの発火条件が必要です。秘密情報の問題なら、権限管理と再発行手順まで含めて扱います。

責任表にする場合は、細かい担当名を増やすより、止まる仕事、一次担当、確認証拠、復旧元が分かることを優先します。次のように短く置くだけでも、障害時に最初に見る場所がそろいます。

この分け方の目的は、担当を細かく分けることではありません。障害が起きたときに、どこを見ればよいかを迷わないようにすることです。静的CMSは構成が読みやすいぶん、層を分けて記録しておけば原因と戻し先に早く近づけます。

障害時に困るのは担当者と戻す状態が不明なこと

障害時に困るのは、原因が分からないことだけではありません。誰の担当か分からず、どの状態へ戻してよいかも分からないことです。

記事の誤字なら、編集担当が戻せるかもしれません。フォームが送れないなら、技術担当と通知先の確認が必要です。DNSやSSLの問題なら、ドメイン管理者やサーバー管理者が関わります。

復旧では、直前に何を変えたかが重要です。記事を更新したのか、テンプレートを変更したのか、環境変数を変えたのか、外部サービス側の設定が変わったのかを見ます。変更履歴がないと、原因調査も復旧も遅れます。

AIエージェントが触れる範囲と人が確認する範囲を分ける

AIエージェントが更新を手伝う場合も、変更できる範囲と触ってはいけない範囲を分けます。記事本文の修正は任せられても、秘密情報やデプロイ設定の変更は人が確認する、といった境界が必要です。

AIエージェントは、Markdownの構造確認、リンク候補の整理、変更差分の説明、点検表の作成に向いています。一方で、公開してよいか、外部サービスの設定を変えてよいか、秘密情報を扱ってよいかは、人が責任を持って判断します。

更新速度が上がるほど、保守範囲を曖昧にしないことが大切です。速く直せる運用は便利ですが、速く壊して気づけない状態になると、静的CMSの強みを活かせません。

平常時点検と障害時記録は別に用意する

点検表には、平常時に見るものと障害時に見るものを分けます。平常時は、問題が起きる前に劣化や設定ミスを見つけるための確認です。障害時は、影響を小さくし、戻す判断をするための記録です。

平常時には、主要ページ表示、フォーム送信、サイトマップを定期的に確認します。noindex、リンク切れ、画像、表示速度も同じ点検に入れます。証明書期限、バックアップ、依存関係の更新有無は、周期を決めて確認します。noindexやX-Robots-Tagを使う場合は、robots metaタグの公式資料を参照し、意図しない非表示が起きていないかを見ます。

障害時には、いつから起きたか、直前の変更は何か、影響URLはどこか、ユーザーに見えている症状は何か、戻す候補はどれかを記録します。復旧後は、原因と再発防止を残します。

平常時の点検は、すべてを毎日見る必要はありません。フォームや主要ページのように損失が早いものは短い間隔で見ます。証明書や依存関係のように周期で管理できるものは、月次や四半期の点検へ入れます。

静的CMSの強みは戻せる構成まで設計して生きる

静的CMSの保守で目指すのは、問題が絶対に起きない状態ではありません。問題が起きても、影響を小さくし、責任者が迷わず、前の状態へ戻せることです。

サイトマップ、robots指定、リダイレクト、HTTPSは、検索エンジンやブラウザでのアクセスに関わります。表示やインデックスにも影響するため、記事本文だけを見ていても、これらの異常には気づけません。

静的CMSの強みは、構成を読みやすくし、変更履歴を残しやすくし、人とAIエージェントが同じ状態を確認しやすいことです。その強みは、制作時だけでなく保守設計まで広げてこそ生きます。どの層を誰が見て、どこまで戻せるかを決めておけば、静的CMSは速く更新できるだけでなく、障害時にも落ち着いて扱える基盤になります。