CMS・サーバー・ドメインの決め方

実装で発注側が決めることは、技術の選択ではありません。「誰が、どこを、どうやって触るか」の割り振りです。 WordPressにするかどうか、どのサーバーを使うかは、制作側が決めればよいことです。発注側が決めないと誰も決められないのは、更新できる範囲・フォームの届き先・契約名義・速度の合格ライン・更新作業の担当の5つだけです。 この章は、その5つを○×の付く形にし、公開後に「触れない」「届かない」「止まった」が起きない状態で実装に入るための章です。

この章で分かること

• CMSで自社が触ってよい範囲の決め方（「管理画面から全部」が×である理由）
• フォームの送信先・保管・自動返信の決め方と、届かないフォームが生まれる仕組み
• ドメインとサーバーの名義、速度の合格ライン（数字）、更新作業を誰が持つか

発注側が実装で決めるのは5つだけ

2章で埋めた5枚の表を、そのまま実装の仕様に落とします。追加で決めるのは次の5つです。

決めること	決めないと起きること	決めるのは誰か
自社で更新できる項目	公開後に「その欄は触れません」と言われる	発注側（表3から）
フォームの送信先と保管	問い合わせが届かない・個人情報の置き場所が不明	発注側
ドメインとサーバーの名義	制作会社と連絡が取れなくなった瞬間に全部失う	発注側
速度の合格ライン	「重い」「いや普通です」の水掛け論になる	発注側（数字で）
更新作業（CMS本体・プラグイン）の担当	放置され、改ざんの対象になる	発注側と制作側の取り決め

技術の指定は不要です。 「Next.jsで作ってほしい」「◯◯というプラグインを使ってほしい」と指定すると、後で直せる会社が減ります。指定してよいのは、社内に触れる人がいる場合だけです。

CMS：触ってよい範囲を、項目名で書く

2章の表3で「CMSを入れる」と決めた場合、次に決めるのはどこを入力欄にするかです。ここを曖昧にしたまま納品されると、必ずどちらかになります。触れなさすぎるか、触れすぎて壊すかです。

触り方	対象になる項目	壊れるか
専用の入力欄で更新する	お知らせ・実績・社員紹介・価格・よくある質問	壊れない（推奨）
文章だけ書き換える	各ページの本文	ほぼ壊れない
レイアウトを自由に組める	トップページの構成	壊れる。渡さない
テーマ・プラグインの設定	サイト全体	壊れる。渡さない

仕様書に書く形は「管理画面から更新できます」ではなく、項目名の一覧です。

お知らせ（タイトル・日付・本文・画像1枚）／実績（業種・課題・やったこと・結果・写真3枚まで）／社員紹介（氏名・部署・写真・コメント）／価格（金額のみ）

当社は更新頻度の高い項目だけを専用の入力欄にし、ページ構成やデザインは触らせない形で作ります。プラグインを増やさない作りにするのも同じ理由で、プラグインが多いほど、更新のたびに壊れる確率が上がるからです（WordPress構築 80万円〜・2ヶ月〜）。

操作説明の予定も、この段階で書面にしてください。 当社は公開前に1時間ほど操作説明を行い、手順書も渡します。手順書が無いまま納品されると、担当者が代わった瞬間に更新が止まります。

フォーム：この章で一番事故が多い場所

問い合わせが届かないサイトは、珍しくありません。フォーム自体は動いていて、送信完了画面も出るのに、メールだけが届かないという壊れ方をするためです。原因はたいてい次のどれかです。

原因	起きること	先に決めておくこと
送信先が制作側のテスト用アドレスのまま	発注側に1件も届かない	本番の宛先を書面で指定する
送信先が個人のアドレス1つだけ	その人が休むと止まる。退職で消える	共有アドレス＋個人の2か所にする
迷惑メールに入る	届いているのに気づかない	公開前に実送信し、迷惑メールも見る
自動返信の文面が仮のまま	会社名や署名が違う状態で客に届く	文面を発注側が確認する
受信側で誰も対応を持っていない	届いても返信されない	対応する担当者名を決める

決めるのは4つです。

決めること	合格の状態
必須項目	「無いと返信できないもの」だけ。数が決まっていて、理由が言える
送信先	届くメールアドレス（共有＋個人）と、対応する担当者名
自動返信	出す／出さない。出すなら文面と、返信までの日数が書いてある
データの保管先と期間	管理画面に残すのか、メールだけか。何年置くか

4つ目を飛ばさないでください。 フォームを置く以上、氏名・連絡先という個人情報を預かります。「どこに何年置いて、誰が消すか」を決めていないと、退職者のメールボックスの中だけに顧客情報が残ります。管理画面に保存する設定なら、保存期間と削除の担当も決めます。

必須項目は少ないほど送信されます。会社名・氏名・メールアドレス・用件の4つで足りることがほとんどです。電話番号を必須にすると送信数は落ちますが、電話で返したい業種なら合理的です。増やす／減らすの判断は「返信できるか」だけで決めてください。

ドメインとサーバー：名義と金額

項目	決めること	当社の勧め
ドメインの契約名義	誰の名義で契約するか	発注側の名義。 管理の代行は可
ドメインの年額	いくらか、支払いは誰か	.jp や .com で年数千円程度が一般的
サーバーの契約名義	誰の名義か	発注側の名義
サーバーの月額	いくらか	共用サーバーなら月1,000円台で足りることがほとんど
管理画面のID	誰が持つか	発注側が持ち、制作側にも渡す

名義が制作会社にあると、その会社と連絡が取れなくなった時点で、サイトとメールを同時に失います。 これは技術の問題ではなく契約の問題なので、後から直すには相手の協力が要ります。実装に入る前に確認してください（4章の点検リスト5と同じ項目です）。

メールも同時に確認します。サイトとメールが同じサーバーで動いている場合、サーバーを移すとメールも止まります。 10章の切り替えで最も損害が大きい事故がこれです。今の構成を先に把握しておきます。

速度とスマホ：数字で合格を決める

「速いこと」は仕様になりません。次の3つの数字を仕様に書きます。

指標	合格ライン	何の速さか
LCP	2.5秒以下	主要な内容が表示されるまで
INP	200ms以下	押してから反応するまで
CLS	0.1以下	表示中にレイアウトがずれない

測るのは PageSpeed Insights で、見るのはモバイルの実データです。公開直後は実データが無いため、その場合はラボのスコアで代用し、公開30日後にもう一度測ります。測り方と、画像・サーバー側の具体的な直し方は SEOの教科書2章に譲ります。 同じ表を2冊に書きません。

スマホ対応は「スマホ用のページを別に作る」ことではありません。同じURLで、画面の幅に合わせて表示が変わる形にします。確認は実機で行います（9章）。

セキュリティとバックアップ：担当を名前で決める

決めること	合格の状態	決めないと
HTTPS	鍵マークが出る。証明書の更新方法が決まっている	「保護されていない通信」と出て、フォームが送られない
バックアップの頻度	日次か週次か。どこに残るかも	壊れた日に戻せない
復旧の手順と担当	誰が、何分で戻すか	誰も戻せないバックアップになる
CMS本体・プラグインの更新	担当者名か、保守契約の範囲に書いてある	改ざんの対象になる
問い合わせ窓口	障害時に連絡する先と、受付時間	落ちた夜に連絡先が分からない

バックアップは「取っている」だけでは不合格です。 戻せることを1回試して初めて○になります（12章の点検リスト6で、実際に試した日付を求めています）。

更新の担当は、保守契約に含めるか自社で持つかの二択です。自社で持つなら、月1回の更新作業を誰かの業務として決めます。「気づいた人がやる」は、誰もやらないのと同じです。

頼まないほうがよい実装

制作側に頼まず、既製のサービスで足りるものがあります。作り込むほど、直せる人が減ります。

やりたいこと	作り込む前に	判断
予約を受け付けたい	予約サービスを埋め込む	月数千円で足りるなら、作らない
決済したい	既製のECサービスを使う	決済とセキュリティを自前で持つ理由が無ければ、作らない（3章）
会員機能が欲しい	使う人の名前が言えるか	言えないなら作らない
多言語にしたい	問い合わせが来ているか	来ていないなら後回し
チャットを置きたい	応答する人がいるか	いないなら置かない（無人のチャットは信用を下げる）

判断の基準は2章の表4と同じです。「使う人の名前と、運用する人の名前が言えるか」。 言えない機能は、作った日が一番きれいな日になります。

よくある間違いを5つ

「管理画面から全部更新できるようにしてほしい」 ——全部触れる状態は、全部壊せる状態です。レイアウトを崩した状態で数日公開されることがあります。直し方：更新したい項目を名前で挙げる。挙げた項目だけを入力欄にしてもらう。

「フォームは動いているから大丈夫」 ——送信完了画面が出ることと、メールが届くことは別です。テスト用の宛先のまま公開された例は実際にあります。直し方：公開前に、発注側が自分で実送信する（9章の必須項目3）。届いた／自動返信が来た／文面が正しい、の3つを確認する。

「サーバーは制作会社に任せる」 ——任せるのは管理であって、名義ではありません。名義まで渡すと、契約の更新も移転も相手の同意が要ります。直し方：名義は自社、管理は代行、のセットにする。請求書の宛名で確認できる。

「速いかどうかは見れば分かる」 ——作る側の回線と端末では速く見えます。読み手は電波の悪い場所でスマホから開きます。直し方：PageSpeed Insights のモバイルで測り、LCP 2.5秒以下を仕様に書く。数字なら揉めない。

「プラグインで機能を足せばいい」 ——足すほど、更新のたびに壊れる確率が上がり、脆弱性の入口も増えます。公開後に「更新すると壊れるので更新しない」状態になると、最悪です。直し方：プラグインを足す前に、使う人と運用する人の名前を言う。言えないものは足さない。

この章の出口

この章を終えたとき、手元に残っているべきものは3つです。

1. 更新できる項目の一覧（項目名で書かれていて、触ると壊れる場所と分かれている）
2. フォームの4点（必須項目・送信先・自動返信・保管先と期間）
3. 名義と数字（ドメイン・サーバーの契約名義、速度の合格ライン、更新作業の担当名）

ここまでで「決める」と「作る」が終わりました。次は出す工程です。ただし、作る側が「できました」と言った時点では、まだ公開してはいけません。 発注側が自分の手で確かめる検査が要ります。この本で最もよく使われるのが、次の章です。

次の章へ：9章 サイト公開前のチェックリスト｜受入検査