PDFが10本、どこに何が書いてあるか言えますか？
調査資料でもレポートでも提案書の根拠でもいいんですけど、PDFが10本あって、そこから共通点と相違点を洗い出して議論しないといけない場面を思い浮かべてください。
僕がまさにそれをやっていて、正直きつかったんですよね。全部人力で一から読むのってかなりの時間がかかりますし、そもそも必要な情報を探すのに、その必要なキーワードがそもそも分からないみたいなことがずっと起きるんですよ。「このデータ、どのPDFのどこに書いてあったっけ」を毎回探しにいく感じです。
結論から言うと、PDFのまま抱え込むのはやめて、Markdownに起こして持つようにしました。結論をざっくりと、これによってAIの力を受けやすくなったよ！って話です。ただし「精度よく変換できます」という話ではなくて、落ちるものは落ちると認めた上で、どう補うかという現実的な話もあります。今回はその起こし方と、落ちたぶんの埋め方を書いていきます。
PDFのままAIに渡すんじゃダメなんですか？
PDFのままでも読めるんですよ。読み込めますし、中身も見られます。
でも、じゃあこのデータとこのデータがこういうのに使えそうです、ってなった時に、その都度文字起こしとかしてられないわけですよね。10本を横断して照らし合わせるとなると、この手間が本数ぶんそのまま乗ってきます。
もう1つ、何度も読ませるほど重くなる話があります。PDFをAIに渡すと、たとえばClaudeだと公式のPDFサポートの仕組み上、各ページがテキストと画像の両方に変換されて渡されるんです。ページの文字を抜き出したテキストと、そのページをまるごと画像化したものが、セットでコンテキストに乗ります。Markdownはテキストだけなので、この画像ぶんがまるっと上乗せになります。同じ資料を何度も読ませるなら、ここでトークンをバカ食いするわけですね。
画像側の数字はClaudeが公式に出している上限値なので、実際はもう少し下振れします。Markdown側は文字数からの概算で、どちらも実測ではありません。
ただ、これは「トークンが安くなるからMarkdownにしろ」という話ではありません。起こすときに全ページ分の画像ぶんは一度払っていますし、1回か2回引いて終わる資料なら、PDFのまま渡した方が安く済みます。効いてくるのは同じ資料を何度も引き直す前提のときだけで、僕がMarkdownに起こしているのもそこです。そして何度も引くなら、引くたびに原典まで辿り着ける形になっていてほしいわけですよね。その形の話が、このあとの中心になります。
ここでちゃんと言っておきたいのは、Markdownに起こすと捨てるものがあるってことです。段組みやページ内の位置関係といったレイアウトは消えますし、図やグラフの見た目そのものも残りません。何ページ目かという単位も失われますし、原文の文字列自体もAIの変換を一度経由したものになります。ここを「精度でカバーします」とは言いません。捨てると決めた上で、埋められるところだけ埋める、というのが次の話です。
じゃあ、PDFをどうやってMarkdownに起こすのか
やっていることは大きく2つで、どう割って起こすかと、落ちたぶんをどう埋めるかです。
起こし方：章単位のPDFに割って、並列で起こす
でかいPDFをそのまま扱おうとすると、そもそも全部読み込めなくて該当のエラーが出ることがあります。実際、201ページある社内向けのガイド資料でこのエラーに当たりました。Claudeの公式ドキュメントを見るとページ数に上限があって、1リクエストあたり600ページ、コンテキストが1M未満のモデルだと100ページまでなんですよね。
理由はもう1つあって、実際必要なのは1章単位だったりするんですよね。全部のデータを一括で編集する必要はなくて、必要なところだけ抜き出せればよかったんです。
やっていることを順番に書くと、こうなります。
- 目次からチャプターごとのページ範囲を出す（ここは人が決めます）
- 自作したCLIで、その範囲を章単位のPDFとして切り出して保存する
- 章ごとのPDFを並列のAgentsに渡して文字起こしする
- 画像も含めてMarkdownで精査しながら変換する
つまり、でかいPDFをAgentsの入力にできるぐらいの小さなPDFに変換する切り出しの作業を挟んでいるだけなんですよね。目次からページ範囲を対応づけるのは人の仕事で、切り出し自体はツールに任せています。
変換に何を使うかは正直お好みでいいと思っていて、この記事では変換ツールの比較には踏み込みません。ここで話したいのは、起こしたあとの形の話です。とはいえ切り出しの道具が何もないと始まらないので、僕が使っているCLIが何を満たしているかだけ、記事の最後に付録として置いておきます。
埋め方：該当ページと原文引用で、原典まで辿れるようにする
ここは誤解されやすいので先に言っておくと、落ちたものをMarkdown側で復元しようとはしていません。やっているのは、原典のその箇所まで人が辿り着けるようにすることだけです。
| 落ちるもの | 原典まで辿るための手がかり |
|---|---|
| レイアウト（段組み・位置関係） | 置きません。見たければ原典を開きます |
| 図表の見た目 | 図表一覧の索引（図表番号・タイトル・ページ・主な内容） |
| 何ページ目かという単位 | 該当ページの記載 |
| 原文の文字列そのもの | 原文のままの引用。原文性の保証ではなく、原典を検索して同定するためのキーです |
レイアウトだけは索引すら置いていません。ここまで埋めにいくと「結局全部取り戻せます」という話になってしまって、捨てる決断をしたこと自体が崩れるので。
ページ番号は章単位に割ったぶんズレるんじゃないか、と思われるかもしれません。切り出した章PDFを中間成果物として残してあるので、章PDFの何ページ目かと、切り出しの開始ページを足せば原典のページに落ちます。章PDFで区切るか原典の通しに揃えるかは紐づけ方の好みで、辿れさえすればどちらでも構いません。
なぜ原文のままの引用とページ番号にこだわっているかというと、情報を使うにあたってAIをかませて変換しているので、その情報がちゃんと変換されているか、確認作業が絶対必要なんですよね。実は原文の意味をちゃんと読んだら、逆のことを言ってるみたいなことがあったりするので、人間だろうがAIだろうが、その数字をまるっと信用するわけにはいかないんです。だから、採用する数字に関しては、元のPDFをきちんと読んで確認をするっていう作業が絶対的に必要になります。
実際にどんな形で持っているかというと、こんな感じです。調査資料を起こしたものから抜粋します。
## 1. 調査概要（母集団） ── ✅ Web確認値と完全一致
**該当ページ**: p.1（SUMMARY 脚注）、p.8（調査先企業の属性）
原文（p.1 脚注）:
> ※ 調査期間は2026年3月17日～3月31日。調査対象は全国2万3,349社で、
> 有効回答企業数は1万312社（回答率44.2％）
| 項目 | PDF記載値 | Web確認値 | 判定 |
|---|---|---|---|
| 調査対象 | 23,349社 | 23,349社 | ✅一致 |
| 有効回答 | 10,312社 | 10,312社 | ✅一致 |
該当ページと原文の引用がセットで載っているので、この数字を使うときは引用文を検索キーにして原典のp.1を開けば確認できます。ファイルの冒頭には「『PDFでは確認できず』と明記した項目以外は、すべて原典に実在する記述」という書き分けの宣言も置いています。
ちなみに一度、トークンが余っていたので、起こしたMD24本をPDF原典と突き合わせる実験をしたことがあります。採用していた数字はPDFと合っていて、軽微な齟齬が2件（本文と図表のページ併記のずれ、係り先が少し曖昧な箇所）出ましたが、数字そのものの誤りはありませんでした。24本のうち2本は同じ突合をもう一度回してみて、結果は変わりませんでした。設計してやったわけではなく、手が空いたときの実験です。
そして、再現率については、そもそもこっちでどうしようもないことなんですよね。AIのモデルで変換をかましているだけなので。だいたい9割、99%くらいは再現できている感覚があって（これは測った数字ではなく体感です）、残りの1%の厳密性を背負っているわけではないんです。再現率を追い求めるのはAIのモデル企業に頑張っていただいて、こちとら何もしません。
Markdownに起こして、何が変わったか
前は、PDFも資料もいっぱい読んで、「このデータとこのデータを」を頭の中で突き合わせていました。今は、この情報ソースからこれ、この情報ソースからこれ、じゃあ自分は確認だけします、というところまで来ています。
大きいのは、同じソースをセミナー資料にもブログにも使い回せるようになったことです。たとえばセミナーで「日本企業の生成AI活用率」を出したいときは、こういう順番になります。
- 起こしたMD群を横断して探す。該当の調査資料のファイルに、活用率の記述が該当ページと原文引用つきで載っている
- 採用する数字なので、原文の引用文を検索キーにして原典のPDFを開き、その場で一致を確認する
- セミナー資料側には、数字と一緒に「この数字がどのMDのどこから来たか」を残す
3が地味に効いていて、セミナー資料から辿ると、加工した数字、起こしたMD、原典のPDF、と鎖がつながったままになります。使った先にも原典への道が残るんですよね。
ただし、採用する数字は結局PDFを開いて確認する作業が残ります。そこは省けません。それと、一次ソースが章ごとに配布されているとも限らなくて、総務省白書みたいなのはむしろ少数派です。
原典に戻れること自体は、Anthropic の Citations API や NotebookLM みたいな製品側の機能にもあります。とくにNotebookLMは単体だと本当に優秀です。ただ、あそこに溜めた資産は外へ持ち出すのが地味に大変で、上でやったみたいに自分の書式で常設して別の成果物へ引き回す形にはならないんですよね。製品側の引用が出力を信頼させるために付いているのに対して、こっちの書式は人間が効率よく疑うために付いている。目的が逆なんだと思います。
検索の探し方（ベクトル検索やGraphRAGみたいな話）は別問題なので扱いません。見取り図はベクトル検索以外のRAG手法7選に、なぜMarkdownなのかという一般論はHTMLでブログ記事を保存してる奴、全員Markdownにしろに書いています。
もし手元にPDFのデータソースが何本もあるなら、まずは1本、目次からページ範囲を拾って章単位に割ってみるところから始めてみてください。
付録：同じことをやるなら、各工程で何を満たせばいいか
使う道具は何でもいいと思っているので、コードは載せません。工程ごとに満たすべきことだけ書いておきます。
先に道具の話を済ませておきます。切り出しは、Anthropicが公開しているpdf skillでだいたい足ります。ページ範囲の抽出（qpdf input.pdf --pages . 1-5 -- pages1-5.pdf）も、総ページ数の取得も、埋め込み画像の抽出（pdfimages）も中に書いてあるので、僕みたいに自分でCLIを書く必要はありません。
しかも間が悪い話で、僕がこのCLIを書いたのは2026年3月です。公式のskillは2025年10月から公開されていて、qpdfでページ範囲を切り出す例も最初から載っていました。5ヶ月遅れで同じものを作っていたわけですね。ちゃんと作り始める前に公式のskillを確認しましょう、というのが今回いちばん痛い学びです。
とはいえ、道具が揃っても埋まらないものが1つあります。切り出しの開始ページを控えることです。これは機能ではなく運用の話なので、そこだけは自分で決めることになります。
1. 章の境界を決める
目次に書いてあるページ番号と、PDFビューアが表示する物理ページ番号がズレていないかを先に確かめます。表紙や前付けがあると一致しません。ここがズレたまま切ると、章の境界が丸ごとずれます。
出すものは、章ごとの開始ページと終了ページの一覧です。
2. 章単位のPDFに切り出す
ページ範囲を指定して抽出できれば、手段は問いません。僕は自分でCLIを書きました（pypdfでページを抜いて、Typerでコマンドの口を付けただけのものです）。自分で用意する場合、要るのは次の3つです。
- 元PDFの総ページ数が分かること。章の境界を決めるのに要ります
- ページ範囲を指定して1本のPDFに切り出せること。「1-3,5,7-10」のように飛び番と範囲を混ぜて書けると、章が連続していない資料で楽になります
- 切り出しの開始ページを控えられること。ファイル名に入れるでも記録に残すでもいいので、あとで原典のページに戻せる形にしておきます
あるとうれしいのが、埋め込み画像を抜き出せることです。図表が多い資料だと、起こしたMDと並べて「この図はこれ」を確認するのに使えます。
そして1つだけ大事なのは、切り出したPDFを捨てずに残しておくことです。あとで「章PDFの何ページ目か」を原典のページに落とすときに要ります。
3. まず1章だけ起こして、書式が決まったら残りを並列で流す
いきなり全章を投げないで、まず1章だけ起こしてみるのがおすすめです。1本目は書式の実験台で、出てきたMDを見ながら「該当ページはどこに置くか」「引用はどの粒度で残すか」を決めます。
指定する書式は、該当ページ、原文のままの引用、図表一覧の索引、そして「原典では確認できなかった」の書き分け。書式を後から揃えようとすると全章やり直しになるので、ここは1章目で決め切ってしまうのがいいです。
決まったら、あとは1エージェントに1章ずつ渡して並列で流すだけです。章が小さくなっているので、入力に載らない問題はここで消えています。まとめて走らせて出てきたものを眺めるだけになるので、章数が多い資料ほど気持ちよく効いてきます。
4. 原典に戻れることを確かめる
採用する数字について、原文の引用文を検索キーに原典を開いて、一致を見ます。
全部を検証しようとしないのがコツです。使う数字だけでいいので。
