Claude Code × Medical Application

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

1. はじめに — 「動いた」と「正しい」は違う

Part1 で見た改ページの検出は、手順だけを見れば単純です。ページを灰色の画像にして、端の白い画素を数えるだけ。だからこそ、画面に結果が出たことと、その結果が正しいことは別 です。

  • 灰色にする式が少し違えば、245 を境にした白の数が変わる
  • 縮め方が違えば、端の画素の値が変わる
  • しきい値の「より大きい」と「以上」を取り違えれば、ちょうど 0.98 のページの判定が変わる

どれも画面を見ただけでは気づきません。帳票の確認に使う道具が、自分自身の確認をおろそかにしていては意味がありません。

この回では、TLF Visual QC の改ページの検出を、3つの段階で確かめた方法を紹介します。

  1. 部品:灰色化と縮小を、定番の道具と画素単位で突き合わせる
  2. 全体:わざと崩したページと正解を先に用意したダミーの帳票で、当たり外れを数える
  3. 現実:申請形式の実際の帳票で、どう振る舞うかを見る
  • 全画素灰色化と縮小の結果が、ImageMagick と一致
  • 8 / 8わざと崩したページのうち、CHECK が付いたページ
  • 0崩していないページに付いた CHECK(ダミーの帳票)
  • 4ページ試した申請形式の帳票(R Consortium の申請パイロット)
部品・全体・現実の3段で確かめる図。部品は画素の照合、全体は正解つきのダミー、現実は申請形式の帳票
確かめ方の3段。下の段ほど細かく、上の段ほど実際の使い方に近い

2. 部品 — 灰色化と縮小を、画素単位で突き合わせる

2-1. なぜ部品から確かめるか

改ページの検出の数値は、灰色化と縮小の結果に強く依存します。白の判定は「245 より明るいか」の1本の線なので、灰色にする式のわずかな違いで、244 と 246 のように線をまたぐ画素が出てきます。縮小も、隣の画素をどう混ぜるかで、文字の端の画素の明るさが変わります。

そこで、ブラウザの中で書いた灰色化と縮小を、画像処理で広く使われている ImageMagick で同じ処理をした結果と、画素ひとつずつ突き合わせました。

2-2. 結果

同じページの画像を入れて、ダミーの帳票の29ページ分で、灰色化と縮小のあとの画素の値が すべての画素で ImageMagick と一致 しました(差は 0)。そのうち3ページ分は単体テストに入れ、手を入れるたびに確かめています。ずれが1つもないので、ここから先の白の割合の計算に、部品のずれが入り込むことはありません。

テスト画像を、ツールの処理と ImageMagick の処理で灰色化・縮小し、差を取った図。差はすべて0
画素の照合。差の画像は真っ黒(すべて0)

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
ダミーの帳票の崩したページの縮小画像を並べた図。下が空いたページ、右が空いたページ、ほぼ白紙のページ
ダミーの帳票の崩したページ(5, 8, 10, 15, 18, 21, 24, 29)

崩したページだけでなく、崩していないのに余白の多いページ も入れています。3分の2で終わる表(7, 26)と、短い表と脚注のページ(31)です。崩れたページを当てるだけなら、何でも CHECK にすれば当たります。崩れていないページに印を付けないことも、同じだけ大事です。

縦向きの表と横向きの一覧を混ぜたのも、実際の帳票の束に近づけるためです。横向きのページは、同じ文字の量でも白の割合が違って出ます。

3-3. 結果

ダミーの帳票の30ページについて、下の端・右の端・全体の白の割合と、正解・判定を並べた図
ダミーの帳票の判定。CHECK は正解の8ページとすべて一致し、それ以外のページには付かなかった

検査した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ページの、下の端・右の端・全体の白の割合を並べた棒グラフ
申請パイロットの帳票の測定値(ページの画像は載せていない)

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 の帳票は、ページの画像を載せず、ツールで測った数値だけを示しています