はじめに——「全エンジン共通の万能施策」という前提が、2026年に崩れた
これまでのAEO（Answer Engine Optimization）記事では、llms.txt 2.0やパッセージ単位の最適化、FAQ構造化といった「個別施策のやり方」を一つずつ解説してきました。しかし2026年5月、その前提を揺るがす公式アナウンスが出ました。
Googleは2026年5月15日、「Optimizing your website for generative AI features on Google Search（生成AI検索機能向けの最適化ガイド）」を公開し、そのmyth-busting（神話の打破）セクションで、llms.txt・コンテンツのチャンキング・特殊なスキーマ・AI向けの書き換えは、AI OverviewやAI Modeに出るために不要だと名指しで断言しました。さらに6月15日には「Clarifying guidance on llms.txt files」として、llms.txtは検索の表示順位に「害もなければ益もない」と追記しています。
ここで重要なのは、この指針はあくまで「Google検索」に限定された話だという点です。AI OverviewやAI Modeは従来のGoogle検索インデックスから情報を引くため、SEOの延長線上にあります。一方で、ChatGPTやPerplexityといった非Googleプラットフォームはシグナルの重み付けが異なり、Googleの「不要」宣言がそのまま当てはまるわけではありません。つまり——
「ある施策が全エンジンで効く」という前提が崩れ、施策はエンジン別に効果を検証する時代に入った。
筆者はネットワークのNOC／TAC（運用監視・テクニカルアシスタンス）で長年、ベンダーの公式アナウンスを鵜呑みにせず、設定変更の効果を自分の環境のログで実測してきました。本記事の核心は、その発想をAEOに転用することです。すなわち——AEO施策を「config（設定）変更」とみなし、推測ではなく、クローラー到達ログと引用有無という「実測値」で効く/効かないを切り分ける。これが、工数を浪費しないための運用思想です。
本記事は、これまで解説してきた個別施策（728／756／356…）を横断し、「どの施策がどのエンジンで効くのか」を再評価する“棚卸し”兼“意思決定”ガイドです。施策を一通り実装したものの「結局どれが効いているのか分からない」状態の方に向けて、投資の優先順位を整理します。
想定読者：施策を一通り実装したオウンドメディア担当・AEOコンサル・情シス兼任マーケ。限られた工数を、本当に効くものに集中させたい方。
前提崩壊：Googleの公式myth-bustingで何が変わったか
まず、Googleが「不要」と名指しした施策と、「重要」と再確認した要素を整理します。これがエンジン別仕分けの出発点になります。
Googleが「不要」と断言した4つの施策
- llms.txt・特殊なマークアップ：AI検索に出るために、機械可読ファイルやAI専用テキストを作る必要はない。Google検索はそれらを使わない（作っても害も益もない）。
- コンテンツのチャンキング：AIが理解しやすいよう、コンテンツを細切れに分割する必要はない。Googleのシステムは1ページ内の複数トピックを理解し、関連箇所を抽出できる。
- AI向けの書き換え：生成AI向けに特殊な文体で書く必要はない。AIは同義語や一般的な意味を理解する。ロングテールの語句バリエーションを網羅する必要もない。
- 特殊なスキーマ：生成AI検索のために追加すべき特別なschema.orgマークアップは存在しない（構造化データはリッチリザルト用途としては引き続き有用）。
逆にGoogleが「重要」と再確認した3つの軸
- 非コモディティ・コンテンツ（non-commodity content）：誰でも書ける一般論ではなく、一次体験・独自データ・固有の視点を持つコンテンツ。Googleは「7 Tips for First-Time Homebuyers」のような汎用記事と、「なぜ我が家は住宅検査を省いて費用を節約したか」のような実体験記事を対比している。
- マルチモーダル資産：関連性の高い高品質な画像・動画。
- テクニカルな健全性：クロール可能・インデックス可能であること。要するに従来SEOの基礎。
NOC／TAC的に言えば、これは「ベンダーが“この設定はもう要りません”と公式リリースノートに書いた」状態です。リリースノートは尊重すべきですが、自分の環境（＝対象エンジン）で同じ挙動が再現されるとは限らない——だからこそ、次に「エンジン別の差」を見ます。
なぜエンジン別に効果が分かれるのか——アーキテクチャの違い
「同じ施策なのにエンジンによって効果が違う」のは、感覚論ではなく、各エンジンの情報取得アーキテクチャが構造的に異なるためです。ネットワーク機器でも、同じconfigがベンダー／OSバージョンによって挙動を変えるのと同じです。
| エンジン | 情報源の中心 | 引用が決まる主な要因 | 施策が効く経路 |
|---|---|---|---|
| Google AI Overview / AI Mode | Google検索インデックス（既存） | 従来のランキングシグナル＋抽出可能性 | SEOの延長。AI専用ファイルは経由しない |
| Perplexity | リアルタイムのWeb検索＋クロール | その場で取得したページの構造・明快さ | 取得時に解釈しやすい構造が効きやすい |
| ChatGPT（検索連携） | 連携検索＋学習データ | 第三者プラットフォーム上の言及・権威性 | 外部での言及・エンティティ一貫性が効きやすい |
| Claude等のエージェント／開発者文脈 | 学習データ＋エージェント取得 | 構造化された取得しやすさ（文書サイト等） | llms.txt等が“agent-readiness”として機能する場面あり |
この表から導かれる結論はシンプルです。
- Google向け：llms.txtやチャンキングは経路上、効きようがない。SEOの基礎と非コモディティ性に投資する。
- Perplexity向け：その場のクロールで解釈されるため、見出し・段落構造・明快な主張といった「取得時の読みやすさ」が相対的に効きやすい。
- ChatGPT向け：第三者サイト（Reddit・YouTube・Wikipedia等）での言及やエンティティの一貫性が、引用される確率に効きやすい。
- エージェント文脈：llms.txtは「Google検索のランキング」には無関係でも、エージェントがサイト構造を素早く把握する助けとして価値が残る場面がある（実際、ChromeのLighthouse 13.3はAgentic Browsing監査でllms.txtの有無をチェックし始めた。Anthropicもエージェント向け文書でllms.txtを推奨している）。
つまりllms.txtは「死んだ施策」ではなく、「目的（対象エンジン）が変われば評価が変わる施策」です。Googleのランキング目的では不要、エージェント可読性の目的では有効——この使い分けが本記事の肝です。
施策仕分けマトリクス——施策 × エンジン × 効果の確度
個別施策を、エンジン別の効果の確度で棚卸しします。◎＝効く確度が高い／○＝条件付きで有効／△＝限定的・状況次第／×＝効果は見込みにくい（Google公式が不要と明言、等）。
| 施策 | Google AIO/AIM | Perplexity | ChatGPT | エージェント文脈 |
|---|---|---|---|---|
| llms.txt（?p=728） | ×（公式に不要） | △ | △ | ○（agent-readiness） |
| チャンキング（細断） | ×（公式に不要） | △ | △ | △ |
| AI専用の特殊スキーマ | ×（公式に不要） | △ | △ | △ |
| AI向けの文体書き換え | ×（公式に不要） | △ | △ | △ |
| パッセージ単位の明快な構造（?p=756） ※チャンキングとは別物 | ○ | ◎ | ○ | ○ |
| answer-first（結論先出し）構成 | ◎ | ◎ | ◎ | ○ |
| エンティティの明確化・一貫性 | ◎ | ◎ | ◎ | ○ |
| E-E-A-T／一次体験・独自データ（非コモディティ） | ◎ | ◎ | ◎ | ○ |
| 第三者プラットフォームでの言及 | ○ | ○ | ◎ | △ |
| マルチモーダル資産（独自画像・動画） | ◎ | ○ | ○ | △ |
| FAQ構造化（?p=356） | ○（リッチリザルト用途） | ○ | ○ | ○ |
注意すべき混同：「チャンキング（×）」と「パッセージ単位の明快な構造（◎）」は別物です。Googleが否定したのは“AIのために不自然に細切れにする”操作であって、見出し・焦点の定まったセクション・明快な主張といった「人間にも機械にも読みやすい設計」は引き続き全エンジンで有効です。この線引きを誤ると、「Googleが構造化を否定した」と過剰解釈して、本来効く普遍施策まで捨ててしまいます。
“効かない可能性”が高い施策と、なお有効な「普遍施策」
投資を絞る（または止める）候補
Google検索が主戦場で、かつ工数が逼迫しているなら、以下は優先度を下げてよい候補です。
- Googleのためだけのllms.txt整備：Google公式が「ランキングに無関係」と明言。ただしエージェント経由の流入が意味を持つ文書サイト・APIリファレンスなら別途検討の価値あり。
- 過剰なチャンキング：コンテンツを不自然に断片化する作業。読みやすさを損なうなら逆効果。
- AI向けの不自然な文体書き換え：定義過多・機械的な言い回しへの全面リライト。
- 不自然な言及の量産（inauthentic mentions）：Googleが明確に否定。スパム判定リスクすらある。
エンジンを問わず効く「普遍施策」
逆に、どのエンジンでも効果の確度が高い——つまり“安全資産”として優先投資すべき施策は以下です。
- answer-first：各セクション冒頭で結論を1〜2文で言い切る。抽出・引用のしやすさに直結。
- エンティティの明確化・一貫性：固有名詞・主体・関係性を曖昧にしない。サイト全体で表記を統一する。
- E-E-A-T／非コモディティ・コンテンツ：一次体験・独自データ・固有の視点。Googleが最も強調した差別化要因であり、ChatGPT・Perplexityでも引用されやすさの土台になる。
- 明快な情報構造：記述的な見出し、焦点の定まった段落、根拠の提示。人間にも機械にも読める設計。
- テクニカルな健全性：クロール可能・インデックス可能・表示が安定（CLS）。
NOC／TAC的に言えば、これらは「どのベンダー機器でも通用する標準プロトコル」に相当します。ベンダー固有のオプション（＝エンジン固有のハック）に賭ける前に、まず標準プロトコルを固める——それが投資効率の鉄則です。
自分で検証する方法——「クローラー到達 × 引用有無」のA/B
ここが本記事で最も実践的なパートです。ベンダー（各AIプラットフォーム）の言い分を鵜呑みにせず、自分のドメインで実測する。NOCがトラフィックを実ログで確認するのと同じ要領です。検証は2つのレイヤーに分けます。
レイヤー1：クローラー到達ログ（インフラ層の実測）
施策が「そもそも取得されているか」をサーバーログで確認します。引用の前提は「取得されること」だからです。
- 見るもの：サーバーのアクセスログ／CDNログのUser-Agent。
OAI-SearchBot・PerplexityBot・ChatGPT-User・Google-Extended等のAI関連クローラーが、対象URLに到達しているか。 - 確認できること：例えばllms.txtを設置した後、そのファイルに実際にボットがアクセスしているか。アクセスが皆無なら、その施策はそのエンジンに対して「経路上、効いていない」と切り分けられる。
- NOC視点：これは「pingが返るか」のレイヤー。到達していない施策に効果を期待するのは、リンクダウンした経路でトラフィックを待つのと同じ。
レイヤー2：引用有無のA/B（アウトカム層の実測）
到達が確認できたら、次は「引用されたか」を測ります。これはShare of Model（?p=776）やCitation Decay監視（?p=782）で扱った計測手法と接続します。
- 方法：同種のクエリ群を用意し、施策を適用したページ群（A）と未適用のページ群（B）で、各エンジンの回答に自社が引用される頻度を一定期間比較する。
- 記録項目：対象エンジン／対象クエリ／施策の有無／引用された回数／引用された箇所（どの段落か）／観測日。これを改ざんしにくい形でログ化する。
- 判定：「適用群の引用率が、有意に・継続的に高い」ときのみ、その施策をそのエンジンで“効く”と確定する。一度の偶然で判断しない（Citation Decayの観点で、引用は揺らぐ前提）。
本サイトで繰り返し述べてきた思想——「推測ではなくログで語る」——を、AEOにそのまま適用したものです。ベンダーの公式アナウンス（Googleの「不要」宣言）も、この2レイヤーで自分の環境において再検証して初めて、自社の運用ルールに昇格させられます。
投資の優先順位づけ——工数を「効くもの」に寄せる
以上の仕分けと実測を踏まえ、限られた工数の配分指針を示します。優先度の高い順です。
- 普遍施策を最優先で固める：answer-first・エンティティ一貫性・非コモディティ性・明快な構造・技術的健全性。全エンジン共通で効くため、投資対効果が最も高い。
- 主戦場エンジンを1つ決め、そこに固有施策を寄せる：流入・コンバージョンの実態から、Google／Perplexity／ChatGPTのどれが自社の主戦場かを特定し、そのエンジン固有の効きやすい施策（例：ChatGPTなら第三者言及）に集中。
- “効かない候補”は止めるか、目的を限定する：Google目的のllms.txtや過剰チャンキングは、エージェント可読性など明確な別目的がある場合のみ残す。
- 実測ループを常設する：クローラー到達ログ＋引用A/Bを定常運用にし、四半期ごとに仕分けマトリクスを更新する。エンジンのアルゴリズムは変わるので、仕分けは“一度きり”にしない。
NOC／TAC的に言えば、これは「ベースラインを学習し、逸脱を監視し続ける」運用そのものです。一度設定して終わりではなく、リリースノート（各社の公式アナウンス）を監視しつつ、自環境のログで継続的に検証する。それがAEOの“枯れない”運用設計です。
仕分け・運用チェックリスト
| フェーズ | 確認項目 | 判定の根拠 |
|---|---|---|
| 棚卸し | 実装済み施策を「普遍／エンジン固有／効かない候補」に分類したか | 仕分けマトリクス |
| 主戦場特定 | 自社の主戦場エンジンを流入実態から1つ特定したか | アクセス解析・流入元 |
| 到達確認 | 各施策に対象ボットが実際に到達しているか（ログ確認） | サーバー／CDNログのUA |
| 引用確認 | 施策適用群の引用率が未適用群より有意に高いか | 引用A/B・Share of Model |
| 普遍施策 | answer-first・エンティティ一貫性・非コモディティ性を満たすか | 編集チェック |
| 停止判断 | Google目的のllms.txt等を、別目的がないのに維持していないか | 目的×エンジンの対応 |
| 定常監視 | 四半期ごとに仕分けを更新し、各社アナウンスを追っているか | 運用ループ |
よくある質問（Q&A）
Q1. Googleが「llms.txtは不要」と言ったので、もう作らなくていいですか？
「Google検索のランキング目的」であれば、作らなくて問題ありません。Google公式が、害も益もないと明言しています。ただし、Claude・OpenAIのエージェントや、API/開発者文書サイトのように、エージェント経由の到達が意味を持つ場合は別です。ChromeのLighthouseがllms.txtの有無を監査項目に加えるなど、エージェント可読性の文脈では価値が残ります。「Google向けには不要、エージェント向けには検討」と目的で切り分けてください。
Q2. 「チャンキングは不要」なら、見出しで区切るのもやめるべきですか？
いいえ、それは混同です。Googleが否定したのは「AIのために不自然にコンテンツを細断する操作」であって、見出し・焦点の定まったセクション・明快な主張という“人間にも読みやすい構造”は引き続き全エンジンで有効です。むしろPerplexityのようにその場でクロールするエンジンでは、明快な構造の効果が相対的に高くなります。
Q3. Google向けと非Google向けで、施策を完全に分けるべきですか？
分ける必要はありません。土台は共通（普遍施策）、その上に主戦場エンジン向けの固有施策を“足す”のが効率的です。answer-first・エンティティ一貫性・非コモディティ性はどのエンジンでも効くため、まずここに投資し、余力を主戦場エンジンに寄せます。
Q4. 効果検証に高価なツールは必要ですか？
必須ではありません。第一歩はサーバー／CDNのアクセスログでAIボットの到達を確認することで、追加コストはほぼかかりません。その上で、主要エンジンの回答に自社が引用されるかを定点観測すれば、無料〜低コストでも仕分けは始められます。専用ツールは規模が大きくなってからで十分です。
Q5. アルゴリズムが変わったら、この仕分けは無駄になりませんか？
仕分け“結果”は変わり得ますが、仕分け“手法”（目的×エンジンで分け、ログと引用で実測する）は陳腐化しません。だからこそ本記事は、特定の施策の良し悪しを固定するのではなく、四半期ごとに更新する運用ループとして設計しています。NOCが機器を入れ替えても監視の作法が変わらないのと同じです。
まとめ——AEOは「config変更」、評価は「ログ」で
2026年5月のGoogle公式myth-bustingは、AEOの世界に「エンジン別に効果を検証する」という当たり前を突きつけました。要点は3つです。
1. 「全エンジン共通の万能施策」は存在しない。Googleが「不要」と言った施策も、対象がPerplexity・ChatGPT・エージェントに変われば評価が変わります。施策は必ず「どのエンジンに対してか」とセットで考えます。
2. 普遍施策に最優先投資する。answer-first・エンティティ一貫性・非コモディティ性・明快な構造・技術的健全性は、どのエンジンでも効く“標準プロトコル”。エンジン固有のハックに賭ける前に、ここを固めます。
3. 推測ではなくログで語る。ベンダーの公式アナウンスすら、クローラー到達ログと引用A/Bで自環境において再検証する。AEO施策を「config変更」とみなし、効く/効かないを実測で切り分ける——これがNOC/TAC流の、工数を浪費しないAEO運用です。
個別施策の“やり方”はllms.txt 2.0・パッセージ単位AEO・FAQ構造化へ、計測の“測り方”はShare of Model・Citation Decay監視へ。本記事はそれらを束ね、「結局どれに投資すべきか」を決めるためのハブとして使ってください。
参考リンク
- Google「Optimizing your website for generative AI features on Google Search」（公式ガイド）
- Search Engine Journal「Google’s New AI Search Guide Calls AEO And GEO ‘Still SEO’」
- Search Engine Land「Google adds llms.txt check to Chrome Lighthouse」
免責事項：本記事は2026年6月時点の公開情報および各プラットフォームの公式アナウンスに基づく一般的な情報提供であり、特定のサイト・施策における効果を保証するものではありません。AI検索エンジンのアルゴリズムや各社のガイドラインは頻繁に更新されるため、最新情報は各公式ソースでご確認ください。施策の採否は自社の主戦場エンジン・運用体制・実測結果に照らして判断してください。
コメント