MacをキャッシュサーバーにしてAppleサーバーを切り離した話

183.67GBを93.3%ローカル化、OTA配信でボトルネックを突破した技術検証ログ

「有線で繋げば速い」という思い込みが、最大のボトルネックを生んでいた。

検証環境

・配信サーバー：MacBook Air M3（メモリ24GB / 13インチ）
・ネットワーク：ahamo光 10Gbps（IPoE / IPv4 over IPv6）
・インフラ配線：Cat.6A（10Gbps対応）
・検証規模：数百台規模・40台同時接続の限界を検証

何が詰まったのか

当初は「要塞」のような有線キッティング環境を構築した。電源系とデータ系を完全に分離し、Anker 100W PD充電器を用いて各ハブに独立給電するVer.4.4構成だ。

しかし、40台を同時接続した瞬間に「動脈硬化」が起きた。1台あたりの速度が極端に低下し、パケットロスが頻発。残り時間が「3日」と表示された端末が続出した。

真犯人はUSB-LANアダプタだった。

MacBook AirにはLANポートがない。そのため1Gbps対応のアダプタを介してルーターに接続していたが、これが数百台の通信を捌く際の「出口」を絞り込んでいた。Cat.6Aの10Gbpsインフラが、わずか1本のアダプタによって完全に殺されていた。
なぜ最初から10Gbps対応アダプタを使わなかったのか。理由は2つあった。

1つ目、発熱リスクへの警戒。10Gbps対応アダプタはフル稼働時に発熱する。熱暴走で通信が途切れるより、1Gbpsで安定完走させる方が事故が少ないと判断した。

2つ目、iPad側を過信した。1台あたり数百Mbpsがせいぜいだから、44台繋いでもハブ側が先に限界に来る。1Gbpsのアップリンクで十分だと計算した。

どちらも机上の判断だった。183GBの濁流の前で、その計算は崩れた

Macをキャッシュサーバーにした理由

有線教条主義を捨て、macOS標準の「コンテンツキャッシュ」機能を採用した。一度Appleから取得したアップデートデータをMac内に蓄積し、2台目以降にはローカルネットワーク経由で配信する仕組みだ。

【通常のOTA】
各端末 → インターネット → Appleサーバー

【キャッシュサーバー構成】
各端末 → MacBook Air M3（ローカルキャッシュ）
初回だけAppleから取得して蓄積

設定で効いた4つのポイント

① コンテンツキャッシュの有効化
システム設定 → 一般 → 共有 →「コンテンツキャッシュ」をON

② ストレージの無制限化
デフォルトの制限のままだと183GBのキャッシュが途中で削除されるリスクがある。オプションから「無制限」に設定し、SSD内に物理的にロックした。

③ インターネット共有のオフ
オンのままだとMacがルーター（NAT/DHCP）として動作し、CPUとメモリが消費される。オフにすることでデータ配信に専念させた。

④ MTU=1454の調整
OCNバーチャルコネクト環境では、IPv4パケットをIPv6でカプセル化する際のオーバーヘッドが発生する。MTU=1500のまま運用したところ、断片化・不安定化を観測したため1454へ調整した。

# Mac
sudo networksetup -setMTU Wi-Fi 1454

# Windows
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1454 store=persistent

現場で判明した「5つの地層」

今回のアップデートはiPadOS 26.4.0→26.4.1という「0.0.1」のマイナー更新だった。かつてのマイナーアップデートは数百MBで済んでいた。しかし今回、標準層で5.16GB・重量層で5.35GBという想定外のデータ量が配信された。原因は不明だが、フルサイズに近いデータが送られてきた。これがキャッシュサーバーを必要とした直接の理由だ。

同じOSバージョンへのアップデートでも、製造ロットによって5種類の異なる挙動があることを現場で特定した。

• 軽量層（約1GB）：出荷時OSが最新に近い個体

• 標準層（5.16GB）：最も多いロット

• 重量層（5.35GB）：初期ロット・修正項目が多い

• 中量層・正常（4.56GB）：アイコンが「iPadOS」と表示

• 中量層・特殊（4.56GB）：アイコンが「歯車」・表示が「iOS」

「歯車アイコン」「iOS表記」への対処：ソフトウェアアップデート画面を下に引っ張って更新（プルリフレッシュ）すると、アイコンと表示が正しいメタデータに切り替わることを確認した。

これらのデータがキャッシュサーバーなしで外部へ流れていれば、回線は完全にパンクしていた。実際、外部通信は13.27GBに抑えられた。93.3%のローカル化がこれを可能にした。

eSIM「不明」問題のメカニズムと解決

作業中、一部の端末で電話番号が「不明」のまま更新されない事象に直面した。

iOSの内部プロセス

CommCenter → キャリアと通信して電話番号を取得

CoreTelephony → 取得した番号をデータベースに書き込む

Settings → データベースの内容を画面に表示

アンテナピクトが立つ前に設定画面を開くと、UIに「空っぽ」というステータスがキャッシュされてしまう。その後、CommCenterが番号を取得しても、画面の更新トリガーが発火しない。現場観測上、UIキャッシュまたは非同期更新由来と思われるRace Condition的挙動と判断した。

AppleもキャリアもこのメカニズムについてRace Conditionの公式見解を出していない。「再起動してください」がすべてだ。

現場で導き出した手順：「アンテナピクトが完全に立ってから設定画面を開く」

この手順を徹底することで、不明表示の発生率を大幅に抑制できた。ただし根本原因は閉鎖環境での電波不足にある。電波状況が安定しない環境では完全な解決とは言い切れない。

地下という「電波の牢獄」で、iPhoneのアクティベーションに必要なセルラー回線をどう確保するか。その検証は続編で記録する。

続編はこちら：1%〜4%の確率で起きる。iPhoneのeSIM「電話番号不明」問題

結果

ボトルネックを1つずつ、叩き伏せる。

• 完遂率：99.6%

• キャッシュ配信量（ローカル）：183.67GB

• 外部通信量（Appleサーバー）：13.27GB

• ローカル化率：93.3%

同時接続が15台を超えた瞬間、アクティビティモニタのキャッシュ圧力が赤くなり、配信速度が112.5MB/sから2.1MB/sまで急落した。この限界点を把握し、最適な同時接続を10台前後に絞る判断を下した。

途中でエラーが出た端末は、アップデートデータを削除して再試行した。残り時間が「3日」と表示されていた端末が「数分」に戻った。迷う時間より、消して再試行する方が早かった。

ラスト2台で発生した署名エラーについては、深追いせずキャリア交換へ切り離した。「技術的撤退」もインフラを制するための判断だ。100%を目指して全体を止めるより、99.6%で流す判断の方が、現場では正解になる。

なぜ最初から10Gbps対応アダプタを使わなかったのか。発熱リスクへの警戒と、iPad側のボトルネックを過信した机上の計算だった。

183GBの濁流の前で、その計算は崩れた。

ボトルネックは、現場でしか見えない。

次の現場のためのチェックリスト

□ MTU=1454 に設定する（OCN IPoE環境は必須）
□ コンテンツキャッシュをONにして
　 1台目でデータを蓄積してから量産に入る
□ インターネット共有をオフにする
□ ストレージを無制限に設定する
□ 同時接続は10台前後でキャッシュ圧力を監視する
□ eSIMはアンテナピクトが立ってから設定画面を開く
□ ゾンビ端末はデータ削除→再試行が最速
□ 有線でやるなら USB-LANアダプタは10Gbps対応品が必須
　（ただし管理コストを考えればOTA×キャッシュが至高）

本記事は当時の現場記録。文中の数値はすべて実測値に基づく。その後のOSアップデートにより、状況が変わっている場合がある。