特定済みのSnapchat Spotlightで自分のコメントへの直接の返信を探す方法

1. Spotlightと自分のコメントを確認する

読者が知りたいのは、Snapchat Spotlightに自分が残したコメントへの返信をどう探すか、という実用的な方法です。提供された読者の公開質問（2026年8月11日取得、質問は1件のみ）でも、この点を直接尋ねています。この質問だけでは、同じ問題を抱えるユーザーの人数は分かりません。

特定済みのSpotlightを開いて自分のコメントを見つけられる場合は、そこから始めてください。関連する公開のやり取りを読みます。返信の意味を理解したい場合や、返信するか判断したい場合は、手作業での確認が役立ちます。すでに場所が分かっているやり取りを読むだけなら、データを書き出す必要はありません。

書き出したデータを検証するには、収集前に次の条件を確認してください。

1. 公開SpotlightのウェブアドレスであるURLを保存します。
2. 自分のコメントの正確なIDを保存します。
3. そのコメントが目的のSpotlightに属することを示す証拠を保存します。
4. そのコメントが自分のアカウントのものであることを示す証拠を保存します。

検証済みのレコードがすでにある場合は、それを使ってください。このガイドでは、不明なコメントIDを通知から取得する方法は確認できていません。また、文書に記載のないSnapchatの画面の操作方法も説明していません。

文面が似ているだけでは、自分のコメントだと特定できません。表示名だけでも不十分です。保存した証拠で対象を特定できない場合は、その対象の検索を中止してください。行数を増やしても、未確認の対象を確定することはできません。

公開コメントのレコードは、所有者だけが閲覧できるレコードとも異なります。文書に記載されたツールは、外部から閲覧できる公開コメントと返信を収集します。その仕様では、非公開メッセージや通知は提供されません。公開データの書き出しを、自分のアカウントの非公開の活動を複製したものとして扱わないでください。Actorの公開仕様（2026年10月25日確認、文書に記載されたフィールドのみ）。

2. 必要に応じて小規模な公開データ収集を設定する

Actorは、ホスト環境で動くデータ収集プログラムです。Chronometrica Snapchat Comments Scraperには、特定済みの公開SpotlightのURLを入力できます。`includeReplies`設定を使うと、公開の返信を個別の課金対象の行として取得するように指定できます。初期値は`false`なので、この方法では`true`に設定してください。公開入力仕様（2026年10月25日確認、実行テストなし）。

提供された次の入力形式を使ってください。

{
  "includeReplies": true,
  "startUrls": [
    "https://www.snapchat.com/@mrbeast/spotlight/W7_EDlXWTBiXAEEniNoMPwAAYbHZzZmtrYm1jAZhMOQmTAZhMOQfqAAAAAQ"
  ]
}

サンプルのアドレスを、特定済みの公開SpotlightのURLに置き換えてください。このサンプルは、有効な入力形式を示しています。自分の投稿を特定するものではなく、そこに自分のコメントがあることも示していません。このガイドのための収集は実行していません。

まず投稿1件から始めてください。確認した公開入力スキーマには、投稿ごとの行数上限を指定する入力項目がありません。スキーマとは、使用できるフィールドとその型を定めたものです。行数上限は、投稿1件から取得するレコード数の最大値を指定するものです。スキーマに記載のない入力フィールドを追加しないでください。

実行する前に、利用できる支出管理の設定を確認してください。書き出したレコードとともに、実際に指定した入力内容をそのまま保存します。これにより、すべての返信を取得できたと示すことなく、何を要求したかを記録できます。

Taskは、保存した入力設定です。公開のSnapchat Spotlight Comments and Replies Task（2026年10月25日確認、ページの存在のみ）があります。保存された設定はログイン済みのアカウントでは確認しておらず、実行もしていません。使用前に入力内容を確認してください。

3. 各返信の確認に必要なフィールドを保存する

行とは、書き出したファイル内の1件のレコードです。分類する前に、元の行を保存してください。各行を、収集対象の投稿と正確な親コメントに結び付けられるだけの情報を残します。

親コメントとは、その返信が直接返答しているコメントです。深さは、やり取りの中でコメントがどの階層にあるかを表します。深さは文脈を理解する手掛かりになりますが、対象への直接の返信かどうかは親IDで判断します。

現在の出力仕様には、次のフィールドが記載されています。仕様に記載されていても、実際の個々の収集で、文脈を理解するための情報がすべて得られるとは限りません。公開出力仕様（2026年10月25日確認、文書に記載された出力のみ）。

投稿時刻と観測時刻は、それぞれ別の問いに答える情報です。前者は、コメントがいつ投稿されたかを示します。後者は、レコードがいつ確認されたかを示します。投稿時刻が欠損していても、観測時刻で置き換えないでください。

欠損値とゼロを区別してください。親IDの欠損は、親コメントとの関係が確認できていないことを意味します。親コメントが存在しないという意味ではありません。件数が欠損している場合、その件数は不明です。記録されたゼロは数値です。

対象ID、判定、理由、出典参照の列を自分で追加しても構いません。自分の確認用フィールドだと分かるようにしてください。これらはActorが標準で出力するフィールドではありません。出典参照では、元の書き出しファイルの行を特定できるようにし、その公開投稿へのリンクも残してください。コメントへの直接のURLを作り上げないでください。

4. 既知のコメントIDを1つの索引にまとめる

索引は、レコードを探すための表です。ここでは、既知の各`commentId`を保存済みのレコードに結び付けます。同じレコードを繰り返し確認した場合は、別の観測ログに残してください。観測とは、読み込んだファイル内でレコードを1回確認することです。

次の手順で進めてください。

1. 返された投稿の識別情報が、目的のSpotlightと一致することを確認します。
2. 重複を除いた各コメントIDを、索引に1回ずつ記録します。
3. 読み込んだ各観測を観測ログに保存します。
4. 繰り返し観測したレコードを、索引の既存の項目に結び付けます。
5. 保存済みの検証された対象コメントと、その特定に使った証拠を残します。
6. 必要な識別情報や親コメントとの関係を証明できないレコードは、保留にします。

繰り返しの観測を、追加の返信として数えないでください。同じ返信がファイル内に2回現れても、重複を除いたコメントIDは1件のままです。

後から書き出したデータが公開のやり取りの一部しか含まない場合、対象コメントがそこにないこともあります。含まれていないというだけでは、保存済みの特定結果を否定できません。以前に検証したレコードとその証拠を残してください。重要なのは、対象を引き続き確実に特定できるかどうかです。

収集対象の投稿、重複を除いた行、読み込んだ観測を分けて管理する、より広い例については、TikTokコメントデータセットガイドを参照してください。そこで扱う製品設定はTikTok用です。その設定を今回のSnapchatの入力にコピーしないでください。

5. 正確な親IDで返信を採用する

候補となるすべてのレコードに、同じ判定基準を適用してください。まずSpotlightを確認します。次に親IDを確認します。最後に、採用したコメントIDが結果内で重複していないことを確認します。

これらは、読者が確認時に行う判定です。Actorの`status`フィールドに使う値として文書に記載されたものではありません。

深さ1だけで絞り込まないでください。自分のコメント自体が、すでに下位の返信である場合があります。その場合、自分への直接の返信は、さらに深い階層にあります。それでも、正確な親子関係を使えば正しく特定できます。

行の順序、似た文面、近くにある表示名から親コメントを推測しないでください。表計算ソフトでは、関係のないレコードが隣に並ぶことがあります。その位置だけでは、やり取りのつながりは証明できません。

Facebookの未回答質問ガイドでは、スレッド内に質問がある場合に、コメント間の正確な関係がなぜ重要かを説明しています。そのガイドの、ブランドからの回答を確認する手順は、別の目的のためのものです。ここでは、観測したレコードのうち、自分の検証済みコメントへの直接の返信がどれかだけを判断します。

構造上の一致だけでは、内容の意味も確定できません。どう返信するかを決める前に、本文と関連する公開のやり取りを読んでください。この方法は、レコード間の関係を特定するものです。返信の意味を自動で解釈したり、返信を投稿したりするものではありません。

6. 独自に作成した架空の例で確認する

独自に作成した架空の例です。この例では架空のIDを使っています。実際に収集したSnapchatのデータや、非公開のアカウントデータは含みません。自分で作る確認表を説明する例であり、実行時に検証した出力ではありません。

特定済みのSpotlightをS1とします。自分のものだと確認済みのコメントはT2です。その親はROOTで、深さは1です。ROOTは、この例の中で作った架空のコメントIDです。

以下の行はすべてS1に属します。この架空の演習では、各行がその投稿に属することを確認済みとします。

M1の深さの欠損は、この架空の例における確認用レコードの不完全さを表しています。現在の出力スキーマが、深さにnull値を許容するという主張ではありません。そのスキーマでは、`depth`を整数と定義しています。

R1とR2は親がT2なので採用します。深さが2でも、直接の返信であることに変わりはありません。D1はR1の下にあるため、下位のやり取りとして文脈を補います。O1は別の返信系統に属します。

深さ1で絞り込むと、直接の返信を2件とも見落とします。また、T2への返信ではないO1が含まれてしまいます。このため、採用するかどうかは親IDで判断します。

次に、読み込んだファイルにR1の重複がもう1件あるとします。両方の合計を示してください。

読み込んだ観測 7 件 − 重複した観測 1 件 = 重複を除いたコメントID 6 件。

重複を除いた6件のIDを分類します。

対象 1 件 + 直接の返信 2 件 + 下位の返信 1 件 + 別の返信系統の行 1 件 + 未解決の行 1 件 = 重複を除いたコメントID 6 件。

直接の返信の結果は、R1とR2という、重複を除いた2件のコメントIDです。2人という人数ではありません。この演習では、投稿者が別人かどうかは確認していません。

R1とR2を、元の行への参照と特定済みのSpotlightへの参照を付けて提出してください。D1は下位のやり取りとして保存します。O1は別に保存します。M1は未解決のままにします。T2を特定できない場合は、検索全体を保留にしてください。

7. 結果を確認し、その限界を明記する

表を確定する前に、次の確認を済ませてください。

1. 対象IDが、保存した特定のための証拠と引き続き一致していることを確認します。
2. 採用した返信のすべてが、目的のSpotlightに属することを確認します。
3. 採用したすべての`parentCommentId`が対象IDと一致することを確認します。
4. 採用した各`commentId`が結果に1回だけ現れることを確認します。
5. 採用した各返信に、元の行への参照があることを確認します。
6. 保存した同じ書き出しファイルをもう一度読み込み、新たなコメントIDが増えないことを確認します。
7. 下位のやり取り、別の返信系統、未解決の行を分けて保存します。

再読み込みでは、同じファイルの処理を確認します。これは提案する検証手順であり、このガイドのために実施したテストではありません。新たに実際の収集を行っても同じレコードが返されることを示すものではありません。

重複を除いた返信のうち、確認を通過するものがなければ、「この確認済みファイルで採用した直接の返信は0件」と報告してください。「誰も返信していない」とは報告しないでください。公開で閲覧できる範囲から、返信の全件が得られるとは限りません。

必要な親の値が欠損している場合は、その行を未解決のままにしてください。対象自体を確認できていない場合は、検索が未解決だと報告します。これらの状態は、観測した件数がゼロであることとは異なります。

提出時の説明には、特定済みのSpotlight、検証済みの対象ID、観測時刻、読み込んだ観測の件数、採用した直接の返信の重複を除いた件数を記載してください。未解決のレコードと、公開で閲覧できる範囲の制約も明記します。返信件数のフィールドは、実際の返信レコードを検証して作ったこの一覧の代わりにはなりません。