24時間稼働する工場システムのジョブ管理、その過酷な現実
生産ラインが止まれば数千万円の損失。夜中の2時にアラートが鳴り、原因を特定できずに朝を迎える。これが、24時間365日稼働する工場システムの運用設計を担当したときの現実でした。
オンプレミスでのジョブ管理システム、特にJP1のような統合運用管理ツールを使った経験がある方なら、この緊張感を理解していただけると思います。画面上では整然と並ぶジョブフロー図。しかし、その裏には複雑に絡み合った依存関係があり、一つのジョブの遅延が連鎖的に他のジョブに影響を及ぼします。
私が2017年に担当したのは、ある食品工場の生産管理システムでした。プロジェクト規模は50名体制で、期間は3ヶ月。SEとして運用設計を任されたのですが、これが想像以上に骨が折れる仕事だったんですよね。
2017年、私は食品工場の生産管理システムでSEとしてJP1の運用設計を担当しました。体制は50名、期間は3ヶ月でした。食品工場は24時間稼働が前提で、夜間バッチが多数走ります。受注データ取込、在庫更新、生産計画作成、出荷指示など、ジョブの依存関係が非常に複雑でした。JP1のジョブネット設計だけで、図面が壁一面になるほどでした。アラート設計も難しく、閾値を厳しくしすぎると過剰アラート、緩めると本当の障害を見逃すリスク。何度も試行錯誤して落とし所を見つけました。当時はオンプレ前提でしたが、今ならDatadogやMackerelでもっと柔軟に設計できると感じます。クラウド監視ツールはJP1の良いところを引き継ぎつつ、より直感的に運用できる方向に進化していますね。
この経験を通じて、私は運用設計の難しさを痛感しました。特に厳しかったのは以下の3点です。
- 生産ラインの稼働状況に応じて動的に変わるジョブの実行タイミング
- 夜間バッチの処理時間が日によって大きく変動する予測困難性
- アラートの閾値設定が適切でないと、誤報と重要アラートの区別がつかなくなる問題
当時はJP1/AJS(Automatic Job Management System)を使ってジョブネットを構築していました。このツール自体は非常に高機能で、複雑なジョブ制御が可能です。しかし、その高機能さゆえに、設定項目が膨大で、運用設計書も分厚くなる一方でした。
ジョブの依存関係が複雑化する理由
食品工場特有の事情として、生産計画の変更が頻繁に発生します。原材料の入荷遅延、機械のトラブル、急な受注変更など、計画通りに進まないことの方が多いんです。
そのため、生産管理システムのバッチ処理も、固定スケジュールで動かすわけにはいきません。前工程のデータが揃ってから次の処理を開始する、という条件分岐が多数必要になります。JP1では「先行ジョブネットの終了を待つ」「ファイルの存在をチェックする」といった待ち合わせ制御を細かく設定できますが、これが増えれば増えるほど、全体の見通しが悪くなります。
私が担当したシステムでは、最終的に約200個のジョブを管理することになりました。これらが時間帯によって異なるパターンで実行され、依存関係は複雑に絡み合っていました。ジョブフロー図を印刷すると、A3用紙10枚以上になり、壁一面に貼り出さないと全体像が把握できない状態でした。
夜間バッチの処理時間が読めない苦しみ
もう一つの大きな問題は、バッチ処理の実行時間が予測しづらいことでした。日中の生産データを夜間にまとめて処理するのですが、その日の生産量によって処理時間が大きく変動します。
通常は2時間で終わる処理が、繁忙期には5時間かかることもありました。そうなると、朝6時に開始予定だった次のジョブが実行できず、出勤してきた現場スタッフが必要なデータを見られない、という事態が発生します。
この問題に対処するため、私たちはジョブの実行時間を毎日記録し、閾値を調整し続けました。しかし、閾値を緩くしすぎると本当に異常が起きたときに気づけず、厳しくしすぎると誤報が増えて運用担当者が疲弊します。このバランス調整に、試行錯誤を重ねました。
アラート設計で陥った罠
運用設計でもう一つ苦労したのが、アラートの設計です。JP1では、ジョブの異常終了やリソース監視の閾値超過時に、メールやポップアップでアラートを通知できます。これ自体は便利な機能なのですが、設定が不適切だと「オオカミ少年」状態になってしまうんですよね。
稼働初期、私たちは「念のため」という考えから、かなり細かくアラートを設定しました。ジョブの警告レベルの終了でも通知、CPU使用率が70%を超えても通知、といった具合です。
結果はどうだったか。運用担当者のもとに、一晩で50件以上のアラートメールが届くようになりました。その大半は、実際には対応不要な軽微なものです。こうなると、本当に重要なアラートが埋もれてしまい、対応が遅れる原因になります。
私たちは運用開始後の1ヶ月間、アラートの内容を毎日レビューし、不要なものは停止、閾値の見直しを繰り返しました。最終的には、夜間の通知を10件以下に抑えることができましたが、そこに至るまでの調整作業は本当に地道で大変でした。
なぜオンプレ運用設計はこれほど複雑になるのか
ここまで、私の実体験を中心に、JP1を使った運用設計の難しさをお伝えしてきました。では、なぜオンプレミス環境でのジョブ管理や監視は、これほどまでに複雑になってしまうのでしょうか。
カスタマイズ自由度の高さが生む複雑性
JP1のような統合運用管理ツールは、非常に高機能です。ジョブスケジューリング、リソース監視、ログ管理、障害対応の自動化など、あらゆる運用業務を一元管理できます。そして、その機能の多くが細かくカスタマイズ可能です。
この「何でもできる」という自由度の高さが、実は諸刃の剣なんです。自由度が高いということは、設計者の判断次第でいくらでも複雑にできてしまうということでもあります。
私が担当したプロジェクトでも、当初は「この機能も使おう」「この制御も入れよう」と、できることを全部やろうとしていました。しかし、機能を追加すればするほど、設定項目は増え、テストケースも増え、結果として運用の負荷が上がっていきました。
ツール習得のハードルとブラックボックス化
もう一つの問題は、JP1のようなエンタープライズ向けツールは、習得するのに時間がかかるということです。マニュアルは数千ページに及び、設定画面も専門用語だらけです。
プロジェクト初期に運用設計を担当したメンバーは、時間をかけて勉強し、何とか設定を完成させます。しかし、そのメンバーが異動したり退職したりすると、後任者は「なぜこの設定になっているのか」を理解するのに苦労します。
設計書はあっても、細かい調整の意図までは書かれていないことが多いんですよね。結果として、運用が属人化し、「触らぬ神に祟りなし」という状態になりがちです。これがブラックボックス化の始まりです。
環境変化への追従の難しさ
システムは生き物です。業務要件が変われば、ジョブの内容も変わります。サーバーのスペックが変われば、監視の閾値も見直す必要があります。
しかし、オンプレミス環境では、こうした変更を加えるたびに、影響範囲を慎重に検証しなければなりません。本番環境での変更は失敗が許されないため、テスト環境で十分に検証してから、という手順を踏みます。この検証作業が、想像以上に時間を取るんです。
結果として、「できれば変更したくない」という保守的な姿勢になりがちです。ビジネス環境の変化スピードが速い現代において、この柔軟性の欠如は大きな問題です。
クラウド時代の運用設計はどう変わるか
さて、ここまでオンプレミス環境での運用設計の難しさを語ってきましたが、クラウド環境ではどう変わるのでしょうか。2017年に私がJP1と格闘していた頃と比べて、2025年現在、運用監視ツールの選択肢は大きく広がっています。
特に注目すべきは、SaaS型の監視ツールの台頭です。Datadog、Mackerel、AWS CloudWatch、Splunkなど、クラウドネイティブな監視サービスが充実してきました。これらのツールは、オンプレミスのツールとは根本的に設計思想が異なります。
コード化された運用設計という発想
クラウド時代の運用設計で最も大きな変化は、「Infrastructure as Code」「Monitoring as Code」という考え方の普及です。設定をGUIでポチポチと入力するのではなく、YAMLやJSONといったテキストファイルで管理します。
これの何が嬉しいかというと、設定がバージョン管理できるようになることです。Gitでコミットしておけば、いつでも過去の状態に戻せますし、変更履歴も明確に残ります。また、コードレビューの対象にできるため、設計の属人化を防げます。
私がJP1で苦労していた「誰がいつどの閾値を変更したのか分からない」という問題は、クラウドツールではかなり解消されるんですよね。
自動スケーリングと動的な閾値調整
クラウド環境では、サーバーのリソースが動的に変化します。負荷が高まれば自動でスケールアウトし、下がればスケールインします。この変化に対応するため、監視ツール側も動的に閾値を調整する機能を持っています。
例えば、Datadogには異常検知機能があり、過去のメトリクスデータから正常範囲を学習し、通常と異なる振る舞いを自動で検知してくれます。私が手動で何度も調整していた閾値設定を、機械学習がある程度カバーしてくれるわけです。
もちろん、完全に任せきりにはできませんが、初期設定の負担は大幅に軽減されます。
可視化の進化とチーム共有
オンプレミスのツールでも、グラフやダッシュボードは作成できました。しかし、クラウド監視ツールの可視化機能は、それとは次元が違います。
リアルタイムで更新されるダッシュボード、ドリルダウンして詳細を確認できるインタラクティブな操作感、SlackやTeamsとの連携によるアラート通知。こうした機能により、チーム全体で状況を共有しやすくなっています。
私がA3用紙10枚に印刷して壁に貼っていたジョブフロー図も、今ならブラウザ上で全員がアクセスできる形で管理できるでしょう。
現代のクラウド監視ツール、それぞれの特徴と使いどころ
ここからは、具体的なツールを見ていきましょう。私がJP1で苦労した経験を踏まえて、現代のクラウド監視ツールがどのように課題を解決してくれるのか、またどんな点に注意すべきかを、実務者の視点で解説します。
Datadog:包括的な監視を一つのプラットフォームで
Datadogは、クラウド監視ツールの代表格と言っていいでしょう。インフラ監視、アプリケーション性能監視(APM)、ログ管理、セキュリティ監視など、あらゆる監視機能が一つのプラットフォームに統合されています。
便利な点:
- AWS、Azure、GCPなど主要クラウドとの連携が非常にスムーズ
- エージェントをインストールするだけで、基本的なメトリクスがすぐに可視化される
- 異常検知機能により、閾値の手動調整を大幅に削減できる
- ダッシュボードのカスタマイズ性が高く、経営層向けから運用担当者向けまで、用途に応じた画面を作成できる
使いこなしの難しさ:
- 機能が豊富すぎて、どこから手を付けていいか迷う(私がJP1で感じたのと似た状況)
- 料金体系が複雑で、使い方によっては想定外のコストがかかることがある
- 日本語ドキュメントは充実しているが、高度な機能は英語情報を参照する必要がある
- 小規模なシステムには過剰スペックで、コストパフォーマンスが合わない場合も
私の経験から言えば、Datadogは中規模以上のシステムで、インフラからアプリケーションまで一元管理したい場合に向いています。初期設定に時間をかけられるチームであれば、その投資に見合う価値は十分にあります。
Mackerel:日本製ならではのシンプルさ
Mackerelは、日本のはてな社が提供する監視サービスです。Datadogと比べると機能は限定的ですが、その分シンプルで使いやすいのが特徴です。
便利な点:
- 日本語のドキュメントとサポートが充実している
- 料金体系がシンプルで、コストの見積もりがしやすい
- 必要最小限の機能に絞られているため、学習コストが低い
- 「サービス」「ロール」という概念で、サーバーをグルーピングして管理できる
使いこなしの難しさ:
- ログ管理やAPMなど、高度な機能は他のツールと併用する必要がある
- カスタムメトリクスの送信には、スクリプトを書く必要がある
- 大規模システムでは、機能不足を感じる場面が出てくる
Mackerelは、中小企業のIT担当者が最初に導入する監視ツールとして最適だと思います。日本語で情報が得られる安心感は、実務上大きなメリットです。私がJP1で格闘していた頃、こういうシンプルなツールがあれば、もっと楽だったろうなと感じますね。
AWS CloudWatch:AWSユーザーならまず検討すべき
AWS CloudWatchは、AWSの標準監視サービスです。EC2、RDS、Lambdaなど、AWSの各サービスと深く統合されています。
便利な点:
- AWSサービスを使っていれば、基本的な監視は自動で始まる
- 追加のエージェントインストール不要で、多くのメトリクスが取得できる
- CloudWatch Logsと組み合わせて、ログベースのアラート設定が可能
- 料金は従量課金で、小規模なら無料枠内で収まることも
使いこなしの難しさ:
- AWS以外の環境の監視には使いづらい(オンプレミスサーバーなど)
- ダッシュボードのカスタマイズ性は、DatadogやMackerelに比べると劣る
- アラート設定がやや複雑で、SNSやLambdaとの連携設定が必要
- メトリクスの保存期間が短く、長期的な傾向分析には別途データ保存が必要
CloudWatchは、「まずは標準機能で始めたい」というAWSユーザーにとって、スタート地点として最適です。ただし、より高度な監視が必要になったら、DatadogやMackerelへの移行を検討することになるでしょう。
Splunk:ログ分析の最高峰、ただし高価
Splunkは、ログ管理と分析に特化したツールとして長年の実績があります。クラウド版のSplunk Cloudも提供されています。
便利な点:
- 膨大なログデータを高速に検索・分析できる
- 機械学習を使った異常検知やパターン分析が強力
- セキュリティ監視(SIEM)としても利用できる
- 豊富なアドオンにより、様々なシステムと連携可能
使いこなしの難しさ:
- 料金が非常に高額で、データ量に応じて急激にコストが増える
- 学習曲線が急で、効果的に使いこなすには専門知識が必要
- インフラ監視としては、他のツールと組み合わせる必要がある
- 小規模システムには完全にオーバースペック
Splunkは、大規模システムでセキュリティやコンプライアンスが重要な場合に選択肢に入ります。ただし、コストと専門性の要求度合いから、中小企業がいきなり導入するのは現実的ではありません。
クラウド監視ツール導入後の現実的なステップ
ツールの機能を理解したところで、実際に導入する際のステップを考えてみましょう。私がJP1で失敗と成功を繰り返した経験から、「こうすればよかった」と思うアプローチをまとめます。
ステップ1:小さく始めて段階的に拡大する
JP1の運用設計で私が最も後悔しているのは、最初から完璧を目指してしまったことです。あらゆるジョブを管理下に置き、全てのリソースを監視し、詳細なアラート設計をしようとしました。
結果として、設定が複雑になりすぎて、トラブル時の切り分けが困難になりました。クラウド監視ツールでも、同じ轍を踏まないことが重要です。
まずは、最も重要なサーバー1〜2台から監視を始めましょう。基本的なメトリクス(CPU、メモリ、ディスク)とアプリケーションログだけを対象にします。この段階では、アラートも最小限に設定します。
1〜2週間運用して、問題なく動いていることを確認したら、次のサーバーを追加します。この繰り返しで、徐々に監視対象を拡大していきます。
ステップ2:アラート疲れを避ける設計
私がJP1で経験した「一晩に50件のアラート」という悲劇を避けるため、アラートの設計には特に注意が必要です。
クラウド監視ツールでは、アラートの優先度を段階的に設定できます。例えば、Datadogでは「Low」「Medium」「High」の3段階があります。Mackerelでも「Warning」「Critical」の区別があります。
実際の運用では、次のような方針が有効です:
- 夜間に通知するのは「Critical」のみ。それ以外は翌朝の確認でOK
- 初期は閾値を緩めに設定し、誤報が起きないことを確認してから厳しくする
- アラートが発生したら、必ず「実際に対応が必要だったか」を記録し、不要だったものは設定を見直す
ステップ3:チーム全体で情報を共有する仕組みを作る
JP1時代、運用設計の詳細を知っているのは私を含めた数名だけでした。これが属人化の原因でした。
クラウド監視ツールでは、ダッシュボードをチーム全員で共有できます。この利点を最大限に活かすために、以下のような仕組みを作ることをお勧めします:
- 毎朝のミーティングで、前日のアラート履歴を全員で確認する
- ダッシュボードを大型モニターに常時表示し、チーム全員が見える状態にする
- アラート対応の手順書をWikiやNotionなどに整備し、誰でもアクセスできるようにする
- 月次でアラートの傾向を振り返り、改善点を議論する場を設ける
こうした情報共有の文化を作ることで、特定の人に依存しない運用体制が構築できます。
ステップ4:定期的に設定を見直す
システムは変化します。ビジネスの成長に伴ってトラフィックが増えれば、監視の閾値も変わります。新しい機能が追加されれば、監視対象も増えます。
クラウド監視ツールは、設定変更が比較的容易です。この利点を活かし、定期的な見直しを習慣化しましょう。例えば、四半期ごとに以下のチェックを行います:
- 過去3ヶ月で発生したアラートを分析し、誤報が多いものは閾値を調整
- 新たに追加されたサーバーやサービスが、適切に監視されているか確認
- ダッシュボードが実際の運用に役立っているか、チームメンバーにヒアリング
- コストが想定内に収まっているか、データ量の傾向をチェック
オンプレからクラウドへ、運用設計思想の転換
最後に、私がJP1で学んだことと、現代のクラウド監視ツールを比較して感じる、根本的な思想の違いについてまとめます。
完璧を目指すより、素早く改善する文化へ
オンプレミス時代の運用設計は、「最初に完璧な設計を作り、その後は極力変更しない」という考え方が主流でした。変更にはリスクが伴い、テスト工数もかかるため、慎重にならざるを得なかったんですよね。
しかし、クラウド時代の運用設計は、「まず動かしてみて、問題があれば素早く改善する」というアジャイルな考え方が合っています。設定はコードで管理され、いつでも元に戻せます。テスト環境も簡単に作れます。
この思想の転換は、実は技術的な問題というより、文化の問題だと私は思います。「失敗してもいいから試してみよう」という雰囲気を、チーム内に醸成することが重要です。
ツールに使われるのではなく、ツールを使う
JP1のような高機能なツールを使っていると、いつの間にか「ツールができることに業務を合わせる」という本末転倒な状況に陥りがちです。私もそうでした。
しかし、本来は逆であるべきです。業務の要件が先にあり、それを実現するためにツールを選び、使いこなすのです。
クラウド監視ツールは、APIが充実しているため、自社の業務に合わせたカスタマイズがしやすくなっています。例えば、SlackのBotと連携させて、自然言語でアラート情報を問い合わせるといったことも可能です。
「このツールでは、この機能しか使えない」ではなく、「この要件を実現するには、どのツールをどう組み合わせるか」という発想で考えましょう。
コストと価値のバランスを常に意識する
オンプレミスのツールは、ライセンスを一度購入すれば、その後のコストは比較的固定的でした。しかし、クラウド監視ツールは従量課金が基本です。使えば使うほど、コストが増えます。
これはデメリットのように聞こえますが、見方を変えれば、必要な分だけ使えばいいということでもあります。小さく始めて、ビジネスの成長に合わせてスケールさせればいいのです。
重要なのは、「このコストに見合う価値が得られているか」を定期的に評価することです。監視ツールの目的は、システムの安定稼働とトラブルの早期発見です。その目的が達成できているなら、コストは正当化されます。
逆に、ほとんど見ないダッシュボードに高額な料金を払っているなら、それは見直すべきです。
まとめ:運用設計は「生き物」として育てるもの
2017年に食品工場のシステムでJP1と格闘していた頃、私は運用設計を「一度作って完成させるもの」だと考えていました。しかし、実際に運用が始まると、想定外のことが次々と起こり、設計を変更し続ける必要がありました。
今振り返ると、運用設計は「生き物」なんですよね。ビジネスの変化、システムの成長、チームメンバーの入れ替わり。あらゆる要因で、最適な運用のあり方は変わっていきます。
クラウド監視ツールは、この「変化への対応」を、オンプレミスツールよりもはるかに容易にしてくれます。設定の変更、環境の複製、チームでの情報共有。すべてがスムーズです。
ただし、ツールが便利になったからといって、運用設計の本質的な難しさが消えるわけではありません。「何を監視すべきか」「どんなアラートが本当に重要か」「チームでどう情報を共有するか」。こうした問いに答えるのは、やはり人間です。
私の経験からのアドバイスは、「完璧を目指さず、小さく始めて改善を続ける」ことです。最初から全てを監視しようとせず、本当に重要なところから始めましょう。アラートも最小限から始めて、運用しながら調整しましょう。
そして、運用設計を一人で抱え込まず、チーム全体で育てていく文化を作りましょう。ダッシュボードを共有し、アラート対応の知見を蓄積し、定期的に振り返る。そうした地道な活動の積み重ねが、安定した運用につながります。
JP1で苦労した日々は、決して無駄ではありませんでした。その経験があるからこそ、今のクラウド監視ツールの便利さを実感できますし、どこに注意すべきかも分かります。オンプレミスとクラウド、両方の良さと難しさを知っていることが、実務者としての強みになると私は信じています。
あなたが今、運用設計で悩んでいるなら、一人で抱え込まないでください。ツールは日々進化しています。過去のやり方に囚われず、新しいアプローチを試してみる価値は十分にあります。そして、この記事が、その一歩を踏み出すきっかけになれば嬉しいです。
コメント