はじめに：作業前に必ず読む3つの原則
このマニュアルは、WEBサイトを1つ公開するまでの流れを順番に説明します。専門用語は本文中でそのつど補足し、末尾に用語集もあります。まず、制作を通して守り続ける3つの原則から確認してください。
📌 原則1
設計が全て。時間をかける。
手を動かす（コーディングする）前に、サイトマップ・ワイヤーフレーム・デザインで作るものを固めきる。設計であいまいなまま進めると、後工程での作り直し（手戻り）が必ず発生します。「早く作り始める」より「設計に時間をかける」方が、結果的に速く終わります。
📌 原則2
一人で決めない。実装方法は必ず会議で決める。
使用する技術・ライブラリ・実装の方針を独断で決めてはいけません。必ず会議で共有し、合意を取ってから進めます。判断に迷ったら止まって相談する。これは 報告・連絡・相談 と 決裁ルール の考え方と同じです。会議の進め方は 会議・MTG を参照してください。
📌 原則3
重複を作らない。共通化できるものは共通化する。
同じ見た目・同じ処理を各ページにコピーして貼らない。ヘッダー・フッター・ボタン・カードなど、繰り返し使うパーツは共通コンポーネントとして1か所にまとめ、各ページから読み込みます。1か所を直せば全ページに反映される状態を保つことが、品質と修正スピードにつながります。（この考え方を DRY ＝ Don't Repeat Yourself と呼びます）
🎯 このマニュアルのゴール
ヒアリングで要望を正しく引き出し、設計で作るものを固め、共通化しながら制作し、テストを経て Firebase Hosting で公開できる状態になること。
⑤ 制作（コーディング）と共通化
設計で決めたとおりに、HTML（構造）・CSS（見た目）・JavaScript（動き）で実装します。ここで原則3「共通化」を徹底します。
📌 共通化のルール（DRY）
・同じ見た目・同じ処理を各ページにコピペしない
・ヘッダー／フッター／ボタン／カードなどの繰り返しパーツは1か所にまとめて共通コンポーネント化し、各ページから読み込む
・色・余白・フォントサイズなどの数値は、CSS変数などで1か所に定義して使い回す
・「同じ修正を複数ファイルに手作業で入れている」と感じたら、それは共通化できていないサイン
制作時のチェックリスト
- ディレクトリ構成（フォルダの分け方）を会議で決めた形に統一する
- Git でバージョン管理する（変更履歴を残し、いつでも戻せるようにする）
- 共通パーツはコピペせず、1か所を参照する形にする
- スマホ・タブレット・PCで崩れないレスポンシブ対応にする
- 画像は表示速度のために適切なサイズ・形式に最適化する
- 命名規則（クラス名・ファイル名の付け方）をチーム内でそろえる
⚠️ 迷ったら止まって相談
「この実装で合っているか」判断に迷ったら、自己判断で進めず会議・報連相で確認する。手戻りを防ぐ一番の近道です。
⑥ コンテンツ投入・SEO・構造化データ
SEO（検索エンジン最適化）とは、Google などの検索結果で見つけてもらいやすくするための設定です。原稿・画像を入れたら、次の項目を各ページに設定します。
各ページに必ず設定する
| 項目 | 役割 |
|---|
title | 検索結果やタブに出るページのタイトル。ページごとに変える |
meta description | 検索結果に出る説明文。ページごとに変える |
| OGP（og:title / og:image 等） | SNSでシェアされたときに出るタイトル・画像 |
| favicon | タブに出る小さいアイコン |
| JSON-LD（構造化データ） | ページの内容を検索エンジンに正確に伝える。下記参照 |
JSON-LD 構造化データ
構造化データとは、「このページは会社情報」「これはよくある質問」といったページの意味を機械が読める形で書いたものです。Google が推奨する書き方が JSON-LD で、<script type="application/ld+json"> の中に書きます。正しく設定すると、検索結果にパンくずやFAQなどが表示されやすくなります（リッチリザルト）。
📌 よく使う構造化データ（schema.org）
・Organization / LocalBusiness：会社・店舗の名前・住所・電話・ロゴ
・BreadcrumbList：パンくずリスト（トップ > サービス > …）
・WebSite：サイト名・サイト内検索
・Article / BlogPosting：記事・ブログ
・FAQPage：よくある質問
⚠️ 実装したら必ず検証する
JSON-LD を書いたら、Google の「リッチリザルト テスト」でエラーが出ないか確認してから公開する。書いた内容とページの実際の表示は必ず一致させること（虚偽の情報はペナルティ対象）。
🎯 実装方法は会議で決める
どのページにどの構造化データを入れるか、雛形をどう共通化するかは、一人で決めず会議で方針を合わせてから実装します（原則2・原則3）。
⑧ 公開・デプロイ（本命：Firebase Hosting）
完成したファイルをインターネット上に置いて、誰でも見られる状態にすることを「公開（デプロイ）」と言います。当社の標準は Firebase Hosting です。
Firebase Hosting の公開手順
1
プロジェクト準備
Firebase コンソールでホスティング先のプロジェクトを用意する（既存の運用ルールに従う）。
2
初期設定
firebase login → firebase init hosting で公開するフォルダ（例：public）を設定する。
3
デプロイ
firebase deploy を実行。*.web.app の仮URLで公開され、まず動作確認できる。
4
独自ドメイン接続
Firebase コンソールの「カスタムドメインを追加」から、案件のドメインを接続する。表示される認証用の TXT レコードと、A / AAAA レコードをドメイン側（バリュードメイン）に設定する。→
ドメインカード参照。
5
SSL（https）自動発行を待つ
Firebase が SSL証明書を自動発行するので、https:// で正しく表示されるまで待つ（反映に時間がかかる場合あり）。
6
公開後チェック
独自ドメイン・https で全ページが正しく表示されるか、スマホでも確認する。
⚠️ Xserver を使う既存案件の場合（補足）
既存でエックスサーバーを使っている案件では、サーバーパネルでドメインを追加 → ファイルをアップロード → 無料独自SSLを設定、という流れになります。新規案件は原則 Firebase Hosting を使います。どちらにするかは会議で決めること。
分岐：ドメイン（当社標準＝バリュードメイン）
ドメインとは example.com のような「サイトの住所」です。当社はレジストラ（ドメインを管理する会社）としてバリュードメインを標準で使います。案件によって、次の3つのケースに分かれます。
ケースA：新規取得
- バリュードメインで希望のドメイン名が空いているか検索し、取得する
- 名義（顧客名義／自社名義）を契約どおりに設定する
- 取得後、公開先（Firebase）に合わせてDNS（A / AAAA / TXT）を設定する
ケースB：他社からの移管
他社で管理しているドメインを、バリュードメインに移してくるケースです。移管には時間がかかるため、公開スケジュールに余裕を持って着手します。
- 移管元で認証コード（Authコード / EPPコード）を取得する
- 移管元でレジストラロック（移管ロック）を解除する
- ドメインのWhois連絡先メールが受信できる状態にする（承認メールが届く）
- ドメインの有効期限が近すぎないことを確認（期限間近は失敗しやすい）
- 移管完了まで数日かかる。完了後にDNSを設定する
ケースC：既存ドメインをそのまま使う（移管しない）
ドメインは今のレジストラのまま、公開先だけ新サイト（Firebase）に向けるケースです。DNS（ネームサーバーやレコード）の変更だけを行います。
- 現在のドメイン管理画面にログインできるか（ID/PW）を確認する
- Firebase が指定する A / AAAA / TXT レコードを設定する
- 反映（DNSの浸透）に時間がかかることを見込む
⚠️ 事故が一番多いポイント
ネームサーバーごと切り替えると、そのドメインで使っているメール（MXレコード）も一緒に切り替わり、メールが止まることがあります。既存メールを使っている場合は、ネームサーバー変更ではなく
必要なレコードだけを変更し、MXレコード（メール設定）を引き継ぐこと。→ 次の
公開ケースで詳しく説明します。
分岐：新規公開 と リニューアル公開
ケース1：新規公開（既存サイトなし）
既存サイトがないため、切り替えの心配が少ないケースです。ドメインを設定し、Firebase にデプロイして公開します。公開後の表示確認をして完了です。
ケース2：リニューアル公開（既存サイトあり）
今動いているサイトを、新サイトに切り替えるケースです。切り替え中にサイトが見られない時間（ダウンタイム）や、メールが止まる事故が起きやすいため、特に慎重に進めます。
📌 リニューアル時の必須チェック
・メール（MXレコード）を止めない：既存ドメインでメールを使っている場合、DNS切替でメールが止まらないよう、MXレコードを必ず引き継ぐ
・301リダイレクト：旧ページのURLが変わる場合、旧URL→新URLへ転送を設定し、検索評価とブックマークを引き継ぐ
・切替タイミング：アクセスの少ない時間帯に切り替え、直後に全ページ・フォーム・メールを確認する
・切り戻し手順：問題が起きたときに元へ戻せる手順を、切替前に用意しておく
⚠️ 切替は一人で実行しない
リニューアルの切替は影響が大きい作業です。手順を会議で共有し、2人以上で確認しながら実行すること（原則2）。
