1. 概要（Executive Summary）
見込み客がChatGPTに「韓国でこの分野に強い会社を教えて」と尋ねる場面は、もはや仮定ではありません。問題は、その回答に自社が含まれるかどうかです。明暗を分けるのは広告費ではありません。企業サイトがAIに読み取れるよう設計されているかどうかです。
この記事では、その設計作業であるAEO（Answer Engine Optimization／回答エンジン最適化）を企業サイトの視点から扱います。前回の「SEOを超えてGEOへ」が「どのようなコンテンツを書くか」という戦略を扱ったのに対し、今回はサイトという基盤そのものがテーマです。AIがどの経路で企業を把握し、どの形式で情報を示せば正確に引用されるのかを、構造化データ → llms.txt → AIクローラー方針 → 実行計画の順に整理します。
結論から言えば、企業サイトのAEO対策は次の5点に集約できます。会社紹介文の統一、スキーママークアップ、FAQの構造化、llms.txtの公開、AI回答のモニタリング。以下では、なぜ必要なのか、どの順序で、どう実施するのかを説明します。
この記事で答える質問
「AI検索時代の企業サイトには何が必要か」「AEOはSEOと何が違うのか」「llms.txtは作るべきか」。新規サイトの構築やリニューアルを控えたスタートアップ、中小・中堅企業の実務担当者を想定して答えます。
読み終えたとき、開発会社や制作会社へそのまま渡せる要件チェックリストが残る構成です。
2. 顧客はAIに会社を尋ねるようになった
B2Bの購買プロセスの起点が、検索窓からAIのチャット画面へ移りつつあります。以前は購買担当者がキーワードを検索し、10社ほどのサイトを一つずつ確認していました。今は条件をAIに伝え、3〜4社の候補を受け取ります。企業サイトの競争は、「検索順位の競争」から「候補リストに入る競争」へ変わりました。
2.1 10回の検索が1回の質問になった
生産ラインに導入する産業用センサーの仕入先を探す担当者を考えてみましょう。2〜3年前なら「産業用センサー メーカー」「近接センサー 納入」などで検索し、各サイトで仕様や納入実績を確認したはずです。今はPerplexityやChatGPTにこう尋ねます。「韓国の産業用近接センサーメーカーで、自動車部品会社への納入実績がある企業を教えて。」AIは数秒で3〜4社を、一行の説明とともに提示します。
Gartnerは2024年初め、生成AIチャットボットの影響で、2026年までに従来型検索エンジンの利用量が25%減少すると予測しました。数値が正確に当たるかより、方向性が重要です。情報探索の入口は移動しており、比較と検証に時間がかかるB2B購買ほど、「条件に合う候補を絞ってほしい」というAIへの依頼と相性が良いのです。
2.2 AIは会社情報をどこから得るのか
第一の情報源は公式サイトです。ChatGPT SearchやPerplexityなどのAI検索は、回答を作る際にウェブを読み、出典リンクを添えます。このとき、特定企業について最も権威のある文書として扱われるのが公式サイトです。プレスリリース、ニュース記事、企業情報ディレクトリ、求人プラットフォームの会社紹介が補助情報になります。
AIが企業を回答に含める前に確認する要素は、おおむね次のとおりです。
- 企業の同一性：何をする会社か、一文で理解できるか
- 一貫性：公式サイトと外部情報の内容が一致しているか
- 具体性：サービス・製品説明に対象顧客、提供範囲、実績があるか
- 最新性：最後の更新が3年前なら信頼性は下がります
サイトがなければ候補にも入れない
AIは確認できない会社を推薦しません。サイトがない、または画像だけで文字情報がない場合、AIには読み取れるデータがない会社と映ります。人には立派に見えても、クローラーにとって空のページなら、存在しないのと同じです。
検索の時代には順位が低くても、どこかには表示されました。AIの回答は3〜4社だけを挙げて終わることが多いため、候補から外れた瞬間、その質問の中では会社の存在自体が消えてしまいます。
3. AEOはSEOと何が違うのか
AEOが狙うのは検索順位ではなく、AIの回答内容です。SEOの目標が検索結果の1ページ目に入ることなら、AEOの目標はAIが自社を正確な情報とともに優先して言及することです。
3.1 SEO・GEO・AEOの用語を整理する
3つの用語は混同されがちですが、実務上の作業は大きく重なります。SEOは検索順位の最適化、GEO（Generative Engine Optimization）は生成AIにコンテンツを引用させる最適化、AEOはその中でも「質問への回答」に掲載されることを狙う最適化です。この記事では、企業情報がAIの回答に正しく掲載されるようサイトを整える作業という意味でAEOを使います。
3.2 企業サイトでは何が変わるのか
最大の違いは最適化の「単位」です。SEOはページとキーワード単位で動きますが、AEOは会社というエンティティ全体を扱います。AIは個別ページの順位を付けるだけでなく、「この会社は何者か」という全体像を組み立てるからです。
| 項目 | SEOの視点 | AEOの視点 |
|---|---|---|
| 最適化の単位 | 個別ページ・キーワード | 会社というエンティティ全体 |
| 表示形式 | 検索結果一覧のリンク | AI回答内の文章と推薦リスト |
| 会社紹介文 | ページごとの差が多少あっても問題になりにくい | 全ページと外部チャネルで一貫している必要がある |
| 主な作業 | キーワード、被リンク、ページ速度 | 構造化データ、FAQ、会社情報の整合性 |
| 成果確認 | Search Consoleの順位・トラフィック | AIに直接質問し、回答をモニタリング |
| 失敗した場合 | 順位が数段下がる | 回答から完全に消え、存在しない会社のように扱われる |
SEOを飛ばしてAEOだけを行うことはできません。ChatGPT SearchはBingのインデックスを、Perplexityは独自クローラーのインデックスを基盤にしています。AI検索はクロールとインデックスという従来の基礎の上で動くため、サイトマップ、robots.txt、メタタグが不十分ならAEOは始まりません。新しいサイトを公開する段階なら、まず新規サイト公開後90日間のSEO設定を確認してください。
4. 構造化データとスキーママークアップ
構造化データは、サイトに埋め込む機械向けの名刺です。画面には表示されませんが、クローラーはこれを読み、会社名、業種、サービス、連絡先を誤解なく把握します。AIに会社を「推測」させず「確認」させる仕組みです。
4.1 どのスキーマをどう入れるか
schema.orgという共通語彙をJSON-LD形式でページに挿入します。GoogleもJSON-LDを推奨しています。表示HTMLを変更せずhead内にスクリプトブロックを追加するため、運用中のサイトにもデザイン変更なしで適用できます。
中心になるのはOrganizationスキーマです。会社名、代表URL、ロゴ、住所、連絡先を記載し、sameAsプロパティでSNSアカウントや外部プロフィールをつなぎます。sameAsは特に重要です。ウェブ上に分散した会社情報を「同じ会社」として結び付けるからです。
4.2 どのスキーマから導入すべきか
| スキーマ種別 | 適用箇所 | AIに伝える内容 |
|---|---|---|
| Organization | 全ページ共通（通常はトップが基点） | 会社名、ロゴ、住所、連絡先、外部プロフィール。会社エンティティの基準点 |
| Service | サービス紹介ページ | どのサービスを誰に提供するか |
| Product | 製品詳細ページ | 製品名、仕様、価格。製品単位の質問に対応 |
| FAQPage | FAQページ | 質問と回答の組。AIがそのまま引用しやすい形式 |
| LocalBusiness | 実店舗・事業所案内 | 所在地と営業時間。「近くの会社」型の質問に対応 |
| BreadcrumbList | 全ページ | サイト構造とページ間の関係 |
| Article / BlogPosting | 記事・ニュースページ | 公開日と著者。情報の新しさを示すシグナル |
必要なものは、ほぼこの7種類です。企業サイトなら、Organization、Service、FAQPageの3つを正しく入れるだけでも、基本対応の半分は完了します。
4.3 FAQを特に重視する理由
AIの回答そのものが質問と回答の形式だからです。営業やサポートに実際に寄せられる「見積もりはどう決まりますか」「制作期間はどのくらいですか」「保守は含まれますか」といった質問をFAQページにまとめ、FAQPageスキーマを接続すれば、見込み客がAIに同じ質問をしたとき、自社の回答が使われる可能性が高まります。
スキーマより先に行うこと：表記の統一
公式サイトでは「The BlueCanvas」、Naver Placeでは「BlueCanvas」、求人情報では別の法人名という状態なら、AIは3つが同じ会社か確信できません。住所や電話番号も同様です。
会社名・住所・電話番号（NAP）を全チャネルで統一することが、スキーマより先です。マークアップが精密でも、元情報が揺れていれば効果はありません。
5. llms.txtとAIクローラー対策
llms.txtはAIに渡すサイト案内です。サイトのルートにMarkdownファイルを一つ置き、「当社はこのような会社で、重要なページはここ」と伝えます。1時間もかからず作成でき、大きなデメリットもありません。
5.1 llms.txtとは何か
Answer.AIのJeremy Howardが2024年9月に提案した仕様で、llmstxt.orgに公開されています。出発点は単純です。LLMのコンテキストウィンドウはサイト全体を収めるには小さく、HTMLにはナビゲーションやスクリプトなどのノイズがあります。そこで、サイトの要点をきれいなMarkdown一枚に要約するという考え方です。
形式は次のように定められています。
- 配置：ドメイン直下の /llms.txt（例：company.com/llms.txt）
- H1見出し：サイト名または会社名。仕様上、唯一の必須項目
- 引用ブロック：会社を要約する1〜2文
- H2セクションとリンク一覧：[ページ名](URL): 説明、の形式で重要ページを列挙
- Optionalセクション：コンテキストが足りないとき省略できる補助リンク
文書量の多いサイトでは、全内容を一つにまとめたllms-full.txtも置きます。一般的な企業サイトならそこまでは不要で、会社紹介の一文、サービスページ、代表実績、問い合わせ先を含む20〜30行で十分です。
llms.txtの現在地を率直に見る
まだ公式標準ではありません。OpenAIやGoogleはllms.txtを参照すると公表しておらず、GoogleのJohn Muellerも、過去のkeywordsメタタグになぞらえて懐疑的な見方を示しています。
それでもAnthropicの技術文書を含め、開発者向けドキュメントサイトを中心に採用が増えています。作成コストは低く、実質的な副作用もありません。効果が完全に証明されるまで待つより、今のうちに公開する方が現実的です。
5.2 AIクローラーを拒否するか、許可するか
企業サイトなら、多くの場合は「許可する」が答えです。報道機関や有料コンテンツ事業者には学習用収集を拒否する理由がありますが、会社紹介やサービス説明は広く引用されるほど価値が高まる情報です。まず、どのクローラーが訪れるのかを把握しましょう。
- GPTBot — OpenAIのモデル学習用クローラー
- OAI-SearchBot — ChatGPT検索結果への掲載に使われるインデックス用クローラー
- ChatGPT-User — ユーザーが会話中にページを要求したときのリアルタイムアクセス
- ClaudeBot / Claude-User — Anthropicの学習用クローラー／リアルタイム回答用アクセス
- PerplexityBot — Perplexityの検索インデックス用クローラー
- Google-Extended — Geminiの学習利用を制御するrobots.txtトークン。拒否してもGoogle検索順位には影響しません
- CCBot — 非営利のCommon Crawlによる収集クローラー。複数のAIモデルがそのデータを学習に利用します
判断基準は一つです。OAI-SearchBot、ChatGPT-User、PerplexityBotなど検索・リアルタイム系を拒否すると、AI検索で引用される候補から外れます。AIの回答に出たいなら許可すべきです。GPTBot、ClaudeBot、CCBotなど学習用クローラーは方針次第ですが、コンテンツ自体が商品でなければ、拒否して得られるものは多くありません。robots.txtではUser-agentごとに設定できるため、まず現在の扱いを確認してください。Disallow: / による全面拒否を残したまま忘れているサイトは意外に多くあります。
6. 企業サイトのAEO実行計画
実行は5段階です。前段階の成果物が次の材料になるため、順序を守ることが重要です。
ステップ1 — 会社紹介文を統一する
まず「自社を一文でどう説明するか」を決めます。業種、対象顧客、差別化要因を含む事実ベースの文章にします。「顧客価値を最優先するグローバル革新企業」といった表現は、人にもAIにも有用な情報を与えません。「中堅製造業向けMES構築12年、累計80ラインに導入」の方が引用されます。決めた文はトップページ、会社概要、フッター、Naver Place、求人情報、プレスリリースの定型文まで同じものを使います。AIは複数の情報源で繰り返される一貫した説明を信頼します。
ステップ2 — スキーママークアップを実装する
ステップ1で決めた文章と会社情報をOrganizationスキーマに入れ、各サービスページにServiceスキーマを追加します。外部の開発会社へ依頼するなら、「JSON-LD形式で実装し、Googleリッチリザルトテストに合格した画面を検収資料として提出してください」と伝えます。検収基準まで要件に含めることで、形式だけの対応を防げます。
ステップ3 — FAQを構造化する
営業面談やサポート窓口で実際に受けた質問を10件選びます。回答は各2〜4文とし、最初の文で結論を示します。ページとして公開し、FAQPageスキーマを接続します。作った質問より実際の質問の方が、見込み客がAIへ入力する表現に近いため効果的です。
ステップ4 — llms.txtを公開する
第5章の形式で作成し、ドメイン直下に配置します。サービス構成が変わったら更新し、少なくとも四半期に一度は見直します。ステップ1の紹介文をここでも利用します。
ステップ5 — AIの回答を監視する
月に一度、同じ質問をChatGPT、Claude、Perplexity、Geminiに入力し、回答を記録します。
- 「この分野に強い韓国企業を推薦して」— 自社が候補に入るか
- 「（会社名）はどのような会社？」— 事実と異なる説明がないか
- 「（会社名）と（競合）を比較して」— 何を根拠に比較しているか
誤った回答の多くは、必要な情報がサイトにない、または曖昧であることが原因です。AIそのものを修正することはできないため、元の情報を補強します。GA4でchatgpt.comやperplexity.aiからの参照流入を確認すれば、AI経由の訪問推移も把握できます。
無料で使える3つの検証ツール
Googleのリッチリザルトテスト（search.google.com/test/rich-results）でスキーマの認識を、Schema.org Validator（validator.schema.org）で構文エラーを、Search Consoleでインデックス状況を確認します。すべて無料です。
リニューアルを発注するなら、見積もり段階で「構造化データとllms.txtは含まれますか」と尋ねてください。項目自体を知らない制作会社に、本格的なAI検索対策を期待するのは難しいでしょう。
7. 結論とチェックリスト
企業サイトの読者が一人増えました。人、検索エンジン、そしてAIです。3番目の読者はデザインを見ません。テキストとデータだけを読み、読んだ内容だけを伝えます。この記事で扱ったのは、その読者を迎えるための準備です。
最終チェックリスト
- 紹介文の統一：会社を説明する一文が、サイトと外部チャネルのどこでも同じか
- スキーママークアップ：Organization・ServiceをJSON-LDで実装し、リッチリザルトテストに合格しているか
- FAQの構造化：実際の顧客質問に基づくFAQがあり、FAQPageスキーマと接続しているか
- llms.txt：ドメイン直下に公開し、現在のサービス構成を反映しているか
- クローラー方針：robots.txtがOAI-SearchBotなどAI検索クローラーを拒否していないか
- 監視ルーティン：月1回、主要AIに自社について尋ね、回答を記録しているか
6項目のどれにも該当しなくても不思議ではありません。韓国の企業サイトの多くが同じ状態です。逆に言えば、先に整えた会社が当面、その分野のAI回答を獲得できます。競合がこの記事を読む前に始めましょう。