AIO/LLMOで差をつける「XHTMLの理念」

公開日

今、Web上で、AIO (AI Optimization / AI最適化) や LLMO (Large Language Model Optimization / 大規模言語モデル最適化) が注目されています。今回は、AIO / LLMO でライバルに差をつけるための「XHTMLの理念」について解説します。

生成AI が Webサイト を評価する時代、あなたの Webサイト は ChatGPT や Google Gemini のような AI / LLM (大規模言語モデル) に最適化されていますか？

かつての XHTML全盛期 の Webサイト制作 では、HTMLの構造 をバリデータで細かくチェックし、エラーが出ないように徹底することが求められました。当時は HTMLの構造 を工夫することで検索結果が変化する、そんな SEO の時代でした。

しかし、その後の SEO は HTMLの構造 よりもコンテンツの量と質が重視される時代へと移り変わりました。ところが、昨今の AI の目覚ましい進化によって、HTMLの構造 の重要性が再び増しています。そこで今、注目すべきなのが「XHTMLの理念」です。

XHTML とは？

2000年代初頭に登場した XHTML は「ソフトウェアやプログラムといった機械同士が正確に会話するための言語」のように設計されていました。現在の HTML (HTML Standard) が人間に優しく、多少の間違いがあってもブラウザが気を利かせて表示してくれるのに対し、XHTML は XML という「機械語」のルールを厳格に守っています。

「国際会議での通訳」を例にすると、現在の HTML が「ちょっとした方言や文法の乱れも汲み取る通訳」だとすれば、XHTML は「決められた文法通りに話す必要がある厳格な通訳」でした。

なぜ厳格なのか？ それは、機械が人間の書いた情報を正確に理解して処理するためです。例えば、

  • タグの閉じ忘れを許容しません。<a> と書いたら必ず </a> で閉じる必要があります。閉じないと、機械はどこからどこまでが一つの情報なのか分からなくなり、混乱してしまいます。
  • 要素の入れ子が厳格です。「大きな箱の中に小さな箱を入れる」というように、要素の親子関係が明確でなければなりません。親子関係が明確でない場合、機械は「どの情報がどの情報に属しているのか」を正確に判断できなくなります。

このように、XHTML は XML の厳格なルールを適用することで、Webページ上の情報をデータベースのように構造化し、機械が効率的かつ正確にデータを読み取れるように作られていました。

XHTMLの理念 とは？

現在の HTML は、記述ミスがあっても、ブラウザが独自に解釈し、何とか表示してくれるように作られています。これを「エラー耐性」と言います。例えば、段落を明示する <p> タグがなくても、閉じタグを忘れても、ブラウザは「ここで段落が変わるんだろう」と気を利かせて表示してくれます。

しかし、この「エラー耐性」が、AI や LLM にとって厄介な問題になることがあります。

AI が Webサイト の HTMLコード を「読む」とき、「だいたいこんな感じだろう」と察してくれるわけではありません。AI は HTMLコード を非常に機械的かつ論理的に解析します。意味を持たない <div> だけでマークアップされたテキストや、閉じられていないタグがあると、AI は「これは何の情報だろう？」「どこからどこまでが一つの意味のまとまりだろう？」と迷ってしまいます。

曖昧な HTMLの構造 は AI にとってノイズになり、正確な情報抽出やサイト全体の理解を妨げる原因になりかねません。AI はその情報を見つけることはできても、その情報がどれだけ重要なのか、何に関連しているのかを正確に把握するのが難しくなります。

そこで、XHTML が持っていた「機械語」のルールを厳格に守るという理念が重要になります。

すべてのテキストを <h1>, <p>, <li> のように意味を持つタグでしっかり囲み、要素の親子関係を論理的に整理することで、Webサイト は AI にとってのデータベースに変わります。整理された HTML は、AI がコンテンツの意図、情報の階層、そしてサイト全体の構造を正確かつ効率的に理解するための強力な手助けとなります。

参考: Google Gemini との対話

「LLM は セマンティックな HTML をどのように評価するか」に対する Google Gemini の回答 (抜粋)

LLM にとってのセマンティックな HTML の価値

  • コンテンツの構造と階層の理解促進:
    LLM は、テキストコンテンツを理解し、要約したり、質問に答えたりする能力に優れています。セマンティックな HTML は、ドキュメントの構造 (見出し、段落、リスト、ナビゲーション、サイドバーなど) を明確に定義します。LLM はこの構造をヒントとして利用し、コンテンツの主要なテーマ、重要な情報、そしてそれらの相互関係をより正確に把握することができます。例えば、<article> 内の <h1> が記事のメインタイトルであり、その後の <p> が本文、<ul> が関連情報であることを、機械的に判断しやすくなります。
  • 情報抽出の精度向上:
    LLM は、与えられたテキストから特定の情報を抽出するタスク (例: 固有名詞、日付、場所など) を得意とします。セマンティックなタグは、特定の種類の情報がどこにあるかを示すメタデータのような役割を果たします。例えば、<address> タグ内の情報は住所である可能性が高い、<table> 内の情報は表形式のデータである、といった判断がしやすくなり、情報抽出の精度が向上する可能性があります。
  • 多様な出力形式への対応:
    LLM は、質問応答、要約、翻訳など、様々な形式で情報を出力できます。セマンティックな構造が明確であれば、LLM は元のコンテンツの意図や構造を保ったまま、異なる形式で情報を提供しやすくなります。例えば、記事の <nav> 要素の内容を元に「このページにはどんなセクションがありますか？」という質問に答えたり、<main> 要素の内容だけを抽出して要約を生成したりすることが容易になります。
  • ファクトチェックや信頼性評価の補助:
    LLM は、時に誤った情報を生成する「ハルシネーション」の問題を抱えています。信頼性の高い情報を特定するためには、その情報がページのどの部分にあるか、どのようなコンテキストで提示されているかといった情報が重要になります。セマンティックな HTML は、LLM がコンテンツの信頼性を評価する上で、構造的な手がかりを提供し、より正確なファクトチェックをサポートする可能性があります。例えば、引用符で囲まれた <q> や <blockquote> の内容は引用であると判断しやすいでしょう。

まとめると

SEO と同様に、LLM も最終的には「コンテンツの質」を最も重視します。しかし、セマンティックな HTML は、その高品質なコンテンツを LLM がより深く、より正確に理解し、活用するための「手助け」となります。

「誤ったマークアップによって LLM が間違った解釈をする可能性があるか」に対する Google Gemini の回答 (抜粋)

誤ったマークアップが LLM の誤解釈を招く可能性

誤ったマークアップは、LLM がコンテンツを間違って解釈したり、その確信度を下げたりする可能性があります。

これは、LLM がテキスト内容だけでなく、HTML の構造とセマンティクスを重要なヒントとして利用しているからです。正しいマークアップは、コンテンツの「地図」や「説明書」のような役割を果たします。この地図が間違っていたり、説明書が不完全だったりすると、LLM は目的地 (コンテンツの意味) にたどり着くのが難しくなったり、間違った道を進んでしまったりするリスクが生じます。

具体的な例としては、以下のようなケースが考えられます。

  • セマンティクスが無視されたマークアップ:
    本来 <h2> であるべきタイトルが単なる <div> でスタイルされている場合、LLM はそれが重要な見出しであることを確信しづらく、記事の主要な構造を見誤る可能性があります。結果として、要約が不適切になったり、関連性の低い情報として扱われたりすることがあります。
  • 誤った要素の利用:
    引用文ではないものが <blockquote> で囲まれている場合、LLM はそれを「引用された情報」と誤解し、出典を求めたり、元の著者の意見ではないと判断したりする可能性があります。
  • 構造的な混乱:
    関連性のない要素が不自然にネストされていたり、本来分離されるべき内容が混在していたりすると、LLM は情報の区切りや関係性を正確に把握できず、誤った文脈で情報を解釈してしまうことがあります。

LLM の頑健性と限界

もちろん、LLM は非常に頑健であり、多少の不備があってもテキスト内容からある程度意味を推測する能力は持っています。Google の検索エンジンがそうであるように、LLM も完全に完璧な HTML だけを求めるわけではありません。多くの「誤った HTML」からも学習していますから、ある程度の推測は可能です。

しかし、それはあくまで「推測」の域を出ない場合があり、確信度は低下します。確信度が低い情報は、LLM が引用を避けたり、その情報に基づいて推論する際に誤りを犯したりするリスクを高めます。特に、重要度が高い情報や、ファクトチェックが必要な情報において、このリスクはより顕著になります。

したがって、「正しい HTML」でマークアップすることは、LLM にとってコンテンツを正確に理解してもらうための、依然として非常に有効な手段であるという認識で間違いありません。

Webサイト を XHTMLの理念 で強化するヒント

意味を持つ要素を徹底活用する

<div> や <span> といった意味を持たない要素を使う前に、意味を持つ要素で使えるものがないか検討しましょう。もし使うのであれば、role属性 や aria-label属性、Microdata の itemtype属性 や itemprop属性 などの使用して意味を持たせることを検討しましょう。

「暗黙の段落」を作らないようにする

テキストは必ず、<h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <address>, <p>, <pre>, <li>, <dt>, <dd>, <figure>, <figcaption>, <caption>, <td>, <th>, <fieldset>, <legend>, <details>, <summary> のいずれかを祖先要素に持つようにマークアップしましょう。これらを祖先要素に持たないテキストは現在の HTML では「暗黙の段落」として扱われ、 AI にとってノイズになる可能性があります。

<!DOCTYPE html>
<html lang="ja">
  <head>
    …
  </head>
  <body>
    テキスト<!-- 暗黙の段落 --><!-- XHTML では Invalid -->
    <p>テキスト</p>
    <div>テキスト<!-- 暗黙の段落 --></div>
    <article>
      <p>テキスト</p>
      <div>テキスト<!-- 暗黙の段落 --></div>
    </article>
  </body>
</html>

HTML のバリデータを利用する

バリデータを利用して、HTMLの構造 に問題がないか確認しましょう。

現在の HTML がチェックできるバリデータには「Nu Html Checker」があります。しかし、頻繁にアップデートされる HTML の仕様に対応していない可能性があります。

そこで、ChatGPT や Google Gemini にバリデータになってもらうプロンプト (指示・質問) を紹介します。

HTMLコードの中に暗黙の段落があるか調べるプロンプト
後述するHTMLコードを分析し、
h1, h2, h3, h4, h5, h6, address, p, pre, li, dt, dd, figure, figcaption, caption, td, th, fieldset, legend, details, summary を祖先要素に持たないテキストコンテンツが存在するか教えてください。
もし存在する場合は、そのテキストコンテンツの内容と、最も近い祖先要素を特定してください。
----
<!-- ここに分析したい HTMLコード を貼り付けます -->
無効な属性を調べるプロンプト
後述するHTMLコードを分析し、
HTMLの仕様として要素に使用できない属性がないかチェックしてください。
使用できない属性が見つかった場合は、要素名と属性名を指摘してください。
----
<!-- ここに分析したい HTMLコード を貼り付けます -->
無効なネストを調べるプロンプト
後述するHTMLコードを分析し、
HTMLの仕様として要素の無効なネストがないかチェックしてください。
無効なネストが見つかった場合は、開始タグと終了タグの範囲、含まれる要素名を指摘してください。
----
<!-- ここに分析したい HTMLコード を貼り付けます -->

〆

現在の HTML は「エラー耐性」があり、人に寄り添った仕様である一方、XHTML は機械に寄り添った仕様であり、LLM との相性がいいです。今ここで XHTML に回帰するのは、HTML4.01 時代のテーブルレイアウトから、XHTML 時代の CSSレイアウト にシフトしていった感じに似ています。

そして、AI が進化していき、コードだけでなく、人が目にしているデザインから、人が耳にしている音まで解析するようになれば、また XHTML から遠ざかっていくのだと思います。

関連記事