2026年版：日本のXアルゴリズムの読み方

X運用の情報は、今でも「1つのテクニックで伸びる」という説明に寄りがちです。
ただ、2026年は公開コードとして確認できる範囲が増え、議論の前提をかなり具体化できます。

この記事は、2026年3月1日時点の xai-org/x-algorithm を起点に、For You推薦の処理構造を日本語運用に落とし込んだ実務向けの再編集版です。
タイトルはそのままに、本文を大幅に詳細化しています。

先に3分要約

忙しい人向けに、結論だけ先に置きます。

1. x-algorithm は「For Youフィード向け推薦」の実装構造を示しており、候補取得・除外・スコアリングが明確に分業されている
2. ランキングは単一指標ではなく、複数行動確率の重み付き合算で、not interested / block / mute / report など負のシグナルが明示的に減点方向に扱われる
3. スコア前後に二段階フィルタがあり、「点数を上げる」だけではなく「そもそも落とされない設計」が必要
4. 候補同士を見ない ranking mask（candidate isolation）があるため、投稿単体の品質改善が再現性に直結しやすい
5. 日本語X運用では「1投稿1テーマ」「導入2行の明確化」「24h/72hでの同型比較」を固定化するのが最短

以降は、この5点をコードの語彙に合わせて細かく解説します。

この記事の立ち位置（事実と推論の線引き）

最初に、どこまでが公開事実で、どこからが運用推論かを明確にします。

公開事実（リポジトリで確認できる）

• For You向け推薦の主要コンポーネント名
• 候補取得、ハイドレーション、フィルタ、スコア、選択の段階構造
• 複数行動予測と重み合算スコアの考え方
• 候補同士を見ない attention mask の実装方針
• 代表的なフィルタ名（重複、古さ、既読、ミュート、可視性など）

非公開または未確定（断定しない領域）

• 本番運用で使う正確な重み値や閾値（params は公開対象外部分あり）
• モデル学習頻度、実トラフィックでの配信比率、地域別の微調整
• X全プロダクト面を横断した全システム像

つまり、この記事は「構造はコード根拠で説明」「具体値は推測を混ぜない」を原則にしています。

図1: For You推薦パイプラインの全体像

この図は、公開READMEと home-mixer 実装で読める処理順を要約したものです。
重要なのは、スコアリングが単独で存在するのではなく、前後の処理に強く依存している点です。

コードに沿って読む7段階

home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs を中心に、段階ごとに見ていきます。

1. Query Hydration

ここでは、推薦リクエスト時点の「ユーザー文脈」を作ります。

• ユーザー行動シーケンス（過去の反応履歴）
• ユーザー特徴量（フォロー関係や設定由来の情報）

運用観点では、ここが「過去の振る舞いが次の配信に効く」根拠です。
短期でバズる投稿より、継続して反応の質を揃える投稿が有利になりやすい理由はこの層にあります。

2. Candidate Sourcing

候補は少なくとも2系統から来ます。

1. Thunder（In-Network）
2. Phoenix Retrieval（Out-of-Network）

In-Networkはフォロー中アカウント由来、Out-of-Networkは未フォローも含む発見枠です。
ここで重要なのは「最初から1本に決まる」のではなく、候補集合を作ってから後段で絞る設計であることです。

3. Candidate Hydration

取得した候補に、スコア計算で必要な追加情報を付与します。

• コア投稿データ
• 動画長などの属性
• サブスク閲覧可否
• 著者情報

この段階は地味ですが、ここが欠けると後段で落ちます。
投稿内容だけでなく、メタデータ整合性が実質的に品質要件になる理由です。

4. Pre-Scoring Filters

スコア前に「候補として不適格」なものを落とします。公開実装に現れる主なフィルタは次です。

• DropDuplicatesFilter
• CoreDataHydrationFilter
• AgeFilter
• SelfTweetFilter
• RetweetDeduplicationFilter
• IneligibleSubscriptionFilter
• PreviouslySeenPostsFilter
• PreviouslyServedPostsFilter
• MutedKeywordFilter
• AuthorSocialgraphFilter

ここから分かる実務ポイントは単純です。
「スコアを上げる努力」より前に、「落ちる要因を減らす運用」が必要です。

5. Scoring

公開実装では、スコア関連処理は複数ステップで連結されています。

1. PhoenixScorer: 行動確率を推定
2. WeightedScorer: 複数行動の重み付き合算
3. AuthorDiversityScorer: 同一著者連続露出を減衰
4. OONScorer: Out-of-Network補正

この順序が重要です。
単純に「推定値が高い順」ではなく、多様性とネットワーク種別の補正が後段で入ります。

6. Selection

最終スコアでソートして上位K件を選択します。
selectors/top_k_score_selector.rs の構造は非常に明快で、最終スコア中心に決まることが分かります。

7. Post-Selection Filters

選択後にさらに除外されます。代表は次です。

• VFFilter
• DedupConversationFilter

つまり「上位に入った = 配信確定」ではありません。
可視性ポリシーと会話重複制御の最終ゲートがあります。

図2: スコア設計の実務理解

WeightedScorer では、複数アクション確率に重みを掛けて合算します。
ここで大事なのは、「正の反応を増やす」だけでなく「負の反応を減らす」が同時に必要なことです。

予測対象アクションを運用言語に翻訳する

公開READMEや phoenix/runners.py で見えるアクションを、投稿運用に引き直すと次のようになります。

この設計から導ける結論は明確です。

1. いいね最適化だけでは足りない
2. クリックだけ取りに行く釣り設計は長期で不利
3. 負シグナルを減らす編集が、想像以上に効く

Candidate Isolation をどう解釈すべきか

phoenix/grok.py の attention mask は、候補同士の相互参照を禁止し、ユーザー文脈と履歴への参照を許す形です。
実務での意味は次の3点です。

1. バッチ内の他候補に引っ張られにくい
2. 投稿単体の改善が素直に効きやすい
3. 「比較対象ガチャ」で勝つより、投稿そのものを磨く方が再現性が高い

ここを踏まえると、投稿改善は次の順で行うのが合理的です。

1. 導入2行の明確化
2. 段落分割と情報密度の最適化
3. CTAの単一化
4. 反応ログを見た再編集

図3: フィルタ2段階の見取り図

スコアに注目しすぎると、フィルタ設計を見落とします。
実際には、フィルタが露出上限を先に決める場面が多いです。

スコア前フィルタで詰まりやすい運用ミス

• 同じ文面の短期再投下
• 既読を無視した量産
• ミュートワードに触れる曖昧表現
• 文脈不足で誤読されやすい導入

スコア後フィルタで詰まりやすい運用ミス

• 炎上気味の文面を反復して可視性判定を悪化
• 同一会話スレッド内で重複枝を量産

ここでの原則は「伸ばす前に落ちない」です。

旧来ハックが効きにくい理由を構造で説明する

「昔のやり方が急に通らなくなった」と感じる背景は、公開構造に照らすと次のように整理できます。

1. 候補選定の入口が複線化している
2. スコアが多目的最適化（複数行動）になっている
3. ネガティブシグナルが明示的に減点される
4. 多様性補正があるため同型連投が相対的に弱くなる
5. 二段階フィルタで不適合コンテンツが後段でも落ちる

だからこそ、短期ハックより「反応品質を安定化する型」が有利になります。

日本語Xでの実践設計（詳細版）

ここからは、上記構造を日本語運用に落とす具体手順です。

1. 投稿設計: 1投稿1テーマを厳守

混ぜるほど推定が難しくなります。
1投稿内で伝える価値は1つに固定し、補足は返信に逃がします。

• 見出し相当の1行目: 誰向けか
• 2行目: 何が得られるか
• 本文: 結論 -> 理由 -> 具体例 -> 行動

2. 導入2行の作り方（テンプレ）

次の型を使うと、反応の比較がしやすくなります。

• 対象: 「X運用初月で反応が止まる人向け」
• 便益: 「72時間で改善点を1つ特定する方法」
• 期待値: 「投稿数を増やさずに検証する」

導入で期待値を過剰に釣ると、負シグナル側に寄りやすくなります。
「強い約束」より「具体的で誠実な約束」を優先してください。

3. 本文の情報密度設計

日本語圏は流速が高く、長文でも視線は高速です。
次のルールで可読性を担保します。

1. 1段落2-4行
2. 1段落1論点
3. 抽象語には数字か手順を添える
4. 用語は初出だけ定義

4. CTAは1つだけ

複数CTAは行動率を割ります。
reply を取りに行く回、profile click を取りに行く回を分ける方が計測可能です。

5. ネガティブ反応の予防線

次を投稿前チェックに入れてください。

• 主語が大きすぎないか
• 読み手属性を不必要に煽っていないか
• 事実と意見を混同していないか
• 断定口調が誤解を誘発しないか

これは道徳論ではなく、スコア設計への実務対応です。

TenguXで回す運用フロー（実装向け）

1. /neta でテーマ候補を1つ選ぶ
2. 引用/リライトで2案作る（導入2行のみ変える）
3. /queue でJST固定枠に配信
4. 24hと72hで指標比較
5. 勝ち導入だけ次週へ持ち越す

ここでのコツは「本文を毎回全部いじらない」ことです。
比較可能性を守るため、変更点は1-2個に限定します。

計測設計: 24h/72hの二段レビュー

24hで見るもの（初速）

• imp（配信の入り）
• engagement（反応の入口）
• profile clicks（興味遷移）

72hで見るもの（持続）

• replies（議論の深さ）
• reposts / quotes（再拡散余地）
• 保存される型かどうか（再訪反応の有無）

実務上の判定ルール例

• 初速が弱い -> 導入2行を修正
• 初速は良いが持続が弱い -> 本文構造を修正
• 反応はあるが質が荒い -> 主語と断定表現を修正

30日運用プラン（詳細）

Week 1: 計測の土台作り

1. 投稿テンプレを1種類に固定
2. テーマを2つまでに制限
3. 投稿後24h/72hの記録シートを作成

Week 2: 導入最適化

1. 導入2行だけA/B
2. 本文は固定
3. もっとも安定する導入型を1つ決める

Week 3: 本文最適化

1. 段落長と箇条書き比率を調整
2. 具体例の量を1.2倍に増やす
3. CTAは固定して純粋に本文差分を比較

Week 4: 再編集と資産化

1. 反応上位3本を再編集
2. 同一テーマで角度違いを作る
3. テンプレ化して翌月の基準にする

この30日で作るべき成果物は「バズ投稿」ではなく「再現可能テンプレ」です。

よくある誤解（FAQ）

Q1. いいねが増えれば全部良くなる？

いいえ。公開構造上、複数行動の合成です。
like だけ強くても、他シグナルや負シグナルで相殺される可能性があります。

Q2. 投稿本数を増やせば勝てる？

短期的に露出機会は増えますが、フィルタや品質が揃わないと逆効果になりえます。
初月は本数より検証精度です。

Q3. Out-of-Networkを狙うには煽ればいい？

非推奨です。OONScorer は存在しますが、それで何をしても許されるわけではありません。
負シグナル増加は長期で不利です。

Q4. このリポジトリを読めばX全体が分かる？

分かるのはFor You推薦の中核構造です。
本番運用の全要素や閾値は公開されていないため、断定は避けるべきです。

Q5. 日本語運用で最優先する1点は？

導入2行の明確化です。
対象読者と便益が曖昧だと、後段最適化の効果が出にくくなります。

実務チェックリスト（投稿前）

1. この投稿は1テーマに絞られているか
2. 1行目で対象読者が明示されているか
3. 2行目で便益が明示されているか
4. 段落ごとに論点が1つか
5. 誤読を生む断定表現がないか
6. 過剰な煽りがないか
7. CTAは1つか
8. 24h/72hで検証する項目を決めたか

この8項目を満たすだけで、運用の再現性はかなり改善します。

まとめ

2026年のX運用で重要なのは、裏ワザ探しではなく構造理解です。
xai-org/x-algorithm から読み取れる実務上の本質は次の3点です。

1. For You推薦は段階分業で動く（候補取得 -> 補完 -> フィルタ -> スコア -> 最終フィルタ）
2. スコアは多目的で、負シグナルは明示的に不利
3. 投稿単体の品質改善を継続する運用が、最も再現しやすい

日本語Xでは、まず「1投稿1テーマ」「導入2行の明確化」「24h/72h検証」を固定してください。
この3点を30日続けるだけで、感覚運用から検証運用に移せます。

付録A: 実装ファイルと読みどころ対応表

深掘りするときに迷わないよう、主要ファイルを用途別に整理します。
「まずどこを読めば何が分かるか」を明示しておくと、情報更新にも追従しやすくなります。

上の表で特に重要なのは、weighted_scorer と grok.py の組み合わせです。
前者は「何を合成しているか」、後者は「どう比較しているか」を示します。
この2つが分かると、施策が「当てずっぽう」から「仮説検証」に変わります。

付録B: 日本語X向け投稿テンプレ12本

以下は、初月でも回しやすいテンプレです。
いずれも「導入2行を比較可能にする」前提で書いています。

テンプレ1: 手順公開型

1. 対象読者を明示
2. 得られる成果を数字で置く
3. 手順を3-5ステップで列挙
4. 最後に「次回どこを改善するか」を宣言

テンプレ2: 失敗学習型

1. 失敗状況を事実ベースで書く
2. 原因を1つに絞る
3. 修正手順を示す
4. 再発防止チェックを置く

テンプレ3: チェックリスト配布型

1. 使う場面を先に指定
2. 7-10項目のチェックを提示
3. 「満たせなかった項目」を次回改善対象にする

テンプレ4: 比較検証型

1. A案/B案の差分を1個に限定
2. 24h/72hで比較した指標を開示
3. 次回施策を1つだけ決める

テンプレ5: 誤解修正型

1. よくある誤解を1つ提示
2. なぜ誤解が起きるか説明
3. 実装構造か観測データで補強
4. 実務上の代替案を示す

テンプレ6: 用語分解型

1. 難語を1つ選ぶ
2. 初学者向け定義を置く
3. 実務で起きる例を添える
4. 使う/使わないの判断条件を示す

テンプレ7: 逆算設計型

1. 目標指標を先に置く
2. 逆算して必要行動を分解
3. 投稿設計に変換する

テンプレ8: 事例抽象化型

1. 単発事例を示す
2. 成功要因を3つに抽象化
3. 他テーマへ転用する条件を書く

テンプレ9: QA先回り型

1. 反論されやすい論点を先に列挙
2. それぞれに短く回答
3. 「適用外の条件」も明記する

テンプレ10: ミニ連載型

1. 1本目で全体地図
2. 2本目で最重要1点
3. 3本目で運用テンプレ
4. 各回でCTAを変えない

テンプレ11: 週次レビュー公開型

1. 週の投稿を俯瞰
2. 良かった点/悪かった点を各2つ
3. 次週の修正方針を1つに固定

テンプレ12: 初心者向け再定義型

1. 専門家向け定説を、初心者向けに言い換える
2. いま実行できる最小手順を添える
3. 失敗したときの戻り方を示す

テンプレは数より一貫性です。
最初の1か月は、2-3個だけ選んで回す方が学習速度が上がります。

付録C: 24h/72h検証ログの記録フォーマット

実務で成果が出るかは、投稿品質より「記録品質」に左右されます。
以下の形式でログを残すと、月末に判断を誤りにくくなります。

このログから、次のように意思決定します。

1. 指標が動いた投稿の「変更点」だけ抜き出す
2. 変更点をカテゴリ化する（導入/本文/CTA）
3. 翌週は最も寄与したカテゴリだけ改善する

「全部直す」は学習を壊します。
毎週1カテゴリだけ直す方が、4週後の再現性は高いです。

付録D: 負シグナルを抑える編集ガイド

not_interested / block / mute / report は投稿者側で直接値を観測しにくいため、
代理指標（proxy）で管理します。

代理指標の例

1. 反応が増えているのに、プロフィール遷移が落ちる
2. リプ数はあるが建設的会話が少ない
3. 投稿翌日以降の反応持続が急減する
4. 同テーマ連投時に露出が急に細る

これらは確定指標ではありませんが、負シグナル増加の兆候として扱えます。
兆候が出た週は、次の修正を優先してください。

1. 強すぎる断定を減らす
2. 対立構造を煽る見出しを避ける
3. 対象読者を広げすぎない
4. 主観と事実を明確に分離する

付録E: リポジトリ更新に追従する読み替え手順

公開実装は将来更新される可能性があります。
次の手順で差分監視すると、記事内容を継続的に保守できます。

1. 月1回 README.md の差分を確認
2. home-mixer/scorers と home-mixer/filters の差分を確認
3. phoenix/grok.py のmask周辺差分を確認
4. 追加・削除されたアクション名を記録
5. 記事の「実務への翻訳」セクションだけ先に更新

この運用を回すと、説明が古いまま固定化されるリスクを減らせます。

参照（2026年3月1日時点）

• xai-org/x-algorithm README
• home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs
• home-mixer/scorers/weighted_scorer.rs
• home-mixer/scorers/author_diversity_scorer.rs
• home-mixer/scorers/oon_scorer.rs
• phoenix/README.md
• phoenix/grok.py