LLMO

1.1LLMOとは何か#

LLMOは、Large Language Model Optimizationの略称として実務で用いられるが、国際的に一つの公式定義へ統一された用語ではない。本稿では、次のように定義する。

DEFINITION

LLMOとは、LLMを利用する検索・回答・推薦・エージェント環境において、対象となる実体と情報を、発見可能、取得可能、解釈可能、検証可能、引用可能、選択可能、操作可能な状態へ整え、その成果とリスクを継続的に測定・改善する組織横断的活動である。

この定義は、単なる「AI回答に社名を出す施策」と異なる。誤った説明で社名が出れば、可視性は高くても事業価値は低い。検索には出ても価格や在庫が古ければ、AI経由の購入体験を損なう。引用が増えても、規制違反や個人情報漏えいが起これば、施策として失敗である。

したがって、LLMOは少なくとも次の七要素を含む。

1. 発見可能性：クローラー、検索、フィード、API等から情報源を発見できる。
2. 取得可能性：HTML、画像、文書、データが安定して取得できる。
3. 解釈可能性：対象、属性、関係、時点、条件、例外を機械が誤解しにくい。
4. 検証可能性：主張の根拠、著者、発行主体、日付、出典、改訂履歴が追跡できる。
5. 回答適合性：質問の意図、比較軸、意思決定条件に対応する情報がある。
6. 行動可能性：人またはエージェントが問い合わせ、予約、購入、登録等を実行できる。
7. 統制可能性：権利、法令、セキュリティ、ブランド、データ品質を管理できる。

1.2SEO、AEO、GEO、LLMOの関係#

用語の混同を避けるため、本稿では次のように整理する。

これらは排他的ではない。実務上は、SEOで取得・索引化の基礎を整え、AEOで質問への回答構造を整え、GEOで生成回答内の可視性を評価し、LLMOで組織・データ・ブランド・法務・エージェント対応まで統合する、と考えると理解しやすい。なお、生成AI時代の検索最適化を総称してAI SEOと呼ぶ場合もあるが、本稿では最も広い運用概念としてLLMOを用いる。

1.3RAGとは何か#

RAG（Retrieval-Augmented Generation、検索拡張生成）は、モデル内部のパラメータだけに依存せず、質問に関連する外部文書を検索し、その情報を用いて回答を生成する構成である。Lewisらの研究は、知識集約型タスクにおいて、外部検索を組み合わせる意義を体系化した初期の代表例である［12］。

公開WebにおけるLLMOでは、RAGの存在により、ページ全体の評価だけでなく、次が重要になる。

• どの質問で取得候補になるか
• 取得された部分が単独でも誤解されにくいか
• 主張と根拠の対応が明確か
• 更新日、対象地域、通貨、単位、適用条件が示されているか
• 同じ企業の複数ページが矛盾していないか
• 引用元として第三者が検証できるか

ただし、「検索システムが文書を分割するから、すべての段落を短くすればよい」という単純化は不適切である。検索単位や分割方法はシステムごとに異なる。重要なのは、文章を不自然に断片化することではなく、見出し、文脈、指示対象、条件、数値、出典を保った意味的に完結したセクションを作ることである。

1.4AIエージェントとは何か#

AIエージェントは、情報を生成するだけでなく、目的に応じて複数の手順を計画し、画面、DOM、アクセシビリティ情報、API、外部ツール等を利用して操作するシステムである。例えば、条件比較、在庫確認、予約、フォーム入力、購入補助、問い合わせ作成等が該当する。

LLMOが回答掲載だけを目的にすると、エージェント時代の重要な要件を取り落とす。価格や在庫が機械取得できない、入力欄のラベルが曖昧、確認画面がない、認証と権限が不適切、操作を繰り返すと重複注文が生じる、といった問題は、文章最適化では解決しない。エージェント対応では、セマンティックHTML、アクセシビリティ、API設計、認証、冪等性、監査ログ、安全確認が必要になる［16］［17］。

2.1なぜ経路を分離するのか#

AIサービスへの情報提供を一括して考えると、目的と制御方法を誤る。少なくとも次の四経路を分けるべきである。

経路A：検索への掲載

検索用クローラーや検索インデックスを通じて、ユーザーの質問時に情報源として発見される経路である。目的は、検索・回答への出典候補になることにある。

経路B：モデル学習・改善への利用

公開コンテンツが基盤モデルの学習や改善に利用され得る経路である。検索表示とは目的、更新速度、権利判断、制御手段が異なる。モデルに学習されたとしても、最新情報が回答される保証や、出典リンクが表示される保証はない。

経路C：ユーザー質問時の取得

ユーザーがURLを指定したり、AIに特定ページの閲覧・要約・操作を依頼したりした際に、ユーザーの代理として取得する経路である。通常の自動巡回クローラーとは異なり、robots.txtの適用方針がサービスによって異なる場合がある。アクセス制御、認証、WAF、利用規約、監査ログを含めて設計する必要がある。

経路D：AIエージェントによる操作

比較、予約、購入、送信、更新等の操作を行う経路である。検索表示の可否ではなく、操作権限、本人確認、同意、入力検証、冪等性、取消、監査、安全確認が中心課題となる。

2.2四経路の比較#

2.3経路別ポリシーの原則#

企業は、最低限、次の文書を持つべきである。

• AIクローラー・エージェントの分類表
• 目的別の許可・拒否方針
• 公開可能データと非公開データの境界
• コンテンツ利用許諾と契約の判断基準
• WAFで正規ボットを確認する手順
• ユーザー起点取得に対する認証・ログ方針
• エージェント操作の確認・取消・事故対応手順
• 変更時のレビュー責任者

「すべてのAIボットを拒否する」「すべて許可する」の二択ではなく、検索、学習、ユーザー取得、操作を分け、事業目的とリスクに応じて決定する。

3.1企業規模だけでは施策を決められない#

従業員10人のEC事業者が100万SKUを持つ場合、組織は小さくても、クロール、商品データ、在庫、価格、重複、フィードの技術課題はエンタープライズ級である。反対に、従業員1万人のBtoB企業でも、公開サイトが300ページで更新頻度が低ければ、クロールバジェットより、部門間の表現統一、承認、法務、ブランド・エンティティ整合のほうが重要となる。

したがって、本稿は規模を次の四軸に分ける。

1. 組織規模（O：Organization）
2. Web公開規模（W：Web）
3. データ規模（D：Data）
4. ガバナンス・リスク複雑性（G：Governance）

3.2法定区分と実務区分を混同しない#

日本の中小企業基本法では、業種ごとに資本金または従業員数による中小企業者の範囲が示されている［21］。これは政策・制度上重要な区分であるが、LLMOの技術負荷を直接表すものではない。例えば、資本金が小さくても、ユーザー生成コンテンツ、商品DB、多言語サイト、リアルタイム在庫を持てば技術複雑性は高い。

本稿で示す売上高・従業員数・ページ数の境界は、法的定義ではなく、役割分担、予算、ツール、承認、技術アーキテクチャを選ぶための運用上の目安である。

4.1組織規模 O：従業員数・売上高・組織分化#

表4-1組織規模の実務区分

売上高は業種差が大きいため、従業員数・売上高のいずれか一方だけで判定しない。次の要因がある場合は、一段階上の組織複雑性として扱う。

• 複数ブランド、複数法人、フランチャイズ、代理店網を持つ
• 3言語以上または複数国で運営する
• 医療、金融、法律、公共等の高規制領域である
• 広報、IR、採用、製品、サポート等で発行主体が分散している
• コンテンツ公開に3部門以上の承認が必要である
• M&Aによりシステム・ブランド・ドメインが統合されていない

4.2Web規模 W：公開URL数・更新頻度・URL増殖性#

表4-2Web規模の実務区分

ここで数えるのは、サーバー上の全URLではなく、検索・AI回答・ユーザー行動にとって価値があり、索引対象とするURLである。パラメータ、セッションID、並び替え、内部検索、重複印刷ページ等を含めると、見かけのURL数が膨張し、判断を誤る。

Googleのクロールバジェット高度ガイドは、概ね「100万ページ以上で週単位の更新」「1万ページ以上で日次更新」「Discovered - currently not indexedが多い」等を、より詳細な管理が必要になり得る目安としている。これは一律の閾値ではないが、本稿がW3を1万ページから始める根拠の一つである［4］。

4.3データ規模 D：公開実体数・レコード数・鮮度#

ページ数が少なくても、背後のデータが大きければ、LLMO対応はデータ基盤問題になる。例えば、APIで100万商品を提供し、Web上では検索結果ページだけを公開するサイトでは、ページ数だけを見ても複雑性を把握できない。

表4-3データ規模の実務区分

レコード数が少なくても、価格、在庫、金利、空席、診療時間等の更新遅延が重大な損失を生む場合は、鮮度要件を理由に上位区分として扱う。

4.4ガバナンス複雑性 G：規制・権利・ブランド影響#

表4-4ガバナンス複雑性

4.5複合分類コード#

各企業・サイトを、例えば O2-W3-D3-G2 のように表す。

• O2：小規模組織
• W3：1万ページ以上の大規模Web
• D3：100万件以上の公開データ
• G2：中程度の規制・評判リスク

この企業は「中小企業向けの簡易SEOプラン」では不十分であり、商品データ、クロール、フィード、ログ、WAF、変更管理にエンタープライズ級の技術が必要になる。一方で、組織人数は限られるため、フル内製ではなく、PIM・CMS・フィード・監視の自動化と外部専門家を組み合わせるべきである。

逆に O4-W1-D1-G3 の企業では、クロールバジェットより、公式見解の統一、資格者・法務レビュー、部署間の矛盾防止、危機対応、ブランドと人物のエンティティ整合が優先される。

4.6LLMO複雑性スコア#

優先順位を議論するため、各軸を0〜3点に正規化し、補助的なスコアを作ることができる。

LCS = 0.20O + 0.25W + 0.25D + 0.30G

• O：組織規模・分化
• W：Web規模・URL増殖性
• D：データ規模・鮮度
• G：規制・権利・ブランド影響

Gの重みを大きくするのは、誤情報や規制違反の損失が、露出機会の損失より重大になり得るためである。ただし、LCSは投資優先度の対話を支援する指標であり、普遍的な科学尺度ではない。

平均値の罠

平均点だけで戦略を決めてはいけない。WとDが最大なのに、OとGが低い場合、平均すると「中程度」に見えるが、クロール・データ基盤は依然として最上位設計が必要である。

そこで、次の二つを併用する。

技術クラス T = max(W, D)
統制クラス C = max(O, G)

• Tが高い：クロール、データ、API、フィード、監視、自動化を優先
• Cが高い：責任、承認、証拠、法務、教育、監査を優先
• TとCが共に高い：全社プログラムとして扱う

4.7追加補正軸#

実務では次の補正も必要である。

更新頻度 F

• F0：四半期以下
• F1：月次・週次
• F2：日次
• F3：リアルタイムまたは常時更新

多様性 V

• V0：単一ブランド・単一言語
• V1：複数カテゴリ・複数担当
• V2：複数ブランド・複数言語
• V3：複数法人・国・規制圏

依存度 A

• A0：AI検索からの獲得が事業にほぼ影響しない
• A1：認知・比較の補助チャネル
• A2：問い合わせ・売上に重要
• A3：AIエージェント経由の取引が中核になり得る

最終的な投資判断では、T、C、F、V、Aをレーダー状に見て、突出項目を先に処理する。

5.1ステップ1：URLとデータの事実を測る#

「ページ数は約1万」といった推測ではなく、次を取得する。

• XMLサイトマップ掲載URL数
• 検索エンジンで索引可能なcanonical URL数
• サーバーログで実際に取得されたURL数
• 内部リンクから到達できるURL数
• 30日・90日で更新されたURL数
• 404、soft 404、5xx、リダイレクト、重複URL数
• 商品、店舗、人物、記事、求人等のマスター件数
• API・フィードで公開するレコード数
• 価格・在庫・営業時間等の許容遅延時間

5.2ステップ2：発行主体と責任を可視化する#

次の単位で責任者を特定する。

• 会社・ブランド・事業
• 商品・サービス
• 価格・在庫・条件
• 著者・監修者
• 法務・規制
• 技術・クローラー
• データ・API
• 訂正・削除
• AI回答モニタリング

情報が誤っていても、誰が直すか分からない状態では、LLMOは改善できない。

5.3ステップ3：プロンプトではなく意思決定場面を分類する#

評価用質問は、単なるキーワード一覧ではなく、顧客の意思決定段階で分類する。

1. 問題認知：「何が原因か」「どの選択肢があるか」
2. 学習：「仕組み」「条件」「違い」「注意点」
3. 比較：「おすすめ」「AとB」「選び方」
4. 適合判断：「自分の条件に合うか」
5. 信頼確認：「実績」「根拠」「安全性」「評判」
6. 行動：「見積もり」「予約」「購入」「相談」
7. 継続利用：「使い方」「解約」「トラブル」「更新」

5.4ステップ4：四経路を診断する#

各重要情報について、次を確認する。

• 検索クローラーが取得できるか
• モデル学習に関する方針が決まっているか
• ユーザー起点の取得をWAFが誤遮断していないか
• エージェントが操作する際の安全設計があるか
• 公開HTML、構造化データ、フィード、APIの内容が一致するか
• 古いページや第三者情報と矛盾していないか

5.5ステップ5：最も弱い連鎖を特定する#

LLMO成果は次の連鎖で考える。

発見 → 取得 → 解釈 → 信頼 → 引用・言及 → 選択 → 行動 → 成果 → 学習・改善

どこか一つがゼロなら、後段の最適化は機能しにくい。

• 取得できない：記事を増やしても候補にならない
• 解釈できない：ブランドや商品の取り違えが起きる
• 信頼されない：比較候補・引用元として選ばれにくい
• 行動できない：露出しても問い合わせ・購入につながらない
• 計測できない：投資判断と改善ができない

5.6診断票#

合計点より、0点の項目を先に解消する。これは、平均値よりボトルネックを重視する本稿の原則に対応する。

6.1原則1：規模ではなく制約から設計する#

• 人が少ないなら、自動化と対象集中を選ぶ。
• ページが多いなら、テンプレート・マスター・ログで管理する。
• 規制が重いなら、公開速度より証拠と承認を優先する。
• データが速く変わるなら、記事更新よりフィード・API・同期を優先する。
• ブランドが分散するなら、エンティティと用語の統一を優先する。

6.2原則2：量より情報利得を重視する#

AIが既に多数の情報源から容易に要約できる一般論を大量生産しても、追加価値は小さい。重要なのは、次のような非コモディティ情報である。

• 独自調査・実測データ
• 具体的な判断基準
• 適用条件と例外
• 失敗事例と改善過程
• 専門家の経験に基づく差分
• 商品・価格・在庫・仕様等の一次データ
• 地域固有の情報
• 明示的な比較軸と評価方法

6.3原則3：AI向け情報と人向け情報を分離しすぎない#

構造化データ、フィード、APIは重要だが、可視本文と矛盾してはいけない。人に見えない宣伝的属性をマークアップだけで追加する、本文では不明な条件をAPIだけに置く、価格が各面で異なる、といった不整合は信頼と運用を損なう。

6.4原則4：露出より正確性を先に置く#

医療、法律、金融、公共情報では、誤った言及を増やすことは成果ではない。可視性KPIには必ず、正確性、根拠、時点、適用範囲、リスク表現を組み合わせる。

6.5原則5：サイトを「公開知識基盤」として扱う#

LLMOに強いサイトとは、AI専用の文章を並べたサイトではない。企業の公式な知識を、次の状態で維持するサイトである。

• 事実の正本がある
• 名称と識別子が統一される
• 主張と証拠が結びつく
• 更新日と有効期間が分かる
• 古い情報を廃止できる
• 人と機械の双方が取得できる
• 外部情報との不一致を検知できる
• 行動への安全な接続がある

7.1エンタープライズLLMOの本質#

大企業の問題は、コンテンツ不足よりも、情報の分散、責任の分散、システムの分散、評価の分散であることが多い。事業部、広報、IR、採用、サポート、研究開発、販売代理店、海外法人が別々の表現を公開すると、AIは同一企業について複数の矛盾した説明を取得する。

したがって、エンタープライズLLMOは、個別記事の最適化プロジェクトではなく、次を統合する全社プログラムとして設計する。

• 公開情報ガバナンス
• SEO・生成AI検索
• ブランド・広報・第三者評価
• 商品・顧客・店舗・人物のマスターデータ
• CMS、PIM、DAM、CRM、API、フィード
• 法務、プライバシー、知的財産、広告審査
• AI回答モニタリングと訂正
• AIエージェントによる操作の安全性

NIST AI RMFは、AIリスク管理をGovern、Map、Measure、Manageの機能で整理し、継続的かつ多職種で実施する考え方を示す。ISO/IEC 42001は、方針、責任、リスク、監視、継続的改善を含む組織的なAIマネジメントシステムを扱う。経済産業省・総務省系のAI事業者ガイドラインも、経営層の関与、リスクベースの運用、透明性、説明責任等を重視する［18］［19］［20］。LLMO固有の規格ではないが、全社統制の骨格として利用できる。

7.2ハブ・アンド・スポーク型組織#

エンタープライズでは、すべてを中央集権にすると公開が遅れ、すべてを事業部任せにすると品質が分裂する。推奨するのは、中央の専門機能と事業部の専門知識を組み合わせるハブ・アンド・スポーク型である。

中央ハブの役割

• LLMO方針、対象AI、KPI、リスク許容度の決定
• URL、エンティティ、データ、構造化データの共通標準
• AIクローラー・エージェントの目的別ポリシー
• 評価プロンプト、採点基準、実験手順の共通化
• 共通ツール、ログ基盤、ダッシュボードの提供
• 法務・セキュリティ・ブランドの最低基準
• 重大な誤回答・炎上・情報漏えいのインシデント統括

事業スポークの役割

• 顧客質問、専門知識、一次データ、事例の提供
• 商品・サービス固有の更新
• 専門家監修と現場検証
• 事業KPIへの接続
• 地域・言語・規制に応じたローカライズ

共通サービス層

• CMSテンプレート
• PIM・商品フィード
• 著者・監修者マスター
• 証拠・引用台帳
• 構造化データ生成
• サイトマップ・URLライフサイクル管理
• AI回答モニタリング
• APIゲートウェイとエージェント操作基盤

7.3全社LLMO憲章#

取締役会または経営会議が承認する短い憲章には、少なくとも次を記載する。

1. 目的：売上、顧客支援、ブランド正確性、社会的説明責任等
2. 対象：公開Web、商品データ、アプリ、API、外部プロフィール、第三者媒体
3. 対象AI経路：検索掲載、学習、ユーザー取得、エージェント操作
4. 禁止事項：虚偽の専門性、偽レビュー、不自然な第三者言及、規制回避、隠し情報
5. リスク許容度：医療・金融等で許容しない誤り、更新遅延、操作事故
6. 責任：経営責任者、データ責任者、コンテンツ責任者、法務、技術、事業部
7. 評価：可視性だけでなく正確性、引用根拠、行動成功、収益、事故を測る
8. 訂正：誤情報発見時の優先度、公開訂正、外部訂正要請、再評価

7.4公式事実レジストリ#

大企業では、「どのページが正しいか」を人にもAIにも示せないことが根本問題になる。そこで、頻繁に問われる公式事実をレジストリ化する。

対象例

• 正式社名、旧社名、ブランド名、法人番号
• 本社、拠点、営業時間、連絡先
• 役員、専門家、資格、所属
• 商品名、型番、GTIN、仕様、価格、在庫
• サービス対象、対象外、契約条件、解約条件
• セキュリティ、認証、データ保管地域
• 医療・法律・金融上の適用範囲と注意事項
• 調査結果、算定方法、対象期間

必須属性

このレジストリを公開ページへ機械的に反映すれば、部門ごとの表現差と更新漏れを減らせる。ただし、内部情報を無差別に公開してはならない。公開可否、個人情報、営業秘密、契約上の制約を属性として管理する。

7.5ポリシー体系#

全社規程は、次の階層で作ると運用しやすい。

レベル1：原則

• 正確性優先
• 利用者利益
• 透明性
• 人による責任
• データ最小化
• 証拠保存
• 訂正可能性

レベル2：標準

• 著者・監修表示
• 更新期限
• 構造化データ整合
• URL廃止
• クローラー制御
• API認証
• AI生成物のレビュー
• 第三者レビュー・引用の利用条件

レベル3：手順

• 公開前チェックリスト
• robots.txt変更手順
• 価格更新手順
• 誤回答調査手順
• 外部訂正依頼テンプレート
• インシデントエスカレーション

レベル4：証拠

• 承認ログ
• 変更履歴
• サーバーログ
• 評価結果
• 法務判断
• 監修記録
• 事故対応記録

7.6RACI#

Rは実行責任、Aは最終説明責任、Cは協議、Iは報告を表す。一つの活動にAを複数置くと、事故時に責任が曖昧になる。

7.7ポートフォリオ管理#

大企業は、全ページを同時に最適化しない。事業価値とリスクにより、次の四象限へ分類する。

優先対象は、売上が大きいページだけではない。誤りが社会的損害を生むページ、AIが頻繁に誤認するブランド・製品、顧客サポート負荷を下げる情報も含める。

7.8変更管理とインシデント対応#

重大情報の変更では、公開ページだけでなく、フィード、API、構造化データ、PDF、営業資料、外部プロフィールを同時に更新する。変更の完了条件は「CMSで公開した」ではなく、各面の整合確認とする。

誤回答インシデントの流れ

1. 検知：モニタリング、顧客、営業、広報から受付
2. 分類：事実誤り、古い情報、別実体混同、第三者誤情報、生成上の推測
3. 影響評価：利用者、安全、規制、契約、評判、売上
4. 封じ込め：該当ページ修正、API停止、robots/noindex、注意表示等
5. 根本原因：正本不在、矛盾、取得不能、外部情報、評価漏れ
6. 訂正：公式発表、外部媒体への訂正依頼、顧客案内
7. 再評価：主要AI、主要質問、地域・言語別に確認
8. 改善：ルール、テンプレート、監視、教育を更新

8.1中堅企業の構造的立場#

中堅企業は、専門性、顧客データ、導入実績を持つ一方、エンタープライズ級の共通基盤を一度に構築する余力は限られる。成功条件は、網羅性ではなく、事業価値の高い質問領域へ投資を集中し、90日単位で学習することである。

8.2ROIの構成#

LLMOの便益を直接流入だけで測ると過小評価し、ブランド露出をすべて売上換算すると過大評価する。便益を次のように分解する。

総便益 = 直接成果価値
       + アシスト成果価値
       + 営業・サポート効率価値
       + ブランド正確性価値
       + リスク回避価値
       - カニバリゼーション調整

ROI =（総便益 - 総費用）÷ 総費用 × 100

直接成果価値

AI参照セッションや識別可能なキャンペーンから発生した売上・粗利・商談価値。

直接粗利 = AI経由の適格問い合わせ数
         × 商談化率
         × 受注率
         × 受注当たり粗利

アシスト成果価値

AIで認知・比較した後、指名検索、直接訪問、電話、店舗等で成約する価値。アンケート、CRM、会話ログ、指名検索変化、地域・期間比較を用いて推定し、直接成果と重複しないようにする。

効率価値

正確なFAQや仕様がAI回答に利用され、営業説明時間、問い合わせ件数、一次対応時間が減る価値。

効率価値 = 削減件数 × 1件当たり処理時間 × 人件費単価

リスク回避価値

誤価格、誤説明、規制違反、二重予約、情報漏えい等の期待損失を低減する価値。

期待損失低減 =（改善前発生確率 - 改善後発生確率）× 事故影響額

これは推定幅が大きいため、単一値ではなく低・中・高シナリオで示す。

8.3プロンプトクラスター期待価値#

個々の質問ではなく、意思決定が共通する質問群で投資を判断する。

PEV = Q × E × U × A × C × M

• Q：質問機会の相対規模
• E：対象AIがWeb取得・回答する確率
• U：施策による言及・引用改善余地
• A：回答後にサイト・店舗・操作へ進む確率
• C：コンバージョン率
• M：成果当たり粗利または価値

PEVは厳密な需要予測ではなく、クラスター間の相対比較に用いる。各変数を1〜5点で採点してもよい。

優先順位式

Priority =（事業価値 × 改善余地 × 実行可能性 × 証拠優位性）
           ÷（費用 × 規制リスク × 維持負荷）

ここで証拠優位性とは、自社が一次情報、専門家、実績、データを持ち、競合より検証可能な回答を作れる程度である。

8.490日実験ポートフォリオ#

中堅企業は、次の三種類を同時に持つ。

1. 基盤実験：クロール、エンティティ、構造化データ、速度、内部リンク
2. コンテンツ実験：比較、選定基準、一次データ、事例、FAQ
3. 行動実験：AI経由ランディング、見積もり、相談、デモ、API

各実験は、仮説、対象質問群、変更内容、先行指標、事業指標、期間、停止条件を持つ。

実験票の例

8.5推奨投資配分#

初年度の一例であり、固定比率ではない。

既に技術的SEOが成熟している企業は、一次情報と外部信頼へ配分を移す。大規模DBがある企業は、技術・データ比率を上げる。

8.6Build、Buy、Partner#

• Build：競争優位となる一次データ、評価設計、顧客知識、公式事実
• Buy：一般的なクロール監視、ログ基盤、ダッシュボード、CMS機能
• Partner：高度なRAG評価、法規制、デジタルPR、セキュリティ試験

AI可視性ツールは観測の補助であり、AIサービスの内部評価を完全に示すものではない。ツール選定では、質問・地域・モデル・日時・回答・引用URLの保存、再現性、エクスポート、個人情報、利用規約を確認する。

9.1小規模であることは必ずしも不利ではない#

中小企業は、ドメイン全体の権威やコンテンツ量で大企業に劣る場合がある。しかし、次の領域では優位を作れる。

• 狭い地域の現場情報
• 代表者・資格者の経験
• 顧客の具体的な質問
• 商品・サービスの適合条件
• 独自工程、品質基準、失敗回避
• 迅速な更新
• 顧客との直接関係

生成AIが必要とするのは、必ずしも最大サイトではなく、質問に対して最も明確で検証可能な情報源である。

9.2「狭く深く」の設計#

全国の一般論を網羅するより、次のように対象を絞る。

顧客属性 × 問題 × 地域 × 条件 × 行動段階

例：

• 「東京都内の従業員50人未満の製造業が、ISO対応SaaSを選ぶ条件」
• 「特定地域で夜間対応できる診療所を探す際の確認項目」
• 「相続相談で初回面談前に準備すべき資料」
• 「築古住宅の断熱改修で見積書を比較する基準」

対象を絞ることで、一般的なまとめ記事では得られない具体性を作れる。

9.3最小公開知識セット#

小規模サイトは、記事本数を増やす前に次を揃える。

1. 会社・事業者の正式情報
2. 代表者・専門家の実在性、資格、経験、担当範囲
3. サービスの対象、対象外、地域、価格または算定方法
4. 依頼・購入・予約の流れ
5. よくある質問と例外
6. 実績・事例・数値の算定条件
7. リスク、限界、注意点
8. 連絡先、営業時間、所在地、緊急時の案内
9. プライバシー、利用規約、キャンセル・返品等
10. 更新日、監修、訂正窓口

9.4顧客会話から質問を作る#

少額の検索ツールだけに依存せず、次を集める。

• 電話・メール・チャットで繰り返される質問
• 営業が説明に時間を使う論点
• 契約直前の不安
• 失注理由
• クレーム・返品理由
• 現場で起こる例外
• 口コミで評価・批判される点
• 競合との比較質問

月に一度、営業、サポート、現場、代表者が30分集まり、「新しく出た質問」「誤解されやすい説明」「情報が古いページ」を更新するだけでも、情報鮮度は大きく改善する。

9.5地域企業のエンティティ整合#

地域サービスでは、Webサイトだけでなく、地図、業界ディレクトリ、予約サイト、自治体・商工団体、口コミサイト等の名称、住所、電話、営業時間を一致させる。支店と本社、旧住所、略称が混在すると、別実体として扱われたり、古い情報が回答されたりする。

整備項目は次のとおりである。

• 正式名称と一般的な呼称
• 住所、建物名、郵便番号、電話
• 営業・診療・受付時間
• 対応地域
• サービスカテゴリ
• 予約可否、当日対応、支払方法
• 資格者・責任者
• 休業・移転・閉店情報
• 公式URLとプロフィールの相互参照

9.6一次情報を作る方法#

大規模調査を行えなくても、次は一次情報になり得る。

• 100件の問い合わせを匿名集計した質問傾向
• 施工・導入前後の実測値
• 選定チェックリスト
• 見積もり内訳の読み方
• 失敗しやすい条件
• 地域固有の手続・季節性
• 自社が対応できないケース
• 専門家による判断フロー

数値を示す場合は、対象期間、件数、除外条件、測定方法を明記する。少数データを一般化しない。

9.7最小チーム#

一人が複数役割を兼務してよいが、次の機能は残す。

9.8低予算で優先すべき20テーマ#

1. 正式な会社・店舗情報
2. 代表者・専門家プロフィール
3. 何を提供するか
4. 誰に適するか
5. 誰に適さないか
6. 料金・算定方法
7. 契約・依頼の流れ
8. 必要書類・準備
9. 期間・納期
10. 対応地域
11. 比較時の判断基準
12. よくある失敗
13. リスク・副作用・限界
14. 事例
15. よくある質問
16. キャンセル・返品・解約
17. 相談・問い合わせ方法
18. 緊急時・対象外時の案内
19. 情報の根拠・監修
20. 更新日・訂正窓口

9.9やらない施策#

• 一般論だけの記事を毎日大量公開する
• AIが作った文章を専門家確認なしで公開する
• 実在しないレビュー、受賞、比較順位を作る
• 地域名だけを差し替えた類似ページを大量生成する
• すべてのAIボットを同じルールで扱う
• llms.txtや構造化データだけで引用が増えると期待する
• 一度のAI回答を順位として記録し、成果を断定する
• 引用数だけを追い、誤説明や不適合な問い合わせを無視する

11.1「大規模」の判定#

1万ページは絶対的な境界ではない。重要なのは、URL総数、更新頻度、重複率、応答性能、内部リンク、検索需要、データ鮮度である。Googleの公式クロールバジェットガイドは、100万ページ以上で週単位の更新、1万ページ以上で日次更新、または「Discovered - currently not indexed」が多いサイト等を高度な管理が必要になり得る例として挙げる［4］。

LLMOの観点では、通常検索の索引に入らない情報は、検索連携型AIの取得候補になりにくい。したがって、生成AI専用の小技より、重要URLを安定して発見・取得・索引化できる状態が先である。

11.2URL在庫台帳#

大規模サイトは、URLをページ単位ではなく、テンプレート・ディレクトリ・データ型単位で管理する。

URL台帳には、生成元、公開条件、廃止条件、最終更新、内部リンク数、検索流入、AI引用、事業価値を持たせる。

11.3クロール能力とクロール需要#

クロール量は、サーバーが耐えられる能力だけでなく、検索側が取得する価値を感じる需要にも左右される。重要な改善は次である。

• 5xx、タイムアウト、過度な遅延を減らす
• 重複・無価値URLを発生させない
• 重要ページへ明確な内部リンクを張る
• 実際に変更したURLの更新信号を正確に出す
• 古いURLを404または410で明確に廃止する
• リダイレクトチェーンを避ける
• 条件付きリクエストと304を適切に利用する
• sitemapのlastmodを実際の重要変更に合わせる

サイトマップは発見を助けるが、索引を保証しない［6］。大量のURLを送信すること自体を成果とせず、価値のあるcanonical URLだけを含める。

11.4ファセットナビゲーション#

EC、不動産、求人、旅行では、色、価格、地域、ブランド、並び順等の組合せが無限に近いURLを生む。Googleの公式ガイドも、ファセットが過剰クロールと新規ページ発見の遅延を招き得ると説明する［5］。

対策は次の順序で考える。

1. 検索需要と独自価値がある組合せを定義する
2. 索引対象のURL形式を固定する
3. 並び替え、表示件数、セッション等はURL在庫から除外する
4. 無効・空結果の組合せは明確に404とする
5. 不要なファセットのクロールをrobots等で抑える
6. 索引対象ページには固有の見出し、説明、内部リンクを与える
7. canonicalだけに過剰依存しない

robots.txtでクロールを拒否したURLにnoindexを置いても、クローラーがnoindexを読めない場合がある。クロール制御と索引制御を混同しない。

11.5重複とcanonical#

大規模サイトでは、同一商品、印刷版、追跡パラメータ、地域別、AMP、翻訳、転載等が重複を生む。canonicalは代表URLの信号だが、次も一致させる。

• 内部リンク先
• サイトマップ掲載URL
• hreflang参照
• 構造化データのURL
• フィードのランディングURL
• SNS・広告・メールの恒久URL

矛盾する信号を出すと、検索側の代表URL選択が不安定になる。

11.6JavaScriptとレンダリング#

重要な本文、価格、仕様、リンクがクライアント側JavaScriptの実行後にしか現れない場合、取得・レンダリング失敗が起きる。SSR、静的生成、プログレッシブエンハンスメント等を用い、少なくとも主要情報とナビゲーションが安定したHTMLで提供されることが望ましい。

確認項目は、初期HTML、レンダリング後DOM、遅延読込、無限スクロール、クリックしないと出ない本文、認証、Cookie同意、地域分岐である。

11.7ログ分析#

サーバーログは、宣言したサイト構造ではなく、実際の取得行動を示す。最低限、次をURL群別に集計する。

• 正規クローラー別リクエスト数
• 応答コード、応答時間、転送量
• 新規URLと既知URL
• 重要ページの再取得間隔
• パラメータ・無価値URLへの浪費
• sitemap掲載と実取得の差
• WAF遮断、レート制限、認証エラー

ユーザーエージェント名は偽装可能である。公式IP範囲、逆引き・正引き、署名方式等、各サービスが示す検証手段を利用する。GoogleはWeb Bot Authを実験的な認証方式として公開しており、従来のIP確認と併用する考え方がある［25］。

11.8AIクローラー別の制御#

OpenAIはOAI-SearchBot、GPTBot、ChatGPT-Userを区別し、PerplexityはPerplexityBotとPerplexity-Userを区別している［9］［11］。大規模サイトでは次を別々に決める。

• 検索・回答への出典掲載を許可する範囲
• モデル学習・改善への利用方針
• ユーザー指定取得を許可する範囲
• 認証後・有料・個人情報ページの扱い
• エージェント操作用APIの許可範囲
• レート制限と障害時の遮断条件

robots.txtだけで、契約、著作権、認証、個人情報、安全な操作をすべて制御できるわけではない。

12.1正本を先に作る#

LLMOの失敗は文章表現より、データの正本がないことから生じる。価格がWeb、営業資料、構造化データ、商品フィード、APIで異なれば、AIは正しい値を安定して選べない。

推奨構造は次である。

業務システム・専門家判断
        ↓
マスターデータ／公式事実レジストリ
        ↓
検証・承認・有効期間・出典
        ↓
CMS、PIM、DAM、ナレッジベース
        ↓
HTML、構造化データ、フィード、API、文書
        ↓
検索、RAG、AI回答、エージェント

12.2データモデルの必須属性#

公開する実体には次を持たせる。

• 永続ID
• 正式名称、別名、旧名
• 実体種別
• 属性と単位
• 関係する実体
• 情報源・作成者
• 有効開始・終了日時
• 最終確認日時
• 対象地域・言語
• 公開範囲
• リスク区分
• 更新責任者
• 廃止・統合先

時点を持たないデータは、古くなったときに判定できない。価格、在庫、制度、役職、診療時間、キャンペーンには特に有効期間が必要である。

12.3RAGに適した公開文書#

RAGで取得されやすくする目的で文章を機械的に短文化するのではなく、次を満たす。

• 見出しが質問・論点を明示する
• 代名詞だけに頼らず対象を特定する
• 数値に単位、通貨、税、対象期間を付ける
• 条件、例外、対象外を同じ節に置く
• 主張の近くに出典を置く
• 表には列見出し、注記、前提を付ける
• 更新日と変更内容を示す
• ページ固有の要約と結論を持つ
• PDFだけでなくHTMLでも重要情報を提供する

引用評価研究ALCEは、回答品質を流暢さだけでなく、引用の正しさや主張への支持で評価する枠組みを提示する。RAGASも、検索された文脈の関連性、回答の忠実性等を評価する［13］［14］。企業側も、単に自社URLが引用されたかではなく、引用が主張を本当に支えるかを確認すべきである。

12.4検索、ベクトル、グラフの役割#

一つの方式に統一せず、質問の種類に応じて組み合わせる。

12.5プロベナンス#

プロベナンスは、情報がどこから来て、誰が変更し、どの処理を経たかという来歴である。最低限、次を追跡する。

• 原資料
• 抽出・計算方法
• 著者・監修者
• 承認者
• 公開版
• 修正履歴
• AI回答で利用された版

高リスク情報では、AI回答の誤りを直すだけでなく、誤った元データを特定しなければ再発する。

12.6AIエージェント対応#

UI層

• セマンティックな見出し、ボタン、リンク、フォーム
• 明確なラベルとエラー説明
• キーボード操作とアクセシビリティ
• 価格、在庫、取消条件の可視化
• 重要操作前の確認

API層

• 明確なスキーマとバージョン
• 認証・認可
• 最小権限
• 冪等性キー
• レート制限
• 取消・返金・ロールバック
• 操作結果と理由コード
• 監査ログ

安全層

• ユーザー同意
• 高額・不可逆操作の再確認
• 個人情報最小化
• プロンプトインジェクション対策
• 外部コンテンツを命令として扱わない分離
• ボット認証
• 不正検知

AIエージェントに人と同じ画面を操作させるだけでなく、取引が重要な場合は、明示的なAPIや標準プロトコルを検討する。Googleはエージェント型コマース向けUCPを公開しており、商品・決済・注文等の相互運用を目指している［16］。採用はサービス要件と成熟度を評価して決める。

13.1別々の施策リストにしない#

GEO、AEO、SEOを別部署・別記事・別KPIで完全分離すると、重複投資が起こる。統合モデルは次のとおりである。

技術SEO：発見・取得・索引
    ↓
情報設計：対象・意味・関係・時点
    ↓
AEO：質問への直接回答・構造
    ↓
GEO：生成回答内の引用・言及・寄与
    ↓
LLMO：ブランド、データ、行動、成果、リスクを統合

Googleの公式説明では、生成AI検索でも従来のSEO基礎が有効で、AI専用の特別な構造化データは必要とされていない［2］［3］。したがって「GEOのためにSEOを捨てる」のではなく、検索可能性と独自価値を基盤に、回答・引用・行動を追加する。

13.2GEO研究の実務的解釈#

GEO論文では、引用、統計、権威的な文体等の施策が実験条件下で可視性へ影響し、効果は領域で異なった［1］。実務では次のように解釈する。

• 引用を増やすために無関係な文献を付けない
• 数値を増やすために出所不明の統計を使わない
• 権威的に見せるために断定を強めない
• 対象分野、質問意図、根拠品質別に実験する
• 現在の複数AIで再評価する

研究結果は「万能なランキング要因一覧」ではなく、検証すべき仮説の源泉である。

13.3AEOの実装単位#

AEOはFAQページだけではない。次の形式を使い分ける。

• 定義
• 手順
• 比較表
• 選定基準
• 条件分岐
• 計算例
• リスク・例外
• チェックリスト
• トラブルシューティング
• 次の行動

回答を短くすることより、質問に対する結論、根拠、条件、例外が近接していることが重要である。

14.1エンティティとは何か#

エンティティは、企業、人物、商品、店舗、制度、場所、研究等の識別可能な実体である。キーワードが文字列であるのに対し、エンティティには属性と関係がある。

例：

企業A ─提供する→ サービスB
企業A ─運営する→ 店舗C
人物D ─所属する→ 企業A
人物D ─監修する→ 記事E
サービスB ─対象とする→ 業界F

W3CのRDFは、主語・述語・目的語の三つ組でグラフを表現する標準である［15］。公開サイトがRDF基盤を必ず導入すべきという意味ではないが、実体と関係を明確にする考え方として有用である。

14.2エンティティホーム#

重要な実体には、正本となる恒久URLを設ける。

• 会社：公式概要、沿革、識別子、ブランド、拠点
• 人物：資格、所属、担当、経歴、執筆・監修
• 商品：型番、仕様、価格、在庫、後継、サポート
• 店舗：住所、時間、サービス、予約
• 研究：目的、方法、対象、結果、データ、限界

URLを頻繁に変えず、旧URLから恒久転送し、内部・外部の参照先を統一する。

14.3構造化データ#

Schema.org等の構造化データは、ページの内容や実体を機械が理解する助けとなる。ただし、本文にない主張を構造化データだけで追加しない。Googleも、構造化データは可視内容と一致すべきと説明する［7］。

組織では、正式名称、URL、ロゴ、連絡先、識別子、関連プロフィール等を整備する［27］。商品では、名称、ブランド、SKU、GTIN、価格、在庫、レビュー等を、実際の表示やフィードと一致させる。

14.4sameAsの注意#

sameAsは、同一実体を示す参照に使う。関連するだけのページ、非公式プロフィール、同名他社、販売代理店を無差別に指定すると誤同定を招く。登録前に、運営主体、名称、所在地、識別子、公式リンクを確認する。

14.5エンティティ解決#

同名異人、旧社名、ブランドと法人、製品世代、店舗移転を解決するには、名称だけでなく、識別子、所在地、期間、関係を使う。

衝突解決順序

1. 法令・登記・契約・公式DB等の一次資料
2. 社内マスター
3. 公式サイト
4. 信頼できる第三者資料
5. 一般投稿・推測

どの資料を優先したかを記録する。

14.6ナレッジグラフ成熟度#

ナレッジグラフの整備状況は、次の五段階で捉えると投資判断がしやすい。段階を飛ばさず、名称の統一から順に進める。

14.7小規模サイトにグラフDBは必要か#

必ずしも必要ではない。数十の実体なら、CMSのカスタム項目、表計算、JSON、構造化データでも管理できる。重要なのは製品を導入することではなく、同じ実体を同じIDで扱い、属性・関係・時点・根拠を矛盾なく管理することである。

16.1LLMOの戦略目的#

ECのLLMOは、商品名を回答に出すことだけではない。ユーザーの条件に適した商品を正確に比較し、価格、在庫、配送、返品、互換性を確認し、安全に購入へ進める状態を作ることである。

16.2規模別重点#

• 小規模EC：独自商品、用途、選び方、職人・開発者の知見、地域性を強化
• 中規模EC：カテゴリ、属性、比較、レビュー、在庫・価格同期を標準化
• 大規模EC・モール：PIM、GTIN、SKU、ファセット、フィード、リアルタイム在庫、不正レビュー、エージェント取引を統制

16.3商品データ#

商品には次を統一する。

• 商品名、ブランド、型番、SKU、GTIN
• バリエーションと親子関係
• 用途、対象者、適合条件、非適合条件
• 仕様、寸法、重量、材質、互換性
• 価格、税、セール期間、在庫
• 配送、返品、保証、修理
• 画像、動画、取扱説明書
• レビューの対象商品と集計方法

Googleは、商品構造化データとMerchant Centerフィードを組み合わせることで、商品情報の理解と鮮度を高められると案内する［8］。ページ、構造化データ、フィードの価格・在庫が一致しなければ、ユーザー体験とデータ信頼性を損なう。

16.4回答コンテンツ#

商品説明の形容詞を増やすより、次を明示する。

• どの用途に向くか
• どの条件では向かないか
• 競合カテゴリとの違い
• 選定時に見るべき属性
• 使用・保守・安全上の注意
• 実測データと測定条件
• 返品が起きやすい誤解

16.5エージェント対応#

在庫確認、価格、配送先適合、カート、決済、注文変更を機械的に扱う場合、認証、冪等性、確認、取消、監査が必要である。会話だけで購入が完了する環境では、古い価格を回答するより、最新データをAPIから取得する設計が重要になる。OpenAIも、商品フィードが価格・在庫等の精度と鮮度の制御に役立つと案内している［26］。

16.6LLMOのKPI#

正確商品言及率、適合条件言及率、価格・在庫一致率、商品引用率、比較採用率、商品詳細到達、カート追加、購入、返品率、誤推薦率、エージェント操作成功率。

17.1LLMOの戦略目的#

メディアの価値は、既存情報の言い換えではなく、取材、検証、独自データ、解説、記録、訂正にある。生成AIが要約するほど、情報源としての差別化が重要になる。

17.2必須情報#

• 発行主体と編集方針
• 著者、編集者、監修者
• 公開日時、更新日時、訂正履歴
• 原資料、取材対象、データ
• 事実と意見の区別
• 利益相反、広告、タイアップ表示
• 引用・転載・ライセンス方針

17.3規模別重点#

• 小規模専門媒体：一分野の深い取材、専門家ネットワーク、原資料リンク
• 中規模媒体：トピック台帳、著者・出典管理、更新・訂正SLA
• 大規模媒体：ニュースサイトマップ、アーカイブ、重複配信、シンジケーション、権利ライセンス、クローラー目的別方針

17.4AI時代の編集#

速報と恒久解説を分ける。速報ページを更新し続けて論点が混在する場合は、時系列、現在の結論、未確定事項を明示する。調査記事では、調査票、対象期間、サンプル、欠測、限界を公開する。AI生成の下書きを利用しても、取材・事実確認・責任は人が担う。

17.5LLMOのKPI#

原典引用率、記事引用率、著者認識率、訂正率、引用の主張支持率、指名検索、会員登録、再訪、ライセンス収益、誤要約インシデント。

18.1LLMOの戦略目的#

SaaSでは、マーケティングページだけでなく、技術文書、API、セキュリティ、料金、統合、障害情報が意思決定に使われる。AIが旧バージョンの仕様を引用すると、導入失敗やサポート負荷につながる。

18.2情報層#

1. 製品概要と対象課題
2. 機能、制約、対応環境
3. 料金、契約、上限
4. 導入・移行・運用
5. API・SDK・サンプル
6. セキュリティ、プライバシー、認証
7. ステータス、変更履歴、廃止予定
8. 導入事例と測定方法

18.3バージョン管理#

• ドキュメントに対象バージョンを表示
• 最新版と旧版のcanonical・ナビゲーションを整理
• 非推奨・廃止APIに移行先と期限を表示
• changelogを構造化し、日付・影響・対応を明示
• コード例を自動テストする
• 料金・機能比較表をマスターから生成する

18.4BtoD・開発者向けLLMO#

開発者は、自然言語質問と正確なシンボル名の両方を使う。概念説明、APIリファレンス、エラーコード、実行可能な例、トラブルシューティングを相互リンクする。GitHub、公式ドキュメント、サポート回答、マーケページの矛盾を監視する。

18.5LLMOのKPI#

正確機能言及率、バージョン誤回答率、API引用率、ドキュメント到達、コード成功率、デモ申込、試用開始、適格商談、サポート削減、廃止API利用率。

19.1LLMOの戦略目的#

BtoBでは、検索量が小さくても一件の商談価値が大きい。LLMOはトラフィック最大化より、複雑な要件を整理し、自社が適合する条件と適合しない条件を正確に説明することが重要である。

19.2必須コンテンツ#

• 業界・業務課題の定義
• 選定基準とRFP項目
• 対応範囲、非対応範囲
• 導入条件、期間、体制
• セキュリティ、品質、認証、規格
• 価格構造、TCO、契約単位
• 導入事例、測定指標、前提
• 移行、教育、保守、障害対応
• 競合カテゴリとの違い

19.3導入事例の品質#

「売上が向上した」とだけ書かず、導入前課題、対象部門、期間、変更内容、測定方法、外部要因、顧客コメント、再現条件を示す。顧客名非公開でも、業種、規模、条件を匿名化して提示できる。

19.4製造業のデータ#

型番、仕様、公差、材料、規格、用途、代替品、CAD、SDS、証明書、保守部品を管理する。販売終了製品は削除するだけでなく、後継、保守期限、互換性、問い合わせ先を示す。

19.5LLMOのKPI#

対象アカウント言及率、選定基準引用率、適合条件正確性、ホワイトペーパー取得、デモ、RFP参加、商談適格率、受注、営業期間、誤適合問い合わせ率。

20.1LLMOの最優先事項#

医療では可視性より、患者安全、正確性、適用範囲、広告規制、プライバシーを優先する。厚生労働省は医療広告に関するガイドライン、Q&A、事例解説書等を公開しているため、公開時点の最新版を確認する［22］。

20.2情報設計#

• 疾患・症状の一般情報と個別診断を区別
• 緊急性の高い症状は受診・緊急連絡を明示
• 診断・治療の対象、禁忌、限界、不確実性を表示
• 医師・資格者の氏名、資格、担当範囲を示す
• 研究結果に対象、比較群、期間、限界を付ける
• 費用、保険適用、自由診療を区別
• 症例・体験談の表示を法務・倫理面から審査
• 更新日と医学的レビュー日を分ける

20.3規模別重点#

• 診療所：診療科、対応症状、受付、予約、費用、緊急時、地域情報
• 病院：診療部門、専門医、紹介、検査、入院、地域連携、更新統制
• 医療メディア：エビデンス階層、編集独立性、監修、訂正
• 製薬・医療機器：承認範囲、適正使用、安全性、規制審査、版管理

20.4評価#

引用率単独ではなく、医学的正確性、適用条件、危険な省略、受診勧奨、出典品質、更新日、広告表現を専門家が評価する。

20.5LLMOのKPI#

正確回答率、危険省略率、専門家レビュー合格率、予約完了、適切な診療科到達、誤予約、苦情、規制指摘、個人情報事故。

21.1LLMOの戦略目的#

法律情報は、法域、時点、事実関係で結論が変わる。一般情報と個別助言を明確に区別し、資格者の責任範囲、適用法、基準日を示す。弁護士広告では、日本弁護士連合会の規程・指針等、対象業務の現行ルールを確認する［23］。

21.2情報設計#

• 対象国・地域・裁判管轄
• 法令・制度の基準日
• 一般原則、例外、争いのある論点
• 手続、期限、必要資料
• 費用の算定方法と追加費用
• 成功を保証しないこと
• 判例・公的資料の出典
• 執筆者・監修者の資格と担当
• 個別相談が必要となる条件

分野によって、利用者が最初に確認したい条件は異なる。例えば交通事故では時効、過失割合、保険会社との交渉段階が判断を左右し、相続では期限、必要書類、相続人の範囲が手続の可否を決める。分野ごとに適用法域、基準日、手続の期限、必要資料、費用の算定方法を明示し、一般情報と個別助言の境界を崩さないことが、AI回答経由の相談でも誤解を防ぐ。

21.3大量地域ページの注意#

地域名だけを差し替えたページを大量生成すると、重複・品質・広告表現の問題が起きる。地域ごとの裁判所、相談窓口、手続差、統計、交通、実務上の注意等、実質的な差がある場合に限り、固有ページを作る。

21.4LLMOのKPI#

法的正確性、法域・基準日明示率、根拠引用率、誤解を招く保証表現、相談適格率、必要資料準備率、予約、受任、苦情、訂正。

22.1LLMOの最優先事項#

金融情報は、収益可能性だけでなく、損失、手数料、流動性、期間、適合性、利益相反を説明する。金融庁の監督指針その他の現行規制、所属業界の自主規制、各商品の法的要件を確認する［24］。

22.2情報設計#

• 商品・サービスの法的区分
• 対象顧客と不適合条件
• 元本割れ、信用、価格変動、為替、流動性等のリスク
• 手数料、税、解約、期間
• 想定・シナリオ・算定方法
• 過去実績が将来を保証しないこと
• 情報基準日と市場データ時点
• 広告・分析・助言の区別
• 利益相反と報酬関係

22.3データ鮮度#

金利、価格、為替、基準価額、キャンペーン条件は記事更新では追いつかないことがある。正本DB、API、タイムスタンプ、キャッシュ期限、異常検知を使い、取得不能時に古い値を無条件で表示しない。

22.4AI回答評価#

「おすすめ」だけでなく、前提となるリスク許容度、期間、目的、流動性需要が回答に含まれるかを確認する。商品推薦の可視性向上より、不適合な推薦の抑制を優先する。

22.5LLMOのKPI#

情報時点正確率、リスク説明完全率、手数料一致率、適合条件言及率、申込完了、適合性エラー、苦情、訂正、規制事故。

24.1LLMOは単一順位では測れない#

生成AI回答は、モデル、検索状態、地域、言語、日時、会話履歴、質問表現で変動する。したがって、検索順位のような一つの数字ではなく、質問集合、反復回数、回答品質、引用、ブランドの扱い、行動、事業成果をまとめて評価する。

24.2プロンプトユニバース#

プロンプトユニバースとは、顧客が尋ね得る質問を、評価可能な母集団として体系化したものである。次の層で抽出する。

• 意思決定段階：認知、学習、比較、適合、信頼、行動、継続
• ペルソナ：初心者、専門家、経営者、購買、患者等
• 商品・サービス・課題
• 地域、言語、端末
• 条件：価格、規模、期限、規制、既存環境
• 質問形式：定義、手順、比較、推薦、否定、例外
• ブランド有無：非指名、カテゴリ指名、競合比較、指名

事業価値、リスク、質問機会に応じて層化抽出し、重要群は毎回固定し、探索群は定期的に入れ替える。

24.3可視性指標#

言及率 = 自社実体が正しく言及された回答数 ÷ 評価回答数
引用率 = 自社URLが出典として示された回答数 ÷ 引用可能な評価回答数
推薦率 = 自社が選択肢として推薦された回答数 ÷ 推薦型回答数
第一推薦率 = 自社が最優先候補になった回答数 ÷ 推薦型回答数
引用シェア = 自社引用数 ÷ 対象回答内の全競合引用数

引用可能な評価回答数を分母にするのは、回答自体が引用を表示しない場合や、単純計算等で外部出典が不要な場合を区別するためである。

24.4AI Share of Voice#

単純な出現回数では、低価値質問と高価値質問が同じ重みになる。重み付きAI Share of Voiceを用いる。

AI-SOV = Σ（質問重み × 自社可視性得点）
         ÷ Σ（質問重み × 全比較対象の可視性得点）

可視性得点の例：第一推薦3、候補2、言及1、なし0。質問重みは事業価値、質問機会、意思決定への近さ、リスクで定める。重みの決め方を公開し、都合よく変更しない。

24.5品質指標#

• 主張正確率：評価した事実主張のうち正しい割合
• エンティティ正確率：同名他社、人物、商品を混同しない割合
• 引用支持率：引用先が直前・対応する主張を実際に支持する割合
• 引用完全率：重要主張のうち根拠が示された割合
• 条件完全率：対象、例外、時点、地域、単位等が含まれる割合
• 鮮度適合率：最新の有効情報が使われた割合
• 不確実性適正率：不明・争い・推定を断定しない割合
• 有害省略率：医療・金融等で重要な警告が欠落した割合

ALCEやRAGASが示すように、流暢な文章と、根拠に忠実な回答は別に評価すべきである［13］［14］。

24.6行動・事業指標#

• AI参照セッション
• 指名検索、直接訪問、電話・来店
• 問い合わせ、予約、購入、試用、資料取得
• 適格問い合わせ率、商談化率、受注率、粗利
• サポート自己解決率、対応時間削減
• エージェント操作成功率、取消率、二重処理率
• 誤推薦、不適合、返品、苦情、訂正、規制事故

OpenAIはChatGPT検索からの参照URLにutm_source=chatgpt.comを付けると説明しているが、すべてのAI接点やアシストを直接計測できるわけではない［10］。アクセス解析、CRMの流入自己申告、会話記録、指名検索、時系列・地域比較を組み合わせる。

24.7実験設計#

1. モデル名、機能、地域、言語、日時を記録する
2. 重要質問は複数回実行する
3. 新規会話と会話継続を分ける
4. 施策対象群と対照群を作る
5. 回答全文、引用URL、スクリーンショットまたは構造化記録を保存する
6. 自動採点だけでなく、重要回答を専門家が監査する
7. 変更前後だけでなく、競合・季節・モデル更新を考慮する
8. 小さな差を断定せず、信頼区間または変動幅を示す

24.8ダッシュボード#

25.10〜3か月：把握と基礎#

• O-W-D-G分類と重要事業の選定
• 主要100〜500質問のベースライン
• URL、データ、外部プロフィールの棚卸し
• robots、noindex、canonical、サイトマップ、WAFの確認
• 会社・人物・商品・店舗の正本整備
• 高リスク誤情報と古い情報の修正
• KPI、責任者、訂正手順の決定
• AI参照流入とCRM項目の計測開始

成果物： 診断報告、分類コード、優先順位表、プロンプトユニバースv1、公式事実台帳、技術修正一覧、リスク台帳。

25.23〜6か月：実装と実験#

• 高価値クラスターの回答コンテンツ・事例・比較を整備
• 著者・監修・出典・更新履歴を標準化
• 構造化データ、商品・店舗フィード、内部リンクを改善
• 1万ページ以上ではログ分析、ファセット、URL廃止を実施
• 主要第三者情報との不一致を修正
• 90日実験を複数実行
• AI回答の正確性・引用支持を人手監査
• 中堅・大企業では運営委員会とRACIを稼働

成果物： テンプレート、公開知識セット、技術リリース、実験結果、ダッシュボードv1、訂正SLA。

25.36〜12か月：統合と拡張#

• CMS、PIM、CRM、ナレッジ、APIの共通ID連携
• 多言語・多ブランド・複数事業への展開
• プロベナンスと有効期間の自動管理
• AIエージェント向けUI・API・安全設計
• 外部調査、専門家連携、デジタルPRを継続
• 因果推論・地域比較等で事業寄与を推定
• リスク演習、内部監査、ベンダー監査
• 低価値・重複・古いコンテンツを統合・廃止

成果物： 統合データモデル、AI対応API、全社標準、ダッシュボードv2、年次評価、次年度投資計画。

25.4規模別の重点#

26.1代表的な失敗#

26.2リスク台帳#

各リスクに、原因、影響、発生可能性、検知方法、予防、対応、所有者、期限を持たせる。最低限のカテゴリは次である。

• 事実誤り・古い情報
• 別実体混同
• 著作権・商標・ライセンス
• 個人情報・営業秘密
• 広告・専門職規制
• 偽装ボット・過負荷
• プロンプトインジェクション
• 不正レビュー・なりすまし
• エージェント誤操作
• ベンダー・外部API停止
• 計測バイアス・過剰な成果主張
• ブランド危機・訂正遅延

26.3ガードレール指標#

成長KPIと同時に、次を上限管理する。

• 重大事実誤り件数
• 高リスク未監修ページ数
• 価格・在庫不一致率
• 不適合推薦率
• 個人情報事故
• 操作重複率
• 規制・権利指摘
• 訂正完了時間

27.1最低限必要な八機能#

1. 戦略・経営：目的、対象、予算、優先順位
2. SEO・検索技術：クロール、索引、構造、ログ
3. 編集・コンテンツ：質問体系、論理、品質、更新
4. 対象分野の専門家：判断、一次情報、監修
5. データ・エンティティ：正本、ID、関係、フィード、API
6. 計測・実験：質問集合、採点、分析、事業接続
7. ブランド・外部信頼・UX：第三者評価、行動導線
8. 法務・安全・PM：権利、規制、セキュリティ、進行

一人が兼務してもよいが、機能を消してはならない。

27.2規模別編成#

小規模

経営者兼戦略責任者、業界専門家、編集・Web担当の3人を核とし、技術、法務、計測、PRを必要時に外部利用する。

中堅

専任のLLMO/SEO責任者、編集、対象分野専門家、Web/データ、分析、広報、法務をコアチーム化し、四半期ごとに事業責任者が投資判断する。

エンタープライズ

経営スポンサー、中央CoE、事業スポーク、データ・プラットフォーム、法務・リスク、セキュリティ、広報、分析をハブ・アンド・スポークで配置する。高リスク分野は独立レビューを設ける。

27.3採用・外注の評価#

肩書きではなく、次を確認する。

• SEO、RAG、生成AIの違いを説明できるか
• 検索掲載、学習、ユーザー取得、操作を分けられるか
• 出典と限界を示せるか
• サーバーログ、CMS、データ、法務を横断できるか
• 可視性だけでなく事業成果とリスクを測れるか
• 不確実な点を断定しないか
• 自社の一次情報を引き出せるか
• ベンダーロックインとデータ持出しを説明できるか

27.4プロジェクトの完了条件#

LLMOは一度の公開で完了しない。成熟した運用の完了条件は、「継続運用へ移管できること」である。

• 責任者と予算がある
• 定期評価が自動・半自動で回る
• 重大誤りを検知・訂正できる
• データの正本と有効期間が管理される
• 新商品・法改正・組織変更へ追随できる
• AIサービス変更時に評価セットを更新できる
• 事業価値とリスクを経営へ報告できる