大規模スクレイピングではなぜ取り漏れが発生するのか - サイト仕様の理解と検証手法

大規模スクレイピングではなぜ取り漏れが発生するのか - サイト仕様の理解と検証手法

大規模スクレイピングではなぜ取り漏れが発生するのか - サイト仕様の理解と検証手法

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

大規模な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つの数字が次のように食い違っていました。

数字

件数

サイトが公式に表示している総数

2,088店舗

ページをめくって実際にたどれた数

1,978店舗

最終的にお渡ししたデータ

2,072店舗

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

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

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

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

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

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

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

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

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

まとめ

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

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

AIのおかげで、データを集めるプログラムを作る速度は、本当に劇的に上がりました。だからこそこれからは、「コードが書けるか」よりも「集まったデータが本当に正しいと確かめられるか」が、価値の分かれ目になっていくんじゃないかと思います。

スクレイピングの代行・データ収集の外注をお考えの方へ

「自社でスクレイピングを組んでみたものの、取り漏れや精度が不安」「大量のデータ収集を安心して任せられる会社を探している」という方は、ぜひ一度ご相談ください。

VISKでは、この記事で紹介したような検証と品質チェックの仕組みまで含めて、Webスクレイピングやデータ収集の代行を承っています。対象サイトの利用条件の確認から、データの取得・整備・納品まで一貫して対応しますので、「ただ集めるだけ」ではなく「安心して使えるデータ」をお届けします。スクレイピング代行の会社をお探しの際は、お気軽にお問い合わせください。

AI・システム開発のこと、VISKにご相談ください

「自社の業務にAIを活かせないか」「この作業、自動化できないか」——

そんな漠然とした段階からで大丈夫です。大阪のAI・システム開発会社VISKが、御社の課題に合わせて、企画から開発・検証までサポートします。