【AI駆動開発】100ページ超のPDFを“間違えずに”Markdown化する方法【v3・検証強化版】
何百ページものPDFをMarkdownに変換して、AIに読ませる。前に書いたその方法は、今もちゃんと動いている。少なくとも、そう思っていた。
下記が当時の記事です。
# 【AI駆動開発】100ページ超のPDFをMarkdownに変換してAIに読ませる方法
ところが、何百ページも流し続けたある日に気づいた。変換の“検証”を、書いた本人にやらせていたのだ。AIが書き、同じAIが見直し、「合っています」と言う。人間の校正ならまず通さない構図を、しばらく疑いもしなかった。今回の v3 は、この一点をつぶすために作り直した版です。人間の仕事は、相変わらずコーヒーを飲みながら進捗を眺めることくらい。☕
その「OKです」は、どこまで信じられるのか
まず、前のやり方をおさらいしておく。PDFを1ページ1枚の画像にし、AIに画像を精読させてMarkdownに起こし、5〜10ページずつ処理して積み上げる。骨格としては今も正しいし、v3の土台でもある。崩れていたのは、最後の検証だった。
例えば、商品名の『烏龍茶』を『高麗茶』と書いてしまったとする。同じAIに見直させると、どうなるか。日本語として自然に読めてしまい、すっと通る。書いた本人は、自分の書いたものを疑う理由を持っていないからだ。以前の案件で実際に踏んだ事故を並べると、性質がはっきりする。
- 金額の近似誤読：
50と68、0と8。形が似ているだけで数字は別物になる。 - ローマ数字の取り違え：
売変Ⅱ-2が売変Ⅲ-2に化ける。Ⅱ↔Ⅲは本当に多い。 - 記号の混同：権限表の
○ × ★と空欄。空欄と×を取り違えると、可否が反転する。 - 意味の反転：「標準売価より高い売価は設定できません」が「低い」に。
最後のがいちばん怖い。金額やコードは、間違っても「なんか変だ」と引っかかる余地がある。ところが反転した文は、文章として完全に自然に読める。引っかかりようがない。四つに共通するのは、体裁が整っているほど気づけないという一点だ。だとすれば、「気をつけて見直す」では原理的に止まらない。止められるのは、書き手とは別の根拠との照合と、数えれば分かることを数える機械だけである。
検証を、書いた本人の手から取り上げる
v3でいちばん変えたのは、そこだった。検証の根拠を、書いた本人の申告から、正本との照合へ移す。正本とは、AIとは独立に正しさを担保できる情報源のこと。ここでは、PDFが内部に持つ文字データや、別系統のOCRの読みがそれにあたる。そして照合するのは人ではなくスクリプト、いわば機械の監査役だ。言葉にすると一行だが、効き方はまるで違う。
具体的には三つの仕掛けを足した。それぞれ「何を」「どうやって」担保するかを、曖昧にしないことにした。
-
① 機械検算： 表の列数がヘッダと合っているか。合計行と内訳の和が一致するか。AIが転記時に付ける未確定マーカー（
[判読不能]/⚠）が残っていないか。どれも“数えれば分かる”類のことで、人もAIも数え間違えるが、スクリプトは間違えない。だから目視をやめてスクリプトに渡す。 - ② 独立の正本照合： born-digitalなPDF（中に文字データを持つデジタル生成PDF）は、その埋め込みテキストを正本として抜き出し、AIの出力と機械で突き合わせる。Visionを数値や固有名詞の正本にしない、というのが肝だ。スキャンで正本が無いときは、出力を見ていない別セッションに同じ表をもう一度書き起こさせ、二つを差分照合する。二人が同じ間違いを同じ場所で犯す確率は、低い。
- ③ 予算トリガー＆引き継ぎ台帳： セッションで生成したMarkdownの累計が1万字に達するか、AIがセッションの重さから「そろそろ」と判断したら、区切りを提案する。状態は task.md に残し、次のセッションが精度もカバレッジも落とさず続きに入れるようにした。区切りの実際は、後半でそのまま見せる。
この三つがどう噛み合うかは、全体像の一枚で見たほうが早い。
ひとつだけ、先に言っておきたい勘所がある。PDFを画像化“だけ”で終わらせないことだ。born-digitalなPDFは中に正確な文字列を持っているのに、画像に変換した瞬間その情報を捨ててしまう。もったいない、という話では済まない。捨てた文字こそが、あとで誤読を捕まえる正本になる。だからv3は画像とテキストレイヤの両方を用意し、役割を分ける。画像はレイアウトと表の構造を理解させるため、テキストレイヤは数値と固有名詞の正しさを照合するため。片方の弱点を、もう片方が埋める。
Step 1：PDFを画像＋テキストレイヤに変換する
前のバージョンで、読者がいちばん詰まったのは poppler のインストールだった(と思う)。環境構築で心が折れる、というのは変換以前の話で、いちばん避けたい。
そこでv3のスクリプトは自己完結型にした。変換エンジン（PyMuPDF）が無ければ自動でpip導入し、popplerのシステムインストールは要らない。うまい話に聞こえるかもしれないが、実際に poppler 未導入の環境で試すと、pdf2image はきっちり落ちる。落ちたあと、スクリプトが自分でPyMuPDFに切り替えて最後まで走り切る。下は、そのときの本物のログだ。
画像化と同じ手で、テキストレイヤも抜いておく。ここで各ページが自動的に二つに仕分けられる。『TEXT（正本に使える）』か、『IMAGE-ONLY（スキャン等で文字が無い＝独立クロスチェックが必須）』か。そのページをどう検証すべきかが、精読を始める前に決まる。
コマンドはこの二本だけだ（p.1-5をバッチ処理する例）。
# ① 画像化（400dpi）
python3 scripts/pdf_to_page_images.py 107.pdf 107_pages -r 400 -f 1 -l 5 --force
# ② テキストレイヤ抽出（正本の確保）
python3 scripts/extract_pdf_text_layer.py 107.pdf 107_textlayer -f 1 -l 5
解像度で手を抜くと、あとの全部が崩れる。150dpiは表が潰れて誤読の温床、300dpiが標準、小さな文字や色分けマトリクスを含むなら400dpi、600dpiは重いだけで普通は要らない。粗い画像は、そのまま誤読の量になる。迷ったら400、と決めておくと悩まずに済む。
ページごとに、正本の取り方が変わる
さっきの TEXT / IMAGE-ONLY は、ただの分類ではない。そのページの"正本"をどこから取るかの分岐だ。そして分かれ目は「スキャンか否か」ではなく、テキストレイヤが在るか無いか――この一点。ページ単位で読み方が切り替わる。
- テキストレイヤ有り（born-digital PDF） … 文字はPDFの中に確定して在る。テキストレイヤがそのまま正本。OCRの出番はない。
- テキストレイヤ無し（IMAGE-ONLY） … スキャンに限らない。写真・スクリーンショット・書き出し画像・画像だけのPDF。元が"画像"なら、みな文字データを持たない。ここで初めてOCRが要る。ただし主役は交代しない。AIが構造と意味で転記し、その脇で RapidOCR（ローカルで動き、トークンもAPI課金もかからないOCR）が文字だけを字面どおりに読んで、独立の正本になる。AIは意味で"それっぽく"補うのが得意で、まさにそこで数字を取り違える。RapidOCRは意味を解さないぶん、ピクセルどおりに読む。得意と苦手が逆、つまり誤り方が独立だから、片方の幻覚をもう片方が刺せる。born-digitalでテキストレイヤが担っていた正本役を、画像ではOCRが肩代わりする、という構図だ。（鮮明なスクショならAI単体でもよく読めるが、数値・コードの裏取りにOCRを添えて損はない。タダである。）
- 手書き・かすれ … AIもOCRも、同じ曖昧なストロークを別々に推測するだけ。独立した正本が存在しない。だから確定させず、⚠️を付けて人に回す。
性質を一つ書いておきたい。全ページがTEXTの資料では、OCRは一度も起動しない。 今回の555ページもそうだった。まるごとborn-digitalだったので、分岐はすべてテキストレイヤ側に倒れ、OCRの世話にはならなかった。裏を返せば、画像のページが混ざったその時だけ、もう一方の経路が静かに立ち上がる。born-digital の速さと確実さは、何ひとつ犠牲にしていない。
Step 2：AIに精読させてMarkdownに変換
ここは前と同じく、画像を1枚ずつ精読させてMarkdownに起こす。同じ、と言いつつ、三つ決め事を足した。同じ事故を二度踏まないためだ。
一つめは、「表」と「スクリーンショット」を『図』でひとくくりにしないこと。種別ごとに扱いを変える。
| 種別 | 例 | 扱い |
|---|---|---|
| A 概念図・フロー図 | 業務フロー、矢印図、ポンチ絵 | 内容を説明文で再現してよい。ただし図中のラベル文字は省略せず転記 |
| B データ表・権限表 | ○×★の権限表、区分値マトリクス、明細 | 逐語転記。 列数・行数・全セルを画像どおりに。要約・省略は禁止 |
| C 帳票・画面内の値 | レシート、金額、登録番号、コード | 逐語転記。 数字・記号を1文字も変えない |
B と C を「だいたいこんな感じ」と説明文に丸めた瞬間、AIは存在しない列名や数値を創作しはじめる。実際、列名が『売場/バーコード/カテゴリー名』、値が『64.17』『¥10,234』と、丸ごともっともらしい別物になった事故がある。面倒でも一字ずつ写す、しかない。
二つめは、高リスクなトークン——ローマ数字、コード、金額、記号、反転語——を、転記した“その場で”機械と正本に当てること。あとでまとめて、ではない。危ないものほど、書いた直後に潰す。
三つめは、分からないものを分かったふりで埋めないこと。転記の途中で確信が持てないセルや文字が出たら、その場で ⚠️（機械が数える対象としては ⚠ または [判読不能]）を付けて、先へ進む。想像で埋めた誤りは検証をすり抜けるが、印なら数えられる。印が残っているかぎり、次の検証が「まだ完了ではない」と言い続ける。だから付けっぱなしのまま完成にはできない。⚠️がどう付いて、どう外れていくかは、後半の実物で見せる。
Step 3：検証は3段＋締めの2手
バッチごとに3段の検証を通し、資料全体に締めの2手をかける。3段の順番には意味がある。いちばん当てにならない自己再読を最初に持ってくると、そこで安心してしまい、機械照合を省く。本末転倒だ。だから信頼できる順に並べ、自己再読は最後の網に回した。
-
3-A 機械検算： 生成したMarkdownをスクリプトにかけ、列数整合・合計の算術・
[判読不能]/⚠の残数を検出する。残数が0でないバッチは、まだ完了ではない。 - 3-B 独立照合： 独立した正本と機械照合する。born-digitalはテキストレイヤ、テキストレイヤの無い画像（スキャン・写真・スクショ・画像PDF）は RapidOCR が正本。AIの出力にあって正本に無い数値・コードは幻覚の候補。ただしOCRは取りこぼしも誤読もするので、不一致は「AIが誤り」ではなく「そこをクロップ再読して決着せよ」の合図（照合できるのは文字だけ。表の構造ミスは3-A・3-Cの担当、手書きは正本が無いので人へ）。
- 3-C 自己再読： ここで初めて、人間的な読みを使う。反転語のような“機械では拾えない意味崩れ”だけを、画像と見比べる。
ここまでの3段は、バッチが終わるたびに毎回かける。残る2手は、全バッチが終わったあとの、資料全体の締めだ。
- 横断一致： 同じ表が複数ページに再掲される資料は、ページ間で突き合わせ、名称・数値・行数の食い違いを探す。
- ⚠️/[判読不能] の潰し込み： 未確定に付けた印は、付けっぱなしにしない。最後に正本（別ページの章扉、目次の再掲、相互参照先など）へ当てて、ひとつ残らず消す。正本が同じ資料の中で安く取れるなら、後回しにもしない。
3-Aは一本のコマンドで済む。構造・算術・マーカーに加えて、テキストレイヤ照合とセッション予算まで一度に吐く。
python3 scripts/check_md_output.py 107.md --textlayer 107_textlayer --budget --task task.md
実際にやってみた：経産省の555ページPDF
理屈はここまでだ。実物で試す。題材は『平成21年度産業技術調査事業（技術に関する施策調査）最終報告書』（アーサー・D・リトル作成、全555ページ）。まず先頭5ページ——表紙、目次、背景と目的、MFT（市場・機能・技術の関係を一枚に整理する、この資料の分析フレームワーク）の概念図、その特徴表——を1バッチだけ回した。
目次の1ページで、さっそくVisionは分野名をいくつか読み間違えた。どれも日本語として自然な誤りで、自己再読だけならまず素通りしていた種類だ。捕まえたのは、テキストレイヤとの照合だった。
たとえば7番目。画像を見たAIは『製品分野』と読んだ。もっともらしい。だが正本は違う。ここで抜き出したテキストレイヤ（page_002.txt）を、整形も省略もせずに全文そのまま貼る。抜き出したものを一部だけ見せれば、都合の悪い所を落としたと疑われる。だから、抽出順が乱れているのが丸見えでも、全部載せる。この乱れ自体が、あとで効いてくる。
1
Contents
2
調査結果
1
調査の背景及び進め方
1
自動車分野
21
省エネルギー対策分野
2
情報処理分野
22
石油・天然ガス分野
3
あとは長いので折りたたみ
1
Contents
2
調査結果
1
調査の背景及び進め方
1
自動車分野
21
省エネルギー対策分野
2
情報処理分野
22
石油・天然ガス分野
3
情報政策分野
23
石油精製備蓄分野
4
情報ｾｷｭﾘﾃｨ分野
24
石炭分野
5
情報通信機器分野
25
鉱物資源分野
6
産業施設分野
26
電力基盤分野
7
製鉄分野
27
原子力政策分野
8
非鉄金属分野
28
原子力立地・核燃料サイクル分野
9
ナノテクノロジー・材料分野
29
放射性廃棄物等対策分野
10
化学物質管理分野１
11
化学分野
31
技術振興分野
12
住宅産業窯業建材分野
13
ファインセラミックス分野
33
環境指導等分野
14
素形材分野
34
化学物質管理分野２
15
繊維分野
35
オゾン分野
16
ガス安全分野
36
アスベスト対策分野
17
産業機械分野
37
バイオ分野
18
地域技術分野
医療・福祉機器分野
19
研究開発推進分野
航空機武器宇宙分野
20
新エネルギー対策分野
30
32
322
332
341
355
372
383
400
413
425
438
450
467
486
497
504
523
537
23
37
55
64
81
131
140
150
162
171
177
207
218
234
243
252
257
283
291
305
2
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
･･････････････
正本では『7 → 製鉄分野』と並んでいる。『製品』ではなく『製鉄』。同じ調子で、『家業』ではなく『窯業』、『課題』ではなく『備蓄』、『産業基盤』ではなく『電力基盤』、ページも『365』ではなく『372』。どれも一字か一桁の違いで、意味はまるごと変わる。これが人手を介さず挙がってくるのが、v3で得たいちばんの安心だ。
なぜ効くのか。Visionはレイアウトと表構造の把握に強い一方、細かい漢字や数字は取り違える。テキストレイヤは文字列こそ正確だが、レイアウトを持たない。だから役割を分けた。構造は画像に、文字の正しさはテキストレイヤに聞く。互いの穴を、互いにふさぐ。
もっとも、テキストレイヤも万能ではない。さっきの全文を見返すと、番号「30」「32」が名称と離れて末尾に落ちている。抽出順が乱れているのだ。おかげで右列の #30〜35 は、分野名の綴りとページ番号は確度が高いのに、どの番号がどの分野かを、目次のテキストだけでは決めきれなかった。
このとき、手元のMarkdownはこうなっていた。Step 3 の最後に貼ったログの [3] 未確定マーカー: ⚠=7（右列#30-35を要確認フラグ） が数えていたのは、まさにこの状態だ（表そのものは当時の中間出力を残していないため、同じ状態を再現した抜粋である）。
| # | 分野 | ページ |
|---|---|---|
| 30 | ⚠️ 技術振興分野（この番号との対応が目次からは確定できず） | 438 |
| 31 | ⚠️ 環境指導等分野（同上） | 450 |
| 32 | ⚠️ 化学物質管理分野２（同上） | 467 |
| … | ⚠️ #35まで同様 | … |
Step 2 の三つめの決め事どおり、埋めずに印を付けて先へ進む。同時に、task.md の未決レジスタへこの保留を積んでおく。
## 4. 未決レジスタ
- [ ] p.2 目次・右列 #30〜35：番号と分野名の対応が未確定（テキストレイヤの抽出順乱れ）
→ 確認先の候補：各章の扉ページ（p.438、p.450、p.467 …）
だが、⚠️ を付けて終わり、ではない。⚠️ は答えを放棄した印ではなく、判断をいったん保留しただけの仮置きだ。最後に正本へ当てて、ひとつ残らず潰す。しかも正本が同じPDFの中に安く見つかるなら、後回しにもしない。目次のテキストがだめでも、各分野の本体ページがある。そこで、該当章の実ページ（p.438、p.467…）を開いた。
すると、章の扉が目次を丸ごと再掲していて、その章の行だけを灰色地で反転させていた。p.438 では『30 技術振興分野』が、p.467 では『32 化学物質管理分野２』が、はっきり浮いている。番号と分野名の対応は、これで確定した。
仮置きの行は、こう変わる。
- | 30 | ⚠️ 技術振興分野（この番号との対応が目次からは確定できず） | 438 |
+ | 30 | 技術振興分野 | 438 |
未決レジスタの当該行にも確認済みの印が付いて、ようやく落ちる。分からない所を分かったふりで埋めないことと、⚠️ を付けっぱなしにしないことは、同じ規律の裏表である。
変換後は、目次がそのまま検索・参照できるMarkdownテーブルになる（誤読は修正済み）。ここでも抜粋はしない。全37分野を全文で載せる。
### 調査結果 分野一覧（37分野）
| # | 分野 | ページ | # | 分野 | ページ |
|---|---|---|---|---|---|
| 1 | 自動車分野 | 23 | 21 | 省エネルギー対策分野 | 322 |
| 2 | 情報処理分野 | 37 | 22 | 石油・天然ガス分野 | 332 |
| 3 | 情報政策分野 | 55 | 23 | 石油精製備蓄分野 | 341 |
| 4 | 情報ｾｷｭﾘﾃｨ分野 | 64 | 24 | 石炭分野 | 355 |
| 5 | 情報通信機器分野 | 81 | 25 | 鉱物資源分野 | 372 |
| 6 | 産業施設分野 | 131 | 26 | 電力基盤分野 | 383 |
| 7 | 製鉄分野 | 140 | 27 | 原子力政策分野 | 400 |
| 8 | 非鉄金属分野 | 150 | 28 | 原子力立地・核燃料サイクル分野 | 413 |
| 9 | ナノテクノロジー・材料分野 | 162 | 29 | 放射性廃棄物等対策分野 | 425 |
| 10 | 化学物質管理分野１ | 171 | 30 | 技術振興分野 | 438 |
| 11 | 化学分野 | 177 | 31 | 環境指導等分野 | 450 |
| 12 | 住宅産業窯業建材分野 | 207 | 32 | 化学物質管理分野２ | 467 |
| 13 | ファインセラミックス分野 | 218 | 33 | オゾン分野 | 486 |
| 14 | 素形材分野 | 234 | 34 | アスベスト対策分野 | 497 |
| 15 | 繊維分野 | 243 | 35 | バイオ分野 | 504 |
| 16 | ガス安全分野 | 252 | 36 | 医療・福祉機器分野 | 523 |
| 17 | 産業機械分野 | 257 | 37 | 航空機武器宇宙分野 | 537 |
| 18 | 地域技術分野 | 283 | | | |
| 19 | 研究開発推進分野 | 291 | | | |
| 20 | 新エネルギー対策分野 | 305 | | | |
表も同じだ。MFTの特徴と効用の2列表を、要約せず逐語で写す。機械検算で「3表とも列数一致」も確認済み。省略記号は使わず、全セルを載せる。
| MFTの特徴 | 調査における効用 |
|---|---|
| 各レイヤにおける選択肢の幅が見える | 各事業が想定している選択肢と、選ばなかった選択肢が明確になるため、各事業の目論見の正しさ（十分条件性）を評価する土台となる（一般的な事業計画では選んだ結果しか表現されないため、必要条件しか確認できない） |
| 技術の潜在的な応用可能空間が見える | 各事業が潜在的に解決できる課題や、それによって広がる応用先を漏れなく発見できる。従い、施策/事業の関係性の見逃しが防止できる（複数の市場に貢献できる事業が明確になる） |
| 各市場（施策）における重要課題が見える | 施策として掲げられている市場における主要課題が見える。従い、施策/事業の関係性の見逃しの防止や、未着手の課題の発見ができる |
| 市場/課題/技術の関係が一気通貫して見える | 各事業が当該施策において、果たしている役割（どの課題を解決するか）が見える。また、施策の粒度や事業の括り方を検討する参考材料となる |
| 各市場における技術打ち手の体系が見える | 各事業間の関係性（相乗・独立・競合など）が見える。また、民間や他省庁、諸外国プロジェクトの技術開発事例も同じ土台に当てはめられるため、今後の施策・事業企画の際に、民間との役割分担や国際競争力の観点から検討できる |
今度は、機械のほうが声を上げた
さっきの #30〜35 は、こちらの不安（⚠️）を正本で消した話だった。潰し方はもう一つある。機械が「これは怪しい」と指してくる場合だ。別のページ——p.80、情報セキュリティ基本計画の目標をまとめた表——を転記して、3-A の機械検算にかけた。構造も算術も問題なし。ただ、テキストレイヤ照合が一箇所だけ引っかかった。
[4] テキストレイヤ照合: 要確認 1 件
幻覚候補（テキストレイヤに無い数値/コード）: 1 件
- 2009
出所の脚注に書いた『2009』が、正本に見当たらない、という。同じページで使った『2012』は素通りしているのに、だ。ここで手が滑りやすい。機械が疑ったのだから直そう、と別の数字に書き換えたくなる。だが、フラグは判決ではない。まず、原本を見る。脚注をクロップして拡大した。
『第2次情報セキュリティ基本計画（2009年2月3日情報セキュリティ政策会議）』。2009 で正しい。史実とも合う。では、なぜ照合が弾いたのか。正本を覗くと、答えがあった。テキストレイヤは、この年号を全角の『２００９』で持っていた。こちらは半角の『2009』で書いた。同じ数だが、文字としては別物だ。機械は素直に「その並びは無い」と言っただけだった。先ほどの『2012』が素通りしたのは、正本の中に半角の『2012』と全角の『２０１２』が両方あったからで、たまたま半角側に当たっていた。
結論はこうだ。中身は正しい。フラグの正体は、全角と半角の差であって、幻覚ではない。だから内容はそのまま確定し、出力はAI可読性を優先して半角に統一する（原本が全角だった事実は記録に残す）。フラグを潰すとは、機械の指摘を鵜呑みにも黙殺もせず、原本と正本に当てて白黒つけることだ。ときには「機械が過敏だった」が結論になる。それでも、当たってみるまでは分からない。
555ページを、一気には終えられない
さて、5ページはこれで片付いた。残りは550ページある。一つのセッションで最後まで、とはいかない。コンテキストが埋まるほど、細部の精度は静かに落ちていく。かといって1バッチ（今回は5ページ）ごとに区切り直すのは、せっかくの広い文脈枠を捨てているようなものだ。
落としどころとして、v3は次の“早い方”で区切りを提案する。勝手には止めない。
- ① 機械トリガー： 累計出力が1万字に達したら。スクリプトが数える、動かない下限だ。
- ② 判断トリガー： 1万字に届かなくても、往復数や読み込んだ画像・大ファイルの量、文脈圧縮が走ったかどうかから、AIが「そろそろ危ない」と感じたら先回りで提案する。こちらは推定でよい。外しても、①が下限を守ってくれる。
区切るときに、記憶を頼りにしない。task.md という引き継ぎ台帳へ、状態を全部書き出す。次のセッションはこれを読むだけで、迷わず・抜けなく続きに入れる。台帳はこの5ブロックだ。
## 0. 再開手順（新セッションが最初に読む順序）
## 1. 計画（作業ルート/検証強度/IMAGE-ONLYページ 等）
## 2. バッチ台帳（✅完了・👉次バッチ・📊予算 累計字数）
## 3. 横断チェック対象（複数ページ再掲の一致確認）
## 4. 未決レジスタ（[判読不能]/⚠ を解決まで消さない）
## 5. 完了の定義（全バッチ✅ かつ 未決0 かつ 横断照合済）
いちばん効くのは『4. 未決レジスタ』だと思う。要確認のセルをここに載せておけば、セッションをまたいでも「未解決のまま完了扱い」という、いちばん静かな事故を防げる。さっき実物を見せたとおり、#30〜35 の ⚠️ もここに居座っていた。実ページを読んで正本を確認し、対応を確定してから、ようやく落とす。未決は、埋めるか正本で潰すかの二択で、宙ぶらりんのままにはしない。
地味だけど効く：出力先を必ず聞く
最後に、派手さはないが実務で効く一手を。以前は、生成した画像やmdが、ツールと同じ場所に散らかりがちだった。片付けは、あとになるほど面倒になる。
v3は着手前に、必ず出力先を尋ねる。「どこにフォルダを作りますか？」と聞き、推奨2案＋自由入力を出す。画像もテキストレイヤもmdも台帳も、まとめて作業ルート側へ。ツールはコード専用のまま保つ。今回も、変換一式は 107_変換/ に集約した。
まとめ
前のやり方の骨格——PDF→画像→AI精読→Markdown——は、v3でもそのまま生きている。変えたのは、その上に「AIの嘘をどう潰すか」を正面から積んだことだ。
| 観点 | 内容 |
|---|---|
| 課題 | 大量PDF ＋ AIの“もっともらしい嘘”（体裁が整っているほど気づけない） |
| 骨格 | PDF → 画像 ＋ テキストレイヤ（スキャンはOCRを正本に）→ AI精読 → 検証3段＋締め2手 → Markdown |
| v3の核心 | 自己申告レビュー → 正本との機械照合（独立監査） |
| 効いた証拠 | Vision誤読5件をテキストレイヤ照合が捕捉／poppler無しでも自動フォールバック |
| 運用 | 1万字＋重さ判断で区切り提案、task.md台帳で安全に再開、出力先は必ず確認 |
冒頭の「その『OKです』は、どこまで信じられるのか」に戻る。答えは、書いた本人の「OK」は当てにしない、だ。別の根拠と機械に言わせる。“間違えたら困る”数値や固有名詞が多い資料ほど、この独立監査は効く。引き継ぎや新規参画で「資料がPDFばかりで辛い」という人は、一度試してみてほしい。あとは、コーヒーの淹れ方くらいしか残っていない。
利用するSkillやスクリプトはこちらからインストール可能です！
最後まで読んでいただきありがとうございました。
https://github.com/enomoso-pm/convert-image-to-md-v3