アラームは、選択したタグを周期的に判定して状態の変化をイベントとして記録し、設定したチャンネルへ通知する機能です。設定は 設定 → アラーム設定 にあります。

ヘッダーのアラーム表示をクリックすると、アラームのオン／オフを切り替えられます。クリックした時点でこの値だけが即座に保存されるため、アプリを開き直しても維持されます。設定タブで保存していない編集内容は一緒には保存されません。アラームがオンのときは、表示に監視方式のバッジ（서버 상시 サーバー常時 / 앱 アプリ / 앱 · 보기 전용 アプリ・閲覧専用）が付きます。オフにすると、カードの等級は引き続き表示されますが、イベントの記録と通知は止まります（サーバー監視タイマーも解除されます。帯域抽出タイマーは、帯域抽出を別途オフにしないと解除されません）。

どのような計算で等級とイベントが決まるかは 異常判定の仕組み で扱います。このドキュメントでは設定と運用を扱います。

監視方式

まず、判定を誰が行うかを選びます。

アプリ監視

アプリが開いている間、判定周期ごとに選択したタグを判定します。特別な準備なしですぐに動作しますが、ウィンドウを閉じると、その間の判定は行われません。

常時監視が不要な場合や、設定を試している段階であれば、こちらが手軽です。

サーバー常時監視

保存すると、現在の判定設定が Neo タイマーとして登録され、アプリを閉じても判定が続きます。このモードでは、アプリ画面は結果を表示するだけで、判定はサーバーが担当します。

判定ルールは両方式で同じなので、モードを切り替えても、同じデータからは同じ結果が得られます。

知っておくべき点：

• 設定を変更したら、保存し直すまで反映されません。 タイマーは保存時点の設定で動作します。
• ROLLUP があるテーブルのみ判定します。 ロールアップがないテーブルのタグはサーバー監視から除外されます。サーバー監視を選ぶと、除外されるテーブルがこの画面に警告として表示されます。そのようなタグはアプリ監視で確認してください。
• サーバーモードをオフにするとタイマーは削除されます。 パッケージを削除してもタイマーは自動では消えないため、削除する前にアカウントごとにアプリのアラームをオフにします。すでに削除した場合は Neo のタイマー画面で削除します（残ったタイマーは実行するファイルがないため停止しています）。
• タイマーは保存したアカウント（APIトークンのアカウント）の権限で実行されます。 他のアカウントのタイマーは一覧に表示されず、操作もできません。
• 監視するタグがない場合、タイマーは作成されません。
• タイマーが自ら停止した場合、アプリが開いていれば自動的に再登録します（最大3回）。その間、判定がなかった区間は「異常なし」が確認されたわけではない、という案内も一緒に表示されます。

複数のタブ・PC で同じアカウントで開いたとき

同じアカウントでアプリを複数の場所で開いても、判定・通知を受け持つのは1か所（担当）だけです。残りは結果を表示するだけなので、通知が重複して送られることはありません。

• アプリ監視 — 担当タブだけが判定し、通知を送ります。残りのタブのヘッダーバッジは 앱 · 보기 전용（アプリ・閲覧専用）に変わり、担当タブが記録したイベントは一覧の30秒ごとの更新で表示されます。担当タブを閉じると、1分以内に残りのタブが引き継ぎます。
• サーバー常時監視 — 判定はもともとサーバーが行うため、変わりません。タイマーの再登録や自動復旧といった裏方の処理だけを担当タブが行います。
• 設定・学習はどのタブからでも行えます。保存すると、他のタブは10秒以内に新しい設定を読み込んで反映します。そのタブで設定を編集している途中だった場合は、編集内容はそのまま残し、「別の場所で設定が保存されました」という警告を表示します — そのまま保存すると、直前に保存された変更を上書きします。

別のアカウントにログインが切り替わったとき

同じブラウザーで Neo コンソールのログインを別のアカウントに切り替えると、すでに開いていたアプリは旧アカウントの画面なので、保存・判定・照会をすべて停止し、画面全体に「別のアカウントでログインされました」（다른 계정으로 로그인되었습니다）という案内を表示します。

• 새로고침（再読み込み）をクリックすると、新しいアカウントで開き直します。自動では再読み込みしません。このブラウザーに新しいアカウントのAPIトークンがなければ、先にトークン入力画面が表示されます。
• 元のアカウントで再度ログインすると、案内が消えてそのまま動作を続けます。
• 旧アカウントのサーバー常時監視は Neo タイマーなので、影響を受けずに続きます。アプリ監視だった場合はそのタブの判定は止まり、別の PC に旧アカウントで開いている画面があれば、そちらが引き継ぎます。

判定周期と区間

まず知っておくこと — 監視は2つの周期で動きます。

	行うこと	周期	設定場所
速い軸	運転／停止・信号途絶・計測異常・平常比（ベースライン）	判定周期（既定3秒）	アラーム設定（下記）
遅い軸	欠陥パターン — 等級と等級イベントはここから出ます	抽出周期（既定10分）	判定基準 → 帯域エネルギー推移の 抽出周期、または下記の通知カードの 周期変更

以下の設定は速い軸を決めます。等級が実際に変わるのは遅い軸なので、 判定周期を1秒に縮めても、アラームが早く届くわけではありません。 詳しくは 異常判定の仕組み にあります。

アラーム設定の最初の項目は、1つの文になっています。

直前 [RMS区間] 間のデータを [判定周期] ごとに判定

• 区間が長いほど短い揺らぎが1つにまとまって誤警報が減りますが、その分、反応は遅くなります。
• 判定周期より短い区間は選択肢で選べないようになっています。後から判定周期を延ばして区間より長くなると警告が表示され、このとき判定は区間を判定周期の長さまで広げて行うため、抜け落ちるデータはありません。
• 負荷が周期的に変化する設備であれば、その変動周期より長い区間を設定してください。短いと、負荷の変化が停止・逸脱として検出されます。
• タグ数が多く周期が短いと、負荷警告が表示されます。

この設定は、カードの運転状態（停止・信号途絶・計測異常）の判断と平常比の根拠にも、同じ定義で使われます。等級はこの値ではなく、抽出周期ごとに欠陥パターンと ISOゾーンが決めます。

通知

アラームをいつ出すか（確定ルール）と、どこへどのように送るか（チャンネル・重大度別の方式・再通知・まとめ送信）を1か所で設定します。

いつ出すか — 2回連続

設定ではなく固定ルールです。 等級は同じ判定が2回連続して初めて確定し、そのときにアラームが出ます。悪化するときも改善するときも同じです。

1回目   注意    観察イベント・通知なし
2回目   注意    しきい値超過・通知送信
3回目   良好    （まだ復帰ではない）
4回目   良好    正常復帰・通知送信

判定回の間隔は 抽出周期（既定10分）に従います。この周期を30分に変えると、確定までに60分かかります。通知カード上部の判定回の表が、現在の設定でいつ通知が送られるかを示し、周期変更 ボタンですぐに変更できます。

監視状態イベントは、速い軸で時間を基準に判定します（設定では変更しません）。

どこへ送るか — 通知チャンネル

送信チャンネルは Webhook 1つです。URL から送信先のサービスを判別し、メッセージ形式を合わせて送るため、以下のサービスは URL を入力するだけで使えます。

URL を入力して テスト送信（테스트 발송）を押すと、実際に1件送信して接続を確認できます。

Webhook URL はパスワードと同じです。 URL を持っている人は誰でも、そのチャンネルに投稿できます。漏えいした場合は、該当サービスで Webhook を削除して新しく作成してください — 削除した時点で古い URL は無効になります。

メール・ショートメッセージ（SMS）で受け取る必要がある場合は、Webhook を自動化ツールで中継します。n8n・Node-RED・Zapier・Google Apps Script などのツールの Webhook 受信 URL をチャンネルに入力すると、独自エンドポイント向けのペイロードにメールの件名（subject）と HTML 本文（body）まで含めて送られるため、受信側でそのままメール・SMS に変換できます。

通知言語

通知文の言語を韓国語・英語・日本語から選びます。画面の言語とは別に設定できるので、画面は英語で使いながら現場の通知は韓国語で受け取る、といった使い方もできます。

• 最初は、いまの画面言語が選ばれた状態で表示されます。サーバー常時監視の通知に反映するには 保存 が必要です。一度も保存していないアカウントは、これまでどおり韓国語で送信します。
• 件名（等級・種類）、値の行、イベントの理由がすべてその言語で送られます。設備の別名やタグ名は入力したままです。
• テスト送信 は保存しなくても、いま選んでいる言語で送るので、保存する前に文面を確認できます。

重大度別の通知

重大度ごとに、通知するかどうかと、異常が続くときに再度通知する周期を決めます。

表には、等級の3行の下に 監視異常（감시 이상）の行がもう1行あります。

既定値は4行すべて即時です。

• 「注意」も既定でオンになっています。 このアプリで注意は「欠陥パターンが検出された」という意味なので、オフにすると、このツールが検出するものの大部分が、通知なしで一覧に溜まるだけになります。
• 再通知が既定でオンになっています。 確定後に何も来なければ、「さっきのは単発だったのか」が分からないためです。正常な設備はそもそも確定自体がまれなので、再通知で増える量はほとんどなく、溜まるのは本当の欠陥が続くときだけです。
• 監視異常は設備の等級ではありません — 「この設備がどれだけ悪いか」ではなく、「この値を信頼できるか」です。そのため、等級のルーティングとは別にオン／オフします。監視が目を閉じているのに誰も気づかない状態が、最悪の失敗だからです。
• 監視異常の行には再通知がありません。途絶・計測異常は状態が続いている間はイベント自体が発生しないため、再度通知する対象がありません。
• 通知しない に設定してもイベントは記録されます — 送信だけを省きます。再通知イベントも同様に、履歴には常に残ります。
• 復帰通知 は、注意・危険・重大のいずれか1つでも即時になっていれば送信されます。アラームを受け取ったなら、解除も知る必要があるためです。
• チャンネルはオンなのに 等級の3行（注意・危険・重大） がすべて 通知しない になっている場合、画面に警告が表示されます（監視異常の行は数えません）。

一度に多数発生したとき — まとめ送信

同じ判定回に同じ種類・同じ等級のイベントが5件以上あると、1件にまとめて送ります。

[주의] 신호 두절 91대
PUMP_A 38 · FAN_B 25 · LINE_3 16 · 외 12
6분 무수신
2026-10-12 14:03:20

収集が途切れると、全タグが同じ判定回に途絶を出します。1件ずつ送るとチャンネルの上限（Slack 毎秒1件・Discord 2秒に5件）に引っかかり、任意の一部だけが届きます。「91台途絶」が「ランダムな8台途絶」として届くと、残りは正常だと思い込んでしまうため、全く届かないよりも悪い結果になります。

4件以下は個別に送ります — 設備が2~3台なら、タグ・値・基準まで見えるほうが役に立ちます。

履歴は常に個別に保存されます。 まとめは送信形態にすぎないため、イベント一覧・CSV はそのままです。

Webhook 設定ガイド

Discord

サーバー管理権限のあるチャンネルで作業します。アラーム専用チャンネル（例：#振動-アラーム）を1つ作って設定することをお勧めします — 会話用チャンネルに混ざると、アラームを後から追いにくくなります。

1. チャンネル横の ⚙️ チャンネルの編集 をクリック
2. 左メニューの 連携サービス（Integrations）
3. ウェブフック → 新しいウェブフック — 名前・アバターは自由（例：振動監視）
4. ウェブフックURLをコピー

URL は https://discord.com/api/webhooks/… の形式です。アプリの Webhook 欄に貼り付け、テスト送信で確認します。

通知は重大度の色バーが付いたカードとして届きます。送信制限は Webhook あたり2秒に5件程度で、通常の運用では達しません。

Google Chat（スペース）

Workspace（会社・組織）アカウント専用です — 個人の @gmail.com アカウントの Chat には Webhook メニューがありません。Webhook はスペースにのみ追加できます（DM には不可）。

1. chat.google.com → スペース → + スペースを作成（例：振動-アラーム）
2. スペース名をクリック → アプリと統合（Apps & integrations）
3. Webhook → Webhook を追加 — 名前を入力（例：振動監視）、アバター URL は空欄でも可 → 保存
4. 作成された URL をコピー

URL は https://chat.googleapis.com/v1/spaces/… の形式です。送信制限はスペースあたり毎分60件です。

Webhook メニューが表示されない場合は、個人アカウントであるか、Workspace 管理者が Webhook を無効にしています（管理コンソール → Chat の設定で許可が必要）。

Slack

Slack では Webhook が「アプリ」の中にあるため、アプリを1つ作成する必要があります。5分ほどかかります。

1) アプリを作成 — api.slack.com/apps

1. ワークスペースのアカウントでログイン → Create New App
2. From scratch を選択
3. アプリ名を入力（例：振動監視） → 追加先の ワークスペースを選択 → Create App

2) Incoming Webhooks を有効にする

ここからは、作成したアプリの設定画面の中です。api.slack.com/apps はアプリ一覧ページでメニューがないため、一覧でアプリ名をクリックして中に入ります。

1. 左サイドバーの Features → Incoming Webhooks（見当たらない場合は、Basic Information ページの「Add features and functionality」アコーディオンを開くと、同じ画面へ移動するカードがあります）
2. トグルを On に
3. 下の方にある Add New Webhook to Workspace をクリック
4. アラームを受け取る チャンネルを選択（例：#振動-アラーム） → 許可する
5. 作成された Webhook URL をコピー

URL は https://hooks.slack.com/services/T…/B…/… の形式です。

回避策 — アプリを作成したくない場合：Slack クライアントでワークスペース名 → ツールと設定 → アプリを管理する → 検索欄に 「Incoming WebHooks」 → Slack に追加 → チャンネルを選択。Slack ではレガシーと表示されますが、動作は同じです。

知っておくべき点：

• 送信制限は毎秒1件が目安で、このドキュメントで紹介するサービスの中で最も厳しい制限です。
• 無料プランでは 90日を過ぎたメッセージが非表示になります。 アラーム履歴は Slack ではなく、アプリのイベント一覧でさかのぼってください — イベントは自動削除されません。
• 複数のチャンネルを使う場合は、Add New Webhook to Workspace を繰り返すと、チャンネルごとに別の URL が発行されます。ただし、アプリの Webhook 欄は1つなので、重大度別に異なるチャンネルへ送ることはサポートしていません。

帯域エネルギー根拠（任意）

全体の振動はほとんど動かないのに、特定の周波数帯域だけが跳ね上がる変化 — 代表的なのは初期のベアリング欠陥 — を根拠として見るには、帯域抽出をオンにします。設定 → 判定基準 → 帯域エネルギー推移 にあります。

使用手順は次のとおりです。

1. 帯域・欠陥パターン抽出 スイッチをオンにし、抽出周期を決めます（10分・30分・1時間）。
2. サンプルが不足している場合は、過去データの補完 で、すでに DB にある生データをさかのぼって計算します。
3. サンプルが十分になったら、学習 で系列ごとの正常基準を作成します。
4. 学習済みの系列が限界値を超えると、カード（数値にマウスを合わせる）と根拠表に 限界値に対する倍率 で表示されます。

帯域は通知を出しません。 複数の系列のうち1つでも超えればオンになる仕組みのため誤検知が多く、判定の時間軸も等級とは異なります。 帯域の値は通知ではなく、「どの帯域が動いたか」で原因を絞り込むための根拠として使います。 同じ理由で、ベースラインからの逸脱も通知を出しません — 表示されるだけです。

8つの周波数帯域に加えて、包絡線（エンベロープ）系列（周期性、ベアリング型番があれば BPFO・BPFI・BSF の欠陥周波数）も一緒に蓄積され、同じ方法で学習されます。各タグ行の 4/9 계열 학습됨（4/9系列学習済み）で、分母はそのタグで測定可能な系列の数です — サンプルレートやマウンティング上限が低いと上位の帯域が外れ、ベアリング型番がないと欠陥周波数の系列が外れますが、これは正常です。詳しい設定は 初期設定 › 帯域・欠陥パターン抽出 にあります。

学習は正常運転が確実なときに行ってください。欠陥がすでに進行中であれば、その欠陥が正常基準になってしまいます。

イベント

判定結果は Neo にイベントとして蓄積され、アプリを開き直したり、タイマーが再び動いたりしても引き継がれます。

イベントは モニタリング タブ下部の一覧で確認します。期間チップとタグ・種類フィルターで絞り込むことができ、各行をクリックすると、その時点の詳細分析に移動します。一覧の各欄の意味は 使い方 › イベント一覧 に、種類別の意味と記録ルールは 異常判定の仕組み › イベント にあります。

• 一覧は30秒ごとに読み込み直します。サーバー常時監視が記録したイベントも、ページを再読み込みしなくても表示されます。
• 一覧と件数は現在監視中のタグだけを数えます。データソースで選択を解除したテーブルのイベントは一覧から外れますが、削除はされません。
• タグ・種類フィルターは照会条件です — フィルターに一致するイベントのうち最新 200件 を表示し、件数はフィルターに一致する全体です。ヘッダーの 最近のイベント 欄はフィルターとは関係ありません。
• 全履歴は 保存（エクスポート）で期間を指定し、CSV・JSON で取得します。選択を解除したテーブルのイベントも含まれます。
• イベントは自動的には削除されません。撤去した設備の履歴は 設定 → データ管理 → タグ別整理 で削除します。

監視状態の確認

「イベントがない」には2つの意味があります — 設備が正常であるか、監視が動いていないかです。アプリはこの2つを区別して、モニタリング画面の一番上に知らせます。メッセージは画面の言語で表示されます。

サーバー監視

帯域抽出

アプリ共通

等級が短い間隔で悪化を繰り返すと（直近2時間にしきい値超過が3回以上）、カードに 等級反復 N回 バッジが付きます。欠陥の根拠が採択ラインの付近を行き来している状態で、負荷変動が原因の場合もあれば、欠陥の初期段階の場合もあります。バッジをクリックすると、最後に悪化した時点の詳細分析が開きます — 設定で隠すのではなく、欠陥の根拠と包絡線スペクトルで原因を確認してください。

確認手順

アラームが意図どおりに動いているかを見るときは、次の順序で確認します。

1. ヘッダーのアラーム表示が オン になっているか、サーバーモードならバッジが付いているか。
2. 画面上部に監視状態の警告が出ていないか。
3. モニタリング → イベント 一覧に判定結果が溜まっているか。種類・タグのフィルターで絞り込んで確認します。
4. 通知が届かない場合は、チャンネルの テスト送信 で、まず送信経路を切り分けて確認します。
5. テストは届くのに実際のアラームが届かない場合は、重大度別の通知方式 を確認します。また、等級は 2回連続 で初めて確定するため、1回だけ出たものは 観察 として残るだけで、通知は送られません。
6. サーバーモードで特定のタグだけ反応がない場合は、そのテーブルに ROLLUP があるか確認します。
7. 振動が明らかに高いのに何のアラームも出ない場合は、回転数とベアリング型番 が入力されているか確認します — どちらか一方でも空だと欠陥パターンを計算できないため等級が上がらず、カードに 判定保留（판정 보류／判定不可）と表示されます。

ページ移動

• 前へ：使い方
• 目次に戻る
• 次へ：異常判定の仕組み