Xリプライ「返信済み」判定が誤検知だった話をnoteで公開しました
本記事にはアフィリエイトリンクが含まれています。記事の内容は独自の調査・評価に基づいています。
POINTこの記事でわかること
- 1Xリプライ自動化の「返信済み判定」が誤検知していたバグの発見〜修正実録をnoteに公開
- 2原因はログイン中に常時表示される自分のアカウント名をサイドバーごと拾っていたこと
- 3同日発見したブログ記事のcategory表記ゆれバグ(クラスター監査漏れ)も併記
- 4note #30「Claude Codeブロガーpepe」より¥500で公開中
マネログ運営の筆者が、X自動リプライ運用で見つけた「動いているように見えて実は壊れていた」判定ロジックのバグについて書いた note を公開しました。
同じツイートへの二重リプライを防ぐための「返信済みチェック」が、実はページを開いた瞬間に常に true を返す状態になっていたという話です。エラーは出ない、投稿事故も起きない、それでも機会損失は静かに積み重なっていました。
この note では、バグに気づいた瞬間から原因特定、修正、そして同じ日に見つけたもう1つの表記ゆれバグまでを実録としてまとめています。
第30弾 note の内容ハイライト#
第30弾「Xリプライ『返信済み』判定が実は全部誤検知だった話」では以下を扱っています。
- 壊れていた判定ロジック:
document.body.innerText.includes(...)が広すぎる条件だった理由 - 気づいたきっかけ: 新着ツイートまで「返信済み」判定になった違和感
- 原因特定の手順: 実際にマッチした箇所を出力して確認する方法
- 修正後のコード:
article要素内の投稿者名だけを見る正確な判定ロジック - もう1つのバグ: ブログ記事のcategory表記ゆれ(英語/日本語)がクラスター監査から漏れていた話
本文の詳細は note 本体でご確認ください。
想定読者#
| ✅ 向いている方 | ❌ 向いていない方 |
|---|---|
| Playwright等でDOM操作の自動化をしている方 | 自動化・スクレイピングに関心がない方 |
| X運用の自動化フローを組みたい方 | ブログ運営やClaude Codeに関心がない方 |
| 「動いているのに実は壊れている」バグの見つけ方を知りたい方 | 具体的なコード例より概念だけ知りたい方 |
ご購入は note 本体で#
「Xリプライ『返信済み』判定が実は全部誤検知だった話」を note で見る →価格: ¥500(税込)/ Claude Codeブロガーpepe(bloger_pepe)
あわせて読みたい#
Xリプライ判定バグに関するよくある質問#
FAQよくある質問
Qなぜ「返信済み」判定が誤検知していたのですか?
Xにログイン中は画面左のサイドバーに自分のアカウント名が常時表示されます。判定コードがページ全体のテキストを対象に自分のハンドル名を検索していたため、実際に返信していなくてもサイドバーの表示だけで「返信済み」と誤判定していました。
Qどうやって修正しましたか?
ページ全体ではなく、ツイート本体とその返信スレッドを含む article 要素の中にある投稿者名だけを見るように判定範囲を絞りました。これによりサイドバーやおすすめ欄の表示を誤って拾うことがなくなりました。
Qこのバグにはどうやって気づいたのですか?
投稿から3時間しか経っていない新着ツイートまで「返信済み」判定になっていたことに違和感を覚え、実際にマッチした文字列の前後100文字を出力して確認したところ、サイドバーのナビゲーション文言だとわかりました。
Qcategory表記ゆれバグとはどんな内容ですか?
ブログ記事のfrontmatterで、2本の記事だけ category が英語表記「side-job」になっており、他の記事が使う日本語表記「副業」と一致しないため、トピッククラスター監査スクリプトの集計から漏れていました。記事自体は正常に公開されビルドも通るため、監査スクリプトを実行するまで気づけない種類のバグでした。
QDOM操作の自動化で同じ失敗を避けるにはどうすればいいですか?
一致条件(includes・完全一致など)を書いたら、実際にマッチした箇所を一度出力して目で確認するステップを挟むことをおすすめします。「エラーが出ない」「動いているように見える」バグは可視化されにくく、機会損失として静かに積み重なるため注意が必要です。
参考資料#
更新履歴 (1件)
- 2026.07.02公開(note第30弾の告知)