---

固定パーティションを過去にしたAPFSの空間共有

予約容量は空欄にして割り当て上限だけ決めるコツ

従来のファイルシステムでは、4TB のドライブを 2TB ずつに分けるには「物理的な固定の壁（パーティション）」を作るしかありませんでした。すると後から「データ側が 2.5TB に増えたのに、バックアップ側はまだ 500GB しか使っていなくてガラ空き」という無駄が生まれ、壁の位置を動かそうとするとデータ破損のリスクが伴いました。

これに対して macOS 標準の APFS「スペースシェアリング（空間共有）」 は、ドライブ全体を「1 つの大きな共有プール（コンテナ）」にしたまま、その中に 独立したドライブアイコンとして見える仮想ボリュームを何個でも一瞬で追加できる 仕組みです。既存データが入った APFS ドライブでも、データを消さずに数秒で追加できます。

特に Time Machine 用ボリュームを追加するときに一番大切なのが、サイズオプションにある 「予約容量」と「割り当て容量（クォータ）」の使い分け です。

設定項目	おすすめ入力値（4TBを2TBずつ使う例）	理由と実際の動き
予約容量（下限ロック）	空欄（何も入れない！）	ここに 2 TB と入れてしまうと、バックアップがまだ 100GB しかない初期段階でも 2TB 分を最初からロックしてしまい、共有の良さが消えてしまいます。
割り当て容量（上限クォータ）	2 TB を指定	Time Machine は放っておくと古い履歴を残そうとしてドライブ全体を食い潰します。上限を 2 TB にしておけば、2TB の天井に達した時点で古い履歴から自動整理 され、残りの 2TB 以上が自動的にデータ用ボリュームで広々使えます。

さらに APFS ボリュームは「確定申告や資産管理用のボリュームだけ暗号化パスワードをかけて普段はアンマウント（Finder や Spotlight から完全に非表示化）しておく」といった使い方も自在にでき、家庭用 Mac でも抜群の使い勝手を発揮します。

外付けSSD2台をRAIDで束ねない方がいい理由

ちなみに、PRO-G40 のような外付け SSD が手元に 2 台 あるとき、「いちいち 2 つのドライブを見に行くのが面倒だから、RAID 機能（ストライピング RAID 0 や連結 JBOD）で 2 台を合体させて 1 つの巨大ドライブに見せるのはどう？」と考えたくなりますが、これは絶対に避けるべき危険な罠 です。

外付けケーブル接続の SSD を 2 台またぎで 1 つの論理ドライブにしてしまうと、どちらか片方のケーブルが一瞬緩んだり、片方だけが故障したりした瞬間に、無傷なはずのもう 1 台も含めて「全データが道連れで消失」 してしまいます（なお、APFS のスペースシェアリング自体は 1 台のドライブ内の機能であり、2 台を合体させるものではありません）。

2 台の外付け SSD を安全かつ快適に使うなら、物理ドライブは独立させたまま「1 台目は写真・動画用、2 台目は書類・バックアップ用」と役割を分け、Finder の 「サイドバー登録」や「スマートフォルダ（2 台を横断して最新ファイルや画像を自動一覧表示する検索窓口）」 で束ねるのが、データ消失リスクゼロの最も賢い運用です。

---

謎の容量圧迫とローカルスナップショットの正体

パージ可能領域が消える4つのタイミングと手動整理

Mac を使っていると、容量可視化アプリ（DaisyDisk など）で内蔵 SSD を見たときに 「隠し領域（Hidden space）」が 300GB〜 400GB 近くも占領している！ と肝を冷やすことがあります。

まず DaisyDisk に「フルディスクアクセス権限」を与えて管理者スキャンを行うと、その大半の正体が 「パージ可能領域（Purgeable space）＝ Time Machine のローカルスナップショット」 であることが分かります。

ローカルスナップショットとは、外付けバックアップドライブを繋いでいない時間帯にも、APFS の差分記録技術を使って 1 時間ごとに自動作成される「内蔵 SSD 内の復元ポイント」です。原則として次のタイミングで自動削除されるため、普段は放置して構いません。

1. 作成から 24 時間が経過したとき（古い世代から順次自動破棄）
2. 内蔵 SSD の空き容量が足りなくなったとき（OS がユーザーの保存を最優先して即座に自動回収）
3. 外付けドライブへの Time Machine バックアップが完了した数分後（※直近の最新 1 世代だけは安全のため残り、余裕があれば 24 時間満了まで残ることもあります）

もし大容量データのコピー前などで「今すぐ実容量として空けたい」という場合だけ、ターミナルで tmutil listlocalsnapshots / を実行して日付を確認し、sudo tmutil deletelocalsnapshots <日付文字列>（またはディスクユーティリティのスナップショット一覧から削除）を実行すれば安全に解放できます。

Handoff用キャッシュが200GB超に膨らむ罠

ただし、隠し領域ではなく 「本当にバグで勝手に膨れ上がっている異常キャッシュ」 が潜んでいることもあります。実際に私の環境で発見したのが、次のフォルダがなんと 約 207.4 GB も内蔵 SSD を圧迫していた現象でした。

~/Library/Group Containers/group.com.apple.coreservices.useractivityd

この useractivityd は、iPhone や iPad と作業を引き継ぐ「Handoff」や「ユニバーサルクリップボード（コピー＆ペースト共有）」の同期データを扱う裏方プロセスですが、macOS の不具合で一時ログが消えずに何百 GB も溜まり続けることがあります。

この場合は、Finder の「フォルダへ移動（Shift + Command + G）」で上記パスを開き、親フォルダ自体は残したまま「中身のファイルやサブフォルダだけ」をゴミ箱へ入れて空にし、Mac を再起動 すれば、不具合を起こさず一気に 200GB 以上の空き容量を取り戻せます（なお、クリーンインストール時などに Time Machine から ~/Library を手動復元する際も、Fonts や Keychains、必要なアプリの Application Support だけを戻し、Caches や Saved Application State は復元しないのが不具合を持ち込まない鉄則です）。

SSDの残り寿命診断とデスクトップのスリープ設定

また、長く使っている Mac の「内蔵 SSD の寿命があとどれくらい残っているか」は、無料トライアルのある診断アプリ 「DriveDx」 や、Homebrew で入れる smartctl -a disk0 コマンド（S.M.A.R.T. 情報）で正確に確認できます。

実際に手元の 2 台を診断したところ、1TB の NVMe SSD（通電約 1,035 時間）は残り寿命 97% と新品同様だった一方、長年稼働してきた 500GB SSD は書き込み寿命（セルの摩耗度）こそ残り 約 70%（総書込量約 115TB）と余裕があるものの、通電時間が 50,476 時間（約 5.76 年分！） に達していました。5 万時間を超えるとメモリセルより先にコントローラ IC が突然死するリスクが高まるため、こうした数値を見ておくことでバックアップの重要性がよく分かります（※なお CPU・RAM・GPU には摩耗パーセンテージを出す機能はなく、Apple Diagnostics［起動時 D キー］等で健全性を確認します）。

パーツの通電寿命やファンのホコリ吸い込みを抑えるには、1 時間以上離席するときは「画面オフだけ」ではなく 「システム全体のスリープ」 に入れるのが一番です。デスクトップ型の iMac は初期設定で hibernatemode 0（メモリ通電スリープのみ・SSD への毎回書き出しなし）になっているため SSD を傷めませんし、夜間に外付けドライブが勝手に動くのが嫌な場合は sudo pmset -a powernap 0 でスリープ中のバックグラウンド動作を止めておいても、次回スリープ復帰後に前回から 1 時間以上経っていれば自動で Time Machine が走ってくれるので安心です。

---

大容量メモリ環境でのキャッシュとTCP通信の真実

ブラウザのキャッシュ上限拡大より効くRAMディスク

32GB や 64GB の大容量メモリを積んでいると、「Chrome や Safari、動画再生ソフト（IINA）、動画編集ソフト（Final Cut Pro）でもっとメモリキャッシュを使わせたい！」と思いますよね。しかし調べてみると、ここにも現代ならではの意外な真実がありました。

• Google Chrome の --disk-cache-size 拡大はほぼ無意味 ：Chrome の標準ディスクキャッシュ上限は最大 320MB 前後に抑えられていますが、これを起動オプションで無理に 2GB へ広げても、あくまで「SSD 上の保存枠」が増えるだけです。現代の Web は動的ページばかりな上、数 GB のキャッシュ目次を探す処理でかえって遅くなり SSD 書き込みも増えます。メモリを活かすなら、本当にメモリ上に作った RAM ディスクへキャッシュ先を逃がす か、メモリセーバーを切って大量のタブをそのままメモリに常駐させる方がずっと快適です。
• IINA と Final Cut Pro は効果絶大！ ：動画プレイヤー IINA は「設定 ＞ ネットワーク」のキャッシュサイズを 1024〜 2048MB に上げることでシークが安定し、Final Cut Pro はライブラリの「キャッシュ（レンダリングファイル）」の保存先だけを RAM ディスク に指定する（バックグラウンドレンダリングはオフにして手動レンダリング運用にする）ことで、プロジェクト本体を安全な SSD に置いたまま内蔵 SSD の寿命消費を劇的に減らせます（※逆に ATOK の学習辞書をシンボリックリンクで RAM ディスクへ逃がす手法は、再起動時の消失や macOS の厳格な権限保護・クラウド同期エラーの原因になるため非推奨です）。

sysctlによるTCPバッファ確認と自動調整の壁

また、Windows 時代にレジストリで TCP/IP のウィンドウサイズを弄っていた感覚で、macOS のカーネル設定コマンド sysctl を覗いてみた結果も非常に興味深いものでした。

ターミナルで sysctl net.inet.tcp を調べると、iMac 15,1 でも iMac 20,1 でも、接続（ソケット）1 本あたりの初期バッファ（sendspace / recvspace）は一律 131072（128KB） になっていますが、自動拡張の上限（autorcvbufmax / autosndbufmax）は最初から 4194304（4MB） が確保されており、昔の rfc1323 設定も現在は常時有効としてカーネルに統合されています。

通信で本当に必要なバッファ量（帯域遅延積：BDP）を計算してみると、その完成度がよく分かります。

つまり、一般的な 1Gbps 光回線の国内通信なら 標準の自動拡張 4MB で 100% 帯域を使い切れている のです（10Gbps 回線や海外サーバーとの大容量転送をする場合のみ、8MB〜 16MB へ広げる余地があります）。

---

ATOK対ライブ変換の思想差とブックPDF一括救出

人間が確定するATOKと文脈任せのライブ変換

日々の執筆で毎日触れる日本語入力についても、長年愛用してきた ATOK と、macOS 標準の 「ライブ変換」 には設計思想の面白い対比があります。

macOS 標準のライブ変換は、スペースキーを押さなくても文字を打ったそばから文脈を読んで勝手に漢字へ変わっていくため、雑記やチャットをノンストップで流し込むスピード感は抜群です（ATOK 側には 1 文字ごとのライブ変換はなく、句読点を打った瞬間に変換する「自動変換」モードが最も近い機能になります）。

しかし、いざ長文の原稿を書いていると、ライブ変換は 「『〜という感じがする』と打ったのに、前後の専門用語に引っ張られて勝手に『漢字がする』に化ける」 といった同音異義語の空振りがどうしても起きます。勝手に変わった文字に気づいて矢印キーで戻って直す「視線と思考のノイズ」を考えると、スペースキーを押した瞬間に用例（「感：気持ち」「漢：文字」）を見て 人間が自分の意思で確定させる ATOK のリズム は、やはり誤字の許されない執筆において今なお圧倒的な安心感があります。

AppleブックのPDF数百冊を一括で取り出す手順

最後に、macOS Sequoia の純正 「ブック（Apple Books）」 アプリに取り込んでいた 約 800 冊もの PDF 資料を、パソコンの通常フォルダへ一括で救出（バックアップ）したときの実戦手順 を共有します。

数が少ないうちはブックアプリの「PDF」一覧から Command + A で全選択してフォルダへドラッグ＆ドロップするだけで取り出せますが、800 件規模で iCloud 同期が絡んでいるとドラッグが重くなったり、古い解説記事にあるローカル保存パス（~/Library/Containers/com.apple.BKAgentService/...）を開いても Books.plist しか入っていなかったりして焦ることがあります。

iCloud 同期が有効な環境で確実に全 PDF を取り出す手順は次の 3 ステップ です。

---

まとめ：macOSの自動制御を信じる部分と整える部分

Windows 時代の細かい手動チューニング経験があるからこそ見えてきた、現代 macOS との一番気持ちいい付き合い方をまとめます。

普段は見えない macOS の裏側の仕組みを一度しっかり把握しておくと、「ここは OS に任せて大丈夫」「ここだけは時々掃除しよう」と迷いがなくなり、毎日のデスクワークがいっそう快適になりますね！