こんにちは!JP1/AJS3の運用を担当されている皆さん、日々の運用お疲れ様です。
「最近、なぜかJP1マネージャーの動きがもっさりする時間帯がある」 「ビューアーの表示や、コマンドのレスポンスが時々重くなる気がする……」
そんな悩みはありませんか? サーバー自体のスペックは足りているはずなのに発生する原因不明の重さ。実はそれ、リポジトリ(データベース)内に溜まった「過去の遺物」や「不要なジョブネットの放置」が原因かもしれません。
今回は、未実行の作成中ジョブネットや臨時実行の残骸が重さに与える影響と、それらを一発であぶり出すための実用的な1行コマンドを徹底解説します!
結論:「不要なジョブネットの残骸」は確実に重さの原因になる!
結論から言うと、「未実行の作成中ジョブネット」や「過去の単発の臨時実行済みジョブネット」が残っていることは、マネージャーが重くなる原因に深く関係しています。
「実行していない(または終わった)なら、CPUもメモリも食わないのでは?」と思いがちですが、JP1/AJSの仕組み上、これらはバックグラウンドでボディブローのように効いてきます。
原因①:データベース(ajsdb)の肥大化と検索コスト
JP1マネージャーは、すべてのジョブネット定義や実行ログを内部のデータベースで管理しています。 実行されていない作成中のジョブネットや、過去に1回だけ動かして放置されている臨時ジョブネットであっても、定義データとしてデータベースの容量を圧迫します。
ビューアーを開いたときや、ajsshow などのコマンドを叩いたとき、JP1はデータベース全体をスキャンしにいくため、データ件数(オブジェクト数)が多ければ多いほど、ディスクI/Oが発生して全体の動きが重くなります。
原因②:スケジュール算出と「カレンダー参照」の罠
特に要注意なのが、「臨時実行以降スケジュールされていないのに、他定義のカレンダーを参照しているジョブネット」が残っているケースです。
JP1マネージャーは、日付が変わるタイミングや参照先カレンダーが更新されたタイミングで、裏で実行スケジュールを再計算しています。例えそのジョブネット自体はもう動かす予定がなくても、カレンダーの紐づけが残っているだけで無駄なスケジュール計算のオーバーヘッドが発生している可能性があります。
実践:放置された「臨時ジョブ」をコマンド1行であぶり出す
あなたの環境に、過去に動かしたまま放置されているルートジョブネットがどれくらいあるか、以下のコマンドで一括取得してみましょう。余計な子ジョブ(PCジョブ等)の細かいログを徹底的に省き、「ルートジョブネットレベルの履歴だけ」 を正確に抽出します。
このコマンドは、指定したジョブグループの「直下にあるジョブネット」はもちろん、「直下にあるジョブグループの中に隠れているジョブネット」も含め、配下の階層を自動で深く掘り下げて(再帰的に)すべてのルートジョブネットの履歴を1回で拾い上げます。
OSに合わせて、コマンドプロンプトやターミナルに以下の「1行」をそのまま貼り付けて Enter を押すだけで実行できます。
1. Windows(コマンドプロンプト)の場合
(※結果は C:\temp\ajs_history.txt に出力されます。あらかじめ C:\temp フォルダが存在することを確認してください)
DOS
ajsshow -F AJSROOT1 -f %J,%C,%s,%e -R -N "AJSROOT1:/" > "C:\temp\ajs_history.txt"
※-Nを取るとジョブ単位で表示されます。
2. Linux(Bash)の場合
(※結果は /tmp/ajs_history.txt に出力されます)
Bash
ajsshow -F AJSROOT1 -f %J,%C,%s,%e -R -N "AJSROOT1:/" > "/tmp/ajs_history.txt"
✍️ 事前準備と出力結果の見方
-
/あなたのジョブグループ名: 調査したいグループのフルパス(例:/AJS1ROOT1/GroupA)に変えて実行してください。全体を調べたい場合は/でOKです。 -
出力結果(CSV形式): 指定したテキストファイルに、以下のように階層を問わず 「ルートジョブネット名」「状態」「開始日時」「終了日時」 が出力されます。
ajsshow -F AJSROOT1 -f %J,%C,%s,%e -R -N "AJSROOT1:/" /jobnet1,正常終了,2026/07/21 09:20:00,2026/07/21 09:20:00←直下のジョブネット/jobnet2,正常終了,2026/07/21 11:52:49,2026/07/21 11:52:49←直下のジョブネット/jobnet2/sub_jobnet2,正常終了,2026/07/21 11:52:49,2026/07/21 11:52:49←直下のジョブネット内のジョブネット/subgroup/jobnet2,正常終了,2026/07/21 11:55:16,2026/07/21 11:55:16←直下のジョブグループ内のジョブネット/subgroup/jobnet2/sub_jobnet2,正常終了,2026/07/21 11:55:16,2026/07/21 11:55:16←直下のジョブグループ内のジョブネット内ジョブネット↓-Nを付けないとジョブ単位で表示するajsshow -F AJSROOT1 -f %J,%C,%s,%e -R "AJSROOT1:/" /jobnet1,正常終了,2026/07/21 09:20:00,2026/07/21 09:20:00 /jobnet1/PCジョブ,正常終了,2026/07/21 09:20:00,2026/07/21 09:20:00 /jobnet2,正常終了,2026/07/21 11:52:49,2026/07/21 11:52:49 /jobnet2/sub_jobnet2,正常終了,2026/07/21 11:52:49,2026/07/21 11:52:49 /jobnet2/sub_jobnet2/PCジョブ,正常終了,2026/07/21 11:52:49,2026/07/21 11:52:49 /subgroup/jobnet2,正常終了,2026/07/21 11:55:16,2026/07/21 11:55:16 /subgroup/jobnet2/sub_jobnet2,正常終了,2026/07/21 11:55:16,2026/07/21 11:55:16 /subgroup/jobnet2/sub_jobnet2/PCジョブ,正常終了,2026/07/21 11:55:16,2026/07/21 11:55:16
コマンド内の最初のオプションである -R が、配下の
フォルダ階層をすべて自動巡回してくれるため、どんなに複雑な階層構造になっていても漏れなく過去ログをあぶり出すことができます。Excel等に貼り付けて「最終実行日」でソートすれば、何ヶ月も放置されているお化けジョブネットが一目瞭然になります。
他にも考えられる「JP1が時々重くなる」主な原因
不要なジョブネット以外にも、マネージャーが一時的に重くなる代表的な原因をリストアップしました。
1. 実行世代数(ログ)の溜まりすぎ
ジョブネットの「保存世代数」を大きく設定しすぎていませんか? 毎日高頻度(数分おきなど)で動くジョブネットの保存世代数が「999」などになっていると、膨大な実行履歴がデータベースに蓄積され、一気にパフォーマンスが落ちます。
2. ジョブの集中時間帯(スパイク)
毎日「00:00」や「09:00」など、キリの良い時刻に何百ものジョブを一斉に起動させている場合、その瞬間だけプロセス生成やログ書き込みが集中し、マネージャーの負荷が跳ね上がります。
まとめ:マネージャー軽量化のための対策
重い状態を解消し、快適なJP1環境を取り戻すためのベストプラクティスです。
-
不要なジョブネットは「即・削除」または「エクスポートして退避」 作成途中のものや、過去の臨時実行ジョブは、放置せず削除しましょう。もし後で使う可能性があるなら、
ajsprintコマンドでユニット定義ファイル(テキスト)としてバックアップを取った上で、システム上からは削除するのが鉄則です。 -
保存世代数の見直しとスケジュールの分散 高頻度ジョブの保存世代数は必要最低限(例: 2〜5世代など)に抑え、同時起動するジョブネットの開始時刻を数分ずつずらす(平準化する)だけで、負荷の山を劇的に潰すことができます。
「使っていないから大丈夫」と過信せず、定期的にユニットの棚卸しを行い、データベースをスリムに保つことが、安定運用の第一歩です。ぜひご紹介した1行コマンドを使って、環境内の「お掃除」を検討してみてくださいね!

