JP1/AJS3で「特定のファイルがある（または無い）ことを条件に、後続のジョブを動かしたい」というケースはよくあります。
その際に使うのが 「判定ジョブ（ファイル判定）」 ですが、
ここには設計・開発時にめちゃくちゃハマりやすい仕様の罠が隠されています。
「エージェント側のパスを指定しているのに、なぜか意図通りに判定されない…」と頭を抱えている方に向けて、その原因と正しい回避策を解説します！
1. ハマりポイント：判定ジョブは「マネージャーのパス」しか見ない！
結論から言うと、判定ジョブのファイル判定は、ジョブネット全体の「実行エージェント」にどのホストを指定していようが、エージェント側のローカルパスを見に行くことはできません。
判定ジョブの定義画面をよく見ると分かりますが、そもそも「実行エージェント」の入力項目がグレーアウトしていて選択できない仕様になっています。
つまり、判定ジョブが動作するのは常に 「マネージャー環境（JP1/AJS Managerが動いているサーバー）」のローカル です。
❌ ネットワークマウント（共有フォルダ）による指定は非推奨
「じゃあ、エージェントのフォルダをネットワークドライブやファイル共有（NASなど）でマネージャー側にマウントして、マネージャー自身のパスっぽく見せかければいいのでは？」と思いつくかもしれません。
しかし、日立の公式でもネットワーク上のファイルに対する判定ジョブの実行は推奨されていません。 ネットワークの瞬断や認証のタイミングによって判定が不安定になり、予期せぬ誤検知やエラーの原因になるためです。
2. 「ファイルが存在しないこと（非存在）」を条件にしたときの最悪のシナリオ
この仕様を理解しないまま、判定ジョブで「ファイルが存在しないこと」を条件（真）として設定すると、現場では以下のような大混乱（罠）が発生します。
-
開発者は「エージェントAの
C:\tmp\test.txtが無くなったら後続を動かそう」と考えて設定する。 -
しかし、判定ジョブは「マネージャーサーバー」の
C:\tmp\test.txtを見に行く。 -
マネージャー側にはそんなファイルは（最初から）存在しないので、判定ジョブは「よし、ファイルは無いな！判定は【真】だ！」と即座に判断する。
-
結果として、エージェントA側にどれだけファイルが残っていようが関係なく、永遠に「真」となって後続ジョブが突き進んでしまう……。
逆のパターンで「ファイルが存在すること」を条件にしていた場合は、マネージャー側にファイルがないため永遠に「偽（条件不成立）」になり、後続ジョブが一切実行されずに止まります。これ、実際にハマっている現場が結構多いのではないでしょうか。
3. 解決策：エージェントのファイルをチェックしたいなら「ファイル監視ジョブ」を使う
「じゃあ、エージェント側にあるファイルの有無はどうやってチェックすればいいの？」という時の正解は、判定ジョブではなく 「ファイル監視ジョブ（イベントジョブ）」 を使うことです。
ファイル監視ジョブの特徴
-
実行エージェントが指定できる： マネージャーではなく、動かしたいエージェントサーバーを明示的に指定できます。
-
エージェント基準のパスで動く： 指定したエージェントが持つローカルパスを正しく監視してくれます。
💡 【検証テクニック】ファイル監視ジョブの確実な挙動確認
ファイル監視ジョブがちゃんとエージェント側を見ているかテストしたい時は、ファイル名にワイルドカード（＊）などを指定して、適当なファイルをエージェント側で検知させてみてください。
検知に成功すると、JP1の実行結果（詳細情報）に「実際に検知したエージェント側のファイル名」が綺麗に出力されます。これを見れば、マネージャー側ではなく間違いなくエージェント基準のパスでファイル監視が行われていることが確認（確証）できます！
まとめ
-
判定ジョブ： 実行エージェントが選べない。見るのは マネージャーサーバーのローカルパス のみ。
-
ファイル非存在判定の罠： マネージャー側を見て「無い」と判断され、意図せず常に「真」になるリスクがある。
-
エージェントのファイルを見たい時： 迷わず 「ファイル監視ジョブ」 を使い、実行エージェントを正しく指定する。
JP1のアイコンの見た目は似ていますが、中身の挙動は全くの別物です。実務のジョブフローを作る際は、どちらのサーバーのパスを指しているのかを意識して使い分けていきましょう！
