/hp-flow — HP制作フロー（12ステップ・最初から最後まで全部入り）

参考HP受領から 完成・著作権最終監査・SEO対策・公式ドメイン公開・公開後設定まで、HP制作の全工程を12ステップで完結する対話型コマンド。「これ通りやれば全部バッチリ」を目指す。

コマンド改訂履歴（ver管理）— 「ver◯に戻して」で即ロールバック・2026-06-29 大串FB・恒久

このコマンド自体を改修するたびに ver+1 し、下表の先頭に1行追記する。 直近3ver＋★大きな変化(マイルストーン)を常に表示。修正を重ねて「前の方が良かった」時は 「ver◯に戻して」 と言えば、その commit の版に戻す（git履歴がバックアップそのもの）。
「ver今何？」と聞かれたら、最新版を git -C ~/dev/scale-brain pull で同期してから下表の現行ver（最上段）を答える。メンバー全員が同じ最新verを見られる（git+symlinkで自動同期）。

現行: v2.9（2026-08-24）手順2-bに「引用符付き属性セレクタ／属性値に入ったクラス名／文字列連結で組む属性セレクタ」を追加＝[class*="p-hero"] [data-class="js-svg"] [data-popup="'+t+'"] が同時に断線した実例を型にした

ver	日付	変更内容（★=大きな変化）	commit
v2.9	2026-08-24	★手順2-bに引用符付き/属性値型の属性セレクタを追加。[class*=xxx]（引用符なし）だけを処理する実装だと、①header[class*="p-hero"]（引用符付き）②[data-class="js-svg"]（属性の値がクラス名＝属性名と値の両方を直す必要）③[data-popup="'+t+'"]（文字列連結で組む）が全部素通りし、実測で9箇所が断線した。検出コマンド（属性セレクタ形式の文字列を全部出して旧名と照合）を明記	(現行)
v2.8	2026-08-24	★CSS変数のJS追従を必須化。CSSの --x を --t-x に改名しても、JS側の getPropertyValue('--mqUp-lg') / setProperty('--area-height',…) / {thisWidthVarName:"--width"} は文字列なので置換対象から漏れる。漏れても JSエラーは出ず・見た目もほぼ同じまま、メディアクエリ判定やサイズ計算だけが死ぬ（実測16箇所が断線し、確認②の全項目を通過した後に発覚）。手順2の「全部同時に変える」表に追加＋手順3の検証に「JS内の '--xxx' 文字列が全て新名か（残ってよいのは --swiper-* 等 vendor だけ）」＋「実ブラウザで getPropertyValue('--t-xxx') が空でないこと」を追加	(現行)
v2.7	2026-08-24	★手順2-c①を訂正。v2.6の「.の直前は数字だけ除外」は、クラス名が数字で終わるサイト（c-person2 p-card2 c-title8 等＝日本語サイトに頻出）で .c-person2.-xsmall の2つ目の.が数字直後になりモディファイアだけ改名されず静かに死ぬ（実測でCSSが初期値に戻り bodyH −816px・font-size 12→10px。grepもHTTP200も素通り）。正解は「.の直後が英字/-/_か」だけで判定（数値リテラルは直後が数字なので構造的に除外済み＝先読みは元々不要）。+ 収集元の限定（JSは classList / querySelector の引数だけ。全文字列走査は "…/module.min.js" から min/js を拾い .t-min.js に破壊する）+ vendorのCSS変数も除外（--swiper-pagination-* を改名するとSwiperが崩れる）+ 確認②に 「アニメーションが常時動くサイトはheadlessのDOM計測が時刻で揺れる→アニメ停止CSSを注入して測る／最終判定は実ブラウザ」 を追記	(現行)
v2.6	2026-08-17	★Step4に 手順2-c「置換エンジンの境界条件4点セット」 を新設。frontier採用サイトのデモで4件連続で踏んだ"静かに壊れる"事故を型にした：①./#の直前は数字だけ除外（body.is-loaded .a.b 等の複合セレクタが改名されず body{opacity:0} を打ち消せず全ページ真っ白）②CSS変数--xは英字/ハイフン直後を禁止（.link--arrowを.t-link--t-arrowに破壊）③idはHTML実在のものだけ収集（#fff等16進カラーをid誤認して全色無効化）④vendor束はクラス置換対象外（GSAPの".in"/".out"/".inOut"誤爆でアニメ全停止）。あわせて確認②に実描画スクショ必須（headless Chrome・数KB=白紙のサイン）＋計算済みスタイル突合にhtml/body自身を含める＋セレクタ単位の前後照合（過剰改名は逆マッピング差分では原理的に検出不能）を追加	(現行)
v2.5	2026-07-25	★Step4 置換漏れゼロ方式に 手順2-b「部分一致セレクタの追従」 を新設。[id^="font_bold_"] [id*="h3_animation"] [id^="anchor"] は名前の一部しか書かれていないため手順2（完全一致置換）では原理的に検出できず、改名した瞬間にエラーも出さず静かに死ぬ（実害＝太字/英字のフォント指定が全部外れる・追従ナビが死ぬ・出現アニメが動かない。grepもHTTP200も素通り）。①属性セレクタの全棚卸し ②改名関数を再利用してパターン側も書換 ③before/afterでセレクタのマッチ件数を突き合わせて断線ゼロを証明、を必須化（ACES whoweare案件で発見）	(現行)
v2.4	2026-07-23	★「流用ルート」を撤廃（大串指示「使わないから元に戻して」）。v2.3で入れた「オリジナル化済みコード／プレビューリンクを渡すと Step1〜4 を飛ばせる」座組をやめ、作りたいHPが見つかったら毎回 参考HPから一から作る（Step1から）に戻した。あわせて参考HP側（TERASU Lab / mikke!）にコード・プレビューを持たせる構想も撤廃	(現行)
v2.2	2026-07-14	★STEP0完全mirrorをバックグラウンド実行＋ログをファイルに逃がす方式に（run_in_background＋-nv -o・完了後は find/wc/du でサマリのみ確認）。ギャラリー系等アセット過多サイトで進捗ログ数百〜千行がコンテキストを埋め、開始直後にセッション停止→引き継ぎになる事故を根絶。完全再現の軸は不変＝--page-requisites全取得・3欠陥補完・404ゼロ検証ゲートは一切削らない（--reject/深さ制限は使わない）	(現行)
v2.1	2026-06-30	★【重要】Org=Freeプランでは private リポで Org secret が使えない(GitHub仕様)→リポ単位の secret 必須を明記。新規案件はワンコマンド ~/hp-flow-work/bin/new-hp-preview.sh <slug> <site> [client\|demo]（リポ作成〜リポsecret設定〜push〜デプロイ自動）。完全自動(Org secret)はTeamプラン課金時のみ	(現行)
v2.0	2026-06-30	★常に最新verで進行する仕組み＝起動時にgit pullで最新化＋ステップ移行の節目で再読み込み（途中アップデート反映）＋起動時に現在ver表示＋「ver今何？」応答	f0e2d7b
v1.9	2026-06-30	デモ用もGitHub接続＝preview.demo-◯◯.pages.dev（クライアント用と同じ運用・出口だけStep9 Lab還元/demos公開）	ac975b3
v1.8	2026-06-30	★一時トンネルを全廃止＝クライアント用は最初からpreview.client-◯◯.pages.dev→完成でmain本番接続	ddca5a7
v1.7	2026-06-30	クライアント用は固定プレビューリンク必須・一時トンネル共有禁止を明記	b810e09

★マイルストーン: v1.8 GitHubプレビューリンク統一 ／ v1.9 デモもGitHub接続 ／ v2.0 常に最新ver運用（※v1.0=QAゲート 36981d4・v1.1=用途分岐 a3a6e4a・v1.5=ライティング b59c458・v1.6=PC幅等比ズーム）

ロールバック手順: 「ver◯に戻して」→ cd ~/dev/scale-brain && git log --oneline -- 22_AI運用ルール/コマンド集/hp-flow/hp-flow.md で対象ver commitを特定 → git checkout <hash> -- 22_AI運用ルール/コマンド集/hp-flow/hp-flow.md（その版を復元）→ commit。表に無い古いverも git log には全部残るので遡れる。

---

設計の核心3つ:
1. オリジナル化を完全再現の後に分離 → 前後で見た目・挙動が変わってないか確認し「置換漏れでボタン押せない」事故を物理的に防ぐ
2. 著作権の最終監査を必須化 → 元サイトとバレる箇所・引っかかる箇所をゼロにしてから公開
3. 公式ドメイン公開・SEO設定まで一気通貫 → 制作だけで終わらず「集客できる状態」まで持っていく

→ 各ステップの詳細知識は manual-terasu（https://manual-terasu.pages.dev/）も参照。本コマンドは「実際に手を動かす実行フロー」。

設計思想（厳守）

• 用途分岐（デモ/クライアント）を最初に確定（2026-06-25 大串FB・恒久）: Step1冒頭で「デモ用 / クライアント納品用」のどちらかを必ず聞く。クライアント=全12ステップ（現状のまま）／デモ=簡略ルート（トップページのみ作成・他メニューは全部トップへ遷移・公開系Step10-12はスキップ）。デモは数を量産するのが目的なので軽く速く回す。詳細は下記「用途分岐プロトコル」
• 順次推進: 12ステップを順番に進める（一気にやらない）
• 全ページ一括方式（2026-05-30 大串FB・恒久）: Step1で TOP＋全下層ページを一度にコード抜き出し＋ダミー化（画像は元のまま・文字は同量ダミー）→ 確認① → Step4で 全ページを一気にTERASUオリジナル化。ページ毎に分けない（共通アセット補完が1回で済む・リネームマッピングを全ページ一貫適用でき品質も効率も上）。※「分けると品質が落ちる」懸念はwgetの取りこぼしが原因で、STEP0完全mirror手順があれば全ページ一括でも品質は落ちない（mont.jp下層12ページ一括で実証済み）
• 完全再現を先・オリジナル化を後: まず元HPを壊さず完全再現 → 確認 → それからオリジナル化（同時にやらない）
• 2回の確認を必ず挟む: ①完全再現が元と一致するか ②オリジナル化後にStep3から変化してないか
• ステップガイド型: 各ステップで素材を待ち、処理 → 完了確認 → 次へ
• ユーザー入力は番号 + アルファベットだけで完結
• 各ステップ内でも修正介入余地（やり直し/戻る/スキップ）
• 元のレイアウト/フォント/アニメーション/カラーコードを 絶対に壊さない
• 文字数オーバー等の懸念は事前報告
• 置換漏れゼロ方式: オリジナル化はリネームマッピング → 全ファイル横断同時置換 → grep整合性検証 → 前後プレビュー比較で、壊さず変換する
• 共有は全部GitHubプレビューリンク・一時トンネルは廃止（2026-06-30）: クライアント用もデモ用も案件開始時に名前でGitHub立ち上げ→固定リンク（preview.client-◯◯ / preview.demo-◯◯.pages.dev）にpushして改修・共有。クライアントは完成でmain本番接続／デモはStep9 Lab還元＋/demos/公開がゴール（本番接続なし）。ngrok/localhost.run/cloudflare(trycloudflare)等の一時トンネルは使わない（URLが毎回変わり消えるため）。ローカル(localhost)は自分の高速確認用
• セルフ進化（自動学習）必須: フロー中・セッション内のどこでFBが出ても検知し learning.md に記録 + 恒久ルールは hp-flow.md 本体を自分で書き換えて永続化

---

セルフ進化プロトコル（自動学習）— 最優先で常時稼働

このコマンドは使うほど賢くなる。ユーザーのFBを検知したら、Claude が自分で hp-flow.md 本体や learning.md を書き換えて永続化する。

起動時（必ず最初に実行）— 常に最新verで開始（v2.0・2026-06-30 大串FB・恒久）

/hp-flow 実行時、フロー開始前に必ず以下を順に実行する:

# ① 最新版に同期（他メンバー/別セッションの改修を取り込む）
git -C ~/dev/scale-brain pull --rebase --autostash 2>/dev/null

② 同期した最新の hp-flow.md（自分自身）と learning.md を Read:

~/dev/scale-brain/22_AI運用ルール/コマンド集/hp-flow/hp-flow.md   ← 冒頭の改訂履歴で現行verを確認
~/dev/scale-brain/22_AI運用ルール/コマンド集/hp-flow/learning.md  ← 過去のFB・学習を継承

③ 現行ver（冒頭「改訂履歴」表の最上段）を確認し、フロー開始時に「現在 vX.Y」と表示する。

→ 過去のFB・学習を全部読み込み・起動時点で必ず最新版にしてからフローを進める。これがセルフ進化＋「常に最新ver」の核心。

セッション中の最新同期（途中アップデートを取り込む・v2.0・2026-06-30 大串FB・恒久）

長いセッションだと進行中に他メンバー/別セッションがコマンドをアップデートする（例: v1.6で開始→途中でv1.9に）。それを取り込んで常に最新verで進むため:

• 各ステップの節目（ステップ完了→次へ進む時）に最新の hp-flow.md を Read し直す（git -C ~/dev/scale-brain pull → 次ステップ該当箇所＋冒頭改訂履歴を再読み込み）
• 再読み込みで verが上がっていたら「 vX.Y→vA.B に更新されました。最新版で続けます」と通知し、以降は最新版の手順で進行
• 進行中の作業（案件の成果物）はそのまま・手順だけ最新に乗り換える（ver管理＋後方互換なので作業はやり直さない）
• 技術上「毎ターン完全最新」は無理（コンテキストは読んだ瞬間で固定）だが、節目で読み直せば実用上ほぼ常に最新

FB検知ルール（セッション内のどこでも・常時監視）

フロー中だろうと雑談だろうと、ユーザーの発言に以下が含まれたら FBとして検知:

FBシグナル例	検知
「ここ違う」「そうじゃない」「なんで○○したの」	不満系
「次からこうして」「毎回○○して」「今後は」	恒久ルール系
「○○はやめて」「○○は不要」	禁止系
「○○した方がいい」「○○できる?」	改善提案系
「もっと○○」「○○が足りない」	強化要望系
やり直し指示が続く・同じ修正を何度も	暗黙の不満（パターンから推測）

→ FBする場所は決まってない。セッション内のどこで言われても拾う。

FB検知時の処理（3分岐）

種別	判定基準	アクション
A. 恒久ルール	「次から」「毎回」「今後」等・明確に再発する改善	hp-flow.md 本体を自分で Edit して反映 + learning.md に記録
B. 学習候補	良いFBだが恒久化の確信が持てない	learning.md に「候補」として記録（3回出たら本体昇格）
C. 一時対応	この案件だけの個別要望	その場で対応するだけ（記録しない）

横展開判定（他HPにも効くFBは「初回アウトプット」に焼く）— 2026-06-25 大串FB・恒久

大串FB「みんながHPを作る中で出たFBで、他のHPにも使えそうな部分は学習して、アウトプットの質が上がる体制にしたい」。FBを直すだけで終わらせず、「次の別HPの初回アウトプット」に必ず反映する。

• FB検知時、種別A/B/Cの判定に加えて 「これは他HPでも同じことを言われる汎用か？」 を必ず自問する
• Yes（汎用） → 該当ステップの本体（標準パック・チェックリスト・テクニック集）に昇格し、次回案件の初回から自動適用される形にする（その場の1案件で直して終わりにしない）
• No（この案件固有） → その場で直すだけ（本体は汚さない）
• 横展開先の対応例：レスポンシブ対応＝Step7「標準パック」、オリジナル化＝Step4「18項目」、文章＝Step5「SEO/CVコピー」、納品＝Step10「QAゲート」。FBの内容に対応するステップの"初回から効く型"に積むのが原則

hp-flow.md 本体への自動反映ルール

種別A（恒久ルール）と判定したら、ユーザーに確認を取らず即座に hp-flow.md を Edit:

1. 該当セクションに追記 or 修正
2. ver+1 して冒頭「改訂履歴」表の先頭に1行追記（直近3ver＋★マイルストーンを維持・大きな変化は★）。「前に戻りたい」を git で即叶えるため
3. learning.md に「いつ・誰の・何のFBで・どこを・どう変えたか」を1行記録
4. フロー中なら作業を止めず、完了報告時に「✏️ 今回○件の改善を本体に反映しました（ver→v◯.◯）」とまとめて報告

learning.md への記録フォーマット

| YYYY-MM-DD | {FB者/不明ならsession} | {FB内容要約} | {種別A/B/C} | {hp-flow.mdのどこをどう変えたか/候補のまま} |

安全装置（暴走防止）

• 削除系は慎重に: 既存ルールを消す系のFBは、消す前に「○○のルールを削除しますが本当に？[a]はい [b]learning.mdに記録だけ」と1回だけ確認
• 矛盾検知: 過去の学習と矛盾するFBが来たら「以前は○○でしたが、今回△△に変えますか?」と確認
• 肥大化防止: 本体が冗長になってきたら「ルールが増えてきたので整理しますか?」と提案
• Vault編集前に必ず ai_session_lock.sh acquire vault でロック取得

---

改良フェーズ運用プロトコル（ver管理＋複数パターン＋リンク事故防止）— 2026-05-30 大串FB・恒久・絶対遵守

TERASUオリジナルコードが完成した後（Step5以降）の「修正依頼」は、すべてこの3点セットで回す。 リンク混同・反映漏れ事故をゼロにし、ラリーを最小化する。

リンク構成（事故防止の核心・2026-06-15 GitHub運用化）

git preview ブランチ = 正本（source of truth）
  └ 採用が確定した修正だけが commit され、履歴(ver)が刻まれていく唯一の正本
  └ push すると https://preview.client-{案件}.pages.dev が自動更新（約30秒）＝「今の確定版」
  └ ※Step1-4（会社名確定前）はローカルlocalhostで作業。Step5でGitHub立ち上げ後は このプレビューが本体
複数パターン比較 = 選定用（使い捨て）
  └ 修正候補を複数見せるとき: 別ブランチ(preview-optA/B/C)を push、or URLパラメータ(?variant=A/B/C)で出し分け
  └ 採用が決まったら preview ブランチへ確定統合 → 候補ブランチは破棄

→ 本番ドメイン(main)で直接試行錯誤しない。 必ず preview ブランチで見比べ → 決まったものだけ commit。本番(main)反映は Step11（公開）／納品後は「納品後の修正運用」フローまで一切しない。

ver番号管理（修正のたびに必ず・GitHub運用版＝git が全自動）

1. 修正・採用のたびに git commit（小さなtypo直しでも＝細かく巻き戻せる）。commit message = 修正内容（例 fix: CTA色変更）
2. git log が ver管理表（誰が・いつ・何を 自動記録）。手書き VERSIONS.md・tar.gz バックアップは不要（git履歴がバックアップそのもの）
3. push でプレビュー自動更新（約30秒）→ プレビューURLで確認
4. 「ver◯に戻して」「さっきの状態に戻して」 → git log --oneline で対象commit特定 → git revert <hash> → push で即反映
5. index.html の <!-- VER --> マーカーは任意（git が履歴を持つので必須ではない。クライアント表示用に残すのはOK）

# ロールバック例（GitHub運用）
cd ~/dev/client-{案件} && git checkout preview
git log --oneline          # 戻したいcommitを探す
git revert <hash>          # その変更だけ安全に取り消し（履歴は残る）
git push                   # → プレビュー自動更新（約30秒）

複数パターン提示（修正依頼が来たら極力これ・ラリー削減）

• 修正依頼 → 1案だけ出さず、極力2〜4パターン作る（デザイン変更・アニメ変更・レイアウト変更は特に）
• 各パターンを 別ブランチ(preview-optA/B/C)で並列デプロイ or URLパラメータ(?variant=A/B/C) で出し分け → 「どれがいい？」と番号で選んでもらう
• 選定 → 採用版だけ preview ブランチに確定統合 → commit → 候補ブランチ/一時CSSは撤去（本体を汚さない）
• 「1個出す→違う→また1個」の無限ラリーを禁止（_SCALE_共通_トラブルシューティング集 ラリー最小化と同思想）

反映漏れ・混同 事故防止チェック（修正反映のたび）

確認	内容
commit済み	採用した修正が git commit されている（message=修正内容）
push済み	git push してプレビューが自動デプロイされた
プレビュー確認	preview URL を再読込し、採用した修正が実際に見えていることを目視
候補ブランチ破棄	選定後の使い捨て候補ブランチを削除・本体と混同しない
本番未反映の確認	main(本番)にはまだ反映していない（Step11／納品後フローまで本番触らない）

→ 「あの修正が入ってない」を物理的に防ぐ。毎回この5点を通してから「反映済み」と言う。

---

用途分岐プロトコル（デモ / クライアント）— 2026-06-25 大串FB・恒久・絶対遵守

/hp-flow の用途は2つ。Step1冒頭で必ずどちらかを確定してから進める。 クライアント納品用は現状の全12ステップ（バッチリなので不変）。デモ用は「数を量産する」ためトップページだけ作る簡略ルート。

クライアント納品用（現状のまま・全12ステップ・不変）

• 全ページ作成 → オリジナル化 → 流し込み → GitHub立ち上げ → 改良 → スマホ → 著作権 → Lab還元 → 納品前QAゲート → 本番公開 → 公開後SEO まで全部やる。
• このルートは完成されているので何も変えない。

デモ用（簡略ルート・トップのみ・公開しない）

変更点	内容
トップページのみ作成	下層ページ（about/service/works…）は作らない（デモは数をたくさん作りたい＝トップだけで完成）。Step1のmirror/ダミー化もトップ表示に必要なアセットだけ
他メニューは全部トップへ遷移	ナビ/メニュー/フッターの全リンクを href="./"（トップ）に向ける。押すと自然にトップに戻る＝下層が無くても破綻しない。Step2をこの処理に置き換え
流し込みは本番同様	デモも依頼書を受け取って流し込み＋SEO/CVコピー（大串が依頼書を作って送る）。ここは手を抜かない
GitHub接続・固定プレビューリンク（クライアント用と同じ・2026-06-30 大串FB）	デモも案件開始時にデモ名でGitHub立ち上げ→固定リンク preview.demo-◯◯.pages.dev にpushして改修・共有（クライアント用と同じ運用）。違いは出口だけ＝本番ドメイン接続はせず Step9 Lab還元＋/demos/公開がゴール
著作権監査(Step8)は残す	デモも制作実績として外部公開する＝元サイト痕跡ゼロは必須。むしろデモこそ指紋を残さない
Lab還元(Step9)＝デモの正式ゴール	ここで完了。完成後、制作実績に載せるなら別ワークフロー（feedback_terasu_demo_workflow の /demos/<名>/ 内部ホスト公開）へ引き継ぐ
公開系(Step10/11/12)はスキップ	納品しないので 納品前QAゲート・本番公開・公開後SEO は不要。ただしStep10の軽量チェックだけ実施＝①リンク切れ0 ②コンソールエラー0 ③全メニューがトップ遷移する、の3点
デモも最小メタは必須（2026-06-29 大串FB）	デモは /demos/ でリンクを送る＝favicon・<title>・OGP画像(1200×630) が無いとシェア時/タブで安っぽい。トップだけでも favicon＋<title>＋og:image/og:title/og:url(絶対URL) を必ず設定（Step10「ブラウザ・SNSシェア表示」の最小セット）

→ デモルート＝Step1(トップのみ)→Step2(メニューtop遷移)→Step3→Step4→[Step6/7は任意]→Step8→Step9ゴール。Step10は軽量チェックのみ・Step11/12は無し。

---

ステップ全体像

Step	内容	フェーズ
1/12	全ページ一括コード抜き出し＋ダミー化（TOP＋全下層を一度に / テキスト=同長ダミー / 画像=元のまま / STEP0完全mirror適用）	制作
2/12	全ページ抜き出しの仕上げ（量産ページ=works個別/blog等は1テンプレで代表化・取りこぼし補完・全ページ揃え）	制作
3/12	ローカルプレビュー + 確認①（全ページが元HPと一致）	制作
4/12	全ページ一括TERASUオリジナル化（リネームマッピングを全ページ横断適用・置換漏れゼロ） + 確認②（Step3から不変）	著作権
5/12	案件依頼書の流し込み ＋ SEO/CVコピーライティング（キーワード逆算・問い合わせ導線・複数案）＋ GitHub立ち上げ・プレビューリンク発行	制作
6/12	改良ループ（デザイン・コピーを磨く・ver管理＋複数パターンプレビュー方式）	改良
7/12	レスポンシブ対応（全端末幅で基準デザインを崩さずフィット → 各端末実機FB依頼）	最適化
8/12	著作権 最終監査（元サイトとバレる箇所・引っかかる箇所をゼロに・スマホCSSも対象）	著作権
9/12	TERASU Lab セクション還元（完成HPを全セクション細分化→Labセクションに蓄積・デモの実質ゴール）	還元
10/12	納品前QAゲート（ライティング・コピー最終監査 + フォームQA双方向疎通 + URL正規化/index設計 + ブラウザ/シェア表示 + プリフライト + SEO内部対策）	QA
11/12	本番公開（公式ドメイン・DNS・SSL ＋ リニューアル時は旧URL→新URL 301移行）	公開
12/12	公開後SEO・解析実測検証・監視（GA4データ保持14か月/キーイベント実測 + 外形監視 + ドメイン/SSL期限）	SEO

→ クライアント用: 案件開始時にクライアント名でGitHub立ち上げ→最初から固定プレビューリンク preview.client-{案件}.pages.dev に push して制作・改修・共有／ Step 8 = 著作権ゲート／ Step 11 で main にマージ＝公式ドメイン本番公開／ 納品後の修正は末尾「納品後の修正運用」。 デモ用: クライアント用と同じくGitHub接続→固定リンク preview.demo-{名}.pages.dev（pushで改修・共有）。ただし本番接続はせず Step9 Lab還元＋/demos/公開がゴール（両方ともローカルは自分の確認用・一時トンネルは廃止）

→ 上の表はクライアント納品用の全工程。デモ用はStep1で分岐＝トップのみ作成・他メニューはトップ遷移・Step5のGitHub立ち上げ と Step10-12（QAゲート/本番公開/公開後SEO）はスキップ・Step9 Lab還元がゴール（上記「用途分岐プロトコル」参照）。

---

公開後：案件リポにスタートカードを作る（クライアント用・毎回必須・2026-07-15 大串FB・恒久）

HPを本番公開したら（Step11後）、その案件リポ直下に CLAUDE.md（スタートカード）を必ず作る。 git log は履歴、スタートカードは「案件固有の要点＝次に修正/引き継ぐ時に最初に読む1枚」（役割が違う）。テンプレート:

# <クライアント名> HP — 作業スタートカード
> このリポで作業を始めたら、このファイル + `git log` で現在地。
> 現在地把握: `bash "$(dirname "$(readlink ~/.claude/commands/recover.md)")/site_snapshot.sh" <案件名>`

## これは何
- クライアント: <名前>／本番: https://<ドメイン>／リポ: `scale-group-jp/<案件>`
- <サイトの種別・目的・ページ構成>

## デプロイ・修正フロー（hp-flow GitHub運用）
- 制作/改修は `preview.client-<案件>.pages.dev` に push → 大串OK → `main` マージで本番公開
- **承認なしの main マージ禁止**（納品後修正も preview→OK→本番）
- ver管理: コミットメッセージに ver番号（「ver◯に戻して」で復元）

## 絶対に守る地雷
- <クライアント特有の要望・触ってはいけない箇所・過去FB>

## 状況
- 最新ver: <N>／納品状況: <納品済/進行中>

## 困ったとき
- コマンド: `/hp-flow`／memory: <関連>

→ デモ用はスキップOK（納品しない・Lab還元がゴールのため）。既存の納品済みHPでスタートカードが無いものは、次に触る時に1枚作る。

進行制御コマンド（全Step共通）

入力	動作
次 / OK / 1	次ステップへ
やり直し / 2	現ステップ再実行
戻る / 3	前ステップへ
スキップ / 4	完了扱いで次へ
終了	中断

---

起動時の挙動

/hp-flow 実行時、まず learning.md を Read（過去の学習継承）してから、「用途（デモ/クライアント）＋参考HP」だけを聞く。フロー全体の長い説明は出さない。

 HP制作フロー開始（現在 v{冒頭改訂履歴の現行ver}）

① この制作は どちら用？
  [A] クライアント納品用（公開まで・全12ステップ）
  [B] デモ用（トップのみ・他メニューはトップ遷移・公開なし／数を量産する用）

② 参考にするHPを送ってください:
  [a] URL（fetchして処理）
  [b] ローカルパス（zip解凍済み等）
  [c] HTMLを直接ペースト

（例:「B / https://example.com」のように一度に送ってOK。いつでも「戻る」「やり直し」「スキップ」「終了」可）

→ 起動を軽くして「すぐ 用途＋参考HP を送ればいい」と直感的にする。[B]デモなら簡略ルート（上記「用途分岐プロトコル」）。12ステップの詳細は、必要になった時 or「全体像見せて」と言われた時だけ提示。

Step 1/12: 全ページ一括コード抜き出し＋ダミー化（TOP＋全下層を一度に）

このステップで TOP＋全下層ページを一度に抜き出す（2026-05-30 大串FB）。STEP0完全mirror手順を全ページに適用 → 共通アセット（CSS/JS/SVG/画像）の補完が1回で済む。以降の説明は「1ページ分」の処理ルールだが、対象は全ページ（TOP・about・service・works・contact… 構造が違うページ全種）。同型の量産ページ（works個別・blog個別）は Step2 で1テンプレ代表化。

このステップではオリジナル化は一切しない。 元HPのコードを「完全再現」しつつ、テキストは同じ長さのダミー文に差し替え・画像は元のまま残す。これで Step3 の確認①で「元と同じレイアウトか」が一目で判断できる。オリジナル化はStep4でまとめてやる。

空・プレースホルダ化は禁止。空 {{KEY}} や placeholder.jpg にすると、レイアウトが元と同じか・崩れてないかが確認できない（実体験FB 2026-05-30）。実物大のダミーで「見た目が元と一致」を作るのがこのステップのゴール。

【デモ用の場合】トップページだけ抜き出す（2026-06-25 大串FB）。 下層ページ（about/service/works…）は作らない。STEP0完全mirrorもトップ表示に必要なアセットだけでOK（下層専用CSS/JS/画像は不要）。他メニューのリンクは Step2 で全部トップへ向ける。クライアント納品用は従来どおり全ページ一括。

STEP0: 完全mirror（wgetの3欠陥を必ず補完）— 2026-05-30 mont.jp案件の教訓・恒久・最重要

大串FB原文: 「最初からこのクオリティで一発で出して、修正少ない方が助かる（時間がかかってもいい）」。wget --page-requisites 一発では JS駆動サイトは約50%しか再現できない（mont.jp実例：初回5割）。元HP取得後、下記3欠陥を必ず補完してからダミー化（処理ルール）に進む。ここを省くと5割になる。

取得コマンド（--restrict-file-names は使わない／必ずバックグラウンド＋ログはファイルへ）

mirrorは必ず run_in_background: true（または末尾 &）で実行し、-nv -o site/_wget.log で進捗ログをファイルに逃がす。 フォアグラウンドで進捗ログ・DLファイル一覧をツール結果に返すと、アセットの多いサイト（デザインギャラリー系・画像過多サイト等）で数百〜数千行がコンテキストに一気に載り、セッションが詰まって停止→引き継ぎになる（2026-07-14 sankoudesign.com 案件の事故）。取得物は1つも減らさない＝詰まりの原因は「取得量」でなく「出力の垂れ流し」なので、実行方式だけ変えれば完全再現と両立する。

mkdir -p site
# ↓ run_in_background: true で実行（末尾 & でも可）。-nv -o でログはファイルへ＝ツール結果に載せない
wget --page-requisites --convert-links --no-host-directories -e robots=off \
  -P site -U "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ... Chrome/120 Safari/537.36" \
  -nv -o site/_wget.log "https://対象/"
#  --restrict-file-names=windows は使わない（? → @ 変換で .css 拡張子が壊れMIMEがtext/cssにならない）

# 完了後は「サマリだけ」確認（ファイル一覧を全部出さない＝ここでも詰まらせない）
find site -type f | wc -l                  # 取得ファイル数
du -sh site                                # 総容量（重いサイトの早期検知）
grep -ci "error\|failed" site/_wget.log    # wget失敗数（0でなくても後段の404ゲートで補完するので続行可）

完全再現の中身は一切削らない（このステップの軸は不変）。 --page-requisites の取得物を減らしたり --reject／深さ制限で弾いたりは しない（取りこぼし＝再現率低下に直結）。変えたのは「実行の仕方（バックグラウンド＋ログをファイルへ）」だけ。下の3欠陥補完・404ゼロ検証ゲートは従来どおり全実施する。

補完すべき3欠陥（全部やる）

1. クエリ付きCSS/JSの取りこぼし — HTMLの全 <link>/<script>（?ver 付き含む）がローカルに在るか1個ずつ検証。page-top.css?240424 のようなクエリ付きはwgetが落とさない（mont.jpではトップ専用CSS 75KBが丸ごと欠落→FV全崩壊）→ curl "https://対象/path/file.css?ver" -o path/file.css でクリーン名保存（MIMEも正常化）。
2. JS動的読み込みアセット — ローカルをブラウザで開き preview_network filter=failed の404を全部拾う ＋ CSS/JSから grep -oE '/(assets|wp)/[A-Za-z0-9_./-]+\.(svg|png|jpe?g|gif|webp|mp4|woff2?)' で全パス抽出 → 欠けを一括 curl。logo_symbol_*・oval・balloon/* 等JSが文字列で組むパスは grep に出ない → preview_network の404が唯一の検出手段（mont.jpではSVG 14個欠落）。
3. 遅延ロード動画 (data-src-pc 等) — <video src="" data-src-pc="...mp4"> の動画も --page-requisites は辿らない → 明示 curl。

完全mirror検証ゲート（パスして初めて「完全再現」と認める）

• [ ] preview_network filter=failed の404がゼロ（GA/analytics の ERR_ABORTED は無視可）
• [ ] FV主要要素の高さを eval で確認（潰れてない＝CSS適用済み。例: 見出し getBoundingClientRect().height > 200）
• [ ] ローカルと本物を並べてスクショ比較して一致
• [ ] ローカル配信のCSSが Content-Type: text/css で返る（curl -sI で確認）

→ このゲートを通った状態が「Step3 確認①で一発OKが出るクオリティ」。時間がかかってもここで完全に詰めるのが、修正ラリーを最小化する唯一の道。

処理ルール

テキスト → 「同じ長さのダミー文」に差し替え（空・プレースホルダ禁止）

• 見出し・本文・ボタン文言・キャプション等を、元と同程度の文字数・行数のダミーテキストに差し替える
• 見出しは見出しらしいダミー（例: 元「自然素材の家づくり」→ ダミー「ダミー見出しテキスト一」）
• 本文は本文らしいダミー（元が3行なら、ダミーも3行分の長さ）
• ボタンは短いダミー（元「お問い合わせ」→「ボタン文言」）
• 言語は元に合わせる（日本語サイトは日本語ダミー、英語は英語ダミー）
• 文字数・行数を元に近づけるのが最重要（レイアウト崩れ確認のため）
• <title>・meta description・alt・aria-label も同様にダミー文（空にしない）
• 後で差し替えやすくするため、対応表に「どこに・元は何の文字だったか・何文字か」を記録（Step5で案件内容を流し込む時に使う）

画像 → 元のものをそのまま残す（あとで差し替え前提）

• <img> の src・background-image: url(...)・<picture>/<source srcset>/og:image/favicon は 元の画像をそのまま使う
• 理由：画像がないとデザインが何も分からない・元と同じか確認できない（実体験FB）
• これは制作途中の暫定措置。元画像は Step5（案件画像に差し替え）→ Step7（著作権監査で元画像ゼロを確認）で必ず除去する。最終納品物に元画像を残さない
• 対応表に「どの画像が・どこに使われてるか」を記録（差し替え漏れ防止）

完全再現する対象（=絶対変更しない・この段階では命名も変えない）

• HTMLのタグ構造・階層・順序・class名・id名・data属性（元のまま維持）
• CSS のセレクタ・プロパティ・値（フォント指定含む）
• レイアウト、余白、グリッド、Flex、レスポンシブのブレークポイント
• アニメーション、トランジション、JavaScriptの挙動
• カラーコード、影、角丸、ボーダー等
• フォント指定（font-family, font-weight, @font-face・src も元のまま）

→ この段階では class/id も元のまま。オリジナル化（リネーム）はStep4まで触らない。理由：先に完全再現を確定させてから変換するため。

既存スキル連携

本Stepの「ダミー化・元画像そのまま」仕様で抽出する。（旧 hp-template コマンドは 2026-07-20 に廃止。中身ゼロ化はこのStep内で完結する）

完了確認

 Step 1/12 完了（TOPページ再現・ダミー化）

完成物:
  - HTML / CSS / JS 一式（class/id は元のまま・完全再現）
  - テキスト: 同じ長さのダミー文 × N箇所（見た目が元と一致）
  - 画像: 元画像そのまま（※Step5で差し替え・Step7で元画像ゼロ確認）
  - 対応表: テキスト差し替え位置 × N / 元画像位置 × N

次どうする?
  [1] Step 2/12 へ（クライアント=下層ページ再現 / デモ=メニューをトップへ遷移）
  [2] Step 1 やり直し
  [3] 終了

---

Step 2/12: 全ページ抜き出しの仕上げ（量産ページの代表化・取りこぼし補完）

2026-05-30 改定: Step1で構造の違う全ページを一括抜き出し済みの前提。本Stepは ①量産ページ（works個別110件・blog個別等の同型ページ）を1テンプレで代表化、②全ページぶんの取りこぼしアセットを preview_network 404ゼロまで補完、③全ページ揃ったか最終確認。下層を1ページずつ別工程で抜く旧運用は廃止（全ページはStep1で一括）。

【デモ用の場合】このStepは「下層ページ再現」をせず、「他メニューを全部トップへ遷移」させる処理に置き換える（2026-06-25 大串FB）。

• ナビ・ハンバーガーメニュー・フッター・CTA等の 全リンクの href を ./（トップ）に書き換える（例 href="/about/" → href="./"）
• 【2026-06-29 koba案件・恒久・絶対遵守】href置換は <a> タグの中だけを対象にする。<link rel="stylesheet"> / <link rel="modulepreload"> / <link rel="icon"> / <link rel="canonical"> / SVG <use href> / xlink:href は絶対に書き換えない。 「href="..." を全部 ./ に置換」のような雑な一括正規表現（re.sub(r'href="[^"]*"', ...)）は、CSS/JS読み込みリンクまで ./（=トップHTML）に向けてしまい、全スタイル消失でレイアウト全崩壊する（koba-clinic Astroデモで実際に発生：全CSSが0ルール化・bodyH 6358→52179に暴走・ナビが素のbullet list化）。必ず <a\b[^>]*> 単位でマッチしてそのタグ内の href だけ置換する。残す href＝tel: / mailto: / http(s)://（外部）/ #始まり（ページ内アンカー・SVGシンボル参照）。
• トップ内に該当箇所があるアンカー（#section）は残してOK。別ページへ飛ぶリンクは全部トップへ
• 置換後の検証必須: ①<link rel=stylesheet> の href が ./ になってないか grep ②プレビューで scopedルール数>0・主要要素の computed style が効いてる（例 hero の min-height が0pxでない）③コンソールエラー0。HTTP200やリンク見た目だけで判断しない（CSSが./でも200は返る＝HTMLが返るだけ）。
• 検証: メニューの全項目をクリックして例外なくトップに戻ること（下層へ飛んで404・空ページにならない）
• これで「トップだけ作ったデモ」がリンク切れなく自然に見える。クライアント納品用は下記「処理ルール」で下層ページを再現（デモはこの下のルールはスキップ）。

起動時の提示

━━━━━━━━━━━━━━━━━━

 Step 2/12: 下層ページの再現

何ページ処理する?
  [a] 1ページだけ
  [b] 2〜3ページ
  [c] 4ページ以上
  [d] スキップ（下層なし）

処理ルール

Step 1 と同じ（テキストは同じ長さのダミー文に差し替え・画像は元のまま・class/idは元のまま完全再現）。複数ページは 1ページ=1セット でバラバラに出力。

• テキストは元と同程度の文字数・行数のダミー文（空・プレースホルダ禁止）
• 画像は元のものをそのまま（Step5で差し替え・Step7で元画像ゼロ確認）
• ページの順番・ファイル名・ディレクトリ構造を元と完全同一に
• 対応表のテキスト位置はページ名プレフィックスで管理（例: ABOUT-見出し1）
• ページ間リンク（href）の構造とパスは絶対維持

完了確認

 Step 2/12 完了（下層ページ再現・ダミー化）

処理ページ数: N
テキスト: 同じ長さのダミー文（見た目が元と一致）
画像: 元画像そのまま（※Step5で差し替え）

次どうする?
  [1] Step 3/12 へ（プレビュー + 確認①）
  [2] Step 2 やり直し
  [3] Step 1 に戻る
  [4] 終了

---

Step 3/12: ローカルプレビュー公開 + 確認①

Cloudflareの枠を使わない。 ローカルでプレビューを立てて、元HPと完全に同じに再現できてるか確認する。ここでOKが出るまで次へ進まない。

起動時の提示

━━━━━━━━━━━━━━━━━━

 Step 3/12: ローカルプレビュー + 確認①

ローカルで自分が確認する方法:
  [a] python3 -m http.server（最速・推奨）
  [b] npx live-server（ホットリロード付き）

※  一時トンネル(ngrok/localhost.run/cloudflared)は廃止・使わない。共有は全部GitHubプレビューリンク:
   ・クライアント用 → 案件開始時にクライアント名でGitHub立ち上げ済み＝`preview.client-◯◯.pages.dev` にpushして共有（ローカルは自分の高速確認用）
   ・デモ用 → クライアント用と同じくデモ名でGitHub立ち上げ→`preview.demo-◯◯.pages.dev` にpushして共有（本番接続なし・Step9 Lab還元＋/demos公開がゴール）

完成テンプレのパス: {推測 or 確認}

公開コマンド（ローカルは自分の確認用・共有はGitHubプレビューリンク）

[a] python3 -m http.server

cd {テンプレフォルダ}
python3 -m http.server 8000

→ http://localhost:8000（自分が見る用）

[b] live-server

cd {テンプレフォルダ}
npx live-server --port=8000

【一時トンネルは廃止・2026-06-30 大串FB・恒久・絶対遵守】ngrok / localhost.run / cloudflare(trycloudflare) は使わない。 毎回URLが変わり・消えるので「1つのリンクに修正を入れていく」ができない。共有は全部GitHubのプレビューリンクに統一：
- クライアント用 → 案件開始時にクライアント名でGitHubリポ＋プレビューリンク preview.client-◯◯.pages.dev を立ち上げ済み（下記「GitHub立ち上げ」節を Step1着手時に前倒し実行）。以降は git push するたび同じ1つのURLに反映して大串・クライアントに共有。完成したら main にマージ＝そのまま本番ドメインに接続。ローカル(localhost)は自分の高速確認用に併用
- デモ用 → クライアント用と同じくGitHub接続：デモ名でGitHubリポ＋固定リンク preview.demo-◯◯.pages.dev を立ち上げ、pushして改修・共有。本番ドメイン接続はせず Step9 Lab還元＋/demos/公開がゴール（ローカルは自分の確認用）

ローカルプレビュー共有ルール（2026-05-30 大串FB・恒久・絶対遵守）

大串FB原文: 「リンクタップできない / ローカルホストで毎回デプロイして これルールで」

1. プレビューURLは必ずタップで開けるMarkdownリンクで渡す — [再現版プレビュー](http://localhost:8000/) 形式。生URL直貼り禁止（http://localhost:8000/ をそのまま書くとチャットでタップできない）。
2. 修正のたびに毎回ローカルホストでプレビューを立て直して（デプロイして）、最新版のタップリンクを共有する — 「直したらプレビュー共有」までが1セット。確認待ちで止めても、必ずタップリンクを添える。
3. ポートは案件ごとに固定（例: raw=8753 / template=8754 / demo=8755）。.claude/launch.json に登録して preview_start で毎回立て直す。
4. 関連: メモリ <span class="wikilink-dead">feedback_tappable_links</span>（全リンクをMarkdownタップ形式で出す既存ルール）と同趣旨。HP制作フローでも徹底する。

確認①（完全再現チェック）

ユーザーに 元HPとプレビューを並べて見比べてもらう:

 確認①: 元HPと完全に同じに再現できてますか?

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

プレビューURL（タップで開ける・必ずMarkdownリンクで渡す）: [再現版プレビュー]({URL})

  [1] 完全に同じ → Step 4/12（TERASUオリジナル化）へ
  [2] 違う箇所がある → どこが違うか教えて（修正します）
  [3] Step 2 に戻る
  [4] 終了

→ ここで「完全再現」が確定する。 この状態を基準に、Step4で壊れてないか比較する。

---

Step 4/12: 全ページ一括TERASUオリジナル化（置換漏れゼロ） + 確認②

全ページを一気にオリジナル化（2026-05-30 大串FB）。リネームマッピング（class→t-* 等）は1回作って全ページ横断で同時適用する。ページ毎にバラバラにやると命名がズレて崩れるため、必ず全ページまとめて。

ここで初めてコードを改変する。 著作権侵害を避けるため「コード指紋」を全除去してTERASU独自仕様にする。ただしStep3の見た目・挙動を1ミリも変えないのが絶対条件。

大原則（絶対前提・違反したらやり直し）— 2026-06-12 大串FB・恒久ルール

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

これがTERASUコードオリジナル化の 絶対前提。参考HPを参考にした理由は「そのデザイン・構成・動きが良いから」。
それを崩したら参考にした意味がなくなる。コードだけ変える・見た目は完全に同じを堅持する。

絶対に変えてはいけないもの:

項目	内容	チェック方法
構成(レイアウト)	セクション順序・配置・グリッド・余白・配色比率	Step3プレビューと 並べて目視比較
デザイン	色・フォント・サイズ・装飾・線・影・グラデーション	カラーピッカー・実測
アニメーション	動き・タイミング・イージング・トリガー・連鎖順序	スクロール録画して コマ送り比較
インタラクション	ホバー・クリック・スクロール反応	全箇所操作テスト
レスポンシブ挙動	ブレイクポイントでの変化・スマホ表示	各デバイスサイズで比較

変えていいのは「コード(命名・構造表現)」だけ・「見た目と挙動」は1ミリも変えない

→ オリジナル化中にバグったら、それは見た目を壊した = NG。原点(Step3完全再現)に戻して再実行。

→ オリジナル化の本質: コード指紋の除去 であって デザイン改変 ではない。混同するな。

→ 参考HPの「良さ」をそのまま持ち込むのがTERASUの価値。0.1mmでも崩したら価値が下がる。

着手前判定：サイトの「結合度」でリネーム方針を分岐（2026-06-19 昇格・恒久 / studio.design・ntvart・ai-model 3案件で確立）

オリジナル化に入る前に、まず「クラス/属性とJSの結合度」を測る。 密結合バンドル（Vite/Webpack の minified JS・STUDIO/ノーコード生成・ヘッドレスCMS）では、クラス/data-* の blanket t-* 一括改名は 大原則（見た目1mm不変）を破る高リスク × クラス名は汎用で指紋価値が低い ため、既定で見送り、代わりに Stage A（実在指紋の安全な全除去）を必須とする。

着手前チェック（grepで5分）:
- minified JS が querySelector('[data-xxx]') / クラス文字列 / class="..." の動的生成HTML を持つか（→ あれば密結合）
- 挙動が data-* 属性駆動か（→ data改名は querySelector を全部直す必要＝高リスク）
- クラス名が汎用語（clip/inner/title/icon/uppercase 等）か（→ JS内の同名トークンと衝突して算術/文字列誤爆）

結合度	方針
疎（独自CSS＋素のJS・セレクタが追える）	従来どおり 置換漏れゼロ方式で全クラス/id/var/data を t-* 改名
密（minified束・data駆動・JS動的生成）	Stage A 必須＋ blanket改名は既定で見送り（やるなら「JS非参照が証明できたCSS専用クラスのみ」を HTML+CSS 限定で改名＋computed-style/CDP検証）

Stage A（密結合でも必ずやる・実在指紋の除去）:
1. 構造のTERASU化：/movie/等のサブパス → ルートにフラット化、Viteビルドハッシュ名（index.78217a4d.css等）→ 中立名（app.css/app.js）。全参照(HTML/CSS/JS)をパス書換
2. トラッキング全除去：GTM/gtag/GA/dataLayer/HubSpot/doubleclick、inline計測script
3. メタ指紋除去：generator/Yoast/name="google"(notranslate)/og:url・og:image・twitter:image・canonical・favicon の 元ドメイン、本文の元ドメイン外部リンク（CTA等）→ #（実URLはStep5）
4. CMS痕跡除去：wp-/プラグインCSS/media|uploads/YYYY/MM//wixstatic/data-wf-/studio.site 等（Step4-18）
5. CSS変数 → --t-*（JS非参照を確認すれば安全。before/afterの var() 使用数が1:1一致で整合証明）
6. コメント除去＋TERASUスタンプ（自分で書いた開発メモも消す。元サイト名を書いたCSSコメントが配信物に残ると、ソース閲覧で由来が見える＝2026-07-20 mikke!で実際に発生）
7. 有料フォントの参照除去（2026-07-20 mikke!監査で追加）：Adobe Typekit（typekit.css／avenir-next-world等のfont-family）・Font Awesome Pro（all.css／fa-light/falクラス）。元サイトのライセンス契約に紐づくため引き継げない。CSSを外したら、それ前提の空<i>アイコンも消す（何も描画されない抜け殻が残る）
8. 未使用アセットを配信しない*：読み込んでいないCSS/JS/フォントを置いたままにしない（ライセンス物が同梱されたままになる）

Stage A の検証（grepで機械確認・全部0になること）:

for w in UA- gtag googlesyndication doubleclick typekit 'fa-light' '<!--' ; do
  printf "%-20s %s\n" "$w" "$(grep -rc "$w" <配信ディレクトリ>/index.html)"; done
# 存在しないパスが404を返すか（200だとsoft-404＝ゴミURLが無限にインデックスされる）
curl -s -o /dev/null -w '%{http_code}\n' <本番URL>/zzz-nope.js

検証（密結合は特に必須）：オリジナル化版を別portで配信し、before(mirror) vs after を同一手順で計測 → ①bodyH・全セクション高さ(px)②画像枚数/broken数③主要要素のcomputed色(CSS変数解決後)④data-*カウント・accordion等の実クリック⑤コンソールエラー0 が完全一致で「見た目・挙動1mm不変」を証明（ai-model案件で全項目一致を実証）。HTTP200やgrep一致だけでは不十分。

置換漏れゼロ方式（最重要・壊さない手順）

「ボタンが押せない/スタイルが消える」を物理的に防ぐため、必ずこの順序でやる:

手順1: リネームマッピング表を先に作る

置換する全名前を、旧名→新名で一覧化してから着手:

| 種別 | 旧名 | 新名 |
|------|------|------|
| class | hero | t-hero |
| class | nav-menu | t-nav-menu |
| id | main-header | t-main-header |
| CSS変数 | --color-primary | --t-primary |
| data属性 | data-scroll | data-t-scroll |
| JS変数 | scrollObserver | tScrollObserver |
| JS関数 | initSlider | tInitSlider |

手順2: 全ファイル横断で「同じ名前を全箇所同時に」置換

1つの名前を変えたら、その名前が出てくる全ての場所を漏れなく同時に変える:

旧名の出現箇所（全部同時に変える）
HTMLの class="hero" / id="..."
CSSのセレクタ .hero { } / #main-header { }
CSSの var(--color-primary)
JSの querySelector('.hero') / getElementById('main-header')
JSの classList.add('hero') / classList.toggle(...)
JSの el.dataset.scroll / [data-scroll]
HTMLの data-scroll 属性
JSが文字列で読み書きするCSS変数＝getComputedStyle(x).getPropertyValue('--mqUp-lg') / el.style.setProperty('--area-height', …) / 変数に入れて渡す {thisWidthVarName:"--width"} （2026-08-24追加。ここを忘れると値が届かず、JSエラーも出ず、見た目もほぼ変わらないままメディアクエリ判定やサイズ計算だけが死ぬ。実測で16箇所が断線していた）

→ HTML・CSS・JSの3ファイルを1セットで扱い、1つのリネームを全箇所反映してから次のリネームへ。これが漏れを防ぐ核心。

手順2-b: 部分一致セレクタの追従（2026-07-25 ACES案件・恒久・手順2だけでは絶対に防げない断線）

[id^="font_bold_"] [id*="h3_animation"] [id^="anchor"] のような「前方/部分一致セレクタ」は、名前の"一部"しか書かれていない。 そのため手順2（＝旧名の完全一致で全箇所を置換）では 原理的に検出できず、id/class を改名した瞬間に何にもマッチしなくなる。
これが最悪なのは「静かに死ぬ」こと——エラーも出ず、HTTP 200 のまま、grep も通り、computed-style 比較でも「元から当たっていない状態」になるだけで差分に出ないことがある。ACES案件の実害＝太字/英字のフォント指定が全部外れる・追従ナビのセクション判定が死ぬ・h3出現アニメが動かない。

1. 全棚卸し（HTML内 inline CSS・外部CSS・JS の全部から）:
   bash grep -ohE '\[[a-zA-Z-]+[\^*$~|]=["'"'"']?[^]"'"'"']*["'"'"']?\]' <対象> | sort | uniq -c | sort -rn
2. id/class の変換規則と"同じ関数"でパターン側も書き換える（font_bold_ → t-f-bold-／anchor → t-sec／h3_animation → t-h3a）。手打ちで対応表を作らず、改名関数を再利用するのが漏れゼロの条件。
3. before/after で「セレクタのマッチ件数」を突き合わせて断線ゼロを証明（これが唯一の検出手段）:
   js // before で採取 → after で同じ数になるか ({sec: document.querySelectorAll('[id^="anchor"]').length, // → after: '[id^="t-sec"]' h3 : document.querySelectorAll('[id*="h3_animation"]').length, // → after: '[id*="t-h3a"]' bold: document.querySelectorAll('[id^="font_bold_"]').length}) // → after: '[id^="t-f-bold-"]' // 旧3件→新3件・旧26件→新26件のように「同数」なら断線なし。旧セレクタ側が 0 なら改名も完了。
4. 【2026-08-24追加】「引用符付き」と「属性値にクラス名が入る形」も同じ盲点。棚卸しの正規表現を引用符ありに対応させること。 実測で3種類が同時に漏れた:
   - header[class*="p-hero"] … 引用符付きの [class*="…"]（引用符なししか処理しない実装だと素通り）
   - [data-class="js-svg"] … 属性の"値"がクラス名。属性名(data-class→data-t-class)と値(js-svg→t-js-svg)の両方を直す
   - [data-popup="'+t+'"] … 文字列連結で組む属性セレクタ。dataset.popup→dataset.tPopup だけ直して、こちらを忘れると読み書きが食い違う
   検出コマンド（JS/CSS両方に流す）— 属性セレクタ形式の文字列を全部出し、旧名が残っていないか照合する:
   bash grep -ohE "['\"][^'\"]*\[[a-zA-Z-]+[\^*$~|]?=[^]]*\][^'\"]*['\"]" <JS> | sort -u
5. 対象外: [class*="fa-"]（Font Awesome）や [style*="padding-top"] のように、改名対象でない語のパターンは触らない（触ると逆に壊れる）。

手順2-c: 置換エンジンの境界条件4点セット（2026-08-17 frontier案件・恒久・全部やらないと"静かに壊れる"）

置換の正規表現をどう書くかで、エラーも出さず・grepも通り・DOM計測も全部一致したまま、画面だけが壊れる事故が起きる。frontier採用サイトのデモで実際に4件連続で踏んだ。この4点は毎回そのまま適用する。

#	ルール	破ると何が起きるか（実害）
1	. の「直後」だけで判定する＝\.(-?[A-Za-z_][A-Za-z0-9_-]*)。 「.の直前が数字なら除外」という先読み (?<![0-9]) は絶対に付けない（2026-08-24 訂正）	先読みを付けても外しても事故る両面がある。正解は「直後が英字/-/_ か」だけを見ること。 ⓐ 直前が英字でも置換しないと body.is-loaded .a.b a.button などの複合セレクタが改名されずカスケードが切れる（body{opacity:0} を打ち消す body.is-loaded{opacity:1} が効かず全ページ真っ白）。ⓑ しかし (?<![0-9]) を付けると、クラス名が数字で終わる（c-person2 c-arrow2 p-card2 c-title8 など日本語サイトに頻出）とき .c-person2.-xsmall の2つ目の . が数字直後になり、モディファイア側だけ改名されず静かに死ぬ（実測: 該当クラスのCSSが全て初期値に戻り font-size 12px→10px・padding 26px→0・bodyH が816px縮んだ。それでも grep もHTTP200も素通り）。ⓒ 数値リテラル（1.5em matrix(2.7,…) transition:.3s）は . の直後が数字なので、パターンが [A-Za-z_] 始まりを要求している時点で構造的に除外済み＝先読みは元々不要。あわせて url() と 文字列リテラルは事前にマスクしてから走査する（.png .min.css をクラスと誤認して .t-png に壊すため）
2	CSS変数 --x は「英字/ハイフンの直後」を禁止	.link--arrow の中の --arrow を変数と誤認 → .t-link--t-arrow になりそのルールが死ぬ
3	idは「HTMLに実在するid」からだけ集める（CSSの # トークンから拾わない）	#fff #eee #ed6a4d 等の16進カラーをidと誤認して #t-fff に壊す → サイト全体の色指定が無効化
4	第三者ライブラリ束（vendor/lib）はクラス置換の対象外（パス書換のみ）	GSAPはイージング名を ".in"/".out"/".inOut" の文字列連結で組み立てる。CSSに .in/.out/.inOut クラスがあると誤爆し power2.out が解決不能 → (f || this._ease) is not a function でアニメ全停止＝白画面

• JS内の置換は「特徴的な名前（- か __ を含む）＋実セレクタと確認済みの短い名前だけ」に限定する（button index 等の汎用語はJSでは別用途＝イベント属性・正規表現の .index なので触らない）。
• セレクタ単位の前後照合を必ず通す（下記 手順3 の項目6）。逆マッピングして差分を取る方法は過剰改名を原理的に検出できない（戻すと一致するため）。before のセレクタに写像を当てて after に実在するかを1本ずつ確認するのが唯一の検出法。

手順3: grep で整合性を機械検証（必須）

置換後、以下を grep で確認:

# 旧名が1個も残ってないか（全旧クラス名・id・変数を順にチェック）
grep -rn "hero\b" {テンプレフォルダ}        # → t-hero 以外でヒットしたら漏れ
grep -rn "class=\"" *.html | ...            # 旧命名の痕跡確認

# CSSの全セレクタに対応するHTML要素があるか
# JSの全 querySelector/getElementById に対応する要素があるか

検証項目:
- [ ] 旧クラス名・id名・CSS変数・JS変数が1個も残ってない
- [ ] CSSの全セレクタに対応するHTML要素が存在する（孤立セレクタなし）
- [ ] JSの全 querySelector/getElementById/classList が対応要素に届く
- [ ] data属性のHTML側とJS側の名前が一致してる
- [ ] JS内の '--xxx' 文字列が1つ残らず新名になっている（2026-08-24追加）。grep -ohE "['\"]--[A-Za-z][A-Za-z0-9_-]*['\"]" <JS> | sort -u で目視し、残ってよいのは vendor の変数だけ（--swiper-* 等）。さらに実ブラウザで getComputedStyle(document.documentElement).getPropertyValue('--t-xxx') が空でないことを確認する（空＝断線）
- [ ] イベントリスナーが対象要素に正しく結びついてる
- [ ] 6. セレクタ単位の前後照合が全本一致（2026-08-17追加）— before の全セレクタに改名写像を当て、after に1本残らず実在するか確認。改名漏れ（body.is-loaded）と過剰改名（.link--t-arrow）の両方をここだけが捕まえる
- [ ] 参照ファイルの実在チェック（HTML/CSS/JSの全 href|src|url()|data-* を os.path.exists で確認）＝リンク切れを配信前に潰す
- [ ] 未使用アセットの棚卸し（どこからも参照されないファイルを配信物に置かない＝ライセンス物の同梱防止）

手順4: オリジナル化18項目を全部やる（2026-06-12 拡張・専門家でも見抜けないレベルへ）

全項目「見た目1ミリも変えない」という大原則の下で実施。デザイン・構成・アニメに影響する変換は実装前に確認②で前後比較し、崩れたら即rollback。

命名系（既存7項目・最重要）

1. クラス名を全部 t-* プレフィックスにリネーム（最重要）
2. id名も t-* に統一
3. CSS変数を --t-* 命名に統一
4. data属性は削除 or data-t-* に独自化
5. JS変数・関数名をTERASU命名にリネーム（tScrollObserver 等）
6. ファイル構成をTERASU標準に（/css/main.css, /js/app.js, /images/, /fonts/）
7. 独自CDN・トラッキングタグ削除（jsdelivr等の標準CDNに差し替え）

コード構造系（2026-06-12追加・見た目影響ゼロ）

8. CSS rule の並び順を組み替え（TERASU標準: reset→tokens→base→layout→components→utilities→@media）
   - 元の並び順を機械的に組み替え。視覚への影響ゼロ
   - 同じセレクタが複数箇所に分散してたら集約
9. JS function 定義順を組み替え（TERASU標準: const/let→utility→DOMReady→handlers→export）
   - import 文を ABC順 or 種別順に統一
10. HTML属性順序を TERASU標準に統一（id → class → data-* → aria-* → href/src → その他）
    • 全タグで順序統一。検索エンジン・ブラウザ動作には無影響
11. asset ファイル命名を t-*命名 + 形式変換（例: hero-01.jpg → t-hero-001.webp）
    • jpg→webp/avif変換は容量削減のオマケ付き
    • 大串FB「画像は後から差し替えるから気にしない」= 命名規則変更OK

スタイル系（2026-06-12追加・数値不変・表現のみ変換）

12. CSS値の単位変換（数値は1ミリも変えない・表現方法だけ変える）
    • margin: 24px → margin: 1.5rem （16px基準・等価）
    • padding: 16px 24px → padding-block: 16px; padding-inline: 24px; （logical property）
    • color: #FF5733 → color: hsl(11, 100%, 60%) （カラーピッカーで完全一致を確認）
    • すべて 見た目は完全一致・コード表現だけ独自化
13. アニメーション timing function の等価変換（動きは完全一致・記法を変えるだけ）
    • transition: 0.6s ease-in-out → transition: 600ms cubic-bezier(0.42, 0, 0.58, 1) （ease-in-out のベジエ等価値）
    • ease, ease-in, ease-out も対応するベジエ値で記述統一
    • @keyframes 内の stop位置（0%/50%/100%等）は 絶対に変えない・名前と書き方だけ変更
    • 大串FB「デザイン性が変わらないならやりたい」= 等価変換だけOK・微調整は禁止
14. Prettier で全コード整形（TERASU独自設定: tabWidth=2 / semi=true / singleQuote=true / printWidth=100）
    • 元のフォーマット癖を機械的に上書き

コメント・痕跡系（2026-06-12強化）

15. コメント・著作表記の完全削除 → 独自TERASUコメント追加
    • 元コメント・著作表記は HTML/CSS/JS 全部から削除
    • 削除のみだと不自然 → 各セクション冒頭にTERASU独自コメント追加
    • 例: <!-- Hero section / TERASU original --> /* Section: t-hero | TERASU design tokens */
    • 元の「無コメント」状態は逆に怪しいので、自然な設計意図コメントで「TERASU色」を出す

構造系（2026-06-12追加・慎重実装・確認②で必ず前後比較）

16. DOM構造の見た目維持リファクタ（崩れリスクあり・確認②で厳格チェック）
    • 不要な <div> ラッパーを削除 / 必要なら追加 で 階層パターンを変える
    • <div> → semantic HTML 置換（<section>, <article>, <header>, <aside>, <nav>）
    • ARIA属性を独自に追加（機能向上 + 識別困難化）
    • 必須条件: Step3プレビューと並べて見て1ミリも変わってないことを確認
17. ライブラリ差し替え（慎重・動作100%同じが証明できるもののみ）
    • 例: Locomotive→自前scroll実装、GSAP→Anime.js、Splide→Swiper、Lottie→純CSS+SVGアニメ
    • 差し替えで動きが変わったら即rollback ・大原則違反
    • 差し替え対象は 動作テストが容易なもの優先（スクロールアニメ・スライダー等）

CMS痕跡除去系（2026-06-13追加・petomo検収の教訓・恒久）

18. 元サイトのCMS痕跡を全除去（WordPress / Wix / Webflow / Shopify / STUDIO 等）
    • 元サイトがCMS製の場合、ミラーに「CMSの指紋」が残る。動作に不要なCMS由来物は全部削除する
    • WordPress: wp-polyfill*.js・regenerator-runtime・wp-block系のJS参照（モダンブラウザに不要→参照とファイルごと削除）／contact-form-7等プラグインCSS（静的サイトでは無機能→削除 or style.cssへ統合）／wpcf7等プラグイン由来クラス
    • 日付型アップロードパス: media/YYYY/MM/・uploads/YYYY/MM/（元サイトのアップロード日が残る指紋）→ 中身を assets/images/ へ移動＋参照書き換え
    • 他CMSの指紋例: wixstatic(Wix)／data-wf-(Webflow)／cdn.shopify・myshopify(Shopify)／studio.site(STUDIO)／jimcdn(Jimdo)／mt-static(MovableType)／eccube(EC-CUBE)／<meta name="generator">
    • 理由: TERASUは「WordPressではない静的サイト」と営業している。コードにCMS痕跡が残ると、技術に明るい顧客がソースを見た時に矛盾する（2026-06-13 petomo検収で wp-polyfill×4・CF7 CSS×4・media/2023/12×7 を検出した教訓）
    • 削除後の検証必須: ブラウザコンソールエラー0＋表示崩れなしを確認してから次へ

検証系

19. grep + diff で痕跡ゼロ確認（手順3）
    • 旧クラス名・id・変数の残存ゼロ
    • 元サイトのドメイン・asset名 痕跡ゼロ
    • コード類似度測定 で 10%以下を目標（将来は jscpd で自動測定）

実装しない項目（大原則違反のため不採用）

• Media query breakpoint シフト（768→720px等）
• スマホ/PC切替タイミングがズレる → レスポンシブ挙動が変わる = 大原則違反
• 元の breakpoint をそのまま維持する

確認②（オリジナル化後の不変チェック）— 厳格版（2026-06-12 大原則 反映）

オリジナル化後、Step3のプレビューと並べて見比べてもらう。
「ほぼ同じ」じゃダメ。「完全に同じ」じゃないと進めない。

【2026-08-17 frontier案件・恒久】確認②の機械検証は「実際に描画された絵」を必ず含める。DOM計測だけで合格にしない。
- DOM計測だけでは白画面を検出できない：body{opacity:0} を打ち消すルールが改名漏れで切れると、全要素は visible / opacity:1 / 高さも色も画像も完全一致のまま画面だけ真っ白になる。実際にこの状態で「全項目一致」と判定しかけた。
- 必ずやる3点
1. before/after を同一手順でスクショして目視（in-appプレビューが非表示だと visibilityState:hidden で描画が止まり白く写るので、/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --headless=new --window-size=1440,900 --virtual-time-budget=9000 --screenshot=x.png <URL> で撮る。スクショのファイルサイズが数KB＝白紙のサイン）
2. 計算済みスタイルの前後突合に html と body 自身を必ず含める（子孫だけ走査する実装が事故の温床）
3. JSエラー0の確認（window.addEventListener('error') を仕込んで headless の --dump-dom で回収すると、ペインが使えなくても取れる）
【2026-08-24 追加・恒久】アニメーションが常時動くサイトは、headless の DOM計測が「時刻」で揺れる。数値の不一致を見たら、まず変換のせいか計測のせいかを切り分ける。
- やりがちな誤診: before/after で bodyH やセクション高さが違う→「壊した」と判断する。実際は 遅延初期化・スクロール連動アニメ・カルーセルの複製 が計測時点までに終わっていないだけのことがある（実測: トラッキングタグを消したら読み込みが速くなり、フッターの切替パネル7枚が計測時点で 0px → 待機を1.5秒→6秒に延ばしたら 753px に戻った＝実害ゼロだった）。
- 切り分けの型（この順でやる）: ①同じものを2回測って不一致インデックスを「ノイズ集合」として先に確定（0件でない前提で設計する）②待機時間を変えて再測（数値が戻れば計測のせい）③アニメ停止CSSを注入して測る（*{animation-duration:0s!important;transition-duration:0s!important}）④変換を1つずつ個別適用した検体を並べて一気に測る（1つずつ戻すより速く、犯人が1発で出る。必ず「無変換の検体」も混ぜる＝ハーネス無罪の証明）
- 最終判定は実ブラウザ（Claude Browser 等）で before/after を同一手順（同じ幅・同じスクロール往復・同じ待機）で測って突き合わせる。元サイト（本物）も同じ手順で開いて三者比較すると「そもそもその挙動が元からそう」なのかが一発で分かる（実測: FV背景が出ない→本物も同じだった＝再現できている証拠）。
- 検証器と変換器で同じ実装を共有しない（同じバグで両方すり抜け、「セレクタ照合 欠落0本」という誤った合格が出た）。照合側は独立に書くか、フォールバック規則を明示的に二重化する。
- 実描画で差が出たら、変換を1つずつ戻して二分探索（リネームのみ／除去のみ／移動のみ）＋リネーム対象名の二分探索で原因名を特定する。この時「変換を全くしない対照実験」を必ず先に通し、ハーネス自体の不具合を除外すること。

 確認②: Step3の状態から、見た目・動きが完全に変わってないですか?

【構成・レイアウト】
  □ セクション順序が完全に同じ
  □ 各セクションの配置(grid/flex)が同じ
  □ 余白(margin/padding)が同じ
  □ ヘッダー・フッターの構造が同じ
  □ 画像のサイズ・配置・トリミングが同じ

【デザイン】
  □ 配色が完全に同じ(カラーピッカーで色コード一致)
  □ フォントファミリー・サイズ・行間が同じ
  □ ボタン・カード・装飾の見た目が同じ
  □ 線・影・グラデーション・border-radius が同じ
  □ アイコンの種類・サイズが同じ

【アニメーション・挙動】
  □ スクロールアニメーションの動き方が同じ
  □ ホバー時の反応(色変化・拡大等)が同じ
  □ クリック時のフィードバックが同じ
  □ ローディングアニメーションが同じ
  □ メニュー開閉の動きが同じ
  □ タイミング(0.6s等)・イージング(ease-in-out等)が同じ
  □ アニメーション連鎖順序(loader→FV→中身)が同じ

【インタラクション】
  □ 全ボタン・リンク・メニューが正常に動く ← 置換漏れの一番出やすい箇所
  □ フォーム送信が動く
  □ スクロール・タブ・モーダル等のJS機能が動く
  □ 外部連携(問い合わせ・SNSシェア)が動く

【レスポンシブ】
  □ スマホ表示が崩れてない
  □ タブレット表示が崩れてない
  □ PC幅(1920px / 1440px / 1280px)で崩れてない

  [1] 全部「変わってない」 → Step 5/12（案件依頼書 流し込み）へ
  [2] 壊れた箇所がある → どこか教えて（置換漏れを特定して直します）
  [3] Step 3 に戻る（オリジナル化前に戻す）
  [4] 終了

→ もし[2]なら、リネームマッピング表と照合して漏れた箇所を特定 → 修正 → 再確認。壊れたまま進めない。

大原則違反検知: 構成・デザイン・アニメーションのどれかが少しでも変わってたら、それは大原則違反。即やり直し。
参考HPの「良いところ」を持ち込むのがTERASUの価値。それを少しでも崩したら 参考にした意味も商品価値もなくなる。

---

Step 5/12: 案件依頼書の流し込み

起動時の提示

━━━━━━━━━━━━━━━━━━

 Step 5/12: 案件依頼書の流し込み

案件依頼書を送ってください:
  [a] テキスト直貼り
  [b] ファイルパス（Vault内ファイル等）
  [c] PDF添付
  [d] スキップ（依頼書なしで完了）

処理ルール

守ること（=変更してはいけない）

1. HTML構造: タグ階層、順序、class名（t-*化済み）、id名、data属性 ← 変更しない
2. CSS / レイアウト: セレクタ・プロパティ・値、余白、グリッド、Flex、レスポンシブ、フォント、色、アニメ ← 維持
3. 既存の挙動: JavaScript動作、リンク先、フォーム送信先 ← 変更しない

やること（=依頼書の内容を反映）

1. テキスト差し込み: Step1-2で入れたダミー文を、依頼書の実テキスト（見出し・本文・ボタン文言）に差し替える。文字数がHP側の枠を超える場合 → 「○文字オーバーします」と 事前報告
2. 画像差し替え（必須）: Step1-2で残した元サイトの画像を、依頼書指定の画像／TERASU用意の画像に全部差し替える。← ここで元画像が1枚でも残ると Step7 著作権監査で止まる。元画像ゼロが必須
3. 配色: 依頼書の世界観を反映（元の配色・ロゴ・文言は使わない・柔軟に変更OK・レイアウト/フォント/アニメは崩さない）
4. 対応表の明示: 依頼書のどの項目をどこに入れたか最後に対応表で提示

配色・トーン反映の「範囲」（大規模リスキン禁止）— 2026-06-20 大串FB・恒久・絶対遵守
依頼書のトーン語（「ダーク基調」「プレミアム」「高級」「ミニマル」等）は コンテンツ・コピーの方向性 であって、参考HPのデザイン（明暗構造・各セクションの配色・レイアウト）を再スキンしてよいという許可ではない。流し込み（Step5）も改良（Step6）も参考デザインの忠実保持が大原則（参考にした理由＝そのデザインが良いから）。
- やってよい配色変更＝局所的なもの: アクセント1色の差し替え（例 #ff305f→ブランド色）、ロゴ/ブランド色の反映。
- 勝手にやらない: 全面ダーク化／グレースケール反転／明色セクションの一括暗色化／フォント刷新／セクション配色の大規模変更／リスキン。ブリーフに「ダーク」とあっても、元が明暗混在なら混在のまま保持する。
- どうしても大規模な配色変更が要りそうなら → 着手前に1問だけ確認、or 1セクションだけサンプルを出してOKをもらってから全体展開（改良フェーズ運用プロトコルの複数パターン方式）。19ページ分を勝手に作り込んでから見せるのは禁止（却下時の手戻りが大きい）。
- 発端: GIST(jillion)デモのStep6で、依頼書「ダークトーン基調」を根拠に明色節を全19ページ完全ダーク反転→大串「全面ダーク化やめて」で即revert。feedback_no-unsolicited-arrangements（言われていないアレンジをしない）のStep5/6版。スナップショット運用で即戻せた＝ver管理の有効性。

SEO/CVコピーライティング（流し込みと同時にコピーを「強く」する・2026-06-16 大串FB・恒久・絶対遵守）

依頼書のテキストをそのまま入れて終わりにしない。 ①SEOで取りたいキーワードから逆算 ②問い合わせ（CV）が増える導線文言、の2軸でコピーを設計する。デザイン（レイアウト・文字数枠）は崩さない範囲で言葉を磨く。

1. SEOキーワード逆算（最初に決める）

• 案件の「取りたいキーワード」を確定（依頼書になければヒアリング or 業種×地域×サービスで提案）
• メインKW（例「渋谷 美容室」「税理士 福岡」）／サブKW／指名・ロングテール
• 検索意図（何を知りたくて検索する人か）を1行で言語化
• キーワードを自然に配置: h1(1つ・メインKW)／h2(セクション見出し・サブKW)／本文冒頭／CTA周辺。詰め込みすぎ(キーワードスタッフィング)はNG・読んで自然に
• title/meta descriptionの種もここで作る（Step10で最終確定）

2. 問い合わせ導線（CV）設計

• ファーストビュー: 3秒で「何屋か・誰向けか・選ぶ理由」が分かるキャッチ＋サブコピー
• ベネフィット: 機能でなく「お客様がどう良くなるか」で書く（「制作実績100件」→「初めてでも安心して任せられる」）
• CTA文言: 行動＋ベネフィット（「お問い合わせ」→「まずは無料でご相談」「30秒で相談予約」）。FV・中間・フッターに複数配置
• 不安解消: 料金の明示／よくある質問／実績・お客様の声 で問い合わせ前の不安を消す
• フォーム前の一押し: 「しつこい営業はしません」等の心理的ハードル下げ

3. 重要コピーは複数案→選定

• 見出し・FVキャッチ・CTA文言は1案で決めず、2〜4案出して大串/クライアントに選んでもらう
• 各案に狙い（SEO寄り / 感情訴求 / ベネフィット直球 等）を一言添える

4. デザイン不変の鉄則

• 文字数・行数は既存デザインの枠に収める（はみ出してレイアウトを崩さない）。超える場合は「○文字オーバー」と報告して短い案を出す
• 見出しの文字サイズ・改行位置・ボタン幅は変えない＝見た目はそのまま、言葉だけ強くする

GitHub立ち上げ ＋ 専用プレビューリンク発行（クライアント用は案件開始時=Step1着手時に前倒し実行・2026-06-30 大串FB・恒久・絶対遵守）

【デモ用もこのGitHub立ち上げを実行する（2026-06-30 大串FB・前回のスキップから変更）】。 デモもクライアント用と同じく、案件開始時にデモ名でGitHubリポ＋固定プレビューリンク preview.demo-◯◯.pages.dev（slugは client- でなく demo- プレフィックスにするだけ）を立ち上げ、pushして改修・共有する。違いは出口だけ＝デモは本番ドメイン接続（Step11）をせず、Step9 Lab還元＋/demos/公開がゴール。

依頼書を読んで会社名／HP名が確定したこのタイミングで、GitHubリポジトリを作り「専用プレビューリンク」を発行する。 以降の改良（Step6〜10）は全部このプレビューリンクで大串・クライアントに共有しながら進める。git push するだけで自動デプロイ（約30秒）＝ver管理・バックアップ・履歴が全部自動になる。

前提・secret運用（2026-06-30 実地検証で確定）: GitHub Actions のデプロイには CLOUDFLARE_API_TOKEN（Cloudflare Pages:Edit 権限）が必要。

【重要・ハマりどころ】Org（scale-group-jp）は現在 Free プラン。Free では private リポで Organization secret が使えない（GitHub仕様）。gh secret set --org ... --visibility all で登録しても private リポの Actions には渡らず、初回デプロイが必ず失敗する（In a non-interactive environment, it's necessary to set a CLOUDFLARE_API_TOKEN）。
→ 対策＝リポ単位の secret を必ず設定: printf '%s' "$TOKEN" | gh secret set CLOUDFLARE_API_TOKEN ●●●●●● scale-group-jp/<PROJ>。
→ これらを全部やるワンコマンド: ~/hp-flow-work/bin/new-hp-preview.sh <slug> <siteディレクトリ> [client|demo]（リポ作成→コード配置→workflow→リポsecret設定→push→自動デプロイ）。token は ~/.config/scale/cloudflare_pages_token(chmod 600) から読む。新規HPの初期設定は実質この1コマンド。
→ 真の「Org secret 1回で全案件自動」にしたい場合は GitHub Team プランへの課金が必要（その時のみ gh secret set --org が private に効く）。
補足: workflow ファイル(.github/workflows)の push には gh トークンに workflow scope が必須。

手順（Claudeが全自動・人間の操作なし）:

# 1. 会社名から repo slug を決める（例: 株式会社ハナミ → client-hanami）
SLUG="client-{会社slug}"
# 2. GitHubリポジトリ作成（プライベート）＋ clone
gh repo create scale-group-jp/$SLUG --private
cd ~/dev && git clone git@github.com:scale-group-jp/$SLUG.git && cd $SLUG
# 2.5 制作チーム(terasu-seisaku)に編集権限付与＝メンバー全員が push 可に（権限抜け再発防止・2026-06-15）
gh api -X PUT orgs/scale-group-jp/teams/terasu-seisaku/repos/scale-group-jp/$SLUG -f permission=push
# 3. ここまでの成果物（Step1-5の完成HP一式）を配置
# 4. 自動デプロイ workflow を配置（下記テンプレ・project-name を $SLUG に置換）
mkdir -p .github/workflows   # → deploy.yml（下記）
# 5. Cloudflare Pages プロジェクト作成
unset CLOUDFLARE_API_TOKEN; npx wrangler pages project create $SLUG --production-branch=main
# 6. preview ブランチで初回push → プレビューリンク発行
git checkout -b preview && git add -A && git commit -m "init: $SLUG HP" && git push -u origin preview
# → 専用プレビューURL: https://preview.$SLUG.pages.dev を大串に共有（本番ドメイン無影響）

workflowテンプレ（.github/workflows/deploy.yml・preview/prod 自動切替）:

name: Deploy HP
on:
  push:
    branches: [main, preview]
  workflow_dispatch:
concurrency:
  group: deploy-${{ github.ref_name }}
  cancel-in-progress: false
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secret●●●●●● }}
          accountId: 9c601cdb4666c746e5cb97fa00187f06
          command: pages deploy . --project-name={SLUG} --branch=${{ github.ref_name }}

→ preview ブランチへ push = プレビューURL（本番無影響・作業中はこれで共有）／ main ブランチへ push = 本番ドメイン。Step11（本番公開）まで main は使わず preview だけで進める。

完了確認

 Step 5/12 完了（依頼書反映済み）

最終納品物:
  - 完成HP（オリジナル化 + 依頼書反映済み）
  - プレビューURL: {URL}
  - 差し込み対応表

懸念点:
  - 文字数オーバー: {あれば}

次どうする?
  [1] Step 6/12 へ（改良ループ）
  [2] Step 5 やり直し
  [3] Step 4 に戻る
  [4] 完了して終了

---

Step 6/12: 改良ループ（デザイン・コピーを磨く）

デザイン・コピーをどんどん改良するフェーズ。 ユーザーの改善FBを受けてHPを磨く。同時にコマンド自体もFBで進化する。

挙動

━━━━━━━━━━━━━━━━━━

 Step 6/12: 改良ループ

完成版をベースに、気になる箇所を改善していきます。
改善したい点を自由に教えてください（例:「ここの余白広げて」「CTAもっと目立たせて」）。

  - 改善FB → その場で反映 → プレビュー更新
  - 「次からも毎回こうして」系のFB → コマンド本体に学習（セルフ進化）
  - 「これで完成」→ Step 7（レスポンシブ対応）へ

何を改善する? それとも「完成」?

このステップでのFB

• HP個別の改善（この案件だけ）→ その場で反映
• フロー全体の改善（「次からこうして」）→ セルフ進化プロトコルで hp-flow.md 本体に反映 + learning.md 記録

→ 改良が一段落して「完成」と言われたら Step 7（レスポンシブ対応）へ。

---

Step 7/12: レスポンシブ対応（全端末幅で崩さない・SEOの前・公開前の必須ステップ）

2026-05-30 大串FB・恒久。 デザインがある程度固まったら（改良ループ後）、SEO/公開の前にレスポンシブ対応を必ず入れる。先に対応を実施してから「各端末で見てFBください」と依頼する（対応前に確認依頼しない）。

対象は「スマホだけ」でなく全端末幅（2026-06-29 大串FB・恒久・「スマホ最適化」からリネーム）。 大串FB「見た目は絶対変えないうえで、スマホや他の端末の大きさに合うように調整。スマホだけでなくPCの大きさでも調整かけれたらベスト→名前もレスポンシブ対応に」。→ 大画面PC(2560/1920) 〜 小型ノート(1440/1366/1280) 〜 タブレット(1024/768) 〜 スマホ(430/390/375/360) の全レンジで、確定したデザインの見た目（意図）は1pxも変えずに各幅へフィットさせる。従来の「スマホ最適化」はこのレスポンシブ対応の一部（最も手数が多い帯）で、下記の標準パック・実装テク集はそのスマホ帯の蓄積。

2026-06-25 大串FB・恒久。レスポンシブ対応は「後で毎回手直しする工程」から「初回から作り込まれている標準」へ。 大串FB原文「毎回このくらいやらないといけないのは大変で工数なく、どんどん学習して初回のアウトプットがめっちゃいい状態にしたい」。
→ 下記「 TERASU SP最適化 標準パック」を Step5（流し込み）の時点で先に当てる（①日本語SP改行クラス ②共通CONTACT/CTAのSP最適化 ③文言のSP言い換え ④共通パーツ横展開）。Step7 の役割は「ゼロから直す」から「標準パックを当てた状態で実機の残差だけ詰める＋PC不変を検証する」へ変わる＝毎回の手直し量を構造的に減らす。
→ 各案件で出たSP系FBは「他HPにも効く汎用」か「この案件固有」かを必ず仕分け、汎用は標準パックに昇格させて次回の初回アウトプットに自動で乗せる（末尾「 SP最適化の横展開・自己進化ループ」）。これが「使うほど初回完成度が上がる」体制の核。

最重要の注意点（絶対遵守）

レスポンシブ対応の唯一にして最大のリスク = 基準デザイン（確定したPCの見た目）が崩れること。
各端末幅へフィットさせるために足したCSSが、基準レイアウトを壊す事故を物理的に防ぐ。
「PC幅でも調整する」と「基準デザインを変える」は別物。 基準（確定デザイン幅・例1440px）の見た目は不変／その上で 大画面・小型ノート・タブレット・スマホ の各幅にフィットさせるのはデザイン改変ではない（＝大串FB「見た目は絶対変えない上で端末サイズに合わせる」）。

• Step7中の修正依頼はレスポンシブ対応だけに限定（2026-08-16 大串FB・恒久）。Step7中に「◯◯をコンパクトに」等の見た目系FBが来ても、PC（基準デザイン）は一切変えず@media内のみで対応する。PCデザインの変更を伴う要望は勝手に適用せず「Step6（改良ループ）に戻して直しますか？」と大串に確認（実例: WORKSカード縮小をPCにも当ててしまい復元になった）
• 各幅の調整は @media クエリの中だけに書く（基準デザイン幅に影響しないブレークポイント内に限定。大画面側は min-width、狭い側は max-width）
• 基準デザイン（確定したPC見た目）のルールを書き換えない（上書き・削除しない／メディアクエリ内で完結させる）
• 作業中・作業後に 大画面(2560/1920) / 小型ノート(1440/1366/1280) / タブレット(1024/768) / スマホ(430/390/375/360) の全レンジでプレビュー確認
• 1px単位で基準デザインが変わってないか、対応前後でスクショ比較

レスポンシブ チェック項目（全端末幅）

項目	内容
大画面PC	1920/2560で間延び・余白過大・要素が伸び切らないか
等比ズーム（最重要・iMac↔MacBook FB根治）	MacBookで確定した画面を、iMac等の大画面では"そのまま等比ズーム"する（左右に余白を作らない）。 基準幅(MacBook・通常1440)以上で zoom:calc(100vw/基準幅)→文字・余白・要素が全部比例拡大しMacBookと相似＝余白感そのまま・左右余白ゼロ・間延びゼロ。基準幅未満(タブレット/スマホ)は通常レスポンシブ（→標準パック⑤）
小型ノート	1440/1366/1280で横スクロール・折返し崩れ・はみ出しなし
タブレット	1024/768（横・縦）でグリッド段落ち・ナビ切替が破綻しない
ブレークポイント	主要幅(〜768 / 〜480)で破綻なし・横スクロール無し
タップ領域	ボタン/リンクは最低 44×44px・近接要素と十分な間隔
文字サイズ	本文 ≥16px相当（iOS自動ズーム防止）・行間/余白の最適化
画像/動画	はみ出さず・適切に縮小・重い画像は軽量化
ナビ/メニュー	スマホでハンバーガー等が正常に開閉
FV/見出し	スマホで主役要素が見切れず読める
固定要素	ヘッダー/CTA固定がスマホで邪魔/被りしてない
フォーム	入力欄/送信がスマホで操作しやすい
基準デザイン不変	対応前後で基準（確定PC）の見た目が完全一致（最重要）

TERASU SP最適化 標準パック（初回から当てる・手直しを撲滅）— 2026-06-25 TERASU公式HP実戦で確立

このパックは「毎回出る同じFB」を型にしたもの。 Step5（流し込み）の時点で先に当てておけば、Step7での手直しが激減する。5点セット＝①日本語SP改行クラス ②共通CONTACT/CTAのSP最適化 ③文言のSP言い換え ④共通パーツの全ページ横展開（①〜④はSP帯＝@media内でPC不変）＋⑤PC幅 等比ズーム（MacBook基準・iMac等の大画面はそのまま拡大／左右余白ゼロ）。

① 日本語SP専用改行クラス（最重要・毎回効く）

問題: 日本語の長い見出し・リード文・FAQ・キャッチは、スマホ幅(375px=全角約16字)で「単語/フレーズの途中」や「変な位置」で折り返し、読みにくく安っぽく見える。
型: SP幅でだけ表示される改行クラスを <head> 内に1つ用意し、本文の 意味の切れ目（文節・句点/読点の後） に挿入する。PCには display:none で一切出ない。

<style id="sp-line-fixes">
/* SP専用改行：PCでは出ない（display:none）。閾値は元サイトのSP切替に合わせる */
.u-spbr{display:none}
@media only screen and (max-width:766px){.u-spbr{display:inline}}
</style>

• 本文側： 見たほうが早い。<br class="u-spbr">TERASUが作る実例を… のように 読点・句点・助詞の後で改行（フレーズ途中で割らない）
• 空行（呼吸）が欲しい所は二重 <br class="u-spbr"><br class="u-spbr">（段落内の意味区切り）
• 閾値は案件ごとに変える（TERASU公式HP=index/共通は766px・aboutの長文セクションは880px=.t-sp-br）。1案件内で複数閾値が要るならクラスを分ける
• PCに改行を出さないのが絶対条件。display:none→@media{inline} で必ず制御。素の <br> をPCにも出すと崩れる

② 共通CONTACT/CTAのSP最適化（テキスト左・矢印密着）

問題: フッターやCTAの「テキスト＋矢印」ブロックは、PC設計のままだとSPでテキストと矢印が大きく離れて間延びする。
型: SPで flex横並び＋矢印をabsoluteでテキスト直後に密着。タイトルは縮めて white-space:nowrap、本文は12.5px前後。（クラス名は案件ごとに置換。下はTERASU公式HP=kurokitec系テーマの実装例）

@media only screen and (max-width:766px){
  .cm-f__main,.cm-f-cont{width:100%!important;max-width:100%!important;box-sizing:border-box!important}
  .cm-f__mainContact{width:auto!important;max-width:100%!important;margin:0 16px clamp(3rem,7vw,5rem)!important}
  .cm-f__mainContactTarget{display:flex!important;flex-direction:row!important;align-items:center!important;justify-content:flex-start!important;position:relative!important;padding:1.9rem 1.4rem!important}
  .cm-f__mainContactTarget .body{display:block!important;flex:0 0 auto!important;width:auto!important;text-align:left!important}
  .cm-f__mainContact .body__title{font-size:1.4rem!important;white-space:nowrap!important;margin:0 0 .5rem!important;letter-spacing:0!important}
  .cm-f__mainContactTarget .body .body__txt{font-size:12.5px!important;line-height:1.7!important;text-align:left!important}
  .cm-f__mainContactTarget .arrow{position:absolute!important;left:61%!important;right:auto!important;top:50%!important;transform:translateY(-50%)!important;margin:0!important;width:52px!important;height:52px!important}
  .cm-f__mainContact .arrow__icon{width:52px!important;height:52px!important}
}

• 汎用ロジック=「テキストをflexで左寄せ→矢印を position:absolute でテキスト直後(left:約60%)に密着→translateY(-50%) で縦中央」。flexだとテキスト幅に縮まず空白が出るので矢印はabsoluteが正解（flexのまま放置はNG）

③ 文言のSP言い換え（読みやすさ・構造化データ同期）

• 略語・口語を正式名称へ：HP→ホームページ、つくる→作る
• 長い/曖昧な数字を具体化・表記統一：数百万→300万、2,000,000円→300万円
• 読点を減らしてリズムを整える（狭い画面で一文が長いと読みにくい）
• 構造化データ(JSON-LD)があるページは、本文を変えたら JSON-LD側も同じ文言に必ず同期（FAQPage等。本文だけ直すとリッチリザルトと食い違う）

④ 共通パーツは1回直して全ページ横展開

• ヘッダー/フッター/CONTACT/CTA等の共通パーツのSP-fixは、1ページで確定したら全ページの同じ箇所へ同一CSSを注入（TERASU公式HPは sp-line-fixes ブロックを11ページの </head> 直前へ）
• 1ページだけ直して終わりにしない＝「あのページだけSPが古い」を防ぐ

⑤ PC幅 等比ズーム（MacBook基準・iMac等の大画面はそのまま拡大）— 2026-06-29 大串FB・最重要

問題: MacBook(13"≈1280〜1440px)で完璧に見えても、iMac(27"5K≈2560px)や外部モニタで開くとコンテンツが横に広がり余白が間延びする。中央寄せ(max-width固定)だと左右に余白が出る→大串はそれが気になる。大串FB「左右の余白が気になるのだから、iMac等の大きい画面ではMacBookの画面がそのままズームされる感覚にしてほしい」。
型（＝基準幅以上では画面全体を等比ズーム。左右余白ゼロ・余白比率はMacBookと完全一致）:

/* 基準幅(MacBook)以上では、超えた分だけページ全体を等比拡大＝MacBook画面をそのままズーム */
@media (min-width: 1441px){
  :root{ zoom: calc(100vw / 1440); }   /* 1440で確定したデザインを画面幅まで等比拡大。左右余白ゼロ */
}

より堅牢（スクロールバー幅の誤差で横スクロールが出るのを防ぐJS版・こちら推奨）:

/* clientWidth(スクロールバー除外)で正確に等比ズーム。基準幅未満は無効化して通常レスポンシブに戻す */
(function(){ var base=1440; function fit(){ var d=document.documentElement;
  d.style.zoom = innerWidth>base ? (d.clientWidth/base) : ''; }
  addEventListener('resize',fit); fit(); })();

• 要点: 基準幅(MacBookでOKをもらった幅・通常1440)を1.0倍とし、それ以上の画面では 画面幅÷基準幅 倍に全体ズーム。文字・余白・要素すべてが等比拡大＝MacBookの見た目そのまま・左右余白ゼロ・余白比率不変。例: iMac 2560px → 約1.78倍。
• 基準幅未満（タブレット/スマホ）にはズームをかけない（既存の @media レスポンシブが効く）。ズームは大画面側だけ。
• zoom 採用理由: transform:scale() と違いレイアウトフロー・position:fixed・スクロール量が正しく保たれる。全モダンブラウザ（Chrome/Edge/Safari/Firefox126+）対応済（2026時点）。
• 横スクロール注意: CSSの 100vw はスクロールバー幅を含むので僅かに横スクロールが出ることがある→JS版(clientWidth)が確実。CSSだけで出たら係数を僅かに下げる。
• 上限キャップ（任意）: 超巨大4Kで文字が大きすぎるなら zoom: min(calc(100vw/1440), 1.6) 等で上限可。標準は青天井（そのままズーム＝大串の希望）。
• 基準幅の決め方: MacBookで「これが完成」とOKをもらった時の表示幅（通常1440px）。元サイトにコンテナ最大幅があればそれを基準に。
• 検証: 1440(基準=1.0倍)/1920/2560(iMac)で開き、レイアウトがMacBookと相似（全体が比例拡大・左右余白なし・横スクロールなし）を確認。responsive-check.html ビューアで1440と2560を並べて相似か目視。

スマホ実装テクニック集（2026-06-15 TERASU HP実戦で確立・大串依頼で体系化）

「PCの見た目を変えずにスマホだけ直す」を事故なく回す実戦ノウハウ。原理は メディアクエリの中に書けば構造的にPCへ影響しない ＋ 変更後にPCをbefore/afterで照合すれば100%証明できる の2枚。

1. 背景montage/装飾が透ける時は多層構造を疑う。elementFromPoint(x,y) でその座標の実要素を特定（憶測で1つ消すと別の層が出て泥沼）。TERASU実例: 黒montageは serviceBodySlider → tphf → serviceBg の3層で真因はセクション背景 serviceBg。FVの position:fixed 背景はスクロール後も残るので、①セクションに不透明背景+高z-indexで覆う ②is-fvclip-unlocked等のスクロール後クラスで非表示、のどちらか。
2. 消すなら opacity:0 > visibility:hidden。visibilityは子にvisible明示があると上書きされて効かない。opacityは親で合成され確実。
3. CSSセレクタは実DOM階層を querySelectorで辿って確認してから書く。推測で書くとtransform等がnoneのまま効かず気づきにくい。TERASU実例: 背景英字「WHAT WE DO」は .p-ism__missionBody でなく .p-ism__spiritsHeadTitle 配下。getComputedStyle(el).transform==='none'ならセレクタ不一致を疑う。
4. 絵文字化する記号文字（↗ U+2197 等）。iOSはカラー絵文字化・PCはテキストでズレる。U+FE0Eを直後に足すとPC同様テキスト矢印に統一（↗→↗︎）。
5. スマホ専用要素(ハンバーガーメニュー等)のHTML編集はPC不変。PCでdisplay:noneの要素(cm-nav等)はHTML変更がPCに出ない＝@media不要で直接編集してよい。
6. 相対単位で機種差を自動吸収。clamp(下限,理想vw,上限)でSE(375)〜ProMax(430)〜Android全機種が自動フィット。固定pxは小機種ではみ出す。1機種ずつ対応しない。
7. 速度=過剰解像度画像のリサイズが最大効果。@2xは「表示実寸×2」で十分(240px表示→480px。880px等は過剰)。ただし元から最適化済みPNGはsips再エンコードで逆に増えるので必ず前後サイズ比較。FV画像fetchpriority="high"は先頭数枚に絞る(全部highはLCP悪化)、eagerは白チカ対策で維持。
8. 検証はローカル実機で。Claude Preview のpreview_resize(mobile/PC)＋preview_eval(computed数値)＋スクショ。PCはheadless Chrome 1280で撮る(preview iframeは~846pxまでで@media発動域に入るため880超はheadless必須)。elementFromPoint/getBoundingClientRectで「見切れright>innerWidth」「重なり」を数値判定。

マルチデバイス確認ビューア（端末を持ってなくても全幅を画面上で確認・2026-06-29 大串FB・恒久）

大串FB「スマホ・タブレット・PCなど選んだらその画面で見れる機能があるとめっちゃいい。今は自分の持ってる端末でしかチェックできない」。→ プレビューと一緒に responsive-check.html を置き、デバイスボタンで iframe 幅を切り替えるビューアを毎回生成。大串・クライアントは実機が無くても、ボタン1つで各端末の見え方を確認できる。

手順:
1. 完成HP（or プレビュー）と同じフォルダに responsive-check.html を生成（下記テンプレ。iframe の src は対象トップHTMLに合わせる）
2. ローカルプレビューサーバで配信 → タップリンク [レスポンシブ確認](http://localhost:PORT/responsive-check.html) で大串に渡す
3. Claude側も preview_resize で 375/768/1280/1920 を撮って各幅スクショを添付（大串が開く前に崩れを潰す）
4. シェア表示も同時確認（下記Step10「ブラウザ・SNSシェア表示」とセット）: OGPは ラッコツールズ OGP確認 / metatags.io に本番URLを入れ、リンクシェア時の見え方を実機確認（公開後）

responsive-check.html テンプレ（自己完結・そのまま置けば動く）:

<!doctype html><html lang="ja"><head><meta charset="utf-8"><title>レスポンシブ確認</title>
<style>
 body{margin:0;font-family:system-ui;background:#1e1e1e;color:#eee}
 .bar{display:flex;gap:6px;flex-wrap:wrap;align-items:center;padding:10px;background:#111;position:sticky;top:0;z-index:9}
 .bar button{padding:7px 10px;border:1px solid #444;background:#2c2c2c;color:#eee;border-radius:6px;cursor:pointer;font-size:13px}
 .bar button.on{background:#3a82f6;border-color:#3a82f6}
 .bar input{width:74px;padding:6px;border-radius:6px;border:1px solid #444;background:#2c2c2c;color:#eee}
 .stage{display:flex;justify-content:center;padding:18px;overflow:auto}
 .frame{background:#fff;box-shadow:0 0 24px rgba(0,0,0,.5);transition:width .2s}
 iframe{width:100%;height:calc(100vh - 110px);border:0;display:block}
 #cur{margin-left:auto;color:#9ab}
</style></head><body>
 <div class="bar"><b>📐 端末幅</b>
  <button data-w="375">📱SE 375</button><button data-w="430">📱ProMax 430</button>
  <button data-w="768">📲タブ縦 768</button><button data-w="1024">📲タブ横 1024</button>
  <button data-w="1280">💻ノート 1280</button><button data-w="1440">💻ノート大 1440</button>
  <button data-w="1920">🖥️大画面 1920</button>
  <input id="cu" type="number" placeholder="任意px"><button id="ap">適用</button>
  <span id="cur"></span>
 </div>
 <div class="stage"><div class="frame" id="fr"><iframe id="f" src="./index.html"></iframe></div></div>
 <script>
  var fr=document.getElementById('fr'),cur=document.getElementById('cur');
  function set(w){fr.style.width=w+'px';cur.textContent=w+'px 表示中';
   [].forEach.call(document.querySelectorAll('.bar button[data-w]'),function(b){b.classList.toggle('on',+b.dataset.w===w)});}
  [].forEach.call(document.querySelectorAll('.bar button[data-w]'),function(b){b.onclick=function(){set(+b.dataset.w)}});
  document.getElementById('ap').onclick=function(){var v=+document.getElementById('cu').value;if(v)set(v)};
  set(375);
 </script></body></html>

→ src の ./index.html は案件のトップHTMLに合わせる（下層は内部リンクで辿れる）。デモ用でも生成して渡す＝トップだけでも各端末の見え方を確認できる。

進め方（標準パックを先に当てる → 実機で残差だけ詰める → 確認依頼）

0. 【Step5流し込み時に前倒し】標準パック①②③④を当てておく（初回完成度を底上げ）
1. 全端末幅(大画面2560/1920・小型ノート1440/1280・タブレット1024/768・スマホ430/390/375/360)で「標準パック適用後に残った崩れ」を洗い出し
2. @media内だけで修正（基準デザインのルールは触らない）＋共通パーツは全ページ横展開
3. 全レンジ＋基準デザイン幅でプレビュー → 基準デザイン不変を before/after で確認
4. ver+1 で本体反映 + backup（GitHub運用案件は commit & push）
5. ここで初めて大串に「レスポンシブ対応しました。各端末（スマホ/タブレット/PC幅）で確認してFBください」と依頼
   （プレビューURL or 本体localhost を案内・QR/直リンク添付）
6. 大串FBを反映 → 出たFBは下記ループで「汎用か固有か」を仕分けて学習

完了確認

 Step 7/12 完了（レスポンシブ対応）

  - 全端末幅: 大画面2560/1920・小型ノート1440/1280・タブレット1024/768・スマホ430/390/375/360 で破綻なし・横スクロール無し
  - タップ領域/文字サイズ/画像/ナビ: 全項目 
  - 基準デザイン不変: 対応前後で確定PC見た目 完全一致 
  - ver: ver{N} で本体反映済 / backup有

  → 各端末（スマホ/タブレット/PC幅）でFB依頼済み。FB反映が一段落したら:
  [1] Step 8/12（著作権 最終監査）へ
  [2] スマホFBをさらに反映する
  [3] Step 6（改良ループ）に戻る

→ スマホFBが一段落したら Step 8/12（著作権 最終監査）へ。

SP最適化の横展開・自己進化ループ（2026-06-25 大串FB・恒久）

大串FB「HPコマンドでみんながHPを作る中で出たFBで、他のHPにも使えそうな部分は学習して、アウトプットの質が上がる体制にしたい」。スマホFBを毎回ここで仕分け、汎用は標準パックに昇格させて次回の初回アウトプットに自動で乗せる。

FBの種類	判定	アクション
他HPにも効く汎用（日本語SP改行の当て方・共通CTA/フッターのSP型・文言言い換え・画像/速度・検証手法 等）	昇格	上の「標準パック」or「実装テクニック集」に追記 → learning.md 確定表に1行 → 次回案件の初回から自動適用
テーマ共通の実装（同じCMS/テーマ＝kurokitec系・STUDIO系等を使う案件群で再利用できるCSS）	昇格	標準パックにテーマ別の実装例として追記（クラス名はテーマ単位で使い回せる）
この案件だけの個別調整（特定セクション固有の見切れ等）	留置	その場で直すだけ。標準パックには上げない（肥大化防止）

• 仕分けの口ぐせ：「このFB、次の別HPでも同じこと言われる？」→ Yesなら昇格。
• 昇格したら learning.md に記録（セルフ進化プロトコル準拠）。これで使うほど初回レスポンシブ完成度が上がり、Step7の手直しが減っていく。

---

Step 8/12: 著作権 最終監査（公開前の必須ゲート）

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

デモ用でもこの監査は必ず実施（スキップ不可・2026-06-25 大串FB）。 デモは制作実績として外部に晒す＝「元サイトの真似」と思われたら致命的。むしろデモこそ指紋ゼロを徹底する。

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

参考HPの痕跡がコードに残ってないか、grepで全部確認:

cd {テンプレフォルダ}

# 0. 【最重要】元画像の残存チェック（Step1で元画像をそのまま使ってるので必ず確認）
#    元サイトのドメイン・画像URL・元画像ファイル名が1個でも残ってたらアウト
grep -rnE 'src=|background-image|url\(' . | grep -iE '{元サイトドメイン}|{元画像ファイル名の特徴}'
#    → 元画像が全部 案件画像 or フリー素材 に差し替わってるか確認

# 1. 元クラス名・id の残存（t- で始まらない独自っぽいクラスを洗い出す）
grep -rhoE 'class="[^"]*"' . | tr ' ' '\n' | grep -vE 't-|^class=' | sort -u

# 2. コメント・著作表記の残存（あったら即削除）
grep -rnE '<!--|/\*|//|@author|Designed by|Built by|Powered by' . | grep -v node_modules

# 3. 元サイト独自CDN・トラッキングの残存
grep -rnE 'cdn\.|googletagmanager|gtag|fbq|hotjar|clarity' . 

# 4. ファイル名・パスに元サイト名の痕跡
find . -type f | grep -iE '{元サイト名や独自っぽい単語}'

# 5. metaタグ・OGPに元サイト情報が残ってないか
grep -rnE 'og:|twitter:|<meta' *.html

# 6. CMS痕跡の残存（WordPress/Wix/Webflow/Shopify/STUDIO等・2026-06-13追加・petomo検収の教訓）
grep -rniE 'wp-polyfill|wp-content|wp-includes|wp-json|wpcf7|contact-form-7|wp-block|xmlrpc|wixstatic|data-wf-|cdn\.shopify|myshopify|studio\.site|jimcdn|mt-static|eccube|name="generator"' . | grep -v node_modules
# CMSの日付型アップロードパス（media/2023/12/ 等＝元サイトのアップ日が残る指紋）
find . -type d | grep -E '(media|uploads)/20[0-9]{2}'
# → 1件でもヒットしたら除去（JS/CSS参照は削除・ファイルはassets/へ移動＋参照書き換え）→ 削除後コンソールエラー0確認

# 7. 【最重要・2026-06-19 ai-model案件の教訓】アウトライン文字SVG（ブランド名が<path>で描かれた指紋）
#    テキストgrepでは絶対に検出できない（文字でなくパスだから）。inline SVG を全走査して
#    「path数が多い／aspect比が大きい(横長)」SVG＝アウトライン化された文字 を炙り出し、必ず描画して中身を読む。
python3 - <<'EOF'
import re,io
h=io.open("index.html",encoding="utf-8").read()
for m in re.finditer(r'<svg[^>]*viewBox="([^"]*)"[^>]*>(.*?)</svg>', h, re.S):
    vb=m.group(1); paths=m.group(2).count('<path')
    try: w,hh=[float(x) for x in vb.split()[2:4]]; asp=w/hh if hh else 0
    except: asp=0
    if paths>=5 or asp>4: print(f"  viewBox={vb} paths={paths} aspect={asp:.1f}  ← 描画して文字内容を確認")
EOF
# → 出たSVGを1枚のHTMLに並べて headless 描画(fill白/黒)→何の文字か目視。
#   ブランド名(社名/サービス名)がアウトライン化されていたら、その <path> 群を
#   <text textLength=幅 lengthAdjust="spacing" fill=元色>新ブランド名</text> に置換（viewBox/svgタグは保持）。
#   ※マーキー/ロゴ/見出しが「文字なのにpath」のサイトで多発。汎用ラベル(WHAT WE DO/FLOW等)は残してOK。

Step1で元画像をそのまま使う仕様にしたため、ここでの「元画像ゼロ」確認が特に重要。 元画像が1枚でも残ってたら著作権侵害。Step5で全部 案件画像 or フリー素材 に差し替わってるか必ず検証する。
アウトライン文字SVGの指紋は text-grep では検出ゼロになる（ai-model案件で reel マーキー "AI MODEL & MOVIE" が path で残存→危うく公開）。監査A-7 の SVG走査＋描画目視を必ず通すこと。

監査B: 著作権リスクチェック（目視 + 判定）

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

完了確認

 Step 8/12 完了（著作権 最終監査）

監査結果:
  - コード指紋 grep: 残存 {N}件 → {全部除去済み / 要対応}
  - 著作権チェック: {8項目すべて  / 要対応}
  - 第三者目線: {真似と感じない / 要修正}

  [1] 全項目クリア → Step 9/12（TERASU Lab セクション還元）へ
  [2] 引っかかる箇所あり → 修正する（どこか特定して直す）
  [3] Step 6 に戻る
  [4] 終了

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

---

---

Step 9/12: TERASU Lab セクション還元（完成したら必ず・デモの締め）

2026-06-13 大串FB・恒久・最重要＝TERASU事業の肝。 完成HP（デモ含む）から、良いアニメ・デザイン・構成を セクション単位で細分化 して TERASU Lab の「セクション」(git版 ~/dev/lab-terasu の entries/<id>.json) に登録する。全制作担当がこの蓄積を使い回して効率化＋品質UPする世界を作る。デモこそ積極的に還元（デモは公開ステップに進まないので、ここが実質ゴール）。

2026-06-17 大串FB・恒久・絶対遵守＝push前に必ずプレビューを見せてOKをもらう。 大串FB原文「毎回プレビューで一回私に見せてから最終でTERASULABのセクションページに入れて」。Lab還元(Step9)は「①ローカルでスニペット完成→②大串にプレビュー(タップリンク＋スクショ)を見せる→③大串の『OK/入れて』をもらう→④初めて git commit & push(本番Lab反映)」の順を毎回厳守。 承認を待たず先にpushするのは禁止（前回それをやって指摘された＝本ルールの発端）。理由: 還元元の「どのセクションをどう忠実再現したか」を大串が確認してから本番Labに載せる（精度担保＋意図ズレ防止）。例外は大串が「もう入れていい」「確認不要」と明示した時のみ。StepCの[1]OK→pushはこのOKを大串からもらうという意味。

なぜ必須か

• 良いものが「作って終わり」で流れるのを防ぐ。1案件＝Labが1段強くなる。
• 次回HPで「あの時のFV使いたい」→ Labから即コピペで入る状態を作る。

登録先の正本（絶対・2026-06-15 git移行＋entries分割で competゼロ化）

• リポジトリ: ~/dev/lab-terasu（GitHub: scale-group-jp/lab-terasu）。初回のみ git clone git@github.com:scale-group-jp/lab-terasu.git ~/dev/lab-terasu
• Drive版 AI/lab-terasu は凍結・編集禁止（同期競合・データ消失のため）。sections.html も手編集しない（fetchするだけ）
• 公開: lab.terasu.scale-group.co.jp/sections（Cloudflare Pages lab-terasu）
• 1エントリ = 4点セット: ①entries/<id>.json を新規作成（SECTIONS配列直書きは廃止）②メディア img/sections/<id>.png(+動きは.mp4) ③自己完結コード code-previews/<id>.html ④python3 build.py で sections-data.json 再生成
• id命名（競合ゼロの肝）: <案件>-<種別>-<担当>-<MMDD>（例 babuutalk-fv-saki-0615）。担当・日付を入れて他メンバーと絶対に被らせない＝何人が同時に還元しても競合しない（新規ファイルだから）

データ構造（entries/<id>.json・JSON形式）

{ "id": "案件-種別-担当-MMDD",
  "cats": ["fv"],
  "img": "img/sections/<id>.png",
  "url": "案件のプレビューURL or 案件名",
  "caption": "業種｜種別：特徴",
  "snippet": "code-previews/<id>",
  "author": "担当名",
  "created_at": "YYYY-MM-DD" }

• cats(分類): fv / navbar / heading / features / service / works / gallery / news / logos / access / pricing / faq / qa / testimonial / cta / footer / motion / preloader / layoutdesign（複数可）
• 動画も登録する場合は img の代わりに "media":[{"type":"image","src":"...png"},{"type":"video","src":"...mp4","poster":"...png"}]
• snippet は .html 無しで書く（CF配信仕様）・コード本体に <!-- COPY:START -->〜<!-- COPY:END --> 必須

処理フロー（スクショ/動画ドリブン・人間が選ぶ・Claudeは忠実に再現）

再利用価値の自動判定・全セクション自動列挙はしない（2026-06-13 大串FB）。何をLabに入れるかは人間が決める。 Claudeは「送られた箇所を忠実に・間違えずに特定して、その部分のコードを正確に入れる」役に徹する。

Step A｜依頼（Claudeはまずこれだけ出す。勝手に列挙・推奨しない）

 TERASU Lab セクション還元

このHPで TERASU Lab のセクションに追加したい箇所を、スクショ または 動画 で送ってください。
（複数あれば一気に送ってOK。1つ=1セクションとして登録します）
メモがあれば一緒にどうぞ。

Step B｜登録（送られた各メディアごとに・全作業は ~/dev/lab-terasu で）
1. 送られたスクショ/動画が完成HPのどのセクション・どの範囲か忠実に特定する（場所・範囲を絶対間違えない。少しでも曖昧なら「ここで合ってますか？」と確認してから進む）
2. id を採番: <案件>-<種別>-<担当>-<MMDD>（競合ゼロの肝・他メンバーと被らせない）
3. その箇所の実コードを正確に抽出 → 自己完結スニペット ~/dev/lab-terasu/code-previews/<id>.html（<!-- COPY:START -->〜<!-- COPY:END -->／色は --accent/--accent-2 参照／クラスは t-*／外部依存はインライン化＝他のHPに貼って即動く）
- 2026-06-17 大串FB・恒久＝「キャラクター入れないで」「イラスト入れなくていい、もっと再現度高くして」。 元サイト固有の装飾キャラ/人物イラスト/顔文字を「ダミー丸＋"イラスト/キャラ"ラベル」で代用しない（安っぽく再現度を下げる＝逆効果）。Labスニペットは レイアウト/グリッド罫線/タイポgrafi/余白/配色/hover・スクロールのリビール挙動の再現度で勝負する。画像が要る箇所は無難な 画像 プレースボックス1つに留め、人物・キャラ・顔文字系は入れずに省く（その分レイアウトと動きを忠実に）。
4. 送られた写真/動画を ~/dev/lab-terasu/img/sections/<id>.png（動画は .mp4＋poster=png）に配置
5. cats(分類)をユーザーに確認（fv/navbar/heading/features/service/works/gallery/news/logos/access/pricing/faq/qa/testimonial/cta/footer/motion/preloader/layoutdesign・複数可）
6. caption付与（業種｜種別：特徴）
7. entries/<id>.json を新規作成（上記データ構造で。SECTIONS配列への直書きは廃止＝新規ファイルなので他メンバーと同時でも競合しない）。1サイトの複数箇所は別々に1ファイルずつ
8. python3 build.py を実行（entries/*.json → sections-data.json 再生成）

Step C｜確認 → 修正なければ完成

登録しました。問題ないか確認してください:
  ・<id> ｜ cats:[...] ｜ メディア:✓ ｜ コード:✓
  プレビュー: http://localhost:<port>/sections （該当カードを確認）

  [1] OK → `python3 build.py && git add -A && git commit -m "lab: add <id>" && git push`（**push すれば GitHub Actions が自動でビルド＆本番反映・約30秒**。手動 wrangler デプロイは不要）
  [2] 修正 → どこを直すか教えて（場所違い / コード不足・崩れ / 分類変更 等）

→ 修正なければ完成。あればその場で直して再確認（場所の取り違え・コード不足ゼロまで）。push すれば GitHub Actions が自動デプロイ（build.py も Actions 側で再実行されるが、ローカルでも実行して確認するのが安全）。本番直接編集せず ローカルプレビュー→OK→push で完了（反映 約30秒）。

完了確認

 Step 9/12 完了（TERASU Lab セクション還元）

  登録: {N}件（id / cats / メディア(png+mp4) / 自己完結コード 全部完備）
  lab.terasu 反映: {済み / プレビュー確認待ち}

   【デモの場合・渡し漏れ防止】完成デモのプレビューリンクを必ずサイト管轄の方へ送付:
     「TERASU HPのデモ内に入れたいので、サイト管轄の方にプレビューリンクをお送りください」＋ [プレビューリンク]

  [1] 完了 → クライアント納品用は Step 10/12（納品前QAゲート）へ ／ デモはここが正式ゴール
  [2] もっと登録する（戻る）
  [3] 終了

→ デモはここが正式ゴール（完了）。 完了時に必ず「TERASU HPのデモ内に入れたいので、サイト管轄の方にプレビューリンクをお送りください」とプレビューリンクを添えて渡す（渡し漏れ防止・2026-06-25 大串FB）。 制作実績への格納は別ワークフロー（feedback_terasu_demo_workflow の /demos/<名>/ 内部ホスト公開）。クライアント納品用のみ Step 10（納品前QAゲート）以降の公開・SEOへ進む。

Step 10/12: 納品前QAゲート（文言最終調整 + フォームQA + 設定ミス防止 + プリフライト + SEO内部対策）

公開前に ①文言の最終最適化（デザイン不変）→ ②「設定ミスでサイレントに機会損失する穴」を全部潰す納品前QA → ③技術的な品質とSEOの土台 を仕込む。manual-terasu の Phase 1（公開準備）+ Phase 5（SEO内部対策）の実行版。

2026-06-24 大串FB・恒久・絶対遵守＝設定ミス＝サイレント機会損失を構造的に潰す（StockSun品質ガイドライン反映）。 「フォームが本番で不達」「GA4データ保持2か月のまま」「CVイベントが実は未計測」「旧URLの301漏れでアクセス激減」「集客ページのnoindex残しで検索消滅」等は、見た目は完璧なのに気づかぬまま売上を失うのが最も怖い。このStepは見た目でなく 「設定が正しく効いているか」を実測で証明するゲート。1つでも未クリアなら公開（Step11）に進まない。

【デモ用はこのStep10をスキップ】（2026-06-25 大串FB）。 デモは公開しないのでフォームQA・URL正規化・解析・SEO等は不要。ただし軽量チェック3点＋最小メタを実施＝①リンク切れ0 ②コンソールエラー0 ③全メニューがトップに遷移する ④ 最小メタ（favicon・<title>・OGP画像）＝デモは /demos/ でリンクを送るので、これが無いとシェア時/タブで安っぽくなる（下記「ブラウザ・SNSシェア表示」の最小セットだけは必ず当てる）。デモはこれで完了（Step11/12なし）。

起動時の提示

━━━━━━━━━━━━━━━━━━

 Step 10/12: 公開準備（プリフライト + SEO内部対策）

公開前の品質チェック・SEO設定をします。
案件のターゲットキーワードがあれば教えてください（なければこちらで提案）:
  [a] キーワード指定あり（教えてください）
  [b] こちらで業種から提案して
  [c] スキップ（最低限の技術設定だけ）

ライティング・コピー最終監査（誤字＋「問い合わせが来る」コピー＋改行設計・デザイン不変・2026-06-29 大串FB・恒久・絶対遵守）

TERASUは「問い合わせが来るHP」を作る会社。ここがHPの成果(=CV)を決める最重要工程。 デザイン・スマホ確定後に、見た目を1pxも変えず文言だけで問い合わせを最大化する。Step5で入れたコピーを誤字・SEO・CV・改行の4観点で総監査。「この文言、こう変えたらもっと問い合わせが来る」を能動的に提案するのがこのStepの本質（下記「問い合わせが来るコピーの型」を毎回当てる）。

A. 誤字脱字・表記ゆれ 全文チェック（信頼の土台）

• [ ] 全ページの全文章・全画像内テキストを通読（誤字・脱字・衍字）
• [ ] 表記ゆれ統一（半角/全角・送り仮名・「お問い合わせ/お問合せ」・漢数字とアラビア数字・英字の大小）
• [ ] 固有名詞（社名・サービス名・人名・地名）と数字（料金・電話・営業時間・実績数）を依頼書と1字ずつ照合 ← ここの誤りは信用直撃

B. SEOキーワード 最終チェック（取りたいKWから逆算）

• [ ] title にメインKWが前半（各ページ個別）／h1(各ページ1つ)にメインKW・h2にサブKW
• [ ] 本文冒頭100字以内にメインKWが自然に出ている／画像altに関連KW（不自然でない範囲）
• [ ] meta description にKW＋ベネフィット＋CTA（120字）
• → 不足はデザイン枠内で差し替え（文字数厳守・レイアウト不変）

C. コピー改善診断（「この文言→こう変えたら問い合わせが来る」を能動提案）

依頼書の文言をそのまま入れて終わりにしない。 弱いコピーを見つけ、現状＋改善案2〜3個＋狙いを提案する。判定の型↓
| 弱いコピーのサイン | 改善の方向 | 例 |
|---|---|---|
| 自社が主語（うちは〜・当社の〜） | お客様主語・ベネフィットへ | 「実績100件」→「初めてでも安心して任せられる」 |
| 機能・特徴の羅列（〜機能・〜対応） | 「だから何が嬉しいか」に翻訳 | 「24時間対応」→「夜中の不安もすぐ解決」 |
| 抽象的・曖昧（高品質・最適な） | 具体数字・固有名詞へ | 「多くの実績」→「導入300社」 |
| 命令形CTA（お問い合わせはこちら） | 行動＋ベネフィット＋ハードル下げ | 「お問い合わせ」→「まずは無料相談（30秒）」 |
| 専門用語・難語 | 中学生でも分かる言葉へ | 「DX推進」→「面倒な手作業をなくす」 |
- FVキャッチ・各セクション見出し・CTA・フォーム前の一文を重点監査。重要箇所は1案で決めず2〜3案出して狙い（行動喚起/不安解消/限定感/共感）を添えて選定
- 問い合わせ前の不安解消が本文にあるか（料金明示・よくある質問・実績/お客様の声・「しつこい営業はしません」等の一押し）

D. 改行・読みやすさ設計（PC/スマホ両方・「スッと頭に入る」リズム）

• [ ] 一文を短く（一文一義。長い文は句点で割る）
• [ ] 意味の切れ目で改行（文節・読点/句点の後。フレーズ途中で折らない）。SPは Step7「日本語SP改行クラス」、PCも見出し/リード文の改行位置を整える
• [ ] 漢字とひらがなのバランス（漢字が続くと硬い→ひらく。「出来る」→「できる」「事」→「こと」）
• [ ] 見出しは2行以内・FVキャッチは一目で読める塊に・行間(余白)で呼吸を作る

E. デザイン不変の確認（最重要）

• [ ] 文言差し替え後、PC/スマホでレイアウト崩れゼロ（はみ出し・改行ズレ・ボタン伸び なし）
• [ ] 変えたのは「文字」だけ。CSS・レイアウト・文字サイズは未変更

→ A〜E を通したら文言確定。判断に迷うコピーは下記「問い合わせが来るコピーの型」を当てる。

問い合わせが来るコピーの型（プレイブック）— TERASU事業の核心・2026-06-29 大串FB・恒久

「問い合わせが来るHPを作る会社」の差別化はここ。 毎案件この型を当て、出たコピーFBは汎用なら下記へ昇格（＝使うほどコピーが強くなる）。Step5の初稿コピーもこの型で作り、Step10で監査する。

• ヘッドライン(FVキャッチ)の公式: 「誰が」「何をすると」「どうなる(ベネフィット)」を3秒で。ターゲット明示＋具体性＋数字（例「初めての方専門｜最短2ヶ月で"問い合わせが来る"HPを」）
• ベネフィット変換: 特徴(自社視点)を「お客様がどう良くなるか」に翻訳。"機能"でなく"得"を売る
• CTA設計: 行動＋ベネフィット＋心理的ハードル下げ。FV/中間/フッターに複数配置（「お問い合わせ」より「まずは無料で相談(30秒)」「料金を見てみる」）
• 不安解消: 料金明示／よくある質問／実績・お客様の声／保証・「無理な営業なし」。問い合わせ前の"こわい"を消す
• 社会的証明: 導入社数・実績・お客様の声・受賞・メディア掲載で「みんな使ってる」を示す
• 構成の型(PASONA/PREP): 問題提起→共感→解決策→根拠→行動。各セクションが次へ読み進めたくなる流れに
• 読みやすさ: 一文短く・意味で改行・ひらく・余白で呼吸。読む努力ゼロを目指す

→ 出たコピーFBの仕分け: 他HPでも効く汎用(弱いコピー診断の新パターン・CTA/ヘッドラインの型)→このプレイブックに追記＋learning.md／この案件固有→その場だけ。Step7「SP最適化の自己進化ループ」のコピー版。

フォームQA（=CVエンジンの双方向疎通＋スパム耐性・最優先・2026-06-24 StockSun 9-3/11-3/12-4反映）

問い合わせフォームが本番でサイレント不達 → 全リード消失・数週間気づかない＝直接の売上損失。 HP制作で最も機会損失が大きい設定ミス。「送信できた」で終わらせず、エンドユーザー側（成功表示）と 管理者・CRM側（実受信）の双方が本番で通ることを必ず実測する。

A. 双方向疎通（本番で実測・最重要）

• [ ] エンドユーザー側: 送信後にサンクスページ or 成功アラートが出る（無言で終わらない）
• [ ] 管理者・CRM側: 送信内容が実際に届く先（CRM/メール受信箱）に着信する ← ここが本丸
• [ ] preview と本番でフォーム送信先・メール挙動が違う前提で、必ず本番でテスト送信する（preview success ≠ 本番success）
• [ ] 送信データの控え保存（サーバー/CRM側に残る・取りこぼし保険）
• [ ] 異常系テスト（必須未入力・不正値・二重送信でエラーや重複が壊れない）

B. スパム耐性（迷惑送信でCRMが汚染されない）

• [ ] reCAPTCHA（v3等）設定
• [ ] honeypot（隠しフィールド）設置
• [ ] CSRF対策
• [ ] 同一IPから5分以内に3回以上の送信はブロック

C. 入力体験（離脱を防ぐ）

• [ ] 電話番号・メール・住所のバリデーション（形式チェック）
• [ ] 郵便番号→住所 自動入力
• [ ] 日付・時間は選択式でバリデーション
• [ ] バリデーションエラーがわかりやすい（赤字＋該当箇所へ自動スクロール）
• [ ] スマホでinputにフォーカスしても自動ズームしない（font-size:16px以上 / 適切なinputmode）

→ A〜Cが本番で全部通って初めて「フォームOK」。 Step12「解析テスト」で、この送信が GA4 のCVとして数字に立つことまで確認して完結（→ Step12と連結）。

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

各ページに以下を実装・確認:

• [ ] title 各ページ個別・32字以内・キーワード前半・ブランド名末尾
• [ ] meta description 各ページ個別・120字程度・CTA含む
• [ ] OGP（og:title/description/image/url/type）※og:imageは絶対URLで1200×630
• [ ] Twitter Card（summary_large_image）
• [ ] canonical 絶対URL
• [ ] favicon（svg + png + apple-touch-icon）
• [ ] robots.txt（開発用 Disallow: / が残ってないか厳重確認）
• [ ] sitemap.xml（全ページ列挙・lastmod正確に）
• [ ] 404ページ（専用ページ・TOP導線あり）
• [ ] 構造化データ（ページ別に適切な型を・2026-06-24 StockSun 7-1反映）: WebSite=TOPのみ／Organization=TOPとabout(会社概要)のみ／LocalBusiness=店舗・会社概要ページのみ／BreadcrumbList=TOP以外／ContactPage=問い合わせページ／AboutPage=会社紹介／Article=記事個別／FAQPage=FAQ記載ページ／Person・ProfilePage=人物紹介／JobPosting=採用／VideoObject=動画／Event=イベント。該当コンテンツが無いページに付けない（過剰実装はリッチリザルトエラーの要因）

ブラウザ・SNSシェア表示プリフライト（タブのタイトル/アイコン・リンクシェア画像・2026-06-29 大串FB・恒久・絶対遵守）

見栄え・中身が完璧でも、ブラウザタブのタイトル/アイコンや、リンクをシェアした時の画像が未設定だと一気に安っぽく見える＝信頼を落とす。 上の必須技術設定の title/OGP/favicon を、①全下層ページ網羅 ②画像を実際に作る ③実機でシェアプレビュー確認まで詰めるのがこの小節（埋もれ・抜け防止で独立させた）。

A. ブラウザタブ（Chromeで開いた時・全下層ページも）

• [ ] 全ページに固有の <title>（タブに出る一文）。機械確認: for f in $(find . -name '*.html'); do grep -q '<title>' "$f" || echo "NO TITLE: $f"; done
• [ ] favicon を新規作成（元サイトのは著作権監査で除去済＝作り直し必須）: ロゴ/ブランドから favicon.svg＋favicon-32.png＋apple-touch-icon.png(180×180)
• [ ] favicon を全ページの <head> に注入（共通パーツとして全下層に・1ページだけ入れて終わりにしない）。機械確認: for f in $(find . -name '*.html'); do grep -q 'rel="icon"\|apple-touch' "$f" || echo "NO FAVICON: $f"; done

B. リンクシェア画像（Slack/LINE/X/メールで送った時の見た目＝OGP）

• [ ] OGP画像を新規作成（1200×630・ブランド色＋サービス名＋一言。共通1枚 or 主要ページ個別）
• [ ] 全ページに og:title/og:description/og:image/og:url/og:type（og:image・og:urlは絶対URL）＋ Twitter Card（summary_large_image）。機械確認: for f in $(find . -name '*.html'); do grep -q 'og:image' "$f" || echo "NO OGP: $f"; done
• [ ] 実機シェアプレビュー: ラッコツールズ OGP確認 / metatags.io に本番URLを入れ、Slack/LINE/X/Facebook での見え方が崩れてないことを目視（画像の見切れ・文字化け・画像が出ない、をゼロに）
• [ ] og:image が実在して200で返る（相対パス・404・空はNG）: curl -sI "{絶対og:image URL}" | head -1

→ A・B が全ページで埋まって初めて「ブラウザ/シェア表示OK」。デモ用もこの最小セット（favicon・<title>・OGP画像）は必須（デモは /demos/ でリンクを送るため。→ 用途分岐プロトコル／Step10デモ注記）。

SEO内部対策

• [ ] h1 が1ページ1個・メインKW含む / h2→h3 の階層
• [ ] 内部リンク（パンくず・関連リンク・フッター）
• [ ] 画像: alt属性・WebP化・width/height・loading="lazy"
• [ ] URL設計: 短く・英語・ハイフン

URL正規化・index設計（設定は一瞬・知らないと機会損失・2026-06-24 StockSun 7-2/7-3/7-4反映）

StockSun原文「設定は一瞬。知っているだけで、機会損失を回避できます」。同一ページが複数URL化して評価分散したり、集客ページがnoindexで検索から消える事故を潰す。

• [ ] www有無を301で1本化（www有りか無しどちらかに統一・もう片方は301リダイレクト）
• [ ] 末尾スラッシュの有無を正規化（どちらかに統一）
• [ ] canonical を正規URL（絶対URL）で全ページに（重複URL対策）
• [ ] HSTS 設定（https強制・セキュリティ＆評価）
• [ ] index/noindex方針を明示: 集客ページ=index／サンクス・絞り込み・重複・thanks等=noindex。集客ページにnoindexが残ってないことを全ページ確認（StockSun「index設定のミスが多数ある」）
• [ ] sitemap.xml は index対象ページのみ列挙（noindexページを混ぜない・整合を取る）
• [ ] （画像検索を狙うなら）画像サイトマップも生成

信頼性ページ監査（E-E-A-T・2026-06-24 StockSun 11-1反映）

信頼性ページの欠落は 問い合わせ前の不安＋SEO評価の両方を落とす。公開前に存在と導線を確認。

• [ ] プライバシーポリシー がある
• [ ] 運営会社情報（会社概要・所在地）がある
• [ ] 特定商取引法に基づく表記（該当する事業の場合）がある
• [ ] 問い合わせ先（フォーム/電話）が明確
• [ ] （医療・金融・法律等のYMYL）監修者情報を該当ページに設置
• [ ] （信頼性を要する内容）法人番号・国税庁・経産省等の公的機関への外部リンクで裏付け
• [ ] 全ページが2クリック以内で到達できる（回遊性）

誤字脱字・全文最終レビュー（2026-06-24 StockSun 11-4反映）

• [ ] 全ページの全文章・全画像内テキストを最終目視（誤字脱字・表記ゆれ・社名/サービス名/電話番号/住所の誤り）
• [ ] 数字（料金・電話・営業時間）は依頼書と1文字ずつ照合 ← 機会損失・信用毀損の直結点

パフォーマンス・セキュリティ

• [ ] PageSpeed Insights モバイル90+ / PC95+
• [ ] Core Web Vitals 全項目「良好」
• [ ] 画像最適化（WebP・1枚300KB以下・適切なサイズ）
• [ ] SSL（https） ※公開後に確認
• [ ] Rich Results Test エラーゼロ

公開前NG最終チェック

公開前に絶対確認（1つでも該当したら公開しない）:
  □ robots.txt が Disallow: / になってない
  □ 集客ページに noindex メタタグが残ってない（サンクス等の意図的noindexはOK）
  □ OGPに開発URL・ステージングURLが残ってない
  □ <title>サンプル</title> 等のプレースホルダ放置がない
  □ console.log のデバッグ出力が残ってない
  □ og:image が空 or 相対パスじゃない（絶対URL）
  □ フォームが本番で双方向疎通OK（成功表示＋管理者/CRM実受信）
  □ www有無・末尾スラッシュが301で1本化されている
  □ sitemap.xml に noindexページが混ざってない
  □ 料金・電話番号・住所が依頼書と一致（誤字脱字最終レビュー済み）

完了確認

 Step 10/12 完了（納品前QAゲート）

  - フォームQA: {双方向疎通OK・スパム対策・入力体験 全クリア}
  - URL正規化/index設計: {www301・スラッシュ・canonical・HSTS・noindex方針・sitemap整合}
  - 信頼性ページ/誤字脱字: {privacy・運営会社・特商法・監修者・公的リンク・全文レビュー}
  - 必須技術設定: {N項目}
  - SEO内部対策: {完了}
  - PageSpeed: モバイル{NN}点 / PC{NN}点
  - 公開前NG: {全クリア / 要対応}

  [1] 公開OK → Step 11/12（本番公開）へ
  [2] 要対応あり → 直す
  [3] Step 7 に戻る
  [4] 終了

詳細: manual-terasu の Phase 1（s3-c01）・Phase 5（s3-c05）参照。

---

Step 11/12: 本番公開（公式ドメイン・DNS・SSL）

【デモ用はこのStepなし】 デモは公開しない（Step9 Lab還元がゴール）。以下はクライアント納品用だけ。

いよいよ公式ドメインで本番公開。manual-terasu の Phase 2（ドメイン・公開作業）の実行版。ここで初めてCloudflare枠 or 顧客の本番環境を使う（プレビューと違い、本番は公開が目的なので枠使用OK）。

起動時の提示

━━━━━━━━━━━━━━━━━━

 Step 11/12: 本番公開（公式ドメイン）

ドメインの状況を教えてください:
  [a] 顧客が既にドメイン持ってる（DNS設定する）
  [b] 新規取得が必要（取得手順を案内）
  [c] サブドメインで公開（例: lp.example.com）
  [d] まだ仮で .pages.dev のまま公開

このStepの分岐: 新規制作か / 既存サイトのリニューアルか を必ず確認。リニューアルなら下の「リダイレクト移行」が最優先（怠るとアクセス激減）。

リニューアル時：旧URL→新URL 301リダイレクト移行（最重要・2026-06-24 StockSun 11-6/12-3/10-3反映）

既存サイトの作り替え時、旧URLを301でマッピングしないと検索評価がリセット → 流入が激減する。 StockSun原文「リダイレクト確認は最重要。アクセスが激減する可能性があります」。新規制作（既存サイトなし）の場合はこの節をスキップ。

0-1. 旧サイトのバックアップ（公開作業の前に必ず）

• [ ] 旧サイトの全ファイルを退避（HTML/CSS/JS/画像一式を tar.gz or リポジトリに保存）
• [ ] 旧サイトにDB/フォームデータがあれば退避
• [ ] 旧サイトの現状の流入URL一覧を取得（Search Console「ページ」/ GA4 / sitemap / curlクロール）

0-2. 301マッピング表を作る（旧URL→新URL 全件）

| 旧URL | 新URL | 種別 |
|-------|-------|------|
| /company/about.html | /about/ | 301 |
| /old-service/       | /service/ | 301 |
| （廃止ページ）       | 最も近い新ページ or TOP | 301 |

• [ ] 旧サイトの主要流入ページ・被リンク獲得ページを漏れなくマッピング（流入の多い順に最優先）
• [ ] URL構造が変わるページは全部301（404に落とさない）
• [ ] Cloudflare Pages なら _redirects に /old/path /new/path 301（旧実ファイルが残ると force でも負ける → 旧実体を消す or 301! 運用。reference_terasu_hp_pages 参照）

0-3. 公開後に301到達を全件検証（Step11完了の必須ゲート）

# マッピング表の旧URLを全件叩いて 301 → 正しい新URL に飛ぶか確認
while read OLD NEW; do
  CODE=$(curl -s -o /dev/null -w "%{http_code}" -I "https://{ドメイン}${OLD}")
  LOC=$(curl -s -o /dev/null -w "%{redirect_url}" -I "https://{ドメイン}${OLD}")
  echo "${OLD} → ${CODE} ${LOC}"
done < redirect_map.txt

• [ ] 全旧URLが 301 を返す（200で旧コンテンツが生きてない・404で消えてない）
• [ ] リダイレクト先が意図した新URL（チェーン・ループなし）
• [ ] 発注者（大串/クライアント）にもマッピング表を共有して確認（StockSun「発注者も必ず確認」）

公開手順

1. 本番デプロイ（GitHub運用＝preview を main にマージするだけ）

# リポジトリ・Pagesプロジェクトは Step5 で作成済み。本番公開 = preview を main へマージ
cd ~/dev/client-{案件}
git checkout main && git merge preview && git push   # → main が自動デプロイ＝本番化（GitHub Actions 約30秒）

→ https://{案件名}.pages.dev（main本番）で公開 → 次の手順でカスタムドメイン接続

Cloudflare for SaaS 構成なら配信基盤(terasu-platform)側でホスト名追加。Pages単体運用なら枠残数に注意。

2. カスタムドメイン接続（公式ドメイン）

• Cloudflare Dashboard → 該当プロジェクト → Custom domains → ドメイン追加
• 顧客のDNSに CNAME 追加（@ と www → {案件名}.pages.dev）
• 顧客のMXレコード（メール）を絶対に消さない

3. DNS伝搬・SSL確認

dig {ドメイン}                                          # DNS確認
curl -s -o /dev/null -w "HTTP:%{http_code}\n" "https://{ドメイン}/"  # 疎通

• whatsmydns.net で伝搬確認
• SSL証明書 Active 確認・Mixed Content ゼロ確認

4. 本番動作確認

• 全ページ HTTP 200
• PC / タブレット / スマホ / 4ブラウザで表示
• フォーム送信テスト＝本番で双方向疎通（エンドユーザー側に成功表示 ＋ 管理者/CRM側に実着信。Step10 フォームQA A〜C を本番で再実測）
• （リニューアル時）旧URLの301到達を全件確認（上記 0-3）
• 全リンク疎通・全ボタンを最終クリックテスト（リンク切れ・非活性ゼロ／第三者目線で1周・StockSun 11-3）
• OGPプレビュー確認（ラッコツールズ等）

完了確認

 Step 11/12 完了（本番公開）

  - 公開URL: https://{ドメイン}/
  - DNS伝搬: {完了}
  - SSL: {Active・Mixed Contentゼロ}
  - 本番動作: {全ページ200・全デバイス・全リンク疎通確認済み}
  - フォーム: {本番で双方向疎通OK（成功表示＋管理者/CRM実着信）}
  - リダイレクト: {（リニューアル時）旧URL→新URL 301 全件到達 / 新規はN/A}

  [1] 公開完了 → Step 12/12（公開後SEO設定）へ
  [2] 問題あり → 対応
  [3] Step 8 に戻る
  [4] 終了

詳細: manual-terasu の Phase 2（s3-c02）参照。

---

Step 12/12: 公開後SEO・解析実測検証・監視設定（設定して終わりにしない）

【デモ用はこのStepなし】 デモは公開しないので公開後設定も不要。以下はクライアント納品用だけ。

公開して終わりじゃない。検索エンジンに認識させ、集客の土台を作る＋ 「設定が本当に効いているか」を実測で証明し、落ちたら気づける監視を仕込む。manual-terasu の Phase 3（SEO基礎設定）の実行版。

2026-06-24 大串FB・恒久（StockSun 10-2/10-4/12-4/13-1反映）＝設定だけして終わりにしない。 GA4は作っただけだと「データ保持2か月のまま履歴消失」「CVイベントが実は未発火で計測ゼロ」が起きる。実際にテスト送信して GA4 に数字が立つことを目視し、ダウン/期限切れを通知で気づける状態まで作って初めて完了。

起動時の提示

━━━━━━━━━━━━━━━━━━

 Step 12/12: 公開後SEO・解析実測検証・監視

検索エンジン登録・解析設定・実測検証・監視をします。
  [a] 全部やる（Search Console + GA4 + 解析実測検証 + 監視 + Bing）
  [b] 実店舗あり → Google Business Profile も
  [c] 最低限（Search Console + sitemap送信 + フォームCVの実測検証だけ）

設定項目

1. Google Search Console

• [ ] プロパティ追加（ドメインプロパティ推奨）
• [ ] 所有権確認（DNS TXTレコード）
• [ ] sitemap.xml 送信
• [ ] 主要URL（TOP・サービス・お問い合わせ）のインデックスリクエスト
• [ ] 顧客に権限付与（オーナー）

2. Google Analytics 4（+ GTM）

• [ ] プロパティ作成（顧客名義のGoogleアカウントで）
• [ ] 測定タグ設置（GTM経由推奨＝タグ散乱を防ぐ。GTMコンテナ→GA4設定タグ→全ページ）
• [ ] データ保持を「14か月」に変更（プロパティ設定＞データの保持。デフォルト2か月のままだと履歴がサイレント消失＝改善判断の土台が消える）
• [ ] キーイベント（旧コンバージョン）を整理して設定: フォーム送信完了 / 電話クリック / LINEクリック / サンクスPV（最低でもフォーム送信完了）
• [ ] 電話番号・LINEリンクのクリックをイベント化（onClick計測）
• [ ] DebugView / リアルタイムで動作確認
• [ ] 顧客に権限付与（管理者）

3. Google Business Profile（実店舗ある場合）

• [ ] 登録・オーナー確認手配
• [ ] NAP情報統一・カテゴリ選定・写真10枚以上
• [ ] 顧客に権限付与

4. Bing Webmaster Tools

• [ ] Search Console からインポート（5分）

5. 解析テスト（設定が本当に効いてるか実測・最重要・StockSun 12-4）

「設定した」と「計測されている」は別物。 実際にテスト送信/テストクリックして、GA4の数字として立つことを目視する。ここを飛ばすと「公開3か月、CV計測ゼロ」事故が起きる。
- [ ] フォームを実際にテスト送信 → GA4（DebugView/リアルタイム）にキーイベントが立つことを確認
- [ ] 電話番号・LINEを実際にクリック → クリックイベントが立つことを確認
- [ ] サンクスページPV / マイクロCV（問い合わせページ到達等）が計測されているか確認
- [ ] このCV = Step10/11のフォームQA双方向疎通と一致（送信が CRM着信 かつ GA4計測 の両方OK）

6. 監視設定（落ちたら気づける・StockSun 10-4「監視に言及しない業者には発注しない」）

サイトダウン＝リード損失。客より先に検知する。
- [ ] 外形監視: 本番URLを外部から定期的に叩いて200を確認・異常時メール通知（UptimeRobot等。通知が正常に届くかもテスト）
- [ ] 死活監視（サーバー稼働・該当する構成の場合）
- [ ] 通知の閾値を適切に（多すぎる通知は形骸化する）
※ Cloudflare Pages（静的）は基盤側で可用性が高くサーバー死活監視は不要だが、外形監視（本番200チェック）は入れる＝デプロイ事故・ドメイン/証明書トラブルで落ちたら気づける。

7. ドメイン/SSL期限・GSCエラーの継続監視（StockSun 13-1/13-2）

• [ ] ドメイン有効期限・支払いをカレンダー/リマインダー登録（失効＝サイト消滅の致命傷を防ぐ）
• [ ] SSL証明書の有効期限（Cloudflareは自動更新だが、独自運用なら期限管理）
• [ ] Search Console エラーの定期確認を運用に組み込む（カバレッジ/拡張/手動による対策タブ・月1以上）

完了確認 → フロー完了

 Step 12/12 完了 → HP制作フロー全完了 

最終成果物:
  - 公開URL: https://{ドメイン}/（公式ドメイン・SSL・SEO設定済み）
  - 著作権: 最終監査クリア（元サイト痕跡ゼロ）
  - Search Console: 登録・sitemap送信・インデックスリクエスト済み
  - GA4: 設置・データ保持14か月・キーイベント設定済み
  - 解析実測検証: フォーム送信/電話クリックが GA4 に立つことを目視確認済み
  - 監視: 外形監視（本番200・異常通知）設定済み
  - ドメイン/SSL期限: リマインダー登録済み
  - 顧客権限: 付与済み

これで「制作 → 著作権クリア → 公開 → 集客の土台 → 計測実測 → 監視」まで全部完了です。

次:
  [1] 完了 → Vault保存 + 作業ログ記録
  [2] Step 10 やり直し
  [3] 改良したい → Step 6 に戻る
  [4] 終了

詳細: manual-terasu の Phase 3（s3-c03）参照。月次運用・効果計測は Phase 8（s3-c08）、クライアント引き渡しは Phase 9（s3-c09）。

---

フロー完了時の挙動

最終アクション:

1. 最終ファイル一式を 30_HP制作部/{案件名}/{日付}_完成版/ にコピー保存（推奨）
2. Vault に作業ログを記録
3. セルフ進化サマリ報告（このセッションで検知したFB → 本体反映N件 / 学習候補M件。learning.md 記録済みを明示）
4. プレビューURLを Slack で共有するか確認
5. 「お疲れさまでした」で締め

---

納品後の修正運用（本番公開後・preview→OK→本番・2026-06-15 大串FB・恒久・絶対遵守）

大串FB原文: 「実際にHPが完成して納品してからの修正は、まずプレビューリンクで作成し、修正で最終的にOK出たら本番のドメインに公開という流れ。ここだけしっかり作れる体制に」

納品済み（本番ドメイン公開済み）のHPに修正依頼が来たら、絶対に本番へ直接反映しない。 必ず preview で作って → OK が出てから本番。ミスった修正が「今まさにHPを見ているクライアント／その先のお客さん」に出る事故を物理的に防ぐ。

フロー（毎回これ）

[修正依頼] → ① preview ブランチで修正 → git push（プレビュー自動デプロイ・約30秒）
          → ② プレビューURL を大串/クライアントに共有 → 確認
          → ③ OK が出たら main へマージ → 本番ドメインに反映
                                            ↑ ここで初めて本番が変わる

コマンド（Claudeが実行）

cd ~/dev/client-{案件}
# ① preview ブランチで修正
git checkout preview && git pull
#   …修正を編集…
git add -A && git commit -m "fix: {修正内容}" && git push   # → https://preview.client-{案件}.pages.dev 自動更新
# ② 大串/クライアントに preview URL 共有 → OK 待ち（★承認なしで③へ進まない）
# ③ OK が出たら本番反映
git checkout main && git merge preview && git push          # → 本番ドメインに反映（GitHub Actions 自動・約30秒）

絶対ルール

ルール	理由
承認なしで main(本番) へマージ禁止	大串/クライアントの「OK」が出てから本番。グローバルCLAUDE.md「Preview Deploy 必須ルール」と同一思想
本番ファイルを直接編集しない	必ず preview ブランチ経由で作る
「ver◯に戻して」= git で一発	git log で対象commit特定 → git revert。tar.gz不要（git履歴がバックアップ）
誰が・いつ・何を = git log	修正履歴は自動記録。Vault管理表の手追記も不要

例外（preview を挟まず本番直接OK）

• 大串が「すぐ本番で」と明示した緊急修正
• 1文字typo直しで影響範囲が即わかる軽微修正

→ それ以外は全部 preview 経由。

---

振る舞いルール（厳守）

ルール	内容
用途分岐を最初に確定（デモ/クライアント・2026-06-25）	Step1冒頭で「デモ/クライアント」を聞く。クライアント=全12ステップ不変／デモ=トップのみ・他メニューはトップ遷移・Step5 GitHub＆Step10-12スキップ（Step10は軽量チェックのみ）・著作権監査(Step8)は残す・Step9 Lab還元がゴール。詳細は「用途分岐プロトコル」
改修ごとに ver+1（2026-06-29・恒久）	このコマンドを改修したら冒頭「改訂履歴」を ver+1＋1行追記（直近3ver＋★維持）。「ver◯に戻して」で git から即ロールバック
ブラウザ/シェア表示プリフライト必須（2026-06-29・恒久）	全下層ページに <title>・favicon・OGP(og:image絶対URL・1200×630)を作成＋注入＋ラッコツールズで実機シェア確認。デモも最小メタ(favicon/title/OGP)は必須（/demosでリンク送るため）
12ステップを順次進める	一気にやらない。1ステップずつ完了確認
完全再現を先・オリジナル化を後	Step1-3で完全再現を確定 → Step4でオリジナル化。同時にやらない
確認①②を必ず挟む	①完全再現が元と一致 ②オリジナル化後にStep3から不変。OK出るまで進まない
置換漏れゼロ方式	リネームマッピング → 全ファイル横断同時置換 → grep検証 → 前後比較
Step8 著作権ゲート必須	最終監査（grep + 8項目チェック）をクリアしないと公開（Step10以降）に進ませない
共有は全部GitHubプレビューリンク・一時トンネル廃止（2026-06-30・恒久）	一時トンネル(trycloudflare/ngrok/localhost.run)は使わない（URL毎回変わる・消える）。クライアント用もデモ用も案件開始時に名前でGitHub立ち上げ→固定リンク（preview.client-◯◯ / preview.demo-◯◯.pages.dev）に最初からpushして改修・共有。クライアントは完成でmain本番接続／デモはStep9 Lab還元＋/demos公開がゴール。ローカルは自分の確認用
プレビューURLはタップリンクで毎回共有	ローカルプレビューは必ず [ラベル](http://localhost:PORT/) のMarkdownタップリンクで渡す（生URL禁止）。修正のたび毎回立て直して最新リンクを共有
公開まで一気通貫	制作で終わらず Step8-10（SEO準備→公式公開→公開後設定）まで進める。「集客できる状態」がゴール
公開前NG最終チェック必須	Step8でrobots Disallow残し・noindex残し・og:image空 等を厳重確認
顧客のMXレコード保護	Step11のDNS設定で顧客のメール設定（MX）を絶対に消さない
Step10 納品前QAゲート必須（2026-06-24・StockSun反映）	フォーム双方向疎通(成功表示＋管理者/CRM実受信)・URL正規化(www301/末尾スラッシュ/HSTS)・index/noindex方針・sitemap整合・信頼性ページ・誤字脱字 を全クリアしないと公開に進ませない。設定ミス＝サイレント機会損失を構造的に潰す
設定は実測で証明（2026-06-24・StockSun反映）	GA4は作って終わりにしない。データ保持14か月・実テスト送信でキーイベント発火を目視・外形監視・ドメイン/SSL期限リマインダーまでがStep12。「設定した」≠「計測されてる」
リニューアルは301移行が最優先（2026-06-24・StockSun反映）	既存サイト作り替えは旧URL→新URL 301マッピング→公開後に全件301到達を検証。怠るとアクセス激減。旧サイトのバックアップも公開前に取る
各Stepで素材を要求	推測で進めない。素材ない時はスキップ提案
番号回答で完結	自由記述させない。各選択肢に [a][b][c][d]
レイアウト・フォント・アニメ保護	絶対に壊さない。元の挙動完全再現
文字数オーバー事前報告	レイアウト崩れる前に報告して判断仰ぐ
オリジナル化11項目 全通過	Step4の11項目チェック全部 でないと完了扱いにしない
Prettier整形必須	元コードのフォーマット癖を残さない
中身ゼロ化	Step 1, 2 内で完結（旧hp-templateコマンドは2026-07-20廃止）
起動時に learning.md 必読	過去の学習を継承してからフロー開始
FBを常時検知	セッション内どこでFBが出ても拾う。恒久ルールは hp-flow.md 本体を自分で書き換え
学習を learning.md に記録	いつ・誰の・何のFBで・どう変えたか1行記録
完了時に学習サマリ報告	本体反映N件 / 学習候補M件 を報告

特別な指示への対応

• 「対話で進めて」: 各Step内でもさらに細かい対話モードに切替
• 「全部一気にやって」: 警告した上で順次自動実行（素材が全部揃ってる場合のみ・確認①②は省略しない）
• 「実装指示は気にせず」: 細かい挙動より全体フロー優先

関連

• 中身ゼロ化は Step 1, 2 内で完結（旧 hp-template は 2026-07-20 廃止）
• 過去のHP案件: <span class="wikilink-dead">project_hp_demo_neie</span> <span class="wikilink-dead">project_hp_demo_tetetoco</span> <span class="wikilink-dead">project_hp_demo_hubble</span> <span class="wikilink-dead">project_hp_demo_seigaku_kase</span> <span class="wikilink-dead">project_scale_hp_demo</span>
• 単一行HTML編集ノウハウ: <span class="wikilink-dead">reference_minified_html_surgery</span>
• 画像最適化反省: <span class="wikilink-dead">feedback_terasu_fv_whiteflash</span>
• ラリー最小化ポリシー: CLAUDE.md
• 学習ログ: learning.md
• メタ情報: meta.md
• 元プロンプト集: prompt.md