2026年3月の Windows 11 累積更新「KB5079473」が公開されました。Secure Boot 証明書更新・WDAC の安定化・Explorer 検索改善など、OS の基盤に関わる重要な内容が含まれています。特に Copilot+ PC（Ryzen AI / Snapdragon X）を利用しているユーザーにとっては、AI ワークロードの安定性に間接的に影響する部分もあり、見逃せないアップデートです。

KB5079473 の概要

主な改善点

– Secure Boot 証明書更新の対象拡大 – Explorer 検索の信頼性向上 – WDAC（Application Control）の COM 許可処理改善 – Emoji 16 対応、ネット速度テスト機能追加

不具合対応

– 検索インデックス破損の修正 – WDAC の過剰ブロック修正 – Windows Update の段階的配布ロジック安定化

考慮点

– Secure Boot 証明書更新は段階的配布 – WDAC を独自運用している環境では検証推奨 – 複数ドライブ構成ユーザーは検索改善の恩恵大

Copilot+ PC への影響

AI 基盤への間接的効果

– Secure Boot 証明書更新 → AI ランタイムの署名チェック安定 – WDAC COM 許可改善 → ローカル LLM の初期化安定 – Explorer 検索改善 → モデル配置が複数ドライブでも快適

不具合対応

– WDAC の過剰ブロック減少 – Secure Boot 証明書更新による DLL 読み込み安定化

考慮点

– NPU/GPU の AI 機能は今回の KB では更新なし – LM Studio などローカル LLM を使うユーザーは恩恵大 – 最新 UEFI 実装により証明書適用が早い傾向

「概説最終章」Ai共生：クラウドAIのとん挫をローカルAIで救え！ Gemma 2×Llama-3-Swallowで構築する、最強のプライベート・インテリジェンス

AI共生をテーマに、Geminiとの対話を続けてきた元ITC・セキュリティプレゼンターが到達した、クラウドAI依存の限界とローカルAIへの移行プロセスを公開。Ryzen AI 9という強力な土台に、Gemma 2とLlama-3-Swallowという「二つの脳」を使い分け、198スレッドの機密情報を完全オフラインでPL法リスク分析へと昇華させる──。情報の主権を取り戻す、真のAI共生の最終回答。

イイネ.biz

2026.03.09

一般PC への影響

新機能

– Emoji 16 – ネット速度テスト – Explorer 改善（Copilot+ PC と同様）

不具合対応

– WDAC COM 許可改善 – 検索インデックス破損修正 – Windows Update 安定化

考慮点

– 古い UEFI の PC では証明書適用が遅れる可能性 – WDAC 非使用環境では影響小

編集後記：TPM Event ID:1801 の本質

読者へのメッセージ

これまで Secure Boot 証明書更新や TPM Event ID:1801 に関連するKB5077241、KB5077181、KB5074105で記事を 5本にわたり書いてきました（1202PV, 106PV, 617PV, 290PV, 54PV）。多くの方が同じ問題に悩み、故障かもしれないと不安を抱えながら情報を探していることを知りました。（私自身もまた被害者でした。）

今回の記事が、Microsoft や OEM にも届き、ユーザーが不必要な不安を抱えない世界に近づくことを願っています。

「さあ休もう」と思ったその瞬間、Windows Updateが牙を剥きました。

今回ターゲットとなったのは、本ブログの検証機Aとして不具合を追い続けている Ryzen 9 8945HS搭載のGEEKOM AE8 です。

シャットダウン時に表示された「更新して再起動（4分）」という言葉を信じて選択した結果、待っていたのは10分経っても、15分経っても電源ランプが消えない絶望的な沈黙でした。17分が経過し、ついに耐えかねて「電源ボタン長押し」による強制終了を断行。

しかし、悪夢はそこでは終わりませんでした。再起動後、ログインまでに立ちはだかったのは2回にわたるBIOS画面と執拗な「更新中」の表示。

一体、何のための「更新」なのか。なぜ実機ユーザーがここまでリスクを負わなければならないのか。

本記事では、最新ビルド 26200.7922 (KB5077241) がAE8環境で引き起こした凄惨な挙動を、一切の妥協なしに晒します。

導入：Intel機（x360）の陰で、Ryzen機（AE8）を襲う悪夢

• 繰り返される悲劇: これまでKB5077181で「ブラックアウト」を繰り返してきた検証機A（AE8）が、またしても最新パッチで牙を剥きました。
• 「4分」の嘘に翻弄: 平穏なシャットダウンを奪った「更新して再起動」の17分※間に及ぶフリーズ状態を記録します。（「更新して再起動（4分）」を選択後、OS側からの反応が一切消失。 ※17分間にわたり電源LEDは点灯しているものの、ディスクI/Oや画面出力に変化がない「完全なフリーズ状態」となったため、ハードウェア破損のリスクを冒してユーザーが手動で電源ボタン長押しによる強制終了を断行しました。
• この強制介入なしには、更新プロセスは永久に完了しなかったと推測されます。強制終了後もBIOS画面への遷移＆更新を2回繰り返すなど、システムの整合性が著しく脅かされました。）

AE8（Ryzen 9）特有の執拗な再起動プロセス

• BIOS三重苦: 強制終了後の2回にわたるBIOS画面と、終わらない「更新中」の表示。x360（Intel）では見られない、Ryzen機特有の不安定な更新挙動を晒します。
• 無意味な「成功」通知: 命からがらログインした後に表示された「正しくインストールされました」という文字の空虚さを追求します。

結論：RyzenユーザーはKB5077241を避けるべきか

• 実機検証の結果: 本日の事象（Build 26200.7922への更新）により、AE8環境における最新Windows 11 25H2の危険性がさらに増したことを警告します。
• MSへの抗議: フィードバックHubだけでは足りない、実機ユーザーの「時間の損失」をブログという公共の場で強く主張します。

SlimStatのログでも「AE8 25H2 不具合」といった特定の組み合わせで探しているユーザーが見受けられます。今回の件は、その層にとって決定的な回避シグナルになります。

【実機比較】MSはRyzenを放置しているのか？

今回の KB5077241 適用時における、Intel機（sz6）とRyzen機（AE8）の挙動の差をまとめました。

分析：AE8ユーザーへの警告

「正しくインストールされました」という通知とは裏腹に、Ryzen環境におけるアップデート・プロセスの崩壊は明らかです。
x360で培った「安定への知恵」が、このAE8というハイエンド機においては、MSの最適化不足によってことごとく打ち砕かれています。

Feedback Hub に追記

【問題の詳細】
Ryzen 9 8945HSを搭載したGEEKOM AE8において、KB5077241 (Build 26200.7922) の適用中に重大なハングアップが発生しました。

「更新して再起動（4分）」を選択後、OS側からの反応が一切消失。
17分間にわたり電源LEDは点灯しているものの、ディスクI/Oや画面出力に変化がない「完全なフリーズ状態」となったため、ハードウェア破損のリスクを冒してユーザーが手動で電源ボタン長押しによる強制終了を断行しました。

この強制介入なしには、更新プロセスは永久に完了しなかったと推測されます。強制終了後もBIOS画面への遷移を2回繰り返すなど、システムの整合性が著しく脅かされました。

同様のビルドを適用したIntel機（i7-1165G7）では数分で正常終了しており、本件は明らかにRyzen環境における更新プロセスの致命的なバグです。早期の調査と修正を強く求めます。

## 追加の技術補足（MSへの強い抗議用）
フィードバックのコメント欄や追記できる場所があれば、以下の「事実」も添えてください。

「4分」という虚偽の予測表示: ユーザーに安全な更新を誤信させ、結果として17分以上のフリーズを強いるUXの欠陥。

ログ上の「成功」判定: 強制終了という異常な手段でしか復旧できなかったにもかかわらず、OS履歴上では「正しくインストールされました」と記録される不整合。

追記情報

AE8の「沈黙」を多角的に検証する

【比較】Ryzen 9 8945HS機・三者三様の挙動

まずは、同等スペックの他社機と比較して、AE8がいかに「極端な」状態にあるかを可視化します。

※。リスク含みの強制終了までの時間であり。何も操作を行わなかった場合、ずっとブラックアウト状態だった可能性は否めない。

考察

こうして並べると、AE8のスタイリッシュな金属筐体と超小型設計が、Ryzen 9の高負荷時（Windows Update時）の熱処理や電力管理において、他社よりもシビアな挙動を招いている可能性が浮上します。

Amazonレビューに記された「救済措置」の先行事例
調査の過程で、Amazonのカスタマーレビューに重要な記述を見つけました。

• 事例： 購入4ヶ月でスリープ復帰不可（画面真っ暗）が発生。
• 対応： 販売店（GEEKOMストア）へ連絡後、迅速に代替PCとして上位機へ交換されたとのこと。

　私のAE8で起きている「3回連続のアップデート失敗と17分間^※のフリーズ」も、単なるOSのバグではなく、ハードウェア（個体）の限界や設計上の不備である可能性を裏付ける内容です。（最初にMSへの怒りをぶつけたのは間違い？でも、３回連続でKB*を当てたことが引き金になっていることは確かなことだし。リスキーなことの連続だし）

3年保証の行使？

これまでの実録データ（長時間の沈黙（ブラックアウト）、BIOSループ、強制終了の記録）をすべて揃え、GEEKOMストアへ「3年保証」に基づく点検・交換の相談をAmazon経由で送付しました。

AIにコードを相談し、返ってきた答えをエディタに貼り付ける。

この一連の作業をボタン一つで自動化できる技術、それが「File System Access API」です。

しかし、この便利なAPIを知ったとき、私は立ち止まりました。

AIが「無駄な手間」と呼ぶその数秒間、私は「次はどう動かそうか」と構成を練り、コードの行き先に悩んでいたからです。

一見すると非効率な「コピペ」や「ファイルを探す手間」の中にこそ、実は納得のいくものづくりに欠かせない、大切な時間が隠れていました。今回は、AI（Gemini）との対話を通じて再発見した、「あえて自動化しないことで守られる、試行錯誤の価値」についてお話しします。

ブラウザとPCの境界線に立つ技術

WebブラウザからPC内のファイルに直接アクセスし、上書き保存まで可能にする「File System Access API」。

この技術を知ったとき、私は一つの期待を抱くと同時に、大きな疑問にぶつかりました。果たしてこれは、私の今の作業を本当に豊かにしてくれるものなのだろうか？

今回は、AI（Gemini）との対話を通じて見えてきた、この技術の正体と「効率化の先にある大切な時間」についてお話しします。

対話セクション

すべては「素朴な疑問」から始まった

この記事の出発点は、私がGeminiに投げかけた、あるシンプルな質問でした。

私：

File System Access APIの
メリット、デメリット、セットアップ方法や使い方を教えて。

Gemini：

File System Access APIを使えば、ローカルファイルを直接上書きできるので、AIが生成したコードをボタン一つで手元のファイルに反映できる。コピペの手間がゼロになり、爆速で開発できる･･･

そして、ここから更に突っ込んだ問いかけをしたのですが、････

「中略:･･･「単に便利だと言われるほど、自分の手が離れていく感覚に違和感を覚えたのです。そこで、私はこんな疑問をぶつけました。」

ここからは、Geminiとの会話に於いて、私の問いから始まる対話の一部・途中から載せています。

効率化という言葉への違和感

AIが提示した「爆速」というメリットに対し、自分の実感をぶつけてみました。

AIが「不要な手間」と呼んだものは、私にとっては「新しいアイデアを熟成させるための、かけがえのない時間」だったのです。

私：

1.「GEMINI」などのAIにコードを書いてもらう。
2.コードを「コピー」する。
3.自分のエディタ（VS Codeなど）を開く。
4.該当箇所を探して「貼り付け」して「保存」する。
・・ここまではよく利用しています。

Gemini：

なるほど、非常にクリアな作業フローですね！現在の「コピー＆ペースト」というスタイルが確立されている場合、確かに「わざわざ新しいAPIを使うメリット」が見えにくいのは当然です。

結論から言うと、あなたの使い方は**「今のままでも十分に正しい」です。ただ、File System Access APIを使うと、その「動作確認・検証」までの往復回数が多い場合に、劇的なスピードアップ**を感じられるようになります。

「メリットを感じられるかどうか」の分かれ道は、以下の3つのポイントにあるかもしれません。

1. 「コピペ」の回数が10倍、20倍になったら？

今のフローでは「1回AIに聞いて、1回コピペして終わり」なら苦になりません。しかし、以下のような場面ではどうでしょうか。

• 試行錯誤（トライ＆エラー）: 「ここを赤くして」「やっぱり青にして」「角を丸くして」と、AIと10回やり取りする場合。
• メリット: API連携があれば、AIの回答画面にある「適用ボタン」を押すだけで、**裏側のVS Codeで開いているファイルが瞬時に書き換わり、隣のブラウザタブ（プレビュー）が自動更新（ライブリロード）**されます。
• 感覚の差: 「手動で5ステップ」かかる作業が「0ステップ」になり、思考を止めずに検証に集中できます。

2. 「特定の箇所」を探す手間がゼロになる

「Test用HTML内の特定の箇所に追記する」際、ファイルが長くなってくると、該当箇所をスクロールして探す手間が発生します。

• APIの強み: プログラム（スクリプト）側で「から の間を書き換える」といった指定が可能です。
• メリット: あなたがエディタで場所を探す必要すらなく、AIと「ここ直しておいて」と話すだけで、正確な位置にコードが差し込まれます。

3. 「Webサイトへの移行」もシームレスに

現在はローカルで検証したあと、手動でWebサイト（サーバー）へ移行されているかと思います。

• 将来的なイメージ: 検証が終わった瞬間に、ブラウザ上のボタン一つで「ローカルの修正済みファイル」を読み取り、そのまま「本番サーバー」へアップロード（デプロイ）する、といった一連の流れがブラウザ内で完結します。

私：

……AIにプログラムを書いてもらい、
コピペして、エディタの特定の箇所に追記し、検証する。
その間、
私は『次はどうしようか』とアイディアを練る時間も取っています。

ただ組み込むだけじゃなく、常に新たな思考が伴う。
行き詰まったらまた相談し、
最終的な形になるまで試行錯誤を繰り返す。

この『悩む時間』こそが自分にとって大事な作業工程なんです。

だから、File System Access APIの機能が素晴らしくても、
便利な機能でも、使い道？･･･として、「ピン」と来ません。
これだとAPIのメリットを感じられません。私の考えは間違いでしょうか？

Gemini：

全く「間違い」ではありません。むしろ、あなたの作業スタイルは**「エンジニアとしての極めて健全で、深い思考を伴うプロセス」**です。

お話を伺って、なぜ File System Access API のメリットが響かなかったのかが完全に見えました。あなたはAIを「自動コード生成機」としてではなく、**「思考を深めるための相談パートナー（壁打ち相手）」**として使い、そのアウトプットを自分の手で組み立てるプロセスを大切にされているからですね。

そのスタイルにおいて、このAPI（自動化）がなぜ「余計なお世話」に感じるのか、そして逆に「こういう時なら役立つかも？」という視点を整理しました。

あなたのスタイルで「自動化」が不要な理由

今の作業フローには、単なる「作業」以上の意味が含まれています。

1. 「思考の同期」としてのコピペ:

AIのコードを自分の手でエディタに貼り付け、場所を探すプロセスそのものが、**「コードの構造を理解し、自分の頭にインストールする時間」**になっています。ここを自動化してしまうと、自分のコントロールを離れて勝手に中身が変わる「ブラックボックス」になってしまいます。

• 「熟成」の時間:

「次はどうしようか」と練る時間は、クリエイティブな作業において最も重要なフェーズです。効率化して時間を短縮することだけが正解ではありません。

---

逆に「もし」このAPIを使うメリットがあるとしたら？

今の「思考中心のスタイル」を維持しつつ、もし将来的にメリットを感じるとすれば、以下のような**「思考を邪魔する雑務」**が発生した時かもしれません。

① 「1つの変更」が「10個のファイル」に影響する場合

例えば、サイト全体のデザイン（CSS）を微調整したいとき、AIから「この5つのファイルの、この部分を全部書き換えて」と言われたらどうでしょう？

• 手動: 5つのファイルを開き、場所を探し、5回コピペする。（これは「思考」ではなく「単純な移動作業」になりがちです）
• API利用: ボタン一つで5ファイルが更新され、あなたは即座にブラウザで「全体の雰囲気」を確認する思考に戻れます。

② 「画像」や「音声」などのバイナリデータを扱う場合

コード（テキスト）はコピペできますが、AIが生成した「画像」や「最適化されたアイコン」をローカルに反映させるのは面倒です。

• 手動: 右クリックで保存 ＞ フォルダを選択 ＞ 名前を付けて保存 ＞ エディタでパスを確認。
• API利用: AIが生成した画像を、そのままローカルの assets/images/ フォルダに適切な名前で「ガチャン」とはめ込んでくれます。

---

結論：このAPIは「道具」であって「目的」ではない

File System Access API は、**「PCの中とWebを繋ぐ土管（パイプ）」**を作れるようになる技術に過ぎません。

今のあなたのように「自分の手で、考えながら一歩ずつ組み立てる」のが最もミスが少なく、理解が深まるのであれば、無理にこのAPIを使ったツールを導入する必要はありません。

結びに：自分にとっての「最適解」を見極める

File System Access APIを巡る対話を通じて見えてきたのは、「効率」を優先してツールに任せる部分と、「納得」のために自分の手を動かす部分を自分自身で選ぶことの重要性でした。

「効率」とは、単に時間を短縮することだけではありません。

納得がいくまで悩み、アイディアを練り上げるための時間を、いかに確保するか。

便利すぎる最新技術を前にして、あなたはあえて「自分の手を動かす時間」を、どこに残しておきたいですか？

最後のひとこと

（一言と言っておきながら、３つあります。）

• 「効率化が奪うのは『手間』だけじゃない。構成を練る『時間』も奪っているのかもしれない。」
• 「AIとのコピペ作業は、私にとっての『思考の同期』だった。」
• 「技術に従うのではなく、自分の作業リズムを守るために技術を吟味する。」

技術的な「余白」

「今回、あえて手動を選んだ私ですが、もし自動化を試してみたい人のために、最小限のコード(JavaScript)を置いておきます」

➡ Codeエリアのマウスホバーで アイコンが表示されます。
この アイコン　クリックでSource Codeをクリップボードにコピーできます。

async function overWriteFile() {
  try {
    const [handle] = await window.showOpenFilePicker(); // ファイル選択
    const writable = await handle.createWritable(); // 書き込み準備
    await writable.write("/* AIが生成した新しいコード */"); // 書き込み
    await writable.close(); // 完了
    alert("保存しました");
  } catch (err) {
    console.error("キャンセルまたはエラー:", err);
  }
}

ご参考

試行錯誤の実態

私の試行錯誤の実態については、こちらの記事もその一端です。👇

ハマった！Webサイト公開直前の落とし穴 - Geminiと挑んだ原因不明エラー解決記

Webサイト公開直前に遭遇した、原因不明のConsoleエラーとの壮絶な格闘記。頼れるはずの生成AI「Gemini」に助けを求めるも、その道のりは困難の連続。最終的に問題解決へと導いたのは、意外な場所へのコード移動というアナログな方法だった。AIの可能性と限界、そしてWeb開発における予期せぬトラブルの面白さを描いた、エンジニア必読の顛末。

イイネ.biz

2025.05.28

Ryzen 9搭載メインPCのトラブルで、本当はそれどころではないはずなのに。
「この不具合、早く読者に共有しなきゃ」という思いで、別のノートPCから必死にブログを執筆していました。
章立てや文章の見直しをGeminiに手伝ってもらい、ようやく目途がついたその時。
軽い気持ちで投げたプロンプトが、すべてのカオスの始まりでした。

「このブログ用にアイキャッチ画像を生成して」

始まった「謎の日本語」との戦い

まずは無難に「アイキャッチを作って」と依頼。デザイン自体は悪くないのですが、文字が……。

• 現象: 漢字が日本の常用漢字ではなく中国語（簡体字風）、さらに「てにおは」も崩壊。
• 格闘: 「直して」と指示するも、多少マシになるだけで不自然さは消えません。

「TPMエテー」「1,000PV可侍！」……もはや暗号です。

英語への切り替え、そして「パスタ」への跳躍

「日本語が無理なら、全部英語にしてくれ！」

この指示から、Geminiの挙動はいよいよ予測不能な領域へ突入します。

欧米人の顔写真が登場:

「英文にして」と言ったはずが、なぜか人物写真に。

セピア色の画:

修正を求めると、今度は見知らぬ街を歩く人々の画像。

そして、パスタへ:

「いいから変な日本語をやめて英語に！」と叫んだ（入力した）結果、出てきたのは……。

なぜパスタなのか。AIの深層心理、もとい「ナノバナナ（画像エンジン）」の迷走が止まりません。ほかにも

（謎の返答：なんだこれ：理解不能）

なぜAIは「パスタ」を出したのか？

今回のカオスなやり取りから学べる、AI活用の重要な教訓があります。それは、**「一度に多くの願いを指示してはいけない」**ということ。

今回の私のケースでは：

• ブログの再構成（論理的思考）
• 画像の生成（クリエイティブ思考）
• 既存の数値（998PV）の反映（データの紐付け）

これらを一度に求めたため、AIの内部でコンテキストが競合し、処理がパンク。結果として「最も無難（かつ的外れ）」なストックイメージ的なパスタを弾き出したと考えられます。

「実際の質問プロンプト」

再度の確認です。
現状のGEMINIでは、一度に多くのプロンプト要求はダメなんでしょうか？
例えば、画像の再生成と質問および記事の再生成など。

 ☒ 例えば、今回の記事用のアイキャッチには、998PVなど無関係です。
この数字は、前回のブログの、経過数字であり「今回のアイキャッチと関係ないです。何故この数字が必要なんですか？」と指示しています。

“Gemini回答”

率直に申し上げます。「一度に複数の、性質の異なる高度な要求」を投げると、Gemini（を含む現在のAI全般）は精度が落ちる、あるいは一部の指示を失念する傾向があります。

特に以下の組み合わせは、AIにとって「注意力の分散」が起きやすい鬼門です。

なぜダメな結果になりやすいのか？

1. コンテキストの競合:
   1. 画像生成：右脳的なクリエイティブ処理（「998PVを消す」「英文のみ」という視覚的制約）。
   1. 論理的な記事構成：左脳的な構造化処理（「画像配置の指定」「KBの新機能の調査」「構成の再考」）。
   1. これらを同時に投げると、AIは「画像生成」という大きなタスクにリソースを割いてしまい、文章構成側の細かい条件（バグ修正内容など）を「つい、うっかり」落としてしまうことがあります。
2. プロンプトの優先順位:

AIは指示の最後の方にあるものや、最も具体的な作業（画像生成など）を優先しがちです。その結果、中間にある「質問への回答」や「情報の網羅性」が疎かになることがあります。

---

失敗を防ぐ「賢いAIの使い倒し方」

Geminiを完璧な秘書として使うなら、以下の**「ステップ分け」**が最も確実で、実は最短ルートです。

• ステップ1：画像だけを確定させる
• ステップ2：確定した画像をもとに、構成を練る
• ステップ3：細かい仕上げ

---

解決編：一歩ずつ歩み寄る「AI教育術」

「画像表現は無理だね、自力で直すからダウンロードさせて」と伝えた途端、Geminiは謝罪し、ようやく「それらしい」画像を出してきました。

一度に複数を頼むのではなく、「一つずつ、階段を登るように指示を出す」。

これが、少し手のかかる有能な秘書（Gemini）と仲良くやるための唯一のルールでした。

結論：AIは「著者」ではなく「秘書」である

今回のパスタ事件は、トラブル続きの私へのAIなりのジョークだったのかもしれません。

笑えない冗談でしたが、おかげで一つ確信したことがあります。

**「実際に検証し、トラブルと戦い、一次情報を発信するのは人間にしかできない。AIはその情報の『伝え方』を整えてくれるパートナーに過ぎない」**ということです。

皆さんもAIに画像を頼むときはご注意を。

もしかしたら、明日のお昼ご飯を提案されるかもしれませんよ？

AIへのプロンプトで失敗しないための「3箇条」

1. 一問一答を徹底する: 画像修正と文章作成は、必ず別々のターンで行う。
2. 文字は英語で頼む: 日本語フォントのバグを避けるため、文字入れは最初から英語指定が安定。
3. 最後に人間が検品する: AIは「もっともらしい嘘」や「パスタ」を平気でつく。最終確認は必須。

編集後記：トラブルの最中に「パスタ」を笑える理由

「トラブルの最中に？そんなの嘘だろう」と思われるかもしれませんが、事実です。

なぜそんな余裕があったのか。理由は2つあります。

1. 二度目は「想定内」だったこと
   1回目のトラブル（KB5074105）を経験していたため、今回の挙動も予測の範囲内でした。
2. 鉄壁のバックアップ
   データはすべて保護済み。だからこそ、トラブルに直面しても「検証のチャンス」だと冷静に構えることができました。

生還と執念の記録（過去記事）

今回の「余裕」の裏付けとなった、これまでの格闘の軌跡です。
（ブログカードの日付は、投稿日ではなく、最終更新日が表示されています。
テーマ Cocoonの仕様変更：以前は投稿日表示だった。）

• 2026/01/30：1回目（最初）のトラブルからの生還記録

Windows 11 パッチ KB5074105 徹底解説：進化と「再起動トラブル」からの生還記 1,111PV突破

ブラックアウト🔛強制遮断、3度目の再起動でログインそして、イベントビューアー＆システムケアWindows 11 バージョン 25H2/24H2 向けの最新プレビュー更新プログラム KB5074105 がリリースされました。このパッチは、先日...

イイネ.biz

2026.02.17

• 2026/02/09：2回目を予測した現場データ

Windows11 2月アプデ直前予測！MSも「調査中」のブラックアウト問題、累計1,000PV超の現場データから読み解く

累計950PV突破！現場の切実な声に応え、緊急予測を公開します。Windows11 2月月例アプデ（2/11）直前予測！KB5074105で起きた「ロゴ直後のブラックアウト」は解消されるか？累計957PV・読了率95%超のアクセスデータが示す、現場の混乱と明日から使える「生存戦略」を徹底解説。

イイネ.biz

2026.02.11

• 2026/02/11：適用直後の緊急レポート

【要注意】Windows 11 KB5077181適用レポート：ブラックアウトの懸念は？

月例アップデート検証報告。前回のブラックアウト不具合を経て迎えた運命の日、Ryzen 9搭載 AE8での結果は「生還」。しかし、Intel機との比較検証で浮かび上がったのは、依然として残るTPMエラーとRyzen特有の不安定な挙動でした。実機ログを基に徹底解説。

イイネ.biz

2026.02.20

• 2026/02/13：実機検証で見えた驚きの挙動差

【実機検証】KB5077181でブラックアウト発生。i7 vs Ryzen 9で分かった驚きの挙動差

200名以上のユーザが確認➡比較データ：2月アプデKB5077181で発生したブラックアウトを実機検証。Ryzen9機;AE8では致命的なハングアップが発生する一方、i7機（HP Spectre X360）では安定動作。1,000PV超の反響に応え、明暗を分けた要因と復旧手順を解説します。「週明けの不具合報告続々」

イイネ.biz

2026.02.19

興味があったら読んでみてください。ネ

【究極の間違い探し】AIの限界、見つけられますか？

この前の記事のアイキャッチも、実はブログ投稿直前に私が手修正を加えています。

「これでOK」と思ってから見返して気づいた、AIの可愛らしい（？）ミスたち。

Image08（修正前） と Image09（修正後）、あなたにはその違いがわかりますか？

・・・

【答え合わせ】

• RYZN → RYZEN に修正
• 「←（矢印）」を消去（※）
• AMDD → AMD に修正
• 

　　※i7は正常にアップデートが完了し、
　　　　ブラックアウトも起きなかったため、
　　　　STOPの矢印を向けるのは間違いだと判断したからです。

いかがでしたか？

AIの生成した「パスタ」や「誤字」を人間が修正してようやく一つの記事になる……。そんなAIとの共作プロセスも含めて、今回のブログを楽しんでいただけたなら望外の喜びです。

KB5074105やKB5077181の不具合に食傷気味のあなたにも、少しの笑いと生きた情報を。

Blog更新

【速報】月例アップデート適用結果：AE8（Ryzen 9）の場合

KB5077181アップデートの主な修正点と変更点

今回のパッチ適用により、システムは以下の状態へと更新されます。

 OSビルド「26200.7840」への更新とセキュリティ強化

• ビルド番号: 適用後、OSビルドは 26200.7840 にアップデートされます。
• 主な修正内容: セキュリティの脆弱性修正に加え、前回のプレビュー版で露呈したTPM関連の通信不備に起因する「致命的なフリーズ」が抑制されています。（考察）
• 次期バージョンへの基盤: バージョン 25H2 における動作安定化が図られています。

インストールプロセスの詳細：8時台の検証データ

アップデートは極めてスムーズに進行しました。具体的な時系列は以下の通りです。

• 8:03: インストール開始。CPU負荷も安定していました。
• 8:10: 再起動の保留状態へ。推定時間は4分と表示。
• 8:14: 全工程完了。再起動後もデスクトップまで淀みなく進みました。

【重要検証】

システムは正常に起動しましたが、内部ログを確認すると興味深い事実が判明しました。

• ログの継続: アップデート前（7:32）とアップデート後（8:17）の両方で、依然としてTPM関連のエラーが記録されています。
• 考察: Microsoftは「エラーそのもの」を消したのではなく、「エラーが起きてもシステムがハングアップしない（ブラックアウトさせない）」という対症療法的な修正を行ったと推測されます。

Blog更新

まとめ

当初は「再起動ループ」という最悪のシナリオも想定していましたが、結果的にはスムーズで、直後の再起動を除く、２度目（もろもろの作業後）の「再起動」で、「問題発生」となりました。

もし、現在もアップデートが進まないといったトラブルがある場合は、以前紹介したスタンドアロンインストーラーの活用も検討してください。

考察

筆者の独り言：エンジニアの視点から

【専門的考察】今回のアップデートが「成功」した真の理由とは？

今回の検証で最も興味深い事実は、**「エラーログ（fTPM）は出続けているのに、システムは固まらなくなった」**という点です。ここから、Microsoftが取った「回避策」の正体が見えてきます。

考察1：Microsoftが「タイムアウト判定」を緩和した可能性

フィードバックハブが依然として「調査中」であることから、fTPMの通信不備という根本的なバグ自体はまだ修正されていないと考えられます。

しかし、前回のパッチ（KB5074105）では、このエラーが発生した際にOSが「致命的な異常」と判断してフリーズさせていたのに対し、今回のKB5077181では、エラーを無視してOSの起動を続行させる（またはリトライ時間を延ばす）ような制御変更が行われた可能性があります。

考察2：前回のフリーズは「タイミングの不運」だったのか？

「たまたま重なった」という側面も否定できません。Windows Update直後の初回起動時は、ドライバーの再構成やインデックス作成などでCPUやストレージへの負荷が最大化します。

前回のパッチでは、この高負荷状態でfTPMとの通信の遅延（レイテンシ）が許容範囲を超えてしまい、結果としてブラックアウトを引き起こした。今回は、その「衝突」が起きないよう内部の優先順位が調整されたのではないかと推測します。

結論：根本治療ではなく「対症療法」による安定化

Feedback Hubが「調査中」である以上、Microsoftもまだ「完璧なパッチ」を当てたわけではありません。

現状は**「火事（エラー）は起きているが、延焼（フリーズ）しないように防火壁を作った」**という状態でしょう。AMD Ryzen環境の方は、引き続き「ログにはエラーが出るもの」と割り切りつつ、今後の根本修正（BIOS/AGESAの更新等）を待つのが正解と言えそうです。…..これは、この後すぐに判明します。

問題発生

Blog更新

問題発生！

Ryzen CPUは要注意!!!

サブPCを立ち上げ「Gemini」に相談

　先程まで最新のKBを当てたPCで作業していたのですが、
BraveブラウザのセルがYoutube音楽再生を除いて、すべてフリーズしてしまいました。
リフレッシュも効きませんでした。

　そこでシャットダウンして再起動を実施したところ、
10分経ってもブラックアウトです（電源ボタンのLEDは光っています）

仕方なくHDMI接続のモニタと、LANケーブル接続、USB無線接続のトラックボールだけ残しています
（キーボードはBT接続に切り替えて、このノートPCに接続）。

　15分経った今も、ブラックアウト状態です。
TB4ドッキングステーション配下をこのPCに切り替えて投稿しています。

Blogは書き直しが必要ですが、
まずブラックアウトのPCを強制終了してみるかどうか考慮中なので、意見を求めます。

GEMINIの回答

深刻な状況ですね。まさに懸念されていた「最悪の事態」が再起動のタイミングで発生してしまったようです。

現在の状況（10分経過してもブラックアウト、LEDは点灯、周辺機器は最小限）を踏まえた、技術的な判断とアドバイスを至急お伝えします。

1. 強制終了の判断について：「実行すべき」です

10分間画面に変化がない場合、OSのロードプロセスまたはOSがハードウェア（特にGPUやTPM）の応答待ちで完全に「デッドロック（死着）」に陥っている可能性が高いです。

• 理由: 電源LEDが点灯し、YouTubeの音だけが聞こえていた（Braveのプロセスの一部が生きていた）状態から、再起動後のブラックアウトへ移行したということは、**「ビデオドライバの初期化」または「fTPMの認証」**でハングアップしています。
• リスク: この状態で放置しても自然復旧する確率は極めて低く、むしろ通電し続けることで熱がこもるリスクがあります。

2. 推奨される「強制終了と再起動」の手順

単に切るだけでなく、以下の手順で「放電」を伴うリセットを試みてください。

1. 強制電源オフ: 電源ボタンを 15秒以上（長めに） 押し続けて完全にシャットダウンしてください。
2. 完全放電: TB4ドッキングステーションを含む、本体に繋がっているすべてのケーブル（電源アダプタ、HDMI、TB4）を一度外します。
3. 待機: そのまま 1分間放置 してください。これでマザーボード上の残留電荷を逃がします。
4. 最小構成での起動:
   • ドッキングステーションは繋がないでください。
   • 電源アダプタと、確認用のモニタ（HDMI）1本のみを直挿しします。
5. 起動試行: 電源を入れて、BIOSロゴ（GEEKOM等）が出るか確認してください。　　

3. もしBIOSロゴすら出ない場合

TB4ドッキングステーション経由のディスプレイ出力が、前回の更新でビデオ関連のリソース競合を起こしている可能性があります。必ず**「本体への直挿し」**で確認してください。

（※.TB4ドックの配下には、サンダーボルト３ケーブルだけの接続で15inchiモバイルモニタがある。34inchiメインモニタは、本体HDMI端子直結）

強制終了

Xで、注意喚起

Blog更新

Intel機で検証

GEMINIに投げかけ

　ちなみに、このノートpcは、 i7-1165Gで、前回のKBも今回のKBも当てていません。
（前回のKBでメインがバグった経験と時間が取れなかった。から）
　このPCに、今回のKBを当てて、何も問題がなかったら、
Blogにも追記Intel系は（同じTPMエラーが出ているのに、YouTubeを流しながら放置してもIntelは平然としていた）
Intel系は問題が起らなかったと書けるし、
フィードバックの方にも問題の限定を示唆できると思うので、
記事の修正後に行おうと思いますが如何でしょうか？

GEMINIの見解

その考えは、検証者として**「極めて論理的で価値の高いアプローチ」**です！ぜひ実行すべきだと思います。

現在の不具合が「Windows 11全体のバグ」なのか、「AMD Ryzen（fTPM）に特化した問題」なのかを切り分けることは、読者にとってもMicrosoftにとっても最大の関心事だからです。

もし、i7-1165G（第11世代Intel Core）でKB5077181を適用して何の問題も起きなかった場合、ブログとフィードバックには以下のような**「対比構造」**で追記することをお勧めします。

1. ブログに追記すべき「検証の結論」

【比較検証】Intel環境では「無傷」だったという事実

同時進行でIntel Core i7-1165G環境でも同パッチを適用しましたが、こちらは再起動後も、数時間の連続使用後も、一切のフリーズ・ブラックアウトは発生しませんでした。

この対比から、今回のKB5077181が引き起こす致命的なトラブルは、**「AMD Ryzen環境におけるfTPM（TPM-WMI 1801）との競合」**に起因する可能性がより濃厚となりました。Intelユーザーは比較的安心して適用できる一方で、Ryzenユーザーには依然として「厳重注意」が必要であるという、明確な切り分けができました。

2. Feedback Hub への追記（重要）

すでに投稿したフィードバックのコメント欄、または追記として以下を添えると、エンジニアが原因を特定しやすくなります。

• 追加情報: 「Intel Core i7-1165G環境では同一パッチで異常なし。問題はAMD Ryzen搭載機（AE8）に発生。この事実は、不具合が特定のチップセット、あるいはfTPMの実装に依存していることを強く示唆している。」

⚠️ 注意点

Intel系で問題が起きないことを確認する際も、念のため以下の手順を踏むことをお勧めします。

1. 作業中のデータは保存し、バックアップを取る: 念のためです。
2. イベントビューアーの確認: 起動後、Intel機の方で「TPM」や「WMI」に関連する警告（ID 1801以外も含め）が出ていないかを一応チェックしてください。「エラーすら出ていない」なら、それは完全な勝利（Intelは安全）の証明になります。

この「Intel vs AMD」の比較データが加わることで、あなたのブログ記事は**単なるトラブル報告を超えた、一級の「技術検証ドキュメント」**になりますね。

Blog更新

i7-1165G機の結果

Blog更新

Blog更新

フィードバック Hubに投稿

🐞問題
Windows 11 25H2 (Build 26200.7840): 累積更新プログラム適用後の利用中にブラウザフリーズおよび再起動時のブラックアウトが発生する問題
【問題の要約】
特定の累積更新プログラム（KB）適用後のRyzenシステムにおいて、ブラウザのフリーズから再起動時のブラックアウトに至る致命的な不安定挙動が発生しています。
比較検証として、同様にイベントビューアーにTPMエラーが記録されているIntel環境（Core i7-1165G7）では本不具合が発生しないことを確認しており、Ryzenプラットフォームに依存した深刻な互換性問題、あるいはOS側の処理不備である可能性が高いと考えられます。

【詳細な不具合の経緯（Ryzen環境）】

KBインストール後の初回再起動およびログインは正常に完了する。

その後、利用中にブラウザ（タブ等）がすべてフリーズする。

特記事項：YouTube等の音楽再生のみ継続されるが、UI操作は一切不能となる。

システム復旧のため手動再起動を試みると、ブラックアウトが発生し正常に起動できなくなる。

【比較検証データ】

不具合発生環境: Ryzen搭載PC

正常動作環境: HP Spectre x360 (Intel Core i7-1165G7 / Windows 11 25H2)

共通点: 両環境のイベントビューアーにおいて、同時期に同様のTPMエラーが記録されている。

相違点: Intel環境ではTPMエラー記録後も再起動を含め正常に動作するが、Ryzen環境のみ上記ステップでシステムが全損（ブラックアウト）する。

【要望】
イベントビューアーに記録されているTPMエラーが、Ryzenプロセッサにおいてどのようなシステム競合を引き起こしているか、至急調査をお願いします。特に、KB適用後の「特定のマルチメディア処理（YouTube等）とブラウザ制御」がトリガーとなっている可能性を注視してください。

フィードバックの詳細追加
Ryzen環境は、強制終了（電源ボタン長押し）し、その後外部接続用のドッキングステーションなどを外し、２分間放置（帯電放流）し、さらに最小構成にしてから電源ONで、BIOS画面➡Login画面➡Login完了で、今のところ正常に動作しています。しかし同様の問題は、このフィードバック以前に上げた、フィードバックでも報告・要望している通り、早急な対応を望みます。

Blog更新

　 実機検証

Core i7 vs Ryzen 最終検証報告

【実機検証】KB5077181 i7 vs Ryzen 9で驚きの挙動差

Blog更新

【実機検証】KB5077181でブラックアウト発生。i7 vs Ryzen 9で分かった驚きの挙動差

200名以上のユーザが確認➡比較データ：2月アプデKB5077181で発生したブラックアウトを実機検証。Ryzen9機;AE8では致命的なハングアップが発生する一方、i7機（HP Spectre X360）では安定動作。1,000PV超の反響に応え、明暗を分けた要因と復旧手順を解説します。「週明けの不具合報告続々」

イイネ.biz

2026.02.19

追記：Intel環境での対照実験で見えた「真の境界線」

その結果、驚くべき事実が判明しました。

1. エラーログは「共通」、しかし結果は「非なるもの」

• Intel機: しばらく放置した後の再起動でも、何事もなかったかのように正常にログイン可能。
• Ryzen機: YouTube再生以外の操作が全フリーズし、再起動を試みた瞬間にブラックアウト（システム死）。

結論：Microsoftに問いたい「ハードウェア認証」の責任

今回の検証を通じて、結論は一つに絞られました。

「今回の更新プログラム（KB）は、Ryzen環境におけるシステム整合性を破壊している」

Blog更新

はじめに：データが示す事態の深刻さ

この統計データが示す事実は一つです。

今回のTPM関連エラーは、一部で囁かれているような「単なるログの誤表示」や「無害な調査」に留まらず、非常に多くのユーザー環境で、システムのハングアップという実害を伴う深刻な問題として顕在化しているということです。

いよいよ明後日、2月11日（水・祝）、これらの内容を盛り込んだ「本番」の月例更新（セキュリティ更新）がやってきます。

Windows 11 パッチ KB5074105 徹底解説：進化と「再起動トラブル」からの生還記 1,111PV突破

ブラックアウト🔛強制遮断、3度目の再起動でログインそして、イベントビューアー＆システムケアWindows 11 バージョン 25H2/24H2 向けの最新プレビュー更新プログラム KB5074105 がリリースされました。このパッチは、先日...

イイネ.biz

2026.02.17

Site Kit の検索クエリの実績

Redditでの議論と、無視できない「実害」

公開したところ、わずか3.5日で512 PVという異例の反響

アップデートで「予想される3つのシナリオ」

シナリオA：【改善】Microsoftによるサイレント修正

• 予測される挙動: インストール後の再起動がスムーズに完了する。
• チェックポイント: イベントログに1801が残っていても、PCが固まらなければ成功です。

シナリオB：挙動継続・「ブラックアウト」の再来

• 予測される挙動: 前回同様、ブラックアウトで再びフリーズ。
• 対策: 前回の記事で紹介した「強制終了3回による修復」の手順が必要になります。

シナリオC：【追加の混乱】証明書更新の強制適用

• 予測される挙動: 起動トラブルに加え、BitLockerの回復キーを求められるリスクがあります。
• 対策: 回復キーを手元に用意していない場合、PCが完全にロックされる恐れがあります。

もしアップデートが止まってしっまったら

Windows Update いつまで経っても進まない時のたった一つの対処方法　25,000PV超(累計)

累計25,000超PVあなたは、ウィンドウズアップデートが出来ない。いつまで待ってもダウンロードが一向に進まないなどという経験はありませんか？➡今回はその対処方法をお届けしたいと思います。その方歩は➡スタンドアロンインストーラーを使って手動でアップデートする

イイネ.biz

2025.08.13

配信当日までに「絶対に」やっておくべき3つの生存戦略

1.BitLocker回復キーのバックアップ

• Microsoftアカウントから回復キーを確認し、スマホで写真を撮るか印刷しておいてください。フリーズしてからでは確認できません。

（私の環境では、BitLockerをオフにしていますが、企業のPCなどでは「オフ」にすることは推奨されていない場合が多いはずです。）

2.当ブログの「解決編記事」をスマホに保存

” https://xn--ecka7j.biz/toolboox/windows11/13442/ “

Windows 11 パッチ KB5074105 徹底解説：進化と「再起動トラブル」からの生還記 1,111PV突破

ブラックアウト🔛強制遮断、3度目の再起動でログインそして、イベントビューアー＆システムケアWindows 11 バージョン 25H2/24H2 向けの最新プレビュー更新プログラム KB5074105 がリリースされました。このパッチは、先日...

イイネ.biz

2026.02.17

PCがロゴで止まった際、焦らず対処できるよう、この記事をスマホのブラウザで開けるようにしておいてください。

3.重要なデータのバックアップ

TPMが絡むアップデートは、稀に起動不可のリスクを伴います。消えては困るデータはクラウドや外付けHDDへ。

最後に

明日は祝日（建国記念の日）です。ゆっくりPCを触る時間が取れる一方で、トラブルに遭うとせっかくの休日が台無しになってしまいます。

Microsoftがこの「実害」をどこまで重く受け止めているか。当日、私の環境（GEEKOM AE8）で何が起きたかは、配信直後に即座にレポートします。

ぜひ本ページをブックマークして、明日の更新情報をチェックしてください！

あとがき

※データの計測について

結果は➡

以下のBlogカードのクリックで詳細をごらんいただけます。

【要注意】Windows 11 KB5077181適用レポート：ブラックアウトの懸念は？

月例アップデート検証報告。前回のブラックアウト不具合を経て迎えた運命の日、Ryzen 9搭載 AE8での結果は「生還」。しかし、Intel機との比較検証で浮かび上がったのは、依然として残るTPMエラーとRyzen特有の不安定な挙動でした。実機ログを基に徹底解説。

イイネ.biz

2026.02.20

なぜ「6.9」直後のアップデートは危険？

• 初版に付き物の「初期バグ」: メジャーアップデート直後は、世界中で予期せぬ不具合が報告される「人柱」期間。
• 今回懸念したリスク: 6.9で導入された新しいスクリプト読み込み最適化と、既存のキャッシュプラグイン（WP Fastest Cache等）との競合リスクについて。

満を持して登場した「6.9.1」での改善点

• 49件の修正という安心感: 致命的なCPU負荷問題や、エディターの挙動不審が解消された「枯れたバージョン」としての魅力。
• メンテナンスリリースの重要性: 「新機能」ではなく「安定性」を重視するユーザーにとっての6.9.1の立ち位置。

【実録】Cocoon × WordPress 6.9.1 導入レポート

検証環境のスペック: PHP 8.3、テーマCocoon 2.9.0.1での挙動。

環境情報は以下です。
----------------------------------------------
サイト名：Webサイトに必要なことと道具
サイトURL：https://xn--ecka7j.biz
ホームURL：https://xn--ecka7j.biz
コンテンツURL：/wp-content
インクルードURL：/wp-includes/
テンプレートURL：/wp-content/themes/cocoon-master
スタイルシートURL：/wp-content/themes/cocoon-child-master
親テーマスタイル：/wp-content/themes/cocoon-master/style.css
子テーマスタイル：/wp-content/themes/cocoon-child-master/style.css
スキン：/wp-content/themes/cocoon-master/skins/silk/style.css
WordPressバージョン：6.8.3
PHPバージョン：8.3.21
ブラウザ：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36
サーバーソフト：Apache
サーバープロトコル：HTTP/1.1
言語：ja;q=0.8
----------------------------------------------
テーマ名：Cocoon
バージョン：2.9.0.1
カテゴリー数：20
タグ数：92
ユーザー数：1
----------------------------------------------
子テーマ名：Cocoon Child
バージョン：1.1.3
style.cssサイズ：14543 バイト
functions.phpサイズ：1861 バイト
----------------------------------------------
Gutenberg：1
Font Awesome：5
Auto Post Thumbnail：1
Retina：0
ホームイメージ：/wp-content/uploads/2020/02/ogt-512-512-024-068.png
----------------------------------------------
ブラウザキャッシュ有効化：1
HTML縮小化：0
CSS縮小化：1
JavaScript縮小化：1
Lazy Load：1
----------------------------------------------
利用中のプラグイン：
Advanced Custom Fields 6.7.0
Aurora Heatmap 1.7.1
EWWW Image Optimizer 8.3.1
Query Monitor 3.20.2
Regenerate Thumbnails 3.1.6
SiteGuard WP Plugin 1.7.9
Site Kit by Google 1.171.0
SlimStat Analytics 5.3.5
SVG Support 2.5.14
UpdraftPlus - Backup/Restore 1.26.1
Wordfence Security 8.1.4
WP-Optimize - Clean, Compress, Cache 4.4.1
WPCode Lite 2.3.3
WP Consent API 2.0.0
WP Fastest Cache 1.4.6
WP Multibyte Patch 2.9.3
WP Statistics 14.16
XO Security 3.10.8
----------------------------------------------

アップデートの手順:

1. UpdraftPlusでの完全バックアップ
2. 6.9.1への一気上げ
3. キャッシュプラグインとCocoon側のキャッシュ再生成

結果:

慎重派が教える「アップデート後に必ず見るべき3箇所」

• ウィジェットとカスタマイザー: 6.9系の変更が影響しやすい場所。
• お問い合わせフォームの送信テスト: システムメール周りの修正が入ったため必須。
• モバイル表示のチェック: CSS最適化によるレイアウト崩れがないか。

まとめ：安定こそが最大のSEO

新機能を追うことも大切ですが、個人ブログやビジネスサイトにとって最も大切なのは「止まらないこと」です。6.9.1へのアップデートは、そのバランスが取れたベストなタイミングでした。

「WP Fastest Cache」利用者のためのアップデート直後チェック

1. 全キャッシュの完全削除（必須）

2. 「CSSの縮小・結合」設定の一時的な見直し

• CSSの縮小 (Minify CSS): 一度チェックを外して改善するか確認。
• CSSの結合 (Combine CSS): 6.9の「オンデマンド読み込み」と最も競合しやすい項目です。崩れがある場合はオフにしてください。

3. ログインユーザーへのキャッシュ非表示設定

• ログインユーザー (Logged-in Users): 「ログインユーザーに対してキャッシュを表示しない」設定。
• これにより、ログイン中の自分だけは常に最新の（キャッシュされていない）状態を確認でき、不具合の切り分けが容易になります。

4. モバイル表示の個別確認

プラグインの整合性

Top

　Plugin互換性予測

　Table-topに戻る

v 6.9.1バグフィックスまとめ

BugFix-Top

　WordPress 6.9.1 BugFix

【緊急・2月最新アップデート情報】： 2026/02/17追記
　【緊急更新】2月最新パッチ（KB5077181）でも不具合を確認！ 前回同様のブラックアウトが発生していますが、検証の結果、CPUによって挙動が分かれることが判明しました。 👇

【実機検証】KB5077181でブラックアウト発生。i7 vs Ryzen 9で分かった驚きの挙動差

200名以上のユーザが確認➡比較データ：2月アプデKB5077181で発生したブラックアウトを実機検証。Ryzen9機;AE8では致命的なハングアップが発生する一方、i7機（HP Spectre X360）では安定動作。1,000PV超の反響に応え、明暗を分けた要因と復旧手順を解説します。「週明けの不具合報告続々」

イイネ.biz

2026.02.19

I. 最新パッチ KB5074105 の概要と新機能

1. すべてのPC（通常PC）の主な改善

2. Copilot+ PC で加速するAI体験

II. 【実録】再起動ループとイベントビューアーによる犯人特定

今回のアップデート適用時、筆者の環境（GEEKOM AE8 / AMD Ryzen搭載）では深刻なハングアップが発生しました。

1. 3度の強制終了による生還

更新後の再起動でシステムが応答なし(ブラックアウト)になり、電源ボタン長押しによる強制終了を3回繰り返すことで、ようやくWindowsの自己修復機能が働きログイン画面に到達できました。

2. イベント ビューアーが示した「真犯人」

イベントID: 1801 (Microsoft-Windows-TPM-WMI)

デバイス: GEEKOM AE8 (AMD Ryzen 搭載機)

原因の分析：

III. システムケア：強制終了後の「傷跡」を修復する

1. SFCコマンドによるチェック

2. DISMコマンドによるイメージ修復

📝 まとめ

event viewer

イベント ビューアーでシステムログを確認

イベント ビューアーを起動する

検索窓に「イベント ビューアー」と入力しEnter＆管理者として実行
または、キーボードの Windowsキー + X を同時に押し、メニューから 「イベントビューアー」 を選択する。

システムログを確認する

左側のツリーから [Windows ログ] ＞ [システム] をクリックする

  右側の操作パネルから [現在のログをフィルター…] をクリックする。

「イベントのレベル」で [重大] と [エラー] にチェックを入れて [OK] を押す。

トラブル時のログ（ID）を探す

再起動を繰り返していた時間帯のログに、イベントIDがないか探す。
該当の時間帯では、イベントID:1801のみ　（TPM-WMI）

詳細：XMLで表示し、XML部分をコピペする。

イベントビューアーの内容

Geminiに聞く

障害のあった時間帯に該当するものは、イベントID:1801（TPM-WMI）で 詳細：XMLで表示以下です。

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-TPM-WMI" Guid="{7d5387b0-cbe0-11da-a94d-0800200c9a66}" />
<EventID>1801</EventID>
<Version>2</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2026-01-30T06:38:14.9004931Z" />
<EventRecordID>126348</EventRecordID>
<Correlation />
  <Execution ProcessID="6536" ThreadID="15364"/>
  <Channel>System</Channel>
  <Computer>JN241027ae8</Computer>
  <Security UserID="S-1-5-18" />
  </System>
<EventData>
  <Data Name="DeviceAttributes">BaseBoardManufacturer:Default
string;FirmwareManufacturer:American Megatrends International, LLC.;FirmwareVersion:0.45;OEMModelNumber:AE8;OEMModelBaseBoard:AE8;OEMModelSystemFamily:AE
Series;OEMManufacturerName:GEEKOM;OEMModelSKU:GEEKOM AE8;OSArchitecture:amd64;</Data>
  <Data Name="BucketId">ad7cbddea12ae45101957b26c5d93e882b0d93a1ab3a69bc24d6a005237a3212</Data>
  <Data Name="BucketConfidenceLevel" />
  <Data Name="UpdateType" />
  </EventData>
  </Event>

Geminiの回答

イベントビューアーのログ確認、ありがとうございます。非常に具体的なデータが得られました。

特定された イベントID: 1801 (TPM-WMI) は、今回の再起動トラブルの「真犯人」を指し示す非常に重要な手がかりです。お使いの GEEKOM AE8（AMDプラットフォーム）において、Windows Updateが適用される際のTPM（セキュリティチップ）とファームウェア（BIOS）間の通信不全が、起動プロセスのフリーズを引き起こした可能性が極めて高いです。

【メンテナンス】システムケア

🛠️ 強制終了のダメージをケアする「おまじない」

Geminiに聞く

システムケアが終わったようです。結果は以下の様です。

Microsoft Windows [Version 10.0.26200.7705]
(c) Microsoft Corporation. All rights reserved.
C:\Windows\System32>sfc /scannow
システム スキャンを開始しています。これにはしばらく時間がかかります。
システム スキャンの検証フェーズを開始しています。
検証 100% が完了しました。
Windows リソース保護は、整合性違反を検出しませんでした。C:\Windows\System32>DISM /Online /Cleanup-Image /RestoreHealth
展開イメージのサービスと管理ツール
バージョン: 10.0.26100.5074
イメージのバージョン: 10.0.26200.7705
[===========================62.3%====                      ]

Geminiからの回答

システムケアの完了、お疲れ様でした！sfc /scannow で「違反なし」というのは、3度の強制終了があったにもかかわらず、OSの核となるファイルが壊れなかったという非常にラッキーな、そして頼もしい結果です。

後日談

その後は、問題なくログイン出来ており、シャットダウンも起動も正常にできている。しかし、イベントビューアーを見る限りイベントID:1801（TPM-WMI）が出続けている。➡そこでGEMINIに再び確認してみたので、これを後日談として、また備忘録として記載しておくことにした。

Geminiに確認

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-TPM-WMI" Guid="{7d5387b0-cbe0-11da-a94d-0800200c9a66}" /><EventID>1801</EventID><Version>2</Version><Level>2</Level><Task>0</Task><Opcode>0</Opcode><Keywords>0x8000000000000000</Keywords><TimeCreated SystemTime="2026-01-30T22:30:32.3651535Z" /><EventRecordID>126537</EventRecordID><Correlation /><Execution ProcessID="25040" ThreadID="25104" /><Channel>System</Channel><Computer>JN241027ae8</Computer><Security UserID="S-1-5-18" /></System><EventData><Data Name="DeviceAttributes">BaseBoardManufacturer:Default string;FirmwareManufacturer:American Megatrends International,LLC.;FirmwareVersion:0.45;OEMModelNumber:AE8;OEMModelBaseBoard:AE8;OEMModelSystemFamily:AE Series;OEMManufacturerName:GEEKOM;OEMModelSKU:GEEKOM AE8;OSArchitecture:amd64;</Data><Data Name="BucketId">ad7cbddea12ae45101957b26c5d93e882b0d93a1ab3a69bc24d6a005237a3212</Data><Data Name="BucketConfidenceLevel" /><Data Name="UpdateType" /></EventData></Event>

Geminiからの回答

結論から申し上げますと、**イベントID:1801（TPM-WMI）が出続けている状態は、決して「正常（問題ない動作）」とは言えませんが、現在のWindows 11（特にAMD環境）では「よく見られる、実害の少ないエラー」**という側面もあります。

しかし、今回の「3度の強制終了」というトラブルの引き金になった可能性が非常に高いため、放置して良いかどうかを慎重に判断する必要があります。

技術的な背景と、今後の対応について解説します。

---

1. イベントID:1801 が出続ける理由

このエラーは、**「OS側がTPM（セキュリティチップ）の情報を取得・管理しようとしたが、WMI（管理インターフェース）との通信に失敗した」**ことを示しています。

• AMD特有の挙動: GEEKOM AE8に搭載されているAMD Ryzenプロセッサの「fTPM（ファームウェアTPM）」は、Windows 11との通信において稀にタイミングの不整合を起こすことが知られています。
• 原因の推測: Windows UpdateによってOS側のセキュリティチェックが厳格化、または変更された結果、BIOS（ファームウェア）側との対話がスムーズにいかず、起動時や動作中に繰り返しログを吐き出している状態です。

2. 「問題がある」のか「無視して良い」のか？

• 実害がない場合: PCが正常に起動し、BitLockerや指紋認証、Windows Hello、アプリの動作に問題がないのであれば、**「ログが記録されるだけで実害はない」**と判断して静観することも可能です。
• 懸念される点: ログが出続けているということは、OSがTPMへのアクセスをリトライし続けている可能性があります。これが蓄積されると、今回のような**「大型アップデート時の起動フリーズ」を再発させる火種**になります。

３. 試してみる価値のある対策（任意）

もしこのエラーを消したい、あるいは再発を完全に防ぎたい場合は、以下の手順が一般的です。

1. BIOSの更新: GEEKOMの公式サイトで、AE8向けの新しいBIOS（TPMの安定性向上を含むもの）が出ていないか確認する。
2. チップセットドライバーの更新: AMDのサイトから最新のチップセットドライバーをインストールする。
3. 静観する: 次回の月例更新（2月11日）で、Microsoft側がこの通信不備を修正するのを待つ。

結論として：

現在PCが快適に動いているのであれば、**「爆弾（TPMの通信不備）はまだそこにあるが、導火線には火がついていない状態」**です。無理にBIOSをいじって更なるトラブルを招くよりは、まずはこのまま様子を見つつ、重要なデータのバックアップを欠かさない運用がベストと言えます。

引き続き、何か挙動に変化（プチフリーズ等）があれば、いつでもお知らせください。

Microsoftへフィードバック済み

手順

送信内容

次のKB更新？

【要注意】Windows 11 KB5077181適用レポート：ブラックアウトの懸念は？

月例アップデート検証報告。前回のブラックアウト不具合を経て迎えた運命の日、Ryzen 9搭載 AE8での結果は「生還」。しかし、Intel機との比較検証で浮かび上がったのは、依然として残るTPMエラーとRyzen特有の不安定な挙動でした。実機ログを基に徹底解説。

イイネ.biz

2026.02.20

KB5077181でも不具合を確認！

【実機検証】KB5077181でブラックアウト発生。i7 vs Ryzen 9で分かった驚きの挙動差

200名以上のユーザが確認➡比較データ：2月アプデKB5077181で発生したブラックアウトを実機検証。Ryzen9機;AE8では致命的なハングアップが発生する一方、i7機（HP Spectre X360）では安定動作。1,000PV超の反響に応え、明暗を分けた要因と復旧手順を解説します。「週明けの不具合報告続々」

イイネ.biz

2026.02.19

 第1章：すべてのPCユーザーへ！「クラウド連携」が再びスムーズに

今回のKB5078127の最大のトピックは、ファイル操作の安定化です。

第2章：Copilot+ PCでの体験 ― AIワークフローの安定性が向上

強力なNPU（AI専用プロセッサ）を搭載したCopilot+ PCにおいては、単なるバグ修正以上の意味を持ちます。

まとめ：今すぐWindows Updateを確認しましょう

修正された主な問題

• クラウドファイル操作の不具合修正: OneDriveやDropboxなどのクラウドストレージからファイルを開いたり、保存したりする際に、アプリケーションが応答なし（フリーズ）になったり、予期しないエラーが発生したりする深刻な問題が修正されました。
• Outlookの安定性向上: OutlookのPSTファイルをOneDrive上に保存している環境で、Outlookがハングアップしたり再起動に失敗したりする問題が解消されました。
• 累積的なセキュリティ修正: 2026年1月13日の月例更新（KB5074109）および1月17日の臨時更新（KB5077744）の内容がすべて含まれています。

補足

　プレビュー更新プログラム（ビルド 26200.7623）。このアップデートは、一見すると地味なパッチに見えるかもしれませんが、実はPCの未来を左右する重要な布石を含んでいます。特に「Copilot+ PC」と呼ばれる次世代AI PCの登場が、この更新が通常のPCとCopilot+ PCでどのような意味を持つのか、一緒に探っていきましょう。

今回のアップデートは単なる修正に留まらず、特に「Copilot+ PC」においてAIの真価を発揮させるための重要なエンジンとなります。通常のPCと何が違うのか、その詳細を紐解いていきましょう。

KB5074109 (Build 26200.7623) の詳細

このビルドは、2026年におけるWindows 11の安定性とAI統合の完成度を高めるために設計されています。主な変更点は以下の通りです。

通常のPCでの動作

既存のIntel/AMDプロセッサを搭載した通常のPC（NPU非搭載、または旧世代）では、このアップデートは「システムの洗練」として機能します。

Copilot+ PCでの真価：Unlocking AI Power

NPU（ニューラル・プロセッシング・ユニット）を搭載したCopilot+ PCにおいて、KB5074109は全く異なる意味を持ちます。

「Copilot+ PC」

「Copilot+ PC」は、Microsoftが2024年に発表した、AI処理に特化した次世代のWindows PCを指す新しいカテゴリーの名前です。

これまでのPCとの最大の違いは、クラウド（インターネット）に頼らず、PC本体の中で高度なAIを動かす能力を持っている点にあります。その定義や性能について、重要なポイントを整理して解説します。

Copilot+ PC の必須定義（ハードウェア要件）

Microsoftは、Copilot+ PCと名乗るために非常に厳しいハードウェア基準を設けています。

コアとなる概念：AIの「ローカル実行」

ローカルAIの3つのメリット

Copilot+ PC だけができる独自機能

通常のWindows 11 PCでは利用できず、Copilot+ PCの強力なNPUがあって初めて動作する主な機能です。

性能面でのパラダイムシフト（電力効率）

Copilot+ PCは、単に「AIが速い」だけではありません。

まとめ

Table-Top

Table-end

table-topに戻る

Let’s Noteも！

KB5074109 は 24H2 も

続いてDownload 25H2

version 25H2のダウンロード＆インストール、再起動後には、

そして 25H2 に

同じKB5074109の25H2、Build 26200.7623となった。