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