ChronometricaとNoviを比較：TikTokプロフィールの項目とActorイベント料金

アプリケーションに必要な項目から始める

各プロフィールを使って、アプリケーションが何をする必要があるかを書き出します。次に、その処理に必要な項目を挙げます。こうすると、明確な要件に沿って比較できます。

架空のプロフィール名簿では、ハンドル、表示名、プロフィールURL、説明文、フォロワー数が必須項目になるかもしれません。保存済みレコードを更新する処理では、識別用の項目、観測時刻、明確なステータスも必要かもしれません。これらは要件の例です。両サービスが同じ値を提供することを示すものではありません。

必須項目と、あると便利な追加項目を分けてください。必須項目がないと、必要な処理を実行できません。追加項目は補足情報になりますが、なくてもその処理は実行できます。料金差を見る前に、この区別をしてください。そうしないと、価格の安さによって、不完全な結果でも十分だと思えてしまうことがあります。

必須項目ごとに、次の3点を記録します。

1. 意味：その項目は、どのような事実を表す必要がありますか。
2. 受け入れルール：アプリケーションは、どのような値を使用できますか。
3. 欠損値のルール：事実が不明な場合、どのように処理する必要がありますか。

項目名だけで判断しないでください。似た名前の2つの項目が、異なる事実を表したり、異なる形式を使ったりすることがあります。どちらの項目も、保存先のレコードに対応付ける前に、文書に記載された意味を確認してください。

何をもって有用な結果1件とするかも定義します。アプリケーションによっては、プロフィールの識別情報が確認でき、すべての必須項目がそろっている必要があります。一方で、ステータスが欠損情報を説明していれば、一部のみのレコードを受け入れる場合もあります。どちらのルールも妥当になり得ます。結果件数を比較する前に、ルールを決めてください。

要件とその目的を結び付けておきます。既存のレコードと照合する必要があるなら、照合に使う項目を特定します。件数を表示する必要があるなら、不明な値や精度が限られた値をどう表示するかを定義します。こうすると、後の確認を同じ方法で繰り返せるようになります。

両サービスの出力仕様を必須項目と照合する

Chronometricaの文書に記載されたプロフィール出力には、`input`、`channelId`、`secUid`、`shortId`、`channelUrl`、`handle`、`displayName`、`description`、`bioLink`、公開されている各種件数、`countPrecision`、`status`、`statusReason`、`observedAt`が含まれます。収集対象はプロフィールです。投稿履歴やフォロワー一覧は収集しません。Chronometricaの出力仕様

これらのプロフィール情報と、その情報に付随する情報で要件を満たせるなら、このフラットな出力が適しています。フラットな出力では、名前の付いた項目を直接取得できます。必要な事実がそれぞれ、出力のどの項目で提供されるかを文書で確認してください。利用できる項目の数だけでは、その判断はできません。

Noviはユーザー名、ユーザーID、URLを入力として受け付け、より大きな生のユーザーオブジェクトを返します。生のオブジェクトは、収集元の構造をより広く保持します。必要な項目そのものと、その意味を確認してください。Noviの仕様、Noviの入力スキーマ

特定の要件を満たすために、より広範な出力が必要になることがあります。その場合も、アプリケーションがどの部分を使うかを特定する必要があります。出力の大きさだけでは、対象一覧に対してより良い結果が得られるとは判断できません。

文書を読んでも必須項目について不明な点が残る場合は、未解決として記録します。文書に項目の記載がないことは、サービスがその項目を提供しない証拠にはなりません。項目名が似ていることも、要件に合う証拠にはなりません。料金でサービスを選ぶ前に、その疑問を解決してください。

簡単な項目対応表を作ります。アプリケーション側の項目に対し、文書に記載された収集元の項目、その意味、受け入れルールを並べます。少量の結果を確認するときに、この対応表を使ってください。出力を受け入れるか、不足を調べるかを判断する明確な基準になります。

プロフィールの利用に必要な付随情報を保持する

プロフィールの値には、付随情報が必要です。いつ観測した値か、用途に対して十分にそろった結果かを保存します。Chronometricaは`observedAt`、`status`、`statusReason`、`countPrecision`を提供します。プロフィール情報を読み込むときは、文書に記載された各項目の意味に従ってください。Chronometricaの仕様

件数の欠損と、件数が0であることを区別してください。0は、件数が0であることを示します。欠損値は、件数が不明であることを示します。不明な値を0に置き換えると、根拠がないままレポート、フィルター、通知の結果が変わることがあります。

件数の精度も保持します。精度とは、値がどの程度正確かを示すものです。件数の精度が限られている場合は、正確な測定値として表示しないでください。件数を表示または比較するアプリケーションの処理で、精度の情報を利用できるようにします。

一部のみの結果を得たときに、保存済みレコードをどう扱うかを決めます。例えば、最新の収集で値を確認できなかった場合、以前に確認した値を保持するルールが考えられます。このルールを使う場合は、その以前の値の観測時刻も保持してください。古い事実を、新しく観測した事実のように見せてはいけません。

最新の収集試行のステータスも、以前の観測とは別に保持します。こうすると、過去に確認した値と、最新の収集で確認した値をアプリケーションが区別できます。どちらの値を使用できるかを、欠損値のルールで明示してください。

アカウントの地域を示す値を使う場合でも、その値だけで本人の居住地は判断できません。収集元の項目が要件を満たすか判断する前に、アプリケーションが必要とする事実を定義してください。

これらのルールは、結果が有用かどうかに影響します。新たに確認した事実と未解決の値をアプリケーションが区別できないなら、項目名が合っているだけでは不十分です。関連ガイドのTikTokプロフィールのアクセス状態と欠損値で、この問題を詳しく説明しています。

適用開始済みの最新のActorイベント料金を使う

確認した両サービスの公開API記録は、どちらも`PAY_PER_EVENT`を使っています。この料金モデルでは、名前の付いたイベントごとに料金が記載されます。イベントとは、料金記録で指定された課金対象の処理です。履歴の最初の項目ではなく、`startedAt`に基づき、適用開始済みの最新の記録を選んでください。両Actorで同じプランを使います。

確認したChronometricaの現行記録の適用開始日時は、`2026-07-16T22:51:35.105Z`です。Freeでは、有用なプロフィール1件あたり$0.0015と記載されています。現行のイベント一覧には、Actor開始イベントがありません。Chronometricaの公開API料金

確認したNoviの現行記録の適用開始日時は、`2026-08-16T17:08:03.534Z`です。Freeでは、結果1件あたり$0.0055に加え、開始1回あたり$0.001と記載されています。Noviの公開API料金

これらの記録は、2026年10月20日に確認しました。ChronometricaのREADMEには、API記録と異なる古い料金が記載されています。この比較では、上記の適用開始日時が明確なAPI料金を使います。過去の記録と現行料金を混在させないでください。

計算した金額は「Actorイベント料金」と呼びます。この限定的な計算には、プラットフォーム利用料を含めません。結果を請求総額と表示してはいけません。

イベント名、単位、単価、プラン、適用開始日時、確認日を記録します。これにより、計算を検証できます。現在の判断に使う前に、適用開始済みの最新の記録を再確認してください。単価が変わっていれば、計算を更新します。

計算を確認済みの架空の例

これは架空の料金モデルです。実際の請求、ベンチマーク、顧客の結果ではありません。各ActorがFreeプランで、条件に合う有用なプロフィールをちょうど100件返すと仮定します。それ以外の結果イベントは発生しないと仮定します。2つの行で変わるのは実行回数だけです。

この表では、適用開始日時が明確なChronometricaのAPI料金とNoviのAPI料金を使っています。記載されている開始イベントも含みます。その料金が見えるように、小数点以下3桁で示しています。

実行1回では、$0.551 − $0.150 = $0.401です。実行5回では、$0.555 − $0.150 = $0.405です。どちらの差額も、Actorイベント料金だけを表します。

有用な結果の件数が同じという条件は、仮定です。測定結果ではありません。プロフィールを100件入力しても、どちらのサービスも、利用者の受け入れルールを満たす有用なレコードを100件返すとは限りません。したがって、この表は、未検証の対象一覧で実際に費用を削減できることを証明するものではありません。

差額を使う前に、項目に基づく判断をしてください。両サービスの仕様が要件を満たすなら、このモデルは、範囲を限定した妥当な料金判断の材料になります。一方だけが必須項目の要件を満たすなら、まずその要件に基づいて選びます。

実行回数もモデルに含めます。有用な結果の件数が同じでも、何回の実行に分けて収集するかは変わり得ます。別の開発者が収集方法を推測せずに計算を再現できるよう、結果件数と実行回数の両方を明記してください。

少量の公開データを入力して必須項目を1つ確認する

選択を左右する可能性が最も高い項目から始めます。プロフィールとデータベースを照合するための識別値かもしれません。欠損値の扱いがレポートに影響する件数かもしれません。データを収集する前に、合格条件を定義してください。

Chronometricaの文書に記載されたスキーマは、`startUrls`を受け付けます。スキーマとは、受け付ける入力項目を定義したものです。以下は現行スキーマの例であり、有料で実行した結果や、検証済みの実際の収集結果ではありません。使用前に、用途に合う公開プロフィールのURLに置き換えてください。この例は、収集元が現在利用できることを示すものではありません。Chronometricaの入力スキーマ

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

Taskは、保存された入力プリセットです。確認済みの公開TikTokプロフィールデータAPI Taskは、入力の参考になります。保存されたプリセットだけでは、選んだプロフィールからどのような結果が得られるかは判断できません。

少量の結果を確認するときは、用意した項目対応表を使います。

1. 結果が、意図したプロフィールのものであることを確認します。
2. 必須項目の意味と形式を確認し、その値が使用できることを確認します。
3. ステータスと観測時刻を確認します。
4. 該当する場合は、件数の精度を保持します。
5. 不明な値は、不明として記録します。

項目について未解決の点がある場合は、何が不明なのかを特定します。文書に記載された意味、返された値、アプリケーションの受け入れルールのいずれかかもしれません。判断記録では、この違いを区別して残します。これにより、不明確な要件をサービスの性質についての主張にしてしまうことを防げます。

1回の確認が成功すれば、次の小さな段階へ進む根拠になります。すべてのプロフィールで成功することを示すものではありません。アプリケーションに必要な根拠が結果から得られたら、対象一覧を広げます。後の変更も同じ要件に照らして検証できるよう、受け入れた項目対応表を保持してください。

6つの手順で判断する

1. 必要な事実を定義します。必須のプロフィール項目、受け入れ可能な形式、欠損値のルールを列挙します。結果が有用とみなされる条件を明記します。
2. 両サービスの仕様を対応付けます。必要な事実をそれぞれ、文書に記載された出力に対応付けます。数量を比較する前に、意味の違いを解決します。
3. モデルの入力値を設定します。有用な結果の件数、実行回数、両サービスでそろえたプランを記録します。仮定した数量は、架空であると明記します。
4. 現行料金を確認します。適用開始済みの最新のAPI記録を選びます。該当するすべての結果イベントと開始イベントについて、単価、単位、確認日を列挙します。
5. Actorイベント料金を計算します。各イベントの発生回数に単価を掛け、金額を合計します。提示する金額にプラットフォーム利用料を含めないようにします。
6. 必須項目を検証します。用途に合う少量の結果を確認します。不明な値と観測に関する情報を保持してから、対象一覧を広げます。

判断記録は短くて構いません。必須項目、未解決の疑問、根拠へのリンク、確認日付きの料金、仮定、計算が必要です。別の開発者が、判断の過程を一から組み立て直さずに、選択を検証して更新できるようにしてください。

まず、必須項目を提供する仕様のサービスを選びます。そのうえで、料金計算を判断材料の1つとして使います。安定性、実行時間、抽出の成功については、別の根拠で確認できない限り、未解決のままにしてください。