Twitter Snowflake ID のデコード方法

#Snowflake ID を日時にデコードする

ツイートの作成時刻は ID の中に書き込まれているので、投稿を取得しなくても読み取れます。ID の下位22ビットを捨て、X の基準日を足せば、UTC の Unix 時間が1000分の1秒の精度で得られます。X が投稿の下に表示する分単位の時刻より細かい値です。ID さえ手元にあれば、削除された投稿でも同じ方法で求められます。無料のツイート ID 日時変換ツールなら、1件でも、リスト全体でも変換できます。

1. ID をコピーする。 x.com/<username>/status/2110301305616889042 のような投稿リンクでは、status/ の後ろの数字が ID です。同じ数字で、x.com/i/web/status/ の後ろに ID を続けても、その投稿が単独で開きます。

2. 下位22ビットを捨てる。 2110301305616889042 >> 22 は 503135038761 です。X の基準日から投稿までの時間を、1000分の1秒で数えた値です。2^22 で割って小数点以下を切り捨てても、同じ数になります。

3. 基準日を足す。 503135038761 + 1288834974657 = 1791970013418 で、1000分の1秒単位の Unix 時間です。秒に直すと 1791970013.418 です。

4. 日時として読む。 1791970013.418 は、2026年10月14日（水）09:26:53.418 UTC です。表示するときは、自分のタイムゾーンに変換してください。X は読む人ごとに、その人のローカル時間で表示しています。

投稿 ID、ユーザー ID、投稿リンクのどれでも下のデコーダーに貼り付けると、日時と4つの構成要素が表示されます。

同じ計算をコードで書くと次のとおりです。Python の整数は64ビットすべてを保持できます。JavaScript では BigInt を使ってください。通常の数値型だと、19桁の ID が丸められます。

from datetime import datetime, timezone

EPOCH = 1288834974657  # ms: November 4, 2010, 01:42:54.657 UTC


def snowflake_to_datetime(snowflake_id):
    ms = (int(snowflake_id) >> 22) + EPOCH
    return datetime.fromtimestamp(ms / 1000, tz=timezone.utc)


print(snowflake_to_datetime("2110301305616889042"))
# 2026-10-14 09:26:53.418000+00:00

const EPOCH = 1288834974657n;

function snowflakeToDate(id) {
  // BigInt keeps all 19 digits; Number("2110301305616889042")
  // would turn the ID into 2110301305616889000
  const ms = (BigInt(id) >> 22n) + EPOCH;
  return new Date(Number(ms));
}

console.log(snowflakeToDate("2110301305616889042").toISOString());
// 2026-10-14T09:26:53.418Z

ID を64ビット整数で保存しているデータベースなら、同じシフト演算をクエリの中で実行できます。

-- PostgreSQL, id stored as BIGINT
SELECT id,
       to_timestamp(((id >> 22) + 1288834974657) / 1000.0) AS created_utc
FROM posts;

-- BigQuery, id stored as INT64
SELECT id,
       TIMESTAMP_MILLIS((id >> 22) + 1288834974657) AS created_utc
FROM dataset.posts;

変換ツールは、ID の列をまとめて受け取り、結果を CSV でダウンロードし、日時から ID への逆変換も行います。すべてブラウザ上で完結します。

#古い ID と長いリストの日時を Sorsa API で取得する

この計算が成り立たない ID が2種類あります。2010年11月4日より前の投稿と、2016年2月より前に作られたアカウントです。これらの ID は1つずつ連番で採番されていて、時刻を含みません。そのため計算すると、基準日から数秒後の時刻が返ります。もっともらしく見えますが、誤りです。こうした ID のほか、デコードした時刻と並べて X 自身の created_at も欲しい場合は、ID をバッチで照会します。

古い ID を含め、ツイート ID の日時を大量に取得するなら、公開データ向けの Twitter（X）API 兼スクレイピングツール である Sorsa API を使います。POST /tweet-info-bulk は、1リクエストで最大100件の投稿 ID の created_at を、投稿1,000件あたり$0.014からで返します。公式 X API では1,000件あたり$5.00です。アカウントは GET /info-batch で、同じ料金のまま1リクエストあたり100件を取得できます。公式 X API は1,000件あたり$10.00です。

1. キーを取得する。 サインアップして、ダッシュボードから API キーをコピーします。アカウントには100回分の無料リクエストが付き、カードは不要です。

2. 投稿 ID を最大100件送る。 tweet_links に ID か投稿リンクを渡して POST /tweet-info-bulk（新しいタブで開きます） を呼び出します。各投稿は、投稿者のプロフィール付きで丸ごと返ります。

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1243617904", "2110301305616889042"]}'
   

   {
     "tweets": [
       {
         "id": "1243617904",
         "created_at": "2009-02-24T19:51:06Z",
         "full_text": "Field notes from the harbor survey are up on the site",
         "likes_count": 4,
         "user": {
           "id": "20536157",
           "username": "lanternbay_research",
           "created_at": "2009-02-10T16:22:31Z"
         }
       },
       {
         "id": "2110301305616889042",
         "created_at": "2026-10-14T09:26:53Z",
         "full_text": "New dataset: ten years of harbor traffic, in one CSV",
         "likes_count": 212,
         "user": {
           "id": "1427632226255384585",
           "username": "copperfield_signals",
           "created_at": "2021-08-17T14:03:41Z"
         }
       }
     ]
   }
   

   レスポンス全体を表示

3. アカウントも同じ方法で取得する。 GET /info-batch（新しいタブで開きます） に、アカウントごとに user_ids を繰り返して最大100件指定します。各プロフィールに created_at が含まれます。

   curl -G "https://api.sorsa.io/v3/info-batch" \
     -H "ApiKey: YOUR_API_KEY" \
     --data-urlencode "user_ids=20536157" \
     --data-urlencode "user_ids=1427632226255384585"
   

4. デコードでは足りない分にだけリクエストを使う。 このスクリプトは post_ids.csv を読み込み、すべての Snowflake を無料でデコードして、古い ID だけを API に送り、ID ごとに日時を1つ書き出します。

   import csv
   from datetime import datetime, timezone
   
   import requests
   
   BASE = "https://api.sorsa.io/v3"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   EPOCH = 1288834974657           # Twitter's epoch, Unix ms
   
   
   def decode(post_id):
       """The UTC time inside a Snowflake ID; None for an older ID."""
       if len(post_id) < 15:       # counted ID from before Nov 4, 2010
           return None
       ms = (int(post_id) >> 22) + EPOCH
       return datetime.fromtimestamp(ms / 1000, tz=timezone.utc)
   
   
   def look_up(post_ids):
       """created_at from Sorsa API, 100 post IDs per request."""
       found = {}
       for i in range(0, len(post_ids), 100):
           r = requests.post(f"{BASE}/tweet-info-bulk", headers=HEADERS,
                             json={"tweet_links": post_ids[i:i + 100]},
                             timeout=30)
           r.raise_for_status()
           for tweet in r.json().get("tweets", []):
               found[tweet["id"]] = tweet["created_at"]
       return found
   
   
   with open("post_ids.csv", newline="", encoding="utf-8") as f:
       ids = [row["post_id"].strip() for row in csv.DictReader(f)]
   
   decoded = {i: decode(i) for i in ids}
   looked_up = look_up([i for i, d in decoded.items() if d is None])
   
   with open("post_dates.csv", "w", newline="", encoding="utf-8") as f:
       out = csv.writer(f)
       out.writerow(["post_id", "created_at_utc", "source"])
       for i in ids:
           if decoded[i]:
               out.writerow([i, decoded[i].isoformat(), "decoded"])
           else:
               out.writerow([i, looked_up.get(i, ""), "looked up"])
   

削除された投稿や非公開の投稿は返ってこないため、その行は空のままになります。結果は位置ではなく、必ず id で突き合わせてください。403 はキーがないか、リクエストを使い切ったことを、429 は1秒間に20リクエストを超えたことを示します。失敗したリクエストに課金されることはありません。

古い投稿 ID の照会は、公式 X API では1,000件あたり$5.00です。返した投稿1件ごとに課金されるためです。Sorsa API なら1,000件あたり$0.014からで、課金の単位はリクエストであり、1リクエストに投稿100件が入ります。

公式 X API と比べて、この作業に必要な項目はどれも Sorsa API のほうが有利です。

• 投稿1,000件あたりの料金

  Sorsa API

  $0.014から

  公式 X API

  $5.00

• アカウント1,000件あたりの料金

  Sorsa API

  $0.014から

  公式 X API

  $10.00

• 1リクエストあたりの ID 数

  Sorsa API

  投稿100件またはアカウント100件

  公式 X API

  100件、1件ずつ課金

• 2010年11月より前の投稿

  Sorsa API

  対応、created_at 付き

  公式 X API

  対応、投稿ごとの同じ料金

• セットアップ

  Sorsa API

  ヘッダーに API キー1つ

  公式 X API

  開発者アカウント、アプリ、ベアラートークン

• 速度

  Sorsa API

  全プランで毎秒20リクエスト

  公式 X API

  15分ウィンドウごとのレート制限

• 取得量

  Sorsa API

  投稿の読み取り上限なし。成長に合わせて上位プランへ

  公式 X API

  月300万件の投稿読み取り。超えると月約$42KからのEnterprise

• X のログイン情報

  Sorsa API

  求められない

  公式 X API

  開発者アカウントが自分の X アカウントに紐づく

公式 X API の料金は料金ページ（新しいタブで開きます）に掲載されています。詳しい比較は、ガイド X API 料金にまとめました。2006年以降のタイムライン全体や検索結果を取得するなら、過去の Twitter データをご覧ください。

#Snowflake ID の64ビットに入っているもの

Snowflake ID は64ビットの整数で、4つのフィールドに分かれています。41ビットのタイムスタンプ、5ビットのデータセンター番号、5ビットのワーカー番号、12ビットのシーケンスです。最上位ビットは常に0で、数値が正のままになります。この構造は2010年に公開された Twitter 自身の ID 生成プログラムに由来し、snowflake-2010 のソース（新しいタブで開きます）に残っています。ID は ((time - epoch) << 22) | (datacenter << 17) | (worker << 12) | sequence で組み立てられます。

各フィールドは、シフトとマスクで読み取れます。

• 63

  幅

  1

  フィールド

  符号（常に0）

  読み取り方

  値の例

  0

• 62〜22

  幅

  41

  フィールド

  基準日からの時間（1/1000秒）

  読み取り方

  id >> 22

  値の例

  503135038761

• 21〜17

  幅

  5

  フィールド

  データセンター（0〜31）

  読み取り方

  (id >> 17) & 31

  値の例

  11

• 16〜12

  幅

  5

  フィールド

  ワーカー（0〜31）

  読み取り方

  (id >> 12) & 31

  値の例

  7

• 11〜0

  幅

  12

  フィールド

  シーケンス（0〜4,095）

  読み取り方

  id & 4095

  値の例

  1234

基準日。 1288834974657 は、そのソースファイルにある定数 twepoch で、2010年11月4日（木）01:42:54.657 UTC にあたります。Snowflake は1970年ではなくこの日から数えるので、41ビットをより長く未来のために使えます。このフィールドが表せるのは2^41 の1000分の1秒、約69.7年で、2080年7月10日 17:30:30.208 UTC に上限に達します。

残りの22ビット。 Twitter の2010年の README（新しいタブで開きます） には、マシン ID が10ビットで最大1,024台と書かれており、コードはこれをデータセンターとワーカーに分けています。12ビットのシーケンスは、同じ1000分の1秒の間に1台のマシンが発行する ID に番号を振るもので、最大4,096個です。現在のデータセンター番号とワーカー番号が何を意味するのか、X は文書化していません。データではなくラベルとして扱ってください。

順序。 時刻が最上位のビットにあるため、ID が大きいほど、ほぼ確実に新しい投稿です。README は、マシンをまたいでもおよそ1秒以内の順序を保証すると述べており、X の ID ガイド（新しいタブで開きます）も、そのため ID はおおよそ時系列に並ぶとしています。別のマシンで同じ秒に作られた2つの投稿は、順序が入れ替わることがあります。

他のプラットフォームもこの設計を、独自の基準日で採用しています。そのため、他サービスの ID を X の基準日でデコードすると、実際の日付から何年もずれます。

#どの X の ID が Snowflake で、いつからか

投稿 ID は2010年11月4日に Snowflake になりました。ユーザー、リスト、保存した検索の ID は、2016年2月1日に続きました。2回目の切り替えは、X 自身が2015年11月23日の開発者向けフォーラム投稿（新しいタブで開きます）で告知しています。2016年2月1日以降、新しいユーザー、リスト、保存した検索には64ビットの Snowflake ID が付与されます。投稿と DM はすでにこの形式で、既存の ID は引き続き有効です。

混乱の原因の大半は、これより古い2つの日付にあります。2013年1月、Twitter の開発者ブログは 64ビットのユーザー ID（新しいタブで開きます） を告知し、2013年10月21日に有効化しました。この変更は、カウンターが32ビットを超えて増えられるようにしただけで、アカウントには2016年まで連番の ID が付き続けました。ユーザーの切り替えを「2020年ごろ」とするページも誤りです。2016年半ばに作られたアカウントの ID は、すでに18桁の Snowflake です。

• 投稿（ツイート）

  Snowflake ID になった時期

  2010年11月4日

  日時にデコードできるか

  15桁以上の ID ならできる

• ダイレクトメッセージ

  Snowflake ID になった時期

  2015年11月まで

  日時にデコードできるか

  15桁以上の ID ならできる

• ユーザーアカウント

  Snowflake ID になった時期

  2016年2月1日

  日時にデコードできるか

  18桁・19桁の ID ならできる。古いアカウントはできない

• リスト、保存した検索

  Snowflake ID になった時期

  2016年2月1日

  日時にデコードできるか

  新しい長めの ID ならできる

• スペース

  Snowflake ID になった時期

  なし

  日時にデコードできるか

  できない。スペース ID は 1YqGodQbNXDxv のような英数字

知っておきたいこと

連番の ID はエラーなしでデコードできてしまうので、ここが落とし穴です。X 自身が例に挙げるユーザー ID 2244994945 は、基準日の1秒足らず後にあたる2010年11月4日 01:42:55 UTC に変換されます。史上最初の投稿である ID 20 は、基準日そのものにデコードされます。2010年11月4日の最初の数時間に収まる結果が出たら、その ID には日時が含まれていません。

アカウントの登録時刻を秒単位で知りたい場合は、ID が Snowflake であっても、プロフィールの照会で created_at を読んでください。サインアップのどの時点で ID に時刻が刻まれるのか、X は文書化していません。コードを使わないなら、無料の Twitter アカウント作成日確認ツールで、あらゆるアカウントの登録日がわかります。

#ID の古さは桁数でわかる

Snowflake ID は、内部の時計が10のべき乗を超えるたびに1桁増えるため、長さだけで作成時期がおおよそわかります。投稿 ID は2018年5月25日から19桁で、最上位ビットが常に0なので、フィールドが尽きる2080年まで19桁のままです。

• 11桁以下

  投稿 ID

  2010年11月4日より前：連番、日時なし

  アカウント ID

  2016年2月より前：連番、日時なし

• 15

  投稿 ID

  2010年11月4日〜6日

  アカウント ID

  なし

• 16

  投稿 ID

  2010年11月6日〜12月1日

  アカウント ID

  なし

• 17

  投稿 ID

  2010年12月1日〜2011年8月7日

  アカウント ID

  なし

• 18

  投稿 ID

  2011年8月7日〜2018年5月25日

  アカウント ID

  2016年2月1日〜2018年5月25日

• 19

  投稿 ID

  2018年5月25日以降

  アカウント ID

  2018年5月25日以降

長さは、JavaScript やスプレッドシートで ID が壊れる原因でもあります。2010年11月28日以降に作られた投稿 ID はすべて、JavaScript の数値型が正確に保持できる最大の整数 2^53 より大きくなります。X の ID ガイドが ID を文字列で保持するよう求めているのは、このためです。Excel や JavaScript が ID をどう壊すか、安全に保存するにはどうするかは、ガイドユーザー名から Twitter ユーザー ID を取得で解説しています。

#日付を ID に変換して since_id と max_id に使う

計算は逆向きにもできます。1000分の1秒単位の Unix 時間から基準日を引き、結果を22ビット左にシフトすると、その時点で X が作りえた最小の ID が得られます。これはどの投稿のものでもなく、X の検索が理解できる時間上の目印です。

X の検索構文には、こうした目印を取る指定が2つあります。since_id: は指定した ID より新しい投稿を、max_id: は指定した ID 以下の投稿を返します。2026年10月14日の UTC 09:00〜10:00 の1時間なら、下限は (1791968400000 - 1288834974657) << 22 で 2110294538449846272、上限は10:00時点の ID から1を引いた 2110309637944246271 です。Sorsa API の POST /search-tweets（新しいタブで開きます） も同じ構文を受け付けます。

Q="from:lanternbay_research since_id:2110294538449846272"
Q="$Q max_id:2110309637944246271"
curl -X POST "https://api.sorsa.io/v3/search-tweets" \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"query\": \"$Q\", \"order\": \"latest\"}"

各ページは約20件の投稿と next_cursor を返します。これが空で返ってくるまで、リクエストのボディに入れて送り返してください。保存してある最新の ID を覚えておき、次の実行で since_id: に渡せば、定期実行のジョブが同じ投稿を二度取得することはありません。秒単位で指定したい場合は、ID の代わりに Unix 秒を取る since_time: と until_time: を使います。日付に関するそのほかのコマンドは、Twitter 検索コマンドの一覧にあります。

#最初の ID の日時を調べる

Twitter の Snowflake ID は、それ自体が日時を持っています。22ビット右にシフトして 1288834974657 を足せば、2010年11月4日以降のあらゆる投稿と、2016年2月以降のあらゆるアカウントの作成時刻が、1000分の1秒単位でわかります。それより古いものや、何千件もの ID に X 自身の created_at を並べたい場合は、Sorsa API の /tweet-info-bulk が1リクエストで投稿100件を、1,000件あたり$0.014からで読み取ります。必要なのは API キー1つだけで、開発者アカウントは不要です。100回分の無料リクエストで最初の1万件の投稿の日時がわかるので、上のスクリプトを手持ちのリストで実行してみてください。

#よくある質問