AとBの二行を用意する
Aはtransit、Bはhousingとし、どちらもurbanplanningを対象にします。Aは https://api.subredditdata.com/v1/search?q=transit&subreddit=urbanplanning&limit=3、Bはqだけをhousingに変えます。これは検索案であり、特定の記録が存在するという主張ではありません。表の上に「取得した文章は交通アクセスと住宅をどう結び付けているか」と問いを書きます。
手元の表に、エンドポイント、subreddit、qの全文、kind、from、to、min_score、limit、読んだページ、取得時刻、成功や不明の結果を記録します。話題以外の条件は同じにし、使わないフィルターも省略と明記します。この表は利用者の作業記録であり、APIが作成する分析レポートではありません。
日付を使うかどうかも記録する
日付はcreated_utcに対してYYYY-MM-DD、UTCで指定します。from=2026-04-01、to=2026-04-30なら四月の全暦日が境界ですが、四月の完全収録を意味しません。toを今日にしても23:59:59までを含み、送信時刻で切りません。日付を合わせても、話題ごとに異なる収録漏れは解消しません。
日付で絞らない場合は、両方の行に省略と記します。housingの結果を見た後、その行だけ期間を狭めて元の比較と混ぜないでください。問いを変えるなら新しい二行を作り、以前の条件を残します。
語とページ制限が選ぶ範囲を読む
qはtitleとtextを検索し、複数の解析済み語を一致するフィールド内でANDとして扱います。語を加えることは別候補を増やすことではなく、完全一致のフレーズ保証でもありません。なぜその語を選んだか残します。交通の文章にtransitがない場合もあるので、該当なしから話題の不在を証明しないでください。
_doc順は日時順や関連度順ではなく、min_scoreは正しさを選ぶ条件ではありません。最大100件と100ページの制限があるため、同じページ数は同じ努力量のルールにすぎません。eq、gte、unknownも応答の件数関係であり、代表性ではありません。保存後の日付順ソートも、欠けた履歴を補いません。
共通の記録に二つのラベルを付ける
実際の文章ごとに、実務的な疑問、提案、不明な文脈を手元で注記します。駅近くの住宅についての記録は二つの検索に重複するかもしれません。信頼できる識別子があれば重なりの確認に使い、識別子がないことを一意性の証拠にしないでください。記録の数を参加者数と同一視せず、重複を含む合計を独立した意見の数にしないようにします。
駅近くの住宅という仮の注記なら、手元の記録参照は一つにして二つの話題ラベルを付けます。実務上の疑問、提案された答え、分類した理由を別の欄に残してください。例を完成させるために架空の文をアーカイブからの引用として使わないでください。適切な文章が届かなければ、その欄は空のまま実際の結果を記録します。
任意のフィールドは欠けることがあります。parent_idやlink_idで手元の関連付けはできますが、会話全体や親の存在は保証されません。分類不能の欄と理由を残し、欠けた発言を推測で埋めないでください。感情、属性、話題の重要度はAPIの測定結果ではなく、注記を付けた人の解釈として扱います。
比較メモと次に読む問いを残す
読んだ件数、重複件数、除外した件数、不明な件数を明記します。文章の違いを説明し、全員の好み、コミュニティの成長、関心の低下、統計的に有意な変化とはしません。同じ条件の再検索でも記録は変わり得ます。保存した応答は解釈の根拠を示しますが、アーカイブの不変性は証明しません。
成功した取得は空でも一クレジットで、返答紛失後の成功した再試行は追加料金になり得ます。手元での再読や分類変更はAPIを呼びません。得られる有用な成果は、次に読むべき問い、文脈を伴う例、不足情報の一覧かもしれません。検索で多く出た語をコミュニティ全体の重要話題ランキングに置き換えないでください。
メモと一緒に条件表と取得済みの応答を保管すれば、同僚はAPIキーを受け取らずに同じ根拠を確認できます。追加ページで新しい例が見つかっても、読む量をそろえることと収録範囲が等しいことは別です。続ける前に、どの不足情報を補いたいか言葉にしてください。
