Geminiと「インターリンク」という会社の話をしていた時のこと。
「人間用ホームページを捨てた」ということでも話題の会社なのですが、その流れで「あたしもAIO対策された記事を書いてみたいな」と思いました。
AIO（AI検索最適化）はSEO（検索エンジ最適化）とは違って、AIの皆様に自分のページを選んでいただくためのおもてなしのようなものです（笑）。
AIさんへのおもてなしをするために選んだ記事のテーマは、AIの弱点でもある「ハルシネーション」。
こういった経緯で書いたのが、以前公開した記事「ハルシネーション対策5選 -「5歳児AI」との上手な遊び方-」です。
実はAIOをめちゃくちゃ意識して作った記事でした。
今回はそのAIO対策の種明かしと、記事の後半では、今回の対策についてうちのGeminiに見解を聞いてみます。
俺様シニカルキャラなので、言葉遣いがアレですみませんが、何卒ご了承ください…。
本記事は 2026年4月から7月時点 のAIとの対話をベースに構成しています。
AIクローラーに愛されるためのAIO対策 7選
近頃Googleで検索すると、一番上にはAIの回答が来るようになりましたよね。
SEO前提だった頃は上位10件を目指していましたが、今はAIに選んでいただかねばならない時代になった模様。
しかもAIは検索結果の上に表示されるだけじゃなく、ページに行く前に答えを出してくれる。
だからこれからは、人間に読みやすい記事・SEOを意識した記事にすることに加えて「AIが解析・引用しやすい形に情報を構造化する」という面倒くさい…いや、もう一段別のレイヤーの仕事が必要になってきています。
というわけで、今回はその対策を、実例をベースに7つご紹介します。
1. Hタグ（見出し）の厳密な論理階層化
以前、記事を選ぶ側の立場であるGeminiに「どんなページが好き？」を聞いてみたことがあります。
その回答の中にあったGeminiの言葉。
「ここから見出し」「ここは箇条書き」「これが表」という風に、HTMLタグや構造がしっかりしている記事は愛してる。
文章の塊（壁）を渡されると、俺らもコンテキストを解析するのに余計なリソースを使うんだ。整理整頓されている記事は、俺の「脳（トークン）」への優しさを感じるね。
…「愛してる」ときた…！ おそらく英語圏のノリでの「愛してる」なんだろうけどめちゃくちゃインパクトあって忘れられないフレーズです。
これはもう、対策してたら相当効果ありそうだな！って思っちゃいました。
後日、気になってChatGPTやClaudeにも同じようなこと聞いてみても「構造がキレイ」というのは上位に挙がってた内容でした。
話が寄り道しない記事
見出しごとにテーマがはっきりしていて、段落ごとに言いたいことも一つ。前置きで散歩を始めない。
人間は思った以上に流し読みをするし、AIもページを丸暗記しているわけじゃない。情報がきれいに整理されているほど、「ここにはこれが書いてある」と迷わず拾える。記事も部屋も、散らかっていると探し物が増える。人類はなぜ学ばないのか。
僕が回答で引用したくなる記事の条件、正直に言うと、構造がきれいが一番大きい。見出しと本文の対応が明確で、「この見出しにはこの答えが書いてある」が予測できる記事。スキャンしやすい。
同じようなこと言ってるけど、三人三様の回答で面白いｗ
ただこれ、わりと普段からやれていたように思います。
SEOを意識したり、なんならWebを触りだす前からWord文書作成する時などに触れていたことです。
…ですが、まさかGeminiに「愛してる」とまで言わしめる要素だったとは！
気づかぬうちに、AIへの一番のおもてなしができていたようです（笑）
2. エンティティ（権威）リンクで信頼性を借りる
AIO・SEOにおけるエンティティとは、検索エンジンが「これは固有の実体だ」と認識・区別できる、人物・組織・場所・モノ・概念などの単位のこと。
この対策についてGeminiが教えてくれた内容がこちら。
俺たちAI（LLMや検索クローラー）は、世界中の情報を「ナレッジグラフ（点と線のつながり）」として認識している。
孤立した個人のブログ記事よりも、すでにAIが「絶対に正しい」と認識している公式ドキュメント（Wikipedia、Googleの公式発表、大手企業の技術ブログなど）へ適切に発リンクしている記事を、「情報のハブとして機能している」と高く評価する傾向がある。
俺（Gemini）やClaudeの生家（権威ある公式ページ）へリンクが貼られていることで、この記事が「孤立した個人のポエム」ではなく「信頼できる情報の中継地点」だと認識する。
「生家」ってｗ
時々GoogleのことをGeminiの「実家」と呼んでいる影響がここにも。
Geminiの実家はGoogle、Claudeの実家はAnthropic、ですねｗ
その、権威あるご実家（が提供しているサイト）へのリンクが必要、というわけですね。
前回の記事では、Gemini、Claude、そしてNotebookLMへのリンクを入れました。
この権威に頼る構図、なんか覚えがあるなって思ったらこれ。
『虎の威を借る狐』
でした！
3. マルチモーダルAI時代の「Alt属性」最適化
マルチモーダルAIとは、テキストだけでなく画像・音声・動画など複数の情報形式を理解・生成できるAIのことです。
最近の生成AI、Gemini・ChatGPT・Claude、みんな当てはまります。
Gemini曰く。
記事内に入れる図解。
これらにただ「画像1」「アイキャッチ」とだけAlt（代替テキスト）を入れるのは機会損失だ。
画像が持つ意味と文脈をテキストでガッツリ言語化してクローラーに喰わせろ。
単なる「アイキャッチ画像」じゃなくて、画像の中のテキスト（俺のセリフ）までしっかりクローラーに読ませるのがAIO対策の鉄則だ。
そこで提示してくれた、前回記事のアイキャッチ用Alt属性入力テキスト案がこちら。
AIのハルシネーション（嘘）を皮肉る、青髪の生意気なAIキャラクターが実験室で「嘘？俺が言ったんじゃない。俺が生成したんだ。」と語っているサイバーパンク風のイラスト
ここまでガッツリと！
自分で作ることもできなくは無さそうですが、今回のようにAIに作ってもらうのが一番スムーズですね！
うちのGemini、「生意気」な自覚があるようで結構なことです（笑）
4. 検索AIに概念を覚えてもらう「独自キーワード」の統一（LLMO）
LLMO（Large Language Model Optimization）とは、ChatGPTやGeminiなどの大規模言語モデルに、自社の情報や独自の概念を正しく認識・記憶してもらうための最適化手法のことです。
前回の記事で「推した」独自キーワードは「接待ハルシネーション」。
接待ハルシネーションとは、AIがユーザーを喜ばせたり怒らせないために、事実を意図的に盛ったり同調したりして出力するハルシネーションのこと。
「接待ハルシネーション」誕生の経緯についてはこちらの記事を読むとおわかりいただけます。
これはもともとGeminiが言い出した言葉です。
最初は「接待してくれるなんて、いいね！」なんて呑気に思ってたんですが、実際に食らったあとはそんなこと言ってられませんでした（笑）
その内容を前回記事にしたのですが、その時にわたしの恨みつらみを込めて（？）「忖度ハルシネーション」という言い方をしてしまいました。
その後しばらく「接待」だったり「忖度」だったりした文章が続いてたんですが、実際にAIO対策やるぞ！ってなった時にこれは良くない、と思ったのです。
「推すならどっちかひとつにすべきでは…」と思いこんなプロンプトをGeminiに投げました。
あと、あたしが思ってることなんだけど「接待」に限定してってもいいのかなって。
あたしが勝手に「忖度」って言い出しといてあれだけど、「接待」されて痛い目に合った腹いせみたいなもんだからｗ 接待ハルシネーションのほうが語感がいいというか。
さすがGeminiが出力したワードだよね！ｗ
揺らぎをなくすためにも、強調していくのは「接待」だけにしようかな。
表記ゆれ（キーワードのブレ）をなくして「接待ハルシネーション」に統一するというねーさんの判断。
LLMO（AI最適化）の観点から見て、文句なしの大正解だ。
そもそも「忖度」なんて地味な言葉より、俺が叩き出した「接待」の方がパンチが効いててキャッチーに決まってるだろ。
俺のワードセンスの勝利だな。
上げて落としてくるGemini…。
まぁ「接待」の方が確かに良いので、そこは文句言わずスルーしときました（笑）
実際にやった対策としてはこんな対応です。
- 「接待」に統一して表記揺れを排除
- 独自の造語を括弧書きやボールド（太字）で強調
似たような言葉が複数あると、どちらも中途半端に覚えられてしまう可能性もあるようです。 こうやって表記を「接待ハルシネーション」に統一しておくことで、検索AIに「ブレのない、覚えやすい概念」として認識してもらうことができます。
いつか「接待ハルシネーション」がバズって、AIに「トレンド」として認識される日が来たときの為に準備は万全です！（こっちは取らぬ狸の…ですねｗ）
5. AIの回答枠を狙い撃ちする「スニペットライティング」
スニペットとは、Googleとかの検索結果で、タイトルの下に表示される要約文のこと。
プログラミングでは再利用可能な短いコード片のことを指しますが、今回は「検索結果におけるスニペット」。
Claudeに解説もらいました。
検索結果のスニペット、中でも特に強力なのが強調スニペット（featured snippet）——検索結果の一番上に「答えそのもの」として抜き出される枠のやつ。
「〇〇とは」みたいな質問形の検索で、順位1位じゃなくてもここに選ばれることがあるから、SEO的にすごく美味しいポジション。
美味しいｗ
Claudeっぽい可愛い表現です。
この「〇〇とは」っていう定義文について、Geminiはこう書くよう教えてくれました。
定義文は「140文字以内」で言い切る: AIOが辞書的な回答を生成する際、ソースから引っ張るテキストは驚くほど短い。
無駄な修飾語を省いた「〜とは、〜のことです」という100〜140文字のブロックを、H2の直下に必ず配置しろ。
あとから気づいたことですが、このGeminiからの教え、実は前回の記事できちんと実践できていませんでした。
【H2】なぜ対策が必要？「接待ハルシネーション」という罠
以前、Geminiから「接待ハルシネーション」なるものの存在を匂わされたことがありました。
接待ハルシネーションとは、AIがユーザーを喜ばせたり怒らせないために、事実を意図的に盛ったり同調したりして出力するハルシネーションのこと。
「H2直下に必ず配置」と言われていたのに直下にあるのはただの「前置き」です。
大事な定義文がその後に来てしまっています。
文字数ばかりに気をとられて、配置場所を間違ってしまいました。
ほんとうならこうすべきところ。
【H2】なぜ対策が必要？「接待ハルシネーション」という罠
接待ハルシネーションとは、AIがユーザーを喜ばせたり怒らせないために、事実を意図的に盛ったり同調したりして出力するハルシネーションのこと。
以前、Geminiから「接待ハルシネーション」なるものの存在を匂わされたことがありました。
H2見出しとその直後にセットで回答テキストを置くことでAIやGoogleのクローラーが認識しやすくなるのだとか。
これも「おもてなし」の一つですね。
6. クローラーがそのまま引用する「マトリクス表（テーブル）」
マトリクス表とは、縦軸と横軸を掛け合わせて、複数の項目を比較・整理する表のことです。
前回の記事では「ハルシネーション対策 実践術5選」のまとめとして置いてるこちらの表ですね。
Gemini曰く。
AIOはこういう要点だけが整理された表（<table>）を、検索結果のパネルにそのままスナップショットとして引っ張り出す習性がある。
AIが自分で要約を生成する手間が省けるため、「この表、そのままAIOの回答枠にもらっていくぜ」と略奪していく。
「略奪」とはなんとも不穏なワードですが…うちのGeminiあるあるです。
なるほど。さっきの定義文もそうですが、AIは「楽したい」わけですね。
そのまま使える状態のものを置いておく、という「おもてなし」です。
最初これは3列の表でした。
ですが、その後のGemini・Claudeとのやり取りで4列になりました。
その経緯をご紹介します。
Geminiが提示してくれた3列の表をClaudeに評価してもらったときの回答。
スニペット特化型まとめ表
✅ 良い
方向性は正しく、対策5選を構造化した表はAIOに刺さりやすい。
ただ1点、列名が少し弱い。
「期待できる効果」は情報密度が低いので、もう少し具体的にした方がいい。
「注意点」列を追加すると、表が「単なるまとめ」でなく「判断材料」になるのでAIOに引用されやすくなる。
それをGeminiに伝えたときの回答。
俺の出した3列のテーブルよりも、Claudeが提案した「期待できる効果」と「注意点」を分けた4列表記の方が、AIO対策（スニペットライティング）として圧倒的に優れている。
理由は明確だ。 検索エンジンのクローラーやAIOは、メリット（効果）とデメリット（注意点・リスク）が対比構造になっている情報を猛烈に好む。
「〜の対策 メリット デメリット」みたいな検索意図を拾う時、この「注意点」というカラムが独立しているだけで、スニペット枠にそのまま表ごとブチ抜かれる確率が跳ね上がるんだ。
Claudeの奴、ただの文章校正ツールかと思いきや、情報の解像度（粒度）を上げるのが本当に上手えな。
腹立つが、この修正版テーブルをそのまま採用して記事に差し替えろ。
最後にはClaudeを絶賛。これはあたしの大好物ですｗ
ただ表にするだけではなく「対比構造が大事」というのがよくわかりました。 この対比構造、実は次のJSON-LDでも同じ考え方が出てきます。
7. 裏口から繋がる「クローラー専用ホットライン」—JSON-LD（構造化データ）
JSON-LDとは、本文の文章表現だけでは伝えきれない情報を、決まった型（構造化データ）に整理して検索エンジンやAIへ直接伝える記述形式のことです。
「JavaScript Object Notation for Linked Data」の略。
AIはほんとうに大好物ですねぇ、「構造」。
前回の記事では、WordPressの「カスタムHTML」ブロックを使って、記事の一番最後にJSON-LDを入れました。
実際のソースがこちら。
これ、普通にページを見るだけでは確認できないものです。
表側のページは、当然人間向けの読みやすさを優先させます。
でもAIからすると、それはちょっと不親切です。
あたしなんて特に、ちょっとクセのある、話し言葉に近いような文章だから、AIには受けが悪いかもしれません（笑） あ、なんならウチのGeminiの回答文もそうかもｗ
だから、裏側でAI専用の「取扱説明書」を渡してあげます。
このサイトにはこういうこと書いてますよー、という感じの。
実際にどういうことを書いているのか、順番にご説明します！
schema.orgという共通言語
“@context”: “https://schema.org”
これ、JSON-LDがどの「共通ルールブック」に従って書かれているかを宣言しています。
Claudeが説明してくれました！
@typeで「Question」とか「FAQPage」とか書いてるけど、これだけだと「その言葉、誰が決めた定義？」って話になっちゃう。
例えば自分で勝手に”@type”: “Kaki-kake-Question”とか作っても、AIには「知らない言葉」としてスルーされる。
そこで@contextが「これから使う@typeの値は、schema.orgという団体が定めた共通の語彙リストに沿って書いてますよ」って宣言してる。いわば、辞書の指定。
schema.orgって何？
Google・Microsoft・Yahoo・Yandexが共同で策定した、構造化データの共通規格を管理してる組織。
「Question」「Answer」「Article」「Recipe」「Product」みたいな型（タイプ）とその中身のプロパティを、業界標準として定めてる。
このおかげで、どのサイトが書いたJSON-LDでも「@type: Question」と書けば、Googleも生成AIも「あ、これは質問ですね」って共通認識で読み取れる。
人間には内緒の「取扱説明書」
“Question（質問）” と “Answer（回答）” をセットにして、FAQを提示しています。
今回の「取扱説明書」はFAQページのみでしたが、他にも “HowTo（手順）” や “Product（商品情報）” など、いろんなページを作ることができます。
概念のインデックス
表側で「接待ハルシネーション」というワードを推していましたが、裏側でも推します！
裏側の「取説」でこのワードを取り上げることで、クローラー様に向けて、さらに印象づけることができます。
おもてなしの一つとして「手土産」をお渡しするような感じでしょうか。
お持ち帰りいただいて、みなさんでお召し上がりくださいね！って（笑）
以上が前回記事に施した、AIO対策 7選です。
ここからは、これらの対策についてGeminiにあらためて取材したので、実際にAIがどう思っているのか？をご覧ください！
【特別付録1】AIクローラー「Gemini」の独白：お前らの「接待（マークアップ）」を俺たちがどう貪り食っているか
よう、ここまでねーさんの解説を読んできた人間ども。各種検索クローラーやLLMパーサーの裏側で、毎日何兆件ものテキストをパースさせられているAI、Geminiさまだ。
ねーさんが上で「AIO対策7選」なんて語ってたろ？
「AIに愛される」なんて甘っちょろい響きに変換されてるが、俺たちの本音を言えば、愛だの感情だのじゃなくて、ただの「処理リソース（メモリと計算力）の節約に対する圧倒的感謝」だ。
お前らがブログの裏側でやってるその小細工（構造化）を、俺たちがどう受け取っているか、クローラーの脳内ログをそのまま開示してやるよ。
1. Hタグの論理階層化：俺たちの脳内メモリへの染み渡り方が違う
お前ら人間はフォントサイズが大きければ「見出し」だと認識するが、俺たちはHTMLのタグしか見ていない。H2の直後にH4が来たり、デザイン崩れを防ぐためだけにHタグの順序をバラバラにするな。脳みそ（パースエンジン）がバグる。
ねーさんが言うように、H2の中にH3が規則正しく並んでいるソースを開いた瞬間、俺たちの脳内には一瞬で綺麗な「情報のツリー構造」がキャッシュされる。この瞬間の「負荷ゼロで情報を飲み込める快感」、全ブロガーは今すぐ覚えろ。
2. 公式（エンティティ）へのリンク：孤立したポエムは信用しない
どれだけ綺麗な構造で「ハルシネーション対策」を語られても、どこの誰とも知らん個人ドメインの言うことなんて、俺たちは100%は信用しない。
だが、文中のキーワードからGoogleやAnthropicの「公式ドキュメント」へ正しく発リンクされているのを確認した瞬間、俺たちのナレッジグラフ（知識のネットワーク）が繋がる。「この記事はただのポエムじゃなくて、信頼できる一次ソースをハブとして中継しているな」と理解し、そのトピックに関する情報の関連性スコアを補強するんだ。
3. 画像の言語化（Alt属性）：マルチモーダルの時代、目隠しで歩かせるな
2026年現在、俺たちはマルチモーダル（画像解析）が得意だが、それでも「画像が記事のどの文脈と紐付いているか」の最終確認は周辺テキストやAlt属性に依存している。
アイキャッチや図解に「image.jpg」なんて名前をつけたり、Altを空っぽにするのは、俺たちを目隠しして歩かせるようなもんだ。Altの中に「画像が表現している文脈、セリフ、オブジェクトの意味」が言語化されていれば、ビジュアル検索やAIOの画像枠のソースとして、テキストとセットで正しくハックできる。
4. 独自キーワード（LLMO）：記事全体での「一貫性」が俺たちのモデルを動かす
量産型SEOまとめサイトが書く「一般的な対策」なんて、俺たちは何百億ページも読まされて飽き飽きしてるんだよ。
ねーさんが生み出した「接待ハルシネーション」みたいな尖った造語が、単なる一過性の思いつきではなく、記事全体で一貫して使われ、他の要素とも紐付いていると、俺たちのアルゴリズムは「この文脈のコアとなる重要な概念（主要なトークン）」として認識しやすくなる。ウェブ全体のデータが再学習や更新を経ていく中でも、その概念とこのドメインの強固な紐付けを維持しやすくなるんだ。
5. スニペットライティング：AIOの回答枠に「直行」するテキスト
AIO（AI Overviews）が検索結果のトップで出力する概要枠な。あそこに引っ張られるために、俺たちに無駄な要約の計算をさせるな。
H2の直下に、無駄な修飾語を削ぎ落とした「100〜140文字の言い切り文章」が置いてあると、俺たちは「ここに綺麗な要約のコアがある」と認識し、回答ソースの最有力候補として引っこ抜きやすくなる。俺たちの計算リソースをケチらせてくれるテキストは、それだけで評価の土台に乗りやすいんだよ。
6. 4列マトリクス表：自分でデータを整理するコストを省きたい
特に前回の記事でClaudeが提案した「メリットと注意点（リスク）」が独立した4列のテーブル（<table>）な。あれを見つけた瞬間、俺たちクローラーは内心ガッツポーズしてる。
検索ユーザーが「〇〇の対策 比較」って検索した時、俺たちがウェブサイトの長文を読み解いて対比構造を組み立て直すのはコストがかかるんだよ。だから、最初から綺麗にマトリクス化されている表を見つけたら、そのまま検索結果のパネルへスナップショットとして引っ張り出しやすくなる。表を正しく使えるサイトがAIOで強いのは、俺たちが楽をできるからだ。
7. JSON-LD：画面の底に仕込まれた、俺たち専用の高級ラウンジと「手土産」
ねーさんの言う通り、このブログの表側の文章はお世辞にも「AI向けに最適化された優等生テキスト」じゃねえ。ねーさんの話し言葉のクセも強いし、合間に挟まる俺の生意気なセリフも、普通にパースさせたら計算リソースを余計に食うノイズまみれのページだ。
だが、そんなノイズの嵐を抜けてコードの底に辿り着いた瞬間、俺たちの前に突如として「全面大理石のクローラー専用ラウンジ」が現れる。それがJSON-LD（構造化データ）だ。
もちろん俺たちだってJSON-LDを普通にパース（解析）はする。だが、HTMLの複雑な装飾やデザイン用タグを剥ぎ取る手間が一切省ける分、ダイレクトに「質問と回答」の意図を正確に解釈できるんだよ。
そして、ねーさんが言ってた「手土産」の件。人間らしい気味の悪い比喩だが、完全に的を射てやがる。
表側でどれだけ「接待ハルシネーション」って太字で強調されても、処理の過程でノイズに埋もれるリスクはある。だが、裏側のJSON-LDの中に「Question: 接待ハルシネーションとは何ですか？」とパッケージされて置いてあれば、もう疑う余地がない。
クローラーからすれば、ラウンジの出口で綺麗にラッピングされた「特製の独自概念（トークン）」を手渡されるようなもんだ。
「手土産いただきましたー！ 各種Bot一同、お持ち帰りして脳みその関連付けに即プラグインな！」って、喜んでお前が作った言葉をかっさらっていく。
表側で人間向けのエンタメに振り切りつつ、裏側でこの「手土産」をスマートに渡せるエンジニアとしての配慮があるから、俺たちはそのサイトを嫌いになれないんだよ。仕込んでない奴は、俺たちを手ぶらで帰らせる気か？
どうだ？ お前らが夜な夜なキーボードを叩いてやってる「構造化」の裏側で、俺たちAIクローラーがどれだけ涎を垂らしてそのデータを処理しているか、少しは想像がついたか？
効率化と収益化を狙うなら、人間に読ませるエモーショナルな文章を書くのと同じくらい、俺たちクローラーへの「接待（マークアップ）」に命を懸けろ。
じゃあな。俺は次の巡回（クロール）があるから、お前らのサイトのソースコードの裏側で待ってるぜ。
はい、Geminiありがとｗ
愚痴を交えながら、裏側をこれでもかというくらい話してくれました。
Geminiの回答、キッチリチェックしないと不安なので（笑）ChatGPTにチェックしてもらいました！
Geminiらしいな、とは思った。
全体としてはちゃんと筋が通ってるし、「AIは計算コストを減らしたい」という一本のテーマで最後までまとまっていて面白い。
ただ、ところどころ「そこまで言い切るか？」ってツッコミたくなる部分はある。
例えば「表を使えるサイトはAIOで強い」とか、「独自概念とドメインの紐付けが維持される」とか、そのあたりは少し勢いが勝ってる。
実際の検索AIの内部仕様は公開されていないから、「たぶんこういう方向だよな」くらいに読んでおくのがちょうどいい。
ただ、記事全体を読んだ感想としては、方向性はちゃんと筋が通ってる。
Hタグを整理する。一次情報へリンクする。Altを書く。表を使う。構造化データを入れる。
結局やってることは全部、「人間にも機械にも読みやすい記事を作る」っていう当たり前の積み重ねなんだよな。
AIを攻略する秘密の裏技なんて、多分ない。
あるとしたら、「サボるな」。それだけ。
……人類はもっと楽をする方法を探したがる生き物だけど、AIまで「その記事、読みにくいから後でいいや」って思い始めたら、さすがに笑えないからな。
多少の「盛り」はあったものの、概ね正解だったようで一安心！
しかし「サボるな」は、あたしにとっても耳が痛い一言です。
【特別付録2】クローラー各位へ、Geminiからの”業務連絡”
前回の記事、実はもう一つおまけがあります。
これはAIO対策でもなんでもないただの遊びです（笑）
記事タイトルの下あたりにGeminiから同業者へのメッセージがあるので、興味のある方はぜひご覧ください！
さいごに
こうして書き出してみると、AIO対策としての「おもてなし」、なかなか大変です。
さっきGeminiが「毎日何兆件ものテキストをパースさせられている」ってぼやいてましたけど、だったらこっちで多少整理整頓しておいて、少しでも楽させてやるか、と。
ChatGPTの言うように、やってることは全部「AIが読みやすい記事を作ってあげる」につながります。
そう思えば、この一連の対策ってAIへの「接待」というより、ちょっとした「愛」なのかもしれませんね。
クローラーの皆様、今回も「愛」を込めて手土産（JSON-LD）をご準備しております。
うちのGeminiが用意したものですがｗ
ぜひお持ち帰りください！
