反復調査を始める前に検索演算子を検証する

1. クエリを書く前に、判断したいことを定める

検索によって何を判断する必要があるのか、1文で書いてください。必要なページの種類と、除外したいページを示します。

たとえば、ある機能を説明した公開ドキュメントのページが、判断に必要な場合があります。販売案内の中でその機能に触れているだけのページでは、目的を満たさないかもしれません。検索結果を見る前に、この基準を決めてください。

次の手順で進めます。

1. 調査の問いを明示します。
2. 必要なページの種類を示します。
3. 必要な話題や語句を明示します。
4. ウェブサイトや文書形式に条件がある場合は、それを明示します。
5. 検索結果のページを有用と判断する基準を定めます。
6. 検索結果のページを不適切と判断する基準を定めます。
7. どの証拠が欠けると判断できなくなるのかを明示します。

対象範囲を明確にしてください。公開検索では、候補となる公開ページを見つけられます。ただし、非公開のアカウント記録にはアクセスできず、ウェブサイトの全ページを網羅した一覧も確定できません。自分が所有するアカウント内の記録について調べる場合は、そのアカウントから記録を確認してください。公開検索に出ないことを、非公開の記録に関する証拠として使わないでください。

本ガイドでは、クエリの動作と調査目的への適合性を確認します。検索結果のサンプルを保存する方法は、別のテーマです。取得範囲を限定したGoogle検索のエクスポートガイドを参照してください。エクスポート件数だけでは、必要な種類のページをクエリで見つけられるかどうかは判断できません。

2. 適合・不適合の参照ページを選ぶ

参照ページとは、検証の前に内容を確認するページです。適合参照ページは、採用基準を満たすページです。不適合参照ページは、その基準を満たさないページです。

これらのページは、対照例として使います。対照例とは、検証結果を解釈するために使う、状態がわかっている例です。手作業で確認できる少数のページを選んでください。

1. 適合参照ページの候補をそれぞれ開きます。
2. 必要な情報が含まれていることを確認します。
3. 正確なウェブアドレスと、基準を満たす理由を保存します。
4. 不適合参照ページの候補をそれぞれ開きます。
5. 基準を満たさない理由を記録します。
6. 確認した日付を保存します。
7. クエリの結果を見る前に、参照ページの集合を明示します。

不適合参照ページには、調査で実際に混入が問題となりうるページを選んでください。たとえば、無関係なウェブサイトで同じ語句を使っているページです。こうしたページがあると、サイトの限定が目的に役立つかどうかを確認できます。

ページの同一性と関連性は分けて確認してください。タイトルだけでは、意図したページかどうかを特定できないことがあります。必要に応じて、検索結果のウェブアドレスとリンク先のページを確認します。ページを特定できない場合は、不明と記録してください。

適合参照ページが見つからなかったときに、都合のよい検索結果のページに置き換えて、元の検証を合格にしないでください。新しい参照ページは後から追加できます。変更した参照ページの集合には新しいバージョンを付け、変更内容を説明してください。

3. Googleの文書で検索演算子の動作を確認する

検索演算子とは、検索エンジンに条件の適用を求めるクエリ内の記述です。Googleは、引用符、`site:`、マイナス記号による除外、`before:`、`after:`、`filetype:`を文書で説明しています。使う予定の検索エンジンの文書を確認してください。別の検索エンジンでも同じ構文や動作になるとは限りません。Googleの検索ガイド — 2026年10月25日に取得。演算子が意図する動作の説明であり、本ガイドの検証結果ではありません

演算子と値の間に空白を入れないでください。たとえば、`site:docs.example.com`は続けて書きます。Googleのガイドでは、記号や演算子の語を検索語に続けて書く必要があると説明しています。Googleの構文ガイド — 2026年10月25日に取得。構文の規則は、特定のページが検索結果に出ることを保証しません

日付の演算子は、文書の更新日が重要な場合にのみ使ってください。その検索結果を、初回公開日を検証済みのページ集合として説明しないでください。

適合参照ページを対照例として使う場合には、重要な制約があります。Googleは、`site:`の結果は網羅的ではないと説明しています。インデックスに登録されたアドレスでも、`site:`クエリに出るとは限りません。そのため、適合参照ページが見つからなければ、そのページを含むかどうかの確認は判定不能のままです。インデックスに未登録だという証拠にはなりません。Google Search Centralのガイド — 2026年10月25日に取得。`site:`の結果は網羅的ではなく、インデックス登録数の総数も示しません

4. 1か所ずつ変更したクエリを作る

クエリの変更案とは、検索文の1つのバージョンです。比較する変更案どうしでは、1つの要素だけを変えてください。予想外の結果が出たときに、原因を調べやすくなります。

次の順序が役立ちます。

1. 演算子を付けない語句から始めます。
2. その語句にサイトの限定を加えます。
3. サイトの限定を維持したまま、語句を引用符で囲みます。
4. 調査上の判断に必要な場合にのみ、別の演算子を追加します。

各クエリの全文を保存してください。「サイト検証」のようなメモだけでは、同じ検索を繰り返せません。

比較中は、検索エンジン、国、言語、結果件数の上限、その他の設定を同じにしてください。確認できない設定も記録します。設定を変えた場合は、次の収集を条件が変わった検証として扱ってください。

取得上限とは、実行された各クエリで要求する結果件数の最大値です。実行クエリとは、収集した結果に付随する検索文です。上限を小さくすると、返された各記録を確認できます。一方で、見つからなかったページについて判断できる範囲も限られます。

完全一致の語句は、限定された目的を明確にするのに役立ちます。一方で、有用な別の表現を対象から外すこともあります。2つ目の語句が必要なら、別のクエリとして検証してください。Redditのキーワード検証ガイドでは、有用な表現の変更でも、別の種類の問題を見逃すことがある理由を説明しています。そのRedditでの結果は、Googleの検索演算子を検証するものではありません。

5. 少数の結果を手作業で確認するか、Actorによる収集を計画する

少数のクエリ変更案では、まず手作業で検索し、結果に出た公開ページを確認してください。クエリ、確認できた設定、確認時刻、ページごとのメモを保存します。これにより、クエリの作り方に関する小さな問いに直接答えられます。

検索結果を行単位で保存する必要がある場合、Chronometrica Google Search Scraperの文書に記載されたフィールドが、この方法に適しています。Actorとは、ホスト環境で動くデータ収集プログラムです。Actorは検索記録を提供します。関連性の判断、参照ページとの一致の確認、採用するクエリの選択は、利用者が行います。

提示された少量取得用の入力は次のとおりです。

{"country":"US","engines":["google"],"language":"en","maxResultsPerExecutedQuery":3,"queries":["site:developers.google.com \"site:\""]}

JSONは、名前付きの値やリストを記述するテキスト形式です。この入力では、検索エンジンをGoogle、国を米国、言語を英語に設定し、クエリの取得上限を3件にしています。クエリは、指定したGoogleのドキュメントサイト内で`site:`という語句を検索します。これは出発点となる例であり、特定のドキュメントページが出る証拠ではありません。

サンプルの値は、次の順序で置き換えてください。

1. `queries`内のクエリを、最初に明示した変更案に置き換えます。
2. このGoogleの検証では、`engines`を`["google"]`のままにします。
3. 調査の目的に合わせて、`country`と`language`をそのまま使うか、置き換えます。
4. 最初は`maxResultsPerExecutedQuery`を3に設定します。
5. 収集前に入力の全体を保存します。
6. 同じ設定で、他の変更案を検証します。

確認した取得上限の設定範囲は1〜100です。提示された入力は、静的なスキーマ検証に合格しました。スキーマとは、データのフィールドや値に関する規則の集合です。静的な検証では、収集を実行せずに入力を調べます。実際の結果、網羅性、正常な動作を証明するものではありません。公開のデフォルトビルド1.0.15 — 2026年10月25日に確認。入出力仕様を確認。実際の収集は未実施

Taskとは、Actor用に保存された入力設定です。公開されているMulti-Engine Search Results Scraper Taskを出発点として使えます。そのページと正確なTask IDは確認済みです。現在保存されている設定は検証していません。使う前に設定を確認し、置き換えてください。この例と同じ設定だとは限りません。Multi-Engine Search Results Scraper Task — 2026年10月25日に確認。ページの存在は確認済み。保存済み入力と実行時の動作は未検証

6. 元データのフィールドと自分の検証判断を保存する

元の結果記録と、自分の確認メモは分けて保存してください。確認した製品仕様では、この方法に使える次のフィールドが定義されています。

これらは文書に記載されたフィールドです。本ガイドのために実行して得た出力ではありません。公開のデフォルトビルド1.0.15 — 2026年10月25日に確認。定義された結果フィールドのみを確認。実行時の出力は未検証

スポンサー付きの結果とは、有料の広告結果です。関連性を確認するときも、そのフラグを保持してください。元データの`rank`は、記録された位置として保存します。関連性のスコアとして使わないでください。Bingの順位スナップショットガイドでは、別の作業である順位比較を扱っています。このGoogleの対照例を使った検証では、順位の安定性は測定しません。

自分のシートに、次の確認用フィールドを追加してください。

時刻が欠けている場合は、不明のままにしてください。自分で確認した時刻は、別のフィールドに追加できます。元データから提供された時刻であるかのように、`observedAt`へ入れないでください。

`snippet`がnullであることは、テキストが欠けていることを意味します。リンク先のページが空である証拠ではありません。結果件数が欠けている場合は、不明です。定めた条件での収集で保存された行が0行だったという証拠がある場合にのみ、0と記録してください。

7. 合格・不合格・不明の明確な規則を適用する

適合参照ページの確認と、限定条件の確認を分けてください。

サイトの限定が合格という判断は、確認したサンプルが規則を満たしたことを意味します。今後のすべての結果が規則を満たす証拠にはなりません。

無関係なドメインが出た場合は、構文に原因があると判断する前に、検索結果のアドレスとリンク先を確認してください。収集に失敗した場合は、その失敗と、結果が0件だったという観測を分けて記録します。既知のページが見つからなかった場合は、元の検証を判定不能の状態のまま保存してください。

参照ページが1つ見つからなかったことから、Googleの偽陰性率を計算しないでください。偽陰性とは、定めた測定方法において、関連する項目を誤って除外することです。この小規模な参照ページの確認では、Googleにある関連ページ全体を把握できません。

8. 具体例：判定不能のクエリ変更案は判定不能のまま残す

独自に作成した架空の例です。この例のページ、クエリ結果、件数、判断は、すべて説明のために作ったものです。Actorの実行結果、顧客の成果、実際に観測した企業の調査結果ではありません。

ある調査者は、アクセス設定に関する公開ドキュメントを探しています。参照ページを2つ指定します。

• 適合参照ページ：`https://docs.example.com/guide`。アクセス設定について記載されていることを確認したドキュメントページ。
• 不適合参照ページ：`https://other.example.com/guide`。同じ語句を使っている、無関係なページ。

調査者は3つのクエリ変更案を作ります。各段階で、1つの要素だけを変えます。

この架空の3回の収集はすべて、検索エンジンをGoogle、国を米国、言語を英語に設定し、各クエリの観測件数の上限を3件にしています。観測1件とは、保存した結果記録1件のことです。

この架空の例では、Q1の観測に付けた関連性のラベルは、関連あり1件、関連なし1件、不明1件です。Q2は関連あり1件、不明1件です。Q3は関連あり1件です。

計算は次のとおりです。

• 要求した取得枠：3クエリ × クエリあたり観測3件 = 観測9件。
• 保存した記録：3 + 2 + 1 = 観測6件。
• 関連ありの記録：1 + 1 + 1 = 観測3件。
• 関連なしの記録：1 + 0 + 0 = 観測1件。
• 不明の記録：1 + 1 + 0 = 観測2件。
• ラベル別件数の確認：3 + 1 + 2 = 観測6件。
• 未使用の取得枠：9 − 6 = 観測3件。

この未使用の観測枠3件分は、存在がわかっている未取得ページ3件を意味しません。6件の記録は検索結果の観測であり、6人を表すものではありません。また、必ずしも異なる6ページでもありません。同じ適合参照ページがQ1とQ3に出ています。

この架空のサンプルでは、調査者は、完全一致の語句を探す限定的な作業にQ3を採用します。Q2は、適合参照ページについて判定不能のまま残します。Q3によって、Q2で結果が見つからなかった事実が解消されるわけではありません。この選択は、Q3が一般的に優れていることや、網羅的であることを示しません。