インフラエンジニアの皆さん、昨夜はぐっすり眠れましたか？
もし、「CPU使用率が80%を超えました」というアラートで深夜2時に叩き起こされ、ログを確認したら単なるバッチ処理の一時的なスパイクだった……という経験があるなら、この記事はまさにその課題を解決するためのものです。
あるいは、逆に「アラートは鳴らなかったのに、システムが応答不能になっていた」という、背筋が凍るようなサイレント障害を経験したことがあるかもしれません。
インフラ運用の現場では長年、CloudWatchで静的な「閾値（しきいち）」を設定し、監視が行われてきました。しかし、クラウドネイティブな環境やマイクロサービス化された複雑なシステムにおいて、人間が手動で設定する閾値だけでは、もはや限界が来ています。
そこで注目されているのが、AIや機械学習（ML）を活用した「予兆検知」です。
「機械学習は難しそう」「数式は苦手だし、データサイエンティストになるつもりはない」と身構えてしまう方も多いでしょう。しかし、インフラエンジニアに必要なのは、複雑なアルゴリズムを実装する力ではなく、AWSが提供する便利なAIサービスを使いこなすための「言葉」を知ることです。
この記事では、AWSのドキュメントや設定画面に出てくるAI/ML関連の用語を、インフラ運用の現場の言葉に翻訳して解説します。難しい数式は一切使わず、現場の一般的な事象と照らし合わせながら、段階的に理解できるよう構成しています。
なぜ今、「予兆検知」の用語を知る必要があるのか
まずは、なぜインフラエンジニアが新しい用語を学ぶ必要があるのか、その背景を整理します。
閾値監視と予兆検知の決定的な違い
従来の監視は「ルールベース」です。「CPUが90%を超えたら異常」というルールを人間が決めます。これはシンプルですが、ふたつの大きな弱点があります。
- 「いつもと違う」がわからない: 例えば、普段のCPU使用率が10%のサーバーが、突然50%になったとします。閾値が90%ならアラートは鳴りませんが、これは明らかに異常な兆候（予兆）かもしれません。
- 季節変動に対応できない: 日中はアクセスが多くて負荷が高いのが正常、夜間は低いのが正常。これを静的な閾値で管理しようとすると、設定が非常に複雑になるか、誤検知（オオカミ少年アラート）を受け入れるしかありません。
一方、AIによる予兆検知は、過去のデータから「普段の振る舞い（正常なパターン）」を学習し、そこから逸脱したものを検知します。これにより、閾値設定の限界から解放され、より本質的な異常に気づけるようになります。
インフラ担当者が直面する「サイレント障害」の課題
ディスク容量がいっぱいになるような分かりやすい障害は減りました。現代の障害はもっと複雑です。
- デプロイ後にメモリリークが徐々に進行している
- 特定のAPIだけ応答速度がわずかに遅延している
- データベースのコネクション数が不自然に増減している
これらは静的な閾値では捉えにくいものばかりです。こうした「サイレント障害」がユーザーに影響を与える前に察知するには、AIの力を借りてデータの傾向（トレンド）を分析する必要があります。
用語理解がツール選定の第一歩
AWSには CloudWatch Anomaly Detection や Amazon SageMaker（現在のSageMaker AI）、Amazon DevOps Guru など、AIを活用した運用ツールが多数存在します。これらのツールは日々進化しており、サーバーレスでのモデル運用や生成AIとの統合など、機能は拡張され続けています。
しかし、ドキュメントを開くと「推論」「学習」「特徴量」といった言葉が並んでいて、そこで挫折してしまうケースも珍しくありません。ツールが高機能になればなるほど、その裏側にある仕組みを理解しておく重要性は増しています。
用語の意味がわかれば、「現在の課題に対してどのサービスが適切か」を正しく判断できるようになります。ツールを効果的に使いこなすために、まずは基礎語彙を固めていきましょう。
1. 監視データソースに関する基礎用語
AIモデルを構築するためには、まず「素材」となるデータが必要です。ここでは、普段見慣れている監視データが、ML（機械学習）の文脈でどう呼ばれ、どう扱われるかを解説します。
メトリクス (Metrics) とログ (Logs)
これらは一般的な監視用語ですが、AI視点で見ると少し意味合いが変わります。
- メトリクス: CPU使用率、メモリ残量、レイテンシなどの数値データ。時系列で整理されており、AIが最も扱いやすい「構造化データ」です。CloudWatch Anomaly Detectionは主にこれを扱います。
- ログ: アプリケーションが出力するテキストデータ。「エラーが発生しました」といった文字列です。これは「非構造化データ」であり、そのままではAIが数値を計算できません。
CloudWatch Logs Insightsを使用して特定のエラーパターンをカウントしたり、ログフィールドを抽出して数値化したりする前処理が不可欠です。
インフラ担当者へのポイント:
予兆検知を始めるなら、まずは扱いやすい「メトリクス」から着手するのが定石です。ログのAI分析は、テキストを数値に変換するプロセス（構造化）が必要となるため、難易度が一段上がります。
時系列データ (Time Series Data)
MLの世界では、時間の経過とともに記録された一連のデータ点を「時系列データ」と呼びます。
- タイムスタンプ: データが記録された時刻。
- 値: その時刻における計測値。
予兆検知において重要なのは、データが「等間隔」であることです。例えば「1分ごと」や「5分ごと」に欠けなくデータが存在することが、精度の高いモデルを作るための条件になります。
現場でのイメージ:
CloudWatchメトリクスでデータが途切れている（欠損している）箇所があると、AIは「システムが停止していたのか、データが送られてこなかっただけなのか」の判断に迷います。監視エージェントの設定を見直し、データを途切れさせないことが、AI活用の第一歩です。
ディメンション (Dimensions) と粒度
- ディメンション: メトリクスを一意に識別するための属性（タグのようなもの）。例：InstanceId, AutoScalingGroupName。
- 粒度 (Granularity): データの細かさ。1分、5分、1時間など。
AIモデルは、基本的に「ひとつの時系列データにつき、ひとつのモデル」を作ります。つまり、サーバーが100台あれば、100個のモデルが必要になるのが基本です（まとめて学習する手法もあります）。
なぜこれを知る必要があるか:
「全サーバーまとめて異常検知したい」と考えがちですが、WebサーバーとDBサーバーでは負荷の傾向が全く異なります。ディメンションごとにデータを分け、適切な粒度で分析対象を絞ることが、コストと精度のバランスを取る鍵になります。
2. Amazon CloudWatch Anomaly Detection 関連用語
ここからは、AWSで最も手軽にAI監視を始められる機能、CloudWatch Anomaly Detection（異常検知）に関する用語です。マネジメントコンソールでグラフを見たことがある方も多いでしょう。
アノマリー (Anomaly) / 外れ値
統計的に見て「正常なパターンから逸脱している状態」を指します。単に数値が高い・低いではなく、「普段の動きと違う」ことがポイントです。
- ポイントアノマリー: 突発的なスパイクなど、一点だけの異常。
- 集団アノマリー: 一定期間、普段とは違う動きが続く状態。
インフラ運用では、バッチ処理などで一時的に負荷が上がるのは正常（アノマリーではない）と見なしたい場合があります。AIがこれをどう判断するかが重要なポイントになります。
バンド (Band) / 信頼区間
CloudWatchの画面で、メトリクスの折れ線グラフの周りに表示される「灰色の帯」のことです。
- 定義: AIが過去のデータから予測した「正常であればこの範囲に収まるはず」という幅。
- 仕組み: 帯（バンド）からはみ出したデータが「異常」として検知されます。
現場でのイメージ:
このバンドの幅は調整可能です。バンドを狭くすれば感度が上がり（些細な変化も検知）、広くすれば感度が下がります（大きな変化だけ検知）。従来の閾値設定のように「90%」と決めるのではなく、「標準偏差の何倍まで許容するか」という感覚で調整します。
季節性 (Seasonality) とトレンド
AIがデータを分析する際に見つけ出すパターンのことです。
- 季節性: 一定の周期で繰り返されるパターン。例：「毎日昼の12時にアクセスが増える」「毎週月曜日の朝にバッチが走る」。
- トレンド: 長期的な上昇・下降傾向。例：「ユーザー増に伴い、毎月少しずつメモリ使用量が増えている」。
なぜこれを知る必要があるか:
CloudWatch Anomaly Detectionは、最大2週間分の過去データを学習して、この季節性やトレンドを自動的に把握します。つまり、導入直後よりも、データが蓄積されてからのほうが精度が向上します。「導入したけど精度が悪い」とすぐに判断せず、AIに学習期間を与えることが必要です。
3. Amazon SageMaker によるモデル構築用語
CloudWatchの標準機能だけでは物足りない、独自のデータを分析したいといった場合に登場するのが Amazon SageMaker です。ここでは少し専門的な用語が出てきますが、インフラ構築のメタファーを使って理解していきましょう。なお、SageMakerは機能拡張が著しく、現在は生成AI向けの機能なども統合されていますが、ここでは予兆検知に必要な基本概念に絞って解説します。
Random Cut Forest (RCF) アルゴリズム
Amazon SageMakerで異常検知を行う際によく使われる代表的なアルゴリズムです。
イメージ:
森（Forest）の中にたくさんの木が生えています。異常なデータ（外れ値）は、他の正常なデータとは離れた場所にポツンと存在しています。RCFは、データをランダムに切り分けていき（Cut）、「少ない回数で切り分けられたデータ＝他と離れている＝異常」と判断します。
インフラ担当者へのポイント:
「RCFは異常検知に強い定番アルゴリズム」と覚えておけば十分です。AWSの異常検知系サービス（Kinesis Data Analyticsなど）の裏側でも、このRCFが動いていることが多くあります。
学習 (Training) と推論 (Inference)
機械学習プロセスの根幹となるふたつのフェーズです。
学習 (Training):
- 過去のデータをAIに読み込ませ、正常なパターンを覚えさせるプロセス。
- 例え: 新入社員（AIモデル）に、過去のマニュアルやトラブル履歴を読ませて研修する期間。
- これには計算リソース（GPU/CPU）と時間がかかります。
推論 (Inference):
- 学習済みのモデルを使って、現在のデータが正常か異常かを判断するプロセス。
- 例え: 研修を終えた社員が現場に配属され、リアルタイムで流れてくる事象に対して「これはおかしい」と判断すること。
現場でのイメージ:
SageMakerを使う場合、「学習ジョブ」を実行してモデル（アーティファクト）を作成し、それを「エンドポイント」にデプロイして「推論」を行います。インフラで言えば、Dockerイメージをビルドする工程が「学習」、コンテナとして起動してリクエストを処理させるのが「推論」に近い感覚です。
モデルアーティファクトとエンドポイント
- モデルアーティファクト: 学習の結果できあがったモデルの実体ファイル（S3に保存されます）。
- エンドポイント: そのモデルを稼働させ、外部からの問い合わせ（APIリクエスト）を受け付けるインターフェース。
予兆検知システムを構築するとは、このエンドポイントに対してCloudWatchやLambdaから定期的にデータを送信し、「異常スコア」を返してもらう仕組みを作ることになります。
コスト最適化のポイント:
従来のエンドポイントは常時起動するサーバー（インスタンス）でしたが、現在はリクエストがある時だけ起動する「サーバーレス推論（Serverless Inference）」という選択肢もあります。予兆検知のようにリクエスト頻度が変動する場合、コスト効率を高めるために検討する価値があります。
※最新のインスタンスタイプや料金体系については、必ずAWS公式ドキュメントをご確認ください。
特徴量エンジニアリング (Feature Engineering)
生データをAIが理解しやすい形に加工することです。
例:
「CPU使用率」と「ディスクI/O」という別々の数値を、そのままAIに渡すのではなく、「CPU使用率 ÷ ディスクI/O」のような新しい指標（特徴量）を作って渡すことで、より精度の高い検知ができる場合があります。
料理に例えると:
食材（生データ）をそのまま調理するのではなく、皮をむいたり、適切なサイズに切ったり（特徴量エンジニアリング）して、扱いやすくする工程です。インフラエンジニアのドメイン知識（「この数値とこの数値は関連しているはずだ」という知見）が最も活きる領域です。
4. 運用・アクションに関するビジネス用語
技術的な用語を理解したら、次はそれをビジネスや運用の現場でどう評価するか、という視点の用語です。チーム内でのKPI設定や報告に役立ちます。
偽陽性 (False Positive) と偽陰性 (False Negative)
AIモデルの精度を評価する上で重要な用語です。
- 偽陽性 (False Positive): 「異常なし」なのに「異常あり」と判定してしまうこと。
- いわゆる「誤検知」。運用担当者が疲弊する原因となります。
- 偽陰性 (False Negative): 「異常あり」なのに「異常なし」と判定してしまうこと。
- いわゆる「見逃し」。サイレント障害に繋がる危険な状態です。
トレードオフ:
このふたつはトレードオフの関係にあります。偽陽性を減らそうとして感度を下げると、偽陰性が増えます（見逃しやすくなる）。逆に、絶対に見逃したくないと感度を上げると、偽陽性が増えます（アラートが鳴りすぎる）。
運用のアドバイス:
「誤検知ゼロ」を目指すのは非現実的です。「深夜の緊急対応を要するレベルの誤検知は減らしつつ、日中の軽微な予兆は多めに拾う」といった、時間帯や重要度に応じたバランス調整が求められます。
AIOps (Artificial Intelligence for IT Operations)
IT運用にAIを活用すること全般を指す用語です。
Gartnerなどが提唱しており、単なる監視だけでなく、原因分析や自動復旧までを含みます。近年では、生成AIを用いた対話的なログ分析や、MLOps（機械学習基盤の運用）との統合も進んでいます。
現場でのイメージ:
「CloudWatchのアラートを検知したら（監視）、Amazon SageMaker（またはSageMaker AI）で構築したモデルがメトリクスを詳細に分析して異常の根本原因を特定し（分析）、Lambdaが自動的に再起動やスケーリングを実行する（アクション）」といった一連の流れ全体を指してAIOpsと呼びます。
MTTR (Mean Time To Recovery) の短縮
平均復旧時間。予兆検知を導入する最大のビジネスメリットはここにあります。
障害が起きてから調査を開始するのではなく、予兆の段階で調査を始めることで、結果としてサービス停止時間を短縮できます。
プロアクティブなキャパシティプランニング
「来月サーバーリソースが不足しそう」と予測することです。CloudWatchの機能でも一部可能ですが、AIを使うことで、ビジネスの季節変動（セール時期など）を加味した高度な予測が可能になります。これを「オートスケーリング」と組み合わせることで、無駄なコストを削減できます。
よくある混同：ルールベースとMLベースの違い
最後に、これまで解説した内容の整理として、従来型（ルールベース）とAI型（MLベース）の違いを明確にしておきましょう。ここを混同すると、チーム内でのツールの選定や運用設計の議論にズレが生じてしまいます。
「閾値」と「ベースライン」の違い
| 項目 | 閾値 (Threshold) | ベースライン (Baseline) |
|---|---|---|
| 定義 | 人間が決めた固定のライン | AIが学習した「正常な状態」の範囲 |
| 変動 | 固定（変更には手動設定が必要） | 動的（データの変化に合わせて自動追従） |
| 監視対象 | 「90%以上」といった絶対値 | 「普段と違う動き」という相対値 |
| 得意なこと | 明確な障害の検知（死活監視など） | 未知の障害や予兆の検知 |
AI監視を導入しても、従来の閾値監視が不要になるわけではありません。「ディスク使用率100%」といった物理的な限界は、問答無用で異常であり即座に対応が必要なため、これは閾値で監視すべきです。AIはあくまで「固定の閾値では拾えない隙間」や「季節変動する正常値」をカバーするための補完的な役割だと考えてください。
「自動化」と「自律化」の違い
- 自動化 (Automation): 定められた手順を自動で実行すること（スクリプトによる再起動など）。
- 自律化 (Autonomous): システム自身が状況を判断して行動すること。
予兆検知は「自律化」への第一歩と言えます。しかし、運用現場でいきなり全ての判断をシステムに委ねるのはリスクが伴います。まずは「異常の検知」をAIに任せ、「判断とアクション」は人間が行う、あるいは承認フローを挟んで自動化を実行する、というステップから始めるのが安全で現実的なアプローチです。
理解度チェッククイズ
ここまでの内容を振り返ってみましょう。
Q1. CloudWatch Anomaly Detectionで、グラフの周りに表示される「AIが予測した正常範囲の帯」を何と呼ぶでしょうか？
- 閾値（Threshold）
- バンド（Band）
- トレンド（Trend）
Q2. Amazon SageMaker（SageMaker AI）などのプラットフォームにおいて、学習済みのモデルを使って新しいデータに対する判定や予測を行うプロセスを何と呼ぶでしょうか？
- 学習（Training）
- 推論（Inference）
- 特徴量エンジニアリング（Feature Engineering）
A1. 2. バンド（Band）
これが狭いほど異常検知の感度が高くなり、広いほど感度が低くなります（許容範囲が広がるため）。
A2. 2. 推論（Inference）
「学習」は過去のデータからパターンを学ぶプロセス（研修期間）であり、「推論」はそのパターンを使って実データに基づき判断するプロセス（実務配属）です。
まとめ：次のステップへ
「予兆検知」や「AI監視」といった概念が、少し身近に感じられるようになったのではないでしょうか。
インフラエンジニアにとって、AIは運用を効率化し、システムの安定稼働を支援する強力なツールになり得ます。
今回解説した用語や概念は、AWSに限らず、DatadogやNew Relicなどのモダンな監視ツールを使用する際にも共通する基礎知識です。まずは、現在運用しているCloudWatchのアラーム設定画面を開き、「Anomaly Detection」のオプションを有効にしてみることから始めてみてください。
既存の監視設定に影響を与えることなく、テスト的に有効化してグラフの推移を観察するだけでも、システムの振る舞いについて新たな発見があるはずです。
この記事をきっかけに、リアクティブ（事後対応）な運用から、プロアクティブ（予兆検知）な運用への第一歩を踏み出していただければ幸いです。用語を正しく理解し、ツールを適切に選定することが、より高度で安定したインフラ運用を実現するための最短ルートとなります。
コメント