Xのゼロスタート

ゼロから始めるなら、まず知るべきことが一つある。アルゴリズムは新規アカウントに補助を与えるが、それには期限がある。 これは「初心者保護期間」のようなマーケティング文句ではない。コード内で author_cold_start と呼ばれるロジックであり、デフォルトで有効、条件も厳密に書かれている。

その処理はこうだ。各 feed リクエストで、すべての「小規模アカウントによるオリジナル投稿」から最もスコアが高い一件を選び、そのスコアをその候補群で16番目に高いスコアまで引き上げる。

二つ注意点がある。各リクエストで選ばれるのは一件だけであり、引き上げ先は その候補群で16番目に高いスコアであって、1位ではない。 これは「バズらせる」仕組みではなく、「中位の位置で見つけてもらう」仕組みだ。

一、そのウィンドウの仕様

冷スタートの資格 — 以下をすべて満たす必要がある

1. オリジナル投稿でなければならない —— 返信とリポストは対象外（in_reply_to_tweet_id.is_none() 且 retweeted_tweet_id.is_none()）

1. 投稿者のフォロワー数 ≤ 1000 —— ちょうど 1000 はまだ資格があり、超えた時点で失う

1. その投稿のインプレッション数 < 1000 —— 厳密に未満。1000 を超えた時点でこのプールから外れる

1. 順位が後方 15% に落ちていない（順位 < 0.85 × 有効候補数）

1. その投稿が Phoenix 検索 MoE 由来ではない（デフォルトのグループにおける追加条件）

着地点の正確なアルゴリズム（多くの人が書き間違える）

コードは候補スコアを高い順にソートし、ranked[random_range(lo..hi)] を目標スコアとして取る。ここで lo = min(ColdStartSlotMin, hi)、 hi = min(ColdStartSlotMax, 候補数)。

デフォルトの Min=15、Max=16 では、random_range(15..16) は常に 15となる。つまり、デフォルト値では「区間内でランダム」にランダム性はなく、着地点は16番目に高いスコアに固定される。

さらに、候補数 ≤ 15 では lo >= hi となり、関数は直接 None を返す —— 冷スタート全体が起動しない。この補助を得るには、その候補群に有効候補が少なくとも 16 件必要だ。

しばしば誤って伝えられる条件が一つある：24 時間。 コードには確かに ColdStartMaxPostAgeSecs = 86400（24 時間）がある。 しかしこれは実験の Treatment グループでしか有効にならない—— cold_start_freshness_eligible() は Treatment 以外のグループでは直接 true を返す。 そして二つのグループ切替（PhoenixMoeCodivertViewerIsTreatment / ...IsControl）はどちらもデフォルトで false、すなわちデフォルトは Holdout グループを通る。 したがってデフォルト経路では、冷スタートに 24 時間の制限はない。 真のハードウォールはグローバルな 48 時間の AgeFilter——超過すれば直ちに除外され、徐々に減衰するわけではない。

この点は私も最初に誤った。私が依頼した素材パックでは 24 時間を一般条件として書き、外部エージェントの原稿もそれを一般ルールとして記した。あとから author_cold_start.rs:149-154 を読んで、実験グループのゲートで囲まれていると分かった。ここに注意として書いておく。条件付きのものは、何に囲まれているかを見る必要がある。

見落とされやすい二つの性質

一、質の低い投稿は救わない。 第 4 の資格は「順位が後方 15% に落ちていない」ことだ。冷スタートがするのは、もともと悪くない投稿を中位から16位へ引き上げることであり、最下位を救済することではない。コンテンツ品質は依然として入場券だ。

二、これは argmax の競争である。 すべての資格を満たす小規模アカウント投稿から「最もスコアが高い一件だけ」を選ぶ。この競争が報いるのは「ある狭い人々にとって極端に有用であること」であり、「誰にとっても中程度」であることではない。 中程度のコンテンツは argmax では決して一位になれない。だからテーマは一文で言い切れるほど狭くすべきだ。

二、六つの条件から逆算される三つの運用ルール

ルール一

同時に場へ出す主力オリジナル投稿は「一件」だけにする

各 feed リクエストで選ばれるのは一件だけだ。同時にオリジナル投稿を三つ出しても、三つの枠を得るのではなく、同じ一枠を奪い合う。

根拠：apply_cold_start は max_by(scores) で一つのインデックスだけを取り、その一件にのみスコア引き上げを行う。

ルール二

二件目は一件目に「課税」する

さらに厳しいのは順序の問題だ。デフォルト経路では、コードの実行順は次のとおりである。

初期優遇策  →  同著者減衰  →  未追随割引 ×0.75

つまり、投稿が冷スタートで引き上げられても、それより前に同じ投稿者の別投稿があると、続けて同一投稿者減衰で 0.625 を掛けられる。その後さらに 0.75 の未フォロー割引を掛けられる。引き上げは先に発生し、減点は後に発生する。

根拠：ranking_scorer.rs における author_cold_start.apply() → apply_author_diversity() → after_diversity × effective_oon の順序（機械検証済み）。

ルール三

次の投稿に切り替える時点は、二つの数字で判断する

主力投稿を「使い切った」シグナルは二つある。インプレッションが 1000 を超える（冷スタートプールから外れる）、または公開から 48 時間が経過する（AgeFilter で直接除外される）。どちらかが起きたら次の投稿に切り替える。

根拠：ColdStartImpressionThreshold = 1000、 MAX_POST_AGE = 172800 秒。ソースコードには「最適な投稿時間」や「一日に何件投稿すべきか」はない。他人が語るそうした数字は、このコードには存在しない。

これを一つのスロットだと考える。 場には常に主力オリジナル投稿を一件だけ置き、 それが 1000 インプレッションを超えるか 48 時間に達したら、次の投稿を入れる。

システムが防いでくれない落とし穴：テーマ疲労

既読フィルタ（3 段階）は投稿単位であり、テーマ単位ではない。 同じ人が一週間の間に、別々だが同じことを語るあなたの投稿を三つ見られる——システムはまったく止めない。

テーマ疲労こそが「ミュート」（−58.8）の原因だ。したがってこれは自分で管理する必要がある。 同じテーマへの最短再訪間隔は 48 時間（元投稿が AgeFilter で除外され、自分と競合しなくなるのを待つ）とし、 実務では 7 日のローテーション表にする。

付随する推論：48 時間を超えた古いコンテンツは、角度を変えて書き直して再投稿しても、仕組み上の損失は一切ない—— 元投稿はすでに AgeFilter の外にあり、とっくに流量はない。これがこの戦い方の主力だ。

三、1000 フォロワーは天井ではなく、期限付きのチケットである

1000 フォロワーを超えた後に失うのはただ一つ、オリジナル投稿が選ばれ、選ばれ、16番目に高いスコアへ引き上げられる機会だけだ。 コードには「フォロワーが 1000 を超える」ことへの追加ペナルティは一切ない——通常のスコアリング、候補化、フィルタリングの流れは完全に同じである。

だから正しい見方は「1000 未満に留まるほうがよい」ではなく、こうだ。

1000 フォロワーに達する前には、期限付きの無料テスト場がある。 この期間にすべきことは、「どのコンテンツが通常スコアだけで生き残れるか」を見極めることだ—— 1000 を超えれば補助はなくなり、残るのはすべてコンテンツそのものの力だからだ。

実務的な判断基準が一つある。投稿が冷スタートで引き上げられたときにしかインプレッションを得られないなら、そのコンテンツ自体の予測スコアは不足しており、1000 を超えれば崖のように落ちる。 逆に、ある投稿のインプレッションが 1000 を大幅に超える（すでに冷スタートプールを出てもなお伸びている）なら、それこそが「コンテンツが自力で動いている」証拠だ。

四、何を書くか：価格表がコンテンツの形を決める

スコア ＝ 各アクションの予測確率 × そのアクションの重み。重みは設定ファイル内に固定された価格である。

したがってコンテンツの目標は「いいねに値する」ことではなく、「持ち帰るに値する」ことだ。 問うべきは一文だけ。誰かがこの投稿のリンクをコピーし、グループに貼るか、友人へ DM するか？

ゼロ段階では、単独で持ち帰れるコンテンツ単位を優先できる。整理済みのリスト、対照表、 操作手順の組、出典を確認できる数字、明確に述べられた判断だ。これらは 20.0 と 5.0 の項目のために設計された形だ——ただし明確にしておく。 これはコンテンツ設計であり、それらのアクションが必ず起きることを意味しない。

五、相互フォロー：コード内で唯一、関係に加点する仕組み

重み表全体の中で、「人と人の関係」に追加で加点する箇所は一つだけだ。 あなたと投稿者が相互フォローである場合、返信の重みは 5.0 から 20.0 になる。 二つ目はない。フォロワー数自体には加点がなく、一方向のフォローにも加点はない。

そしてここには、ゼロから始める人にとって特に重要な組み合わせがある。

互いに衝突しない二つのレーン

• 主投稿レーン：オリジナル投稿 → 冷スタートを通る。一度に一件

• 返信レーン：返信には冷スタートの資格がない（最初の条件で除外される）。したがって返信は主投稿の枠を占有せず、薄めもしない—— 相互フォロー関係では、その価値は 20.0

言い換えると、返信を増やしても主投稿を傷つけない。この二つのレーンはコードの層で分かれている。 ゼロから始める実際の方法は、毎日主力オリジナル投稿を一件、冷スタートに乗せ、 残りの力を本物の相互フォロー関係を築き、その人たちの投稿に真剣に返信することへ振り向けることだ。

ただし「中身のない相互フォロー」の価値は小さいのではなく、ゼロである

鍵は、その +15.0 の加算が「モデルが相手はあなたへ返信すると予測する」確率に乗算されることにある。 相手があなたへまったく返信しないなら、p(返信) ≈ 0、15.0 × ≈0 ≈ 0 となる。

同時に、相互フォロー一件ごとにフォロワー数は +1 となる——そしてフォロワー数が 1000 を超えると、冷スタート資格を永久に失う。

これは戦略全体で最も鋭い緊張関係だ。 フォロワー枠は 1000 個しかなく、相互フォローはそのうち一つを使う。 中身のない相互フォローを一つするたびに、補助期間の枠を使って、価値 0 のものを買っている。

したがってフォローの基準は一つだけである。この人は本当に私と会話してくれるか。観察可能な判断基準（フォローする前にも見える）は次のとおり。

• その人のタイムラインには「他人へ返信している」記録が多くあるか。発信するだけで返信しない人からは、この加算を決して得られない。

• その人のテーマはあなたと重なるか。重なって初めて返信する話題があり、返信に中身が生まれる。

• フォロワー数は重要ではない。大規模アカウントをフォローしても、ほぼ相互フォローにはならず、加算は得られない。フォローはあなた自身が見る内容に影響するだけだ。

実行方法は素朴だ。毎日決まった数人を選び、全文を読んでから、実質的な中身のある一言を返す（「よく言った」「同意」ではない）。 フォローは相手が返信した後に行う。前ではない。

ついでに一つ試算する。相互フォロー加算を入れると、ポジティブ側の総予算は 43.324 から 58.324 になり、負／正比は 8.48 から 6.30 へ下がる。 これはコード全体で唯一、負正の構造を改善できるレバーである。

ただし、これは「相互フォロー術」への許可ではない。相互いいね・相互フォローのグループ（engagement pod）、 数字を伸ばすための大量の機械的返信は、プラットフォームが明示的に禁じる操作行為である。 しかもアルゴリズムの観点でも割に合わない——理由は次節にある。

六、ゼロから始める際に最も犯してはならない誤り：論争で最初のフォロワーを得ること

まず 43.324 という数字を理解しよう。これは「一人の読者があらゆるポジティブアクションをすべて満たした」理論上限である （確率がすべて 1、現実には不可能）。この上限があれば、ネガティブシグナルを非常に具体的なものへ換算できる。

「スクロールで通り過ぎられる」ことと「興味なしを押される」ことには、2160 倍の差がある。 だから「読み飛ばされない」ために扇情的な書き出しを書くべきではない—— 節約できるのは 0.02、引き換えにするリスクは 43.2 だ。

システム自身の式で、一件の投稿を計算する

スコアは Σ(重み × 確率) であるため、インプレッションごとの期待寄与を直接計算できる。 以下の確率は式を示すための仮定であり、実測値ではない——repo には確率がない。

例： 「20% の人がいいねし、3% の人が興味なしを押す」投稿

いいね寄与    0.20 × 0.5   = +0.100
興味なし寄与  0.03 × 43.2  = −1.296
                          ─────────
純値                        −1.196

「興味なし」の 3% は、20% のいいね率の 12.96 倍を食い尽くす。 いいねだけで相殺したいなら、必要ないいね率は 259.2% —— 不可能だ。 リンクコピー共有だけで相殺したいなら、6.48% の人があなたのリンクをコピーする必要がある —— 非常に高いが、少なくとも可能性のある数値だ。

これが戦略全体の核心である。この価格構造でネガティブシグナルに耐えられる唯一のポジティブ項目は「コピーされ、持ち帰られる」ことだ。 いいねでは耐えられない。

よくあるフォロワー獲得手法の期待値

通報一回は −234.0 であり、さらに——スコアが一度でも負になると、0 から 0.001 という極めて狭い範囲に圧縮される。 負スコア投稿同士の順位差はほぼゼロとなり、まとまって最下層へ沈む。これは「少し後ろに並ぶ」ことではない。

計算して見せよう。対立を煽って 100 個のいいね（＋50）を得ても、 同時に 1 人がミュート（−58.8）を押せば、この取引はすでに負だ。

これが、この価格構造では「論争的コンテンツはフォロワーが早く増える」ことが期待値マイナスである理由だ。 ポジティブ・ネガティブ両方のアクションの予測確率を同時に上げるが、ネガティブ側は一桁高価である。 ゼロから始める場合はとりわけ危険だ——まだこのコストを償却できるコンテンツ資産がない。

テーマ選定の一票拒否権

公開前に、まずこの問いへ答える

あなたをまったく知らず、あなたの立場にも同意しない見知らぬ人がこれを読んだとき、 最もありそうな反応は「つまらない、スルーする」か、それとも「興味なしを押したい」か？根拠：−0.02 対 −43.2、差は 2160 倍。 非対象者に対するコンテンツの最悪ケースは「つまらない」でなければならず、「嫌い」ではならない。

見知らぬ人へ推薦されたいなら、コンテンツはよりクリーンでなければならない

冷スタートの意味は、非フォロワーにあなたを見てもらうことだ。しかし非フォロワーへ推薦されるコンテンツは、 フォロワーに出すものより26 個多いルールを通過する必要があり、その 26 個は除外だけで通過させることはできない。 そこには「高再現率」のスパム情報・成人向けコンテンツ検出も含まれる——率直に言えば過剰除外を選ぶ。

非フォロワー経路には前提説明がない。文脈があって初めて不快でなくなるもの（皮肉、内輪ネタ、風刺）は、 この経路では誤って除外されるだけだ。境界線上のコンテンツはフォロワー圏では流通できても、推薦として出ることはほぼ不可能だ。

七、これはどこまで自動化できるか

できるし、そうすべきだ——ただし先に三つを区別しなければならない。機械がすべきこと、機械ができるが人間の承認が必要なこと、触れれば問題になること。

✓ 青信号：機械による完全自動化が正当で、行うべきこと

• 公式 X API を使い、「すでに人間が承認した」コンテンツを公開する

• パフォーマンスデータを取得し、24／48 時間のスナップショットを作る

• 「現在場に出ている主力投稿はどれか」の状態機械を維持する

• しきい値アラート：インプレッションが 1000 を超える、公開から 48 時間、フォロワーが 1000 を超える、スケジュールの衝突、API エラー

• 素材ライブラリ、バージョン記録、テーマ仮説と実験記録

• 重複コンテンツ検出（自分で自分にぶつからないため）

▲ 黄信号：機械が下書きを作り、人間が承認する

• LLM による投稿下書きの生成、書き直し、書式整理

• LLM によるフィードバックの整理、次ラウンドのテーマ brief 作成

• 返信と DM の候補下書き——ただし送信前に必ず人が読む

• ローカル資格チェック（オリジナル／非返信／非リポスト／フォロワー／インプレッション）

✕ 赤信号：行ってはならない。これらはプラットフォームが明示的に禁じる操作行為である

• 偽アカウント、複数アカウント連携によるインタラクションシグナルの偽造

• 相互いいね・相互フォローのグループ（engagement pod）

• 自動での大量返信、自動での大量 DM

• 投票の操作

• 規模化された規約違反のスクレイピング

赤信号のものが「見つからなくても割に合わない」理由

これは単なるルールの問題ではなく、アルゴリズムの仕組みからも説明できる。

• 機械的なインタラクションでは、価値の高いアクションに届かない。価格表の上位は「リンクコピー共有」「DM 共有」「引用」だ—— これらは実在の人が持ち帰る価値を感じて初めてする行動だ。自動化で水増しできるのはいいね（0.5）であり、20.0 は水増しできない。

• コンテンツを合わない人へ押し出すことは、負スコアを買うことだ。操作で得たインプレッションは興味のない読者へ届き、 NotInterested／Mute／Report の予測確率を押し上げる——そちらは 8.48 倍高価だ。

• 量産はむしろ自分を薄める。冷スタートは各回一件しか選ばず、同一投稿者減衰も引き上げの後に作用する。 自動化で連投すれば、自分の投稿同士で枠を奪い合い、互いに課税するだけだ。

ツールチェーンはこうなる

企画仮説／素材集
      │
      ▼
LLM 草案と書式整理
      │
      ▼
自動資格検査（ローカルで算出可能な部分）
オリジナル？ 非返信？ 非リポスト？ フォロワー ≤1000？ フィード上に主力投稿は既にある？
      │
      ▼
╔══════════════════════════════════╗
║  人手関門：事実、口調、危険、決定  ║   ← 省略不可
╚══════════════════════════════════╝
      │ 承認
      ▼
投稿待列 ──► 公式 X API 投稿
      │
      ▼
状態機械：フォロワー数／投稿別露出／投稿年齢／フィード上の主力投稿
      │
      ├─► 警報（露出超 1000、満 48h、追随超 1000）─► 人
      ├─► 24h / 48h 結果記録 ──────────────────► 報告
      └─► 次周期 brief ─────────────────────► LLM 草案

コメント／私信は別の手作業支線：
分類と草案（機械）─► 人が読み文脈判断 ─► 人が送信

重要な設計が一つある。「ローカルで計算できること」と「サーバーだけが知ること」を区別することだ。

ローカルで算出可能（自動ゲート化できる）：
    オリジナル かつ 非返信 かつ 非リポスト
    かつ フォロワー数 ≤ 1000
    かつ 当該投稿露出 < 1000

サーバーのみが把握（算出できるふりをしない）：
    当該投稿のある feed リクエストにおける順位 < 0.85 × 有効候補数
    当該投稿がすべての適格候補で最高スコアかどうか
    モデルによる各アクションの予測確率

この境界は重要だ。なぜなら、ダッシュボードが何を主張できるかを決めるからだ。 実際にその引き上げを得たかどうかは、決して見えない。 インプレッションの増加は冷スタートによるものかもしれず、通常ランキングや外部からの拡散によるものかもしれない—— 相関を因果と取り違えてはならず、自分で「X スコア」を作ってダッシュボード上で本物のように見せてもならない。

計測すべきものを正しく計測する

最後の実務的提案：「いいね数」を主要指標にしてはならない。 いいねの価格は 0.5 であり、共有／引用／返信は 5.0～20.0 だ。 レポートでは共有系と返信系を分けて取り出して見るべきである。 それこそが価格表で実際にランキングを動かす部分だからだ。

八、この戦略が最も失敗しやすい場所

最大のリスクは、公開スナップショット一件への過剰適合だ。 冷スタートはデフォルトで有効だが、投稿はまず有効候補に入り、17 の前段フィルタを通過し、 後方 15% に落ちず、さらに同一リクエストで資格を満たす全候補の中で最もスコアが高くなければならない—— 引き上げ先も16番目に高いスコアにすぎず、候補が 16 件未満ならそもそも起動しない。 コンテンツと読者が合わなければ、「一度に一件」のリズムは低い予測スコアを補えず、 反対にネガティブ予測によって 0～0.001 の圧縮領域へ落ちる可能性がある。 さらにアカウント側からは、モデル確率、実際の順位、完全なネガティブシグナルは見えないため、 通常の変動を冷スタートの効果と誤読しやすい。 構造的なリスクもある。フォロワーが 1000 を超えた時点で、補助に依存しないコンテンツ能力がまだ育っていなければ、 このランキング支援は直接消える。しかもソースコードには代替の成長仕組みがない。 しかし最も根本的な反論はこれだ。この手冊全体が証明するのは「どう減点されないか」であり、「どう得点するか」ではない。 式では、ポジティブ項とネガティブ項は別々に合算される。 負スコアを避けても、正スコアは自動では生まれない。 「地雷回避」を重く語りすぎれば、誰にも害がなく、そのため誰の役にも立たないものを書くことになる—— その種のコンテンツでもポジティブ予測確率はゼロに近づき、最終スコアは同じく 0.001 付近で止まる。 さらに厳しい穴がある。冷スタートは各回一件しか引き上げない。グローバルで資格を満たす小規模アカウントの数が feed リクエスト数を大きく上回るなら、 個別アカウントがその枠を得る頻度は戦略上意味のないほど低い可能性がある——しかし競合者の母数はソースコードに載っておらず、この戦略の期待値は計算できない。 もう一つ構造的な脆弱性がある。EnableViewerColdStart は一つのスイッチだ。 同じ設定には、NEW_USER_OON_WEIGHT_FACTOR = 0.00001 のような極端な強度のパラメータが存在し、しきい値を 0 に設定してオフにしている——X が新規アカウント配信をいつでも反転できる能力を残している証拠だ。 「冷スタートで始める」あらゆる戦略は、このスイッチに対して構造的に脆弱である。

九、この手冊が教えられないこと

一、これは公開スナップショットであり、オンラインの実況ではない。param.rs の冒頭コメントには "mirrored from config feature-switch defaults; last sync 2026-08-12" と書かれており、 これらの値はオンラインでいつでも調整できる。コードが証明できるのは「公開版のデフォルト値が何か」であり、「X が今この瞬間に何を使っているか」は証明できない。 二、価格は実際の得点と同義ではない。式は「重み × モデル予測確率」であり、確率は repo にはない。 「A は B の N 倍の価値がある」というすべての記述は価格の層でのみ成立し、重みにインタラクション回数を掛けてアルゴリズムスコアのように扱ってはならない。 三、対象は For You の一経路だけだ。別の 6 個の filter は他のパイプラインに属し非公開である。 Grox の LLM コンテンツ安全性プロンプトは、X が明示的に公開していない。 四、これは運用戦略であって、成果の約束ではない。 上の各項目は公開された仕組みから導いた運用提案であり、プラットフォームの保証でも、リーチやフォロワー増加の保証でもない。 ソースコードには「最適な投稿時間」「一日に何件投稿すべきか」のようなものはない——誰かがこの種の正確な数字を提示したら、どの行から読んだのかを聞けばよい。

ソースコードに未掲載のリスト（意思決定に使えないもの）

「分からない」を明確に列挙することは、知っているふりをするより有用だ。

一つの正直な内的矛盾：この手冊の核心は「安全性ペナルティを避ける」ことだが、 安全性を判定するプロンプトは、まさに X が公開していない部分である。 安全性の基準を欠いたスナップショットを使い、安全性ペナルティの回避を核心とする戦略を書く—— このこと自体に矛盾があり、公開資料の内部だけでは解決できない。

この手冊はどう作られたか（私自身の誤りを一つ含む）

私は同じ素材パックを二つの独立したエージェントへ同時に渡し、それぞれに原稿を書かせた後、ソースコードに対して一項目ずつ検収した。 二つの原稿の算術はすべて再計算した（23 項目すべて正しい）。採用した箇所は上に示した。

ただし二つの原稿はいずれも、私の一つの誤りを引き継いでいた。 素材パックで「24 時間」を冷スタートの一般条件として書き、 二つのエージェントはいずれも「24 時間間隔で投稿し、資格ウィンドウを重ねない」と結論した。 あとから author_cold_start.rs:149-154 を読むと、その条件は実験グループのゲートで囲まれており、 デフォルト経路ではまったく有効でないと分かった。「一日一件」という結論自体はなお成り立つ。 だが根拠は「各回一件だけを選ぶ」＋「同一投稿者減衰が引き上げ後に作用する」ことであり、存在しない 24 時間ウィンドウではない。 それを捉えたのはエージェント間の不一致ではなく、ソースコードへ戻って読むことだった。 二つの独立エージェントが同じ誤った前提を与えられれば、一致して同じ誤った結論を導く—— 合意は正しさと同義ではない。

一文で持ち帰る

1000 フォロワーに達する前は、場には持ち帰る価値のあるオリジナル投稿を一件だけ置く。 残りの時間で、本物の相互フォロー関係を築く。 自動化はパイプラインを管理し、人間は判断を管理する。

出典と検証

本稿は、xai-org が GitHub で公開した X 推薦アルゴリズムのソースコードに基づいて執筆した。判読日は 2026 年 8 月 14 日。

本文のすべての仕組みとしきい値はソースコードに基づき、機械による命題の逐項目再現検証を経ている。

効力の境界：ソースコード内のパラメータは feature switch デフォルト値のミラーであると明記され、オンラインでいつでも調整できる。 本稿は公開版のデフォルト値を証明できるが、プラットフォームがオンラインでその時点に実際に使う数値は証明できない。 最終スコアは「重み × モデル予測確率」であり、確率は公開ソースコードにはない。そのため、すべての倍率比較は価格の層でのみ成立する。