監査ログとセキュリティ監視の運用を強化しました。この記事は、MCPサーバー経由でWordPressを更新・確認する運用担当者を主な対象にしています。単に「記録する」だけでなく、あとから追跡できる粒度で変更内容を残し、異常に気づける状態を優先しています。
この投稿は、mcp-rs の WordPress デモ構築部分を実例として見せるために公開しています。redring.jp をどのように立ち上げ、どのように運用情報を残すかを示すことで、コード側のデモと実際のサイト運用をつなげる狙いがあります。詳しくは mcp-rs のリポジトリ と redring.jp を参照してください。
対象読者
この内容は、MCPサーバーを使ってWordPressの更新や点検を自動化している人、あるいは人手での更新と自動処理を併用しながらサイト運用を進めている人を想定しています。サイト公開後の変更履歴を残したい、障害時に原因をすばやく追いたい、という運用寄りの課題に向けた話です。
見直しの背景
サイト公開後は、コンテンツ更新や設定変更が少しずつ増えていきます。そのため、どの変更が、いつ、誰によって行われ、結果として何が変わったのかを後から把握できる形にしておく必要がありました。
監査ログの粒度
- 設定更新は、変更前後の差分が追える粒度で記録します。
- 投稿や固定ページの更新は、公開状態と更新対象が分かる形で残します。
- カテゴリやタグの再分類は、導線設計への影響を確認できるように扱います。
- メニューやフロントページ設定の変更は、ユーザー体験に直結するため重点的に追跡します。
監視の観点
- REST API の失敗や権限エラーを早めに検知します。
- 想定外の更新や差分が出たときに原因を追跡しやすくします。
- 公開後の運用で継続的に確認すべき項目を絞り込みます。
運用上の効果
この見直しによって、変更時の確認コストを下げながら、問題が起きたときの切り分けを速くできます。公開直後の段階でも、将来の自動アラートや監査運用へつなげやすい土台になります。