ChronometricaとScraperLinkの比較：Google検索結果の1ページが重複して見える理由

まず、何を単位に数えるかを決める

データセット項目は、保存された1つのオブジェクトです。必ずしも検索結果1件を表すわけではありません。ページオブジェクトは、リスト内に複数の結果を格納できます。別のオブジェクト内に格納されたリストを、入れ子の配列と呼びます。

結果を数える前に、保存された各項目が何を表すかを確認してください。2つのオブジェクトが、同じ観測記録を別の形式で示している場合があります。インポート処理で両方を展開すると、合計が、本来使うつもりだった観測記録の件数を上回ることがあります。

ScraperLinkの公開課題には、結果の重複を懸念する利用者の声が記録されています。これは過去の課題で、すでにクローズされています。利用者が抱いた疑問の根拠にはなりますが、現在の不具合やサービス停止を示すものではありません。過去の結果重複に関する課題

ここで使う公開製品仕様は、2026年10月20日に確認しました。同じ条件での収集実行や、実際の結果の確認は行っていません。この比較では、ドキュメントに記載された入力と出力形式を説明します。

次の3つの件数は、それぞれ異なる問いに答えます。

• データセット項目数：保存されたオブジェクトはいくつあるか。
• 検索結果の観測記録数：選択した検索に属する結果の項目は何件あるか。
• 重複を除いたリンク先数：それらの項目には、異なるリンク先ページがいくつ現れるか。

合計を確認する前に、どの件数を使うかを決めてください。保存オブジェクト数が正しくても、検索結果については誤った答えになることがあります。

現在のリクエストに直接修正を加える

提示した例では、次のScraperLink入力を使ってください。

{
  "keyword": "Nike",
  "limit": "10",
  "page": 1,
  "include_merged": false
}

現在の公開入力仕様は、これらの設定に対応しています。`limit`は、ここに示す文字列のまま使ってください。この例は、統合出力を無効にして、範囲を限定した1ページをリクエストします。ScraperLinkのデフォルトビルドと入力スキーマ

`Nike`を、使いたいクエリに置き換えてください。別のプログラムに送る前に、出力を確認してください。

選択したページ項目の中から、入れ子の結果リストを見つけてください。その項目数を数えます。次に、インポート処理がどのオブジェクトを読み、どのリストを展開するかを確認してください。インポート処理では、意図した出力形式を1回だけ使う必要があります。

リストの長さに保存オブジェクト数を掛けないでください。まず、それらのオブジェクトに別々の観測記録が入っているのか、同じ観測記録が異なる形式で入っているのかを確認してください。

この最初のリクエストは小規模にしてください。目的は、出力形式と数え方を確認することです。ページ項目をそのまま次の処理で使えるなら、目の前の要件は満たせています。現在の処理では満たせない別の要件を明確にしてから、ツールの変更を検討してください。

次の処理に必要な出力を比較する

受け入れ条件とは、出力を使う前に満たす必要がある条件です。この表を使って、その条件を書いてください。入力の行には、これらの例で使う設定を示しています。すべてのフィールドが必須だという意味ではありません。

各製品の列は、現在ドキュメントに記載されている仕様に基づいています。ScraperLink Actor、Chronometrica Actor、Chronometricaの入力スキーマ

展開とは、入れ子のリスト内の各項目を、それぞれ別の行に変換することです。展開するときは、各項目に属する検索の情報を保持してください。

展開処理が正常に動いているなら、使い続けてもかまいません。選択は、受信側のシステムによって決まります。ページオブジェクトを受け入れられるなら、出力形式を変えても役に立たない場合があります。個々の観測記録が必要なら、展開処理を残すか、最初からその行形式で受け取るかを決めてください。

架空の例：オブジェクトが2つあっても、結果が20件ある証拠にはならない

これは架空の例です。製品テスト、測定結果、顧客事例ではありません。

分析担当者が1ページをリクエストします。この架空の例では、未加工のページに、入れ子の検索結果の観測記録が10件入っています。任意の統合オブジェクトにも、同じ10件の観測記録が繰り返し格納されています。

分析担当者には、保存されたオブジェクトが2つ見えます。インポート処理で、その両方を展開します。

10 observations from the raw page
+ 10 repeated observations from the merged object
= 20 imported sightings

10 + 10 = 20という計算は正しいですが、その解釈は誤っています。この1ページで本来数えるべきなのは、10件の観測記録です。インポート処理で両方の出力形式を使ったため、スプレッドシートには各観測記録が2件ずつ入っています。

分析担当者は統合出力を無効にします。次に、未加工のページの結果リストを1回だけ読み、その長さを確認します。この架空の例では、それによって二重の展開を防げます。

この例は、Actorがページを2回取得したことや、2回課金したことを示していません。保存オブジェクト数だけでは、どちらが起きたとも判断できません。

その後、別のAPIが、送信する各項目に観測記録1件を求める場合、分析担当者は新たな選択をすることになります。展開処理を残すことも、その要件に合う出力がドキュメントに記載されたActorを選ぶこともできます。

Chronometricaは、その後に必要となる行形式の要件に合っています。この架空の合計件数は、収集性能が優れていることの根拠にはなりません。

Chronometricaが要件に合う場合

Chronometricaのドキュメントには、データセットの各行に検索結果の観測記録1件を格納し、検索エンジン、クエリ、順位、検索の情報を含めると記載されています。また、実行する検索エンジンとクエリの組み合わせごとに結果行数の上限を設定する`maxResultsPerExecutedQuery`も記載されています。Chronometrica Actor

次の入力例を出発点にしてください。

{
  "queries": [
    "Nike"
  ],
  "engines": [
    "google"
  ],
  "maxResultsPerExecutedQuery": 10,
  "country": "US",
  "language": "en"
}

キー、必須フィールド、使用できる値、リストの要素数の範囲、数値の範囲を、現在の公開スキーマと照合しました。この例は実行していません。Chronometricaのデフォルトビルドと入力スキーマ

この設定は上限です。リクエストから必ず10件の観測記録が返る証拠ではありません。件数を報告する前に、実際の出力を確認してください。

この形式は、各行に観測記録1件を保存するスプレッドシートに適しています。また、送信する各項目に観測記録1件を求めるAPIにも適しています。保存単位が、次の処理に必要な単位と一致します。

単位が一致するため、入れ子の結果リストを先に展開する必要がなくなります。それでも、システムで使うフィールドの選択、不明な値の保持、出力の確認は必要です。重複を除いたリンク先のリストが別に必要になる場合もあります。

この確認済みの適合性を理由に、Chronometricaを選んでください。利用できる根拠からは、速度、信頼性、精度、費用での優位性は確認できません。移行する前に、ほかの必要な機能も現在のドキュメントで確認してください。

ツールを変える前に5項目を確認する

1. 現在の統合出力の設定を確認してください。処理に必要な出力形式を特定します。目の前の件数の問題と、その後の行形式の選択を分けて考えてください。
2. **`include_merged:false`を設定し、範囲を限定した1ページをリクエストしてください。** 入力を正確に記録します。これにより、出力を、リクエストしたクエリとページに対応付けられます。
3. 入れ子の結果項目を数えてください。選択した未加工のページの結果リストを確認します。インポート処理がそのリストを1回だけ読むことを確かめてください。項目数と、展開によって作られた行数を比較します。
4. 次の処理で必要な単位を定義してください。たとえば、「インポートする各行は、正確に指定した1つのクエリに対する結果1件を表すこと」と、1文で書きます。その文を受け入れ条件にしてください。
5. 重複を除いたリンク先リストを作る前に、検索の情報を保持してください。検索エンジン、正確なクエリ、順位、利用できる時刻情報を残します。自分の処理で記録した時刻には、自分の処理で記録した時刻だと分かるラベルを付けてください。

これらの確認から、2つの判断を行います。まず、現在の出力を正しく数えられるかを判断してください。次に、その保存単位が次のシステムに適しているかを判断します。

手作業で使うスプレッドシートなら、展開処理を確認しやすい場合があります。繰り返し行うインポートでは、結果行を直接受け取る方が、受信側のシステムに合う場合があります。時間を短縮できると考える前に、自分の処理で必要な作業を確認してください。

その後に費用を比較する場合は、課金単位を別に定義してください。保存オブジェクト、検索結果の観測記録、課金対象の検索は、それぞれ異なる概念です。統合出力の合計件数だけでは、課金対象の検索数や価格面の優位性は分かりません。

合計件数を使う前にインポート処理を確認する

受け入れ条件は、確認できるほど具体的にしてください。「出力が正しく見える」だけでは、合計が違うときにほとんど役に立ちません。有用な条件には、元のリスト、数える単位、インポートする各行に残す必要がある検索の情報を明記します。

まず、選択した出力を展開前の状態で確認してください。対象とする観測記録を数えます。次に、その出力から作られた行を確認します。合計が異なる場合は、行を削除する前に、インポート処理がどのオブジェクトとリストを読んでいるかを確認してください。

重複するURLを削除するルールは、件数の誤りの原因を隠してしまうことがあります。また、別々のクエリで得られた有効な観測記録も削除するおそれがあります。まず、使う出力形式の選択を修正してください。重複を除いたリンク先リストは、その別の件数が必要なときだけ作成します。

確認結果を分かりやすい言葉で記録してください。数えたのがページオブジェクト、観測記録、リンク先のどれなのかを明記します。これにより、元の出力を見ていない人も、その合計を使えます。

観測記録と重複を除いたリンク先を区別する

同じリンク先が、異なるクエリの結果に現れることがあります。同じページを指していても、それぞれ別の観測記録として扱える場合があります。

重複を除いたリンク先リストからは、どのページが現れたかが分かります。観測記録からは、各クエリでそのページがどの順位に現れたかが分かります。両方の答えが必要なら、両方の出力を保持してください。

観測記録を基にリンク先リストを作成してください。リンク先から検索の情報をたどれるように、観測記録も保持します。同じURLが別のクエリにも現れたという理由だけで、観測記録を削除しないでください。

この区別は、2人が異なる合計を報告したときにも役立ちます。一方は観測記録を数え、もう一方はリンク先を数えたのかもしれません。結果が食い違っていると判断する前に、単位を明記してください。

その後、複数回の実行で得たエクスポートを統合する場合は、クエリと順位の根拠を失わずにBing検索のエクスポートを統合する方法を参照してください。そのガイドは、複数回の実行にまたがる統合を扱います。この比較では、その前段階である出力形式と保存単位の選択を扱います。

インポート時に不明な値をそのまま保持する

値がないことは、0を意味しません。順位が欠けているときに、順位0にしないでください。不明な件数を、確認済みの0件にしないでください。

不明な値は空欄のままにするか、受信側のシステムが対応する欠損値の形式を使ってください。その選択を記録し、後の計算で欠損データが測定結果として扱われないようにします。

時刻にも同じルールを適用してください。取得元のタイムスタンプを作り出さないでください。自分の処理がデータを受信した時刻しか分からない場合は、明確なラベルを付けてその時刻を保存してください。

どちらの出力形式でも、これらのルールを確認してください。独立した行の方が受信側のシステムで受け入れやすい場合がありますが、正しい解釈は必要です。行数が正しくても、すべてのフィールドがそろっていることや、各値が報告で想定した意味を持つことの証明にはなりません。