📚 ナレッジベース

01-02_制作過程

最終更新 2026年08月25日／ 21_ナレッジベース/マニュアル_ナレッジ/制作部署/01-02_制作過程.md

出典: 制作部署マニュアル制作過程（自動ミラー・正本は /Users/oogushiyuuki/manual-terasu）

この章の目的：TERASUの「作り方」を1本の道にする

HP制作は「センスのある人がゼロから絵を描く」仕事だと思われがちだが、TERASUは違う。良い参考HPを土台にして、それを壊さず再現 → 自社のコードに作り替え（著作権対応）→ 案件の中身を流し込み → プレビューで共有しながら磨き → スマホを整え → 著作権を最終チェック → 資産として蓄積 → 公式ドメインで公開、という決まった道を通る。この道のことを TERASU では /hp-flow（HP制作フロー）と呼んでいる。

制作未経験でも、この12ステップを順番にこなせば「集客できるHPが公開された状態」までたどり着ける。それがこのフローの狙い。

なぜ「決まった道」にするのか。理由は3つ。

退化・事故を防ぐ：作り替えの途中で「ボタンが押せなくなる」「レイアウトが崩れる」事故を、手順で物理的に潰す。
著作権を守る：参考HPの痕跡を残したまま公開すると著作権侵害になる。二重のチェックで痕跡をゼロにする。
集客まで持っていく：作って終わりにせず、SEO設定・公式ドメイン公開まで一気通貫でやる。

この章では、各ステップで「何をするか・なぜそうするか・どう判断するか」を具体例つきで解説する。

全体像（12ステップ早見表）

まず全体を頭に入れる。12ステップは大きく4つのフェーズに分かれる。

Step	内容	フェーズ
1	全ページ一括でコードを抜き出し＋ダミー化（参考HPを完全コピー・文字は同じ長さのダミー・画像と構造はそのまま）	制作
2	抜き出しの仕上げ（量産ページの代表化・取りこぼし補完・全ページ揃え）	制作
3	ローカルでプレビュー＋確認①（元HPと完全に一致しているか）	制作
4	全ページ一括でTERASUオリジナル化（命名を作り替え・置換漏れゼロ）＋確認②（Step3から見た目が変わってないか）	著作権
5	案件依頼書の中身を流し込み＋SEO/問い合わせ向けのコピー作り＋GitHub立ち上げ・プレビューリンク発行	制作
6	改良ループ（デザイン・文言を磨く・ver管理＋複数パターン比較）	改良
7	スマホ最適化（PCを崩さずスマホ表示を整える→実機で確認依頼）	最適化
8	著作権最終監査（元サイトとバレる箇所をゼロに）	著作権
9	TERASU Labへセクション還元（良い部品を会社の資産として蓄積）	還元
10	納品前QAゲート（文言最終調整＋フォーム双方向疎通＋URL正規化/index設計＋信頼性ページ/誤字脱字＋プリフライト＋SEO内部対策）	QA
11	本番公開（公式ドメイン・DNS・SSL・`main`へマージ＋リニューアル時は旧URL→新URL 301移行）	公開
12	公開後SEO・実測検証・監視（Search Console/GA4＋テスト送信でキーイベント実測＋外形監視＋ドメイン/SSL期限）	SEO

大きな流れだけ覚えるなら「再現 → 作り替え → 中身入れ → 磨き → 公開」。Step1〜4はパソコンの中（ローカル）で作業し、Step5でGitHubを立ち上げてからは専用のプレビューリンクでクライアントや上長に見せながら進める。Step11で初めて公式ドメインに出る。

進行制御コマンド（全ステップ共通）

このフローは1ステップずつ進む。各ステップの終わりで、次のどれかを伝えれば進行をコントロールできる。

入力	動作
`次` / `OK` / `1`	次のステップへ進む
`やり直し` / `2`	今のステップをもう一度やる
`戻る` / `3`	1つ前のステップに戻る
`スキップ` / `4`	完了扱いにして次へ飛ばす
`終了`	中断する

迷ったら無理に進めない。確認①・確認②でOKが出るまでは次に進まないのが鉄則。「だいたい合ってる」で進めると、後の工程でズレが膨らむ。

着手前に：用途は「クライアント納品」か「デモ」か

/hp-flow を始めるときは、最初に「クライアント納品用」か「デモ用」かを決める。用途でルートが分岐する。

クライアント納品用：上の全12ステップをそのまま通す（一切省略しない）。
デモ用（制作実績として量産・TERASU HPに載せる用）：数を作るので簡略ルートにする。

	クライアント納品	デモ
作るページ	全ページ	トップのみ（他メニューは全リンク `href="./"` でトップに戻す）
中身の流し込み（Step5）	本番同様	本番同様（依頼書を作って流す）
GitHub立ち上げ（Step5）	あり	スキップ（ローカルプレビューのみで共有）
著作権監査（Step8）	必須	必須（外部公開物なので指紋ゼロは譲れない）
Lab還元（Step9）	あり	これが正式ゴール（公開しないのでLab還元が締め）
公開系（Step10-12）	あり	スキップ（ただしStep10の軽量チェック＝リンク切れ0・コンソールエラー0・全メニューがトップ遷移、だけは実施）

デモでも著作権監査（Step8）は省かない。制作実績として外部に見せる以上、元サイトの痕跡が残っていたら事故になる。
デモが完成したら（Step9のLab還元時）、プレビューリンクを「サイト管轄の担当」へ必ず送る。これでTERASU HPのデモ枠への載せ漏れを防ぐ。

Step1：全ページを一括で抜き出して「ダミー化」する

最初にやるのは、参考HPの全ページ（トップ＋会社概要・サービス・制作実績・お問い合わせ…）を一度にまるごとコピーすること。ページを1枚ずつ別作業で取るのではなく、最初に全部まとめて取る。共通の素材（CSS・JS・画像・フォント）の補完が1回で済み、後の作り替えも全ページ一貫してできるからだ。

「完全コピー」が一番の難所

参考HPを取ってくるとき、wgetという取得ツールを使うが、これ一発ではJavaScriptで動くサイトは半分くらいしか再現できない。実際の案件（mont.jp）では初回は5割しか再現できなかった。原因は決まっていて、次の3つが取りこぼされる。

クエリ付きのCSS/JS：page-top.css?240424 のように ? が付いたファイルは取得ツールが落とさない。ここを取りこぼすと、トップ専用のデザインが丸ごと消えてファーストビューが全崩れする。
JavaScriptが後から読み込む画像・SVG：ロゴやアイコンなど、コードの中で文字列として組み立てられるパスは見つけにくい。ブラウザで開いて「読み込み失敗（404）」を全部拾うのが唯一の検出方法。
遅延読み込みの動画：data-src-pc のような仕掛けで後から読み込まれる動画も、取得ツールは辿らない。

ここを省くと「5割の完成度」のまま進んでしまい、後でやり直しが大量発生する。時間がかかっても、ここで完全に詰めるのが、結果的に一番早い。

「ダミー化」とは何か・なぜやるか

完全コピーしたら、文字だけを「同じ長さのダミー文」に差し替える。画像と構造はそのまま残す。これを「ダミー化」と呼ぶ。

見出し「自然素材の家づくり」→「ダミー見出しテキスト一」（見出しらしい長さ）
本文が3行なら、ダミーも3行分の長さにする
ボタン「お問い合わせ」→「ボタン文言」（短く）

なぜ文字をダミーにするのか。この段階のゴールは「元HPと見た目がそっくりか」を確認できる状態を作ることだから。実際の文字数・行数のダミーを入れておけば、レイアウトが崩れていないか一目で分かる。

空っぽにする・{{KEY}} のような穴あきにするのは禁止。空にするとレイアウトが崩れているのか元からそうなのか判断できなくなる。「実物大のダミー」で「見た目が元と一致」を作るのがこのステップの正解。

そして画像は元のものをそのまま残す。画像がないとデザインが何も分からないからだ。ただしこれは制作途中の暫定措置で、Step5で案件の画像に差し替え、Step8で「元画像がゼロ」になっていることを必ず確認する。最終的な納品物に元画像は1枚も残さない。

このとき、class名・id名（HTMLの部品につける名前）も元のままにしておく。名前の作り替えはStep4でまとめてやる。先に「完全再現」を確定させてから作り替える、という順番が崩れ防止の核心。

Step2：抜き出しの仕上げ

Step1で構造の違う全ページを取り終えた前提で、Step2は仕上げを担う。

量産ページの代表化：制作実績が110件あるような「同じ型のページが大量にあるサイト」は、全部を作る必要はない。1枚をテンプレートとして代表化する。
取りこぼしの補完：ブラウザで開いて「読み込み失敗（404）」がゼロになるまで、欠けた素材を補う。
全ページが揃ったか最終確認：ページの順番・ファイル名・フォルダ構造を元と完全に同じにする。ページ間のリンク（押すと別ページに飛ぶ仕掛け）の構造も元のまま維持する。

処理ルールはStep1と同じ。文字は同じ長さのダミー・画像は元のまま・名前は元のまま。

Step3：ローカルでプレビュー＋確認①（元HPと一致しているか）

ここで初めて「作ったもの」を画面で見る。自分のパソコンの中（ローカル）でプレビューを立てる。python3 -m http.server という簡単なコマンドでローカルにHPを表示できる。Cloudflare（公開用の枠）はまだ使わない。枠を無駄に消費しないためだ。

そして確認①を行う。参考HPと作ったプレビューを並べて見比べて、完全に同じになっているかをチェックする。

[ ] レイアウト・余白が元と同じ
[ ] フォント・文字サイズが同じ
[ ] 配色が同じ
[ ] アニメーション・動きが同じ
[ ] ボタン・リンク・メニューが正常に動く
[ ] スマホ表示が崩れていない

この確認①でOKが出た状態が「完全再現の基準点」になる。Step4で作り替えたあと、この基準点と比べて「壊れていないか」を判定するので、ここを曖昧にしてはいけない。違う箇所があれば、OKが出るまで直す。

プレビューを共有するときは、必ずタップして開けるリンクで渡す（[再現版プレビュー](http://localhost:8000/) の形式）。URLをそのまま貼ると、チャットでタップできず相手が開けないからだ。修正するたびにプレビューを立て直して、最新のリンクを共有する。「直したらプレビュー共有」までが1セット。

Step4：TERASUオリジナル化（著作権ゲート①）＋確認②

ここが著作権対応の1つ目のゲートであり、フロー全体で一番重要なステップ。

なぜオリジナル化が必須なのか

参考HPのコードをそのまま使うと、著作権侵害になる。TERASUは「WordPressではない、自社で書いた静的サイト」として営業している。コードに参考元の痕跡が残っていると、技術に詳しい顧客がソースコードを見たときに矛盾する。だからコードの「指紋」を全部消して、TERASU独自の作りに変える必要がある。

大原則：「コードだけ変える・見た目は1ミリも変えない」

ただし、ここには絶対に守るべき大原則がある。

参考HPの構成・デザイン・アニメーションを崩さずにオリジナル化する。

参考HPを選んだ理由は「そのデザイン・構成・動きが良いから」。それを崩したら参考にした意味がなくなる。変えていいのは「コードの書き方（名前・構造の表現）」だけ。見た目と動きは1ミリも変えない。オリジナル化の本質は「コード指紋の除去」であって「デザイン改変」ではない。ここを混同してはいけない。

置換漏れゼロ方式（ボタンが押せなくなる事故の防止）

名前を作り替えるとき、一番怖いのが「HTMLでは名前を変えたのに、その名前を使っているCSSやJavaScriptを変え忘れて、ボタンが押せなくなる」事故。これを防ぐため、必ずこの順序でやる。

手順1：リネームマッピング表を先に作る。「旧名→新名」を一覧化する（例：hero → t-hero、nav-menu → t-nav-menu）。TERASUでは部品の名前を t- で始める決まりになっている。
手順2：1つの名前を、出てくる全ての場所で同時に変える。HTML・CSS・JavaScriptの3つを1セットで扱い、heroという名前ならHTMLのclass="hero"もCSSの.heroもJavaScriptのquerySelector('.hero')も全部同時にt-heroに変えてから、次の名前へ進む。
手順3：grep（文字検索）で機械チェック。古い名前が1個も残っていないか、コードを横断検索して確認する。

置換漏れチェックの要点
- [ ] 古いclass名・id名・変数名が1個も残っていない
- [ ] CSSの全ルールに対応するHTML要素が存在する（行き場のないルールがない）
- [ ] JavaScriptが操作しようとする要素が全部存在する
- [ ] ボタン・リンク・メニューが全部正常に動く（一番事故が出やすい箇所）

着手前に「結合度」を判定する（密結合は無理に改名しない）

サイトによっては、一律（blanket）でclass名を t-* に改名すると壊れるものがある。だから着手前に「結合度」を見極める。

素直に改名できるサイト：手書きのHTML/CSS/JSで、名前の対応が追える → これまで通り全名称を t-* に改名。
密結合バンドル（minifyされた塊・ノーコードツール生成・data-*駆動・JSが動的にクラスを生成・汎用クラス名）：blanket改名は破壊リスクが高いので既定で見送る。代わりに Stage A を必須でやる。
ルート構成のフラット化、ビルドハッシュ名（app.a1b2.css 等）→中立名（app.css）に
トラッキング・メタ・CMS・元ドメインの指紋を全除去
CSS変数だけ --t-* に改名（安全に変えられる範囲に絞る）

「全部 t- に変える」を機械的にやらない。動いているものを壊さない範囲で指紋を消すのが目的。判定を誤ると確認②で崩れる。

何を作り替えるか（主な項目）

名前のリネームに加え、コードの「指紋」を消すために次のようなことをする。すべて「見た目は変えない」前提で行う。

命名系：class・id・CSS変数・JavaScriptの変数や関数名を全部 t- / TERASU命名にする。ファイル構成も /css/main.css・/js/app.js・/images/ のTERASU標準に揃える。
構造系：コメントや著作表記を全部消し、代わりにTERASU独自のコメントを足す（無コメントは逆に不自然なので、自然な設計コメントで「TERASU色」を出す）。CSSやJavaScriptの並び順をTERASU標準に組み替える。
スタイル系（数値は変えず書き方だけ）：margin: 24px を等価な margin: 1.5rem に、色コード #FF5733 を同じ色の別表記に変える。見た目は完全に一致したまま、コードの表現だけ独自化する。
CMS痕跡の除去：参考元がWordPressやWix等で作られていた場合、wp-polyfill・wp-content・プラグインのCSSなど「CMSの指紋」がコードに残る。動作に不要なこれらは全部消す。media/2023/12/ のような「アップロード日が残るフォルダパス」も指紋なので、中身を移動してパスを書き換える。

確認②：Step3から「完全に同じ」か

作り替えたら、Step3のプレビューと並べて見比べる。ここは「ほぼ同じ」では不合格。「完全に同じ」でないと先に進まない。構成・デザイン・アニメーション・インタラクション・スマホ表示のすべてを、Step3の基準点とコマ送りレベルで照合する。

もし少しでも崩れていたら、それは大原則違反。リネームマッピング表と照合して漏れた箇所を特定し、直してから再確認する。壊れたまま進めない。これがTERASUの法的・ブランドリスクを守る防衛線の1つ目。

Step5：案件の中身を流し込み＋GitHub立ち上げ

ここで「ダミーのHP」が「本物の案件のHP」に変わる。

守ること・やること

守ること（変えない）：HTML構造・CSS・レイアウト・フォント・色・アニメーション・JavaScriptの動き・リンク先。これらは触らない。

やること（中身を入れる）：
- テキスト差し込み：Step1-2で入れたダミー文を、案件依頼書の実際の文章（見出し・本文・ボタン文言）に差し替える。文字数がHPの枠を超えそうなら「○文字オーバーします」と事前に報告してから判断を仰ぐ（黙って詰め込むとレイアウトが崩れる）。
- 画像差し替え（必須）：Step1-2で残しておいた元サイトの画像を、案件の画像・TERASUが用意した画像に全部差し替える。

ここで元画像が1枚でも残ると、Step8の著作権監査で止まる。元画像ゼロが必須条件。

文言は「ただ入れる」だけにしない（SEO・問い合わせ設計）

依頼書の文章をそのままコピペして終わり、にはしない。①検索で見つかるように（SEO）②問い合わせが増えるように（CV）、という2つの観点でコピーを磨く。ただしデザイン（レイアウト・文字数の枠）は崩さない範囲で言葉だけを強くする。

SEOキーワードから逆算：その案件で「取りたい検索キーワード」を決める（例「渋谷美容室」「税理士福岡」）。それを見出し（h1・h2）や本文の冒頭に自然に配置する。詰め込みすぎは逆効果なので、読んで自然な範囲で入れる。
問い合わせ導線（CV）の設計：ファーストビューで「何屋か・誰向けか・選ぶ理由」が3秒で伝わるキャッチを作る。ボタンの文言も「お問い合わせ」より「まずは無料でご相談」「30秒で相談予約」のように行動＋安心で書く。料金明示やよくある質問で、問い合わせ前の不安も消す。
重要な文言は複数案出して選ぶ：見出し・キャッチ・ボタン文言は1案で決めず、2〜4案出して「どれがいいか」選んでもらう。各案に「SEO寄り」「感情に訴える」などの狙いを一言添える。

配色・トーンの「大規模リスキン」を勝手にやらない。依頼書に「ダーク基調」「高級感」などのトーン語があっても、それはコンテンツ・コピーの方向性であって、参考HPのデザイン（明暗構造・セクション配色・レイアウト）を作り替えてよいという許可ではない。流し込み（Step5）も改良（Step6）も参考デザインの忠実保持が大原則。配色反映は「アクセント1色の差し替え」など局所に留め、大きく変えたいときは着手前に1問確認するか、1セクションだけサンプルを見せてOKをもらってから展開する。

GitHub立ち上げ・専用プレビューリンク発行

依頼書を読んで会社名／HP名が確定するのがこのタイミング。ここでGitHubのリポジトリ（コードの保管・履歴管理の置き場）を作り、専用のプレビューリンクを発行する。以降の改良はすべてこのプレビューリンクで共有しながら進める。

仕組みはこうだ。

会社名から名前を決める（例：株式会社ハナミ → client-hanami）。
GitHubにリポジトリを作り、preview という作業用のブランチ（並行作業の枝分かれ）にコードを置く。
すると https://preview.client-hanami.pages.dev のような専用プレビューURLが自動で発行される。これがクライアントや上長に見せる「今の確定版」になる。
以降、git push（コードを送る操作）をするだけで、約30秒でプレビューが自動更新される。バックアップ・履歴・ver管理が全部自動になる。

この仕組みのおかげで、修正するたびに手作業でデプロイする必要がなくなる。「直す → push → 30秒で反映 → リンク共有」がワンセットで回る。なお初回のCloudflare連携設定は1回やれば全案件に自動で引き継がれるので、2件目以降の初期設定は人の手がゼロになる。

Step6：改良ループ（ver管理＋複数パターン比較）

ここからはデザインと文言をどんどん磨くフェーズ。「ここの余白を広げて」「CTAをもっと目立たせて」といった改善要望を受けて、HPを良くしていく。このフェーズには事故を防ぐ3つの決まりがある。

改良の肝：「なぜ良いか」を言語化してから触る

改良ループはこのフロー全体で一番難しい。完成度の高い参考HP（100点）を「崩してさらにプラスに持っていく」必要があるからだ。ここで品質と著作権の両方が決まる。

触る前に必ず「なぜ良いと思うか」を言語化する。これが肝。良さの理由が分からないまま触ると、良い部分まで壊してしまう。
「良い」と思った部分は変えない。そこを変えると、かえってダメなHPになる。
逆に、「ここは他のHPでもよくある」「必須ではない」部分を変えていく。これがパクリに思われず、かつ質の高いHPにする秘訣。
いいHPの良い部分を組み合わせて8割完成まで持っていき、残りは細かい気になる箇所を微修正する。

ゴールは「元と全く同じ箇所を残さない／パクリに見えない」状態。良いデザイン・コードを組み合わせて、崩して、ひたすら整える——これがTERASUの改良。

ver管理：修正のたびにgitに記録する

修正・採用のたびに git commit（記録）する。小さなtypo直しでも記録する。理由は「細かく巻き戻せるようにするため」。
git の履歴がそのままバージョン管理表になる（誰が・いつ・何を、が自動で記録される）。手書きのバージョン表やtar.gzバックアップは不要。git履歴がバックアップそのものになる。
「verいくつに戻して」「さっきの状態に戻して」と言われたら、git で一発。履歴から対象を探して git revert（その変更だけ安全に取り消し）して push すれば、約30秒で戻る。

複数パターン提示：ラリーを減らす

デザイン変更・アニメ変更・レイアウト変更の依頼が来たら、1案だけ出さず、極力2〜4パターン作る。別のブランチやURLパラメータ（?variant=A/B/C）で出し分けて、「どれがいい？」と選んでもらう。

「1個出す → 違う → また1個出す → 違う」の無限ラリーを禁止する。複数パターンを一度に見せて選んでもらう方が、やり取りの往復が激減する。採用が決まったら、その1案だけをpreviewブランチに統合し、使い捨ての候補ブランチは捨てる（本体を汚さない）。

本番ドメインでは絶対に試行錯誤しない

改良は全部 preview ブランチで行う。公式ドメイン（mainブランチ）では一切いじらない。本番反映はStep11（公開）まで待つ。ミスった修正が公開中のHPに出る事故を防ぐためだ。

Step7：スマホ最適化

デザインが固まったら、SEO・公開の前にスマホ表示を整える。今やスマホからの閲覧が大半なので、これは必須ステップ。

最大のリスクは「PCが崩れること」

スマホ最適化の唯一にして最大の事故は、スマホ対応で足したコードがPCのレイアウトを壊すこと。これを構造的に防ぐ。

スマホ用の調整は @media (max-width: …) という「画面幅が狭いときだけ効くカッコ」の中だけに書く。こうすればPC幅には絶対に影響しない。
既存のPC用ルールは書き換えない・消さない。
作業の前後で、PC幅（1440/1280）とスマホ幅（390/375）の両方でプレビューを確認し、PCが1pxも変わっていないことをスクリーンショットで照合する。

チェック項目

項目	内容
横スクロール	スマホ幅で横にはみ出していない
タップ領域	ボタン・リンクは最低44×44px・隣との間隔が十分
文字サイズ	本文は16px相当以上（小さすぎるとiOSが勝手に拡大する）
画像・動画	はみ出さず適切に縮む・重い画像は軽量化
メニュー	ハンバーガーメニューが正常に開閉する
PC不変	最適化の前後でPCの見た目が完全一致（最重要）

進め方：先に最適化してから確認依頼

順番が大事。先にスマホ最適化を済ませてから「スマホで見てFBください」と依頼する。最適化前に「確認して」と投げない。直してからプレビューURL（QRや直リンク）を案内し、実機で見てもらう。

Step8：著作権最終監査（著作権ゲート②）

公開前の最後の砦。コードの中に「元サイトだとバレる箇所」が1つも残っていないか、機械的に監査する。ここを通らないと公開ステップに進めない。Step4とこのStep8で、著作権を二重にチェックする設計になっている。

なぜ二重チェックなのか

Step4で一度オリジナル化しても、その後のStep5（中身流し込み）やStep6・7（改良・スマホ対応）で、新しく元サイトの痕跡が紛れ込む可能性がある。特にStep1で元画像をそのまま残す仕様にしているため、「Step5で全部差し替わったか」をここで最終確認することが極めて重要。だから公開直前にもう一度、痕跡ゼロを保証する。

監査A：コード指紋の機械チェック（grep）

文字検索（grep）で、次の痕跡が残っていないか全部確認する。

元画像の残存（最重要）：元サイトのドメイン・画像URL・元画像ファイル名が1個でも残っていたらアウト。全部が案件画像かフリー素材に差し替わっているか確認する。
古いclass名・id：t- で始まらない、参考元っぽい名前が残っていないか。
コメント・著作表記：Designed by Powered by などが残っていないか。
元サイト独自のCDN・トラッキングタグが残っていないか。
CMS痕跡：wp-polyfill などのWordPress痕跡や、media/2023/12/ のような日付パスが残っていないか。

文字検索（grep）だけでは見つからない指紋がある：ブランド名がアウトライン化（文字を図形に変換）されたSVGで埋め込まれていると、テキスト検索では0件でも残ってしまう（例：ロゴやマーキーの社名）。全インラインSVGを「viewBox・path数・縦横比」で走査し、pathが多い／横長のものを抜き出して画面に並べて目視し、元サイトの社名・ワードマークが残っていないか必ず確認する。

監査B：著作権リスクの目視チェック

チェック項目
元サイトの画像・イラスト・ロゴ・独自SVGを1つも使っていない
元サイトのテキスト・キャッチコピーが残っていない（言い換えただけのコピーもNG）
元サイトの独自キャラクター・ビジュアルモチーフを再現していない
class・id・変数が全部 `t-` / TERASU命名になっている
コメント・著作表記がコードに1つも残っていない
CMS痕跡（プラグインCSS・日付パス等）がゼロ
第三者が元サイトと並べて「真似」と感じない水準
提供画像・フォントのライセンスがクリア（商用利用可）

1つでも引っかかったら必ず修正する。クリアするまで公開（Step10以降）に進ませない。これがTERASUの法的・ブランドリスクの最終防衛線。

Step9：TERASU Labへセクション還元

完成したHPは、良い部品を会社の資産として蓄積して終わる。これがTERASU事業の肝。

なぜ還元するのか

良いアニメーション・デザイン・構成が「作って終わり」で流れてしまうのはもったいない。完成HPから良い部分をセクション単位（ファーストビュー・料金表・お客様の声…という部品単位）で切り出して、TERASU Lab（社内の部品ライブラリ）に登録する。

狙いは「1案件＝Labが1段強くなる」状態を作ること。次のHP制作で「あの時のファーストビューを使いたい」となったら、Labからコピペで即座に持ってこられる。全制作担当がこの蓄積を共有して、効率も品質も上がっていく。デモ案件こそ積極的に還元する（デモは公開ステップに進まないので、Labへの還元が実質ゴールになる）。

進め方

何をLabに入れるかは人間が決める。担当者が「この部分を登録したい」とスクリーンショットや動画で指定し、その箇所のコードを正確に切り出して登録する。登録するときの決まりは、

id（名前）に担当・日付を入れる：案件-種別-担当-日付（例 hanami-fv-saki-0615）。こうすれば何人が同時に登録しても名前がかぶらず、競合が起きない。
他のHPに貼ってすぐ動く「自己完結した部品」にする：色やクラスをLabの共通ルールに合わせ、外部依存をなくす。

登録してOKが出たら push するだけで、約30秒で公開ライブラリに反映される。

Step10：納品前QAゲート（公開してはいけない状態を構造的に潰す）

公開の直前に、「設定ミス」を1つずつ潰す関門。デザインの良し悪しより、ここの細かいミスの方が事故になりやすい。設定ミスは見た目に出ない＝サイレントな機会損失（フォームが届かない・検索除外が残る・URLが揺れて評価が分散…）だからだ。文言の最終最適化（見た目は変えない）＋フォーム疎通＋URL/index設計＋信頼性＋プリフライト＋SEO内部対策を、チェックリストで漏れなく通す。

文言の最終調整（デザインは1pxも変えない）

デザインとスマホが完全に固まったこの段階で、見た目を変えずに「文言だけ」を最終最適化する。Step5で入れたコピーを、SEOと問い合わせ（CV）の観点で総点検する。

SEOキーワードの最終チェック：titleの前半にメインキーワードが入っているか、h1（各ページ1つ）にメインキーワードがあるか、本文冒頭にキーワードが自然に出ているか。
問い合わせ導線の最終調整：キャッチ・ボタン文言・フォーム前の一文を、現状＋改変案2〜3個並べて選んでもらう。選んだ文言は同じ文字数枠で反映し、ボタン幅や改行が変わらないか確認する。

フォームの双方向疎通テスト（最重要）

問い合わせフォームは「送信できた風」でも裏で届いていないことがある。これが一番怖いサイレント機会損失。

双方向で確認：①ユーザー側に「送信完了」が正しく出る ②管理者／CRMに実際に着信する ——両方を実テスト送信で確認する。
スパム耐性：reCAPTCHA・honeypot（隠し罠）・CSRF対策・同一IPからの連投ブロック（例：5分に3回まで）を入れる。
入力体験：電話・メール・住所のバリデーション、郵便番号→住所の自動補完、スマホで入力欄をタップしても画面が勝手に拡大しない（入力欄のフォントを16px以上に）。

URL正規化・index設計

URL正規化：wwwあり/なしを片方に301で統一、末尾スラッシュを統一、HTTPS強制（HSTS）。ここが揺れると検索評価が分散する。
index / noindex 方針：検索に出すページ・出さないページ（サンクスページ等）を決め、sitemap.xml と矛盾がないか整合を取る。

信頼性ページ・誤字脱字の最終レビュー

信頼性ページ監査：プライバシーポリシー・運営会社・（必要なら）特定商取引法・監修者情報・公的リンクが揃い、2クリック以内で到達できるか。
誤字脱字の最終レビュー：全ページを通しで読み、誤字・脱字・表記ゆれをゼロにする。

必須の技術設定（プリフライト）

各ページに次を実装・確認する。専門用語が多いが、要は「検索エンジンとSNSにHPを正しく認識させる設定」。

[ ] title：各ページ個別・32字以内・キーワードを前半に・ブランド名を末尾に
[ ] meta description：各ページ個別・120字程度（検索結果に出る説明文）
[ ] OGP / Twitter Card：SNSでシェアしたときに出る画像・タイトル（og:imageは絶対URLで1200×630）
[ ] canonical：正規URLの指定（重複扱いを防ぐ）
[ ] favicon：ブラウザタブのアイコン
[ ] robots.txt：検索エンジンへの指示（開発用の「見せない設定」が残っていないか厳重確認）
[ ] sitemap.xml：全ページの一覧（検索エンジンに地図を渡す）
[ ] 404ページ：存在しないURLに来たとき用の専用ページ
[ ] 構造化データ：会社情報などを検索エンジンが理解できる形式で記述

公開前のNG最終チェック

1つでも該当したら公開しない。
- [ ] robots.txt が「全部見せない」設定になっていない
- [ ] 本番ページに noindex（検索除外）が残っていない
- [ ] OGPに開発用URLが残っていない
- [ ] <title>サンプル</title> のような穴埋め忘れがない
- [ ] デバッグ用の出力（console.log）が残っていない
- [ ] og:image が空・相対パスになっていない（絶対URLか）

Step11：本番公開（公式ドメイン・DNS・SSL）

いよいよ公式ドメインで本番公開する。ここで初めて公開用の枠（または顧客の本番環境）を使う。

公開は「previewをmainにマージするだけ」

GitHub運用なので、本番公開の操作はシンプル。今まで作業してきた preview ブランチを main ブランチに合流（マージ）させるだけ。main に送ると自動で本番デプロイされ、約30秒で公式ドメインに反映される。Step5で作ったリポジトリ・プロジェクトをそのまま使う。

カスタムドメイン接続とDNS設定

Cloudflareの管理画面でプロジェクトに公式ドメインを追加する。
顧客のDNS（ドメインの住所録）に、HPの場所を指すレコード（CNAME）を追加する。
顧客のメール設定（MXレコード）を絶対に消さない。これを消すと顧客のメールが届かなくなる重大事故になる。

リニューアル案件：旧URL→新URL の301移行

新規ではなく既存サイトのリニューアルの場合、URL構成が変わると今までの検索評価が消え、旧URLのブックマークやリンクが切れる。これを防ぐ。

公開前に旧サイトを丸ごとバックアップ（いつでも戻せるように）。
旧URL→新URLの対応表を作り、301リダイレクト（恒久転送）を全件設定する。これで検索評価を新URLへ引き継ぐ。
公開後に301が全件正しく飛ぶか検証する（旧URLを叩いて新URLに着地するか）。

公開後の動作確認

全ページが正常表示（HTTP 200）されるか
PC・タブレット・スマホ・主要4ブラウザで表示崩れがないか
フォーム送信テスト：本物のアドレスでお問い合わせを送り、ちゃんと着信するか
SSL（https：通信の暗号化）が有効か・混在コンテンツ（暗号化されていない要素）がゼロか

Step12：公開後SEO・実測検証・監視（設定して終わりにしない）

公開して終わりではない。検索エンジンに認識させ → 計測が本当に動いているか実測で確かめ → 公開後も壊れないか監視するのが最後のステップ。「設定したつもりで実は計測できていない」を潰す。

検索・解析の設定

Google Search Console：検索結果での見え方を管理するツール。プロパティ登録・所有権確認をし、sitemap.xmlを送信、主要ページのインデックスリクエスト（早く登録して、と依頼）を出す。顧客にも権限を付与する。
Google Analytics 4（GA4）：アクセス解析ツール。測定タグを全ページに設置し、コンバージョン（キーイベント）設定（お問い合わせ完了・電話タップ等を「成果」として計測）を最低1つ入れる。データ保持を14か月に設定（既定の2か月だと過去比較ができない）。
Google Business Profile：実店舗がある案件は、地図検索に出るよう登録する。
Bing Webmaster Tools：Search Consoleからインポートするだけ（5分）。

実測検証（「計測できているつもり」を潰す）

設定しただけでは計測は信用できない。実際に発火するかを目視で確かめる。

テスト送信でキーイベントが発火するか：本物の問い合わせを送り、GA4に成果（キーイベント）が記録されるかをリアルタイムで確認する。
電話・LINEのタップも計測対象に：クリックを計測（GTM経由が楽）し、発火を確認する。

監視（公開後に壊れていないか）

外形監視：UptimeRobot等で「サイトが落ちていないか」を常時監視（落ちたら通知が来る）。
ドメイン・SSLの有効期限：切れるとサイトごと止まる。期限リマインダーを設定する。
Search Consoleのエラー：インデックスエラー・カバレッジを定期的に確認する。

ここまで来て初めて「制作 → 著作権クリア → 公開 → 集客の土台が実際に動いている」が全部そろう。これがTERASUのHP制作フローのゴール。

納品後の修正運用（公開後の鉄則）

HPを納品（公式ドメインで公開）した後にも、修正依頼は来る。そのとき絶対に本番へ直接反映しない。

納品後の修正は、必ず「プレビューで作る → OKが出る → 本番に公開」の順で進める。ミスった修正が「今まさにHPを見ているクライアント・その先のお客さん」に出る事故を物理的に防ぐためだ。

フローはこうなる。

① preview ブランチで修正 → push（プレビューが約30秒で自動更新）
② プレビューURLをクライアント／上長に共有 → 確認してもらう
③ OKが出たら main にマージ → 本番ドメインに反映

ルール	理由
承認なしで本番（main）にマージ禁止	「OK」が出てから本番に出す。事故防止の最重要ルール
本番ファイルを直接編集しない	必ずpreviewブランチ経由で作る
「verいくつに戻して」はgitで一発	履歴から探して `git revert`。バックアップを別途取る必要なし

例外は「クライアントが急いでいて緊急」「1文字のtypo直しで影響範囲が一目で分かる」場合のみ。それ以外は全部プレビュー経由が原則。

この章のまとめ

TERASUのHP制作は、良い参考HPを土台に、壊さず再現 → 自社コードに作り替え → 中身を入れ → 磨き → 著作権を二重チェック → 資産化 → 公式公開、という12ステップの決まった道を通る。

覚えておくべき芯は6つ。

用途で分岐する：着手前に「クライアント納品」か「デモ」かを決める。クライアントは全12ステップ、デモは簡略ルート（トップのみ・公開系スキップ／ただし著作権監査は残す）。
再現が先、作り替えが後：Step1-3で完全再現を確定させてから、Step4で作り替える。順番を守るのが崩れ防止の核心。
確認①②でOKが出るまで進まない：「だいたい合ってる」で進めない。
著作権は二重ゲート（Step4とStep8）：元サイトの痕跡をゼロにしてから公開する。grepで見つからないアウトライン文字SVGまで潰す。これがTERASUの生命線。
GitHubのプレビューリンクで共有しながら進める：Step5で立ち上げ、push＝30秒で自動更新。verも履歴も全自動。
公開前のQAと公開後の実測まで：納品前QAゲート（フォーム双方向疎通・URL正規化・index設計・誤字脱字）で「設定ミス＝サイレントな機会損失」を潰し、公開後はキーイベントの実測と外形監視まで。納品後の修正は必ずプレビュー経由で。

このフローのすごみは「未経験でも、順番通りにやれば集客できるHPが公開できる」こと。1ステップずつ、確認を挟みながら、確実に進めていこう。