LLMOを内製する社内体制｜7役割・RACI・週次運用テンプレート

結論：7人を採用するのではなく、7つの責任を割り当てる

最小構成でも必要なのは、LLMO専任7人ではなく、誰が最終判断し、誰が実行し、誰へ確認するかが決まった状態です。小規模企業では1人が複数の役割を兼ねられます。ただし、事実を作る人と公開を承認する人、変更を実装する人と結果を判定する人を、可能な範囲で分けます。

中心にはLLMO責任者を1人置きます。責任者はすべての作業を自分で行う人ではなく、対象質問、優先順位、公開可否、再計測、次の判断を止めない人です。SEOだけ、広報だけ、開発だけへ丸投げすると、その部署が持っていない情報で施策が止まります。

• 7役割は職種名ではなく、欠かせない責任の一覧
• 最終責任者は1人にし、会議体だけを責任者にしない
• 兼務は可能だが、承認者と実行者を記録する
• 外注しても、事業事実と公開可否の責任は社内に残す
• 担当者名、期限、証拠URL、判断を同じ台帳へ残す

なぜLLMOをSEO担当だけの仕事にしないのか

AI回答は、自社サイトの記事だけでなく、サービスページ、会社情報、ヘルプ、外部メディア、レビュー、公開プロフィールなど複数の情報を組み合わせます。検索流入を分析できても、価格、対象顧客、提供範囲、法的表現、第三者情報をSEO担当者だけでは確定できません。

LANYがWebマーケティング歴3年以上の企業経営者・役員100名へ行った2025年8月の調査では、LLMO推進上の最大課題として「専門人材不足」20%、「実施ロードマップが描けない」11%、「組織全体の理解・浸透」11%が挙げられました。回答者集団の傾向であり一般化はできませんが、知識だけでなく責任と進め方が課題になっていることを示す材料です。

Semrushが有効回答481人を対象にした2026年調査では、SEOとAI検索を戦略・実行・報告まで完全統合したとの回答は22%でした。AI検索の責任は複数部門へ分散し、明確な所有者がいない回答も確認されています。これもベンダー調査であり因果関係の証明ではありませんが、別チームを増やすより共通の運用を作るという仮説を支持します。

役割1：LLMO責任者

LLMO責任者は、事業目標と検索・AI回答の観測を接続します。対象顧客、候補になりたい課題、誤ると重大な事実、競合、対象地域・言語を決め、施策の優先順位と中止判断に責任を持ちます。

毎週の会議では、スコアの上下だけでなく、どの質問で何が変わり、顧客判断へどう影響し、どの証拠で次の作業を選んだかを確認します。検索順位やAI掲載を保証する目標ではなく、観測可能な改善目標を承認します。

• 事業目標、対象質問、対象AI、対象地域の承認
• 優先順位、予算、担当、期限の決定
• 公開・延期・中止と再計測の最終判断
• 経営・営業・顧客対応への報告

役割2：検索・AI可視性の計測担当

計測担当は、Google検索とAI回答を同じものとして混ぜず、比較可能な基準線を作ります。Search Consoleではクエリ、ページ、クリック、表示回数、CTR、平均掲載順位を確認し、AI回答では質問、サービス、画面上のモデル、検索条件、日時、回答全文、引用URL、判定を保存します。

一回の手動質問を一般的な掲載率と呼ばず、指名、非指名、比較、事実確認を分けます。質問文や条件を変えた場合は、同じ系列として上書きせずバージョンを残します。障害や利用制限は結果0へ混ぜず、除外理由を記録します。

• 質問台帳と測定条件の管理
• 回答ログ、引用URL、判定根拠の保存
• Search ConsoleとAI経由流入の確認
• 母数、欠損、除外、変更履歴の管理

役割3：事業・製品の情報責任者

事業・製品担当は、AIへ見せたい表現を作るのではなく、公開可能な正しい事実を確定します。対象顧客、機能、価格条件、提供地域、制約、導入条件、更新日、正式名称を一つの情報台帳で管理します。

営業資料、サービスページ、ヘルプ、プレスリリースで説明が異なる場合、どれが現行かを決めるのはこの役割です。公開情報の不足を見つけたら、新しいページが必要か、既存ページの更新で足りるかを判断します。

• 会社・サービス・製品の正本となる情報台帳
• 重要事実の確認者と更新期限
• 廃止情報、例外条件、対象外顧客の明示
• 営業、サポート、Web間の説明差の解消

役割4：コンテンツ・編集担当

編集担当は、質問台帳と事業の一次情報を、人が理解し判断できるページへ変換します。検索語を繰り返すのではなく、結論、条件、比較軸、根拠、限界、更新日を明確にします。

生成AIは調査候補や構成整理に使えますが、Googleは価値を加えない大量生成がスパムポリシーへ抵触し得ると案内しています。編集担当は、出典確認、独自材料、読者の意思決定、公開後の更新責任を受け入れ条件に含めます。

• コンテンツ企画、検索意図、中心ページの管理
• 事実確認、出典、著者・編集責任、更新日の確認
• 類似ページ、誇張、無断転用、薄い大量生成の防止
• サービス、診断、問い合わせへの自然な内部リンク

役割5：Web・技術担当

Web担当は、内容が公開HTMLとして取得でき、正しいURLと状態コードで配信されるようにします。robots.txt、サイトマップ、canonical、タイトル、見出し、内部リンク、構造化データ、JavaScriptレンダリング、速度、計測タグを確認します。

構造化データやllms.txtを入れただけで引用されるとは扱いません。実装前後の差分、テスト、公開URL、ロールバック方法を残し、検索エンジンやAI検索の取得条件とコンテンツの品質を分けて診断します。

• クロール、インデックス、HTML、内部リンクの技術確認
• 構造化データと公開URLの検証
• 変更差分、テスト、公開確認、ロールバック
• Search Console、アクセス解析、問い合わせ計測の実装

役割6：広報・外部情報担当

広報担当は、自社サイト外で会社やサービスがどう説明されているかを管理します。公式プロフィール、パートナー一覧、業界団体、取材記事、登壇資料、レビューサイトなど、管理可能な情報の更新先と担当を整理します。

目的は大量の被リンクや偽レビューではありません。公式情報と第三者情報の不一致を見つけ、事実に基づいて訂正を依頼し、公開価値のある調査、専門家コメント、事例を正しい権利処理で発信します。広告、寄稿、取材、自然掲載の区別も記録します。

• 外部プロフィールと第三者掲載の棚卸し
• 古い名称、価格、機能、所在地などの訂正
• 調査、事例、専門家発信、PRの計画
• 広告・提供・紹介料・編集記事の関係開示

役割7：法務・セキュリティ・品質確認

法務・セキュリティ担当は、公開前に顧客情報、契約情報、著作権、商標、個人情報、規制表現、比較広告、機密情報を確認します。すべての記事を長い承認工程へ入れるのではなく、リスク区分と期限を先に決めます。

AI回答ログを保存する場合も、入力した機密、顧客名、個人情報、利用規約を確認します。生成AIによる要約や下書きでは、出典の誤認、存在しない事例、他社表現の近似、権利不明な画像を公開しない受け入れ条件を設けます。

• 公開可能情報と機密情報の境界
• 個人情報、著作権、商標、規制、比較表現の確認
• AIサービスへ入力できる情報と保存期間
• 高リスク変更の承認者、期限、差し戻し条件

RACIで作業と責任を同じ表にする

RACIは、実行するResponsible、最終責任を持つAccountable、事前に相談するConsulted、結果を共有するInformedを作業ごとに決める方法です。LLMOでは「記事担当」「SEO担当」と人だけを並べず、基準線作成、事実確定、技術実装、公開承認、再計測などの成果物単位で割り当てます。

一つの作業にAccountableを複数置くと、最終判断が会議へ戻ります。原則としてAは一つにし、実行者R、相談先C、共有先Iを必要最小限にします。兼務する場合はARと記録し、自己承認が高リスクになる作業だけ別の確認者を置きます。

配布CSVには、13の活動、成果物、7役割、受け入れ条件の例を収録しています。会社の部署名へ置き換え、空欄を埋めることより、Aが不在の作業と、Rが期限内に実行できない作業を先に見つけます。

週次30分会議は観測・判断・担当だけに絞る

週次会議を勉強会や記事案の発散だけで終わらせません。事前に回答ログ、Search Console、公開変更、事実変更、外部掲載を更新し、会議では異常、優先順位、受け入れ、担当、期限を決めます。

最初の5分で基準線と障害を確認し、次の10分で重要質問の変化と原因仮説、次の10分で公開変更の受け入れと優先バックログ、最後の5分で承認待ちと担当・期限を読み上げます。データがない週も、何も起きなかったのか、取得できなかったのかを分けます。

• 0〜5分：データ取得状態、重大な誤情報、障害
• 5〜15分：重要質問、検索クエリ、競合・引用元の変化
• 15〜25分：公開変更の受け入れ、次の優先作業
• 25〜30分：承認待ち、担当、期限、再計測日

90日は三つの判断ゲートに分ける

1〜30日目は、目標、対象質問、正しい公式情報、測定条件、技術基盤を確定します。記事数を増やす前に、重要事実の欠損と取得不能を分け、基準線を保存します。完了条件は、全体スコアではなく、質問台帳、回答ログ、事実台帳、技術監査が再利用できることです。

31〜60日目は、事業影響が大きい欠損から直します。サービス・製品ページ、ヘルプ、比較材料、一次情報、内部リンク、構造化データ、外部プロフィールを担当別に更新します。変更ごとに公開URL、差分、確認者、対象質問、再計測日を残します。

61〜90日目は、同じ条件で再計測し、変化しなかった項目も報告します。続ける施策、中止する施策、追加検証、外部支援が必要な領域を決め、次の90日へ引き継ぎます。90日で順位や引用を保証する計画ではなく、自社で判断を回せる運用を作る計画です。

成果物の受け入れ条件をRACIと接続する

RACIは誰が実行・承認するかを決めますが、それだけでは「記事を作成」「計測を実施」のような曖昧な完了報告が残ります。各作業IDへ、成果物、証拠、確認者、受け入れ条件を接続し、次の担当者が同じ条件で確認できた時点を完了とします。

ベースライン計測では、質問ID、対象AI、検索機能、日時、地域、会話条件、回答全文、引用URL、有効・除外の判定を保存します。技術点検では、対象URL、HTTP状態、canonical、index可否、HTMLリンク、構造化データと表示内容の一致、確認日を記録します。

コンテンツは、主張の出典、対象期間、母数、条件、限界、一次情報の確認者を確認します。公開実装は本番URLのHTTP 200、タイトル、H1、内部リンク、更新日、変更履歴、ロールバック方法を確認します。再計測と月次報告では、基準線と同じ条件、変化なし・不明を含む判定、次に検証する仮説を残します。

• Aは原則1人、Rが不在の作業は着手しない
• 受け入れ条件を満たした証拠URLまたは保存場所を記録する
• 障害・利用制限・欠損は結果0へ混ぜず、未取得として扱う
• 順位、言及、引用、正確性、流入、問い合わせを一つの点数へ混ぜない
• RACI、受け入れ条件、90日台帳を共通の作業IDで接続する

内製・外注・共同運用を成果物で選ぶ

完全内製が向くのは、事業事実を確定できる人、Webを変更できる人、編集・計測を続ける時間があり、試行錯誤を社内資産にしたい場合です。外部の診断や助言がなくても、観測条件と判断基準を説明できる必要があります。

共同運用は、社内が事実・承認・実装の一部を持ち、外部が質問設計、基準線、技術監査、編集、再計測を補う形です。外注範囲は「LLMO対策一式」ではなく、成果物、データ形式、公開作業、受け入れ条件、再計測、契約終了時の引き継ぎで定義します。

全外注が必要でも、対象顧客、公式事実、公開承認、契約・権利、成果物の受け入れ責任は社内に残ります。質問一覧、回答全文、引用URL、変更差分、ソースファイルを持ち出せない契約では、終了後に内製へ移行しにくくなります。

外部支援の受け入れ条件

提案書のページ数や独自スコアだけで完了とせず、次の担当者が再現できる成果物を受け取ります。診断では質問と条件、実装では変更差分と公開URL、コンテンツでは出典と更新責任、再計測では同じ母集団と除外条件を確認します。

公開できる顧客事例がない支援会社でも、自社実験、生データ、調査方法、失敗結果、サンプル成果物から判断できます。反対に、大きな改善率があっても、開始値、質問数、期間、対象AI、他施策、計算式が不明なら自社へ再現できる証拠にはなりません。

• 編集可能な質問台帳、回答ログ、引用URL
• 課題、優先度、担当、期限、受け入れ条件
• コード・記事の変更差分、公開URL、テスト結果
• データと制作物の所有権、持ち出し、解約条件
• 再計測日、同一条件、変更条件、除外試行

小さく始める最小構成

担当者が少ない会社では、事業責任者がLLMO責任者と事業情報を兼務し、Web担当が計測と技術、編集担当がコンテンツと広報を兼務できます。法務・セキュリティは高リスク項目だけ既存の確認者へ依頼します。

最初から全AI、全事業、全言語を対象にしません。一つのサービス、一つの地域、重要質問10件から開始し、作業時間、判定の揺らぎ、公開速度を測ります。続けられない頻度や複雑な点数を導入するより、証拠と判断が残る小さな運用を優先します。

日本LLMOセンターのLLMO診断では、質問設計、回答・引用・正確性の基準線、技術・情報課題、優先度つき改善計画を整理します。社内で実装する、共同で改善する、診断だけ受け取る、の範囲を分け、編集可能な成果物と再計測条件を確認してから進めます。