PDFハイライトをChatGPTとRAGで活用するワークフロー
PDFの注釈をAIやRAGワークフロー向けにエクスポートするには、pdfannotations.com にPDF(またはXFDF/XML FDF)を読み込み、AI Context Markdown(ChatGPT・Claude・Geminiに貼り付けるために設計された構造化フォーマット)か、RAG JSON(ベクトルデータベースに書き込めるスキーマ対応JSONデータ)を選びます。どちらのフォーマットもサーバーアップロード不要でブラウザー内だけで完結し、LLMや検索パイプラインが必要とするメタデータ(ページ・色・作成者・日付・タグ)をすべて保持します。これにより、モデルの回答をあなたのソース資料にしっかり基づけられます。
本ガイドでは両方のエクスポートフォーマットを解説し、それぞれの使い分けと、出力をChatGPTの会話・LangChainの検索パイプライン・自作ベクトルデータベースに接続する方法を紹介します。
なぜLLMにPDF注釈を読ませるのか?
PDFを読むことと、ハイライトを活用することは別物です。多くの知識労働者は「重要な箇所をハイライトした」だけで終わり、二度と見返しません。注釈をLLMに読ませると状況が変わります。
- 統合。 200件のハイライトを3段落の要約にまとめるようLLMに依頼。
- クロスリファレンス。 「これらのハイライトのうち矛盾するものはどれ?」と数秒で回答。
- ドラフト作成。 ハイライトを文献レビューやメモ、メール要約の素材として活用。
- 質問応答。 RAGパイプラインを組み、ハイライトに対して自然言語で質問(「12ページで筆者は構成概念妥当性についてどう述べている?」)。
- 翻訳とトーン調整。 学術的なハイライトを非専門家向けの平易な説明に書き直すようLLMに依頼。
厄介なのは、LLMには構造が必要なことです。整理されていない200件のハイライトをチャット欄に貼り付けると、構造のない塊になり、モデルが正確に引用するのは困難です。だからこそ pdfannotations.com は目的別のエクスポートフォーマットを2つ用意しています。
フォーマット1:AI Context Markdown
AI Context Markdown は、チャットの会話に貼り付けるために特化して設計された構造化Markdownフォーマットです。その構造がLLMに明示的なアンカーを与え、回答時の引用精度が劇的に向上し、ハルシネーションが減ります。
構造
# Source: research-paper.pdf
Author: Jane Doe
Pages: 32
Exported: 2026-07-22
## Page 12
### Highlight
> The most reliable predictor of long-term success is consistent practice over time.
### Context
Discussion of the role of deliberate practice in skill acquisition.
### My Note
This connects to the Ericsson framework I read last week.
### Tags
#key-concept #practice #skill-acquisition
## Page 15
### Highlight
> Sample size was limited to 30 participants, which constrains generalizability.
### Context
Limitations section.
### My Note
Flag for follow-up — need to check if a replication exists.
### Tags
#limitation #methodology
階層は次のとおりです:
# Source— ソースファイル名を示す最上位見出し。作成者・ページ数・エクスポート日付をメタデータとして併記## Page N— 注釈を含むページごとに1セクション### Highlight— PDFでハイライトした原文### Context— ハイライトが文書中のどこにあるか(セクション、段落位置)を1行で記述### My Note— そのハイライトに付けたあなたのコメントや付箋### Tags— 色カテゴリとあなたが割り当てた任意のタグ
この構造が重要なのは、LLMに次のものを与えるからです:
- アンカー。 各ハイライトは
### Highlight見出しで包まれており、モデルが引用できます(「12ページのハイライトによると……」)。 - 出所。 ページ番号とソースファイル名のおかげで、モデルは主張の内容だけでなくどこから来たかも教えられます。
- あなたの解釈。
### My Noteフィールドはあなた自身のコメントで、モデルはこれを使ってハイライトのどこが重要だったかを理解できます。 - 絞り込み可能なタグ。 タグがあれば「
#limitationタグの付いたハイライトだけを要約して」と頼めて、絞り込まれた回答が得られます。
AI Context Markdown の使い方
- pdfannotations.com で AI Context フォーマットを使って注釈をエクスポート。
- 生成された
.mdファイルをテキストエディタで開き、内容をコピー。 - ChatGPT・Claude・Gemini の新しいチャットに貼り付け。
- 次のようなプロンプトを先頭に追加:「以下はある論文からのハイライトで、ページごとに構造化しています。主張を3文で要約したうえで、
#key-conceptタグを付けたハイライトを3つ挙げてください。」
このフォーマットはプレーンMarkdownなので、どのモデルでも同じように扱えます。特別なプラグインもAPI呼び出しもベクトルデータベースも不要です。
AI Context Markdown を使うべきとき
- 単一文書のハイライトについてLLMと1回限りの対話をしたい
- モデルに特定のページやタグを引用してほしい
- 探索的分析をしていてプロンプトを繰り返し改善したい
- ベクトルデータベースやembeddingパイプラインを構築したくない
フォーマット2:RAG-Ready JSON
RAG JSON は、ベクトルデータベースへの取り込みを想定した構造化JSONデータです。各注釈は独自のテキストとメタデータを持つ独立したレコードになるため、embeddingパイプラインは文書全体を1塊として扱うのではなく、個々のハイライトをチャンク化・ベクトル化・検索できます。
構造
[
{
"text": "The most reliable predictor of long-term success is consistent practice over time.",
"metadata": {
"source": "research-paper.pdf",
"page": 12,
"type": "highlight",
"author": "Jane Doe",
"date": "2026-07-20T12:00:00Z",
"color": "#FFEB3B",
"tags": ["key-concept", "practice", "skill-acquisition"],
"note": "This connects to the Ericsson framework I read last week."
}
},
{
"text": "Sample size was limited to 30 participants, which constrains generalizability.",
"metadata": {
"source": "research-paper.pdf",
"page": 15,
"type": "highlight",
"author": "Jane Doe",
"date": "2026-07-20T12:10:00Z",
"color": "#F44336",
"tags": ["limitation", "methodology"],
"note": "Flag for follow-up — need to check if a replication exists."
}
}
]
各レコードは2つのフィールドを持ちます:
text— embedding対象のハイライト本文metadata— 構造化オブジェクト。内容は:source— ソースPDF/XFDFのファイル名page— ハイライトがあるページ番号type—highlight・note・underline・strikeout・freetextauthor— Acrobatで注釈を作成した人date— 注釈作成のISO 8601タイムスタンプcolor— マークアップのRGB 16進値tags— タグ配列(色カテゴリ+任意のカスタムタグ)note— あなた自身のコメント本文(あれば)
この構造は、Pinecone・Weaviate・Chroma・Qdrant・pgvector などのベクトルデータベースが期待する標準フォーマットです。embedding用の text フィールドと、検索時のフィルタ用 metadata フィールド。
RAG JSON をベクトルデータベースに取り込む方法
正確なコードはスタック次第ですが、パターンはどこでも同じです:
- 各
textフィールドをベクトル化(OpenAItext-embedding-3-small、Cohere、Voyage、または sentence-transformers によるローカルモデルなど、お好みのembeddingモデルを使用)。 - embeddingをベクトルデータベースに保存。
metadataオブジェクトはフィルタ可能なフィールドとして付与。 - クエリ時、ユーザーの質問をベクトル化し、top-kの近傍ハイライトを取得して、コンテキストとしてLLMに渡す。
以下は、Python で OpenAI クライアントと汎用ベクトルストアを使った最小例です:
import json
import openai
client = openai.OpenAI()
with open("annotations_rag.json") as f:
records = json.load(f)
vectors = []
for record in records:
embedding = client.embeddings.create(
input=record["text"],
model="text-embedding-3-small"
).data[0].embedding
vectors.append({
"id": f"{record['metadata']['source']}-p{record['metadata']['page']}-{record['metadata']['type']}",
"values": embedding,
"metadata": record["metadata"],
"text": record["text"]
})
# Upsert `vectors` into your vector store of choice
# (Pinecone, Weaviate, Chroma, Qdrant, pgvector, etc.)
取り込みが済めば、自然言語で質問し、それに答える具体的なハイライトを検索できます。結果には完全な出所(ソース・ページ・作成者・色・タグ)が付与されます。
RAG JSON を使うべきとき
- 文書が多数あり、一度にすべて横断検索したい
- メタデータでハイライトを検索したい(「Jane Doe の論文の
#limitationをすべて見せて」) - 注釈の上に本番運用のQ&Aシステムやチャットボットを構築したい
- ハイライトを他の知識源(Webページ・社内文書・コード)と1つの検索インデックスに統合したい
ChatGPT・Claude・Gemini に貼り付ける
ベクトルデータベースを構築せずにアドホック分析をしたい場合、AI Context Markdown が最速の道です。主要モデルごとの使い方を紹介します。
ChatGPT
- ChatGPT で新しい会話を開始(長いコンテキスト向けに GPT-4o 以降を推奨)。
- AI Context Markdown の内容を最初のメッセージとして貼り付け。
- プロンプトを追加:「以下はある論文からのハイライトで、ページごとに構造化しています。主張を要約したうえで、
#key-conceptタグを付けたハイライトを3つ、ページ番号付きで挙げてください。」
ChatGPT はMarkdownをネイティブに扱うため、### Highlight 見出しや > 引用ブロックが正しく描画され、モデルはページを正確に引用できます。
Claude
Claude(特に Claude 3.5 Sonnet と Claude 4)は長文書の構造化推論がとりわけ得意です。AI Context Markdown を貼り付け、統合を依頼します:
「以下はページごとに構造化した論文のハイライトです。最も強い主張3つと最も弱い主張3つを、それぞれページ番号付きで挙げてください。」
Claude の大きいコンテキストウィンドウ(200K tokens)のおかげで、1つの会話に複数論文のハイライトを貼り付けられます。
Gemini
Gemini はMarkdownのサポートが良く、Google Workspace と連携できるため、LLMの出力を Google Doc や Sheet に送りたい場合に適しています。AI Context Markdown を貼り付け、次のようにプロンプトを入れます:
「以下はPDFのハイライトをページごとに構造化したものです。Google Sheets に貼り付けられる表を、Page・Highlight・My Note・Tags の列で作ってください。」
LLM出力を良くするコツ
- 常にページ引用を求める。 AI Context フォーマットは見出しにページ番号を埋め込んでいるので、「各主張にページ番号を引用して」と頼むとモデルに明確なアンカーができ、ハルシネーションが減ります。
- タグをフィルタとして使う。 「
#limitationタグのハイライトだけを考慮して」とプロンプトで絞り込みます。 - 自分のノートも提供する。
### My Noteフィールドはあなたの解釈です。モデルになぜハイライトしたのかを推論させたいなら、ノートを考慮するよう明示的に指示します。 - 大きなエクスポートは分割する。 500件以上のハイライトがある場合、エクスポートを複数ファイル(ソース文書ごとに1つ)に分け、別々の会話で処理します。各会話が焦点を保ち、コンテキストウィンドウのオーバーフローを防げます。
実際のユースケース
学術的な文献レビュー
教育測定の論文を50本読む博士課程の学生が、各論文のハイライトを AI Context Markdown でエクスポートします。50本すべてを1つの Claude の会話に貼り付け、「この50本の論文全体で、構成概念妥当性研究の限界として最も多く引用される3つは何ですか?それぞれどの著者が挙げていますか?」と尋ねます。
Claude はページ引用付きの統合を返し、学生はそれをそのまま論文の文献レビュー欄に貼り付けます。同じ学生は同じハイライトを RAG JSON でエクスポートして Pinecone インデックスに取り込み、研究室の仲間からの「論文XはYについて何と言っていた?」に答える Slack ボットを構築します。
法的契約分析
200ページの合併契約書をレビューする弁護士が、補償条項をすべて赤、終了トリガーをすべて黄でハイライトします。AI Context Markdown でエクスポートし、ChatGPT に「上限が100万ドル未満の補償条項をすべて、ページ番号付きで挙げて」と依頼します。構造化フォーマットのおかげで ChatGPT はページを正確に引用でき、弁護士はそれを赤線修正のドラフトに使います。
継続案件では、同じハイライトを RAG JSON パイプラインに通し、事務所内の Qdrant インスタンスに取り込みます。パラリーガルは「第7.3節は存続期間についてどう述べていますか?」と尋ね、該当ハイライトとページ番号を検索できます。
技術文書のナレッジベース
レガシーシステムを移行するエンジニアリングチームが、30件のアーキテクチャPDFのハイライトを RAG JSON でエクスポートします。各ハイライトは Chroma インデックスのベクトルになります。新しいエンジニアが「認証フローはどこにドキュメント化されていますか?」と尋ねると、検索パイプラインが該当ハイライトをページ番号・ソースファイル名・ハイライト作成者のノート付きで返します。誰も答えがどのPDFにあるか覚えておく必要がありません。
同じチームは AI Context Markdown を使って週次サマリーを作成します。その週の新規ハイライトを Claude に貼り付け、1ページのブリーフを作成してチームの Slack に投稿します。
AI Context と RAG JSON のどちらを選ぶか
| 質問 | AI Context Markdown | RAG JSON |
|---|---|---|
| 1回限りのチャット分析? | ✅ | — |
| 本番運用のQ&Aシステム? | — | ✅ |
| コードもセットアップも不要? | ✅ | — |
| 文書横断検索? | — | ✅ |
| クエリ時のメタデータフィルタ? | 限定的 | ✅ |
| 任意のLLMで動く? | ✅ | ✅(検索レイヤー付き) |
| チャット向きでトークン効率が良い? | ✅ | — |
| 数千件のハイライトにスケール? | — | ✅ |
経験則として:探索には AI Context Markdown から始め、スケールが必要になったら RAG JSON に移行する。 ほとんどのユーザーはチャットベースのワークフローから入り、実際にどんな質問をしているかを発見し、質問が反復的になったらRAGパイプラインを構築します。
AIエクスポートにおいてローカル処理が重要な理由
LLMプロバイダーはデフォルトで会話を記録します。機密の研究、法的契約、専有文書を ChatGPT に貼り付けると、その内容が保持され、モデル訓練に使われる可能性があります(アカウントのプランや設定によります)。注釈自体は文書の中でも特に機密性が高い部分です。どの段落を重要と見なしたか、どれに不同意か、どれを要フォローアップとしてマークしたかがわかってしまいます。
ローカル処理のエクスポートワークフローはこの懸念を完全に消すわけではありません(ハイライトをLLMに貼り付ける必要は残る)ものの、次のことを保証します:
- 変換ステップはローカルで行われる。 注釈抽出の間、PDFやXFDFがサーバーにアップロードされることはありません。
- 貼り付ける内容を自分で制御できる。 AI Context Markdown を送信前に確認し、機密性の高い部分を黒塗りで伏せられます。
- RAG JSON パイプラインは自分のもの。 セルフホストのベクトルデータベース(Qdrant・Chroma・pgvector)に取り込めば、データはあなたのインフラから外に出ません。
変換そのものは、pdfannotations.com が完全にブラウザ内で実行します。ページが読み込まれた後にインターネットを切断しても、エクスポートは動き続けます。
よくある質問
AI Context Markdown と通常のMarkdownの違いは?
AI Context Markdown は特定の見出し階層(# Source → ## Page → ### Highlight / ### Context / ### My Note / ### Tags)を採用しており、LLMに引用用の明示的なアンカーを与えます。通常のMarkdownエクスポートはよりフラットで、ノートアプリでの人間の閲覧向けに最適化されており、LLMの取り込み向けではありません。
ベクトルデータベースなしで RAG JSON を使えますか?
はい。ただし検索の利点は失われます。RAG JSON を Python スクリプトに読み込み、メタデータでレコードをフィルタ(例:page == 12)し、一致するハイライトだけをLLMに渡せます。これは簡易版のRAGパイプラインですが、小さな注釈セットなら十分機能します。
RAG JSON にはどのembeddingモデルを使うべきですか?
英語のハイライトなら、OpenAI の text-embedding-3-small が良いデフォルトです。安価・高速で、ほとんどの検索タスクに十分な精度があります。多言語コンテンツには、Cohere の embed-multilingual-v3 やローカルの sentence-transformers モデルを検討してください。領域特有の語彙を含む法律や技術コンテンツには、Voyage AI の voyage-law-2 や voyage-code-2 が汎用モデルより優れることが多いです。
1回のLLM会話に貼り付けられるハイライトは何件まで?
モデルのコンテキストウィンドウ次第です。GPT-4o と Claude 3.5 Sonnet はどちらも128K〜200K tokens をサポートし、だいたい50〜100ページ分の密集したハイライトに相当します。それ以上は、複数会話に分割するか RAG JSON パイプラインに移行してください。
エクスポート時にコメント本文は保持されますか?
はい。AI Context Markdown と RAG JSON のどちらもコメント(付箋)本文を含みます。前者は ### My Note フィールド、後者は metadata.note フィールドです。
関連ガイド
もっと知りたいですか?関連ガイドをチェックしてください:
- PDF を Markdown に変換するベストプラクティス - あらゆるPDFソースからLLM向けMarkdownを生成するクリーンな変換パターン
- Adobe Acrobat から XFDF 注釈をエクスポートする方法 - AIエクスポートの入力としてAcrobatからXFDFを取り出す
- XFDF とは?PDF注釈XMLフォーマットの解説 - XFDFファイルフォーマットとそのXML構造を深掘り
- XFDFをObsidianに変換するワークフロー - AIエクスポートとObsidian vaultを組み合わせて知識パイプラインを構築
- PDF ハイライトを Obsidian へエクスポート:完全ワークフローガイド - あらゆるPDFソースに対応する完全なObsidianワークフロー