Soracom

Users

アーキテクチャーセンター
フィードバック
Home アーキテクチャーセンター 運用監視・保守

監視データを通知・分析・自動対応につなげる

監視データを可視化、メール、Slack、Webhook や外部 API 通知、分析、判断、自動対応につなげる設計順序と、SORACOM Harvest Data、SORACOM Lagoon 3、SORACOM Query、SORACOM Flux の役割分担を整理するページ

デバイスや設備からデータを集めたあと、そのデータを「見る」だけでなく、異常検知、通知、判断、対応までつなげるには、データの置き場所、可視化、分析、ワークフローを分けて設計します。監視は、状態を把握するだけで終わりではありません。状態を把握したあとに、誰が、どの情報を見て、どのタイミングで、どの行動を取るかまで決めておく必要があります。

このページでは、監視信号そのものの取り方ではなく、集めた監視データを運用アクションにつなげる設計を整理します。デバイスが動いているかどうかを確認する監視、ping 応答、HTTP 応答、送信データ、通信量の使い分けは、デバイス監視の設計 を参照してください。

このページが役立つケース

  • デバイスや設備からデータを集めたあと、異常検知、通知、判断、自動対応までつなげたい。
  • SORACOM Harvest Data、SORACOM Lagoon 3、SORACOM Query、SORACOM Flux の役割分担を整理したい。
  • メール、Slack、Webhook 対応の通知サービス、外部 API 連携が必要な通知先を切り分けたい。
  • 複数デバイスからの通知をそのまま大量に送らず、担当者が判断しやすい形にまとめたい。
  • 監視データをもとに、しきい値監視だけでなく傾向分析や AI による判断支援も検討したい。
  • 自動対応を導入するときに、通知、判断支援、SORACOM API 実行、外部システム連携のどこまで自動化するか決めたい。

監視後の流れを分けて考える

監視データを運用アクションにつなげるときは、次の 5 つに分けて考えると整理しやすくなります。

段階決めること主な SORACOM サービス
蓄積監視データをどこに保存し、あとからどの期間参照するか。SORACOM Harvest Data
可視化担当者が Dashboard を見て、状態や次の行動を判断できるか。SORACOM Lagoon 3
通知どの条件で、誰に、どの通知先へ、どの粒度で通知するか。SORACOM Lagoon 3、SORACOM Flux
分析通信状況、センサーデータ、設備データをどの単位で集計し、傾向や異常を確認するか。SORACOM Query
自動対応通知だけで止めるか、SORACOM API や Webhook を実行して運用操作まで進めるか。SORACOM Flux

監視データが届いた時点で毎回通知する設計にすると、対象台数が増えたときに通知が多くなり、担当者が重要な通知を見落としやすくなります。通知は「データが届いた事実」ではなく、「対応が必要な状態」になったときに送ることを基本にします。

サービスごとの役割分担

SORACOM の各サービスは、同じ監視データを扱う場合でも役割が異なります。設計時は、どれか 1 つのサービスにすべてを寄せるのではなく、役割を分けて組み合わせます。

サービス主な役割向いている使いかた設計時に確認すること
SORACOM Harvest Data監視データの蓄積デバイスから送られた温度、電流、稼働状態、エラーコードなどを時系列で保存する。データ保持期間、書き込み回数、データ形式、送信頻度、一括書き込みの利用可否。
SORACOM Lagoon 3可視化と AlertDashboard で状態を見える化し、Alert rule、Email、Slack、Webhook の Contact point、Notification policy で通知する。プラン、Dashboard 数、Alert rule 数、Contact point type、データ取得間隔、通知遅延の扱い。
SORACOM Query検索、集計、分析IoT SIM の通信状況や Harvest Data のデータを検索、集計し、傾向や異常を分析する。プラン、クエリ実行回数、単一クエリの実行時間、参照できるデータ期間。
SORACOM Fluxワークフロー、自動化、AI 連携イベントソース、チャネル、アクションを組み合わせ、条件判定、Slack 通知アクション、Email 通知アクション、Email 通知アクション (高機能版)、AI アクション、SORACOM API アクション、Webhook アクションを実行する。プラン、イベント数、クレジット、ログ保持期間、アクション数、通知先別の設定、メッセージ集約アクションの利用可否。
まず役割を決めてからサービスを選びます

「可視化したい」「通知したい」「分析したい」「自動対応したい」という目的を分けると、サービスの選び方が明確になります。たとえば、時系列データを保存して Dashboard と Alert を作るなら SORACOM Harvest Data と SORACOM Lagoon 3、複数デバイスの結果を集約して通知や API 実行につなげるなら SORACOM Flux、通信状況や蓄積データを横断的に集計するなら SORACOM Query を検討します。

設計順序

1. 監視データの単位を決める

最初に、運用で判断したい対象を決めます。デバイス単位、設備単位、拠点単位、製造ライン単位など、通知や分析で使う単位に合わせてデータをそろえます。

監視データには、少なくとも以下を含めると、通知や分析につなげやすくなります。

  • 対象を識別する情報。
  • 測定時刻。
  • 測定値または状態。
  • 正常、注意、異常などの判定に使う値。
  • 調査時に必要になる補助情報。

SORACOM Harvest Data に保存する場合、後から時系列で確認できるように、測定時刻を正しく扱う必要があります。デバイスが一時的に通信できない状況を想定して設計する場合は、測定データをデバイス側に一時保存し、再接続後に送信することも検討します。

2. 蓄積と送信頻度を決める

監視データをすべて即時送信する必要があるとは限りません。異常を早く知る必要があるデータと、日次や時間帯ごとに確認できればよいデータを分けます。

データの扱い向いているケース主な注意点
即時送信異常検知、緊急通知、設備停止につながる状態。通信量、電力消費、通知頻度が増えやすい。
定期送信温度、電流、稼働状態などの継続監視。送信周期が長いほど異常検知も遅くなる。
まとめて送信バッテリー駆動、通信頻度を抑える必要がある設備、通信できない時間帯がある現場。各データの測定時刻、書き込み件数、重複時刻の扱いを確認する。

SORACOM Harvest Data の一括書き込みを利用すると、1 回のデータ送信で複数件のデータを書き込めます。ただし、データ送信回数ではなく、書き込むデータ件数に応じて書き込みリクエストが発生します。利用前に、データ件数、時刻データ、料金を確認してください。

3. Dashboard で判断できる形にする

Dashboard は、担当者が状態を見る場所です。単にグラフを並べるのではなく、次の行動が判断できるようにします。

  • 現在対応が必要な設備を見つけられる。
  • 正常、注意、異常の違いが分かる。
  • 異常値だけでなく、変化傾向も見られる。
  • 拠点、設備、デバイスなどの単位で絞り込める。
  • 通知された内容を Dashboard で確認できる。

SORACOM Lagoon 3 は、SORACOM Harvest Data に保存したデータ、SORACOM Harvest Files に保存したファイル、SORACOM Query で取得できるデータを可視化できます。Alert rule を使う場合は、データ取得間隔、評価範囲、評価間隔を合わせて設計します。

Alert は時間設計を先に確認します

SORACOM Lagoon 3 の Alert は、データ取得間隔、評価範囲、評価間隔の組み合わせによって、意図したとおりに評価できない場合があります。特に No data を監視する場合や、評価間隔を短くする場合は、SORACOM Lagoon 3 のプランとライセンスパック で Harvest Data からのデータ取得間隔を確認し、評価範囲と合わせて設計してください。

4. 通知の粒度を決める

通知は、担当者が行動するための入口です。多数のデバイスや設備を扱う場合は、通知の件数を減らすことだけでなく、通知を読んだ担当者が何をすればよいか分かることを優先します。

通知設計向いているケース注意点
個別通知1 台ごとの異常にすぐ対応する必要がある。対象台数が増えると通知が多くなる。
条件別通知温度異常、電源異常、通信異常など、担当部署を分ける必要がある。Alert rule、Label、通知先の設計が必要。
集約通知複数デバイスや複数カメラの結果をまとめて確認する必要がある。集約する範囲、待ち時間、失敗時の扱いを決める。
定期報告日次、週次、シフト交代時にまとめて確認する必要がある。即時対応が必要な異常通知とは分ける。

SORACOM Flux のメッセージ集約アクションを利用すると、分岐した処理の結果をまとめて後続の通知アクションへ渡せます。複数カメラや複数デバイスの処理結果を 1 通の通知にまとめる場合に利用できます。

Flux の通知はイベント数と上限を先に決めます

SORACOM Flux で通知、メッセージ集約、Webhook 連携を行う場合は、通知件数だけでなく、Flux アプリのイベント数、クレジット使用量、上限到達時の動作を確認してください。バンドル分を超えて処理を継続するために上限を緩和するか、上限内に収まる通知頻度にするかを運用前に決めておきます。詳しくは、イベント数、クレジット使用量の上限を設定する を参照してください。

通知先と実現方法を選ぶ

通知先は、担当者がどこで確認し、どの行動につなげるかに合わせて選びます。通知先ごとに、SORACOM Lagoon 3 の Contact point で扱うか、SORACOM Flux の通知アクションや Webhook アクションで扱うかを分けます。

通知先向いているケース主な実現方法設計時に確認すること
メール低頻度の重要通知、担当者や部門への連絡、日次や週次の定期報告。SORACOM Lagoon 3 の Email Contact point、SORACOM Flux の Email 通知アクション、画像を添付する場合は Email 通知アクション (高機能版)。宛先管理、送信上限、到達保証ではないこと、通知遅延、添付画像のサイズ。
Slackチームで同じ通知を見て、その場で会話しながら対応する場合。SORACOM Lagoon 3 の Slack Contact point、SORACOM Flux の Slack 通知アクション。通知先チャンネル、メンション、Webhook URL または Bot User OAuth Token、Slack App のチャンネル追加。
Webhook 対応の通知サービスGoogle Chat、Microsoft Teams など、Webhook 連携機能を利用できるサービスへ通知する場合。SORACOM Lagoon 3 の Webhook Contact point、SORACOM Flux の Webhook アクション、必要に応じた中継サービス。送信先 URL、認証、HTTP ボディ形式、タイムアウト、受信側の制限、連携先サービスのサポート範囲。
外部 API 連携が必要な通知先LINE など、担当者が普段使うサービスに通知する必要があるが、SORACOM の標準通知先や単純な Webhook だけでは完結しない場合。連携先が提供する API を SORACOM Flux の Webhook アクションまたは中継サービスから呼び出す。連携先アカウント、認証、送信先、利用条件、メッセージ数制限、個人情報の扱い。
通知は重要度と対応先を分けます

すべての異常を同じ通知先に送ると、担当者が対応の優先度を判断しにくくなります。警告、重大異常、復旧、定期報告を分け、通知先と通知文を設計してください。

5. 分析で見る範囲を決める

SORACOM Query は、SORACOM Air for セルラーの IoT SIM の通信に関する情報や、SORACOM Harvest Data に保存されたデータを検索、集計できます。しきい値を超えたかどうかだけではなく、傾向や分布、拠点ごとの差、デバイスごとのばらつきを確認する場合に利用します。

分析で確認する観点の例は以下のとおりです。

  • デバイスごとの通信量、セッション履歴、ステータスの推移。
  • 設備ごとの測定値の変化傾向。
  • 異常が発生しやすい時間帯や拠点。
  • 同じ条件で動作している設備同士の差。
  • 通知が多い設備や、復旧まで時間がかかる設備。

分析結果を定期的に確認するだけでなく、SORACOM Lagoon 3 と組み合わせて Dashboard や Alert に使うこともできます。利用時は、クエリ実行回数、単一クエリの実行時間、参照できるデータ期間、元データ側の保持期間を確認します。

6. AI に任せる範囲を決める

AI は、監視データの判断材料を整理したり、画像やテキストから状態を読み取ったり、判断候補を提示したりする用途で検討できます。一方で、いきなり人の判断をすべて置き換える設計にすると、誤判定や運用上の説明責任が問題になります。

AI を使う場合は、次の順で設計します。

  1. 現在の判断基準を明文化する。
  2. 期待する出力を決める。
  3. 人の判断と AI の出力を並行して評価する。
  4. 期待と異なる出力を記録し、プロンプトや判定条件を改善する。
  5. 通知、判断支援、自動実行のどこまで AI の結果を使うか決める。

SORACOM Flux では、AI アクションを使って入力データを分析し、その結果を通知や後続のアクションにつなげられます。AI の結果を運用操作に使う場合は、最初から完全自動化するのではなく、人が確認する段階を設けて評価してください。

7. 自動対応の範囲を決める

自動対応は、通知だけで終わらせる段階から、SORACOM API や外部システムを実行する段階まであります。どこまで自動化するかは、誤実行した場合の影響、復旧手順、権限、監査方法を含めて決めます。

自動対応の段階内容主な確認事項
通知条件を満たしたら Slack、メール、Webhook などに通知する。通知先、通知文、重要度、再通知、停止時間。
判断支援監視データや画像を AI で要約し、担当者が確認する。出力の評価基準、誤判定時の扱い、改善手順。
外部連携Webhook で外部サービスへ連携する。認証、再試行、失敗時の通知、外部サービス側の制限。
SORACOM API 実行SORACOM API アクションで SORACOM のリソースを操作する。実行する API、SORACOM Access Management (SAM) ユーザーの権限、課金への影響、レスポンスサイズ。
運用操作条件に応じて制御や状態変更を実行する。誤実行時の影響、取り消し方法、人による承認の必要性。
自動対応は実行権限と課金への影響を確認します

SORACOM Flux の SORACOM API アクションは、SAM ユーザーの権限で SORACOM API を実行します。API の実行結果として課金が発生する場合があります。実行権限、対象 API、レスポンスサイズ、実行履歴、失敗時の通知を確認してから利用してください。

組み合わせ例

小さく始めて可視化と Alert を作る

まず監視データを保存して、担当者が Dashboard で確認し、しきい値を超えたら通知する構成です。

目的組み合わせ
監視データを保存するSORACOM Harvest Data
状態を見える化するSORACOM Lagoon 3
しきい値で通知するSORACOM Lagoon 3 の Alert rule、Contact point、Notification policy

この構成は、データの見える化と初期の通知設計を素早く確認したい場合に向いています。長期保存、Alert rule 数、Dashboard 数、データ取得間隔、料金はプランごとに確認します。

複数デバイスの結果を集約して通知する

複数のデバイスやカメラから取得した結果を、それぞれ個別に通知せず、まとめて通知する構成です。

目的組み合わせ
定期実行するSORACOM Flux のインターバルタイマーイベントソースまたはスケジュールタイマーイベントソース
複数対象に処理を分岐するSORACOM Flux の Republish アクションなど
結果をまとめるSORACOM Flux のメッセージ集約アクション
通知するSORACOM Flux の Slack 通知アクション、Email 通知アクション、Email 通知アクション (高機能版)、Webhook アクション

この構成は、点検対象が複数あり、担当者が 1 通の通知で状況を把握したい場合に向いています。画像付きの点検結果をメールでまとめて送りたい場合は Email 通知アクション (高機能版)、チームで対応する場合は Slack 通知アクション、Webhook を受け取れる通知サービスや外部システムへ連携する場合は Webhook アクションを検討します。メッセージ集約アクションを利用できるプラン、集約対象、通知先、処理失敗時の扱いを確認します。

傾向分析と Dashboard を組み合わせる

蓄積した監視データや通信状況を、SORACOM Query で集計し、SORACOM Lagoon 3 で可視化する構成です。

目的組み合わせ
データを保存するSORACOM Harvest Data
通信状況やセンサーデータを集計するSORACOM Query
集計結果を可視化するSORACOM Lagoon 3
必要に応じて通知するSORACOM Lagoon 3 の Alert

この構成は、単一デバイスの異常検知ではなく、多数デバイスの傾向や拠点ごとの差を見たい場合に向いています。SORACOM Query のクエリ実行回数、データ参照期間、SORACOM Lagoon 3 から Query を実行した場合の API 実行回数を確認します。

判断支援から自動対応へ段階的に進める

最初は通知と判断支援に留め、運用で妥当性を確認してから自動実行へ進める構成です。

段階内容
1監視データを保存し、Dashboard と通知を作る。
2SORACOM Query で傾向や異常の発生条件を確認する。
3SORACOM Flux の AI アクションで判断材料を整理する。
4人が AI の出力と実際の判断を並行して評価する。
5条件が明確な操作だけ、SORACOM API アクションや Webhook アクションで自動化する。

自動対応を始める前に、実行結果を記録し、失敗時に通知されること、誤実行時に戻せること、担当者が後から確認できることを確認してください。

運用前に確認すること

監視データを通知、分析、自動対応につなげる前に、以下を確認してください。

  • SORACOM Harvest Data のデータ保持期間、データ保持期間延長オプション、書き込み回数、データエクスポート料金。
  • SORACOM Lagoon 3 のプラン、Dashboard 数、Alert rule 数、データ取得間隔、通知までの遅延、Public dashboard や自動更新を利用する場合のデータエクスポート料金。
  • SORACOM Query のプラン、クエリ実行回数、単一クエリの実行時間、クエリで指定できる最大期間、元データ側の保持期間。
  • SORACOM Flux のプラン、作成できる Flux アプリ数、イベント数、クレジット、ログ保持期間、通知数、メッセージ集約アクションの利用可否。
  • メール通知を使う場合の宛先管理、送信上限、到達保証ではないこと、迷惑メール振り分け、画像添付サイズ。
  • Slack や Webhook 対応の通知サービスを使う場合の Webhook URL、Bot User OAuth Token、認証情報、チャンネル権限、受信側の制限。
  • 外部 API 連携が必要な通知先を使う場合に、連携先が提供する API、認証方式、利用条件を確認すること。
  • SORACOM API アクションを使う場合の SAM ユーザー権限、実行対象 API、実行結果として発生する料金、レスポンスサイズ。
  • AI を使う場合の評価基準、プロンプト改善方法、人による確認範囲、誤判定時の扱い。
  • 外部通知や Webhook を使う場合の認証、再試行、失敗時の通知、監査ログ。
料金、制限、保存期間は実装前に最新情報を確認してください

料金、プラン、制限事項、保存期間は変更される場合があります。実装前に、利用するカバレッジタイプ、プラン、対象サービスの最新ドキュメントと料金ページを確認してください。

元記事・元資料

このページは、以下の記事・資料をもとにしています。
正確な内容や最新の情報を確認するときは、元の記事・資料もあわせて参照してください。

© 2015-2026 SORACOM
最終更新日: 2026-06-01
会社概要 プレスルーム お問い合わせ プライバシー 商標 特定商取引法 契約約款
Facebook Twitter Speaker Deck YouTube Blog