🚀 新規事業
PMマニュアル追加依頼_WordPress統合対応
最終更新 2026年07月08日 ／ 40_新規事業/TERASU/PMマニュアル追加依頼_WordPress統合対応.md
PMマニュアル追加依頼「既存WordPressサイトへのデザイン統合対応」
宛先: TERASU PMマニュアル担当セッション（~/dev/terasu-pm-manual）
依頼: 以下の内容でPMマニュアルに1ページ追加してほしい（2026-07-08 大串指示）。
目的: 未来共創で初対応した「既存WordPressへのデザイン統合」の異例ケースを型化し、他のPMが同じ状況になったとき対処できるようにする。
ページ構成・見出し・文体は既存マニュアルのトンマナに合わせて再構成してよい（内容の追加・削除は下記に忠実に）。
1. このページで扱うケース（いつ発動するか）
通常のTERASU案件＝新規の静的HP制作＋Cloudflare配信。それと違い、クライアントが既に
WordPressでサイト運用していて（記事資産あり）、「デザインだけ刷新したい」と言うケース。
発動シグナル:
- 「今のWordPressの記事は残したい」「URLは変えたくない」「SEOを落としたくない」
- 既存サイトが有料テーマ（SWELL等）＋カスタム投稿タイプで作り込まれている
- 記事数が数百〜1000本規模（＝SEO資産が会社の宝レベル）
初回実例: ミライ共創コミュニティ（miraikyoso.jp・WordPress+SWELL・記事約1000本・2026-07対応）
2. PMが最初に確認すること（ヒアリングチェックリスト)
- 既存テーマ名（SWELL等の有料テーマか）
- 記事の種類と数（通常投稿＋カスタム投稿タイプの一覧・概算本数）
- サーバー（エックスサーバー等）とドメイン管理の場所
- WordPress管理画面のログインをもらえるか（これだけで完結する。FTP・サーバー契約情報は不要）
- 先方のSEO要件（URL維持・同一ドメイン統合が絶対条件か）
- 依頼範囲の切り分け: デザインのみか、記事コンテンツ管理も含むか（原則デザインのみ）
3. 絶対にやってはいけない提案（実例で先方NG＆お詫びになった）
- 別ドメインで新HPを作る提案 → NG（ドメインが別＝SEO完全分断。記事資産がHPに効かない）
- サブドメイン（blog.〇〇等）に分ける提案 → NG（サブドメインも完全一体ではない）
- 記事資産が大きいクライアントには「同一ドメイン・同一WordPress内にデザインを載せる」が唯一の正解。
先方がSEOを分かっている場合、上記の提案は確実に拒否され、信頼を失う（未来共創で実際に発生・方向修正とお詫びをした）。
4. 期待値調整（先方への伝え方）
- 初めて対応する構成の場合は正直に伝える: 「この形はTERASUとして初対応。質問・試行錯誤しながら進める」→ 未来共創ではこれで合意を得てから進めて問題なく進行した
- 安全性の説明はこの3点セットで:
1. 記事・データの消失は構造的に起きない（テーマ＝表示層。記事DBには読み取りしかしない）
2. リスクは「有効化（公開切替）の瞬間」のみ。構文チェック＋ライブプレビュー＋WordPressの致命エラー保護＋1クリック復帰の4重対策済み
3. 「絶対」と言えるのは「いつでも元のテーマに1クリックで戻せる」こと
5. 技術方式（開発側に伝える確定方針・シンプル版）
- 子テーマ＋白紙テンプレ方式。既存テーマ・記事・プラグインには一切手を入れない
- 静的ページ（トップ等）＝TERASUの静的HTMLをテンプレとして移植／記事系ページ＝型（テンプレート）だけ作り、記事更新は先方が従来通り
- ローカルWordPress複製は作らない。「ZIPアップ→有効化しないライブプレビュー」が検証環境（本番実データ×新デザインを訪問者に見せずに確認できる）
- サーバー（エックスサーバー等）は触らない。自動バックアップ有効の目視＋管理画面エクスポート1回のみ
- 手順: ①子テーマ作成 → ②バックアップ確認 → ③構文チェック→ZIP→アップ（有効化しない）→ ④ライブプレビューで確認・修正 → ⑤有効化＝公開（責任者の号令・低トラフィック帯）→ ⑥公開後チェック（主要記事URLの200確認・Search Console翌日確認）
6. 絶対の地雷（未来共創で実際に踏んだ/踏みかけたもの）
| 地雷 | 何が起きるか | 回避策 |
|---|---|---|
| 既存記事のURLを変える | SEO資産の破壊 | URLは1文字も変えない |
| テーマフォルダ名が既存テーマと同名 | アップ時に稼働中テーマを直接上書き＝即本番事故（未来共創で「swell_child」が本番の有効テーマと同名で事故未遂） | アップ前に有効テーマのフォルダ名を実測し、独自名にする。「このテーマはインストール済みです／置き換える」画面が出たら即キャンセルして確認 |
| htmlの基準フォントサイズを固定する | モダンビルド由来のCSSはrem連動スケール設計のため、rem箇所だけ膨張し「所々崩れる」（実害発生・原因特定に3往復した） | htmlのfont-sizeに触らない。「所々だけサイズがおかしい」＝rem基準値の食い違いをまず疑う |
| 本番のテーマエディタで直接編集 | 正本とズレる・戻せない | 必ずローカルで修正→ZIP再アップ |
| 勝手に「有効化」を押す | 未完成デザインが即公開 | 有効化＝公開は責任者の号令のみ |
| カスタム投稿タイプ名を推測で作る | テンプレが適用されず表示されない | 本番のREST API（/wp-json/wp/v2/types）で実名を実測してから作る |
7. 公開後の更新運用（先方との役割分担）
| 更新の種類 | 誰が | テーマ再アップ |
|---|---|---|
| 記事の投稿・更新 | 先方がWP管理画面で従来通り | 不要 |
| デザイン・レイアウト・リンク変更 | TERASU側 | 必要（コード修正→ZIP→アップ、1回数分） |
- 正本は常にGitHub。ZIP直編集・テーマエディタ編集は禁止（ver管理・巻き戻しを効かせるため）
8. 参考（正本・実例）
- 技術詳細の正本: Vault 40_新規事業/TERASU/TERASU_既存WordPress統合の進め方
- 実例リポ: scale-group-jp/client-miraikyousou-wp（子テーマ）／client-miraikyousou（静的正本）
- 未来共創の経緯・注意はどちらにも記載あり
このページの狙い: PMが「既存WordPressあり案件」で①間違った提案（別ドメイン等）をしない ②安全性を正しく説明できる ③開発側に正しい方式を伝えられる、の3点ができる状態にすること。