Xのリポスト日時の特定方法｜発信者情報開示請求の実務【2026年】

誹謗中傷の相談を受け、元投稿だけでなくリポスト（旧リツイート）による拡散も対象にしようと調べ始めたところで、多くの方が同じ場所でつまずきます。X（旧Twitter）の画面には、リポストがされた日時がどこにも表示されないのです。タイムラインに出ているのは元投稿の日付であり、リポストしたアカウントの一覧にも日時は出てきません。投稿記事目録には投稿日時を書かなければならないのに、その日時が画面上に存在しない、という状況です。

この記事では、Xのリポストがされた日時をどのように特定し、どのように証拠化して投稿記事目録に落とし込むかを、実務の手順に沿って解説します。あわせて、なぜ日時の特定がそこまで重要なのか──Xに対する開示請求がいわゆる「ログイン型」であることとの関係──についても整理します。

1　単純リポストも発信者情報開示請求の対象になる

前提を確認します。発信者情報開示請求の根拠法は、令和6年改正により題名が変更され、現在は「特定電気通信による情報の流通によって発生する権利侵害等への対処に関する法律」（平成13年法律第137号。いわゆる情報流通プラットフォーム対処法・情プラ法）となっています。改正法は2025年（令和7年）4月1日に施行されました。開示請求の根拠規定は同法5条、裁判所に対する発信者情報開示命令の申立ては同法8条、提供命令は15条、消去禁止命令は16条にそれぞれ置かれています。条文番号が旧プロバイダ責任制限法から動いているため、書式を流用する際は必ず現行条文を確認してください。

次に、リポストが「侵害情報の流通」に当たるかという点です。この点については、大阪高等裁判所令和2年6月23日判決が参考になります。同判決は、コメントを付さない単純リツイート（現在のリポスト）について、元ツイートの表現内容をそのままの形でリツイート主のフォロワーのタイムラインに表示させ閲読可能な状態に置く行為であると位置づけたうえで、元ツイートが他人の社会的評価を低下させる内容であり、リツイート主がこれを閲読可能な状態に置くことを認識している以上、投稿の経緯や意図を問わず不法行為責任を負い得るとして、慰謝料等の支払を命じました。

この判断枠組みを前提とすれば、リポストも独立した権利侵害行為として構成でき、リポストをしたアカウントに対する発信者情報開示請求が可能ということになります。実務上も、元投稿者が海外在住であったり既にアカウントを削除していたりする場合に、拡散に寄与したリポスト主を対象とする例は珍しくありません。リポスト・シェア・「いいね」といった拡散行為の法的責任の整理については、誹謗中傷のリポスト（RT）・シェア・「いいね」でも訴えられる？拡散者の法的責任もあわせてご覧ください。

2　なぜリポスト日時の特定が必要なのか──Xは「ログイン型」だから

「日時は分かる範囲で書けばよいのではないか」と考えたくなりますが、Xに対する開示請求の構造上、リポストの日時は手続の成否を直接左右します。鍵になるのは、Xがいわゆる「ログイン型」のサービスであるという点です。

Xから開示されるのは、投稿時ではなくログイン時のIPアドレスである

掲示板のような投稿型のサイトであれば、開示の対象は投稿時の通信に係るIPアドレスと、その投稿が送信された年月日及び時刻（タイムスタンプ）です。総務省令（特定電気通信による情報の流通によって発生する権利侵害等への対処に関する法律施行規則）も、発信者情報として、侵害情報の送信に係るIPアドレス及び組み合わされたポート番号と、当該IPアドレスを割り当てられた設備から侵害情報が送信された年月日及び時刻を掲げています。

ところがXは、投稿（リポスト）が行われた際の通信のIPアドレスを保有していないのが通例です。そのため、実際に開示を受けることになるのは、アカウントへのログイン等の通信に係るIPアドレスと、その通信の日時です。これが情プラ法にいう「特定発信者情報」であり、その前提となる「侵害関連通信」は、同法5条3項及び施行規則において、①アカウント開設のための通信、②サービスを利用し得る状態にするための通信（ログイン）、③その状態を終了するための通信（ログアウト）、④契約を終了させるための通信（退会）と定められています。Xの事案で問題になるのは、通常②のログイン時の通信です。

「リポストに近接するログイン」を画するために、リポスト日時が要る

ここが本質的な理由です。特定発信者情報は、条文上「当該侵害情報の発信者を特定するために必要な範囲内」のものに限られており、実務上も、侵害情報の送信に近接する時期のログインに係るIPアドレス及びタイムスタンプの開示を求める形をとります。アカウントには日々多数のログインがあり得ますから、そのすべてが開示対象になるわけではなく、問題の投稿と時間的に結び付くログインに絞って特定する必要があるのです。

そうすると、近接性を測る起点となるのが、まさに当該リポストがされた日時ということになります。リポスト日時が特定できていなければ、どのログインが「近接」するのかを画することができず、開示を求める対象そのものを定められません。申立書や目録の上でも、「令和◯年◯月◯日◯時◯分のリポストに近接するログイン」という形の特定ができなくなります。

アクセスプロバイダの段階でも日時が鍵になる

Xから開示を受けたログイン時のIPアドレスとタイムスタンプの組合せを、アクセスプロバイダが保有する接続記録と照合して契約者を特定するのが、二段階の開示請求の基本構造です。この照合はタイムスタンプを鍵として行われますから、時差の処理を誤っただけでも「該当なし」という回答が返ってきます。Xから開示される日時は協定世界時（UTC）で示されることがあるため、日本標準時（JST）との換算を常に意識してください。

目録上の特定としても必要になる

東京地方裁判所が公開している発信者情報開示命令申立書の記載例では、投稿記事目録の記載項目として、サイト名称、アカウント名、閲覧用URL、投稿日時が挙げられています。同裁判所のチェックリストでは、投稿日時について「UTC（協定世界時）か、JST（日本標準時）かも明らかにすること」が求められており、記載例でも日本標準時と世界標準時が併記される形式が示されています。目録は開示の対象範囲を画する書面ですから、日時の記載が空欄では、対象の特定として不十分と評価されるおそれがあります。

時間との勝負になる

アクセスプロバイダの接続記録の保存期間は、事業者や回線の種類によって異なるものの、一般に短期間であり、数か月程度とされることが多いと指摘されています。リポストの日時を特定する作業に手間取っているうちに、対象となる時点の記録が失われてしまえば、その後の手続をどれだけ丁寧に進めても発信者にはたどり着けません。相談を受けたら、まず日時を確定させ、保全を意識して動く必要があります。保存期間の実情と消去禁止命令の使い方は、ネット誹謗中傷のログはいつ消える？プロバイダのログ保存期間と消去禁止命令で整理しています。

3　Xの画面にリポスト日時が表示されないという問題

ここが本題です。2026年8月時点のXの仕様では、単純リポストがされた日時は、通常の閲覧画面のどこにも表示されません。実際に確認できるのは次のとおりです。

• リポスト主のタイムライン……「○○さんがリポスト」という表示とともに元投稿が並びますが、そこに出ている日付は元投稿の投稿日付です。
• 元投稿に付いている「リポスト」の一覧……リポストしたアカウントの一覧が表示されるだけで、各アカウントがいつリポストしたかは表示されません。
• リポスト固有のIDに対応するURL……後述のとおりリポストにも固有のIDがありますが、そのURLを開いても、表示されるのは「○○さんがリポスト」の表示と元投稿の内容であり、画面上の日時は元投稿の投稿日時です。ここを誤って転記すると、元投稿の日時をリポストの日時として目録に記載してしまうことになります。

つまり、画面を見て転記するという通常の方法では、リポスト日時は絶対に得られません。にもかかわらず、タイムライン上でリポストは投稿日付順ではなくリポストされた順に並んでいます。並び順を決定している日時の情報は存在するのに、画面に描画されていないだけなのです。

4　リポスト日時を特定する方法──リポスト固有のIDから復元する

リポストは独自のIDを持つ一個の投稿である

Xの内部では、リポストは「元投稿を参照する、リポスト主自身の一個の投稿」として記録されています。この投稿には、元投稿のIDとは別に、リポスト自身のID（19桁前後の数字）が付与されています。タイムラインの並び順を決めているのは、この固有IDに対応する生成時刻です。

投稿IDには生成時刻が埋め込まれている

Xの投稿IDは、分散システムで時系列順の一意な識別子を発行するために設計された、いわゆるスノーフレーク方式のIDです。この方式では、IDの上位ビットに生成時刻がミリ秒単位で埋め込まれており、下位ビットに発行元の識別子と連番が入ります。Twitter由来の実装で用いられる基準時刻（エポック）は 1288834974657（1970年1月1日からのミリ秒。2010年11月4日に相当）で、時刻部分は上位41ビットに置かれています。

したがって、IDから生成時刻を復元する式は次のとおりです。

具体例で確認します。仮にリポスト固有のIDが 2086023762554601952 であった場合、これを4,194,304で割った整数部に 1288834974657 を加えると 1786181796097 となり、UNIX時刻（ミリ秒）として日時に直すと 2026年8月8日 09時36分36.097秒（UTC）、日本標準時では同日18時36分36.097秒となります。ミリ秒単位まで復元できる点が、この方法の実務上の利点です。

肝心のリポスト固有のIDをどう取得するか

画面に表示されるリンクは元投稿のURLですから、リンクをコピーしても得られるのは元投稿のIDです。リポスト固有のIDは、リポスト主のタイムラインを表示した状態で、その画面を描画するために読み込まれているデータの中に含まれています。ブラウザの開発者向け機能を用いて当該データを参照し、元投稿のIDを参照している側の投稿のIDを読み取る、という手順になります。

この作業は技術的な要素を含むため、事務所内で対応が難しい場合は、対応経験のある弁護士に共同受任や引継ぎを相談するのが現実的です。なお、事件情報を外部のオンライン変換サービスに入力することは、依頼者情報の管理の観点から避けるべきです。IDから日時への換算は表計算ソフトでも計算できますから、外部サービスに頼る必要はありません。なお、同じように画面に正確な日時が表示されないサービスとしてGoogleマップの口コミがあり、その特定方法はGoogleマップ口コミの正確な投稿日時・最終編集日時を特定する方法で解説しています。

5　証拠化の手順──「再現できる形」で残す

特定した日時は、そのまま目録に書けばよいというものではありません。画面に表示されていない情報を主張する以上、どのような方法で取得し、どのように算出したのかを、相手方や裁判所が同じ手順で再現できる形で示しておく必要があります。当事務所では、次の順序で証拠化しています。

• 画面の写しを撮る……リポスト主のプロフィール画面のうち、「○○さんがリポスト」の表示と対象投稿が一体として写る部分を撮影します。アカウント名が判読できることが重要です。
• 取得元URLと取得日時を記録する……表示状態は変動しますから、いつ時点の表示に基づくものかを明示します。
• 取得したデータと算出過程を記録する……リポスト固有のID、元投稿のID、それぞれの生成時刻、算出式、算出結果（UTCとJSTの双方）を一覧にします。
• 投稿記事明細としてまとめる……上記を1通の書面に整理し、画面の写しを別紙として添付します。開示請求の甲号証として、また後の損害賠償請求でも使い回せます。

ここまで整えておくと、アクセスプロバイダに対する二段階目の申立てで日時の根拠を問われた際に、その都度作業をやり直さずに済みます。

6　投稿記事目録への記載方法

目録の記載は、リポストという行為を対象としていることが一読して分かる書き方にします。閲覧用URLについては、リポスト固有のIDに対応するURLと元投稿のURLの双方を掲げ、どちらがどちらであるかを明示するのが親切です。記載例の骨格は次のとおりです。

日時欄には、画面上に日時が表示されない仕様であること、記載した日時が投稿記事明細に記載の方法により特定したものであることを、注記として付しておくとよいでしょう。裁判所から「この日時はどこから出てきたのか」と問われる前に、書面上で説明しておくという趣旨です。

7　実務上の注意点

元投稿が削除されてもリポストは残ることがある

元投稿が削除されると、リポストの表示は通常失われます。他方、リポスト主がリポストを解除した場合には、元投稿は残るがリポストだけが消えることになります。いずれの場合も、その時点で画面からは取得できなくなりますから、相談を受けた段階で速やかに保全することが重要です。

特定発信者情報の開示要件を確認する

前記2のとおりXの開示はログイン時の情報が中心になりますが、特定発信者情報の開示については、情プラ法5条1項において、権利侵害の明白性・開示を受けるべき正当な理由に加え、同項3号の要件（開示関係役務提供者が特定発信者情報以外の発信者情報を保有していないと認めるときなど）を満たすことが求められています。申立ての段階で、Xが投稿時のIPアドレスを保有していないことを前提に主張を組み立てておく必要があります。

提供命令・消去禁止命令の活用

発信者情報開示命令の申立てとあわせて、提供命令（情プラ法15条）と消去禁止命令（同法16条）を申し立てるのが一般的です。提供命令によりコンテンツプロバイダから経由プロバイダの名称等の提供を受け、消去禁止命令によりログの消去を防ぐという流れです。前記のとおりログの保存期間には限りがありますから、この二つの命令を早期に確保することが結果を左右します。提供命令の仕組みは提供命令とは？発信者情報開示を早める新制度で詳しく説明しています。

リポストが多数ある場合の絞り込み

拡散が大きい事案では、リポストが数百件に及ぶこともあります。すべてについてIDの取得と日時の算出を行うのは、費用対効果の面でも現実的ではありません。フォロワー数、反復性、コメントの有無といった要素で対象を絞り込み、その理由を説明できるようにしておくのが実務的な対応です。当事務所でも、SNS上の誹謗中傷については、SNSのなりすまし・誹謗中傷への対応のご相談を受ける中で、拡散への寄与度を基準に対象を選別する方針をとっています。

8　よくある質問

元投稿をしていない単純リポストだけでも、発信者情報開示請求の対象になりますか。

リポストも、元投稿の表現内容をそのままの形で自己のフォロワーに閲読可能な状態に置く行為であり、権利侵害情報の流通に当たり得ます。大阪高裁令和2年6月23日判決は、単純リツイート（リポスト）について不法行為責任を認めており、これを前提に開示請求の対象とする実務が定着しています。もっとも、権利侵害の明白性は元投稿とは別に、リポスト主による拡散という観点から主張立証する必要があります。

リポストの日時が分からないまま、発信者情報開示命令を申し立てることはできますか。

実際には困難です。Xはいわゆるログイン型であり、開示を受けるのは投稿時ではなく、投稿に近接する時期のログインに係るIPアドレスとタイムスタンプです。近接性を測る起点がリポスト日時ですから、これが特定できなければ開示を求める対象ログインを画することができません。加えて、東京地方裁判所の記載例でも投稿記事目録の記載項目として投稿日時が挙げられ、UTCかJSTかを明示することが求められています。申立て前に特定しておくべきです。

投稿IDから算出した日時は、証拠として使えますか。

算出値そのものよりも、算出の過程を検証可能な形で残しておくことが重要です。リポスト固有のID、算出式、算出結果、取得日時、取得元URL、取得方法を一覧にした明細書を作成し、画面の写しを添付しておけば、相手方や裁判所が同じ手順で再現できます。あわせてサービス側が保持する日時情報と一致することを示せれば、より確実です。

引用リポスト（コメント付きリポスト）の場合はどうなりますか。

引用リポストは、コメントを伴う独立した投稿として扱われ、通常の投稿と同じく固有のURLを持ち、画面上にも投稿日時が表示されます。したがって日時の特定に特別な作業は不要です。日時の表示が問題となるのは、コメントを付けない単純リポストの場合です。

リポストが数百件ある場合、すべてを開示請求の対象にすべきですか。

件数が多い場合、すべてを対象とすると特定作業と費用の負担が大きくなります。フォロワー数が多く拡散への寄与が大きいアカウント、繰り返しリポストしているアカウント、コメントを付して積極的に加担しているアカウントなどに絞り込むのが現実的です。絞り込みの理由を申立書で説明できるようにしておくとよいでしょう。

9　まとめ

Xの単純リポストについては、画面上にリポスト日時が表示されないため、通常の転記作業では投稿記事目録を埋めることができません。しかしリポストは固有のIDを持つ一個の投稿として記録されており、そのIDには生成時刻がミリ秒単位で埋め込まれています。IDを取得して復元計算を行い、サービス側が保持する日時情報と突合すれば、リポストがされた日時をミリ秒単位で特定することが可能です。

要点を整理すると、次のとおりです。

• リポストも独立した権利侵害行為として開示請求の対象とし得る（大阪高判令和2年6月23日参照）
• Xはログイン型であり、開示対象は投稿に近接する時期のログインに係るIPアドレスとタイムスタンプである
• 近接性を測る起点がリポスト日時であり、これが特定できないと対象ログインを画せない
• 投稿記事目録には投稿日時を記載し、JSTかUTCかを明示する（東京地裁の記載例・チェックリスト）
• 画面上の日付は元投稿のものであり、リポスト日時ではない
• リポスト固有のIDから生成時刻を復元し、算出過程を明細として証拠化する
• ログの保存期間には限りがあるため、提供命令・消去禁止命令を含めて早期に動く

発信者情報開示請求は、法律上の主張と技術的な事実の確認とが交錯する分野です。とりわけリポストのように画面に情報が出てこない類型では、事実を「どう取得し、どう示すか」の設計が結論を左右します。ご自身の事務所で対応するか迷われた場合や、時間的な余裕がない事案では、早い段階で対応経験のある弁護士に相談されることをお勧めします。

※本記事は一般的な情報提供を目的としたものであり、個別の法的助言ではありません。具体的な事案についてのご判断は、弁護士にご相談ください。また、各サービスの仕様は変更されることがありますので、実際の手続にあたっては最新の状況をご確認ください。