外部ドライブに APFS が必要な理由

要点

1.9.0 以降、AppPorts は ~/Library/Containers/（WeChat のチャット履歴などのアプリのコンテナデータ）を移行するとき、外部ドライブの APFS コンテナに新しいボリュームを作り、元のディレクトリに直接マウントします。この方法は APFS 形式の外部ドライブでのみ使えます。exFAT / NTFS のドライブではディスクイメージを使う方法も試しましたが、ドライブを取り外すとイメージ全体が使用不能になったため、提供していません。

APFS でなくても、すぐに変更する必要はありません。 アプリ本体と通常のデータディレクトリはこれまでどおり移行できます。コンテナデータだけをローカルに残せば、アプリも通常どおり使えます。後でコンテナデータを移行したくなったら、APFS の外部ドライブを準備するに従ってください。exFAT パーティション内に空き容量があっても、そのまま新しいパーティションを作れるとは限りません。

APFS が必要な操作

行いたい操作	外部ドライブの形式の要件
アプリ本体の移行（.app を外部ドライブへ移動）	指定なし。exFAT も使用可能
通常のデータディレクトリの移行（Application Support、キャッシュ、~/.npm などのツールディレクトリ、カスタムディレクトリ）	指定なし
コンテナデータの移行（~/Library/Containers/、~/Library/Group Containers/。WeChat、QQ Music、App Store アプリなどのデータ）	APFS が必須

影響があるのは 3 番目だけです。ただし、容量が特に大きく、移行したいデータが多いのもこの種類です。

コンテナデータが特別な理由

多くの Mac アプリはサンドボックスアプリです。システムが各アプリに専用フォルダ（~/Library/Containers/ 内のフォルダ）を割り当て、アプリはその中だけで読み書きできます。これは macOS のセキュリティ設計であり、App Store で配布するアプリには必須です。

以前の AppPorts は、フォルダを外部ドライブにコピーし、元の場所に移行先を指す「ショートカット」（シンボリックリンク）を置いていました。通常のデータディレクトリでは有効ですが、サンドボックスアプリではこの方法だけで正しく動作したことはありません。

• システムが確認するのはショートカットの場所ではなく、その参照先です。外部ドライブを指すと「専用フォルダの外に出た」と判断し、アクセスを拒否します。
• 以前使えているように見えたのは、移行時に再署名も行い、アプリのサンドボックス ID を取り除いていたためです。サンドボックスアプリでなくなれば、その制約を受けなくなります。
• macOS 27 でその代償が表れました。「このアプリにこのフォルダを使う資格があるか」という確認で、ID を失ったアプリが一致せず、ダブルクリック後 1 秒ほどで終了する場合があります。WeChat で確認済みで、QQ Music は現時点では開けます。修復にはアプリの再インストールが必要です。経緯は macOS 27 へのアップグレードを参照してください。

新しい方式に必要なのは、データを外部ドライブに置きながら、専用フォルダの外へ出ないことです。

新しい方式の仕組み

ショートカットを使わず、外部ドライブの領域を元のフォルダに直接マウントします。フォルダの場所は同じまま、その「床」だけが外部ドライブに置き換わるイメージです。

• アプリから見えるパスは一文字も変わらず、システムの検証も通過します。
• アプリの署名は 1 バイトも変更しません。再署名が不要なので、その変更が原因で今後の OS アップグレードに問題が起きることもありません。
• 外部ドライブがないときはフォルダが空になり、アプリはデータがないものとして扱います。ローカルに新しいデータを書き込んで二重化することはありません。

ある領域をフォルダにマウントするには、その領域が独立したボリュームである必要があります。APFS では、同じ APFS コンテナ内に複数のボリュームを追加し、コンテナの空き容量を共有できます。各ボリュームの容量を事前に決めたり、パーティションを作り直したりする必要はありません。AppPorts はこの機能で、移行するディレクトリごとに専用ボリュームを作成します。「ボリュームの追加」は、物理ディスクに新しいパーティションを作ることとは異なります。

exFAT や NTFS のパーティション内には、この方法で APFS ボリュームを追加できません。同じドライブで APFS と併用するには、APFS 用の独立したパーティションが必要です。既存の未割り当て領域を使うか、現在のファイルシステムに対応したツールで元のパーティションを縮小します。それができない場合は、バックアップしてからパーティションを作り直します。AppPorts がディスクのパーティションを変更することはありません。

ディスクイメージを試して採用しなかった理由

exFAT を使うユーザーも多いため、exFAT 上にディスクイメージファイル（ネットワークドライブへの Time Machine バックアップでも使われる sparsebundle）を置き、その中を APFS にしてフォルダへマウントする方法を検討しました。

最初は有望に見えました。2026 年 9 月に macOS 27 で実際に試した結果は次のとおりです。

• APFS のドライブが不要で、どの形式でも保存できます。
• アプリの初回アクセス時に、リムーバブルボリュームへのアクセス許可を求めるダイアログが表示されません。APFS ボリューム方式では一度表示されます。
• 読み書き速度は APFS ボリュームとほぼ同じです。
• システム標準のスティッキーズなど、プラットフォームアプリでも使えます。APFS ボリューム方式はプラットフォームアプリでは使えません。

そこで、実際の使用に近いテストとして、書き込み中にドライブを直接取り外しました。64 GB の USB メモリを APFS でフォーマットし、その上に APFS ボリュームとディスクイメージを用意して、それぞれ別のフォルダへマウントしました。2 つのプログラムがデータベースへ書き込み続ける状態にして、十数秒後に USB メモリを取り外し、再接続して残ったデータを確認しました。WeChat や QQ Music がチャット履歴やプレイリストを保存するときと同様の書き込みです。

	取り外し前の書き込み件数	再接続後
APFS ボリューム、1 回目（通常の書き込み）	7177 件	データベースで一度破損を検出。修復コマンドで全 7172 件を回収。ファイルシステムは正常
APFS ボリューム、2 回目（アプリが永続化を強制）	1906 件	1905 件が正常。最後の 1 件だけ失われた
ディスクイメージ、1 回目（通常の書き込み）	25574 件	イメージを開けず、中のすべてのデータにアクセスできない
ディスクイメージ、2 回目（アプリが永続化を強制）	373 件	再びイメージを開けない

数件失うか、全体にアクセスできなくなるかという違いでした。

理由は複雑ではありません。ディスクイメージは外部ドライブ上の 8 MB のファイルを組み合わせたもので、イメージ自体の「目録」は最初のファイルにあり、数秒ごとに書き換えられます。取り外し時に外部ドライブが保証するのはファイル自体の整合性であり、ファイル内部の書きかけの内容の整合性ではありません。目録の書き込みが途中で途切れると、イメージ全体が目録のない断片になってしまいます。アプリがどれだけ永続化を強制しても、アプリが制御できないイメージ側の層の問題なので防げません。

Time Machine でネットワークドライブにバックアップするときに「バックアップが破損したため、新しいバックアップが必要」という状態に遭遇することがありますが、同じ問題です。バックアップは作り直せても、失われたチャット履歴は戻せません。

このため、テスト後にディスクイメージ方式の採用を見送りました。ほかの点で便利でも、データ移行ツールが「一度ドライブを取り外すだけですべて失われる可能性がある」選択肢を提供することはできません。

今できること

まず、移行したいものがコンテナデータかどうかを確認してください。違う場合は何も変える必要はありません。コンテナデータの場合は、現在のドライブに合わせて選びます。

現在の状況	推奨する方法
暗号化されていない APFS の外部ドライブ	「アプリデータ」で「マウント移行」を実行
exFAT / NTFS を変更せず使いたい	このままにする：コンテナデータをローカルに残し、ほかは通常どおり移行。問題のない使い方です
別の APFS ドライブがある、または専用のものを用意できる	AppPorts の外部ストレージをそのドライブに切り替えてから移行
現在のドライブに APFS 用の領域を作りたい	先にバックアップし、下の APFS の外部ドライブを準備するを参照
暗号化した APFS の外部ドライブ	現在は非対応。下の暗号化した外部ドライブを参照

判断できない場合は、AppPorts で一度「マウント移行」をクリックしてください。最初に読み取り専用で外部ストレージを確認し、何も変更せずに状況を案内します。

外部ドライブの形式を確認するには：Finder で外部ドライブを選択して ⌘ I を押し、「フォーマット」を確認します。「APFS」なら対応しています。「ExFAT」「NTFS」「Mac OS 拡張」（HFS+）は上の表の 2 番目に該当します。

APFS の外部ドライブを準備する

ディスクを変更する前に

以下のどの方法でも、まずドライブのデータをバックアップしてください。AppPorts が代わりに消去やパーティションの変更を行うことはありません。

重要なデータがない場合：「ディスクユーティリティ」を開いてドライブを選択し、「消去」をクリックします。フォーマットを「APFS」、方式を「GUID パーティションマップ」にします。消去するとドライブ全体のデータがなくなります。

データがあり、既存のパーティションを残したい場合：まず「GUID パーティションマップ」であることを確認し、次の状況を区別してください。Finder に表示される空き容量はファイルシステム内の余裕であり、パーティション外の未割り当て領域とは異なります。

現在の状況	APFS 用の領域を準備する方法
既存の APFS コンテナがある	AppPorts でその中のボリュームを選択するだけです。移行用の APFS ボリュームを自動追加するため、パーティションの作り直しは不要です
新しいパーティションに使える十分な未割り当て領域がある	元のパーティションを消去せず、その領域に APFS パーティションを作成できます。実行前にディスクユーティリティに表示される変更範囲を確認してください
exFAT がドライブ全体を使用し、未割り当て領域がない	macOS のディスクユーティリティと Windows 標準のディスクの管理は、どちらも exFAT を縮小できません。標準ツールを使う場合は、バックアップ後に消去してパーティションを作り直し、ファイルを戻す必要があります
NTFS パーティションがあり、未割り当て領域がない	macOS はデータを保持したまま NTFS を縮小できません。先に Windows のディスクの管理で NTFS を縮小し、未割り当て領域を確保できたら、macOS で APFS パーティションを作成できます。縮小可能なサイズはファイルの配置などに制限されます
Mac OS 拡張（ジャーナリング HFS+）パーティションまたは APFS コンテナ	macOS でデータを保持したままサイズを変更できます。空き容量とパーティション配置の条件を満たせば、縮小して APFS パーティションを作成できます。それでも事前のバックアップは必要です

GUID パーティションマップでない場合は、上記のパーティション追加手順をそのまま使わないでください。先にバックアップし、GUID 方式でパーティションを作り直します。準備できたら、AppPorts の外部ストレージのパスを APFS ボリュームに設定してください。

根拠：ローカルの man diskutil では、resizeVolume の対象は journaled HFS+ とされています。APFS は apfs resizeContainer を使います。Microsoft の基本ボリュームの縮小に関する説明も、Windows 標準ツールの対象を NTFS またはファイルシステムのないボリュームとしており、exFAT は含みません。サードパーティ製ツールによる exFAT のデータを保持した縮小は個別に確認が必要で、OS の標準機能として扱うことはできません。

Windows と共用する場合：Windows は標準では APFS を読み書きできません。exFAT と APFS の 2 つのパーティションを用意し、exFAT を Windows との共用に、APFS を AppPorts に使えます。既存の exFAT がドライブ全体を使用している場合、標準ツールでその中から直接 APFS 用の領域を切り出すことはできないため、バックアップしてパーティションを作り直します。

暗号化した外部ドライブ

マウント移行では、外部ドライブの APFS コンテナにデータボリュームを作成しますが、新しいボリュームは元のパスワードを引き継ぎません。そのまま移行すると、ローカルで FileVault に保護されていたチャット履歴が、ドライブを接続した人なら誰でも読めるボリュームに保存されます。ログイン時の自動ロック解除とパスワード管理を実装するまでは、AppPorts は暗号化した APFS ドライブでのマウント移行を提供しません。未暗号化のボリュームを黙って作成することもありません。

選択できる方法は次のとおりです。

• このままにする：コンテナデータをローカルに残し、FileVault による保護を維持します。
• 暗号化されていない APFS のドライブまたはパーティションを使う：外部ドライブ上ではこのデータが暗号化されないことを理解したうえで移行します。

クラシックデータ移行モード

設定の「クラシックデータ移行モード（非推奨）」は、1.8.1 のシンボリックリンク + 再署名方式を復活させます。APFS は不要ですが、macOS 27 でサンドボックスアプリを開けなくなったり、ログイン状態を失ったりする旧方式のリスクがすべて残ります。既存の方式に依存するユーザー向けの機能であり、APFS の要件を避ける目的で有効にすることは推奨しません。設定を参照してください。

よくある質問

以前 exFAT に移行したコンテナデータはどうすればよいですか？

旧方式はショートカットと再署名を使用し、外部ドライブの形式には依存しません。問題は形式ではなく再署名です。macOS 27 へのアップグレードに従って対処してください。その後もコンテナデータを外部に置きたい場合は、APFS の外部ドライブを準備するに従って準備します。

exFAT に「リスクを承知して使う」オプションを用意しないのはなぜですか？

このリスクは、ときどき少量のデータを失うことではなく、一度ドライブを取り外すだけですべて失うことです。取り外しはポータブルドライブのごく普通の使い方です。実際にチャット履歴を失ったユーザーにとって、事前に警告したという説明に意味はありません。

APFS に変えると読み書き速度に影響しますか？

遅くはなりません。APFS は macOS のネイティブ形式で、SSD では通常 exFAT より高速です。私たちのテストでは、同じ USB メモリの APFS ボリュームへのデータベース書き込みは、exFAT への直接書き込みの約 10 倍でした。

HFS+（Mac OS 拡張）は使えますか？

マウント移行には直接使えません。HFS+ には APFS のように複数のボリュームで容量を共有する機能がありません。ただし、ジャーナリング HFS+ は macOS の標準ツールでデータを保持したまま縮小できるため、条件を満たせば領域を確保して APFS パーティションを作成できます。この点は exFAT と異なります。操作前のバックアップは必要です。上の APFS の外部ドライブを準備するを参照してください。

関連ドキュメント

• マウント移行：新しい方式の使い方
• 実験記録：ドライブの取り外しテスト：このページの実験の元データ
• macOS 27 へのアップグレード：旧方式が macOS 27 で動作しなくなる理由
• 外部ストレージガイド：接続方式、容量、ファイルシステムの一般的な推奨事項