「公表されている件数と、実際に取得できたデータの数が合わない」

大規模なWebスクレイピングをやったことがある人なら、この "取り漏れ" 問題に一度は当たったことがあるんじゃないでしょうか。全国3万件規模の販売店データを扱ったプロジェクトで、うちも同じ壁にぶつかりました。

今回集めていたのは、全国の中古車販売店の情報です。お店の名前や住所、電話番号に加えて、「そのお店が今、何台くらいの車を売りに出しているか」という在庫の台数まで含まれます。この記事のなかで「台数」と出てきたら、この "各お店がサイトに掲載している車の在庫数" のことだと思って読んでみてください。

なお今回のデータ収集は、対象サイトの許可をいただいたうえで実施したものです。そのうえで得られた知見を、これから同じような取り組みをする方の参考になればと思ってまとめてみました。

原因を1つずつ潰していった結果、大規模スクレイピングでの取り漏れは、だいたい次の3つのパターンで起きるとわかってきました。

1. データの「最後のほう」を、システムが勝手に「もう終わり」と判断して取りこぼす

2. ページの枚数を数え間違えて、途中までしか集めていない

3. 宣伝用の文章に出てくる数字を、本物のデータと取り違えてしまう

どれも、プログラムとしては問題なく動いてしまうぶん、気づかないうちに紛れ込んでしまう落とし穴なんですよね。特にAIにコードを書かせる場合は、こうしたミスが混ざりやすい印象があります。防ぐ鍵は「サイトの仕組みを正しく理解すること」と「本物のデータと突き合わせて確かめること」の2つ。この記事では、それぞれの原因と対策を、実際にあった例と一緒に紹介していきます。

前提：大規模なデータ収集は、なぜ難しいのか

スクレイピングのプログラムを作ると、たいていは「エラーを出さずに最後まで動く」ようになります。でも、大量のデータを集める仕事では、「動く」ことと「正しく集められている」ことは、まったくの別物なんです。ここを混同すると、静かに欠けたデータや間違ったデータを、そのまま納品してしまうことになります。

やっかいなのは、取り漏れも取り違えも、エラーとして表に出てこないこと。10件のうち3件が抜けていれば、ざっと見ればすぐ気づけます。でも3万件のうち500件が抜けていても、全体を眺めた印象は「ちゃんと取れている」ままなんですよね。数字の間違いも同じで、大半が正しければ、少数のおかしな値は平均や件数の中に埋もれて見えなくなります。プログラムが止まらないミスほど、発見が遅れてしまうわけです。

3万件という規模になると、難しさはさらに増します。相手のサイトは、ページのめくり方、並び順、地域の区切り方、表示のクセなど、こちらの想定どおりには作られていません。そのちょっとしたズレが、そのまま取り漏れや取り違えにつながっていきます。だからこそ、「動いたから大丈夫」で終わらせず、サイトの実際の作りと、本物のデータで一つひとつ裏を取っていく工程が欠かせないんです。

取り漏れの原因① 「もう終わり」の勘違い

まず一番よくあるのが、データを集め終える「区切りの付け方」です。今回は最初、「新しい店舗がしばらく出てこなくなったら、その地域は集め終わった」と判断させていました。一見もっともらしいのですが、実はこれが最後のほうのデータを丸ごと落としてしまいます。

理由はこうです。店舗の一覧が「在庫の多い順」に並んでいると、最後のほうのページには在庫の少ない小さなお店がびっしり固まっています。しかもこの層は同じ順位の店がずらっと並ぶので、ページをめくるたびに順番が微妙に入れ替わるんですね。すると、新しい店がしばらく出てこない区間が途中にできてしまい、まだ続きがあるのに「もう終わり」と勘違いしてしまう。名簿の後ろ数ページを読まずに閉じてしまうようなもので、実際にこれで全国500件以上のお店を取りこぼしていました。

さらに困ったことに、サイトによっては、存在しないページ番号を開いても「最後のページと同じ内容」を返してくることがあります。つまり「空っぽになったら終わり」という区切り方は、いつまで経っても成立しないんです。

対策は、区切りの付け方を賢くしたうえで、集める経路そのものを二重にすることでした。サイトが公開している「全店舗の索引」にあたるデータを別ルートで取得して、地域ごとに集めた結果と照らし合わせます。片方が取りこぼしても、もう片方が補ってくれる。この二重チェックで、網羅性をぐっと引き上げることができました。

取り漏れの原因② ページの枚数を数え間違える

次は、各地域が「何ページあるか」の数え間違いです。システムがページ数を読み取るとき、本来のページ番号とは関係のない数字を拾ってしまうことがありました。今回は、ページの中に埋め込まれていた地域コードの数字を「ページ数」と勘違いして、一部の地域を途中までしか回っていなかったんです。

原因はシンプルで、数字を拾う範囲を広げすぎていたこと。ページの中には住所のコードや店舗の番号など、数字があふれています。「それらしい数字」を広く拾おうとすると、必ずどこかで取り違えが起きてしまうんですね。

対策は、数字を読む場所を「ページめくりの表示部分」だけにきっちり限定すること。これだけで数え間違いは消えました。修正後は、9ページしかない地域も、70ページを超える大きな地域も、最後まで漏れなく回れるようになっています。「広く拾って後で捨てる」より「最初から狭く取る」ほうが、この手の間違いにはずっと強いんです。

取り漏れの原因③ 宣伝文句の数字を、本物のデータと取り違える

3つの中でいちばんやっかいだったのが、これです。あるお店の「在庫台数」を集めるとき、店舗紹介ページの文章の中から数字を拾う作りになっていました。ところがこの紹介文は自由に書けるPRスペースで、たとえば「大型モニタでのデジタル商談で、グループ在庫10,000台以上」といった宣伝文が入っていることがあります。システムはこの10,000を、そのお店の在庫台数として記録してしまっていたんです。実際には全国で一番多い店でも1,122台なので、10,000は明らかにおかしい数字。でも「これは宣伝、これは実データ」と文章を読み分けるのは、機械には案外むずかしいことなんですよね。

大事なのは、文章の中から数字を拾うやり方そのものに、そもそも無理があるという点です。「在庫」も「台」も、そのお店の在庫にも、グループ全体の在庫にも、同じように出てくる言葉。だから言葉づらだけでは区別できないんです。

そこで、文章からではなく、ページの決まった場所に正式に表示されている台数だけを見るように作り直しました。ただ、ここにも一段の罠があって、その「決まった場所」が、実はクチコミの件数を表示するのにも使い回されていたんです。そのため「これは本当に在庫台数なのか」を、もう一段確認する必要がありました。こうした一手間を惜しまないことが、信頼できるデータと、それっぽいだけのデータの分かれ目になるのかなと思っています。

サイトの仕組みを理解する：公表数と、実際に取れる数はなぜ違うのか

3つの原因を潰しても、公表されている件数とぴったり一致するわけではありません。ここで大事になるのが、「そもそも取れる上限は、サイト側の作りで決まっている」という理解です。ある地域では、3つの数字が次のように食い違っていました。

この差は不具合ではなく、仕組みとして説明できます。公表数と、実際に一覧でたどれる数がずれるのは、契約はしているけれど一時的に休業しているお店、新しく登録されてから一覧に載るまでの時間差、一時的に非公開になっているお店、そして数え方そのものの違いといった事情が重なるためです。総数は在籍しているお店の数、一覧に出るのは今まさに公開中のお店だけ、と考えると腑に落ちるんじゃないでしょうか。

ここを説明できるかどうかは、データの信頼性そのものに関わってきます。「100%取れていないから雑なデータ」なのではなく、「サイトの仕組み上たどれるのはここまでで、その差はこういう理由です」と根拠を持って言えること。これがあると、受け取った側も安心してデータを使えます。取り漏れをなくす努力と、取れない差をきちんと説明する努力は、どちらも品質の一部だと考えています。

品質のチェック：AIがコードを書く時代に、正しさをどう担保するか

ここまでの原因に共通するのは、「動くコードが、正しいとは限らない」という一点です。AIにコードを書かせる時代には、この原則がますます大事になります。それらしいコードが一瞬で出てくるぶん、前提の間違いに気づく機会が減ってしまうからです。だからうちでは、確かめる作業を「仕組み」として組み込むようにしています。

ひとつめは、本物のページと突き合わせて確かめること。集めたデータの一部について、実際のページをもう一度開いて、値が合っているかを一件ずつ見比べます。ここでコツがあって、集めるプログラムと確かめるプログラムが同じ作りだと、同じ勘違いをしたまま「合っています」と言ってしまうんですよね。なので、人の目で別に確認し、しかも「今回問題が起きた場所」を狙って重点的にチェックするようにしています。

そしてもうひとつ、ここが今回いちばん学びになった点です。在庫台数のように日々変わる数字は、あとで同じお店を見に行っても、その時にはもう値が変わっていることがあります。たとえば集めた時点で55台だったお店が、数日後に見ると38台になっている。こうなると、後から画面を確認しても「集めたときのミスなのか、それとも実際に在庫が減ったのか」を区別できません。つまり、集めたその瞬間の記録（スクリーンショットや、そのときのページそのもの)が残っていないと、目視での確認そのものが意味を失ってしまうんです。「今見たら38台でした」は、「集めたときに55台だったこと」の証明にはならないんですよね。

だからうちでは、取ってきた元のページを、その時点の記録として丸ごと保存するようにしました。全国規模でも、圧縮すれば100MB程度に収まります。これがあれば、「このデータは、いつのこのページの、この表示です」と現物で示せます。実際、あとから値の食い違いが見つかったときも、保存しておいたページと突き合わせて、数分で「これは在庫の変動」「これは問題なし」と切り分けることができました。プログラムの精度そのものより、元データを残しておくことのほうが、結果的にいちばん効いたというのが正直な実感です。

ふたつめは、桁のおかしい値を自動で止めること。全国で一番多い店でも1,122台とわかっていれば、それを大きく超える値が出た時点で「何かおかしい」と機械的に気づけます。今回は、たとえば1,500台を超える値が出たら、データを書き出す前にいったん止まる仕組みにしました。「値が入っているか」ではなく「値の大きさや分布が自然か」を見る、という視点の切り替えですね。

まとめると、AIが書いたコードは「動く」ことは見せてくれても、「正しい」ことまでは保証してくれません。突き合わせ、記録を残すこと、そして異常の自動検知。この3つを仕組みにして初めて、安心して使えるデータになります。

まとめ

大規模なデータ収集での取り漏れは、多くの場合この3つに行き着きます。最後のほうを「もう終わり」と勘違いして落とすこと、ページの枚数を数え間違えること、そして宣伝文の数字を本物と取り違えること。どれもプログラムとしては動いてしまうので、静かに紛れ込んでしまいます。

これを防ぐ鍵は2つでした。ひとつはサイトの仕組みを理解すること。データの区切りはどう付けるべきか、公表数と実際にたどれる数はなぜ違うのか、同じ表示が別の意味で使われていないか。もうひとつは、本物のデータと突き合わせて確かめること。実際のページとの照合、その時点の記録を残すこと、おかしな値の自動検知です。この2つを押さえることで、「ただ動くだけ」のデータ収集を、「安心して使える」データ収集に引き上げられます。

AIのおかげで、データを集めるプログラムを作る速度は、本当に劇的に上がりました。だからこそこれからは、「コードが書けるか」よりも「集まったデータが本当に正しいと確かめられるか」が、価値の分かれ目になっていくんじゃないかと思います。うちでは、こうしたデータ収集と品質チェックの仕組みづくりに継続的に取り組んでいます。データの取得や整備でお困りのことがあれば、どうぞお気軽にご相談ください。