【Claude Code】社内の BI ダッシュボードを AI ダッシュボードに Part2：数値の検証 — 照合とレビューで正しさを担保する

1. はじめに — 正しそうで間違う数字

社内の BI ダッシュボードで一番怖いのは、画面が動かないことではなく、正しそうに見えて間違っている数字です。動かない画面はすぐ気づかれますが、もっともらしい数字は会議の資料に貼られ、判断に使われます。

Part1 では、年度・施設・地域の不一致をそろえる進め方を紹介しました。Part2 は、そろえたデータの数字をどう確かめたかです。

先に結論を書くと、作る途中で見つかった誤りの多くは、自動のテストも件数の照合も通った状態で残っていました。見つけたのは、地図に描いたとき、表の定義を読んだとき、変化を並べたとき、人が画面を見たときです。

↻

この回の構成です。

1. はじめに（この章）
2. 照合は育てるもの
3. 描いてみる — 305施設が海の上
4. 定義を読む — 医療圏の表は患者の住所で数える
5. 変化を見る — 能登北部 −11%
6. 抜き取る・実物を見る
7. 数字の出し方のルール
8. テストが通っても残る誤りの見つけ方
9. 今回のハーネス／まとめ

2. 照合は育てるもの

2-1. 止まるパイプライン

データの整備は sh pipeline/run.sh の1本で、取得から照合までが通しで走ります（Part1）。最後の照合（validate.py）は、照合レポート（data/out/validation.md）を書き出し、止める確認が1つでも外れたら、アプリ用のデータを書き出さずに止まります。

止まる作りにしておくと、Claude Code に段階を任せても、照合を通らないデータが画面に出ることはありません。Claude Code 自身も「照合が通るまでが自分の仕事」と分かって作業します。

2-2. 誤りを見つけるたびに、確認を1つ足す

照合の確認は、最初から全部そろっていたわけではありません。誤りを見つけるたびに、同じ誤りが二度と通らない確認を1つずつ足していきました。

↻

3章の地図の誤りでは、次の順で確認を足しました。

1. 誤りを見つけたら、先に確認を足す
2. 直す前のデータに当てて、その誤りをちょうど拾えることを確かめる
3. それからデータの作り方を直し、確認が通ることを確かめる

2番目を飛ばすと、「何も拾わない確認」を足して安心することになります。地図の誤りでは、この2番目で、足すべき確認が1つでは足りないことが分かりました。

3. 描いてみる — 305施設が海の上

3-1. 表では気づかなかった

地図とランキングの画面を作り、初めて地図を出したところ、東シナ海や中国大陸の上に病院の円が出ました。

原因は、病院の位置を借りた医療情報ネット（ナビイ）のデータに、座標が「0.0, 0.0」の病院が268あったことです（北海道147、沖縄31 など）。それをそのまま使っていました。影響は305施設で、うち272は日本の外（突き合った病院の座標が0、または0が混じった市町村の代表点）、33は日本の範囲内ですが誤った位置でした（鹿児島市の代表点が海の上に出る、など）。

件数の照合は通っていました。位置についての確認が「どのルールで位置を付けたか」の内訳しかなく、表で見ても気づかず、地図に描いて初めて分かった誤りです。

3-2. 直し方にも判断が要る

単純に「座標0の病院を外す」と、名前の突き合わせの相手がいなくなり、同じ市町村の別の病院に結び付くおそれがあります。そこで、名前の突き合わせには使い、座標としては使わない形にしました。直した後、突き合わせの結果が1件も変わらないことも確かめています。

3-3. 1つの確認では足りなかった

再発を防ぐため、照合に「日本の範囲内」の確認を足し、2-2 の手順どおり直す前のデータに当てました。すると拾えたのは272件だけで、日本の範囲内の誤った位置33件を見逃していました。「所在地の都道府県の範囲内」の確認も足すと、272件と33件をちょうど拾います。

社内のデータでも、住所や座標、日付のように表で眺めても違和感が出にくい列は、地図や時系列に描いて確かめるのが近道です。

4. 定義を読む — 医療圏の表は患者の住所で数える

当初は、DPC の「医療圏別 MDC患者数」の表を、病院ごとの件数を医療圏で足した値の照合先にする予定でした。病院の所在地で足した値と、表の値が合えば正しい、という考えです。

ところが、集計条件の資料で表の定義を読むと、この表は患者の住所で数えていました。県をまたいで受診する分だけ、合わないのが正しい表です。

照合先からは外し、参考として県ごとの差だけを照合レポートに出しています（令和6年度で埼玉 −15%、東京 +5% など）。照合先にしていたら、「合わない」原因を探して、正しいデータを壊していたかもしれません。

社内でいえば、「売上」が出荷ベースか請求ベースか、「顧客数」が契約単位か拠点単位か、にあたります。照合する前に、照合先が何をどの単位で数えているかを読むのが先です。

5. 変化を見る — 能登北部 −11%

Part1 で触れたとおり、レビューで「医療圏の名前が同じでも、境界が変わることがある」と指摘されました。名前で突き合わせているので、境界が変わっても照合は通ってしまいます。

そこで、医療圏ごとの件数の変化率を年度で比べ、全国の変化率から15ポイントを超えてずれた医療圏を報告する確認を足しました。

• 2022 → 2023年度：全国 +6.3%。ずれの大きい医療圏は0
• 2023 → 2024年度：全国 +4.4%。ずれの大きい医療圏は1つ。石川県 能登北部 −11%

令和6年能登半島地震（2024年1月）の後の年度です。境界の変更ではなく、患者数の減少と判断し、データには手を入れていません。

機械が出したのは「ずれている」という事実だけで、その意味を決めたのは人です。止める確認にしなかったのは、このためです。

6. 抜き取る・実物を見る

6-1. 抜き取りは、知っている数字で

照合が通ったあとも、数字を元の表と見比べる抜き取りを、段階ごとに入れました。

• 名寄せ：60件を抜き取り、取り違えがないことを確かめた
• 件数：札幌医大の MDC別件数、脳腫瘍の手術別件数・在院日数が元の表と一致
• 臨床の感覚：脳梗塞の経皮的脳血管形成術、結腸がんの結腸切除術の上位が専門病院になっている。榊原記念病院は先天性（MDC14）が多い

最後の項目は、照合では確かめようがありません。その分野を知っている人が見て、違和感がないかです。社内の BI でも、営業や現場の人に「この顧客がこの順位はおかしい」と言ってもらう場面にあたります。

6-2. 注記の行が施設になっていた

照合レポートには、地図の位置が付かなかった施設の一覧も出しています。この一覧を見ていると、施設名に注記の文が入った行がありました。施設の一覧の表の下にある注記を、施設として読んでいたのです。件数は0なので集計には効かず、照合も通っていました。一覧を人が眺めて初めて見つかった誤りです。

6-3. 画面は実物で見る

画面ができた区切りでは、Claude in Chrome で実物の画面を見ながらレビューし、5つを直しました。

見つかったこと	直したこと
地図の左半分を中国大陸が占め、地名が中国語・韓国語・ロシア語	地理院タイルの淡色地図に。地図の右に上位10施設を置き、地図を縦長の日本に合わせた
施設名が正式名称のままで長い	短い名前に。6,448施設のうち4,499の表示名が短くなった
非公表の書き方が表によって「10未満または0」と「-」でそろっていない	どちらも「<10」に
「伏せ字」は読み手には内部用語	画面では「非公表（<10）」
比較表の列の間が空きすぎ	項目名の列を30%に、施設の列を均等に

スマホの幅の確かめでは、ヘッドレスの Chrome が最小幅500pxで描いていて、390px を指定しても正しく確かめられていないことにも気づきました。端末の幅を指定できる方法で確かめ直しています。道具が正しく測れているかも、確かめる対象です。

7. 数字の出し方のルール

数字そのものが正しくても、出し方で誤解されることがあります。非公表（10症例未満または0件）を0として足さないのは前提として、画面では3つのルールを決めました。

↻

3つ目の「地域は公表件数の合計」は、作る途中で見込みが外れた場面から決まりました。最初は、手術の分岐を足すと非公表が混じって「以上」が増えるので、デモの質問を手術1つに絞れば減ると考えていました。ところが絞っても、北海道の医療圏の比較では、札幌の 1,067件が44施設のうち16施設の非公表を含む「以上」のままでした。

原因は分岐の足し算ではなく、地域の合計には、その手術をしていない病院（10件未満または0件）が必ず入ることでした。Claude Code はこれを報告して判断を仰ぎ、人が「見出しで断り、行ごとの『以上』はやめる。上限は吹き出しと CSV に出す」と決めています。

1. 
2. 

‹1 / 2›

上限は公表された情報だけから出せる値で、1位と2位の範囲が重なるかどうかが分かります。順位を読みすぎないための情報です。

8. テストが通っても残る誤りの見つけ方

ここまでの誤りは、どれもコードは動き、テストは通り、件数は合っていました。見つけたのは、次の4つの角度です。

↻

生成 AI で表やリストを作ると、正しそうに見えて間違っていることがあります。文章がもっともらしいのと同じで、数字ももっともらしく並びます。だからこそ、AI に作らせる量が増えるほど、人が別の角度から確かめる場面を作業の区切りごとに入れておく必要があります。

9. 今回のハーネス

道具	このリポジトリでの実体	役割
止まる照合	pipeline/validate.py、run.sh	外れたらアプリ用のデータを書き出さない
照合レポート	data/out/validation.md	止める確認と報告だけの確認を、毎回書き出す
確認の足し方	直す前のデータで拾えることを確かめてから直す	何も拾わない確認を防ぐ
修正だけのコミット	座標0の修正を単独に	何が変わったかを後から見られる
実物のレビュー	Claude in Chrome、端末の幅を指定した確かめ	表では分からない誤りを見る
人の判断	報告の意味、出し方のルール	機械が白黒を決められないところ

10. まとめ

• 作る途中の誤りの多くは、テストも件数の照合も通った状態で残っていた
• 照合は育てるもの。誤りを見つけたら、直す前のデータで拾えることを確かめてから確認を足す。1つで足りないこともある
• 描く・定義を読む・変化を見る・抜き取る。角度を変えて見ると、表では見えない誤りが出てくる
• 正しい数字でも、出し方で誤解される。非公表を0で足さず、うるさくならない書き方をルールにした

数字の正しさは、AI ではなく、照合と人の目で担保します。

次のステップ

Part3（近日公開）では、いよいよ生成 AI の組み込みです。AI に件数を一度も渡さない仕組み、返答を画面に渡す前の4つの関所、本物の API を呼ぶテストと呼ばないテストの分け方、そして AI の揺れを指示文ではなくサーバー側の決まりで止めた場面を紹介します。