LLMO対策でAIの誤回答を直す。MongoDBは自社の正解集と回答を照合し、自社関連の質問で正確性90%超を報告

AIが自社を紹介してくれても、案内された手順が古ければ、利用者は途中で困ります。MongoDBが取り組んだのは、この「紹介されるが、答えが正しくない」という問題でした。

同社の事例では、MongoDB関連の質問に対するAI回答の正確性が90%超になったと報告されています。Profoundの事例

AIに正しく説明してもらうためのLLMO対策として、自社の正解とAI回答を見比べ、元の資料へ修正を戻す方法を考えます。

MongoDBが困っていたAIの回答：登録後の手順が抜け、古いドキュメントを案内する

MongoDBでは、AIが登録後に必要な手順を省いたり、古いドキュメントへ案内したりする問題が報告されています。Profoundの事例

説明図：古い資料や抜けた手順が、利用者とAIの理解を妨げる場面を示す。

例えば、説明用の想定として「登録したら使える」と案内されても、実際には接続設定が必要なら、利用者は先へ進めません。会社名が回答に出たかだけを見ると、この問題を見落とします。

自社の製品についても、料金や機能だけでなく、申し込み後に何をするかまで答えを読みます。正しい製品が紹介されていても、正しい使い方が説明されているとは限りません。

自社の正解Q&Aと照合し、誤った引用を原文の修正へ戻す

MongoDBは、自社で用意した正解のQ&AとAI回答を照合し、誤りと引用元を調べて、元のコンテンツの改善へつなげています。Profoundの事例

説明図：用意した正解とAIの回答を比べ、相違点を根拠資料へ戻って確認する。

自社でも、まず「正しい答えは何か」を決める必要があります。担当者の記憶だけで判断せず、現行の仕様や運用資料を根拠にします。

そのうえで、AI回答のどの文が違うか、何が抜けているかを確認します。引用されたページにも同じ誤りがあるなら、そのページの修正を検討できます。

外部サイトの古い情報なら、自社から直接変更できるわけではありません。現在の仕様を示すURLを添え、運営者へ訂正を依頼する対象として記録します。

引用の集約とschema提案の2つを自動化し、更新時間を約30%短縮

事例では、引用情報の集約とschemaの提案を行う二つのAgentが紹介され、リリース更新に関する作業時間が約30%減ったとされています。Profoundの事例

これは会社全体の作業時間が30%減ったという数字ではありません。schemaはページ内容を機械にも伝える構造化データであり、提案が出ても、実際の本文や仕様と合っているかを確認してから反映します。

可視性50%増と、MongoDB関連質問での正確性90%超は何を測った数字か

可視性50%増は、調べたAI回答での紹介され方の変化です。正確性90%超は、MongoDB関連の質問についての評価であり、AI全般の正答率ではありません。Profoundの事例

説明図：会社が紹介されたかと、説明が正しいかは、別々に確かめる。

元資料では、すべての質問や採点の細かな条件までは公開されていません。自社で同じ数字を目標にする前に、どんな誤りを減らしたいかを決める方が実務につながります。

例えば、登録後の操作を正しく案内できるかと、料金の数字が合っているかは別の確認です。内容別に結果を残すと、修正する資料が分かります。

自社で試す：よく聞かれる質問の正解表を作り、AIの回答と見比べる

まず、問い合わせで繰り返し聞かれる質問を三つ選び、正しい答えと根拠のURLを表にします。以下は編集部の提案です。

説明図：質問・正解・根拠URL・確認日をそろえ、回答と照合する。

質問の例	正解表に残すもの	AI回答で見るところ
登録後は何をする？	必要な操作と順番	手順の抜け、順序の違い
このプランで使える？	対象機能と条件	古いプランや対象外機能
データを移せる？	移行可能な項目と制限	移せない項目まで含めていないか

同じ質問を対象のAIへ尋ね、回答、日付、引用URLを残します。誤りを見つけたら、正解表の根拠と照らし、修正すべきページを一つ決めます。

公開後も同じ条件で再確認します。直した当日にAI回答が変わらなくても、すぐに別の修正を重ねず、変更日と回答の記録を残してください。

自社の正解表を更新するときは、仕様の確認日も変えます。AIを点検するための表自体が古くならないようにすることが、継続運用の土台です。