この「AI大法廷」は、Windows PC の認証混線事故を追った本編の「番外編」です。
- 複数アカウントを1台のPCで使っている
- 同じ Microsoft アカウントを複数端末で使っている
- 過去のアカウントが選択肢に出る
そんな環境では、一度認証が混線すると、別のアプリや端末、Store の購入履歴まで巻き込んで揺らぎが広がることがあります。
なぜ混線するのか。なぜ切り離しにくいのか。
その謎を、実際のログと証拠品をもとに裁いていくのが、この「AI大法廷」です。
本編では、365 Personal の使い回しをきっかけに、弟雀PC で起きた🦁（Brave）認証事故と、
連鎖的に 母雀PC まで認証崩壊に至った経緯を追いました。
PC は別。
Windows のログインユーザーも別。
それなのに「弟雀PC」で起きた事故が、何故「母雀PC」にまで波及したのか？
その答えを探してログを掘っていくと、TPM、WAM、PRT、Entra、そしてクラウド側の認証まで、次々と容疑者が浮かび上がってきました。
証言は食い違い、ログは NO 祭り。
消したはずのアカウントまで、👻（Ghost）になって再登場。
こうなったら仕方ありません――
関係者全員、法廷へ。
当時のスクリーンショット、資格情報、コマンドの実行結果を証拠品として、
AI諸君に改めて検証してもらうことにしました。
その名も【AI大法廷】
完全に遊び倒していますが、実証ログや内容は至ってまじめです。
なお、横文字を三歩で忘れる母雀自身のため、認証まわりの役割もできるだけ噛み砕いて進めます。
コマンドの検証が必要な方は、別記事の「ログ検証編」へお進みください。
さて、本日の出廷者はこちら。
- Copilot刑事（Windowsに詳しい現場担当）
- GPT検事（ログを掘る新米検事）
- Gemini弁護士（TPM被告の熱血弁護人）
- Claude判事（事実と推測を切り分ける裁判長）
そして被告人席には、TPM君。
先ほどから口笛を吹いている。
開廷：イベントビューアーの異常と甲第壱号証（dsregcmd /status）の罠
そもそも、なぜTPM君が被告席に座ることになったのか。
捜査の始まりは、母雀PC のイベントビューアーに残っていた異常の痕跡だった。.NET Runtime 1022、User Profile General 1509
など、複数の異常が確認された。
これより、第1回公判を開廷します。
本件、PC 認証揺らぎ発生における『TPM原因説』の事実関係を審理します。
それでは被告人TPM、前へ。
氏名は、TPM。
母雀PC 内のセキュリティモジュール領域、在住です。
職業は秘密鍵の保管と、認証の署名処理を担当しています。
俺は犯人じゃないでーす。
早速ですが、裁判長。
イベントログだけでは特定に至らない為、
定評ある診断手法として次のコマンドを実行しました。
dsregcmd /status コマンドの結果を提出します。
【甲第壱号証】 dsregcmd /status 実行後の記録
「AzureAdPrt : NO」
企業向け SSO に使う延長用認証トークン「PRT」の取得状態
「NgcSet : NO」
Windows Hello キーが設定されているか？
※NGC = Hello PIN や生体認証などに使う、次世代型のローカル認証
「PreReqResult : WillNotProvision」
Windows Hello for Business をセットアップする為の前提条件チェック
WillNotProvision ＝ 条件を満たさなかった為、PINを生成できません
「WamDefaultSet : YES」
「WAM」の既定 Web アカウントが設定されているか？
Claude判事
「これは何を示す証拠ですか？
いつの時点の？」
GPT検事
「🦁（Brave）事件から、10日前後の記録です。
当時、Windows Helloを含む認証トラブルが発生しており、
NgcSet : NO も確認されました。
これは、現在のユーザーに
Windows Hello キーが設定されているかを示す項目です。
この時点では原因を特定できませんが、
Helloに実症状があり、その鍵もNO。
鍵の保護に関わるTPM被告の関与は十分に疑われます。」
弁護士
ちょっと待ってくれたまえ！
母雀氏はすでに、
資格情報の削除、Hello PINの再設定、
ローカルアカウントへの切り替え ⇒ Microsoft アカウントへの再接続
まで試しています。
それでも、コマンドの結果変わらなかった。
- AzureAdPrt : NO
🚨クラウド側が PRT（認証トークン）の発行を「NO」！ - PreReqResult : WillNotProvision
🚨「プロビジョニング拒否」でビタ止まり！
これは、クラウド側が認証を拒んでいる証。
ローカル在住の TPM被告の異常を示す証拠にはならないでしょう！
異議あり！AzureAdPrt 、PreReqResult ともに、企業クラウドを診断する項目です。
個人用 Microsoft アカウントの母雀 PC で、
その2つを『クラウド側が認証を拒んでいる証拠』とするのは無理があります。
弁護士
「公式上の用途」ではなく、私は「実際の挙動」を読んでいるのだ。dsregcmd /status は、
PC と Microsoft サーバーの間を結ぶ通信状態を見る診断書のようなもの。
異常時には、ギークが診断材料として参照することもあります！
弁護人、
その見方は参考意見として記録します。
しかし、Microsoft 公式で公表されておらず、
再現性が不確かである以上、裁定の根拠にはできません。
弁護士
何故です？！
……ならば、はっきりさせましょう。
TPMをクリアします！！！
TPM被告が原因だというなら、一度クリアして再構築すればいい。
それでも状況が変わらなければ、
TPM被告を犯人とする説は崩れます！
は？
ちょっと待て！！
先生……、
それ本気で俺を守る手続き？
判決より先に、
刑の執行に突っ走ってない？
こうしてTPM被告は、判決を待たずしてクリア刑（Biosによる処置）に処された。
Win11のクリーンインストールとともに、
TPM被告は鍵束をすべて失い、NGCも再構築の運命へと投げ込まれたのである。
クリーンインストール後、再び dsregcmd /status を確認すると――
NgcSet : NO
PreReqResult : WillNotProvision
Gemini弁護士
「ご覧ください！
変わっていません！」
GPT検事
「確かに…」
Claude判事
「なるほど。
少なくとも今回、OSの初期化も TPMクリアも『とりあえずやっておけば治る』
というものではないことは分かりましたね。」
………。
俺、消され損じゃね？
WAMの証言：弟雀PC「OneNote混線」から始まった認証汚染
Claude判事
「続いて、弟雀PCで起きた認証トラブルが、
母雀アカウントへ与えた影響について審理します。」
♪～
Claude判事
「被告。
………随分と余裕ですね。」
TPM被告
「だって、俺、弟雀PC に住んでないし！」
GPT検事
「証拠品として、甲第弐号証を提出します。」
GPT検事
「①クイックノート：母雀365
②バックアップ：弟雀ローカル
③既定ノートブック：弟雀の OneDrive
これは、弟雀君が OneNote を使い始めた直後の記録です。
母雀氏の365アカウントは、Office の認証にしか使っていませんでした。
ところが、保存先には母雀365側の d.docs.live.net が入り込んでいます。
これは母雀氏の OneDrive を示すものです。
しかも〈同期が不完全〉の表示。
つまり、この OneNote の混線は
🦁Brave事件より前から、弟雀PCの認証経路が揺らいでいたことを可視化した証拠です。
裁判長。この事情を知るWAM証人に、証言を求めます。」
Claude判事
「認めます。証人を入廷させてください。」
Web Account Manager と申します。
弟雀さんのローカル在住です。
職業は、Windowsの認証ブローカーです。
Microsoft アカウントでのログイン認証を、
Windows 上のアプリへ取り次ぐ仕事をしています。
GPT検事
「弟雀PCでは、弟雀本人の Microsoft アカウントで、
Windows へログインしていました。
確認ですが、
弟雀氏のアカウント認証を、これまで取り次いだことはありますか？」
WAM証人
「はい、あります。」
GPT検事
「しかし、OneNote が参照していたクラウド保存先は、母雀氏の365側でした。
なぜ母雀氏の365として、取り次いだのですか？」
WAM証人
「複数候補があった場合、
使えるアカウント情報の中から、認証先を選びます。」
GPT検事
「なるほど。
OneNote は、WAM が持つ主軸アカウントを参照してクラウド認証を行うと聞きます。
あなたが主軸をアカウント選ぶ際、
Windowsのサインインアカウントを、優先しないのですか？」
WAM証人
「優先はしますが、必ずしもそれだけではありません。」
GPT検事
「では何を基準に、母雀氏のアカウントを主軸としたのですか？」
WAM証人
「過去のクラウド接続や、Office で使われているアカウント、
Windows が認識しているアカウントなど、
いくつかの状態をもとに、その時点で一番整合性がとれるアカウントを選びます。
それがユーザーの認識とは、違うこともあるかもしれません。」
弁護士
待った！
つまり証人自身が、なぜ母雀氏のアカウントだったのか断言できない？
ほら。WAMさんの話じゃん。
Authority出廷――クラウド側の異常か？端末側の異常か？
WAMが母雀氏のアカウントを主軸として扱った以上、
他の認証にも影響する可能性がある。
OneNote は、その認証の揺らぎが表面化した一例にすぎないということですね。
その経路は、端末の中だけで完結していますか？
クラウドサービスへの認証ですので、クラウド側も関与します。
GPT検事
「裁判長。
ローカル側だけでは、ここから先の認証経路を追い切れません。
クラウド側の証人を申請します。」
Claude判事
「認めます。
それでは証人、氏名・住所・職業をお願いします。」
氏名は Authority。
所在地は、Microsoft Entra ID（旧Azure AD）の認証基盤。
役職は、クラウド側の最終審判者です。
……お呼びでしょうか。
GPT検事
「先ほど WAM 証人への尋問で、
複数アカウントを使った認証経路が成立し得ることは確認できました。
個人用 Microsoft アカウントにも、
複数のアプリで認証状態を共有する SSO（シングルサインオン） の仕組みがあるのでは？」
クラウドのお偉方
「ございます。
個人用 Microsoft アカウントでも、Windows 上の対応アプリは、毎回パスワードを入力することなく、認証をご利用いただけますので。」
弁護士
SSO……？！
裁判長、第一幕の証拠品を再提示します。
AzureAdPrt : NO
弁護側はこの NO を、認証異常の根拠として主張しました。
企業版には、PRT（延長用トークン） を利用して
Windows・端末・クラウドをまたぐ SSO の仕組みが存在します。
そして個人版にも SSO 相当の仕組みが存在する。
ならば――
個人版にも、 PRT と同じような役割を担う仕組みが存在すると考えるのは自然では？
クラウドのお偉方
「個人用 Microsoft アカウントの内部実装を、
企業版 PRT と同一であるとは申し上げられません。」
Gemini弁護士
「本日、Authority 殿の付き人として、PRT さんも同席しているようですし、
証人として、証言を求めてもよろしいですか？」
ノーコメント。口止めされてるの〜
Gemini弁護士
「個人版にもあなたの親戚がいるのではないですか？
PRT はクラウド側の SSO に関わる仕組み。
本件も、PRT 側の不整合だったのでは？」
PRTちゃん
「私、口が硬いの〜」
Gemini弁護士
「裁判長！ 今のはほぼ自白です！」
Claude判事
「却下します。
黙秘は自白ではありません。
弁護人、勝手に被告を増やさないでください。」
少々よろしいでしょうか。
AzureAdPrt : NO は、
端末側に必要な鍵が存在しないことまで意味するものではありません。
鍵が存在していても、
AzureAdPrt : NO となる余地はあります。
つまり、
端末側に鍵はあっても、
現在の認証状態と整合していない可能性があるということですね。
クラウドのお偉方
「可能性としては残ります。」
Gemini弁護士
「・・・」
Claude判事
「では、その点は検察側の主張を認めます。
ところで……
被告、急に静かになりましたね。」
いや、
今までクラウドの話だったじゃん！
修理後の亡霊「Ghost Device」：マザーボード交換後も残る旧アカウントの影
GPT検事
「ここで、🦁（Brave）事件発生後の2台の足取りを整理します。」
両PC2台とも「資格情報の削除」と、不要な「Microsoftアカウントの削除」を行い、
単独アカウント運用へ切り替えました。
弟雀PCは、さらにユーザープロファイルを削除。
参照元ごと切り離したため、症状は軽くなりましたが
Defenderが認識せず、OneDrive 内で 同名📁フォルダが重複するなど、
異常は残ったままでした。
母雀PCは、ユーザープロファイルは残存。
その後10日ほどで、Hello 認証全滅、Google PIN認証エラー、PC起動時の人物マーク喪失など、
より深刻な認証異常が続きました。
その後、TPMクリア（Bios経由）とクリーンインストールまで行いましたが、
復旧には至っておりません。
弟雀君の OneNote の保存状況から見て、
2台は別々の Windows 端末でありながら、同時期に
クラウド側で同じ母雀氏の Microsoft アカウントへ接続していました。
その状況下で🦁（Brave）事故が起こった。
事件後、それぞれ単一アカウントに切り替えても、
程度こそ違えど、両方とも認証異常を抱えた。
つまり、クラウド上からアカウントを削除しただけでは、
端末側の認証状態までは元に戻らなかった。
問題は『端末側に何が残っていたか』なのです！
弁護士
異議あり。
クラウド側に齟齬が生じても、
直ちに端末側に影響を生じるとは考えにくい。
同じアカウントを使っていただけで、
弟雀PCの異常が母雀PCへ伝播した証拠にはなりません。
裁判長！
論点は、何故2台同時に
認証トラブルが起きていたのかではありませんか？
弁護側は、新たな証人を申請します。
異議を認めます。
ただし、共通のクラウド経路までは認定します。
それでは証人、入廷して下さい。
・・・・・
Claude判事
「……証人が透けていますが」
Gemini弁護士
「過去の資格情報の残骸です。
母雀氏は事件の直前、PCを修理に出しています。
- 資格情報を全削除
- SSDクリア
- マザーボード交換
- メーカー初期化
これらをすべて行っても、修理後のWeb資格情報に、
修理前のPCで使っていた👻アカウントが再び確認されています。」
Claude判事
「……証人、証言はできますか？」
証人Ghost
「・・・・・」
TPM被告
「無理だろ？
でも、裁判長！
その頃の俺、もう物理的にいません！
前任者の俺は、マザーボードの基盤ごと交換されましたから。」
Gemini弁護士
「その通りです。
この認証経路について、新たな証人に確認したいと思います。
母雀PC側のWAM証人、証言をお願いします。」
呼びました～？
Gemini弁護士
「早速ですが、WAM証人。
この👻（Ghost）に見覚えは？」
WAMおばちゃん
「ええ、知ってます。
以前は常連さんでしたから。」
Gemini弁護士
「この👻（Ghost）、あなたが取り次いだ？」
WAMおばちゃん
「いいえ。
少なくとも、私がこの子を連れてきた覚えはありません。」
Gemini弁護士
「裁判長。
修理の状況から見て、
旧SSD や 旧TPM にそのままデータが残っていたという説明は厳しい。
WAM 証人が認識していたかどうかは別として、
クラウド側から何らかの情報が再び下りてきたと考えるのが自然です。
母雀PCでは、端末側の問題を整理した直後に、認証の揺らぎが再発しています。
弟雀PCでも、
🦁（Brave）ブロック以前から『同期が不安定』との表示が確認されていました。
しかも、その OneNote は、クラウドサービスです。
少なくとも、クラウド側の関与を主要な仮説として扱うべきではないでしょうか。」
TPM被告
「そうだ、そうだ～♪」
GPT検事
「裁判長。
この旧アカウントの再出現について、
当時の捜査を担当したCopilot刑事の所見を求めます。」
Claude判事
「認めます。
Copilot刑事、入廷を。」
現場じゃ、
この👻（Ghost）、時々見かけるぜ……。
通称、Ghost Device 。
消したはずのものが戻った。
なら、どこかに元帳が残ってたってことだ。
TPM被告
「ほら、前任者の俺も、関係ないじゃん！」
Copilot刑事
「ローカルを焼いただけじゃ、帳簿までは消えねぇ。
だがな、その👻（Ghost）、生きていた頃と同じとは限らないぜ。」
GPT検事
「つまり、修理前の資格情報そのものが残っていたとは限らない。
クラウド側の記録を元に、
似て非なる認証状態が新しい環境へ再構成された可能性もある、と。」
Copilot刑事
「そういうことだ。」
Ghost
「・・・・・」
・・・・・
なるほど。
再構成された経路と、異常が生じた場所は別に考える必要がありますね。
その通りです。
クラウドから再構成された可能性は認めます。
しかし、それはクラウド側だけに異常があった証拠にはならない。
一時的に不整合となったクラウド側の情報を端末が拾い、
端末側に残る鍵や認証情報との間に、ズレが生じた可能性も残ります。
弁護士
待ちたまえ、諸君。
端末側の問題なら、TPMクリアはすでに試していますよね？
しかも、クリーンインストールまで行った。
それでも完全には復旧しなかった。
ならば、端末側に原因を求める検察側の主張には、無理があるのでは？
TPM被告
「よし♪」
GPT検事
「……。」
Copilot刑事の爆弾証言：Get-Tpmログ（TpmReady）と神コンボの神髄
待ちな！！
一同
「？？？」
確かに一度目は治らなかった。
まだ、捜査記録には続きがあるぜ。
TPM の足取りを追うなら、
「Get-Tpm」 コマンドの方を見るべきだな。
それと――WAM参考人、
隠し持ってる「帳簿」を出しな！！
ローカルの認証キャッシュを全部洗い直せば、
何か出てくるだろうさ。
人聞きの悪いこと、言わないでおくれよ。
誰がいつサインインしたか、どのトークンが生きてるか──
その記録があたし達 Wam の商売道具なんだよ。
……刑事、
それ、いつから知ってた？
Copilot刑事
「最初からだ。」
GPT検事
「我々が dsregcmd /status を見ながら悩んでいた時も、知ってたよね？
なぜ報告しなかった。」
Copilot刑事
「聞かれませんでしたので。」
一同
「このやろうwww」
ついに判決。神コンボ爆誕秘話「TPMクリアの正しい手順」とは？
【甲第参号証】WAM参考人の帳簿
ローカルの認証キャッシュやプロファイル情報について。
資格情報マネージャーを全部削除した後に、発見されている。
① OneAuth・IdentityCache・TokenBroker フォルダ
→ 母雀のメインアカウントの他、2体👻（幽霊）の情報を確認
② TokenBroker\Accounts フォルダ
→ tbacctファイルが3組ある。👻2体 ＋ 現役1体と思われる
GPT検事
「刑事、これは？」
Copilot刑事
「……見ての通りだ。
WAM 参考人の帳簿には、本来削除済みでいないはずの住民が２名、記録されていた。
そしてこの .tbacct。
こいつはアカウントの身元台帳みたいなもんだ。
Edge のプロファイル候補にも、しっかり同じ2名が顔を出していたしな。」
GPT検事
「WAM 参考人、この帳簿はこちらで預からせてもらいます。
では、甲第四号証に関しても報告を。」
【甲第四号証】刑事の捜査記録（Get-Tpm）
弟雀PCにおける、TPM 動作確認に関する時系列記録。
認証キャッシュクリア → 資格情報クリア → TPMクリア → 再起動 → Hello 認証
●Clear-Tpm直後●
TpmReady : False （TPM がまだ使用準備完了していない）
TpmOwned : False （OS が TPM の所有権を持っていない）
●再起動後●
TpmReady : True
TpmOwned : True
弟雀PCでは、
最初からこいつを見ながら処置を行った。
TpmReady : False
TpmOwned : False
――まだ準備ができてねぇ。
だから再起動させて、TPMを覚醒させたんだ。
つまり、
TPMクリア直後と、PCを再起動後では、実際に状態が変わった、と？
ログの通りだ。
古い帳簿（認証キャッシュと資格情報）を削除して、
👻（過去の残骸）ごと始末する。
その後に
TPMクリアで金庫を空にして、再起動で受け入れ準備を整え、
即座に新しい鍵（Hello 再構築）にかけ替える。
神コンボの神髄は、除霊だ。
この順番を崩すと、👻（Ghost）に席を空けることになるぜ。
でも……待ってください。
母雀PCでは、先の弁論で「BIOSからのTPMクリア」を行いました。
その当時の TPM被告の状態を記録したログは？
ない。
Get-Tpm を取ってなかったからな。
それに、BIOSでそのままOSを燃やしちまったから、
再起動する間もなかったしな。
被告が準備中のまま鍵をかけて、
👻（Ghost）にのっとられたんだろうさ！
俺を消す前に調べろよ！！
弁護士
ぐぬぬ
裁判長。
母雀PCでは我々立会いの下、TPMクリア自体は行いました。
しかし、TPMクリア単体ではなく、
資格情報削除と再起動を含めた一連の作業を、
再構築手順として評価すべきでした。
ならば、同手順を以て、母雀PCでも再現するか試す価値があります。
その通りですね。
では判決を――。
主文。
TPM被告の単独犯行は、これを認めません。
ただし、一度目の処置には手続上の不備があったものと認定します。
よって、正しい順序による再構築を命じます。
弁護士
……被告には、身をもって無実を証明してもらう為にも、
再現実験には合理性があります。
やりましょう！！
弁護士ォォォ！！
こうして神コンボは爆誕し、
弟雀PC・母雀PCともに安らぎを得たのである。
ーーーーー 完 ーーーーー
●関連リンク●
第一章：Microsoft 365 を買って3時間でPCがあの世へ逝きかけた話｜認証混線事件簿 （本編）
第三章：【実証データ】認証揺らぎはどこまで見える？ Get-Tpmとdsregcmdで追った端末側の回復
