
システム障害やインシデント発生時、「誰に、どうやって、確実に」連絡するかは、対応のスピードを左右する最重要ポイントです。
本記事では、この課題を解決するクラウドサービス「JP1 CS 通報管理」について、その特長や従来の仕組みからの進化ポイントをわかりやすくご紹介します。
※本記事の内容は、2025年11月現在、JP1 CS 通報管理 02-40 時点の情報です。
JP1 CS 通報管理の概要
「JP1 CS 通報管理」は、クラウド(SaaS型)で提供される、システム障害発生時の「通報(通知)」に特化したサービスです。 システムに問題が起きた際に、関係者へ迅速かつ確実に連絡する仕組みを提供し、インシデント対応の初動をスピードアップします。最大の特長は、SaaS型であることです。電話発信機器や電話回線の物理的な準備・管理は一切不要です。導入・運用の手間を大幅に削減し、迅速に確実な通報体制を構築できます。
また、JP1 CS 通報管理自体が稼働監視されているため、安定した運用を実現します。
JP1 CS 通報管理の4つの特長
もう通知漏れとはサヨナラ!多様な手段で「届く」を保証する通知チャネル
JP1 CS 通報管理は、電話、メール、ビジネスチャット(Teams、Slack、LINE WORKS)など、多様な通知手段に対応しています。お客様の運用に合わせ、最適な手段を選択し、確実に担当者に情報が届く体制を構築できます。(使用するチャットサービスやSMS通知などは、事前にお客様側での契約が必要です。)

「気づくまで」逃さない!繰り返しの通知機能
一度通知しても担当者が気づかないケースは珍しくありません。設定した間隔で自動的に通知を繰り返すことで、担当者が通知に気付くまで通知を継続し、「対応漏れ」のリスクを排除します。
JP1 CS 通報管理では、事前に"誰に""どのような"連絡方法をとるかをユーザ情報として登録します。ユーザ情報から通知するユーザと通知方法を組み合わせて「連絡網」として設定し、その設定内容に沿って通知されます。
連絡網には、繰り返し通知(実行回数)を設定できます。電話通知で、連絡先の相手が電話に出なかったり、一時的な電波障害などでつながらなかった場合でも繰り返し通知されます。

時間帯や曜日で自動切替!柔軟な通知運用
夜間・休日と日中とで、担当者が変わることもあるかと思います。JP1 CS 通報管理は、曜日や時間帯に応じた通知手段と通知先の自動切り替えや、通知の停止/再開を簡単に行えるため、柔軟な通知運用ができます。

JP1だけじゃない!既存システムと柔軟に連携できる汎用性
「JP1製品としか連携できないのでは?」という心配はいりません。JP1 CS 通報管理は、コマンド一つで通報を開始できるため、既存の監視システムや自社開発のアプリケーションなど、通知が必要なあらゆる処理と柔軟に連携できます。
通報管理の仕組み
JP1 CS 通報管理は、Webブラウザから通報管理サービスの画面にアクセスし、通知手段、通知先のユーザ、そして最も重要な連絡網を設定します。連絡網は複数設定することができ、システムや障害、時間や曜日によって使い分けることができます。
実際に通知を行うイベントが発生した場合、REST APIまたはJP1 CS 通報管理から提供されているコマンドを使用して、JP1 CS 通報管理へイベント情報(メッセージ)を連携します。JP1 CS 通報管理は、連携されたイベント情報を受け取り、設定された連絡網に基づき、自動で担当者へ通知します。
実行例
SlackにREST APIを使用して通知する例を元に、実際の通報管理サービスの設定画面を紹介します。
通知先のSlackを設定
通知先のSlackは、通報管理サービスの[接続先]で設定します。
Slackの場合は[通知先]>[Slack]でSlackのOAuth Tokensを設定します。OAuth Tokensは、Slack側であらかじめ発行しておく必要があります。
ユーザ情報の設定
通報管理サービスの[ユーザ]の画面で、ユーザと連絡方法をユーザ情報として登録します。ユーザ情報には、Slackを登録する場合は、「Slackメンバー名」と連絡先で登録した「Slackプロファイル名」を設定します。
連絡網の設定
通知を届けたいユーザとその連絡方法を組み合わせて連絡網を作成します。連絡網は、通報管理サービスの[連絡網]で作成します。
設定するユーザと連絡方法は、ユーザ情報から選択します。
通知の実行
コマンドまたはREST APIを使用して通知を実行します。実行時に連絡網を指定することで、連絡網にあらかじめ設定されているユーザへ、設定された通知方法で情報が通知されます。以下にREST APIでの実行例を紹介します。この内容をスクリプト化して、JP1/IM3や他社監視製品から実行します。
ステップ1:サインインして利用トークンを取得(認証)
まず認証を行い、APIを利用する権利を証明するための「鍵(トークン)」を取得する必要があります。これは、APIセッションを開始するための最初のステップであり、ブラウザを使って通報管理にログインするのと同じような手続きです。
1-1.リクエストの基本情報
項目 | 内容 | 説明 |
|---|---|---|
実行操作 | POST | データの送信 |
宛先 | https://host/api/v1/signin | 認証処理を行うAPIのURL |
ヘッダー | Content-Type: Application/json | 送るデータが JSON 形式であることを示す |
1-2.送信するデータ(リクエストボディ)
アカウント情報を以下の形式で送信します。
フィールド名 | 型 | 説明 | 必須/任意 |
|---|---|---|---|
account | string | アカウント名 | 必須 |
subaccount | string | サブアカウント名 | 任意 |
password | string | パスワード | 必須 |
1-3. cURL サンプル: トークンの取得
1-1、1-2 で説明したデータ形式(JSON)を元に、以下のコマンドを実行すると、APIにサインイン情報を送信できます。
※実際は1行で実行します。
curl -X POST "https://notify-saas-xxxxx.hitachi-solutions.co.jp/api/v1/signin"
-H "Content-Type: application/json"
-d "{\"account\"":\”アカウント名\""1-4.返されるデータ(レスポンスボディ)
認証が成功すると、APIを利用するための「IDトークン」が返されます。
フィールド名 | 型 | 説明 |
|---|---|---|
id_token | string | API利用に必要なIDトークン |
expires | number | IDトークンの有効期限(秒数) |
refresh_token | string | IDトークンの更新用トークン |
access_token | string | サインアウト時に使用 |
ステップ 2: 連絡網の発信要求を実行
連絡網発信APIを使って連絡網の発信要求を実行します。この際、ステップ 1 で取得したトークン(鍵)を提示することで、APIに対して同一セッション(ログイン中)であることを証明します。
2-1. リクエストの基本情報
項目 | 内容 | 説明 |
|---|---|---|
実行操作 | POST | データの送信 |
宛先 | https://host/api/v1/net/{id}/execute | 連絡網発信を行うAPIのURL |
ヘッダー (必須) | Authorization: Bearer [id_token] | [id_token] の部分にステップ 1 で取得したトークンの値を設定 |
Content-Type: Application/json | 送るデータが JSON 形式であることを示す |
2-2.送信するデータ(リクエストボディ)
実行したい処理に渡したい具体的な指示や内容を以下の JSON 形式で API に送信します。
フィールド名 | 型 | 説明 |
|---|---|---|
tel_content | string | 連絡網内の電話発信の内容を指定 |
mail_subject | string | 連絡網内のメール発信時の件名を指定 |
mail_content | string | 連絡網内のメール発信の内容を指定 |
slack_content | string | 連絡網内のSlackへの発信の内容を指定 |
2-3.cURL サンプル: 処理の実行
2-1、2-2 で説明したデータ形式(JSON)を元に、以下のコマンドで、IDトークンを使いながら、連絡網の発信処理を依頼できます。
※実際は1行で実行します。
curl -X POST https://notify-saas-xxxxx.hitachi-solutions.co.jp/api/v1/net/blogtest/execute
-H "Content-Type: application/json"
-H "Authorization:Bearer サインインで取得したid_tokenの値"
-d "{ \"tel_content\": \"エラーが発生しました\",
\"mail_subject\": \"エラーが発生しました(メール)\",
\"mail_content\": \"エラーが発生しました\",
\"slack_content\": \"エラーが発生しました(slack)\
"}"通知結果
Slackへの通知
APIのリクエスト書式「slack_content」で指定した文字列が通知されます。

電話への通知
APIのリクエスト書式「tel_content」で指定した文字列「エラーが発生しました」が、音声メッセージとして流れます。
メールでの通知
APIのリクエスト書式「mail_subject」がメールの件名、「mail_content」がメール本文として通知されます。
件名:エラーが発生しました(メール)
本文:エラーが発生しました
REST APIによる通知が可能なので、JP1以外の既存の監視システムと本サービスを連携することも可能です。
また、JP1/IM3と連携することで、JP1/IM3へ転送されたメッセージを、通報管理サービスのメッセージとして関係者に通知することができます。
JP1/TELstaffをお使いの方へ
JP1の通報管理機能として、オンプレミス製品の「JP1/TELstaff」が提供されていますが、「JP1/TELstaff」はV12で開発が終了になりました。今後についてはクラウド版「JP1 CS 通報管理」への移行をご検討ください。
JP1 CS 通報管理とJP1/TELstaffの機能差異は下表の通りです。
比較区分 | JP1/TELstaff | JP1 Cloud Service 通報管理 | |
|---|---|---|---|
提供形態 | オンプレ | SaaS | |
対応OS | Windows | クラウドサービスのため不要 | |
連携手段 | コマンドを受けての通知実行 | ○ | ○ |
メールを受けての通知実行 | ○ | ○ | |
REST APIを受けての通知実行 | ‐ | ○ | |
通知手段 | パトランプ通知(パトランプ利用) | ○ | ○※1 |
電話通知 | ○ | ○ | |
メール通知 | ○ | ○ | |
SMS通知 | ○ | ○ | |
コマンド実行 | ○ | ‐ | |
デスクトップパトランプ通知 | ○ | ‐ | |
チャット通知 | ○ | ○ | |
監視機能 | ○ | ‐ | |
機器稼動監視機能 | ○ | ‐ | |
設定方法 | GUI | GUI | |
管理機能 | 連絡網 | ○ | ○ |
ユーザ管理 | ○ | ○ | |
通知先の最適化 | ‐ | ○ | |
ユーザ数 | 2000 | 30,000 | |
連絡網数 | 500 | 500 | |
連絡網グループ数 | 200※2 | 連絡網グループの概念なし | |
(電話通知の場合)電話通知機器・電話回線など | 必要 | 不要 | |
<凡例> ○…対応 ‐…非対応
※1:メール受信機能を持つパトランプ通知で代替えできます。
※2:1連絡網グループ内に登録可能な連絡網の数です。
まとめ
本記事では、システム障害やインシデント発生時の初動対応で重要となる「確実な通報」を実現するクラウドサービス「JP1 CS 通報管理」についてご紹介しました。
既存の通報システムに課題をお持ちの方、オンプレ版の「JP1/TELstaff」をご利用中のお客様は、この機会にクラウド型の「JP1 CS 通報管理」への移行をご検討いただき、緊急事態でも慌てない「確実な」インシデント通知体制を実現しましょう。
製品正式名称(略称表記)
JP1 Cloud Service/Notification Management(JP1 CS 通報管理) 02-00 以降JP1/Integrated Management 3 - Manager(JP1/IM3)13-00以降
※記載されている会社名や製品名は、各社の登録商標です。
JP1ブログをご覧いただいているみなさまへご案内
いつもJP1サポート技術者ブログをご覧いただきありがとうございます。
本ブログの執筆を担当しているアシストJP1サポートセンターは、「JP1認定技術者」の資格を持つサポート技術者の対応が支持され、お客様満足度は10年連続90%以上を維持しています。
紹介サイトでは、サポートセンターが誇る3つの特徴とJP1の最新情報満載の提供サービスを、お客様の声とともにご紹介しています。是非ご覧ください。
また、アシストとJP1保守契約を締結されている方は、Webサポートセンター「AWSC-2」をご利用いただけます。本ブログサイトではご紹介しきれない2,000件以上のFAQを公開していますので、是非ご利用ください。詳細は、下記リンクよりご確認ください。
ページトップへ戻る
この記事を書いたスタッフ
保木 紗知子
保木 紗知子






