LLMO対策の提案は、根拠の種類を2つ確かめれば、専門知識がなくても見極められます。1つは、根拠が「規格に対応している」という説明か、「検索エンジンやAIのプログラムが実際に読み取る」という説明か。もう1つは、施策の選び方が推測によるものか、実際に数えた結果によるものかです。
しかし、相手は専門の会社です。発注側が根拠を問いただして、提案の良し悪しまで判断できるのかという疑問は残ります。
この記事では、よく出る2種類の提案を例に、発注側が聞くことと、聞くときの進め方を並べます。
規格どおりに書いたデータでも、AIのプログラムが読み取るとは限らない
規格は、データの書き方の取り決めです。その書き方で書いたデータをいつ、どう読み取るかは、ページを集めるプログラム(クローラー)を作る各社が決めています。
LLMO対策の提案でよく出るのは、「業界の共通規格で、主要な検索エンジンが対応しているので実装すべきです」という説明です。この説明自体は正しく、反論しにくく聞こえます。
例として多いのが構造化データです。構造化データは、ページに書いてある情報を、機械が意味を取りやすい形で書き添える仕組みです。ページの階層を示すパンくずリストも、この形式で書き添えられます。
規格どおりに書き添えたデータを、どのクローラーが実際に読み取るかは、規格とは別に確かめる必要があります。
schema.org は、自らを正式な標準化団体ではないと説明している
構造化データの規格として使われる schema.org は、検索結果への反映を約束していません。schema.org の公式FAQが、そう書いています。
schema.org は、Google、Microsoft、Yahoo!、Yandex の4社が共同で運営しています。複数の検索エンジンの共同規格だという説明は、ここまでは正確です。
一方で、同じFAQには「Schema.org is not a formal standards body.」とあります。schema.org は正式な標準化団体ではなく、主要な検索エンジンが対応する書き方を記録する場所だという説明です。
FAQには、schema.org のすべての種類の情報が検索結果に出るわけではないとも書かれています。具体的な使われ方は、各検索エンジンの資料を見るよう案内しています。
「共同規格だから読まれる」という説明は、規格の紹介としては正しいものの、実装する根拠としては足りません。提案の中身が間違っているわけではありません。根拠として挙げているものが、規格の説明の段階で止まっているということです。
構造化データをどの方式で書き込むかを聞けば、提案の確かさを判断できる
構造化データの書き込み方は2通りあり、どちらで書くかによって、読み取れるクローラーが変わります。発注側は、どちらの方式で書くのかを聞けば足ります。
| 書き込み方 | 仕組み | 読み取れるクローラー |
|---|---|---|
| サーバー側で埋め込む | サーバーが返すHTMLに、最初から構造化データを書いておく | 受け取ったHTMLをそのまま読むクローラーも、JavaScriptを動かしてから読むクローラーも読める |
| JavaScriptで差し込む | ブラウザでページを開いたあと、JavaScriptで構造化データを追加する | JavaScriptを動かしてから読むクローラーだけが読める |
人が見る画面は、どちらの方式でも同じです。違いが出るのは、受け取ったHTMLをそのまま読むクローラーにとって、JavaScriptで差し込んだ情報がページに無いのと同じになる点です。
Googleは、JavaScriptで生成した構造化データも、ページを描画したあとに処理できると説明しています。OpenAIも、自社のクローラーの一覧を公開しています。一覧には、検索用、広告のリンク先の確認用、学習用、利用者の操作に応じて動くものの4種類が並んでいます。ただし、それぞれがJavaScriptを動かすかどうかは書かれていません。
ここから先は、公式の仕様に書かれていない私の解釈です。公式に書かれていない以上、JavaScriptが動く前提で設計すると、読み取られない場合が残ると思います。読み取られない場合に備えるなら、サーバー側で埋め込むほうが確実です。
相手が「サーバー側で埋め込む」と答えれば、その提案はクローラーの読み取り方を踏まえています。「JavaScriptで差し込む」と答えれば、その方式でどのクローラーに読まれる見込みなのかを説明してもらいます。このやりとりに専門知識は要りません。
掲載先の媒体を勧められたら、実際に数えた結果かを聞く
「この業界のポータルサイトへの掲載を強化しましょう」という提案では、その媒体を選んだ理由を確かめます。市場での規模や知名度で選んだのか、AIに質問して、どの媒体のURLが答えに引用されるかを数えた結果なのかを聞きます。
媒体の規模と、AIの答えに引用される回数は、一致しないことがあります。AIが答えを作るときに参照するのは、その質問に答えているページです。そのため、大きな媒体より、比較記事やまとめ記事で名前が多く挙がっているほうが引用される場合もあると思います。
聞くことは「実際に数えましたか」の1つです。数えていれば、AIに投げた質問の一覧と、媒体ごとの件数が出てきます。出てこなければ、その選定は推測です。
推測による選定だと分かれば、その媒体に予算を回す判断をいったん保留できます。推測で提案すること自体に問題はありません。発注側が推測だと知ったうえで判断できることが大事です。
発注側が聞くことは2つにまとめられる
ここまでの2つの例から、発注側が聞くことは次の2つになります。どちらも、相手の答えがどの種類の根拠に当たるかを分ける問いです。
| 聞くこと | 根拠が弱い答え | 根拠が確かな答え |
|---|---|---|
| その根拠は、規格の話か、読み取りの話か | 「規格に対応しています」で説明が終わる | 「この書き方なら、このクローラーがこう読み取ります」まで説明がある |
| その選定は、推測か、実際に数えた結果か | 件数が出てこない | 質問の一覧と件数が出てくる |
答えが正しいかを判定するには、相手より詳しくなる必要があります。根拠の種類を分けるだけなら、専門知識がなくてもできます。
発注側が守ることは、「規格に対応している」という説明と「実際に読み取られている」という説明を区別することです。
根拠を聞く前に、自分たちでAIの答えを数えておく
根拠を聞きにくいときは、先に自分たちで数えてから聞くと、相手を疑う聞き方になりません。専門家として依頼した相手に根拠を求めると、信頼していないように受け取られることがあるからです。
根拠を求めることには、不利な点もあります。すべての提案に根拠の数字を求めると、相手は身構えます。提案が慎重になって進みが遅くなり、思い切った案が出にくくなるおそれもあります。
自分たちで数えるには、自社が答えに挙がるべき質問をいくつか決めてAIに投げ、どのURLが引用されたかを記録します。専門的な道具は要りません。
数えた結果を持っていくと、質問は「自社で数えたらこうなりましたが、そちらの数字と合っていますか」に変わります。確かめている内容は同じで、相手と数字を突き合わせる形になります。
根拠が推測の施策は、止めるかを決める前に順番を見直す
根拠が推測だった施策も、無駄だとは限りません。発注側が決めるのは、やるかやらないかの2択より、どの順番で進めるかです。
構造化データがその例です。ページの階層を機械が読める形で書き添えておいても、害はありません。サイトのテンプレートに1回入れれば、そのテンプレートを使う全ページに反映されるので、手間も少なく済みます。
気を付けたいのは、優先順位です。AIがページを引用するかどうかは、書き添えたデータより、本文に何が書いてあるかで決まる部分が大きいと思います。他社が書けない数字や事例が本文にあることが、引用される理由になると考えます。
手間の少ない施策は、優先度が低くても先に済ませてよく、順番を入れ替えるのは人手と時間を取り合う施策です。テンプレートに1回入れるだけの作業は、ほかの施策と工数を取り合いません。人手と時間を取り合う施策を並べ替えるときに、さきほどの2つの問いを使います。
よくある疑問
Q:提案してきた会社に、書き込み方や数えた結果の有無を聞くのは失礼になりませんか。
A:失礼にはなりません。どちらも、提案を実行する会社が決めているはずのことです。決まっていればすぐ答えが返り、決まっていなければその場で決めることになり、どちらでも話が進みます。角を立てたくないときは、「見積もりが妥当か判断したいので」と前置きを添えてください。
Q:構造化データは、入れたほうがよいのでしょうか。
A:新しくページを作るなら、最初から入れておくと手間が少なく済みます。今あるサイトに後から加えるなら、書き込み方によって読み取れるクローラーが変わるので、方式を確かめてから決めてください。手間の少ない作業なので、優先度が低いことと、後回しにすることは分けて考えて構いません。
Q:AIの答えを数える作業は、自社でもできますか。
A:できます。自社が答えに挙がるべき質問を10問ほど書き出し、AIに投げて、どのURLが引用されたかを記録します。同じ質問を時期をずらして繰り返すと、変化も追えます。外部に頼む価値があるのは、数える作業より、質問の決め方と結果の読み方です。
Q:根拠が推測だと分かったら、依頼先を替えるべきでしょうか。
A:推測だったというだけでは、替える理由になりません。LLMO対策では、推測で提案する場面を避けられないからです。見るのは、相手が推測を推測だと説明できるかどうかです。聞かれたときに「数えていません」と答えられる相手は、推測と実測を区別しています。
手元の提案書を2つの問いで分けてみる
LLMO対策を外部の会社に頼むのは、自社に知識がないからです。発注側が提案の正しさを自分で判定しようとすると、頼んだ意味が薄れます。発注側が見るのは、根拠の種類です。
規格に対応しているという説明か、実際に読み取られるという説明か。推測か、実際に数えた結果か。この2つで提案書の項目を分けると、多くの項目はそのまま進められます。残りの数項目について、根拠の数字がないまま優先度が高く置かれていないかが分かります。
手元の提案書のうち、実際に数えた数字が添えられている項目がいくつあるか、数えてみてはいかがでしょうか。
