ChatGPTやGeminiにあなたのサービスを質問すると、競合は引用されるのに自社は出てこない——その差は、コンテンツの良し悪しより前に「AIがサイトを読めているか」で決まっていることがあります。AIはページを人間のように眺めるのではなく、裏側のHTMLを文字どおり読み解きます。この記事では、AI検索に引用されるための技術的な土台、つまり構造化データ・表示速度・AIクローラー対応・llms.txtを、実装の観点から具体的に説明します。

AIはあなたのサイトの「見た目」を見ていない

最初に押さえるべき前提があります。生成AIや検索クローラーは、ブラウザに表示された美しいレイアウトを評価しているのではなく、その下にあるHTMLという設計図を読んでいます。見出しがどこで、本文がどこで、これは質問でこれは答え——そうした意味の区切りをHTMLのタグから判断しています。

ここでつまずきやすいのが、ノーコードツールで作られたサイトです。見た目は整っていても、内部では文章が意味のないdivタグで何重にも包まれ、どこが見出しでどこが結論なのかが構造から読み取れないことが珍しくありません。人間の目には同じページでも、AIにとっては「意味が曖昧で引用しづらいページ」になっているわけです。技術土台を固めるとは、この曖昧さを取り除き、機械が誤解なく内容を読める状態にすることに尽きます。

構造化データ：ページに「意味のラベル」を貼る

構造化データは、ページの各部分が何を意味するかをAIに直接伝える仕組みです。これがあると、AIはページを推測で解釈する必要がなくなります。

具体例で考えましょう。よくある質問のページに「料金はいくらですか？」「月額1万円からです」と書いてあるとき、人間はどちらが問いでどちらが答えか一目で分かります。しかしHTMLが普通の段落として並べているだけだと、AIには判別が難しくなります。そこでSchema.org（構造化データの世界共通の語彙集）のFAQPageという型を使い、「これは質問」「これは対応する回答」とラベルを貼ります。すると、AIは安心してその回答を引用できます。

実装では、ページの役割に応じて型を使い分けます。コラムやニュースには記事を表すArticle、よくある質問にはFAQPage、トップからの階層を示すパンくずにはBreadcrumbListを付与します。難しく見えますが、要は「このページは何で、どこが要点か」を機械に申告する作業です。コンテンツの中身を変えなくても、ラベルを正しく貼るだけで読み取りやすさは大きく変わります。

表示速度：遅いサイトは「読み切ってもらえない」

表示速度は、訪問者の離脱を防ぐためだけの指標ではありません。クローラーが効率よくページを読めるかどうかにも直結します。

Googleは表示の速さ・操作のしやすさ・レイアウトの安定性をまとめてCore Web Vitalsという品質指標で評価しており、これを満たせないサイトは検索評価で不利になりやすいとされています。AIに情報を届ける前段として、Googleなどの検索基盤にきちんとクロールされ、評価されることがそもそも必要です。重い画像や過剰なスクリプトでページが遅いと、クローラーは限られた時間で全ページを読み切れず、肝心のコンテンツが見落とされることもあります。

表示速度の改善は派手な施策ではありませんが、土台としての効き目は大きい領域です。軽く・速く・崩れないサイトは、人にもAIにも好かれます。

AIクローラー対応：そもそも「読む許可」を出しているか

どれだけ構造を整えても、AIのクローラーがサイトに入ってこられなければ意味がありません。ここで関わるのがrobots.txtと、新しく提案されているllms.txtという2つの仕組みです。

robots.txtは、サイトのどこを巡回してよいかをクローラーに伝えるファイルです。AI検索エンジンはそれぞれ専用のクローラーでサイトを訪れるため、引用してほしいページが誤ってブロックされていないかを確認しておく必要があります。「対策はしているのに引用されない」場合、入口で締め出していたというのは意外とよくある話です。

もう一つのllms.txtは、AI向けにサイトの主要情報を整理して提供するためのテキスト規格で、現在提案・普及の途上にあります。サイトの概要や重要ページの一覧をAIが読みやすい形でまとめておくもので、いわばAIのための案内板です。まだ標準として確立しきってはいませんが、対応しておくことで、AIがサイトの全体像と重要ページを把握しやすくなることが期待されています。

サイトマップと情報設計：点ではなく「地図」で伝える

個々のページを整えるだけでなく、ページ同士のつながりをAIに見せることも土台の一部です。

XMLサイトマップを用意し、各ページの公開日・更新日を伝えると、クローラーは新しい情報や更新箇所を見つけやすくなります。さらに、パンくずや内部リンクでページ間の関係を示すと、AIは「このサービス紹介ページの下に、料金ページと事例ページがある」といった全体構造を理解できます。一枚一枚の良い地図より、つながった一枚の大きな地図のほうが、機械はサイトを正しく案内できるということです。

ここまでの構造化データ・表示速度・クローラー対応・情報設計は、すべて同じ目的に向かっています。サイトの意味と構造を、機械が誤解なく読み取れる状態にすること。これが技術土台の本質です。

自社サイトで実際に検証しました

ここまでの内容を、カラフルボックスはまず自社サイトで実践し、効果を測りました。

以前の自社サイトはノーコードツール製で、AIがページ構造を読み取りにくい状態でした。そこでNext.jsで一からサイトを内製し直し、この記事で挙げた構造化データの整備・情報設計・AIクローラー対応・llms.txtの適用を一通り行いました。結果として、自社診断によるGEO対応度スコアは13点から87点へと改善しています。Google公式の測定ツールLighthouseの実測でも、SEO100点・AI対応100点・アクセシビリティ100点・品質96点という数値を確認しました。

参考までに、AI検索の広がりは数字にも表れています。Ahrefsの2024年の調査では、全検索結果の約20.5%にGoogleのAI Overviews（検索結果上部のAIによる要約）が出現していました。検索結果のおよそ5回に1回でAIの要約が顔を出す計算です。技術土台を固めることは、この流れの中で引用される側に回るための準備でもあります。

まとめ：コンテンツの前に、読まれる器を整える

AI検索対策の技術土台とは、構造化データ・表示速度・AIクローラー対応・llms.txt・情報設計を組み合わせ、サイトの意味を機械が正しく読める状態をつくることです。良いコンテンツはここで初めて生きてきます。器が整っていなければ、せっかくの中身もAIには届きません。

カラフルボックスのScale Sonarは、Next.js × Cloudflare Pagesを基盤に、制作の段階からこれらの技術土台を組み込んだサイトを構築します。AIコーディングツール「Claude Code」を100%活用することで短納期・低コストを両立し、制作は10万円（税抜）から、最短1ヶ月での提供が可能です。対応するAI検索はChatGPT・Claude・Gemini・Perplexity・Google AI Overviewsの5つ。技術面からAI検索対策を固めたい方は、お気軽にご相談ください。