> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2026/w11-twitters-algorithmic-evolution-and-the-iteration-of-source-management.md).

# W11-Twitterのアルゴリズム進化と情報源管理の改善

今年、継続して取り組んでいるテーマがある。自分の情報源ネットワークを選別する効率を高めることだ。

先週、Twitterの推薦アルゴリズムを少し調べた。ClaudeのCoworkで、2つの定期実行タスクも作った。

Twitterの推薦アルゴリズムは近年、抜本的に作り直された。中核コードを公開している数少ないソーシャルメディアでもある（マスクによれば、公開している唯一のプラットフォーム）。先進的な検索・広告・推薦システムを学ぶにはよい資料だ。

初期に公開されたコード（[twitter/the-algorithm](https://github.com/twitter/the-algorithm)）と、最近の大規模モデルを基盤とする新しいコード（[xai-org/x-algorithm](https://github.com/xai-org/x-algorithm)）を比べると、推薦アーキテクチャの変化がはっきり見える。人手による特徴量設計とヒューリスティックなルールに大きく依存した複雑なマイクロサービスから、Transformer（Grok）によるエンドツーエンドの深層学習を中心とした簡素な構成へと進んでいる。

以下に、両リポジトリの構成と技術的特徴をまとめた。進化の方向を感じ取れると思う。

| 比較項目                | 2023年版（The-Algorithm）           | 2025年版（X-Algorithm）                 |
| ------------------- | ------------------------------- | ----------------------------------- |
| **技術スタック**          | Scala / Java（JVMエコシステム）         | Rust / Python（AIエコシステム）             |
| **特徴量設計**           | 人手で設計した数千の統計的特徴量に依存             | **人手による特徴量はゼロ**。利用者の反応系列から学習        |
| **中核モデル**           | Heavy Ranker（48Mのニューラルネットワーク）   | **Grok-based Transformer**          |
| **In-Networkストレージ** | Timeline Cache / Fanout Service | **Thunder**（高性能なRustのインメモリストレージ）    |
| **パイプライン基盤**        | Product Mixer（Scala）            | **Candidate Pipeline Crate**（Rust）  |
| **検索ロジック**          | 検索インデックス（Lucene）＋グラフ探索          | ベクトルによるTwo-Towerモデル                 |
| **開発効率**            | 特徴量パイプラインが複雑で保守コストが高い           | モジュールを組み合わせる構成（Composable）で、ロジックが簡潔 |

Twitterの推薦アルゴリズムを読んでも、学んだことを使いこなせるわけではない。私にできるのは、まだプロンプトを書く程度だ。Coworkで、自分の思考の枠組みに沿った2つの定期実行タスクを作った。1つは市場、もう1つは技術を追うものだ。何度も調整した結果、今の版は、ほぼ私の好みに合うものになった。具体的な指示と最近の例を、参考として載せておく。

世界の市場と主要な資産クラスを追うもの。

{% content-ref url="/pages/0VXc76WXkAAHOctfMNLZ" %}
[毎日の市場ブリーフィング](/ja/2026/w11-twitters-algorithmic-evolution-and-the-iteration-of-source-management/daily-market-briefing.md)
{% endcontent-ref %}

主要な技術組織、コミュニティ、メディアを追うもの。

{% content-ref url="/pages/jTBXyL7HAFlymokKRUTm" %}
[週間テックTop20](/ja/2026/w11-twitters-algorithmic-evolution-and-the-iteration-of-source-management/weekly-tech-top20.md)
{% endcontent-ref %}

ブリーフィングやアシスタントで、さまざまなコミュニティを自分で気ままに歩き回ることを完全には置き換えられない。偶然性も、楽しさも、少し失われるからだ。

たとえば先週、偶然見つけて気に入った記事がある。[Temporal: The 9-Year Journey to Fix Time in JavaScript](https://bloomberg.github.io/js-blog/post/temporal/)だ。BloombergのJSチームが書いたもので、技術ブログの公開を始めたのは今月だが、業界での蓄積は相当に深いチームなのだろう。

この記事は、ES2015以来で最も大きなJSの言語レベルの拡張であるTemporalについて、標準が形になるまでの長い道のりを振り返っている。Date APIが30年間抱えてきた問題を体系的に修正し、時間を扱う型の体系全体を設計し直した。複数のJSエンジンがRustの実装ライブラリ（temporal\_rs）を共有し、実装コストを抑えながら一貫性を高めている。言語標準の層でRustの実装を中核とし、複数のエンジンが採用する基盤という形は、JSでは初めてではないだろうか。