SEOだけでは届かない？AI検索時代にWeb制作で仕込むセマンティック実装

Google の検索結果に並ぶ「10本の青いリンク」だけを想定してサイトを作っていると、答え合わせの場所が足りなくなります。Perplexity や ChatGPT の検索、Google の AI による概要のように、先に要約と出典が出る画面が増えているからです。業界では GEO や LLMO（Generative Engine Optimization）と呼ばれることもありますが、公式の順位指標ではありません。現場で起きているのは、「自社の説明が、回答の出典として残るかどうか」です。

ここで必要なのは、裏技のメタタグではありません。人が読める見出しと本文があり、機械が役割を取り違えない DOM があることです。スクリーンリーダー向けのセマンティックHTML、検索エンジン向けの構造化データ、AI が引用しやすい本文は、別々の施策に見えつつ、制作工程では同じ仕込みになります。アクセシビリティと SEO の融合、と言ってよい地点です。

この記事では、フリーランスのWebディレクター兼エンジニアとして、HTML / CSS、Next.js、WordPress、microCMS の実装を見てきた立場から、着工前に決めておく仕様を整理します。AI に必ず引用される、とは書きません。引用されやすい条件と、引用が歪みやすい作りを、工程の言葉に落とします。

なぜ AI 検索時代は、制作工程からの仕込みが必要なのか

AI の回答は、画面のスクリーンショットを見て文章を書いているわけではありません。多くの場合、取得した HTML のテキスト、見出し、リスト、表、場合によっては JSON-LD などの構造化データを手がかりに、どの文が「主張」でどれが「補足」かを組み立てます。画像の中の文字は OCR で拾えることもありますが、修正・引用・言語切替に弱く、スクリーンリーダーも同様に詰まります。

つまり、見た目が美しいだけでは足りません。見た目と同じ情報が、DOM 上でも同じ順番・同じ役割であることが、人間にもクローラにも必要です。

ここをコーディング完了後に足そうとすると、手戻りが出ます。

• FAQ をアコーディオンの見た目だけで作ってあり、見出しも dt/dd も JSON-LD も無い
• 比較表が画像1枚で、セルの関係が HTML に無い
• ブランド名と法人名が、フッターの画像にしか無い
• h1 がロゴ画像だけで、文書としての題名が空

構造化データだけ後付けしても、本文の DOM が div の入れ子だと、要約は「それっぽいが違う」方向へ寄りやすいです。着工前に、ページ種別ごとの情報（組織、サービス、記事、FAQ）と、HTML の役割を決めておく方が安く済みます。

失敗と成功：見た目優先か、着工前の構造か

固有の企業名や、確認できない引用数・売上は出しません。制作で繰り返される型です。

悪い例：div と画像テロップで「それっぽく」見せる

ヒーローにキャッチを画像で置き、料金比較も PNG、強みはカードの背景に焼き込んだ文字。CSS で再現できる装飾まで画像にしているサイトです。ブラウザでは綺麗でも、抽出される本文は「お問い合わせ」「メニュー」など、クローラが拾いやすいナビゲーション側に偏ります。AI の要約は、フッターの一般論か、別サイトの同業説明に寄ることがあります。自社の対象・非対象・料金の前提が、出典として残らない、という失敗です。

div を使うこと自体が悪ではありません。役割のあるまとまりまで全部 div にすると、どこからどこまでが記事で、どこが関連リンクかが機械に伝わりません。

良い例：見出し・表・FAQ・JSON-LD を画面設計と同時に決める

キックオフで「このサイトが機械に渡したい事実」を先に書きます。商号、提供サービス、対象、よくある誤解、記事の著者。それを、見た目のコンポーネントと、HTML のアウトラインと、JSON-LD のタイプに対応付けます。比較は table、FAQ は見出しと本文（必要なら FAQPage）、記事は article と著者情報。

この状態だと、検索結果用のスニペットも、回答型検索の引用も、同じ本文を参照します。コンバージョンは「AI が勧めたから」ではなく、誤解の少ない説明が残ったあとに、人が問い合わせる、という順です。魔法ではなく、取り違えを減らす設計です。

【職種別】作業に入る前に決めておくポイント

Webディレクター / SEO担当者：何を事実として固定し、誰に取らせるか

決めるのはキーワードリストより先に、エンティティ（誰が、何を、誰向けに）です。Schema.org では、よく使う型は次です。

• Organization / LocalBusiness: 運営者、所在、連絡先
• WebSite: サイト名と検索の入口（使う場合）
• Service または提供内容の説明: サービスの範囲
• FAQPage: 画面上にも同じ Q&A がある場合のみ
• Article / BlogPosting: 著者、日付、所属

JSON-LD は、画面に無い事実を足す場所ではありません。画面と矛盾する構造化データは、検索側でも評価を落とす原因になります。FAQ を JSON-LD だけに置き、HTML に質問が無い、は避けます。

AI クローラの方針も、着工前に一文で決めます。学習用と、回答のための取得は別、という整理が必要です。

robots.txt の例です。コピーする前に、自社の法務・公開方針と、各社の最新ドキュメントを確認してください。名前も仕様も変わります。

User-agent: Googlebot
Allow: /

User-agent: GPTBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Disallow: /

「全部ブロックして盗用を防ぐ」と「回答の出典に残す」は同時に最大化できません。出典に残したいページ（サービス、料金の前提、方針）は許可し、会員ページや未公開の一次データは制限する、という切り方が実務的です。

ミニ事例です。納品後に「FAQ を構造化してほしい」と依頼が入り、テンプレートと CMS 項目の追加見積もりになった型があります。対して、画面設計のカードを FAQ の質問文と1対1にし、同じ文を JSON-LD に載せる仕様をキックオフで書いた現場は、実装の追加工数がほぼ出ません。

UI/UXデザイナー：画像の文字を減らし、見出しの見た目と DOM を一致させる

AI にも支援技術にも弱いのは、意味のある文字列が画像だけになることです。ロゴ以外のキャッチ、注意書き、比較、価格は、テキスト（必要なら CSS）で組む前提にします。どうしても画像にするなら、同じ内容のテキストを近くに置くか、代替テキストに要約ではなく本文相当を入れるかを、先に決めます。代替テキストにキャッチ全文を詰め込むのは、装飾画像では不適切です。役割で分けます。

見出し階層は、見た目の大きさで決めてはいけません。「小さいが重要な見出し」を h2、「大きいが飾り」を p にする、が正解です。視覚的な優先度と、DOM の h1〜h3 を一致させるルールをデザインガイドに1行入れます。

ミニ事例です。料金比較を画像1枚にしたページは、更新のたびに書き出しが発生し、AI 側の引用は古い金額のまま残ることがあります。HTML の table にし、キャプションと列見出しを付けたページは、修正がセル単位で済み、抽出も列の関係を保てます。レスポンシブは、表をカードに「見せる」CSS は使ってよいですが、データ構造まで div に分解すると、表だった意味が消えます。カード化する場合も、元データが表なら、可能な範囲で table を残すか、定義リストで対応関係を示します。

フロントエンドエンジニア / コーダー：役割のあるタグと、足りないときだけの ARIA

セマンティックタグは、全部使うことが目的ではありません。ページの役割に対して、足りるものを選びます。

• サイト全体: header nav main footer
• 独立した記事: article
• テーマのあるまとまり: section（見出しと組にする）
• 補足: aside
• 表データ: table th caption
• 操作: button / a[href]

悪い例です。見た目のグリッドのために、見出しも本文も関係が消えます。

<div class="wrap">
  <div class="title">料金</div>
  <div class="img"><img src="/price.png" alt="料金表" /></div>
</div>

良い例です。表の関係が HTML に残ります。

<section>
  <h2>料金の目安</h2>
  <table>
    <caption>公開サイトの制作費用（税別）</caption>
    <thead>
      <tr>
        <th scope="col">範囲</th>
        <th scope="col">目安</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <th scope="row">ランディングページ</th>
        <td>個別見積もり</td>
      </tr>
    </tbody>
  </table>
</section>

WAI-ARIA は、ネイティブで足りない状態にだけ足します。role="button" を div に付けるより、button を使う方が、支援技術にも機械抽出にも安定します。アコーディオンは aria-expanded と、開閉する領域の紐付けがあれば十分です。装飾の aria-label を量産しない方が、本文の信号が薄まりません。

記事と FAQ を、HTML と JSON-LD で揃える例です。FAQ の質問文は、画面と JSON で一字一句を近づけます。

<article>
  <h1>AI検索に届くサイト構造</h1>
  <p>著者：伊藤保宏（Webディレクター兼エンジニア）</p>

  <section>
    <h2>よくある質問</h2>
    <h3>JSON-LD だけ置けばAIに引用されますか？</h3>
    <p>されません。画面上の本文と矛盾しない構造化が前提です。</p>
  </section>
</article>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "name": "Web Creator Yasuhiro Ito",
      "url": "https://webdesign-code.com/"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "JSON-LD だけ置けばAIに引用されますか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "されません。画面上の本文と矛盾しない構造化が前提です。"
          }
        }
      ]
    }
  ]
}
</script>

name や URL は、公開情報と一致させてください。存在しない受賞や件数を Schema に書かない、は E-E-A-T の話以前に、事実の問題です。

クライアントは知らない。先に提案するトレードオフ

ブロックしたい気持ちと、出典に残りたい気持ち

学習に使われたくない、と、検索の回答に社名を出したい、は衝突します。方針は次のように切ると説明しやすいです。

• 公開してよい一次情報（サービス範囲、連絡先、記事）: 取得を許可し、HTML で正確に書く
• 非公開・個人情報・社内向け: robots.txt と認証、インデックス除外
• 学習だけ避けたい場合: 各社のオプトアウト（例: Google-Extended）を、検索用クローラと分けて検討する

「AI に全部読ませない」は、出典からも消えやすい、と伝えて合意します。

CMS で、入稿が構造を壊さないようにする

WordPress でも microCMS でも、本文がひとつのリッチテキストだと、見出し階層が崩れやすいです。着工前に提案したいのは次です。

• タイトル、著者、公開日、FAQ、をフィールドに分ける
• アイキャッチの代替テキストを必須にする
• 可能なら、公開時に BlogPosting や FAQPage をテンプレートで出す
• 見出しはエディタの見出しスタイル以外で「大きく見せない」運用ルール

このサイトのように microCMS の本文が HTML なら、入稿時点の h2/h3 が、公開ページのアウトラインになります。後から JSON-LD だけ足すより、フィールド設計の方が再利用できます。

E-E-A-T は、Schema の魔法ではない

Google の品質評価で使われる E-E-A-T は、JSON-LD を置いた瞬間に上がる数値ではありません。著者が誰か、一次情報か、運営者が実在するか、を ページ上で読めること が先です。そのうえで Person や Organization を同じ事実でマークアップすると、検索エンジンがエンティティを取り違えにくくなります。実績値や顧客名は、確認できるものだけを書く。これは AI 引用でも同じです。モデルは、確からしく見える数字を補完します。

AI検索時代の実装・制作工程チェックシート

キックオフに貼って、必須だけ合意します。全部を一度に必須にしないでください。

まとめ：AI 検索対策は、正しい Web 制作の延長にある

Perplexity や ChatGPT 検索に「選ばれる裏技」を足す、というより、人が読んでも機械が抜いても、同じ事実になるページを着工前に決める話です。セマンティックHTML、構造化データ、アクセシビリティは、名前は違っても、DOM に役割と本文を残す、という一点で重なります。

• 見た目の完成後に JSON-LD だけ足すと、本文と矛盾しやすい
• 画像の文字と div の入れ子は、引用の精度を落とす
• クローラの許可と、学習のオプトアウトは分けて決める
• CMS のフィールドと著者情報は、E-E-A-T の土台になる

既存サイトなら、まずトップと主要サービス、よくある質問の3ページだけ、見出し・表・JSON-LD の一致を見てください。全ページの一括マークアップは、合意が薄いと形だけになります。

AI 検索を前提にした情報設計や、セマンティックHTML / 構造化データの仕込みを、制作工程に載せたい場合は、相談・お問い合わせからどうぞ。診断という言葉で過度な保証はしません。今の DOM と公開方針から、残したい事実を先に切ります。