Twitter ID コンバーター：ユーザー名・ユーザー ID・プロフィールリンク

Q: なぜ一部の Twitter のユーザー ID は短く、他は非常に長いのか？

X は初期のアカウントに短い、連番の整数の ID を割り当て、それが Jack Dorsey のアカウントが 12 である理由で、ユーザー ID を64ビットの Snowflake 形式に2016年2月に切り替えただけです。その切り替えの前に作成されたアカウントは短い、低い ID を持ちます。その後に作成されたアカウントは、上位ビットに作成のタイムスタンプをエンコードする、約18〜19桁の長い Snowflake ID を持ちます。

Q: 開発者は数千のユーザー名を規模でどう ID に変換する？

大量の作業には、Sorsa API が3つの変換エンドポイント（/username-to-id、/id-to-username、/link-to-id）を、変換あたりフラットな1リクエストで公開します。100,000リクエストで月額 $199 の Pro プランでは、各変換は約 $0.002 で、公式 API のリソース単位のレートのおよそ5分の1の安さです。スループットはキーあたり毎秒20リクエストに上限が設けられ、自分のコードが通常 API ではなくボトルネックであるほど十分に高いです。

著者：Sorsa Editorial

2026年7月更新：100回分の無料リクエストの開始オプション（クレジットカード不要）を追加し、変換の料金をフラットな1,000変換あたりのレートで捉え直し、公式の従量課金の読み取りレートを再確認しました。

要点： Twitter（X）のユーザー ID は、アカウント作成時に割り当てられる永続的な64ビットの数字で、一方 @ユーザー名はいつでも変わり得ます。それらを相互変換するには、ハンドル、数値の ID、またはプロフィール URL を照会エンドポイントに送ります。ID は改名を生き延びるため、ハンドルではなく ID を保存します。

@brand_name を主キーとして保存し、それからそのアカウントが @new_brand にリブランドするのを見たことがあるなら、なぜこれが重要かをすでに知っています。X（旧Twitter）はユーザーが望むときにいつでもハンドルを変えさせ、@brand_name がいったん解放されると、誰でもそれを主張できます。数値のユーザー ID は、生涯にわたって元のアカウントに付いたままの唯一の識別子です。

これらの変換をコードで行うために、代替の Twitter/X API プロバイダーである Sorsa API は、3つの専用のエンドポイント（ハンドルから ID、ID からハンドル、プロフィール URL から ID）を、OAuth フローもアプリ承認の列もなく単一の API キーの背後で公開します。各変換は、公式 API が使うリソース単位の計測ではなく1つのフラットなリクエストと数えるため、100,000のハンドルを解決するのは、公式 X API クレジットのおよそ$1,000に対して Proプランで$199からです。すべての新規キーは100回分の無料リクエスト（1回限り、クレジットカード不要・有効期限なし、40個のエンドポイントすべて）で始まり、プランを決める前に最初のアカウントのバッチを変換するのに十分です。コードをまったく書きたくない単発の照会には、無料の ID コンバーターの playground が、キーなしでブラウザで3つの変換すべてを行います。

開示：Sorsa API は当社の製品です。以下の料金の比較は、2026年7月に確認した公式 X API の公開された従量課金レートを使います。コミットする前に、自分のワークロードに対して現行のレートを確認してください。

本ガイドは、このトピックを通る開発者の経路です。実際にいつ変換が必要か、なぜこれらの識別子の設計が重要か、各変換をコードでどう行うか、そしてパイプラインを壊さずに数千のアカウントにまたがってどう実行するかです。

なぜユーザー ID が信頼できる唯一の識別子か
Twitter のユーザー ID がどう生成されるか
Twitter のユーザー ID の見つけ方
3つの変換操作
2026年に ID 変換はいくらかかるか？
Sorsa API での変換
規模でのバッチ変換
混在した入力の正規化
ハンドルの変更を検出する
実践
始め方
よくある質問

なぜユーザー ID が信頼できる唯一の識別子か {#why-user-ids-are-the-only-identifier-you-can-trust}

X 上のユーザー名は可変です。ユーザーは今日 @old_name を @new_name に変えられ、明日には別の誰かが @old_name をつかめます。アプリケーションがハンドルを主キーとして扱うと、2つのことが一度に壊れます。保存されたすべての参照が間違ったアカウントを指し、そしてサードパーティが今や、元のユーザーに関連付けていたハンドルを持つかもしれません。

これはまれなエッジケースではありません。870万のアカウントを監視した縦断的な研究は、Twitter のユーザーのおよそ10%が時間とともにハンドルを変えることを見つけました（Jain と Kumaraguru、IIIT-Delhi）。2023年の料金の見直しの後に企業が公式 X API から移るのを支援してきた実地の作業でも、ハンドルの入れ替わりは、見つかった最もよくある静かなデータ破損の問題の1つでした。いくつかのクライアントは、ハンドルを外部キーとして保存する監視ダッシュボードを動かしており、追跡していた競合がリブランドすると、ダッシュボードは、古いハンドルを拾った完全に無関係なアカウントからツイートをうれしそうに収集し続けました。

ユーザー ID は、アカウント作成時に割り当てられる64ビット整数です。変えられず、転送できず、プラットフォーム全体で一意で、そしてすべての信頼できる X データパイプラインが構築される結合キーです。

ハンドルの変更はシステムを壊しません。 アカウントが1回でも50回でも改名しても、ID は同じプロフィールを指します。
インデックスがより速いです。 整数のインデックスは可変長の文字列よりストレージ効率が良く、数値の主キーでの照会は、あらゆる規模でユーザー名での照会に勝ります。
時間をまたいだ結合がきれいなままです。 異なる時点で収集されたデータセットにまたがってアカウントを一致させるとき、ID が唯一の安全なキーです。何年もまたいだハンドルの一致は、静かに2人の異なる人を一致させ得ます。
いくつかのエンドポイントは ID を必要とします。 Sorsa の /info-batch は user_ids を受け付け、リストとコミュニティのエンドポイントは数値の ID でアカウントを参照し、ほとんどの公式 X API エンドポイントも同様に数値の ID を期待します。

本記事から1つ持ち帰るなら：データベースにはハンドルではなく ID を保存します。ハンドルは、古くなり得るキャッシュされた表示データとして扱います。

ID を整数ではなく文字列として保存する

Twitter のユーザー ID は、数字に見えても、文字列として保存し転送します。現代の19桁の Snowflake ID は JavaScript の安全な整数の限界（Number.MAX_SAFE_INTEGER、これは2^53 - 1、つまり9,007,199,254,740,991）を超えるため、ID をネイティブの JS の数値にパースすると、最後の数桁が静かに丸められ破損します。同じリスクは、64ビットの値が32ビットや浮動小数点の型に着地するどこにでも現れます。ID を文字列の列か64ビットの BIGINT に保ち、デフォルトの int や JavaScript の number には決して入れません。Sorsa API がまさにこの理由で、すべての ID を JSON の文字列として返します。

Twitter のユーザー ID がどう生成されるか {#how-twitter-user-ids-are-generated}

Twitter は、分散システムの問題を解決するために、2010年に ID 生成システム Snowflake を構築しました。Twitter の規模では、すべての新しいツイート、メッセージ、アカウントについて中央のデータベースに「次の ID は何か？」と尋ねることは機能しません。Snowflake は、3つの値を組み合わせることで、どのサーバーもグローバルに一意な64ビット整数を、協調なしに独立に鋳造させます。

タイムスタンプ（41ビット）： Twitter エポック（2010-11-04 01:42:54.657 UTC）以降のミリ秒。
ワーカー／マシン ID（10ビット）： ID を生成したサーバーを識別します。
シーケンス番号（12ビット）： 同じミリ秒の中で増分し、マシンあたりミリ秒あたり最大4,096の ID をサポートします。

符号ビットを加えて、合計64ビットになります。タイムスタンプが最上位ビットに座るため、Snowflake ID はおおむね時間でソート可能で、それがツイート ID を比較したとき時間順である理由です。

ほとんどのコンバーターのページが間違えるユーザー ID の細部

ほとんどの ID コンバーターのページが不正確に述べる点があります。ツイート ID は2010年に Snowflake になりましたが、X はユーザー ID を Snowflake 形式に2016年2月まで切り替えませんでした。そして多くのページが間違った日付（しばしば2020年）をいまだに繰り返します。X 自身の 64ビット ID 移行の発表によると、Snowflake ID は2016年2月1日にユーザー、リスト、保存された検索に展開され始めました。それより前、X は何年も短い、連番の整数のユーザー ID を配りました。それが、Jack Dorsey のアカウントが 12 である理由で、切り替えの前に作成されたアカウントが短い、低い ID を持ち、その後に作成されたアカウントが長い、18〜19桁の Snowflake ID を持つ理由です。

実用的な帰結：任意のツイート ID から作成のタイムスタンプを抽出できますが、古いユーザー ID から登録日を確実には抽出できません。2016年より前のユーザー ID は埋め込まれたタイムスタンプを運ばないからです。古いアカウントの参加日が必要なら、プロフィールから created_at フィールドを直接読むか、素早い単発の照会にはアカウント年齢チェッカーを使います。

Twitter のユーザー ID の見つけ方 {#how-to-find-a-twitter-user-id}

X はそのインターフェースのどこにもユーザー ID を表示しないため、導出しなければなりません。労力のおおまかな順で、3つの実用的な経路があります。

手動の方法（遅い）。 プロフィールを開き、ページソース（Ctrl+U または Cmd+U）を表示し、HTML で user_id または rest_id を検索します。またはブラウザの開発者ツール（F12）を開き、Network タブを見て、更新し、API レスポンスから ID を読み出します。両方とも単一のアカウントには効きますが、退屈で、X がマークアップを組み替えるたびに壊れ、ひと握りの照会を超えてスケールしません。

無料のコンバーター（単発）。 ハンドル、ID、またはプロフィール URL を照会ツールに貼り付け、結果を読みます。Sorsa の ID コンバーターの playground は、サインアップも API キーもなしにブラウザで3つの方向すべてを扱い、正しいアカウントを持っていることを確認できるようプロフィールも返します。停止された、削除された、または存在しなかったアカウントは not-found の結果を返し、保護された（非公開の）アカウントは ID を返しますが統計は限定的です。

API（規模で）。 いくつかを超えるアカウントを解決する必要があるとき、またはパイプラインの中で無人で照会を実行するとき、変換エンドポイントを直接呼びます。以下のコードが3つすべての操作を Python で示します。

3つの変換操作 {#the-three-conversion-operations}

必要になる変換操作はちょうど3つです。

持っているもの	欲しいもの	すること
ユーザー名（ハンドル、`@` あり／なし）	数値のユーザー ID	ハンドルを ID に解決
数値のユーザー ID	現在のユーザー名	ID をハンドルに解決
プロフィール URL（`x.com/username` または `twitter.com/username`）	数値のユーザー ID	URL からハンドルを抽出し、ID に解決

各操作は単一の API 呼び出しです。Sorsa のようなサードパーティ API を使うとき、どれも OAuth、コールバック URL、またはアプリ承認を必要としません。サードパーティのキーが公式の開発者アカウントのフローを完全に置き換えるため、提出すべき申請も、待つべきものもありません。開発者アカウントなしで X API を使うガイドで扱う同じ経路です。3つすべての Python と curl の例は以下のコードのセクションにあり、それぞれが文書化されたエンドポイントに対応します。ユーザー名から ID、ID からユーザー名、そしてプロフィールリンクから ID です。

ツイートには同等の操作はありません。ツイート ID はツイートの URL（x.com/user/status/1234567890）に直接見えるため、照会を呼ぶのではなく URL の文字列からそれをパースします。

代わりに /info エンドポイントを使うとき

ユーザー ID と完全なプロフィール（表示名、フォロワー数、プロフィール文、アバター URL）の両方が必要なら、/username-to-id を呼んでから /info を別々に呼ばないでください。/info?username=... を直接呼びます。それは、id フィールドを含む完全なプロフィールを1回のリクエストで返します。それを2つの呼び出しに分けることは、コードレビューでよく見かける、最もありがちなコストの間違いの1つです。より大きな量では、/info-batch が最大100件のプロフィールを1つのリクエストにまとめ、それが完全なプロフィールと並んで ID を取得するコストを、バッチ価格のプランで1,000プロフィールあたり$0.01からにします。

2026年に ID 変換はいくらかかるか？ {#how-much-does-id-conversion-cost-in-2026}

料金は今年大きくシフトしました。2026年2月、X は API を新規開発者のデフォルトとして従量課金のクレジットモデルに移し、古い Basic と Pro の層を置き換えました。公式 X API でのユーザー名から ID への照会はユーザー読み取りで、返されたリソースあたり約$0.010で課金され、それは1,000変換あたり約$10.00になります。内部ツールの中のたまの照会には、それで問題ありません。バッチや繰り返しのジョブには、コストが速く積み上がります。100,000のハンドルの解決は、公式 API クレジットでおよそ$1,000かかります。

Sorsa では、3つの変換エンドポイントのそれぞれが1つのフラットなリクエストと数えるため、コストは1,000変換あたり$1.80からに着地し、すべての新規キーは、まずワークフローをテストする100回分の無料リクエスト（1回限り、クレジットカード不要・有効期限なし、40個のエンドポイントすべて）で始まります。

	Sorsa Starter	Sorsa Pro	公式 X API（従量課金）
課金単位	1リクエスト（フラット）	1リクエスト（フラット）	返されたリソース単位
変換あたりのコスト	$0.0049	$0.00199	約$0.010（ユーザー読み取り）
1,000変換あたりのコスト	$4.90	$1.99	約$10.00
含まれる月次リクエスト	10,000	100,000	なし、クレジットを買う
100,000変換	Proプランを使う	フラットで月額$199から	クレジットで約$1,000
認証	API キーヘッダー	API キーヘッダー	OAuth 2.0
セットアップ	約30秒	約30秒	アプリにクレジット購入

変換あたり、Proプランは公式 API のおよそ5分の1のコストになり、バッチすればギャップは広がります。/info-batch を通じたプロフィール照会は最大100アカウントを単一のリクエストにまとめます。公式モデルが今年どう変わったかの全体像は、Twitter API 料金の内訳となぜ公式 API はこれほど高いかの理由をご覧ください。Sorsa 側のプランの詳細は料金ページにあります。

公式側の正直な但し書きが1つ：その最も安い読み取り層、リソースあたり$0.001の自己所有の読み取りは本当に競争力がありますが、アプリが固定のエンドポイントのセットを通じて自分のアカウントのデータを読むときにのみ適用されます。任意のサードパーティのアカウントのハンドルから ID への照会は、標準のユーザー読み取りレートで課金される非所有の読み取りなので、本ガイドが扱う変換の作業には、フラットなリクエスト単位のモデルが先を行き続けます。

Sorsa API での変換 {#converting-with-the-sorsa-api}

認証は単一のヘッダーです。ApiKey: YOUR_API_KEY。OAuth フローも、スコープも、コールバックもありません。3つの操作のそれぞれが1つの文書化されたエンドポイントに対応し、同じキーを共有します。

python

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}


def username_to_id(handle: str) -> str:
    """Resolve a handle (without @) to its permanent numeric user ID."""
    resp = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["id"]  # returned as a string, keep it that way


def id_to_username(user_id: str) -> str:
    """Resolve a numeric user ID to the account's current handle."""
    resp = requests.get(f"{BASE}/id-to-username/{user_id}", headers=HEADERS)
    resp.raise_for_status()
    return resp.json()["handle"]


def link_to_id(profile_url: str) -> str:
    """Extract the numeric user ID from a full profile URL."""
    resp = requests.get(
        f"{BASE}/link-to-id",
        headers=HEADERS,
        params={"link": profile_url},
    )
    resp.raise_for_status()
    return resp.json()["id"]


# Examples
print(username_to_id("elonmusk"))                    # "44196397"
print(id_to_username("44196397"))                    # "elonmusk"
print(link_to_id("https://x.com/elonmusk"))          # "44196397"

最初の呼び出しの curl 相当：

bash

curl "https://api.sorsa.io/v3/username-to-id/elonmusk" \
  -H "ApiKey: YOUR_API_KEY"
# {"id": "44196397"}

規模でのバッチ変換 {#batch-conversion-at-scale}

競合のハンドルのスプレッドシート、CRM のエクスポート、または監視パイプラインの種となるアカウントのリストがあるとき、それらすべてを1回のパスで ID に変換する必要があります。以下のパターンは、リトライのロジック、ソフトなレート制限（Sorsa はすべてのプランでキーあたり毎秒20リクエストを許可）、そして停止された、または削除されたアカウントの優雅な処理を加えます。API の残りにまたがるページネーション、バッチ処理、エラー処理の Python でのより広いカバレッジは、Twitter API Python ガイドをご覧ください。

python

import requests
import time
from typing import Iterable

API_KEY = "YOUR_API_KEY"
BASE = "https://api.sorsa.io/v3"
HEADERS = {"ApiKey": API_KEY}


def batch_username_to_id(handles: Iterable[str], pause: float = 0.05) -> dict[str, str | None]:
    """
    Resolve a list of handles to user IDs.

    Returns a dict mapping handle -> id (or None if the lookup failed).
    Soft rate limit: ~20 req/s, well under Sorsa's per-key cap.
    """
    results: dict[str, str | None] = {}

    for handle in handles:
        handle = handle.strip().lstrip("@")
        try:
            resp = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS, timeout=10)
            if resp.status_code == 200:
                results[handle] = resp.json()["id"]
            elif resp.status_code == 404:
                results[handle] = None  # Account does not exist or is suspended
            elif resp.status_code == 429:
                time.sleep(1)  # Back off and retry once
                retry = requests.get(f"{BASE}/username-to-id/{handle}", headers=HEADERS, timeout=10)
                results[handle] = retry.json()["id"] if retry.status_code == 200 else None
            else:
                results[handle] = None
        except requests.RequestException:
            results[handle] = None

        time.sleep(pause)

    return results


handles = ["NASA", "SpaceX", "Tesla", "OpenAI", "stripe"]
id_map = batch_username_to_id(handles)

for handle, uid in id_map.items():
    print(f"@{handle:<10} -> {uid or '(not found)'}")

逆方向も同じように動きます。URL を /id-to-username/{user_id} に入れ替え、レスポンスから handle フィールドを読みます。

混在した入力の正規化 {#normalizing-mixed-input}

よくある状況：アプリケーションが、ソースがたまたま生成するどんな形式でも、エンドユーザーや上流のシステムからアカウントの参照を受け付けます。一部のエントリーは素のハンドル、一部は @ 付き、一部は完全な URL、一部はすでに数値の ID です。以下の正規化器は、4つの形すべてを安定したユーザー ID に折りたたみ、入力がすでに ID のときは API 呼び出しを完全に飛ばします。

python

def normalize_to_id(value: str) -> str:
    """
    Accept any of:
      - "elonmusk"
      - "@elonmusk"
      - "https://x.com/elonmusk"
      - "https://twitter.com/elonmusk"
      - "44196397"
    Returns the numeric user ID as a string.
    """
    value = value.strip().lstrip("@")

    # Already a numeric ID, no API call needed
    if value.isdigit():
        return value

    # Profile URL
    if "x.com/" in value or "twitter.com/" in value:
        return link_to_id(value)

    # Bare username
    return username_to_id(value)


# All four return the same ID
for source in ["elonmusk", "@elonmusk", "https://x.com/elonmusk", "44196397"]:
    print(f"{source:<35} -> {normalize_to_id(source)}")

これを、あらゆる取り込みパイプラインの最初のステップとして使います。入力がどれだけ雑然としていても、下流のロジックがつねに安定した識別子で動くことを保証します。

ハンドルの変更を検出する {#detecting-handle-changes}

収集時にユーザー ID とハンドルの両方を保存していたなら、定期的に ID を再解決して、どのアカウントが改名したかを検出できます。これは、古い表示名を保持しているかもしれないデータベースを更新するワークフローです。

python

def detect_renames(records: list[dict]) -> list[dict]:
    """
    records: list of {"user_id": str, "stored_handle": str}
    Returns: list of {"user_id", "old_handle", "new_handle"} for renamed accounts.
    """
    changes = []
    for record in records:
        try:
            current = id_to_username(record["user_id"])
        except requests.HTTPError:
            continue  # Account deleted, suspended, or transient error

        if current and current.lower() != record["stored_handle"].lower():
            changes.append({
                "user_id": record["user_id"],
                "old_handle": record["stored_handle"],
                "new_handle": current,
            })
        time.sleep(0.05)

    return changes


db_records = [
    {"user_id": "44196397", "stored_handle": "elonmusk"},
    {"user_id": "1234567890", "stored_handle": "old_brand_name"},
]

for change in detect_renames(db_records):
    print(f"Renamed: @{change['old_handle']} -> @{change['new_handle']} (ID {change['user_id']})")

より豊かな改名の監査には、/about エンドポイントが username_change_count と last_username_change_at を返します。それは、現在のハンドルだけでなく、アカウントが何回改名したか、そして最新の変更がいつ起きたかを教えます。

実践 {#in-practice}

あるおよそ12人規模のソーシャル分析チームが、追跡していた競合がリブランドし、そのダッシュボードが誰も気づく前に3週間近く見知らぬ人のツイートを静かに取り込んだ後に、Sorsa に相談してきました。根本原因は古典的なものでした。ハンドルをキーとして保存していたのです。修正は巧妙というより構造的でした。取り込み時にすべてのハンドルをそのユーザー ID に解決し、ID をキーとして保存し、ハンドルを表示専用に保ち、そして改名を捕まえるスケジュールされた再解決を実行する（上の detect_renames のパターン）です。

コスト側も重要でした。このチームの月次のハンドル解決の量は、公式 X API のユーザー読み取りクレジットで$1,000近くで動いていました。100,000リクエストでフラットに$199の Proプランでは、それは予測しやすい項目になり、そのワークロードでおよそ5分の1へのコスト削減となり、/info-batch を通じたバルクのプロフィール照会が最大100アカウントを1つのリクエストに詰め込むため余分な余裕がありました。信頼性の面での成果、つまりもう静かなアカウント間の破損がないことが、このチームが最も気にした部分でした。

始め方 {#getting-started}

これを試す3つの方法：

ノーコード、サインアップなし。 ID コンバーターの playground を開き、任意のハンドル、ID、またはプロフィール URL を貼り付けます。単発の照会と、コードを書く前にアカウントが存在することを確認するのに有用です。
100回分の無料リクエスト付きの API キー。 無料アカウントを作成すると、すべてのキーが100回分の無料リクエスト（1回限り、クレジットカード不要・有効期限なし、40個のエンドポイントすべて）で始まります。キーを ApiKey ヘッダーに落とし込めば、上の Python の例がそのまま動きます。有料プランは Starter で変換あたり$0.0049から始まり、Pro で$0.00199に下がり、一律の毎秒20リクエストがすべてのプランで適用されます。
すでに公式 X API を使っている？ 移行ガイドが各公式のエンドポイントをその Sorsa 相当物に対応付け、Twitter API の代替の概要がトレードオフを扱います。

ここの3つの変換エンドポイントは、プロフィール、ツイート、フォロワー、検索、検証をカバーする40エンドポイントの読み取り専用 API の一部です。

よくある質問 {#frequently-asked-questions}

Twitter（X）のユーザー ID とは？

Twitter のユーザー ID は、X アカウントが作成されるときに割り当てられる一意な64ビット整数です。永続的です。変えられず、転送できず、再割り当てされません。いつでも編集できるユーザー名（ハンドル）と異なり、ユーザー ID はそのアカウントの生涯にわたって同じアカウントに付いたままで、それが開発者がそれを任意のアカウント参照の安定したキーとして使う理由です。

自分の Twitter のユーザー ID をどう見つける？

X のインターフェースはユーザー ID をどこにも表示しません。それを見つけるには、ハンドルやプロフィール URL を Sorsa の ID コンバーターのようなコンバーターに貼り付けるか、ハンドルを照会エンドポイントに送ります。アカウント設定から X のデータアーカイブをダウンロードすることもでき、それはアカウントのメタデータにユーザー ID を含みます。

Twitter のユーザー ID は変わり得る？

いいえ。Twitter のユーザー ID はアカウント作成時に割り当てられ、アカウントの生涯にわたって永続的です。アカウントの改名、表示名の変更、メールアドレスの切り替え、または停止されてから復活することは、ユーザー ID を変えません。変わる唯一のものは、ハンドルと ID の間のリンクで、それはハンドル自体が変えられ古いハンドルが別の誰かが主張できるようになるときにシフトします。

なぜ一部の Twitter のユーザー ID は短く、他は非常に長いのか？

X は初期のアカウントに短い、連番の整数の ID を割り当て、それが Jack Dorsey のアカウントが 12 である理由で、ユーザー ID を64ビットの Snowflake 形式に2016年2月に切り替えただけです。その切り替えの前に作成されたアカウントは短い、低い ID を持ちます。その後に作成されたアカウントは、上位ビットに作成のタイムスタンプをエンコードする、約18〜19桁の長い Snowflake ID を持ちます。

ユーザー ID から登録日をデコードできる？

2016年2月の Snowflake の切り替えの後に作成されたアカウントには、はい。ID を22ビット右にシフトし、Twitter エポック（1288834974657）を加えると、ミリ秒での作成のタイムスタンプが得られます。連番の2016年より前の ID を持つ古いアカウントには、それらの ID が埋め込まれたタイムスタンプを運ばないため、いいえです。その場合はプロフィールを取得して created_at フィールドを直接読みます。

API キーを必要としない無料の Twitter ID コンバーターはある？

はい。Sorsa の ID コンバーターの playground は、API キーもサインアップもなしにブラウザで3つの操作すべて（ハンドルから ID、ID からハンドル、プロフィール URL から ID）を扱い、アカウントを確認できるようプロフィールを返します。単発の照会のために作られています。バッチのジョブ、繰り返しのパイプライン、または無人で動く何かには、API キーがよりよく合い、すべての新規キーは、支払う前にバッチをテストできるよう100回分の無料リクエスト（1回限り、クレジットカード不要）で始まります。

開発者は数千のユーザー名を規模でどう ID に変換する？

大量の作業には、Sorsa API が3つの変換エンドポイント（/username-to-id、/id-to-username、/link-to-id）を、変換あたりフラットな1リクエストで公開します。100,000リクエストで月額$199の Proプランでは、各変換は約$0.002で、公式 API のリソース単位のレートのおよそ5分の1のコストです。スループットはキーあたり毎秒20リクエストに上限が設けられ、自分のコードが通常 API ではなくボトルネックであるほど十分に高いです。

ユーザー ID とツイート ID の違いは？

どちらも64ビットの Snowflake スタイルの整数ですが、別々の名前空間に住み、異なるものを識別します。ユーザー ID はアカウントを識別し、ツイート ID（ステータス ID とも呼ばれる）は単一の投稿を識別します。ツイート ID はツイートの URL（x.com/user/status/{tweet_id}）に直接見えるため、それらには照会は要りません。ユーザー ID は X のインターフェースのどこにも公開されず、それが専用の変換エンドポイントが存在する理由です。

監修：Keksich（Sorsa創業者、マーケター兼X APIリサーチャー）

本ガイドのまとめ方：代替の Twitter/X API をビルドして運用する Sorsa 自身の実地の作業と、稼働中の変換エンドポイントに対する直接のテストに基づいており、エンドポイントの挙動には Sorsa API のドキュメントと、現行の従量課金レートには公式の X API 料金の発表と突き合わせました。Snowflake の構造は Twitter の元のエンジニアリングの投稿から、2016年2月のユーザー ID の切り替えは X の 64ビット ID 移行の発表から、そしてユーザー名の入れ替わりの数字は Jain と Kumaraguru の縦断的な研究から得ました。料金とレートの数字は2026年7月確認。運営元の詳細は会社概要ページにあります。

Twitter ID コンバーター：ユーザー名・ユーザー ID・プロフィールリンク

目次

なぜユーザー ID が信頼できる唯一の識別子か {#why-user-ids-are-the-only-identifier-you-can-trust}

ID を整数ではなく文字列として保存する

Twitter のユーザー ID がどう生成されるか {#how-twitter-user-ids-are-generated}

ほとんどのコンバーターのページが間違えるユーザー ID の細部

Twitter のユーザー ID の見つけ方 {#how-to-find-a-twitter-user-id}

3つの変換操作 {#the-three-conversion-operations}

代わりに /info エンドポイントを使うとき

2026年に ID 変換はいくらかかるか？ {#how-much-does-id-conversion-cost-in-2026}

Sorsa API での変換 {#converting-with-the-sorsa-api}

規模でのバッチ変換 {#batch-conversion-at-scale}

混在した入力の正規化 {#normalizing-mixed-input}

ハンドルの変更を検出する {#detecting-handle-changes}

実践 {#in-practice}

始め方 {#getting-started}

よくある質問 {#frequently-asked-questions}

Twitter（X）のユーザー ID とは？

自分の Twitter のユーザー ID をどう見つける？

Twitter のユーザー ID は変わり得る？

なぜ一部の Twitter のユーザー ID は短く、他は非常に長いのか？

ユーザー ID から登録日をデコードできる？

API キーを必要としない無料の Twitter ID コンバーターはある？

開発者は数千のユーザー名を規模でどう ID に変換する？

ユーザー ID とツイート ID の違いは？

関連記事

【2026年版】Xでコメント（リプライ）を見る方法

【2026年版】Twitter のレート制限超過：原因と対処法

Twitter を日付で検索する方法：コマンド・ツール・API