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

Xで自分が一日に何件の返信をしたかを数えるには、確認済みの自分の投稿記録を使います。集計用のタイムゾーンを一つ選びます。各返信IDを、その地域の暦日で1回だけ数えます。一日全体の記録があり、返信がないと確認できた場合だけ、0を入力します。記録の欠落は別に扱います。日別表を確定する前に、日付が変わる午前0時の前後と、夏時間の切り替え時の記録を確認してください。

この方法で数えるのは、自分が書いた返信です。投稿に表示される返信数は、その投稿が受け取った返信の数です。自分が返信した回数を示すものではありません。

日別表を作成し、時刻に関する問題を記録します。また、同じデータを再度取り込んでも件数が変わらないことを確認します。公開投稿の収集は任意です。公開投稿を収集しても、保存したアカウントの記録にすべての返信が含まれることは証明できません。

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

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

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

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

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

公開投稿の検索で分かるのは、検索条件に一致するどの投稿が返されたかという別の内容です。検索も使う場合は、[キーワードと日付でXを検索するガイド](/ja/articles/x%E6%8A%95%E7%A8%BF%E3%81%AE%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E3%81%A8%E6%97%A5%E4%BB%98%E3%81%AB%E3%82%88%E3%82%8B%E6%A4%9C%E7%B4%A2/)で、その検索対象期間を確認できます。検索結果は、自分のアカウントの記録が一日全体を網羅する証拠とは分けて扱ってください。

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

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

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

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

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

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

| 日別表の項目 | 保存する内容 |
| --- | --- |
| `account_id` | 確認済みのアカウント識別情報 |
| `date` | 集計用タイムゾーンでの暦日 |
| `reporting_zone` | 選択したIANAタイムゾーン名 |
| `coverage_state` | 一日全体を網羅すると確認済みか、一部のみか、欠落か、不確かか |
| `known_reply_count` | この日付に割り当てた、集計対象の重複しない返信IDの数 |
| `unresolved_count` | この日付に影響する可能性がある、把握済みの未解決候補の数。確定できた場合に記録する |
| `source_reference` | その行の根拠となる保存済みファイルと記録 |

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

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

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

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

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

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

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

| 返信単位の項目 | 目的 |
| --- | --- |
| 固定の投稿ID | 自分が書いた返信を識別する |
| 確認済みの投稿者 | そのアカウントが書いた返信であることを確認する |
| 確認済みの投稿の種類 | その記録が返信であることを確認する |
| 元の時刻の値 | 元データの時刻を変更せずに保存する |
| 元データから確定した時点 | 確定できた場合に、時間上の正確な一点を特定する |
| 現地のタイムスタンプ | その時点を集計用タイムゾーンで表示する |
| 割り当てた日付 | 返信を日別表のどの行に含めるかを示す |
| 集計に含める理由、または例外とする理由 | その記録を数えた理由、または確認のために保留した理由を説明する |
| 元データの参照先 | 元の記録と重複したコピーの場所を示す |

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

同じ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日確認。タイムゾーン変換と、繰り返される時間帯の処理に対応](https://docs.python.org/3/library/zoneinfo.html)を参照してください。

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

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

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

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

次のルールを使います。

| 元データの状態 | 日別の結果 |
| --- | --- |
| 一日全体の記録を確認済みで、返信も未解決の候補もない | 正確な合計は返信0件 |
| 一日全体の記録を確認済みで、集計対象の返信すべてに日付があり、未解決の候補がない | 正確な合計は重複しない返信数と等しい |
| 有効な返信はあるが、記録の網羅範囲が不完全、または不確か | 確認できた返信数を示す。一日全体の合計は算出不可 |
| 必要な範囲の元データが欠落している | 件数は算出不可。0で代用しない |
| 未解決の候補がその日付に影響する可能性がある | 確認できた返信数と、不確かな点を明記した注記を示す |

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

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

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

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

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

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

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

| 返信ID | 元データのUTCタイムスタンプ | トロントのタイムスタンプ | 割り当てた日付 |
| --- | --- | --- | --- |
| R1 | `2026-10-25T03:59:00+00:00` | `2026-10-24T23:59:00-04:00` | 2026-10-24 |
| R2 | `2026-10-25T04:01:00+00:00` | `2026-10-25T00:01:00-04:00` | 2026-10-25 |
| D1 | `2026-11-01T05:30:00+00:00` | `2026-11-01T01:30:00-04:00` | 2026-11-01 |
| D2 | `2026-11-01T06:30:00+00:00` | `2026-11-01T01:30:00-05:00` | 2026-11-01 |

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日は記録が欠落しています。提示した時刻変換だけでは、ほかの日付の記録が一日全体を網羅するとは確認できません。

| 日付 | 記録の網羅状態 | 確認できた返信数 | 一日全体の合計 |
| --- | --- | --- | --- |
| 2026-10-24 | 一日全体の網羅は未確認 | 1 | 算出不可 |
| 2026-10-25 | 一日全体の網羅は未確認 | 1 | 算出不可 |
| 2026-10-26 | 一日全体の元データを確認済み。返信なし | 0 | 0 |
| 2026-10-27 | 欠落 | 算出不可 | 算出不可 |
| 2026-10-28 | 未確認 | 算出不可 | 算出不可 |
| 2026-10-29 | 未確認 | 算出不可 | 算出不可 |
| 2026-10-30 | 未確認 | 算出不可 | 算出不可 |
| 2026-10-31 | 未確認 | 算出不可 | 算出不可 |
| 2026-11-01 | 一日全体の網羅は未確認 | 2 | 算出不可 |

「算出不可」のセルは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日に公開仕様を確認。既知の投稿の特定時点の情報を取得するもので、アカウント所有者のアーカイブではありません](https://apify.com/chronometrica/x-post-metrics)は、`startUrls`に既知の公開X投稿またはTwitter投稿のURLを1〜1,000件受け付けます。検索を実行したり、アカウント所有者のアーカイブを返したりする機能ではありません。

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

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

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

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

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

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

返されたカウンターとアカウント所有者のレポートを比較する場合は、[Xの公開カウンターとアカウント所有者のエクスポートを比較するガイド](/ja/articles/x-%E5%85%AC%E9%96%8B%E3%82%AB%E3%82%A6%E3%83%B3%E3%82%BF%E3%83%BC-%E5%88%86%E6%9E%90%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%9D%E3%83%BC%E3%83%88-%E7%85%A7%E5%90%88/)を使ってください。この比較で必要な確認は、公開日ごとに自分の返信を数えるための確認とは異なります。

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

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

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

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

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

## 次に行う作業を選ぶ

まず、保存した自分のアカウントの記録と照合できる期間を一つ選びます。集計用のタイムゾーンを選び、すべての日付の行を作成します。アカウントの識別情報、時刻、記録の網羅範囲、再取り込みを確認してください。これらの確認で裏付けられる日だけ、一日全体の合計を使います。それ以外の日は、確認できた返信数と、残る不確実な点を示します。

自分の日別返信数だけが必要なら、これらの表で作業は完了です。既知の投稿を選び、その時点で公開されている情報も必要な場合は、[X Post Metrics Actor](https://apify.com/chronometrica/x-post-metrics)を確認してください。入力例を自分の入力に置き換え、公開情報の観測結果は自分のアカウントの活動記録と分けて管理します。

## 出典と参考資料

- [Xヘルプセンター：アーカイブのダウンロード — 2026年10月25日確認。アカウント所有者によるアーカイブの取得方法を裏付けます。削除済み投稿の全履歴や、返信を識別する一定のデータ構造を保証するものではありません](https://help.x.com/en/managing-your-account/how-to-download-your-x-archive)
- [Python zoneinfoドキュメント — 2026年10月25日確認。IANAタイムゾーンと、繰り返される時間帯の処理に対応。架空例の時刻変換は、アカウントの観測結果ではありません](https://docs.python.org/3/library/zoneinfo.html)
- [X Post Metrics Actorと公開ビルド1.0.4 — 2026年10月25日確認。文書化された既知のURLの入出力仕様のみ。実行時の動作や履歴の完全性は検証していません](https://api.apify.com/v2/acts/chronometrica~x-post-metrics/builds/default)