macOS Tahoe 26.4でiCloud Driveが全ファイルを自動ダウンロードする問題：原因・回避策・今後の見通し

macOSTahoe ·
macOS Tahoe 26.4でiCloud Driveが全ファイルを自動ダウンロードする問題：原因・回避策・今後の見通し

macOS 26.4以降、iCloudフォルダを開くと中のファイルがすべてダウンロードされ、通信量とSSD容量を圧迫します。検証済みの4つの回避策とbrctl evictコマンドの詳細解説。

Finderで ~/Documents フォルダを開き、いくつかのファイルをスクロールしていると、奇妙なことに気づきます。数百件のPDF、Keynoteのデッキ、写真、アーカイブなど、すべてのファイルが突然ダウンロードされ始めるのです。ダブルクリックしたファイルだけではありません。すべてです。 小さなクラウドアイコンがダウンロード矢印に変わり、ファンが回転し始め、メニューバーのWi-Fiインジケーターが点灯します。状況を把握する頃には、256GBのMacBook Airが40GBのiCloudライブラリを消費し、ホットスポットのデータプランが底をついています。

これは2026年3月下旬にmacOS Tahoe 26.4がリリースされて以来、Apple Communityのスレッドを席巻しているバグです。Optimize Mac Storage（マックストレージを最適化）を利用しているユーザーが影響を受けています。これはiCloud Driveをディスク上で軽量に保つために、使用頻度の低いファイルをクラウドに残しておく機能です。26.4以降、フォルダを閲覧するだけでその内容のフルローカルダウンロードがトリガーされるようになり、この機能の目的が完全に損なわれています。

Appleはこの記事の執筆時点でバグを公式に認めていません。リリースノートへの記載も、ホットフィックスも、一般ユーザーが結果を確認できるAppleSeedチケットもありません。現状では、Apple Discussionsスレッド256273434、Reddit、開発者フォーラムに再現報告が積み重なっており、26.5を待つ間のダメージを実際に軽減できる4つの回避策が存在します。

この記事では、何が起きているのか、なぜ起きているのか、そしてその間にどうすれば帯域幅とSSDを守れるかについて説明します。

まとめ

  • バグの内容: macOS Tahoe 26.4（およびその後の26.4.1）以降、FinderでiCloud Driveフォルダに移動すると、Optimize Mac Storageが有効になっていても、フォルダ内のすべてのファイルのダウンロードがトリガーされます。
  • 影響を受けるユーザー: Optimize Mac Storageを有効にしてiCloud Driveを使用しているすべてのユーザー。小さいSSD（128GB / 256GB MacBook）や従量制接続（ホットスポット、モバイル通信、上限付きプラン）を使用しているユーザーに最も大きな被害をもたらします。
  • 推定原因: bird（CloudDocsデーモン）が使用するファイル調整レイヤーとFinderのQuickLookプリフェッチの回帰。以前は読み取り時のみ水和されていたファイルが、ディレクトリの列挙時に水和されるようになりました。
  • 現在利用可能な回避策: Optimize Mac Storageをオフにして再度オンにする、ターミナルコマンド brctl evict でダウンロード済みファイルを手動で退避する、Optimize Mac Storageを完全に無効にしてローカルコピーを保持する、または選択的アクセスにiCloud.comを使用する。
  • 長期的な修正: コミュニティのテスターはmacOS 26.5 beta 4で部分的な改善を報告しており、一般公開は2026年5月下旬の見込みです。Appleは正式に修正を確認していません。

ユーザーが実際に目にしていること

原因に入る前に、症状を正確に把握しましょう。いくつかの隣接するiCloudバグが存在し、混同しやすいためです。

Apple Discussionsスレッドの複数の報告で一致している報告された動作：

  1. ユーザーが システム設定 → Apple Account → iCloud → iCloud Drive → Optimize Mac Storage をオンにしている。
  2. 最近開いていないiCloud Drive上のファイルがFinderで小さなクラウドと下矢印のバッジを表示しており、リモートに保存されていることを示している。
  3. ユーザーがFinderでフォルダを開く — たとえば ~/iCloud Drive/Documents/Invoices/2024/ — そこには200件のPDFが含まれているとする。
  4. 数秒以内に、そのフォルダ内のすべてのファイルがダウンロードを開始する。Finderのステータスバーに累積進捗バー（「200個のアイテムをダウンロード中、12.8GBのうち4.2GB」）が表示される。クラウドのバッジが青い進捗リングに変わる。
  5. サブフォルダに移動すると、同じことが再帰的に起こる。

多くのiCloud DriveファイルでFinderに同時ダウンロードの進捗が表示されている

これはFinderが常に行ってきた通常の「QuickLook用にサムネイルを取得する」動作ではありません。サムネイルの取得は小さな処理（ファイルあたり最大数キロバイト）であり、ファイルの「ローカルに保存済み」状態を変更しませんでした。26.4の動作はファイルを完全に水和させます — つまり、ペイロード全体がディスクに保存され、ローカルストレージとしてカウントされます。

スレッドの一部のユーザーは、バグが常にすぐにトリガーされるわけではないと報告しています。Spotlightのインデックス作成がフォルダに触れたときにトリガーされることもあります。Finderの列ビュープレビューパネルが開いているときにのみ発生することもあります。Macがアイドル状態になり、birdがメンテナンスパスを実行した後にのみ発生することもあります。トリガーが一貫していないため、バグの確認が難しく、クリーンなバグレポートの提出がさらに困難です。

一貫しているのは結果です。クラウドのプレースホルダーとして残るべきだったファイルが完全にダウンロードされてしまいます。

これが見た目以上に重大な理由

2TBのMac StudioをギガビットFiberで使用している場合、これは迷惑ですが壊滅的ではありません。それ以外のユーザーにとっては、バグは本当に深刻です。

小さいSSDへのストレージ圧迫。 Appleはほとんどのコンシューマー向けMacのベース構成として依然として256GBを提供しています。積極的に水和される200GBのiCloudライブラリは数分でディスクを満杯にします。ディスク使用量が約90%を超えると、macOS自体が誤動作し始めます — Spotlightの再構築が失敗し、スワップが激しくなり、アプリの起動が遅くなり、システムが予測できない順序でキャッシュされたファイルを強制的に退避させることがあります。

従量制接続での通信費。 驚くほど多くのMacユーザーが、帯域幅が従量制または上限付きのカフェ、コワーキングスペース、ホテル、または農村の自宅から作業しています。Photosライブラリバックアップフォルダを誤って閲覧しただけで、午後の間に1ヶ月のデータ割り当てを使い切ることがあります。ダウンロードが始まる前に警告がないため、モバイルホットスポットのユーザーは特に危険にさらされています。

バックアップの混乱。 Time Machineまたはサードパーティのクローンツールを使用している場合、新しく水和されたすべてのファイルがバックアップツールの観点から「変更済み」ファイルになります。コンテンツについて意味のある変更がなかったにもかかわらず、次のバックアップ実行が大規模になります — 時にはテラバイト単位で。バックアップの観点についてはMacバックアップ戦略ガイドでさらに詳しく説明しています。

バッテリーと熱。 継続的なダウンロードはWi-Fiラジオをアクティブに保ち、SSDを常に書き込み続けます。ノートパソコンでは、これによりランタイムが測定可能なほど低下し、MacBook Airなどのファンレスモデルでは熱スロットリングが発生することがあります。

要するに、これは根本的な欠陥は小さいが、後続のコストは大きいバグの1つです。

バグを確認する方法

回避策を適用する前に、5分ほどかけてこのバグがMacで実際に起きていることを確認してください。症状は、新規ログイン後の通常のiCloud同期や、SpotlightやBackupなどのアプリがファイルを読み取ろうとするときに起こる意図的な水和と混同される可能性があります。

テスト手順：

  1. システム設定 → 一般 → ストレージを開きます。現在の空きディスク容量をメモします。
  2. アクティビティモニタ → ネットワークタブを開きます。「受信バイト数」で降順にソートします。bird（CloudDocsデーモンプロセス）の現在の値をメモします。
  3. ターミナルで brctl status を実行し、Optimize Mac Storageが有効になっていることを確認します。
  4. Finderを開き、少なくとも1週間訪れていないiCloud Driveフォルダに移動します。多くのファイル（50件以上）が含まれ、それぞれのサイズが意味のある（1MB以上）ものを選びます。
  5. 60秒待ちます。個々のファイルはクリックしません。
  6. アクティビティモニタに戻ります。birdは数百MB以上を受信しましたか？
  7. ストレージ設定に戻ります。空きディスク容量が顕著に減少しましたか？
  8. Finderに戻り、ファイルのバッジを確認します。クラウドアイコンが進捗リングに置き換えられたり、完全に削除されたりしましたか？

質問6、7、8への答えがすべてYesで、かつ個々のファイルをクリックしていない場合 — バグが発生しています。

より詳細なトレースが必要な場合は、ステップ4の前にターミナルウィンドウで brctl monitor com.apple.CloudDocs を実行できます。birdが実体化を決定したすべてのファイルのライブイベントが表示されます。以前のmacOSリリースでの通常の動作では、明示的に開いたファイルのみが materialize イベントを生成していました。26.4のバグでは、開いたばかりのディレクトリ内のすべてのファイルに対して、急速な連続でmaterializeイベントが発生するのが確認できます。

根本原因：26.4で何が変わったか

ここでは、何がわかっていて何がわかっていないかについて正直に説明する必要があります。

Appleはこの回帰について何も公表していません。26.4の開発者向けリリースノートから最も明確なシグナルは、ファイル調整レイヤーが「iCloud Driveの応答性の改善」に関連する変更を受けたという点です — その正確な表現で、それ以上の詳細はありません。birdのログ出力を注意深く観察に基づくコミュニティの推測では、2つの関連する変更が示唆されています：

1点目、FinderがColumnビューのプレビューやアイコンビューのサムネイルを表示するために使用するプリフェッチヒューリスティックが拡大されたようです。以前、Finderは表示されている各ファイルについてbirdにメタデータ — ファイルサイズ、更新日時、サムネイル — を要求し、birdはファイルを完全に水和させることなくそれを返していました。26.4では、サムネイルサブシステムが、サムネイルジェネレーターがボディを調べる必要があるかもしれないあらゆるファイルタイプについて完全なファイルコンテンツを要求しているようです — 実際にはほぼすべてのもの（PDF、画像、動画、Officeドキュメント、さらには一部のプレーンテキストファイル）を意味します。

2点目、使用されていない期間の後にファイルをクラウドに再オフロードする通常の退避ポリシーが、大幅に積極性を失っています。数時間以内に退避されるべきファイルが何日も残り続けています。これは、バグを一度だけトリガーしたとしても、ダメージが蓄積することを意味します。birdが喜んで片付ける速度よりも速くディスクが満杯になります。

どちらの観察もユーザーが報告していることと一致しています。トリガーはフォルダのナビゲーション（Finderがサムネイルを要求するとき）であり、ダメージは持続します（その後に何もファイルを退避させていないため）。

明確に指摘しておきたいのは：これはコミュニティが導き出した推測であり、公式な原因分析ではありません。症状と一致していますが、Appleは確認していません。フィードバックアシスタントのレポートを提出する場合は、推測された原因ではなく、観察した症状を説明してください。

iCloud Drive同期がTahoeでどのように機能すべきかについての広いコンテキストは、iCloud Drive完全ガイドが通常のアーキテクチャをカバーしています。現在のバグはそこで説明されている文書化された動作からの逸脱です。

回避策1：Optimize Mac Storageをオフにして再度オンにする

これは最も手間のかからない修正であり、一部のユーザー — 一部の — に機能します。根本的なバグには対処しませんが、birdのプリフェッチ状態をリセットし、一時的な猶予を与えるようです。

手順：

  1. システム設定 → Apple Account（上部に表示されている名前）→ iCloudを開きます。
  2. iCloudを使用しているアプリのリストでiCloud Driveをクリックします。
  3. Optimize Mac Storage をオフにします。スピナーが落ち着くまで待ちます。macOSがローカルコピーがダウンロードされると警告する場合があります — この場合は、完了する前にオンに戻すので警告を無視してください。
  4. 30〜60秒待ちます。
  5. Optimize Mac Storage を再度オンにします。
  6. アクティビティモニタを開いて bird を1分間観察します。ネットワークスループットがほぼゼロに低下するはずです。

最良のケースでは、これによりデーモンの内部状態がリセットされ、数時間または数日間、フォルダの閲覧でダウンロードがトリガーされなくなります。最悪のケースでは何も変わらず、回避策2に移る必要があります。

注意点: 2回の切り替えの間にmacOSが実際にファイルのダウンロードを開始した場合、それらのファイルは現在ローカルにあります。しばらくの間、自動的に退避されません（上記の退避ポリシーの問題を参照）。回避策2でスペースを手動で解放することをお勧めします。

Optimize Mac Storageのトグルを表示するmacOS設定パネル

回避策2：brctl evict でファイルを手動退避する

ファイルがすでに自動ダウンロードされている場合は、コマンドラインユーティリティ brctl を使用して手動でクラウドに戻すことができます。brctl はAppleが提供する実際のツールです — Tahoeを実行しているMacで man brctl を実行すると確認できます。

関連するコマンドは brctl evict で、「このパスにあるドキュメントのローカルコピーを退避する」というものです — まさに私たちが求めているものです。

単一ファイル

brctl evict ~/Library/Mobile\ Documents/com~apple~CloudDocs/Documents/old-invoice.pdf

~/Library/Mobile Documents/com~apple~CloudDocs/ 内のパスは、macOSが実際にiCloud Driveのコンテンツを保存している場所です。サイドバーのFinderショートカット「iCloud Drive」はそのパスにマッピングされています。また、Finderからターミナルウィンドウにファイルをドラッグすることで、完全なパスを自動的に貼り付けることもできます。

フォルダ全体を再帰的に

brctl evict には組み込みの -R 再帰フラグがないため、find と組み合わせます：

find ~/Library/Mobile\ Documents/com~apple~CloudDocs/Documents/Invoices -type f -exec brctl evict {} \;

これは Invoices フォルダ全体を走査し、見つかったすべてのファイルを退避します。数百のファイルがあるフォルダでは、1〜2分かかることがあります — それは正常です。

まず最大のファイルを解放する

急いでディスクスペースを回復する必要がある場合は、大きなファイルだけを対象にします：

find ~/Library/Mobile\ Documents/com~apple~CloudDocs -type f -size +100M -exec brctl evict {} \;

-size +100M フィルターは100MB以上のファイルに絞り込みます。お好みに合わせて調整してください。

前後の状態を確認する

brctl status

これはCloudDocsデーモンの状態のスナップショットを出力します。ローカルに保存されているファイルとクラウドのみのファイルの数が含まれます。退避パスの前後に実行して変更を確認します。

brctl evictコマンドと出力を表示するターミナルウィンドウ

brctl evict がしないこと

iCloudからファイルを削除しません。このMac上のローカルコピーを削除するだけです。ファイルはクラウドに残り、Finderのプレースホルダーはそのまま残ります — ダブルクリックすることでいつでも再ダウンロードできます（バグが再トリガーされないと仮定して）。

また、未保存の変更があるファイルや現在アプリケーションで開いているファイルには機能しません。最初に関連するアプリを閉じてください。

広範な退避を実行する前の確認

大きなツリーに対して find ... -exec brctl evict {} \; を実行する前に、パスと動作を確認するために小規模なドライランを実行します：

# 対象となるファイルをリスト表示、退避はまだ実行しない
find ~/Library/Mobile\ Documents/com~apple~CloudDocs/Documents/Invoices -type f -size +100M

# リストが正しいことを確認したら、退避を実行する
find ~/Library/Mobile\ Documents/com~apple~CloudDocs/Documents/Invoices -type f -size +100M -exec brctl evict {} \;

bird が特定のファイルを退避できない場合（コミットされていない変更がある、他で開かれている、アクティブなiCloud同期操作の一部である）、エラーを出力して続行します。エラーは致命的ではなく、ループを停止しません。

brctl dump com.apple.CloudDocs を使用して、完全なデータベース状態を出力することもできます — これは詳細であり、主にフォレンジックツールとして役立ちますが、退避が明らかでない理由で失敗している場合、どのファイルが詰まっているかを特定するのに役立つかもしれません。

Appleスレッドの不満を持つユーザーによく見られるパターンは、退避を毎日のLaunchAgentにラップすることです — 本質的に、バグが日中にローカルキャッシュを再充填するという仮定の下で、毎晩iCloud Drive全体に対して brctl evict を実行するスケジュールジョブです。これは壊れやすく、実際にオフラインで欲しいファイルと悪い相互作用をする可能性があるため、ほとんどのユーザーにはお勧めしません。しかし launchd を理解していて試してみたい場合は、レシピは簡単です。

回避策3：Optimize Mac Storageを完全に無効にする

帯域幅の状況が深刻で、偶発的なダウンロードさえ許容できない場合、核の選択肢はOptimize Mac Storageを無効にして、iCloud Drive内のすべてをローカルに保持することを受け入れることです。

トレードオフ分析：

  • メリット: サプライズダウンロードがなくなる。ディスク上にあるものはディスク上にある。iCloud Driveのネットワーク使用量は、作成または変更したファイルのデルタのみになる。
  • メリット: 予測可能なバックアップ。毎晩のTime Machineとクローンは実際に変更されたファイルのみを確認する。
  • デメリット: iCloud Driveライブラリの全体サイズと同じ空きディスクスペースが必要。iCloudに500GBあり256GBのSSDがある場合、これは選択肢にならない。
  • デメリット: Optimize Mac Storageを無効にした後の初回ダウンロードは、ライブラリ全体からすでにローカルにあるものを引いた分の一時的な帯域幅消費となる。100GBのライブラリの場合、100GBのダウンロードになる。
  • デメリット: どのデバイスからでもライブラリ内の任意のファイルを開くという利便性が失われる — iCloud Driveに何を置くかについてより慎重になる必要がある。

この状況の多くのユーザーは、この機会を積極的にアーカイブする強制関数として使用します。古いプロジェクト、古い請求書、古いスクリーンショット — 外部ドライブまたはアーカイブクラウド（Backblaze B2、Wasabi、Dropboxのコールドストレージ）に移動し、iCloud Driveから完全に削除します。ストレージ管理ガイドでは、何がスペースを消費しているかを特定するツールについて説明しています。

このルートを選択した場合、初回の同期に長時間かかることを覚悟してください — 大きなライブラリの場合は数日かかることが多く、その間はMacを電源に接続し、電力にやさしいWi-Fiに接続したままにしておいてください。

回避策4：選択的アクセスのためにiCloud.comを使用する

古い税務書類、アーカイブ済みプロジェクト、参照用PDFなど、時々しかアクセスする必要がないファイルについては、Finder経由でアクセスしなければならないというルールはありません。iCloud.comは、アクティブにクリックしたものだけをダウンロードするWebベースのファイルブラウザを提供します。

これが有効な場合：

  • フォルダ全体ではなく、フォルダ内の特定のファイルが必要な場合。
  • 従量制接続で、すべてのバイトについて慎重になりたい場合。
  • 借りたMacや空きディスクスペースがほとんどないMacを使用している場合。

手順：

  1. 任意の最新ブラウザで iCloud.com にアクセスしてサインインします。
  2. iCloud Driveをクリックします。
  3. 目的のファイルに移動します。一度クリックしてプレビューするか、ダウンロードアイコンをクリックしてローカルのDownloadsフォルダに保存します（同期ループに入れないために重要 — iCloud Driveフォルダではなく）。

これにより bird とFinderを完全にバイパスします。ダウンロードはブラウザへの標準HTTPSを介して行われ、ファイルはこのMacのiCloud Driveキャッシュの一部になりません。

欠点は明らかです — 日常の作業ファイルの場合、ブラウザタブに切り替えることは不要な摩擦です。しかし、バグが続く間の時々のアクセスのリリーフバルブとして、これは本当に役立ちます。

回避策5：代替としてのサードパーティクラウドマウンター

一部のコミュニティメンバーは、iCloud Drive（および他のクラウドサービス）を厳格なオンデマンドセマンティクスを持つ適切なネットワークボリュームとしてマウントするサードパーティツールに切り替えました。最もよく言及される2つ：

  • CloudMounter: iCloud Drive（およびDropbox、Google Drive、OneDrive）を仮想ディスクとしてマウントします。明示的に開いたファイルのみが取得されます。マウントが別のプロトコルを使用するため、Finderのサムネイルプリフェッチはありません。
  • Mountain Duck: 同様のコンセプトで、開発者/SFTPワークフローをより重視しますが、iCloud Driveをサポートしています。

重要な注意点: どちらのツールも、Appleのネイティブicloud Driveと同じレベルのシステム統合を持っていません。Photosライブラリの同期、アプリのサンドボックスコンテナの同期、~/Desktop および ~/Documents のリダイレクトは、これらのツールでは機能しません — それらは引き続きネイティブのAppleスタックを経由します。これらは、厳格な制御が必要な特定のアーカイブまたはドキュメントフォルダに役立ちますが、完全な代替品としてではありません。

私たちは個人的に26.4バグに対してこれらをテストしていないため、自分のセットアップで確認するまでは報告を逸話的なものとして扱ってください。実験する場合は、まず重要でないフォルダで試してください。

一般的なパワーユーザーのiCloudワークフローの詳細については、iCloud Drive高度なワークフローをご覧ください。

帯域幅とストレージへの影響：概算

コストに数字をつけることで、優先順位を付けやすくなります。

帯域幅シナリオ。 70GBが以前にクラウドプレースホルダーとして保存されていた100GB iCloud Driveライブラリを想定します（Optimize Mac Storageは設計通りに機能していた）。バグが1週間の通常のFinder閲覧で完全な再水和をトリガーした場合、最大70GBを再ダウンロードします。50Mbps接続では、それは約3〜4時間の飽和ダウンロード — または1ヶ月の典型的な100GBモバイルプランが1週間でなくなることを意味します。

ストレージシナリオ。 同じ100GBライブラリ、同じ70GBが以前リモートにあった。バグが進行した後、ディスクに100GBがあります。OSとアプリ、その他のドキュメントがすでに120GBを占めている256GBのSSDでは、66GB空きからゼロになります — macOSは新しいファイルの保存を拒否し、キャッシュをランダムに退避させ、ディスクスペース不足を警告し始めます。

マルチMacシナリオ。 これが最も痛い状況です。デスクトップとラップトップなど2台のMacを持ち、どちらもOptimize Mac Storageを有効にした26.4を実行している場合、バグはそれぞれ独立してトリガーされます。ラップトップでライブラリを閲覧するとそこでファイルが水和され、デスクトップで閲覧すると同じファイルがそこでも水和されます。それは2倍の帯域幅コストです。iCloudライブラリがNASベースのTime Machineにある場合、バックアップターゲットでもストレージコストが発生します。

これらは概算ですが、数量の桁感は人々がスレッドで報告していることと一致しています。

具体的な例。 数年前の完成したクライアントプロジェクトを保有する250GB iCloud Driveを持つフリーランスのデザイナーを考えてみましょう。通常のOptimize Mac Storageの動作では、512GB MacBook Proにはある時点で約40GBのみがローカルに存在していました — 最近のプロジェクト、現在の請求書、いくつかの参照資料。26.4にアップグレードした後、新しいピッチデッキのスクリーンショットを見つけるために Clients/2023/ フォルダを開いたところ、20分で空き容量が180GBから60GBに減少しました。翌朝、Spotlightが新しくダウンロードされたファイルの再インデックスを終えると、28GBの空き容量になり、macOSはスタートアップディスクがほぼ満杯であると警告していました。作業スペースを回復するためだけに、ローカルに必要なかった何年分もアーカイブされたプロジェクトに対して1時間 brctl evict を実行しなければなりませんでした。それらのファイルのどれも意図的に触れられていませんでした。その帯域幅は計画されていませんでした。

これが、大きなライブラリと重要な仕事を抱えるユーザーにとってのバグの実体験です。数字は理論的なものではありません。

今後のストレージ戦略

Appleがこの特定の回帰を修正した後も、このエピソードは「Optimize Mac Storage」が魔法のスペルではないことを思い出させてくれます — これは失敗する可能性があるヒューリスティックです。ストレージ戦略にある程度の多層防御を構築することは価値があります。

iCloud Driveに何を置くかについて慎重になりましょう。 フォルダが真にアーカイブ用の場合 — 年に一度参照するような場合 — それはそもそもiCloud Driveに属しません。外部SSDまたはオブジェクトストレージサービスに移動してください。iCloud Driveはデバイス間でアクティブに作業するファイルのために予約すべきです。

PhotosライブラリとiCloud Photosを別々に使用しましょう。 Photosにはicloud Driveよりも堅牢な独自の最適化モデルがあります。写真ライブラリがiCloudの使用量の大部分を占める場合、iCloud Driveのバグは直接影響しません。

bird を定期的に監視しましょう。 日常的なチェックを追加します — 週に一度、brctl status と du -sh ~/Library/Mobile\ Documents/com~apple~CloudDocs を実行して、何がローカルにあるかを確認します。ローカルサイズが予期せず増加している場合は、早期に介入できます。

ディスクスペースアラートを設定しましょう。 macOSはディスクスペース不足を警告しますが、それは重大なときだけです。より積極的なモニター（DaisyDiskの空きスペースウィジェット、OmniDiskSweeper、または osascript 通知付きの小さなシェルスクリプト）は、まだ対処の時間があるうちに問題を検出できます。

これらのパターンについての詳細な説明は、ストレージ管理最適化ガイドをご覧ください。

Appleはいつ修正するか？

Tahoeサイクルの次のmacOSリリースは26.5です。2026年5月初旬時点で、beta 4は開発者とパブリックテスターの手にあります。Apple Discussionsスレッドの複数のユーザーは、beta 4では自動ダウンロードの動作がそれほど深刻ではないと報告しています — テストではフォルダの閲覧で大規模な水和がトリガーされなくなりました。ただし、退避は依然として26.4以前のベースラインよりも遅く見えており、Appleが最も急性の症状には対処したが必ずしも元の動作に完全に戻していない可能性を示唆しています。

Appleの典型的なリリースサイクルに基づくと、26.5の一般公開は2026年5月下旬（5月18日または5月25日の週）と予想されます。Appleは日程を正式に確認しておらず、歴史的にはベータ版に後期の回帰が現れた場合、ドットリリースが6月初旬にずれ込むことがあります。

26.5 beta 1の内容については別途詳細をまとめており、ベータが進むにつれて更新します。26.5 GAがリリースされ、iCloud Driveの動作が26.4以前のレベルに戻ったかどうか確認できたとき、この記事も更新します。

それまでの間：26.5 GAに修正が含まれていると仮定しないでください。無効にした場合は、Optimize Mac Storageを再度有効にする前に自分のセットアップでテストしてください。Appleのドットリリースのリリースノートは悪名高いほど簡略で、修正が明示的に言及される場合とそうでない場合があります。

バグが生きている間のベストプラクティス

これからの1ヶ月程度の推奨姿勢をまとめると：

  1. ライブラリサイズを把握する。du -sh ~/Library/Mobile\ Documents/com~apple~CloudDocs を実行して現在ローカルにある量を確認し、システム設定 → Apple Account → iCloudでiCloud Driveの総使用量を確認します。
  2. 許容範囲を決める。 十分なディスクと無制限の帯域幅がある場合、Optimize Mac Storageをオンのままにして brctl evict で定期的にクリーンアップできます。どちらかが制限されている場合は、Optimize Mac Storageを無効にしてフルローカルコピーとともに生活するか、最もアーカイブ用のコンテンツをiCloud Driveの外に移動してください。
  3. 大きなiCloudフォルダをカジュアルに閲覧するのを避ける。26.5がリリースされて確認されるまで、アーカイブフォルダへのFinder移動を意図的な行為として扱い、何気なくクリックしないようにしてください。
  4. バックアップを監視する。バグによる水和の嵐は、1回の実行でバックアップサイズを10倍以上に増やす可能性があります。バックアップクォータがある場合は注視してください。
  5. フィードバックアシスタントにレポートを提出する。Appleがバグを認識していても、再現可能なケースと sysdiagnose の添付ファイルを持つ追加のレポートは重みを増します。macOSのフィードバックアシスタントを使用し、iCloud → iCloud Driveの下に提出し、症状を具体的に説明してください。
  6. 参照ドキュメントを更新する。26.4 / 26.4.1アップデートガイドとiCloud Drive完全ガイドはブックマークする価値があります — 状況が進展するにつれて両方を更新します。

よくある質問

Q1. Appleはこのバグを確認しましたか？ いいえ。2026年5月初旬時点で、Appleは26.4のiCloud Drive自動ダウンロード動作について公的な声明を出していません。認識はApple Discussionsスレッド256273434などのコミュニティスレッドにのみ存在します。

Q2. これはiOSまたはiPadOSに影響しますか？ Finder固有のトリガーは、iOSまたはiPadOSには存在しません。それらは異なるファイルブラウザを使用するためです。ただし、一部のiPadOSユーザーは最近のアップデート後にファイルアプリで同様のダウンロード増加を報告しています。原因が関連しているかどうかはわかりません — 別個の調査事項です。

Q3. Optimize Mac Storageを無効にすると、クラウドのファイルが削除されますか？ いいえ。Optimize Mac Storageを無効にすると、ローカルキャッシュポリシーのみが変更されます。ファイルはiCloudに残ります。変更はより多くのファイルがクラウドと同時にMacにローカルに存在することを意味するだけです。

Q4. brctl evict はPhotosライブラリのファイルで機能しますか？ Photosライブラリには独自の最適化モデルがあり、iCloud Driveと同じ bird プレースホルダーを使用しません。brctl evict はPhotosには適切なツールではありません。Photosのスペース管理については、システム設定 → Apple Account → iCloud → Photosと、そこにある Optimize Mac Storage トグルを使用してください。これはiCloud Driveのものとは別の設定です。

Q5. brctl evict を自動的に実行するようにスクリプト化できますか？ はい、launchd のLaunchAgentまたはシンプルなcronエントリを介して可能です。実際にオフラインで欲しいファイルを退避させる可能性があるため、デフォルトとしてはお勧めしません。行う場合は、範囲を厳密に絞ってください — たとえば100MB以上で過去30日間に変更されていないファイルのみ。

Q6. サードパーティのクラウドサービスでバグは発生しますか？ いいえ。Dropbox、Google Drive、OneDriveは独自のデーモンを使用しており、同様の動作を示すとは報告されていません。バグはmacOS 26.4のAppleのiCloud Driveスタックに固有のものです。

Q7. 26.3にロールバックすると修正されますか？ 技術的にはYesですが、Appleはポイントリリースのロールバックを公式にサポートしていません。以前のmacOSのUSBインストーラーから再インストールする必要があり、消去とバックアップからの復元を意味します。ほとんどのユーザーにとって、これは数週間バグと共存するよりも悪い選択肢です。

Q8. セーフモードではどうですか — そこでバグは発生しますか？ セーフモードはSpotlightのインデックス作成と多くのバックグラウンドサービスを無効にします。一部のユーザーはセーフモードではバグが深刻でないと報告しており、Spotlightのインデックス作成またはサムネイルのプリフェッチが関与しているという理論を支持しています。セーフモードは長期的な回避策として使用できませんが、有用な診断です。

Q9. これに対処するために追加のiCloudストレージを購入しました — それは正しい選択ですか？ いいえ。追加のiCloudストレージはクラウドスペースを増やします。バグはローカルディスクと帯域幅の問題です。iCloudストレージを増やしても助けにはなりません。それどころか、再ダウンロードする潜在的なデータが増えるため、最悪のケースをさらに悪化させます。

Q10. 最終的な26.5の修正により、すでにダウンロードされたファイルが自動的に退避されますか？ おそらく自動的にはなりません。修正はキャッシュを事後的にクリーンアップするよりも、トリガーに対処すること（将来の過度に積極的なダウンロードを防ぐこと）が最も可能性が高いです。26.5がリリースされた後も、オフラインで必要ないフォルダに対して1回限りの brctl evict パスを実行することをお勧めします。

まとめ

macOS Tahoe 26.4のiCloud Drive自動ダウンロードバグは、低レベルサービス — この場合、ファイル調整 — の小さな回帰がどのようにしてエンドユーザーへの実際のコストにカスケードできるかの典型的な例です。修正はAppleの手にあり、26.5ベータで部分的に修正されているようです。それまでの間、ここで説明した4つの回避策によって被害を大幅に制限できます：

  1. Optimize Mac Storageをオフにして再度オンにする（クイックリセット）。
  2. brctl evict を使用してファイルが自動水和した後に手動でスペースを解放する。
  3. 帯域幅の状況がそれを必要とする場合、Optimize Mac Storageを完全に無効にする。
  4. アーカイブファイルへの選択的アクセスにiCloud.comを使用する。

継続的なコンテキストについては、iCloud Drive完全ガイド、iCloud高度なワークフロー、およびバックアップ戦略ガイドが長期的な姿勢をカバーしています。26.4アップデートガイドと26.5 beta 1ガイドは広いリリース状況を追跡します。26.5がリリースされてバグが完全に解決したかどうか確認できたとき、この記事を更新します。

追加の再現や詳細を共有する場合、最も適切な場所は引き続きApple Discussionsスレッド256273434です — そこに具体的な報告が多いほど、Appleがクリーンな修正を提供するプレッシャーが大きくなります。