【JP1/AJS】Windowsイベントログ監視新旧2つのジョブで設定はどう違う？

JP1/AJS

2026.07.282026.07.29

JP1でWindowsのイベントログ（アプリケーションログやシステムログなど）を監視してジョブを起動させる際、大きく分けて2つのジョブアイコンが存在します。

どちらを使っても「イベントログが出力されたらジョブを動かす」ということは実現できますが、裏側で動く「JP1/Base」のイベントログトラップ設定や動作メカニズムには明確な違いがあります。

今回は、この2つのアプローチにおける「設定や仕組みの違い」を徹底解説します！

結論：何が違うのか？（比較表）

まずは全体像を表で比較してみましょう。

比較項目	① Windowsイベントログ監視ジョブ	② JP1イベント受信監視ジョブ（旧来）
定義場所	AJS3 – View のジョブ詳細定義画面	OS側の `ntevent.conf`（動作定義ファイル）
監視のトリガー定義	AJSの画面上で画面入力	`ntevent.conf` に直接テキスト記述
JP1/Base サービス設定	特別なファイル編集は不要（AJSが自動設定）	手動で設定ファイルを編集・反映が必要
フィルター処理の場所	JP1/AJS（AJS側で条件絞り込み）	JP1/Base（Base側でJP1イベント化段階で絞り込み）
手軽さ・運用性	🟢 非常に高い（GUIで完結）	🟡 設定変更時にコマンド実行等の手間あり

現在推奨されている専用アイコンを使用する方法です。

結論から言うと、手動での ntevent.conf の編集は不要です。

AJSの画面上で「イベントID：1000」「メッセージ：Error」といった条件を設定して実行登録すると、JP1/AJSがJP1/Baseに対して自動的に監視条件を登録してくれます。

メリット：

サーバー側の設定ファイルを直接書き換える必要がないため、AJSの画面（GUI）だけで設定が完結します。ジョブの追加や変更が非常に簡単です。

古くからの運用や、他のJP1イベント（他システムからのイベントなど）と共通の仕組みで監視する場合の方法です。

この方法では、事前に監視対象サーバー上で設定ファイルを手動編集し、コマンドで反映させる作業が必須となります。

以下のように、監視したいログの種類やイベントID、フィルター条件を記述する。

Plaintext

# 例：アプリケーションログのイベントID 1000 のみトラップする設定
trap-name "App_Error_1000"
  Logfile "Application"
  EventID 1000
  Type Error

Windowsイベントログが発生する。
JP1/Baseが ntevent.conf の定義に従ってログをフィルタリングし、合致したものだけをJP1イベントとして発行する。
JP1/AJS側は「JP1イベントID（00003A71←Windowsイベントのログメッセージを検知した場合に発行される基本変換イベント　通常のイベントジョブ場合は通常このIDを設定）など」を受信したことだけを検知してジョブを起動する。

注意点・デメリット：

監視したいイベントログの種類が増えるたびに、OS上の設定ファイルを書き換えてコマンドで反映させる手間が発生します。設定漏れやファイル記述ミスによるトラブルが起きやすいのが難点です。

基本的には、新しい設計であれば「Windowsイベントログ監視ジョブ（専用アイコン）」一択です。

専用の「Windowsイベントログ監視ジョブ」：JP1/Baseの設定（ntevent.conf）は自動化され、AJS画面だけで設定が完結する。
旧来の「JP1イベント受信監視ジョブ」：JP1/Base側で ntevent.conf の手動編集と反映コマンドが必須。

裏側の仕組みを知っておくと、トラブルシューティング（「なぜイベントログを拾ってくれないのか？」の調査）の際に「AJS側の画面定義を疑うべきか」「Base側のトラップ設定を疑うべきか」の切り分けがスムーズになります！