生成AIに引用される企業情報の整え方をやさしく解説

結論から言うと、生成AIに自社を正しく紹介してもらうには、プロンプトを工夫する前に、企業情報の置き場所と内容を整えることが大切です。情報が古い、表記が違う、根拠が見つからない。そんな状態では、AIも正しい答えを組み立てにくいですよね。

商談前に、佐伯さんが見た「知らない自社」

青葉精密株式会社の営業企画を担当する佐伯直人は、取引先との商談を翌日に控えていました。話題になる予定なのは、同社の対応サービスと過去の導入実績です。そこで佐伯は、生成AIにこう尋ねました。

「青葉精密株式会社が対応できる製造現場向けのサービスと、主な導入実績を教えてください」

返ってきた回答には、もっともらしい説明が並びました。しかし、よく読むと、数年前に名称を変更したサービス名が残っています。すでに提供を終了したオプションも、現在利用できるように書かれていました。導入実績の業界も、社内で確認できる資料とは少し違います。

佐伯は、画面を見ながら首をかしげました。「これを商談で話したら、間違った約束をしてしまうかもしれない」。営業担当なら、問い合わせ対応や見積書の作成で、似た不安を感じたことがあるのではないでしょうか。

情報は、社内のあちこちに散らばっている

問題の原因は、生成AIだけとは限りません。青葉精密の情報は、公式サイト、営業資料、PDFの製品カタログ、社内共有フォルダ、FAQに分かれていました。

しかも、同じサービスなのに呼び方が部署ごとに異なります。営業部は「現場データ連携パック」、開発部は「データ接続オプション」、古いカタログは別の略称を使っていました。価格や対応範囲の説明も、資料を作った時期によって少しずつ違います。

最新情報を公式サイトに載せても、過去のPDFや終了したキャンペーンページが公開されたままなら、検索の対象に残ることがあります。人が読めば「これは古い資料だ」と気づけても、AIには資料同士の優先順位や有効期限が自動で伝わるとは限りません。

情報の断片化とは、同じ会社やサービスの情報が、複数の場所に分かれて管理され、全体像をつかみにくくなっている状態です。

生成AIは、質問への回答を一つのページだけから作るとは限りません。複数のWebページやPDFなどから、関連しそうな断片を組み合わせます。そのため、情報の断片化があると、古い説明と新しい説明が一つの回答に混ざることがあります。

AIが「間違えて読んだ」のではなく、間違えて読める状態だった

ここで押さえたいのは、生成AIの回答品質が、情報源の品質と見つけやすさに左右されるという点です。AIが会社情報を利用する経路には、Common Crawlのような事前学習データと、質問された時点でWebを検索するリアルタイム検索があります。後者は、検索結果などを参照して回答を作る仕組みで、RAG（検索拡張生成）と呼ばれることがあります。

RAGとは、AIが手元の知識だけで答えず、質問に関係する資料を検索して、その内容をもとに回答する仕組みです。

どちらの経路でも、サービス名、提供条件、実績、所在地、更新日、根拠資料が整理されていなければ、AIは「何が最新で、何を信じるべきか」を判断しにくくなります。情報量が多ければ安心、というわけではありません。古い資料が新しい資料と同じように見えると、かえって誤解の材料が増えます。

佐伯は、回答を見て一度は「生成AIが間違えた」と考えました。しかし、社内資料を並べてみると、別の見方が浮かびます。

「生成AIが間違えたというより、間違えて読まれる状態で情報を置いていたのかもしれない」

この気づきは、特別なシステムを持つ大企業だけの話ではありません。中小企業では、一人の担当者がWeb更新、営業資料、FAQ、問い合わせ対応を兼務することもあります。担当者が変わったり、急いで資料を複製したりすると、表記の違いや更新漏れは自然に起こりますよね。

引用元は、取引先にも見られている

生成AIの引用は、単なる検索順位の問題ではありません。回答の下に表示された引用元を、利用者が確認するからです。ADKマーケティング・ソリューションズが生成AI検索経験者394人を対象に、2025年5月23日から29日まで実施した調査では、引用元サイトを「ときどきクリックして開く」人が40.6％、「開いて読むことが多い」人が20.8％でした。合計すると61.4％です。調査結果

確認する理由で最も多かったのは、「出典元の信頼性を判断するため」の58.7％でした。つまり、AIに引用されたページは、見込み客や取引先が会社の説明を確かめる入口になります。古いサービス名や終了条件が残っていれば、回答だけでなく、引用元の企業サイトにも不信感を持たれる可能性があります。

同じ調査では、引用元サイトについて、従来の検索エンジン経由より信頼度が高まったと答えた人が合計40.7％いました。一方、AIに出典がない場合、49.5％は従来の検索エンジンで補完や裏取りをしています。調査結果

生成AI対策は、プロンプトより情報整理から始まる

LLMOという言葉を聞くことも増えました。LLMO（Large Language Model Optimization）とは、ChatGPTやPerplexityなどのAI検索で、自社の情報が正しく参照・引用されやすくする取り組みです。SEO（検索エンジン最適化）の代わりではなく、情報を見つけてもらう方法を広げるものと考えると分かりやすいでしょう。解説

ただし、LLMOは魔法のような裏技ではありません。質問への答えを冒頭に置くこと、見出しや表で情報を整理すること、具体的な実績や数値を示すこと、出典や更新日を明記すること。まず必要なのは、こうした基本を企業情報にそろえることです。

佐伯が最初に取り組むべきなのは、AIに特別な指示を出すことではありません。サービス名と正式な説明を一つに決め、提供中・終了・予定の状態を分け、根拠資料と更新日を結びつけることです。さらに、公開してよい情報と社内限定の情報を分けます。

情報を整えることは、AIのためだけではありません。営業担当が正しい資料をすぐ見つけられ、問い合わせにも同じ説明で答えられます。生成AIに「別の会社のように」答えられないための第一歩は、会社自身が自社情報の正本を決めることなのです。次章では、散らばった情報をどう棚卸しし、重複や不整合を見つけるかを見ていきます。

原因はここにあります。プロンプトは生成AIに「どう答えるか」を頼めますが、「どの資料を正しいとみなすか」までは自動で整理してくれません。古いPDF、重複したページ、条件の違う営業資料が検索対象に残っていれば、指示文を丁寧にしても、古い情報や別の条件が回答に混ざります。

佐伯はまず、生成AIへの指示文に「公式情報を優先する」「不明な場合は不明と答える」と追加しました。これで安心できると思ったのです。しかし、サービスについて質問すると、回答には以前の納期条件が引用されました。検索結果には古いPDFと現行ページが並び、営業資料には「短納期対応」、現場資料には「特定条件では通常納期」と書かれていたからです。

LLMOとは、ChatGPTやPerplexityなどの生成AI検索で、自社の情報が正しく理解され、引用されやすくする取り組みです。SEOの代わりではなく、検索で見つかる情報をAIにも扱いやすくする拡張策と考えると分かりやすいですよ。

プロンプトは、散らかった資料を片づけられない

プロンプトは、図書館の受付係に渡す質問票のようなものです。「最新版を優先してください」と伝えることはできます。ただし、書庫に最新版と旧版が同じ本棚にあり、発行日も管理者も書かれていなければ、受付係は正しい本を確実に選べません。

生成AIが外部情報を利用する経路には、Common Crawlのような事前学習データと、質問時にWebを検索するリアルタイム検索があります。企業内の検索システムでは、検索拡張生成（RAG）と呼ばれる仕組みを使うこともあります。RAGとは、質問に関係しそうな社内文書を検索し、その内容を材料に回答を作る方式です。LLMO対策の解説でも、AIが参照する情報源を整えることが重要だと説明されています。

つまり、検索対象に古い資料が残っていれば、その資料も「候補」です。AIは候補を見つけることと、社内で決めた正本を判断することを、同じ意味では扱えません。「公式サイトに載っているから安全」という考え方にも注意が必要です。公式ページの中にも、更新日、適用範囲、問い合わせ先が不明な資料はあります。

情報は3種類に分けて棚卸しする

最初に行うべきは、資料を増やすことではなく、何がどの形で存在するかを一覧にすることです。特に次の3分類が役立ちます。

構造化データとは、項目と形式が決まった表やデータベースのことです。サービス名、価格、対応地域、適用開始日などを列にそろえます。

半構造化データとは、見出し、表、タグなど、一部の決まりを持つ情報です。HTMLのFAQ、見出し付きの文書、項目名がそろったExcelなどが該当します。

非構造化データとは、決まった項目や形式がなく、文章や画像として保存された情報です。スキャンPDF、紙の申込書、メール、自由記述の営業メモなどが代表例です。

ここでいう構造化データは、Webページに埋め込むschema.orgなどの仕組みだけを指しません。まずは社内情報を、AIも人も確認しやすい項目に並べ替える、という意味です。たとえば「短納期対応」という一文だけでなく、対象サービス、最短日数、対象地域、受付条件、情報の基準日、管理部署まで分けて記録します。

PDFや紙は、検索前に中身を取り出す

非構造化データは、そのまま検索に入れると誤引用の原因になります。画像になったPDFでは、画面上は読めても、検索システムが文字を認識できないことがあります。また、表の列が崩れると、価格と条件の対応関係も失われます。

OCRとは、画像やスキャン書類に写った文字を読み取り、検索や編集ができるテキストに変換する技術です。

OCRや文書解析で文字と見出し、表、ページ番号を取り出したら、サービス名や更新日などの項目を付けます。そのうえで、検索システムに登録するインジェスト前処理を行います。

インジェストとは、文書を検索システムやAIの知識源へ取り込む工程です。取り込む前に、形式をそろえ、不要な情報を除き、管理情報を付けます。

前処理では、同じ資料の別ファイルやコピーを重複としてまとめます。本文とヘッダー、フッター、メニューの繰り返し、意味のないページ番号などのノイズも除きます。内容が食い違う資料は、勝手に消すのではなく、「現行版」「旧版」「確認待ち」と状態を付けます。最新版を正本として指定し、旧版には公開終了日や参照禁止の印を付けると、後から経緯も確認できます。

「公開情報」と「社内限定」を同じ棚に置かない

価格表や顧客情報が、公開用データと同じ保存場所にある状態も危険です。公開範囲は、公開、社内限定、担当者限定などに分けます。さらに、誰が更新し、誰が承認し、いつ見直すかを決めます。フォルダ名だけでなく、文書そのものに権限区分と適用範囲を持たせることが大切です。

引用元は、読者にとっても確認したい情報です。ADKマーケティング・ソリューションズの生成AI検索経験者394人調査では、引用元サイトを開く人は合計61.4％でした。また、引用元によって信頼度が高まった人は40.7％です。調査結果からも、AIに見つけてもらうだけでなく、人が根拠を確認できる状態まで整える必要が分かります。

佐伯が見つけた、先に整えるべき順番

佐伯は、ようやく問題の中心に気づきました。必要なのは、質問の言い方を増やすことではありません。答えの材料を、正しい順番で並べることです。

「質問の仕方を変える前に、答えの材料を棚卸ししよう」

そこで、①資料を全件一覧にする、②サービス名や条件の表記を統一する、③更新日・適用範囲・管理者を付ける、④重複と不整合を確認する、⑤公開範囲を分ける、⑥OCRや文書解析を使って検索しやすくする、という順番を決めました。

生成AIは、情報を増やせば賢くなるとは限りません。整理されていない資料を大量に渡すと、候補が増えて根拠がぼやけます。まずは「何が正しいか」を人が決め、その判断をデータの項目と管理ルールに落とし込むことです。それが、プロンプトを直す前に行うべき、引用品質の土台になります。

会社情報の意味をそろえる主な選び方は3つあります。①共有スプレッドシートで始める、②データベースやデータカタログで管理する、③セマンティックモデルとAIエージェントを組み合わせる方法です。大切なのは、資料を一か所に集めることだけではありません。人とAIが、同じ情報を同じ意味で読める状態にすることです。

共通スキーマとは 情報を同じ項目とルールで表す設計図のことです。たとえば、どのサービスにも「サービス名」「提供内容」「対象顧客」「利用条件」「根拠資料」「更新日」「管理部門」を持たせます。

まず、佐伯が気づいた「資料を集めるだけでは足りない」理由

佐伯は、社内のデータ設計担当である水野凛に、古い料金や条件違いが生成AIに引用される問題を相談しました。佐伯は、公式サイトや営業資料を一つのデータベースに集めれば解決すると考えていました。

しかし、水野は画面上の項目を指しながら言いました。

「AIに正しく引用してほしいなら、まず人間同士が同じものを同じ名前で呼べる状態にしましょう」

調べてみると、営業部は「製品」、マーケティング部は「サービス」、カスタマーサクセス部は「導入事例」と呼んでいた情報の境界が、部署ごとに違っていました。「導入支援」をサービスの一部と見る部署もあれば、別サービスとして扱う部署もあります。

エンティティとは 企業、製品、サービス、導入事例、FAQ、規約など、社内で一つの対象として管理する情報の単位です。

生成AIが迷っていた原因は、文章の表現力ではありませんでした。企業内で、エンティティと項目の意味が統一されていなかったのです。

3つの選び方を比べる

1．共有スプレッドシートで「正本」を作る

小規模なチームなら、Google スプレッドシートやMicrosoft Excelで始める方法が現実的です。サービスを1行、項目を列にすると、抜け漏れを見つけやすくなります。

いいところ

• 初期費用と準備期間を抑えやすい
• 現場の担当者が内容を確認しやすい
• サービス名や更新日など、共通項目を試しながら決められる

気をつけるところ

• コピーされた古いファイルが残りやすい
• 誰が更新したか、どの資料が正しいか分からなくなりやすい
• 複雑な権限管理や自動連携には向きにくい

まずは主要サービス10〜20件など、範囲を絞ると進めやすいですよね。

2．データベースやデータカタログで管理する

情報量が多い企業は、データベースやデータカタログに移します。データカタログとは、社内データの場所、項目、意味、管理者を一覧にする台帳です。

いいところ

• サービスと料金、対象顧客、規約などの関係を管理できる
• 更新履歴や公開範囲を残しやすい
• APIや検索システムと連携しやすい

気をつけるところ

• 最初に項目と責任者を決める手間がかかる
• 部署間で定義が合わないと、立派な箱だけができてしまう
• 権限設定を誤ると、社外秘の情報をAIに渡す危険がある

「何でも登録する」のではなく、公式情報、社内限定情報、利用停止情報を区分することが重要です。

3．セマンティックモデルとAIエージェントを組み合わせる

すでにMicrosoft Power BIを使っている企業は、セマンティックモデルを活用できます。セマンティックモデルとは、データの項目名だけでなく、「売上とは何か」「サービスと顧客をどう結びつけるか」といった意味や関係を定義する仕組みです。Microsoft Fabricのデータエージェントと組み合わせれば、AIが参照するデータと指示をそろえやすくなります。

いいところ

• 用語、データの関係、回答ルールをまとめて管理しやすい
• 「現行サービスだけ」「公開可能な情報だけ」といった条件を付けやすい
• 部署やシステムが増えた後も拡張しやすい

気をつけるところ

• データ設計や権限管理の知識が必要
• 製品の契約、設定、運用担当が必要になる
• モデルを整えても、元データが古ければ正しい回答にはならない

水野は、最初から大きな仕組みを入れるのではなく、①で意味をそろえ、必要になった範囲から②や③へ進める案を示しました。

共通スキーマに入れる項目を決める

最初に、企業、製品、サービス、導入事例、FAQ、規約の6種類をエンティティとして定義します。そのうえで、各情報に次の項目を付けます。

• 正式名称、略称、表記揺れ
• 提供内容、対象顧客、利用条件、料金
• 根拠資料のURLや文書名
• 公開範囲（公開、社内限定、取扱注意）
• 状態（提供中、終了予定、提供終了）
• 最終更新日、次回確認日、責任者

たとえば「顧客管理サービス」「CRM」「顧客管理SaaS」が同じものなら、正式名称を一つに決め、略称を別項目に記録します。AIに略称を禁止するのではなく、「正式名称を優先し、必要なら略称を併記する」とルール化するのです。

Webページでは、schema.orgの構造化データも補助になります。構造化データとは、ページの企業名、記事タイトル、著者、公開日などを機械が読み取れる形で記述する情報です。形式はJSON-LDが一般的です。ただし、構造化データだけで引用が保証されるわけではありません。本文と記載内容を一致させ、一次資料や出典も示しましょう。構造化データの実装ガイド

公開前に「同じ質問」をAIへ投げる

最後に、ChatGPTやPerplexityなどで、「現行サービスの対象顧客と利用条件は？」「提供終了したサービスは？」と同じ質問を定期的に試します。回答、引用元、更新日、公開範囲を確認し、誤りがあれば元データを直します。

LLMOとは、生成AI検索で自社情報が引用されやすくなるよう、情報の構造や内容を整える取り組みです。SEOの代わりではなく、情報発見の間口を広げる施策と考えると分かりやすいでしょう。LLMOの基本と進め方

生成AIの引用元を確認する人は少なくありません。2025年の394人調査では、引用元サイトを訪問する人が合計61.4％でした。調査結果だからこそ、AI向けの特別な文章を増やす前に、人にもAIにも意味が通じる「会社情報の正本」を作ることが近道なのです。

ゴールは、散らばった資料を「誰が、いつ、どの条件で、外部に出してよいか」が分かる情報に変え、棚卸し、分類、抽出、構造化、検証、検索・公開、更新までを一周することです。青葉精密では、いきなり全資料をAIに読ませず、情報源を仕分けながら小さく始めます。

LLMOとは、ChatGPTやPerplexityなどの生成AI検索で、自社の情報が正しく参照・引用されやすくする取り組みです。SEOの代わりではなく、検索対策を広げる考え方です。

引用元サイトを確認する人は、調査で合計61.4％に上りました。AIに引用されることは、訪問や信頼につながる可能性があります。調査結果

1. まず情報源を一覧にする

最初にやることは、資料を集めることではなく、どこに何があるかを見える化することです。次の列をスプレッドシートに作り、公式サイト、PDF（レイアウトを保った文書形式）、社内文書、FAQ、データベース、営業資料を一行ずつ登録します。

担当者が分からない資料には、仮の担当部署を置きます。空欄のままにすると、後で更新漏れが起きやすいからです。

2. 公開範囲を三つに分ける

次に、資料を「公開用」「社内限定」「機密情報」に分類します。公開用は公式サイトや公開FAQに出せる情報です。社内限定は価格交渉の方針や営業手順、機密情報は顧客名、個人情報、未公開の開発計画などです。

ここで大切なのは、資料単位だけでなく項目単位で判定することです。製品仕様書全体は公開可能でも、最終ページの顧客名は社内限定かもしれません。水野は検索インデックスに登録する項目を絞り、顧客情報や社内メモが外部回答に混ざらないことを確認します。

3. 紙やPDFから本文と表を取り出す

紙資料や画像PDFは、そのままでは検索しにくいため、OCRと文書解析を使います。OCRとは、画像の文字を読み取り、検索できるテキストに変換する技術です。本文だけでなく、表、見出し、脚注、単位、ページ番号も分けて抽出します。

佐伯は古いPDFを一枚ずつ確認し、現場担当者に「この条件は今も有効ですか」と尋ねます。OCRの読み間違いで、0.5が5になったり、マイナス記号が消えたりすることがあるためです。抽出結果には、読み取りの信頼度と確認者を記録し、重要な数値は原本と照合します。

4. 共通スキーマで整形する

抽出した資料は、サービスごとに同じ項目へそろえます。共通スキーマとは、情報の名前、型、意味を統一した設計図のことです。まずは次のような項目で十分です。

service_id、service_name、summary、conditions、effective_from、effective_to、source_url、updated_at、visibility、owner、status

保存形式は、少量ならCSV（表をカンマ区切りで保存する形式）、項目の入れ子が多ければJSONが扱いやすいでしょう。日付は2026-04-01のように統一し、料金の通貨、重量の単位、対象地域も明記します。「要相談」だけで終わらせず、相談が必要な条件を本文に書きます。

サービス名の表記ゆれも直します。「A-100」「製品A100」「A100製品」が同じものなら、正式名称を一つ決め、別名として管理します。企業の所在地、サービス内容、実績、信頼性など、AIが紹介時に使う構造的な情報も抜けなく入れます。

5. 重複・期限切れ・根拠不明を確認する

整形後は、資料の数ではなく、正しさを確認します。同じサービスを説明する資料が複数ある場合は、正式な優先順位を決めます。たとえば「契約・法務文書」「公式サイト」「営業資料」の順です。根拠URLや承認者がない記述は、公開候補から外して確認待ちにします。

古い資料をすぐ削除するのは危険です。新旧データを横に並べるサイドバイサイド更新、つまり変更前と変更後を同時に比較する方法で、差分を確認します。期限切れの資料にはarchivedなどの状態を付け、外部検索の対象から外しつつ、監査用には残します。

6. 検索基盤に登録し、取得項目を制限する

整形した公開用データは、検索インデックスに登録します。検索インデックスとは、必要な情報をすばやく探すための索引です。選択肢にはElasticsearchやAzure AI Searchがあります。

RAGとは、質問を受けたAIが、登録済みの検索データから関連情報を取り出して回答に使う仕組みです。必要な項目だけを取得できるため、資料全体を無制限に渡すより安全です。

登録するフィールドは、サービス名、概要、条件、有効期限、根拠URL、更新日などに絞ります。顧客情報や社内メモには、外部回答から除外する権限フィルターを設定します。検索結果に必ず出典URLと更新日を添え、AIが回答時に提示できるようにします。

テスト質問も用意します。たとえば「製品Aの対象地域と有効期限を、公式URL付きで答えてください」と入力し、正しい資料だけが返るか確認します。古い条件が混ざる場合は、削除ではなくstatus、更新日、公開範囲の設定を見直します。

7. 人が読むページとAI向けデータを一致させる

公開ページには、見出しへFragment IDを付けます。Fragment IDとは、URLの末尾に付けてページ内の特定箇所へ移動する目印です。たとえば製品Aの見出しにid='service-a'を設定し、https://example.jp/services#service-aで直接案内できるようにします。

さらに、公開済みのタイトル、要約、本文、URL、更新日をAI向けデータ配信APIで提供します。APIとは、別のシステムが決められた形式で情報を受け取る窓口です。人向けページを更新したら、APIと検索インデックスも同じ変更内容へ更新します。

ページにはJSON-LD（ページの意味を機械へ伝える記述形式）の構造化データを補助的に使えます。ただし、構造化データだけで引用が保証されるわけではありません。本文、著者、更新日、FAQの内容と一致させることが重要です。構造化データの実装ガイド

最後に、月次など社内で決めた周期で、引用テスト、期限切れ確認、権限確認を行います。最初から完璧を目指さず、代表的なサービス数件で流れを完成させてから広げるのが安全です。情報を増やすより、正しい情報源を一つにそろえることが、AIに引用される企業情報への近道ですよね。

公開前の回答テストを行うと、生成AIが「正しく引用したか」だけでなく、最新情報・根拠資料・公開範囲まで確認できます。これにより、公開後に誤回答が見つかるリスクを減らせます。実際、生成AI検索経験者394人を対象にした調査では、引用元サイトを訪問する人が合計61.4％、引用元によって従来の検索より信頼度が高まった人が40.7％でした。ADKマーケティング・ソリューションズの調査

つまり、引用は「名前が出れば成功」ではありません。読者が根拠を確認でき、安全に次の行動へ進めることが成果です。

まず、顧客の質問をそのまま再現する

佐伯は、整備した企業データを生成AIにつなぎ、実際の顧客が尋ねそうな質問を入力しました。最初に確認したのは、次の4問です。

• 青葉精密株式会社が提供している主要サービスは何か
• そのサービスの対象業種と利用条件は何か
• 導入事例の根拠資料はどこにあるか
• 現在提供していないサービスを尋ねた場合、不明または終了済みと回答できるか

ここで大切なのは、答えを見て「それらしい」と判断しないことです。質問ごとに、あらかじめ正解と根拠を用意します。たとえば、主要サービスなら公式サービスページ、利用条件なら最新の料金・契約条件、導入事例なら公開許諾済みの事例ページを正解データにします。

検証の基本：回答、根拠URL、更新日、公開範囲の4点を一組で確認します。

合格条件をチェック表にする

検証は、担当者の感覚ではなくチェック表で行うと再現しやすくなります。表には、質問、期待する回答、根拠資料、更新日、公開範囲、判定、修正担当者を記録します。

確認する観点は5つです。第一に、最新の公式情報を使っているか。第二に、回答から根拠ページや資料へたどれるか。第三に、営業資料と開発資料など、部署の違う情報が矛盾していないか。第四に、社内限定の価格や個人情報を回答していないか。第五に、不明な情報を推測で補っていないかです。

とくに最後の確認が重要です。提供終了サービスを尋ねたとき、AIが似た現行サービスを勝手に紹介してはいけません。「現在の公式情報では確認できません」「提供終了です」と答えるルールを、データ側にもテスト側にも入れておきます。分からないときに分からないと言えることは、AIの弱さではなく安全機能ですよね。

引用先と本文の不一致を直す

回答にURLが付いていても、リンク先の本文と回答が食い違えば合格にはしません。古いPDFだけに残った条件、部署ごとに異なるサービス名、更新日のない導入実績は、優先順位を決めて整理します。

WebページにJSON-LDを使っている場合も、機械向け情報だけを直してはいけません。JSON-LDとは、ページの内容を検索エンジンやAIが読み取りやすい形で記述するデータ形式です。本文、著者、公開日、更新日、構造化データの内容を一致させます。構造化データは引用を保証するものではなく、本文の質や一次情報を補助する仕組みです。構造化データの実装ガイド

エンティティ抽出モデルも育てる

製品名やサービス名を取り違える場合は、質問だけでなく抽出モデルを見直します。エンティティとは、企業名・製品名・導入事例など、情報の中で識別して管理したい対象のことです。

たとえば、サービス名に似た社内プロジェクト名まで拾うなら、カスタムAIモデルに正しい例と誤りやすい例を追加します。既存のエンティティタイプを変更する場合は、少なくとも5件の追加例で検証します。誤抽出が起きた質問、抽出結果、最終回答、正しいラベルを記録し、データとモデルを継続的に改善しましょう。

同じ質問をChatGPTやPerplexityなど、実際に利用するAIでも試すことも有効です。AIによって検索や引用の仕組みが異なるためです。LLMOとは、AI検索で自社情報が適切に参照・引用されやすくする取り組みのことですが、SEOの代わりではなく、情報整備を広げる考え方です。LLMOの実務解説

一度の確認で終わらせない

最後に、情報を運用へつなげます。各AI資産に所有者を置き、更新、承認、公開停止の手順を決めます。サービス責任者が内容を更新し、法務や情報管理担当が公開範囲を確認する、といった役割分担です。アクセス権限と利用ポリシーも設定します。

重要な回答を外部公開するときは、人間の最終確認を残します。社員向けには、「機密情報や個人情報を入力しない」「AIの出力をそのまま外部公開しない」という短い利用ガイドラインを配ります。

佐伯は最後に、こう整理しました。

「引用されたかどうかだけではなく、どの情報を根拠に、どこまで安全に答えたかを確認しよう」

検証は試験ではなく、健康診断に近い作業です。質問を追加し、誤りを記録し、所有者が更新する。この小さな繰り返しが、企業情報を一度きりの整備から、信頼され続ける仕組みへ変えていきます。

今日のポイントはこの3つです。

• 情報を棚卸しし、共通の型にそろえること。サービス名、提供条件、根拠資料、更新日、公開範囲を一つの基準で管理します。
• 検索しやすく、引用しやすい形にすること。重複や古い情報を除き、見出し、表、構造化データ、検索インデックスを活用します。
• 公開後も人が確認し、更新し続けること。生成AIを一度設定して終わりにせず、企業情報のライフサイクルとして運用します。

LLMOとは、生成AIの検索結果や回答で、自社の情報が正しく引用されやすくする取り組みです。 SEOの代わりではなく、SEOを広げる施策と考えると分かりやすいですよね。

まず、企業情報を「台帳」にする

最初に行うことは、公式サイト、PDF、営業資料、FAQ、社内フォルダにある情報の棚卸しです。情報を、表形式の構造化データ、一部が整理された文書などの半構造化データ、自由記述の議事録やメールなどの非構造化データに分けます。

そのうえで、サービスごとに共通スキーマを作ります。共通スキーマとは、情報を同じ項目で記録する「共通の台帳」です。最低限、次の項目をそろえましょう。

• サービス名、概要、対象顧客
• 価格、提供地域、契約条件
• 根拠ページや正式資料のURL
• 最終更新日、次回確認日
• 公開範囲、管理責任者、廃止状態

重複した説明や部署ごとの表記違いは、正しい情報を一つ決めて整理します。古い資料には「廃止」「社内限定」などの状態を付け、検索対象から外します。これが、AIにも営業担当者にも分かりやすい企業情報の土台になります。

引用されるために、情報への道案内を整える

次に、情報を検索しやすい形へ変換します。見出しを付け、1段落1論点にし、冒頭に結論を書きます。サービス条件は表にし、根拠資料と更新日も近くに置きます。こうすると、人が読むときだけでなく、AIが必要な一部分を取り出すときにも迷いにくくなります。

記事や企業ページには、schema.orgの構造化データをJSON-LDで追加できます。これは、ページに「誰が、何を、いつ書いたか」を機械にも伝える補助情報です。ただし、構造化データだけで引用が保証されるわけではありません。本文と内容を一致させることが前提です。構造化データの実装ガイド

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "正式な企業名",
  "url": "公式サイトのURL",
  "description": "本文と一致する企業概要"
}

社内検索では、ElasticsearchやAzure AI Searchなどの検索インデックスを使い、公開範囲や更新状態で絞り込めるようにします。さらに、AI向けAPIや見出しへのFragment IDを用意すると、回答の根拠へ直接案内しやすくなります。#priceのような識別子で、料金表の位置まで示すイメージです。

「公開してよい情報」を仕組みにする

検索性と同じくらい重要なのが、権限管理です。公開情報、取引先限定、社内限定、個人情報を分類し、AIが参照できる範囲を分けます。所有者、更新期限、承認者を決め、変更時には根拠資料も更新します。

公開前には、実際の顧客質問で回答をテストします。サービス名、価格、対象地域、納期などを尋ね、回答が正しいページを引用しているか、古い資料や社内情報が混ざっていないかを人が確認します。llms.txtは補助的な選択肢ですが、現時点では効果の裏付けや標準化が途上です。まずは本文、一次情報、出典、更新管理を優先しましょう。LLMOの実務ガイド

明日から始める3ステップ

1. 30分で情報源を列挙する：公式ページ、PDF、FAQ、営業資料を表にします。
2. 一つのサービスで試す：共通スキーマに登録し、重複・古い資料・公開範囲を確認します。
3. 5問で回答テストをする：顧客が実際に聞きそうな質問を入力し、根拠URLと安全性を確認します。

引用元を確認する人は少なくありません。ADKマーケティング・ソリューションズの394人調査では、引用元を開く人は合計61.4％でした。調査結果 根拠ページは、AIのためだけでなく、営業や顧客の安心にもつながります。

佐伯が生成AIを「勝手に答える検索窓」ではなく、整備された企業情報を根拠付きで案内するインターフェースと捉え、水野がAI導入ではなく情報のライフサイクル管理として運用する。そんな変化が、企業の強さになります。

生成AIに正しく引用してもらうために必要なのは、情報を増やすことではありません。何が正しいのか、誰が管理するのか、どこまで公開してよいのかを、人にも機械にも分かる形に整えることです。

これはSEOだけの施策ではありません。データ品質、検索性、ガバナンス、セキュリティを一体で整えれば、企業情報はAIに引用されるだけでなく、営業、サポート、社内ナレッジにも使える更新資産になります。まずは一つのサービス、一枚の台帳から始めてみましょう。