# AI検索に「引用される」サイトをつくる — 自社サイトで実装したAEO(AI検索最適化)

- 公開日: 2026-07-23
- 更新日: 2026-07-23
- URL: https://systemdesignworks.co.jp/news/aeo-ai-search-optimization
- 発行: 株式会社システムデザインワークス

> 「ググる」から「AIに聞く」へ検索行動が変わるなか、ChatGPT・Gemini・Perplexity などのAI検索に引用されやすいサイトを設計する取り組み(AEO)を自社サイトで実装しました。AIクローラーの受け入れ、IndexNow、構造化データ、FAQ、Markdown配信まで、実装内容と実際につまずいたポイントを公開します。

こんにちは！システムデザインワークスの山岸です。

なにか調べるとき、Google で検索する代わりに ChatGPT や Gemini に直接聞く——そんな行動が当たり前になってきました。AIは答えを作るとき、根拠として数件のWebサイトを引用します。ユーザーの目に入るのは、その**引用された数枠のサイトだけ**。「検索結果の1ページ目に載る」ことを競っていた時代から、「AIの回答に引用される」ことを競う時代への転換点です。

弊社では 2026年7月、自社サイトにこの新しい流入経路への対策——**AEO(AI検索最適化)**——を実装しました。この記事では、その設計方針・実装内容・実際につまずいたポイントを、そのまま公開します。

## AEO(AI検索最適化)とは何か

AEOとは、ChatGPT・Gemini・Perplexity などのAI検索・AIアシスタントが回答を作る際に、自サイトを**発見し、正しく理解し、引用しやすくする**ためのサイト設計のことです(Answer Engine Optimization の略)。

先に正直なことを言うと、**AIに引用されることを保証する技術は存在しません**。何を引用するかは各社のアルゴリズム次第です。できるのは「引用候補に入るための条件を、先回りしてすべて満たしておく」こと。SEOが「検索順位を上げる努力」だとすれば、AEOは「AIという新しい読者への受け入れ態勢づくり」です。

## 全体像:「発見・理解・抽出」の3層で設計する

やみくもに施策を並べるのではなく、AIがサイトを引用するまでの流れに沿って3つの層に整理しました。

| 層 | 目的 | 実装したもの |
| --- | --- | --- |
| 発見 | AIのクローラーに見つけてもらう | robots.txt の明示許可、IndexNow |
| 理解 | 「何者のサイトか」を機械が読める形で伝える | 構造化データ(JSON-LD)のエンティティグラフ化 |
| 抽出 | 回答に引用しやすい形でコンテンツを渡す | FAQブロック、要点ボックス、Markdown配信、llms.txt |

どれか1つでは機能しません。入口が塞がっていれば理解も抽出もされず、理解されなければ「栃木のシステム開発会社」という文脈で引用されることもないからです。

## 発見: AIクローラーをどう迎え入れるか

まず robots.txt(クローラー向けの入場案内)に、GPTBot(OpenAI)・ClaudeBot(Anthropic)・PerplexityBot・Google-Extended など**9種類のAIクローラーを名指しで「巡回OK」と明記**しました。「*(全員) Allow」だけでも巡回はできますが、名指しすることで受け入れの意図がはっきりし、後述するBot対策との衝突にも気づきやすくなります。

次に **IndexNow** を導入しました。IndexNow とは、サイトの更新を検索エンジンへ即時に通知するプロトコルです。従来はクローラーの巡回を待つだけでしたが、記事を公開した瞬間に「更新しました」とこちらから呼び鈴を鳴らせます。通知先である Bing のインデックスは ChatGPT検索 や Perplexity が回答の材料に使っているため、AI検索への反映を早める効果が期待できます。

```mermaid
flowchart LR
  A[記事を公開] --> B[公開フックが発火]
  B --> C[IndexNow へ URL を自動通知]
  C --> D[Bing 系インデックスが更新]
  D --> E[ChatGPT検索・Perplexity の回答材料に]
```

通知は「失敗しても公開処理を止めない」ベストエフォート設計にしました。外部サービスへの通知のために、本来の記事公開が失敗しては本末転倒だからです。

## 理解: サイトを「機械が読める名刺」にする

人間はページのデザインや文脈から「これは栃木のシステム開発会社のブログだ」と読み取れますが、機械にはそれが難しい。そこで各ページに **JSON-LD(構造化データ)** という機械可読の名刺を埋め込みます。

ポイントは、名刺を配るだけでなく**全ページの名刺に同じIDを振って相互に紐づけた**ことです(エンティティグラフ化)。「この記事の著者」「このサイトの運営者」「この開発事例の実施者」がすべて同一の会社だと機械的に辿れるため、AIがサイト全体を「ひとつの主体」として理解できます。会社情報には事業内容・専門領域・所在地・設立日まで宣言し、ブログ記事は BlogPosting、開発実績は「課題→解決→成果」を持つ事例記事としてそれぞれ型を明示しました。

## 抽出: AIが引用しやすい記事の形にする

AIは記事を丸ごと引用するのではなく、「質問への答えになる部分」を抜き出します。抜き出しやすい形をこちらで用意しておくのが第3層です。

- **要点ボックス** — 記事冒頭に結論のまとめを表示します。AIは文章の最初の数百字を要約の材料にしがちなので、そこに答えを置きます(この記事の冒頭にもあります)
- **FAQブロック** — 「Q. 費用は? / A. 規模によります」のような質問と回答のペアは、AIが最も引用しやすい構造です。表示した内容がそのまま構造化データにもなる仕組みにしたので、見た目とデータが絶対にズレません(この記事の末尾で実際に使っています)
- **Markdown配信** — 記事URLの末尾に `.md` を付けると、デザインを除いた本文だけのテキスト版を返します。AIにとっての「読みやすい軽量版」です。この記事のURLに `.md` を付けて試してみてください
- **llms.txt** — AI向けの「サイト案内板」です。会社の基本情報と主要コンテンツへのリンクを、AIが読みやすい形式でまとめています

あわせて執筆側のガイドラインも整備しました。結論を先に書く、見出しを「読者が検索窓に打ちそうな質問」にする、「◯◯とは△△である」という定義文を入れる、数値と日付を具体的に書く——どれもAIのためだけでなく、人間の読者にとっても読みやすくなる規約です。

## つまずき①: CDN がAIボットを門前払いしていた

実装を終えてデプロイした後の検証で、robots.txt が想定と**正反対の内容**になっていることに気づきました。CDN(Cloudflare)の「AIボット対策」機能が有効になっており、こちらが用意した robots.txt を管理版で上書きして、GPTBot も ClaudeBot も全面ブロックしていたのです。

この機能自体は「コンテンツをAIの学習に使われたくないサイト」にとって正しい保護です。ただ、AEOとは目的が真逆。**アプリケーション側でいくら受け入れ態勢を作っても、インフラ層が門前払いしていれば全施策が無効になります**。AI対策系の設定はCDN・WAF・サーバーと複数の層に存在するので、AEOに取り組む際は必ずインフラ層から確認することをおすすめします。

## つまずき②: robots.txt が本番に存在していなかった

CDNの上書きを解除すると、今度はサイト本体が robots.txt を配信していないことが判明しました。原因はビルド手順の隙間です。robots.txt はビルド後の後処理(postbuild)で生成する構成だったのですが、本番のデプロイでは後処理が実行されておらず、**生成されたつもりのファイルが一度も本番に含まれていなかった**。これまではCDNの管理版が上書き配信していたため、誰も気づけませんでした。

修正として、ビルド手順に依存しないアプリケーションルート(サーバーが直接応答する方式)での配信に切り替えました。教訓はシンプルで、**「配信しているつもり」は本番URLへの実際のリクエストで確かめる**こと。加えて `.txt` ファイルはCDNにキャッシュされやすく、修正後も古い応答が返り続けることがあるため、検証時はキャッシュを迂回する工夫も必要でした。

## 効果はどう測り、どう付き合うか

繰り返しになりますが、引用されるかどうかは保証できません。それでも取り組む理由は2つあります。

1つは**観測できる**こと。ChatGPT や Perplexity 経由の訪問はアクセス解析で参照元として確認でき、弊社では[毎週自動で届くレポート](/news/weekly-analytics-report-automation)でその推移を追える体制になっています。もう1つは**先行者メリット**です。構造化データの整備や Markdown 配信に対応しているサイトはまだ少なく、実装コストの低さに対して「候補に入る条件を満たしたサイト」の希少性が高い、いまが取り組みどきだと考えています。

なお、こうした施策を後から素直に足せたのは、サイトが[ヘッドレスCMS × SSG × エッジ配信という構成](/news/why-we-left-wordpress-headless-ssg)で、すべてをコードで制御できるからでもあります。

## まとめ

- 検索行動は「ググる」から「AIに聞く」へ。**AIの回答に引用される数枠**が新しい入口になる
- 引用は保証できない。できるのは「発見・理解・抽出」の3層で**候補に入る条件をすべて満たす**こと
- アプリ側の実装だけでは不十分。**CDN・ビルド手順・キャッシュまで含めて疎通を確認**しないと、施策が届いていないことに気づけない
- 施策の多くは人間の読者にとっての読みやすさ改善と同じ方向を向いている

## よくある質問

**Q. AEOとSEOは何が違うのですか?**

A. 対象が違います。SEOは検索エンジンの順位を対象にした最適化で、AEOはAIが回答を生成する際の「引用元」に選ばれることを狙った設計です。ただし土台は共通しており、良質なコンテンツと正しい技術基盤というSEOの基本は、AEOでもそのまま効きます。

**Q. AEOを実施すれば必ずAI検索に引用されますか?**

A. いいえ、保証はできません。何を引用するかはAI各社のアルゴリズム次第です。AEOでできるのは、発見・理解・抽出の各段階で引用候補に入るための条件を満たしておくことです。

**Q. 何から始めるのがよいですか?**

A. まず現状確認をおすすめします。robots.txt がAIクローラーを拒否していないか、CDNやWAFのAIボット対策が有効になっていないかを本番URLで確かめるだけでも、「施策以前に入口が塞がっていた」というケースを防げます。

## ご相談お待ちしております。

**栃木県でアプリ開発・システム開発の会社をお探しの方、Web サイトや業務システムを長く安心して任せられるパートナー企業を探している方へ。** 今回ご紹介したようなAI検索への対策はもちろん、サイト制作・業務システム・アプリ開発まで、システムデザインワークスが一貫して対応します。

「うちのサイト、AIから見えてるのかな?」といった軽い疑問からで構いません。弊社は自社サイトで実際に運用し、効果と落とし穴を把握したうえでご提案するスタイルです。お気軽にお問い合わせフォームよりご連絡ください。