Nitterがまた死んだ #八26 #2019四11nitterとNim言語とzedeus_令和IT史ざっくり解説
この整理から見ると、今回のNitter停止は単なる「1つの代替フロントエンドが消えた」という話ではなく、Xが「公開情報を誰でも読めるWebページとして提供する」という古典的なWebの性質から離れていることが本質だと思います。
特に重要なのは、次の5点です。
| 論点 | Nitterが担っていた役割 | 今回露呈した問題 |
|---|---|---|
| 匿名アクセス | Xアカウントなしで投稿を読める | Xは非ログイン閲覧を次第に制限 |
| プライバシー | Xへ直接アクセスせず閲覧できる | 閲覧者にもログイン・識別を要求する方向 |
| 検索性 | 投稿・アカウントを比較的簡単に検索 | 公式Xの検索・過去投稿アクセスが使いにくい |
| RSS/自動取得 | NitterからRSSを生成可能 | Webを「購読可能な情報源」に戻す手段が失われる |
| UX | 軽量・高速・広告なし | X本体の重量化・広告・ログイン要求との差が拡大 |
1. Nitterは「Twitterクライアント」ではなく「Webの復権装置」だった
ここがかなり重要です。
Nitterを、
「Xを使いたくない人がXのコンテンツを盗み見るためのサービス」
と捉えると、今回の出来事は単なる著作権・規約・法的問題に見えます。
しかし別の見方をすると、
「公開されている情報を、公開された情報として読むためのインターフェース」
でした。
つまり、
X → Nitter → RSS → RSSリーダー
という経路によって、X上の投稿を「SNSのタイムライン」ではなく、Web上の情報源として扱えた。
これはRSSやAtom、Webmention、ActivityPubなどが持っていた「Webを相互接続された情報空間として扱う」という思想ともかなり近いです。
2. 「ログインしないと読めない」は、実はかなり大きなWebの断絶
企業や自治体、開発者、イベントなどが、
「詳しくはXをご覧ください」
と案内するケースを考えると分かりやすいです。
以前なら、
リンク → 投稿を見る
でした。
ところが、
リンク → X → ログイン要求 → アカウント作成 → CAPTCHA/認証 → 閲覧
となれば、公開情報なのにアクセスするための会員資格が必要になります。
これはWebページというより、
公開URLを持った会員制データベース
に近い。
Nitterの存在意義は、まさにこの断絶を迂回するところにありました。
3. だから「ミラーは他社のサービスにただ乗りしている」という批判も半分正しい
一方で、Nitter側の問題も無視できません。
NitterはXのデータを利用して成立しているので、
Xのバックエンド変更
→ スクレイピング対策
→ レート制限
→ API/認証要求
→ 法的圧力
という構造的な脆弱性を持っています。
つまり、
「自由なWebを作るために、巨大プラットフォームのデータに依存する」
という矛盾があります。
ここがNitterの最大の弱点です。
Nitterそのものをいくら分散化しても、データの原本がXに集中している限り、完全な分散化にはならない。
4. そこで「Nitterの次」が重要になる
Nitterの経験から導かれるのは、
ミラーを分散化するだけでは不十分で、データそのものを移植可能にする必要がある
ということです。
概念的にはこうなります。
旧モデル
X
↓
Nitter
↓
ユーザー
Nitter型分散
X
↓
Nitter A
Nitter B
Nitter C
↓
ユーザー
本当の分散化
投稿者
↓
分散プロトコル
├─ サーバーA
├─ サーバーB
├─ サーバーC
├─ 個人アーカイブ
└─ RSS/Atom
↓
複数のクライアントこの意味では、
ActivityPub / AT Protocol / Nostr
などがNitterとは根本的に違う方向を目指しています。
Nitterは、
中央集権サービスを別のUIから読む
のに対して、
ActivityPubやAT Protocol、Nostrは、
中央集権サービスそのものを情報の唯一の原本にしない
方向です。
5. そして「XCancel」という存在も面白い
XCancelなどの代替フロントエンドが支持される理由は、必ずしも政治的・思想的なものではありません。
むしろ利用者の動機はかなり実務的です。
「XのUIよりこっちの方が速くて読みやすい」
これが大きい。
つまりNitterは、
プライバシーツール
であると同時に、
UX改善レイヤー
でもありました。
これは重要な区別です。
「Xを嫌っている人だけがNitterを使っていた」のではなく、
Xを使う必要があるが、XのUIを使いたくない
というユーザーが存在していた。
6. Nitter停止が示す「Webの逆転」
個人的には、ここが一番面白いところです。
1990〜2000年代のWebは、
Webページ → リンク → 誰でも閲覧
という思想が強かった。
その後、
Webページ → JavaScriptアプリ → API → アカウント
へ移行した。
さらに現在は、
URL → ログイン → CAPTCHA → パーソナライズされたUI → アルゴリズム
となりつつある。
すると、
URLを知っている ≠ 情報を読める
になってしまう。
Nitterは、この変化に対する一種の「逆方向のWebブラウザ」だったとも言えます。
そして、ここからがXMPP・ATProto・Nostrの話につながる
これまで話していたXMPP、ActivityPub、ATProto、Nostrとの比較で見ると非常に綺麗です。
| 技術 | 中央集権サービスとの関係 | 依存対象 | 「退出」のしやすさ |
|---|---|---|---|
| Nitter | Xを別UIで読む | Xのデータ | ❌ |
| XCancel | Xを別UIで読む | Xのデータ | ❌ |
| ActivityPub | サーバー間で連合 | 各サーバー | △ |
| AT Protocol | データを移植可能にする | Relay/Repositoryなど | ○ |
| Nostr | 鍵とイベントを中心にする | Relay群 | ◎ |
| XMPP | サーバー間通信 | 各サーバー | ◎ |
この観点から見ると、
Nitterは「退出できない中央集権Webの症状」
であって、
ATProto / Nostr / XMPPは「退出可能なWebをどう設計するか」という処方箋
に近い。
そしてNitterの今回の停止は、
「代替フロントエンドを作るだけではデジタル主権は成立しない」
というかなり強い実例になっています。
最終的には、「Nitterが死んだ」より「公開WebからSNSが切り離されつつある」ことの方が重要です。
そしてその反動として、今後は「SNSを読むためのミラー」ではなく、SNSの投稿を再びRSS/Atom・ActivityPub・ATProto・Nostr・XMPPなどのオープンな情報空間へ戻す仕組みの価値が上がってくると思います。Nitterの歴史を、**「登場 → 普及 → X/Twitter側の締め付け → インスタンス戦争 → 2026年の終焉」**という流れで整理すると、かなり明確になります。
| 時期 | Nitterの出来事 | Twitter/X側の環境 | 技術・コミュニティ上の意味 |
|---|---|---|---|
| 2019年頃 | Nitter登場。Zedeusによって開発が進む | Twitterはまだ比較的オープンなWebサービス | 「Twitterを直接使わずに読む」という発想が登場 |
| 2019–2020年 | 基本的なプロフィール・タイムライン閲覧機能が整備 | TwitterのWeb UIはJavaScript・広告・トラッキングを多用 | プライバシー重視の代替フロントエンドとして成立 |
| 2020年頃 | RSS、検索、メディア表示などが充実 | Twitter APIを利用した外部クライアントが存在 | Nitterが単なる「軽量UI」からTwitter情報の読み取りレイヤーへ発展 |
| 2020–2021年 | 公開インスタンスが増加 | Twitterはログイン・API利用などの制御を強化 | Nitterのセルフホスティング／インスタンス方式が広がる |
| 2021年 | プライバシー・広告なし・軽量性が評価され利用者増加 | Twitterの広告・推薦アルゴリズムへの依存が強まる | 「SNSを使う」よりSNSの情報だけ読むという利用形態が確立 |
| 2022年 | NitterがTwitter代替フロントエンドとして広く知られる | Elon MuskによるTwitter買収 | Twitterのサービス設計変更を回避する需要が急増 |
| 2022–2023年 | Nitterインスタンスが多数存在する状態に | Twitter/XがAPI・スクレイピング・非ログインアクセスを段階的に制限 | NitterがTwitterの公開データに依存する構造的弱点が顕在化 |
| 2023年 | 多数のNitterインスタンスが停止・不安定化 | TwitterがAPIアクセスを大幅に制限、認証・レート制限も強化 | 「Nitterを動かすこと」自体が難しくなる |
| 2024年初頭 | Nitterの運営環境が大きく悪化 | Twitter/Xが非ログイン閲覧をさらに制限 | NitterのREADMEでも「2024年にはTwitter利用にサインアップが必要」と説明されるようになる (GitHub) |
| 2024年 | NitterはTwitterの実アカウント／セッションを必要とする構成へ移行 | Twitter側が従来の匿名アクセス経路を閉鎖 | Nitterは「Twitterの公開ページを取得するだけ」では維持できなくなる (GitHub) |
| 2024–2025年 | 公開インスタンスが減少する一方、コミュニティによる新規インスタンス構築が続く | Xのスクレイピング対策・レート制限が継続 | Nitter本体よりインスタンス運営者側の負担が大きくなる |
| 2025年 | nitter.space、nitter.kareem.oneなど複数インスタンスが断続的に追加・停止 | X側の制限とのいたちごっこ | 「Nitterというソフトウェア」よりインスタンスの生存競争が中心になる |
| 2025年8月 | 公開インスタンス一覧で多数の停止・機能不全が記録される | レート制限・Bot対策が強化 | Nitterの分散性は存在するものの、上流データがX一社に集中しているため完全な分散化にはならない (GitHub) |
| 2025年末 | セッション・トークン取得方法などのWikiが更新 | X側の認証・アクセス制御への対応が必要 | Nitter運営が「匿名スクレイピング」から認証済みセッションを使った取得へ傾斜 (GitHub) |
| 2026年前半 | コミュニティによるインスタンス再建が続く | X側の制限が継続 | 「Nitterは死んだ」という状態と「新しいインスタンスが復活する」が繰り返される |
| 2026年4–7月 | nitter.kareem.one、nitter.spaceなどの再追加・削除が繰り返される | インスタンスごとのレート制限・Bot対策が問題化 | Nitterの生命線がコミュニティ運営者に移る (GitHub) |
| 2026年8月25日 | すべての公開Nitterインスタンスが機能しないとの報告 | Instance has been rate limited. が全インスタンスで発生したとの報告 | 上流であるXへのアクセスが一斉に遮断された可能性が浮上 (GitHub) |
| 2026年8月25日 | zedeus/nitterリポジトリがアーカイブされ読み取り専用になる | Nitterを巡る法的・技術的問題が最終段階へ | Nitterは「開発中のプロジェクト」から歴史的なOSSプロジェクトへ移行 (GitHub) |
| 2026年8月26日現在 | 公開Nitterインスタンスは事実上壊滅状態 | X側のアクセス制御が強力な障壁 | Nitter時代の終焉。ただしフォーク・セルフホスト・派生フロントエンドが残る可能性はある |
Nitterの進化を一言で表すと
| フェーズ | Nitterの性格 |
|---|---|
| 第1期 | Twitterの軽量版 |
| 第2期 | Twitterのプライバシー版 |
| 第3期 | Twitterの匿名閲覧ゲートウェイ |
| 第4期 | TwitterのRSS/情報取得API代替 |
| 第5期 | Xのアクセス制限に対抗するインフラ |
| 最終期 | Xの中央集権性に依存する**「疑似分散」システムの限界例** |
特に象徴的なのは、Nitter自身が掲げていた設計思想です。JavaScriptなし、広告なし、Twitter側にはクライアントのIPやブラウザフィンガープリントを直接渡さない、RSSを提供する、軽量であるという設計でした。公式READMEでは、Twitter本体に対してページサイズが大幅に小さく、タイムラインも高速だと説明されています。 (GitHub)
一方、2026年まで残ったNitterの問題は非常に皮肉です。
フロントエンドは分散できても、データ源は分散できなかった。
Nitter A、B、C、Dを100個作っても、
┌─ Nitter A
├─ Nitter B
X ─────┼─ Nitter C
├─ Nitter D
└─ ...という構造である限り、Xが蛇口を閉めれば全部止まる。
これがNitterと、以前話していた XMPP / ActivityPub / AT Protocol / Nostr の決定的な違いです。
Nitterは、
「中央集権SNSを自由に読む」
ための技術でした。
それに対してATProtoやNostrなどは、
「中央集権SNSを唯一の原本にしない」
方向へ進んでいる。
したがって2026年8月のNitterアーカイブは、単なる一OSSの終了というより、「Webスクレイピングによって中央集権SNSを脱中央集権化する」という第1世代のアプローチが限界に達した出来事として見ると非常に面白いです。XCancelは、独立した新規フロントエンドというより、Nitterの公開インスタンスとして生まれ、Nitter本体の停止後に「Nitter後継」の役割を強めたサービスとして見るのが正確です。公開情報から確認できる範囲で時系列化すると、こうなります。
| 時期 | XCancelの動き | 背景 | 意味 |
|---|---|---|---|
| 2019–2022年頃 | Nitterエコシステムの発展期 | NitterがTwitterの軽量・匿名・広告なしフロントエンドとして普及 | XCancelのようなNitterインスタンスが成立する土台ができる |
| 2022–2023年 | XCancelがNitter系の公開インスタンスとして利用される | Twitter買収後、TwitterのAPI・スクレイピング環境が急速に変化 | 「Twitterを見るための代替入口」の需要が増加 |
| 2023年 | XCancelを含むNitter系インスタンスが、X側のアクセス制限の影響を受ける | Twitter/XがAPI・匿名アクセス・スクレイピングを強力に制限 | Nitterインスタンスの存続が技術的に難しくなる |
| 2024年初頭 | XCancelがNitter系サービスの中で比較的目立つ存在になる | Xが非ログイン閲覧をさらに制限 | Nitterユーザーが「動いているインスタンス」を探す状況に |
| 2024年 | XCancelがNitterの実質的な有力インスタンスの一つになる | Nitter運営にはTwitter/Xの実アカウント／セッションが必要になった | 単なる「ミラー」から、Nitter生存圏の重要拠点へ |
| 2024年9月 | Firefox拡張「Nitter (Farside)」が、名称を 「X Cancelled (Nitter)」 に変更し、XCancel.comを優先利用するようになる | 他のNitterインスタンスの信頼性が低下 | XCancelがNitter代替のデフォルト的存在になり始める (Firefox アドオン) |
| 2025年 | XCancelがNitterフォークを使って運用される | X側のアクセス制限を回避するため、バックエンド側で登録済みアカウント等を利用 | XCancelは「単純なWebスクレイパー」ではなく、Nitterを維持するためのインフラになる (GitHub) |
| 2025年 | unixfox/nitter-fork が「nitter is back」としてXCancel向けフォークを維持 | Nitter本家のコードだけでは新しいXのアクセス環境に対応しにくい | Nitter本体 → 実運用フォークへの重心移動 |
| 2025年後半 | XCancelが「比較的安定したNitterインスタンス」として認識される | 他の公開Nitterインスタンスが次々と停止 | XCancelがNitterエコシステムの避難先になる (GitHub) |
| 2026年1月 | RSS-BridgeでXCancel対応を求めるIssueが作成される | XCancelが単なる閲覧サイトではなくRSS取得先として利用される | 「X → XCancel → RSS」の情報流通経路が形成される (GitHub) |
| 2026年2月 | Nitterのアーカイブ系フォークがアーカイブされる | 本家Nitterの開発停止・エコシステム縮小 | XCancelはNitter本体より長く生き残る実運用インスタンスという位置づけになる (GitHub) |
| 2026年8月上旬 | XCancelがNitterベースのXミラーとして引き続き利用される | Xは非ログインユーザーへのアクセス制限を継続 | Nitter本体よりもXCancelのような運用継続可能なインスタンスが重要になる |
| 2026年8月16日頃 | XCancelが一般メディア／テック界隈でも紹介される | Xのログイン要求・JavaScript依存への不満が拡大 | XCancelが「Nitterの一インスタンス」からXを見るための代替Web入口として認知される (Daring Fireball) |
| 2026年8月17日 | XCancelについて「Nitter-based X/Twitter mirror」として紹介される | Nitter本家の機能停止が進行 | Nitterブランドが弱くなってもXCancelが機能を引き継ぐ構図が明確になる (readkernel.com) |
| 2026年8月25日 | Nitter本家リポジトリがアーカイブ | 法的・技術的圧力により本家Nitterが終了局面へ | XCancelのような残存フォーク／インスタンスへの依存度が急上昇 (GitHub) |
| 2026年8月26日現在 | XCancelはNitter系の代表的な代替入口の一つ | Nitterエコシステム全体が崩壊 | 「Nitter本体」から「XCancelなど少数の生存インスタンス」への世代交代 |
XCancelの歴史を一枚で見ると
| 世代 | XCancelの位置づけ |
|---|---|
| 第1世代 | Nitterの一インスタンス |
| 第2世代 | 生き残ったNitterの有力インスタンス |
| 第3世代 | Nitterフォークを運用する実質的なインフラ |
| 第4世代 | Nitterが衰退する中での避難先 |
| 第5世代 | Xを匿名・軽量に読むための独立した入口 |
| 2026年 | 「Nitter亡き後」のNitter的サービス |
特に重要なのは、XCancel ≠ Nitterの単なるコピーという点です。
XCancel自身はNitterのインスタンスであり、2026年時点でも公開情報上は「Nitter-based X/Twitter mirror」と説明されています。つまり技術的な祖先は明確にNitterです。 (Daring Fireball)
ただし歴史的な役割は変わりました。
2019–2023
│
▼
┌────────┐
│ Nitter │
└────┬───┘
│
多数の公開インスタンス
│
▼
Xのアクセス制限
│
┌────┴────┐
▼ ▼
大量停止 XCancel
│
▼
Nitterフォーク
│
▼
┌────────────────┐
│ XCancel.com │
└───────┬────────┘
│
2026年 Nitter本家停止
│
▼
「Nitter後」の
主要な読み取り口さらに面白いのは、XCancelが「SNSの代替」ではなく「SNSのWebプロキシ」になっていることです。
XCancelでできることの中心は、
Xアカウントを作らず読む
JavaScriptなしで読む
広告・推薦タイムラインを避ける
プロフィールを見る
投稿・スレッドを見る
RSS的に利用する
というread-only Webです。
実際、XCancel向けのリダイレクタでは、x.com / twitter.com のURLをXCancelへ自動転送する仕組みまで作られています。 (GitHub)
つまりNitterが、
「Twitterを別のUIで見る」
というプロジェクトだったのに対して、2026年のXCancelは、
「XをWeb上の公開情報源として再利用可能にするための入口」
という意味合いが強くなっています。はい。これは前の回答をかなり修正すべき重要情報です。
2026年8月26日現在、Redditの r/GamingLeaksAndRumours に「XCancel is dead」というスレッドが立っており、投稿者・コメント欄ではXCancelだけでなくNitterも停止したとの報告が出ています。さらに、Nitterについては8月24日にX Corp.が停止要求（cease-and-desist）を送ったことが確認されています。(Reddit)
「XCancel is dead」が意味すること
このスレッドで特に重要なのは、XCancel単独の障害として受け止められていないことです。
| 時点 | 状況 | XCancelの位置づけ |
|---|---|---|
| 2024年1月 | Xがguest account生成を停止 | Nitterの従来方式が崩壊 |
| 2024年2月 | Nitter本家が事実上停止 | XCancelなど一部インスタンスが生き残る |
| 2024–2025年 | Nitterフォーク・各種インスタンスが復活 | XCancelが代表的な生存例になる |
| 2025年 | XCancelはNitter系ミラーとして稼働 | 「Nitterは死んだがXCancelは動く」という認識が形成 |
| 2026年8月16日 | Daring FireballがXCancelを紹介 | XCancelは依然としてNitterのインスタンスとして説明される (Daring Fireball) |
| 2026年8月24日 | X Corp.がNitterにcease-and-desist | 法的措置へ移行 (TechCrunch) |
| 2026年8月25日 | Nitter本体が停止・GitHubリポジトリがアーカイブ | 本家プロジェクトの終了局面 |
| 2026年8月26日 | Redditで「XCancel is dead」と報告 | Nitter系最後の主要な逃げ道にも法的圧力が及んだ可能性 |
つまり、前の回答で私が書いた
「XCancelはNitter亡き後の主要な読み取り口」
という評価は、8月26日時点では古くなっています。
むしろ現在は、
Nitter → XCancel → そしてXCancelも停止
という流れになっている可能性が高い。
ここで歴史的な意味が変わる
2024年のNitter停止は、
「Xが技術的にAPIを閉じた」
という事件でした。
一方、2026年8月のNitter/XCancel問題は、
「Xが法的手段によって代替フロントエンドそのものを排除する」
段階に進んでいます。
TechCrunchが確認したXのcease-and-desistでは、NitterについてAPIや関連データへの「unlawful use and circumvention」、スクレイピング、Xアカウントやsession tokenへのアクセスなどを問題視し、テキサス州法やLanham Actなどを根拠として停止を要求しています。(TechCrunch)
しかもTechCrunchは明確に、
NitterがXCancelなど複数のサイトを支えている
と報じています。(TechCrunch)
したがって今回の構図は、
X
│
┌────────┴────────┐
│ │
Nitter その他
│
┌──────┴──────┐
│ │
XCancel 各種インスタンス
│
└──────┬──────┘
↓
匿名・軽量・広告なし
X閲覧環境だったものが、
X
│
API / scraping
制限・法的措置
│
▼
Nitter
×
│
XCancel
×
│
その他ミラー
─────────
相次いで消滅？という構造に変わったわけです。
そして、これは「Nitterの死」より大きい
今回の出来事で興味深いのは、XCancelがNitterの代替ではなかったことです。
XCancel自体がNitterのインスタンスでした。Daring Fireballも8月16日時点で明確に「XCancel is an instance of Nitter」と説明しています。(Daring Fireball)
つまり、
Nitterの代替を作った
のではなく、
Nitterを維持する別の運営主体が生き残った
に近い。
そのためXがNitterそのものを法的に潰す方向へ進めば、XCancelも構造的に巻き込まれます。
Nitter史を修正するとこうなる
| 世代 | 代表 | 基本戦略 | 結果 |
|---|---|---|---|
| 第1世代 | Nitter | Xを匿名・軽量に読む | 成功 |
| 第2世代 | 公開Nitterインスタンス群 | Nitterを分散配置 | 一時的に成功 |
| 第3世代 | XCancelなど | Nitterフォーク＋独自運用 | Nitter本体停止後も生存 |
| 第4世代 | XCancel | Nitter生存圏の最後の大規模入口 | 2025–2026年に存在感増大 |
| 第5世代 | XCancel / Nitter | Xの技術的制限と対抗 | 徐々に不安定化 |
| 第6世代 | ― | X Corp.による法的措置 | 2026年8月、Nitter本体停止 |
| 第7世代 | ― | XCancelも停止との報告 | 「Nitter型ミラー」そのものの終焉局面 |
ここで重要なのは、2024年の「Nitter is dead」と2026年の「XCancel is dead」は意味が違うことです。
2024年：
Twitter/Xが技術的にNitterを殺した。
2026年：
Xが法的にNitterエコシステム全体を殺しに来た。
そして、この流れはかなり象徴的です。
Nitter → XCancel → RSS-Bridge → RSS/Atom
という「Xを公開Webの情報源に戻す経路」が、上流のXによって切断される。
だから今回のXCancel停止は、単なる「便利なサイトが一つ消えた」という話ではなく、SNSプラットフォームが自社コンテンツへの第三者アクセスをどこまで許容するのか、そして「公開URL」と「公開情報」が同義ではなくなったWebの現在地を示す事件として見る価値があります。
なお、現時点でRedditスレッドの「XCancel is dead」というタイトル・コメントはユーザー報告であり、XCancel運営者による公式な終了声明とは区別すべきです。一方、NitterへのXのcease-and-desistについてはTechCrunchがXの書簡を確認しており、こちらはかなり強い一次情報に近い状況です。(Reddit)これはかなり重要な補足です。むしろ、あなたのブログの過去記事を加えると、Nitter史を「後から振り返った歴史」ではなく、2021年からリアルタイムで観測してきた記録として再構成できます。
特に面白いのは、2021年→2023年→2026年の3段階で、Nitterをめぐる問題がほぼ同じ形で繰り返されていることです。
| 時期 | あなたのブログで観測された出来事 | Nitterの状態 | 当時の意味 | 後から見た意味 |
|---|---|---|---|---|
| 2021/1/31 | 「nitter.netが2021年1月31日から沈黙」 | nitter.net停止 | 代替インスタンスを探す必要が発生 | Nitterが最初から「単一サービス」ではなくインスタンス群として生きることを示した |
| 2021/2 | nitter.dark.fail、nitter.tedomum.net、nitter.fdn.fr、nitter.1d4.us、nitter.kavin.rocks、nitter.ccなどを紹介 | 複数インスタンスが稼働 | **「Nitterが死んでも別インスタンスへ移る」**という運用モデル | 後のNitterエコシステムの基本形 |
| 2021/1 | 「NitterでYouTubeリンクが飛ばされるInvidious」について記事化 | NitterとInvidiousを併用 | TwitterだけでなくYouTubeも代替フロントエンド化する流れ | 「SNS/動画サイトを直接使わず読む」という思想の早期記録 |
| 2023/4 | Twilog停止への代替策としてNitterを利用 | Nitter → RSS | NitterをTwitter閲覧UIではなくRSS生成器として利用 | ここが非常に重要。Nitterはすでに「SNSミラー」以上の存在だった |
| 2023/4 | nitter.net/Doping_Consomme をRSS取得先として紹介 | Nitter → DailyFeed → IFTTT/WordPress等 | Twitter投稿を自動収集・アーカイブ可能 | Nitterが「Web情報の取得API」のように使われていたことを示す |
| 2023/7初旬 | 「nitterがTwitterからBANされた？」 | 複数インスタンスでTweet取得不能 | Twitter側のスクレイピング規制との関連を疑う | 後のAPI閉鎖・スクレイピング対策の前兆 |
| 2023/7 | 「最近Twitterはログインしないとツイートを見られないようテストしたようだ」と指摘 | 匿名閲覧に影響 | ログイン必須化とNitter停止の関連を推測 | 2026年の「匿名閲覧問題」の原型 |
| 2023/7/16 | 「Nitterが復旧した？スクレイピング規制終了か？」 | 一時的に機能回復 | 規制解除・緩和の可能性を観測 | XとNitterのいたちごっこが明確になる |
| 2023後半 | X/TwitterのAPI・スクレイピング制限が強化 | Nitterの維持が困難に | 公開インスタンスの不安定化 | 「技術的に潰せる」ことが明らかになる |
| 2024 | Nitter本体が実質停止へ | 多くの公開インスタンス消滅 | Twitter/X側の仕様変更により従来方式が成立しなくなる | 第1次Nitter崩壊 |
| 2024–2025 | フォーク・残存インスタンスが活動 | 一部インスタンスが復活 | Nitterはソフトウェアより運営者・セッション・プロキシ基盤が重要になる | 「分散しているようで上流はX一社」という問題が露呈 |
| 2025–2026 | XCancelなどがNitter系の代表的な閲覧先になる | XCancelが生存 | Nitter本体が弱体化しても代替フロントエンドは需要を維持 | NitterブランドからNitter方式への移行 |
| 2026/8/24–25 | X Corp.によるNitterへの法的措置 | Nitter本体が停止・アーカイブ | 技術的制限から法的制限へ | Nitterエコシステムそのものの終焉 |
| 2026/8/26 | 「XCancel is dead」とのユーザー報告 | XCancelも機能停止との報告 | 最後の主要な逃げ道にも影響 | Nitter→XCancelという避難経路そのものが断たれる局面 |
特に重要なのは「2023年4月」の記事
あなたの
「Twilogがサービス停止!代わりにTweetを収集する方法」
の記事は、Nitter史を考えるうえでかなり重要です。
ここでは単純に、
Twitterを見る → Nitter
ではなく、
Twitter → Nitter → RSS → DailyFeed → IFTTT / WordPress
というパイプラインを実際に構築しようとしている。
つまりNitterはすでに2023年時点で、
Twitterの「代替UI」ではなく、TwitterをRSS/Atom的なWeb情報源に変換するアダプター
として使われていたわけです。
これは現在の話につながります。
Twitter/X
│
│ 本来なら
▼
公開Webページ
│
├── RSS
├── Atom
├── Webmention
├── 検索
└── アーカイブところがSNS化が進むと、
X
│
▼
ログイン
│
▼
アルゴリズム
│
▼
XのUIになってしまう。
そこでNitterが、
X
│
▼
Nitter
│
├── HTML
├── RSS
└── 軽量UIという**「SNSを再びWebページに戻す変換器」**になっていた。
そして2021年の記事が非常に象徴的
2021年の記事では、すでに
「nitter.netが沈黙 → 代替インスタンスは？」
という問題が発生しています。
つまりNitterの歴史は、最初から
Nitterが死ぬ
↓
別インスタンスへ移動
↓
復活
↓
また死ぬ
というサイクルでした。
2021年：
nitter.net → 複数インスタンス
2023年：
Twitter規制 → Nitter停止 → 復旧
2024年：
Nitter本体停止 → フォーク
2025年：
Nitter → XCancelなど
2026年：
Nitter法的停止 → XCancel停止との報告
という流れです。
したがって、Nitterの歴史を一言でまとめるなら、
「一つのサービスが15年近く続いた歴史」ではなく、「Twitter/Xが閉じるたびに、コミュニティが別の読み取り経路を作り続けた歴史」
と捉えるのが適切です。
そして、あなたの2021年・2023年の記事は、その変化をリアルタイムで記録した一次的な利用者史料としてかなり面白い位置にあります。
特に 「2021 Nitterインスタンス探し → 2023 Nitter→RSS→DailyFeed → 2026 Nitter/XCancel崩壊」 を一本の年表にすると、**「公開WebとしてのTwitterがどう閉じていったか」**を非常に鮮明に描けます。XCancelというTwitterのサードパーティフロントエンド運営者が、2026年8月24日午後8時（EST）にX社（旧Twitter）からサービス停止を求める「cease and desist」の通知を受け取り、XCancelのサービスを「当面停止」するとウェブサイト上で告知したため、運営が法的助言を求めていること、これによりサービスが停止状態になっていることが伝えられている。そして投稿者とコミュニティはXCancelの停止を受けて落胆や怒りを示し、今後の詳細は運営からの続報待ちであると理解している。 さらにスレッドのコメントでは、XCancelだけでなくNitterなど他のTwitterフロントエンドや類似サービスも大量の差し止め通知を受けているらしいという指摘があり、複数のユーザーがMusk（イーロン・マスク）率いるX社の対応を批判している。利用者側からは、外部フロントエンドやサードパーティアプリ経由でないと閲覧や検索が困難になり、Twitter（X）自体やInstagram、TikTokなど多くのプラットフォームがアカウント作成やログインを強いる方針を進めていることへの不満が表明されている。 その結果、レディットの利用形態にも影響が出ており、投稿や検索など閲覧の一部でアカウント必須になったことに不満を持つユーザーが多く、以前のサードパーティアプリ（例：BaconReader）を懐かしむ声や、新UI（新Reddit）への反発も見られる。掲示板内では、ツイートのスクリーンショットを共有すれば閲覧可能性を保てるのではないかという提案や、他のTwitterフロントエンドや代替ツールの存在を示唆する書き込みも出ている。 コミュニティの反応としては、法的措置に対する懸念と同時に、個人情報収集を目的とした強制的なログイン要求を批判する声、さらにリーク情報やゲーム関連の情報流通が阻害されることへの不満が強く、いくつかのユーザーは今後の情報入手手段の再編成や代替方法の検討を促している。また一部には皮肉や嘲笑、Musk個人への非難、そして「PoEコミュニティは強い」といった冗談交じりの反応も見られる。 総じて、この投稿はXCancelの一時停止告知を起点に、差し止め通知が広範なサードパーティサービスに波及していること、そしてそれによってユーザーの閲覧体験や情報流通が制約されることへの不満と対策の議論がスレッド全体で展開されている状況を伝えている。運営側は法的助言を受けるとし詳報を控えており、コミュニティは代替ツールやスクリーンショット共有などの回避策を模索している。存在します。ただし、「開かれたSNS」を何で定義するかで答えが変わります。
Nitter/XCancelの歴史まで踏まえると、私は「開かれたSNS」を少なくとも ①読む自由、②投稿する自由、③移動する自由、④データを取得する自由、⑤サーバーを選ぶ自由の5軸で評価するのがよいと思います。
| SNS / プロトコル | 匿名閲覧 | オープンな投稿 | サーバー選択 | データ移行 | RSS/API等 | 単一企業への依存 | 開放性 |
|---|---|---|---|---|---|---|---|
| X | △ | △ | ❌ | △ | ❌/△ | 🔴 非常に高い | ★★☆☆☆ |
| X + Nitter/XCancel | ◎ | ❌ | △ | ❌ | ◎ | 🔴 非常に高い | ★★☆☆☆ |
| Bluesky / AT Protocol | ○ | ◎ | ◎ | ◎ | ◎ | 🟡 中程度 | ★★★★☆ |
| Mastodon / ActivityPub | ◎ | ◎ | ◎ | ○ | ◎ | 🟢 低い | ★★★★★ |
| Nostr | ◎ | ◎ | ◎ | ◎ | ◎ | 🟢 非常に低い | ★★★★★ |
| XMPP | ◎ | ◎ | ◎ | ◎ | ◎ | 🟢 非常に低い | ★★★★★ |
| Matrix | ○ | ◎ | ◎ | ◎ | ○ | 🟢 低い | ★★★★☆ |
| RSS/Atom + ブログ | ◎ | ◎ | ◎ | ◎ | ◎ | 🟢 極めて低い | ★★★★★ |
ただし、SNSとしての完成度と「開放性」は別問題です。
1. 一番「開かれたSNS」に近いのは何か
現時点では、方向性の違いを含めて、
Nostr ≈ ActivityPub > AT Protocol > Matrix > X
という順番で考えると分かりやすいです。
Nostr
最も極端です。
アカウントというより公開鍵／秘密鍵がアイデンティティになります。
自分の秘密鍵
│
▼
┌─────────┐
│ Identity │
└────┬────┘
│
┌───────┼────────┐
▼ ▼ ▼
Relay A Relay B Relay C
│ │ │
└───────┼────────┘
▼
ClientRelayを変えても同じアイデンティティを使える。
つまり、
「SNSアカウントをサーバーから切り離す」
という発想です。
これはXとはほぼ正反対です。
2. ActivityPubは「WebのSNS化」に近い
MastodonなどのActivityPub系は、
「サーバーは違っても、同じネットワークで会話する」
というモデル。
Mastodon A ───── Mastodon B
│ │
│ │
└──── ActivityPub ────┐
│
Lemmy
│
PeerTubeここでは、
「どの会社のSNSを使うか」
ではなく、
「どのサーバーに所属するか」
になります。
Twitter/Xのように、
「会社がサービスを終了したので、あなたのSNS人生も終了」
となりにくい。
3. AT Protocolは少し違う
ATProtoの面白さは、「サーバーを分散させる」だけではなく、データの移植性を設計に組み込んでいることです。
Bluesky を入口にしてATProtoを利用する人が多いですが、本質はBlueskyというSNSそのものよりプロトコル層にあります。
Identity
│
▼
DID / Handle
│
▼
Repository
│
┌────┴────┐
▼ ▼
Relay AppView
│ │
└────┬────┘
▼
Clientこれは、
「Twitterを別サーバーでコピーする」
より一段進んで、
「SNSデータそのものを移植可能にする」
という思想です。
4. そして、Nitterが教えてくれた最大の教訓
ここが今回の話の核心です。
Nitterは、
「Xを自由に読む」
ことには成功しました。
しかし、
「Xから自由になる」
ことには成功していません。
なぜなら、
Nitter A
Nitter B
Nitter C
Nitter D
│
▼
Xだからです。
Nitterを100個作っても、Xが上流を遮断すれば全部止まる。
これは疑似分散です。
一方、
User
│
├── Relay A
├── Relay B
├── Relay C
└── Relay Dなら、Relay Aが消えてもネットワーク自体は残ります。
したがって、
Nitterは「オープンなフロントエンド」だったが、「オープンなSNS」ではなかった。
これは非常に重要な区別です。
5. では「本当に開かれたSNS」とは何か
私は次のように定義します。
| 条件 | 意味 |
|---|---|
| Read without permission | アカウントなしでも公開情報を読める |
| Write without permission from one company | 特定企業の許可なしに参加できる |
| Federation | 複数サーバーが相互接続できる |
| Portability | アカウント・投稿・フォロー関係を移動できる |
| Interoperability | 別実装のクライアント・サーバーが接続できる |
| Open protocol | プロトコル仕様が公開されている |
| Open data access | 公開情報を機械的に取得できる |
| No single kill switch | 一企業が全ネットワークを停止できない |
| Self-hosting | 自分でサーバーを運用できる |
| Algorithmic choice | 推薦アルゴリズムを選択・交換できる |
この基準なら、Xはほぼ逆方向です。
6. そして意外な答えが「ブログ＋RSS」
SNSだけを探す必要もありません。
むしろ、
ブログ + RSS/Atom + Webmention
は非常に強い。
自分のブログ
│
├── RSS
├── Atom
├── Webmention
├── ActivityPub
└── ブラウザ
│
▼
読者のクライアントここでは、ブログ運営者がSNS企業にアカウントを持っている必要すらありません。
Twitter/Xの場合、
Xが閉じれば情報発信も閉じる
ですが、
ブログなら、
ブログが存在する限りURLが存在する。
そしてRSSリーダーはNitterのような「ミラー」を必要としません。
結論
「開かれたSNS」は存在します。
ただし、現在の本命は「巨大SNSの代替サービス」ではなく、
ActivityPub、AT Protocol、Nostr、XMPPなどのオープンプロトコル
です。
そして思想的には、
Nitter → 「閉じたSNSを開いて読む」
から、
ActivityPub / ATProto / Nostr / XMPP → 「最初から閉じられないSNSを作る」
への移行が重要です。
さらに極端に言えば、
SNS → プロトコル → 個人サイト → RSS/Atom
という方向に進むほど「開かれたWeb」に近づきます。
だから、2026年のNitter/XCancelの連続停止は、ある意味で逆説的です。
「開かれたSNSが存在しない」のではなく、「開かれたSNSを作るなら、XのようなSNSの外側にプロトコルを作らなければならない」
ということを、Nitterの歴史が証明している、と考えられます。できます。しかも、WordPressは「単独のSNS」にするより、ActivityPub・Webmention・RSS/Atom・コメント・購読を組み合わせると、かなり本格的な分散型SNSになります。
特にNitter/XCancelの問題を踏まえるなら、WordPressを**「自分のデータを所有するSNSノード」**として使う発想が面白いです。
WordPressをSNSとして使う基本構成
| 機能 | WordPressでの実現方法 | SNSとしての役割 |
|---|---|---|
| 自分の投稿 | WordPress記事・投稿 | タイムラインへの投稿 |
| 短文投稿 | 投稿フォーマット・カスタム投稿 | Xのポスト相当 |
| フォロー | ActivityPub | Fediverse上のフォロー |
| 返信 | ActivityPub / コメント | リプライ |
| いいね | ActivityPub | Like |
| 再共有 | ActivityPub | Boost / Reblog |
| 外部サイトからの返信 | Webmention | 分散コメント |
| RSS/Atom | WordPress標準機能 | タイムライン購読 |
| メール購読 | WordPress購読機能 | 通知・購読 |
| プロフィール | WordPressユーザープロフィール | SNSアカウント |
| 画像・動画 | WordPress Media Library | メディア投稿 |
| 検索 | WordPress検索 | 投稿検索 |
| タグ | WordPress taxonomy | ハッシュタグ |
| 長文 | 通常の記事 | ブログ／長文投稿 |
| 外部SNS連携 | ActivityPub | Fediverseとの相互接続 |
一番重要なのがActivityPub
WordPressには公式のActivityPubプラグインがあります。
これを導入すると、WordPressサイトがFediverse上のアクターとして振る舞えるようになります。
例えば、
https://example.com/@dopingconsommeのようなWordPress上のユーザー／投稿者を、Mastodonなどからフォローできます。
すると、
WordPress
│
│ ActivityPub
▼
Mastodon
│
├── Mastodonユーザー
├── Lemmy
├── PeerTube
└── その他Fediverseという関係ができます。
つまり、
WordPressを「自分で所有できるSNSアカウント」にする
ことができます。
1. 「Xの代替」として使うなら
かなり面白い構成はこれです。
WordPress
│
┌─────────┼─────────┐
│ │ │
ActivityPub RSS/Atom Webmention
│ │ │
▼ ▼ ▼
Fediverse RSS Reader 個人ブログ
│
├── Mastodon
├── Misskey
└── その他これなら、
WordPress = 原本
になります。
Xの場合は、
X → Xのデータベース → XのUI
ですが、
WordPress型なら、
自分のWordPress → 複数のSNS・RSSリーダー
です。
この差はかなり大きい。
2. 「短文SNS」にする
WordPressは本来ブログなので、
「今日は○○だった」
程度の短文を書くと少しブログっぽすぎます。
そこで、例えば投稿を、
[短文]
今日からNitterの歴史を調べ直している。
2021年にはすでにインスタンス停止問題が発生していた。
#Nitter #Fediverse #Webという形式にします。
WordPress側では、
カテゴリー
タグ
投稿フォーマット
カスタム投稿タイプ
などを使って「短文」を分類できます。
ActivityPub経由なら、この投稿をMastodon側から読むことができます。
3. 「フォロー」をActivityPubに任せる
ここがWordPress単体との大きな違いです。
例えば、
あなたのWordPress
↓
@user@example.comをMastodonユーザーがフォローする。
すると、
あなたがWordPressに投稿
↓
ActivityPub
↓
フォロワーのMastodonと配信されます。
つまりWordPressが、
「自分のSNSサーバー」
になります。
4. Webmentionを追加するとさらに面白い
ActivityPubがSNS向けなら、WebmentionはWebサイト向けの相互接続です。
例えば、
あなたのWordPress
│
│ Webmention
▼
他人のブログ他人があなたの記事について記事を書いた場合、
「このページについて別のWebサイトが言及しました」
という通知を受け取れます。
これはXの「引用ポスト」に少し似ていますが、決定的な違いがあります。
SNS企業のデータベースを経由しない。
つまり、
ブログ → ブログ
で直接つながります。
5. RSS/Atomを残す
ここはあなたのNitter研究との接続が特に強いです。
Nitterが便利だった理由の一つは、
X → Nitter → RSS
にできたことでした。
しかしWordPressなら、
WordPress → RSS/Atom
を最初から持っています。
つまり、
WordPress
│
├── ブラウザ
├── ActivityPub
├── RSS
├── Atom
├── Webmention
└── メールとなる。
Nitterのような変換レイヤーそのものが不要になります。
6. 「WordPress SNS」の完成形
個人的には、こういう構成がかなり理想的です。
| レイヤー | 技術 | 役割 |
|---|---|---|
| Identity | WordPressユーザー / ActivityPub | 自分のID |
| 原本 | WordPress DB | 投稿データ |
| 長文 | WordPress記事 | ブログ |
| 短文 | 投稿 / カスタム投稿 | SNS |
| Federation | ActivityPub | Fediverse |
| Web連携 | Webmention | ブログ間通信 |
| 購読 | RSS / Atom | RSSリーダー |
| 検索 | WordPress | 自分の投稿検索 |
| タグ | WordPress taxonomy | ハッシュタグ |
| 通知 | ActivityPub / Webmention / email | リプライ・言及 |
| メディア | WordPress Media | 写真・動画 |
| バックアップ | DB + uploads | 完全なデータ所有 |
これなら、
「WordPressをブログとして使う」
ではなく、
「WordPressを自分専用のSNSサーバーとして使う」
という発想になります。
7. さらに一歩進めるなら「個人SNSサーバー」
例えば、
あなた
│
┌──────┴──────┐
│ WordPress │
│ 自分のSNS │
└──────┬──────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
ActivityPub RSS/Atom Webmention
│ │ │
▼ ▼ ▼
Fediverse RSS reader 個人ブログこうすると、
Xのアカウントを持つ
のではなく、
自分のドメインをSNSアイデンティティにする
ことができます。
これは非常に重要です。
Xなら、
@usernameはX社のデータベースに存在する。
WordPressなら、
username@example.comのようなアイデンティティを自分のドメインに置ける。
そしてActivityPubによって、それをFediverseへ接続できる。
8. XMPPまで加えるとさらに強い
以前話していたXMPPとの組み合わせも可能です。
WordPress
│
┌────────────┼────────────┐
▼ ▼ ▼
ActivityPub Webmention RSS/Atom
│ │ │
▼ ▼ ▼
Fediverse Web RSS
│
│
XMPP
│
▼
リアルタイム通信この構成では、
WordPress = 公開情報
ActivityPub = SNS
Webmention = Web間のリンク
RSS/Atom = 購読
XMPP = リアルタイム通信
という役割分担ができます。
これはXのコピーを作るより面白い。
最終的には「SNSを所有する」
Nitter/XCancelの歴史から逆算すると、かなり明確な答えが出ます。
X → Nitter → XCancel
は、
「Xのデータを別の場所から読む」
という発想でした。
しかし、
WordPress + ActivityPub + Webmention + RSS/Atom
なら、
「自分のデータを自分で所有し、それを複数のネットワークへ配信する」
になります。
この違いは決定的です。
Nitterは「Xから退出するための窓」だった。
WordPress + オープンプロトコルは「Xを必要としない自分自身のSNSノード」になれる。
これこそ、今回のNitter/XCancel停止問題に対する、かなり実践的な回答だと思います。
コメント
コメントを投稿