固定トピックパネルでTikTokのトレンドを見つける

検索入力と予備検証の範囲を定める

現在公開されているTikTok Searchのビルド1.1.5は、次の標準入力をそのまま受け付けます。`queries`（文字列の配列）、`expandQueries`（真偽値）、`maxExpandedQueries`（整数）、`maxResults`（整数）、`resultsPerQuery`（整数）、`maxPagesPerQuery`（整数）、`searchDistribution`（"balanced"または"sequential"）です。`maxResults`フィールドは、全クエリを通して保存する動画数の上限を、重複を除いて設定します。`resultsPerQuery`フィールドは、検索語ごとに保存する動画数の上限を、重複を除いて設定します。ただし、検索配分をbalancedにすると、検索語ごとの実効上限がこれより少なくなる場合があり、検索語間での再配分も保証されません。

最初の予備検証では、保存済みのデフォルト入力値（`queries`は3件のサンプルクエリの配列、`expandQueries`はtrue、`maxExpandedQueries`は10、`maxResults`は150、`resultsPerQuery`は30、`maxPagesPerQuery`は2、`searchDistribution`は"balanced"）を変更し、`queries`配列には目的のクエリを1件だけ入れます。範囲を限定するため、設定を次の値に上書きします。`expandQueries`はfalse、`maxExpandedQueries`は0、`maxResults`は2、`resultsPerQuery`は2、`maxPagesPerQuery`は1、`searchDistribution`は"balanced"です。

標準の検索出力には、`postId`、`postUrl`、`authorId`、`profileHandle`、`publishedAt`、`query`、`rootQuery`、`querySource`、`pageIndex`、`pageRank`、`status`、`statusReason`、`observedAt`が含まれます。`queryPlans`などの出力フィールドが示すのは、予定されたクエリとソースだけであり、クエリごとの実際の実行結果ではありません。読者は、実行の証拠に基づいて検索試行の台帳を別途作成する必要があります。"python tutorial"を使った対照実行では、メタデータが二行返され、`max_results_reached`で停止しました。公開日は五月と八月でした。この結果は、基本的な検索フィールドの出所を確認するものですが、実際のキャンペーン、トレンドスコア、自動日付フィルターを裏付けるものではありません。

出力レコードには、収集に関するメタデータとして、queriesSearched、queryPlans、maxResults、resultsPerQuery、effectiveResultsPerQuery、maxPagesPerQuery、searchDistribution、rowsSaved、fieldCoverage、candidateItemsSeen、rowsAddedBeforeGlobalDedupe、duplicatesSkipped、invalidCandidatesSkipped、stopReason、sourceStatusCounts、status、statusReasonが含まれます。queryPlansフィールドは予定された検索語とソースの概要を示しますが、クエリごとの成功・失敗の結果は記録しません。読者は、収集した出力に基づいて検索試行の台帳を自分で管理する必要があります。

結論と、トレンド候補を見つけるための全手順

対象トピックを固定した検索パネルで候補を収集し、繰り返し観測しながら公開日、関連性、クリエイターの広がりを確認します。新たに見つけた動画は、公開時刻を確認するまで、新たな観測として扱います。得られるのはトピックの検討用一覧であり、プラットフォーム全体のトレンドランキングや拡散予測ではありません。

1. 収集を始める前に、トピックについて何を判断するかと、最近の公開とみなす期間を定めます。たとえば、ある形式を次の制作サイクルで小規模な独自テストに使う価値があるかを検討します。事前に明示したクエリ群と収集予算を厳密に維持してください。あるサンプルが魅力的に見えるからといって、途中で検索語を変えてはいけません。読者自身のフィードと、ログアウトした状態での公開検索では、表示対象を選ぶルールが異なります。
2. 保存済みTaskに設定されている無関係で広範なトピックを、目的のパネルに置き換えます。最初に同じ検索をそのまま繰り返す際は、クエリ拡張を無効にします。関連検索を意図的に含める場合は、元のクエリごとのクエリ群を明示します。標準の検索入力には日付フィルターがありません。最近の投稿を対象に含めるかどうかは、収集後に読者がpublishedAtとソースの証拠を確認して判断するものであり、Actorが日付フィルターを提供すると約束しているわけではありません。
3. 試行したクエリ、ソースごとの結果、上限を突き合わせます。投稿IDとURL、投稿者ID、公開日、observedAt、手作業によるトピック・形式の分類コードを保存します。古い投稿が返された場合でも候補は得られますが、最近の期間に関する問いには答えられない場合があります。今回確認した対照実行の公開日は数か月前だったため、現在のトレンドの証拠にはなりません。
4. observedAtとpublishedAtを区別します。初回観測とは、その時点で読者がこのパネル内で投稿を見つけたことを意味します。その時点で投稿が公開されたことや、それまでTikTokで知られていなかったことを意味するわけではありません。公開日が不明な投稿は、確認するまで不明のままにし、最近の投稿だけを厳密に数える集計からは除外します。収集日を公開日として扱ってはいけません。
5. トピックとの関連性と公開対象期間について、同じルールを手作業で適用します。広範なハッシュタグだけで判断せず、実際の公開動画を見て形式を確認します。元の分類と文脈を保存します。判明している投稿IDの種類数と、判明しているクリエイターIDの種類数は別々に数えます。1つのアカウントによる関連動画が5本あっても、IDが判明しているクリエイターは1人です。クリエイターIDが欠損しているものは未解決として別扱いにし、すべて同じ1人のクリエイターとして扱ってはいけません。
6. 持続性の証拠が必要な場合は、明示したパネルを後の時点で再実行し、その時刻を記録します。スナップショットとは、ある1時点で行ったパネルの1回の実行と定義します。各スナップショットと、ソースごとの停止状況を保存します。対象条件を満たしたサンプル内で、新たに観測したID、繰り返し観測したID、クリエイターの広がりを比較します。検索の変更、上限、削除、表示の可否によって、得られる集合は変わり得ます。公開検索を繰り返しても、プラットフォーム全体での増加や最初の発見を証明することはできません。スナップショットの取得に失敗した場合、実行間の比較はできません。
7. 明示した編集上のルールに従って、insufficient_evidence、repeated_multi_creator_candidate、ready_for_small_original_testなどのトピックの状態を設定します。たとえば、詳しい検討に進む前に、比較に使える2回のスナップショットで、少なくとも3人のIDが判明しているクリエイターによる、関連性のある最近の動画を確認するという条件を設けます。これは読者が設定する基準であり、公式なトレンドの定義や、精度を較正した予測ではありません。1回でもスナップショットの取得に失敗した場合は、比較を保留します。
8. 候補を1つ選び、広告クリエイティブを人の目で確認して、小規模な独自テストを行います。その候補が対象読者に合う理由と、まだ不足している証拠を記録します。公開再生回数は背景情報にはなりますが、公開からの経過時間、クリエイターの規模、表示のされやすさはそれぞれ異なります。部分的な検索結果を合計してプラットフォーム全体の人気を推定したり、将来のリーチを予測したりしてはいけません。

繰り返し観測するパネルの独自の架空例

以下の候補一覧には、説明用に独自に作成した架空のデータを使っています。最近の公開とみなす期間を厳密に定め、2026年10月6日00:00 UTC以上、2026年10月13日00:00 UTC未満とします。

共通集合には、両方のスナップショットで対象条件を満たした集合に含まれる候補の投稿IDが入ります。和集合には、いずれかのスナップショットで対象条件を満たした集合に含まれる候補の投稿IDが入ります。この観測例の共通集合は{V2, V3}で、繰り返し観測された投稿IDは2件です。和集合は{V1, V2, V3, V6}で、IDが判明している3人のクリエイター（A、B、C）による、対象条件を満たす動画が重複を除いて4本あります。V6を初めて観測したのは10月13日のスナップショットS2ですが、実際の公開日は10月11日です。V6を10月13日公開と記載してはいけません。

検討結果の台帳

個々のスナップショットの*それぞれ*に、IDが判明している異なるクリエイターが3人必要という厳密なルールでは、S1のクリエイターが2人しかいないため、トピックの状態はinsufficient_evidenceになります。複数のスナップショットの和集合で、重複を除いて3人のクリエイターがいればよいという、より緩やかな基準を使う場合、状態はready_for_small_original_testになります。どちらの基準も、大規模な拡散や、トレンドとして自動判定されることを保証しません。