この記事で得られること
- Google AI Overview(AIO)がオーガニック検索順位と異なる基準で引用元を選んでいる実例
- AIO引用を得るために実装した構造化データ(JSON-LD)の具体的なコード
- llms.txtの設計・配置と、AIO引用との関連性
- Next.js App Routerでの
generateMetadataと構造化データの実装パターン
対象読者は、個人開発やWeb制作でSEOの構造面を改善したいエンジニアです。
何が起きたか
2026年5月、「seo スコア チェック 無料」でGoogle検索を行ったところ、以下の状態が確認されました。
| 表示箇所 | 結果 |
|---|---|
| AI Overview(AIO) | 当サイトが1番目に引用。「45項目を診断」「改善コードも自動生成」と機能まで記述 |
| オーガニック検索結果 | 1ページ目(10位以内)に表示なし。ohotuku.jp、EmmaToolsなど老舗が上位 |
サイトは公開から約3ヶ月、被リンクも少ない状態です。オーガニックで老舗ツールに勝てないのは当然ですが、AIOでは最上位に引用されている。このギャップが偶然なのか、構造的な要因があるのかを技術面から分析します。
外部調査データ:AIO引用の62%はトップ10圏外から
この現象は当サイト固有ではありません。
Ahrefs(86.3万SERP分析):
- AIO引用の62%がオーガニックトップ10以外のページから選出
- AIO引用ページの平均DRは65 — 中規模サイトでも十分引用される
- AIOは「順位が高いページ」ではなく「回答に適した情報を持つページ」を優先
Seer Interactive:
- AIO引用の**55%がページ上部30%**から情報を抽出
- ページ冒頭で検索意図に直接回答している構造が、AIO引用の重要条件
つまり、被リンクやドメイン歴よりもページ構造と情報の抽出しやすさがAIO引用の鍵になっています。
実装1:JSON-LD SoftwareApplication スキーマ
ツール型サイトではWebApplicationスキーマを実装することで、AIがサービスの性質を機械的に理解できる状態を作れます。
// lib/json-ld/home.ts — ツール型サイトの構造化データ例
export function getToolJsonLd() {
return {
"@context": "https://schema.org",
"@type": "WebApplication",
name: "ツール名",
url: "https://example.com",
description: "ツールの概要を1文で記述",
applicationCategory: "UtilitiesApplication",
operatingSystem: "All",
offers: [
{
"@type": "Offer",
price: "0",
priceCurrency: "JPY",
name: "無料プラン",
description: "基本機能の説明",
},
{
"@type": "Offer",
price: "980",
priceCurrency: "JPY",
name: "有料プラン",
description: "追加機能の説明",
},
],
featureList: [
"主要機能1",
"主要機能2",
"差別化ポイント(例:改善コード自動生成)",
],
}
}
ポイント:
-
offersで無料プランを明示する(AIOが「無料」を引用文に含める根拠になる) -
featureListに具体的な機能を列挙する(AIが「何ができるツールか」を抽出する情報源) -
applicationCategoryとoperatingSystemで用途を明確化する
当サイトではfeatureListに記載した「改善コード自動生成」がAIOの引用文にそのまま含まれていました。
実装2:FAQPage スキーマ
FAQPageは、Google検索でのリッチリザルトだけでなく、AIOが「よくある質問」を抽出する際のソースにもなります。
// FAQエントリーのヘルパー関数
function faqEntry(name: string, text: string) {
return {
"@type": "Question" as const,
name,
acceptedAnswer: { "@type": "Answer" as const, text },
}
}
// FAQPage JSON-LDの生成
const faqJsonLd = {
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
faqEntry(
"このツールは何ができますか?",
"URLを入力するだけでSEO診断ができます。構造化データ・メタタグ・"
+ "技術SEOなど複数の観点から総合的にチェックします。"
),
faqEntry(
"無料で使えますか?",
"はい、登録不要で無料利用が可能です。"
),
],
}
設計の注意点:
-
as constを付けることで"@type"がリテラル型になり、型安全性が上がります - Googleのガイドライン上、JSON-LDで定義したFAQはページに実際に表示されている必要があります。JSON-LDだけに書いてページに非表示はNG
- FAQの回答には具体的な数値を含めます。AIOはこの種の具体情報を引用しやすい傾向があります
実装3:llms.txtの設計と配置
llms.txtは、LLMがサイトの内容を理解するための説明ファイルです。robots.txtがクローラー向けなら、llms.txtはAI向けのサイト説明書です。
配置
public/
llms.txt ← サマリー版
llms-full.txt ← 詳細版(全機能・料金・FAQ)
Next.js App Routerではpublic/に置くだけで静的配信されます。Route Handlerは不要です。
llms.txtの構造(実際のファイルから抜粋)
# CodeQuest.work SEO
> Webサイトの健康診断ツール。構造化データ・メタタグ・Core Web Vitals・
> ドメインパワーなど45項目以上を瞬時にチェックし、100点満点のSEOスコアで可視化。
> 診断結果から改善コードを自動生成し、コピペで即修正できる
> 「診断→改善」一体型ツール。
## サービス概要
CodeQuest.work SEOは、URLを入力するだけで、構造化データ(JSON-LD / Schema.org)、
基本SEO(タイトルタグ・メタディスクリプション・見出し構造・canonical)、
コンテンツ品質(文字数・画像alt属性・内部リンク)、
技術的SEO(HTTPS・モバイル対応・ページ速度)の
4カテゴリ・45項目以上を瞬時にチェックし、100点満点のSEOスコアで
サイトの健康状態をスコア化します。
## 他ツールとの違い
競合との差別化ポイントを明記するセクション。
AIはここから「何が違うか」を抽出する。
## 詳細情報
- [llms-full.txt](https://example.com/llms-full.txt): 全機能の詳細
AIOが引用したフレーズとの一致箇所:
AIOは「45項目を診断」「改善コードも自動生成」と記述しました。これはllms.txtの冒頭に書かれている内容そのものです。Seer Interactiveの調査(ページ上部30%から55%が抽出される)と一致する挙動で、llms.txtの冒頭に要約を置く設計が効いていると考えられます。
実装4:generateMetadataとページ冒頭の直接回答
Next.jsのgenerateMetadataで、検索意図に対する直接的なdescriptionを設定します。
// Next.js App Router — generateMetadataの例
export async function generateMetadata(): Promise<Metadata> {
return {
title: "ツール名|具体的な機能を含むタイトル",
description:
"URLを入力するだけで〇〇項目を無料で診断。"
+ "改善コード自動生成付き。",
openGraph: {
title: "ツール名",
description: "機能の要約を1文で",
type: "website",
},
twitter: { card: "summary_large_image" },
}
}
さらに、ページ本体の冒頭で検索意図に直接回答するテキストを配置しています。
<!-- ランディングページのヒーローセクション -->
<section>
<h1>ツール名 — 具体的な数値を含む1文の要約</h1>
<p>
〇〇項目を△△で診断。
改善コードの自動生成まで、これ1つで完結します。
</p>
</section>
当サイトのh1とリード文には「45項目」「改善コード自動生成」が含まれており、AIOの引用文にもこれらがそのまま使われていました。ページ冒頭の30%以内に、検索意図への回答を具体的な数値と共に配置することがAIO引用の前提条件になっています。
実装の検証方法
構造化データが正しく実装できているかは、以下の方法で確認できます。
Google Rich Results Test
Rich Results TestにURLを入力すると、Googleが認識している構造化データの種類と、リッチリザルトの対象になるかどうかが表示されます。FAQPage、SoftwareApplication、WebApplicationなどが検出されていれば正常です。
Schema.org Validator
Schema Markup Validatorでは、JSON-LDのシンタックスエラーやプロパティの欠落を検出できます。@typeの指定ミスや必須プロパティの漏れはここで見つかります。
Chrome DevToolsでの確認
// コンソールでJSON-LDの内容を確認
document.querySelectorAll('script[type="application/ld+json"]')
.forEach(el => console.log(JSON.parse(el.textContent)))
まとめ:GEO対策の正体は良いSEOそのもの
AIOに引用された要因を振り返ると、すべてSEOの基本施策の延長線上にあります。
| 実装内容 | SEOとしての位置づけ |
|---|---|
| JSON-LD SoftwareApplication / FAQPage | 構造化データ(SEOの基本) |
| llms.txt / llms-full.txt | robots.txtの延長(AI向け情報開示) |
| ページ冒頭の直接回答 | コンテンツSEOの基本 |
| generateMetadataでのmeta最適化 | メタタグ最適化(SEOの基本) |
GEO(Generative Engine Optimization)専用の特殊な対策は何もしていません。構造化データを正しく実装し、検索意図に直接回答するページ構造を作り、AIが読み取れる形式で情報を提供した結果が、AIO引用として先に現れたに過ぎません。
個人開発や新規サービスのように被リンクが少なくオーガニック順位で不利な場合でも、ページ構造と構造化データの実装次第でAIO引用を獲得できる可能性があります。まずはJSON-LDの実装とllms.txtの配置から始めてみてください。
SEOスコアチェックツール: SEO_CHECK — RINIAディレクターツール。
Web制作・SEO関連の技術情報サイト: CodeQuest.work