Xのおすすめ欄、同じ出所の投稿を抑えめに並び替え　公開コードで判明

2026年10月26日 21:542026年10月27日 12:32

X（旧Twitter）の「For You」タイムライン向けに、候補を間引く方式が変わったと読めます。公開リポジトリ xai-org/x-algorithm では、候補を取得元（ServedType）ごとに分け、予算を超えたときに各ソースの比率を保ったまま削る FairShareRankingFilter が入り、EnableFairShareRanking の公開デフォルトは true（既定ON）になっています。画面に並ぶ本数そのものではなく、「スコアリングに回せる候補の上限」まわりの設計変更です。

マーケターや運用担当向けに先に言うと、「小アカウントが一気に伸びる」とまでは言えません。一方で、新投稿が候補の最後尾に固まって丸ごと落ちやすかった、という読みが正しければ、冷スタート寄りの投稿が候補枠に残りやすくなる、という期待はコードと整合します。以下は公開コードで確認できたことと、個人の解説で未確認な点を分けて整理します。

この記事の要点

一次情報はX公式ブログではなく、公開コード xai-org/x-algorithm（同期注記おおよそ2026-10-23 UTC）。
PhoenixScoresResultSize=2800 はFor You 1リクエストあたりのスコアリング候補上限（画面表示本数ではない）。
FairShareは候補をServedTypeごとに分け、超過時に比例間引き（テスト例：440/220/440 → 予算1000で400/200/400）。
EnableFairShareRanking の公開デフォルトは true。ただし毎回は動かない条件あり。
冷スタート関連の公開デフォルト：投稿年齢2時間以内・フォロワー上限5万・Home表示200まで。
「小アカ救済確定」「いいね8未満・表示500未満が新投稿」などは未確認または誇張になりやすい。

誰が何を言っているか（個人のコード読解）

話題の発端は、X上の個人による公開コード解説です。X公式のアルゴリズム解説ブログではありません。

Peter Mick（@ThePeterMick） — Inflowpayのパートナーで、テック／AI／マーケティング寄りの発信。2026年10月25日夜（おおよそ23:47 JST）に公開コードを読み解いた長文スレッドを投稿（該当投稿）。確認時点で約24.6万表示規模まで広がっています。
Alek Asaduryan（@Ldnbox） — SaaS向けのSEO／AI検索まわりで発信するアカウント（フォロワーおおよそ3万規模）。Peter氏の解説を引用し、運用向けの箇条書きにまとめた投稿（該当投稿）が広がっています。
第三者の整理として、情報の塔（Toru Misaki氏）も、FairShareの有効化（おおよそ10月22日）や約9.6万行規模の変更を文書化しています。

本記事では、これら個人解説を「きっかけ」として扱い、主張のうち公開コードで裏が取れる部分だけを事実として書きます。数字の効果量や「必ず伸びる」系の言い切りは採用しません。

公開コードで確認できたこと

候補上限 2,800 と FairShare（比例カット）

home-mixer/params/param.rs（同期注記：2026-10-23T16:00:34Z）では、次が公開デフォルトです。

PhoenixScoresResultSize = 2800 — スコアリング結果として残せる候補の予算（For You 1リクエスト単位）。タイムラインに並ぶカード枚数ではありません。
EnableFairShareRanking = true — FairShareによる候補間引きが既定で有効。

実装は home-mixer/filters/fair_share_ranking_filter.rs の FairShareRankingFilter です。候補を ServedType（取得元）ごとにグループ化し、合計が予算を超えると、各グループの比率を保ったまま残数を割り当てます。ユニットテストでは、InNetwork 440・Simclusters 220・PhoenixRetrieval 440（計1100）を予算1000で間引くと、400 / 200 / 400 が残る、と断言されています。つまり「全体を先頭から切る」のではなく、「ソースごとの構成比を崩しにくい間引き」です。

この設計なら、冷スタート用など相対的に後段へ押しやられがちなソースも、他ソースと同じ比率で候補枠に残り得ます。「新投稿が常に最後尾で丸ごと落ちる」問題は緩和されうる、という読みはコードと整合します。ただし FairShare 自体は「新投稿を優先表示するブースト」ではありません。

フィルターが動かない条件

enable() を見ると、次のときは FairShare は無効です。

EnableFairShareRanking が false
キャッシュ投稿がある（has_cached_posts）
scoring_sequence がない
Phoenix ranker の Kill switch が有効

「毎回・全ユーザーで必ず比例カットが走っている」とは、公開コードだけでは言えません。

冷スタート関連の公開デフォルト（別機能だが運用上セットで見る）

同じ param.rs に、冷スタート寄りの公開デフォルトもあります（FairShareそのものではありませんが、投稿直後の扱いを考える材料になります）。

パラメータ	公開デフォルト	意味の読み
`ColdStartMaxPostAgeSecs`	7200（2時間）	投稿年齢の上限目安
`ColdStartFollowerCap`	50000	フォロワー数の上限目安
`ColdStartImpressionThreshold`	200	Home表示回数のしきい値目安

Ldnbox氏の「最初の2時間が大事」は、この2時間窓と一致します。一方で「いいね8未満・表示500未満が新投稿」といった条件は、公開の冷スタートパラメータには見当たりません（後述の未確認）。

重みは「予測確率への係数」

公開コード／README側の注記どおり、各アクションの重み（例：FavoriteWeight=0.66、ShareViaCopyLinkWeight=20.0）は、生のいいね数などに掛ける点数ではありません。モデルが出す「その行動が起きる予測確率」などへの係数です。「コピリンク共有1回＝いいね何十回分」といった換算は、公式コメントでも誤読だと注意されています。シェアが相対的に重い係数なのは確かですが、「公式がシェア至上主義を宣言した」わけではありません。

運用で合理的に言えること（言い過ぎない範囲）

クライアントや自社アカウントの運用に落とすなら、次の程度が公開コードと整合しやすいです。

投稿直後〜2時間は、冷スタート条件と重なる時間帯。ここで反応が全く出ない投稿を連発するより、オリジナルの本文・メディアで反応を取りにいく方が合理的。
オリジナル投稿は、返信やRTだけの投稿よりフォロワー外へ出やすい、という公開設計の読みと整合しやすい（ただし保証ではない）。
質と多様性 — 同一フィード内で同じ著者の2本目が減衰する仕組みがある、という説明は従来からあり、連投で埋め尽くす運用は不利になりやすい。
エンゲージメントベイト・低質ラベル系は、公開コードの重み以外にもコード上に出てこない品質・安全性レイヤがあり得る。過度な誘導は避ける、という従来どおりの注意が妥当。
効果の大きさは未知 — 2800上限にどれだけ当たるか、小アカウントの到達が何％上がるかは公開コードに出ていません。ABテスト結果の公式発表でもありません。

未確認・誤解しやすい点

「小アカウントが一気に伸びる」は確定ではない。 FairShareはソース比率の保全であり、フォロワーの少ないアカウント専用ブーストではありません。効果量は公開されていません。
Peter氏の「新投稿＝いいね8未満かつ表示500未満」 — 公開の冷スタート条件（2時間／フォロワー5万／表示200）には、いいね8・表示500は見当たらない。未確認として扱います。
「約3700候補を集めて先頭2800、新着が最後」 — 各ソース上限を足すとそれくらいになり得る、という解釈ストーリーです。FairShareの本体はServedTypeごとの比例間引きであり、「常に古い順で切る」普遍ルールとして公式に示されたものではありません。
公開デフォルト ≠ 全ユーザー・全リージョンの本番確定。 機能フラグやKill switchがあり、コード上の true がそのまま全員に即時適用されたとは限りません。
Ldnbox氏の箇条書き（シェア＞いいね、dwell重視など）は、重み表を踏まえた実務Tipsとしては筋が良いものもありますが、「Xが公式発表した運用指針」ではありません。