性能問題は「平均」では起きない──ピークの正体を特定する
MESの負荷見積でまず捨てるべきなのは「1日あたりの実績登録件数」という平均値です。1日1万件の登録があるラインでも、それが24時間に均等に散らばることはありません。実務でMESの応答が悪化するのは、決まって次の瞬間です。
- 交替直後・昼休み明け：中断していた実績登録が一斉に入る
- ロット完了の集中時間帯：バッチ系工程で複数釜の完了が重なる
- ERPからの指図一括連携直後：夜間バッチで数百件の指図が流入し、マスタ展開処理が走る
- 月末・期末の帳票出力：大量データの集計・出力が日中の登録処理と重なる
したがってサイジングの基準は「最繁1時間に何が同時に起きるか」です。現場ヒアリングで各工程の登録タイミングを聞き、時間帯別の件数分布を1枚にすると、ピークは平均の5〜10倍に達することが珍しくありません（サオスの導入支援経験にもとづく目安であり、公表された統計ではありません）。この倍率を見込まない構成は、平常時のデモでは快適に動き、稼働初月の月末に破綻します。
負荷を決める4変数──端末数よりトランザクション構造が効く
| 変数 | 見積りの起点 | 見落とされやすい点 |
|---|---|---|
| 同時アクティブ端末数 | ピーク時間帯に操作中の端末数 | 登録直前に画面を開いたまま待機する端末も接続を消費する |
| トランザクション件数 | ピーク1時間の登録・照会件数 | 1回の登録の裏で走る検証処理（資格・期限・照合）の数が製品で大きく違う |
| 1件あたりデータ量 | 実績1件に紐づく明細・パラメータ数 | 個体管理（シリアル単位）はロット単位の数十〜数百倍の行数になる |
| 保持データ量 | オンライン保持期間×日次増分 | 照会・帳票の速度は総データ量に依存して劣化していく |
このうち構成への影響が最も大きいのは3つ目と4つ目、つまりデータの粒度と保持量です。ロット管理から個体（シリアル）管理へ要件を1段階上げると、トランザクション行数は桁で増えます。性能の議論は要件定義の粒度の議論と不可分であり、「とりあえず細かく取っておく」という方針がサーバ費用と応答時間で請求されることになります。何を持ち、何を持たないかの判断はMESが持つべきデータと、持つべきでないデータで扱っています。
また、センサー時系列のような高頻度データをMESの業務DBに入れる設計は、この4変数のすべてを悪化させます。時系列はヒストリアン側に分離するのが原則です。
ボトルネックの実際──CPUよりも、DBのロックと帳票
サイジングというとサーバのCPU・メモリの話になりがちですが、稼働後の性能障害の原因を調べると、ハードウェア能力の不足よりも次の3つが上位に来ます。
1. DBのロック競合。 同一ロット・同一指図への同時更新、採番テーブルの競合、在庫残高の更新集中など、追加ハードウェアでは解決しない構造的な待ち行列です。ピーク時の「遅い」の正体がロック待ちである場合、スケールアップは効果がありません。テスト段階で同時更新を意図的に起こす試験を組む必要があります。
2. 帳票・照会の重いSQL。 全期間を対象にしたトレーサビリティ照会や月次帳票が、日中の登録処理と同じDBを叩く構成では、月末にだけ現場の画面が遅くなります。対策は照会用レプリカの分離、またはアーカイブによるオンラインデータの削減で、これは構成設計の段階で決めておくべき事項です。
3. 外部インターフェースの一括処理。 ERPからの指図一括受信、実績の一括送信が業務時間帯に走ると、その間の応答が劣化します。バッチの時間帯設計と流量制御（1回あたりの件数上限）はMES-ERP連携の設計の論点ですが、性能設計としてもここで決めます。
性能テストは「応答時間の合否」より「限界の位置」を測る
性能テストを「規定の負荷で応答N秒以内なら合格」という合否試験だけで終えるのはもったいない設計です。稼働後の運用で本当に欲しい情報は、どこまで負荷が増えたら破綻するのか、最初に破綻するのはどこかだからです。実務では次の3種類を分けて実施します。
- 負荷テスト：ピーク見積の100%負荷で、要件の応答時間（現場端末の登録操作で1〜2秒以内が目安）を満たすことの確認
- 限界テスト：負荷を150%、200%と上げ、最初に劣化する処理と劣化の仕方（緩やかに遅くなるのか、突然エラーになるのか）を記録する。この記録が、稼働後に負荷が増えたときの増強判断の基準になります
- 長時間テスト：ピーク相当の負荷を数時間かけ続け、メモリリーク・ログ肥大・コネクション枯渇のような時間依存の劣化を検出する
もう一つ、テストと同じくらい重要なのが稼働後の計測の仕込みです。応答時間・DB待ち・IF処理時間を常時記録しておけば、「最近遅い」という現場の体感を数字で検証でき、増強の要否をデータで判断できます。稼働時に計測がないと、性能問題は毎回ゼロからの調査になります。
よくある質問
何年分のデータをオンラインに置くべきですか？
業務照会の実態から決めます。日常業務で参照するのは通常直近数か月〜1年で、それ以前はトレーサビリティ調査など例外的な照会です。オンラインは1〜2年とし、それ以前はアーカイブへ移して照会手順を別に用意する構成が、性能とコストのバランス点になることが多いといえます（サオスの導入支援経験にもとづく目安です）。ただし規制産業では保存義務期間が別に決まるため、アーカイブを含めた保持設計として要件化してください。
性能テストは本番と同じスペックの環境でやるべきですか？
原則は本番同等です。半分のスペックで測って2倍する、という外挿はDBのロック競合やメモリ境界の挙動が非線形なため成立しません。本番同等環境が用意できない場合は、クラウドで一時的に本番相当を構築してテスト期間だけ使うのが現実的です。オンプレミス構成でも、性能テストだけクラウドで行い、結果をハードウェア選定に反映する方法が使えます。
稼働後に遅くなってきました。増強の前に何を確認すべきですか？
まず「いつ・どの操作が・どれだけ遅いか」を特定してください。全操作が常時遅いならリソース不足の可能性が高い一方、特定時間帯・特定操作だけならロック競合か重いSQLが原因で、増強しても解決しません。次にデータ量の推移を確認します。稼働から数年でオンラインデータが当初想定を超えているなら、アーカイブの実施が増強より先です。増強・改修のいずれにしても、保守契約でどこまでがベンダーの対応範囲かが費用を左右します（保守契約で確認すべき8項目参照）。
