AIエージェントにPCの障害調査を任せた2日間｜任せてよかったこと、任せて失敗したこと

はじめに：AIに「実機の調査」を任せてみた

AIOPulse の運営元である Marketing Cloud Lab では、サイトの運用や調査に AI エージェントを使っています。この「AI運用ノート」では、AI に仕事を任せた記録を残していきます。うまくいったことだけでなく、うまくいかなかったことも、そのまま書きます。

第 1 回の題材は、運営者の私が自宅で使っている PC のトラブルです。ローカル LLM を動かすために使っている HP OMEN 30L に、メモリを足して 64GB にしようとしたら、Windows が通常起動しなくなりました。2 日間、ChatGPT と Claude Code に手伝わせて原因を調べ、最後は買ったメモリ（CFD の 16GB×2）を諦めました。

なお、この PC は AIOPulse の計測の仕組みとは関係がありません。AIOPulse の計測には影響していません。

この記事では、次のことを書きます。

• AI の役割分担
• 任せる前に決めた約束事
• 任せてよかったこと、任せて失敗したこと
• 仕事で AI エージェントを使うときのチェックリスト

技術的な手順と時系列の全記録は、姉妹サイト AIpedia の「AI実践ログ」にまとめました（このページの下の関連リンクから読めます）。

何が起きたか：3分でわかる経緯

日時	起きたこと
10/12	Claude Code にメモリ選びを調べさせる。CFD の 16GB×2 が推奨になる。ただし「未確認の点」つき
11/01 午後	CFD を挿すとビープ音が鳴り、画面が出ない。CMOS の電池が切れていたことも分かる
11/01 22:20 ごろ	電池を交換して 4 枚・64GB に。BIOS は 64GB を認識し、UEFI のメモリ高速テストも合格。しかし通常起動は、ロゴの下の白い輪で止まる
11/02 朝	64GB でも、セーフモードなら起動する
11/02 昼	セーフモードの PC に Mac から SSH で入れるようにし、Claude Code がログを集めて分析
11/02 午後	GPU の無効化や BIOS の設定変更で切り分け。AI が提案した BIOS の変更で POST（電源を入れた直後の自己診断）すら通らなくなり、CMOS の電池を外して戻す
11/02 16:58	元の 2 枚（32GB）に戻すと通常起動できる。原因は「CFD を加えたこと」にしぼられる
11/02 17:04	CFD を諦め、HP 純正のメモリを買い直すと決める

64GB での通常起動は、記録で確認できるだけで 7 回失敗し、成功は 0 回でした。元の 32GB での通常起動は、すべて成功しています。

ただし、原因は完全には特定していません。CFD のメモリが不良だとは言えません。CFD そのもの（または HP 以外のメモリに対する BIOS の扱い）なのか、2 種類を混ぜたことなのかは、CFD の 2 枚だけで試していないので分からないままです。

役割分担：ChatGPTは「目」、Claude Codeは「手」と「記録係」

PC がまともに起動しない間、画面の中身を AI に渡せるのは、スマートフォンのカメラだけでした。そこで、写真を読める ChatGPT（スマートフォン）を「目」にしました。BIOS の画面、ビープ音、回復画面などを撮って読ませ、その場で次の手順を聞きました。相談の流れも、時刻があいまいなものは「時刻不明」と区別した履歴にまとめさせました。

Claude Code（Mac）は「手」と「記録係」です。Mac から SSH で PC の中を調べ、ログを集めて突き合わせ、切り分けのテストを実行し、報告書と手順書を書きました。BIOS の画面は、ChatGPT が写真から作った要約を、私がそのまま渡しました。Claude Code は写真そのものは見ていません。

人間（私）の担当は、電源ボタン、メモリの抜き差し、BIOS の操作、そして「その変更を実行するかどうか」の判断です。

この形では、AI 同士は直接つながらず、人間が要約を運びます。運ぶ途中で、情報が落ちたり変わったりするおそれがあります。写真の読み取りに誤りがあれば、その誤りはそのまま次の AI に伝わります。それでも、役割を分けたことで、それぞれの AI が得意な所に集中できました。

任せる前に決めた約束事

AI エージェントに実機を調べさせる前に、次の約束事を決めました。

1. 読み取りを先にする：最初の診断スクリプトは読み取り専用にしました。変える前に、今の状態を正確に知るためです。
2. 変更は「変更前の値と戻し方」を先に書かせ、実行するかは人間が決める：レジストリの変更や GPU の無効化などが当たります。
3. 情報の種類を分けて書かせる：実機の記録、私の記憶、資料上の情報（フォーラムなど）、推論の 4 つを混ぜないようにしました。
4. 時刻は実時刻に直してから突き合わせる：PC の時計は 32 分、のちに 2 時間 20 分ずれていました。ずれたまま並べると、出来事の順番を読み違えます。
5. 1 回に 1 か所だけ変える：一度に複数を変えると、何が効いたのか分からなくなります。

2 の例が、セーフモードで SSH を使えるようにしたレジストリの変更です。HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network に sshd を登録する必要がありました。Claude Code には、変更前の控え（reg export）、変更の中身、効く範囲、副作用、戻し方を手順書に書かせました。私はそれを読んでから、自分でコマンドを実行しました。

3 の効果も大きかったです。私には「白い輪の間も、裏で Windows は動いているのでは」「CFD が不良なのでは」という思い込みがありました。Claude Code は実機の記録を示し、思い込みと、記録で確かめられたことを分けて扱いました。「CFD が不良だ」ではなく、「記録の上では、64GB で通常起動に成功したことが一度も無い」という事実から考えられました。

実際に渡した指示と、返ってきた報告の形

Claude Code への指示文は、スマートフォンの ChatGPT に下書きさせ、私が Mac に貼り付けました。AI に、別の AI への指示を書かせた形です。SSH で調べ始めるときの指示は、おおよそ次の 7 項目でした。

1. 既存の接続資料と SSH の設定を、まず読む
2. 短い時間切れの設定で、つながるかを確かめる
3. つながらなければ、「時間切れ」「接続の拒否」「認証の失敗」を区別し、PC 側で必要な最小限の確認を示す
4. つながったら、構成、メモリ、BIOS、自動修復の記録、直近のイベントログなどを集める
5. Mac 側のメモ、フォーラムの情報、実機の値を分けて分析する
6. 強制終了の記録（Kernel-Power 41）と本当の故障を区別し、セーフモードで止まっているサービスを、そのまま障害とみなさない
7. 次に試すことは 1 つだけにして、戻し方と一緒に提案する

あわせて、この段階では「やらないこと」も書きました。自動の再起動、BIOS やメモリの設定の変更、サービス・レジストリ・ファイアウォールの変更、ドライバーの削除、OS の修復や初期化です。読み取りの範囲を、言葉ではっきり区切ったわけです。

午後になって、私は「そっちでテストもやって」と範囲を広げました。そこからは、GPU の無効化のような変更も、私の許可を得たうえで Claude Code が SSH で実行しています。最初は狭く、様子を見て広げる。段階を分けて任せた形です。

返ってくる報告は、毎回ほぼ同じ見出しで書かれていました。

見出し	書かれていたこと
実機から取得した事実	コマンドの結果、ログ、時刻（実時刻に直したもの）
資料上の情報（実機では未確認）	メーカーの資料、フォーラムの書き込み
読み取り（推論）	事実から言えることと、言えないこと
次の一手（実行するのは利用者）	試すことを 1 つ、目的、手順、結果の見方
元に戻す方法	変更前の値と、戻すコマンド
ファイル	根拠になった記録の置き場所

この形のおかげで、報告を読むたびに「どこまでが確かなのか」を迷わずに済みました。あとからこの記事を書くときも、時刻と根拠をそのまま拾えました。

任せてよかったこと

いちばん助かったのは、いくつもの記録を並べて突き合わせる作業です。人がやれば何時間もかかる作業を、AI は速く、根拠つきで出してきました。

別のログから、時系列を作り直した

PC がいつネットワークに居たのかは、PC 側の記録だけでは分かりませんでした。Claude Code は、Mac 側に残っていた別の自動処理のログ（PC に定期的につなぎに行く処理の記録）を使い、それを復元しました。「11/01 の 21:51 より後、朝の 08:53 まで一度もネットワークに現れていない」。これで、「白い輪の間も裏で Windows は動いている」という説は弱まりました。

決め手の 1 行を探し当てた

最後に通常起動に成功したとき、メモリは 32GB だったのか、64GB だったのか。私の記憶では決められませんでした。Claude Code は、NVIDIA のアプリが起動時に書いた設定ファイル（SHIM.json）から、「物理メモリ約 32GB」という記録を見つけました。この 1 行で、「通常起動に成功したのは 32GB のときだけ」と確定しました。

「書かれなかった記録」を証拠にした

ブートログを有効にして通常起動しても、白い輪で止まり、ブートログには 1 行も増えませんでした。Claude Code はこれを、「ブートログを書く前の、かなり早い段階で止まっている」と読みました。イベントログも 1 件も残っていません。記録が無いこと自体が、止まった場所の手がかりになりました。

切り分けのテストを、戻せる形で回した

GPU のドライバーが原因かを見るため、私の許可を得て、Claude Code が SSH で NVIDIA の GPU を無効にし、通常起動を試しました。結果は同じく停止。NVIDIA は候補から外れ、GPU はすぐに有効に戻しました。戻すコマンドを、実行の前に決めてありました。

任せて失敗したこと・危なかったこと

1. AI の提案で、POST すら通らなくなった

BIOS のメモリ設定の画面（Memory Overclocking）の値を仕様と照らし、Claude Code は「tRFC を 560 から 880 に変える」ことを提案しました。足した CFD のチップ（16Gb）に規格で必要な値で、仕様の上では筋の通った提案です。

ところが、手動の設定に切り替えて 880 にすると、ビープ音が鳴り、POST で止まるようになりました。手動に切り替えたとき、画面に出ていた規格外の値（tWTR_S の「0」）までそのまま使われた可能性がある、というのが後からの推論です。電源を何度入れ直しても戻らず、CMOS の電池を外して初期化して、やっと元に戻りました。

提案には、最後の手段として「CMOS の電池を外す」という戻し方が添えてありました。だから取り返せました。AI 自身も、「BIOS でタイミングを手で変えるのは、ほかに方法が無いときだけにする」と記録に残しています。

2. 根拠の無い確率

「BIOS を更新したら直る可能性は？」と聞くと、AI は「1〜2 割くらい」と答えました。本人が「根拠のある数字ではなく見立て」と断っていたのは良かった点です。それでも、数字は一度出ると独り歩きしがちです。根拠を聞き、無ければ「見立て」として扱う必要があります。

3. 集めすぎた

読み取り専用の診断スクリプトが、BIOS にある OEM 版 Windows のプロダクトキーに関わる情報まで集めてしまいました。Mac 側のコピーは伏せ字にしました。スクリプトには、要約の手順で例外が出る、隠しファイルの扱いを誤って pagefile を「無し」と記録する、といった不具合もありました。AI が書いたコードも、人が書いたコードと同じように間違えます。

4. 自分の説明を訂正した

Claude Code は、「メモリの誤りの記録（WHEA）がゼロ」を正常の材料のように書いていました。しかし、このメモリには ECC（誤りを検出・訂正する機能）が無く、そもそも WHEA には記録されません。あとで AI 自身が訂正しました。その一文だけを読んでいたら、「メモリは問題ない」と早合点していたかもしれません。

5. 出発点の推奨を、読み流していた

10 月にメモリ選びを任せたとき、AI は CFD を推奨しつつ、「2 ランクと 1 ランクの混在は未確認」「この BIOS での動作は未確認」と書いていました。つまずいたのは、まさにその「未確認」のあたりです。私は推奨の文だけを読んで、未確認の欄を読み流していました。

AI の提案は、「仕様の上では正しい」ことが多いです。しかし、OEM の BIOS の癖のような、手元の機械の事情までは知りません。戻し方を確かめてから試せば、失敗しても取り返せます。

AIの答えを「確かめる」のは、AI検索でも同じ

今回の失敗の多くは、AI の答えをそのまま受け取ったところから起きました。推奨の文だけを読んだ。仕様の上の正解を、そのまま実機で試した。根拠の無い数字が出てきた。

AIOPulse が扱う AI 検索にも、同じ構図があります。ChatGPT・Gemini・Claude の答えは、聞き方や日によって変わります。1 回の答えだけで「自社は AI に推薦されている」「されていない」と決めず、条件をそろえて繰り返し確かめ、事実と推測を分けて読む必要があります。AI の答えが文脈や地域で変わる点は、AI 検索のパーソナライズの解説でも扱っています。

AIOPulse の連載「日常の論点を、AIに条件を変えて聞いてみる」も、同じ考え方です。ChatGPT・Gemini・Claude に条件を 1 文ずつ変えて聞き、答えの重心がどう動くかを記録しています。

AIOPulse を使えば今回のような失敗が防げる、というわけではありません。ただ、「AI の答えは、確かめるまで分からない」という考え方は同じです。

仕事でAIエージェントを使うときのチェックリスト

今回の経験から言えることを、チェックリストにしました。

1. まず読み取りだけを任せる：ログや状態の確認から始める。今回は、SSH で読み取り専用のスクリプトを動かし、結果を回収するところまでを最初の範囲にしました。
2. 変更は「変更前の値・戻し方・効く範囲」を先に書かせ、実行は人間が決める：レジストリや BIOS のように、システムに効く変更は特に。
3. 事実・記憶・資料・推論を分けて書かせる：推論は、断定ではなく仮説として扱う。
4. 確率や見込みの数字には、根拠を聞く：根拠が無ければ「見立て」として扱う。
5. 推奨と一緒に出てくる「未確認」の欄を、必ず読む：リスクは、そこに書いてあることが多い。
6. 1 回に 1 か所だけ変える：何が効いたのか分かるようにする。
7. AI が集める情報の範囲を、先に決める：秘密や識別情報が混ざったら伏せる。
8. 時刻などの前提をそろえてから突き合わせる：今回は PC の時計が最大 2 時間 20 分ずれていました。
9. 諦める判断（損切り）も、材料をそろえて人間が決める：今回は「CFD の 2 枚だけで試しても、どちらの結果でも直し方は『HP のメモリにそろえる』で同じ」という整理が決め手でした。

AI エージェントは、「速くて疲れない調査係」として、とても役に立ちました。ただ、最後の判断と責任は人間に残ります。

まとめ

2 日間の調査で、AI は記録の突き合わせと切り分けで大きく役立ち、BIOS の変更の提案では失敗しました。メモリの増設は失敗し、HP 純正のメモリで出直すことになりました。

AI の答えは、確かめてから使う。設定を変える前に、戻し方を先に用意する。この 2 つは、PC の調査でも、AI 検索の対策でも変わりません。

技術的な時系列の全記録は、AIpedia の「AI実践ログ」にあります。