Xアルゴリズム解析の証拠総覧

xai-org / x-algorithm · HEAD a389166

各主張には、ソースコードの位置と再現コマンドを付す。すべての数値はスクリプトの実行で生成されており、手作業で転記したものではない。

リポジトリ xai-org/x-algorithm（2026-08-13 更新） HEAD a389166f6cf5da70a286b568c87695d4dcdce3a1 規模 2,015 ファイル / 21 MB / 5 commits 判読 2026-08-14 検証 58 件の機械命題、58 PASS / 0 FAIL 自己検証：誤った期待値を注入 → 正しく 1 FAIL を生成（ゲート有効）

① 機械命題の検証表

以下の 58 件はすべて verify-all.sh の実行で生成された。本ページの数値は同スクリプトの出力を直接表に変換したものであり、手作業で書き写してはいない。スクリプト本体は付録に示す。

② 重みの総表

出典は home-mixer/params/param.rs。ファイル全体の 183 個の param! をブロックごとに解析し、名前に Weight を含むものを 33 個抽出した。うち 30 個が数値の重みで、以下の三つの表にすべて掲載している。残る三つは単一の数値ではなく、残る二つは別の場所に載せている（DwellRegretGateWeights は本節末、VMRankerSendHeadWeights は第 ④ 節のスイッチ表）、残る一つ PostUnexploredWeightInNetworkOnly（param.rs:369-374、既定 true）は探索加点をフォロー内の投稿に限定する真偽値スイッチであり、重みの値ではないため重み表には入れていない。数値はコードに組み込まれたデフォルト値であり、オンラインでは feature switch により上書きできる。

抽出の落とし穴（私も初版で踏んだ）：このファイルには複数行と単一行の二種類の param! 記法が混在する。複数行だけを走査すると 13 個を黙って取りこぼす——そして本当のスコアリング重みはすべてその 13 個に入っている。実測 170 ≠ grep -c '^param!(' の 183 で初めて判明した。付録のパーサーは両方を処理する。

正の重み（表は 19 行＝正の重み 17 個＋OON 割引係数 2 個）

負の重み（5 個）

この 8.48 倍を誤読しない読み方：比較しているのは重みの価格付けであり、最終スコアではない。式に入るのは「重み × モデル予測確率」であり、通報・ブロックの予測確率は非常に小さく、いいねの確率ははるかに高い。そのため、一件の投稿における負の項の実際の寄与は、正の項の 8.48 倍にはならない。これらの確率はモデルが算出するもので、公開コードにはなく、計算できない。成立する表現は、X の負のシグナルに対する価格付けは、正のシグナルより一桁高い、である。

ゼロ重み（6 個）

第 33 個：19 次元のロジスティック回帰

DwellRegretGateWeights（param.rs:534）は単一の数値ではなく、19 個の係数からなる文字列である。入力はあなたのアカウント履歴（インタラクション系列長、いいね数、返信数、負のフィードバック数、7 日／1 日のアクティブ状況、フォロワー数、フォロー数、アカウント年齢…）で、出力は「この投稿を見たことを後悔するか」の確率である。抜粋：

seq_len:0.530298     n_reply:0.485541     n_click:-0.176675
n_fav:-0.082139      n_1d:-0.241730       account_age_years:-0.045455
n_profile_follow:-0.221285                n_negfb:0.031839

③ スコアリング式を行ごとに追う

単項 = モデル予測確率 × 動作の重み                  ranking_scorer.rs:416-418
       fn apply(score: Option<f64>, weight: f64) -> f64 {
           score.unwrap_or(0.0) * weight
       }

26 項目で配列構成                                   ranking_scorer.rs:470-510

正負二群分割                                        ranking_scorer.rs:513-521
       for t in terms { if t >= 0.0 { pos += t } else { neg -= t } }

combined = pos − neg                                ranking_scorer.rs:427

最終補正                                            ranking_scorer.rs:524-532
       if total_sum == 0.0        → max(combined, 0)
       else if combined < 0.0     → (combined + negative_sum) / total_sum × 0.001
       else                       → combined + 0.001

NEGATIVE_SCORES_OFFSET = 0.001                      params/config.rs:40
negative_sum = −(not_interested+block+mute+report+not_dwelled)   :127
total_sum    = positive_sum + negative_sum                       :128

この offset の実際の効果：負のスコアになったすべての投稿は、0 ~ 0.001 という極めて狭い区間に圧縮される。負のスコア同士の順位差はほぼゼロになり、すべて最下部に沈み、一塊になる。「少し後ろに並ぶ」のではなく、「可視範囲から落ちる」。

二つの条件付きボーナス

④ 三段階の調整

0.00001 を扇情的な結論にしてはならない：NewUserAgeThresholdSecs のデフォルト値は 0（param.rs:273）である。アカウント年齢が 0 秒未満になることはないので、この仕組みはデフォルトでは有効にならない。正しい表現は、スイッチは存在し、効き目は極端だが、現在はオフである。

「作られているがオフ」の三つのスイッチ

⑤ 20 個のフィルター

出典は home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs L344–362（前段 17 個）および L417–421（後段 3 個）。すべて無条件に登録されており、条件付きスイッチはない。

照合結果：README が主張する 17＋3 個とその順序は、コードと項目ごとに完全一致し、ずれはゼロである。この点について X は美化していない。

⑥ 54 件の可視性ルール

出典は visibility-filtering/rules/registry.rs（912 行）。最初に drop を返すルールを基準とし、それ以降は評価しない。

基本の 28 件を順に挙げる：著者状態 4 件（凍結／無効化／消去／離脱）→ 保護アカウント → あなたがブロック → あなたがミュート → ミュートしたリポスト → コンテンツラベル 8 件（PDNA、却下、スパム、緊急、ヘイトスピーチ、暴力的発言、悪用、公民的完全性）→ 非ブロードキャスト → 期限切れ → 法的削除 2 件 → ログアウト／未成年／年齢未入力向けのセンシティブコンテンツ 3 件 → 専用コンテンツ → 最後の 4 件は直接落とすのではなくインタースティシャル警告である。

未フォロー時に追加で背負う 26 件はすべて drop のみを行う。DMCA 対象メディア、地域制限メディア、成人向けコンテンツの 4 種類の判定、高リコールの成人向け・スパム検出（誤って落としてもよい）、悪意ある URL、「拡散しない」ラベルなどである。

⑦ ゼロ重み 6 個の三種類の性質

見分け方は、モデルがこのアクションを予測するよう学習されているかを見ることだ。学習済みで価格付けだけが 0 ＝本物のレバー、学習損失すら設定されていない＝単なる空き枠である。

共通の仕組み：「重みが 0 ならスキップする」というガードは存在しない（唯一の例外は BidirectionalFollowDwellWeightBoost（下記））。式は一律に 確率 × 重みであり、重み 0 でも計算され、26 項の配列に入り、結果は常に 0 である。モデルは依然として計算資源を使って予測し、パイプラインもそれを渡す。ただし最後にゼロを掛けるだけである。

第 1 類：モデルは学習済みで、価格付けだけが 0 —— 本物のレバー

QuotedVqv の二重保険：util/candidates_util.rs:42-60 に同名関数quoted_vqv_weight()があり、これは重みをゼロにするゲートである。EnableQuotedVqvDurationCheck がオン（デフォルト false）の場合、引用動画は > 10,000 ミリ秒でなければならず、そうでなければ重みが直接 0.0 に書き換えられる。

第 2 類：学習損失すら設定されていない —— 単なる空き枠

phoenix/ の学習設定全体で、損失関数が設定されている連続ヘッドは DWELL_TIME だけである（recsys_model.py:473-479 と xrecsys.py:566-585。ギャラリーレイアウトには tweedie、それ以外には mae を使う）。

この二つには構造的な問題もある。分子と分母が非対称である。positive_sum（:104-122）にはこの二つの連続項が含まれないが、これらは分子に入る 26 項の合計には入る。そして total_sum はまさに負のスコア圧縮式の分母である（:524-532）。上げると、分子は大きくなり、分母は変わらないため、負のスコアの圧縮比が歪む。重みが 0 のときには見えず、調整すると表面化する。

第 3 類：ガードと専用テストを持つ正式なオフスイッチ

BidirectionalFollowDwellWeightBoost は、唯一 != 0.0 の短絡ガードを持つ（ranking_scorer.rs:216-221）。テストコードには、「0 に設定した場合は必ずまったく作用しない」ことを専用に検証するテスト bidirectional_weight_zero_boost_is_noop（L1288 から）があり、別のテストでは 2.0 に設定してボーナスが有効になることを検証している（L1250-1253）。その双子の兄弟（返信版のボーナス）はオンで、値は 15.0。

204 から 21 へ

⑧ BRIDGE_PROBABILITY 専論

repo 全体で大文字小文字を問わず grep -rin bridg を行うと、ヒットは 25 件である。まず同名のノイズを三種類除外する。

schema には位置がある

enum ContinuousActionName {                    recsys.proto:437-443
  INVALID_CONTINUOUS_ACTION_NAME = 0;
  DWELL_TIME                     = 1;   → Rust 重み 0.004（有効）
  CLICK_DWELL_TIME               = 2;   → Rust 重み 0.0（無効）
  ACTIVE_SECS_5M_RESIDUAL_NORM   = 3;   → Rust 重み 0.0（無効）
  BRIDGE_PROBABILITY             = 4;   → Rust 側に定義なし
}

repo 全体の .rs ファイルで grep bridge ＝ 0 ヒット。ランキング式にはその項がなく、ゼロを掛ける場所すら残されていない。

二本の配線は、どちらも入力で、どちらもオフ

repo 全体のどこにも、この二つのスイッチを True に設定する箇所はない——configs にも、テストにも、yaml/json/toml にもない。対照群の enable_dwell_time はまったく同じ仕組みを使い、デフォルトは True であり、複数の設定ファイルで明示的に指定されている。同じ配管で、一方には水が通り、もう一方は封じられている。

インデックスの矛盾：四つの証拠が解く

二本の bridge 経路はいずれもインデックス 0を読むが、列挙では 0 は INVALID、bridge は 4 となっている。

結論：配列の意味は公開された列挙だけで完全には決まらない。ただしリアルタイムのサービス経路では曖昧さがない——埋められるのは dwell のスロットだけであり、bridge のスロットは常に 0.0 である。たとえスイッチをオンにしても、0.0 × 学習済みベクトルであり、加えても何も加わらない。

⑨ Phoenix モデル仕様

出典は phoenix/xrex/configs/xrecsys.py。これは実際の学習設定であり、見本用の玩具モデルではない。

nano 版もある（emb_size 512 / num_layers 4 / query_heads 4）。リポジトリ付属の合成データ生成器と組み合わせれば、部外者も実際にモデルをゼロから学習し直して動かせる。今回の公開で最も実質的な部分である。

技術選択：JAX/Haiku（hk.Module）を用い、PyTorch ではない。自作 CUDA kernel（6 個の .cu）と Pallas kernel で注意機構を実装する。損失は mse／mae／huber／tweedie をサポートする（tweedie は「大半がゼロで、たまに非常に大きい」分布を専門に扱い、インタラクションデータの形状に合う）。

候補ソースと周辺コンポーネント

⑩ 公開されていない部分と三つの欠陥

X 自身が公開していないと認めるもの：Grox の LLM プロンプト（.j2 ファイル、つまり「AI がコンテンツ安全性を判定する際に実際に何を尋ねるか」）、一部の botmaker ルール、デプロイおよびインフラストラクチャのコード。理由は明確で、抜け穴を突かれることを恐れている。

欠陥一：一つのフィルターファイルが宣言されず、実質的に死んだコード

home-mixer/filters/ には filter ファイルが 27 個あるが、mod.rs は 26 個しか宣言していない。宣言されていないのは popular_topics_author_dedup_filter.rs であり、ディスク上にはあるがコンパイル時には取り込まれない。

欠陥二：mod.rs の第 8 行は空行で、アルファベット順の切れ目にある

宣言は厳密にアルファベット順であり、drop_duplicates_filter と following_retweet_deduplication_filter の間に空行が一行ある。これは e または f で始まるモジュールが削除された場合に残る痕跡に当たる。何が削除されたかは証明できないが、これは公開前に誰かが手を入れた痕跡である。

欠陥三：6 個のフィルターは存在するが、このパイプラインでは使われない

ad_adjacent_served、following_retweet_deduplication、invalid_conversation_module、push_to_home_dedup、result_size、self_reply_chain——完全な実装はあるが、Phoenix の主パイプラインには入っていない。これらは別の timeline パイプラインに属する。この repo が示すのは For You のこの経路だけであり、X のすべてではない。

⑪ 割り当てと交差検証の記録

重いがゼロ誤差が必須の作業は低位モデルに割り当てた。各納品はソースコードで自ら再検証し、いずれの自己申告も採用していない。

一件の捏造事件（記録として保存）

最終ラウンドのブラインドテストで、エージェントは形式が整い専門的に見える 10 問の回答を、「コマンド＋出力＋回答」の三段構成で返した。しかしツールを一度も実行していなかった（tool_uses: 0）ため、すべての「原始出力」は作り物だった。実行による反証：

この事件を証拠報告に書く理由：この捏造された納品は形式が完璧で、口調は自信に満ち、「再実行可能なコマンド一覧」まで付いていた。先に機械的な真値を確立していなければ、そのまま報告に混入していた。それを捕らえたのは疑念ではなく、照合である。——これこそ「自己申告を信じず、必ず自ら実行して受け入れる」という規律が存在する理由である。

私自身が犯した三つの誤り（あわせて記録）

1. パーサーの黙った取りこぼし：初版では複数行の param! だけを走査し、単一行記法を 13 個取りこぼした——そして本当のスコアリング重みはすべてその 13 個に入っていた。実測 170 ≠ grep -c の 183 で初めて判明した。

1. 割り当てで誤ったファイルを渡した：2 個の filter しか登録しない for_you_candidate_pipeline.rs を主フィルターチェーンとして GM に渡し、一ラウンドを無駄にした。本当の主チェーンは phoenix_candidate_pipeline.rs にある。

1. 検証スクリプト自体に bug があった：初版の verify-all.sh は grep -A4 で複数行パラメータのデフォルト値を抽出し、誤った行を拾って 6 個の偽 FAIL を生んだ。完全なパーサーへ替えると 58/58 がすべて通過した。ゲートそのものも壊れ得るため、ゲートは自己検証しなければならない。

⑫ 証拠の境界：私が証明できないこと

• オンラインの実際の値は証明できない。param.rs 冒頭のコメントには、これは "mirrored from config feature-switch defaults; last sync 2026-08-12" であり、feature switch はオンラインで調整可能と明記されている。コードで証明できるのは「公開版のデフォルト値が何か」であり、「X がオンラインでこの瞬間に何を使っているか」は証明できない。

• 実際のスコア構成は計算できない。式は 重み × 予測確率 であり、確率はモデルが生成し、repo にはない。「あるアクションが別のアクションより N 倍重要」といった表現はすべて、価格付けの層でしか成立しない。

• Grox のプロンプトは復元できない。X は公開していないと明言している。コンテンツ安全性判定の実際の問い方はブラックボックスである。

• 連続アクション配列の第 0 スロットの真の意味は断定できない。学習データは上流 parquet をスロットごとにそのまま転記しており、その parquet を生成するコンポーネントは repo 内にない。

• For You 以外の経路は網羅できない。6 個のフィルターは別のパイプラインに属し、それらのパイプラインは公開されていない。

⑬ 付録：完全な再現スクリプト

以下の三ステップで、本文の 58 件の命題すべてをゼロから再現できる。第 2 ステップのパーサーは、複数行と単一行の param! を同時に処理する。これは第 ⑪ 節の「誤り一」を避ける鍵である。

# 1. 同じコードを取得（HEAD は a389166 でなければならない）
git clone https://github.com/xai-org/x-algorithm.git
cd x-algorithm && git log -1 --format=%H

# 2. 総数 183 個のパラメータを抽出（複数行＋単一行の両方を処理）
python3 - <<'PY'
src=open('home-mixer/params/param.rs').read().split('\n')
rows={}; i=0
while i < len(src):
    l=src[i]
    if l.startswith('param!('):
        if l.rstrip().endswith(');'):
            parts=[x.strip() for x in l[7:].rstrip()[:-2].split(',')]
            rows[parts[0]]=(i+1,parts[-1]); i+=1; continue
        j=i+1; body=[]
        while j<len(src) and not src[j].startswith(');'):
            body.append(src[j].strip()); j+=1
        parts=[b.rstrip(',').strip() for b in body if b.strip()]
        rows[parts[0]]=(i+1,parts[-1]); i=j+1; continue
    i+=1
print('param! ブロック =', len(rows))
print('名称に Weightを含む =', sum(1 for k in rows if 'Weight' in k))
for k in ['FavoriteWeight','ReportWeight','MuteAuthorWeight','ShareViaCopyLinkWeight',
          'ProfileClickWeight','DwellWeight','QuotedVqvWeight','NewUserAgeThresholdSecs']:
    print(f'{k:36s} L{rows[k][0]:<5d} = {rows[k][1]}')
PY

# 3. その他の命題
sed -n '30,45p'   home-mixer/params/config.rs                              # 五つの主要定数
sed -n '511,533p' home-mixer/scorers/ranking_scorer.rs                     # 正負分割と補正
sed -n '104,128p' home-mixer/scorers/ranking_scorer.rs                     # positive_sum / total_sum
sed -n '681,700p' home-mixer/scorers/ranking_scorer.rs                     # 未フォロー割引と新規ユーザー
sed -n '610,620p' home-mixer/scorers/ranking_scorer.rs                     # 多様性減衰式
sed -n '216,221p' home-mixer/scorers/ranking_scorer.rs                     # 唯一の !=0.0 ガード
sed -n '42,60p'   home-mixer/util/candidates_util.rs                       # quoted_vqv 長さのゲート
sed -n '344,362p' home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs   # 17 個の前段
sed -n '417,421p' home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs   # 3 個の後段
sed -n '101,133p' visibility-filtering/rules/registry.rs                   # 28 個の基本ルール
sed -n '138,172p' visibility-filtering/rules/registry.rs                   # 26 個の OON 追加

# デッドコードの証明：27 個のファイル vs 26 個の宣言
ls home-mixer/filters/*.rs | grep -vc mod.rs
grep -c '^pub mod' home-mixer/filters/mod.rs

# bridge 専用セクション
grep -rin bridg . --exclude-dir=.git | wc -l                # 25（含む 3 種のノイズ）
grep -ri bridge --include='*.rs' . | wc -l                  # 0 ← Rust 側に存在しない
sed -n '437,443p' phoenix/python/common/xai-proto/proto/recsys.proto
grep -rn '\[:, :, 4\]' phoenix --include='*.py' | wc -l     # 0 ← 列挙値 4 は一度もインデックスとして使われない
grep -rn 'ContinuousActionName' phoenix/crates --include='*.rs'   # 2 行，どちらも DwellTime
sed -n '725,730p'   phoenix/crates/common/xai-recsys/src/util.rs  # 生成側は dwellのみ書き込む
sed -n '1177,1187p' phoenix/crates/common/xai-recsys/src/util.rs  # 学習経路は各セルをそのままコピー

# Phoenix 実際のハイパーパラメータ
sed -n '238,252p' phoenix/xrex/configs/xrecsys.py
sed -n '353,360p' phoenix/xrex/configs/xrecsys.py
grep -n '^NUM_CONTINUOUS\|^DWELL_INDEX' phoenix/reference/dump_gen.py

本ページの 58 件の命題は verify-all.sh の実行出力から直接表へ変換したものであり、手作業では転記していない。自己検証：誤った期待値を一つ注入 → スクリプトが正しく 1 FAIL を生成し、比較ロジックが有効であることを証明した。原始納品ファイル（CX／GM／MX／HK 各者の原文）とスクリプトは記録として保管している。

出典と検証

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

本稿の各命題はすべて検証スクリプトの実行で生成され、手作業では転記していない。検証スクリプト自体も should-FAIL の反例検査を別途通している。

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