【Claude Code】目視の確認を自動チェックに Part0：全体像と設計

1. はじめに — 数値は確かめられても、体裁は目で見ている

治験の解析結果をまとめた帳票（TLF：表・一覧・図）は、総括報告書や申請資料、学会発表や論文の土台になります。1つの試験で数百ページになることも珍しくありません。

数値が正しいかは、別の担当者が同じ解析を独立にプログラムして突き合わせる、といった方法で確かめられます。一方で、次のような 体裁 の確認は、いまも多くの場合、人が PDF を1ページずつめくって行っています。

• 脚注を1行足したら、後ろのページの改ページが全部ずれた
• ページの最後に1〜2行だけ残って、下が大きく空いたページがある
• 図の色が、白黒で印刷すると同じ灰色になる
• 赤と緑で群を塗り分けた図が、色覚の違いのある人には見分けにくい

ページが多いほど見逃し、作り直すたびに全部を見直すことになります。

この連載では、この2つの確認を自動で行うツール TLF Visual QC を、Claude Code と進めた過程とあわせて紹介します。

• 2つ確かめること（改ページ・図の配色）
• 約30ミリ秒1ページあたりの計算時間
• 0件PDF を読み込んで計算する間の、サイトの外への通信
• 8 / 8ダミーの帳票で、わざと崩したページに付いた印

TLF とは何か、どこで誰が読むのか、当局の PDF の要件は何か、といった業務の背景は、参照ページ にまとめています。

2. TLF Visual QC でできること

2-1. 改ページのチェック

PDF の各ページを画像にして白い部分の割合を測り、下の端か右の端に不自然な余白があるページに CHECK の印を付けます。しきい値に近いページには、念のための札も付けます。

2-2. 図の配色のチェック

群に使う色の組ごとに、白黒にしたときの明るさの差、色の差、3つの色覚での見え方を測り、見分けにくい組に印を付けます。印の付いた色には、代わりの色の候補も出せます（試行中）。

2-3. 使い方は3ステップ

1. PDF を選ぶ（または最初から入っているダミーの帳票・例の配色を使う）
2. 検査する
3. 印の付いたページや色の組を、目で確かめる

登録もインストールも要りません。日本語と英語に対応しています。

3. 設計の要点 — 帳票を受け取らない

申請前の帳票は、社外のサービスに上げられないのがふつうです。そこで TLF Visual QC は、次の形にしました。

• 計算はすべて、使う人のブラウザの中：PDF はサーバーに送られず、画面を閉じれば消える
• サーバーは画面を配るだけ：受け取る仕組みそのものを持たない
• 外への通信を止めている：画面の部品もすべて同梱し、サイトの外には何も取りに行かない
• 通信を切っても動く：画面を開いて読み込みが終わったあとなら、ネットワークを切っても計算できる

「送っていない」を、ブラウザの開発者ツールで誰でも確かめられるようにしています（Part4）。

4. どこで役に立つか

部門	場面	使いどころ
開発（統計解析・プログラミング）	総括報告書・申請資料の TLF	出力し直すたびに、改ページの崩れを洗い出す
開発（メディカルライティング・QC）	提出前の確認	数百ページから、目で見るページを絞り込む
メディカルアフェアーズ	学会発表・論文・医療関係者向けの資料	図の配色が白黒の印刷や色覚の違いで見分けにくくないか確かめる
当局の照会への対応	追加の解析の帳票	短い期限の中で、体裁の確認にかける時間を減らす

どの場面でも、ツールは目視の確認を置き換えるものではなく、目で確かめるページと色を絞り込むための補助 です。

5. 手法の出どころ

改ページのチェックは、PharmaSUG 2026 で発表された論文（Yi Guo, Paper AP-233）の手法にもとづきます。同じ手法は R/Pharma 2026 のワークショップでも紹介されました。TLF Visual QC では、論文の手順と既定値のとおりに、ブラウザの中で動く形で書き直しています。

図の配色のチェックは、色の差の国際的な式（CIEDE2000）、ウェブの読みやすさの基準（WCAG）の相対輝度とコントラスト、色覚のシミュレーションの公開論文（Viénot ら 1999、Machado ら 2009）の式から実装しました。

6. 連載の構成

回	題名	中身
参照ページ	【業務説明】TLF の体裁確認 — 解析帳票の改ページと配色の要件	TLF が使われる場面、当局の PDF の要件、改ページが崩れる理由
Part0	全体像と設計	この記事
Part1（近日公開）	改ページの検出 — 灰色の濃さで余白を測る	6段の手順、しきい値と「しきい値に近い」札、手法の限界
Part2（近日公開）	結果の検証 — 画素の照合と正解つきのダミー帳票	部品・全体・現実の3段の確かめ方、申請形式の帳票での結果
Part3（近日公開）	配色の確認 — グレースケール・色の差・色覚	4つの物差し、例の配色7組の結果、代わりの色の提案
Part4（近日公開）	公開と運用 — 帳票を受け取らない設計	サーバーを持たない構成、本番でだけ起きた不具合、通信を切っても動く仕組み

7. Claude Code と進めたこと

実装の大部分は Claude Code に任せました。人が決めたのは、主に次のようなことです。

• 論文の手順と既定値を自分たちで工夫せず、そのまま使うこと
• 崩すページを先に決めたダミーの帳票で、正解と突き合わせて確かめること
• 帳票を受け取らない、外に通信しない、という設計の前提
• 色覚のシミュレーションの式をどの論文から取るか
• どこで線を引くか（しきい値）、何をツールの限界として書くか

式の実装やテスト、画面づくりは任せやすい一方、何を正解とし、何を確かめれば十分とするか は人が決める必要がありました。その分かれ目は、各回で具体的に紹介します。

次のステップ

ツールは visual-qc.herzleben.co.jp で公開しています。ダミーの帳票と例の配色がすぐに試せます。

今回は公開論文の手法をもとにしたツールですが、社内の帳票の決まりに合わせたチェックや、社外に出せないデータを扱うツールのご相談があれば、お問い合わせからお聞かせください。