YouTubeの20秒巻き戻り、AI解析が導いた競合仮説と検証の課題

動画が20秒巻き戻る現象の観測と公式仕様との乖離

現時点で確定した原因は確認されていません。古いタブの再読み込みで発生しやすく、URLの古い時刻とサーバの進捗が競合するという仮説が有力です。利用者向けの確実な修正方法は確認されていません。動画配信サービス「YouTube」のウェブ版において、視聴再開時に再生位置が意図せず巻き戻る現象が報告されました。この挙動は、単にブラウザのタブを切り替えたり、一時停止と再生を繰り返したりする通常の操作では発生しません[1]。動画を一時停止したまま一定時間放置し、古いタブに戻ってページが再読み込みされる「ソフトリロード（soft reload）」の状況で主に発生すると報告されています[2]。

原記事を執筆した技術者の再現手順では、明瞭な規則性が確認されました。動画を一時停止した後にタブを閉じ、再度そのタブを開くと、停止位置より20秒前に戻って復元されました[3]。同じタブの再開を繰り返すと、そのたびに20秒ずつ後退しました[4, 5]。ブラウザを終了して再起動した場合も、さらに20秒後退しました[6, 7]。著者はキーボード操作の「Ctrl+W」でタブを閉じ、「Ctrl+Shift+T」で再開して再読み込みを行う経路でも、1回あたり20秒の巻き戻りが発生することを確認しました[8]。

この観測結果は、YouTube公式が定めている仕様と大きく乖離しています。YouTubeの公式ヘルプでは、ログイン済みの端末において、未完了の動画は通常「前回停止した位置」から再開されると説明されています[9, 10, 11, 12, 13]。再生位置が毎回決まって20秒も巻き戻る挙動は、公式が案内する標準的な動作には含まれていません。

YouTubeプレイヤーを外部プログラムから操作するためのIFrame Player APIにおけるキーフレーム補正だけでは、この現象を説明しにくい側面があります。YouTubeの公式プレイヤー仕様（IFrame Player API）では、再生開始位置を指定する「start」や「seekTo」の命令を実行した際、指定時刻に最も近い「キーフレーム」へ移動することが説明されています[14, 15]。キーフレームとは、他のフレームを参照せずに単独で画像を表示できる基準フレームのことです。このキーフレームへの補正によって再生ヘッドが指定時刻より前に戻る場合でも、通常は約2秒以内にとどまると規定されています[16, 17]。

したがって、原記事で報告された固定的な20秒の後退は、通常のキーフレーム補正だけでは到底説明できません[18, 19]。公式仕様が示す約2秒という目安を大幅に上回っているためです[20]。この乖離は、プレイヤーの内部で別の復元処理や競合といった追加要因が働いている可能性を強く示唆しています[21]。

以下の表は、著者が観測した後退量とYouTube公式仕様の目安を比較したものです[3, 8, 14, 18, 16]。

対象の操作・仕様	再生位置の後退量	公式仕様との比較	出典
初回のタブ再開（Ctrl+W → Ctrl+Shift+Tなど）	20秒後退	通常目安を大きく超過	原記事の観測結果
2回目のタブ再開	さらに20秒追加後退	連続して固定値が累積	原記事の観測結果
ブラウザ全体の終了・再起動	さらに20秒追加後退	環境再起動でも固定値が発生	原記事の観測結果
公式仕様のキーフレーム補正（start / seekTo）	通常は約2秒以内	映像圧縮に伴う標準的な補正	YouTube公式仕様

ChatGPTとブラウザ自動化を活用した内部解析の足跡

原因を探るため、原記事の著者は生成AIの「ChatGPT」を調査パートナーとして活用しました。著者がChatGPTに依頼して作成させたのは、動画のシーク（seek: 再生位置の変更）発生を監視する「Tampermonkey」スクリプトです[22, 23]。Tampermonkeyとは、ブラウザ上で独自のJavaScriptを実行してウェブページの挙動を制御できる拡張機能のことです。著者は、このスクリプトをブラウザに導入した結果、ページの再読み込み時にシーク処理が実行されることを確認しました[24, 25]。

シークの発生を確認した著者は、処理を一時停止させる命令である「debugger;」のコード行を自らスクリプト内へ追加しました[26]。これによって、ブラウザの開発者ツール上で処理を一時停止させ、詳細な調査を行える状態を整えました。著者は後段の解析で、Chromeのデバッグ用ポートにChrome DevTools MCPを接続しました。さらに、OpenCodeからブラウザを操作・検査できる体制を構築しました[27]。この一連の作業記録から、調査はChatGPT単独で自動実行されたのではなく、著者自身による環境構築とブラウザ自動化ツールの組み合わせによって進められたことが分かります。

この調査で使われた「Chrome DevTools Protocol（CDP）」は、ブラウザ内部の通信やスクリプト実行を外部プログラムから制御・検査するためのプロトコルです[28]。また「Model Context Protocol（MCP）」は、AIモデルが外部ツールやブラウザと安全に連携するための標準規格を指します。Google公式の「Chrome DevTools for agents」でも説明されている通り、MCPサーバーを介することで、AIエージェントは稼働中のブラウザにアクセスし、内容の読み取りや検査、デバッグを行えます[29]。

AIは複雑に難読化されたJavaScriptコードの読解において力を発揮しました。ウェブサイトの大規模なスクリプトは、ファイルサイズ削減や保護を目的に変数名や構造が難読化されています。AIはコールスタック（関数の呼び出し履歴）や関連する変数、ネットワーク通信の流れを整理し、何が起きているかの仮説を組み立てる作業を支援しました[30]。その結果、視聴位置を記録するチェックポイント（checkpoint: 視聴進捗データ）は、ブラウザのローカル保存領域ではなくYouTubeのサーバから取得されると推測されました。タブを閉じた時点の時刻をXとすると、サーバは「X−20秒」の値を返している可能性があります[31]。

しかし、この結論を客観的な事実として確定するには大きな課題が残されています。原記事の公開ページには、ネットワーク通信の完全な記録である「HAR（HTTP Archive）」ファイルや、送受信されたリクエスト・レスポンスの本文、時系列ログが掲載されていません[32]。そのため、サーバ側が本当にマイナス20秒の値を返していたかどうかを、第三者が独立して検証することはできません。著者自身もこの調査を網羅的（thorough）なものではなかったと認めており、結論を確認するための追加検証が不足していたと振り返っています[33]。

今回の事例は、AIを活用した障害調査における実務的な教訓を示しています。AIは観測用スクリプトの雛形作成やコードの推論、調査手順の言語化において優れた能力を発揮します[34]。しかし、AIが導いた推論はあくまで仮説に過ぎません。障害調査では、まず期待される動作との差分を明確にします。次に、独立した環境で再現を繰り返します。リクエスト・レスポンス本文や、関数呼び出しの履歴であるスタックトレースも保存します[35]。

なぜ今話題になったのか：公開から15日後の拡散と環境変化

この問題が技術者の間で注目を集めた背景には、原記事の公開時期とオンラインコミュニティで拡散された時期との間に生じた「時間のずれ」が存在します。原記事がブログ上に公開された日付は2026年8月22日であり、更新日も同じく2026年8月22日と記録されています[36]。しかし、米国の著名な技術系フォーラム「Hacker News」にこの話題が投稿されたのは、2026年9月6日17:01

UTC（日本時間では2026年9月7日02:01 JST）でした[37]。

原記事の公開からHacker Newsで話題になるまでには、暦日ベースで15日間の開きがありました[38]。技術的な事象が発見・記録された時期と、それが社会的に広く可視化された時期が一致していなかったことが、このタイミングで議論が巻き起こった直接の理由です[39]。

さらに同時期には、ウェブブラウザ側の環境変化も重なっていました。Google Chromeでは、次期バージョンである「Chrome 152」の先行安定版（early stable）が、2026年8月12日に一部のユーザーに向けて配信されていました[40]。その後、2026年8月25日には正式な安定版（stable）への昇格と、数週間にわたる段階的な配信開始が発表されています。このように、原記事が執筆された8月下旬は、ブラウザ側に大きな更新が加わる移行期間にあたっていました。

ただし、このブラウザの更新とYouTubeの巻き戻り現象との間に因果関係があるかどうかは断定できません。原記事には、検証に使用したChromeの正確なバージョン番号や、利用していたデスクトップOSの種類が一切記録されていないためです[41, 42]。また、Chrome 152においてメディア再生のシーク位置に狂いが生じるような回帰不具合（デグレード）が発生したという一次資料も確認されていません。したがって、ブラウザの更新が今回の現象を引き起こしたと結論づけることは不可能です。

誰に影響するのか：PC版Webの利用形態と再視聴の負担

今回の現象は、原記事ではPCのWeb版経路で確認されました。最新のChromeなどの現行ブラウザには、長期間アクセスされていないタブを一時停止（freeze）したり、メモリから破棄（discard）したりするライフサイクル管理機能が備わっています[43, 44]。タブがdiscardされていた場合、ユーザがその古いタブを再び開いた際にページが自動再読み込みされます。

このブラウザによる再読み込みの仕組みは、今回の巻き戻り現象を誘発する有力な条件と考えられています[45, 46]。しかし、ブラウザのライフサイクル機能自体は一般的なタブの復元処理に過ぎず、YouTube固有の固定的な20秒後退という数値をChrome単独が生成した証拠にはなりません[47, 48, 49]。

利用環境による挙動の違いも報告されています。原記事の著者が同じアカウントのチェックポイントを用いて対照実験を行ったところ、ウェブブラウザで開いた場合は再生位置がずれましたが、YouTubeのAndroidアプリでは毎回正しい時刻が読み込まれました[50, 51, 52]。なお、Android向けアプリは2026年9月5日にGoogle Play上で更新されていますが、公開された更新履歴には視聴再開やチェックポイントに関する仕様変更の記述はありませんでした[53, 54]。この対照結果は、アカウント全体の記録そのものが壊れていたわけではなく、ウェブ版特有の優先順位や処理に原因があった可能性を示唆しています[55]。ただし、サーバーが端末の種類に応じて異なる値を返していた可能性も排除できません。

また、この対照実験の結果を他の環境へそのまま広げて解釈することはできません。原記事には、異なるGoogleアカウントでの比較や、複数の動画、地域別の差異、さらにはSafariやFirefoxといった他のブラウザ、iOSアプリでの検証結果が記録されていないためです[56, 57]。

この現象によって利用者が受ける直接的な不利益は、すでに視聴し終えた場面を余計に見直す手間が生じることです[58]。停止した位置から毎回20秒前に戻されるため、動画を中断して再開するたびに時間のロスが発生します。さらに、タブの再開やブラウザの再起動を繰り返すほど、20秒ずつの後退が積み重なっていきます[59]。単なるタブ切り替えでは起きず、時間を置いた古いタブの再読み込みで主に再現するため、日常的にタブを開きっぱなしにする人ほど影響を受けやすくなります[60]。

特に長時間の動画を少しずつ視聴する利用者は、この負担を大きく受ける傾向があります[61]。視聴を途中で何度も中断し、日をまたいで古いタブから再開する頻度が高くなるためです。YouTubeの視聴履歴から動画を開く利用者にも影響する可能性があります。履歴のURLに残った古い再生時刻とサーバ側の進捗記録に食い違いがある場合、最新の進捗ではなく古い位置へ戻される可能性があるためです[62, 63]。これは、未完了の動画を前回位置から再開させるというYouTube公式の期待動作と明らかに反しています[64]。

ただし、サービス全体においてどれだけの利用者がこの不利益を被ったのかは明らかになっていません。YouTubeは2020年時点で月間20億人以上のユーザを抱えていましたが、これはプラットフォーム全体の規模を示す数字に過ぎません[65]。Hacker Newsのコメント欄にも同様に20秒のずれを経験したという声は寄せられていますが、それらはあくまで個別の体験談にとどまります[66]。問題の発生率や影響を受けたアカウントの総数、地域別の比率などを定量的に推定することは現時点では不可能です[67]。

何が変わるのか：再生制御の二重競合に対する修正案と今後の教訓

なぜ再生位置が巻き戻ってしまうのでしょうか。原因として、URLの時刻パラメータとチェックポイントという二つの情報源の競合が考えられます。これを本稿では「二重ソース競合」と呼びます。YouTube公式のヘルプでは、特定の再生時刻を指定して動画を共有するリンク機能（例: 末尾に t=1200s などを付与するURL）が提供されています[68]。また公式のプレイヤー仕様でも、「start」パラメータによって指定秒数から再生を開始できると規定されています。しかし、通常の視聴履歴からの再開において、URLの時刻とサーバーの進捗のどちらを優先するかという内部ルールは公開されていません[69]。

原記事の更新された整理によると、この競合は具体的な視聴の流れの中で発生します。例えば、ユーザが視聴履歴から動画を開いた際、URLにはその時点の時刻（20分など）がパラメータとして記録されます。その後、動画を40分の位置まで追加で視聴して一時停止すると、サーバー側には最新のチェックポイントとして「40分」が送信されます[70]。ところが、古いタブを一定時間後に再読み込みすると、URLの「20分」とサーバが保持する「40分」が、同時にプレイヤーへ渡される可能性があります。

WHATWGのHTML標準では、メディア要素の再生位置を移動する処理をシークと呼びます。進行中のシークは、後から始まった別のシークによって中断される場合があります[71, 72]。ページ読み込み時に複数の復元処理が同時に走れば、シークの優先順位がぶつかり合い、予期せぬ位置へ着地する現象自体は技術的に十分に起こり得ます。ただし、ブラウザ側のシーク競合という仕組みだけでは、YouTubeでなぜ毎回きっちり「20秒」という固定的な後退が発生するのかまでは説明できません[73]。

コミュニティ内では、一般的なHTTPキャッシュによる影響や、YouTubeが意図的に文脈を思い出させるために数秒巻き戻しているのではないかという推測も議論されました。しかし、HTTPキャッシュの仕様（RFC 9111）から考えてもキャッシュ単独で再生位置が後退する根拠は薄弱です[74]。また、意図的な巻き戻し機能であることを裏付けるような公式仕様の一次情報も存在していません[75, 76]。総合すると、サーバーのチェックポイント、履歴URLの古い時刻、そしてページ読み込み時の複数シークの競合という仮説が最も支持されていますが、20秒という数値を生み出している具体的な生成源は未確定のままです[77, 78, 79]。

以下の図は、URLに残った古い時刻とサーバーの進捗記録が競合し、再生位置が後退する処理の流れを整理したものです[70, 77, 79, 80]。

現時点でユーザ側が取れる確実な解決策や回避策は未確認です。検証で再現しなかったAndroidアプリでの視聴が限定的な代替手段となります。一方、この競合問題に対して、技術的な修正案の一つが考えられます。それは、再生位置を決定する際の優先順位を明確に分離する設計です。ユーザが共有リンクをクリックした場合など、明示的に開始時刻が指定されている通信では、URLの時刻パラメータを最優先として扱います。一方、ユーザが視聴履歴や古いタブから再開する場合は、認証済みユーザに対応するサーバ側チェックポイントを優先します。URLに残った古い時刻パラメータは無視するか、削除します[80]。

今回の事例は、現代のソフトウェアエンジニアリングにおけるAIとの協働について、重要な示唆を与えています。ChatGPTのようなAIツールは、巨大で複雑なウェブサービスの挙動を分析し、難解なコードを読み解きながら仮説を立てるための強力な支援者となります。しかし、AIが導き出した論理的な推論をそのまま確定した原因と過信してはなりません。問題の本質を解明し、再発防止につなげるためには、生ログの収集や厳密な対照実験といった、客観的な証拠に基づくエンジニアリングの基本姿勢が不可欠です。