移行アシスタントが容量不足で終わらない｜原因は見かけ2.4TBの仮想ディスク

Mac Studio への移行アシスタントが「ディスクの空き領域が不足しているため、移行を完了できません」で止まり続け、完走まで約38時間かかりました。移行先の実空きは約965GB、転送量は約320GBで容量は足りていたのに、原因は旧 MacBook Pro のホームにあった見かけ合計約2.4TBの仮想ディスク4つでした。これを消したら、ホームの転送は約28分で終わっています。

2026年9月22日に Mac Studio（M5 Max／64GB／1TB）が届き、開封と設置は特に困りませんでした。ディスプレイ1台をつなぎ、MacBook Pro 16 で使っていた HHKB とトラックパッドを Mac Studio に直結し、旧 Mac とは Thunderbolt 4→5 のケーブルで直結しています。事前に見積もった移行時間は13〜22分でした。

止まったのは移行アシスタントです。エラーは何度やり直しても同じで、しかもどのファイルで失敗したかを表示しません。その間に Mac Studio を初期化しかけ、Time Machine 経由も試し、OneDrive と iCloud Drive も切り離しましたが、どれも直りませんでした。

この記事では、原因ファイルの見つけ方（find とフルディスクアクセス）と消し方、Mac Studio 側でのやり直し手順、誤読しやすい「Mac の空き領域」表示の読み方をまとめます。Docker Desktop・OrbStack・Apple container・仮想マシンを使っている人は、買い替え前の点検にもそのまま使えます。

移行アシスタントの「空き領域不足」は見かけ2.4TBのスパースファイルが原因だった
同じ原因か見分ける方法｜失敗位置を「分母−分子」で比べる
1. 残りファイル数を2回分比べた結果
2. 転送するカテゴリを外して犯人を絞った4段階
原因ファイルの見つけ方と消し方｜findとフルディスクアクセス
Mac Studio側で移行アシスタントをやり直す手順（約28分で完走）
誤読しやすい表示と、効かなかった対処
まとめ｜移行アシスタントの前に点検する5項目
1. 解説動画（9月28日追記）
2. こちらもおすすめ

移行アシスタントの「空き領域不足」は見かけ2.4TBのスパースファイルが原因だった

エラーの原因は容量ではなく、旧 Mac のホームにあった見かけのサイズが巨大なファイル4つでした。 Apple container の試験用マシン2台とスナップショット（各512GB）、OrbStack の仮想ディスク（見かけ926GB）で、合わせて約2.4TBになります。1TB の SSD に、見かけ512GBのファイル3つと926GBのファイル1つを書こうとしていたことになります。

移行アシスタントがこうしたファイルを見かけのサイズで扱っているのかどうか、Apple は仕様を公開していません。

手がかりは2つあります。

OrbStack の公式FAQ: 「Time Machine はスパースファイルに対応しているが、移行アシスタントは対応していない」と明記し、移行前に仮想ディスクを消すか tar で退避するよう案内している（OrbStack の FAQ）
GitHub issue: 見かけ8.8TBの data.img を消したら移行できたという報告がある（orbstack/orbstack #1511）

今回の症状とこの2つを合わせると、移行アシスタントは見かけのサイズで領域を確保しようとして失敗している、と推測しています。

実空き965GB、転送約320GBでも止まった

移行元と移行先の条件は次のとおりです。

項目	内容
移行元	MacBook Pro 16（M1 Max／1TB SSD、使用約500GB）
移行先	Mac Studio（M5 Max／64GB／1TB SSD、初期状態で実空き約965GB）
接続	Thunderbolt 4→5 ケーブルで直結
転送量	約320GB（選択画面の表示で323.01GB）
macOS	両機とも 27.0（26A428）

Mac Studio は届いた後に macOS 27 へ自動でアップデートがかかり、旧 Mac と版がそろいました。版の違いで止まる心配は結果的に要りませんでした。macOS 27 自体の変更点は macOS 27 の日本語 AI と新 Siri の検証記事にまとめています。

【macOS 27】AIは日本語で動く｜新Siriは英語でも順番待ち

macOS 27のAIは日本語でどこまで使えるのかを実機で確認しました。新Siriは英語にしても順番待ちですが、ショートカットの4モデルと作文ツールは日本語のまま動きます。日本語対応は10月予定です。

止まり方は毎回同じでした。

転送が8〜9割まで進んだところで、空き領域不足のダイアログが出る
ダイアログが出た後も、裏でファイル数のカウントは進み続ける
最後は「移行を完了中」のまま30分以上動かなくなる

原因ファイル4つと見かけ・実体のサイズ

旧 Mac で見つかったのは次のファイルです。場所はすべてホームの ~/Library の中でした。

アプリ	場所（~/Library 以下）	見かけ	実体
Apple container	`Application Support/com.apple.container/snapshots/…/snapshot`	512G	未計測
Apple container	`…/machines/cm26-test/rootfs.ext4`	512G	未計測
Apple container	`…/machines/cm26-test-2/rootfs.ext4`	512G	未計測
OrbStack	`Group Containers/HUAQ24HBR6.dev.orbstack/data/data.img.raw`	926G	781MB
（参考）Docker Desktop	`Containers/com.docker.docker/Data/vms/0/data/Docker.raw`	60G	未計測

Apple container の2台は、6月に試験用に作ったマシンです。1台につき見かけ512GBの rootfs.ext4 を持っていました。Docker Desktop の Docker.raw は60GBで容量的には通るので、消さずに残しています。

スパースファイルとは（見かけと実体が別物）

スパースファイルは、中身が空の領域を実際にはディスクに書かないファイルです。OrbStack の仮想ディスクなら、ファイルの大きさは926GBと名乗っていても、ディスク上で使っているのは781MBだけでした。

ls -lh は見かけのサイズを出す
du -sh や Finder の「サイズ（ディスク上）」は実際の使用量を出す
Docker・OrbStack・Apple container の仮想ディスクがこの形式で、Parallels・UTM の仮想マシンも同じ形式になりうる（推測）

Apple container の ext4 イメージが巨大なスパースファイルになり、Time Machine でバックアップすると容量を食う報告も出ています（apple/container #612）。空き領域不足で止まったら、ケーブルや容量を疑う前に、この種のファイルが旧 Mac にないかを探します。

同じ原因か見分ける方法｜失敗位置を「分母−分子」で比べる

何度やっても末尾から数えて同じ位置で止まるなら、特定のファイルで失敗しています。回線やタイミングのせいなら、止まる位置は回ごとにばらつくはずです。

移行アシスタントの進捗は「転送済みのファイル数／総ファイル数」で表示されます。やり直すたびに総数（分母）が変わるので、転送済みの数（分子）だけを見比べても判断できません。分母から分子を引いた「残りのファイル数」を比べます。

残りファイル数を2回分比べた結果

回	総ファイル数（分母）	転送済み（分子）	分母−分子
1回目	883,524	747,897	135,627
2回目	864,856	729,231	135,625

分母は約1万9千個変わっているのに、残りの数は2個しか違いませんでした。同じファイルの手前で止まっていると判断し、ここから転送するカテゴリを外して犯人を絞り込みました。

転送するカテゴリを外して犯人を絞った4段階

アプリケーション・Admin・その他・設定だけを転送した。完走した（CoreSpeech などキャッシュ系の転送失敗が3件出たが害は無い）
ホーム（マクマリ）だけを転送した。同じ位置で失敗し、犯人はホームの中と分かった
ホームの OrbStack・Parallels・ゴミ箱・その他のデータのチェックを外した。それでも失敗し、残るのはライブラリだけになった（ライブラリは画面でチェックを外せない）
旧 Mac で find を実行し、見かけのサイズが巨大なファイルを列挙して特定した

3の段階で OrbStack のチェックを外しても失敗したのは、原因ファイル4つがすべてライブラリの中（~/Library/Application Support と ~/Library/Group Containers）にあったからと見ています。OrbStack の FAQ によると、ホーム直下の ~/OrbStack フォルダはデータを見せるだけの窓口で、仮想ディスクの実体は ~/Library/Group Containers にあります。画面の OrbStack の項目を外しても、ライブラリ側の926GBのファイルと Apple container の512GBのファイル3つは転送対象に残っていたことになります。

原因ファイルの見つけ方と消し方｜findとフルディスクアクセス

旧 Mac で find ~ -type f -size +20G を実行すれば、見かけ20GB超のファイルが出てきます。ただしターミナルにフルディスクアクセスを付けないと、find は Group Containers を黙って飛ばし、OrbStack の仮想ディスクを見落とします。

権限の無い場所に当たると、find は「Operation not permitted」を出して先へ進む仕様です。そのうえ 2>/dev/null を付けているとエラーも画面に出ないので、飛ばされたことに気づけません。フルディスクアクセスを付ける前に実行したときは、OrbStack の926GBが出てきませんでした。

ターミナルにフルディスクアクセスを付ける

システム設定 > プライバシーとセキュリティ > フルディスクアクセスを開き、「＋」でターミナルを追加します。追加した後、ターミナルを開き直してから次へ進みました。

フルディスクアクセス

見かけ20GB超のファイルを列挙する

今回はまずライブラリ、次にホーム全体を見ました。

find ~/Library -type f -size +20G -exec ls -lh {} \; 2>/dev/null
find ~ -type f -size +20G -exec ls -lh {} \; 2>/dev/null

-size +20G は見かけのサイズで判定します。そのため実体が781MBしかない OrbStack の仮想ディスクも、926Gとして引っかかりました。

lsとduの差でスパースか確かめる

見つかったファイルは、ls の見かけと du の実体を並べて比べました。

ls -lh ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data/
du -sh ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data/

今回は ls が data.img.raw を926Gと出し、du の実使用は781MBでした。この差が大きいファイルが、移行アシスタントを止める候補です。

Apple containerとOrbStackの仮想ディスクを消す

Apple container は、止めてからフォルダごと消しました。試験用マシン2台とスナップショットがまとめて無くなります。

container system stop
rm -rf ~/Library/Application\ Support/com.apple.container

OrbStack は終了させてから、仮想ディスクとスワップのファイルだけを消しました。設定と CLI は残り、次に起動したときに仮想ディスクは作り直されます。ただし中のイメージは消えるので、移行後に取り直しが要ります。

pkill -f OrbStack; sleep 3
rm -f ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data/data.img.raw \
      ~/Library/Group\ Containers/HUAQ24HBR6.dev.orbstack/data/swap.img

[!note] 消さずに残したいときは tar で退避する
OrbStack の FAQ は「消すか tar で退避する」と案内しています。exFAT のディスクへ普通にコピーするとスパースが保てず、見かけのサイズぶん実際に書き込まれます。作り直せるものは消すのが確実です。

消した後にもう一度 find ~/Library -type f -size +20G -exec ls -lh {} \; 2>/dev/null を実行し、残るのは Docker.raw（60G）だけになる想定で Mac Studio 側に移りました。

Mac Studio側で移行アシスタントをやり直す手順（約28分で完走）

原因ファイルを消した後、ホームだけの転送は2026年9月23日23時54分に始まり、24日0時22分に終わりました。約28分です。やり直すときは仮の管理者で入り、ホーム以外を先に移してから、ホームだけを移します。

ホームを分けておけば、失敗したときに原因がホームの中にあると分かり、失敗したホームだけを消してやり直せます。Mac Studio 全体を消去し直す必要がありません。

仮の管理者で入り、ホーム以外を先に移す

初回セットアップの移行はスキップし、仮の管理者（今回は temp）を作ってログインする。名前は移す予定のアカウント（今回はマクマリと Admin）と重ねない
アプリケーション > ユーティリティ > 移行アシスタントを開き、ホーム以外を転送する
途中で失敗したホームが残っていれば、システム設定 > ユーザとグループで「ホームフォルダも削除」を選んで消す
旧 Mac で原因ファイルを消してから、移行アシスタントでホームだけを転送する
移したアカウントでログインして動作を確かめ、仮の管理者を削除する

移行アシスタントの基本の流れは Apple の公式サポートにある移行アシスタントの手順と同じで、変えたのは転送するカテゴリを2回に分けた点だけです。

ゴミ箱とライブラリは画面で外せない

移行アシスタントの項目選択で、ゴミ箱（.Trash）は展開してもチェックを外せませんでした。そこで旧 Mac で先にゴミ箱を空にし、転送量が33.11GB減りました。ライブラリも同じで、チェックを外せません。ライブラリの中にあるスパースファイルは、旧 Mac 側で消すしか手がありません。

移行後に残った後始末

仮の管理者 temp を削除する
temp で設定アシスタントを通したので、コンピュータ名が「tempのMac Studio」のまま残る。システム設定で直す
OrbStack を起動し、仮想ディスクの作り直しとイメージの取り直しをする

移行後の Mac Studio の空きは584.2GBでした（diskutil info で実測）。

誤読しやすい表示と、効かなかった対処

選択画面の「Mac の空き領域」は、実空きではなく転送後の残りの予測値です。残り時間の表示も当てになりませんでした。Time Machine 経由は別の形で止まり、OneDrive と iCloud Drive を切り離しても今回のエラーは直りませんでした。

「Macの空き領域」は転送後の残り予測

実空き＝画面の「Mac の空き領域」＋転送に選んだ量です。 画面の数字を2組足すと、どちらも実空きの約965GBになります。

画面の「Mac の空き領域」	転送に選んだ量	合計
551.91GB	413.64GB	965.55GB
642.53GB	323.01GB	965.54GB

最初はこの数字を実空きと読み、「前回失敗した残骸で400GB埋まっている」と思い込んで Mac Studio を初期化しかけました。実際は何も埋まっておらず、初期化は要りませんでした。

残り時間と「移行を完了中」の表示

途中で出た「残り約23時間（304.4MB/秒）」や「12.98GB/秒」は、序盤の速度から外挿した値で、実際の転送とは合いませんでした。「移行を完了中」で数字が止まったまま30分過ぎたら、待たずに戻って切り分けに進みます。

「移行の概要」画面に出る「マクマリの書類のいくつかが転送できませんでした」の警告は、今回は group.com.apple.CoreSpeech のキャッシュでした。Siri の話者認識用のキャッシュで、必要なときに作り直されます。容量不足で止まった回にたまたま出ていただけで、失敗の原因ではありません。

Time Machine経由は20.9MB/秒のまま止まった

外付けディスクの Time Machine バックアップから移そうとすると、ファイル数が総数を超えた「2,168,807個（総数2,156,404）」のところで「残り約20分（20.9MB/秒）」と出たまま、1時間以上動きませんでした。キャンセルした後は Mac Studio のログイン画面でパスワードを入れても先へ進まなくなり、Mac Studio を消去してから Thunderbolt 直結でやり直しています。途中まで作られたアカウントが原因と見ていますが、確かめてはいません。

読み込む元を Time Machine に変えても、Mac Studio 側で書き込むのは同じ移行アシスタントです。ただしこの回は空き領域不足のダイアログが出る前に止まったので、経路を変えればスパースファイルの問題を避けられたかどうかは確かめられていません。

OneDriveとiCloud Driveを切り離しても直らなかった

iCloud Drive をオフにし、OneDrive は File Provider（macOS がクラウドのファイルを Finder に見せる仕組み）の接続を外しました。それでも、その後の Thunderbolt 直結の移行で同じエラーが出ています。

今回は OneDrive を外したままスパースファイルを消して完走したので、OneDrive が原因の一部だったかは判定できません
以前の別の移行では、同じエラーが OneDrive のせいで出たことがあります
OneDrive を入れたまま、スパースファイルだけを消して移行すれば切り分けられますが、今回は試していません

OneDrive が関わっていた可能性は消せないので、スパースファイルを消しても止まるなら、次にクラウドドライブの切り離しを試します。なお ~/Library/CloudStorage/ の中は Finder でも rm でも消えないので、OneDrive なら設定の「この Mac のリンクを解除」で外します。