こんにちは！JP1/AJSのイベント連携やジョブフロー設計、日々お疲れ様です。
システム間で「処理が終わったよ」「次の処理を始めていいよ」という合図を送るために、JP1イベントの送受信（送信ジョブ／受信監視ジョブ）を使っている環境は多いと思います。
その際、受信側のプロパティで設定する「メッセージ」の条件ですが、「送信側と受信側でメッセージが完全に一致していなくてもジョブが検知してしまう」という仕様をご存知でしょうか？
今回は、実際の検証パターンをもとに、JP1イベント送受信におけるメッセージの終了判定ロジックについて詳しく解説します！
顧客常駐はもう嫌だ！社内SEへ転職するなら【社内SE転職ナビ】
Cursor・Claude Code・Codex AIスキルを学ぶなら
環境構築不要！AIエージェント開発を非エンジニアでも即実践【AI Agent Camp】
1. 【検証結果】イベント送受信のメッセージマッチング3パターン
受信側の設定を 【イベントID：1、メッセージ：test】 と定義している環境に対して、送信側から異なるメッセージを送り、受信ジョブがどう反応するかを検証しました。
結果は以下の通りです。
| パターン | 送信側のメッセージ | 受信側の判定 | 理由・挙動の解説 |
| ① 完全一致 | test |
⭕ OK（検知） | 定義通り、完全に一致しているため問題なくフックします。 |
| ② 後ろが長い | testtest |
⭕ OK（検知） | 【重要】 先頭の4文字が test で始まっているため、**前方一致（先頭部分一致）**とみなされて受信に成功します。 |
| ③ 不一致 | ajs |
❌ NG（無視） | まったく異なる文字列なので、当然ながら受け付けません（監視状態のまま待機します）。 |
2. 実務で超重要！JP1はデフォルトで「前方一致」扱いになる
検証のパターン②にある通り、受信側が test なのに対して、送信側が testtest や test_complete のように後ろに余計な文字がくっついていても、JP1は「条件クリア！」と判定してしまいます。
これはバグではなく、JP1/AJSの「引き当て（マッピング）はデフォルトで前方一致で行われる」という仕様によるものです。
⚠️ 運用上の注意点
例えば、別々の処理のつもりで以下のようにメッセージを設計してしまうと、意図しない誤検知（他人のイベントを横取りしてしまう現象）が発生します。
-
受信Aの設定：
AP_START -
受信Bの設定：
AP_START_RETRY
この状態で送信側が AP_START_RETRY を飛ばすと、本来動くべきBだけでなく、先頭が一致しているAのジョブネットまで一緒に動き出してしまうことになります。
これを防ぎたい（完全一致にしたい）場合は、受信側の設定で正規表現を使い、末尾文字を固定する（^test$ のように指定する）などの考慮が必要です。
3. 「終了判定が空白」でもメッセージ判断はサボらない！
よくある勘違いとして、「イベント受信ジョブの終了判定項目（引き当て判定）を空白にしているから、イベントIDさえ合っていればメッセージの中身に関わらず、どんなイベントでも『常に正常終了』として受け付けるだろう」と思ってしまうケースがあります。
しかし、これも今回の検証の通り NG です。
終了判定の記述が空白であっても、受信条件として「メッセージ：test」と書いている以上、JP1は送信されてきたメッセージの中身を厳格にチェックします。 まったく一致しないメッセージ（ajs など）が届いた場合は、条件不一致としてスルーされ、ジョブは正常終了しません。
「空白＝何でも通す」ではなく、「空白＝メッセージが条件に合致した時点で、それ以上の細かい数値比較などをせずに正常終了する」という意味ですので、設計時は注意してください。
まとめ
JP1イベントの送受信メッセージの仕様は、以下の3点を覚えておきましょう！
-
メッセージの判定は、基本は「前方一致（先頭部分一致）」である
-
送信側の後ろがどれだけ長くても、頭の文字が合っていればジョブは動いてしまう
-
終了判定を「空白」にしていても、メッセージの条件チェックはしっかり行われる
イベント連携はシステムを跨ぐことが多いため、予期せぬ誤検知を防ぐためにも、メッセージの命名規則（プレフィックス）は慎重に設計してくださいね！
