Appleデバイスは49.7日を超えて使い続けることはできない。そういう呪いがかかっている。32ビット整数の時間カウンターが最大になってストップすることにより、新たなTCP通信が確立できなくなるのだ。
ただし、再起動すればカウンターはリセットされる。そのため重大なバグというわけではない。しかし、なぜこのような問題が残り続けているのだろうか。
ポチップ
米国のスタートアップ企業が発見したMacのバグ
Appleデバイスには、49.7日の呪いがかかっている。正確には起動してから49日17時間2分47秒後、新たなTCP接続が確立できなくなる。そうなるとWebは表示できなくなり、メールも送受信できない。iCloudの同期もできず、AirDropさえ使えなくなる。
一見正常に動いているように見えても、あらゆる通信ができなくなってしまうのだ。ただし、あまり過度に恐れることはない。再起動すれば元に戻るからだ。
このバグは、米国のスタートアップ「Photon」が発見した。Photonでは、iMessageの挙動を監視するためにMacを24時間365日稼働し続けている。ところが、今年2026年3月30日に、1台のMacが新たなTCP接続を確立できなくなった。そこで調べてみるとこのバグが発見され、ブログで発表した。
ポチップ
現AppleのOSの源流にあるMach（マッハ）、そしてDarwin
（ダーウィン）
いったい何が起きているのか。macOSなどがUNIXベースであることは、みなさんもよくご存じだろう。Appleから追放された創業者のスティーブ・ジョブズ氏は、ワークステーション「NeXT」を開発するために、1985年にNeXTを創業した。
ここでOSのベースとして採用したのが、カーネギーメロン大学が開発したUNIXの一系統「Mach」（マッハ）である。UNIXは優れたOSだったが、大きくなりすぎた。そこで、基本機能に絞り、部品同士がメッセージをやり取りすることで動く先進的な設計につくり変えた。それがMachだ。
この考え方は、現在のAppleデバイスにも受け継がれるさまざまな利点をもたらした。各部品が独立して動くため、OSがクラッシュしづらい。ある部品に問題が生じても、それが他の部品にまで影響することがないからだ。現在のmacOSやiOSなどで、システムがクラッシュして再起動を強制されることは稀になっている。
また、スレッド（処理単位）の管理がしやすくなるため、滑らかに動作する。iOSはタップ関連の処理を優先するため、iPhoneのタッチ操作は非常に機敏に感じられる。適切なスレッドを優先することで、滑らかな使用感を実現しているわけだ。
MachをベースにしたNeXTSTEPは先進的なOSだったが、1996年にAppleによって買収され、macOS Xの開発が始まった。しかし、ここで問題が発生する。Machが内部で頻繁にメッセージをやり取りするため、当時の非力なMacでは全体の動作速度が遅くなってしまうのだ。
そこで、AppleはBSD（カリフォルニア大学バークレー校が開発したUNIXの一バージョン）とMachを合成することにした。
このハイブリッドカーネルをXNU（X is Not UNIX）カーネルと呼び、さらに標準ライブラリなどの追加を行い、これをDarwin（ダーウィン）と名付けた。このDarwinがAppleデバイスのOSのすべての元になっている。macOSだけでなく、iOS、iPadOS、watchOSなど、AppleのOSはすべてDarwinがベースだ。
ポチップ
Web、メール、iCloud利用時のTCP通信を支える「tcp_now」変数
さて、このXNUカーネルのBSD部分にtcp_nowという32ビット整数の変数がある。起動してから1ミリ秒ずつ増えていき、0から2³²-1までの値を取ることが可能だ。
これは、TCP通信の時間カウンターの役割をしている。Webやメール、iCloudなどのほとんどがTCP通信だ。TCP通信では、データはパケットと呼ばれる小さな単位に小分けして送られる。
各パケットは、そのときに混雑していない経路を通じて送られるため、複数のパケットが送った順に相手に到着するとは限らない。そこで、tcp_nowの数値を参照して各パケットには送信した時刻が記録される。受け取った側は、パケットがバラバラに届いたとしても、送信時刻を見れば、どの順番でデータを復元すればいいのかがわかるわけだ。
ところが、tcp_nowは最大2³²-1=42億9496万7295までの値しか取ることができない。つまり42億9496万7295ミリ秒＝49.710269618日になると、最大値のまま更新ができなくなってしまう。いわゆるカンスト（カウンターストップ）だ。
このtcp_nowがカンストしてしまうと、TCP接続に大きな影響を与える。
ポチップ
Macの寿命49.7日。それを決めるのは「tcp_now」のカンスト
macOSは、メモリ資源により数千から数万のTCP接続ができるようになっている（ターミナルで「sysctl kern.maxfiles」と入力すると、同時に接続できるTCP接続の最大値が表示される）。
macOSはTCP接続を大量に行うため、数万接続が利用できても、すぐに枯渇してしまう。そこで、使わなくなった接続は閉じなければならない。ここで思い出してほしいのだが、TCP接続はパケットがバラバラに届くため、どれが最後のパケットなのかは知りようがない。そこで、30秒待っても新たなパケットが届かないと、その接続は不要だとみなして閉じるようになっている。この30秒を測るのに、tcp_nowの数値を使っているのだ。
tcp_nowがカンストしていると、待ち時間のカウンターが増えなくなる。つまり、カウンター上はいつまで経っても30秒経つことがなく、接続が確立したままになる。いずれ資源が枯渇し、新たなTCP接続を確立することができなくなるというわけだ。
なお、再起動をすればtcp_nowの値は０に戻るため、また49.7日間は問題なく使える。
ポチップ
過去Windowsにも存在したがほぼ気付かれなかった49.7日の寿命
実は、Windows 95／98も似たようなバグを抱えていた。起動してから49.7日経つと、Windowsがフリーズしてブルースクリーンが表示されるという致命的なバグだ。
しかし、あまり大きな問題にはならなかった。なぜなら当時のWindowsは不安定で、アプリケーションがフリーズすることが多く、1日に1回ぐらいは再起動するのが普通だったからだ。49.7日も再起動なしというのは当時のWindowsの世界では奇跡のような出来事であり、このバグによるシステムクラッシュに遭遇することは稀だった。何が幸いするかわからないものだ。
また、当時は仕事が終わるとシステム終了するのが一般的で、今日のようにスリープしたままにするという習慣がなかったことも幸運だった。
一方Macも、49.7日間にわたって再起動なしに使うのは難しい。だいたい月に1回ぐらいはアップデートがあり、再起動のきっかけとなるからだ。iPhoneも、アップデートなどでけっこう再起動されている。
iPhoneが急に通信しなくなったが再起動したら治った、という経験を持つ方もいるだろう。ひょっとしたら、その不具合は「49.7日問題」によるものかもしれない。
ポチップ
Mac miniをAIエージェント化。ここでも49.7日がネックに
このバグのもっとも重要な点は「再起動をすれば治る」という点だ。そのため、致命的なバグとも言えない。しかし、Mac miniでは大きな問題になる可能性がある。AIエージェント「OpenClaw」が爆発的人気を呼び、24時間365日AIエージェントを動かし、さまざまなことに利用する人が増えている。このAIエージェントを動かすのに、省電力でコンパクトなMac miniが適しているということから、在庫がなくなるほどの人気だ。
Mac miniでAIエージェントを動かした場合は、49.7日の問題が発生する可能性がある。月に1回ぐらいはメンテナンス日を決めて、再起動をかけるようにしたほうがいいかもしれない。
Appleは、このXNUカーネルのバグを修正するだろうか。やっかいな問題なので修正すべきだが、再起動するだけで対処できるということから、修正すべき優先度はあまり高くないと思われる。また、修正は簡単だが、その影響が及ぶ範囲をすべてテストしなければならないため、修正作業は意外に大掛かりになる。
修正の方法は2つある。ひとつは、32ビット整数であるカウンターを64ビット整数に拡張してしまうことだ。64ビット整数では、カウンターの上限が2⁶⁴-1となるため、Macを起動して5.8億年後にこの症状が現れるようになる。問題を先送りしただけだが、5.8億年の先送りなら問題ないはずだ。
しかし、ひとつの変数を64ビット整数に修正した場合、それを参照しているさまざまな部分がきちんと動作するのか検証する必要がある。カーネルの修正であるだけに、その検証すべき範囲は広大だ。
もうひとつは、モジュラ演算を組み込むことだ。カウンターが最大値になってしまったら、0に戻すようにすればいい。自動車のトリップメーターやデジタル時計の表示と同じように、ぐるぐる回るようにすればいいわけだ。tcp_nowのようにタイムスタンプに使った場合、大小（後先）の比較が難しくなるように思う人もいるかもしれないが、実用上はほぼ問題ない。
ポチップ
解消されるかどうかは不明。Appleユーザなら覚えておきたい49.7日の呪い
私たちは、当然のように西暦年号を下2桁で表す。それでも、98年と24年のどちらが先でどちらがあとかは迷わない。２つの数の差が最大値の半分より大きいか小さいかを見ればいいだけだからだ。98-24=74となるが、これは最大値99の半分より大きいので、98のほうが小さく（先）、24のほうが大きい（後）と判定できる。
しかし、この修正も影響がさまざまなところに及ぶため、簡単な修正というわけにはいかない。Appleはこのバグをいつ修正するだろうか。ここのところ、Appleは毎月のようにアップデータを公開しているが、ひょっとして、このバグの影響が出ないようにするという目的もあるのかもしれない。
大きな問題ではないので気にすることはないとは思うが、Appleデバイスには49.7日の呪いがかかっている。この事実は頭の片隅に入れておいた方がいいかもしれない。
ポチップ
おすすめの記事
著者プロフィール
牧野武文
フリーライター／ITジャーナリスト。ITビジネスやテクノロジーについて、消費者や生活者の視点からやさしく解説することに定評がある。IT関連書を中心に「玩具」「ゲーム」「文学」など、さまざまなジャンルの書籍を幅広く執筆。
