wordpress knowhow 1

View wordpress knowhow 1 flipbook.

WordPress実務ノウハウ大全：構築・運用・高速化・セキ ュリティを一貫して設計する 図1：WordPress サイトの構築、テーマ、プラグイン、SEO 、セキュリティ、運用を俯瞰するイメージ 画像について：背景の管理画面や数値表示は概念表現であり、実在するWordPress 管理画面を完全に再 現したものではありません。 WordPressは、記事を投稿するためだけのブログツールではない。企業サイト、採用サイト、オウンドメデ ィア、会員向け情報サイト、商品紹介サイトなどを、コンテンツ管理機能と拡張機構を組み合わせて構築 できるCMS（Content Management System）である。一方、導入が容易で拡張性が高いからこそ、設計を曖 昧にしたままテーマやプラグインを追加すると、表示速度、更新互換性、セキュリティ、運用責任の問題 が後から表面化する。 本稿は、2026年8月6日時点の情報を前提に、WordPressを「インストールして公開する」だけでなく、「安 全に変更し、障害から復旧し、継続的に改善できる状態」へ持っていくための実務手順をまとめる。初め て担当する人には導入の地図として、既存サイトを引き継ぐ人には点検表として使える構成にした。 1. WordPressとは何か WordPressの本体であるWordPress Coreは、投稿、固定ページ、ユーザー、メディア、コメント、分類、 URL生成、テーマ切り替え、プラグイン読み込みなど、CMSの共通機能を提供する。見た目は主にテー

マ、業務固有の機能は主にプラグイン、文章や画像はコンテンツとして分離するのが基本である。これに より、コンテンツを保持したまま外観を変更したり、テーマを触らずに機能を追加したりできる。 実務では、WordPressを次の五層に分けて考えると判断しやすい。 1. インフラ層：DNS、Webサーバー、PHP、データベース、TLS証明書、ストレージ 2. WordPress Core層：CMS本体、REST API、ユーザー・権限、更新機構 3. テーマ層：テンプレート、デザイン、レイアウト、 theme.json 4. プラグイン層：SEO、フォーム、キャッシュ、バックアップ、独自業務機能 5. コンテンツ・運用層：投稿、固定ページ、画像、承認、公開、分析、保守 障害時に「WordPressが壊れた」と一括りにせず、DNSなのか、PHPなのか、Coreなのか、テーマなのか、 プラグインなのかを切り分けることが重要である。 2026年8月6日時点のバージョン認識 この時点の安定版として扱うべきなのはWordPress 7.0.2であり、同リリースはセキュリティ上の問題へ対 処した更新として案内されている。運用サイトでは、互換性確認とバックアップを行ったうえで7.0.2系を 基準にする。[1] WordPress 7.1は2026年8月19日の正式公開が予定され、公式開発者向け情報では8月5日にRelease Candidate 1へ移行したと案内されている。したがって、2026年8月6日現在の7.1は正式安定版ではなくRC段階であ る。本番環境の標準版として記述・導入せず、ステージング環境でテーマ、プラグイン、編集フローを検 証する対象とする。[2][3] 2. WordPress.orgとWordPress.comの違い 名前が似ているため混同されやすいが、導入判断では「ソフトウェアを自分のサーバーへ設置して管理す る方式」と「ホスティングを含むサービスとして利用する方式」を区別する。 WordPress.org：セルフホスト型 WordPress.orgから入手できるオープンソースのWordPressを、自社または契約先のサーバーへ設置する方式 である。サーバー、ドメイン、バックアップ、更新、監視、障害対応を自分たちの責任範囲として設計す る代わりに、テーマやプラグイン、コード、データ構造、外部連携を広く制御できる。 向いているのは、独自機能が必要な企業サイト、運用基準を自社で定めたい組織、複数環境とGitを用いた 開発を行う案件、データやインフラの選択権を重視する案件である。 WordPress.com：ホスティングサービス型 WordPress.comは、ホスティングや運用機能をサービスとしてまとめて提供する。サーバー構築の負担を減 らして開始しやすい一方、利用できる機能、拡張、収益化、ストレージ、サポートなどは契約プランとサ

ービス仕様に依存する。両者の大きな違いをホスティング方法として整理する解説でも、WordPress.comは ターンキー型、WordPress.orgはセルフホスト型とされている。[4] 選択の基準 以下の問いに答えると選びやすい。 サーバーとPHPの更新を担当できるか 独自プラグインや外部API連携が必要か ステージング、Git、CI/CDを導入するか 障害時にログとデータベースを直接調査したいか 月額費用だけでなく、保守担当者の工数を含めて比較したか 将来、サイトを別事業者へ移管する可能性があるか 「自由度が高いから.org」「簡単そうだから.com」と即断せず、必要な統制と負担を対で見る。自由度 は、そのまま保守責任でもある。 3. 導入要件を決める WordPress.orgの公式要件ページは、推奨環境としてPHP 8.3以上、MySQL 8.0以上またはMariaDB 10.6以 上、HTTPS対応を掲げている。古い環境でも動作する場合があるが、EOLを迎えたソフトウェアはセキュ リティリスクを伴うと明記されている。[5] 導入前に、最低でも次を確認する。 推奨範囲のPHPとデータベースを選べる HTTPSを利用でき、証明書更新を自動化できる PHP拡張、メモリ、実行時間、アップロード上限を確認できる SFTPまたはSSHを利用できる データベースのバックアップと復元ができる ステージング環境を用意できる アクセスログ、エラーログ、PHPログを閲覧できる cron、メール送信、DNSを管理できる 「WordPressがインストール可能」と「事業サイトを安定運用できる」は別条件である。価格だけでサーバ ーを選ばず、復旧手段、サポート範囲、バックアップ保持、WAF、CDN、オブジェクトキャッシュ、 SSH、環境複製の有無を見る。 4. サーバー・ドメイン・SSLの設計 サーバー

小規模サイトでも、本番環境へ直接ファイルを上書きする運用は避ける。理想はローカル開発、ステージ ング、本番の三環境である。難しい場合も、少なくとも本番とは別に更新検証用環境を用意する。PHPや データベースのメジャー更新、テーマ変更、フォーム改修はステージングで確認してから反映する。 サーバー選定では、通常時の表示速度だけでなく、管理画面の応答、バックアップ復元時間、アクセス急 増時の制御、障害通知、ログ保持を確認する。共有サーバー、マネージドWordPress、VPS、クラウドには それぞれ責任分界がある。チーム内にOS・ミドルウェア運用者がいないなら、自由度の高いVPSが必ずし も最適とは限らない。 ドメインとDNS 公開前に、正式ドメイン、 www の有無、メール用DNS、検証用サブドメイン、リダイレクト方針を決め る。正規URLを途中で変えると、内部リンク、画像URL、Cookie、SEO、外部連携に影響する。DNS変更 ではTTLを把握し、旧環境を即座に破棄せず、切り戻せる時間を確保する。 SSL/TLS HTTPSはログイン情報やフォーム入力の保護だけでなく、現在のWordPress推奨要件にも含まれる。[5] 証 明書の取得だけで終わらせず、HTTPからHTTPSへの恒久リダイレクト、WordPressアドレスとサイトアド レス、混在コンテンツ、外部リソース、Cookie、CDNのオリジン設定まで確認する。証明書の自動更新に 失敗した場合の通知経路も必要である。 5. インストールと初期設定 インストール時の原則 データベース名、ユーザー、強いパスワードをサイトごとに分け、必要以上の権限を与えない。管理者ア カウントには推測しやすいユーザー名を避け、担当者ごとに個別アカウントを発行する。共有アカウント は、退職・異動時の停止や操作追跡が難しい。 wp-config.php にはデータベース接続などの基礎設定が入る。公式の管理ハンドブックも、このファイ ルがWordPressルートに置かれ、データベース接続情報などを保持すると説明している。[6] 本番の認証情 報をGitへコミットせず、ホスティングの秘密管理、環境変数、デプロイ時設定など、案件に適した方法で 分離する。 管理画面で最初に決める項目 1. 一般設定：サイト名、キャッチフレーズ、管理メール、タイムゾーン、日付形式 2. 表示設定：トップページを最新投稿にするか固定ページにするか、検索エンジンへの表示方針 3. パーマリンク：公開前にURL構造を確定 4. ディスカッション：コメントを使うか、承認を必要とするか 5. メディア：画像サイズと運用ルール 6. ユーザー：管理者、編集者、投稿者などの役割

7. プライバシー：プライバシーポリシーページと問い合わせ導線 パーマリンクを公開後に変更すると既存URLが変わるため、リダイレクト設計なしで変更しない。検索エ ンジンへの表示抑制は、機密保護機能ではない。検証環境はBasic認証、IP制限、VPNなどでアクセス自体 を制御する。 デバッグ設定 本番画面へPHPエラーを表示してはいけない。検証環境ではログへ記録し、本番では訪問者への表示を止 める。設定変更前に wp-config.php をバックアップし、変更後はPHP構文を確認する。 // 検証環境の例。環境ごとの設定ファイルで管理する。 define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', '0' ); 6. 投稿と固定ページを使い分ける 投稿 投稿は、ニュース、ブログ、ノウハウ、更新情報など、時系列で蓄積し、カテゴリーやタグで分類するコ ンテンツに向く。アーカイブ、RSS、著者、公開日時との相性がよい。カテゴリーはサイト全体の大分類 として先に設計し、タグは横断的な補助分類として必要なものだけを使う。 固定ページ 固定ページは、会社概要、サービス、採用、問い合わせ、プライバシーポリシーなど、ナビゲーション上 の定位置を持つ情報に向く。更新日を持てないわけではないが、基本的には時系列の一覧へ流す目的では ない。 コンテンツモデルを先に決める 画面を作りながら投稿と固定ページを選ぶのではなく、次を先に定義する。 コンテンツの種類 URL構造 必須項目 一覧・詳細の関係 カテゴリーとタグ 執筆者、承認者、公開者 公開期限と更新期限 構造化データやOGPに必要な値

事例、商品、イベントなど、通常の投稿と意味が異なる大量データは、独自投稿タイプや独自タクソノミ ーを検討する。ただし、少数ページのために過剰なデータ構造を作ると運用が複雑になる。 7. テーマ、子テーマ、ブロックテーマ、サイトエディター テーマの役割 テーマは見た目だけでなく、テンプレート、レイアウト、タイポグラフィ、色、ブロックの表示規則を担 う。機能とデザインを分離するため、フォーム送信、会員管理、外部API連携など、テーマ変更後も必要 な機能はプラグイン側へ置く。 クラシックテーマ クラシックテーマはPHPテンプレートとテンプレート階層を中心に構成される。既存資産が多く、細かな PHP制御に慣れたチームには扱いやすい。一方、ヘッダーやフッターの変更がコード依存になりやすく、 編集者だけでは変更できない場合がある。WordPressのテーマ開発資料は、特定テンプレートから一般テン プレート、最後に index.php へ至る階層を前提としている。[7] 子テーマ 配布テーマを直接編集すると、テーマ更新で変更が上書きされる。既存テーマのテンプレートやCSSをコ ードで変更する場合は、子テーマを使う。親テーマを更新できる状態を維持しながら、差分だけを子テー マへ持たせる。 ただし、子テーマは万能ではない。大量の親テンプレートをコピーすると、親テーマの改善が取り込まれ にくくなる。差分が大きいなら独自テーマの方が保守しやすい。ブロックテーマでは、サイトエディター の変更、スタイルバリエーション、パターン、 theme.json で解決できる範囲もあるため、コード差分が 本当に必要かを先に判断する。 ブロックテーマとサイトエディター ブロックテーマでは、投稿本文だけでなく、ヘッダー、フッター、テンプレート、テンプレートパーツも ブロックとして編集できる。テーマ開発資料では、 theme.json 、 templates/*.html 、 parts/*.html 、パターンなどを中心とする構成が示されている。[7] theme.json は、色、余白、タイポグラフィ、レイアウト幅などをデザイントークンとして集約するのに 向く。編集者へ無制限な色やサイズを渡すのではなく、ブランド基準に沿う選択肢を定義する。 ブロックテーマの実務上の注意点は次のとおりである。 サイトエディター内の変更とテーマファイルのどちらが優先されるかを理解する 本番管理画面だけでテンプレートを変更し、差分がGitに残らない状態を避ける 再利用したいレイアウトはパターン化する ロック機能や権限設計で、重要な構造を誤編集から守る

PCだけでなく、スマートフォン、キーボード操作、拡大表示を確認する 8. プラグイン選定の原則 プラグインは便利だが、「入れれば入れるほど危険」「少なければ必ず速い」という単純な話ではない。 重要なのは、各プラグインがどこで何を読み込み、どのデータを保存し、誰が保守し、削除時に何が残る かである。 導入前チェック 解決したい要件が明確か WordPress標準機能やホスティング機能で代替できないか 現行のCore・PHPで検証されているか 更新履歴とサポート窓口が確認できるか 権限、外部送信、Cookie、個人情報の扱いを説明できるか データベースへ作るテーブルやオプションを把握しているか 無効化・削除・乗り換え手順があるか 類似機能を持つ既存プラグインと競合しないか SEO、キャッシュ、セキュリティ、画像最適化は、複数プラグインが同じ機能へ介入しやすい。たとえば 二つのキャッシュ機構でHTML最適化を重ねると、原因切り分けが難しくなる。カテゴリごとに責任を一 つへ寄せる。 独自コードの安全原則 WordPress Coreを直接変更しない。フック、テーマ、子テーマ、独自プラグインで拡張する。入力時にサ ニタイズし、出力時に文脈へ合うエスケープを行う。nonceはリクエストの意図確認に使い、権限確認の 代用にはしない。データベースクエリは $wpdb->prepare() を使い、テーブル接頭辞を固定文字列で書か ない。CSSとJavaScriptは wp_enqueue_style() 、 wp_enqueue_script() で登録する。 以下は、管理画面フォームの最小例である。

<?php defined( 'ABSPATH' ) || exit; add_action( 'admin_post_acme_save_note', 'acme_save_note' ); function acme_save_note(): void { if ( ! current_user_can( 'manage_options' ) ) { wp_die( esc_html__( 'この操作を行う権限がありません。', 'acme' ), '', [ 'response' => } check_admin_referer( 'acme_save_note', 'acme_nonce' ); $note = isset( $_POST['acme_note'] ) ? sanitize_textarea_field( wp_unslash( $_POST['acme_note'] ) ) : ''; update_option( 'acme_note', $note ); wp_safe_redirect( admin_url( 'options-general.php?page=acme&updated=1' ) ); exit; } 表示側では保存値をそのまま出力しない。 <textarea name="acme_note"><?php echo esc_textarea( get_option( 'acme_note', '' ) ); ?></ <?php wp_nonce_field( 'acme_save_note', 'acme_nonce' ); ?> 独自テーブルを検索する場合も、値をSQL文字列へ連結しない。 global $wpdb; $table = $wpdb->prefix . 'acme_items'; $rows = $wpdb->get_results( $wpdb->prepare( "SELECT id, title FROM {$table} WHERE user_id = %d AND status = %s", get_current_user_id(), 'publish' ) ); 9. SEOは情報設計から始める SEOプラグインはタイトルやメタ情報の管理を助けるが、サイト構造や内容の不足を自動で解決するもの ではない。まず、ユーザーが何を知りたいか、どのページが答えるか、関連情報へどう移動するかを設計 する。

基本項目 ページごとに固有で内容を表すタイトルを付ける 見出し階層を文章構造として使う 重複ページと正規URLを整理する 内部リンクを文脈に沿って張る 画像へ内容に合う代替テキストを付ける XMLサイトマップ、robots、noindexを意図どおりに管理する リダイレクトと404を監視する 構造化データは実際の表示内容と一致させる 著者、更新日、根拠、問い合わせ先を明確にする 公開前のチェックだけでなく、公開後に検索クエリ、クロール状況、離脱、フォーム到達を見て改善す る。URLをむやみに変更せず、変更する場合は旧URLから適切に転送する。 10. セキュリティは多層防御で考える WordPress Coreだけを更新しても十分ではない。サーバー、認証、権限、テーマ、プラグイン、バックア ップ、監視を重ねる。公式のハードニング資料は、WordPressを常に最新へ保つこと、信頼できる配布元を 使うこと、ファイル権限や管理アクセスを適切に扱うことなどを整理している。[8] 実務チェックリスト 1. Core、テーマ、プラグインを保守対象として一覧化する 2. 不要なテーマ・プラグインは停止だけでなく削除を検討する 3. 管理者を最小限にし、担当者別アカウントと多要素認証を使う 4. パスワードマネージャーで長く固有の認証情報を管理する 5. ステージングと本番の認証情報を分ける 6. 管理画面、SSH、ホスティング管理画面のログを確認できるようにする 7. WAFやレート制御をサーバー／CDN層で検討する 8. ファイル変更、管理者追加、プラグイン追加、ログイン失敗を監視する 9. 秘密情報をGit、チケット、チャットへ貼らない 0. インシデント時の連絡先と初動手順を文書化する nonceはCSRF対策の一部であり、「そのユーザーがその操作を許可されているか」は current_user_can() で別に確認する。入力は保存前にサニタイズし、出力はHTML本文、属性、URL、 JavaScriptなどの文脈に合わせてエスケープする。 Core 7.0.2はセキュリティリリースとして案内されているため、7.0系の運用サイトでは更新優先度が高 い。[1] ただし、本番へ無検証で適用するのではなく、バックアップ、ステージング確認、適用、スモー クテスト、監視という手順を短時間で回せる体制が必要である。

11. バックアップは「復元できること」が完成条件 バックアップ対象はデータベースだけではない。少なくとも次を含める。 データベース wp-content/uploads のメディア 独自テーマ、子テーマ、独自プラグイン 設定ファイルと環境固有設定の再構築手順 Webサーバー、CDN、DNS、メールなどの構成情報 バックアップを同じサーバー内だけに置くと、サーバー障害や侵害時に同時に失う可能性がある。権限を 分けた別ストレージへ暗号化して保管し、保持期間を定める。個人情報を含む場合は、バックアップへの アクセス、保存地域、削除、廃棄も管理対象である。 復元テスト 定期的に別環境へ復元し、次を確認する。 1. バックアップファイルを取得できる 2. データベースをインポートできる 3. メディアが欠損していない 4. URL置換後にシリアライズデータが壊れていない 5. ログイン、ページ表示、検索、フォーム、メール送信が動く 6. 復元に要した時間を記録できる 「毎日バックアップ」と表示されていても、復元権限、保持数、対象範囲、復元時間が不明なら運用設計 として不十分である。 12. 更新を安全な定常業務にする 更新はイベントではなく定常業務である。放置すれば脆弱性と互換性の差分が蓄積し、まとめて更新する 際の影響が大きくなる。 標準フロー 1. 変更内容とセキュリティ情報を確認 2. 本番の完全バックアップを取得 3. ステージングを本番相当に同期 4. PHP、Core、テーマ、プラグインの順序と依存関係を整理 5. ステージングで更新 6. 主要ページ、ログイン、検索、フォーム、決済や外部連携を確認 7. 本番へ適用

8. キャッシュを適切に消去 9. エラーログ、監視、問い合わせを確認 0. 実施者、日時、バージョン、結果を記録 自動更新は、すべて有効またはすべて無効の二択ではない。小さなセキュリティ更新を迅速に適用しつ つ、影響の大きいメジャー更新や業務中核プラグインは検証後に適用するなど、リスクで分ける。7.1のよ うなRC版は本番更新列へ入れず、互換性試験用に扱う。[2][3] 13. パフォーマンス高速化の順序 高速化はプラグインを一つ追加して終わる作業ではない。測定し、ボトルネックを特定し、変更し、再測 定する。 まず測る キャッシュが効いている訪問者と、ログイン中の編集者を分ける トップだけでなく、記事、一覧、検索、フォームを測る Webサーバー応答、PHP実行、データベース、外部API、画像、JavaScriptを分ける 平常時とアクセス増加時を分ける 変更前の値と条件を保存する 公式Hosting Handbookにもパフォーマンス領域が整理されており、ホスティング、キャッシュ、画像、デ ータベースなどを横断して見る入口になる。[9] 改善の優先順位 1. 過負荷やリソース不足を解消する 2. フルページキャッシュを適用する 3. 重いプラグイン、外部通信、遅いクエリを特定する 4. 画像サイズと形式を最適化する 5. 不要なJavaScriptとCSSを減らす 6. 必要に応じてCDNを使う 7. 永続オブジェクトキャッシュを検討する 8. データベースの肥大とcron処理を点検する 画像は表示サイズに近い寸法で生成し、レスポンシブ画像を利用する。ファーストビューの主要画像を一 律lazy loadにすると逆効果になる場合があるため、重要度で分ける。外部フォント、解析タグ、チャッ ト、広告、動画埋め込みは、それぞれ通信とJavaScript実行を増やすので、事業価値と費用を比較する。 クエリとアセットの実装例 ページネーションが不要な取得では no_found_rows を使い、必要なフィールドだけを取る。値を受け取 る独自SQLはprepared queryにする。

$query = new WP_Query( [ 'post_type' => 'post', 'posts_per_page' => 6, 'no_found_rows' => true, 'fields' => 'ids', 'update_post_meta_cache' => false, 'update_post_term_cache' => false, ] ); アセットはHTMLへ直書きせず、WordPressの仕組みで読み込む。必要な画面だけに限定し、依存関係とバ ージョンを明示する。 add_action( 'wp_enqueue_scripts', static function (): void { if ( ! is_page( 'contact' ) ) { return; } $path = get_stylesheet_directory() . '/assets/contact.css'; $uri = get_stylesheet_directory_uri() . '/assets/contact.css'; wp_enqueue_style( 'acme-contact', $uri, [], file_exists( $path ) ? (string) filemtime( $path ) : null ); } ); 14. キャッシュを正しく理解する キャッシュには複数の層がある。 ブラウザキャッシュ：画像、CSS、JavaScriptなどを利用者側に保持 CDN／エッジキャッシュ：配信拠点で静的ファイルやHTMLを保持 ページキャッシュ：生成済みHTMLを再利用 オブジェクトキャッシュ：計算結果やデータベース取得結果を再利用 PHP OPcache：PHPのコンパイル結果を再利用 キャッシュは速くする一方、古い内容を見せる。公開、更新、削除、権限変更、在庫変更など、データが 変わるイベントで何を無効化するかを設計する。会員情報、カート、管理画面、プレビュー、nonceを含

むページを、全員共通のHTMLとして配信してはいけない。 Transients APIを使う場合も、有効期限だけに頼らず、元データ変更時に削除する。 function acme_get_featured_ids(): array { $key = 'acme_featured_ids_v1'; $ids = get_transient( $key ); if ( false === $ids ) { $ids = get_posts( [ 'post_type' => 'post', 'posts_per_page' => 6, 'fields' => 'ids', 'no_found_rows' => true, ] ); set_transient( $key, $ids, HOUR_IN_SECONDS ); } return array_map( 'absint', $ids ); } add_action( 'save_post_post', static function (): void { delete_transient( 'acme_featured_ids_v1' ); } ); 15. WP-CLIで反復作業を安全にする WP-CLIは、ブラウザ管理画面を介さずにWordPressを操作するコマンドラインツールである。公式コマン ド一覧には、Core、プラグイン、テーマ、データベース、キャッシュ、cron、ユーザーなどを管理するコ マンドが整理されている。[10] 状態確認 wp core version wp core verify-checksums wp plugin list wp theme list wp cron event list 更新前のバックアップと更新

wp db export before-update.sql wp core check-update wp plugin update --all --dry-run wp theme update --all --dry-run 利用中のWP-CLIや各コマンドが --dry-run を提供するかは、実行前に wp help <command> で確認す る。更新後はキャッシュを消すだけで終わらず、主要機能をテストする。 URL置換 環境移行でSQLを直接置換すると、シリアライズされた値を破損する可能性がある。WP-CLIの search- replace を用い、まずdry runで件数と対象を確認する。 wp search-replace 'https://old.example' 'https://new.example' \ --all-tables-with-prefix \ --skip-columns=guid \ --dry-run 確認後に --dry-run を外す。対象URL、テーブル範囲、バックアップを必ず確認する。マルチサイトや 外部テーブルがある案件では、さらに慎重な設計が必要である。 本番での注意 rootユーザーで安易に実行しない --path と対象環境を確認する 破壊的コマンドの前にバックアップを取得する コマンド履歴へパスワードやAPIキーを残さない 複数サイトの一括更新では、一件の失敗を検知して停止できるようにする 実行ログと変更記録を残す 16. 運用体制を作る WordPress運用で最も危険なのは、「誰かが見ているはず」という状態である。最低限、次の役割を割り当 てる。 サイト責任者：目的、予算、リスク受容、公開判断 編集責任者：コンテンツ品質、承認、更新期限 技術責任者：Core、テーマ、プラグイン、サーバー、障害対応 セキュリティ窓口：脆弱性情報、インシデント初動、権限レビュー 外部事業者窓口：契約、SLA、エスカレーション、引き継ぎ

小規模組織では一人が兼務してもよいが、責任そのものを消してはいけない。担当者不在時の代替者、認 証情報の保管、緊急連絡先、復元手順を共有する。 定例運用 日次または自動監視：死活、証明書、バックアップ成否、セキュリティ通知、フォーム送信。 週次：更新候補、エラーログ、容量、管理者追加、重要画面。 月次：Core・プラグイン・テーマ更新、復元可能性、パフォーマンス、404、外部連携、契約状況。 四半期：ユーザー権限、不要プラグイン、PHP・データベースのサポート状況、災害復旧、運用文書、ベ ンダー依存。 変更管理票には、変更理由、対象、実施者、承認者、バックアップ、検証項目、切り戻し条件、結果を残 す。 17. WordPressのメリット コンテンツ更新を分業しやすい 管理画面、ユーザー役割、下書き、プレビュー、公開日時などにより、開発者以外も更新へ参加できる。 適切なテンプレートと入力項目を作れば、担当者がデザインを壊さずに情報を追加できる。 拡張ポイントが豊富 テーマ、プラグイン、フック、REST API、WP-CLIなど、要件に応じた拡張経路がある。小さく始め、必 要に応じてコンテンツ型や外部連携を増やせる。 移管可能性を確保しやすい セルフホスト型では、ファイル、データベース、ドメイン、サーバーを適切に管理していれば、事業者変 更や環境移行の選択肢を持ちやすい。ただし、特定テーマやページビルダーの独自形式へ深く依存する と、実質的な移行コストは高くなる。 編集体験と開発統制を両立できる ブロック、パターン、 theme.json 、権限を設計すれば、編集者の自由度を確保しつつ、ブランドやアク セシビリティの基準を守れる。 18. WordPressのデメリット 継続保守が必要

Coreだけでなく、PHP、データベース、テーマ、プラグイン、外部APIを更新し続ける必要がある。公開 後に予算と担当者が消える案件には向かない。 組み合わせによる複雑性 個々には正常なテーマとプラグインでも、組み合わせ、読み込み順、キャッシュ、PHP更新で問題が起き る。導入数だけでなく、依存関係と責任者を管理する必要がある。 自由度が品質のばらつきにつながる 編集権限やデザイン選択肢を無制限にすると、ページごとに見た目やHTML構造がばらつく。パターン、 入力制約、承認フロー、編集ガイドが必要である。 高トラフィックや複雑業務では設計力が要る キャッシュしにくい動的画面、巨大検索、会員別表示、外部API依存などでは、単純な共有サーバーと汎 用プラグインだけでは対応しにくい。要件によっては、WordPressをコンテンツ基盤に限定し、別システム と分離する方がよい。 19. トラブルシューティング 障害時は、変更を重ねず、再現条件と直前の変更を記録する。まずバックアップ状況を確認し、証拠とな るログを保存する。 画面が真っ白、重大なエラーが表示される 1. PHPエラーログを確認 2. 直前に更新したプラグインやテーマを確認 3. ステージングで同じ状態を再現 4. 問題プラグインを一つずつ切り分け 5. PHPバージョンとメモリ不足を確認 6. 修正後にデバッグ表示を本番へ残さない 管理画面へ入れない場合も、SFTPやWP-CLIで対象プラグインを無効化できる。ただし、停止によるデー タ処理への影響を確認する。 データベース接続エラー wp-config.php の接続情報、データベース稼働、ディスク容量、接続上限、ホスト名、権限を確認す る。復旧を急いで認証情報をチャットや公開チケットへ貼らない。 更新後にレイアウトが崩れる

ブラウザ、CDN、ページキャッシュ、オブジェクトキャッシュを層別に確認する。CSSファイルのバージ ョン、最適化プラグインによる結合・遅延、子テーマの上書き、サイトエディターに保存されたテンプレ ート差分を調べる。 SSL警告やリダイレクトループ 証明書だけでなく、WordPress URL、Webサーバーの転送、CDNのSSLモード、プロキシヘッダー、HTTP で残る画像・スクリプトを確認する。プラグインだけで転送を重ねるとループすることがある。 管理画面は速いが公開画面が遅い、またはその逆 公開画面だけ遅いなら外部タグ、画像、ページキャッシュ、テーマ処理を疑う。管理画面だけ遅いなら、 管理画面で動くプラグイン、Heartbeat、外部API、cron、肥大したautoloadオプション、データベースクエ リを調べる。 404が増えた パーマリンク変更、投稿スラッグ、リダイレクト、Webサーバー設定、キャッシュを確認する。単にパー マリンク設定を保存し直す前に、なぜ書き換え規則が失われたかを調べる。 一般的なWordPress障害には、白画面、SSL、タイムアウト、データベース関連などが含まれ、プラグイ ン、テーマ、サーバー設定が原因候補になる。[11] ただし�