第5章：既存の仕組みを活用する

この章で分かること

SNMP / Syslog / OTel / CI / SIEM / MCP の役割地図
何をAIに任せないか
オンプレ監視とクラウド監視の置き方
「道具を増やす順序」

たとえ話

道具箱です。金槌（閾値監視）で釘を打ち、顕微鏡（トレース）で細部を見、辞書（ランブック）を引き、相談役（AI）に整理してもらう。
相談役に金槌を置き換えない——これがメッセージです。

1. 技術マップ

名前	ひとこと	AIに任せる？	出典
SNMP polling	機器状態を聞きに行く	判定は監視。AIは影響整理	[S05]
SNMP Trap	状態変化の押し出し	検知は監視	—
Syslog	出来事の伝言メモ	保存は基盤。要約は必要時	[S06]
Prometheus+Alertmanager	数値の見張人と通知整理	ルールは基盤	[S14]
OpenTelemetry/APM	動きを共通形式で取る	相関の材料	[S03][S04]
クラウド監視	マネージドのメトリクス／アラーム	製品差は公式確認	—
CI/CD	開発の自動検査・配布	失敗分析可。本番保証ではない	[S01]
SIEM	セキュリティ事象の集約	検知ルールは専用側	—
MCP	AIと道具の差し込み口	権限設計が本体	[S15][S16][S17]

2. 採用の順序

今ある検知（①）を一覧化する
証拠の保存先（②）を確認する
相関キーが揃うか確認する
その上で読取AI（MCP等）を足す

OpenTelemetry … ベンダーに縛られにくい計装枠 [S03][S04]。本資料の深さはログ／メトリクス／トレース中心。Profiles など一部シグナルは発展途上のため、導入初期は深追いしません。
MCP … LLMアプリがツール／データに触る取り決め [S15][S17]。仕様ページは確認日時点で到達を再確認済み（HTTP 200）。

Zabbix / JP1 / Hinemos なども第1層の選択肢です。唯一解は断定しません。

運用担当者既存監視を捨てる前にAIの入力源として棚卸しする

PGアプリ間でtrace_id/request_idを欠落させない

SEOTel/APM/ログ基盤で相関キーの命名と伝播を標準化する

PM新エージェントと既存改修の予算を分ける

経営層「全部AI」より「既存＋AI」が安全側

ふりかえり

検知に使っている製品を3つ言えるか
AIに渡す前の保存先が明確か