macOS 26.4以降、ログインキーチェーンのバックアップがロック解除できない

約20年にわたり、Macに保存したログイン情報のバックアップといえば、login.keychain-db を安全な場所にコピーしておき、必要になった日に新しいMacの ~/Library/Keychains/ に置いてパスワードを入力する、というものでした。The Eclectic Light CompanyのHoward Oakley氏、Michael Tsai氏、そして複数の開発者によると、2026年3月24日にリリースされたmacOS Tahoe 26.4から、この前提は成り立たなくなりました。ログインキーチェーンのファイル単体では役に立たない場合があり、ロックを解除するにはパスワードに加えて、そのキーチェーンを作成したMacの /var/db/SystemKeys にある保護された2つ目のファイルが必要になります。Appleはこの変更をリリース時に告知しませんでした。最初の公式な説明は6か月後の2026年9月24日、開発者向けテクニカルノートTN3137の更新として公開され、多くの人がそこで初めて知りました。新規インストールしたMacにキーチェーンファイルをドラッグしたことがある方、USBメモリのコピーを保険にしている方、これからMacを初期化または交換する方に向けたガイドです。Appleが文書化している内容、他の人が観察した内容、まだ誰も確認していない内容を切り分け、上位の検索結果にはないシナリオ別の一覧表も用意しました。

要点まとめ

• 変更は実際に行われましたが、文書化は不十分です。 macOS Tahoe 26.4(2026年3月24日)以降、ログインキーチェーンは /var/db/SystemKeys にある保護されたエントロピーファイルを参照することがあります。そのようなキーチェーンを解除するには、パスワードとそのファイルが必要です。この点はAppleのテクニカルノートTN3137に記載されており、仕組みの詳細はHoward Oakley氏の検証に基づいています。
• login.keychain-db だけのバックアップは、もはやバックアップではありません。 エントロピーファイルのないコピーは、正しいパスワードを入力しても解除できません。Oakley氏の率直な助言は、エントロピーファイルと一緒に保存されていない古いコピーは永久に解除できないため、失われたものとして扱うべき、というものです。
• Appleが管理するMac間の移行ツールは動作すると報告されています。 Oakley氏によると、Time Machineは /var/db/SystemKeys をバックアップし、移行アシスタントはエントロピーファイルをコピーします。独立した仮想マシンでの検証でも、移行アシスタントがキーチェーンを引き継ぐことが確認されました。サードパーティ製のクローン作成ツールは、このディレクトリに明示的に対応している必要があります。
• クリーンインストールが最も危険なタイミングです。 Michael Tsai氏がまとめた報告によると、同じMacであっても、ディスクを消去してからキーチェーンファイルを戻しても動作しません。消去によってエントロピーキーが失われるためです。
• iCloudキーチェーンと「パスワード」アプリは別のストアです。 これらはファイルベースのログインキーチェーンではなく、データ保護キーチェーンを使用しているため、今回の変更の影響は受けません。ログインキーチェーンにしか存在しない項目こそ、消去の前に移行または書き出す必要があります。
• SIPの保護を安易に解除しないでください。 キーチェーンを別のMacにコピーするために文書化されている唯一の方法は、システム整合性保護(SIP)を無効にすることです。Appleはこれを製品の機能ではなく、デバッグ用の手段だとしています。

何が、どのバージョンで変わったのか

この話はフォーラムで繰り返されるうちに細部があいまいになっているため、誰が何を言ったのかを丁寧に整理します。層は3つあります。Appleが文書化していること、Howard Oakley氏らが観察したこと、そしてまだ確認されていないことです。

Appleが文書化していること

Appleの開発者向けテクニカルノートTN3137: On Mac keychainsには、ファイルベースのキーチェーンのバックアップに関する節が追加されました。私の理解では、次のように書かれています。

• macOS 26.4以降、ファイルベースのキーチェーンは保護されたエントロピーファイルを参照することがあります。そのようなキーチェーンを解除するには、キーチェーンのパスワードと、対応する保護されたエントロピーファイルが必要です。
• エントロピーファイルは、security show-keychain-info -s にキーチェーンのパスを指定してソルトを出力することで見つけられます。エントロピーファイルは /var/db/SystemKeys/ にあり、ファイル名がソルト値です。
• すべてのキーチェーンにエントロピーファイルがあるわけではありません。ソルトに一致するファイルがない場合、そのキーチェーンはエントロピーファイルを参照していません。
• バックアップ製品は /var/db/SystemKeys/ ディレクトリ全体をバックアップしなければなりません。これらのファイルがないと、バックアップしたキーチェーンが使えなくなる可能性があります。
• キーチェーンを別のMacにコピーして調査する場合は、キーチェーンファイルを任意の場所にコピーし、エントロピーファイルをコピー先の /var/db/SystemKeys/ に置きます。このディレクトリにアクセスするには、システム整合性保護(SIP)を無効にする必要があります。
• エントロピーファイルの名前、場所、形式はAPIではないと明記されており、いつでも変更される可能性があるため、これらを前提に製品を作るべきではありません。
• システムは、これらのファイルに関する情報を dp_login というログカテゴリでシステムログに書き込みます。

私はこのテクニカルノートを機械可読な形式でのみ読んだため、ここでの表現は忠実な言い換えとして扱ってください。このテーマについて私が見つけたApple公式の文書はこれだけです。macOS 26.4のリリースノートにこの変更への言及は見当たらず、AppleのセキュリティリリースのページにもmacOS Tahoe 26.4(2026年3月24日)にキーチェーンの保存方式に関する項目はありません。変更が6か月間文書化されなかったというOakley氏の指摘とも一致します。

Howard Oakley氏らが観察したこと

Oakley氏の記事は実際の状況をよく伝えています。9月14日の記事How can you copy or restore keychains?では、この変更をログインキーチェーンへのアクセスが1台のMacに結び付けられたものと説明し、ログイン以外のファイルベースのキーチェーンや、macOS 26.3.1以前で作成されたファイルベースのキーチェーンは従来どおり動作すると報告しています。10月2日の記事How to copy login keychains that can be unlockedは文書化された手順であり、バックアップツールに関する記述の出典です。10月3日の記事What changed in macOS Tahoe 26.4, take 2では、最初に見落としていた項目として、SIPで保護された新しいディレクトリ、それを含めてバックアップするTime Machine、エントロピーファイルをコピーする移行アシスタント、security show-keychain-info の新しい -s オプションを挙げています。

Michael Tsai氏は反応をLocked Down Passkey and Keychain Backups(9月24日)にまとめました。エントロピーファイルは暗号化されていてSIPを無効にしないとアクセスできないこと、キーチェーンを別のMacに復元すると失敗すること、同じMacでもクリーンインストール後は失敗することが報告されています。私はこの記事を要約としてしか読んでおらず、これらの主張を再現することはできませんでした。

もう1つの独立した検証は、ドイツのサイトBorn Cityによるものです。同サイトは仮想マシンでの検証を報告しています。仮想Mac間で login.keychain-db をコピーした場合、Tahoe 26.6.2から26.6.2へ、および26.6.2からmacOS 27のリリース候補版へのどちらでも、正しいパスワードを入力してもエラー -2147413984 で失敗しました。一方、移行アシスタントはテストしたすべてのシナリオでキーチェーンを引き継ぎました。同記事は失敗の原因をSecure Enclaveに保持された鍵だとしていますが、これは著者の説明であり、Appleの説明ではありません。

未確認のこと

• macOS 27でも同じ挙動かどうか。 Born Cityのリリース候補版でのテストを除けば、27.0や27.0.1を検証した情報源は見つかりませんでした。テクニカルノートにもルールが異なるとは書かれていません。26.4の挙動が続くと考えるのは、あくまで推測です。
• 2つ目の秘密情報が具体的に何なのか。 9月14日の記事では、Secure EnclaveまたはAPFSボリューム固有の鍵が関係している可能性が示唆され、Appleはどちらなのかを明らかにしていないとされています。10月2日の記事は、少なくともOakley氏の検証では、SIPを無効にした別のMacにエントロピーファイルとキーチェーンをコピーすれば十分であることを示しています。この2つの知見はすぐには噛み合わず、Appleからの説明も見ていません。
• どの環境が影響を受けるのか。 Oakley氏は、26.4より前に作成されたキーチェーンは引き続き動作する場合があると述べており、TN3137はエントロピーファイルをまったく参照しないキーチェーンがあるとしています。26.3で作成され、その後26.4以降で使われたキーチェーンにエントロピーファイルが付与されるかどうかは、私が読んだどの資料にも書かれていません。

Appleが確認していない関連の主張

同じ週に、Tsai氏はBob Gendler氏による投稿も紹介しました。CVE-2026-43728 と付けられたこの問題では、他の解除要素が利用可能な場合に、誤ったパスワードでもキーチェーンの解除が成功してしまうと報告されており、その趣旨のmanページの記述が引用されています(Accessing the Keychain Without the Passwordを参照)。Apple側では確認できませんでした。私が確認したAppleのセキュリティリリースのページには、この識別子の項目も、26.4から26.7.1までのリリースにおけるキーチェーン関連の項目もなく、macOS 26.5.2のMacの security のmanページで引用された文も見つかりませんでした。サードパーティによる報告であり、Appleが確認したものではないと受け止めてください。また、本記事で扱う問題とは別の問題のため、以下のバックアップに関する助言は変わりません。

仕組みをわかりやすく説明

ログインキーチェーンを鍵のかかった箱だと考えてください。長い間、この箱は ~/Library/Keychains/login.keychain-db という1つのファイルで、鍵はパスワードでした。ファイルとパスワードがあれば、どこでも開けられました。

26.4からは、この箱に2つ目の錠が付くことがあります。情報源が一致している点は次のとおりです。

1. ファイルには、必要なエントロピーファイルが記録されています。 security show-keychain-info -s コマンドは、ファイルベースのキーチェーンのソルトを出力します。Oakley氏の出力例では、salt= の後に長い16進数のソルトが続きます。/var/db/SystemKeys にあるエントロピーファイルは、このソルトにちなんで名前が付けられています。
2. エントロピーファイルはSIPで保護されたディレクトリにあります。 /var/db/SystemKeys は新しいディレクトリで、Oakley氏によると、SIPを無効にしない限り読み書きできません。Tsai氏のまとめでは、中のファイルは暗号化されているとも補足されています。
3. 解除には両方が必要です。 パスワードだけでは、もう解除できません。キーチェーンを作成したMacでは、こうした仕組みは見えません。ログインすればキーチェーンが解除され、エントロピーファイルはユーザーが意識しないままシステムが読み取ります。
4. エントロピーファイルはボリューム上にあります。 ディスクを消去するとディレクトリごと消えます。クリーンインストールが問題になるのも、Time Machineがこのディレクトリを含めてバックアップすることが重要なのも、このためです。

情報源が確定させていないのは、Secure Enclaveの役割です。Oakley氏の9月14日の記事やBorn Cityの記事を含む初期の報告は、暗号化がSecure Enclaveまたはマシン固有の秘密情報と結び付いているとしています。Oakley氏は、Appleがこの点を明らかにしていないと書いています。Tsai氏は、すべてのApple siliconのMacと一部のIntel MacにSecure Enclaveプロセッサが搭載されているため、数百万人に影響しうるというコメントを引用しています。実際に対処できるのは、文書化された仕組み(パスワードとエントロピーファイル)だけです。

混乱しやすい点がもう1つあります。ここまでの話はすべて、従来のファイルベースのログインキーチェーンに関するものです。TN3137は、もう1種類のキーチェーンであるデータ保護キーチェーンについても説明しています。これはiCloudキーチェーンとともにMacに導入されたもので、iOSが使っているものです。こちらは別のストアであり、多くの人が最初に抱く疑問につながります。

ログインキーチェーン、iCloudキーチェーン、「パスワード」アプリ、パスキー:何が影響を受けるか

ストア	内容	26.4の変更の影響	出典
ログインキーチェーン(login.keychain-db)	ユーザーごとのファイルベースのキーチェーンで、Macの標準	あり。パスワードとエントロピーファイルが必要	TN3137、Oakley氏
システムキーチェーン	Mac全体で共有される1つのファイルベースのキーチェーン	私が読んだ資料では言及なし	不明
自分で作成したその他のファイルベースのキーチェーン	個別の .keychain-db ファイル	なし。Oakley氏によると通常どおり動作	Oakley氏、9月14日
iCloudキーチェーン / iCloudパスワード	データ保護キーチェーン。Apple Accountを通じて同期	TN3137の記述の範囲では、この変更の影響なし	TN3137
「パスワード」アプリ	パスワード、パスキー、コードのフロントエンド	ログインファイル自体ではない	Appleのパスワードガイド
iCloudキーチェーンに保存されたパスキー	同期される認証情報	この変更の影響なし。下記の注意点を参照	TN3137、Tsai氏

TN3137は、iCloudキーチェーンにはデータ保護キーチェーンが必要であり、キーチェーンアクセスでは有効なときは iCloudキーチェーン、無効なときは ローカルアイテム と表示されると述べています。また、macOS 11以降ではすべての項目クラスが同期されるとも書かれています。つまり、パスワードをiCloudで同期していれば、持ち歩くファイルではなく、Apple Accountに結び付いたAppleの同期サービス上にコピーがあることになります。新しいMacでの復元は、ファイルをコピーすることではなく、サインインしてiCloudパスワードを再びオンにすることです。

そこに落とし穴があります。ログインキーチェーンの中に、自分でも気づかない項目が入っていることがあります。 Tsai氏の議論では、Google Chrome、Zoom、MailMate、Vienna RSS、Xcodeが認証情報をそこに保存するアプリとして挙げられています。古いメールのパスワード、VPNのシークレット、クライアント証明書、開発者トークンもよくここに入っており、消去前に10分かけて確認する価値があるのはそのためです。

パスキー

Tsai氏の記事のタイトルはパスキーのバックアップに触れているため、確認できたことと確認できなかったことを正確に書いておきます。システムで作成し、iCloudキーチェーンで同期しているパスキーは、ログインファイルではなくデータ保護キーチェーンの側に保存されるため、26.4のエントロピーファイルの変更によって危険にさらされるわけではありません。確認できなかったのは、Appleのパスキーのバックアップや書き出しの挙動が今回の変更とどう関係するかです。Tsai氏の記事のパスキーに関する詳細を全文では読めなかったためです。私が読んだAppleの書き出しガイドでは、パスワードはCSVファイルに書き出せるものの、Wi-Fiのパスワード、グループで共有されているパスワード(自分がグループを作成した場合を除く)、Appleでサインインのアカウントは書き出せないとされています。このファイルにパスキーが含まれるとは書かれていないため、パスキーを書き出す計画は立てないでください。パスキーはiCloudキーチェーンに置いておくことを前提にし、重要なサイトでは、リカバリーコードや2つ目のサインイン方法など、別の入口を確保しておきましょう。

シナリオ別一覧表:ログインキーチェーンの項目はどうなるか

「不明」と書いた箇所は、私が読んだ資料でそのケースを扱っているものがないことを意味します。「動作する」「失敗する」の場合は、報告した人を記載しています。私自身が検証したものはありません。

シナリオ	結果	出典と補足
同じMacでのインプレースアップグレード(例:26.7.1や27.0.1へ)	動作すると見込まれるが、どの資料でも直接テストされていない	Oakley氏は、同じMacからバックアップしたキーチェーンは動作すると述べています。アップグレードでは同じボリュームと同じ /var/db/SystemKeys が維持されるため、何も分離されません。この経路そのものをテストした資料はありません。
移行アシスタントで旧Macから新しいMacへ直接移行	動作する	Oakley氏(9月14日と10月3日)は、移行アシスタントがエントロピーファイルをコピーすると述べています。Born Cityの仮想マシンでのテストでも、すべてのシナリオでキーチェーンが引き継がれました。Tsai氏のまとめでは、旧Macをネットワーク上のサーバとして動かした場合にのみ動作するというコメントが紹介されているため、保存済みのバックアップからではなく、2台とも電源を入れた状態で実行してください。
Time Machineバックアップからの移行アシスタント	不明	Oakley氏は、Time Machineが /var/db/SystemKeys をバックアップすると述べています。そのバックアップを移行元として別のMacに使った場合にどうなるかを述べた資料は、私が読んだ範囲にはありません。
同じMacへのTime Machineでの全体復元(または同じMacで内蔵ドライブを交換した場合)	Oakley氏によると動作する	Oakley氏によると、Time Machineは26.4以降このディレクトリをバックアップし、エントロピーファイルを自動的に復元します。ロジックボード交換の場合の例外は下記を参照してください。
別のMacへのTime Machineでの復元	不明	私が読んだ資料では扱われていません。新しいMacへの移行には、文書化された経路である移行アシスタントを使ってください。
Carbon Copy Clonerによる起動可能なクローンを復元	バックアップ側は動作、復元側は不明	Oakley氏は、Mike Bombich氏が、CCCはボリュームスナップショットから作業するため、特別な手順なしでSystemKeysフォルダの内容をバックアップすると確認したと報告しています。そのクローンを別のMacに復元した場合の挙動は書かれていません。
SuperDuperによる起動可能なクローンを復元	不明(手がかりあり)	Tsai氏の記事のコメントに、SuperDuperはAppleの asr ツールを使って必要な鍵をコピーできるというものがあります。開発元の見解は確認できていません。頼る前にベンダーに確認してください。
login.keychain-db を別のMacに手動でコピー	動作しない	Oakley氏、TN3137、Born Cityの3者が一致しています。Born Cityは、正しいパスワードでもエラー -2147413984 になると報告しています。
キーチェーンとそのエントロピーファイルを手動でコピーし、SIPを無効にしたコピー先の /var/db/SystemKeys に配置	Oakley氏の文書化された手順では動作する	手順と注意点は後述の節にあります。私は実行していません。
クリーンインストール後に古いキーチェーンファイルを戻す(同じMac)	動作しない	Tsai氏の記事は、クリーンインストール後にファイルを復元しても、消去でエントロピーキーが失われているため失敗すると報告しています。Oakley氏は、エントロピーファイルなしで保存されたログインキーチェーンは永久に解除できないと述べています。
Time Machineバックアップから login.keychain-db を1つだけ復元	場合による	そのキーチェーンのソルトに対応するエントロピーファイルが稼働中のボリュームにまだ残っていれば、資料が動作するとしている組み合わせになります。クリーンインストール後や別のMacでは失敗します。この復元経路を直接テストした資料はありません。
ロジックボード交換を伴うハードウェア故障、またはDFU復元	動作しない	Oakley氏の9月14日の記事は、これらをログインキーチェーンを解除できないケースとして挙げ、Macにアクセスできなくなると中身も失われると警告しています。
26.3.1以前で作成されたキーチェーン、ログイン以外のファイルベースのキーチェーン	通常どおり動作	Oakley氏、9月14日。

この表から2つの原則が見えてきます。安全な経路は、Apple自身のツールがシステムの状態全体を運んでくれるもの。危険な経路は、キーチェーンだけを動かす、またはそれを保持していたディスクを消去するなどして、エントロピーファイルとキーチェーンを引き離すものです。

Macを消去または交換する前に:チェックリスト

「すべてのコンテンツと設定を消去」をクリックする前、リカバリからmacOSを再インストールする前、ロジックボードを交換するかもしれない修理店にMacを預ける前に、これを実施してください。目的は、重要なものがログインキーチェーンの中にだけ存在する状態をなくすことです。

1. Macの状態を確認し、きちんとしたバックアップを作成する

実行しているバージョンを確認します。以下の対処法は26.4以降を前提としています。

sw_vers -productVersion

まずTime Machineで完全なバックアップを作成してください。Oakley氏は、バックアップに /var/db/SystemKeys が含まれるようになったと報告しています。バックアップの失敗についてはTime Machineのトラブルシューティングガイドで扱っており、保存先がSMB経由のNASの場合は、26.4の別の問題を解説した26.4のSMBバックアップ修正を参照してください。より広い計画についてはバックアップ戦略ガイドをご覧ください。Time Machineのバックアップはセーフティネットであり、答えのすべてではありません。復元時には守ってくれますが、単一のファイルだけを取り戻すケースは守ってくれません。

2. キーチェーンアクセスを開き、実際に何が入っているか確認する

macOS 26.5.2のMacで、キーチェーンアクセスが /System/Library/CoreServices/Applications/Keychain Access.app に今も存在することを確認しました。以前のアプリケーション/ユーティリティフォルダにはもうないので、Spotlightで検索するか、ターミナルから開いてください。

open "/System/Library/CoreServices/Applications/Keychain Access.app"

サイドバーで デフォルトキーチェーン の下にある一覧を見てください。TN3137によると、ファイルベースのキーチェーンは ログイン、データ保護キーチェーンは、iCloudキーチェーンがオンかどうかに応じて iCloud または ローカルアイテム という名前で表示されます。ログイン をクリックし、パスワード と 証明書 のカテゴリを開きます。種類 と 変更日 で並べ替えると、古い項目や明らかに重要な項目が上に来ます。ログイン にあるものは、消去時に危険にさらされる項目です。iCloud にあるものは、Apple Accountと同期されます。

ターミナルを使う場合は、security のmanページに、読み取り専用の次の2つのコマンドが記載されています。

security list-keychains
security show-keychain-info ~/Library/Keychains/login.keychain-db

1つ目は、現在の検索リストにあるキーチェーンを一覧表示します。2つ目は、指定したキーチェーンの設定を出力します。私が確認したMacでは、ローカルのmanページにOakley氏とTN3137が説明している -s オプションは載っていませんでした。ソルトが必要な場合は、これらの資料にある形式、つまり security show-keychain-info -s の後にパスを付ける形を使い、パスワードの入力を求められることを想定してください。ソルト値は書き留めておくと便利です。このキーチェーンに対応する /var/db/SystemKeys 内のファイルがどれかがわかり、後でバックアップにそれが含まれていることを示す必要が出たときに役立ちます。

security dump-keychain というコマンドもあり、manページによればキーチェーンの内容をダンプします。-d オプションは復号したデータをダンプします。私は実行していないので、出力を扱う場合は非公開にして、後で削除してください。

3. 書き出せるものを書き出す

正直に言えば、簡単に書き出せるもの、手間をかければ書き出せるもの、まったく書き出せないものがあります。

• 「パスワード」アプリのパスワード。 Appleのドキュメントでは、「ファイル」から「選択したパスワードをファイルに書き出す」または「すべてのパスワードをファイルに書き出す」を選びます。結果はCSVで、Appleが警告しているとおり暗号化されておらず、ファイルにアクセスできる人なら誰でも見られます。パスワードマネージャに読み込んだら、CSVは削除してください。また、Appleによると、書き出しにはWi-Fiのパスワード、自分が作成していないグループで共有されたパスワード、Appleでサインインのアクセスを含められません。アプリのその他の機能については、macOS 27の「パスワード」アプリの記事で解説しています。
• ログインキーチェーンにしかない項目。 古いアプリが保存したパスワードはキーチェーンアクセスには表示されても、「パスワード」アプリには表示されないことがあります。私が見つけたユーザー報告の1つでは、保存されたパスワードを選択するとキーチェーンアクセスの「項目を書き出す」コマンドが無効になっていたため、メニューコマンドで書き出せるとは考えないでください。重要な項目ごとに、項目を開いて パスワードを表示 にチェックを入れ、認証を行い、その値をパスワードマネージャに記録します。面倒な作業ですが、数十件程度であれば、これが唯一確実な方法でもあります。
• 証明書とID。 security のmanページには、種類(certs や identities など)と形式(pkcs12 など)を指定できる書き出しコマンドが記載されています。一般的な形式は次のとおりです。

security export -k ~/Library/Keychains/login.keychain-db -t identities -f pkcs12 -o ~/Desktop/identities.p12

manページによると、-P を付けない場合、保護用のパスフレーズはGUIのプロンプトで要求されます。コマンドラインにパスフレーズを書くとシェルの履歴に残るため、こちらのほうが適切です。私はこのコマンドを実行していません。作成したツールが書き出し不可と指定した秘密鍵は書き出しを拒否することがありますが、そのような鍵では想定どおりの動作であり、バックアップの不具合ではありません。VPNや業務ポータルのクライアント証明書に頼っている場合は、発行元に再発行してもらえるか尋ねてください。書き出しに苦労するより、そのほうが早いことがよくあります。

• Wi-Fiのパスワード。 Appleは「パスワード」アプリから書き出せないものとして挙げています。重要なネットワークを控え、それぞれのパスワードをどこに書き留めてあるか把握しておきましょう。
• 取り出せないもの。 そのアプリだけが読み取れるアクセス規則で保存されたシークレット、および、もう解除できないキーチェーンにしか存在しないもの。これらについては、ベンダー自身の書き出し、サインアウト、再認証の手順が唯一の経路です。

4. 残ったものを耐久性のある場所へ移す

大切な項目ごとに、次にどこへ置くかを決めます。Appleの同期ストアを使いたい場合は、システム設定でApple Account、iCloudの順に開き、iCloudのパスワードとキーチェーンをオンにします。または、独自の暗号化された書き出しに対応しているサードパーティ製のパスワードマネージャを使います。どちらの場合も、移行先はこのMacに依存するファイルであってはなりません。

別のデバイスから、同期されたコピーだけでサイトにサインインできることを確認してください。サインインできれば、その項目は今回の変更の影響を受けません。

5. 消去の準備をする

消去の手順そのものはファクトリーリセットガイドで解説しています。Apple Accountからのサインアウトは、同期されたコピーが完全であることを確認してから行ってください。新しいMacには、旧Macの電源を入れたまま移行アシスタントを実行します。止まってしまった場合は移行アシスタントのトラブルシューティングガイドを参照してください。新しいMacでログイン項目が実際に開けると確認できるまで、旧Macのデータはそのまま残しておきましょう。

キーチェーンを解除可能な状態でコピーする、文書化された手順

私はこの手順を実行しておらず、どのMacでもテストしていません。これはHoward Oakley氏の文書化された方法にAppleのTN3137の記述を組み合わせたもので、要件とリスクをそのまま示しています。

文書化されている手順

1. コピー元のMacで、コピーしたいキーチェーンのソルトを調べます。Oakley氏とTN3137は、security show-keychain-info -s の後にキーチェーンのパスを付ける形を示しています。キーチェーンのパスワードの入力を求められます。出力の末尾に長い16進数のソルト値が表示されます。
2. 必要なエントロピーファイルは、/var/db/SystemKeys/ の後にそのソルト値を付けたものです。TN3137とOakley氏によると、このディレクトリを読むにはSIPを無効にする必要があります。コピー元のMacでファイルを読むためにSIPをオフにする必要があるかどうかは、どちらの資料にも明記されていませんが、同じディレクトリ保護が両側に適用されるため、必要になると想定してください。
3. キーチェーンファイルとそのエントロピーファイルを、コピー先のMacにコピーします。キーチェーンは任意の場所に置けます。Oakley氏の例では、書類フォルダ内のサブフォルダに置いています。
4. コピー先で、SIPを無効にした状態で、エントロピーファイルを同じ名前のまま /var/db/SystemKeys に置きます。
5. SIPを再び有効にします。
6. コピーしたキーチェーンを開き、そのパスワードを入力します。

SIPを無効にして再び有効にする方法として、Appleが文書化しているのは、recoveryOSで起動し、そこでターミナルを使うことです。関連するコマンドは次のとおりです。

csrutil disable
csrutil enable

csrutil disable はインストール済みのシステムのSIPをオフにし、再起動が必要です。csrutil enable で再びオンになります。現在の状態はいつでもターミナルで csrutil status を実行すれば確認できます。この調査に使ったMacでは、SIPが有効と表示されました。これは想定されるデフォルトです。Apple siliconのMacでrecoveryOSに入るには、シャットダウンしてから電源ボタンを長押しし、起動オプションが表示されたら「オプション」を選びます。

要件とリスク

• コピーの手順ではSIPをオフにする必要があります。 これが中心的な要件です。オフの間は、作業対象のディレクトリを含め、システムファイルの保護が弱まります。時間は短くとどめ、その間は何もインストールしないでください。
• パスワードとエントロピーファイルの両方が正しくなければなりません。 間違った名前でコピーしたファイルは役に立ちません。間違ったファイルを /var/db/SystemKeys に置くと、得るものがないうえに、保護されたシステムディレクトリに書き込みをしたことになります。
• 明確にサポート対象外の機能です。 TN3137は、エントロピーファイルの場所、名前、形式はAPIではなく、いつでも変更される可能性があり、この手順は開発とデバッグ向けだと述べています。macOSのアップデートで構成が変わり、保存しておいたコピーが無効になることがあります。
• エントロピーファイルは機微な情報です。 パスワードと組み合わせればキーチェーンを解除できるため、2つを暗号化せずに一緒に保管したり、どこかに送信したりしないでください。
• コピー元のMacがない場合は解決しません。 Macが壊れた、またはそのディスクが消去された場合、コピーするエントロピーファイルは存在しません。

実行すべきでない場合

この手順を日常的なバックアップ方法として使ってはいけません。また、Macがキーチェーンのパスワードを要求し、それを思い出せないからといって、この手順に従うのもやめてください。新しいMacに移行したいのであれば、サポートされている経路は移行アシスタントです。キーチェーンの中身を知りたいだけなら、元のMacのキーチェーンアクセスで足ります。recoveryOSやターミナルの操作に不慣れな場合や、ITが当該MacのSIPを管理している場合は、手を出さないでください。これは、手元にまだある古いMacからの一度限りの復旧で、SIPを一時的に下げることを受け入れられる人にだけ向いています。

すでにアクセスできなくなった場合

ここまでの資料に基づく、偽りの希望を持たせない正直な状況は次のとおりです。

復旧できる可能性が高いもの

• iCloudキーチェーンに同期されているすべての項目。 新しいMacでApple Accountにサインインし、パスワードとキーチェーンをオンにして、項目が届くのを待ちます。
• 同じMacで作成したTime Machineバックアップにある項目。 Macがまだ手元にある場合、またはTime Machineのフルバックアップを同じMacに復元する場合、Oakley氏によればエントロピーファイルが含まれ、復元されます。
• macOS 26.3.1以前で作成されたキーチェーン。 Oakley氏は、これらは動作すると述べています。2026年3月より前の古いコピーがあれば、最悪の事態を想定する前に試してみてください。
• エントロピーファイルが残っているコピー。 キーチェーンを手動でコピーし、同じMacの /var/db/SystemKeys のバックアップもある場合は、前述の文書化された手順が使えます。

復旧できない可能性が高いもの

• macOS 26.4以降のログインキーチェーンで、エントロピーファイルなしで保存され、元のMacがもう存在しないか消去されているもの。 Oakley氏は、解除できる日は来ないと断言しており、Macに物理的にアクセスできなくなった場合、ロジックボードの交換、DFU復元の場合も同様だとしています。
• そのキーチェーンにしか保存したことがなく、同期も書き出しもコピーもないすべてのもの。

パスワードを回避できると謳う「キーチェーン復元」サービスにお金を払わないでください。問題はパスワードを忘れたことではなく、2つ目の入力が欠けていることであり、任意のコピーに対してそれを回避する方法を述べた資料は見つかりませんでした。

今できること:Macとバックアップドライブには手を付けず、次の順に確認してください。iCloudキーチェーン、パスワードマネージャ、Time Machineバックアップ、クローン、古いMac、そして最後にアカウントごとのリセット手順です。他のものを解除する鍵になるため、メールとApple Accountから始めましょう。

管理者およびキーチェーンのバックアップをスクリプト化している方へ

Macを管理している方や、~/Library/Keychains を毎晩コピーするスクリプトを使っている方は、26.4以降ではバックアップが不完全だと、そうでないと証明されるまで考えてください。

• スクリプトを監査する。 login.keychain-db だけをコピーするスクリプトは、使えないファイルを作り出している可能性があります。TN3137は、バックアップ製品は /var/db/SystemKeys/ ディレクトリ全体をバックアップすべきだと述べています。このディレクトリはSIPで保護されているため、通常ユーザーとして、あるいはSIPがオンのままrootとして実行するスクリプトでは読み取れない可能性があります。スナップショットベースのツールを除き、SIPがオンの状態で読み取る方法を述べた資料は見つかりませんでした。CCCに関するOakley氏の指摘は参考になります。CCCはボリュームスナップショットから作業するため、特別な手順なしでこのディレクトリが見えます。
• パスをハードコードしない。 TN3137は、名前、場所、形式はAPIではないと述べています。ソルトとパスの対応をツールに組み込むと、アップデートのたびに壊れる可能性があります。security show-keychain-info -s は診断とログ用途に限って使ってください。
• バックアップではなく復元をテストする。 対象で開けないバックアップはバックアップではありません。クリーンなMacまたは仮想マシンに復元し、テスト用のキーチェーンを解除してみるテストを作ってください。仮想マシンでこれを行う場合、Born Cityのテスト条件(異なるMACアドレス、仮想マシンごとに3コア以上のCPUと12 GBのメモリ)は参考になります。
• macOS 27を確認する。 管理下のデバイスには、Tahoe 26.7.1とGolden Gate 27.0.1の両方が混在している可能性が高いでしょう。挙動が同じとは限らないため、両方で復元テストを実施してください。デバイスがどのビルドを実行しているかは、macOSバージョンツールで確認できます。

よくあるトラブルと対処

コピーしたキーチェーンがパスワードを求め、正しいパスワードを拒否する

この症状は、Oakley氏、Apple Developer Forums、Born Cityが述べており、Born Cityはエラー -2147413984 を報告しています。あるフォーラム投稿者は、26.4で、元のキーチェーンは解除されたままなのに、コピーしたログインキーチェーンが解除を拒否する現象を確認し、Appleのエンジニアはフィードバックアシスタントのレポートを求めました。最も可能性が高い原因は、パスワードの間違いではなく、エントロピーファイルの欠落です。元のパスワードをリセットしないでください。コピー元のMacがまだ存在するかを確認してください。

パスワードの入力要求が繰り返されるのは別の問題

アカウントのパスワード変更や復元の後にプロンプトが出始めた場合は、Tahoeでのログインキーチェーンのパスワード要求に関するガイドを参照してください。エントロピーファイルを疑うのは、別のボリュームまたは別のMacからキーチェーンをコピーした場合に限ります。

show-keychain-info -s がソルトを出力しない

TN3137は、すべてのキーチェーンがエントロピーファイルを参照するわけではないと述べています。コマンドがソルトを出力しない場合、または /var/db/SystemKeys に一致するファイルがない場合、そのキーチェーンはエントロピーファイルを必要としません。古いキーチェーンにとっては朗報です。ファイルのフルパスを指定したか、このオプションに対応したmacOSのバージョンを使っているかも確認してください。26.5.2のMacのローカルmanページには -s フラグが載っていませんでしたが、AppleとOakley氏はどちらもこれを説明しています。

よくある質問

Appleは本当にログインキーチェーンの仕組みを変更したのですか?

AppleのテクニカルノートTN3137によると、macOS 26.4以降、ファイルベースのキーチェーンは保護されたエントロピーファイルを参照することがあり、解除にはパスワードとそのファイルが必要です。Appleはリリース時にこれを告知しておらず、Howard Oakley氏によれば、テクニカルノートの更新は、26.4が2026年3月24日に出荷されてから6か月後の2026年9月24日でした。

login.keychain-db を新しいMacにコピーすることはまだできますか?

単独ではできません。情報源は、ファイル単体では、正しいパスワードを入力しても別のMacでは解除できない点で一致しています。文書化された回避策は、SIPを無効にしたコピー先の /var/db/SystemKeys に対応するエントロピーファイルをコピーすることですが、Appleはこれをデバッグ用と位置付けています。新しいMacへの本格的な移行には、旧Macを起動した状態で移行アシスタントを使ってください。

iCloudキーチェーンと「パスワード」アプリにも影響しますか?

TN3137によると、iCloudキーチェーンはデータ保護キーチェーンを使用しており、これはファイルベースのログインキーチェーンとは別のストアです。そのため、今回の変更はログインファイルに関するものです。iCloudパスワードを通じて同期されている項目は、Apple Accountに結び付いています。消去する前に、ログインキーチェーンにしかないものを確認してください。危険にさらされるのはそれらの項目です。

Time Machineはキーチェーンを復元してくれますか?

Howard Oakley氏によると、Time Machineは26.4以降 /var/db/SystemKeys を含めてバックアップし、エントロピーファイルを自動的に復元するため、同じMacへの全体復元は動作するはずです。キーチェーンファイルを単独で復元する場合や、別のMacに復元する場合は、私が読んだ資料では扱われていないため、不明なケースとして扱ってください。

macOS 27でも同じですか?

不明です。Appleのテクニカルノートはリリースごとの区別をしておらず、27.0や27.0.1を検証した公開テストは、26.4の挙動と一致したリリース候補版での仮想マシンテスト1件を除いて見つかりませんでした。同じルールだと想定したうえで、頼る前に27で復元経路をテストしてください。Appleがエントロピーファイルの詳細をいつでも変更する可能性もあります。

エントロピーファイルなしでコピーしたキーチェーンを解除する方法はありますか?

私が読んだ資料に、そうした方法を述べたものはありません。Oakley氏は、26.4以降の古いログインキーチェーンでエントロピーファイルとともに保存されていないものは、解除できる日が来ないため削除したも同然だと述べています。誤ったパスワードでもキーチェーンの解除が成功するというサードパーティの報告(CVE-2026-43728)は、Appleのセキュリティのページでは確認されておらず、復旧手段として扱うべきではありません。

まとめ

macOS 26.4の実践的な教訓は、ログインキーチェーンが持ち運べるファイルではなくなり、システムの状態の一部になったということです。パスワードは依然として必要ですが、それだけでは十分ではなくなり、2つ目の要素は通常のツールからは見えないディレクトリにあります。Appleの移行・バックアップツールは、Oakley氏と独立した仮想マシンでの検証によれば、これを代わりに処理してくれるようです。手作業のコピー、クリーンインストールの後にドラッグ&ドロップで戻す方法、/var/db/SystemKeys を取り込まないサードパーティ製のバックアップでは、そうはいきません。Secure Enclaveの正確な役割や、macOS 27で異なるのかどうかなど、いくつかの詳細はまだ確認されていません。

そこで習慣を変えましょう。消去、交換、修理の前には、Time Machineでバックアップし、ログインキーチェーンの中身を確認し、重要なものをiCloudパスワードまたはパスワードマネージャに移して、別のデバイスから確認してください。新しいMacには移行アシスタントを使いましょう。新しいMacでログインが開けると確認できるまで、旧Macは手元に残しておきます。そして古いキーチェーンファイルしか手元にない場合は、あきらめる前に、そのエントロピーファイルがまだ存在するかどうかを調べてください。

関連記事:2026年のMacバックアップ戦略、移行アシスタントが止まる・遅い場合、Tahoe向けMacのセキュリティとプライバシーガイド