【実証データ】認証揺らぎはどこまで見える？ Get-Tpmとdsregcmdで追った端末側の回復

本記事は、Microsoft認証トラブルを追った三部作の最終編です。
前編で起きた認証混線の経緯 ＆ 復旧、中編「AI大法廷」で整理した原因 ＆ 仮説を踏まえ、
今回は Get-Tpm ＆ dsregcmd /status の実ログから、端末側で何が変わったのかを検証します。

Get-Tpmログで暴く「TPMクリアと再起動」の覚醒メカニズム

🦁（Brave）の認証事故をきっかけに、我が家では2台のPCが連鎖反応のように認証不調へ入り、
最終的には初期化まで行うことになりました。

アカウントを入れ直し、資格情報を削除し、TPMをクリアし、Windows Hello を再構築。
見た目上は Windows も正常に動き、OneDrive や Store の購入履歴も異常なし。

それでも、dsregcmd /status を叩くと「NO祭り」は終わらない――。
一方で Get-Tpm を見ると、TPM内部の状態は明確に変化していました。

三部作の最後となる今回は、
「TPMが正常化しても、なぜクラウド側の認証揺らぎは残ることがあるのか」
を、実際に取得したログから追っていきます。

認証トラブル時に TPM や Hello を何度も触り直すと、復旧操作そのものが新しい認証不整合を生むことがあるため、踏みやすい💣地雷ポイントも置いておきます。

dsregcmd /status が「NO祭り」から動かない理由と、裏読みの指標

アカウントを削除し、資格情報を消し、何度もサインインし直しては叩いたコマンド。
それが dsregcmd /status でした。

しかし、画面に表示されるのは何度やっても変わらない「No祭り」だけ。

dsregcmd /status は本来、
Entra ID（旧Azure AD） のデバイス登録や、SSO 状態を確認する為の組織向けのコマンド。

個人PC でも一部の項目は参考になりますが、
表示された NO をそのまま「個人MSA の異常」と読むことはできません。
むしろ個人MSA では多くの項目が NO になるのが正常ですが、裏読みには使える指標だと思います。
特に NgcSet（Helloキーが構成されているか） は個人でも意味が一致します。

ただ──
事件解決後の母雀PCでは、Hello 認証は絶好調なのに、ここは NO のまま。

物理故障を修理し、認証キャッシュ＆TPMクリアまで実施済み。
OneDrive も Store の購入履歴も正常なのに、
dsregcmd /status の「NO祭り」は変わりません。

Hello 自体はローカルで完結するので実害はなし。
ただし、クラウド側で整合性がとれる前提条件が揃っていないため、
結果として「NO」となっていると考えられます。

クラウド側が「このPCは怪しい」と判断している状態なら、認証がふらっと揺らぐのも道理。
この「NgcSet ＝ NO」は、
認証揺らぎを可視化するひとつの手がかりではないでしょうか。

残念ながら、クラウド側の不整合はユーザーでは触れない領域です。
ユーザーができるのは 端末側の前提条件を整えることだけ。
その指標の1つが Get-Tpm です。

Get‑Tpm は
「TPM（物理セキュリティチップ）が鍵を受け取れるかどうか」を見るコマンド。

「TPMクリア直後」の他、
認証揺らぎでも、裏の物理チップが TpmReady : False になることがあります。

TPM が鍵束を手放す方法は限られていて、
OS上でどうあがこうと（プロファイル削除・クリーンインストール等）、
部分的に参照を失わせるだけで、完全消去にはなりません。

正しい「TPMクリア」により、端末側の前提条件が初めて整います。

【動かぬ物証】PowerShell（Get-Tpm）が捉えた「TpmReady : False」からの完全覚醒

TPMクリア直後の再起動の必要性

「TPMクリア → 再起動（PC再起動による、OS起動）」
によって、どう変わったかをご覧ください。

弟雀PCで実際に取得した Get-Tpm の生ログです。
Clear-Tpm を叩いた直後と、再起動後（＋ Hellow PIN生成）の差分がこちら。

ターミナル（管理者）または「PowerShell」で、直接 Clear-Tpm コマンドを叩いた直後は、
TpmReady : False（鍵を叩き壊しただけの状態）です。
TPMクリア（Clear-Tpm）直後に「PCの再起動」を挟んで OS を起動させ、
受け入れ準備完了状態（TpmReady と TpmOwned を True） に覚醒させなければいけません。

【ログの差分比較と💣 地雷ポイント】

• TpmReady : False → True
  TPMクリア直後は False なので、まだ鍵を受け入れる準備が整っていない証
• TpmOwned : False → True
  自動プロビジョニングで後から True になることがあるので、少し様子見
  💣 TpmReady と TpmOwned が両方とも True なら、TPMの再構築はひとまず完了
  片方が False のままの場合は 1～2 回だけ再起動して再確認し、それでも変わらなければポリシーやBIOS/UEFI など、別の原因を切り分けます
• AutoProvisioning : Enabled のまま
  💣 Enabled にならない場合も、組織ポリシーの名残の可能性があります
  ※今回の検証機は 元学校PC ですが、Enabled でした
• LockoutHealTime : 16分40秒 → 2時間
  通常の2時間のインターバルに移行
  現在の待ち時間を示すものではありません
  TCG の TPM 2.0 リファレンス実装における初期デフォルト値（1000秒 / 3回）と一致しており、TPMクリア直後の初期状態が一時的に露出したものと考えられます
• LockoutMax : 3 → 32
  通常モードに移行
  クリア直後の数値は、 LockedOut = False / LockoutCount = 0 なので、
  完全ロックではない
• RestartPending : True
  機種次第。本機では平時からTrueなので、この値だけで再起動ループに入るのは地雷💣

💣元組織PC や 中古PC では、昔の管理ポリシーが残っていることもあります。
原因切り分けまではOKとして、レジストリやBIOSを触り始めたら、そこから先は別記事級の沼です。
復旧操作を重ねるほど認証状態がさらに揺らぐこともある為、途中で次の操作を足すより、まず一連の手順を完遂し、時間経過による反映も含めて評価した方が安全です。

TPMクリアの3つの方法と注意点（tpm.msc / PowerShell / BIOS）

TPMクリアには実は 3種類あって、踏みやすい地雷も違います。

① 一番安全な、GUI（ローカルコンピューター上のTPM管理）からのクリア —

「Win ＋ R」押下後、「tpm.msc」と入力。
「ローカルコンピューター上のTPM管理」が開くので、そこから「TPMをクリア」をクリックする方法です。

• Windows 標準の管理ツール
• TPMクリア後は OS の再起動が必ず要求される（画面に案内が出る）
• TPMReady / TpmOwned が True になる

💣地雷：ほぼ無し。おすすめの方法です！

つまり今回の結果は、
端末側を正常な状態まで戻せば、実害は解消できる。
しかし、複数の Microsoft アカウントを含む認証状態が、同時に安定するとは限らない。
その状態と、dsregcmd /status の「NO祭り」が妙に噛み合って見えるのも事実です。

② PowerShell（ターミナル）での「Clear‑Tpm」コマンド

母雀が最初に踏んだ地雷。
AIに聞くと、直接このコマンドだけを単独で提示してくることがあります。

• PowerShell で clear-tpm を実行
• 自力で再起動するまでは、TPMReady / TpmOwned が False のままになる

💣地雷：自力での再起動を忘れがち / コマンド実行後の不安定な状態のまま、他の認証作業が可能

「認証系の再構築」はまとめて作業したくなるので、
TPMクリア後に「資格情報の削除」や「Hello の再設定」をやってから再起動しがちですが、
こちらは全AI達が一致して非推奨ルート。
バックグラウンドで稼働中のシステムがリトライを繰り返し、さらに不安定さが増すのだとか。

受け入れ状態が整う前に次へ進むとどうなるのか。
本編にも書きましたが、母雀の実機では、そのまま PC 全体の認証崩壊にまで発展しました。
TPMクリア直後の再起動は必須と言えます。

③ BIOS/UEFI からの「TPMクリア」

２度目に踏んだ地雷。
メーカー実装の「物理クリア」です。

• マザーボード側の TPM初期化
• TPMの物理初期化

💣地雷：BIOSを閉じた後に自動再起動（OSの再起動）するかどうかは、メーカー次第

「BIOSの終了」は、画面が暗転して再起動っぽく見えますが、「OSの再起動」とは限りません。
母雀が踏んだ地雷は正にここで、そのまま「クリーンインストール」に進んで失敗。
同様に、BIOSを閉じて直に PC に「サインイン」してしまえば、その時点で Pin の作成（Windows Hello の作成）が要求されます。
つまり受け入れが整っていない状態での Hello 構築になって、アウトな訳です。

正しい「TPMクリア」の手順とは？

TPMクリアの最重要ポイントをまとめると――

• TPMクリア直後に、PC の再起動を行って、受け入れ準備を整える必要がある
• TPMクリアは、認証キャッシュ＆資格情報の削除 とセットで行う

この２点に尽きると思います。

💣やりがちな「TPMクリア ＋ Hello 再構築」だけでは、
👻（古い資格情報や認証の残骸）を残したまま、新しい認証状態を組み上げてしまうため、
後から再び認証が揺らぐ余地が残ります。

不要な資格情報を整理する為に行うのが、認証キャッシュ＆資格情報の削除です。

過去の資格情報との決別を、目視で確認する方法

認証キャッシュクリア → 資格情報クリア → TPMクリア → 再起動 → Hello 認証

TPMクリアは、ここまでを一連の流れで行って初めて意味を成します。

認証キャッシュ＆資格情報のクリア方法については、本編で書いたのでここでは割愛しますが、
（具体的な削除手順はこちら）

• OneAuth・IdentityCache・TokenBroker 📁フォルダのリネームによる封印
• TokenBroker\Accounts 📁フォルダ内のリセット

上記の認証キャッシュをクリアしたら、
Edgeを開いて右上の人物アイコンから「新しいプロファイルを追加」を開いてみてください。
👻候補が消えていれば成功です！

なお、この時点ではサインインせず、候補が消えたことだけ確認して、資格情報を削除します。
必要な Microsoft アカウントの再認証は、一連の全工程が完了してから行って下さい。

💣「使用中」と表示されてリネームできなかった場合は、無理に継続しなくて構いません。
そのままTPMクリアまで進み、再起動後、Microsoft 系アプリを開く前に、
リネームできなかった📁フォルダーの封印をもう一度試してください。

認証キャッシュ ＆ 資格情報のクリアは、TPMクリアの前後どちらがいい？

なぜ「もう一度リトライ（2回目のお掃除）」が有効なのでしょうか。
ざっくり表現すると――

1回目（TPMクリア前）：
システムが稼働中なので、バックグラウンドのサービスがキャッシュファイルを握りしめていて、
「使用中エラー」になったり、消し残しやバグが発生しやすい。
ただし、Microsoft 公式ではこちらを推奨。
理由は、TPMクリア後に古い資格情報が残っていると、Windows が古いトークンを使おうとして
新しい TPM鍵と整合しない可能性があり、ログイン時にエラーが出る可能性があるから。

TPMクリア ＋ 再起動 ＋ Hello（PIN）登録：
ハードウェアの鍵がリセットされ、全認証セッションが切断（気絶）。
古い鍵束との参照を断ち切り、新しい鍵で OS と再リンク。

2回目（再起動直後）：
誰もファイルを握っていない無風状態になるため、
1回目で生き残ったしぶといゾンビファイルも、今度はワンクリックで完全にゴミ箱へ叩き込める。
……最初から、こちらの再起動直後一択でもいいんじゃないか説もある。

新品登録
跡形もなく除霊された世界で、Hello（PIN）を、再登録（必須じゃないけど、整合性はとれる）。

Get-Tpmの読み違いで認証沼へ？｜RestartPendingとLockoutHealTimeの注意点

再起動直後の Hello（PIN）の再構築を「キャンセル」すると、どうなるか？

Win10 の時代は、
「TPMクリア → 再起動 → Hello 生成のキャンセル」が許されていました。
古い鍵の参照が残る可能性があるため、できれば以前のように
「TPMクリア → 再起動 → 認証キャッシュ ＆ 資格情報のクリア → Hello 再構築」
を試したいところ。
でもWin11 では、💣再起動直後の Hello（PIN設定）で「キャンセル」すると、
クラウド側との不整合が起きやすいようです。

TPMクリア → 再起動 → 認証キャッシュ ＆ 資格情報のクリア → ×
ここまでは問題なく行けるのですが、Hello 再構築で認証エラーが発生（2回検証）。
「Microsoft パスワードマネージャーにアクセスできません」
となり、数十分待機したものの解消できず、そのまま６時間ほど放置したら通りました。

母雀PCで、TPMクリア直後の Hello（Pin）生成を「キャンセル」した時の生ログはこちらです。

【通常時】

• RestartPending : True
  — 本機では平常時から継続して True
• OwnerAuth : [空欄]
• LockoutHealTime : 2 hours
• LockoutCount : 0
• LockoutMax : 32

【Helloキャンセル直後】

• RestartPending : True
  —★OS が再起動待ち？
• OwnerAuth : [*********]
  — セキュリティ上の保護処理が未完了の為、露出
• LockoutHealTime : 10 minutes
  — ★ダウンタイムが10分？
• LockoutCount : 0
  — 完全ロック状態ではない
• LockoutMax : 31
  — 1カウント分減っている？！

平常時との差分で分かることは、
RestartPending = True　は、本機では平常時から継続して確認されているため、
この値だけを見て💣再起動沼に陥るのは地雷です。
Dellでも、TPMクリア後に RestartPending = True が残り続ける事例が公式に確認されています。
少なくともこの値は、機種やBIOS実装の影響を受ける場合があるようです。

また、LockoutHealTime = 10 minutes となっていましたが、
実際には 10分以上待っても、 Hello の再生成が通りませんでした。

LockoutMax = 31 についても、
再試行のたびに30、29と減少したわけではなく、なぜか毎回 31。
LockoutCount = 0 なので、Hello再構築中だけ一時的な待機状態へ入っていたようにも見えます。

ここから導き出せる仮定は――
LockoutHealTime : 10 minutes　の表示は、
Hello と TPMの鍵情報のリンク構築中に、Windows 11の現行実装値が、一瞬だけチラ見えした可能性が高いということです。

今回の検証結果として、
TPMクリア後にHello作成をキャンセルし、その後で資格情報を削除して再生成する手順は、
安定した復旧手順とは言えないと判断して良いと思います。

TPMロックアウトの回復：公式10分と実機2時間の食い違いは、なぜ起きる？

当ブログでは、軽傷2時間、中症6時間、重症72時間待機をおススメしています。
72時間以上様子を見て、それでも揺らぎが解消しなければ、TPMクリアの使用が視野に入るという位置づけです。

２時間は、ネット記事の一般論と、TPM 2.0 の通常値（2時間）を踏まえた目安。

６時間の根拠はこちら。

• TPM 2.0 の回復時間を考慮。今回のログから考察すると、
  LockoutHealTime の時間は、機種ごとに新旧の固定値がある（検証機は2時間で固定）
  TCGレガシー準拠（旧仕様）なら
  2時間 × 3回（警戒モード中は、完全ロックアウトまでの失敗許容回数が3） を回収
  固定値以外は、プロビジョニング中過渡期の、暫定値と推察（危険時に減るのはおかしい）
  （Hello キャンセル時の 10分の表記も、Clear-Tpm 直後の 16分40秒 も、かりそめ値）
• Microsoft 公式（新仕様）なら、
  10分 / 32回 → 約5時間20分 を全回収
• 実機の Hello再生成エラー
  → 数十分では直らず、約6時間後に通った（自然回復）

結論：実害は消えた。でも「認証揺らぎ」までは消えていない

TPMクリアのコンボ実施後、Store、Xbox、OneDrive はすべて正常化し、PIN や Windows Hello も問題なく使えるようになりました。

少なくとも、普段PCを使う上で、困っていた実害は解消しています。

Get-Tpmでも、
TpmReady : False 　→ True
TpmOwned : False　→ True
へ変化し、端末側の TPM が再び利用可能な状態まで整ったことは、ログでも確認できます。

ただ、認証まわりが完全に無風になったわけではありません。

メインの Microsoftアカウント（MSA） はかなり安定した一方、ゲーム専用サブアカウントでは、
今でもふらっと人物アイコンが消えることがあります。

時限爆弾💣のタイマー音が、かすかに聞こえてくるかのようです。

最後に：クラウド様のご機嫌と、端末側の限界——そして自立へ

今回の一連のトラブルで、
どこで問題が発火し、どこが致命傷になりやすいのかが、ようやく見えてきました。

今回地雷を踏んだ「OneNote」は、別格に危険枠。
通常のノートブック保存先や、バックアップ先は変更できます。
ところが、クイックノートの保存先だけはユーザー側で変更できません。
複数の Microsoft アカウントが入っている環境では、ここが WAM の認証状態と噛み合って、
意図しないアカウントへ同期される余地があります。

我が家でも実際にアカウント混線が発生し、認証崩壊を招きました。
Microsoft 365 Personalを家族間の複数アカウントで使い回すような運用が、
認証揺らぎの可能性を多分に秘めていることを、身をもって勉強しました。

認証揺らぎはアプリ単独の不具合では済まずに、PC 全体に波及するのが怖いところ。
OneDrive や、Store（購入履歴）、Edge同期、Outlook など──ダメージは深刻です。
一度クラウド様のご機嫌を損なうと、ユーザーは回復を祈ることしかできません。

我が家では、マザーボードを修理交換し、SSDも初期化、Windowsを初期化したうえで、
新しい Microsoft アカウントから再出発しました。
それでも1か月も経たないうちに、認証状態は再び不安定に……。

端末もアカウントも新しくすれば必ず安定する、というほど単純ではありませんでした。
タイミングがかみ合わないと、認証揺らぎを引きずる可能性もあるのです。

振り向いてくれないクラウド様へ、
いつまでもラブコールを送り続ける必要はないのかもしれません。
端末側でできることをやり切ったら、次は自立の準備です。

●関連リンク●
第一章：Microsoft 365 を買って3時間でPCがあの世へ逝きかけた話｜認証混線事件簿　（本編）
第二章：認証の運命を裁く大法廷：TPM被告が語る真実の記録