はじめに

「Googleで検索」が「AIに質問」へと急速に置き換わりつつあります。2025年の調査では、生成AIからSMBサイトへの紹介トラフィックは前年比+123%という数字が出ています。一方で、従来型の検索クリック数は減少傾向にあります。

この変化を踏まえて登場したのが AEO（Answer Engine Optimization） という概念です。SEOが「検索結果での順位」を最適化するのに対し、AEOは「AIが回答を生成する際に、自社サイトを情報源として引用してもらう」ことを目指します。

ところが、日本語圏ではAEOに関する実践的な情報がまだ不足しています。本記事では、AEO対策のチェックリストを 7つの実装ステップ に分けて、コードレベルで具体的に解説します。

対象読者:

自社サイトのAI検索対応をこれから始める開発者
AEOという言葉は聞いたことがあるが、何から手を付ければいいか分からない方
SEOの知識はあるが、AEO特有の対策を知りたい方

目次

AEOとは何か、なぜ今必要か
ステップ1: AIクローラーのアクセス許可状況を確認
ステップ2: robots.txt を AI 対応に書き換える
ステップ3: Cloudflareの罠を回避する
ステップ4: llms.txt を導入する
ステップ5: 構造化データ（JSON-LD）を整備する
ステップ6: コンテンツのAEO最適化（E-E-A-T + Q&A形式）
ステップ7: 効果測定と継続改善
まとめ：AEO対策チェックリスト

1. AEOとは何か、なぜ今必要か

1.1 SEO vs AEO

項目	SEO	AEO
目的	検索結果での上位表示	AI回答での引用
主要プラットフォーム	Google, Bing	ChatGPT, Claude, Perplexity, Gemini, AI Overviews
評価指標	順位、CTR、流入数	引用率、メンション率、AI由来トラフィック
主要シグナル	被リンク、E-E-A-T、コンテンツ品質	構造化データ、エンティティ明確性、llms.txt、AI crawler 許可
反映速度	数週間〜数ヶ月	数日〜数週間

AEOは「SEOの代替」ではなく「SEOの上に乗る追加レイヤー」として理解するのが正確です。両方を並行して進める必要があります。

1.2 なぜ今 AEO か

3つの観測可能な変化があります：

検索行動の移行: 2024〜2025年にかけて、若年層を中心に「ググる」から「ChatGPTに聞く」への移行が進行中。

Google AI Overviews の本格展開: Google検索結果の上部にAI生成の回答が表示されるケースが増加。クリック前に答えが完結してしまう。

CTRの構造的低下: 検索順位1位でも、AI回答に引用されなければトラフィックは伸びにくくなっている。

つまり「検索結果に表示される」だけでは不十分で、「AIに引用される」ことが重要になっています。

1.3 AEO対策の全体像

本記事で扱う7ステップを先にまとめます：

[基盤レイヤー]
  ステップ1: AIクローラーのアクセス可否を確認
  ステップ2: robots.txt をAI対応に整備
  ステップ3: Cloudflareの自動ブロック設定を見直す

[案内レイヤー]
  ステップ4: llms.txt を配置
  ステップ5: 構造化データ（JSON-LD）を整備

[コンテンツレイヤー]
  ステップ6: E-E-A-T と Q&A 形式の最適化

[継続改善]
  ステップ7: 効果測定と定期的な見直し

2. ステップ1: AIクローラーのアクセス許可状況を確認

AEO対策の 大前提 は、AIクローラーが自社サイトにアクセスできることです。アクセスを拒否されているサイトは、どれだけ良質なコンテンツを持っていても引用対象から外れます。

2.1 現状把握すべき主要AIクローラー（2026年時点）

回答エンジン（live querying）

クローラー名	運営	用途
OAI-SearchBot	OpenAI	ChatGPT Search
ChatGPT-User	OpenAI	ChatGPTのブラウズ機能
Claude-User	Anthropic	Claudeのブラウズ機能
PerplexityBot	Perplexity	Perplexity AI検索
DuckAssistBot	DuckDuckGo	DuckDuckGo AI

学習用クローラー（training）

クローラー名	運営	用途
GPTBot	OpenAI	モデル学習データ収集
ClaudeBot	Anthropic	Claude学習
Google-Extended	Google	Gemini / Vertex AI 学習
Applebot-Extended	Apple	Apple Intelligence 学習
Bytespider	ByteDance	TikTok / Doubao
Meta-ExternalAgent	Meta	Meta AI / Llama
CCBot	Common Crawl	多くのLLMが利用

2.2 現状をチェックするには

3つの方法があります：

方法A: robots.txt を手動確認

curl -s https://example.com/robots.txt

各クローラー名で Disallow ルールがないかを確認します。ただし User-agent: * のグローバルルールも要チェックです。

方法B: 実際のリクエストを送って検証

curl -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.2; +https://openai.com/gptbot" \
     -I https://example.com/

ステータスコードが200ならOK、403や429ならブロックされている可能性が高いです。robots.txtで許可していても、Cloudflareなどの中間レイヤーで拒否されているケースが頻発しているため、実通信テストは必須 です。

方法C: 専用ツールを使う

12種類のAIクローラーをまとめて診断したい場合、AIクローラーチェッカーを使うと robots.txt + 実通信の両方を一度に検証できます（無料、会員登録不要）。

2.3 確認すべきポイント

実装チームで現状把握する際のチェック項目：

robots.txt が存在し、HTTP 200 を返す
主要5クローラー（GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot）が明示的に許可されている、または Disallow されていない
実際のリクエスト（User-Agent差し替え）で 403/429 が返らない
CDN/WAF のレイヤーでブロックされていない

ここで何件かでもブロックされていた場合、次のステップへ進みます。

3. ステップ2: robots.txt を AI 対応に書き換える

3.1 推奨される基本パターン

学習も検索も両方許可する最もシンプルなパターン：

# robots.txt — 全AI許可パターン

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

User-agent: CCBot
Allow: /

# 通常のクローラー
User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

3.2 「学習はブロック、検索は許可」の戦略

コンテンツを学習データとして使われたくない場合：

# 学習用クローラーはブロック
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

# 検索用クローラーは許可（引用機会は確保）
User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: *
Allow: /

この戦略の利点：

モデル学習データへの寄与は最小限に抑えられる
ChatGPT / Claude / Perplexity の 検索機能経由での引用 は維持される
リアルタイム性のあるAI回答での露出が確保される

3.3 注意点

ルール記述は 上から順に評価 されるため、より具体的なUser-agentを先に書く
Allow: / よりも「Disallow がない」状態の方がトラブルが少ない（一部クローラーで Allow 解釈が異なる）
変更後は必ず curl https://example.com/robots.txt で反映確認

3.4 Disallow パスの考慮

サイトに管理画面や検索結果ページなど、AIに見せる必要のないパスがある場合：

User-agent: GPTBot
Disallow: /admin/
Disallow: /search?
Disallow: /api/private/
Allow: /

User-agent: OAI-SearchBot
Disallow: /admin/
Disallow: /search?
Allow: /

4. ステップ3: Cloudflareの罠を回避する

4.1 何が起きているか

2024年後半、Cloudflareは新規ゾーンに対して AIクローラーをデフォルトでブロック する設定を導入しました。これにより、サイト運営者が気付かないうちに：

GPTBot, ClaudeBot, PerplexityBot などが 403 エラーで弾かれている
robots.txt では Allow しているのに、Cloudflareのエッジで拒否されている
結果として、AI検索エンジンでの引用機会を完全に失っている

4.2 確認方法

Cloudflareダッシュボードでの確認：

Cloudflare ダッシュボード → 対象ゾーン
Security → Bots または AI Audit（プランによって表記異なる）
「AI Bots」設定が Block になっていないか確認

または、コマンドラインで検証：

# GPTBot を装ってリクエスト
curl -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.2; +https://openai.com/gptbot" \
     -I https://example.com/

# 期待結果: HTTP/2 200
# 問題あり: HTTP/2 403 with "cf-ray" header

レスポンスヘッダに cf-ray が含まれていて、ステータスが 403 の場合、Cloudflareでブロックされている可能性が高いです。

4.3 修正手順

手順1: Cloudflare の自動ブロックを Off

ダッシュボード → Security → Bots → AI Audit
「Block AI Bots」が有効なら無効に変更
または、特定のクローラーごとに Allow / Block を個別設定

手順2: WAF ルールの見直し

Cloudflareの「カスタム WAF ルール」で User-Agent ブロックを設定している場合、AI クローラー名が含まれていないかを確認します。よくある誤設定：

# 悪い例: "bot" を含むUser-Agentを一律ブロック → GPTBot, ClaudeBot も巻き込まれる
http.user_agent contains "bot"

# 良い例: 明示的な悪性ボットだけブロック
http.user_agent contains "BadBot" or http.user_agent contains "ScraperX"

手順3: Cache設定の確認

エッジキャッシュが古い403レスポンスを保持していることがあります。Cloudflare → Caching → Configuration → Purge Everything で一度キャッシュを消去します。

4.4 検証

修正後、再度実通信テストを行います：

for ua in "GPTBot" "ClaudeBot" "PerplexityBot"; do
  echo -n "$ua: "
  curl -A "Mozilla/5.0 (compatible; ${ua}/1.0; +https://example.com)" \
       -s -o /dev/null -w "%{http_code}\n" https://example.com/
done

全て200が返れば成功です。

5. ステップ4: llms.txt を導入する

5.1 llms.txt とは

2024年9月にJeremy Howard氏が提案した新しい標準で、サイトのコンテンツ構造をMarkdown形式でAI（LLM）に伝えるファイルです。サイトのルート（example.com/llms.txt）に配置します。

robots.txt と llms.txt の役割の違い：

項目	robots.txt	llms.txt
目的	アクセス制御	コンテンツ案内
形式	プレーンテキスト	Markdown
対象	クローラー全般	AI / LLM
標準化	1994年〜業界標準	2024年〜提案段階

両方を併用するのが理想的です。robots.txt で「アクセスして良い」と伝え、llms.txt で「重要なのはここです」と案内します。

5.2 基本フォーマット

# サイト名

> サイト全体の簡潔な紹介（1〜2文）

## Docs
- [ページタイトル](https://example.com/page): ページの説明（80字以内）
- [ページタイトル](https://example.com/page): ページの説明

## Tools
- [ツール名](https://example.com/tool): ツールの説明

## Optional
- [低優先度ページ](url): 説明

5.3 ベストプラクティス

実装時のチェック項目：

H1 は1つ: サイト名のみ
blockquote: H1の直後にサイト概要を1〜2文で
ページ数は30以下: AIが処理しやすい量
絶対URL: 相対パスは不可
HTMLは使わない: 純粋なMarkdownのみ
重要度の低いページは Optional セクション: 利用規約、プライバシーポリシーなど
月1回の更新: 新規ページ追加・廃止に追随

5.4 実装例

実際のサイトでの実装例（短縮版）：

# Example株式会社｜SaaS人事管理ツール

> 中小企業向けクラウド人事管理SaaS。勤怠管理、給与計算、年末調整を一元化。

## Docs
- [製品概要](https://example.com/product): SaaS人事管理ツールの全機能を解説
- [導入ガイド](https://example.com/guide): 初期設定から運用開始までのステップ
- [API ドキュメント](https://example.com/api): REST API リファレンス

## Tools
- [料金シミュレーター](https://example.com/calc): 従業員数別の月額料金を計算
- [機能比較表](https://example.com/compare): 競合製品との機能比較

## Blog
- [年末調整の電子化ガイド](https://example.com/blog/year-end): 2026年版完全ガイド
- [働き方改革と勤怠管理](https://example.com/blog/workstyle): 法対応のポイント

## About
- [会社概要](https://example.com/about): 設立から現在までの沿革
- [採用情報](https://example.com/careers): エンジニア・営業職募集中

## Optional
- [プライバシーポリシー](https://example.com/privacy): 個人情報保護方針
- [利用規約](https://example.com/terms): サービス利用規約

5.5 自動生成ツール

手動でメンテナンスするのは現実的でないため、自動生成ツールを使うのが推奨です。サイトマップを解析して自動的にllms.txtを生成できるllms.txt ジェネレーターを使うと、AIが各ページの日本語要約まで作ってくれます（無料、Claude Haiku 4.5使用）。

5.6 配置とNext.jsでの実装

Next.js 13+ の場合、public/llms.txt に配置するだけで https://example.com/llms.txt でアクセス可能になります：

project-root/
├── public/
│   ├── llms.txt        ← ここに配置
│   ├── robots.txt
│   └── sitemap.xml
└── app/

WordPress の場合、テーマの functions.php に以下を追加：

add_action('template_redirect', function() {
    if ($_SERVER['REQUEST_URI'] === '/llms.txt') {
        header('Content-Type: text/plain; charset=UTF-8');
        readfile(get_template_directory() . '/llms.txt');
        exit;
    }
});

6. ステップ5: 構造化データ（JSON-LD）を整備する

6.1 なぜAEOで構造化データが重要か

構造化データは AI検索エンジンが情報を正確に抽出するための最重要シグナル です：

AI回答エンジンが価格・著者・公開日などの具体的な情報を引用する際、構造化データを参照する
同じ内容のページが2つあった場合、有効なschemaを持つ方が引用される確率が高い
リッチリザルト（FAQ、パンくず、評価など）の表示要件にもなる

6.2 優先度の高いschemaタイプ

企業サイト / SaaS

1. Organization     # 会社情報、ロゴ、SNSリンク
2. SoftwareApplication  # 製品情報、価格、対応OS
3. FAQPage          # よくある質問
4. BreadcrumbList   # パンくずナビ
5. Article          # ブログ記事

ECサイト

1. Product          # 商品情報、価格、在庫
2. Offer            # 販売条件
3. AggregateRating  # 評価（実データのみ）
4. Review           # レビュー
5. BreadcrumbList

メディア / ブログ

1. Article          # 記事
2. NewsArticle      # ニュース記事
3. Author / Person  # 著者情報（E-E-A-T重視）
4. FAQPage
5. BreadcrumbList

6.3 実装例: FAQPage

最も導入効果が高いのがFAQPageです。コードレベルでの実装：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "llms.txt とは何ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "llms.txtは2024年に提案された新標準で、サイトのコンテンツ構造をAIに伝えるMarkdownファイルです。サイトルートに配置します。"
      }
    },
    {
      "@type": "Question",
      "name": "robots.txt と llms.txt は両方必要ですか？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "はい、役割が異なります。robots.txt はアクセス制御、llms.txt はコンテンツ案内です。両方を併用するのが理想的です。"
      }
    }
  ]
}
</script>

6.4 Next.js 13+ での実装

// app/faq/page.tsx
export default function FaqPage() {
  const faqSchema = {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "質問1",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "回答1"
        }
      }
    ]
  };

  return (
    <>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(faqSchema) }}
      />
      {/* ページコンテンツ */}
    </>
  );
}

6.5 よくあるエラー

実装時に注意すべきエラー：

@context の指定漏れ → "@context": "https://schema.org" 必須
必須プロパティの欠落 → Article は headline / author / datePublished が必須
マークアップと表示内容の不一致 → JSON-LDに「価格1000円」と書いて実際は「1500円」表示はNG
テーマ/プラグインによる重複出力 → 同じschemaが複数回出力されると一部が無視される
Google リッチリザルト要件未充足 → schema.orgでは有効でもGoogle表示対象外のケース

6.6 検証方法

構造化データの検証は必ず2段階で行います：

段階1: schema.org 仕様への準拠

Schema.org Markup Validator または、AIの日本語解説付きで検証したい場合は構造化データ検証ツールを使います。

段階2: Google リッチリザルト対象判定

Google リッチリザルトテストで、実際にGoogle検索結果に表示される対象かを確認します。

7. ステップ6: コンテンツのAEO最適化

7.1 E-E-A-T の強化

AI検索エンジンは「信頼できる情報源」を優先します。E-E-A-T（Experience, Expertise, Authoritativeness, Trustworthiness）の強化が重要です。

チェック項目:

著者情報の明示: 各記事に著者名、肩書き、プロフィールページへのリンク
運営者情報の充実: 会社概要、所在地、法人番号（日本の場合）、連絡先
更新日の表示: 「最終更新日」を記事に明記
参考文献の明示: 出典・引用元へのリンク
専門家レビュー: 医療・法律など専門分野では監修者を明記

Organization schemaでの実装:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example株式会社",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "address": {
    "@type": "PostalAddress",
    "addressCountry": "JP",
    "addressLocality": "東京都港区",
    "postalCode": "100-0001"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+81-3-1234-5678",
    "contactType": "customer service",
    "email": "support@example.com"
  },
  "sameAs": [
    "https://twitter.com/example",
    "https://www.linkedin.com/company/example"
  ]
}
</script>

7.2 質問形式（Q&A）の活用

AI回答エンジンは 質問に対する明確な答え を抽出しやすい構造を好みます。コンテンツを以下のパターンで構成すると引用されやすくなります：

悪い例（散文）:

Webサイトのパフォーマンスを改善するには様々な方法があり、それぞれの状況に応じて適切な対応を取ることが重要で、まず最初に取り組むべきは…

良い例（Q&A形式）:

Webサイトの表示速度を改善するには？

最初に取り組むべきは画像の最適化です。具体的には以下の3点：

画像をWebP形式に変換

lazy loading を実装

CDN経由で配信

これにより一般的にLargest Contentful Paint（LCP）が30〜50%改善します。

7.3 エンティティの明確化

「自社が何者か」をAIに明確に伝えるための要素：

会社名・サービス名を一貫した表記で使用（表記ゆれを避ける）
メインキーワードをタイトル・H1・最初の段落に配置
関連する他のエンティティとの関係を明示（「○○社のサービス」「△△業界向け」）

7.4 内部リンク戦略

AI回答エンジンは、サイト内の関連ページ間の繋がりも評価します：

トピックごとに ハブ&スポーク 構造を作る（中心ページから関連記事へリンク）
古い記事から新しい記事へ、新しい記事から古い記事へ、双方向の内部リンク
アンカーテキストは具体的に（「こちら」ではなく「llms.txt の実装方法」）

8. ステップ7: 効果測定と継続改善

8.1 測定すべき指標

AEOの効果測定は従来のSEOよりも難しいですが、以下の指標を追います：

指標	ツール	頻度
AIクローラーアクセス数	サーバーログ分析	週次
AI由来トラフィック	GA4（リファラ分析）	月次
AI検索での引用	手動チェック + 専用ツール	月次
構造化データのエラー	Google Search Console	週次
llms.txt の有効性	バリデーターツール	月次

8.2 GA4 での AI トラフィック追跡

GA4でAI経由のトラフィックを識別するためのカスタムレポート：

Dimensions:
- Session source / medium
- Landing page

Filters:
- Source contains: chatgpt OR perplexity OR claude OR copilot OR gemini

Metrics:
- Sessions
- Engagement rate
- Conversions

このセグメントを月次で確認し、AIトラフィックの推移を把握します。

8.3 定期的な見直しサイクル

推奨される運用サイクル：

週次:

サーバーログでAIクローラーアクセスを確認
403/429エラーの急増がないか
Google Search Consoleで構造化データエラーをチェック

月次:

AIクローラーチェッカーで現状確認
llms.txt の内容を最新ページに反映
新規記事に構造化データを実装
AI由来トラフィックのレポート

四半期:

AEO戦略全体の見直し
競合サイトのllms.txt実装状況をチェック
新規AI検索エンジンの登場に対応（クローラー追加など）

9. まとめ：AEO対策チェックリスト

最後に、本記事で扱った全てのチェック項目をまとめます。自社サイトに対して全てチェックして、未対応の項目から取り組んでみてください。

基盤レイヤー

robots.txt が存在し、HTTP 200 を返す
主要5クローラー（GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot）が許可されている
実通信テスト（User-Agent差し替え）で 403/429 が返らない
Cloudflare の「Block AI Bots」設定がオフ
WAF ルールで User-Agent ブロックを設定していない（または除外設定済み）

案内レイヤー

/llms.txt が配置されている
llms.txt が30ページ以下に絞られている
llms.txt の各セクション（Docs/Tools/Blog/About/Optional）が整理されている
主要schemaタイプ（Organization, FAQPage, Article, BreadcrumbList）が実装されている
構造化データが Schema.org Validator + Google Rich Results Test の両方を通過

コンテンツレイヤー

全記事に著者情報が明示されている
運営者情報（会社概要、所在地、連絡先）が充実している
重要記事にQ&A形式のセクションがある
内部リンクがハブ&スポーク構造になっている
各ページに最終更新日が明示されている

継続改善

サーバーログでAIクローラーアクセスを定期確認
GA4でAI由来トラフィックを月次レポート
llms.txt を月1回更新
新規ページに構造化データを必須実装

おわりに

AEO対策は、SEOと違って「これが正解」というベストプラクティスがまだ確立していない領域です。AI検索エンジン自体が日々進化しており、今日のベストプラクティスが半年後には変わっている可能性も十分にあります。

ただし、本記事で扱った7ステップは どの方向に進化しても基盤として有効 な内容です：

AIクローラーがアクセスできる状態を確保する
サイト構造を機械可読な形で提供する
コンテンツの信頼性をシグナルで強化する

この3つの軸を押さえておけば、AEOのトレンド変化にも追随しやすくなります。

本記事で紹介したツール群（AIクローラーチェッカー、llms.txt ジェネレーター、構造化データ検証ツール）は、すべて無料・会員登録不要で利用できます。日本語の解説付きで、AEO対策の各ステップを実装する際にぜひ活用してみてください。

参考リンク

この記事を書いた人

合同会社山田トレード代表。中小企業・個人事業主向けのSEO/AEO診断ツール「AIテスト番人」を運営。本記事のチェックリストは、自社サイトの6つのツールを構築する中で得た知見をまとめたものです。