競合ドキュメントの変更履歴を残す方法

1. 購入者の作業を1つ決め、少数のページを選ぶ

まず、購入者が製品で行いたい作業を決めます。たとえば、調査担当者がレポート作成の手順を検討するために、ドキュメントに記載されたエクスポート形式を確認する場合です。関連する箇所を全文確認できる程度に、問いを絞ります。

ページを保存する前に、短い収集計画を書きます。

1. 確認する競合と製品の名前を記します。
2. 購入者の作業を1文で記します。
3. その問いに答えられそうな公式ドキュメントの節を選びます。
4. 製品のバージョン、言語、プランがページに記載されていれば、記録します。
5. 次回の確認日を決めます。
6. どのような変更が購入者の作業に影響するかを記します。

不明なプランやバージョンを「全プラン」や「全バージョン」として扱わないでください。不明と記録します。ヘルプページとリリースノートで記述の性質が異なる場合は、別々に管理します。

選んだページは、ページ台帳で管理します。ページ台帳は、再確認するページの一覧です。関連するドキュメントをすべて見つけたことを示すものではありません。

リダイレクトとは、あるアドレスへのアクセスを別のアドレスへ転送することです。両方のアドレスを記録します。アドレスが変わると、2つの保存内容が同じページのものかどうかの判断に影響する場合があります。

2. 検索でページを探し、直接確認する

公式ヘルプページがすでに分かっている場合は、直接開きます。検索は、候補ページや関連するリリースノートを探すときに役立ちます。検索結果だけでは、保存されたページの履歴は得られません。

Google Search Scraper Actorは、この候補探しの手順に適しています。Actorとは、ホスティング環境で動くデータ収集プログラムです。Taskとは、Actor用に保存した入力設定です。どちらの用語も、このガイドでページの各版を収集したことや、製品をテストしたことを意味しません。

提供された確認結果では、公開デフォルトビルド1.0.15に、以下で使う入出力項目が定義されていました。この小規模な入力例は、定義された入力規則に対する静的検証に合格しました。静的検証は、実行せずに規則との一致を調べる確認です。この資料の作成にあたり、Actorは実行していません。この確認は、実際の結果、網羅性、収集の成功を証明するものではありません。公開デフォルトビルドの根拠（2026年10月25日に確認。定義された項目と入力の静的検証のみ）を参照してください。

小規模に候補を探す際の入力案として、次の例を使えます。

{"country":"US","engines":["google"],"language":"en","maxResultsPerExecutedQuery":3,"queries":["reporting software export release notes"]}

検索語の例を、選んだ競合、製品、購入者の作業に合う語句に置き換えます。別の市場を調べる場合は、国と言語も置き換えます。実行前に入力全体を確認してください。この例では、検索エンジンとしてGoogleを提案しています。ただし、静的検証では、現在の実行時の動作は確認できていません。

結果の上限は、実行した検索クエリごとに3件です。これは上限であり、必ず3件得られるという意味ではありません。この例は、置き換え用の入力案です。検証済みの保存済みTask設定からコピーしたものではありません。

公開されているCompetitor SERP Research Task（2026年10月25日に確認。ページの存在のみ）が存在し、正確なTask IDは`Pjq0JLkzo0wHTcabU`でした。保存済み設定と実行時の動作は未検証です。これを出発点として開き、使用前に設定を確認してください。

結果を収集する場合は、定義されている次の検索項目を残します。

スニペットとは、検索結果に表示される短い文章です。その文面を根拠として使う前に、ページを開きます。ページの根拠を確認するガイドでは、検索結果から情報源の該当箇所を確認する手順を説明しています。

検索結果とともに、検索に使った入力も保存します。同じページが複数の検索クエリで見つかった場合は、それぞれの確認記録を残します。検索結果のエクスポートを統合するガイドでは、検索クエリと順位の根拠を残す方法を説明しています。このガイドで変更を比較する対象は、選んだページと、その保存済みの各版です。

3. 各版を比較する前に、同じページかを確認する

ページの同一性を示す情報とは、保存内容がどの文書のものかを記録した情報です。アドレスだけでは判断できない場合があります。ページがリダイレクトされたり、言語が変わったり、別の製品バージョンのドキュメントが表示されたりするためです。

再訪するたびに、アクセス先アドレス、最終アドレス、ページタイトル、節の見出し、記載された適用範囲を確認します。本文を比較する前に、これらの値の変更を記録します。

以前のエクスポートガイドが新しい総合ヘルプページにリダイレクトされたという理由だけで、その違いを記録せずに比較してはいけません。両方の保存内容を残します。それぞれのページが何の文書かを確認するまでは、比較を未解決と記録します。

同様に、異なる言語や製品バージョンは別々に管理します。調査範囲を変えた場合は、その変更を記録します。対象ページを増やすことは役立つ場合があります。ただし、新たに追加したページの過去のスナップショットが得られるわけではありません。

4. 本文と確認日時を保存する

毎回、関連する公開ページ本文の全体を保存します。購入者の作業に関わる箇所も、正確な文面で残します。スクリーンショットは表示レイアウトの保存に役立ちます。ただし、正確に比較し、引用できる本文も残してください。

記述に付く条件も残します。JSONエクスポートについての記述は、近くにあるプラン制限、製品バージョン、アクセス要件を前提としている場合があります。形式名だけを保存すると、その意味を決める条件が抜け落ちることがあります。

ページの確認1回につき、1件の記録を作ります。

確認日時とページに表示された日付は分けて管理します。保存日時は、その文面をいつ確認したかを示します。表示された日付の意味は、そのページで説明されている範囲に限られます。どちらも、それだけで特定の文が変わった日時を証明するものではありません。

公開された根拠と、自分で作った記録は分けて管理します。公式ページの本文は、公開された情報源です。スナップショット参照ID、保存した写し、確認メモ、購入者の優先事項は、自分で管理する記録です。定義された検索項目だけでは、Actorがこれらの記録を作成するとは確認できません。

新しい保存内容で古い保存内容を上書きしないでください。以前の本文を残さなければ、後から差分を確認できません。

5. 対応する箇所を比較し、文面の違いを分類する

同じページについて、関連する適用範囲が一致し、比較用に採用した2つのスナップショットを比較します。該当箇所の全文を並べて読みます。本文の比較で差分の候補を見つけられますが、各差分は前後の文脈も含めて確認します。

文面の違いを次の種類に分けます。

文面の削除は、機能の廃止を証明しません。文面の追加は、機能の新規公開を証明しません。購入者の作業にとっては、形式の追加記載よりも適用条件の変更の方が重要な場合があります。

確認した期間は、「10月1日と10月8日の保存内容で文面が異なる」のように、分かりやすく記録します。根拠にない正確な編集日に置き換えてはいけません。

差分の候補ごとに、変更記録を保存します。

6. 1つの例で手順を丁寧に確認する

学習用に作成した架空の例です。Actorの実行結果、顧客の成果、実際の企業調査の結果ではありません。以下のアドレス、文面、日付、記録はすべて架空です。

ある調査担当者が、1つのレポート作成手順についてエクスポートのドキュメントを確認するとします。担当者は、架空のページA（`https://example.com/help/exports`）の公開本文全体を、2026年10月1日と10月8日に保存します。どちらの確認時刻も12:00:00 UTCです。UTCは、時刻の基準となる協定世界時です。

2回の保存では、同じページであること、言語、関連する適用範囲が一致しています。担当者は10月8日に、架空のページB（`https://example.com/help/report-formats`）も見つけます。ページBには、以前の保存内容がありません。

この例で保存した、関連箇所の全文は次のとおりです。

CSVとJSONはデータ形式です。この例では、文面の比較を示すためにこれらの形式名を使っています。どちらの形式もテストしていません。

ページAについて、採用した変更記録にはこう記します。「10月1日と10月8日の確認の間に、エクスポートの該当箇所にJSONの記述が追加されている。」新旧両方のページ全文と、両方の該当箇所の正確な文面は、引き続き確認できるように残します。

ページBについては、こう記します。「10月8日の該当箇所にはJSONエクスポートが記載されている。以前のスナップショットはない。」これを、確認できた2件目の変更としては記録しません。

計算では、数える対象を分けます。

• ページAの保存済み確認記録は2件です。ページBの保存済み確認記録は1件です。合計は2 + 1 = 3件です。
• ページAでは、比較できる組が1組あります。ページBは以前の保存内容がないため、比較できる組はありません。
• 比較できる1組から、1ページで文面の変更を1件確認できます。
• ページBには、現時点のみのページ確認記録が1件あります。変更の有無は不明です。

これらは、ページ、保存、比較の数です。顧客数、利用者数、機能の公開件数、エクスポートの成功件数ではありません。ページBの以前の保存内容がないことは、以前のJSONの記述が0件だった根拠にはなりません。

購入者の作業に関するメモには、JSONの記述がエクスポートの検討に影響する可能性があると記します。次の手順は、購入者が必要とする製品の適用範囲で、その機能を検証することです。この記録には、公開日や使用結果の根拠はありません。

7. 確認の失敗や根拠の不足を明記する

確認に失敗したことを、文面が消えたという主張に変えてはいけません。状態を明確に記録し、後から読む人が、どの比較が有効か分かるようにします。

「文面の変更を確認せず」は、確認した箇所と期間に限った記述です。製品全体に変更がなかったという意味ではありません。

日付や文面がない場合は、欠けていることを明記したままにします。0を使うのは、採用した比較が実際に0件という数を裏付ける場合だけです。たとえば、確認を完了した結果として、採用した変更が0件と記すことはできます。後のページ本文がなく、確認できなかった場合には使えません。

確認に失敗した記録も履歴に残します。最後に使えたスナップショットを、空または不完全な保存内容で置き換えないでください。

8. 製品に関する根拠を確認し、報告をまとめる

文面の変更を機能の公開と呼ぶ前に、その主張を裏付ける、日付付きの別の公式情報源を探します。リリースノートは役立つ場合があります。ただし、近くに日付があるだけでは、その機能自体の公開日は確定できません。

購入判断に動作テストの結果が必要なら、必要な製品バージョン、プラン、作業手順で別途確認する計画を立てます。実施するまでは、確認予定と明記します。ドキュメント上の対応と、テストで確認した動作は、根拠の状態が異なります。

購入者の作業を中心に、短い報告をまとめます。まず、確認した文面の差分を記します。次に、ページへのリンク、新旧両方の確認日時、両方の該当箇所の参照先、関連する適用範囲を示します。その文面が判断に影響する可能性がある理由を説明します。最後に、未解決の問いと、次に必要な根拠を記します。

共有する前に、報告を確認します。

1. 保存した新旧両方の版を引き続き参照できることを確認します。
2. 該当箇所が同じページに属し、関連する適用範囲が一致することを確認します。
3. 引用したすべての語句を、保存した本文と照合します。
4. 確認日時は、編集日や公開日として主張する日付と分けて管理します。
5. 現時点の確認しかないページは、根拠のある文面の変更と分けて管理します。
6. 導入状況、性能、事業への影響に関する主張のうち、根拠で裏付けられないものを削除します。