自社サイトをAstro＋microCMSで作り直した全記録。ノーコードの負債からGEO最適化まで
自社サイト highdef.jp を、ノーコードで作った旧サイトからAstro + microCMSへ、ゼロから作り直しました。期間はおよそ11日。デザインを新しくしたのではありません。「AIに読まれ、AIに引用される」ことを前提に、ソースコードそのものを書き替えたのが実態です。ここでは、なぜ作り直したのか、何を選び、Claude Codeでどう作ったのかを、技術的な記録として残しておきます。一般向けの「リニューアルしました」報告ではありません。
旧highdef.jpは、重くて、AIに読めないサイトだった
結論から言うと、作り直しの理由は2つです。ページが物理的に重かったこと。そして、機械が構造を読めない作りだったこと。
旧サイトはノーコードツールのSTUDIOで構築していました。立ち上げの速さは大きな武器です。ただ、生成されるマークアップは自動組版由来で、とにかく重かった。CSSが数十本、JavaScriptも数十本に分かれ、日付整形ライブラリのようなものまでページをまたいで重複読み込みされる。クラス名は symbol-1__sd-39 のような自動生成の羅列で、人間にも機械にも意味が読み取れません。
いわゆる div soup です。見出しなのか本文なのかナビゲーションなのか、マークアップからは判別できない。人間の目にはきれいに見えても、クローラやAIから見れば意味の手がかりがゼロ。ノーコードで速く立ち上げた代償が、そのまま技術的負債として溜まっていた状態でした。
そして決定的だったのが、STUDIOはコードの書き出しに対応していないという仕様です。細かなSEO/GEO最適化も、不要CSSの削除も、構造の作り替えも、プラットフォームの外では手を入れられない。つまり「移行」という選択肢が実質的に存在しない。だから私たちは、移行ではなく“作り直し”を選びました。
Astro + microCMS + heteml を選んだ理由
置き換え先にAstroとmicroCMSを選んだのは、流行っているからではありません。「静的に吐き出せて、HTMLが素直に読め、記事の編集資産を捨てずに済む」という3条件を同時に満たす組み合わせが、これだったからです。
選択 | 理由 |
|---|---|
Astro（静的サイト生成） | ビルド時にHTMLを完成させて配信する。実行時JSがほぼ不要で軽い。かつ、自分で書いたセマンティックなHTMLがそのまま出力される。SPAのように中身をJavaScriptで後から描く方式は、クローラにとって不利になりやすい。 |
microCMS（継続利用） | NOTE記事67本と実績データはmicroCMSに蓄積済み。ここを作り替える理由はない。器だけ新しくして、コンテンツ資産はそのまま引き継ぐ判断。 |
heteml（継続利用） | 既存のサーバー資産・メール送信・お問い合わせフォーム（reCAPTCHA v3込み）が動いている。インフラを動かす必然性がなかった。 |
CSSフレームワークのTailwindも採用していません。素のCSSにデザイントークン（色・フォント・余白を変数化した設計の土台）を敷いただけ。結果、37本あったCSSは数本に、37本のJavaScriptは 1本・約1.6KB に減りました。UIの動き（モバイルメニューの開閉、ページトップ、スクロール出現）は、この1ファイルに集約しています。派手さより、抑制された合理性を取った構成です。
Claude Codeで作るとは、設計から本番切替まで一人称で回すこと
このリビルドは、Anthropicの Claude Code を使い、設計・実装・移行・検証まで一気通貫で進めました。「AIにコードを書かせた」という粒度の話ではありません。工程ごとに役割の違うエージェントを立てて、人間はレビューと意思決定に専念する、という進め方です。
- デザイン：デザイン担当エージェントがトップ・NOTE・サービスのモックを生成し、私が画面を見比べて選定。見出しフォントは実画面で比較してZen Kaku Gothic Newに確定しました。
- 実装：ヘッダー・フッター・ナビ・カード等をコンポーネントとして設計し直す。旧サイトは同じマークアップが37枚に直書きで重複し、ナビ1箇所の修正に全HTMLの横断編集が必要でした。これを1箇所直せば全ページに反映される構造へ。
- コンテンツ移植：旧サイト本文からの文言抽出は、サブエージェントに切り出して並行処理。会社概要・代表挨拶・サービス説明を、意味を保ったまま新しいセマンティックHTMLへ移し替えました。
できあがったのは、17個のルートファイルから約100ページを生成する構成です。少人数の会社が、量ではなく構造の精度で戦うための土台になりました。
URLは1本も変えない。タイポすら直さない
作り直しで最も神経を使ったのは、見た目でも速度でもなく URLでした。1本でも変えれば、それまで積み上げた検索評価と被リンクが切れるからです。静的25URLに加え、/news/{id}/ と /case/{id}/ の量産ページ、カテゴリのページネーションまで、旧URLをすべて維持しました。
象徴的なのが、サービスページのURLに digital-markting という綴りミスが焼き付いていたことです。正しくは marketing。直したくなる。しかしこのタイポはURLとして生きており、直せば301だらけになる。だから、あえて直さずそのまま運びました。URL設計とは、正しさより一貫性を優先する場面がある、という好例です。
軽さは、後から足せない。フォントとレンダリングを削り込む
ページの速さは、生成AI検索の前段にあるGoogle検索でも、ユーザー体験でも効いてきます。結論として今回は、「実行時に走るものを、実使用分まで削る」方針で作りました。
効きが大きかったのがWebフォントです。当初は見出し用のZen Kaku Gothic New、英字のPoppins、数値・ラベル用のSpace Monoを読み込んでいましたが、フォントの読み込みは放置すると本文表示をブロックします。そこで、フォントのCSSを非同期で読み込む形（描画をブロックしない読み方）に変え、さらに実際に使っているウェイト（太さ）だけに絞り込みました。使っていない中間の太さを配信していては、その分だけ表示が遅れるからです。モバイルのLCP（最大コンテンツが表示されるまでの時間）を詰めるための、地味だが確実な作業です。
この「削る」判断は、作り終えてからでは足しにくい。派手な機能を後付けするのは簡単でも、一度太った構成を後から痩せさせるのは難しいからです。軽さは、最初の構成の選択でほぼ決まります。Astroを選び、Tailwindを入れず、JSを1本に集約したのは、すべてこの一点に効いています。
構造化データを、全ページの「器」として積む
SEOの土台として全ページに構造化データ（JSON-LD）を実装しました。これは、ページの意味を機械が誤解なく読めるよう、明示的に注釈をつける仕組みです。会社情報はOrganization、記事はArticle、サービスはService、パンくずはBreadcrumbList、FAQはFAQPage——といった具合に、ページ種別ごとに適切な型を割り当てています。実装した型は18種類にのぼります。
旧サイトはJSON-LDの帰属が壊れており、全ページが同じ会社情報を繰り返すだけでした。今は各記事・各実績が、自分自身を説明する固有の構造化データを持っています。これが後述するGEOの前提になります。
GEO：AIに引用される会社になるための3点セット
今回のリビルドの主目的は、実はここにあります。Google検索だけでなく、ChatGPTやPerplexityといった生成AIの回答に、highdefが引用される状態を作ること。これをGEO（生成AI検索最適化）と呼びます。やったことは3つです。
- AIクローラを明示的に歓迎する：
robots.txtで GPTBot・ClaudeBot・Google-Extended・PerplexityBot を明示的に許可。AI検索のクローラを締め出さないと宣言しました。 - llms.txt を置く：AI向けに会社を要約したテキストファイルを設置。ここでhighdefを「新潟県上越市の、地方 × AI × 実装の支援会社」と定義しています。
- セマンティックHTML + 構造化データ：機械が構造を素直に読める本文と、前述のJSON-LD。AIが引用しやすいのは、意味の通ったマークアップです。
そして最も本質的なのが、エンティティ（AIが認識する会社像）の書き換えです。放っておくとAIはhighdefを「上越のデザイン・撮影会社」と説明します。しかし実態は、AIツールを自社業務に実装して動かしている会社です。この認識のズレを、サイトの文言・構造・llms.txtの全部で一貫して修正しにいっています。AIが引用するのは会社紹介ページではなく、比較・事例・費用相場・失敗例といった具体です。だから作るべきは、その形のコンテンツになる。この記事自体も、その一次事例のひとつです。
つまずいた点も、正直に残しておく
うまくいった話だけ書くと嘘になるので、詰まった箇所も残します。公開後、microCMSで記事を更新しても、本番サイトが自動で再ビルドされない事象が起きました。
設計としては、記事の入口はGitHubへのpushで自動デプロイ、記事の更新はmicroCMSのWebhookがGitHub Actionsを外部から叩いて再ビルドする（repository_dispatch という仕組み）二経路にしていました。ところが、microCMS側にそのWebhookが登録されておらず、更新しても本番に反映されない。暫定的には空コミットをpushして手動で再ビルドを蹴っていました。原因を特定してWebhookを正しく登録し、実際に記事を公開して発火を確認するまでが復旧です。
この手の「配管の詰まり」は、ローカルのビルド成功だけを見ていると気づけません。本番で実際にコンテンツ更新が流れるところまで通して、初めて仕組みが動いていると言える。作って動かす、の「動かす」はここまで含みます。
本番切替は「中間成功で終わらせない」
最後の本番カットオーバーは、慎重に段取りを踏みました。本番の全ファイルをバックアップし、旧バージョンをタグで退避。メンテナンス画面を挟んで公開領域をクリーンにしてから、新ソースを配置する。デプロイは main ブランチへのpushでGitHub Actionsが自動配備する経路に一本化しています。
そして公開して終わり、にはしません。本番URLを実際に叩き、H1・構造化データ・お問い合わせフォームの往復・内部リンクが正しく動くかを確認するまでが作業です。ステージングで通った、ビルドが成功した、は「完了」ではない。本番で意図通り動いて初めて完了です。
サイトは、AI時代の読まれ方に作り替える時期に来ている
ノーコードで速く立ち上げたサイトが、数年後に「重くて、機械に読めない負債」に変わっている。これは珍しい話ではありません。人間の目にきれいに映ることと、機械が構造を読めることは、別の要件です。そして生成AI検索が入口になりつつある今、後者の比重が確実に増しています。
私たちは自社サイトで、その作り替えを一度やり切りました。大事なのはツールの名前ではなく、「誰に、どう読まれる前提で作るか」という設計思想です。作って動かしてみたからこそ書ける話として、記録に残しておきます。実際のアウトプットは 実績ページ や デジタルマーケティングのサービス でも公開しています。
関連記事
▶︎ 生成AI、もう"使う側"と"使われる側"に分かれてる件
FAQ
Q. STUDIOやWixで作ったサイトはGEOに弱いのですか？
ツール自体が悪いわけではありません。問題は、書き出されるHTMLが意味構造を持たない（div soup）場合、機械が見出し・本文・ナビを区別できず、AIが引用の手がかりを得にくいことです。立ち上げの速さと引き換えに、この負債が溜まりやすい傾向はあります。
Q. Claude Codeでコーポレートサイトを作るのは現実的ですか？
現実的です。ただし「丸投げで完成する」ものではありません。設計判断・デザイン選定・URL維持・本番切替の意思決定は人間が担い、AIは実装と移植と検証を高速に回す、という分業が前提になります。今回は約11日で設計から本番公開まで到達しました。
Q. llms.txt は本当に効果があるのですか？
現時点で全AIが参照を保証しているわけではなく、効果は限定的・実験的です。ただしコストは低く、会社の定義をAI向けに一次情報として明示できる意味は大きい。robots.txtでのクローラ許可と、各ページの構造化データとセットで初めて土台になります。llms.txt単体で劇的に変わるものではありません。
Q. 既存サイトを作り直すか、部分改修で済ませるか、どう判断すべきですか？
判断軸はURL資産です。URL構成を維持したままHTML構造を入れ替えられるなら、作り直しでも検索評価は守れます。逆に、負債の中心がマークアップ構造そのものにある場合、部分改修では div soup を引きずるため、器ごと作り直したほうが早いことが多いです。