MacのLow Data Mode：実際に何をするのか（そして何をしないのか）

MacのLow Data Modeは、macOSとその上で動作しているアプリに特定の接続のネットワーク使用量を減らすよう指示します。オンにすると、macOSは自動ソフトウェアアップデートやバックグラウンドのApp Storeダウンロードを一時停止し、iCloud Photosの同期を停止し、iCloud Driveやバックアップの活動を控えめにし、Appleのバックグラウンドサービスを静かにし、FaceTimeなどのビデオ通話はビットレートを下げることがあります。これはシステム全体ではなく、ネットワークごとに設定されるため、あなたのMacはiPhoneのホットスポットを高価とみなす一方で、自宅のWi-Fiを無制限とみなすことができます。

この機能が属するカテゴリーについて正確に理解する価値があります。Low Data Modeはスロットル、帯域幅制限、ファイアウォール、またはデータメーターではありません。何も制限しませんし、何もカウントしませんし、制限に近づいていると通知することもありません。なぜなら、制限の概念を持たないからです。これはネットワークに付随する単一のブール値であり、その役割は、遅延可能な作業を後で、より安価な接続に移すことです。

この枠組みは、その長所と短所の両方を説明します。長所は、即時に動作し、無料で、サードパーティのソフトウェアを必要とせず、パフォーマンスへの影響もないことです。Apple自身のサービスは、一般的なMac上で予期しないバックグラウンドトラフィックの最大の原因であり、Low Data Modeはそれらに直接かつ確実に対処します。遅延させたmacOSのアップデートだけでも、あなたのデータ容量を消費する数ギガバイトになることがあります。

短所は同じ設計から生じます。仕組みがフラグでありフィルターではないため、そのフラグの下流にあるすべては任意です。なぜそれが重要かについては第3節で説明しますが、Modeが何を変えるかを読む間、その点を念頭に置いてください：リストの各項目は、Appleがフラグに応答させることを選んだものであり、Apple自身のコード内にあります。

Wi‑Fiの場合は、システム設定を開き、サイドバーのWi‑Fiを選択し、接続しているネットワークの横の詳細ボタンをクリックし、表示されるパネルでLow Data Modeを有効にします。古いリリースのSystem Preferencesを使用している場合は、同等のパスはネットワーク、次にWi‑Fi、次にバージョンに応じてAdvancedまたはDetailsです。この設定はmacOS Montereyで導入され、iOSではiOS 13から存在しています。

重要な点は、このトグルはMacではなくネットワークに属しているということです。macOSはこれを特定のSSIDに保存し、記憶します。したがって、あなたの電話のホットスポットでLow Data Modeを有効にしても、オフィスや自宅のネットワークには影響しません。トレードオフは、通常、ネットワークに接続しているか、既知のネットワークリストに保存されている必要があることです。旅行して新しいホットスポットに接続するたびに、その都度SSIDで設定を再度行う必要があります。

iPhoneのパーソナルホットスポットは、macOSからは通常のWi‑Fiネットワークとして表示されるため、同じ場所で設定されます。ケーブルでテザリングする場合は、システム設定のNetworkでiPhone USBインターフェースを確認してください。そこに同等のオプションが表示されます。有線Ethernetは、固定回線がメーター制限されていないという妥当な想定のため、通常はその設定を提供しません。

一度オンにすると視覚的な確認はありません。バッジも、メニューバーのアイテムも、通知もありません。唯一の確認方法は、同じ詳細パネルに戻り、トグルを確認することです。これはおそらく、この機能の最大の使い勝手の問題です：設定が設定ウィンドウを離れた後に見えなくなるため、ユーザーはそれを有効にしたことを忘れ、速い接続に戻ったときに無効にするのを忘れることがあり、写真ライブラリの更新が停止する原因となります。

最後に混乱しやすい点を明確にします。iPhoneのLow Data ModeとMacのLow Data Modeは、完全に別の設定です。ホットスポットを提供している電話で有効にすると、その電話のトラフィックだけが制限されます。Macには何の影響もありません。

最大かつ最も信頼できる効果はシステムのアップデートに関係しています。Low Data Modeが有効な場合、macOSはバックグラウンドでシステムアップデートをダウンロードしませんし、App Storeは自動アプリのアップデートやバックグラウンドダウンロードを遅延させます。数週間オフラインだったMacでは、これが通常、最も大きな節約になります。なぜなら、macOSのアップデートや大きなアプリのアップデートのいくつかは、ホットスポットで行う他の作業を圧倒するからです。

iCloudは二つ目の主要な領域です。iCloud Photosは同期を一時停止し、これにより新しい写真はMacにストリーミングされず、Macで行った編集もアップロードされずにキューに入ります。iCloud Driveは緊急性の低い同期を遅らせ、バックアップ関連の活動も控えます。これは本当に役立つ動作であり、また最も人を驚かせる可能性のある動作です。なぜなら、一時停止した同期は壊れた同期と見分けがつかないからです。もし同僚がファイルが表示されないと言ったら、他のデバッグを始める前にMacがLow Data Modeのネットワークに接続しているか確認してください。

Appleの他のバックグラウンドサービスも同じパターンに従います。Continuityに関連する機能やAppleが定期的に実行するさまざまなタスクは、その活動を減らします。Safariは予測的なプリロードを縮小し、FaceTimeは弱い接続を飽和させるのではなく低ビットレートのビデオを受け入れます。Appleのフレームワーク上に構築されたサードパーティアプリは、副次的にバックグラウンドスケジューリングが減ることがあります。これはシステムがネットワーク作業のためにそれらを起こす意欲が低いためです。

何が変わらないかについても明確にしておくことが重要です。Low Data Modeは、あなた自身が行うリクエストには一切干渉しません。ページを読み込めば、完全な重さで読み込まれます。ダウンロードを開始すれば、それがダウンロードされます。ストリーミングアプリを開けば、そのアプリが決めた品質でストリーミングされます。何も圧縮されず、何もプロキシされず、画像も縮小されません。モードは、システムが自発的に行う作業にのみ影響します。

また、アカウンティング層がないため、結果についてのフィードバックは得られません。Low Data Modeは、2ギガバイト節約したと教えてくれません。なぜなら、何も計測していないからです。異なる決定を下し、そのまま進むだけです。多くの人にとってはそれで十分です。データ容量に制限がある人にとっては、数字がないことが、内蔵された機能が行き詰まるポイントです。

トグルの下には、Low Data Modeはアドバイザリーフラグです。macOSはネットワークパスを制約されたものとしてマークし、それをNetwork Frameworkを通じてアプリケーションに公開します：パスはisConstrainedを報告し、NWParametersを使って制約されたパスを拒否するように接続を構成でき、URLSessionはリクエストごとのスイッチを提供して、開発者が特定の転送を高価なネットワーク上で実行しないと宣言できるようになっています。macOSはこのフラグを正直かつ一貫して設定します。行わないのはソケットの取り締まりです。

結果は直接的です。フラグを読まないアプリケーションは、それによって全く影響を受けません。カーネルレベルのゲートもなく、トラフィックシェーピングもなく、アプリがオプトインしていないリクエストを横取りするエンフォースメント層もありません。開発者がパスが制約されているかを確認する3行のコードを書かなかった場合、そのソフトウェアはメータリングされたホットスポット上でもギガビットのファイバー上でもまったく同じように動作します。

実際には、多くの実際に使われているソフトウェアがこれに該当します。Chromeのようなブラウザ、Dropboxのような同期クライアント、マルチギガバイトのイメージレイヤーをプルするDocker、パッチを適用するゲームランチャー、スケジュールされた実行を開始するサードパーティのバックアップエージェント、起動時にアップデートを確認するElectronアプリなどです。これらの多くはフラグを確認する義務はなく、いくつかは確認せず、どれもその結果を教えてくれません。AppleのサービスはAppleがそれらを書いたためにLow Data Modeを尊重します。その他は名誉システムに委ねられています。

これは怠慢ではなく、正当な設計上の選択です。アプリケーションだけが、どの転送が延期可能でどれが必須かを知っています。トラフィックを黙ってブロックするシステムは、診断が難しい形でソフトウェアを壊してしまいます。協調的なシグナリングは、皆が協力すれば、単純なブロッキングよりも良い動作をもたらします。

問題は、彼らが協力しないときに何が起こるかです。保証はあなたのマシン上で動作する各開発者に分散しており、あなたはそれぞれを個別に信頼しているため、結果を監査する方法がありません。失敗時の挙動もまた黙然としています：エラーも通知も、あなたが見るようなログへの出力もありません。あなたが気付くのはキャリアからのデータ使用に関する通知が来たときです。これこそがper-app enforcementが埋めるべきギャップであり、NetMuteのようなツールがネットワーク層で動作する理由です。

代替のアプローチは、アプリに振る舞いを求めるのをやめて、代わりに決定を下すことです。NetMuteはmacOS用のアプリごとのファイアウォールとトラフィックモニターで、ネットワーク層で施行します。つまり、アプリの協力は必要なく、その意見も考慮されません。ルールがアプリにネットワークアクセスを許可しないと定めた場合、そのアプリが開発者が制約されたパスAPIを知っていようといまいと、ネットワークアクセスは得られません。

これにより、Low Data Modeが構造的にできないいくつかのことが可能になります。アプリごとに日次または月次のデータ上限を設定したり、Mac全体のグローバル上限を設けたり、アプリが設定した閾値を超えたときに通知を受け取ったり、上限に達したときに自動的にブロックしたりできます。上限はネットワークプロファイルごとに保存されるため、ホットスポットでは厳しい上限を設定し、自宅では設定しないことも可能です。Wi-Fi SSIDに基づいてプロファイルは自動的に切り替わります。ホットスポット保護は、ネットワークにログインできる程度にアクセス可能でありながら、バックグラウンドのすべてのプロセスを解放しない必要があるキャプティブポータルのケースも扱います。

日常的な側面としては、リアルタイムのアプリごとのトラフィックモニターがあり、どのプロセスが何を送信しているかを正確に示し、ワンクリックでブロックや一時的なルールの自己期限切れ設定が可能です。これにより、永遠にではなく次の1時間だけ何かを沈黙させたい場合に対応します。Low Data Modeが答えられなかった質問、すなわちアプリに注意を促すかどうかではなく、実際に送信された量を示します。

結論として、これら二つの機能は競合するのではなく補完し合うものです。Low Data Modeをオンにします。コストはかからず、Appleが管理するトラフィックには効果的ですし、Apple自身のサービスはバックグラウンド使用の大きな割合を占めています。その上に施行を追加し、これに同意しなかったソフトウェアに対してもデータ使用量を制御します。これは、3年前に開発者が行ったアップデートチェッカーに関する決定に依存しないルールです。