同じmacOSなのにファームウェアが違う：Sequoia／Sonomaアップデートに対するAppleの静かな変更

Sequoia 15.7.9を実行する2台のMacが、更新のタイミング次第で異なるmBootファームウェアを持つ状態になっています。Appleはビルド番号を変えずにアップデートの中身を変更しました。自分のMacを確認する方法を解説します。

2台のMacを用意します。どちらもmacOS Sequoia 15.7.9を実行しており、「このMacについて」で表示されるビルド番号も同じです。片方は2026年8月7日に、もう片方は8月28日にアップデートしました。それぞれでシステム情報を開き、「System Firmware Version」を確認すると、前者は18000.161.9、後者は18000.161.10と表示されます。

Appleのリリースノートにはこれを説明する記述が一切ありません。15.7.9アップデートに新しいビルド番号が付与されたわけでもなく、セキュリティノートが改訂されたわけでもありません。Appleは8月17日以降のどこかの時点で、同じ名前のアップデートの中身として異なるファームウェアを配布し始めただけであり、この事実が知られているのはHoward Oakleyがまさにこの種の比較のために仮想マシンを維持しており、数値が変化していることに気づいたからにほかなりません。

この記事では、あなたのMacが本来持つべきファームウェアバージョン、その確認方法、なぜこの番号がmacOSバージョンと連動しなくなったのか、そして（もしあるとすれば）何をすべきかを解説します。

重要なポイント

Sequoia 15.7.9またはSonoma 14.8.9を実行するApple silicon Macは、mBoot 18000.161.9と18000.161.10のどちらかを持つ可能性があります。これは2026年8月17日より前にアップデートしたか後にアップデートしたかによって決まり、いずれの場合もmacOSのビルド番号は同一です。
18000.161.10は、8月17日にTahoe 26.6.2のみで配布されたファームウェアです。Appleはその後、何も告知することなく、これをビルドが変わらないSequoiaおよびSonomaのアップデートにも含め始めました。
macOS 26.4以降、Apple siliconのファームウェアは自らを「mBoot」と名乗るようになり、iBootという名称は使われなくなりました。番号体系も13822.x系列から18000.x系列へと飛躍しています。私たち自身のMacでもこの表記を確認しており、ブートファームウェアは文字通りmBoot-18000.121.3と自己申告します。
macOSバージョンからファームウェアバージョンを確実に導き出すことは、もはやできません。 6年間はそれが可能でしたが、この前提は今や成り立たなくなっており、それを前提に構築されたツールやコンプライアンスチェックは誤検知を出すことになります。
これは侵害の証拠ではありません。 ただし、Appleは何が変わったのかを一切公表していないため、説明のつかないファームウェア番号を持つMacは、セキュリティ上の問題でなくとも監査上の問題になります。

何が変わったのか：一覧表

話の全体像はファームウェアの列に集約されています。以下のバージョンはすべてApple silicon Macを対象としており、T2チップ搭載のIntel Macは番号体系が異なるため、後半で別途扱います。

日付	Tahoe	Sequoia	Sonoma	Apple siliconファームウェア
2025年12月12日	26.2	15.7.3	14.8.3	iBoot `13822.61.10` — 3系統すべて同期
2026年3月24日	26.4 (25E246)	15.7.5	14.8.5	mBoot `18000.101.7` — 新名称・新番号体系、同期は維持
2026年5月11日	26.5 (25F71)	15.7.7	14.8.7	mBoot `18000.120.36` — 同期
2026年6月29日	26.5.2 (25F84)	—	—	mBoot `18000.121.3` — SequoiaとSonomaは取り残される
2026年7月27日	26.6 (25G72)	15.7.8	14.8.8	mBoot `18000.161.9` — 同期回復
2026年8月6日	26.6.1 (25G76)	15.7.9	14.8.9	mBoot `18000.161.9` — 変更なし
2026年8月17日	26.6.2 (25G83)	—	—	mBoot `18000.161.10` — Tahoeのみ
8月17日以降	—	15.7.9（同一ビルド）	14.8.9（同一ビルド）	mBoot `18000.161.10` — 静かに変更

Oakleyによれば、この3つのシステムは初夏まで同期を保っていたとのことで、3月の行が一致する形で示されているのはそのためです。これらの数値は、各アップデートのリリース当日に書かれた彼の記事（26.4、26.5、26.6、26.6.1、26.6.2）に基づいており、さらに私たち自身が直接確認できた行が1つあります。この記事を執筆したMacは26.5.2を実行しており、18000.121.3を報告しています。

重要なのは最後の行です。バージョンは同じ、ビルドも同じ、なのにファームウェアが異なり、告知は一切ありません。

自分のMacのファームウェアバージョンを確認する方法

確認方法は3通りあり、3つ目の方法だけが、最初の2つでは分からない情報を教えてくれます。

システム情報

Appleメニュー＞このMacについて＞その他の情報＞システムレポート、と進み、サイドバー上部の「ハードウェア」を選びます。重要なのは次の2行です。

System Firmware Version: 18000.121.3
OS Loader Version: 18000.121.3

正常なMacであれば、この2つの値は一致します。これらはブートファームウェアの2つの段階を表しており、Appleは両者をまとめて更新します。

ターミナルでの確認：簡易版

system_profiler SPHardwareDataType | grep -E "Firmware|Loader"

先ほどと同じ2行がスクリプトで取得できます。ほとんどの資産管理ツールはこの方法で情報を収集しています。

ターミナルでの確認：ラベルまで表示する方法

macOSが表示するバージョン文字列は、ファームウェアが自己申告する内容を省略した形です。省略されていない完全な文字列を見るには、デバイスツリーを読み取ります。

ioreg -p IODeviceTree -n chosen -r | grep -E "firmware-version|iboot-stage"

私たちの26.5.2搭載Macでは、次のように返ってきます。

"iboot-stage-two-tag" = <"mBoot-18000.121.3">
"iboot-stage-one-tag" = <"mBoot-18000.121.3">
"system-firmware-version" = <"mBoot-18000.121.3">

注目すべき点が2つあります。ファームウェア自体は自らをmBootと名乗っています。一方でプロパティ名は依然としてibootのままです。これがこの名称変更のすべてを物語っています。Appleはファームウェアが報告する文字列だけを変更し、それを読み取る仕組みには手を付けなかったのです。

macOSのデバイスツリーからmBootファームウェアバージョンを読み取る

「mBoot」とは実際には何か

Apple自身のプラットフォームセキュリティガイドは、Apple siliconのブートチェーンを4段階で説明しています。シリコン内のBoot ROMが信頼の連鎖を開始し、Low-Level Bootloader（LLB）が署名を検証してSecure EnclaveからLocalPolicyを取得し、iBootが残りのファームウェアをロードしてカーネルコレクションと署名済みシステムボリュームのルートハッシュを検証し、その後カーネルに制御が渡ります。この文書には「mBoot」という語はどこにも登場しません。Appleが公開しているドキュメントに関する限り、このコンポーネントは今なおiBootと呼ばれています。

macOS 26.4で起きたのは、バージョン文字列の変更です。Oakleyの3月のSilentKnightリリースノートには、この移行が26.4 beta 2で初めて現れ、iBoot 13822.101.6からmBoot 18000.101.6へと変わり、最終的な18000.101.7まで続いたと記録されています。彼の見立てでは、Appleは「Macとデバイスのファームウェアを同じ番号体系に統合したかった」のではないかとのことです。これはあくまで推測であり、Appleは何も説明していません。私たちが確認できるのは観測可能な部分だけです。26.4以降を実行するあらゆるMacで、2つのブート段階はmBoot-<バージョン>として自己申告し、番号は18000から始まっています。

実用上の話をすれば、mBootとは新しい名札を付けたiBootです。果たす役割は同じで、チェーンの中の位置も同じ、そして更新される仕組みも同じ、つまり新しいバージョンをたまたま含むmacOSのアップデートやインストールによって更新されます。

これまでファームウェアがmacOSと正確に連動していた理由

8月の変更がなぜ「断絶」と言えるのかを理解するには、以前の状況がいかに整然としていたかを知る必要があります。

T2チップを搭載しないIntel Macでは、ファームウェアは機種ごとに異なっていました。macOSの各インストーラーは、インストール対象となりうる機種の数だけEFIアップデートのライブラリを内包しており、あるMacにとっての「正しい」ファームウェアはmacOSのバージョンと機種の両方によって決まりました。Oakleyは何年にもわたってこの対応表を手作業でまとめてきました。

T2搭載Macではこれが単純化され、機種を問わず、macOSのリリースごとに共通のEFIと共通のiBridgeバージョンが1つずつ存在するようになりました。

Apple siliconではさらに単純化が進みました。2020年から今年半ばまで、同じmacOSバージョンを実行するApple silicon Macはすべて同じファームウェアを持ち、そしてセキュリティ上重要だったのは、サポート対象の3つのmacOSバージョンがファームウェアを足並みそろえて更新していたという点です。2025年12月にTahoe 26.2がファームウェアを13822.61.10に移行した際には、同日にリリースされたSequoia 15.7.3とSonoma 14.8.3のセキュリティアップデートも同じように更新されました。Macのファームウェアバージョンを見れば、3つのシステムのどれを実行していようと、そのMacがどのセキュリティリリースを適用済みかが正確に分かったのです。

Oakleyによれば、この対応関係があまりに強固だったため、SilentKnightからファームウェアチェックの機能を丸ごと外すことすら検討したそうです。

2026年夏に同期が崩れた経緯

この崩壊は2段階で起きました。

1段階目はアップデートスケジュールの空白です。5月11日から7月27日までの間、SequoiaとSonomaにはセキュリティアップデートが提供されませんでした。一方Tahoeには2件のアップデートがあり、1つは特定のコンテンツフィルタリング系ネットワーク拡張機能下でM5 Macがシャットダウンする問題に対するエンタープライズ向け修正26.5.1、もう1つはセキュリティリリースの26.5.2です。後者にはファームウェアアップデートが含まれており、18000.121.3へと更新されました。約6週間にわたり、完全にパッチを適用したTahoe MacとSequoia Macが異なるファームウェアで動作する状態が続きました。Oakleyは6月末にこれを指摘し、「過去6年間で初めて、多数のMacのファームウェアが同期しなくなる」事態だと述べています。

7月27日の26.6波及アップデートでこれは修復されました。Tahoe 26.6、Sequoia 15.7.8、Sonoma 14.8.8はいずれも18000.161.9へと移行し、8月6日のアップデート（26.6.1、15.7.9、14.8.9）ではファームウェアに変更はありませんでした。すべてが再び一致した状態になったのです。

そして8月17日、AppleはmacOS 27ベータからの修正をバックポートした臨時リリースであるTahoe 26.6.2を、ファームウェア18000.161.10とともに出荷しました。これに対応するSequoiaやSonomaのアップデートはなく、両システムは.9のままにとどまりました。再び同期が崩れ、しかも今回はセキュリティリリースを挟んでのことでした。

静かに起きた部分

ここまでの話は整然とはしていないものの、きちんと記録はされています。それぞれのファームウェアバージョンは当日のうちに報告されていました。記録されていなかったのは、その後に起きたことです。

Oakleyは8月7日にSequoiaとSonomaの仮想マシンを15.7.9と14.8.9にアップデートしており、それ以降さらなるアップデートが提供されていないため、18000.161.9のままです。ところが8月28日に新規のSequoiaとSonomaのVMを作成し、同じ15.7.9と14.8.9にアップデートしたところ、18000.161.10という、それまでTahoe 26.6.2でしか出荷されていなかったファームウェアが現れました。

It appears that those Macs that were updated to 15.7.9 or 14.8.9 prior to the release of 26.6.2 on 17 August had their firmware updated to 18000.161.9, while those updated since 17 August have been provided with 18000.161.10 instead, without any change in macOS version or build number. There has been no mention of any such change in Apple's security release notes.

私たちはこの主張のもう半分を検証しました。Appleの26.6.2向けセキュリティコンテンツページには、ファームウェア、mBoot、iBootへの言及が一切ありません。15.7.9と14.8.9のページも同様です。Appleの公開記録を見る限り、何も変わっていないことになっています。

証拠について一言補足します。Oakleyの比較は物理Macではなく仮想マシンを使用しています。この特定の問いに関しては、これは弱みではなくむしろ強みです。Apple siliconでは、macOS VMのブートファームウェアはゲスト自身のインストーラーとアップデーターによって供給されるため、新規VMが「15.7.9」をインストールした後に.10を報告するということは、15.7.9のアップデートペイロード自体が今や.10を含んでいることを意味します。ただしこれは、すでに.9にある物理Macがどのように扱われるかまでは教えてくれず、私たち自身もそれを検証することはできていません。

どの番号であるべきか

上記の表を踏まえると、期待できる結果は次のとおりです。

実行中のバージョン	8月17日より前にアップデート	8月17日以降にアップデート
Tahoe 26.6.2	（あり得ない）	`18000.161.10`
Tahoe 26.6.1	`18000.161.9`	— 26.6.2へアップデート
Tahoe 26.5.2	`18000.121.3`	— 26.6.2へアップデート
Sequoia 15.7.9	`18000.161.9`	`18000.161.10`
Sonoma 14.8.9	`18000.161.9`	`18000.161.10`
Sequoia 15.7.8 / Sonoma 14.8.8	`18000.161.9`	`18000.161.9`

お使いのSequoiaまたはSonoma Macが18000.161.10を表示していれば、新しい方のファームウェアであり、特にすることはありません。18000.161.9を表示している場合は、アップデートした当日時点で正しかったファームウェアであり、現時点であなたを次に進めるアップデートは存在しません。Appleは、すでに15.7.9や14.8.9を適用済みのMacに対して、それらを再提供していないからです。

それ以外のケース、たとえば26.4以降だと表示されているMacで13822.xの番号が出ている場合や、この表にない18000.xの番号が出ている場合は、無視する前に原因を理解しておく価値があります。最もよくある無害な説明は、そのMacに複数のmacOSがインストールされており、別のボリューム用のローダーを読み取ってしまっているというものです。詳しくは後述のトラブルシューティングを参照してください。

実際に問題になるのか

正直なところ、今のところほとんどの人にとってはあまり問題にならないでしょう。ただし、これが少なからず問題になる理由は、人々が想定しているものとは異なるため、正確に述べておく価値があります。

「あなたのMacが安全でない」わけではない

18000.161.9と18000.161.10の間で何が変わったのか、Apple以外に知る者はいません。セキュリティリリースと同時に登場したことはセキュリティ関連である可能性を示唆していますが、ファームウェアのポイントリリースはハードウェアの互換性、電源管理、起動時のバグ修正なども行います。Appleの26.6.2のノートは28件のCVEを謝辞として挙げていますが、そのいずれもファームウェア修正としては説明されていません。.9のままであれば、3週間前の時点でAppleが最新と見なしていたファームウェアを使用していることになります。

「資産管理台帳が間違っている」問題

6年間、「ファームウェアバージョン」は派生的な属性でした。macOSバージョンさえ分かれば、ファームウェアも分かったのです。コンプライアンスルール、MDMのスマートグループ、スプレッドシート、外れ値を検出するスクリプトなど、この前提の上に構築されたものはすべて、これからは同一のはずのMacの中に2つの集団を目にすることになり、どちらが正しいのか判断できません。この分野で最も広く使われている一般向けツールであるSilentKnightは、バージョン3.01でその挙動を変更し、ファームウェアバージョンを「最新」か「古い」かと判定するのではなく、「検出」として報告するようになりました。まさに、その判定がもはや不可能になったためです。

「Appleが出荷済みアップデートを記録も残さず変更した」問題

バージョン番号そのものより懸念すべきはこの部分です。Apple siliconのアップデートは、Oakleyが「Update Brain」と呼ぶ、macOSがその特定のアップデートを実行するためにダウンロードするアップデートごとのコンポーネントによって適用されます。Appleはそれらのアップデートの1つがインストールする内容を明らかに変更しながら、バージョンとビルドは同一のまま維持し、何も公表しませんでした。彼の結論は率直です。

In the absence of any information from Apple, some could reasonably suspect this was the result of a sophisticated attack.

彼自身はそうではないと考えており、私たちも同意見です。しかし、「Appleが公開している情報だけでは、これを攻撃と区別できない」という状態は、セキュリティアップデートのプロセスが本来あるべき姿ではありません。

macOS Tahoe、Sequoia、Sonomaにまたがるファームウェアバージョンの系譜

SequoiaまたはSonomaを使っていて新しいファームウェアが欲しい場合

選択肢は3つありますが、推奨されるのは最初の1つだけです。

待つ

OakleyはSequoia 15.8が9月後半にmacOS 27と共に出荷されると予想しています。そのアップデートは、その時点で最新のファームウェアをほぼ間違いなく含むはずで、いずれにせよ.10より新しくなっている可能性があります。彼はGolden Gateのファームウェアがおおよそ20457.1.29まで飛躍すると見込んでいます。Sonomaについては事情が異なります。Sonomaの最終リリースは14.8.9になる可能性が高く、その場合8月17日より前にアップデートしたSonoma Macは永久に.9のままとなります。それでも問題はありません。期限内にアップデートしたSonoma Macはすべて同じ状態だったからです。

リカバリからmacOSを再インストールする

recoveryOSからの「macOSを再インストール」は、インストール済みバージョンの新しいコピーをダウンロードし、インストーラーがより新しいものを含んでいればファームウェアを更新できます。新規の15.7.9インストールが現在.10を含んでいることを踏まえると、これは有効かもしれません。私たちはこれを検証していませんし、1時間ほどかかる上に、バージョン文字列の食い違いに対する対応としては釣り合いが取れていません。番号を追いかけるためだけにこれを行うのはやめましょう。

DFUリバイブ

Apple silicon Mac向けのApple公式リバイブ／リストア手順は、USB-Cケーブル経由でもう1台のMacからファームウェアを再読み込みします。Appleによれば、リバイブは「Macを消去しない」ため、消去を伴うリストアよりも先に試すべきだとされています。macOS 14以降を実行するホストMacと、データ転送と充電に対応したUSB-Cケーブルが必要です。Appleは特に、Thunderbolt 3ケーブルを使用しないよう明記しています。これは起動しなくなったMacには適切な手段ですが、問題なく起動していて気に入らないファームウェア番号を持っているだけのMacには不適切な手段です。存在を知ってもらうためだけに触れています。

Tahoeを使っている場合

26.6.2を使用している場合は、すでに.10を持っており、ここでの話は当てはまりません。26.6.1以前を使用している場合、対処法はいずれにせよインストールすべきアップデートそのものです。

次に見ることになるファームウェアの変化は、大きなものになるはずです。Oakleyがベータ版を読み解いたところによれば、Golden Gateのファームウェアは20457.x系列へと移行します。新しいMac miniとMac Studioは9月22日にmacOS 27のプレリリースビルドを搭載して出荷され、すぐに27.0.1へのアップデートを求めてくることになります。そのファームウェアも同時に移行すると見ておくべきでしょう。

複数台のMacを管理する管理者向け

具体的な調整点は3つです。

ファームウェアバージョンをmacOSバージョンから導出できるという扱いをやめましょう。 「15.7.9なら18000.161.9のはず」といった形のルールは、今や管理下のMac群の一部で誤りとなっており、その一部はおそらく記録していないアップデートのタイミングによって決まります。

.9と.10の違いだけでアラートを出さないようにしましょう。 どちらも同じAppleアップデートによる正当な結果です。macOSバージョンごとに比較対象となる単一の値が欲しい場合は、新しい方をターゲットとして扱い、.9については「インストール日時点では正しく、次回のアップデートで収束する」ものとして扱ってください。

登録時および各アップデート時にファームウェアバージョンを記録しましょう。 そうすることで、「このMacは早めにアップデートされた」というケースと、「このMacのファームウェアがmacOSアップデートを伴わずに変化した」という、実際に注目すべきケースとを区別できます。Apple siliconでは、ファームウェアはmacOSのインストールまたはアップデート中にしか変化しないため、対応するmacOSの変化を伴わないファームウェアの変化こそが警戒すべき異常であり、2台のMac間の不一致そのものではありません。

Appleが行うべきこと

これはささやかな要望です。Appleのセキュリティコンテンツページは、すでにアップデートに含まれるすべてのコンポーネントとCVEを列挙しています。「This update includes mBoot 18000.161.10」という一行を追加するだけなら、コストはゼロに等しく、8月の変更を当日のうちに可視化できたはずです。この変更が意図的かつ無害なものであるなら（それが圧倒的に有力な見立てですが）、人々が仮想マシンを比較することでしか気づけない状態を放置しておく理由はありません。

Intel Mac

T2チップを搭載したIntel Macは、EFI形式のシステムファームウェアとT2のiBridge（bridgeOS）という2つのファームウェアコンポーネントを報告します。Oakleyの26.6.2に関する記事では、それぞれ2103.160.2.0.0とiBridge 23.16.16068.0.0,0とされており、26.6.1から変化はありません。mBootをめぐる話はIntelハードウェアには一切当てはまりません。番号体系は変わっておらず、3バージョン間の同期が崩れたこともありません。TahoeのIntel Macはいずれにせよ最後のmacOSリリースを迎えているため、これが目にする最後のファームウェアの系譜になります。

よくある問題のトラブルシューティング

システム情報に2つの異なる番号が表示される

「System Firmware Version」と「OS Loader Version」は通常一致します。この2つが異なる最も一般的な理由は、そのMacに複数のmacOSボリュームがインストールされている場合です。たとえば別ボリュームにGolden Gateのベータ版が入っているようなケースで、報告されるローダーは別のシステムに紐づいたものになります。もう一方のボリュームから起動して比較してみてください。単一のmacOSしかインストールされていないのに値が異なる場合は、それは異常であり、Appleに報告する価値があります。

SilentKnightが「current」ではなく「found」と表示する

これはバージョン3.01以降、ツールが設計どおりに動作している結果です。AppleがmacOSバージョンごとに単一の答えを保証しなくなったため、このツールはもうあなたのファームウェアが最新かどうかを判断できません。代わりに上記の表と照らし合わせてください。

仮想マシンがホストと一致しないファームウェアバージョンを表示する

それは想定どおりです。Apple siliconでは、macOS VMのファームウェアはホストMacではなくゲスト側のインストーラーに由来します。だからこそOakleyのVMがこの変更を明らかにできたのです。

`ioreg`が`chosen`ノードに対して何も返さない

おそらくIntel Macを使用しています。Intel Macではデバイスツリーの構成が異なり、iboot-stage-one-tagは存在しません。代わりにsystem_profiler SPHardwareDataTypeを使用してください。これは「Boot ROM Version」と、T2搭載Macの場合はController配下のiBridgeバージョンを報告します。

8月7日にアップデートしたのにSequoia Macが`18000.161.10`を表示する

それであれば、その日付以降に何かがファームウェアを更新したことになります。考えられるのはmacOSの再インストール、リバイブ、あるいは気づかなかったアップデートです。システム情報の「ソフトウェア＞インストール」で、8月17日以降の日付のものがないか確認してください。何も見当たらない場合はそれを記録しておいてください。対応するインストールを伴わないファームウェアの変化こそ、この記事の中で唯一、改めて確認する価値があるパターンです。

FAQ

`18000.161.10`はセキュリティ修正ですか？

分かりません。セキュリティリリースと同時に出荷されましたが、Appleはその内容を説明していません。「既知の穴を塞ぐもの」としてではなく、「より新しいもの」として扱ってください。

Macが`18000.161.9`の場合、何かすべきですか？

いいえ。それはアップデートした当日時点で正しいファームウェアであり、次にインストールするmacOSアップデートが最新のものをもたらします。Appleが.9に関連付けている既知の脆弱性はありません。

Appleの文書がiBootと書いているのに、なぜファームウェアは自らをmBootと名乗るのですか？

AppleはmacOSバージョン26.4でバージョン文字列の名称を変更しましたが、それに合わせてセキュリティ関連のドキュメントを更新していません。私たちのMacでは、ファームウェアはmBoot-18000.121.3と報告する一方、それを格納するデバイスツリーのキーは依然としてiboot-stage-one-tagやiboot-stage-two-tagという名前のままです。機能的には同じコンポーネントです。

macOSのアップデートを伴わずにファームウェアが変わることはありますか？

Apple siliconでは、それはありません。ファームウェアはmacOSのインストール、アップデート、リバイブ、リストアの際にのみ書き込まれます。だからこそ、対応するインストール記録のないファームウェアの変化こそが、真に異常なケースなのです。

macOS 27で同期は修復されますか？

リセットはされるでしょう。Golden Gate、Tahoe 26.7、Sequoia 15.8は9月にそろって登場すると見込まれており、初日はファームウェアを共有するはずです。その後もAppleが同期を保つのか、それともこの夏のパターンを繰り返すのかは、まだ未解決の問題です。

まとめ

6年間、Apple silicon Macのファームウェアバージョンは、たった1つの要素、すなわちmacOSバージョンの関数でした。これが有用だったのは、そのMacが最新のmacOSを実行していようと、2つの旧バージョンのどちらかを実行していようと、単一の番号を見ればどのセキュリティリリースを適用しているかが分かったからです。この夏、それは成り立たなくなりました。まずTahoeのサイクル中盤のアップデートが、旧システムには提供されないファームウェアを含んでいたことが原因であり、さらに深刻なことに、Appleが目に見える変化を一切伴わずにSequoiaとSonomaのアップデートがインストールする内容を変更したためです。

これによってあなたのMacの安全性が下がるわけではありません。しかし、ファームウェア番号の解釈は難しくなり、それに依存していたツールの有用性は下がり、そしてAppleが出荷済みのアップデートを黙って改訂することがあるという事実が確立されました。複数台のMacを管理しているのであれば、9月のリリース群が4つ目のmacOSバージョンを加える前に、今のうちに前提を見直しておいてください。そうでない場合の実用的な結論はもっと小さなものです。.9も.10もどちらも問題なく、気にすべき番号とは、他に何も変わっていないのに変化した番号のことなのです。