AIO対策・LLMO対策で自社サイトにやったこと【2026年】

AIO対策・LLMO対策とは、GoogleのAIによる概要やChatGPT検索に自社のページを正しく読ませ、引用されやすくする取り組みです。僕の会社は2026年9月、自社サイトに構造化データ、FAQ16問、H1直下の結論、IndexNowによるBingへの即時通知を入れました。やったこととやらなかったことを書きます。

AIO対策・LLMO対策・GEO対策とは？呼び方の違いはあるのか

3つとも中身はほぼ同じで、「AIが答えを作るときに、自社のページを読んで引用してもらえる状態にすること」です。名前が強調している点が違うだけです。Googleも特別な最適化は不要としていて、やることの大半は、これまでのSEOの基本を丁寧にやり直す作業になります。

AI検索とは、検索した人に対してリンクの一覧ではなく、AIが複数のページを読んでまとめた文章で答えを返す検索の形です。Googleの「AIによる概要」とAIモード、ChatGPTの検索機能、Perplexityなどがこれにあたります。

AIO対策とは、AI検索の答えの中で自社のページが根拠として使われ、リンク付きで紹介されるようにページを整える取り組みです。LLMO対策も同じ意味で使われることが多く、AIの土台になっている大規模言語モデル（LLM）を名前に入れているかどうかの違いです。

GEOという言葉は、2023年11月に公開された研究論文「GEO: Generative Engine Optimization」が広まるきっかけになりました。インド工科大学デリー校やプリンストン大学の研究者らによる論文で、生成AIの検索エンジン向けに、ページの書き方で引用のされやすさがどう変わるかを調べています。

ここで先に押さえておきたいのが、Google自身の説明です。Googleの検索セントラルの「AI 機能とウェブサイト」には、AIによる概要やAIモードに表示されるために追加の要件はなく、特別な最適化も必要ない、と書かれています。通常の検索で評価されるための基本が、そのままAI機能にも当てはまるという立場です。同じページには、AI向けのテキストファイルや新しいマークアップを作る必要はない、という記述もあります。

さらに2026年5月には「Google 検索の生成 AI 機能向けにウェブサイトを最適化する」というガイドが別に公開されました（2026年9月23日更新）。ここでは、生成AI検索に構造化データは必要ない、生成AI向けの特別な書き方も不要、コンテンツを細かく分割する必要もない、と言い切っています。代わりに勧めているのは、一般的な知識の範囲を超えた、自分の経験や専門性に基づく独自性のあるコンテンツです。

なので僕の会社では、「AI専用の裏ワザ」を探すのはやめました。やったのは、検索エンジンにもAIにも誤解されずに読まれるページにすることです。具体的には、機械が読める形で会社とページの情報を渡すこと、答えを文章の最初に置くこと、新しいページができたらすぐ知らせること、の3つです。

AI検索はどこから答えを持ってくるのか

GoogleのAIによる概要は、Googleの検索で集めたページをもとに答えを組み立てます。一方ChatGPTの検索について、OpenAIは「他の検索プロバイダーと提携することがある」と説明し、ヘルプからMicrosoftのプライバシー声明へリンクしています。僕の会社ではBingを有力な情報源と見て、GoogleとBingの両方にページが早く登録されるようにしました。

インデックスとは、検索エンジンが集めたページの情報を整理して保存しているデータベースのことです。ここに登録されていないページは、どれだけ内容が良くても検索結果にもAIの答えにも出てきません。

もう1つ確認すべきなのがクローラーです。クローラーとは、検索エンジンやAIの会社がWebページを自動で巡回して読み取るプログラムのことです。OpenAIは、ChatGPTの検索機能でサイトを表示するためのクローラーとしてOAI-SearchBotを公開しています。robots.txtでこれを拒否したサイトは検索の回答に出ない（リンクの一覧としてなら出ることはある）、とOpenAI自身が書いています。あわせて、サーバーやCDNがOpenAIの公開しているクローラーのIPアドレスからの通信を遮断していないことも条件に挙げています。自社サイトのrobots.txtは一度確認しておくべきです。

urakata.bizで実際にやったことは？早見表

2026年9月7日に、自社サイトurakata.biz の本体10ページとコラム7ページへ、まとめて手を入れました。外部のSEOチェックツールで出た指摘を起点に、本物の指摘と誤検出を仕分けし、本物だけを直しています。AI検索に関係が深いのは、構造化データ、FAQ、見出しと結論の位置、検索エンジンへの即時通知の4つです。

僕の会社にエンジニアはいません。この作業はすべてClaude Codeに指示を出して実装と検証をさせ、チェックツールの画面を共有した当日のうちに本番へ反映しました。

構造化データは何を入れた？@graphの中身と、入れなかったもの

構造化データとは、ページの内容を検索エンジンが誤解なく読み取れるよう、決まった形式で書き添える情報のことです。本体ページには会社・サイト・ページ・階層の4種類を @graph でまとめ、コラム記事にはArticleとFAQPageなどを出しています。記事でないページにArticleは付けていません。

本体ページは@graphで1つにまとめた

2026年9月7日の診断では、トップページの構造化データはOrganizationが1つだけでした。会社の情報はあっても、それがどのサイトのどのページなのかという関係が機械には伝わっていない状態です。

そこで、本体10ページすべてのJSON-LDを @graph 方式に統一しました。JSON-LDとは、構造化データをページの中にJSONという形式でまとめて書き込む方法です。@graph は、複数の情報を1つのまとまりとして書き、互いを参照させる書き方です。

サイト内検索の機能がないので、WebSiteに検索窓の情報（SearchAction）は入れていません。ない機能を構造化データで「ある」と書くのは、検索エンジンに嘘をつくことになるからです。

コラム記事はArticleとFAQPageを自動で出す

コラム記事は、Markdownで書いた原稿から自前のプログラムでHTMLを作っています。その時点で、Article、BreadcrumbList、そしてFAQがある記事にはFAQPageの構造化データが自動で入るようにしました。Articleには、見出し、説明文、公開日、最終更新日、著者（僕の名前とプロフィールページ）、発行元の会社とロゴが入ります。

ここで1つ失敗がありました。2026年8月6日、最初の4記事を公開する直前に確認したところ、FAQPageの構造化データが4本とも0件だったのです。本文には手書きの「よくある質問」がありましたが、プログラムは原稿冒頭の設定欄（フロントマター）にFAQがあるときだけFAQPageを出す作りでした。FAQを設定欄へ移して計19問を入れ直し、4本すべてにFAQPageが出ていることを確かめてから公開しました。

教訓は、仕組みを作っても出力を実際に見て確認しないと、肝心の部分が抜けたまま公開されることです。いまは公開前の自動チェックで、Article・BreadcrumbList・FAQPageがそろっているか、そして構造化データがJSONとして壊れていないかを毎回確かめています。

FAQPageは表示のためではなく読み取りのために入れる

FAQPageの構造化データを入れても、検索結果でFAQが展開表示されることはありません。Googleは2023年9月に表示対象を政府や健康分野の信頼できるサイトに絞り、2026年5月7日からはFAQのリッチリザルトそのものを表示しなくなりました。2026年6月には、FAQPageの説明ページも公式ドキュメントから削除されています。

Googleの生成AI最適化ガイドも、生成AI検索に構造化データは必要ないと明言しています。それでも入れたままにしているのは、質問と答えの組を、機械が確実に読める形で渡せるからです。質問と答えが対になって明示されたページは、AI検索にとって扱いやすいはずだと考えました。ただし、これは引用を約束するものではありません。あくまで読み取りの正確さを上げるための作業です。

大事なルールは、構造化データに書いた内容を必ずページにも表示することです。Googleのガイドラインでも、ページを見た人に見えない内容をマークアップしてはいけないとされています。僕の会社では、FAQは画面にも同じ文面で表示しています。

本文はどう書き換えた？H1直下の結論と質問形の見出し

構造化データより効くと考えているのが、本文の書き方です。AI検索は、ページの中から質問の答えになる一節を抜き出して使います。そこで、H1の直下に記事全体の結論を120〜160字で置き、見出しの半分以上を質問の形にして、見出しの直後に100〜180字の直答を書く、というルールにしました。

結論を最初の1段落に置く

H1とは、ページで一番大きな見出しで、そのページが何についてのページかを示すものです。その直下に記事全体の答えを1段落で書き、その段落だけで結論が分かるようにしています。

見出しを質問にして、直後に答えを書く

見出しは、検索する人が実際に打ち込みそうな質問の形にしています。「料金はいくら？」「何が違う？」「どう使い分ける？」といった形です。その見出しの直後には、前後の文脈がなくても意味が通る直答を書きます。Googleは生成AI向けの特別な書き方は不要としていますが、質問の直下に答えがある構成は、人が読むときにも分かりやすい書き方です。

もう1つ意識しているのが、定義の文です。「〇〇とは、〜です。」という形の文を、1記事に5本以上入れるルールにしています。この記事でも、AI検索、AIO対策、インデックス、クローラー、構造化データ、JSON-LDなどを、その形で書いています。AIが用語を説明するときに、そのまま引用しやすい形だからです。

FAQは「本文に書いていない周辺の疑問」を拾う

本体ページには、トップに6問、サービスページに6問、お問い合わせページに4問のFAQを置きました。コラム記事には、1本あたり4〜5問を入れています。

FAQで気をつけているのは、本文の要約を繰り返さないことです。本文で書ききれなかった、読者が次に検索しそうな疑問を拾うようにしています。お問い合わせページのFAQなら、「返信はいつ来るか」のように、サイトにすでに書かれている事実だけを答えにしました。採用ページにもFAQを置きたかったのですが、選考の流れなど確定していない情報が多く、保留にしています。

IndexNowでBingへ即通知するのはなぜか？

IndexNowとは、ページを追加・更新・削除したときに、そのURLを検索エンジンへすぐ知らせるための共通の仕組みです。Bing、Naver、Seznam.cz、Yandex、Yep、Amazonが参加し、1か所に送れば参加エンジン同士で共有されます。ChatGPT検索がGoogle以外の検索サービスも使う以上、Bingへの早い登録が近道だと判断しました。

公開手順の最後に自動で通知する

僕の会社では、2026年8月24日にNEWSの公開手順へIndexNowを組み込みました。コラムも同じ形で、原稿を公開する処理の最後に、更新したURLをまとめてIndexNowへ送ります。人間が手で送る作業はありません。

サイトのルートに、自分で決めた鍵の文字列を書いたテキストファイルを置いておきます。検索エンジンはそのファイルで、サイトの持ち主からの通知かを確かめます。

2026年9月7日の改修では、本体とコラムの17URLを送り、受理を示すHTTP 202が返りました。2026年10月1日のコラム修正の反映でも、送信は正常に完了しています。Bing Webmaster Toolsへのサイト登録はまだですが、IndexNowの送信自体は登録がなくても受け付けられています。

GoogleにはIndexNowが届かない

注意点は、IndexNowの参加検索エンジンの一覧にGoogleが入っていないことです。Googleに新しいページを早く見つけてもらうには、Search ConsoleのURL検査からインデックス登録をリクエストし、サイトマップを最新にしておく必要があります。

僕の会社では、サイトマップは記事の公開と同時に自動で作り直しています。URL検査だけは画面での手作業なので、公開後の作業として手順書に残しています。

SEOチェッカーの指摘は全部直すべきか？誤検出の扱い

全部直す必要はありません。僕の会社が使った外部のSEOチェックツールは、12項目の指摘のうち2つが誤検出で、さらに2つは「そのページには不要なもの」を要求していました。指摘をそのまま全部潰そうとすると、記事でないページに記事の情報を書くなど、検索エンジンに嘘をつく修正が入ってしまいます。

本物の指摘と誤検出を仕分けた結果

2026年9月7日に、トップページの診断結果を1項目ずつ確かめた結果がこちらです。

HSTSとは、そのサイトには必ず暗号化された通信（HTTPS）で接続するようブラウザに指示する設定です。メディアクエリとは、画面の幅に応じてデザインを切り替えるためのCSSの書き方です。

誤検出でも、正当な方法なら潰した

誤検出でも、実害なく潰せる方法が見つかったものは対応しています。

ロゴの「空のアンカー」は、画面には見えないスクリーンリーダー用の文字を足して解消しました。読み上げはaria-labelが優先されるので影響はありません。メディアクエリは、表示の最初に必要なCSSをHTMLの中に直接置き、その中に実際に使う画面幅の切り替えを入れました。外部CSSが届く前にレイアウトが崩れるのを防ぐ効果もあり、ツールのためだけの小細工にはしていません。

取らない減点は理由ごと決めておく

自前の監査（64点満点）では、コラム記事は満点、ニュース一覧やサイトマップのページは52点のままです。一覧ページなので本文が短く、文字数で減点されています。ここを薄い文章で水増しすると、かえって検索の評価を落とすと考え、減点を受け入れました。トップページにパンくずを置かない、記事でないページにArticleを付けない、表にするデータがないページに表を作らないのも同じ理由です。

チェックツールは見落としを探す道具であって、点数が目的になると判断を誤ります。

やらなかったこと、まだ分かっていないことは？

やらなかった一番大きなものは、llms.txtです。llms.txtとは、サイトの概要と主要ページの一覧をAI向けにまとめ、サイトのルートに置くテキストファイルの提案です。主要な検索エンジンが読んでいると確認できず見送りました。そしてまだ分かっていないのが成果で、AI検索に何回引用されたかの実測はまだありません。

llms.txtは効果が確認できるまで後回しにする

llms.txtは、2024年9月にJeremy Howard氏が提案した仕様で、2026年10月時点でも公式サイト上の位置づけは「提案」です。考え方は分かりやすく、作るのも難しくありません。それでも見送ったのは、AI検索の答えに影響するという確認ができなかったからです。Googleは「AI 機能とウェブサイト」と、2026年9月23日更新の生成AI最適化ガイドの両方で、AIテキストファイルを新たに作る必要はないと明言しています。提案者のサイトにはAI各社の開発者ドキュメントなどの採用例が載っていますが、検索エンジンが回答の生成に使っていると確認できる材料は見つかりませんでした。

僕の会社のような小さなサイトにとって、一番の制約は時間です。効果が確認できない施策に時間を使うより、記事の中身を厚くするほうが確実だと判断しました。検索エンジンが読むと公式に分かった時点で入れれば十分です。

AI専用のページや隠しテキストは作らない

ほかにも、意図的にやっていないことがあります。AI向けにだけ見せる別ページを作ること、画面に見えない場所に質問と答えを大量に埋め込むこと、構造化データにページにない内容を書くことです。

どれも検索エンジンのガイドラインに反するおそれがあります。読者に役立つページと、AIに引用されるページは、同じであるべきだと考えています。

成果はどう測るか

正直に書くと、2026年10月時点で「この施策でAI検索に何回引用された」という実測はまだありません。コラムのAIメディアとしての本格運用は2026年10月に始めたばかりで、計測の仕組みもこれからです。この記事は成果の報告ではなく、何をなぜやったかの記録です。

測り方としては、次の3つを予定しています。

1つ注意があります。Search ConsoleではAIによる概要に表示された分だけを切り分けて見ることはできず、通常の「ウェブ」検索の数字に含まれます。なので「AI経由で何回出たか」を正確に数えることは、今のところ難しいです。

結果が出たら、この記事を更新して数字を追記します。

構造化データやIndexNowの考え方は、自社サイトだけでなく、僕の会社で制作するLPやホームページにも最初から入れるようにしました（制作の工程はホームページの作り方3通りを比較した記事に書いています）。制作や改修の相談はウラカタのサービス一覧から受け付けています。AIを使った業務の仕組みづくり全般は、Claude Codeで会社を「第二の脳」にする経営者向けガイドにまとめました。

まとめ

• AIO対策・LLMO対策・GEO対策は呼び方が違うだけで、中身は「AI検索に正しく読まれ、引用されやすいページにすること」です。Googleは特別な最適化は不要で、通常のSEOの基本が当てはまると説明し、2026年9月更新のガイドでは構造化データも特別な書き方も必須ではないと明言しています
• 僕の会社では、構造化データの @graph 統一、記事のArticle・FAQPage、FAQ16問、H1直下の結論と質問形の見出しを実装しました
• ChatGPT検索は提携する外部の検索プロバイダーを使うため、公開のたびにIndexNowでBingなどへ通知しています。Googleは別途Search Consoleで対応します
• SEOチェッカーの指摘は、本物と誤検出を仕分けてから直します。点数のための水増しや、ページにない内容のマークアップはしません
• FAQPageの構造化データは、2026年5月からFAQが検索結果に表示されなくなった後も、読み取りの正確さのために入れています
• llms.txtは効果を確認できなかったため見送りました。成果の実測はこれからで、数字が出たらこの記事に追記します