コーポレートサイト制作フロー
ANTIGRAVITY 使用前提 ／ 複数ページ対応版
制作モードへ
💡 LP制作との主な違いと基本戦略： 複数ページにまたがるため、事前のサイトマップ設計・共通ナビ（shared-nav.js）の構築・ページ間リンクの絶対パス管理・SEOの一括設定が必須となります。

【最重要の基本戦略】
「まず /dual_presentation（初回A/B並列提案）を用いてTOPページのデザイン方針（ハイエンド路線か反響特化か）を完全にロック（確定）させ、そこで合意したコンポーネントを再利用してサブページを一気に展開する」ことで、ちゃぶ台返しを物理的に防ぎます。
※ただし、既にクライアント側で「参考サイト」「トーン＆マナー」が明確に固まっている場合は、このA/B提案ステップはスキップし、1案集中でTOPページを確定させてOKです。
1
クライアントフォルダ＆ページ構成を作成する
  • site/client-work/XX_クライアント名/ フォルダを作成
  • ページ数に応じてサブフォルダを並列に作成：
    index.html（TOP）、company.html、service.html、contact.html 等
  • 共通リソース用に css/style.css、js/shared-nav.js、images/ を用意
  • Antigravityにフォルダ構成を伝えてから作業開始
📁 ページ数が多い場合は先にAntigravityにサイトマップをHTMLで作成させると整理しやすい
2
Antigravityにサイトマップ・方向性を共有する AI

以下をまとめて伝える：

  • サイトマップ（ページ一覧と階層）
  • 事業内容・ターゲット・競合サイト
  • カラー・フォント方向（例：信頼感重視・ネイビー系）
  • 将来のWordPress移行の有無（ある場合はHTML構造をWP化しやすい形に）
  • 納期・優先ページ（TOPから作るのが基本）
💡 【最重要】作業開始の合図
チャットの最初に必ず /read-rules と入力し、Antigravityに最新のコーディング鉄則とモバイル制約（brタグ禁止等）を事前インストールさせてから相談に入ってください。
3
TOPページと共通パーツを先に作る AI
  • 共通ナビ（header/footer）を shared-nav.js として分離しておく
  • 共通CSS（カラー変数・フォント・ボタン）を css/style.css にまとめる
  • ファビコン・OGPの一括管理： HTMLの <head> に直書きせず、shared-nav.js 内で data-root-path を用いて全ページに動的挿入（inject）させる。これにより階層ごとのパス切れを防ぐ。
  • 提案デザインの完全再現（Fidelity）： 提案用FVやFigmaがある場合、Google Fontsの <link> タグ（ウェイト指定含む）や letter-spacing などの精緻なタイポグラフィ設定を勝手に省略せず、完全にコピーして高級感を維持する
  • TOPページでデザインテイストを確定させてから、他ページに展開
  • Go Live で確認しながら進める
🔧 shared-nav.jsのリンク先は必ず絶対パス（/service.html）。相対パスはURL階層で壊れる
4
サブページをAntigravityで展開する AI
  • TOPのコンポーネント（カード・セクション・CTA）を再利用して各ページを作成
  • 各ページには shared-nav.js の読み込みを忘れずに
  • ページごとに <title> と <meta name="description"> を変える
  • AIアクターの一貫性担保： インタビュー等で同一人物の画像を連続して使う場合、顔立ち・服装のプロンプトを固定しシーンだけを変更して生成する。（フリー素材のツギハギ感を排す）
  • 全ページ作成後、Antigravityに「全ページのリンクが正しいか確認して」と依頼
⚠️ 新しいCSSファイルを追加させない。全スタイルは css/style.css に集約
5
SEO設定・SP改行最適化・全ページ確認 確認
  • Antigravityに全ページのtitle・meta・OGPを一括設定させる
  • SP文字組みと余白の「ハイエンド調整」： フォントサイズを下げるだけでなく、行間（line-height: 2.1 以上）や文字間隔（letter-spacing: 0.12em）、文字色を少し抜く（#333, #555）調整を行い、高級誌のような抜け感を演出する。
  • SP改行の完全制御： <br class="pc-only"> といった小手先のタグ非表示は保守性が悪いため、見出し等は必ず .pc-only と .sp-only の2つの独立ブロックにHTMLごと分離し、スマホの横幅（約15文字）に合わせた美しい独自改行テキストを用意する。
  • 窮屈なFlex・Gridの解放（レイアウト破壊防止）： PCで横に並べたカード領域やリスト（ニュース等）は、スマホでは必ず flex-direction: column で縦積みにするか、スマホ専用の grid を使って「上部に日付・下部に画像とテキスト」のように再設計し、文字の圧迫を防ぐ。
  • ネイティブ・スワイプの適用： 横スクロールが必要な領域（Collaboration等）はJSによるドラッグではなく、overflow-x: auto; scroll-snap-type: x mandatory; を用いてOSネイティブの吸い付くような操作感に仕上げる。
  • Go Live で全ページのリンク動作を確認（404がないか）
  • PC・スマホ（DevTools）で全ページの表示崩れを確認
  • PageSpeed Insights：本番デプロイ後に計測して90点以上を目指す
ハイエンド実装の関連マニュアル
より詳細な「高級感の出し方」「レイアウト破壊回避」「軽量化」については下記を参照すること：
📱 Mobile & Multi-Device Optimization Guidelines
💻 レスポンシブLP制作ガイド
6
?v= バンプ → git push → 本番確認 → 納品 Git
  • 全ページの style.css?v=X.X バージョン番号を上げる
  • git add . → git commit -m "feat: complete corporate site" → git push origin main
  • 本番URLで全ページのリンクを再度確認（シークレットモードで）
  • クライアントに確認URLを共有 → 修正対応 → 再push
  • 最終納品：GA4コード挿入・Search Console登録、本番サーバーへの移行
❗ 【要注意】web-tsukuru.jp 上のテスト環境としてデプロイ中は、絶対に全ページの <meta name="robots" content="noindex,nofollow"> を外さないこと。Google等にインデックスされると、後日クライアント（独自ドメイン）が公開した際に「コピーコンテンツ」判定される。外すのはクライアントの本番環境へ移行する時のみ。

🚨 デバッグ・トラブルシューティング

一括置換での「文字化け（Mojibake）」事故

WindowsのPowerShellで安易に正規表現でのテキスト全置換（ターミナルコマンド）を実行すると、BOMなしUTF-8の日本語がShift-JIS等の別コードとして解釈され、HTML内の日本語が完全に文字化けして画面が壊れる事故が発生しやすい。

リカバリー方法：
事故が起きたら手作業で直そうとせず、ターミナルで直近の正常なコミットハッシュを確認し、
git checkout <hash> -- <path/to/folder>
を実行して数秒で正常時点へタイムリープ（復旧）させること。Gitの強みを活かし、パニックにならずに即座に戻すのがプロの鉄則。