macOS 49日間TCPバグ：Macの稼働時間を確認してネットワーク障害タイマーを回避する方法

macOSTahoe ·
macOS 49日間TCPバグ：Macの稼働時間を確認してネットワーク障害タイマーを回避する方法

macOS XNUカーネルのTCPバグを解説します。稼働時間が49.7日を超えると全ネットワーク接続が切断されます。Macの稼働時間を確認して自分を守る方法を学びましょう。

2026年初頭、Photonというハンドルネームで知られる独立系セキュリティ研究者が自身のブログ（photon.codes）に詳細な分析を公開し、macOSコミュニティに衝撃を与えました。AppleのXNUカーネルの深部に潜む不具合により、再起動なしで正確に49.7日間動作し続けたMacはすべての新規TCP接続が静かに切断されることが明らかになりました。警告ダイアログも、エラーメッセージも表示されません。Macがインターネット、ローカルネットワーク共有、TCPに依存するあらゆるものへの接続を単純に停止し、唯一の解決策は完全な再起動のみです。この発見はその後Tom's Hardwareでも報道され、TidBITSによって深く分析され、Reddit、MacRumorのフォーラム、Hacker Newsで議論され、数千件ものコメントと相当な懸念を生み出しました。本記事では、このバグを理解し、影響を受けているかどうかを判断し、すぐに自分を保護し、Appleがどのように対応しているかを理解するための包括的なガイドを提供します。

重要なポイント

  • macOS XNUカーネルの重大な整数オーバーフローバグにより、約49.7日（49日17時間2分47秒）の連続稼働後にすべての新規TCP接続が静かに失敗するようになります。
  • このバグはWi-Fiの切り替え、ネットワーク設定のリセット、個々のアプリケーションの再起動では解決できません。システム全体を再起動することでのみネットワーク接続が復元されます。
  • 最もリスクが高いユーザーは、Mac miniをサーバーとして使用している方、常時稼働の開発マシン、メディアサーバー、ホームオートメーションハブ、およびめったに再起動しないMacのユーザーです。
  • AppleはmacOS 26.5（現在beta 2）で修正をリリースする予定ですが、現在の本番リリースにはパッチが存在しません。
  • 簡単なTerminalコマンドで稼働時間を確認し、49日の閾値に達する前に定期的な再起動をスケジュールすることで、すぐに自分を守ることができます。

49日間TCPバグとは何ですか？

49日間TCPバグは、AppleのXNUカーネルにあるソフトウェアの欠陥です。XNUはmacOS、iOS、iPadOS、その他すべてのAppleプラットフォームを支えるコアオペレーティングシステムカーネルです。このバグはPhotonがXNUのソースコード（AppleがオープンソースとしてPublishしています）を注意深く分析する過程で発見されました。長時間稼働しているMacで謎のネットワーク障害のパターンを追跡した結果、カーネルのTCPスタック内の特定の比較操作に辿り着きました。

本質的に、このバグは整数オーバーフローです。XNUカーネルは32ビット符号なし整数（uint32_t）を使用してミリ秒単位でシステムの稼働時間を追跡する内部タイマーを維持しています。32ビット符号なし整数が保持できる最大値は4,294,967,295です。このミリ秒数を日数に変換すると、約49.71日になります。

4,294,967,295 milliseconds
= 4,294,967.295 seconds
= 71,582.788 minutes
= 1,193.046 hours
= 49.71 days

この閾値を超えると、タイマーの値は最大値からゼロにラップアラウンドします。これはコンピューティングでは珍しいことではありません。タイマーのラップアラウンドはよく理解された現象であり、堅牢なコードはこれを処理するように書かれています。しかし、XNUのTCPスタックにはこのラップアラウンドを正しく処理しない比較操作が含まれています。タイマーがオーバーフローすると、比較操作が誤った結果を生成し、カーネルはすべての新規TCP接続のタイミングパラメータが無効であると判断します。その結果、カーネルはすべての新規TCP接続の試みを静かにドロップします。

重要なのは、オーバーフロー前に確立された既存のTCP接続は（ハンドシェイクプロセスをすでに完了しているため）しばらくの間機能し続ける可能性がありますが、新しい接続、新しいWebページを開く、新しいSSHセッションを開始する、APIへの接続、電子メールの確認はすべて失敗することです。オーバーフロー後の短い期間で、既存の接続もタイムアウトして失敗し、MacはTCPを介して通信できない状態になります。

このバグはTCPプロトコル層に特に影響します。TCPに依存しない他のネットワークプロトコル（基本的なICMPピングなど）は引き続き機能する可能性があり、問題の診断が特に混乱を招くことがあります。Macはネットワークに「接続」されているように見え、ピングに応答することすらあるかもしれませんが、アプリケーションレベルのネットワーク通信はまったく機能しません。

XNUカーネルTCP整数オーバーフロー図

Macへの影響はどのようなものですか？

49日間TCPバグの実際の影響は、完全に一つの要因にかかっています。再起動の間隔でMacがどれだけ動作しているかです。少なくとも49日ごとにMacを再起動、リスタート、またはシャットダウンすれば、このバグに遭遇することはありません。タイマーはすべての起動時にゼロにリセットされます。

TidBITSがこの問題の分析で指摘したように、一般的なMacユーザーの大多数が影響を受ける可能性は低いです。Appleのソフトウェアアップデートは通常再起動を必要とし、多くのユーザーは少なくとも週に一度はMacをシャットダウンまたは再起動しています。これらのユーザーにとって、バグは本質的に見えません。

しかし、このバグが深刻な運用上のリスクとなるMacユーザーのカテゴリがあります。

Mac Miniサーバーとヘッドレスなマック

Mac miniはコンパクトで省エネなサーバーとしてますます人気が高まっています。ユーザーはMac miniをWebサーバー、CI/CDビルドサーバー、メディアサーバー（PlexやJellyfinを実行）、ホームオートメーションコントローラー、リモート開発マシンとして展開しています。これらのマシンは、再起動なしで継続的に動作するように特別に設計されています。1月にセットアップされて動作し続けるMac miniサーバーは2月下旬に49日目に到達し、警告なしにすべてのネットワーク接続を失います。

常時稼働の開発マシン

多くのソフトウェア開発者は、数十のターミナルセッション、開発サーバー、データベース接続、IDEウィンドウを開いたままにして、Macを継続的に動作させています。再起動はこの環境全体を再構築することを意味し、それには相当な時間がかかります。これらのユーザーは49日をはるかに超える稼働時間を積み重ねることがよくあります。

長時間のレンダリングジョブを抱えるクリエイティブプロフェッショナル

ビデオ編集者、3Dアーティスト、音楽プロデューサーは、数日または数週間にわたる長時間のレンダリングまたは処理ジョブを実行することがあります。彼らはこれらのジョブ中に再起動を避け、ジョブが既に相当の稼働時間があるマシンで開始される場合、レンダリングの途中で49日間の閾値を超える可能性があります。

エンタープライズおよび教育機関での展開

キオスクモード、デジタルサイネージ、ラボ環境、または共有ワークステーションにMacを展開する組織は、これらのマシンを無期限に動作させるように設定することがあります。Macのフリートを管理するIT管理者は、このバグに特に注意する必要があります。

ホームオートメーションとIoTハブMac

常時稼働のMacでHomeKitサーバー、Home Assistant、または他のホームオートメーションプラットフォームを実行しているユーザーはリスクにさらされています。ハブマシンのネットワーク障害は、スマートホームインフラ全体をダウンさせる可能性があります。

現在リスクにさらされているかどうかを確認する方法

最も簡単なテストは、Macの稼働時間を確認することです。稼働時間が49日に近づいているか、超えている場合は、再起動を計画する必要があります。次のセクションでは、確認方法を詳しく説明します。

Macの稼働時間を確認する方法

前回の再起動からMacがどれだけ動作しているかを確認する方法はいくつかあります。それぞれが若干異なる情報を提供し、すべて信頼できます。

方法1: uptimeターミナルコマンド

Terminal（アプリケーション > ユーティリティ > Terminal、またはSpotlightでCmd+Spaceを押して「Terminal」と入力）を開き、以下を入力します。

uptime

これにより、次のような出力が返されます。

10:32  up 43 days, 7:14, 2 users, load averages: 1.82 2.01 1.97

この例では、Macは43日と約7時間動作しています。このマシンは危険ゾーンに近づいており、数日以内に再起動する必要があります。

Terminalコマンドを効果的に使用するためのより詳細なガイドについては、Terminalマスタリーガイドをご覧ください。

方法2: system_profilerコマンド

より詳細な起動時間情報を取得するには、次のコマンドを使用します。

system_profiler SPSoftwareDataType

以下を含む出力が返されます。

Software:

    System Software Overview:

      System Version: macOS 26.4 (26E252)
      Kernel Version: Darwin 25.5.0
      Boot Volume: Macintosh HD
      ...
      Time since boot: 43 days, 7:14

「Time since boot」の行は、システムがどれだけの時間動作しているかを正確に示します。

方法3: sysctlで正確な起動時間を取得

Macが最後に起動した時期に関する最も正確な情報を取得するには、次のコマンドを使用します。

sysctl kern.boottime

以下が出力されます。

kern.boottime: { sec = 1709812345, usec = 0 } Mon Mar  7 14:32:25 2026

これにより最後の起動の正確な日時がわかり、49日間の閾値に到達する時期を正確に計算できます。

方法4: クイック計算スクリプト

49日目の時点を正確に教えてくれる簡単なスクリプトを作成できます。

#!/bin/bash
boot_time=$(sysctl -n kern.boottime | awk '{print $4}' | tr -d ',')
danger_time=$((boot_time + 4294967))
current_time=$(date +%s)
remaining=$((danger_time - current_time))

if [ $remaining -le 0 ]; then
    echo "WARNING: Your Mac has EXCEEDED the 49-day threshold!"
    echo "You should restart immediately."
else
    days=$((remaining / 86400))
    hours=$(((remaining % 86400) / 3600))
    echo "Days until 49-day TCP bug: ${days} days, ${hours} hours"
    echo "Danger date: $(date -r $danger_time)"
fi

これをcheck_tcp_bug.shとして保存し、chmod +x check_tcp_bug.shで実行可能にして、./check_tcp_bug.shで実行してください。

方法5: アクティビティモニタ

グラフィカルなアプローチを好む場合は、アクティビティモニタを使用できます。

  1. アクティビティモニタを開きます（アプリケーション > ユーティリティ > アクティビティモニタ、またはSpotlightで検索）
  2. 「CPU」タブをクリックします
  3. ウィンドウ下部の「システム稼働時間」を確認します（バージョンによっては「ウィンドウ」メニューからシステム情報を表示する必要があります）

アクティビティモニタとそのすべての機能に関する包括的なガイドについては、アクティビティモニタガイドをご覧ください。

バグの修正と予防方法

現在のmacOSの本番リリースにはソフトウェアパッチが存在しないため、49日間TCPバグの唯一の修正方法は閾値に達する前にMacを再起動することです。シンプルな手動再起動から完全自動化されたソリューションまで、いくつかのアプローチがあります。

即時修正：Macを再起動する

Macが現在ネットワーク障害を経験しており、49日以上動作している場合は、すぐに再起動してください。

  • Appleメニューから：左上のAppleロゴをクリックして「再起動...」を選択します
  • Terminalから：sudo shutdown -r nowを実行します
  • 強制再起動（Macが応答しない場合）：電源ボタンを10秒間押し続け、再度押して起動します

再起動後、すべてのネットワーク接続が直ちに回復します。稼働時間カウンターはゼロにリセットされ、バグが再発するまでの49日間を再び得ることができます。

予防策1：月次再起動のスケジュール

最もシンプルな予防策は、固定スケジュールでMacを再起動することです。月に一度で十分です。毎月最初の日（または任意の日）にMacを再起動するようにカレンダーリマインダーを設定してください。月次再起動によって稼働時間を49日間の危険な閾値をはるかに下回る状態に保ち、システムアップデートとメモリクリーンアップが定期的に行われるようにすることもできます。

予防策2：pmsetを使った自動再起動

macOSには自動再起動をスケジュールできるpmsetという組み込み電力管理ツールが含まれています。これが最もシンプルな自動化アプローチです。

# Schedule a restart every Sunday at 3:00 AM
sudo pmset repeat restart MTWRFSU 03:00:00

特定の曜日にスケジュールするには。

# Restart every Sunday at 4:00 AM
sudo pmset repeat restart U 04:00:00

スケジュールされた再起動を確認するには。

pmset -g sched

スケジュールされた再起動を削除するには。

sudo pmset repeat cancel

pmsetアプローチは、macOSの組み込み電力管理システムを使用し、ユーザーがログインしていない場合でも機能するため、ヘッドレスサーバーや常時稼働のMacに最適です。

予防策3：launchdを使った自動再起動

より高度な制御のために、特定のスケジュールで再起動をトリガーするlaunchdのplistを作成できます。このアプローチはpmsetよりも柔軟性があります。

/Library/LaunchDaemons/com.local.scheduled-restart.plistにファイルを作成します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.local.scheduled-restart</string>
    <key>ProgramArguments</key>
    <array>
        <string>/sbin/shutdown</string>
        <string>-r</string>
        <string>now</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Weekday</key>
        <integer>7</integer>
        <key>Hour</key>
        <integer>4</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>
    <key>RunAtLoad</key>
    <false/>
</dict>
</plist>

次のコマンドでロードします。

sudo launchctl load /Library/LaunchDaemons/com.local.scheduled-restart.plist

これにより、毎週日曜日の午前4時にMacが再起動されます。ニーズに合わせてWeekday、Hour、Minuteの値を調整できます。Weekdayの値は1（月曜日）から7（日曜日）です。

予防策4：稼働時間監視スクリプト

自動再起動ではなく閾値前に警告を受け取りたいユーザーには、稼働時間が40日に近づいた際に警告を発する監視スクリプトを設定できます。

#!/bin/bash
# Save as /usr/local/bin/uptime_monitor.sh

THRESHOLD_DAYS=40
UPTIME_SECONDS=$(( $(date +%s) - $(sysctl -n kern.boottime | awk '{print $4}' | tr -d ',') ))
UPTIME_DAYS=$(( UPTIME_SECONDS / 86400 ))

if [ $UPTIME_DAYS -ge $THRESHOLD_DAYS ]; then
    osascript -e "display notification \"Your Mac has been running for ${UPTIME_DAYS} days. Please restart soon to avoid the TCP bug.\" with title \"Uptime Warning\" subtitle \"49-Day TCP Bug Prevention\""
fi

このスクリプトを毎日実行するlaunchdのplistと組み合わせることで、再起動が必要な時にmacOSの通知を受け取ることができます。

予防策5：shutdownコマンドを直接使用する

すばやい一回限りの再起動スケジュールには、shutdownコマンドを使用できます。

# Restart in 30 minutes
sudo shutdown -r +30

# Restart at a specific time today
sudo shutdown -r 23:00

# Cancel a pending restart
sudo shutdown -c

これは、Macを積極的に使用しないとわかっている時間帯に再起動をスケジュールする場合に便利です。

Macがこの特定のバグを超えた広範なネットワーク問題を経験している場合、macOS Tahoe Wi-Fiトラブルシューティングガイドでは追加の診断と修正方法を紹介しています。

パッチは来ますか？

はい。Appleはこの問題を認識しており、macOS 26.5で修正がリリースされる予定です。執筆時点では、macOS 26.5は2番目のベータリリース（beta 2）の段階にあり、AppleのベータプログラムからDeveloperおよびパブリックベータテスターが利用できます。

現在の状況

  • macOS 26.4以前：すべての本番リリースにバグが存在します。49日前に再起動する以外の回避策はありません。
  • macOS 26.5 beta 1：初期ベータには修正が含まれていませんでした。
  • macOS 26.5 beta 2：ベータテスターからの報告によると、AppleはTCPスタックの根本的な整数オーバーフローに対処したようです。ただし、バグが発生するには49日間の稼働時間が必要なため、通常のベータテストを通じて修正を迅速に確認することは困難です。
  • 期待されるリリース：Appleの通常のベータサイクルに基づくと、macOS 26.5は2026年の晩春または初夏に一般提供される予定です。

なぜAppleはもっと早くパッチを出さなかったのですか？

いくつかの要因が遅延に寄与していると考えられます。

発見のタイミング：バグは2026年初頭に公開されました。PhotonのパブリックブログポストよりもAppleに責任ある開示チャンネルを通じて報告されていた可能性はありますが、カーネルレベルの修正を開発、テスト、リリースするためのタイムラインは数日ではなく数ヶ月単位で測られます。

カーネルレベルの複雑性：XNUカーネルはすべてのAppleプラットフォームの基盤です。TCPスタックの修正は、数百万のデバイスに影響する可能性のあるリグレッションを引き起こさないよう徹底的にテストされる必要があります。タイマー比較における整数オーバーフローの修正は、他のカーネルサブシステムと微妙な相互作用を持つ可能性があります。

テストの難しさ：バグを再現するには約50日間の継続稼働が必要なため、修正のテストは本質的に時間がかかります。Appleはおそらく自社のテスト環境で時間操作技術を使用して修正を確認し、その後、通常のTCP操作が壊れないことを確認する必要があります。

回避策が簡単：Appleのリスク評価の観点から、回避策（通常の再起動）はシンプルで非破壊的です。これにより、たとえばリモートコード実行の脆弱性と比較して、緊急性が低くなります。

macOSのアップデートと既知の問題に関する最新情報については、macOS Tahoeトラブルシューティングガイドをご覧ください。

技術的な深掘り：XNUカーネル整数オーバーフロー

このセクションは、コードレベルでこのバグがどのように、なぜ発生するかを技術的な観点から理解したい開発者、システム管理者、および関心のある方を対象としています。

オーバーフローの仕組み

XNUカーネルはティックカウンターを使用してシステムの稼働時間を追跡します。このカウンターはuint32_tデータ型を使用する変数に格納されており、0から4,294,967,295までの値を保持できる32ビット符号なし整数です。

カーネルはこのカウンターをミリ秒単位でインクリメントします。TCPスタックはこのカウンターを以下を含むさまざまなタイミング操作に使用します。

  • 再送タイマー：未確認パケットを再送する前の待機時間
  • 接続タイムアウト計算：接続試行が失敗したと見なす時期
  • キープアライブタイミング：アイドル接続で定期的なキープアライブプローブを送信する時期
  • タイムスタンプ比較：パケットヘッダーのTCPタイムスタンプオプションの検証

重大な欠陥は比較操作にあります。簡略化された疑似コードでは、問題のあるロジックは次のようになります。

// Simplified representation of the buggy comparison
uint32_t current_time = get_system_uptime_ms();
uint32_t connection_timestamp = tcp_header->timestamp;

// This comparison fails when current_time has wrapped around
if (current_time - connection_timestamp > MAX_ALLOWED_DELTA) {
    // Drop the connection as "too old" or "invalid"
    drop_packet();
}

システムが49.7日未満動作している場合、current_timeは単純に増加する値であり、比較は正しく機能します。しかし、current_timeが4,294,967,295を超えてオーバーフローし、小さな数値（例えば1,000）にラップアラウンドすると、current_time - connection_timestampの減算は符号なし整数のアンダーフローにより予想外に大きな結果を生成し、カーネルはすべての新規接続のタイミングデータを無効と解釈します。

なぜ発見されなかったのですか？

このタイプのバグは、いくつかの理由から悪名高いほど発見が難しいです。

1. 時間依存の再現：バグは49.7日後にのみ発生します。AppleのCI/CDパイプラインを含むほとんどの自動テストは、その期間にわたる個別のテストサイクルを実行しません。TCPスタックのユニットテストはさまざまな時間値での正確性をテストしていると思われますが、オーバーフロー境界を越える遷移を特別にテストしていない可能性があります。

2. コードは一見正しく見える：比較操作は構文的に有効であり、最初の49日間は正しく機能します。コードレビュアーがバグを発見するには、オーバーフローのケースを特別に考慮する必要があります。XNUのような大規模なコードベース（数百万行のコード）では、このような微妙な問題がレビューを通り抜けることは容易です。

3. 現代のMacは頻繁に再起動する：macOSのアップデートは通常再起動を必要とし、ほとんどのコンシューマー向けMacは十分な頻度で再起動されるためバグが発生しません。このパターンに気づかれるほどの露出をもたらしたのは、常時稼働のMacサーバー（特にMac mini）の増加する人口でした。

4. 誤解を招く症状：バグが発生すると、オペレーティングシステムのバグではなくネットワークインフラの問題のように見えます。ユーザー（経験豊富な管理者でさえも）は通常、Macのカーネルを疑う前にルーター、DNSサーバー、ISP接続、ネットワークスイッチを調査します。このバグに遭遇した多くのユーザーは、再起動自体が修正であることに気づかずにMacを再起動することで「修正」し、問題を他の原因に帰していた可能性があります。

正しい修正

CでのタイマーラップアラウンドのIのための適切な修正は確立されています。生のタイマー値を比較する代わりに、ラップアラウンドを正しく処理する符号付き算術演算を使用して比較を行う必要があります。

// Correct wraparound-safe comparison
// Cast the difference to a signed type
int32_t time_delta = (int32_t)(current_time - connection_timestamp);

if (time_delta > MAX_ALLOWED_DELTA || time_delta < 0) {
    drop_packet();
}

あるいは、カーネルは64ビットタイマー（uint64_t）を使用することもできます。これは約5億8400万年間オーバーフローしないため、オーバーフローの懸念を実質的に排除します。ただし、タイマーの幅を変更するとカーネル全体に広範な影響があり、より大規模な変更とテストが必要になります。

TCP接続のタイムラインとオーバーフローポイント

他のAppleプラットフォームはどうですか？

XNUはすべてのAppleプラットフォーム（macOS、iOS、iPadOS、watchOS、tvOS、visionOS）の共有カーネルであるため、iPhoneやiPadも影響を受けるかどうかという疑問が自然に生じます。

理論的には、同じ脆弱なコードがすべてのAppleプラットフォームに存在します。実際には、iOSとiPadOSデバイスはMacよりもはるかに頻繁に再起動されます。システムのアップデート、バッテリーの消耗、通常の使用パターンにより、iPhoneが49日間継続して稼働し続けることはほとんどありません。Apple WatchとApple TVデバイスも同様に定期的に再起動される傾向があります。ただし、iPadが何らかの形で50日間再起動なしに継続して動作していた場合、理論的には同じバグの影響を受けます。

歴史的背景：これが初めてではありません

macOSの49日間TCPバグには、古いコンピューティングの熟練者がすぐに気づく印象的な歴史的先例があります。1990年代の悪名高いWindows 49日バグです。

Windowsの49.7日バグ

Microsoft Windows 95、Windows 98、Windows MEはいずれも、ほぼ同一のバグを含んでいました。Windowsカーネル関数GetTickCount()は、システム起動からのミリ秒数を表すDWORD（32ビット符号なし整数）を返していました。49.7日後、この値はオーバーフローしてゼロにラップアラウンドしました。

Windowsでの結果は、現在のmacOSのバグよりも深刻だったと言えるかもしれません。Windows 95では、オーバーフローによって以下が引き起こされる可能性がありました。

  • システム全体のフリーズとクラッシュ（ブルースクリーンオブデス）
  • アプリケーションのハングとデータ破損
  • 再起動を必要とする完全なシステムの不安定性

Windowsのバグは1990年代後半に広く知られ、広く文書化されていました。これは、整数オーバーフローを慎重に処理しなければならない理由についてのプログラミング教科書の標準的な例となりました。Microsoftは最終的にWindows Vista（2007年）でGetTickCount64()を導入し、64ビットカウンターを使用することで約5億8400万年間オーバーフローしないようにしました。

皮肉な一致

AppleがWindowsで広く文書化された問題から約30年後に、本質的に同じ種類のバグ（32ビットミリ秒タイマーオーバーフロー）をリリースしたという皮肉は、開発者コミュニティに気づかれていません。macOSのバグに関するHacker Newsの議論はしばしばWindowsの先例を参照しており、よく知られたエラーのクラスが現代のオペレーティングシステムカーネルに入り込めることへの驚きを表明するコメントが多くあります。

ただし、XNUカーネルは数十年分の蓄積されたコードを持つ膨大で複雑なコードベースであることを指摘する価値があります。バグを含む特定の比較操作は、ずっと昔（おそらくNeXTSTEP時代またはOS Xの初期の頃）に書かれ、最近のMacを常時稼働のサーバーとして動作させるというトレンドが生まれるまで、欠陥を露わにする条件下で実行されることがなかっただけかもしれません。

コンピューティングの歴史における他の注目すべきタイマーオーバーフローバグ

49日間のオーバーフローはコンピューティングの歴史全体にわたるタイマー関連のバグのより広いパターンの一部です。

  • ボーイング787ドリームライナー（2015年）：FAAは、発電機制御ユニットの32ビットタイマーオーバーフローによる完全な電力喪失を防ぐため、ボーイング787航空機を248日ごとに電源サイクルするよう求める耐空性指令を発行しました。
  • PlayStation 3うるう年バグ（2010年）：PS3の内部クロックの計算ミスにより、システムが日付を2010年2月29日（存在しない日付）と誤認し、世界中のコンソールが24時間停止しました。
  • マーズパスファインダー（1997年）：厳密にはタイマーオーバーフローではありませんが、パスファインダーの優先順位逆転バグは、ローバーが火星で運用された後に現場で発見され、時間依存のバグが広範な展開前テストを回避できることを実証しました。
  • Y2K（2000年）：2桁の年表現が世紀の境界で広範な障害を引き起こす脅威となった、コンピューティングの歴史上最も有名な日時計算バグです。

これらの例は一貫したテーマを示しています。時間関連のバグはコンピューティングで最も陰険なバグの一つであり、極端な時間の長さや境界条件を特別に考慮しないテストを回避できます。

トラブルシューティング：Macがバグに当たったサインを確認する

MacがTCPの49日バグに当たった可能性がある場合、探すべき具体的な症状と、このバグを他のネットワーク問題と区別する方法を以下に示します。

主な症状

1. すべての新規TCP接続が同時に失敗する

これは特徴的な症状です。1つのアプリケーションや1つのWebサイトではなく、TCPを使用するすべてのものが失敗します。

  • Webブラウザはすべてのページをロードできない（Safari、Chrome、Firefox、すべてが失敗）
  • メールクライアントがメールサーバーに接続できない
  • SSHセッションがタイムアウトする
  • iMessageとFaceTimeが動作しなくなる
  • iCloudの同期が停止する
  • App Storeが接続できない
  • ファイル共有とAirDropが失敗する可能性がある
  • Homebrew、npm、pipおよびその他のパッケージマネージャーが何もダウンロードできない

2. Wi-FiまたはEthernetが接続済みと表示される

Macのメニューバーに接続済みのWi-Fi信号またはEthernet接続が引き続き表示されます。ネットワークインターフェイスはレイヤー1とレイヤー2（物理層とデータリンク層）で機能しており、壊れているのはレイヤー4（トランスポート/TCP）だけです。

3. ピングはまだ機能する可能性がある

ICMPピングはTCPを使用しないため、外部ホストへのピングが成功する可能性があります。

ping google.com

ピングは機能するがWebブラウザやアプリケーションが機能しない場合、これは一般的なネットワークやDNSの問題ではなくTCPバグの強いシグナルです。

4. DNS解決はまだ機能する可能性がある

UDPを使用するDNSクエリ（ほとんどのDNS検索のデフォルト）は引き続き機能する可能性があります。

nslookup google.com

DNSは解決するがTCP接続が失敗する場合、TCPバグが原因の可能性が高いです。

5. 稼働時間が49日以上

前のセクションで説明したように稼働時間を確認してください。稼働時間が49日以上で上記の症状が発生している場合、バグがほぼ確実に原因です。

他のネットワーク問題との区別方法

49日間TCPバグはいくつかの他の一般的なネットワーク問題と混同される可能性があります。以下に区別する方法を示します。

症状TCPバグWi-Fi問題DNS問題ファイアウォールブロックISP障害
すべてのTCP接続が失敗はい可能性ありいいえ可能性あり可能性あり
ピングが機能するはいいいえはい可能性ありいいえ
DNSが解決するはいいいえいいえはい可能性あり
Wi-Fiが接続済みと表示はいいいえはいはいはい
稼働時間 > 49日はい関係なし関係なし関係なし関係なし
他のデバイスが影響を受けるいいえ場合により場合によりいいえはい
再起動で修正されるはい場合によりいいえいいえいいえ

最も決定的なテストは、稼働時間が49日以上、すべてのTCP接続の失敗、ピングが機能する、再起動で問題が修正されるという組み合わせです。4つの条件がすべて満たされる場合、バグに遭遇しています。

他の原因を排除するのに役立つWi-Fi固有のトラブルシューティングについては、macOS Tahoe Wi-Fiトラブルシューティングガイドをご覧ください。

ネットワーク診断コマンド

Terminalでこれらのコマンドを実行して診断情報を収集します。

# Check uptime
uptime

# Test TCP connection to a known-good server
nc -zv google.com 443

# Test DNS resolution
nslookup apple.com

# Test ICMP connectivity
ping -c 4 8.8.8.8

# Check network interfaces
ifconfig | grep "status"

# View active TCP connections
netstat -an | grep ESTABLISHED | head -20

# Check for TCP connection errors
netstat -s | grep -i "error\|fail\|drop\|overflow"

nc -zv google.com 443が失敗（接続タイムアウト）するがping -c 4 8.8.8.8が成功する場合、かつ稼働時間が49日以上の場合、TCPバグの強力な証拠があります。

Macがネットワーク問題と一緒にフリーズやパフォーマンスの問題も経験している場合、macOS Tahoeフリーズ修正ガイドが追加の役立つ背景を提供してくれるかもしれません。

バグを確認したときの対処方法

  1. 開いているアプリケーションの未保存の作業を保存する
  2. アクティブなファイル操作がある（データベース、ビデオエンコーディングなど）アプリケーションを正常に閉じる
  3. sudo shutdown -r nowまたはAppleメニューを使用してMacを再起動する
  4. 再起動後、WebページをロードしてCounterがリセットされたことを確認するためにuptimeを実行して接続を確認する
  5. バグに再び遭遇しないように、上記セクションの予防策を実装する

よくある質問

私のMacは49日間TCPバグの影響を受けていますか？

macOSを実行しているすべてのMacが、ハードウェアモデル、プロセッサの種類、macOSバージョンに関係なく、潜在的に影響を受けます。バグはXNUカーネルに存在し、XNUカーネルはすべてのmacOSインストールの基盤です。ただし、再起動なしでMacが49.7日を超えて継続的に動作する場合にのみバグが発生します。手動でもシステムアップデートを通じてでも、少なくとも月に一度Macを再起動すれば、このバグに遭遇することはありません。

バグを避けるためにどのくらいの頻度でMacを再起動すべきですか？

30日ごとに再起動すると、49.7日間の閾値を快適に下回る安全マージンが確保されます。ミッションクリティカルなサーバーMacの場合、週に一度の再起動（理想的にはオフピーク時間帯に）でさらに大きな安全マージンが得られます。予防セクションで説明したpmset、launchd、またはスケジュールされたshutdown -rコマンドを使用してこれを自動化できます。より頻繁に再起動することに不利はありません。実際、定期的な再起動はメモリリークのクリア、保留中のアップデートの適用、および全体的なシステムの健全性の維持に役立ちます。

Appleはこのバグを修正しますか？

はい、AppleはmacOS 26.5でバグを修正する予定で、2026年4月現在beta 2の段階です。Appleの通常のベータサイクルに基づくと、公開リリースは2026年の晩春または初夏に期待されています。修正には、XNUカーネルのTCPスタックの整数比較を修正して32ビットタイマーのラップアラウンドを正しく処理すること、またはタイマーを64ビット整数にアップグレードすることが含まれる可能性があります。修正が本番リリースに含まれるまで、唯一の軽減策は49日間の稼働時間閾値に達する前にMacを再起動することです。

このバグはApple SiliconとIntel Macの両方に影響しますか？

はい。バグはXNUカーネルのTCPスタックにあり、これはApple Silicon（M1、M2、M3、M4、M5シリーズ）とIntelプロセッサの両方で動作するアーキテクチャに依存しないコードです。整数オーバーフローは、基礎となるハードウェアアーキテクチャに関係なく同じ方法で発生します。Intelプロセッサを搭載した2015年のMacBook Proでも、M5 Ultraを搭載した2026年のMac Studioでも、バグの動作は同じです。

Macの稼働時間をリモートで確認できますか？

はい、MacへのSSHアクセスがある場合（システム設定 > 一般 > 共有 > リモートログインで有効化）、稼働時間をリモートで確認できます。

ssh username@your-mac-ip "uptime"

複数のMacを管理するには、すべてのマシンの稼働時間を確認するスクリプトを作成できます。

#!/bin/bash
# check_all_macs.sh
MACS=("mac1.local" "mac2.local" "mac3.local")

for mac in "${MACS[@]}"; do
    echo "--- $mac ---"
    ssh user@$mac "uptime" 2>/dev/null || echo "  Connection failed"
done

Apple Remote Desktop（ARD）またはモバイルデバイス管理（MDM）ソリューションを使用して、管理されているMacのフリートの稼働時間を監視することもできます。

ネットワークドライブやNASデバイスに接続するMacを管理している場合、49日バグはSMBファイル共有接続も中断させる可能性があります。関連するネットワークストレージのトラブルシューティングについては、macOS Tahoe SMB/NASトラブルシューティングガイドをご覧ください。

まとめ

macOSの49日間TCPバグは、微妙な整数オーバーフロー（ソフトウェアバグの最も古く、最もよく文書化されているクラスの一つ）が、常時稼働のMacサーバー設定を採用するユーザーが増えるにつれて、現代の成熟したオペレーティングシステムカーネルで何年も検出されずに存続し得ることを示す魅力的なケーススタディです。

ほとんどのMacユーザーにとって、このバグは日常のコンピューティングに影響を与えることのない興味深い技術的なトピックです。しかし、Macをサーバー、開発マシン、常時稼働インフラとして使用している成長するコミュニティにとっては、注意と軽減策が必要な本物の運用上のリスクです。

良いニュースは、軽減策が簡単だということです。稼働時間を確認し、49日前に再起動し、できればプロセスを自動化して二度と考えなくて済むようにしましょう。そして、macOS 26.5が間近に迫っており、永続的な修正が手の届くところにあります。

その間は、最も洗練されて信頼性の高いコンピューティングプラットフォームでさえ人間によって作られており、人間が書いたコードは決して完璧ではないという優れたリマインダーとして考えてください。定期的な再起動は単なる怠惰なITサポートの決まり文句ではなく、まさにこの種の潜在的な欠陥から保護するための真のベストプラクティスです。

関連リソース

TCPバグと一緒に他のmacOS Tahoeの問題をトラブルシューティングしている場合、これらのガイドが役立つかもしれません。