AIで長文資料の回答にページ番号・根拠を付けて確認する方法

長文資料へAIで質問する場合は、回答だけでなく「根拠文とPDF上のpage / section」をセットで受け取ります。citationから原文へ戻り、周辺条件を確認できて初めて重要な判断へ使えます。

AIものさし編集部

長文PDFや社内資料へAIで質問するとき、回答だけを受け取ると「その結論がどこに書いてあるのか」を確認できません。重要な判断に使うなら、回答・根拠となる記述・page / section・確認状態を一緒に残し、citationから原文へ戻れる形にします。

この記事では、契約書・調査レポート・マニュアルのような長文資料を想定し、質問を具体化し、Evidence-linked Answerを作り、page番号のずれや複数箇所にまたがる条件まで検証する方法を整理します。最終的には「答え」ではなく「どこを読めばその答えを再確認できるか」まで説明できる状態を目指します。

最初に質問をFieldへ分解する

「契約条件を教えて」「重要なところを教えて」のような質問は広すぎます。対象と欲しいFieldを明示します。

たとえば契約書なら、契約期間、更新条件、解約期限、料金、支払条件、責任上限、例外などへ分けます。調査レポートなら、対象期間、サンプル、主要結論、数値、条件、推奨事項などです。

質問をHigh Risk / Normalへ分ける

すべての質問を同じ確認強度で扱う必要はありません。料金、契約、権利、法規、安全性、顧客への正式回答など、誤ると影響が大きいFieldはHigh Riskとして原文確認を必須にします。

背景説明や参考情報のようなLow Risk項目はSpot Checkでもよい場合があります。確認コストを重要なFieldへ集中させます。

Evidence-linked AnswerのSchemaを固定する

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

Field内容
Question元の質問
Answer資料から確認できる回答
Evidence根拠箇所の要旨
Viewer PagePDF Viewer上のpage
Printed Page印刷ページがあれば記録
Section / Clause見出し・条番号
Condition / Exception適用条件・例外
StatusVERIFIED / PARTIAL / NOT FOUND
Note未確認点

この形なら、AIの文章と原文の位置を一対一で追えます。

AIへの依頼文は回答と根拠を同時に要求する

「以下のPDFだけを根拠に質問へ答えてください。

出力はQuestion / Answer / Evidence / Viewer Page / Printed Page / Section / Condition / Status。

資料に書かれていない内容は補完しない。回答を支える箇所が複数ある場合はすべて列挙する。根拠が見つからない場合はNOT FOUND。条件や例外を省略しない。」

回答の自然さより、原文へ戻れることを優先します。

Citationが回答を直接支えているか確認する

Citationが付いていても、そのpageに関連語があるだけで、Answerを直接支えていない場合があります。

たとえば回答が「30日前までに解約が必要」なのに、citationが契約期間だけ説明しているなら不十分です。該当する解約条項を探し直します。

原文の前後も読む

AIが示した1文だけでは、直後に例外があるかもしれません。重要事項は前後1〜2段落、必要なら同じClause全体を確認します。

「ただし」「除く」「場合に限り」「unless」「except」のような条件表現がある場合は、要約から落ちていないかを重点確認します。

Page番号の2種類を区別する

PDF Viewerのpage番号と文書に印刷されたpage番号は一致しないことがあります。表紙・目次・前付けがある資料で起きやすい問題です。

共有時に迷わないよう、「Viewer p.18 / printed p.12」のように両方記録します。印刷番号がない資料はViewer pageだけで構いません。

Section / Clauseも一緒に持つ

契約書なら「第8条 解約」、マニュアルなら「3.2 権限設定」のようにSectionを残します。page番号だけだと版が変わったときにLocatorがずれることがあります。

Page + Sectionの2つがあると、更新版でも同じTopicを探しやすくなります。

複数箇所が1つのAnswerを構成する場合

長文資料では、Answerが1箇所に完結していないことがあります。料金は料金表、解約期限は本文、例外は別紙というケースです。

この場合、citationを1件だけに絞らず、Answerを構成するすべてのLocatorを残します。各Evidenceがどの部分を支えるかも分けます。

架空例:解約条件を確認する

Question:いつまでに解約通知が必要?

Answer:通常契約は更新日の30日前まで。

Evidence A:第8条「更新日の30日前までに書面通知」Viewer p.14 / printed p.10。

Evidence B:別紙「Enterprise契約は60日前」Viewer p.28。

Condition:通常契約は30日、Enterpriseは60日。

Status:VERIFIED。

数字は説明用の架空例です。Evidence Bを落とすと、重要な例外を誤って一般化してしまいます。

資料内にない場合はNOT FOUNDにする

質問に関連する記述が見つからないとき、AIの一般知識で補完させません。「資料内では確認できない」と返します。

その後、別紙、FAQ、公式Webなど別Sourceを探す必要があるか判断します。NOT FOUNDは回答失敗ではなく、資料のCoverageを示す結果です。

PARTIALを使う

Answerの一部だけ確認できる場合はPARTIALにします。

たとえば「料金は月額5万円まで確認できたが、初期費用は資料内に記載なし」という場合、全体をVERIFIEDにしません。Field単位でStatusを持つと安全です。

根拠の優先順位を決める

本文、Appendix、FAQ、旧版など複数の資料がある場合、どれをSource of Truthとして扱うか決めます。たとえば契約条件なら締結対象の最新版契約書、運用手順なら現行マニュアル、製品仕様なら公式最新版というようにします。

同じ組織の資料でもVersionや用途が違えば優先度は変わります。AIに「新しい方を自動採用」させず、文書の正式性と適用範囲を確認します。

表・脚注・別紙を見落とさない

重要条件が本文ではなくTable、Footnote、Appendixにあることがあります。AIが本文抽出中心だと落ちる可能性があります。

数字や契約条件は、該当pageの表・脚注も人が確認します。OCRが必要なPDFでは、数字認識の誤りにも注意します。

質問を一度に増やしすぎない

20項目を一括質問すると、CitationとAnswerの対応が崩れやすくなります。重要Fieldから5〜10件程度でPilotし、出力Schemaが安定してから増やします。

特に契約・法務・財務に関わるFieldは、少数ずつ原文確認する方が安全です。

Citation QA Checklist

  • CitationがAnswerの主張を直接支えている

  • Page / Sectionへ実際に戻れる

  • 否定・条件・例外が落ちていない

  • Viewer pageとprinted pageを区別した

  • 複数Locatorが必要なら全部残した

  • 表・脚注・Appendixを確認した

  • 資料外の知識を補っていない

  • NOT FOUNDとNoを混同していない

回答の強さをEvidenceに合わせる

原文が「may」「可能性がある」としているのに、AIが「必ず」と断定したら意味が変わります。

Answerの表現はSourceの確実性を超えないようにします。推奨、義務、許可、禁止、可能性を区別します。

Version違いを記録する

同じ資料名でも2025版と2026版でpageや条件が変わることがあります。Document Title、Version、発行日、File ID等をEvidence Logへ残します。

新版が出たら同じ質問セットを再実行し、変化したFieldを差分確認できます。

Version差分はField単位で見る

新版と旧版を全文比較しても変更点が多すぎる場合があります。契約期間、料金、権限など重要Fieldを先に比較し、CHANGE / SAME / REMOVED / ADDEDへ分類します。

変更されたFieldだけ原文を重点確認すれば、再監査が速くなります。

Evidence Logを作る

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

Question IDDocument VersionAnswerLocatorStatuschecked_at
Q01v202630日前p.14 / 第8条VERIFIED2026-10-06
Q02v2026初期費用記載なし—NOT FOUND2026-10-06

後から「どの版のどこを見たか」を追える形にします。

複数人レビューでも同じSchemaを使う

法務、営業、運用など複数人が確認する場合も、自由コメントだけではなくQuestion IDとStatusを共通化します。

誰かがPARTIALにしたFieldを別の人が追加SourceでVERIFIEDへ更新する、といった引き継ぎができます。原文位置が共通なので再確認も速くなります。

回答を利用する前の最終判断

社内メモのような低Risk用途ならCitation spot checkで十分なことがあります。一方、契約、支払い、規制、安全、顧客への正式回答などHigh Risk用途では、該当原文を人が確認してから使います。

AIのEvidence-linked Answerは確認を速くする道具であって、重要判断の責任そのものを置き換えるものではありません。

よくある失敗

  1. 回答だけ保存しCitationを消す。

  2. Citationが関連ページなら十分と考える。

  3. 前後の例外を読まない。

  4. Viewer pageと印刷pageを混ぜる。

  5. 1つのCitationで複数条件を代表させる。

  6. NOT FOUNDを「存在しない」と書く。

  7. 資料Versionを記録しない。

AIものさしの判断

長文資料へのQ&Aで重要なのは、回答生成よりEvidence Traceabilityです。Answer・根拠・Page / Section・条件・Statusをセットにすると、AIの回答を原文へ戻って検証できます。

まず重要な質問を5件選び、Evidence-linked Answer Schemaで回答させてください。Citationを実際に開き、前後・例外・page番号を確認する。これが安定してから質問数を増やせば、長文資料でも「AIがそう言った」ではなく「この版のこの箇所に書いてある」と説明できるようになります。

次に読む・使う

この記事の次に必要な情報へ進めます。