BRAVIAのYouTubeを時間制限してみた【Python・ADBで作って、運用を断念するまで】

こんにちは、えびかずきです！

今回は、家のBRAVIAでYouTubeだけを時間制限する仕組みを作ってみたので、その記録を紹介したいと思います。

やりたかったのは、食事の時間や夜間だけYouTubeを使えなくすること。地デジやHDMIにつないだゲーム機まで止めたいわけではないので、テレビ全体ではなくアプリ単位で制御できないか考えました。

結論からいうと、YouTubeを無効化・有効化する操作は実機で確認できました。ただし、長期運用ではADB接続を復旧できず、2026年10月22日に開発を中止しています。

今回は完成したツールの導入手順ではなく、「どこまでできて、どこでうまくいかなかったか」という開発記録です。

こんな人におすすめ：

• Pythonからテレビなどの家庭内機器を操作してみたい
• 時刻指定の自動化で、PCや接続先が止まっていた場合の扱いを知りたい
• 手動では動く仕組みを、長期運用へ進めるときの検証例を見たい

今回試した構成のイメージです。実機写真ではなく、説明用のイラストです。

開発環境

今回使った環境はこちらです。

ADBは、PCからAndroid端末へコマンドを送るためのツールです。今回は家庭内LAN経由でテレビに接続し、YouTubeアプリの状態確認と切り替えに使いました。

なお、以下はこの機種と環境での結果です。他のAndroid TVやGoogle TVでも同じ挙動になるとは限りません。

YouTubeだけを止めるには？

対象にしたのは、テレビ向けYouTubeアプリのcom.google.android.youtube.tvです。

時間帯の設定例は、次のようにしました。

切り替えの中心となるADBコマンドは以下の二つです。1行目が無効化、2行目が有効化になります。

adb -s <serial> shell pm disable-user --user 0 com.google.android.youtube.tv
adb -s <serial> shell pm enable --user 0 com.google.android.youtube.tv

<serial>は対象テレビの識別子に置き換える部分です。--user 0は今回試したユーザーの指定なので、別の環境では対象の確認が必要になります。

アンインストールやデータ消去は使っていません。短時間の実機試験では、無効化中はYouTubeを起動できず、再び有効化すると使えるようになりました。アカウント、履歴、設定も維持されていました。

操作自体はこれだけです。ただ、自動で毎日動かすには、もう少し考えることがありました。

「21時になったら無効化」だけでは足りない

最初は、21時に無効化、翌4時に有効化する処理を予約すればよさそうですよね。

ところが、その時刻にPCが停止していたり、テレビにつながらなかったりすると、処理できません。

さらに、実行できなかった「21時の無効化」を翌朝まで持ち越してしまうと、すでに許可時間なのにYouTubeを止めることになります。

そこで、どのタイミングにもreconcileという同じ処理を呼び出すようにしました。やることは、「今はYouTubeを使ってよい時間か確認して、その状態に合わせる」というものです。

たとえば、21時に実行できず翌朝6時に動いたなら、6時のルールに従って有効にします。過去の無効化命令をそのまま実行することはありません。

すでに正しければ、何もしない

処理の流れは下のようになります。

接続・状態取得に成功した場合の基本的な流れです。接続できなければ、この比較や変更には進めません。

まず、現在時刻から「有効であるべきか、無効であるべきか」を決めます。次に、テレビの実際の状態を読み、違っている場合だけ変更します。

すでに正しければ何もしません。このように、何度実行しても同じ状態に落ち着く性質を「冪等性（べきとうせい）」と呼びます。

これなら、決まった時刻でも、PCへログオンしたときでも、手動でも、同じ処理を使えるわけですね。

日付をまたぐ時間帯も判定する

21時から翌4時までのように、日付をまたぐ場合は条件を少し変えます。以下は判定部分を抜き出した疑似コードです。

# start、end、currentは時刻を表す値。
if start < end:
    blocked = start <= current < end
else:
    blocked = current >= start or current < end

開始時刻は含め、終了時刻は含めません。つまり、4時ちょうどから利用可能です。

また、接続の再試行中に4時を過ぎることもあります。そこで、再試行するたびに時刻を見直すようにしました。最初の判定を使い続けると、遅れて動く命令と同じ問題が起きてしまうためです。

自動化する前に、戻せることを確認する

テレビを操作するので、最初から自動運転にはしませんでした。

読み取り専用の状態確認から始め、アプリの停止、短時間の無効化・有効化、テレビを再起動した後の復旧という順に試しています。

2026年9月26日の実機試験では、次のことを確認できました。

• 無効化・有効化を3往復し、全6回の変更が正常終了した。
• 無効化中はYouTubeを起動できなかった。
• 地デジ、ホーム画面、HDMIは、確認した範囲で問題なく使えた。
• 再有効化後もYouTubeのアカウント、履歴、設定は維持されていた。
• 有効・無効の両状態でテレビを再起動し、再起動後の緊急有効化も成功した。

この試験は、最後にYouTubeを有効な状態へ戻して終了しています。

プログラム側にも、対象端末を一台に特定できなければ操作しない、タイムアウトと再試行回数に上限を設ける、変更後に状態を読み直す、といった確認を入れました。

手動の有効化・無効化には--confirmを必須にし、緊急時に有効化へ戻す専用スクリプトも用意しました。止められても、戻せないと困りますからね。

同日のリビジョンba6ebd3では、自動テスト121件とRuffのチェックも通っています。ただし、これはその時点のコードに対する結果です。数日間のADB接続が安定することまで確認できたわけではありません。

Windowsの自動実行と、テレビの電源監視

PC起動時ではなく、ログオン時に実行する

自動実行には、Windowsのタスクスケジューラを使いました。

ここで一つつまずいたのが、PC起動時の実行です。ADBの鍵を含むユーザープロファイルを使うため、対象ユーザーのInteractive実行を選んだところ、ログオン前の起動時トリガーでは動きませんでした。

そこで、対象ユーザーがログオンしたときに動くよう変更しました。サインアウト・サインインを伴う試験で、実行時刻の更新と正常終了を確認しています。

登録できたからといって、狙った場面で動くとは限らないんですね。

また、今回はPCを勝手に起こさないようにWakeToRun=falseとしました。PCの停止中やスリープ中、必要なユーザーがログオンしていない間は、この構成では新たな制御を実行できません。

テレビをつけたタイミングも拾う

最初は、時間帯の境界を逃した場合に備えて5分ごとに状態を確認していました。その後、テレビをつけたときに実行できないか、実機の挙動を調べました。

短時間の試験では、リモコンでOFFにしてもADB接続は残っていました。ONへ戻すと、イベントログにscreen_toggled: 1などの記録が出ます。

そこで、電源の変化を待ち受ける常駐処理、watcherを追加しました。ONを検出したら2秒待ってreconcileを実行し、切断されたら待ち時間を段階的に延ばしながら再接続する構成です。

最終的には、次のきっかけで同じ処理を呼び出す設計にしました。

短時間のwatcher実機試験までは成功しました。しかし、その後の長期試験で問題が出ました。

7日間動かしてみると、接続が戻らなかった

最初の7日間試験では、時間帯の境界で動く56件のうち、成功は25件、失敗は31件でした。全実行では成功112件、失敗102件で、期待状態と最終状態の不一致も2件ありました。

そこで対策を加え、2026年10月3日17:08から10月10日17:08まで、もう一度観測しました。固定した接続先が使えなくなる場合に備え、ネットワーク上の接続先を探すmDNSへの追従や、再接続の待ち方も調整しています。

結果は、残念ながら改善しませんでした。

境界実行、予定実行、対象ログ全体は集計範囲が異なります。別々の失敗件数として足し合わせるものではありません。

ここで重要なのは、タスクスケジューラが動かなかったのではなく、起動した処理がテレビを制御できなかったという点です。

この再観測期間ではADBが一度もdevice状態に到達せず、_adb._tcpのmDNS広告も確認できませんでした。そのため、YouTubeが有効なのか無効なのか、読み取ることもできませんでした。

原因は断定できていない

USBデバッグがOFFになっていたのか、テレビ側のadbdが停止していたのか、それ以外の接続要因だったのか。ここは直接確認できていないため、原因を断定できません。

また、ログがunknownだからといって、YouTubeが有効だった、あるいは無効だったとも言えません。状態が分からなかったこと自体を、制御の失敗として扱っています。

1時間ごとに再実行しても、接続が戻らなければ状態確認はできません。イベント監視も同様で、前提となるADB接続を維持できなければ機能しませんでした。

今回は開発を中止することにした

短時間の操作には成功したものの、長期運用で接続を安定して復旧できず、テレビの状態も確認できない状況が続きました。

この状態で家庭内の時間制限を任せるのは適切ではないと判断し、2026年10月22日に開発を中止しました。

最初に考えた「現在時刻から期待状態を決め直す」設計は、遅れて実行される処理を整理するのに役立ちました。変更後に読み直す仕組みも、実際に制御できたかを区別するために必要でした。

ただ、それらが働くには、まず接続して実際の状態を読めなければなりません。今回の長期試験では、その前提を満たせませんでした。

手動で一度動くこと、短時間の試験に通ること、毎日任せられること。この三つは分けて確認する必要があると分かった実験でした。

本記事は、特定のBRAVIAとAndroid 12で行った個人環境の検証記録です。安定稼働する時間制限ツールとしての利用を案内するものではありません。ADBを試す場合は、所有者の同意を得た自分が管理する端末で、対象と復旧方法を確認してください。ADBポートはインターネットへ公開しないでください。