BRAVIAでアプリを更新しようとしたら「空き容量がありません」と表示されて、ほとんどのアプリが更新できない——そんな状態に困っていませんか。
Huluが全然アップデートできないの。空き容量が足りないって出るんだけど、設定を見ても結構空いてるのよね。
僕も最初は「またAndroidの肥大化か」と軽く考えていました。ところが元ソニーエンジニアとして仕組みから追いかけてみたら、原因は容量とはまったく別の場所にありました。
表示されているエラーと、実際に起きていることが違うっぽいんだよね。ログを取って確かめてみよう。
- 何が壊れうるか：この記事で使う
sm forgetというコマンドは取り消しができません。削除するドライブのUUID（背番号のようなもの）を取り違えると、テレビの録画用ハードディスクの登録まで消してしまい、録画した番組が見られなくなるおそれがあります - 元に戻す方法：一度
sm forgetで消した登録を復元する方法はありません。実行前にUUIDを2回照合する、録画用ハードディスクはいったん外してから作業する、といった予防で事故を防ぐしかありません - 自信がない場合：無理にコマンドを実行せず、メーカーのサポート窓口に「空きがあるのに『空き容量がありません』と出る」「設定のストレージに『未接続』のドライブが残っている」という症状を伝えて相談する、という手段もあります。設定画面だけで削除できるかどうかは機種によって違うため、ここでは断定しません
| この記事に出てくる言葉 | ひとことで言うと |
|---|---|
| プライマリストレージ | アプリを置く「メインの物置」として、システムが指定している保存先の住所 |
| 幽霊ドライブ | 引っ越して無くなった物置の住所が、台帳（システムの登録）にだけ残っている状態 |
| UUID | ドライブやボリューム1台ずつに付く、世界に1つだけの背番号 |
| 内部ストレージ化（Adoptable Storage） | USBメモリなどを、テレビ本体の一部として”住み込み”にさせる設定 |
| adb | パソコンからテレビに命令を送るための、公式の連絡線 |
| logcat | テレビの中で起きたことを記録し続ける、業務日誌（古いページから捨てられていく） |
| ボリューム／マウント | ボリューム＝ストレージの単位、マウント＝それを実際に使える状態にすること |
| sm forget | 台帳から、指定したドライブの登録を消すコマンド（取り消し不可） |
結論：原因は容量不足ではなく「幽霊USBドライブ」だった
先に結論を書きます。今回の「空き容量がありません」は誤表示でした。真因は、過去に内部ストレージ化して使っていたUSBドライブを、システムが今もプライマリストレージとして指定し続けていたことです。指している先のドライブがもう存在しないため、共有ストレージがマウントされず、Playストア経由のインストールだけが全滅していました。
| 論点 | 結論 | 根拠 |
|---|---|---|
| 本当に容量不足か | いいえ | システムは両ボリュームとも「NORMAL」判定、Playストア自身も「追加必要0バイト」と判定していた |
| 直す方法 | sm forget <UUID>で幽霊ボリュームの登録を削除 | 直後に全24パッケージの滞留更新が自動で走った |
| 容量は増えたか | 1バイトも増えていない | 空き容量1.9GBのまま。元々容量の問題ではなかった |
「容量が足りないなら消せばいい」という直感が、そのままハズレの原因になります。次の章から、なぜそう言い切れるのかを実測ログで順番に見ていきます。
症状：空きはあるのに、ほぼ全アプリの更新が失敗する
内部ストレージ化って、USBメモリを普通に挿すのとは違うの？
違うよ。普通に挿すと「外付けの箱」のままだけど、内部ストレージ化すると「テレビの一部」として住み込みで登録されるんだ。だから外し方も専用の手順がいる。
我が家で起きていたのは次の状態でした。
- Google Playストアからアプリを更新しようとすると「空き容量がありません」と表示されて失敗する
- Huluだけでなく、Prime Video・Netflix・YouTubeなど、ほぼすべてのアプリが更新できない
- 内蔵ストレージの空きは1.9GBある（アプリ更新が軒並み落ちる水準ではない）
- 外部USBメモリ（57GB）を「内部ストレージ化」してあるのに、まったく使われていない
空きが1.9GBもあるのに「空き容量がありません」って、どういうこと？
これが今回のいちばんの罠です。画面に表示されるエラーメッセージは、失敗した原因そのものではなく、失敗したあとにシステムが選んだ説明でしかありません。実際のPlayストアの内部判定は、まったく違うことを言っていました。
アプリは普通に動いてたから、そんなに長く更新が止まってたなんて気づかなかったわ。
厄介なのは、この状態が「アプリ単体の問題」に見えてしまうことです。Huluのアプリだけがおかしいのかと思って再インストールしたり、Wi-Fiの調子を疑って再起動したりと、対症療法を積み重ねがちです。しかし実際には、Huluだけでなくほぼ全アプリの更新が止まっていました。ここで初めて「個々のアプリの問題ではなく、端末側の共通した原因があるはずだ」という方向に疑いが向きました。
仮説を実測で潰す：容量不足でもシステム領域の肥大でもなかった
思い込みで手を動かす前に、まず容量を実測しました。以下は、パーティションごとの空き容量を一覧表示させた結果です。
/dev/block/mmcblk0p48 6.2G 4.1G 1.9G 69% /data
/dev/block/dm-4 57G 52M 56G 1% /mnt/expand/c7bc0365-...空きは1.9GB。アプリ更新が軒並み落ちる水準ではありません。そして内部ストレージ化したはずの57GBが、52MBしか使われていない点も引っかかりました。次に内訳を見るためdumpsys diskstatsを取ります。
App Size: 906 MB
App Data Size: 309 MB
App Cache Size: 118 MBここで最初の発見がありました。App Size 906MBのうち695MBは、47個のパッケージが全く同じ15,511,552バイトを報告していたのです。共有ライブラリを各アプリに重複計上している計測アーティファクトで、実体は1つ分しかありません。
906MBのうち695MBが重複計上だった。補正すると実使用量は約650MBなんだけど、/dataの使用量4.3GBとの差、約3.6GBがまだ説明つかないんだよな。
もしこの重複計上に気づかず「アプリが906MBも食っている」という数字だけを見ていたら、使っていないアプリを片っ端から消すような遠回りをしていたと思います。数字を疑わずに信じてしまうと、対策の方向自体を間違えます。
非root環境ではdalvik-cache等のシステム領域の内訳までは測れません。「ならシステム領域が肥大したせいだろう」と結論づけたくなりますが、これも早計でした。システムがそもそも容量を低いと認識しているかを、別のコマンドで確認します。
dumpsys devicestoragemonitor
Known volumes:
c7bc0365-... : level=NORMAL lastUsableBytes=60,075,917,312
Default : level=NORMAL lastUsableBytes= 2,067,308,544両ボリュームともNORMAL。低容量フラグは立っていません。「容量が原因」という仮説そのものに、ここで疑いが生まれました。
じゃあ「容量不足」でも「システムが重い」でもないなら、いったい何が原因なの？
正直、この時点では僕にもまだ分かっていませんでした。ここで大事なのは、分からないまま次の対策（アプリの大量削除やテレビの初期化）に進まないことです。仮説がすべて実測で否定されたなら、次にやるべきは「もっと強い対策」ではなく「もっと直接的な証拠を取ること」です。推測を重ねるフェーズから、実際に失敗の瞬間を記録するフェーズへ切り替えました。
再現させて、決定的ログを捕まえる
adbって何？パソコンとテレビをつなぐケーブルみたいなもの？
近いね。物理的なケーブルというより、パソコンからテレビに「これをやって」と指示を送るための、Googleが用意した公式の通信の仕組みだよ。
この機種の標準ログバッファは1MiBしかなく、15分程度で古いログが流れて消えてしまいます。あとから探そうとしても証拠は残っていないので、先にバッファを広げてから再現させます。
adb logcat -G 16M # バッファを 1MiB → 16MiB に拡大
adb logcat -c -b all # クリア
adb logcat -b all -v threadtime > capture.logこの状態でアプリの更新を再実行してもらったところ、次のログが出ました。
23:16:25.358 ICalc: Partition available space: 2032574464,
install size: 58935104,
min free: 334734540,
additional needed: 0
23:16:25.358 AV::DSC: sufficient disk space space available for jp.happyon.android
23:16:25.360 W StorageManagerService: No primary storage defined yet; hacking together a stub
23:16:25.373 E Finsky: InstallerException: Status: 1047「空き容量は十分、追加で必要な容量は0バイト」って、Playストア自身が言ってるじゃない！
そうなんです。Playストアは容量を十分と判定した2ミリ秒後に、StorageManagerServiceが「プライマリストレージが定義されていない」と吐いてインストールを失敗させていました。ダウンロードは1バイトも始まっておらず、失敗までわずか1.15秒。画面の「空き容量がありません」は、やはり誤表示でした。
犯人特定：プライマリストレージが、存在しないUSBドライブを指していた
「プライマリストレージが定義されていない」を手がかりに、どこが壊れているか特定します。
adb shell sm get-primary-storage-uuid # 今「メインの物置」として指定されているUUIDを表示
→ 7652a6e2-9c3c-4016-bcc9-6127e38ec88f
adb shell sm list-volumes all # すべてのボリュームと、それぞれが使える状態（mounted）かを表示
→ private mounted null
private:8,18 mounted c7bc0365-3bcb-41ec-9b32-fb7ec714a457
emulated:8,18 unmounted null
emulated unmounted null ← 本来マウントされているべきUUIDって、ドライブ1個1個に付いてる番号ってこと？
そう、背番号みたいなものだね。名前は変わっても番号は変わらないから、システムはこの番号でドライブを見分けているんだ。
プライマリストレージは7652a6e2-...を指していますが、マウントされているボリュームの中にその UUID がありません。dumpsys mountでこのUUIDの正体を確認します。
adb shell dumpsys mount
Records:
VolumeRecord:
type=PRIVATE fsUuid=7652a6e2-9c3c-4016-bcc9-6127e38ec88f
nickname=BUFFALO製USBドライブ ← 接続されていない犯人が名乗り出ました。過去に内部ストレージ化していたBUFFALO製USBドライブの登録だけが、システム内に残っていたのです。念のため共有ストレージの実体も確認しました。
adb shell ls -d /sdcard # 共有ストレージのフォルダが実在するかを確認
→ ls: /sdcard: No such file or directory/sdcardはディレクトリごと存在していませんでした。流れを整理すると、①過去にUSBドライブを内部ストレージ化してプライマリを移した→②そのドライブを取り外した→③プライマリストレージの指定だけが、存在しないボリュームを指したまま残った→④共有ストレージがマウントされなくなった→⑤Playストア経由のインストールが全件失敗するようになった、という順番です。adbで直接APKを入れる分にはこの経路を通らないため成功します。だから「Playストアだけが壊れている」という、原因の見えにくい状態になっていました。
「内部ストレージ化」というのは、Androidの正式名称でいうAdoptable Storageという機能です。外部のUSBメモリやSDカードを、単なる外付けディスクとしてではなく、端末の内蔵ストレージと一体化した領域として扱えるようにする仕組みで、アプリのデータをまるごと外部メモリ側に置けるようになります。便利な一方で、一度この設定にしたメディアは「端末の一部」として登録され続けるため、外し方を間違えると今回のような取り残しが起こります。物理的に抜くだけでは、システム側の登録は自動的には消えてくれません。
便利な機能だからこそ、やめ方まで一緒に覚えておかないといけないのね。
そのとおりです。設定するときは「ストレージを増やす」という目的しか意識しませんが、やめるときの手順まで一緒に覚えている人は多くありません。今回のように何年も先になって初めて症状が出るため、設定した本人でさえ原因に気づきにくいのが厄介なところです。
実はこの幽霊、設定画面にも最初から表示されてたんだ。ただ「未接続なら無害だろう」って読み飛ばしてしまう。
設定 → ストレージ の画面を見返すと、確かにそのまま出ていました。
- デバイスのストレージ → 内部共有ストレージ（システム領域除く）6.7GB
- デバイスのストレージ → USBドライブ 61GB（現在挿している外部メモリ）
- デバイスのストレージ → BUFFALO製USBドライブ「未接続」（これが幽霊）
- 録画用ハードディスク → BUFFALO製USBドライブ 3.0TB（録画用。別物）
ここで紛らわしいのが、この2つの項目がまったく別の使い方をしているという点です。録画用ハードディスクは、テレビ番組を録画するための専用領域として登録するUSB機器で、今回の幽霊とは別物です。テレビに外付けのUSB機器をつなぐときは「録画用として登録する」のが基本的な使い方で、アプリ用に内部ストレージ化するのは、それとは別の設定です。今回の幽霊は、後者のアプリ用の設定で起きたものでした。録画用に使うドライブを選ぶときは、テレビの録画に対応していると明記されたモデルを選んでおくと、こうした混同が起きにくくなります。
修正：sm forget で2年9か月ぶりに更新が通った
特定できたUUIDを指定して、幽霊レコードを削除します。
adb shell sm forget 7652a6e2-9c3c-4016-bcc9-6127e38ec88f| 項目 | 実行前 | 実行後 |
|---|---|---|
| primary-storage-uuid | 7652a6e2-…（存在しないドライブ） | null（内蔵） |
| emulated ボリューム | unmounted | mounted |
| /sdcard | ディレクトリが存在しない | 存在し、正常にマウント |
| 幽霊VolumeRecord | 残存 | 消滅 |
Huluの更新を再実行してみます。
versionName : 3.5.0 → 3.32.0
versionCode : 310000255 → 310000321
lastUpdateTime: 2023-12-29 → 2026-09-22
空き容量、増えてないのに直っちゃった。あれだけ悩んでたのは何だったの。
空き容量は1.9GBのまま、1バイトも増えていません。元々容量の問題ではなかったので、それで正しいのです。
自分の端末は大丈夫か？読み取り専用で診断する
いきなりsm forgetを叩く前に、まずは読み取り専用のコマンドだけで状態を確認してください。adbの導入手順自体は別記事で詳しく解説しているので、ここでは診断の要点だけに絞ります。
adb shell sm get-primary-storage-uuid # 今のプライマリストレージのUUIDを表示
adb shell sm list-volumes all # すべてのボリュームと、使える状態（mounted）かを表示
adb shell ls -d /sdcard # 共有ストレージのフォルダが実在するか確認get-primary-storage-uuidがnull以外のUUIDを返し、かつ同じUUIDがlist-volumes allの一覧に見当たらない → 今回と同じ状態の可能性が高いemulatedボリュームがunmountedになっている → 共有ストレージがマウントされていない/sdcardが存在しない → 上記と合わせて確定的な兆候
すべて読み取り専用のコマンドなので、実行して何かが壊れることはありません。過去にUSBメモリやSDカードを内部ストレージ化したことがある人ほど、この症状に心当たりが出やすいはずです。特に、メディアを買い替えたり、故障で交換したりした経験がある場合は要注意です。「新しいメディアに乗り換えたから、古いドライブのことはもう忘れているだろう」と思っていても、システム側の登録は律儀に残り続けます。
診断だけならリスクゼロだから、思い当たる人はまず get-primary-storage-uuid から試してみてほしい。
後日談：更新の翌朝、テレビの操作が重くなった話
あれ、なんかホーム画面の反応が鈍いんだけど。昨日の修正、大丈夫だった？
24パッケージが一気に更新された翌朝、たしかに操作が重くなっていました。調べたところ、原因はアプリ更新そのものではなく、更新で消えたはずの古いジョブ登録が「孤児ジョブ」として残っていたことでした。Google アシスタント関連のパッケージが更新され、旧版が登録していたバックグラウンドジョブのサービス本体が新版では存在しなくなっていたのです。JobSchedulerはこの状態を実行できないまま再評価し続け、system_serverのmainスレッドが空回りしていました。
dumpsys jobscheduler | grep -c "comp=false"このコマンドで0以外の数値が出れば、サービス本体が無いジョブが残っている可能性があります。今回は孤児ジョブ14件をジョブID指定で削除しました（アプリ全体の削除ではありません）。
| 項目 | 削除前 | 削除後 |
|---|---|---|
| ジョブ再評価の頻度 | 566回/秒 | 30秒で2回 |
| mainスレッドCPU使用率 | 96〜99% | ほぼ0% |
ホーム画面の左右移動そのものはmainスレッドが100%に張り付いている間も即座に反応していました。キー入力の配送は別スレッドが担当しているためです。遅延はアプリの起動など、システム側の内部処理を待つ操作で出ていた可能性があります（推定）。「テレビ全体が固まる」のではなく「特定の操作だけ数秒待たされる」タイプの不調は、原因を絞り込みにくいので要注意です。
修正の実施前後で、キー処理の遅延ログ（InputDispatcher ... spent Xms）を比較したところ、修正前は5件（最大4.3秒、system_server側の処理3.8秒を含む）検出されていたのに対し、修正後は2件（ホームのタブ切替2.1秒・2.6秒のみ）に減りました。YouTubeアプリを開いたときの遅延は確認できなくなりました。件数が少ないため確定的な結論とまでは言えませんが、孤児ジョブの整理と体感速度の改善には相関がありそうです。
ちなみに、今回のようにテレビ本体のアプリの動作が不安定になったとき、動画アプリの部分だけを外付けのストリーミング端末に任せる、という選択肢もあります。本体の性能や更新の状態に左右されず、動画アプリを使えるようになります。
Fire TVもAndroidベースの機器なので、USBメモリを内部ストレージ化した場合は、抜く前に設定画面から解除する、という今回と同じ注意が当てはまります。
まとめ：内部ストレージ化したUSBは、抜く前に必ず解除する
今回の一件で得た教訓は5つです。
- エラーメッセージを鵜呑みにしない。「空き容量がありません」は失敗の原因ではなく、失敗後に選ばれた説明でしかなかった
- 仮説を立てたら実測で潰す。「容量不足」「システム領域の肥大」という仮説は2回とも実測で否定された
- ログのバッファは、再現させる前に広げてクリアしておく。標準の1MiBでは15分しか残らない
- 内部ストレージ化したUSBメモリやSDカードを抜くときは、必ず設定画面から取り外し操作をしてから抜く。解除せずに抜くと幽霊レコードが残り、Playストアが全滅する
- 「未接続」と書かれた項目を読み飛ばさない。無害に見える表示が、実は全機能を止めていることがある
これはAndroid TVに限った話ではありません。Fire TVやAndroidスマホでも、内部ストレージ化（Adoptable Storage）の仕組みは共通です。USBメモリやSDカードを「内部ストレージとして使う」設定にしている人は、今すぐ設定画面を確認してみてください。
特にテレビやレコーダーは、録画用のハードディスクと、アプリ用に内部ストレージ化したメディアが同じ「ストレージ」画面に並ぶ機種が少なくありません。今回のように似た名前の項目が複数あると、どちらが何のために使われているのか把握しづらくなります。メディアを追加・交換するタイミングで、一度ストレージ画面全体を見直し、「未接続」や見覚えのない項目が残っていないかを確認しておくと、今回のようなトラブルを未然に防げます。録画用のドライブはいったん外してから作業する方が、UUIDの取り違えを避けやすく安全です。
推測で「アプリを消す」「容量を初期化する」をやっていたら、たぶん直らなかったと思う。表示じゃなくて、実際に起きていることを見るのが大事だね。
よくある質問
アプリを削除したり初期化したりすれば直りませんか？
今回のケースでは直りません。見積もると、使っていないアプリの削除も外部メモリへの移動も、空くのは140MB程度です。そもそも容量が原因ではないので、いくら空けても更新失敗は続きます。テレビの初期化はアカウントや録画予約が消えるうえ、今回の原因に効くとも限らないので、僕はおすすめしません。原因が容量以外にある場合、容量を減らす対策では解決しません。
sm forgetを実行すると録画データは消えますか？
UUIDを正しく指定していれば、消えるのは「未接続」になっている幽霊レコードだけです。ただし設定画面で同名の項目が複数ある場合は取り違えのリスクがあるため、実行前に必ずUUIDが一致することを確認してください。取り違えて録画用ハードディスクの登録を消してしまうと、録画した番組が見られなくなり、元に戻す方法はありません。不安な場合は、作業前に録画用ハードディスクをいったん取り外しておくと安全です。
Android TV以外の機種でも同じ手順で確認できますか？
Fire TVやAndroidスマホでも、smコマンド自体は共通のAndroid標準機能なので、同様の手順で読み取り専用の診断ができます。ただし設定画面のメニュー名や、adbの接続方法は機種によって異なります。
コメント