ChatGPTやGeminiに自社を紹介してもらうには？AI検索に選ばれるWebサイトの作り方

「おすすめの制作会社は？」「この課題に合うサービスは？」を、Google の検索窓ではなく ChatGPT、Gemini、Perplexity に聞く人が増えています。キーワードで10件を見比べる前に、会話の中で候補が絞られる。広報も SEO も、順位表だけを見ていると、比較の土俵に乗っていないことに気づきにくいです。

ここで必要なのは、クリック率を上げるタイトルタグの延長だけではありません。回答を組み立てる側が、「この文は誰の、何についての、確認できる事実か」を取り違えないサイトです。業界では GEO や LLMO と呼ばれますが、公式の順位指標ではありません。実務の言い方をすれば、信頼できる情報源として引用されやすい状態を、制作工程で仕込むことです。検索順位対策を捨てる話ではなく、引用される本文と、エンティティ（誰が何を提供するか）を、ページ上で固定する話です。

この記事では、フリーランスのWebディレクター兼エンジニアとして、企画から HTML、Next.js、WordPress、microCMS まで見てきた立場から、ChatGPT や Gemini に「紹介してもらう」ために着工前に決めることを整理します。必ず推薦される、とは書きません。紹介されにくい作りと、紹介の文が歪みにくい作りを分けます。

なぜ AI は特定のサイトを引用・紹介するのか

モデルは、おしゃれさで出典を選びません。取得できたテキストと、他の公開情報との重なり、発信者が追えるか、を材料にします。現場で触るなら、次の3つに分解すると発注が具体になります。

1. 機械読み取り性（マシンリーダビリティ）

クローラや抽出処理が見るのは、画面の完成イメージより DOM です。見出しの順、表のセル、定義リストの対応、メインと余白の区別。div だけで見た目を再現していると、どこからがサービス説明で、どこがキャンペーンバナーかが切れます。クライアント側だけで描画する料金表は、取得時点の HTML に数字が無いことがあります。Next.js の SSG や、サーバーで HTML を出す実装は、その点で有利です。「動く」と「初回 HTML に事実がある」は別です。

2. ファクトの明確さと構造化

「伴走します」「ワンストップ」だけでは、比較質問に答えられません。対象、非対象、手順、期間の目安、FAQ の質問文が、本文に書かれているか。可能なら同じ文を JSON-LD（FAQPage、Service、Organization など）にも載せる。構造化データは、画面に無い実績を足す場所ではありません。独自の数値は、出典（計測日、範囲）とセットで本文に置く。無い数字を Schema に書くと、モデルも検索も、確からしい嘘を増幅します。

3. E-E-A-T（一次情報と、誰が言っているか）

Google の品質評価で使われる E-E-A-T は、JSON-LD を置いた瞬間に上がるスコアではありません。経験・専門性・権威性・信頼は、ページ上で著者と運営者が読め、一次情報（自社の範囲、事例の条件、更新日）があるかです。匿名の「おすすめ5選」より、実名と連絡先と「何をしないか」が書いてあるページの方が、取り違えにくい。他サイトの説明と矛盾する誇張は、引用されてもブランドを傷つけます。

この3つは、アクセシビリティの「役割の見える HTML」とほぼ重なります。選ばれるサイトは、結果として人にも読みやすいです。

AI に無視されやすいサイトと、出典に残りやすいサイト

固有の企業名や、確認できない「カード付きで推薦された」実績は出しません。工程で見る型です。

悪い例：雰囲気は良いが、事実が画像とスクリプトの奥にある

ファーストビューは動画と画像のキャッチ、料金はタブ切替の JavaScript、仕様はインフォグラフィック1枚。ブラウザではリッチでも、取得される本文はナビと「お問い合わせ」に寄ります。「おすすめは？」と聞かれたモデルは、説明可能な他社の文章を拾い、自社は比較表に出てきません。出てきても、対象外の業種を対象にしている、など取り違えが起きます。

失敗の核はデザインの良し悪しではなく、比較に使える文が HTML に無いことです。

良い例：比較できる文と、同じ事実のマークアップがある

サービスページに、誰向けか、何をするか、何をしないか、進め方、よくある誤解を見出しで置く。比較は table、用語は dl、運営者はフッターだけでなくプロフィールブロック。JSON-LD は、その本文と同じ語で Organization と Service を定義する。

この状態でも推薦は約束できません。ただし回答が付くとき、自社の前提（対応範囲、非対応、連絡方法）が残りやすいです。紹介の質は、露出の回数より、誤解の少なさで測った方が安全です。

【職種別】制作工程で仕込む「選ばれ方」

Webディレクター / マーケター：キャッチより、比較に耐える定義

抽象コピーは広告で使えても、相談型の質問には弱いです。「未来をつくるパートナー」より、「WordPress の更新が重いサイトを、表示と運用が分かる形へ組み直す」の方が、モデルも人も事業を特定できます。着工前に、次を1枚にします。

• 誰の、どの状態を、どこまで引き受けるか
• やらないこと（対象外）
• 料金の出し方（固定 / 見積もり / 税の扱い）
• FAQ の質問文は、営業が実際に聞かれる文にする

ミニ事例です。トップが形容詞だけだと、AI の要約が「総合コンサル」になり、問い合わせの期待がずれます。サービス定義を箇条書きと FAQ にしたページは、回答に「対象は中小のコーポレート」など、現場の断りが残ります。後者の方が、問い合わせの質は上がりやすいです。

UI/UXデザイナー：比較と人の情報を、画像で終わらせない

スペック、対応範囲、料金の条件は、HTML テキストと CSS で組む前提にします。どうしても図にするなら、同じ内容の表かリストを近くに置く。運営者・著者・監修がいる場合は、顔写真だけでなく、氏名、役割、責任範囲をテキストで置けるレイアウトにします。画面の端の小さいグレー文字だけ、は機械にも人にも弱いです。

ミニ事例です。スペック表を画像にしたページは、更新のたびに書き出しが必要で、引用側に古い値が残ることがあります。table とキャプションにし、必要なら同じ内容を JSON-LD に載せるページは、セル単位で直せます。レスポンシブでカードに「見せる」のは構いませんが、対応関係が消えるほど分解しない。

フロントエンドエンジニア / コーダー：文脈が切れない HTML と、本文と一致する JSON-LD

main の中に、そのページの主題があること。サービス説明は article または見出し付きの section。用語の対応は dl。表データは table。クライアント JS で後から差し込む価格は、クローラ用に初期 HTML へ同じ内容を出すか、公開時点でサーバーレンダリングする。

悪い例です。文脈がクラス名にしかありません。

<div class="p-hero">
  <div class="c-ttl">伴走するパートナー</div>
  <div id="price"></div>
</div>

良い例です。定義と FAQ が、文書として残ります。

<main>
  <article>
    <h1>コーポレートサイトの改善支援</h1>
    <p>対象は、更新担当が社内にいる中小企業の既存サイトです。</p>

    <h2>できること / しないこと</h2>
    <dl>
      <dt>できること</dt>
      <dd>情報設計の整理、セマンティックな実装、CMS 入稿ルールの設計</dd>
      <dt>しないこと</dt>
      <dd>広告運用の代行、確認できない実績数値の作成</dd>
    </dl>

    <h2>よくある質問</h2>
    <h3>全国対応ですか？</h3>
    <p>オンラインでの打ち合わせを前提にします。訪問の可否は案件ごとに確認します。</p>
  </article>
</main>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "name": "Web Creator Yasuhiro Ito",
      "url": "https://webdesign-code.com/"
    },
    {
      "@type": "Service",
      "name": "コーポレートサイトの改善支援",
      "provider": {
        "@type": "Organization",
        "name": "Web Creator Yasuhiro Ito"
      },
      "areaServed": "JP",
      "description": "更新担当が社内にいる中小企業の既存サイトを対象に、情報設計と実装、CMS入稿ルールを整理します。"
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "全国対応ですか？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "オンラインでの打ち合わせを前提にします。訪問の可否は案件ごとに確認します。"
          }
        }
      ]
    }
  ]
}
</script>

JSON-LD の description は、見出し直下の本文と食い違えない。Product は物販の型です。役務なら Service の方が取り違えにくいです。確認できない価格を offers に書かない。

クライアントは知らない。先に決める運用

クローラを止めるか、出典に残すか

GPTBot や Google-Extended を全部 Disallow すると、学習も回答のための取得もまとめて細くなりやすいです。検索用の Googlebot と、生成 AI 向けの Google-Extended は別、という説明が先です。出典に残したいサービスページは許可し、会員エリアと下書きは遮断する。方針は法務と広報で一文にし、robots.txt は各社ドキュメントのボット名を確認してから書く。名前は変わります。

納品後のブログが、引用を雑にしないための入稿ルール

制作で綺麗にしたトップも、運用記事が「世界一」「必ず成果」と数字なしで積み上がると、モデルは強い語の方を拾います。納品時に、短い入稿ガイドラインを渡します。

• 数値には、日付と範囲（何を数えたか）を付ける。無ければ書かない
• 他社比較は、確認できる公開情報だけ。推測で順位を付けない
• 見出しは、見た目のためではなく質問文や対象が分かる語にする
• 著者名と更新日を、本文の近くに出す
• 画像の中だけに結論を置かない

これは SEO 記事の品質と同じで、AI 引用のためだけの特殊ルールではありません。人が検証できる文が、結果として引用に耐えます。

AI引用適合度チェックシート

キックオフで必須行だけ合意します。推薦の保証チェックではありません。

まとめ：選ばれるサイトは、人にも説明しやすい

ChatGPT や Gemini に紹介してもらう準備は、裏技のプロンプトではありません。相談されたときに、対象と非対象が本文にあり、表が表のまま残り、誰のサイトかが追えること。それは GEO / LLMO という新語より前に、セマンティックでアクセシブルな Web 制作がやっていたことです。

• 機械が迷わない DOM と、初回 HTML の事実
• 比較できる文と、矛盾しない構造化データ
• 著者・運営と、検証できる一次情報
• クローラ方針と、運用記事の入稿ルール

既存サイトなら、まず「おすすめは？」と自社カテゴリで聞かれたときに、今の公開ページのどの文を出典にしてほしいかを先に書いてください。その文が HTML に無ければ、施策はマークアップより情報設計です。

AI 検索での引用されやすさの点検や、比較に耐えるサービスページの作り込みは、相談・お問い合わせからどうぞ。診断で推薦を約束はしません。残したい事実が、今の DOM にあるかどうかから見ます。