Claude Code × Medical Application
【Claude Code】目視の確認を自動チェックに Part2:結果の検証 — 画素の照合と正解つきのダミー帳票

1. はじめに — 「動いた」と「正しい」は違う
Part1 で見た改ページの検出は、手順だけを見れば単純です。ページを灰色の画像にして、端の白い画素を数えるだけ。だからこそ、画面に結果が出たことと、その結果が正しいことは別 です。
- 灰色にする式が少し違えば、245 を境にした白の数が変わる
- 縮め方が違えば、端の画素の値が変わる
- しきい値の「より大きい」と「以上」を取り違えれば、ちょうど 0.98 のページの判定が変わる
どれも画面を見ただけでは気づきません。帳票の確認に使う道具が、自分自身の確認をおろそかにしていては意味がありません。
この回では、TLF Visual QC の改ページの検出を、3つの段階で確かめた方法を紹介します。
- 部品:灰色化と縮小を、定番の道具と画素単位で突き合わせる
- 全体:わざと崩したページと正解を先に用意したダミーの帳票で、当たり外れを数える
- 現実:申請形式の実際の帳票で、どう振る舞うかを見る
- 全画素灰色化と縮小の結果が、ImageMagick と一致
- 8 / 8わざと崩したページのうち、CHECK が付いたページ
- 0崩していないページに付いた CHECK(ダミーの帳票)
- 4ページ試した申請形式の帳票(R Consortium の申請パイロット)
2. 部品 — 灰色化と縮小を、画素単位で突き合わせる
2-1. なぜ部品から確かめるか
改ページの検出の数値は、灰色化と縮小の結果に強く依存します。白の判定は「245 より明るいか」の1本の線なので、灰色にする式のわずかな違いで、244 と 246 のように線をまたぐ画素が出てきます。縮小も、隣の画素をどう混ぜるかで、文字の端の画素の明るさが変わります。
そこで、ブラウザの中で書いた灰色化と縮小を、画像処理で広く使われている ImageMagick で同じ処理をした結果と、画素ひとつずつ突き合わせました。
2-2. 結果
同じページの画像を入れて、ダミーの帳票の29ページ分で、灰色化と縮小のあとの画素の値が すべての画素で ImageMagick と一致 しました(差は 0)。そのうち3ページ分は単体テストに入れ、手を入れるたびに確かめています。ずれが1つもないので、ここから先の白の割合の計算に、部品のずれが入り込むことはありません。
3. 全体 — 正解つきのダミーの帳票
3-1. 正解を先に決める
部品が正しくても、組み合わせた全体が正しいとは限りません。全体を確かめるには、どのページが崩れているかの正解 が要ります。
実在の帳票を使うと、正解を人が後から決めることになります。結果を見てから「このページは崩れていると言えなくもない」と判断が揺れるおそれがあります。そこで、崩すページを先に決めてから帳票を作る 形にしました。
ダミーの帳票は、架空の試験の31ページです。どのページをどう崩したかを、帳票と同時に正解のファイル(JSON)に書き出しています。
3-2. ダミーの帳票の中身
| 種類 | 向き | ページ | 正解 |
|---|---|---|---|
| 表紙 | 縦 | 1 | 検査しない |
| 患者背景の表(1ページいっぱい) | 縦 | 2〜4, 6, 9, 11, 27, 28, 30 | OK |
| 患者背景の表(3分の2で終わる) | 縦 | 7 | OK |
| 患者背景の表の最後のページ(2行だけ残る) | 縦 | 5, 29 | CHECK |
| 列が左に寄り、右半分が空く | 縦 | 8 | CHECK |
| ほぼ白紙(題と注記1行だけ) | 縦・横 | 10, 21 | CHECK |
| 有害事象の一覧(1ページいっぱい) | 横 | 12〜14, 16, 17, 19, 20, 22, 23, 25 | OK |
| 有害事象の一覧(3分の2で終わる) | 横 | 26 | OK |
| 有害事象の一覧の最後のページ(1〜2行だけ残る) | 横 | 15, 24 | CHECK |
| 一覧の列が左に寄り、右半分が空く | 横 | 18 | CHECK |
| 短い有効性の表と、ページ下の脚注2行 | 縦 | 31 | OK |

崩したページだけでなく、崩していないのに余白の多いページ も入れています。3分の2で終わる表(7, 26)と、短い表と脚注のページ(31)です。崩れたページを当てるだけなら、何でも CHECK にすれば当たります。崩れていないページに印を付けないことも、同じだけ大事です。
縦向きの表と横向きの一覧を混ぜたのも、実際の帳票の束に近づけるためです。横向きのページは、同じ文字の量でも白の割合が違って出ます。
3-3. 結果
検査した30ページ(2〜31)で、CHECK が付いたのは 5, 8, 10, 15, 18, 21, 24, 29 の8ページでした。正解の8ページとすべて一致し、崩していない22ページには1つも付きませんでした。
| 正解 CHECK | 正解 OK | |
|---|---|---|
| 判定 CHECK | 8 | 0 |
| 判定 OK | 0 | 22 |
余白の多い OK のページの値も見ておきます。
| ページ | 中身 | 下の端の白の割合 | 判定 |
|---|---|---|---|
| 7 | 3分の2で終わる表(縦) | 0.944 | OK |
| 26 | 3分の2で終わる一覧(横) | 0.859 | OK |
| 31 | 短い表と脚注2行 | 0.977 | OK(しきい値に近い) |
7ページと31ページは、しきい値 0.98 の手前で止まっています。とくに31ページは 0.003 の差です。崩れていないページとの間の余裕は、それほど大きくありません。
4. 現実 — 申請形式の帳票で試す
4-1. R Consortium の申請パイロット
実際の帳票として、R Consortium の作業部会が公開している R 申請パイロット1 の帳票を使いました。R で組み立てた申請パッケージを eCTD の形で FDA に試験的に提出し、FDA が解析を再現した取り組みで、提出物一式が GitHub で公開されています。試験は CDISC のパイロット試験で、実在の会社の帳票ではありません。
このうち、申請用の TLF をまとめた PDF(4ページ)を読み込みました。README によると、この PDF の表の書式は、組織ごとの作り方の違いを残すため、あえて統一されていません。
4-2. 結果
| ページ | 下の端 | 右の端 | 全体 | 判定 | 見立て |
|---|---|---|---|---|---|
| 1 | 0.857 | 0.895 | 0.862 | (既定では検査しない) | 表紙がなく、1ページ目から表 |
| 2 | 0.960 | 0.922 | 0.917 | OK | 表の下が大きく空いているが、脚注が測る範囲の下半分にある |
| 3 | 1.000 | 0.897 | 0.885 | CHECK | 短い表が上のほうで終わっている。改ページの崩れではない |
| 4 | 0.896 | 0.913 | 0.876 | OK | — |
4-3. 分かったこと
4ページだけの小さな例ですが、手法の性質がよく表れました。
- CHECK は「空きの多いページ」に付く:3ページは、短い表が上のほうで終わっているだけで、崩れてはいません。それでも下の端は真っ白なので CHECK になります。印は「崩れている」ではなく「目で見てほしい」という意味です
- 脚注があると見逃すことがある:2ページは、表の下が大きく空いているのに、脚注が測る範囲の下半分にあるため、下の端の白の割合が 0.960 で止まり、OK になりました。Part1 で書いた限界が、実際の帳票で現れた例です
- 表紙のない PDF もある:1ページ目から表が始まるので、既定の範囲(2ページ目から)では1ページ目を見ません。ツールの About では、検査する範囲を Custom にして1ページ目から見るよう案内しています
ダミーでは8ページすべてが当たりましたが、実際の帳票では、空きの多い普通のページへの印と、脚注による見逃しが、どちらも起こりえます。ダミーの結果だけを見て「漏れなく見つかる」と言わない ことが、この段で確かめた一番大事な点です。
5. Claude Code に任せたことと、人が決めたこと
| 任せたこと | 人が決めたこと |
|---|---|
| ImageMagick との画素の照合のテスト | 部品・全体・現実の3段で確かめること |
| ダミーの帳票と正解のファイルを作るプログラム | 崩し方の種類、崩していないのに余白の多いページを入れること |
| 判定と正解の突き合わせ、結果の報告 | 正解を帳票より先に決めること |
| 申請パイロットの帳票を読み込んだ結果のまとめと、各ページの見立て | どの公開の帳票を使うか、画像を載せず数値だけ示すこと |
ダミーの帳票は、Claude Code が架空のデータから生成したものです。人が決めたのは「何を崩すか」「何を崩さずに入れるか」で、崩し方の一覧と正解の形を指示書に書いてから任せました。
照合やテストは、一度書けば何度でも回せます。途中でダミーにページを1枚足したり、画面を作り直したりしても、部品の照合とダミーの判定を回し直せば、結果が変わっていないことをそのつど確かめられました。
6. まとめ
- 画面に結果が出ることと、結果が正しいことは別。部品・全体・現実の3段で確かめた
- 部品:灰色化と縮小は、ImageMagick とすべての画素で一致した
- 全体:崩すページを先に決めたダミーの帳票(31ページ)で、CHECK は正解の8ページと一致し、崩していない22ページには付かなかった
- 現実:R Consortium の申請パイロットの帳票では、短い表のページに CHECK が付き、脚注のあるページを見逃した。印は「崩れ」ではなく「目で見てほしいページ」の意味
- 正解を先に決めること、崩していないのに余白の多いページも入れることは、人が決めた
正解を先に用意しておけば、「だいたい合っている」で止まらずに済みます。そして、正解を自分で用意したことの限界も、実際の帳票で確かめておく必要があります。
次のステップ
Part3 では、もう1つの確認、図の配色を扱います。白黒で印刷したときの明るさの差、色の差、色覚の違いによる見え方を、どう測って印を付けているかを、例の配色7組の結果とあわせて紹介します。
出典
- Yi Guo. Detecting Abnormal Page Breaks Using Grayscale Pixel-Density Analysis in R Shiny. PharmaSUG 2026, Paper AP-233. https://pharmasug.org/proceedings/2026/AP/PharmaSUG-2026-AP-233.pdf(この手法は R/Pharma 2026 のワークショップでも紹介された)
- R Consortium R Submission Working Group. submissions-pilot1-to-fda(R 申請パイロット1の eCTD パッケージ、m1/us/report-tlf.pdf)。https://github.com/RConsortium/submissions-pilot1-to-fda
- 本ページのダミーの帳票は架空のデータで作成したものです。実在の試験・薬剤・企業とは関係ありません。R Consortium の帳票は、ページの画像を載せず、ツールで測った数値だけを示しています
