AIチャットボットの回答に出典を持たせるナレッジ設計

AIチャットボットの回答に出典を付けるには、Promptに「根拠を示して」と書くだけでは足りません。正本の特定、文書の版管理、検索で取得した箇所の識別、回答のどの主張をその箇所が支えるかの検証が必要です。出典ラベルが表示されても、引用先が古い・無関係・主張を裏付けていないなら、利用者には誤った安心感を与えます。

この記事では、問い合わせ対応Botのナレッジを準備する担当者が、文書を登録する前に「どの情報を答えに使うか」「回答から原文へ戻れるか」「根拠がない場合にどう止めるか」を設計できるようにします。ここでの構造例は考え方を示すもので、特定の検索製品の必須Schemaではありません。実装では実際の検索基盤、正本管理、権限要件に合わせてください。

出典付き回答を成立させる6つのつながり

出典は回答の末尾に並べるだけではなく、正本から回答まで追跡できる必要があります。

表は横にスクロールできます

層	保存・管理するもの	ここが切れると起きること
Canonical Source	現行のFAQ、規約、手順書、料金表の正本と管理者	似た文書のどれが正しいか決められない
Version / Validity	文書の版、適用期間、公開・失効状態	古い条件が現行回答へ混ざる
Retrieval Unit	検索対象の段落・節・チャンクと元文書の対応	どの記述が検索されたのか追えない
Answer Claim	回答を検証できる主張単位	一つの引用が回答全体を支えるように見える
Citation Mapping	Claimから原文の節・ページ・範囲への対応	利用者が根拠を確認できない
QA / Fallback	根拠の十分さ、矛盾、欠落時の挙動	検索できない時にAIが一般知識で埋める

この順に作る理由は、検索技術より前に「何を正本と呼び、いつまで有効とするか」を決める必要があるからです。検索が正しく動作しても、登録資料が古い、対象者が違う、または回答に使ってはいけない資料なら、出典付きの誤回答になります。

先に正本と有効範囲を決める

FAQ、利用規約、ヘルプ記事、社内手順、価格表などを登録する前に、資料ごとに次を確認します。

• Owner：内容の変更を承認する担当者・チーム

• Authority：この資料を何の回答の正本として使うか

• Scope：対象製品、契約、地域、顧客区分、社内外のどれに適用されるか

• Version / Effective date：版と適用開始・終了日

• Status：検索対象の現行版、確認待ち、失効、保管のみの区別

• Update trigger：料金改定、契約変更、製品リリースなど、見直しを始める出来事

例えば「返金ポリシー」が一般顧客向けと法人契約向けに分かれるなら、両方を同じ検索対象へ放り込まず、対象契約や利用者の条件を識別できるようにします。対象が分からない問い合わせでは、片方を勝手に適用せず、確認質問か担当者へ回します。

ファイル名の「final」「最新版」だけで有効版を決めるのも避けます。更新日が新しくても承認前の草稿かもしれません。正本のOwnerに適用版を確認し、失効版を回答検索から外す、または履歴用途として別の検索経路に分けます。削除ではなく保管が必要な場合も、通常の回答候補には混ぜない状態を明示します。

文書Metadataは検索条件と追跡の両方に使う

Metadataは、ファイルを説明するためだけの項目ではありません。適切な資料を絞り込み、回答後にその根拠へ戻るために使います。

表は横にスクロールできます

項目例	何に使うか	入力例
source_id	同じ正本の更新版をつなぐ	billing-refund-policy
document_title	人が判別しやすい名称	返金ポリシー
section_id	引用した節を識別	refund-request-window
version	文書版	2026-04
status	検索対象かを判定	active / superseded
valid_from / valid_to	有効期間の確認	2026-04-01 / 未設定
audience / region	適用範囲	consumer / JP
owner	更新確認先	Billing Operations
source_uri	原文に戻る場所	管理された社内URL
content_hash	同じ資料の差替え検知	取込時に生成

これは一般設計の例で、field名や値をそのまま採用する必要はありません。少なくとも「元文書」「節」「版」「有効状態」「適用範囲」が辿れることを確認してください。検索サービスがMetadata filterを提供していても、そのfilterだけで認可やアクセス制御が完成するわけではありません。利用者の権限を検索前に判定する層、検索対象の分離、出力時の確認を別に設計します。

OpenAI APIのFile Searchを実装例にする場合、現行ガイドではVector Store Fileのattributesを使った検索filterが説明されています。具体的なキー数やkey/valueの上限は、ガイドと個別API referenceで記載に差があるため、実装時は採用するendpointとSDKの現行schemaを照合してください。検索に使う少数のfilter項目と、別の管理台帳に置く文書情報を分けます。これはOpenAI APIの仕様例であり、他の検索基盤に同じ機能や制約があるという意味ではありません。

検索単位を小さくしても、元資料の文脈を切らない

ナレッジ検索は、ファイル全体ではなく関係する一部の段落を取得することがあります。段落だけを保存して元文書との対応を失うと、担当者はその条件がどの文書・版・見出しにあったか確認できません。

最低限、検索された各単位に次の関係を持たせます。

• 元文書のsource_idとversion

• 見出しまたはsection_id

• ページ番号や原文の位置（取得可能な形式で）

• 有効状態と適用範囲

• 取得単位の識別子

料金表の例なら、金額だけの一行ではなく、通貨、請求周期、対象プラン、注記、適用日が同じ箇所に含まれるように分割します。前後の条件が別のチャンクへ切れている場合は、回答生成時に隣接節を追加取得する、またはその質問を回答保留へ回します。チャンクを大きくすれば常に解決するわけでもありません。関連する条項が大量に入ると、別のプランや地域の条件を一緒に拾いやすくなります。

回答を「主張」と「根拠範囲」に分ける

回答一つに複数の事実が含まれる場合、主張ごとに根拠を対応させます。例えば、

返金申請は購入後の所定期間内に行い、対象は未使用のプランです。

なら、「申請期間」と「対象条件」は別の主張として、該当する規約節がそれぞれ存在するか確認します。ひとつの「返金規定」リンクだけでは、二つの条件を同時に立証できないことがあります。

利用者に表示するLabelは、内部のfile_idだけでなく、人が開いて内容を確認できる文書名・見出し・ページや節を含めます。一方、タイトルや節名をAIに生成させて実際のSourceだと見せるのは避けます。検索結果が返した識別情報からLabelを作り、リンク先も権限を確認したうえで開けるようにします。

OpenAI API File Searchの例では、回答出力にfile_citation annotationが含まれ、file_idやfilenameを参照できます。ただしFile Searchは検索結果本文を既定ではResponseへ返さず、確認したい場合はincludeにfile_search_call.resultsを指定する手順が現行ガイドにあります。つまり「回答にcitation annotationが付いた」ことと、「アプリ側で根拠本文を検証できた」ことは同じではありません。実装するAPI・SDKの現行仕様で、どの情報が返るかを確認してください。

根拠が弱い・ない・矛盾するときのFallback

「出典を付ける」という指示だけでは、根拠が見つからない場面の挙動が決まりません。次のように検索状態と回答方針を別に定義します。

表は横にスクロールできます

検索・根拠の状態	回答方針	次のAction
現行資料に直接の根拠がある	根拠の範囲に限って回答し、該当節を表示	有効版・対象範囲を最後に確認
根拠の一部だけ取得できた	確認できる部分だけ答え、未確認条件を分ける	追加検索または確認質問
取得した資料が古い・対象外	現行条件として断定しない	Ownerまたは正本を確認
複数の現行Sourceが矛盾する	都合のよい方を選ばない	矛盾を説明し、担当へ回す
根拠が検索できない	「資料から確認できない」と回答	Source追加または人手確認
利用者の権限を確定できない	該当資料の内容を表示しない	認可系統で確認

検索にヒットしないことは「条件が存在しない」という証明ではありません。未知、未登録、対象外、権限不足を、否定回答一つにまとめないでください。検索スコアだけを根拠に「十分」と決める場合も、質問の重要度、必要な条件、引用範囲との対応を評価できる運用ルールが必要です。

Citation QAは存在確認と内容確認を分ける

Citationを付けた回答を、最低でも次の二段階で確認します。

1. Presence：回答が必要な主張に出典を付けているか。

2. Support / Entailment：引用した箇所がその主張を実際に支えているか。

例えば料金の節を引用して解約期限を説明している回答は、Citationが存在してもSupportでは不合格です。また、引用節が対象プラン・地域・契約種別に適用されるか、回答が期限や例外条件を省いていないかも確認します。

公開前の評価セットを作る

問い合わせをそのまま評価用に使う前に、個人情報や秘匿情報を除き、次のタイプを含めます。

• 現行Sourceで答えられる標準質問

• 答えの一部だけ根拠がある質問

• 旧版と新版の内容が違う質問

• 二つのSourceの記述が食い違う質問

• 対象プラン・地域が分からない質問

• 正本に答えがない質問

• 引用は付くが、引用先が別の条件を説明している質問

各ケースで、(a) Answerable / Unknown判定、(b) 取得SourceとVersion、(c) Claimと引用箇所、(d) 不足・矛盾時のFallbackを確認します。正答率だけでは不十分です。誤った引用、古い版の選択、回答を保留すべきケースで断定した数を別々に記録します。評価セット自体も、正本が更新されたときに見直してください。

更新を検索へ反映する手順

文書を差し替える時は、新版の登録だけで終えず、切替の前後を追跡します。

1. 正本Ownerが新版と適用開始日を承認する。

2. 旧版と新版の差分、影響する回答・検索語を記録する。

3. 新版を取り込み、Metadata・分割・検索結果を確認する。

4. 切替前に新版から適切な節が取得されるか評価する。

5. 適用開始後、通常検索から旧版を外すか、明示的な過去照会だけに分離する。

6. 旧版をいつ、誰が、何のために参照可能にするか決める。

7. 代表質問と、過去に失敗した質問を再実行する。

古い資料を単に削除すると監査や過去契約の照会に困る場合があります。逆にactiveとsupersededを同じ検索対象に残すと、現行回答に旧条件が混ざることがあります。回答用の現行検索と履歴確認を別の経路にするか、検索前に有効版へ絞り込む設計にします。

導入前のチェック

• Answerable / Unknown / conflicting / out-of-scopeの挙動が決まっている

• 主要質問で正本Ownerと有効版を特定できる

• 取得単位から原文の節・版・適用範囲へ戻れる

• 回答を主張単位で評価できる

• 生成Citationの存在と、引用が主張を支えることを別々に検査する

• 旧版が通常回答に混ざらないことを評価ケースで確認した

• 利用者の権限を検索結果の絞り込みとは別に確認する

• Source更新の責任者、反映手順、再評価ケースが決まっている

• 検索結果がない時に、一般知識で補って断定しない

• 失敗時に人が確認する担当と記録場所がある

AIものさしの判断

Citationの見栄えを先に作るより、資料の正本・版・適用範囲を決め、検索した節を回答の主張へ結び付ける順番が重要です。出典名が表示されたかだけでなく、引用先がその条件を本当に支えているか、古い情報や対象外の規約が混ざっていないかを評価してください。根拠が弱い、矛盾している、権限が分からない場合には、回答を狭めるか人へ回す設計が必要です。

情報の根拠 / 確認した公式情報

確認日：2026-10-10

OpenAI API「File search」：https://developers.openai.com/api/docs/guides/tools-file-search（新しいタブで開く）

OpenAI API「Retrieval」：https://developers.openai.com/api/docs/guides/retrieval（新しいタブで開く）

OpenAI API Reference「Search vector store」：https://developers.openai.com/api/reference/resources/vector_stores/methods/search（新しいタブで開く）