コンテンツレポートでXのオリジナル投稿・返信・引用を分ける方法

1. アカウント、標本、集計単位を定める

投稿を分類する前に、アカウント一覧を作成します。対象として認めるアカウントの識別子を記録してください。識別子、またはIDとは、アカウントや投稿をほかのアカウントや投稿と区別するための値です。

確認する既知の投稿を具体的に定め、それを標本とします。公開日の条件も使う場合は、その日付を記録してください。提供されたアドレス一覧は、選ばれた標本です。アカウントの全履歴を網羅している証拠にはなりません。

アカウント自身が作成した、重複のない投稿1件を集計単位とします。集計単位とは、各件数が何を数えているかを示すものです。次の単位を分けて扱います。

• リクエストしたアドレス：収集のために送信したアドレス。
• 重複のない投稿：リクエストを通じて見つかり、確認できた投稿ID。
• 対象アカウントが作成した投稿：重複のない投稿のうち、作成者がアカウント一覧と一致するもの。
• 分類済み投稿：対象アカウントが作成した投稿のうち、主分類を確認できたもの。
• 指標の観測記録：明示した時刻に保存したカウンターの読み取り値。

1件の投稿に、複数のリクエストアドレスや複数の指標観測記録が対応する場合があります。どちらの場合も、作成された投稿の件数は増えません。

確認の前に投稿を探す必要がある場合は、別の収集作業として扱います。キーワードと日付でXの投稿を検索するガイドで、その作業範囲の違いを説明しています。検索結果をこのレポートに含める前にも、投稿の識別情報と種類を確認する必要があります。

受け取った反応から、そのアカウントが作成した投稿数を判断してはいけません。投稿の公開返信カウンターは、その投稿に寄せられた返信を示します。作成者自身が書いた返信投稿の件数ではありません。受け取った引用やリポストのカウンターも、同じように区別してください。

2. 既知のアドレスを確認し、返された識別情報を保存する

Actorは、ホスト環境で動くデータ収集プログラムです。X Post Metrics Actorは、仕様上、この作業に適しています。既知の公開X投稿またはTwitter投稿のアドレスを受け取り、指標のスナップショット取得を試みた結果を行として返します。スナップショットとは、ある観測時刻での1回の読み取りです。

2026年10月25日に確認し、固定した公開仕様は、ビルド1.0.4を対象としています。`startUrls`で1～1,000件のアドレスを受け付けます。投稿の検索や、アカウントのアーカイブの取得は行いません。これらは仕様に記載された機能であり、このガイドのために実行して得た結果ではありません。確認済みの公開ビルド仕様を参照してください。

最初の確認に使う入力は、次の小さな形式を参考にしてください。

{
  "startUrls": [
    "https://x.com/OpenAI/status/2077446718728425686"
  ]
}

例のアドレスを、定めた標本に含まれる既知の公開投稿1件のアドレスに置き換えます。提示した入力は、形式としては有効です。このガイドでは、この入力を使った実行は行っていません。既知のアドレスをさらに追加する前に、最初に返された行を調べてください。

Taskは、Actorの入力設定を保存したものです。確認時点で、公開のX Campaign Post Metrics Taskページは存在していました。ログイン済みのアカウントを通じた保存設定の確認は行っておらず、このTaskも実行していません。使用前に入力を確認してください。

リクエストしたアドレスである`inputUrl`と、返された投稿のアドレスである`postUrl`を分けて保存します。返された投稿IDの`postId`と、返された作成者のアカウントIDの`profileId`も保存します。

この区別は、リポストのアドレスを扱う際に重要です。現在の公開READMEによると、リポストを入力した場合の行は、画面に表示される元の投稿を記述します。返される識別情報、作成者、本文、指標は、その元の投稿に関するものです。リクエストと投稿の対応を保存してください。そのリクエストを、リポストしたアカウントが作成した別のオリジナル投稿として数えてはいけません。この動作は、公開ビルドとREADMEの根拠資料に記載されています。

3. 対応表、投稿台帳、指標の観測記録を保存する

異なる単位には、別々の表を使います。台帳とは、判断とその根拠を記録して保存する表です。以下の項目名は、バッククォートで囲んだActorの正確な項目名を除き、読者が作る台帳への提案です。

まず、処理を試みた入力ごとに、リクエストと投稿の対応を1行保存します。

次に、確認済みの重複のない投稿IDごとに、投稿台帳の行を1件作成します。

手がかりとは、判断を助ける根拠です。Actorが直接返す`postType`は、仕様に記載された手がかりとして扱います。行の情報だけでは区別できない点が分類判断に必要な場合は、公開画面の文脈を確認してください。

この台帳の返信先と引用元の投稿へのリンクは、読者が追加する根拠資料です。Actorの仕様では、返信先や引用元の投稿IDは出力されません。手作業で追加した項目を、Actorが直接出力した項目として提示してはいけません。

最後に、指標の観測記録を別に保存します。投稿ID、指標名、値、`observedAt`、公開時刻、指標の状態、精度、情報源を残してください。精度は、その値がどの程度正確かを示します。繰り返し読み取った値は、同じ投稿の観測記録として保存します。

これらは、仕様に記載された出力項目です。ただし、記載があるだけで、処理を試みたすべての行に利用できる値が入ると証明されるわけではありません。この区別は、確認済みの出力仕様に基づいて判断します。

4. 主分類を決めるルールを適用する

分類別に集計する前に、ルールを書きます。このレポートでは、次の順番で判断します。

1. 投稿IDと作成者が確認済みであることを確かめます。
2. 作成者が、あらかじめ定めたアカウント一覧と一致することを確かめます。
3. 返信であることが確認できた投稿は、主分類を返信とします。
4. 返信ではなく、引用であることが確認できた投稿は、引用に分類します。
5. それ以外は、公開画面の文脈がその判断を裏付ける場合に限り、オリジナル投稿に分類します。
6. 種類を確定できない投稿は未解決のままにします。

このルールにより、分類の重複を防げます。つまり、集計対象の投稿が入る主分類は1つだけです。

引用を含む返信は、返信に分類し、引用の有無は「あり」として残します。分析に必要な場合は、両方の参照リンクを保存します。その投稿を引用の分類でも重ねて数えてはいけません。

参照先の管理と、アカウント自身が作成した投稿の集計は分けます。引用元は、作成者が何を共有したかを説明するための情報です。そのアカウントが作成した別の投稿にはなりません。引用元も独立して標本に含まれる場合は、それ自体の確認済み記録を作り、通常の作成者確認ルールを適用します。

関係を示す項目が欠けていても、関係がないとは判断できません。特に、返信先や引用元のIDが直接出力されないことは、この出力仕様の制約です。その投稿に返信先や引用元がない証拠にはなりません。

2つの観測で種類の判断が食い違う場合は、両方の根拠を残します。公開画面の文脈を確認して食い違いを解消するか、種類を未解決のままにしてください。望む結果になる分類を選んではいけません。

5. 計算の前に反応の比較方法を定める

指標を1つ選び、観測ルールを明示します。指標とは、公開の表示回数やいいね数など、測定した量です。別途定義を設けずに、異なるカウンターの値を足し合わせてはいけません。

作成した投稿の種類と、その投稿が受け取った反応を分けます。引用に分類された投稿も、返信、リポスト、引用を受け取ることがあります。これらの受信カウンターは、その1件の投稿への反応を表します。作成した投稿の分類を変えたり、台帳の投稿数を増やしたりするものではありません。

観測記録を比較するときは、投稿後の経過時間を記録します。これは、公開から指標の読み取りまでの時間です。公開直後に読み取ったカウンターと、かなり時間がたってから読み取ったカウンターでは、対象となる時間の範囲が異なります。公開時刻が欠けている場合、経過時間は不明です。`publishedAt`の代わりに`observedAt`を使ってはいけません。

Actorの仕様では、`postMetricStatus`の各要素に指標、状態、精度、情報源が含まれます。状態の値は`present`、`unavailable`、`not_attempted`です。精度の値は`exact`、`unavailable`、`unknown`です。使用する各指標とともに、これらの値を保存してください。1つの指標が利用できても、6つの指標すべてが利用できる証拠にはなりません。

品質のルールを事前に書きます。たとえば、値が存在し、精度が正確で、情報源が明示されていることをレポートの条件にできます。これは読者向けに提案するルールです。実行結果がそのルールを満たしたという主張ではありません。

欠損値は欠損のままにします。返されたゼロは、測定された数値です。表を埋めるために、欠損したカウンターをゼロに置き換えてはいけません。分類が確認済みの投稿でも、指標の集計対象からは外れる場合があります。

分類ごとに、分類済みの投稿数と、指標を集計できる件数を示します。合計には、集計条件に合う観測記録だけを使います。平均を示す場合は、その指標の集計対象となる投稿数で割ります。平均とは、合計を、計算に含めた投稿数で割った値です。その投稿数がゼロの場合、平均は定義できません。

公開画面の読み取り値と、所有者だけが見られるレポートの値は、定義や対象期間が異なる場合があります。使用許可のあるエクスポートデータをすでに持っている場合は、別の情報源として保存します。2つの値を同等とみなす前に、公開カウンターと所有者のエクスポートデータを比較するガイドを参照してください。

6. 独自に作成した架空の例で手順を確認する

独自に作成した架空の例です。この例のラベルと件数は、すべて創作です。Actorの実行結果、Taskの実行結果、実在する投稿IDではありません。

提供された6件のアドレスは、重複を除くと5件の投稿に対応します。2件のアドレスはP1に対応します。残りの4件は、それぞれP2、P3、P4、U1に対応します。

確認済みの分類を示す例は、次のとおりです。

「明示していない」は、確認済みの「なし」を意味しません。実際の台帳では、各判断の根拠を保存する必要があります。この例のU1には、利用できる表示回数の値がありません。この欠損値はゼロではありません。

投稿数の計算は、次のとおりです。

• リクエストした6件のアドレスは、重複のない5件の投稿に対応します。
• 重複のない5件の投稿の内訳は、集計対象の分類済み投稿4件と、未解決の投稿1件です。
• 集計対象の分類済み投稿4件の内訳は、オリジナル投稿1件、返信2件、引用1件です。

P1には2件のリクエストがありますが、投稿数には1回だけ含めます。P4も返信数に1回だけ含めます。引用ありの記録は残しますが、2つ目の分類には加えません。

架空の反応集計表では、この例で明示した前提として、比較条件のそろった表示回数の観測記録を使います。実際の公開時刻や観測時刻は示していません。実際のレポートでは、それらの時刻を保存し、条件がそろっていることを確認してください。

集計対象全体の合計は、4件の投稿について100 + 40 + 200 + 60 = 400回の架空の表示です。分類別の合計を足しても、100 + 100 + 200 = 400回の表示になります。

これらは情報源のカウンターが数えた表示の発生回数であり、重複を除いた人数ではありません。この架空の標本では、引用の分類で合計と平均が最も大きくなっています。ただし、引用したことが反応を増やしたとは示していません。投稿の種類について一般的な順位を示すものでもありません。各分類の投稿数は、それぞれ1件、2件、1件です。

U1を分類別の平均に含めてはいけません。表示回数をゼロにしてもいけません。指標が欠損している未解決の投稿1件として、表の横に明示してください。

7. 件数を確認し、問題が残る状態も明示する

レポートを共有する前に、次の完成条件を確認してください。

1. リクエストしたすべてのアドレスから、保存した処理結果をたどれるようにします。識別情報が未解決のリクエストも明示します。
2. 変わらない投稿IDを使って、重複のない投稿を確認します。繰り返しの観測を追加の投稿として数えてはいけません。
3. 作成者を、あらかじめ定めたアカウント一覧と照合します。作成者が不明の投稿は、対象アカウントが作成した正確な投稿数には含めません。
4. 集計対象の各分類済み投稿が、主分類1つだけに含まれることを確認します。
5. 引用を含む返信が、主分類の合計に1回だけ含まれることを確かめます。
6. 集計に含めるすべての指標値から、観測時刻、状態、精度、情報源をたどれるようにします。
7. 集計に含めた投稿の行から、各分類の合計を再計算します。
8. 結果の横に、未解決件数と除外件数を示します。

異なる問題は、異なる状態として管理します。投稿IDが欠けている場合、投稿の識別に基づく正確な件数は出せません。作成者が不明の場合、アカウントとの一致を確認できません。作成者が判明していてもアカウント一覧に含まれない場合は、不明ではなく除外です。種類が未解決の場合、投稿を識別できていても、分類別の集計には含められないことがあります。

指標の欠損も、別の状態です。指標が欠けていても、確認済みの投稿が消えたり、分類失敗に変わったりするわけではありません。すべての投稿の識別情報と種類が分かっていても、投稿後の経過時間がそろっていなければ、反応の比較には制約があります。

リクエストと投稿の対応表、確認済み投稿の台帳、指標の観測記録、分類ルールの文書、対象範囲を明示した成果の表を提出します。各件数に何を含めたかを示してください。標本が公開情報の確認、使用許可のある所有者の記録、またはその両方に基づくものかも明記します。

その先の問いには、別の方法が必要です。アカウント自身が作成した返信を日別に数えるには、公開日とレポートのタイムゾーンが必要です。話題を比較するには、内容のラベルが必要です。どちらも、この分類別合計だけから自動的に分かるものではありません。同様に、キーワードの共起分析は、投稿内で一緒に現れる語を数える方法です。返信や引用の関係を確定するものではありません。