既知のLinkedIn投稿URLに使うChronometricaとAPI Maestroの比較

要件に合うActorはどちらか

「指定した投稿URLごとに何が起きたか」を最初に確認したいなら、Chronometricaが適しています。文書に記載された入力ごとの試行行を使うと、利用できるレコードと未解決の結果をまとめて確認できます。`activityId`、`ugcPostId`、`postUrn`が別々のフィールドにあるため、各投稿識別子の種類を保持できます。識別子とは、投稿を特定するための値です。Chronometricaの文書

最初の選択には、この表を使ってください。表は確認した文書の内容を示しており、性能の測定結果ではありません。

製品に関する事実は、確認したChronometricaの文書とAPI Maestroの文書に基づいています。

1回の実行で1,000件を超える入力が必要なら、API Maestroはその要件を満たしません。API Maestroの入力に関する文書

上限が不明でも、無制限という意味ではありません。この根拠資料では、Chronometricaの最大件数は確認できません。実行する前に、実際の設定が予定する収集に合うか確認してください。

また、何をもって完全な結果とするかも定義してください。試行した入力をすべて記録することと、すべての投稿から使える本文を取得することは異なります。確認した公開文書だけでは、どちらの製品も、すべての公開投稿に完全にアクセスできるとは証明できません。指定したすべてのURLから使える本文を取得することが必須なら、今回の根拠資料では、どちらかのツールがその要件を満たすとは確認できません。

入力ごとの試行行が重要な理由

コンテンツを確認するには、使える投稿本文が必要です。また、使える本文を取得できなかった入力には、その理由も必要です。受け入れたコンテンツだけの表では、この両方に対応できません。

Chronometricaの文書に記載された出力は、この確認に役立ちます。`inputUrl`を使って、行と指定したURLを対応付けます。`status`と`statusReason`を読み、報告された結果を確認します。`observedAt`も保存してください。後で確認する人が、いつ観測したかを把握できます。Chronometricaの出力に関する文書

観測時刻と公開時刻は意味が異なります。公開時刻は、投稿が公開された時刻です。観測時刻は、収集時に投稿の状態を記録した時刻です。記録では、この2つの意味を区別してください。

投稿の識別情報にも注意が必要です。`activityId`、`ugcPostId`、`postUrn`は、元のフィールド名のまま保存してください。同じ意味だと考えて、ラベルのない1つの値にまとめないでください。別々のフィールドを保つことで、後でレコードを対応付ける際に重要となる可能性のある情報を残せます。Chronometricaの出力に関する文書

入力文字列が完全に一致する重複は、1回だけ確認されます。同じ投稿でもURLの形式が異なると、別々に試行されることがあります。これは、文字列の完全一致による重複処理です。同じ投稿へのリンクがすべて統合されることを保証するものではありません。Chronometricaの入力に関する文書

この違いは、予想される行数に影響します。作業用の入力リストで、完全に同じ文字列を重複とした場合の件数を数えてください。投稿の識別情報を別途確認していない限り、重複のない投稿数を推測して使わないでください。準備中に何を変更したか説明できるよう、元のリストも保存してください。

これらの記録は、「受け入れたコンテンツの表は、なぜ指定したリストより行数が少ないのか」という実務上の疑問に答える助けになります。結果を記録しておけば、後から収集の経過を再現しなくても説明できます。

5つの手順で受け入れを確認する

受け入れ確認では、収集した各行が定めた要件を満たすか判断します。本番の収集を始める前に基準を定義してください。実行が終了しただけでは、その行が作業に適しているとは証明できません。

1. 実際に使う入力リストを準備する。

元のURLのコピーを保存します。完全に一致する重複文字列を取り除き、作業用リストを作成します。この処理の前後で件数を記録してください。作業用リストを使って、予想する試行件数を決めます。

Chronometricaでは、公開の`/posts/` URLを使います。確認した入力の根拠に合うのは、このURL形式だけです。この方法では、代わりに`/feed/update/` URLを使わないでください。複数のリンクが同じ投稿を指しているように見える場合は、確認事項として残します。Actorがそれらを統合すると決めつけないでください。Chronometricaの入力に関する文書

1. 受け入れる行に必要な内容を定義する。

次の作業に必要なフィールドを書き出します。コンテンツのコーディングとは、分析のためにコンテンツにラベルを付けることです。これには、使える本文と出典URLが必要です。入力ごとの結果管理には、試行結果も必要です。後でレコードを照合する場合は、取得できた種類別の投稿識別子が必要になることもあります。

作業で使える本文の条件を定義します。短い投稿でも、全文がそろっていて役立つ場合があります。本文が空なら、コンテンツ分析の前に確認が必要です。本文の長さだけを受け入れ基準にしないでください。件数の欠損が作業を妨げるのか、その件数がなくても本文を使えるのかを決めます。

1. 小さなリストと返された結果を照合する。

1行ずつ確認できる少数の入力を選びます。確認前に件数の上限を決めてください。選んだActorの実際の設定を使います。この確認の目的は、文書に記載された挙動が作業に合うかを判断することです。一般的な成功率を示すものではありません。

Chronometricaでは、`inputUrl`を使って試行と作業用リストを対応付けます。`status`と`statusReason`を読みます。返された本文を受け入れ基準と照合してください。文書に記載されたこれらのフィールドは、入力と結果の照合に役立ちます。Chronometricaの出力に関する文書

入力と出力の合計件数が異なる場合は、その差を調べます。完全に一致する重複文字列、URLの形式、報告された結果を確認してください。説明できない差を、架空の成功記録や失敗記録で埋めないでください。

1. 不明な件数と0を区別する。

0は、値が判明している数値です。件数が`null`の場合は、値が欠損しています。Chronometricaの文書では、取得できない公開件数は`null`のまま保持するとされています。結果のエクスポートや計算でも、この違いを保ってください。Chronometricaの件数の扱い

件数が欠損していることを、反応がないと説明しないでください。平均を計算する場合は、値が判明しているレコードの件数を示します。欠損した件数を0に置き換えないでください。本文が空の行は別途確認します。件数が判明していても、その行に分析で必要なコンテンツがあるとは限りません。

1. 受け入れたコンテンツをエクスポートし、除外した結果も保存する。

基準を満たした行でコンテンツ表を作成します。出典URLと観測時刻を残してください。除外した入力の結果は、別の監査表に保存します。監査表は、何を確認したか、各項目をなぜ受け入れたか、または除外したかを記録する表です。

受け入れ確認には、`inputUrl`、解決後のURL、種類別の投稿識別情報、`status`、本文が使えるかどうか、`observedAt`、受け入れまたは要確認の理由、という列を使います。これらは確認用の列です。すべての列名がActorの出力フィールドであることを意味しません。解決後のURLや識別子を作り出さず、不明な値は不明のまま保持してください。

受け入れた結果と除外した結果を合わせると、作業用の入力リスト全体に対応することを確認します。除外理由は各項目に残してください。後で確認する人が、推測せずに、本文の欠損、入手できない入力、試行の失敗を区別できるようにします。

確認前に入力を準備する

LinkedIn Post Text & Engagement Data Taskは、最初の入力プリセットとして使えます。Taskは、保存済みの入力プリセットです。今回の資料作成に向けて公開ページを確認した際は、HTTP 200が返されました。これはページを利用できたことを示しますが、Taskに現在保存されている入力を検証したことにはなりません。実行前に入力を確認し、現行のスキーマ設定を適用してください。

スキーマは、使用できる入力フィールドと値を定義します。次の入力は、保存した公開スキーマに対するローカルの形式確認に合格しました。このフィールド名は、そのスキーマに存在します。この確認は、対象の投稿を取得できることを証明するものではありません。今回の資料作成では、収集は実行していません。Chronometricaの入力に関する文書

{
  "startUrls": [
    "https://www.linkedin.com/posts/timferriss_i-took-my-whole-genome-dumped-it-into-ai-activity-7333162625675038720-TJPX"
  ]
}

このURL例は、保存した公開スキーマまたは公開例に由来します。収集したい公開の出典URLに置き換えてください。新たに収集した結果として扱わないでください。

確認したスキーマでは、`startUrls`は少なくとも1項目を含む配列である必要があります。配列とは、値を並べたリストです。この最小件数から、入力の最大件数は判断できません。最初の確認には小さな作業用リストを使い、返された行を保存したリストと照合してください。Chronometricaの入力スキーマ

プリセットの名前が作業内容と一致していても、入力を確認してください。ページの確認と入力形式の確認は、それぞれ別のことを確かめています。前者は公開ページに関する確認です。後者は使用できる入力構造に関する確認です。どちらも、収集後の行の受け入れ確認の代わりにはなりません。

12件のURLを使った架空の判断例

次の例は架空のものです。Actorのテスト、顧客の成果、購入者の発言、費用を測定した比較ではありません。

ある調査担当者が、文字列として互いに異なる12件のURLを持っています。作業には、コンテンツのコーディング用の投稿本文と、入力ごとの試行記録が必要です。この要件は、Chronometricaの文書に記載された入力ごとの結果管理という強みに合っています。

この架空の確認では、9行に使える本文があります。2行は入手できない入力について説明しています。1行は試行の失敗について説明しています。調査担当者は、試行した入力の12行すべてを保存します。ただし、コンテンツのコーディングに受け入れるのは、使える9行だけです。

計算は次のとおりです。

• 使える9行 + 入手できない入力の2行 + 試行に失敗した1行 = 試行した入力12件。
• 9 ÷ 12 = この架空の確認で使える行の割合は75%。

75%という数値は、ここで作った架空の結果だけを示しています。製品の成功率ではありません。また、12件の試行が、成功して課金対象となる結果12件を意味するわけではありません。Chronometricaが文書で定める仕様と条件では、失敗した試行は、成功した課金対象の結果には該当しません。Chronometricaの文書

調査担当者には、役立つ記録が2つできました。コンテンツ表は、9件の投稿の分析に使えます。監査表は、3件の入力を分析に含めなかった理由を示します。両方を保存すれば、元のリストに投稿が9件しかなかったと誤解されるのを防げます。

受け入れた9行がコンテンツのコーディングに適していても、12件すべてから使える本文を取得するという元の要件は未達成です。1つの目的で受け入れても、その不足は解消しません。結果を共有する際は、この違いを明確にする必要があります。

一方、ID単体を出発点とし、IDに対応する詳細レコードだけが必要な作業なら、API Maestroのほうが適している場合があります。API Maestroの文書

根拠資料から確認できること

製品に関する根拠資料は、2026年10月20日に収集しました。確認したビルドは、Chronometrica 1.0.60とAPI Maestro 0.1.18です。これらは、その時点の文書を確認した結果です。この記事のために、条件をそろえた新たな比較テストは行っていません。Chronometricaが公開する仕様と条件、API Maestroが公開する仕様と条件

根拠資料は、文書に記載された入力と出力の挙動を基準とする選択を支えます。費用が安い、収集が速い、精度が高い、信頼性が高いという主張を裏付けるものではありません。比較対象の製品について、失敗時の行やデータ損失に関する不具合のテストはしていません。文書にない挙動は不明のままです。

購入者のニーズについても、確認できる範囲は限られています。公開の議論では、見込み客を探すボット用にLinkedIn投稿を収集する方法が質問されていました。この製品比較や、入力と結果の照合が求められていたわけではありません。この記事では、その収集ニーズを、読者が公開投稿のリンクをすでに持っている段階に合わせて扱っています。比較する製品を選んだのは、当社の編集上の判断です。有望な見込み客の獲得、プロフィールの発見、連絡活動を約束するものではありません。LinkedIn投稿の収集に関する公開の議論

収集後に投稿内の主張を評価することは、別の作業です。受け入れた本文と出典URLを使い、LinkedIn投稿の主張と裏付けとなる根拠を比較する方法を参照してください。このガイドは、コンテンツ内の根拠を検討します。今回の比較では、収集ツールを選び、その分析を始める前に必要な確認を定義しています。