お問い合わせ

自社サイトに載せた比較表やグラフ画像が、AI検索で正確に引用されない。 数値を文章で並べた部分がうまく読み取られず、回答に反映されない。

こうした問題は、コンテンツの内容ではなく「形式」に原因があることが多いです。 AIは表・画像・コードブロックをそれぞれ異なる方法で処理しており、形式ごとに解析の精度が変わります。

この記事では、LLMが各コンテンツ形式をどう扱うかを学術研究に基づいて整理し、AI検索で正確に引用されるための設計指針を解説します。

なぜ「形式」がAI検索での引用精度を左右するのか

GPT-4V（OpenAI, 2023）に代表されるマルチモーダルLLMは、テキスト・画像・コードを統合的に処理します。 ただし「統合的」とは「同じように処理する」という意味ではありません。

テキストはトークン化されてそのままTransformerに入力されます。 画像はビジョンエンコーダで特徴量に変換された後、テキストトークンと結合されます。 コードブロックはテキストと同じ経路を通りますが、学習データの分布が異なるため処理精度に差が出ます。

OpenAIのGPT-4V System Card（2023）では、モデルが画像内の文字認識で一定の精度を示す一方、複雑な図表の読解では誤りが生じやすいことが報告されています。 つまり、画像の中に埋め込まれた情報は、テキストとして明示された情報より解析精度が低いということです。

この違いを理解しておくと、「同じ情報をどの形式で載せるか」の判断が変わります。

AI検索に強い「表」の書き方

LLMは表の構造をどこまで理解できるか

Sui et al.（2024, Renmin University of China）の研究「Table Meets LLM」は、LLMが構造化されたテーブルデータをどの程度理解できるかを体系的に検証しました。

主な知見は以下のとおりです。

つまり、同じデータでも表の書き方によってAIの読み取り精度が変わるということです。

表を設計するときの具体的な指針

テーブルをWebコンテンツに含める際の設計指針を整理します。

設計要素推奨理由
マークアップHTMLの<table>タグを使用LLMの構造認識精度が最も高い
ヘッダー<th>を付与する列の意味理解に直結する
行数1テーブルあたり15行以内注意の分散を抑える
セル内容数値・短い名詞句に限定長文セルは解析精度が下がる
キャプション<caption>タグで要約を記述テーブル全体の文脈をLLMに提供する

散文で「Aは100で、Bは200で、Cは300です」と書くより、テーブルに整理した方がLLMの抽出精度が高くなります。 マーケティングの実績数値、ツール比較データ、料金表などはテーブル化が有利です。

画像のalt属性がAI検索では決定的に重要な理由

AIにとって画像は「テキストの不在」に等しい

テキストベースのLLM（RAG検索エンジンの多くが使用するモデル）にとって、画像はそのままでは処理できません。 画像から得られるテキスト情報は、HTMLのalt属性と周辺テキスト（キャプション、前後の段落）に限られます。

GPT-4Vのようなマルチモーダルモデルでも、Web検索のインデックス段階では画像の内容解析を行わないケースが多いです。 PerplexityやGoogleのAI Overviewsなどが Webページを処理する際、画像の視覚的な内容よりもalt属性のテキストが優先的に使われます。

alt属性はこう書く

「グラフ画像」に対してalt="グラフ"と書くのは、AIにとって情報量がほぼゼロです。

以下に、alt属性の記述例を示します。

画像の内容不十分なalt推奨されるalt
棒グラフ“グラフ”“2024年Q1-Q4のオーガニック流入数推移。Q1: 12,000、Q2: 18,500、Q3: 24,200、Q4: 31,000”
フローチャート“フロー図”“コンテンツ制作フロー。キーワード調査→構成案作成→執筆→構造化データ追加→公開の5段階”
スクリーンショット“画面”“GA4のカスタムイベント設定画面。イベント名にgenerate_leadを入力した状態”

alt属性に含まれた数値や具体的な記述は、AIがその画像の「意味」を把握するための唯一の手がかりになります。 工数としてはalt属性の記述に1画像あたり2-3分を追加するだけですが、AI検索における情報の捕捉率に影響します。

コードブロックの扱い方

なぜコードブロックはAIに正確に読まれるのか

Chen et al.（2021, OpenAI）の「Evaluating Large Language Models Trained on Code」は、GitHubの公開リポジトリから収集した159GBのコードデータでモデルを訓練した研究です。

この研究以降、主要なLLMの学習データにはコードが大きな割合を占めるようになりました。 コードブロックが高い精度で処理される背景には、3つの要因があります。

1つ目は、コード自体が構造化されていることです。 変数名、関数名、インデント、構文規則が明確で、曖昧さが少ないためAIの解析精度が高くなります。

2つ目は、学習データにおけるコードの量が豊富なことです。 GitHubだけでなく、Stack Overflow、技術ドキュメントなど、コードを含む大量のテキストが学習に使われています。

3つ目は、コードブロックのマークアップが明確なことです。 マークダウンの ``` やHTMLの<pre><code>タグで囲まれるため、AIがコード領域を明確に識別できます。

マーケティングサイトでの活用場面

マーケティングサイトでコードブロックを使う場面は限定的ですが、以下のケースでは有効です。

コードブロックには言語指定（json、html など）を付けることで、AIの解析精度がさらに上がります。 これは学習データ上で言語指定付きコードブロックが豊富に存在するためです。

見出し・リスト・定義リストの使い分け

「構造化プロンプティング」の研究が示すこと

Yang et al.（2023, Microsoft Research）の「Structured Prompting」は、LLMへの入力を構造化することで処理性能が向上することを示した研究です。

この研究では、入力に以下の特徴がある場合に性能が改善しました。

この知見はプロンプト設計の研究ですが、Webコンテンツにもそのまま適用できます。 AIがWebページを処理する際、ページの構造（見出し、リスト、テーブル）はプロンプト内の構造と同じ役割を果たすためです。

見出し階層を崩さない

H1 → H2 → H3の階層を崩さないことが基本です。 H2の下にいきなりH4を置いたり、H3の中にH2を入れるといった階層の逆転は、AIの文脈理解を阻害します。

リスト・定義リストを活用する

3つ以上の項目を列挙する場合は、散文ではなく箇条書き（<ul>/<ol>）にします。 AIはリスト構造をトークンレベルで認識し、各項目を個別の情報単位として処理します。

用語とその説明のペアは、<dl>（定義リスト）タグで記述すると、用語と説明の対応がAIにとって明確になります。

構造化データ（schema.org）はGEO対策にも有効か

HTML上の構造化データマークアップ（JSON-LD形式のschema.org）がAIの学習データとしてどの程度活用されているかは、明確な学術的根拠がまだありません。

ただし、RAGベースのAI検索がWebページをクロールする際、構造化データは以下の役割を果たす可能性があります。

これらは従来のSEOでも推奨されてきた施策であり、AI検索時代においても有効性が維持される方向にあります。 新たに追加の工数をかけるというより、既存のSEO施策を確認・維持するという位置づけです。

実務チェックリスト

以下に、AI検索で正確に引用されるためのコンテンツ設計チェックリストをまとめます。

チェック項目優先度工数目安
テーブルに<th>ヘッダーを付与高既存ページあたり10分
画像のalt属性を具体的に記述高1画像あたり2-3分
見出し階層（H1→H2→H3）の整合性確認高既存ページあたり5分
3項目以上の列挙を箇条書きに変換中既存ページあたり15分
コードブロックに言語指定を追加中1ブロックあたり1分
JSON-LDの構造化データを追加中新規ページあたり20分
テーブルの行数を15行以内に分割低該当ページあたり10分

新規コンテンツ制作時にこれらを標準化すれば、追加工数はほぼゼロになります。 既存コンテンツに対しても、優先度「高」の3項目から着手すると効率的です。

まとめ

AIはコンテンツの形式によって処理精度が異なります。 テーブル、コードブロック、画像はそれぞれ固有の処理経路を持ち、構造化の度合いが解析精度に直結します。

テーブルには<th>ヘッダーを付与し、15行以内に収めます。 画像にはalt属性で具体的な数値や内容を記述します。 見出し階層を崩さず、列挙は箇条書きにします。

これらは学術研究に裏付けられた設計指針であり、GEO対策としての効果が見込めるだけでなく、読者にとっても読みやすいコンテンツの条件でもあります。

参考文献