店舗ごとに分かれていたサイトをまとめたら、営業時間の変更まで本部への依頼が必要になった。見た目はそろっても、今日中に伝えたい案内を店舗で出せなくなれば、管理が楽になったとは言い切れません。統合前に残すべきなのは、ページの内容だけでなく、その情報を必要な時に更新できる操作です。
複数サイトの統合では、共通にする機能と、各店に残す編集・公開の範囲を対応させます。「本部は管理者、店舗は編集者」と役割名を決めるだけでは、店舗別の制限や急ぎの更新が成立するか分かりません。この記事では、本部と各店の担当者が、統合案を具体的な操作で比較するための表を紹介します。
何を一つにするのか、三つの意味をそろえる
最初に、「サイトをまとめる」が何を指すかをそろえます。一つ目は、利用者が見るサイトを一つにして、その中に店舗ページを置く方法です。二つ目は、ブランド別のサイトを残し、共通の管理環境で動かす方法です。三つ目は、サイトの構成を変えず、更新元と担当、確認手順をそろえる方法です。
これらは組み合わせることもできますが、同じ効果を持つわけではありません。共通の管理画面に入れるようになっても、料金や会社案内が一か所の変更で全店へ反映されるとは限りません。反対に、一つの公開サイトでも、店舗ごとの入力欄や公開できる範囲を設ける必要があります。
WordPressのマルチサイトは、複数サイトを共通の環境で管理する具体例です。公式資料では、サイト同士が内容を既定で共有する仕組みではないことを説明しています。共通環境にすることと、同じ情報を参照・同期することは、別に確かめる必要があります。WordPressのマルチサイト管理資料
打ち合わせでは、公開するURLの構成、担当者が操作する管理環境、情報を更新する元の三つを並べます。「ログインを一つにしたい」のか、「同じ説明を何度も直したくない」のか、「利用者が店舗を探しやすくしたい」のかを書けば、必要な改修を混同しにくくなります。
機能名に、使う人と編集できる対象を加える
既存機能の一覧には、お知らせ、店舗情報、予約ボタンなどの名前に加え、誰が何を変更しているかを記録します。同じお知らせ機能でも、本部は全店向けの告知、店舗は自店の臨時案内を出しているかもしれません。「お知らせは一つへ統合」とだけ決めると、この違いが設計から抜けます。
次の表は、架空の小売ブランドが店舗A・Bのサイトをまとめる場合の設計例です。実在企業の管理権限や導入実績を示すものではありません。統合案で困る操作を見つけ、その代替案まで制作会社と比べるために使います。
| 機能 | 利用者 | 必要な編集範囲 | 統合で確かめる影響 | 代替案 |
|---|---|---|---|---|
| 共通サービス案内 | 本部 | 全店共通の説明 | 店舗の例外も上書きしないか | 共通説明と店舗条件を別の欄へ |
| 営業日時 | 各店 | 自店の通常・臨時情報 | 本部待ちで更新が遅れないか | 自店の対象欄だけ公開可能に |
| 店舗のお知らせ | 各店・本部 | 自店向けと全店向け | 他店の投稿まで編集できないか | 対象店舗を制限できる構成へ |
| 予約先の案内 | 本部・各店 | 自店の案内と接続先 | ボタンだけ変わり受付側が残らないか | 外部受付を残して担当を対応付け |
| 共通デザイン・追加機能 | 保守担当 | 指定した共通部分 | 一変更が他店にも及ばないか | 個別機能を残す案と費用比較 |
実際の表には、今の入力画面と公開先のURLを対応させます。「店舗情報」という一行が広すぎるなら、営業時間、住所、写真、予約先に分けてください。変更する頻度、急ぎの変更があるか、店舗だけで決められる内容かが異なると、同じ権限にまとめにくくなります。
代替案は、すぐに採用する仕様ではありません。利用中の仕組みで実現できるか、追加の制作が必要か、運用で補う場合に誰の作業が増えるかを確認します。表の全行を一つの仕組みに押し込まず、共通化によって減る作業と新しく発生する作業を両方残すことが大切です。
「編集者」という名前だけで、店舗を限定できると思わない
権限を整理するときは、「対象」と「操作」を組み合わせます。店舗Aの営業時間を変更する、店舗Aのお知らせを下書き保存する、本部が全店向け告知を公開する、といった書き方です。読むだけ、編集する、公開する、削除する、機能を追加する操作を、一つの「管理できる」にまとめないようにします。
WordPressの標準的な役割でも、自分の投稿と他者の投稿、編集と公開では許可される操作が違います。例えば、編集者という役割名そのものは「自分の担当店舗だけを編集する」という意味ではありません。店舗単位の制限が必要なら、追加機能や独自設定を含めた構成で実現できるかを確認します。WordPressの役割と権限
また、単独サイトで使っていた管理者と、マルチサイト内のサイト管理者では、同じ名前でも操作範囲が異なる部分があります。従来、店舗が独自に追加していた機能を、統合後も同じように追加できるとは限りません。現在の肩書や画面上の役割名を、そのまま移行表へ写すだけでは不足します。
必要な操作を残すことと、全員へ広い権限を渡すことも別です。営業時間を直せない問題を解消するために、共通デザインや他店の情報まで変更できる状態にする必要があるかを検討します。対象の入力欄を切り出すなど、目的の操作だけを実現する案を制作会社へ相談できます。
業務上の判断も対応させます。画面で公開できても、その人が新しい料金や営業条件を決められるとは限りません。本部が内容を確定し店舗が入力する項目と、店舗が事実を確かめて公開する項目を区別します。ここで決めるのは、既存の業務判断をどの画面操作へ反映するかです。
共通の説明と、店舗の例外を同じ欄に入れない
架空例で、本部が全店共通のサービス説明を更新するとします。店舗Bだけは一部のサービスを提供していないため、その条件は店舗Bの案内に必要です。共通説明を一括で差し替えた際に、Bの条件が消えたり、利用できると読める説明へ変わったりしない構成を考えます。
方法の一つは、本部が管理する共通説明と、店舗ごとの対応条件を別の入力項目にすることです。公開画面では両方を組み合わせ、Bの条件が説明の末尾に埋もれないようにします。ただし、欄を分けるだけで適切に表示されるとは限らないため、一覧と詳細の両方で確かめます。
共通値を店舗側で上書きする設計を使う場合は、どちらが優先されるかを決めます。空欄なら共通値を使うのか、情報なしとして表示するのかでも結果は変わります。「未入力」と「対象外」を同じ空欄にせず、必要な選択肢と表示文を用意できるかが相談事項になります。
臨時営業時間のように期間がある情報は、通常の時間を消して置き換えるだけで足りるかも検討します。開始前の予告、適用中、終了後で何を表示するかと、それを変える操作を対応させます。自動終了を使うなら、設定できる条件と実際の表示を試し、使わない場合は切り替え担当を残します。
予約ボタンと、外部サービスの操作権限を分けて追う
店舗サイトを統合しても、外部の予約サービスまで同じ管理画面になるとは限りません。自社サイトで営業時間を変更できる人と、予約受付の時間や枠を変更できる人が異なる場合もあります。自社側の更新完了を、予約側まで反映された意味にしないことが重要です。
比較表の予約機能には、ボタンの文言とリンク先、自社で入力する案内、外部側で設定する内容を分けて追記します。既存の予約先を残すなら、統合後の店舗ページから正しい店舗の受付へ進めるかを確認します。共通の予約トップへ送ることで、店舗を再選択する手間が増えないかも見ます。
機能を置き換える案では、見た目が似た入力フォームを用意できるだけでは判断できません。現在の受付に必要な項目や操作が残るかを、利用中のサービスと照合します。予約・在庫・顧客データを一体化する話になる場合は、Webの案内整理から範囲を分けて、必要な調査と関係者を確認します。
通知先も画面とは別の確認項目です。サイト上は店舗Aの案内でも、変更依頼や問い合わせの通知が旧担当へ届く設定が残る可能性があります。統合に伴って変えるリンクと通知先を記録し、確認できていない外部設定は「残す」だけで済ませず、担当と確認方法を示します。
本部と店舗、それぞれの操作で統合案を試す
提案画面を見る段階では、本部の管理者だけで全機能を確認しないようにします。実際に想定する店舗担当の権限で、必要な更新が最後までできるかを試します。検証用の環境と架空の情報を使い、営業中のサイトや本番の予約に影響を与えない方法を制作担当と決めます。
店舗Aの担当なら、Aの臨時営業時間を入力し、保存または公開して、一覧と詳細へ正しく出るかを確かめます。同時に、店舗Bの情報や本部の共通説明を変更できないことも確認します。編集画面から項目が見えないだけで十分かは、実装側が実際のアクセス制御も含めて検証する範囲です。
本部の担当は、共通説明の修正が対象店舗へ反映され、Bの例外が残るかを確認します。店舗のお知らせを本部が確認して公開する案なら、店舗が提出した内容を見つけられるか、修正を戻した後にどの状態になるかも試します。提出できたことと、利用者へ公開されたことを区別して表示します。
通常の操作に加え、本部の確認担当が不在の時間帯に急ぎの案内が必要になる場面も比べます。店舗で公開できる範囲を用意するか、代理担当へ渡すかなど、既存の判断に合う方法を検討します。承認を増やすほど安心と決めず、古い案内が残る時間や引継ぎの負担も比較材料にします。
結果は「使いやすかった」だけでなく、対象、操作した役割、期待した表示、実際の結果で残します。試した操作で不足が見つかったら、権限の調整で足りるのか、入力項目の追加が必要か、個別サイトを残した方がよいかへ戻します。統合すること自体を合格条件にしないようにしましょう。
比較表から、今回まとめる範囲を決める
一つのサイトへ集約する案は、店舗の探し方や共通情報をまとめやすい一方、店舗別の操作をその構成で実現する必要があります。別サイトを共通環境で管理する案は、保守をそろえられる部分がある一方、共通機能を変える影響や、既存機能の対応状況を確かめる必要があります。
サイトを残して管理方法をそろえる案も、比較対象に入れます。独自の受付機能が必要な店舗を急いで移すより、情報の更新元と担当、反映先を先に整理する方が進めやすい場合があります。ただし、手作業で複数の掲載先を直す負担が残るなら、その量も費用と合わせて示します。
制作会社へ渡す資料は、サイト一覧、現在の更新画面、機能比較表、店舗で必要な操作の例です。「本部の共通説明は一度で更新したいが、各店の臨時案内は自店で出したい」のように、まとめたい作業と残したい操作を並べると、改修範囲を具体化できます。
採用する案には、実現できた操作と未解決の条件を添えます。URLが変わる場合の移行や、共通部品の保守範囲は、その案に応じて別途確認します。まず必要な更新が継続できるかを確かめ、成立した範囲から構成と費用を決めることが、統合後も店舗が使えるサイトにつながります。
参考にした公開情報
2026年9月21日確認。WordPressの説明は構成による違いの具体例として参照しています。自社の追加機能や独自設定を含む操作範囲は、個別に確認してください。
