Linux向け無料EDRは実質Wazuh一択だった — 自宅RasPi 5で4.5ヶ月運用した本音と実測

TL;DR: 個人のLinuxなら、Wazuhで無料のEDR的監視は十分現実的です。この記事では、RasPi 5で4.5ヶ月運用して分かったことと、詰まりやすいところを実運用ベースでまとめます。

• 結論: 個人のLinuxならWazuhで無料のEDR的監視は現実的
• この記事でやること・やらないこと
• 先に答え: 何ができて、何ができないか
• 実機構成: RasPi 5 16GBとNVMe SSDで回した
• 4.5ヶ月運用して分かったこと
• 実例① OOMで「なんか落ちた」が「何が・いつ・なぜ」に変わった
• 実例② CVEの見逃しを減らす使い方
• 一番つまずいたのは導入手順ではなくARM64の構成だった
• ノイズは多い。だから2段フィルタが要る
• SCAスコアが思ったほど高くなくても焦らない
• 判断の目安: こういう人には合う
• 次にやること
• 注意点・制約
• どのように検証したか
• よくある質問
  • 手順通りに進めても動かない場合は？
  • どのOSで動作確認していますか？
• 参考リンク
• この記事を書いた人

まず結論からいきます。個人のLinux環境なら、Wazuhで無料のEDR的監視は十分現実的です。実際、私はRaspberry Pi 5 1台でLinux 3台 + Windows 1台の計4台を、2026-01-15の運用開始から4.5ヶ月ほど監視し続けています。

ただし、ここは先に線を引いておきます。Wazuhは商用EDRの完全代替ではありません。それでも、「何もない」状態と比べると、何が・いつ・なぜ起きたかが見えるようになります。個人の自宅サーバーや小規模Linux環境では、この差がかなり大きいです。

B2Bの比較サイトを見ても、個人が自宅で本当に運用できるのか、手間はどれくらいか、何が見えるのかはぼやけがちです。この記事では、そこを実運用の感触ベースで書きます。

この記事でやることは、**「無料EDR的監視を個人のLinuxで持てるのか」**を判断できるようにすることです。

• 何が無料でできるか
• 何が商用EDRと違うか
• Raspberry Pi 5で回したときの実感
• ノイズをどう扱うか
• 導入後にどこを見ればよいか

やらないことは、以下です。

• Wazuhの構築手順の完全解説
• 脆弱性個別対応の深掘り
• 自動化や連携の作り込み

そこは別記事に切り分けています。構築で詰まった人は BlogRasPi 5にWazuhを入れたら、Dockerが死んだ話——自宅セキュリティ監視の実録RasPi 5（ARM64）にWazuhをDocker Composeで構築しようとしたらIndexerが落ちて失敗。直接インストールに切り替えた実録。3台を監視したらCritical脆弱性が203件出てきた話。→ を、脆弱性の見方は BlogWazuhを入れたら脆弱性が3,247件検出された話【RasPi 5 自宅ラボ セキュリティ実録 #2】Wazuhの脆弱性ダッシュボードに「3,247件」と表示された。焦ったが、分解してみると数字の正体はシンプルだった。旧カーネル・謎のThunderbird・CVSS 9.8の正体——自宅ラボ実録。→ を、検知を自動化したい人は BlogWazuhとClaude Codeを繋いだら、CVE調査と修正提案が自動化できた【自宅ラボ セキュリティ実録 #3】Wazuh REST APIでCVEリストを取得し、Claude Codeに渡したら調査と修正コマンド生成が自動化できた。93件のCriticalを手動で追っていた状態からの脱出実録。→ を見てください。

ここで一度、足元を見ておきます。Wazuhを「無料EDR」と呼ぶときに、混同しやすい点があります。

要するに、WazuhはEDR的な監視を無料で持てるのであって、商用EDRと同じではありません。

でも、個人のLinuxで本当に困るのは「完全遮断」より先に、「何が起きたか分からないこと」です。そこを埋めるだけでも、かなり価値があります。

実機は以下です。

• Raspberry Pi 5 16GB
• NVMe SSD 256GB
• Wazuh Manager v4.14.5
• 監視対象: Linux 3台 + Windows 1台

電源やケース、冷却は構成により変わるので、型番はここでは固定しません。まずはRasPi 5 16GBとNVMe SSDを押さえるのが先です。この監視サーバーを含む自宅ラボ全体の実機構成は Homelab実機ビルド一覧 にまとめています。

この組み合わせで、Wazuh一式（Manager / Indexer / Dashboard）を4.5ヶ月運用できています。RasPi 5で監視サーバーを立てると聞くと、最初は少し無茶に見えるかもしれません。正直、私も最初はそう思いました。

でも、実測では話が違いました。

2026-06-04時点の実測では、Wazuh一式のメモリ使用量は約2.7GBでした。うち、IndexerのJavaが1.58GB。CPUのload averageは0.50、CPU温度は56.2°C、15日連続稼働でも余裕ありです。

16GB版のRaspberry Pi 5なら、少なくともこの規模では苦しくありません。

ここで重要なのは、スペック表の安心感ではなく、実際に回っているかです。ホームラボは「動く」だけなら簡単ですが、「忘れた頃も動いている」が本番です。その意味で、4.5ヶ月の無停止運用は判断材料になります。

これが一番大きかったです。

ある日、ワークステーションでメモリが枯渇し、OOM Killerがパスワードマネージャ（2.7GB）とChromeを強制終了しました。ついでにtmuxセッションも2つ巻き添えです。現場では、こういう時に「また変なことが起きた」で終わりがちです。

でもWazuhが、rule 5108 / Level 12でリアルタイム検知しました。LINE通知が飛び、翌日にログを追ってみると、原因はメモリリーク + swap不足でした。

その後は、swapを8GB→16GBに増やして恒久対処。

これは大きな収穫でした。EDR的な監視があると、単なる「落ちた」が、**「何が・いつ・なぜ」**に変わります。記憶や勘ではなく、事実をログの時系列で並べて原因にたどり着けるのです。これが分かるだけで、復旧の速さも、再発防止の精度も変わります。

Wazuhは、パッケージ更新のたびに脆弱性DBと突合して、該当CVEを通知できます。実際、CVE-2026-31448 などが rule 23506 / Level 13 で自動通知されました。

ここで大事なのは、Wazuhが「脆弱性がある」と教えてくれるだけで、修正を魔法のように済ませるわけではない点です。通知は入口です。そこから

• 影響範囲はどこか
• そのパッケージは本当に使っているか
• その場で上げてよいか
• 代替や待機が必要か

を判断します。

脆弱性の個別対応は長くなるので、詳しくは BlogWazuhを入れたら脆弱性が3,247件検出された話【RasPi 5 自宅ラボ セキュリティ実録 #2】Wazuhの脆弱性ダッシュボードに「3,247件」と表示された。焦ったが、分解してみると数字の正体はシンプルだった。旧カーネル・謎のThunderbird・CVSS 9.8の正体——自宅ラボ実録。→ に分けています。

Raspberry Pi 5はARM64です。ここで、WazuhのDocker構成は動きませんでした。少なくとも私の環境では、ここが最初の罠でした。

結論だけ言うと、debパッケージの直接インストールが正解でした。systemdサービス3本で組む構成です。

このあたりは構築記事に詳しく書いていますが、本記事で覚えておくべきなのは1点だけです。RasPi 5でWazuhをやるなら、Docker前提で考えない方が早い。これだけです。

Wazuhは便利ですが、静かな監視ツールではありません。むしろ、正常な変更も全部拾うので、最初は驚きます。

私の1日実測では、

• FIM Integrity checksum changed が 762件/日
• dpkg 系が 281件/日

という具合でした。apt upgrade を1回回すだけで、FIMが数百件発火することがあります。

ここで「うるさいから失敗」と切るのは早いです。Wazuhは、異常だけでなく変更の記録装置でもあります。だから通知をそのまま全部飛ばすと、人間が先に疲れます。

運用のコツは、2段フィルタです。

1. LINE通知は Level 12+ のみ
2. さらに 30分クールタイム を入れる

これで、通知は月数件まで圧縮できました。

誤検知というより、正常な変更も全部記録されるのが本質です。ここを理解していないと、「役に立つのに疲れる」という、いちばんもったいない状態になります。

CIS Ubuntu 24.04 のSCAスコアは、私の環境では 48〜53% でした。

数字だけ見ると低く感じますが、内訳を見ると、failの大半は

• 独立パーティション未分離
• mount オプション系

でした。

ホームラボでこれを全部厳格適用すると、別の問題が出ます。たとえば AI サーバーで /tmp noexec を強くかけると、PyTorch系が壊れることがあります。

つまり、SCAは点数を上げる競技ではありません。自分の用途に合わせて、どこを守り、どこを緩めるかを見るものです。

スコアが低いからダメ、ではなく、何が理由で低いのかを見て判断してください。

Wazuhは、次のような人にはかなり相性がいいです。

• 自宅サーバーやVPSの異常を、あとから説明できる形で残したい
• 商用EDRは高くて手が出ないが、監視は欲しい
• Linuxの変更や脆弱性を、1台にまとめて見たい
• ノイズを許容してでも、見える化を優先したい

逆に、

• 自動隔離や自動遮断が必須
• 通知の少なさを最優先したい
• 導入後のチューニングに時間を使いたくない

なら、Wazuh単体では期待値がずれます。

この記事の結論はシンプルです。個人のLinuxならWazuhで無料のEDR的監視は現実的に持てる。そして、RasPi 5一台で4台監視が4.5ヶ月回っている。ただし、商用EDRの完全代替ではない。

次にやることは3つです。

1. 自分の環境で「何を見たいか」を決める
2. RasPi 5 16GB + NVMe SSD で回す前提を固める
3. まずは Level 12+ の通知だけに絞って運用する

構築でつまずいたら BlogRasPi 5にWazuhを入れたら、Dockerが死んだ話——自宅セキュリティ監視の実録RasPi 5（ARM64）にWazuhをDocker Composeで構築しようとしたらIndexerが落ちて失敗。直接インストールに切り替えた実録。3台を監視したらCritical脆弱性が203件出てきた話。→ に進んでください。脆弱性の見方は BlogWazuhを入れたら脆弱性が3,247件検出された話【RasPi 5 自宅ラボ セキュリティ実録 #2】Wazuhの脆弱性ダッシュボードに「3,247件」と表示された。焦ったが、分解してみると数字の正体はシンプルだった。旧カーネル・謎のThunderbird・CVSS 9.8の正体——自宅ラボ実録。→、自動化の方向性は BlogWazuhとClaude Codeを繋いだら、CVE調査と修正提案が自動化できた【自宅ラボ セキュリティ実録 #3】Wazuh REST APIでCVEリストを取得し、Claude Codeに渡したら調査と修正コマンド生成が自動化できた。93件のCriticalを手動で追っていた状態からの脱出実録。→ が役立ちます。

監視の足場ができたら、次は認証情報も自宅に置きたくなるはずです。その時は Blogパスワードも SSH 鍵も、自宅に置いておく——Vaultwarden + Bitwarden SSH Agent で作る個人セキュリティ基盤クラウドパスワードマネージャーへの不安と ~/.ssh/ ファイル管理の煩雑さを、Vaultwarden（RasPi 5 Docker）と Bitwarden SSH Agent の組み合わせで解決した実録。GNOME Keyring の競合解消・毎回確認ダイアログによるプロンプトインジェクション対策・snap バージョン非依存のソケット設定まで解説。→ へどうぞ。

最後にもう一度だけ。無料でできるのは、監視の入口を持つことです。完全防御ではありません。でも、個人運用では、その入口があるだけで事故の見え方がかなり変わります。

• OS・ライブラリのバージョンが異なると手順が変わる場合があります。
• クラウドサービスは設定UIが更新されることがあり、画面が本記事と異なる可能性があります。
• 本番環境への適用前にテスト環境で動作を確認してください。

• 記事の手順を実際に実行して動作を確認しています。
• コマンドの出力例は実際の実行結果を掲載しています。

手順通りに進めても動かない場合は？

エラーメッセージをそのままコピーして検索すると解決策が見つかることが多いです。バージョン違いが原因のケースも多いため、前提条件を再確認してください。

どのOSで動作確認していますか？

記事内に記載の環境で確認しています。他のOSでの差異は適宜読み替えてください。

• META-MARK

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です。エンジニア専門結婚相談所も運営中です。ClaudeCodeで解決できない心の課題も、できる範囲で向き合っています。