OCI Anomaly Detection

解決する課題

OCI Anomaly Detection は次のような課題に応えるサービスでした（以下は提供時点の説明です）。

• 多数のセンサーやメトリクスを人手のしきい値ルールで監視しているが、相互に絡み合う複雑な異常を見逃してしまう
• 設備故障やシステム障害の予兆を早期に捉え、ダウンタイムや不良品を減らしたい
• 単一指標では正常に見えるが、複数指標の組み合わせで初めて分かる異常を検出したい
• 異常検知モデルを自前で開発・運用する専門知識や工数が不足している

OCI Anomaly Detection は、正常時の多変量時系列データから挙動を学習し、過去パターンから外れた振る舞いを API 呼び出しで検出する設計でした。固定しきい値では捉えにくい、指標間の相関を踏まえた異常を判定できる点が特徴でした。

主要概念と用語

• 多変量時系列（Multivariate Time Series）: 複数の信号（センサー値・メトリクス）を時間順に並べたデータ。指標間の相関も学習対象になる
• 教師なし学習: ラベル付けされた異常データを用意せず、正常データのみでモデルを訓練する方式
• トレーニングデータ: モデルの学習に使う、正常な期間を含む時系列データセット。十分な期間と品質が精度を左右する
• モデル（Model）: 学習済みの異常検知器。プロジェクトに紐づき、推論（検知）に再利用する
• プロジェクト（Project）: モデルやデータアセットをまとめる作業単位
• 検知（Detection / Inference）: 新しいデータをモデルに渡し、各時点が異常か、どの信号が寄与したかを返す処理
• 異常スコア / 信頼度: 各検知結果に付く、異常らしさの度合いを示す値
• FAP（False Alarm Probability）: 誤検知の許容度を調整する設定。低くすると見逃しが増え、高くすると誤報が増えるトレードオフがある
• 同期 / 非同期: 少量データはリアルタイム検知、大量データはオブジェクトストレージ連携の非同期ジョブで処理する

仕様・制限・クォータ

• REST API・各言語の SDK・oci CLI から呼び出せるリージョン単位のサービス
• 入力は CSV や JSON などの多変量時系列で、列が各信号、行が各時点に対応する
• トレーニングには正常な期間を十分に含むデータが必要で、信号数や行数・データ品質に学習成立の前提がある
• 1 リクエストで送れるデータ量やレートに上限があり、超える場合は分割または非同期ジョブを用いる
• 学習に使える信号数や時系列長などの具体的な上限値はリージョンや時期で変わり得るため、最新の公式ドキュメントで確認すること

内部の仕組み

OCI Anomaly Detection は、正常時の多変量時系列を学習し、信号間の相関を含む正常な挙動のモデルを構築します。検知時には、入力データが学習した正常パターンからどれだけ外れているかを評価し、時点ごとに異常の有無・スコア・寄与した信号を返します。

学習はラベル不要の教師なし方式で、利用者は正常な期間を含むデータを与えるだけです。少量データはリアルタイムの同期検知でその場で結果を受け取り、大量データは入力をオブジェクトストレージに置き、非同期ジョブで処理して結果を同じくオブジェクトストレージへ出力します。誤検知の許容度は FAP のような設定で調整し、用途に応じて感度を変えられます。

設計パターン / ベストプラクティス

• 正常データで学習する: 異常を含まない、業務状態を代表する期間のデータでモデルを作る
• 信号をまとめて学習する: 相関する指標は同じモデルにまとめ、組み合わせ異常を捉えやすくする
• FAP で感度を調整する: 重要設備は見逃しを避けて感度を上げ、ノイズの多い系では誤報を抑える
• 大量データは非同期ジョブ: バッチ検知はオブジェクトストレージ連携の非同期処理でスループットを稼ぐ
• 定期的に再学習する: 季節性や設備更新で正常パターンが変わったらモデルを作り直す
• 検知結果は二段構え: 高スコアの異常はアラートに、境界付近は人手レビューに回す

運用・監視

• 検知結果（異常の有無・スコア・寄与信号）を後段のOCI Monitoring やアラーム、通知へ連携してインシデント対応につなげる
• API 呼び出しのメトリクスやエラーは Monitoring で可視化し、スロットリングや失敗率を監視する
• 操作の監査証跡はOCI Audit に記録される
• 非同期ジョブはステータスをポーリングして完了・失敗を検知し、失敗時はリトライ設計を用意する
• 誤報・見逃しの傾向を継続的に評価し、データドリフトが見えたら再学習する

コスト

• 課金は主にモデルの学習（トレーニング）と検知（推論）の処理量に応じた従量制が基本
• 学習を高頻度に繰り返すとコストが膨らむため、再学習は正常パターンが変わった時に絞る
• 同一データの重複検知を避け、必要な信号・解像度に絞ってデータ量を抑える
• 具体的な単価は変動するため、料金は公式の価格ページで都度確認する

セキュリティ

• アクセス制御はOCI IAM のポリシーで、コンパートメント単位に最小権限で付与する
• 学習・検知に使うオブジェクトストレージは暗号化し、対象バケットを限定する
• 通信は TLS で保護され、API 認証には署名付きリクエスト（API キーやインスタンスプリンシパル）を用いる
• センサーや業務メトリクスに機微情報が含まれる場合は、保存・出力先の権限と保持期間を明確にする

関連サービス・比較

OCI Anomaly Detection が多変量時系列の汎用異常検知を担うのに対し、OCI Monitoring は固定・統計しきい値ベースでメトリクスを監視します。両者を組み合わせ、しきい値では捉えにくい異常を Anomaly Detection で補完するのが実践的です。

ハンズオン / CLI例

# プロジェクトを作成する例
oci anomaly-detection project create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --display-name "equipment-anomaly"

# オブジェクトストレージ上のデータで非同期の検知ジョブを実行する例
oci anomaly-detection detect-anomaly-job create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --model-id "ocid1.aianomalydetectionmodel.oc1..xxxx" \
  --input-details '{"inputType":"OBJECT_LIST","objectLocations":[{"namespaceName":"mytenancy","bucketName":"timeseries","objectName":"data.csv"}]}' \
  --output-details '{"outputType":"OBJECT_STORAGE","namespaceName":"mytenancy","bucketName":"results","prefix":"out"}'