AIエージェントが「突然死ぬ」時の切り分け ― アプリのバグかOSの資源枯渇か

Windows で AI コーディングエージェント（Claude Code / Cursor / その他 Node・Electron 製ツール）が exited with code 3221226505 のような異常終了コードで突然落ちる時の確定手順と、 直し方をPCに詳しくない人に1クリックで渡すところまでの型。

推測で「メモリ不足かも」と言って終わらせないための、5分で原因を確定させるチェックリスト。

1. まず終了コードを読む（ただしコードだけで決めない）

3221226505 = 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN。 名前は紛らわしいが、実際の意味は __fastfail＝プロセスが「続行不能」と判断して自ら即死した。

Node 系ではこのコードになる原因が2つあり、対処が正反対なので必ず区別する。

原因	見分け方	対処
A. ランタイムの内部assertion	stderr に Assertion failed: の行がある	そのコードを直す（例: top-level await 中の process.exit() を廃止）
B. OS の資源枯渇	Assertion failed: が無い	OS 側の設定を直す（下記）

Assertion failed: が無ければ B を疑う。ここでアプリのソースを読み始めるのは時間の無駄。

2. 決定的な証拠はイベントログにある（最重要）

Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-6)} |
  Select-Object TimeCreated, Id, ProviderName, Message | Format-List

クラッシュ時刻の前後を見る。次があれば B（資源枯渇）で確定。

• 0x800705AF = ERROR_COMMITMENT_LIMIT（「ページング ファイルが小さすぎるため、この操作を完了できません」）
• System.OutOfMemoryException
• アプリと無関係なプロセスも同時に落ちている（シェル、OS標準アプリ、ヘルパープロセス等）

この「巻き添え」が決め手。単一プロセスのヒープ枯渇なら他のアプリは落ちない。 逆に、無関係なアプリまで同時刻に落ちているならシステム全体の資源が尽きている。

誤診しやすい罠

• 「イベントログに当該exeのエラーが無い」を"アプリは無罪でない証拠"と読むのは誤り。 __fastfail はエラー報告に faulting module を残さないことがあるので、 記録が無いことは何の切り分けにもならない。見るのは「同時刻の他プロセス」と「使用率」。
• GPU ドライバのタイムアウト記録（ライブダンプ）は件数が多くて目を引くが、この症状とは無関係。 本当に再起動していれば System ログに電源系の異常終了イベントが残る。無ければ再起動していない。

3. 使用率を数字で出す（コミット＝予約込みで見る）

$os = Get-CimInstance Win32_OperatingSystem
$cs = Get-CimInstance Win32_ComputerSystem
"コミット {0:N1} GB / 上限 {1:N1} GB ({2:N0}%)" -f (($os.TotalVirtualMemorySize-$os.FreeVirtualMemory)/1MB), ($os.TotalVirtualMemorySize/1MB), ((($os.TotalVirtualMemorySize-$os.FreeVirtualMemory)/$os.TotalVirtualMemorySize)*100)
"ページファイル自動管理: {0}" -f $cs.AutomaticManagedPagefile
Get-CimInstance Win32_PageFileSetting | Format-List Name, InitialSize, MaximumSize

90% を超えていたら危険域。 重要な性質:

• コミット上限 = 物理メモリ ＋ ページファイルのサイズ。物理メモリを増やしただけでは上限は伸びない。
• ページファイルを手動で固定サイズにしていると、そこが天井になる。
• 「ページファイルの現在使用量が少ない」は無関係。 予約（コミット）だけで上限を食うので、 実書き込みが数百MBでも上限には効いている。ここを混同して「まだ余裕がある」と誤読しやすい。

4. 誰が食っているかを特定する（WorkingSet ではなくコミットで）

Get-Process | Group-Object ProcessName |
  Select-Object Name, Count, @{n='Commit_GB';e={[math]::Round((($_.Group | Measure-Object PrivateMemorySize64 -Sum).Sum)/1GB,2)}} |
  Sort-Object Commit_GB -Descending | Select-Object -First 10

AI エージェントはセッションごとに1プロセスが常駐し、1本あたり数百MBを開いている間ずっと消費する。 実測例では エージェントのセッション 67本 = 31.4 GB（1本平均 481MB）で、 ブラウザのタブ 87本（18.8 GB）より多かった。開いたまま溜めるのが最大の消費源になる。

放置プロセスか実セッションかは親プロセスの生死で切り分ける。

$live = @{}; Get-Process | ForEach-Object { $live[$_.Id] = $_.ProcessName }
Get-CimInstance Win32_Process -Filter "Name='<対象>.exe'" | ForEach-Object {
  [pscustomobject]@{
    Pid = $_.ProcessId
    Age_h = [math]::Round(((Get-Date) - $_.CreationDate).TotalHours,1)
    Parent = if ($live.ContainsKey([int]$_.ParentProcessId)) { $live[[int]$_.ParentProcessId] } else { 'DEAD' }
  }
} | Group-Object Parent

• Parent = DEAD → 孤児。安全に終了できる
• 親が生きている → 利用者が実際に開いている。勝手に終了させず、本人に確認する

5. 直す（効果順）

1. ページファイルを「システム管理」に戻す ＝ コミット上限が自動で伸びる。要管理者＋再起動。

   $cs = Get-CimInstance Win32_ComputerSystem
   Set-CimInstance -InputObject $cs -Property @{ AutomaticManagedPagefile = $true }
   

2. セッションを溜めない運用にする。1本が常時数百MBを予約するので、 「1セッション=1目的で閉じる」はトークン効率だけでなくマシンの安定性そのものに効く。
3. 不要プロセスの終了は必ずPID指定。taskkill /IM <name>.exe 型の一括killは 稼働中の作業を巻き添えにする。自分自身の祖先PIDを親子チェーンで辿って除外すること。

やってはいけない対処

ヒープ上限を上げる（NODE_OPTIONS=--max-old-space-size=... を増やす）のは逆効果。 ランタイムのヒープ上限は「1プロセスがどこまで膨らめるか」の話で、 システムのコミット上限が縛っている場面で上げると、1プロセスがより多く予約することを許すだけで 巻き添えを広げる。まず上限そのものを広げるのが順序。

6. 直し方を「PCに詳しくない人」に1クリックで渡す（ここで失敗しがち）

管理者権限が必要な変更は本人にクリックしてもらうしかない。その渡し方に静かに失敗する罠がある。

• .ps1 はダブルクリックでは実行されない。 既定の関連付けは「編集（メモ帳で開く）」。 「ダブルクリックで」と案内するなら、起動用の .cmd を必ず添える。
• .cmd の中身とファイル名は ASCII のみにする。 cmd.exe はバッチを OEM コードページ（日本語環境なら CP932）で読む。 多くのエディタ/ツールの既定は UTF-8(BOM無し)なので、.cmd に非ASCII文字を書くと化ける。 とくに非ASCIIのファイル名を .cmd の中で参照すると、渡すパスが壊れて起動直後に失敗し、 黒い画面が一瞬で閉じる ＝ 相手には「ダブルクリックしても何も起こらない」としか見えない。
• 切り分けの一撃:

  cmd.exe /c "if exist "<非ASCIIを含むパス>" (echo FOUND) else (echo NOT-FOUND)"
  

  ファイルが実在するのに NOT-FOUND が返ればこれが原因。
• メッセージ用の .ps1 は BOM 付き UTF-8 で保存する（古い Windows PowerShell は BOM が無いと非ASCIIをシステムコードページとして読み、表示が化ける）。 併せて [Console]::OutputEncoding = [Text.Encoding]::UTF8 を入れる。
• スクリプトに読み取り専用の -Check スイッチを付ける。 → 権限昇格のダイアログを出さずに「文字化けしないか・パスが通るか」を検証できる。
• 検証はダブルクリックと同じ経路で実走する（cmd.exe /c "<launcher>.cmd" -Check）。 スクリプト単体を実行して通っても、.cmd 経由で壊れていれば意味がない。
• 手数をさらに減らす: 相手にファイルを探させるより、 こちらから Start-Process -Verb RunAs で昇格ダイアログを出せばクリック1回で済む。
• 変更前の設定は必ずファイルに退避し、元に戻す1行を画面に表示する。 相手が「壊れないこと」を確認できて初めて押してもらえる。

7. 完了の判定基準

• Assertion failed: の有無でAとBを切り分けた
• イベントログの同時刻に資源枯渇のエラーと巻き添えのプロセスを確認した
• コミット使用率と上限の内訳（物理メモリ＋ページファイル）を数字で出した
• 消費元をコミットで集計し、孤児か実セッションかを親プロセスで判定した
• 終了させたプロセスの履歴・作業が失われていないことを確認した
• 渡した起動ファイルをダブルクリックと同じ経路で実走し、文字化けなく終了コード0を確認した
• 設定が実際に変わったことを読み戻して確認した（「実行した」ではなく「変わった」を確認する）