LLMOの誤情報対策で見落としやすい自社サイト内の食い違い
更新
まず自社サイトの記事と会社情報を照合する
LLMOの誤情報対策では、外部サイトに書かれた情報に目が向きがちです。ただ、自社サイトの中でも、記事と会社概要・料金・サービスのページが違う内容を書いていることがあります。Rootpublishは2026年9月、自社サイトを含む6サイトの公開ページを会社情報ページと照合しました。その結果、3サイトで食い違いが見つかりました。
この監査で調べたのは公開ページどうしの記載で、AI検索の回答そのものは調べていません。そのため、見つかった食い違いが実際に誤った説明につながったかは確かめていません。それでも、自社の情報源どうしが矛盾していれば、正しい説明が返ってくることは期待しにくくなります。
Googleは、AI OverviewsやAI Modeにも従来のSEOの基本が有効で、AI用の特別なテキストファイルや専用の構造化データは必要ないと説明しています。同時に、要件を満たしても表示は保証されないとしています。生成AIでコンテンツを用意する場合も、正確性・品質・関連性を重視するよう案内しています。特別な施策を探す前に、自社の記載が正確で互いに食い違っていないかを確認するのが出発点になります。
見つかったのは数字の誤りより言い過ぎ
見つかった食い違いには、次のようなものがありました。
・無料診断で提供する範囲を、実際より広く書いている
・サービス名を別の名前で書いている
・最低契約期間を「3か月」と書いている（料金ページは「最低契約期間なし」）
・自社の顧客事例に書いた料金が、料金ページの最安プランを下回っている
・製品は公開前に人の承認が必要なのに、見出しで「自動運営」とうたっている
数値の単純な誤りよりも、自社サービスの範囲や条件を言い過ぎる記載のほうが多く見つかりました。誤字や古い数字だけを探していると、こうした記載は見落とされやすくなります。点検では、提供範囲・契約条件・料金・自動化の程度を表す言葉に注意を向けるとよいでしょう。
6サイトの監査結果
サイトごとの結果は次のとおりです。AIで記事を量産している企業ブログでは、12記事から4件の食い違いが見つかりました（うち1件は判断が分かれるもの）。AI関連のコラムを出している企業1社では、12記事から2件でした。Rootpublishのサイトでは、322段落から2件でした。
一方、手書きの個人ブログと、記事末尾の自社案内を定型文にしていた企業2社では、はっきりした食い違いは見つかりませんでした。ただし6サイトだけの結果なので、記事の書き方と食い違いの多さに一般的な関係があるとまでは言えません。
監査の方法
監査は次の手順で行いました。まず公開中のページを段落に分けます。次に、社名・サービス名や「当社」「私たち」などを含む段落を選びます。選んだ段落を、会社概要・料金・サービスのページの記載と照合します。
食い違いの判定にはClaude Opusを使い、候補として挙がった段落はClaudeが読んで確かめました。人による確認は一部にとどまっています。各サイトで対象にしたのは、新しい記事12本までです。
判定に使うAIモデルで結果が変わる
食い違いを判定するAIモデルも比較しました。正解を用意した合成データ102件での正解率は次のとおりです。
・Claude Opus 5.5、Fable 5.1：100%
・Sonnet 5：99%
・Codex経由のGPT、判定専用モデルのJev：97%
・Haiku 4.5：88%
ところが、実際のAI記事で見つかった自社サービスの言い過ぎ4件については、JevとSonnetはどれも拾えず、Opusは拾えました。合成データでの成績は、実際の記事での成績を保証しませんでした。モデルを選ぶときは、テスト用データの正解率だけで決めないことが大切です。自社の実際の記事で拾えるかを確かめてから選ぶ必要があります。
費用の目安
判定専用モデルのJevで12記事・1,212段落を全件照合した費用は、公表単価で約0.25ドルでした。ただし、この方法では実際の食い違いを拾えませんでした。
そこで、自社について述べた段落（全体の約1割）だけを選び、Opusで判定する方式を検討しました。この方式の費用は、1記事あたり約0.05ドルと見積もっています。これは見積もりであり、思考に使うトークン数は計測していません。安く全件を照合するよりも、対象を絞って拾える精度を優先したほうが、この検証では実際の食い違いを見つけられました。
自社サイトの見出しを直した事例
Rootpublishは自社サイトrootpublish.comの公開8ページ・322段落を監査しました。その結果、WordPress版の見出し「自動運営」「On autopilot」が製品仕様と食い違うと判定しました。製品仕様では、公開前に人の承認が必要だからです。
見出しを「一次情報で育てる」「Grown from what you know」に変えて公開しました。公開後に同じページの129段落を再監査したところ、食い違いは0件でした。
これは1サイト・1か所の修正事例です。同じ手順でどのサイトでも食い違いがなくなることを示すものではありません。
この監査の限界
この監査は6サイト・各12記事までの小さな標本です。多くの判定はOpusの判定とClaudeによる確認にとどまっており、人による確認は完了していません。
段落の選び方にも弱点があります。記事と会社情報で製品の呼び名が違うと、その段落を取りこぼすことがあります。また、会社情報の正本のほうが古い場合は、記事ではなく正本を直す必要があります。食い違いが見つかっても、記事の側が間違っているとは限りません。
自社サイトで確認を始める手順
ここまでの記録をもとに、自社で同じ確認を始める手順をまとめます。これは検証から導いた進め方の提案で、検索順位やAIからの引用を改善した実測結果ではありません。
1．照合の基準にするページを決めます。会社概要・料金・サービスのページを正本とし、最初に正本自体が最新かを確かめます。正本が古ければ、記事より先に正本を直します。
2．公開記事を段落に分け、社名・サービス名・「当社」「私たち」などを含む段落を選びます。サービスの旧名称や略称など、呼び名の揺れも条件に加えると取りこぼしを減らせます。
3．選んだ段落を正本と照合します。数字の誤りだけでなく、提供範囲・契約期間・料金・自動化の程度を言い過ぎていないかを重点的に見ます。
4．AIの判定は候補の洗い出しに使い、最終判断は人が記事と正本を読んで行います。判定に使うモデルは、自社の実際の記事で食い違いを拾えるかを試してから選びます。
5．修正は1件ずつ確認して公開し、公開後に同じページを見直します。Rootpublishでは、検索改善について1件の改善を承認・公開した後、同じページを7日間観察して実測で判断する設計にしています。検索順位やAIからの引用は保証していません。
記事を作る段階で食い違いを防ぐ手段もあります。Rootpublishは、原稿の段落ごとに参照した会社情報のIDと版を記録し、承認時に元情報が変更されていないかを検査します。ただし、この版の検査は文章と根拠の意味が一致していることまでは保証しません。そのため、公開前に人が本文と出典を読む工程を残しています。