AI回答の出典がぶれる原因とCoveo｜答えさせる文書の線

「ヘルプページのAI回答が、改定前の料金表を引いて答えていた」「社内向けの資料まで、顧客向けの回答に混ざらないか不安だ」——サイトやヘルプセンターに生成AIの回答を載せた企業の、Web担当やサポートの責任者から出てくる声です。どちらも、AIが間違えた、と受け取られがちです。けれども、AIの性能を上げれば片づく話ではありません。本当は、AIが何を根拠に答えてよいかを、誰も決めていないことが原因です。この記事では、カナダの検索基盤 Coveo を例に、AI回答の出典がぶれる原因と、答えさせる文書の棚・鮮度・外部のAIに索引を開く範囲を誰が決めるかを整理します。

「AIが古い料金を答えた」は、AIの性能の話ではない

サイト内検索やヘルプセンターに生成AIの回答を付けると、最初の数週間でよく出てくる問題があります。回答の根拠に、改定前の料金表や、終了した製品の手順書が使われる。同じ質問でも、日によって引いてくる出典が変わる。そして、顧客向けの回答に、社内向けの資料の一節が混ざるのではないかという不安です。

この種の仕組みは、生成AIが自分の知識で自由に答えるのではなく、索引に入っている文書から関係の深い部分を探し、その部分だけを根拠に答えを書く形をとります。根拠の候補になる文書の集まりが、答えの質の上限を決めます。

だから、古い料金表が答えに出たときに直すべきは、AIの設定より先に、その料金表が根拠の候補に残っていたことです。出典がぶれるのも、同じ問いに答えられる文書が棚に何本もあり、どれが正しいかを決めた人がいないからであることが多いのです。

この記事で扱うのは、サイトやヘルプの回答を「どの文書を根拠に答えさせるか」という線です。サイト内検索をAIに置き換えるかどうかの判断は、置き換えの判断を扱った別の記事に譲り、ここでは置き換えた後の根拠の決め方に絞ります。

Coveo は、検索の索引を根拠に生成AIが答える基盤

Coveo は、企業のサイト・EC・ヘルプセンター・社内のナレッジの検索を担う基盤です。社内外のさまざまなシステムの文書を1つの索引に集め、検索の結果の並び順を機械学習で整えることを得意としてきました。2026年6月には、検索と商品の発見の分野の調査会社の評価で先頭の位置づけを受けたと発表しています（提供元の発表）。

その上に載っているのが、関連度に基づく生成回答（RGA）です。2026年10月時点の公式文書では、利用者の自然な言葉の質問に対し、索引の中の文書だけを根拠に答えを生成し、検索の結果と同じ画面に表示するとされています。答えには、根拠に使った文書の出典が付き、押すとその文書が開きます。絞り込みの条件を変えると、答えもその条件で作り直されます。

公式文書では、RGA は有料の追加機能と位置づけられ、ライセンスに足す形で提供されます。答えを書くのは外部の基盤モデルのサービスに置かれた第三者の大規模言語モデルで、Coveo 側は、どの文書のどの部分を渡すかを決める役を持ちます。

2026年2月10日には、Coveo がホストする MCP サーバーを一般提供したと発表しました。ChatGPT Enterprise や Claude などのAIから、Coveo の索引を検索し、文書を取り出し、回答や文章の断片を受け取れる仕組みです。ChatGPT Enterprise 向けには、公式の連携先の一覧に Coveo のアプリが載っているとされています。MCP そのものの説明は、MCP とは何かを扱った記事に譲ります。

カナダの上場企業で、国内でまだ知られていない理由

Coveo はカナダのモントリオールに本拠を置き、株式を公開している企業です。投資家向けの発表では、2026年9月に豪州の卸売の企業との提携の拡大、10月には豪州の大手スーパーによる採用を発表しています。2026年10月時点で、買収や事業の終了に当たる発表は見当たりませんでした。

国内でまだあまり知られていない理由は、確かめた範囲では3つあります。一つは、主な顧客が北米・欧州・豪州の大きな企業で、発信も英語が中心であること。二つめは、対象が大量の文書と問い合わせを抱える企業で、中小規模のサイトでは導入の検討に上がりにくいことです。

三つめが日本語の扱いです。公式文書では、RGA の検索と回答の生成は既定で英語のみに対応し、英語以外の言語はベータの扱いとされています。日本語の回答は、2026年10月時点でベータの機能を本番で使う判断になります。日本語での精度や対応の範囲は、試行の前に提供元に確かめてください。

日本語の管理画面や国内の窓口の有無は、確かめた公式の資料には書かれていませんでした。以下は、製品を入れるかどうかより、AI回答の根拠を決める考え方として読んでください。Coveo を使わない場合も、索引から根拠を選んで答える形の仕組みなら、同じ線が要ります。

2026年2月の発表では、ホストする MCP サーバーを Claude や ChatGPT と組み合わせて使っている顧客は10社と、提供元の経営者が述べています（提供元の発表）。外部のAIから索引を引く使い方は、提供元の顧客の中でもまだ始まったばかりの段階だと読めます。

回答はどう作られるか：2段で文書を選び、選んだ断片だけで答える

公式文書の説明では、回答は次の順で作られます。まず、通常の検索と同じく、質問が検索の規則と機械学習を通り、索引の中から関係の深い文書が選ばれます。意味の近さで探す仕組みを組み合わせると、言い回しが違っても意味の近い文書を拾えるとされています。

次に、選ばれた文書の中から、質問に最も関係する文章の断片を選びます。生成AIに渡すのは、この断片と質問と指示だけで、AIは渡された断片だけを使って答えを書くとされています。管理者は、断片を探す対象の文書の数や、断片を採用する関連度の線を調整できる、とも書かれています。ただしこれは経験のある管理者向けの上級の設定とされ、マーケの担当者が気軽に触る場所ではありません。

この仕組みから分かるのは、回答の根拠は2つの段の両方で決まるということです。1段目で古い文書が選ばれれば、2段目でも古い断片が選ばれ得ます。1段目で社内向けの文書が候補に残れば、2段目でもその断片が渡り得ます。AIの書き方をいくら整えても、渡す材料が古ければ答えは古いままです。

公式文書では、答えを書く大規模言語モデルは顧客のデータで学習せず、データを残さないとされ、Coveo が回答に関する記録を一定期間保持すると書かれています。何が外に出るかは、生成AIに渡る断片と、残る記録の2つで考えます。前者は棚の決め方で、後者は記録の見方と保存の期間で管理します。

起きている課題を3つの型に分ける

出典のぶれと言われる問題は、中身で分けると3つの型があります。型によって原因も手当ても違うので、まず自社で起きているのがどれかを見分けます。

一つめは根拠がぶれる型です。同じ質問に答えられる文書が、製品ページ、よくある質問、ブログ記事、過去の告知と何本もあり、日によって選ばれる文書が変わる。答えの中身が微妙に食い違い、顧客から「前と言っていることが違う」と言われます。

二つめは古い文書を引く型です。料金の改定や仕様の変更のあとも、古い文書が索引に残っていて、そちらが選ばれる。新しい文書を公開しても、回答に反映されるまでに時間差があることもあります。

三つめは出してはいけない文書を引く型です。社内向けの手順書、取引先向けの価格表、未発表の製品の資料などが、顧客向けの回答の候補に入ってしまう。実際に混ざらなくても、混ざらないと言い切れないことが導入そのものを止めます。次の3つの節で、原因を1つずつ見ていきます。

原因1：索引の範囲と回答の範囲が同じになっている

検索の索引は、もともと「見つかってよい文書」を集める仕組みです。過去の告知やブログ記事も、検索で見つかることには価値があります。ところが生成AIの回答を載せると、見つかってよい文書が、そのまま答えの根拠にしてよい文書として扱われることになります。

検索の結果なら、利用者は日付やページの種類を見て、古い告知だと判断できます。答えの文章になると、その判断の手がかりが消え、古い告知の一節が、今の公式の回答のように読まれてしまいます。出典が付いていても、利用者が毎回それを開いて日付を確かめるとは限りません。

公式文書では、RGA のモデルは指定した索引の文書だけを使うとされ、MCP サーバーの設定でも、どの検索の規則の流れ（クエリパイプライン）を使うかで呼び出せる機能が決まります。仕組みの上では、回答の範囲を検索の範囲より狭くできる余地があるということです。その余地を使わずに、索引の全部を回答の候補にしているのが、原因1の正体です。

原因2：文書の鮮度と持ち主が決まっていない

古い料金表が回答に出る問題の多くは、文書の側に「いつまで正しいか」と「誰が直すか」が書かれていないことから起きます。料金を改定した部署は、料金のページは直しても、ヘルプ記事の中の料金の記載や、過去の告知の中の価格までは追いかけません。

公式文書によると、回答に使う断片を探すための材料は、モデルの組み立ての時点で文書を区切って作られ、組み立ての予定に沿って更新されるとされています。索引の文書を直してから、回答の材料に反映されるまでに時間差があり得るということです。料金のページを直しても、回答が直ったとは限りません。料金の改定のように日付で切り替わる情報は、この時間差も含めて段取りを組む必要があります。

持ち主のいない文書は、誰も消さないまま残ります。ヘルプセンターの記事が数百本になると、どの記事がまだ正しいかを1人で判断することはできません。文書ごとに持ち主の部署と最終の確認日がなければ、仕組みに「新しいほうを選べ」と頼む手がかりもないのです。

鮮度の問題は、古い文書が残っていることだけから生まれるのではありません。よくある質問と製品ページで料金の書き方が違えば、どちらが選ばれるかは質問の言い回しで変わります。情報ごとに正本を1つ決め、ほかの文書は正本への案内にとどめるのが、根拠のぶれを減らす近道です。

原因3：閲覧の権限が回答に引き継がれていない

Coveo の公式文書では、索引を作るときに元のシステムの文書とその閲覧の権限を一緒に取り込み、問い合わせの時点で、認証した利用者ごとに見てよい文書だけを検索と回答に使うとされています。権限を持たない人には、その文書は検索の結果にも回答にも出ないという設計です。

裏を返すと、この仕組みが守ってくれるのは、元のシステムで権限が付いている文書だけです。元の共有の場所で誰でも見られる扱いになっていた社内資料や、権限を付けずに索引に入れた資料は、回答の材料に入り得ます。ログインしない一般の訪問者が使うサイトの回答では、権限で守る前に、そもそも顧客向けの棚に入れないことが基本になります。

外部のAIからつなぐ場合も同じです。MCP サーバーの設定について、公式文書では、利用者の認証が要る非公開の文書にはOAuth による接続が推奨され、認証の要らない公開の文書には匿名のAPIキーが推奨されると書かれています。匿名のキーでつながる窓口に非公開の文書の棚がつながっていれば、権限の仕組みはその役目を果たせません。

社内検索で権限をどう引き継ぐかという論点は、Onyx を扱った記事に譲ります。ここで決めたいのは、顧客向けの回答と、外部のAIへの窓口に、どの棚をつなぐかです。

原因ごとの手当てを1枚にまとめる

3つの原因と手当てを並べると、次のようになります。どれも、AIの設定を細かく変える話ではなく、文書と人の側の決めごとです。

原因	起きること	手当て	決める人
索引の範囲と回答の範囲が同じ	古い告知やブログの一節が、今の公式の回答として読まれる	回答に使う文書の棚を、検索の索引から分けて小さく持つ	Web担当とサポートの責任者
鮮度と持ち主が未定	改定前の料金や終了した手順が回答に出る。直しても反映に時間差がある	棚の文書ごとに持ち主と最終確認日を置き、改定の段取りに回答の更新を入れる	文書の持ち主の部署
権限が回答に引き継がれない	社内向けや取引先向けの資料が、顧客向けの回答の候補に入る	権限の付いていない資料を顧客向けの棚に入れない。外部AIへの窓口は認証の方式を分ける	情報システム部門と Web担当

表の右端の「決める人」が空欄のまま運用に入ると、問題が起きたときに誰も直せません。回答の質の問題を、AIを入れた担当者1人の責任にしないためにも、決める人を最初に書いておきます。マーケの担当者が主導する場合も、文書の持ち主の部署を巻き込んでから始めます。

対策1：答えさせる文書の棚を分ける

最初の手当ては、検索で見つかってよい文書と、回答の根拠にしてよい文書を分けることです。回答の棚には、正式な製品の説明、現行のよくある質問、現行の手順書のように、会社として「今の答え」と言える文書だけを置きます。

過去の告知、ブログ記事、イベントの報告、事例の記事は、検索では見つかってよいが、回答の根拠にはしない棚に置くのが基本です。事例の記事は特に、その時点の価格や仕様が書かれていることが多く、回答に混ざると古い情報の出どころになります。

棚を分けると、回答できない質問が増えます。それは悪いことではありません。答えられない質問は、検索の結果を見せるか、窓口に回すほうが、古い文書で答えるより損が小さいからです。答えられなかった質問の一覧は、回答の棚に足す文書を決める材料になります。

棚の線は、マーケとサポートだけで決めず、製品の責任者と合意しておきます。回答の棚は、増やすより減らすほうが揉めずに決まるので、最初は狭く始め、文書の持ち主が付いたものから足していきます。

「今の答え」と言える文書かどうかは、持ち主の部署が決まっている、最終の確認日が決めた期間の内にある、同じ情報の正本である、の3つで判定すると迷いが減ります。3つのどれかが欠けた文書は、検索の棚に残し、回答の棚には入れません。

対策2：棚の文書ごとに持ち主と更新日を置く

回答の棚に入れた文書には、持ち主の部署と、最終の確認日と、次に確かめる日を付けます。料金や契約の条件のように日付で変わる情報には、いつ切り替わるかも書いておきます。

料金の改定や製品の終了のように、日付の決まった変更があるときは、その段取りの中に「回答の棚の文書を直す」「古い文書を棚から外す」「回答に反映されたかを確かめる」を入れます。反映に時間差があり得ることを前提に、切り替えの日より前に新しい文書を用意し、切り替えの当日に回答を確かめる人を決めておきます。

次に確かめる日を過ぎた文書は、棚から外す運用にしてもかまいません。持ち主が確かめていない文書を、AIが根拠にし続けるよりは安全です。どの文書が期限切れかを一覧で出す作業や、似た内容の文書の候補を挙げる作業は、AIや仕組みに任せられる部分です。

文書の持ち主は、文書を書いた人ではなく、その情報が正しいことに責任を持つ部署にします。料金なら営業企画、仕様なら製品の担当、手順ならサポートです。持ち主のいない文書は、回答の棚に入れないを規則にしておくと、棚が増えすぎることも防げます。

対策3：外部のAIに索引を開く範囲を決める

MCP サーバーを使うと、社員が使う ChatGPT Enterprise や Claude から、Coveo の索引を引けるようになります。便利な一方で、顧客向けの回答のために整えた棚と、社内向けの資料の棚が、同じ窓口から見えるようになるおそれがあります。

公式文書では、MCP サーバーの設定ごとに、使う検索の規則の流れと、外部のAIに使わせる機能を選べるとされています。機能は大きく4つあり、外部のAIに渡るものが違います。

機能	外部のAIに渡るもの	部門で決めること
検索	検索の結果の一覧	どの棚の文書を結果に出してよいか
文書の取り出し	指定した文書の全文	全文を渡してよい文書か。顧客向けの棚に限るか
回答の生成	RGA が作った回答と出典	顧客向けの回答と同じ棚と線で使わせるか
断片の取り出し（Passage Retrieval）	関係の深い文章の断片	外部のAIが自分で答えを書くことを許すか

とくに文書の取り出しは、全文が外部のAIに渡ります。どの機能を、どの棚に対して、誰に開くかを、窓口ごとに決めるのが基本です。公式文書では、利用者の認証が要る文書にはOAuth の接続が推奨され、設定ごとに使える人を管理できるとされています。認証の要らない匿名のキーは、公開してよい文書の棚に限ります。

公式文書では、最初に作った MCP サーバーの設定が自動で既定の扱いになり、ChatGPT などに載っている Coveo のアプリは既定の窓口を呼ぶとされています。既定の設定はそのままでは削除できず、別の設定を既定に切り替えてから消す形です。つまり、試しに作った最初の設定が、そのまま社員のAIから呼ばれる窓口になり得ます。最初の設定は、公開してよい棚だけをつないだ狭いものにしておくのが安全です。

窓口ごとに、外部のAIへの使い方の説明文を書き換えられる、とも書かれています。ただ、説明文は外部のAIへのお願いであって、棚の線の代わりにはなりません。渡したくない文書は、説明文で止めるのではなく、棚から外して止めます。

費用の面では、公式の発表で、MCP サーバー経由の問い合わせは既存の利用量に応じた契約の中で数えられるとされています。外部のAIから引く回数が増えるほど、利用量も増えます。外部に開く判断は、マーケだけで決めず、情報システム部門と文書の持ち主の部署が加わって決める事項です。

価格・契約条件の質問は、AIに答えさせない

回答の棚を整えても、AIに答えさせないほうがよい質問があります。代表は、個別の価格、値引き、契約の条件、返金や解約の扱い、法的な責任の範囲です。これらは文書に書いてあっても、顧客ごとの条件で答えが変わり、誤った答えが約束と受け取られるおそれがあります。

こうした質問には、回答を作らず、正式な料金のページか窓口へ案内する流れを置きます。検索・要約・回答の下書きはAIに任せてよいが、価格や契約条件の回答は人が持つ、という線です。

• 料金表のページを回答の棚に入れ、改定の日に誰も回答を確かめない
• 事例の記事や過去の告知を、検索の索引と同じ理由で回答の棚にも入れる
• 社内の共有の場所を丸ごと索引に入れ、権限が付いているはずだと確かめずに顧客向けの回答につなぐ
• 外部のAIへの窓口を匿名のキーで作り、非公開の文書の棚もつないでしまう
• 回答に出典が付いていることを、回答が正しいことの証明として扱う

最後の点は見落とされがちです。出典が付いていることは、正しいことの証明ではありません。出典の文書が古ければ答えも古い。出典は、利用者と担当者が根拠を確かめるための手がかりで、正しさの保証ではありません。

試行は狭い棚から始め、回答の記録で見直す

回答の棚を決めたら、いきなりサイト全体に載せず、狭い範囲で試します。

記録の見直しで見るのは、回答の点数ではなく、どの文書が根拠に使われたかの偏りです。特定の古い文書が繰り返し出典になっているなら、棚から外すか、新しい文書に置き換える合図です。

公式文書では、利用者が絞り込みの条件を変えると、答えもその条件で作り直されるとされています。試行では、製品や地域の絞り込みを変えたときに、出典が想定どおりに入れ替わるかも確かめておくと、棚の分け方の漏れが見つかります。

ただし公式文書では、回答に関する記録は報告にまとめられる一方、利用者の質問と生成された回答そのものは標準の報告では見られず、サポートへの依頼が要るとされています。どこまでの記録を、誰が、どの頻度で見られるかは、試行の前に確かめておきます。

回答に使わせない文書のチェックリスト

最後に、回答の棚に入れない文書を確かめるためのチェックリストを置きます。導入の前と、四半期ごとの見直しのときに使ってください。

• 社内向けの手順書・規程・会議の資料（元の場所で誰でも見られる扱いになっていないかも確かめた）
• 取引先・パートナー向けの価格表や契約の条件
• 改定前の料金表、終了した製品やキャンペーンのページ
• 持ち主の部署と最終の確認日が付いていない文書
• 日付の入った告知・イベントの報告・事例の記事（検索には残してよいが、回答の根拠にはしない）
• 未発表の製品・機能に関する資料
• 個人の名前や連絡先、顧客の個別の事情が書かれた文書

このリストに当たる文書を棚から外すと、回答できる範囲は狭く見えます。しかし、答えの根拠を説明できる範囲だけで答えるほうが、顧客との信頼は守れます。広げるのは、持ち主と更新日の付いた文書がそろってからで十分です。

まとめ

AI回答の出典がぶれるのは、AIの性能より先に、根拠にしてよい文書を誰も決めていないからです。原因は、索引の範囲と回答の範囲が同じ、文書の鮮度と持ち主が未定、閲覧の権限が回答に引き継がれていない、の3つに分けられます。Coveo は索引の文書を2段で絞り、選んだ断片だけで答えて出典を付け、権限を問い合わせの時点で当てる設計を公式文書で示していますが、どの文書を棚に置くかまでは決めてくれません。入れるなら、回答の棚を検索の索引から分けて小さく持ち、棚の文書に持ち主と更新日を置き、外部のAIに開く機能と棚を窓口ごとに決める。検索・要約・回答の下書きはAIに任せ、回答に使う文書の棚と例外、価格や契約条件の回答、外部AIへの開示は人が決める。日本語の回答は2026年10月時点でベータの扱いなので、狭い棚の試行で確かめてから広げてください。

• 製品の機能と提供状況は、Coveo の公式文書（RGA の概要・RGA のデータの安全・MCP サーバーの設定）と、2026年2月10日の発表、投資家向けの発表の一覧を2026年10月22日に確かめた範囲に基づきます
• 日本語での回答の精度、国内の窓口、料金の体系は公式の資料で確かめられなかったため、契約の前に提供元に直接確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。