choco(*ﾟーﾟ)(一生中居ヅラ)

おそらく日本のツイ廃が騒いだ影響で「1日2400ポスト上限」に緩和

ポストは1日○件まで！ という話が出ていますが ソースはあるのでしょうか？ Author diversity rule（投稿者多様性ルール）のことを言っているのだと思いますが、これは2026年1月の時点で公開されていますよ？ ちなみに、わたしはその公開翌日には記事にしました。 あたかも「1日○件まででなければいけない」というような話になっているので、そもそもAuthor diversity ruleがどんなものなのか超丁寧に説明します。 長文ですが、根拠のない話よりは役に立つと思うのでぜひ最後までご覧ください。 ちなみに、scoreの話が出てきますが、前回も今回も含めて、Xはscoreに関わる「重み」の具体値は公開していません。「ナントカはナントカの○倍」というのは今回もデマです。 ￣￣￣￣￣￣￣￣￣￣ ポストを短時間に連続投稿すると、おすすめタイムラインでの表示に影響が出る可能性はあります。 ただし、ここで重要なのは、コード上では「短時間に投稿したから即ペナルティ」というより、同じおすすめフィード候補の中に、同じ投稿者の候補が複数入ったときに分散されるという処理になっている点です。 この件に関連する主なコードは以下です。 author_diversity_scorer.rs retweet_deduplication_filter.rs dedup_conversation_filter.rs 結論から言うと、 連続投稿は、通常のポストだけでなく、リポスト・引用リポスト・リプライも注意した方がいい、という話にはなります。 ただし、それぞれの処理は少し違います。 連続投稿やリポストの表示に関係する処理として、まず重要なのがこの2つです。 author_diversity_scorer.rs retweet_deduplication_filter.rs この2つは、似ているようで役割が違います。 大きく分けると、 対象：誰を見ているか / 何を見ているか 処理：scoreを下げるのか / removedに入れるのか が違います。 ◆author_diversity_scorer.rsの役割 author_diversity_scorer.rsは、同じauthor_idのポストばかりがおすすめタイムラインに並ばないようにする処理です。 コード上ではauthor_countsで同じauthor_idの出現回数を数え、2件目以降にmultiplierをかけてscoreを調整します。 つまり、同じ投稿者の候補が複数ある場合、最初の1件はそのままに近い形で扱われ、2件目、3件目と出てくるほどscoreが下がりやすくなります。 ここで大事なのは、これは削除（ペナルティ）ではなく、scoreを下げる処理だという点です。 具体例： Aさんが短い間に5回ポストしたとします。 その結果、ある閲覧者のおすすめフィード候補の中に、Aさんのポストが複数入ったとします。 その場合、 1つ目のAさんのポスト →　比較的そのままのscore 2つ目のAさんのポスト →　multiplierによってscoreが下がる 3つ目のAさんのポスト →　さらにscoreが下がりやすい というように、同じauthor_idの候補が連続して出すぎないように調整されます。 そのため、Aさんのポストが完全に消えるとは限りませんが、おすすめタイムライン上でAさんのポストばかりが連続して並びにくくはなります。 つまり、通常ポスト・リポスト・引用リポスト・リプライを短時間に大量に行うと、同じauthor_idの候補が増えやすくなり、結果としてAuthorDiversityScorerの影響を受けやすくなる、ということです。 ◆retweet_deduplication_filter.rs の役割 次にretweet_deduplication_filter.rsです。 これは、同じ元ポストのリポストが複数表示されるのを防ぐ処理です。 ここは「同じ内容のポスト」というより、正確には同じ retweeted_tweet_idを持つ候補を見ています。 コードでは、リポストの場合はretweeted_tweet_idを使い、リポストではない通常ポストの場合はtweet_idを使ってdedup_idを作ります。 そして、同じdedup_idがすでに出ていれば、後から来た候補はremovedに入ります。 つまり、こちらはscoreを下げるのではなく、重複している候補を削除する処理です。 具体例： 閲覧者がフォローしているBさんとCさんが、どちらもAさんの同じポストをリポストしたとします。 この場合、閲覧者のおすすめタイムラインに、 ・BさんがリポストしたAさんのポスト ・CさんがリポストしたAさんのポスト が両方並ぶと、同じ元ポストが2回表示されてしまいます。 そこでRetweetDeduplicationFilterが働きます。 Bさんのリポスト →　最初に出たのでkept Cさんのリポスト →　同じretweeted_tweet_idなのでremoved という処理です。 この処理は、Aさんのアカウント自体やAさんの元ポストを直接下げるというより、閲覧者のおすすめタイムライン上で同じ元ポストのリポスト表示が重複しないようにする処理と考えられます。 2つの違いを整理すると author_diversity_scorer.rsは、 同じ人のポストが 並びすぎないように score を下げる処理 です。 一方で、retweet_deduplication_filter.rsは、 同じ元ポストのリポストが 重複して表示されないように removed に入れる処理 です。 つまり、 author_diversity_scorer.rs →対象はauthor_id →処理はscoreの調整 →表示順位を下げる方向 retweet_deduplication_filter.rs →対象はretweeted_tweet_idまたはtweet_id →処理はkept / removed →重複候補を削除する方向 という違いがあります。 ◆リプライの扱いはどうなる？ 次に、リプライです。 リプライに関係する主な処理は以下です。 author_diversity_scorer.rs dedup_conversation_filter.rs ここでもポイントは、 人を見る処理なのか、 conversationを見る処理なのか です。 ◆リプライもauthor_idベースでは対象になる リプライもPostCandidateの一種なので、author_idを持ちます。 そのため、同じ人のリプライがおすすめタイムライン候補内に複数入った場合、author_diversity_scorer.rsの影響を受ける可能性があります。 たとえば、Aさんが短時間にいろいろな人へリプライしたとします。 Bさんのポストへリプライ Cさんのポストへリプライ Dさんのポストへリプライ Eさんのポストへリプライ この場合、リプライ先が違っていても、投稿者はすべてAさんです。 つまり、おすすめタイムライン候補内では同じ author_idの候補が複数ある状態になります。 そのため、 1つ目のAさんのリプライ →比較的そのままのscore 2つ目のAさんのリプライ →score が下がりやすい 3つ目のAさんのリプライ →さらに下がりやすい という処理になり得ます。 なので、リプライも通常ポストと完全に別枠というより、同じauthor_idを持つ候補として、Author Diversityの影響を受ける可能性があると考えられます。 ◆dedup_conversation_filter.rs の役割 リプライでさらに重要なのが、dedup_conversation_filter.rsです。 これは、同じconversationに属する候補が複数ある場合、代表的な1件だけを残す処理です。 コード上では、候補のancestorsの中から最小のIDを使ってconversation_idを作り、同じconversation_idの候補が複数ある場合は、scoreが高い候補をkeptに残します。 それ以外の候補はremovedに入ります。 つまり、こちらはauthor_diversity_scorer.rsのように scoreを下げる処理ではなく、同じconversation内の重複候補を削除する処理です。 具体例： Aさんが自分のポストに対して、 連続でリプライをつなげたとします。 いわゆるツリー投稿のような状態です。 このとき、同じconversationに属する候補が複数おすすめタイムライン候補に入る可能性があります。 その場合、 DedupConversationFilterは、 scoreが一番高いリプライ →kept それ以外の同じconversationの候補 →removed という処理を行います。 また、バズったポストに複数人がリプライしている場合も、同じconversationに属する候補が複数あれば、同じように代表候補だけが残りやすくなります。 ◆リプライで注意すべきこと リプライについては、2つの方向から制限がかかる可能性があります。 1つ目は、author_diversity_scorer.rsによる author_idベースの調整です。 これは、同じ人のリプライが候補内に複数ある場合、2件目以降のscoreが下がりやすいという処理です。 2つ目は、dedup_conversation_filter.rsによる conversation ベースの重複削除です。 これは、同じ会話に属する候補が複数ある場合、scoreが高い1件だけが残り、それ以外はremovedに入るという処理です。 つまり、リプライは、 投稿者としての重複 と conversationとしての重複 の両方で整理される可能性があります。 ◆「リプライしまくれば露出が増える」は間違い ここから分かるのは、リプライを大量にすれば、その分だけおすすめタイムラインで大量に表示される、とはなりにくいということです。 もちろん、リプライ自体が候補に入る可能性はあります。 しかし、同じauthor_idのリプライが複数あれば AuthorDiversityScorerによってscoreが下がりやすくなります。 さらに、同じconversationに属するリプライが複数あれば、DedupConversationFilterによって代表的な1件だけが残り、それ以外はremovedに入る可能性があります。 なので、 リプライをたくさんすれば、 その数だけ おすすめタイムラインに表示される という考え方は間違いです。 このコードから言えるのは、 リプライを大量にしても、 おすすめタイムライン上では すべてがそのまま表示候補 として残るとは限らない ということです。 ◆まとめ 今回の処理をまとめると、こうです。 author_diversity_scorer.rsは、同じauthor_idの候補が並びすぎないようにscoreを下げる処理です。 つまり、対象は「人（アカウント）」です。 通常ポスト、リポスト、引用リポスト、リプライであっても、同じauthor_idの候補が複数あれば影響を受ける可能性があります。 一方で、retweet_deduplication_filter.rsは、同じ retweeted_tweet_idのリポストが重複して表示されないようにする処理です。 対象は「同じ元ポスト」です。 最初の候補はkeptに残り、重複する候補はremovedに入ります。 そして、dedup_conversation_filter.rsは、同じconversationに属する候補が複数ある場合に、scoreが高い代表候補だけをkeptに残す処理です。 対象は「リプライ」です。 そのため、ポスト・リポスト・リプライを短時間に大量に行った場合、直接「短時間だからペナルティ」というより、同じauthor_id、同じretweeted_tweet_id、同じconversationがおすすめタイムライン候補内で重なりやすくなります。 その結果、 ・同じ人の投稿はscoreが 　下がりやすい ・同じ元ポストのリポストは 　重複削除されやすい ・同じconversationのリプライは 　代表候補以外が削除されやすい ということが起きます。 結論としては、 連続投稿は、通常ポストだけでなく、リポスト・引用リポスト・リプライも注意が必要。 大量にしても全部がおすすめタイムラインに表示されるわけではなく、diversityとdeduplicationによって分散・整理される。 というのがソースコードに基づく 連投は必ずしも有効ではない という解釈です。 ね？ 1日○件まで！ なんて書いてないでしょう？