自作Chrome拡張のXの動画ダウンロードボタンが消えた——DOM構造の変化を追って復活させた

結論

前に自分で作ったXの動画ダウンロードボタンが、いつの間にか画面から消えていた。 Xのタイムラインを開いても、動画ツイートのアクションバーに出るはずのボタンがどこにもない。

Claude Code に調べさせたら、原因は拡張機能ではなくX側にあった。 Xが動画の描画方式を変えて、再生を始めるまで <video> 要素をDOMに置かなくなっていた。 拡張の動画判定（hasVideo）は <video> の有無を頼りにしていたので、「動画なし」と判定し続けてボタンを付けなくなっていた、というのが真相だった。

直し方はシンプルで、動画判定に別の手がかりを足すこと。再生前の状態でも残っている再生ボタンやサムネイル画像を querySelector で拾うフォールバックを 3つ追加して、ボタンを復活させた。変更後にセキュリティレビューもかけて、 DOM判定を広げただけで新しい穴は増えていないことを確認してからコミットした。

何が起きたか

きっかけは「そういえば動画のダウンロードボタン、最近見てないな」という違和感だった。 Chrome DevToolsでXを開いて確かめてもらったら、やはり動画ツイートにボタンが付いていない。

この手のバグは、原因が2つに割れる。

拡張機能そのものが壊れている（エラーで死んでいる、無効化されている）
拡張は生きているが、対象サイト側のDOM構造が変わって判定が空振りしている

まず1を潰すために、chrome://extensions をDevTools経由で開いて、 Shadow DOMを掘って拡張の状態を確認させた。有効で、エラーもなし。拡張は生きていた。となると2が濃厚で、Xの画面のDOMを直接見にいくことにした。

DevToolsで一緒にDOMを追った

ここからは、自分が「どこを見てほしいか」を指示して、 Claude Code に実際のX画面のDOMを掘らせる作業になった。ブックマーク画面と検索フィードを開いて、動画ツイートのDOMツリーを覗いていく。

分かったのは、再生前の動画ツイートには <video> 要素が存在しないという事実だった。以前は動画ツイートを画面に出した時点で <video> がDOMに入っていたはずだが、今は再生ボタンを押すまでプレースホルダー（サムネイル＋再生ボタン）しか置かれていない。

拡張の content.js は、ツイート要素の中に <video> があるかどうかで動画判定していた。つまり、Xが遅延ロードに切り替えた瞬間から、判定が全部「動画なし」に倒れていたわけだ。ボタンが消えたのは拡張のバグではなく、判定ロジックが前提にしていた世界が変わったから、という気持ちのいい切り分けができた。

動画判定にフォールバックを足して復活させた

原因が分かれば直しは早い。<video> が無くても「これは動画ツイートだ」と言える手がかりを、再生前のDOMから拾えばいい。再生ボタン・プレビューの覆い・サムネイル画像あたりが候補になる。

Claude Code に、hasVideo 判定へ次のような querySelector のフォールバックを足させた。

// <video> が無くても、再生前の手がかりで動画ツイートと判定する
const hasVideo =
  el.querySelector('video') ||
  el.querySelector('[data-testid="playButton"]') ||
  el.querySelector('[data-testid="previewInterstitial"]') ||
  el.querySelector('img[src*="video_thumb"]')

playButton は再生ボタン、previewInterstitial は再生前にサムネイルを覆う要素、 video_thumb を含む画像は動画のサムネイルだ。どれか1つでも当たれば動画とみなす。 <video> を先頭に残したのは、再生後のツイートも従来どおり拾えるようにするため。

目視で確認するまでは「直った」と言わない

判定を広げた程度の修正でも、実際に画面でボタンが出るまでは信用しないことにしている。拡張をリロードして、検索フィードとブックマーク画面の両方を開き直してもらった。

検索フィードでは動画ツイート7件すべてに、再生前の状態でダウンロードボタンが付いた。ブックマーク画面でも動画ツイート3件すべてで、サムネイルと再生ボタンが並ぶアクションバーにボタンが表示された。スクリーンショットで見た目が崩れていないところまで確認して、ようやく「復活した」と判断した。

セキュリティレビューをかけてからコミットした

DOM判定を触っただけとはいえ、拡張機能はXのページに注入されて動くコードなので、念のためセキュリティレビュー（/security-review 相当）を走らせた。

結果は指摘ゼロ。今回の差分は hasVideo というクライアント側のDOMヒューリスティックに querySelector のフォールバックを3つ足しただけで、

新しいデータの出口（sink）は増えていない
新しいデータフローも生まれていない
既存の tweetUrl の組み立て、chrome.runtime.sendMessage で送るペイロード、トーストの innerHTML 補間には一切手を付けていない

最悪ケースでも「動画じゃないツイートに誤ってボタンが出る」というUIの誤検知どまりで、これまで越えられなかったセキュリティ境界を新たに越えるものではない、という整理だった。安心して content.js の変更だけをコミットした（background.js などの以前からの未コミット変更は今回の話とは別なので、そのまま残してある）。

学び

ボタンが消えた＝自分のコードが壊れた、とは限らない。 対象サイトのDOMは黙って変わる。拡張が生きているかを先に潰してから、相手のDOMを疑う順序で切り分けると早い
DOM判定は「今ある要素」に賭けると脆い。 <video> 一本足打法だと、遅延ロードに切り替えられた瞬間に全滅する。再生ボタン・サムネイルなど、複数の手がかりでORを取ると壊れにくい
人間は違和感を拾う係、AIは掘る係。 「ボタン見ないな」という肌感覚から始めて、 DOMを実際に掘って原因を突き止め、修正して画面で確認するところまでは道具に回させると速い
小さな差分でもセキュリティレビューは効く。 「DOM判定を広げただけ」を、 sink・データフロー・既存の危険箇所に触れていないかという観点で言語化してもらえると、自分の中で「これは安全な変更だ」と腹落ちしてからコミットできる