AIのグラウンディングとは：LLMの回答を根拠に結び付ける

AIのグラウンディングとは、言語モデルの回答を、タスクに関連し、特定できる根拠に結び付けることです。文書に基づく回答では、事実に関する各主張を、適用可能な原文箇所や検証済みの観測で裏付ける必要があります。テキストをコンテキストに入れるだけでは、モデルがそれを正しく使ったとは確認できません。

執筆：Ai Flowi · 公開日 2026-10-11

グラウンディングは、情報源自体が真実であると証明することとも異なります。回答が古いポリシーを忠実に要約している場合もあります。回答と提示された根拠との関係に加え、その根拠が最新で、信頼できる正式なものであり、ユーザーに適しているかも確認します。

コンテキストがあることと主張を裏付けることの違いは何ですか？

検索は、資料の候補をアプリケーションに取り込みます。コンテキストの構築では、モデルに何を渡すかを決めます。グラウンディングが扱うのは、回答とその資料との関係です。これらの段階は、それぞれ独立して失敗し得ます。正しい原文箇所を検索できても取り除かれたり、含まれていても回答がそれに矛盾したりすることがあります。

引用は情報源の場所を示しますが、裏付けには、その場所が実際に主張を根拠付けることが必要です。発送明細は出荷対象として何が記載されたかを示し、受領記録は到着時に何が記録されたかを示します。配達・到着を主張する回答に発送明細を引用すると、その主張に必要な観測を、前段階の記録で置き換えることになります。

検索と生成を組み合わせた構成は、RAGの定義で扱います。この記事では主張の裏付けを掘り下げます。文書の取り込み手順は、既存のナレッジベースのガイドをご覧ください。

主張と原文箇所の対応表

架空の出荷レビューを考えます。レコードS-Aは「発送明細には、出荷用の木箱が3個記載されている」、S-Bは「受領担当チームは、到着時に木箱2個を記録した」、S-Cは「不一致は引き続き調査中である」と述べています。担当者には、記録された不一致と、提案される説明を区別した状況要約が必要です。

対応表の各判断には、LLMのハルシネーションにある失敗の分類を使ってラベルを付けます。

この執筆者が作成した対応表から、記録には木箱1個分の差があり、原因は未解決である、という状況要約が得られます。記録ミスもあり得るため、実物の木箱がちょうど1個不足していると確認したわけではありません。成果物は、確認可能な記録の説明であり、運送業者の責任の認定でも、観測されたモデルの結果でもありません。

限定表現と情報源の範囲を保持する

「記載されている」と「記録した」という動詞を保持します。どちらかを「配達された」に置き換えると、文書に関する記述が、物理的な出来事についての主張に変わります。「到着時に」も残します。後の訂正で最終的な受領個数が変わっても、元の到着記録が消えるわけではないからです。

訂正された受領記録が後から現れた場合は、対応表のレビュー時点を明示します。過去の状況の要約では、到着時の個数を残して訂正を付記できます。現在の状況の要約には、訂正後の個数とその情報源が必要です。古いレコードの識別子を付けたまま、抜粋だけを黙って上書きしてはいけません。

導出した主張では、必要な前提をすべて示します。個数の差には、発送明細だけでなく、両方のレコードが必要です。対応表の確認担当者が、引き算を再現し、同じ出荷の記録であると特定できるようにします。無関係な出荷の個数を比較すると、計算自体は正しくても、誤った結論につながります。

欠落が分かる回答仕様を設計する

仕様案では、回答文、情報源の識別子、裏付けとなる引用、未解決情報のフィールドを要求できます。この出荷レビューでは、未解決フィールドに、不明な原因と、訂正された受領記録が存在するかどうかを残す必要があります。空欄では、要約に大きく影響する未解決の問いが隠れてしまいます。

複数の主張を含む文は、採点の前に分けます。「木箱2個が到着したのは、運送業者が1個紛失したためだ」は、受領の観測と、確認されていない原因を結び付けています。前半の到着に関する主張は、チームが記録した内容に限定できます。原因の主張には、存在しない根拠が必要です。文全体に1つの「裏付けあり」ラベルを付けると、有効な個数を通じて因果関係の主張まで正当化してしまいます。

回答が訂正版の受領記録の確認を提案する場合は、次に行う作業を記す別欄に置きます。それは執筆者が提案するレビュー作業であり、出荷に関する追加の事実ではありません。回答の語調から読者が推測しなくても、その違いが分かる対応表にします。

カタログのコンポーネントにおけるグラウンディング

Knowledge Baseの文書では、根拠として使うレコードの検索を説明しています。

検索したレコードをテキストに整形するインターフェースは、Parserのページに記載されています。

Prompt Templateリファレンスでは、対応表を要求するリクエストの組み立てを説明しています。

構造化出力の項目では、確認可能なフィールドを表すための回答仕様を説明しています。

この対応表で提案するアプリケーションのフィールドは、claim、source_ids、excerpt、decision、reasonです。導出した個数の主張には、S-AとS-Bの両方を必須にします。理由には、情報源と主張をつなぐ計算や限定条件を示します。「裏付けあり」を長く言い換えるだけにしてはいけません。これらは執筆者が設計したフィールドであり、標準のスキーマ取り込み形式ではありません。

引用した個数が同じ出荷と処理段階に属することを確認してから、不一致に関する記述を受け入れます。別の調査結果で裏付けられるまで、運送業者による紛失という説明は拒否します。これにより、レビューの判断が具体的になります。S-Cへの引用を追加しても、その主張の裏付け不足は解消できません。S-Cが報告するのは調査の状況であり、結果ではないからです。

カタログに記載されていますが、Ai Flowiによる本番環境でのテストは行われていません。

対応表で使うコンポーネントは、コンポーネントカタログで確認してください。モデルを使った出荷レビューには、ご自身で用意するアカウントとAPI認証情報が必要です。外部の生成料金は、ワークフローのサブスクリプションに含まれません。

レビューの限界とよくある誤り

不完全な根拠、矛盾する根拠、無関係な根拠も含め、対応表の判断を原文箇所と照合します。回答とその裏付けの対応表を同じモデルが書くと、両方で同じ誤りを繰り返す可能性があります。理由フィールドがあることは、独立した検証ではありません。

スキーマに適合していることと、事実に関する主張が正しいことを同一視したり、原文箇所を確認せずに情報源の識別子を裏付けとして扱ったりしないでください。また、根拠がないときに、正直に不明とした回答を減点することも避けます。この出荷レビューでは、運送業者への非難を所見として提示するより、原因を未解決のまま保持するほうが適切です。

失敗の分類はLLMのハルシネーションを、タスクの設計はプロンプトエンジニアリングをご覧ください。アプリケーションのコンポーネントは、Agentリファレンスとユースケース集で扱います。グラウンディングは主張を確認可能にしますが、情報源の真実性を保証したり、重大な影響を伴う行動を許可したりするものではありません。