ドライブ整理の区切りとイベントログ診断の計画
このところ進めているPC環境の点検作業で、まずはドライブ容量の確認スクリプトを動かしてみました。
結果を見て少し悩んだのが、ゲームの管理ソフトであるSteam周りのデータです。
以前はCドライブに入れていたのですが、後からEドライブを増設して移行したため、
両方のドライブにデータや残骸が混在して、かなり中途半端な状態になっていました。
アンインストールしたはずの古いゲームの設定データなどもあちこちに残っているようで、
こればかりは機械的に消すわけにもいかず、自分で少しずつ取捨選択して片付けるしかなさそうです。
そこは自分の手作業で進めることにして一旦区切りをつけました。
続けて3つ目のテーマとして、イベントビューアーを使った不調や強制終了の原因診断に進みました。
新しいチャットからでも一言で最近のエラーを調べてくれる仕組みを作るのが目標です。
ログを安全に渡すための3重の保護ルール
作り始める前に一番気になっていたのが、セキュリティやプライバシーの問題でした。
OSの記録にはパスワードやAPIキー、自宅Wi-Fiの情報などが含まれることがあるそうです。
もしAIがコマンドで生の記録をそのまま読み出してしまうと、
後から画面上で伏せ字にしても、裏の会話履歴や共通の記録先にそのまま残ってしまいます。
そこで、まずは自律会議の仕組みを立ち上げて、安全な設計計画を練ってもらいました。
提案してもらったのは、以下のような3重の保護ルールを設けるやり方です。
・認証情報やスクリプトの中身が残る危険な領域は最初から取得を禁止する
・ネットワーク情報などが混ざる領域は手元で個人情報を伏せてから渡す
・日常的に出る無害な警告は除外用の辞書を作ってノイズを減らす
これなら安心して任せられそうだと思い、この方針で進めることにしました。
タスクマネージャーに並ぶ大量のNode.jsに焦った話
診断の仕組みを作ってもらおうとした矢先、ふとタスクマネージャーを開いて手が止まりました。
一覧の中に、Node.jsのプロセスが19個もズラッと並んでいたのです。
たしかにこれまでAntigravityで色々な機能を取り入れる中でNode.jsは使ってきましたが、
さすがに19個も同時に立ち上がっている光景は見たことがありませんでした。
しかも、ちょうど数日前にNode.jsの深刻な脆弱性が見つかったというニュースを見たばかりだったので、
もしかして変なプログラムでも入り込んだのではないかと急に不安になりました。
作業を一旦止めてもらい、画面を見せて緊急で状況を調べてもらいました。
プロセスの親子関係や起動元をすべて辿ってもらったところ、結論としてはウイルスではなく、
19個すべてがAntigravityの本体から起動された正規の連携用サーバーやプラグインでした。
裏側で10個ほどの連携機能が一斉に動いていることに加えて、
Windowsの仕様上、1つの機能を呼び出すときに2〜3個のプロセスに分かれて立ち上がるため、
見た目だけ大量に増えているように見えていたそうです。
ただ、手放しで安心できたわけではなく、調べていく中で大事な問題も見つかりました。
まさに数日前に発表されたばかりの重大な脆弱性の対象バージョンに、
自分のPCに入っているNode.jsが該当していることが分かったのです。
不審な動きではなかったものの、このタイミングで気づいて対策できたのは本当に助かりました。
Windows Updateの失敗と調査の進め方
緊急確認で落ち着きを取り戻したあと、改めてイベントビューアーの診断ルール一式を作ってもらい、
直近14日間のエラーを調べる初回診断を動かしてもらいました。
案内された対処をひと通り終えてPCを再起動したのですが、ここでまた別のトラブルが起きました。
再起動のあと、Windows 11の更新（Windows Update）がエラーを出して失敗してしまったのです。
修復用のコマンドなども試してみたのですが直らず、
私の方ではそもそもどこを見てどう調べればいいのか、調査の入り口すら分かりませんでした。
そこで、解決策だけでなく「普段AIが裏側でどうやって原因を調べているのか」も含めて聞いてみました。
教えてもらった話によると、画面に出るエラーコードはあくまで表面上の結果でしかなく、
本当の原因を知るには、浅い記録から専門の記録へと4段階で掘っていく必要があるそうです。
・更新画面と同じ失敗日時やエラー番号が並ぶ表面の記録
・イベントビューアーの中にあるパッケージ組み込み専用の記録
・システム修復の裏側で何が起きたかを残すさらに深い専門の記録
自分ひとりでこれらを順番に探して読み解くのはとても無理だなと痛感しましたが、
この深掘り調査の手順自体も、先ほど作った診断用の指示書ファイルにさっそく組み込んでもらえました。
次からは「更新が失敗するから調べて」と伝えるだけで自動で辿ってくれるそうです。
CPU交換が引き金になっていたBIOSの設定リセット
深掘り調査の結果をもとに案内してもらった修復手順を試してみたところ、
今度は更新の途中で確認画面が出て、TPM 2.0という項目だけが条件を満たしていないと表示されました。
また部品の買い替えでも必要なのかと少し身構えながら画面を見せて相談したのですが、
部品を買い足す必要はまったくないとのことでした。
マザーボードのBIOS設定で、スイッチを1つオンにするだけで直ると教えてもらいました。
使っているCPUには最初からその機能が内蔵されているものの、
マザーボード側の設定がオフになっているため、Windows側から見えない状態になっていたようです。
その説明を読んで、ようやく自分のやったことと頭の中で線が繋がりました。
実はここ最近、自分でCPUを以前のRyzen 3500系から5800系へと交換していたのです。
AIにその話を伝えたところ、まさにそれが直接の原因でした。
CPUを載せ替えると、初回起動時に新しいパーツが取り付けられたと判定されて、
マザーボードの設定が工場出荷時の初期状態に自動でリセットされる仕様になっているそうです。
手元のマザーボードのプログラムはWindows 11が出る前の少し古い時期のものだったため、
初期状態であるオフの設定に戻ってしまっていた、というからくりでした。
無事に更新が完了して学んだこと
案内してもらった手順通りにBIOSの設定画面を開き、
対象の項目をオンに切り替えてから修復を進めました。
しばらく待っていると、これまで引っかかっていたWindows 11の更新パッチがすべて正常に適用され、
ようやくまともな状態に戻りました。
念のため最後の健康診断もしてもらったところ、アプリケーションのエラー記録はゼロになり、
Cドライブの空き容量も十分に保たれていることが確認できました。
修復の保険で作られた一時保管用のフォルダも、10日ほど経てば自動で消えて容量が空くそうです。
古いBIOSとの組み合わせに関する予備知識
今後のための予備知識として、もう1つ役立つことも教えてもらいました。
今回のように新しい世代のCPUと少し古いBIOSを組み合わせてセキュリティ機能をオンにすると、
ゲームや動画の再生中に、数時間に1回ほど一瞬だけ音が割れて画面が引っかかることがあるそうです。
もし今後その症状が出ても故障ではなく、BIOSを新しい版に更新すれば直ると聞いて安心しました。
今回の作業を振り返ってみて、いくつか良い学びがありました。
・ログをAIに渡す前に、個人情報を伏せる保護ルールを固めておくと安心して任せられること
・見慣れない動きやエラーも、仕組みや調べ方から教えてもらうと落ち着いて対処できること
・自分で行ったCPU交換のような作業が、時間差でOSの更新エラーに繋がることがあること
これで、常駐プロセスの確認、ドライブ容量の棚卸し、エラーログ診断という3つの仕組みが揃いました。
チャットを新しく切り替えても、一言声をかけるだけで安全に定期点検ができるようになったので、
これからは変に放置せず、こまめにPCの健康状態を見ていこうと思います。