長文 PDF を Claude に読ませる時のコンテキスト設計
「100 ページの PDF を AI に読ませたら、要約はそれっぽいけど細かい質問の答えがズレている」――よくある失敗です。Claude の 1M context をもってしても、PDF をそのまま貼り付ける だけでは精度を引き出せません。本記事では、長文 PDF を扱う時の コンテキスト設計の実践 を解説します。
PDF を貼るだけで精度が落ちる原因
PDF を AI に渡す時、次の 3 つで精度が落ちます。
- レイアウト破壊: 表組み・段組み・脚注がテキスト抽出時に崩れる
- 構造情報の欠落: 章立て・目次・索引が無視される
- 冗長性: ヘッダー・フッター・ページ番号など同じ文字列が大量に混在
これらを 前処理 で整えることで、AI が情報構造を理解しやすくなります。
構造化前処理（3 ステップ）
ステップ 1: 章立て抽出
PDF のテキスト抽出後、まず 章立て を AI に抽出させます。
以下の PDF テキストから、章立て（目次相当）を抽出してください。
階層構造を Markdown 見出しで表現してください。
# テキスト
{{pdf_text}}
# 出力
# 第 1 章: ...
## 1.1 ...
## 1.2 ...
# 第 2 章: ...
これで「文書全体のマップ」が手に入ります。
ステップ 2: 章ごとに TL;DR を生成
抽出した章立てに沿って、各章 5 〜 10 行の TL;DR を生成します。
以下の章のテキストから、TL;DR を 5 行で書いてください。
# 章
{{chapter_title}}
# 本文
{{chapter_text}}
各章の TL;DR を 元の章本文の冒頭に挿入 すると、AI が長文を「俯瞰」しやすくなります。
ステップ 3: 索引を文書冒頭に置く
最終的にこういう構造にします。
# 索引
- 会社概要 → 第 1 章
- 製品 A → 第 2.1 章
- 価格表 → 第 3 章
# 第 1 章: 会社概要
**TL;DR**: 創業 2010 年、SaaS 中心、200 名。
（本文）
# 第 2 章: 製品
**TL;DR**: 主力 3 製品、エンタープライズ向けが伸長中。
## 2.1 製品 A
（本文）
これで Claude は長文 PDF でも、必要な箇所を的確に参照できます。
プロンプト側の指示の書き方
長文コンテキストを扱う時のプロンプト側にもコツがあります。
以下の文書を踏まえて、質問に答えてください。
# ルール
- 答えの根拠を「第 X 章の Y 段落」のように明示する
- 文書に書かれていない内容は推測せず「不明」と明示する
- 関連する複数の章を参照すべき場合は、章を全て列挙する
# 質問
{{question}}
# 文書
{{long_document}}
「根拠の章を明示する」を入れることで、AI が「もっともらしい嘘」を作るのを防げます。
100 ページ超を扱う段階的手順
PDF が 200 〜 300 ページに及ぶ場合、1 回のリクエストで処理しないほうが安定します。
- 目次抽出: PDF 全体から目次だけを抽出
- 質問 → 関連章特定: 質問内容から目次を見て、関連しそうな 2 〜 3 章を選定
- 関連章のみで回答: 該当章だけをコンテキストに入れて Claude に質問
- 不足時のみ追加章: 答えに不確実性が残れば、関連章を追加
この 段階的な情報提示 は、RAG のような検索インフラを使わずにできる軽量版アプローチです。
Prompt Caching の活用
同じ PDF に対して 複数の質問 を投げる業務（例: マニュアル参照 Bot）では、Prompt Caching を使うとコストが大幅に下がります。
- キャッシュ対象: PDF 本文（構造化前処理後）
- 変動部分: 質問のみ
Claude の Prompt Caching は同じシステムプロンプト・コンテキストを使い回す業務で 10 倍コスト効率が変わることもあります。
PrompTune で運用する
長文コンテキストの品質は、PrompTune の コンテキスト診断モード で 5 軸スコアリング可能です。構造化前処理が適切か、ノイズが多すぎないかを診断できます。