💡 【検証環境・個人研究（PoC）に関する注記】
本記事は、筆者個人の自宅検証環境（ホームラボ／仮想環境）において、公開情報およびOSS（オープンソースソフトウェア）を用いて独自に構築・検証した個人研究（PoC）の記録です。特定の企業・団体の実環境や業務上の非公開情報とは一切関係ありません。

はじめに：第1弾の反響と「その次」の絶望

前回の記事（第1弾：手打ちパッチ誤検知ゼロ化の話）では、BashとSQLiteを使って「すでに適用したパッチを脆弱性診断から引き算する仕組み」を紹介しました。

おかげさまで多くのインフラ屋・情シスの方から「うちも手動パッチの除外報告書で死んでいた」「過剰アラートを消せて胃薬の量が減った」と共感をいただきました。

……しかし、現場の運用はそこで終わりません。
過剰検知を消して**「本当に未適用の危険な脆弱性」**が浮き彫りになった瞬間、次の絶望がやってきます。

「未適用の端末が30台見つかったぞ……誰が1台ずつログインしてパッチ当てるんだ？」

夜間や休日にRDPでWindowsにログインし、あるいはSSHでLinuxに入り、コマンドを叩いて再起動を見守る……そんな「パッチあて当番」を繰り返していては、いくら診断を自動化しても人間がすり減るだけです。

「エージェントを入れて一括管理」ができない現場の壁

世の中には、パッチ管理や資産管理の立派な商用ソフトウェアがたくさんあります。
「各端末にエージェントソフトを常駐させれば、ボタン一つで一括アップデートできますよ」というやつです。

しかし、現場のリアルはそんなに甘くありません。

「勝手によく分からないソフトを入れるな」という社内の反発:
開発部署や役員端末など、「余計な常駐プロセスで重くなるのを嫌う」ユーザーは必ずいます。
エージェント自体のバージョンアップと死活監視という「負債」:
エージェントが固まった、エージェントが通信エラーを起こした……ツールの管理のために新たな運用工数が発生します。

現場が本当に求めているのは、「新しいソフトを常駐させず、OSが最初から持っている機能だけで、安全に中央からパッチを流し込む仕組み」 です。

設計思想：OS標準機能（WinRM ＆ SSH）による遠隔実行

今回構築したアーキテクチャは極めてシンプルです。

Windows端末: ポート 5985（WinRM: Windows Remote Management）を利用。PowerShellコマンドを直接リモート実行し、winget によるアプリ更新やWindows Update（特定KB）を適用。
Linux / macOS端末: ポート 22（SSH）を利用。apt upgrade や softwareupdate をリモート実行。

クライアント側に新しい常駐ソフトウェアをインストールする必要は一切ありません。

運用事故をゼロにする最大のキモ：「事前疎通診断（Pre-flight Check）」

リモートパッチ適用で最も恐ろしいのは、「途中で通信が切れてコマンドがハングする」「認証が通らずタイムアウト待ちでスクリプト全体が停止する」 といったトラブルです。

これらを防ぐため、パッチ実行コマンドを投げる直前に、必ず以下の**3重の事前疎通診断（Pre-flight Check）**をミリ秒単位で並列実行するガードレールを組み込みました。

実装・運用のポイント：エージェントレス実行の要点

1. 事前疎通診断（Pre-flight Check）ロジック

ソケット通信を使って、パッチを投げる前に一瞬（0.5秒以内）でポートの健全性を確かめます。

2. WinRM経由でのWindowsサイレントアップデート

Windows端末に対して、バックグラウンドで winget またはPowerShellコマンドを安全に実行させます。

第1弾との美しい連動：パッチ適用成功時に「台帳自動引き算」

パッチ適用が成功したら、前回の第1弾で作成した SQLite のパッチ台帳テーブル（applied_patches）に、スクリプトが自動で1行レコードを追記します。

これによって何が起きるか？

管理者がコマンド一発でリモートパッチを実行。
適用完了と同時に、SQLite台帳に「適用済み」の事実が自動登録される。
その直後に第1弾の超軽量プローブ（cve_lookup.sh）を実行すると、先ほどまでCriticalと騒いでいた脆弱性が「適用済みのため除外」と判定され、アラートが0件に消滅する！

人間が報告書に除外理由を手打ちする必要も、パッチ履歴をExcelにメモする必要も、1ミリもありません。

$ ./patch_and_verify.sh 192.168.1.15 CVE-2024-6387
[PRE-FLIGHT] 192.168.1.15 の SSH(Port:22) 疎通確認 ... OK (0.05s)
[DEPLOY] 遠隔パッチ適用中 (apt update && apt install --only-upgrade openssh-server) ...
[DEPLOY] 適用完了 (ExitCode: 0)
[LEDGER] SQLiteパッチ台帳へ記録完了: 192.168.1.15 - CVE-2024-6387
[VERIFY] 超軽量プローブ再診断実行中 ...
==================================================
ホスト: 192.168.1.15 (Ubuntu 24.04)
検出脆弱性: CVE-2024-6387 (適用済み台帳照合により除外)
結果: ✅ 未対応の危険脆弱性: 0件 (完全安全)
==================================================

おわりに：目指すべきは「人間がコマンドを打たない世界」

セキュリティ診断とパッチ適用は、本来**「両輪」**であるべきです。

診断だけを自動化しても、パッチあてが手動なら人間が破綻する。
パッチあてだけを自動化しても、台帳への反映が手動なら誤検知地獄は終わらない。

OS標準の機能（WinRM / SSH）をうまく使い、小さな台帳（SQLite）を真ん中に置くだけで、大掛かりな有償ソフトを導入しなくても**「エージェントレスで完結する堅牢な運用自動化」**は手に入ります。

「Windows環境のWinRMセットアップでハマった」「エージェントレスで資産管理台帳（Snipe-IT等）と組み合わせたい」といったご相談があれば、ぜひコメントやDMでお気軽に教えてください！

📚 さらに詳しい本番実装・トラブルシューティングについて

本記事は現場運用のエッセンスを凝縮したサマリー版です。
本番導入に向けた 「深層メカニズム解説」「完全パラメータ表」「現場アンチパターン」「トラブルシューティング対応表」「運用チェックリスト」 は、以下のGitHub完全技術リファレンスにて全網羅して公開しています。

👉 【第2弾詳細技術リファレンス】

⭐ 全14層・200パターンの自立型インフラ＆オンプレAIリファレンスを順次公開予定です。役に立った・面白かったと感じていただけましたら、ぜひリポジトリへの Star (★) をお願いいたします！
👉 GitHub リポジトリ: ojisan-arsenal