会社情報
採用情報
お問い合わせ
Article

無料で使えるIT管理ツールの活用ガイド2025

高田晃太郎
無料で使えるIT管理ツールの活用ガイド2025

2025年に向けて、IT運用費に占めるサブスクリプションの比率は高止まりが続き、エンドポイント管理や監視のライセンス費が端末あたり月額で積み上がりやすい状況が一般的です。[1] 実務の感覚に照らしても、SaaSのライセンス最適化だけで年間に一定の削減余地が残るケースは珍しくありません。本稿では、無料で使えるIT管理ツールを適切に組み合わせることで、中規模（例：3,000台クラス）でも安定運用に必要な可観測性、資産把握、パッチ、コンプライアンスの主要要件をカバーする現実解を、CTO視点（著者：高田晃太郎）で提示します。

課題は単純な置き換えではなく、全体アーキテクチャの設計と運用自動化の成熟度です。エージェントの重複を避け、データプレーンを一元化し、認証・権限を集約するだけで、安定性とセキュリティを落とさずにライセンス費を圧縮できます。この記事では実装のヒントとコード例を交え、現場で短期間に検証・導入できる筋の良い進め方を示します。記載する数値は一般的なレンジや公開情報に基づく試算であり、実運用では環境に応じた見積もりと検証を行ってください。

全体設計の骨子とROI：無料で作る運用基盤

無料ツール導入の成否は、機能比較ではなくデータフロー設計で決まります。エンドポイント（PCやサーバなどの端末）に常駐するエージェントの重複はCPUとネットワークを消耗させ、現場の反発につながります。osquery系エージェント[2]とログ送信の薄いデーモンを中心に統一すると、軽量なクエリ設定でCPU使用率を低く、メモリも数十MB程度に抑えやすい構成が一般的です[2][3]。一方で複数の常駐エージェントを重ねると、合算のメモリやI/Oが増え、モバイル端末の体感に影響が出やすくなります。

費用対効果は、まず試算可能な前提に分解します。例えば従業員3,000名の環境で、商用のRMM（リモート監視管理）/EDR（エンドポイント検知・対応）/MDM（モバイル端末管理）のライセンスが平均800円/端末/月と仮定すると、年間コストは約2,880万円に達します。無料ツールに移行してもインフラ費用と運用人件費は残りますが、ログ・メトリクスの保管をオブジェクトストレージへ寄せ、保持期間を設計すれば、クラウド費用はデータ量に応じて数十万円/月規模に収まるケースもあります[6]。移行と自動化の初期投資を加味しても、要件が合致すれば1年前後で損益分岐に到達しうるシナリオは十分に現実的です（個別の要件・データ量により大きく変動します）。

アーキテクチャは単純であるほど強い設計になります。資産・構成はosquery系とインベントリDBに集約し、監視メトリクスはPrometheus[4]、ログ・セキュリティはWazuhやLokiに流し、CI/CDやGitOpsで構成を宣言的に管理します。認証はIdP（アイデンティティプロバイダ）に寄せ、監査トレイルは一元保存。これにより、可視化、検知、是正のPDCAをエンドツーエンドで回せます。

資産管理と監視：osquery、Prometheus、可視化の現実解

資産と構成の単一情報源を確立するには、クライアント側の標準化が近道です。osqueryはエンドポイントをSQLで観測でき、Windows、macOS、Linuxをまたいでソフトウェア、起動項目、パッチレベル、ディスク暗号化の状態まで問合せ可能です[2]。集中管理はFleet OSSや商用SaaSが選択肢ですが、まずは結果ログを中央に集約するシンプル構成から始めると導入が滑らかです。

osqueryの即効活用：インベントリと脆弱性の初期把握

ローカルでのクエリは対話的に進められます。例えばWindows端末の暗号化とパッチの整合を確認する場合、セキュアブート、BitLocker、更新KBの有無をクロスチェックします。以下はPythonでosqueryiを呼び出し、結果をJSONで収集する最小構成の実装です。エラーハンドリングとタイムアウトを含み、CIからも回せる形にしています。

import json
import subprocess
import sys
from typing import List, Dict

QUERY = """
select csd AS windows_release,
       secure_boot,
       device_encryption_status
from system_info
join bitlocker_info;"""

def run_osquery(query: str, timeout: int = 15) -> List[Dict]:
    try:
        proc = subprocess.run(
            ["osqueryi", "--json", query],
            capture_output=True,
            text=True,
            timeout=timeout,
            check=True,
        )
        return json.loads(proc.stdout)
    except subprocess.TimeoutExpired:
        print("osquery timed out", file=sys.stderr)
        return []
    except subprocess.CalledProcessError as e:
        print(f"osquery error: {e.stderr}", file=sys.stderr)
        return []

if __name__ == "__main__":
    rows = run_osquery(QUERY)
    compliant = [r for r in rows if r.get("secure_boot") == 1 and r.get("device_encryption_status") == 1]
    print(json.dumps({"total": len(rows), "compliant": len(compliant)}, ensure_ascii=False))

エージェントのリソース消費は、スケジュール頻度とクエリ内容で大きく変動します。軽量なクエリを10分間隔で回す程度であれば、CPUは低負荷、メモリは数十MB程度に収まる傾向があります。重いテーブル（process_open_socketsなど）はピークを作るため、夜間に寄せる運用が効果的です[2][3]。

メトリクス監視：Prometheusの無償スタックで捉えるSLO

メトリクスはPrometheusで集中させ、ExporterでOSとミドルウェアをカバーします。単一ノードでも一定規模のタイムシリーズを安定して扱えることが知られており、保持期間やスクレイプ間隔は要件に応じて調整可能です[5]。可用性を重視する場合はリモートストレージ連携やフェデレーションで段階的に拡張します[4]。SLO（Service Level Objective：サービス目標値）はPrometheusのHTTP APIでダッシュボード外からも取得でき、レポーティングや自動エスカレーションに応用できます。

import requests
import sys
from datetime import datetime, timedelta

PROM = "http://prometheus.example.local:9090"
QUERY = "sum(rate(http_requests_total{job=\"frontend\",code=~\"2..\"}[5m])) / sum(rate(http_requests_total{job=\"frontend\"}[5m]))"

def query_prometheus(expr: str) -> float:
    try:
        r = requests.get(f"{PROM}/api/v1/query", params={"query": expr}, timeout=5)
        r.raise_for_status()
        data = r.json()["data"]["result"]
        return float(data[0]["value"][1]) if data else 0.0
    except Exception as e:
        print(f"prom query failed: {e}", file=sys.stderr)
        return 0.0

if __name__ == "__main__":
    slo = query_prometheus(QUERY)
    print(f"current-5m-success-ratio={slo:.5f}")

可視化はGrafanaが第一候補ですが、導入初期はダッシュボードを増やしすぎない方が現場は回ります。SLOとアラートに直結する3枚程度をチームで合意し、運用レビューの場で改善する方が定着します。関連する思想と導入手順はSREの可観測性入門2025で詳しく解説しています。

パッチ配布・構成管理・MDM相当を無償で組む

Windows、macOS、Linuxを跨ぐ統制は、完全な商用MDMに比べれば体験は劣りますが、セキュリティベースラインとパッチ適用、禁止ソフト検知、証明書配布の多くは無料ツールでカバーできます。構成の源泉はGitに置き、実行はAnsible AWX（OSS版）やOS標準の更新機能を使い、必要に応じてスクリプトで補います[9]。

Windowsのパッチ制御：PowerShellで月例を確実に回す

ドメイン配下ならWSUSで帯域と承認を握れますが、クラウド主体でもPowerShellとスケジューラで安定運用が可能です。PSWindowsUpdateモジュールの利用は定番で、タグやメンテ時間帯をポリシー化すれば、商用RMMに近い体験を再現できます。

#requires -version 5.1
Import-Module PSWindowsUpdate -ErrorAction Stop
try {
  Get-WindowsUpdate -MicrosoftUpdate -AcceptAll -IgnoreReboot | Out-File -FilePath C:\Logs\wu-scan.txt -Encoding utf8
  Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -AutoReboot -IgnoreReboot -Verbose | Tee-Object -FilePath C:\Logs\wu-install.txt
} catch {
  Write-Error "Windows Update failed: $($_.Exception.Message)"
  exit 1
}

安定性を高めるため、更新前後でosqueryのwindows_updatesテーブルを照合し、KB単位の欠落をレポーティングします。夜間帯に分散実行し、再試行ポリシーを設けると失敗率の低減に寄与します。

Linux/macOSの配布：Ansible AWXとパッケージ管理の素直な活用

Linuxではunattended-upgradesとAnsibleの組み合わせが堅実です。AWXのREST APIを叩いてジョブを非同期起動し、結果をSlackやTeamsへ通知すると、RMMなしでも運用体験が向上します[9]。以下はPythonからAWXにジョブテンプレートを投げる例です。

import requests
import sys

AWX = "https://awx.example.local/api/v2"
TOKEN = "<your-awx-token>"
JOB_TEMPLATE_ID = 42

headers = {"Authorization": f"Bearer {TOKEN}"}

def launch_job_template(jt_id: int) -> int:
    try:
        r = requests.post(f"{AWX}/job_templates/{jt_id}/launch/", headers=headers, timeout=10)
        r.raise_for_status()
        return r.json()["job"]
    except Exception as e:
        print(f"awx launch failed: {e}", file=sys.stderr)
        return -1

if __name__ == "__main__":
    job_id = launch_job_template(JOB_TEMPLATE_ID)
    print(f"launched job={job_id}")

macOSはMunkiと申請フローを組み合わせると現実的です。Jamf等に比べるとプロファイル配布や即時性は制限されますが、必須アプリとOSアップデートの準強制は十分に実現できます。社内ワークフローやゼロトラスト端末要件の考え方はゼロトラスト端末標準ガイドに整理しています。

セキュリティ監視とログ：Wazuh中心の軽量XDR構成

無料でログと検知を統合するなら、Wazuhは実績が豊富です。エージェントはWindows、Linux、macOSをカバーし[7][8]、ファイル改ざん、脆弱性、マルウェア系の軽量検知を単体でこなします。まずは単一ノードで小規模から始め、必要に応じてマルチノードへ拡張する段階的アプローチが現実的です。

Wazuh APIで高優先度アラートを収集し是正を自動化

検知結果を拾って是正を発火させるには、APIで高優先度だけを抽出し、影響範囲を限定したプレイブックを呼び出すのが安全です。以下はrequestsを用いた最小実装で、トークンの取得とフィルタを含みます。

import requests
import sys
from typing import List, Dict

BASE = "https://wazuh.example.local"
USER = "apiuser"
PASS = "apipass"

def get_token() -> str:
    r = requests.get(f"{BASE}/security/user/authenticate", auth=(USER, PASS), timeout=5)
    r.raise_for_status()
    return r.json().get("data", {}).get("token", "")

def fetch_alerts(token: str) -> List[Dict]:
    headers = {"Authorization": f"Bearer {token}"}
    params = {"q": "rule.level >= 10", "limit": 50}
    r = requests.get(f"{BASE}/alerts", headers=headers, params=params, timeout=10)
    r.raise_for_status()
    return r.json().get("data", {}).get("items", [])

if __name__ == "__main__":
    try:
        token = get_token()
        alerts = fetch_alerts(token)
        print(f"high alerts={len(alerts)}")
    except Exception as e:
        print(f"wazuh api failed: {e}", file=sys.stderr)
        sys.exit(1)

ログの長期保管はLokiやOpenSearchとS3互換ストレージを組み合わせるとコストが読みやすくなります[6]。例えば保持90日、平均1GB/端末/月の取り込みと仮定すると、3,000台で月あたり約3TB。圧縮やインデックス戦略、アーカイブ運用を工夫することで、保管コストの最適化余地が生まれます。

osquery結果のログ処理：GoでJSONを安全に取り回す

エッジで収集したosquery JSONは、フォーマットやフィールドの揺らぎが少ないため、Goでも扱いやすい形式です[2]。以下はファイルから読み込んで整形し、必要な列だけ抽出する例です。panicを避け、読み込みエラーを確実に返します。

package main

import (
    "encoding/json"
    "fmt"
    "io/ioutil"
    "os"
)

type Row map[string]interface{}

type OsqueryResult struct {
    Rows []Row `json:"rows"`
}

func main() {
    if len(os.Args) < 2 {
        fmt.Fprintln(os.Stderr, "usage: filter <file.json>")
        os.Exit(1)
    }
    b, err := ioutil.ReadFile(os.Args[1])
    if err != nil {
        fmt.Fprintln(os.Stderr, "read error:", err)
        os.Exit(1)
    }
    var res OsqueryResult
    if err := json.Unmarshal(b, &res); err != nil {
        fmt.Fprintln(os.Stderr, "json error:", err)
        os.Exit(1)
    }
    for _, r := range res.Rows {
        fmt.Printf("host=%v version=%v\n", r["hostname"], r["os_version"])
    }
}

こうした軽量のユーティリティをCI/CDで配布し、エンドポイントで部分的に前処理してから集約するだけでも、中央のログ基盤の負荷は下がります。運用詳細はOSSで作るログ基盤の設計指針にまとめています。

現場で効く運用パターン：導入順序、性能、チーム編成

導入は資産の可視化から始め、次に変更管理とパッチ、最後にセキュリティ検知を強化すると摩擦が少ない順序になります。最初の四半期で、osqueryとPrometheusの最小構成、WindowsのPowerShell更新、Linuxのunattended-upgradesを整え、次の期でWazuhを重ねる流れは、2025年の標準的なIT運用にも無理のない計画です。

性能とスケーラビリティは、単一ノード構成の限界を早めに把握するのが安全です。Prometheusは単一ノードでも十万件規模のタイムシリーズを扱えた検証例が公開されていますが[5]、保持期間やクエリ頻度で負荷は大きく変わります。WazuhやLokiも同様に、単一ノードから開始してフェデレーションや分散構成、オブジェクトストレージへのオフロードに段階的に移行する設計が無難です[4][6]。

チーム編成は、SRE/Platformの小さなタスクフォースで先行し、ヘルプデスクやセキュリティ運用チームと週次で接続する形が回りました。役割を固定化するのではなく、プレイブックとダッシュボードの所有権を明示し、保守容易性を高めます。商用ツールを混在させる判断は否定されるべきではなく、たとえばリモートサポートやフル機能MDMなど、ユーザー体験に直結する箇所はスポットで有償を組み合わせると、現場の満足度を維持しやすくなります。

補助的な自動化：申請駆動のソフト配布と是正

申請ベースのソフト配布は、macOSではMunkiのmanifest、Windowsではwinget sourceとPowerShellの組み合わせが運用しやすい構成です。以下はwingetとイベントログ記録を含む最小のインストーラです。

#requires -version 5.1
Import-Module Microsoft.PowerShell.Management
try {
  $pkg = "Mozilla.Firefox"
  Start-Process -FilePath "winget" -ArgumentList "install --id $pkg --accept-package-agreements --silent" -Wait -NoNewWindow
  Write-EventLog -LogName Application -Source "IT-Deploy" -EventId 1001 -EntryType Information -Message "Installed $pkg"
} catch {
  Write-EventLog -LogName Application -Source "IT-Deploy" -EventId 1901 -EntryType Error -Message $_.Exception.Message
  exit 1
}

最後に、アラート疲れを避けるため、検知と是正は常にセットで設計します。PrometheusのSLO逸脱[4]やWazuhの高優先度検知[7]から、AWXジョブやPowerShellリメディエーションを呼び出すことで、ノイズの多い通知から脱却できます。以下はPythonで二つを橋渡しする薄い関数の例です。

import requests
import sys

PROM = "http://prometheus.example.local:9090"
AWX = "https://awx.example.local/api/v2"
AWX_TOKEN = "<token>"
REMEDIATION_JT = 7

def need_remediation() -> bool:
    try:
        q = "probe_success{job=\"blackbox\",target=\"vpn-gateway\"}"
        r = requests.get(f"{PROM}/api/v1/query", params={"query": q}, timeout=5)
        r.raise_for_status()
        v = float(r.json()["data"]["result"][0]["value"][1])
        return v < 1.0
    except Exception as e:
        print(f"prom check failed: {e}", file=sys.stderr)
        return False

def remediate():
    try:
        r = requests.post(f"{AWX}/job_templates/{REMEDIATION_JT}/launch/", headers={"Authorization": f"Bearer {AWX_TOKEN}"}, timeout=5)
        r.raise_for_status()
        print("remediation launched")
    except Exception as e:
        print(f"awx launch failed: {e}", file=sys.stderr)

if __name__ == "__main__":
    if need_remediation():
        remediate()

このような「検知→是正→監査」の小さな連鎖を積み上げると、無料ツールでも実運用の密度は十分に高まります。社内統制や監査対応を見据え、すべての自動化に実行者、対象、結果の三点セットのログを残す方針を貫くと、後戻りのコストを減らせます。合わせて、SaaS統制のベースラインはSaaSガバナンス実践ガイド2025を参照ください。

まとめ：無料スタックでも、運用はここまで出来る

予算に縛られて品質を落とす必要はありません。osqueryで資産と構成の単一情報源を作り、PrometheusでSLOを継続測定し、PowerShellとAnsibleでパッチを自動化し、Wazuhで検知と監査を一元化すれば、3,000台規模まで視野に入る現実解になります。導入初期の数カ月で可視化とパッチの土台を整え、半期程度で通知とエスカレーションの質を高めつつ、コスト構造の改善を見込めます。

鍵は、機能の多さではなく、少数のコンポーネントに絞ってデータフローを整えることです。 あなたの組織で最初に止めたいコストは何か、いま現場が一番困っている運用はどれか。二つの問いに答えられたら、この記事のコードをそのまま試験環境に流し、ダッシュボードを三枚に絞ってSLOを測り始めてください。最初の一週間で基準線が引ければ、次の四半期の投資判断は格段にクリアになります。

参考文献

  1. IDC Japan 国内システム／サービス管理ソフトウェア市場の2019年の実績と2020年〜2024年の予測（2020年9月25日）. https://akase.xsrv.jp/korabo/author/-317/page/157/#:~:text=IDC%20Japan%E3%81%AF2020%E5%B9%B49%E6%9C%8825%E6%97%A5%E3%80%81%E5%9B%BD%E5%86%85%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%EF%BC%8F%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E7%AE%A1%E7%90%86%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B8%82%E5%A0%B4%E3%81%AE2019%E5%B9%B4%E3%81%AE%E5%AE%9F%E7%B8%BE%E3%81%A82020%E5%B9%B4%EF%BD%9E2024%E5%B9%B4%E3%81%AE%E4%BA%88%E6%B8%AC%E3%82%92%E7%99%BA%E8%A1%A8%E3%81%97%E3%81%9F%E3%80%822020%E5%B9%B4%E3%81%AE%E5%9B%BD%E5%86%85%20%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%EF%BC%8F%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E7%AE%A1%E7%90%86%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B8%82%E5%A0%B4%E3%81%AF%E3%80%81%E5%89%8D%E5%B9%B4%E6%AF%940
  2. osquery documentation: Welcome to osquery. https://osquery.readthedocs.io/
  3. Stack Overflow: High CPU usage with osquery on Linux even in idle state. https://stackoverflow.com/questions/78184432/high-cpu-usage-with-osquery-on-linux-even-in-idle-state
  4. Prometheus documentation: Federation. https://prometheus.io/docs/prometheus/latest/federation/
  5. Percona Blog: Prometheus 2 time series storage performance analyses. https://www.percona.com/blog/prometheus-2-times-series-storage-performance-analyses/
  6. Grafana Loki documentation: Configure storage. https://grafana.com/docs/loki/latest/configure/storage/
  7. Wazuh documentation: Wazuh agent for Windows — supported platforms and installation. https://documentation.wazuh.com/current/installation-guide/wazuh-agent/wazuh-agent-package-windows.html
  8. Wazuh documentation: Wazuh agent for macOS — supported platforms and installation. https://documentation.wazuh.com/current/installation-guide/wazuh-agent/wazuh-agent-package-macos.html
  9. Opensource.com: Ansible announces AWX open source project. https://opensource.com/article/17/9/ansible-announces-awx-open-source-project