保存した記録から、Xで自分が書いた返信を日別に数える方法

1. 確認済みの自分の返信記録を用意する

投稿者と投稿の種類を確認済みの記録を使います。自分が書いた返信とは、自分のアカウントから公開した返信です。投稿IDは、投稿を識別する値です。各記録にこのIDを残してください。

自分のアカウントの記録がまだない場合、Xにはアカウントのアーカイブを申請する方法の説明があります。アーカイブとは、ダウンロードしたアカウント情報のコピーです。Xの説明では、投稿を含む、機械で読み取れるHTMLファイルとJSONファイルを取得できます。これらはソフトウェアで読み取れる構造化されたファイル形式です。ただし、この説明は、削除済み投稿の全履歴や、返信を識別するための一定の項目が必ず含まれることを保証していません。Xアーカイブガイド — 2026年10月25日確認。アカウント情報のダウンロード方法であり、削除済み投稿の全履歴を証明するものではありませんを参照してください。

この方法を使う前に、これらの記録を取得して確認します。元データのコピーは変更せずに保管してください。元データがどの期間を網羅するか、何が不確かなままかを記録します。一部の返信がファイルに含まれているだけでは、すべての記録がそろっている証拠にはなりません。

このガイドは、投稿者と返信の確認が済んだ段階から始まります。アーカイブの取得方法や、通常の投稿、返信、引用を区別するための詳しいルールは扱いません。

公開投稿の検索で分かるのは、検索条件に一致するどの投稿が返されたかという別の内容です。検索も使う場合は、キーワードと日付でXを検索するガイドで、その検索対象期間を確認できます。検索結果は、自分のアカウントの記録が一日全体を網羅する証拠とは分けて扱ってください。

2. アカウント、日付、集計用タイムゾーンを決める

集計を始める前に、次の内容を短い集計メモにまとめます。

1. 返信を数えるアカウントを特定します。
2. 集計対象の開始日と終了日を暦日で明記します。
3. 名称のある集計用タイムゾーンを一つ選びます。
4. 元のファイルと、確認済みの網羅範囲を明記します。
5. 未解決の記録を明記します。

`America/Toronto`のようなタイムゾーン名を使います。これはIANAタイムゾーン名です。IANAの名称は、日付によって時刻のルールが変わる地域を識別します。マイナス4時間などの固定の時差では、これらのルールを代用できません。

件数を入力する前に、対象となるすべての日付に1行ずつ作ります。これにより、取り込んだ記録がない日も集計表から消えずに残ります。

次の項目を使うことを提案します。これらは集計用に自分で作成する項目です。Xのアーカイブに同じ見出しがあると保証されているわけではありません。

集計対象の返信とは、投稿者、返信という投稿の種類、固定のID、使用できる公開時刻の確認をすべて通過した記録です。

記録の網羅範囲を示すラベルは、集計メモで定義します。「一日全体」は、現地の暦日で一日全体の元データを確認した状態です。「一部のみ」は、一日の一部しか記録がないと分かっている状態です。「欠落」は、必要な元データがない状態です。「不確か」は、どこまで網羅するかを確定できない状態です。

例外一覧がないという理由だけで、`unresolved_count`に0を入力しないでください。0とするには、確認を完了し、未解決の候補がないと分かっている必要があります。記録が欠落している範囲には、存在を把握できていない記録があるかもしれません。

3. 各返信IDを1回だけ数える

繰り返し取り込んだデータには、同じ返信のコピーが複数含まれる場合があります。一つの固定の返信IDは1回だけ数えます。ほかのコピーは取り込みの証拠として残しますが、活動件数には含めません。

本文や表示時刻が一致するという理由で、記録を削除しないでください。別々の返信でも、同じ文面になることがあります。表示時刻も同じになることがあります。

日別表と併せて、返信単位の小さな表も保存します。

タイムスタンプとは、日付と時刻の値です。時点とは、時間上の正確な一点です。タイムゾーンの情報が十分にないタイムスタンプでは、時点を特定できない場合があります。

同じIDのコピー間で情報が矛盾する場合は、その矛盾を見える形で残します。表を完成させるためだけに、都合のよい日付を選ばないでください。元データで判断を裏付けられるまで、影響を受ける件数は確認のために保留します。

返信ではない通常の投稿は、この返信数に含めません。受け取った返信のカウンターも含めません。この集計全体の単位は、自分が書いた返信の重複しないID一つです。人数、受け取った返信の数、取り込んだ行数ではありません。

4. 公開時刻を変換してから日付を割り当てる

返信が公開された時刻を使います。アーカイブをダウンロードした日や、公開記録を収集した日は使いません。

元の時刻の値を保存します。次に、確認済みのタイムゾーン情報を使って、元データが示す時点を特定します。その時点を集計用タイムゾーンに変換します。暦日は、変換した後で求めます。

UTCは協定世界時のことです。時点を記録するための共通の基準として使われます。UTCオフセットは、現地の時計がUTCよりどれだけ進んでいるか、または遅れているかを示します。例えば、`-04:00`はUTCより4時間遅れていることを意味します。

次の順序で進めます。

1. 元の公開時刻を読み取ります。
2. そのタイムゾーンまたはオフセットで時点を確定できることを確認します。
3. その時点を、指定した名称の集計用タイムゾーンに変換します。
4. 現地のタイムスタンプをオフセットとともに保存します。
5. 現地の暦日を割り当てます。
6. これらの値をすべて確認できる状態で保存します。

タイムゾーンやオフセットがない場合は、ほかの確認済みの元データで時点を確定できない限り、未解決のままにします。ソフトウェアライブラリがその値を受け付けるという理由で、UTCだと決めつけないでください。

Pythonの`zoneinfo`は、IANAタイムゾーンとUTCオフセットの変化に対応しています。時計を戻すときに同じ時間帯が繰り返される場合にも対応しています。Python zoneinfoドキュメント — 2026年10月25日確認。タイムゾーン変換と、繰り返される時間帯の処理に対応を参照してください。

現地で日付が変わる前後の記録を使って確認します。UTCでの日付が同じでも、集計用の日付は異なる場合があります。この確認で、日別件数が一日ずれる問題を検出できます。

夏時間の切り替えで繰り返される時間帯も確認します。夏時間とは、季節に応じて現地の時計を変更する制度です。時計を戻すと、同じ現地時刻が2回現れる場合があります。オフセットの違いによって、二つの時点を区別できます。表示時刻が同じという理由で、別々の返信IDを一つにまとめないでください。

5. 確認できた件数と一日全体の合計を分ける

時刻の確認後、集計対象の返信IDを、割り当てた現地日付ごとにまとめます。各日付の重複しないIDを数えます。その後、記録の網羅範囲と例外を確認します。

次のルールを使います。

確認できた件数は、確認済みの記録から何が分かるかを読者に示します。一日全体の合計とするには、記録の網羅範囲も確認済みである必要があります。また、その合計を変える可能性がある未解決の記録があってはいけません。

例えば、日付が確定した返信が2件あれば、確認できた返信は2件です。ただし、別の返信候補の時刻が未解決なら、一日の正確な合計は確定できません。

確認できた返信2件に未解決の候補1件を足して、返信3件と報告しないでください。その候補には、まだ判断が必要です。確認できた返信2件と未解決の候補を分けて示します。

6. 計算例：日付の切り替わり、繰り返される時間帯、記録が欠落した日

この例は独自に作成した架空のものです。アカウントのデータは取り込んでいません。この例に示す4件の時刻変換は、ローカル環境でPythonの`zoneinfo`を使って確認したものです。学習用の記録であり、Xアカウントの観測結果やActorの実行結果ではありません。

集計用タイムゾーンは`America/Toronto`です。対象期間は2026年10月24日から11月1日までです。

架空のファイルには、取り込んだ記録が6件あります。内訳は、異なる返信4件、返信R1の重複コピー、返信ではない通常の投稿O1です。

R1とR2の間隔は2分です。UTCでは、どちらも10月25日です。トロントでは、R1は10月24日、R2は10月25日に属します。UTCの日付でまとめると、R1を誤った集計日に入れてしまいます。

D1とD2は、トロントではどちらも01:30と表示されます。ただし、オフセットは異なります。二つの異なる時点であり、返信IDも異なります。どちらも11月1日に属します。表示時刻が同じという理由で一方を削除すると、返信を1件失います。

取り込んだ記録の計算は次のとおりです。

• 取り込んだ記録6件 − 重複コピー1件 = 重複しない投稿ID 5件。
• 重複しない投稿ID 5件 − 対象外の通常の投稿1件 = 日付が確定した集計対象の返信ID 4件。
• 10月24日の返信1件 + 10月25日の返信1件 + 11月1日の返信2件 = 日付が確定した集計対象の返信4件。

10月26日については、別途確認した一日全体の元データに返信がありません。10月27日は記録が欠落しています。提示した時刻変換だけでは、ほかの日付の記録が一日全体を網羅するとは確認できません。

「算出不可」のセルは0ではありません。確認できた数値を合計すると、返信は4件です。この計算には、10月26日に確認した0件も含まれます。ただし、対象期間全体の完全な合計を証明するものではありません。

ここで、この独自の架空例に別の条件を追加して考えます。別の候補記録には11月1日01:30としか書かれておらず、確認済みのオフセットがありません。この記録は、元の6件のファイルには含まれていません。時刻は未解決のままにします。11月1日に影響する可能性がある場合は、確認できた返信2件と未解決の候補1件を示します。繰り返される時間帯のどちらを指すかを推測しないでください。

最後に、元の6件のファイルをもう一度取り込みます。結果に含まれる集計対象の返信IDは、引き続き4件でなければなりません。確認できた日別件数も、それぞれに割り当てた日付で1件、1件、2件のままである必要があります。2回目の取り込みで倍増してはいけません。

7. 公開投稿の指標は、別の目的がある場合だけ使う

この計算に公開指標の収集は必要ありません。確認済みの自分のアカウントの記録から、自分が書いた返信を取得できます。

Actorは、ホスティング環境で動くデータ収集プログラムです。X Post Metrics Actor — 2026年10月25日に公開仕様を確認。既知の投稿の特定時点の情報を取得するもので、アカウント所有者のアーカイブではありませんは、`startUrls`に既知の公開X投稿またはTwitter投稿のURLを1〜1,000件受け付けます。検索を実行したり、アカウント所有者のアーカイブを返したりする機能ではありません。

提示する小さな入力例は次のとおりです。

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

サンプルURLを、確認したい既知の公開投稿URLに置き換えます。提示した入力は形式の確認を通過しています。実行はしていません。また、形式の確認は、その投稿を取得できることを示すものではありません。

文書化された出力には、`postId`、`profileId`、`postType`、`publishedAt`、`replies`、`observedAt`が含まれます。`publishedAt`は公開時刻です。`observedAt`は公開情報を観測した時刻です。`replies`の値は受け取った返信のカウンターなので、自分が書いた返信数には含めません。

文書化された出力には、返信先の投稿IDや引用元の投稿IDは含まれていません。活動の一覧が完全であることも証明しません。公開ドキュメントには、リポストを入力すると、表示されている元の投稿の情報を返すとも記載されています。指定したアドレスの`inputUrl`と、返された投稿のアドレスの`postUrl`は、分けて管理してください。返された元の投稿を、自分が投稿した別の活動として数えないでください。これらは文書化されたルールであり、この記事のために実行して得た結果ではありません。X Post Metrics ビルド1.0.4 — 2026年10月25日確認。公開された入出力仕様のみを参照してください。

返されたカウンターとアカウント所有者のレポートを比較する場合は、Xの公開カウンターとアカウント所有者のエクスポートを比較するガイドを使ってください。この比較で必要な確認は、公開日ごとに自分の返信を数えるための確認とは異なります。

8. 次の確認を終えてから日別表を確定する

集計結果を使う前に、次の項目を確認します。

1. 対象となるすべての暦日に行があることを確認します。
2. 集計対象の各返信IDが、必ず一つの日だけに含まれることを確認します。
3. 重複コピーによって、どの件数も増えないことを確認します。
4. 返信ではない通常の投稿と、受け取った返信のカウンターを除外していることを確認します。
5. 現地で日付が変わる前後と、繰り返される時間帯の例に、正しい日付を割り当てていることを確認します。
6. 確認できた日別件数の合計が、対象期間内の日付が確定した集計対象の返信ID数と一致することを確認します。
7. 返信数をゼロとした日には、一日全体の記録がある証拠を確認します。
8. 記録が欠落している場合、件数を「算出不可」のままにしていることを確認します。
9. 未解決の候補を、影響する日付の横に明示していることを確認します。
10. 同じファイルを再度取り込んでも、どの件数も変わらないことを確認します。

合計の確認では、確認できた返信を一貫した方法で日付に割り当てたかを調べます。元データにすべての返信が含まれることは証明できません。再取り込みの確認では、重複コピーによって結果が変わらないかを調べます。タイムスタンプの欠落は解決できません。

日別表とともに、返信単位の表、元データの参照先、網羅範囲の注記、タイムスタンプの例外記録を提出します。確認を通過しない項目があれば、根拠を確認できる記録を修正するか、結果を未解決のままにします。セルを0で埋めて問題を隠さないでください。