51時間、botは黙っていた。犯人はWindows Updateだった

前回：[83日でつくった自動売買botが、自分で決めた合格ラインに届かなかった話]

私が言ったのは、ただの愚痴だった

先に結論を書く。

最初の事故から原因が判明するまで、24日かかった。その間ずっと、AIと私は自動売買botのクラッシュ原因を追いかけていた。仮説を立て、対策を打ち、また落ちる。それを繰り返していた。

原因は、Windows Update の自動再起動だった。

botは一度も、自分から落ちてはいなかった。

そして、それに気づくきっかけを作ったのは、私が何気なく打ち込んだ一行の愚痴だった。技術的な指摘のつもりは、まったくなかった。

51時間、誰も気づかなかった

最初の事故は6月27日に起きた。

自動売買botが午前4時27分ごろに停止した。私がそれに気づいたのは、2日後だった。停止時間はおよそ51時間。

幸い、実害はほとんどなかった。停止した瞬間、保有中の建玉はゼロだったからだ。失われたのは機会だけで、お金ではない。ペーパートレードなので、そもそも本物のお金は入っていない。

だが問題は別のところにあった。

前回書いたとおり、このプロジェクトには実弾（本物の資金）を投入するための条件がある。その一つが「直近30日、インフラ事故がゼロであること」だ。

クラッシュするたび、このカウンターはゼロに戻る。原因が分からないまま落ち続ける限り、永遠に30日には到達しない。 私たちは、実弾（本物の資金）投入の入口に立つことすらできない状態だった。

AIが立てた仮説と、その全滅

原因究明はAIが担当した。私はコードが書けないので、ここは任せるしかない。

仮説1：隠しコンソール由来
botはバックグラウンドで動かしていた。Windowsのコンソールウィンドウに紐づいて起動していると、何かの拍子に「閉じる」信号を受け取って終了する可能性がある。

→ コンソールから完全に切り離した起動方式（detached）に変更。同時に、エラーの詳細を記録するログも仕込んだ。

→ 再発した。

仮説2：処理のタイムアウト
7月16日、別の対策を投入した。

→ わずか2日後、7月18日に再発した。

そして、仕込んだクラッシュログに残っていたのはこれだけだった。

ConnectionAbortedError: [WinError 10053]
確立された接続がホスト コンピューターのソフトウェアによって中止されました。

これは、私がブラウザで開いていた監視画面との接続が切れただけの、無害な記録だった。落ちた原因とは何の関係もない。

手がかりが、無い。

AIは、自分の報告が間違っていたことに気づいた

7月21日。定例のレポートを頼んだとき、AIから訂正が出た。

それまでAIは「無事故のカウンターは19日目、8月2日に満期です」と報告していた。だが監視ログを精査したところ、7月10日・15日・18日にも事故が起きていた。見落としていたのだ。

正しくは「19日目」ではなく「3日目」だった。

AIは自分でそれを見つけて、自分で訂正した。楽観的な数字を検証せずに引き継いでいた、と。

——ただし、原因は依然として分からないままだった。事故の回数は正確になったが、なぜ落ちるのかは謎のままだった。

それで、私は愚痴を書いた

そのやりとりの流れで、私はこう打ち込んだ。

本当に、ただの愚痴だった。パソコンを使っていて煩わしいと感じていたことを、なんとなく書いただけだ。botのクラッシュと関係があるとは、まったく思っていなかった。

AIの返答が、明らかに変わった。

4件が、すべて時刻一致した

AIが調べたのは、それまで一度も見ていなかった場所——Windowsのシステムイベントログだった。

botのクラッシュ時刻と、パソコンの再起動履歴を突き合わせる。結果はこうだった。

4件、すべて一致した。

差は1〜5分。監視プログラムは5分間隔でbotの生死を確認しているので、この差は「再起動が起きてから、監視が気づくまでのラグ」そのものだった。

`TrustedInstaller.exe` はWindowsの更新プログラムをインストールする本体だ。7月15日には、その直前（19:22）に `MoNotificationUx.exe`——「更新のため再起動します」という、あの通知を出すプログラム——も動いていた。

つまり、こういうことだった。

Windows Updateがパソコンを再起動し、その巻き添えでbotのプロセスが消えていた。

24日間、私たちが疑い続けていたbotのコードは、一行も悪くなかった。

なぜ、24日も見つからなかったのか

答えは単純だった。探していた場所が違った。

AIが見ていたのは、botが出力するログ——アプリケーション側の記録だった。そこにはコードの動きが残る。だからそこを疑い、そこを直し、そこに対策を打った。

だが原因はアプリの外、OSの側にあった。そしてOSのイベントログを、誰も見ていなかった。

これは技術力の問題ではないと思う。視野の問題だ。AIは「私が作ったものの、どこが悪いか」を探していた。私は「このパソコンで、何が起きているか」を眺めていた。バグは後者にあった。

コードが書けない私が持っていたのは、専門知識ではない。毎日そのパソコンを使っている、という情報だけだった。それがたまたま、決定打になった。

対策と、その後

原因が分かれば、対策は簡単だった。二つ打った。

1. 監視プログラムに「起動時トリガー」を追加。パソコンが再起動したら、その2分後にbotを自動で立ち上げ直す

2. ログイン中は自動再起動しない設定に変更（Windows Updateのダウンロードとインストールは続く）

効果はすぐに確認できた。

対策を入れた直後、別件でパソコンを再起動する機会があった。15時04分に再起動。botは15時07分、約2分後に自動復帰していた。 私は何もしていない。

そして今日（8月6日）まで、15日間ノークラッシュが続いている。対策前は数日おきに落ちていたことを思えば、明確な変化だ。

30日のカウンターは7月22日から動いている。満期は8月21日。残り15日。

コードが書けないことは、無力ではない

この一件で、AIとの付き合い方について考えを変えた。

AIに開発を任せると、こちらは「見ているだけ」になりがちだ。実際、コードのことは分からない。仮説の妥当性も評価できない。判断はほとんどAIに委ねていた。

だが今回、24日間の停滞を破ったのは、専門知識ではなく日常の観察だった。

AIは膨大なログを読める。私は読めない。
代わりに私は、そのパソコンの前に毎日座っている。AIはそこにいない。

見ている場所が違う。だから、持っている情報も違う。

だとすれば、AIとの協働で一番効くのは「AIに追いつこうとすること」ではなく、**「自分しか持っていない情報を、ちゃんと渡すこと」**なのだろう。

問題は、それをどう渡すかだ。私の場合はたまたま愚痴が当たっただけで、再現性がない。

——この「AIに何を、どう渡すか」については、後の回でまとめて書くつもりだ。実際に使っている引き継ぎ資料の実物も含めて。

現在地

• 原因：Windows Updateの自動再起動（botのコードは無実だった）

• 発見までにかかった時間：24日

• 決め手：技術調査ではなく、日常の愚痴

• 対策後：15日ノークラッシュ（対策前は数日おきに停止）

• 30日クロック：8月21日満期、残り15日

土台は直った。ただし前回書いたとおり、肝心の売買成績のほうはまだ合格していない。

botは、正しく動くようになった。正しく負けている、という状態は変わっていない。

次は、その30日クロックがどうなったかを書きます。

この記録は今後も、勝っても負けても同じ基準で公開していきます。