はじめに：AIを「単一障害点（SPOF）」にしてはいけない
LAN内システムや自動化ツールにローカルLLM（Ollama等）やクラウドAI APIを組み込む動きが盛んです。
「OSの判定」「脆弱性の要約」「機器のリプレース提案」などをAIに任せることで、柔軟なシステムが作れます。
しかし、現場で運用し始めたとき、インフラエンジニアなら誰もが背筋の凍るリスクに気づきます。
- 「Ollamaコンテナがメモリ不足（OOM）で突然落ちたらどうなる？」
- 「AIの推論サーバーが過負荷でタイムアウトしたら、毎朝のスキャン処理が全台エラーで止まるのか？」
- 「クラウドAIの障害やAPI制限のせいで、LAN内資産の棚卸し業務がストップするのか？」
AIがダウンしたからといって、システム全体のコア機能（資産の検出、台帳登録、トポロジー表示）まで道連れにして落とす設計は、エンタープライズの現場では「絶対悪」 です。
AIはあくまで「付加価値（アドオン）」であるべきです。AIが死んでも、従来の「静的辞書・決定論的ルールエンジン」にミリ秒単位で切り替わり、100%の業務を継続できるフェイルソフト設計 を組み込みました。
1. 決定論的ルールエンジンの実装
AIが不在でも、OSのバージョン判定やサポート終了（EoL）の警告は、正規表現と辞書テーブルを使えば完全に決定論的（100%の再現性）に判定できます。
💻 コア実装・設定スニペット（抜粋）
# コア実装ロジック（要点抜粋）
import re
# サポート終了 (EoL) 日時辞書
EOL_DATABASE = {
"windows 10": {"eol": True, "date": "2025-10-14", "msg": "Windows 10 はサポート終了間近です。Win11へ移行してください。"},
"windows 7": {"eol": True, "date": "2020-01-14", "msg": "サポート終了済みOSです。ネットワークから即時遮断してください。"},
"ubuntu 18.04": {"eol": True, "date": "2023-05-31", "msg": "Ubuntu 18.04 LTS は標準サポート終了済みです。"},
"ubuntu 20.04": {"eol": False, "date": "2025-04-02", "msg": "間もなくサポート終了予定です。"},
}
def analyze_asset_by_rules(raw_os: str, ports: list, banners: dict) -> dict:
"""
LLMを一切使わず、高速かつ決定論的に資産分類・EoL判定を行う
処理時間: 0.1ミリ秒
"""
clean_os = (raw_os or "不明").lower()
# 1. OSおよびEoL判定
is_eol = False
eol_message = "サポート期間内です。"
for os_key, eol_info in EOL_DATABASE.items():
if os_key in clean_os:
is_eol = eol_info["eol"]
eol_message = eol_info["msg"]
break
# 2. 稼働ポートに基づくデバイス分類
device_category = "一般端末"
if 445 in ports and 548 in ports:
device_category = "NASストレージ (Synology/QNAP等)"
elif 9100 in ports or 515 in ports:
device_category = "プリンタ・複合機"
elif 22 in ports and "linux" in clean_os:
device_category = "Linuxサーバー"
elif 3389 in ports:
device_category = "Windowsクライアント/サーバー"
return {
"engine": "DETERMINISTIC_RULES", # ルールベース判定であることを明記
"device_category": device_category,
"is_eol": is_eol,
"recommendation": eol_message
}
2. スキャナー側の二重フォールバック制御
スキャナー本体では、LLMの呼び出しを try-except およびヘルスチェックでラップし、異常発生時は1秒以内にルールエンジンへフォールバック させます。
3. CI/CDでの「フェイルソフト自動検証テスト」
この耐障害性が本番で確実に機能することを保証するため、単体テストスイートを用意しています。
「あえてLLMコンテナを停止させた状態」 でテストを実行し、Web画面やスキャンAPIが正常にステータス200を返すかを自動検証します。
まとめ：プロフェッショナルのシステム設計思想
AI技術は華やかですが、実世界のインフラ運用の現場では**「どんな悪条件でも絶対に落ちない頑丈さ」** が最も高く評価されます。
- AIを「主役」ではなく「ブースター（加速器）」と位置付ける
- AIが落ちたら、何事もなかったかのようにルールエンジンが肩代わりする
- ユーザー体験（UX）を1秒たりとも遮断しない
このフェイルソフト思想を持って設計することこそが、PoCで終わる「おもちゃのAI」と、本番運用に耐えうる「堅牢な製品」を分ける決定的な境界線です！
📚 さらに詳しいアーキテクチャ設計・パラメータ表・トラブルシューティング
最後までお読みいただきありがとうございます！
本記事が少しでも「役に立った」「あとで試したい」と感じていただけましたら、ぜひQiitaの 「いいね（♡）」 と 「ストック」、および アカウントのフォロー をいただけると今後の検証・執筆の大きな励みになります！
また、本記事のさらに踏み込んだ 「深層アーキテクチャ解説」「主要パラメータの技術的根拠」「現場アンチパターン・トラブルシューティング対応表」 は、以下のGitHub技術リファレンスにて公開しています。
👉 【第27弾 詳細技術リファレンス (QIITA_ARTICLE_DETAIL_27.md)】
⭐ 全14層・200パターンの自立型インフラ＆オンプレAIリファレンス集（おじさんの武器庫）を順次公開中です。ぜひGitHubリポジトリへの Star (★) と X (@OjisanTechnical) のフォローもお願いいたします！
👉 GitHub リポジトリ: ojisantech/ojisan-arsenal
💡 【検証環境・個人研究（PoC）に関する注記】
本記事は、筆者個人の自宅検証環境（ホームラボ／仮想環境）において、公開情報およびOSS（オープンソースソフトウェア）を用いて独自に構築・検証した個人研究（PoC）の記録です。特定の企業・団体の実環境や業務上の非公開情報とは一切関係ありません。