TikTokの欠損データを使う前にプロフィールの状態を確認する

把握済みのプロフィールを使う

Actorは、ホスティング環境で動作するデータ収集プログラムです。Taskは、保存済みの入力設定です。TikTok Channel Scraper Actorは、取得元のデータを行として収集します。そのうち、作業に使える行を決めるのは利用者です。Actorが代わりに判断するわけではありません。

現在の公開TaskはBulk TikTok Profile Scraperです。保存済みのサンプル入力には、2つの公開URLが含まれています。

{
  "startUrls": [
    "https://www.tiktok.com/@mrbeast",
    "https://www.tiktok.com/@nasa"
  ]
}

サンプルURLを、自分が把握している公開プロフィールのURLに置き換えてください。公開Taskは、あくまで入力の出発点です。確認や判断が自動で行われることを示すものではありません。

公開ビルド0.1.27は、2026-10-13に確認されました。この確認日は、各行の記録時刻ではありません。`observedAt`は、取得した行に記録された観測時刻です。値が現時点のものかを判断する際は、`observedAt`を使ってください。

把握済みのプロフィールだけを送信する

入力フィールドは`startUrls`です。把握済みのプロフィールURLまたはハンドルを、1〜1,000件送信できます。ハンドルとは、@記号の後に続く公開名です。すでに把握しているプロフィールを送信してください。

この入力では、ユーザーを検索しません。国を探し出すこともありません。投稿やコメントは収集しません。非公開の連絡先情報は取得しません。ログインもしません。CAPTCHAや認証チャレンジを回避することもありません。

重複する入力文字列の確認は1回だけです。結果の1行は、1件のプロフィールに対する取得の試行を表します。その行が、必ず利用できるプロフィールとは限りません。長いリストを送信する前に、対象のプロフィール1件で実行してください。

最初に確認するフィールド

すべての行で、`input`、`channelId`、`channelUrl`、`handle`、`status`、`statusReason`、`isBillable`、`observedAt`を確認してください。`channelId`は、取得元でそのプロフィールに付けられたIDです。`status`は、その試行における取得元の結果です。`statusReason`には、理由がある場合に、その状態になった理由が示されます。

任意フィールドには、`followersCount`、`bioLink`、`description`、`detectedEmails`、`accountRegion`などがあります。`countPrecision`がある場合は、件数の精度を示します。対象の件数と併せて確認してください。無視してはいけません。

`isBillable`は、行ごとの課金に関するデータです。その行が課金対象になるかどうかを示します。課金対象とは、その行に料金が発生し得るという意味です。このデータは、実際に課金された証拠ではありません。課金の証拠となるのは、課金の領収書です。`isBillable`は、プロフィールが誰のものかを証明しません。すべてのフィールドがそろっていることも証明しません。`billableRows`は、課金対象となる行数です。この件数は、支払いの証拠ではありません。

取得元の各状態は、現在のスキーマに従って保持してください。状態によって、次に取る対応が変わります。

• `ok`は、プロフィールを取得できたことを示します。それでも、識別情報の一致と必要なフィールドの確認は必要です。任意フィールドはnullの場合があります。
• `partial`は、プロフィールを取得できたものの、行のデータが不完全であることを示します。必要なフィールドを個別に確認するまで、行全体を除外しないでください。
• `private`は、非公開部分を引き続き取得できないことを示します。その行を、公開データで値が0だったかのように扱わないでください。
• `login_required`は、取得元がログインを求めたことを示します。処理を止めてください。このActorはログインしません。
• `not_found`は、今回の確認ではプロフィールが表示されなかったことを示します。いつ、なぜそうなったかは分かりません。削除された証拠にはなりません。
• `blocked`は、取得元へのアクセスがブロックされたことを示します。欠損したフィールドを補完しないでください。ブロックされたことを、フォロワー数が0であるという意味に解釈してはいけません。
• `challenge`は、取得元が認証チャレンジを表示したことを示します。認証チャレンジを解かないでください。
• `rate_limited`は、取得元が確認処理に制限をかけたことを示します。行を保存してください。後で1回だけ再確認する計画を立ててもかまいません。繰り返し再試行しないでください。
• `parser_miss`は、確認処理で想定した情報を読み取れなかったことを示します。その情報を作り上げないでください。
• `invalid_input`は、入力形式が無効だったことを示します。間違いを示せる形式だけを修正してください。
• `failed`は、取得元に関する別の理由で試行が失敗したことを示します。理由と時刻を保存してください。欠けている情報を作り上げないでください。

行のデータを利用できないことは、アカウントが削除された証拠にはなりません。フォロワーがいない証拠にもなりません。

1回の検証用実行で確認したことと、確認していないことを知る

現行の0.1.27で行った検証用の実行では、プロフィールを1件使いました。取得した行は、対象の`channelId`と一致しました。対象の`channelUrl`またはハンドルとも一致しました。`followersCount`も一致しました。状態は`ok`でした。

任意フィールドの`commerceCategory`はnullでした。`isCommerce`、`isSeller`、`isPrivate`はfalseでした。nullは、値が提供されなかったことを示します。falseは、取得元が明確に「いいえ」を返したことを示します。falseを欠損に変えないでください。nullをfalseに変えないでください。`isCommerce`のfalseを、nullになっている`commerceCategory`へコピーしないでください。

この検証用の実行では、非公開プロフィールをテストしていません。ブロックされたプロフィールもテストしていません。すべてのプロフィールフィールドがそろうことを証明したわけでもありません。非表示または未取得のメールアドレスを作り出すことはできません。`detectedEmails`がnullまたは空でも、所有者が連絡先を公開していない証拠にはなりません。

実行結果の集計値を自分のリストと照合する

実行のOUTPUTでは、次の名前をそのまま使います。

• `requestedChannels`は数値です。処理した入力の試行回数を表します。この数値は`rows.length`と等しくなります。`rows.length`は、それらの試行を記録した行数です。この数値は、元の管理リストではありません。元の管理リストは利用者が管理します。そのリストは別に保持します。
• `acceptedProfileInputs`は数値です。`rows.length`から`rejectedInputs`を引いた値と等しくなります。
• `rejectedInputs`は数値です。実行時に拒否された入力の件数を表します。無効な入力と未対応の入力は拒否されます。`rejectedInputs`はリストではありません。
• `datasetRows`は、返されたプロフィール行の数です。これらは、プロフィールの取得を試みた結果の行です。
• `usefulRows`は、返された行のうち、Actorが利用可能と判定した行数です。各行を判定するプログラムがActorです。
• `billableRows`は、返された行のうち、課金対象となる行数です。課金対象とは、その行に料金が発生し得るという意味です。この件数は、支払いの証拠ではありません。
• `nonUsefulRows`は、返された行のうち、利用できない行の数です。
• `statusCounts`は、返された行を状態ごとに数えた件数です。`datasetRows`と`statusCounts`は、返された行を表します。元の管理リストを表すものではありません。

`datasetRows`は、確認済みでデータがすべてそろったプロフィールの件数ではありません。実行が完了しても、取得に失敗した対象が含まれることがあります。利用可能とされた行でも、作業に必要なフィールドが欠けている場合があります。課金対象の行でも、任意フィールドが欠けている場合があります。行の内容を確認してください。合計だけで判断を終えないでください。

作業に必要なフィールドを明示する

一部しか取得できていないプロフィールを除外する前に、次の作業に必要なフィールドを一覧にしてください。不要なフィールドはnullのままでもかまいません。必要なフィールドは、その行を採用する前に値がそろっていなければなりません。

必要なフィールドごとに、取得元の値と、取得状況を表す状態を1つ保存してください。状態は、取得元に実際の根拠がある場合だけ使ってください。

• `present`は、値が返されたことを示します。falseも値が存在する状態です。0を値が存在する状態として扱えるのは、取得元が0を返した場合だけです。
• `explicitly_empty`は、取得元が空のリストなど、空の値を返したことを示します。
• `absent_or_unavailable`は、フィールドがnullであるか、その行では値を取得できなかったことを示します。
• `not_requested`は、この作業ではそのフィールドを使わないことを示します。

空のリストはnullと同じではありません。nullは不明を意味します。不明な値を0として保存しないでください。

これは利用者が作成する記録です。Actorの出力行ではありません。

field: followersCount
source_value: null
availability: absent_or_unavailable
observedAt: the time on that source row

各プロフィールをこの順序で確認する

1. 把握済みのプロフィールをまとめた元の管理リストを保持してください。管理リストとは、手元で管理するリストです。各行に固有のローカルキーを付けてください。返された状態を確認してください。非表示のメールアドレスを取得できると約束してはいけません。ブロックを回避する方法を約束してはいけません。取得元に関するすべての失敗を修復できると約束してはいけません。同じ入力文字列の確認は1回だけです。管理リストの件数と、重複を除いた試行回数は異なる場合があります。ローカルキーによって、管理リストの各行と正しい観測記録との対応を保てます。
2. 最初に、対象のプロフィール1件で実行してください。返された識別情報、状態、`observedAt`を確認してください。`channelId`がある場合は確認してください。対象のハンドルとURLも確認してください。見覚えのある表示名だけを根拠に、間違った対象のデータを修正することはできません。まず識別情報を照合してください。この記事では、同じクリエイターが使う別の名前を統合する方法は扱いません。識別情報が一致した後で、そのデータを使えるかどうかを利用者が判断します。
3. 問題を示す状態と、空のフィールドを区別してください。状態が`ok`または`partial`で、識別情報が一致していても、任意フィールドの`bioLink`がnullの場合があります。そのプロフィールは、それでも利用できる場合があります。`blocked`、`challenge`、`login_required`は、取得元へのアクセスが許可されなかったことを示します。`private`は、非公開部分を引き続き取得できないことを示します。`not_found`では、プロフィールがいつから表示されなくなったかは分かりません。理由も分かりません。
4. 必要なフィールドを個別に判断してください。取得元の値と取得状況を保存してください。falseはfalseのまま保持してください。nullは不明のまま保持してください。空のリストはnullと区別してください。作業に不要なフィールドには`not_requested`を使ってください。使う予定のないフィールドを理由に、そのプロフィールを不適格としないでください。
5. OUTPUTを管理リストと照合してください。`acceptedProfileInputs`を、重複を除いた入力件数と照合してください。取得を試みた結果の行数を`datasetRows`と照合してください。`usefulRows`、`nonUsefulRows`、`rejectedInputs`、`statusCounts`も確認してください。`datasetRows`を、データがすべてそろったプロフィールの件数として報告してはいけません。`billableRows`に、すべての任意フィールドが含まれていると思い込まないでください。
6. 重複を除いた各試行に、次の状態を1つ選んでください。識別情報が一致し、必要なフィールドがすべて存在する場合は`accepted_for_required_fields`を使います。識別情報は一致していても、必要なフィールドが欠けている場合は`useful_but_required_gap`を使います。取得元から利用できるプロフィールが返されなかった場合は`source_unavailable`を使います。ID、ハンドル、URLが対象のプロフィールと一致しない場合は`identity_mismatch`を使います。入力形式自体が間違っている場合は`invalid_input`を使います。無効だと示せる形式だけを修正してください。取得元に関する失敗であれば、後で計画的に1回再確認する理由になります。繰り返し再試行する理由にはなりません。認証チャレンジを解く理由にもなりません。観測記録と一緒に`observedAt`と`statusReason`を保持してください。
7. 後日更新するときは、取得元での識別情報と必要なフィールドを同じにしてください。古い行には値があっても、新しい行を取得できなければ、現在の観測値はありません。古い値は履歴です。その日付を保持してください。現在の値は不明と記録してください。古い値を現在の値として引き継がないでください。0に変えてもいけません。この変化を、件数が0まで減少したものとして報告しないでください。
8. 取得状況のレポートを作成してください。各プロフィール、必要なフィールド、未解決の状態をすべて記載します。行を使えるのは、その作業に必要なフィールドがそろっている場合だけです。収集できなかったことと、所有者についての主張を区別してください。取得できなかったからといって、所有者にその情報がないとは限りません。所有者のアカウントが、その種別に該当しないという意味でもありません。

採用、一部利用、再確認、要確認を選ぶ

次の状態は、データがどのような状況にあるかを示します。利用者の判断は、取るべき対応を示します。採用、一部利用、再確認、要確認の4つから1つを選んでください。

再実行を考える前に、その行を要確認リストに入れてください。`rate_limited`や`failed`など、取得元に関する失敗では、後日の再確認が認められます。その再確認で認証チャレンジを解いてはいけません。ログインしてもいけません。非公開プロフィールを開くために使ってもいけません。このActorは認証チャレンジを解かないため、`challenge`は要確認のままにします。このActorはログインしないため、`login_required`も要確認のままにします。`private`のデータは引き続き取得できません。2回目の呼び出しで、非公開データが公開データになるわけではありません。

独自に作成した架空の例で判断を学ぶ

この節の表と件数は、説明のために独自に作成した架空のものです。製品の実行結果ではありません。実際の成功率を示すものでもありません。

架空の管理リストには、手元で管理する5行があります。

R1とR2は、同じ入力文字列を使います。確認処理は、その文字列を1回だけ受け付けます。それでも、5つのローカルキーは保持します。この実行では、重複を除いた4件の試行が受け付けられ、状態を記録した4行が返されます。この架空の例の`acceptedProfileInputs`は4です。この例には、拒否された入力は登場しません。実際の実行では`rejectedInputs`も数値として返されるため、その件数も確認する必要があります。

架空の状態記録は、次のとおりです。

この架空の作業には、2つの要件があります。`channelId`が対象のプロフィールと一致していること。現在の`followersCount`が存在することです。

R1は、両方の条件を満たします。IDはID100です。現在のフォロワー数は1,000なので、その値は存在します。`bioLink`はnullです。この作業では`bioLink`は不要なので、nullのリンクは不明のままにします。リンクを作り上げてはいけません。R1は、この作業で採用できる、重複を除いた唯一のプロフィールです。利用者の判断は「採用」です。

R2は、2人目のクリエイターではありません。R1と同じ入力であり、同じ観測記録に対応します。管理リストで重複を説明できるように、R2のキーを保持してください。R2を、さらに1,000人のフォロワーを持つ別のプロフィールとして数えてはいけません。

R3はID200と一致するため、識別情報に問題はありません。状態は`partial`です。フォロワー数はnullです。nullは0ではなく、この作業にはその件数が必要です。自己紹介のリンクは存在しますが、欠けているフォロワー数の代わりにはなりません。R3は`useful_but_required_gap`です。利用者の判断は「一部利用」です。R3は保持し、現在のフォロワー数が必要な作業には使わないでください。取得元で利用可能とされた行でも、利用者自身のフィールド要件を満たさないことがあります。

R4の状態は`private`です。必要な情報は利用できません。R5の状態は`blocked`です。こちらも必要な情報は利用できません。どちらも`source_unavailable`です。利用者の判断は「要確認」です。どちらの行も、アカウントが削除されたと解釈してはいけません。フォロワー数が0だと解釈してもいけません。この架空の例では、R4とR5の`channelId`は示されていません。作り上げないでください。

この架空の例の`statusCounts`は、4行に対応して、`ok`が1件、`partial`が1件、`private`が1件、`blocked`が1件です。この4行が`datasetRows`なら、件数は4回の試行を表します。それでも、データがすべてそろったプロフィールが4件あるという意味ではありません。IDと現在のフォロワー数の条件を満たすプロフィールは、重複を除いて1件です。R3の1行には、必要なフィールドの欠損があります。R4とR5の2行は利用できません。4回の試行で1件のプロフィールを採用できたという例を、実際の成功率に置き換えてはいけません。

ID100に対する架空の2回目の観測では、`blocked`が返されたとします。以前のフォロワー数1,000は保持してください。以前の観測記録の日付も保持してください。現在の件数は不明です。0と報告してはいけません。100%減少したと報告してもいけません。以前の1,000は履歴です。現在の件数ではないため、現在の値として引き継いではいけません。

falseとnullを区別するために、もう1組の架空の例を使います。ある`isSeller`の値がfalseなら、値は存在します。取得元が「いいえ」と答えたということです。別の`isSeller`の値がnullなら、不明です。「いいえ」を意味するわけではありません。この架空の例のどの状態も、所有者が連絡先を公開していない証拠にはなりません。

プロフィールデータの採用判断という範囲を守る

この記事で扱うのは、プロフィールデータを採用する方法だけです。識別情報、状態、時刻、作業に必要なフィールドを確認します。そのうえで、行を採用する、一部利用として保持する、1回の再確認を計画する、要確認とする、のいずれかを選びます。

アカウント種別によるプロフィールの分類は、別の作業です。フィードバックも別の作業です。過去の投稿数も別の作業です。この方法では、非公開プロフィールを収集しません。フォロワーのリストは返しません。連絡先を探し出すこともありません。成長の履歴を作成することもありません。現在の値が欠けているのは、今回の確認で取得できなかったということです。変化を測定した結果ではありません。