スライド全数検収

「ざっと見て大丈夫そう」で出した資料が、全数検査したら 62ページ全部に欠陥があった（399件・うち納品不可級79件）。この失敗から作った検収手順。

人間の目視は速いが、(a) 縮小表示では小さい崩れが見えない、(b) 同じ資料を2回見ると2回目は「見たつもり」になる、(c) 10ページ離れた同型ページ同士のズレは記憶で比較できない、という3つの穴がある。この手順はその3つを機械的に埋める。

検収の設計

全ページを、拡大して、並列に見る

ページを4枚ずつの班に分け、班ごとに独立したサブエージェントを走らせる。各班は必ず1ページを6タイル（3×2）に分割して全タイルを開く。ページ全体を1枚で見るだけでは、文字の二重像・1文字だけの潰れ・罫線の虫食いは検出できない。実際、全体表示で「問題なし」としたページを6タイル化した途端に critical が出てくる。

疑わしい箇所は、さらに小さく切って確定させる。推測で報告させない。「〜と思われる」で上がってきた指摘は、後で確認すると半分が誤検出だった。

意図的な変更を先に渡す（これを省くと機能しない）

原本と比較させる場合、「原本と違うが、それは意図的」というリストを渡さないと誤検出で埋まる。統一処理をかけた資料では、揃えた結果すべてが「原本と違う」ので、リストなしだと数百件の偽陽性が出て本物が埋もれる。

渡すべきもの:

• 意図的に統一した要素とその値（例: ラベルは全ページ pt16 / 左1.005in に統一）
• 意図的に原本のまま残した要素（例: 番号 01-05 はラスタのまま。書体が違って見えても正常）
• 文言を変えたページとその内容
• 既知の限界（例: フォントが代替なので字形は原本と違う）
• 許容する誤差の量（下記）

誤差の許容量を数値で渡さないと、判定が「なんとなく」になって報告がぶれる。フォントを代替している資料では文字の累積アドバンス差が必ず出るので、次のような形で線を引いておく:

- 字送りの累積差は行長に比例して増える。行末で 0.05in（約13px）以内は許容
- ただし、そのずれで隣の要素と重なる/罫線を越える場合は行長に関わらず欠陥
- 要素の位置ずれは 0.03in 超で major、0.08in 超で critical

「行長に比例してずれる」のは代替フォントの正常な挙動で、比例していないずれこそが本物の欠陥（1箇所だけ飛んでいる、短い行なのに大きくずれている）。この見分け方も伝えておくと精度が上がる。

同型ページはピクセルで実測する

「カリキュラム 01〜05」のような同型ページ群は、目視では分裂に気づけない。10ページ離れた2枚を記憶で比較できないからだ。実案件では大番号の位置・サイズ・書体が3系統に分裂していたのに、5ラウンド目まで誰も指摘できなかった。

シリーズを検出したら、要素ごとにインクの外接矩形を実測して表にする。ずれ 0.03in（8px相当）超は major、0.08in（20px）超は critical。数値で出せば議論の余地がない。

原本由来を分離する

原本にも同じ乱れがある箇所は、直す対象ではない（クライアント確認事項として別枠にする）。これを分けないと、直せないものを直そうとして無限ループする。原本比較を必ずセットにして、「悪化したもの」だけを修正対象に絞る。

前提条件

• 必須ツール: Python 3（Pillow / numpy）
• PPTX を入力にする場合のみ: LibreOffice（soffice。brew install --cask libreoffice）
• PDF・レンダ済み画像を入力にする場合: poppler（pdftoppm。brew install poppler）
• 検収そのもの（全ページ拡大目視・実測・カバレッジ監査）は Claude Code の Agent（並列サブエージェント）機能のみで完結する。追加の MCP は不要

pip install pillow numpy
brew install poppler
brew install --cask libreoffice   # PPTX入力時のみ

手順

スクリプトは ~/.claude/skills/slide-qa/scripts/ にある。以下では S=~/.claude/skills/slide-qa/scripts を前提に書く。

1. 準備

S=~/.claude/skills/slide-qa/scripts
python3 $S/prepare.py deck.pptx --sheets              # PPTX から
python3 $S/prepare.py deck.pdf --sheets               # PDF なら LibreOffice を経由しない
python3 $S/prepare.py --sheets-only 'render/pg-*.png' # レンダ済みならシートだけ

251dpi（13.33in幅で約3347px）で PNG 化し、俯瞰用のコンタクトシートも作る。解像度は落とさないこと。等倍で見えない欠陥は「実害なし」と判断できるが、そもそも解像度が足りないと判断自体ができない。

2. 原本との差分を先に取る（原本がある場合）

python3 $S/diff.py 'render/pg-*.png' src --out qa/diff --order page_order.json --ink-only

どこが変わったかを機械的に出してから、その領域を拡大目視する。全ページを平等に眺めるより圧倒的に速く、見落としも減る。差分量のランキングも出るので、検査の優先順位付けに使える。

--ink-only は「原本が白地だった場所の変化」だけを残すモード。代替フォントを使っている再構築物では文字が全て差分に出てしまうので、背景・装飾の破壊を探すときはこちらを使う。

--order は納品順と原本順が違う資料（ページ削除・並べ替えをした資料）では必須。渡さないと別ページと比較して、あるはずのない差分だらけになる。

3. 全数検査（並列）

references/workflow-template.md のスクリプトをベースにする（Workflow ツールが無い場合の Agent ツールへの読み替えも同ファイルに書いてある）。実行前に作業ディレクトリを作っておくこと。作らないと各エージェントがタイル生成の1手目で落ちる。

班ごとのプロンプトに必ず含めるもの:

• 対象ページのレンダ画像パスと原本画像パス
• 6タイル（横3×縦2）分割のコマンドと「全タイルを Read せよ」の明示
• 意図的変更リスト（上記）
• チェック観点（文字・整列・消し込み跡・装飾・原本比較）
• severity の判定基準
• 出力JSONの形（page / severity / type / description / fix / bbox）
• 「ゼロ件のページは2周目を回してから確定せよ」

各エージェントの返り値は {"findings": [...]} の形で1つにまとめて保存する。page はレンダの並び順（1始まり）で振る。

4. シリーズ整合の実測

コンタクトシートを1体のエージェントに渡して同型ページ群を洗い出させ、シリーズごとに実測エージェントを立てる。実測は PIL でインク bbox を取らせ、ページ間比較の表を作らせる。比較ストリップ画像も保存させると目視でも裏が取れる。

計測窓の決め方が実測の成否を分ける。 素朴に「非白画素の外接矩形」を取ると、写真・網点・グラデーション罫線・背景装飾を全部インクとして拾って壊れる。窓の指示は次のようにする:

• 測る要素の期待位置の近傍だけに窓を切る（全幅で測らない）
• 窓の中で最大の連続スパンを採る（窓の端が隣の要素をかすると min/max 中心が引っ張られる）
• 文字を測るなら彩度の低い濃色だけに絞る、装飾線なら色で絞る、と対象ごとに条件を変える
• 出た値が要素サイズとして不合理（極端に大きい/小さい）なら計測失敗として捨てさせる

5. カバレッジ監査

検出件数の少ないページ、観点が偏っているページを監査役に選ばせ、重点再検査（9タイル分割）をかける。1周目の取りこぼしはここで拾える。

6. 集計とレビュー

python3 $S/report.py findings.json --render 'render/pg-*.png' --out qa \
        --originals src --order page_order.json

--render は glob パターンで渡す（クォート必須）。ディレクトリを渡すと中の全PNGを拾う。複数の出力系統が同じディレクトリにあると止まるので、その場合はパターンで絞る。

--order は納品順と原本順が違う資料では必須。無いと別ページの原本と並べたHTMLができ、人間が誤判定する。

集計サマリを標準出力に出し、ページ画像と所見を並べたレビューHTMLを作る。critical のあるページは目次で赤くなる。

判定基準

原本にも同じ乱れがあるものは severity に関わらず「原本由来」と明記させ、修正対象から外す。

修正ループ

検収は「見つけて終わり」ではない。実案件では6ラウンド回した。

全数QA → 原因診断（並列） → パッチ適用 → 再ビルド → 対象ページ限定の検収 → （必要なら）全数QAへ戻る

原因診断を検査と分けるのが要点。 検査エージェントの fix 案は現象からの推測なので、そのまま適用すると外す。診断は別のエージェントに、実データ（ソース・中間ファイル・レンダ）を触らせて原因を特定させ、修正後のシミュレーションで差分ゼロを確認してからパッチを出させる。この形にしてから、手戻りが激減した。

修正方針の原則:

• 迷ったら元に戻す。 加工でトラブルが出た箇所は、加工前の状態（原本ラスタ・元の値）に戻すのが最も確実。元データはその範囲では必ず整っている
• グループ単位で揃える。 5個中1個だけ加工に失敗している状態は、残り4個も戻して揃える方が速くて確実
• 修正は副作用を生む。 実案件では、消し込みを直したら罫線が虫食いになり、それを直したら別のゴーストが出た。毎ラウンド全数やり直すのが結局いちばん速い

落とし穴

検査結果を鵜呑みにしない。 自分でも現物を確認すること。実案件では critical 報告と自分のスポット確認が食い違い、確認したら報告が誤りだったケースがあった。逆に、報告が正しくて自分の確認が甘かったケースもある。数値（実測値）を伴う指摘は信頼できるが、印象で書かれた指摘は要検証。

「しきい値超」が減らないときは計測を疑う。 補正を反復しても収束せず振動する場合、直すべきは対象ではなく計測側。計測窓に別の要素が入り込んでいることがほとんど。

セッション上限で部分死する。 20体以上を並列で回すと途中で止まることがある。Workflow なら resume でキャッシュが効くので、完了済みは再実行されない。時間帯をずらして再開する。

検出ゼロを成功と思わない。 検査が浅いだけの可能性がある。カバレッジ監査を必ず通し、それでもゼロなら本当にゼロと判断してよい。