工場のシステム監視2026｜検知までの時間が損失を決める

「サーバーが止まったこと」より「止まっていたことに誰も気づかなかった時間」のほうが、工場では高くつきます。タイの日系工場を訪問して障害の話を伺うと、多くの場合、話題は原因に集中します。どの機器が壊れたのか、どの設定が悪かったのか。しかし現場の損失を実際に決めているのは、原因ではなく、異常が起きてから誰かが気づくまでの時間です。この記事では、アユタヤ県の金属部品加工工場をモデルケースに、年間14件の障害を数え、検知までの2.4時間を9分に縮めたときに何THBの効果が出るのかを、正直に計算します。結論を先に申し上げると、検知短縮の効果だけでは監視の費用を回収できません。それでも監視を入れる理由がどこにあるのかまで、順に整理します。

工場のIT障害は「起きたこと」より「気づくのが遅いこと」が損失を生む

障害対応の議論は、たいてい原因究明から始まります。ディスクが壊れた、電源ユニットが逝った、更新プログラムが設定を上書きした。原因が特定できれば再発防止策が立てられるので、この議論には意味があります。ただし、その障害でいくら損したのかという問いに対しては、原因はほとんど答えを持っていません。

損失の大きさを決めているのは、止まっていた時間です。より正確には、止まってから復旧するまでの時間のうち、誰も気づいていなかった部分です。復旧作業そのものにかかる時間は、原因の重さで決まります。ディスク交換なら数時間、設定の戻しなら数十分。ここは技術の話であり、努力で大きく縮めるのは簡単ではありません。一方、気づくまでの時間は、技術ではなく仕組みの話です。仕組みを変えれば、ここだけは大幅に縮みます。

タイの日系工場でよく見かけるのは、障害の発覚が利用者からの申告に依存している状態です。生産管理システムが応答しなくなると、現場の担当者がまず数回リロードを試します。それでも駄目なら隣の人に「そちらは動きますか」と聞きます。何人かで確認して、これは自分の端末の問題ではないらしいと分かった段階で、ようやく管理部門に連絡が入ります。この一連の流れに、平気で1時間から2時間が溶けます。

しかもこの遅れは、夜間や休日にはさらに伸びます。誰も使っていない時間帯に止まったサーバーは、翌朝の始業まで止まったままです。バッチ処理が走る深夜に止まれば、朝になって「昨日のデータが出ていない」という形で発覚します。このとき失われているのは、止まっていた時間そのものではなく、朝いちばんの生産指示が出せないことによる立ち上がりの遅れです。

規模の大きな企業を対象にした調査では、1時間のシステム停止で非常に大きな金額の損失が報告されており、OutageCost.comのCost of IT DowntimeでもITICやUptime Instituteの調査結果が引用されています。ただし、これらは米国を中心とした大企業の数字であり、タイの中規模な日系工場にそのまま当てはめられるものではありません。産業構造も、止まったときに影響を受ける取引の規模も違います。この記事では、これらの調査を「規模が大きい企業ではこの水準の調査結果もある」という文脈情報として参照するにとどめ、モデルケースの試算には一切使いません。自分の工場の損失は、自分の工場の条件から計算する必要があります。

そして、その計算をするために最初に必要なのが、検知までの時間という数字です。この数字を持っていない工場は、監視に投資すべきかどうかを判断する材料を持っていません。

システム監視とは何か — 死活・性能・ログの3種類

システム監視という言葉は、日常会話では便利ですが、設計の場面ではあいまいすぎます。何を見ているかによって、検知できる異常の種類がまったく違うからです。実務では3種類に分けて考えます。

1つ目は死活監視です。 対象の機器やサービスが生きているかどうかだけを見ます。サーバーに一定間隔で通信を送り、返事があるかを確認する。ウェブの画面を定期的に呼び出し、正常な応答が返るかを確認する。仕組みとしては最も単純で、導入も最も容易です。検知できるのは「完全に止まった」状態だけですが、工場の実務でいちばん高くつく障害はまさにこの完全停止なので、費用対効果としては最初に手をつけるべき領域になります。

2つ目は性能監視です。 生きてはいるが遅い、という状態を見ます。CPU使用率、メモリの空き、ディスクの空き容量、ネットワークの帯域、データベースの応答時間。これらを継続的に測り、いつもと違う値になったら知らせます。死活監視と違って、閾値をどこに置くかという設計判断が必要になります。この設計を誤ると、後述するとおり、アラートが鳴りすぎて誰も見なくなるという典型的な失敗に落ちます。

3つ目はログ監視です。 機器やソフトウェアが吐き出す記録の中から、特定のパターンを拾います。認証の失敗が短時間に繰り返されている、ディスクの読み書きエラーが出始めている、バックアップジョブが異常終了している。ログ監視は、まだ止まっていないが止まりかけている状態を捉えられる唯一の手段です。半面、何を拾うかを決めるのがいちばん難しく、対象システムの中身を理解していないと設定できません。

この3つは、検知できるタイミングが違います。ログ監視は予兆の段階、性能監視は劣化の段階、死活監視は停止の段階です。理想は3つとも入れることですが、現実には予算と運用体制の制約があるので、優先順位をつけます。監視をまったく入れていない工場であれば、死活監視から始めるのが定石です。効果が最も分かりやすく、設定が最も軽いからです。

対象の範囲も決めておく必要があります。サーバーだけを見ればよいのか、ネットワーク機器も含めるのか。工場ではネットワーク側の障害が生産に直結することが多く、特に無線APが落ちるとハンディターミナルによる実績入力が一斉に止まります。無線区間は有線に比べて不安定要因が多いため、設計段階から監視を織り込んでおくのが現実的です。工場ネットワークの設計そのものについては工場の無線LAN構築で押さえる設計の勘所で整理していますので、あわせてご覧ください。

「外に出すか」より先に決めることがある — 情シスアウトソーシングとの役割分担

監視の話を切り出すと、多くの場合、最初に出てくる質問は「それは外注できますか」です。タイ拠点の情報システム担当が1名か2名、あるいは兼任という体制はごく普通なので、自然な反応だと思います。

この反応の背景には、採用の難しさもあります。ジェトロの調査によれば、プログラマーなどのIT人材について人材不足が「とても深刻」または「やや深刻」と答えたタイの日系企業は56.7%で、アジア・オセアニア地域全体の58.2%に近い水準にあります。原因としては、生産年齢人口の減少、タイ財閥系やインフラ企業に対する採用競争力の低下、そして大学入試の第二外国語選択で日本語が韓国語に抜かれたことによる日系企業への関心低下が挙げられています。人を増やして夜間まで見張るという解決策が、そもそも取りにくい環境だということです。

ただ、この問いを先に立てると、たいてい話が止まります。外注先に見積もりを依頼すると、必ず「何を監視対象にしますか」「アラートの条件はどうしますか」「一次対応はどちらが行いますか」と聞き返されるからです。そこで答えられずに検討が止まる、という光景を何度も見てきました。委託の可否は、監視の中身が決まっていて初めて判断できる問いなのです。

決まっていないのは委託の可否ではありません。決まっていないのは3つです。何を測るか、どこまでを異常とするか、検知したら誰にどう届けるか。この3つが決まっていれば、自社でやっても外部に委託しても同じ結果が出ます。逆に決まっていなければ、どちらを選んでも同じように失敗します。

したがってこの記事では、委託の可否そのものは扱いません。監視・ヘルプデスク・保守という3つの層をどこまで外に出すか、その投資対効果はどうかという判断については、タイ拠点の情シスアウトソーシングを層で分けて考えるで扱っていますので、体制の話を先に詰めたい方はそちらをご覧ください。本記事はその手前、監視という行為そのものをどう設計するかに絞ります。

なお、外部の監視代行サービスがどういう階層で提供されているかを知っておくと、自社で何を持つかの整理には役立ちます。日本国内の目安として、アスピックのMSPサービス比較では、アラートを通知するだけの層、監視に一次対応まで含める層、原因分析や改善レポートまで含む上位の層という区分が紹介されています。価格帯は日本国内のものなのでタイの相場としては使えませんが、この階層の分け方自体は、自社の役割分担を決めるときの共通言語として使えます。通知だけを受け取って対応は自社でやるのか、一次対応まで任せるのか。この線引きは、監視の設計が終わっていれば自然に決まります。

タイの工場が見落としがちな第4のレイヤー — 電源品質

前節で監視を3種類に分けましたが、タイの工場にはもう1つ、独立したレイヤーとして扱うべき対象があります。電源品質です。

なぜ独立させる必要があるかというと、純粋なIT監視では検知できないからです。死活監視は、機器が落ちてから初めて反応します。電源側で電圧が下がりかけている段階では、サーバーはまだ動いているので、死活監視は何も知らせません。性能監視も同様で、CPU使用率やディスクの空きは電圧とは無関係です。ログ監視でようやく「電源異常でシャットダウンしました」という記録が残りますが、それは事後の記録です。

タイの電力事情には、日本と異なる特徴があります。ビズインフォログの解説によれば、タイでは完全な停電よりも瞬間的な電圧低下、いわゆる瞬断のほうが多く、バンコク都市部でも年に何度も発生します。瞬断は数秒以下で復旧するため、照明はちらついただけ、生産設備は動き続けている、という状況が起こります。しかしサーバーやネットワークスイッチは、この数秒に耐えられずに再起動することがあります。

さらに厄介なのは、瞬断が起きたこと自体が記録に残りにくい点です。工場の誰も「停電した」とは認識していないので、サーバーが再起動していても原因不明として処理されます。原因が分からないまま同じことが繰り返され、そのたびに「またサーバーの調子が悪い」という話になります。実際には機器の問題ではなく、電源側の問題です。

だからこそ、UPS（無停電電源装置）と電源側の監視を、IT監視とは別のレイヤーとして組み込む必要があります。具体的に監視すべきは、UPSが入力電源の異常を検知した回数、バッテリーへの切り替えが発生した時刻、バッテリーの残量と健全性、そして出力の状態です。これらはUPS自体が持っている情報なので、ネットワーク管理カードを装着すれば取り出せます。装着していないUPSは、情報を持っていても外に出せません。この1点だけでも確認する価値があります。

電源品質を第4のレイヤーとして持たない限り、「落ちてから気づく」という構造は変わりません。IT側の監視をどれだけ精緻にしても、原因が電源側にある障害については、常に事後の検知になるからです。

モデルケース｜アユタヤ県の金属部品工場で障害を数える

ここから具体的な数字で見ていきます。以下は独自試算によるモデルケースであり、実在する企業の数値ではありません。金額そのものより、どこにどれだけの時間が失われていて、それをどう金額に置き換えるのかという手順をご覧ください。

前提はこうです。タイ・アユタヤ県にある日系の金属部品加工工場、自動車部品を扱っており、従業員は210名。IT環境は、生産管理システムを載せたオンプレミスのサーバーが1台、ファイルサーバーが1台、そして工場内ネットワークとしてスイッチが8台、無線APが12台という構成です。生産管理システムを日常的に使う利用者は48名で、受注情報の確認、作業指示の発行、実績の入力、出荷指示の作成をこのシステムで行っています。

監視は導入していません。障害に気づくのは、利用者から「システムが開かない」という連絡が入ったときです。タイの日系加工工場としては、ごく標準的な状態だと思います。

この工場で1年間に発生した障害を、原因別に数えたのが次の表です。

年間14件、月に1件強という頻度です。この数字を見て「思ったより多い」と感じる方と、「そんなものだ」と感じる方に分かれます。分かれる理由は、そもそも数えていないからです。数えていない工場では、記憶に残っている大きな障害だけが件数として認識され、30分で復旧した小さな停止は数のうちに入りません。

この表で注目すべきは、原因の内訳です。ソフトや機器に起因する障害が6件であるのに対し、電源品質に起因する障害は8件あります。全14件のうち電源起因が占める割合は、8を14で割って約57%です。半分以上が電源側に原因を持っているにもかかわらず、監視の議論をするときに電源が話題に上ることはめったにありません。

季節の偏りも明確です。全14件のうち雨季に9件、乾季に5件が発生しています。この偏りがどこから来ているかは、原因別に見ると分かります。ソフト・機器起因の6件は雨季3件・乾季3件で、ちょうど50%ずつに分かれており、季節性がありません。一方、電源品質起因の8件は雨季6件・乾季2件で、雨季の比率は75%です。季節の偏りは、ほぼすべて電源側から来ています。

障害はなぜ雨季に集中するのか — 瞬断とUPSバッテリー劣化

雨季に電源起因の障害が集中する理由は、天候そのものにあります。タイ自由ランドが紹介しているPCサポートタイランドの解説によれば、タイでは雨季にあたる5月から10月にかけてスコールや雷雨による停電・瞬断が頻発し、サーバーやネットワーク機器の故障リスクが高まります。落雷そのものによる直撃被害よりも、送電網側で発生する瞬間的な電圧変動のほうが、件数としてははるかに多くなります。

工場側から見ると、この現象は非常に分かりにくい形で現れます。スコールが来た日の午後にサーバーが再起動していた、という事実は残りますが、そのとき電圧がどうなっていたかの記録はどこにもありません。翌日、担当者は「昨日サーバーが落ちていました」と報告し、管理者は「原因を調べてください」と指示します。しかし調べようがないのです。記録がないものは調べられません。

ここで重要になるのがUPSです。UPSは瞬断のあいだ電力を供給し続けるので、正しく機能していれば機器は落ちません。ただし、この「正しく機能していれば」に条件がつきます。内蔵バッテリーが劣化していないこと、そして容量が実際の負荷に対して足りていることです。

同じ解説では、UPSの設置が推奨されると同時に、タイの室温環境ではバッテリーの劣化が早く進むことが指摘されています。一般に、室温が30℃前後で推移する環境では、UPS内蔵バッテリーは1年程度で劣化が進みやすく、年に1回の点検・交換確認を習慣にすることが目安とされています。日本の感覚で「バッテリーは数年もつもの」と考えていると、いざ瞬断が来たときに、UPSがあるのに機器が落ちるという事態になります。

そして、劣化したバッテリーは静かに劣化します。UPS本体のランプは点いており、通電もしています。実際にバッテリー運転に切り替わったときだけ、容量不足が露呈します。つまり、UPSがあるという事実そのものは、瞬断に耐えられることをまったく保証しません。バッテリーの健全性を監視対象に含めて初めて、UPSは投資として機能します。

モデルケースの工場でも、UPSは設置されていました。設置してあるから大丈夫だという認識のまま数年が経過し、雨季の瞬断でサーバーが落ちる事象が続いていた、というのが電源起因8件の背景です。機器を買っていなかったのではなく、買った機器の状態を見ていなかった、という構図になります。

検知までになぜ2.4時間もかかっていたのか

この工場で、障害が発生してから管理部門がそれを認識するまでの時間は、平均で2.4時間でした。なぜこれほどかかるのかを分解すると、いくつかの段階が見えてきます。

最初の段階は、利用者が異常だと判断するまでの時間です。生産管理システムの画面が開かないとき、利用者はまず自分の操作か端末の問題を疑います。再起動を試し、別のブラウザで開き、それでも駄目なら席を立って隣の人に確認します。この段階だけで数十分が過ぎます。特に、システムを常時使っているわけではない利用者の場合、次にシステムを開こうとした時点で初めて気づくので、実際の障害発生時刻からのずれはさらに大きくなります。

次の段階は、報告の経路です。多くの工場では、システムの不具合はまず現場のリーダーに伝えられ、リーダーが管理部門に連絡します。リーダーが会議中であれば、その分だけ遅れます。連絡手段がチャットであれば比較的速いのですが、口頭や電話に依存していると、相手が不在の場合に待ちが発生します。

三番目の段階は、時間帯です。48名の利用者が全員同じ時間に働いているわけではありません。昼休みに止まれば、気づかれるのは昼休みが明けてからです。夜勤帯にファイルサーバーが止まれば、翌朝まで誰も触りません。これらの「誰も使っていない時間」に発生した障害が平均値を大きく押し上げます。平均2.4時間という数字は、10分で気づいた事例と、8時間気づかれなかった事例が混ざった結果です。

そして四番目、これがいちばん見落とされやすいのですが、「気づいたが報告されない」という状態があります。現場の担当者が、システムが使えないので紙に書いて後で入力しよう、と判断してそのまま作業を続けるケースです。本人の中では問題は回避されているので、報告する動機がありません。この回避が上手な現場ほど、障害は表に出てきません。表に出てこないので対策も打たれず、同じことが繰り返されます。

この4つの段階を眺めると、共通点があります。いずれも人の判断と人の連絡に依存しているという点です。人を教育して速くすることも理屈のうえでは可能ですが、夜勤帯に誰も使っていないサーバーの停止を人が検知することは、原理的にできません。ここが、監視という仕組みが必要になる本質的な理由です。

監視を入れると検知時間はどこまで縮むか

死活監視と閾値アラートを導入した場合、検知までの時間は平均9分、時間に直すと0.15時間まで縮みます。この9分という数字の内訳も、はっきりしています。

監視システムは、対象に対して一定の間隔で応答を確認します。この間隔を短くすれば検知は速くなりますが、監視対象への負荷と通信量が増えます。実務では、数分に1回程度の確認間隔に設定することが多く、加えて1回の失敗で即座にアラートを出すのではなく、連続して数回失敗したら異常と判断する設定にします。1回の失敗で鳴らすと、通信の一時的な揺らぎで誤検知が頻発するからです。この確認間隔と連続失敗回数の積が、検知までの遅れの主要部分になります。

そこにアラートの配信時間が加わります。異常と判断してからメールやチャットに通知が届くまでの数十秒です。合計すると、平均9分という水準に落ち着きます。

1件あたりの短縮時間は、2.4時間から0.15時間を引いて2.25時間です。短縮率で見ると、2.25を2.4で割って約94%になります。つまり、気づくまでの時間の9割以上が消えるということです。この短縮幅の大きさは、元の状態が申告依存だったことの裏返しでもあります。すでに何らかの監視を入れている工場が同じ施策を打っても、ここまでの効果は出ません。

注意しておきたいのは、監視が縮めるのは検知までの時間だけだという点です。検知してから復旧するまでの時間は、監視では縮みません。ディスクが壊れていれば交換に要する時間は変わらず、設定の戻しに30分かかるならその30分も変わりません。監視を入れれば障害の総復旧時間が短くなる、と説明されることがありますが、正確には「検知までの部分だけが短くなる」であり、この区別をあいまいにすると、後で効果が出ていないという評価になります。

また、夜間・休日に検知したアラートを誰が受けるのかが決まっていなければ、検知が速くなっても対応は始まりません。深夜2時に通知が飛んで、誰も見ないまま朝を迎えるのであれば、実質的な検知時間は申告依存と変わりません。この点は監視設計の3番目の軸、通知ルートの問題として後述します。

検知時間短縮1時間の価値をどう見積もるか

検知が速くなることの価値を金額にするには、「気づかれずに止まっている1時間」がいくらの損失を生むかを決める必要があります。ここは工場ごとに大きく異なる部分なので、モデルケースの条件を明示したうえで積み上げます。繰り返しますが独自試算です。

前提として、生産管理システムが止まっても、現場の作業がただちに全停止するわけではありません。この工場では、作業指示書がすでに手元にある工程は、そのまま加工を続けられます。実績の記入も紙で代用できます。おおむね30分は紙運用で持ちこたえられる、というのが現場の感覚です。

問題はその先です。30分を超えると、出荷トラックへの積込指示が出せなくなります。出荷指示はシステムから出力する運用になっているため、システムが止まると、どの製品を何箱積むのかが確定しません。結果として、着車したトラックが構内で待機します。この待機は、運送会社との契約上、待機料として実費が発生します。

もう1つが、対応にあたる要員の時間です。障害が起きると、情報システム担当と製造管理の担当が本来の業務を離れて対応にあたります。時間外に発生した場合は、そのまま時間外対応になります。

この2つを単価と数量に分けて積み上げたのが、次の表です。

出荷トラックの待機コストは1台あたり800 THB/時、影響を受ける台数は平均で1.2台と置きました。掛け合わせて960 THB/時です。対応要員は2名、時間単価350 THBで700 THB/時。合計すると、気づかれずに止まっている1時間あたり1,660 THBという数字になります。

この積み上げ方には、意図的に含めていないものがあります。生産そのものが止まることによる機会損失です。前述のとおり、この工場では紙運用で一定時間は生産を継続できるため、短時間の停止では生産数量に影響が出ません。長時間の停止では当然影響が出ますが、その確率と規模を仮定し始めると、試算全体が仮定の積み重ねになってしまいます。ここでは、確実に発生する費用だけを積み上げています。控えめな数字である、という点をご了承ください。

独自試算｜検知短縮の年間効果と監視費用を並べる

材料がそろったので、年間の効果を計算します。

年間の障害件数は14件、1件あたりの検知短縮時間は2.25時間なので、年間で短縮される時間の合計は14に2.25を掛けて31.5時間です。この31.5時間に、1時間あたりの未検知コスト1,660 THBを掛けると、年間の削減額は52,290 THBとなります。

一方、監視を導入する費用です。初期費用として、監視サーバーまたはクラウドサービスの構築、各機器へのエージェント導入、UPSのネットワーク管理カード設定、ダッシュボードの作成、通知ルートの設定を含めて180,000 THB。月額の監視サービス費用として、死活監視とアラート通知を含めて28,000 THB/月。年間では28,000に12を掛けて336,000 THBです。

両者を並べると、次のようになります。

年間効果52,290 THBを年間サービス費用336,000 THBで割ると、15.6%です。初期費用の180,000 THBを勘定に入れる以前に、月々の費用すら賄えていません。

この結果は、意図的にこのまま出しています。数字を良く見せようと思えば方法はいくつもあります。未検知コストの単価を上げる、生産停止による機会損失を織り込む、障害件数を多めに見積もる。しかしそれをやると、試算は説得の道具にはなっても、判断の材料ではなくなります。

正直に読めば、この試算が言っているのは1つです。検知時間の短縮という効果だけを金額化しても、監視の費用は回収できない。 監視を導入すべきかどうかの判断は、この事実を前提に組み立てる必要があります。

検知短縮だけでは投資回収しない — もう一つの効果を金額化しない理由

では、監視には投資する価値がないのかというと、そうではありません。金額化していない効果が残っているからです。それは、重大化を防ぐ効果です。

小さな異常は、放置されると大きな停止に育ちます。ディスクの空き容量が減り続けている状態は、それ自体では何も止めませんが、ゼロになった瞬間にデータベースが停止します。RAIDのディスクが1本壊れた状態は、冗長性が失われているだけで動作は続きますが、2本目が壊れれば全損です。UPSのバッテリーが劣化している状態も同じで、次の瞬断まで何も起きません。バックアップジョブが失敗し続けている状態に至っては、障害が起きるまで誰も困らないうえに、障害が起きた瞬間に取り返しがつかなくなります。

性能監視とログ監視は、これらの「まだ止まっていないが、止まる方向に進んでいる」状態を捉えます。捉えて手を打てば、大きな停止そのものが発生しません。発生しなかった障害の損失は、当然ながら発生していないので、記録にも残りません。

この効果を金額化しようとすると、必ず確率の仮定が必要になります。ディスク空き容量の枯渇が年に何回起きるはずだったのか。RAIDの2本目が壊れる確率はどれだけか。バックアップが必要になる事態が何年に1回発生するのか。どの数字も、根拠を持って置くことができません。置けば試算の桁が変わりますが、変わった桁に意味がありません。

したがって本記事では、重大化防止の効果は金額化しません。 これは効果が小さいという意味ではなく、誠実に見積もれないという意味です。金額化できないものを金額化すると、投資判断の全体が信用を失います。

実務上の扱い方としては、2つに分けて説明することをおすすめしています。1つは、検知短縮の効果として金額で示せる部分。モデルケースでは年間52,290 THBです。もう1つは、金額化せずに、防ぎたい事象を具体的に列挙する部分。データベースが停止して1日分の実績が入力できない状態、バックアップが取れていないことに気づかないままサーバーが故障する状態、雨季の瞬断でUPSが持ちこたえられずに生産管理システムが落ちる状態。稟議では、この列挙のほうが実際には効きます。金額で15.6%と示されるより、起きたら困ることが具体的に並んでいるほうが、判断する側にとって意味があるからです。

なお、バックアップが取れているかどうかの監視は、監視設計の中でも優先度が高い項目です。バックアップの設計そのものについては業務システムのバックアップ体制と復旧の考え方で詳しく扱っていますので、監視対象の洗い出しと併せてご確認ください。

監視設計の3つの軸 — 何を・どこまで・誰に

ここまでの内容を、設計の言葉に置き換えます。監視の設計で決めるべきことは3つです。

第1の軸は、何を測るかです。 対象の一覧を作ります。サーバー、ネットワーク機器、無線AP、UPS、そして各サーバー上で動いているサービス。ここで陥りやすいのが、機器の一覧で満足してしまうことです。サーバーが生きていても、その上で動いている生産管理システムのサービスが停止していれば、利用者にとっては止まっているのと同じです。測る対象は、機器ではなく、利用者が使っている機能の単位で定義してください。「生産管理システムのログイン画面が正常に応答すること」という定義であれば、途中のどこが壊れても検知できます。

第2の軸は、どこまでを異常とするかです。 閾値の設計です。死活監視であれば、何回連続で応答がなければ異常とするか。性能監視であれば、CPU使用率が何%を何分間超えたら異常とするか、ディスクの空きが何%を下回ったら異常とするか。この設計は、監視を入れてすぐには決まりません。平常時の値を一定期間にわたって計測し、そのばらつきを知ってからでないと、意味のある線が引けないからです。導入初期は緩めに設定し、データが溜まってから絞る、という順序が実務的です。

第3の軸は、検知後どこに届けるかです。 通知ルートの設計です。ここが最も軽視されており、そして最も失敗が多い部分です。決めるべきことは、平日日中の宛先、夜間・休日の宛先、そして誰も反応しなかった場合の二次的な宛先。加えて、重要度による振り分けです。すべてのアラートを全員に送ると、重要な通知が埋もれます。生産管理システムの停止は即座に電話が鳴るべきですが、ディスク空き容量の警告は翌営業日でかまいません。

この3つの軸は、どれか1つでも欠けると監視が機能しません。対象を決めずに導入すれば見落としが出ます。閾値を決めずに導入すればアラートが鳴りすぎます。通知ルートを決めずに導入すれば、検知しても誰も動きません。そして、この3つはいずれも、監視サービスを外部に委託するかどうかとは独立に決められる事項です。冒頭で「外に出すかより先に決めることがある」と書いたのは、この意味です。

決め方の順序としては、第1の軸から始めてください。対象が決まらなければ閾値も決まらず、閾値が決まらなければ通知の重要度も決まりません。逆に、対象さえ決まっていれば、残りは対象ごとに順に埋めていく作業になります。

閾値設計で失敗する典型パターン

閾値の設計は、監視プロジェクトが実質的に失敗する最大の分岐点です。よく見る失敗を挙げます。

厳しすぎる閾値を最初から設定してしまう。 CPU使用率が高い水準を超えたらアラート、という設定を導入初日から入れると、バッチ処理が走る時間帯に毎晩アラートが鳴ります。正常な動作なのにアラートが出る状態が続くと、担当者は数日で通知を無視するようになります。無視が習慣になると、本当の異常が来ても気づきません。監視を入れたのに検知できない、という最悪の状態です。

緩すぎる閾値で妥協してしまう。 上記の反動で、アラートが鳴らないところまで閾値を緩めるケースです。ディスクの空きが1%を切ったら通知、という設定にすれば確かに静かになりますが、通知が来た時点で対処する時間がありません。閾値の目的は、対処できるうちに知らせることであり、限界を知らせることではありません。

平常時のデータを取らずに閾値を決める。 一般的な推奨値をそのまま採用してしまうパターンです。工場ごとに負荷の形は違います。日中に張り付く工場もあれば、夜間のバッチが最も重い工場もあります。自社の平常時がどうなっているかを知らずに引いた線は、根拠のない線です。導入から一定期間はデータ収集に充て、実際の変動幅を見てから閾値を確定してください。

アラートの重要度を分けない。 すべての通知が同じ経路で同じ形式で届くと、受け取る側は選別できません。即座に対応が必要なもの、当日中に確認すればよいもの、週次でまとめて見ればよいもの。この3段階程度に分けるだけで、通知の実効性は大きく変わります。

一度決めた閾値を見直さない。 設備が増え、利用者が増え、データ量が増えれば、平常時の値も動きます。導入時の閾値をそのまま使い続けると、数年後には実態と合わなくなります。年に1回程度は、直近の実測値を見て閾値を確認する時間を取ってください。

これらの失敗に共通しているのは、閾値を技術的な設定値だと考えている点です。実際には、閾値は「誰がいつ動くか」を決める運用のルールです。動ける体制がないところに厳しい閾値を置いても、アラートが積み上がるだけです。閾値の設計は、対応できる人の数と時間帯に合わせて決めてください。

監視ログとPDPA — 保存期間とアクセス権限

監視を導入すると、副産物としてログが蓄積します。誰がいつログインしたか、どの端末からどのシステムにアクセスしたか、どの操作でエラーが出たか。これらは障害対応には有用ですが、扱いには注意が必要です。

タイの個人データ保護法（PDPA）は2022年6月1日に全面施行されています。KPMGの解説によれば、対象となる事業者には個人データ処理の記録を作成する義務があり、リスクの高い取扱いを行う場合にはDPO（データ保護責任者）の設置義務も生じます。データ主体の行動の監視に関連するデータの取扱いも、規制の対象になりうると整理されています。

ここで誤解を避けたいのは、監視ログが必ず個人情報に該当する、という話ではないという点です。サーバーの応答時間やCPU使用率は個人と結びつきません。一方、利用者IDを含むアクセスログは、個人を特定できる情報と結びつく可能性があります。該当するかどうかはログの内容次第であり、一律の答えはありません。実際の判断は、自社が取得しているログの項目を並べたうえで、専門家に確認してください。

罰則の水準は決して軽くありません。One Asia Lawyersの解説では、違反時に最大5,000,000 THBの行政罰金、最大1,000,000 THBの刑事罰金が科されうることが示されています。監視の導入は情報システムの都合で進みがちですが、ログの取扱いは法務の論点でもある、という認識を関係者で共有しておく必要があります。

実務として最低限決めておきたいのは3点です。1点目は保存期間です。何のために保存するのかを決め、その目的に必要な期間を設定し、期間を過ぎたものは削除する運用にします。「念のため無期限」は、目的が定義されていないという意味で最も危険な設定です。2点目はアクセス権限です。監視ダッシュボードに誰がアクセスできるのかを明示し、個人が特定できる情報を含む画面については閲覧できる範囲を絞ります。3点目は取得項目の見直しです。障害対応に必要のない項目まで取得していないかを、導入時と定期見直しの両方で確認します。取得しなければ管理する必要もありません。

監視の設計段階でこの3点を決めておくと、後から追加の作業が発生しません。逆に、動き始めてからログの扱いを整理しようとすると、すでに蓄積したデータの扱いという厄介な問題が加わります。

導入の進め方｜4ステップ

最後に、実際に監視を導入する手順を整理します。

第1ステップは、対象の棚卸しです。 工場内にあるサーバー、ネットワーク機器、無線AP、UPSを一覧にします。この作業を実際にやってみると、多くの工場で「誰も存在を把握していなかった機器」が見つかります。増設時に追加されたスイッチ、以前のプロジェクトで設置されたまま残っているサーバー、担当者が個人的に設置した無線AP。監視の対象にするかどうか以前に、まず何があるのかを確定させます。ここに時間をかける価値は十分にあります。

第2ステップは、利用者から見た機能単位での定義です。 機器の一覧ができたら、それを利用者の視点に翻訳します。生産管理システムが使えること、ファイルサーバーの共有フォルダが開けること、無線が通じること。この単位で「正常とは何か」を文章で定義してください。定義があいまいなまま監視設定に進むと、機器は緑なのに利用者は使えない、という状態を検知できません。

第3ステップは、死活監視と電源監視の導入です。 ここで初めて機器を触ります。優先すべきは死活監視と、UPS・電源側の監視です。モデルケースで見たとおり、障害の約57%は電源起因なので、電源側を見ないまま死活監視だけを入れると、原因不明の再起動が引き続き発生します。UPSにネットワーク管理カードが入っていない場合は、この段階で追加します。性能監視とログ監視は、この後で構いません。

第4ステップは、閾値と通知ルートの確定です。 第3ステップから一定期間データを集め、平常時の変動幅が見えてから閾値を引きます。同時に、平日日中・夜間休日・二次連絡先という通知ルートを決め、重要度の振り分けを設定します。そして必ず、テスト用の異常を意図的に起こして、通知が届くことを確認してください。届かない通知ルートを設定したまま運用している例は、驚くほど多くあります。

4つのステップのうち、第1と第2は設計、第3と第4は構築と運用です。そして効果が出るのは第4に到達してからです。第3で止まっている工場、つまり監視ツールは入っているがアラートが誰にも届いていない工場は、投資だけして効果を得ていない状態になります。導入計画を立てる段階で、第4ステップまでを1つのプロジェクトとして扱ってください。

よくある質問

工場のシステム監視は何から始めればいいですか？

死活監視と電源側の監視から始めてください。死活監視は設定が最も単純で、完全停止という最も損失の大きい障害を捉えられます。電源側は、タイの工場に固有の事情として優先度が高くなります。モデルケースでは年間14件の障害のうち8件、割合にして約57%が電源品質に起因していました。性能監視とログ監視は有用ですが、閾値の設計に平常時のデータが必要なので、死活監視を先に入れてデータを集めながら準備するのが現実的な順序です。なお、監視ツールの選定より先に、監視対象の棚卸しと「正常とは何か」の定義を済ませてください。

監視を導入すると障害はどれくらい早く見つかりますか？

モデルケースの試算では、利用者からの申告に依存していた状態の平均2.4時間が、死活監視と閾値アラートの導入によって平均9分、時間に直すと0.15時間まで縮みました。1件あたり2.25時間の短縮で、短縮率は約94%です。ただし、監視が縮めるのは検知までの時間だけであり、検知してから復旧するまでの時間は変わりません。また、夜間や休日に通知を受ける宛先が決まっていなければ、検知が速くなっても対応の開始は早まりません。効果を出すには、通知ルートの設計まで含めて導入する必要があります。

監視の費用は検知時間の短縮だけで回収できますか？

モデルケースでは回収できません。年間の検知短縮時間は14件×2.25時間で31.5時間、1時間あたりの未検知コスト1,660 THBを掛けると年間52,290 THBの効果になります。一方、監視サービスの年間費用は28,000 THB/月の12か月分で336,000 THB、これに初期費用180,000 THBが加わります。効果を年間サービス費用で割ると15.6%にとどまります。監視の価値は、小さな異常が大きな停止に育つ前に止める効果のほうにありますが、この効果は発生確率の仮定に依存するため、本記事では意図的に金額化していません。

UPSがあれば電源起因の障害は防げますか？

UPSがあることと、瞬断に耐えられることは別です。タイの室温環境ではUPS内蔵バッテリーの劣化が早く進みやすく、一般に1年程度で劣化が進むため、年1回の点検・交換確認が目安とされています。劣化したバッテリーは平常時には何の兆候も示さず、実際に瞬断が来てバッテリー運転に切り替わったときに初めて容量不足が露呈します。したがって、UPSを設置しているかどうかではなく、バッテリーの健全性と切替回数を監視対象に含めているかどうかが分かれ目になります。ネットワーク管理カードが装着されていないUPSは、情報を持っていても外に出せません。

監視ログの保存でPDPA上の注意点はありますか？

タイのPDPAは2022年6月1日に全面施行されており、データ主体の行動の監視に関連するデータの取扱いも規制の対象になりうるとされています。ただし、監視ログが必ず個人情報に該当すると断定することはできません。CPU使用率や応答時間は個人と結びつきませんが、利用者IDを含むアクセスログは結びつく可能性があります。実務としては、保存期間を目的から決めて期限後は削除すること、ダッシュボードのアクセス権限を絞ること、障害対応に不要な項目を取得しないことの3点を導入時に決めてください。個別の判断は専門家にご確認ください。

まとめ

要点を整理します。

工場のIT障害で損失を決めているのは、原因ではなく、気づくまでの時間です。復旧作業に要する時間は技術の制約を受けますが、検知までの時間は仕組みで縮められます。利用者からの申告に依存している限り、夜間や休日の停止は原理的に検知できません。

システム監視は、死活・性能・ログの3種類に分かれ、それぞれ捉えられる段階が違います。そしてタイの工場には、この3つと独立した第4のレイヤーとして電源品質があります。瞬断は死活監視では検知できず、UPSのバッテリー健全性を見ていなければ、UPSがあること自体は瞬断への耐性を保証しません。

モデルケースの試算では、アユタヤ県の金属部品加工工場で年間14件の障害が発生し、うち8件、約57%が電源品質に起因していました。季節では雨季に9件、乾季に5件と偏っており、この偏りはほぼ電源起因から来ています。検知までの時間は平均2.4時間で、死活監視と閾値アラートを入れると平均9分、0.15時間まで縮み、1件あたり2.25時間、率にして約94%の短縮になります。年間の短縮時間は31.5時間、1時間あたりの未検知コスト1,660 THBを掛けて、年間52,290 THBの効果です。

一方、監視の費用は初期180,000 THB、月額28,000 THBで年間336,000 THBです。効果を年間サービス費用で割ると15.6%にとどまり、検知短縮の効果だけでは投資回収しません。この数字を良く見せることは可能ですが、そうすると判断の材料ではなくなるので、そのまま出しています。監視の本当の価値は、小さな異常が大きな停止に育つ前に止める効果のほうにあります。ただしこの効果は発生確率の仮定に依存するため、本記事では金額化していません。これは独自試算であり実在企業の数値ではありませんので、金額そのものではなく、どう積み上げてどこまでを効果と呼ぶかという考え方をご覧ください。

設計で決めるべきことは3つです。何を測るか、どこまでを異常とするか、検知後どこに届けるか。この3つは、監視を外部に委託するかどうかとは独立に決められます。委託の可否を先に議論しても前に進まないのは、この3つが決まっていないからです。

進め方は、対象の棚卸し、利用者から見た機能単位の定義、死活監視と電源監視の導入、閾値と通知ルートの確定という4ステップです。監視ツールが入っているだけで通知が誰にも届いていない状態は、投資だけして効果を得ていない状態です。最後に必ず、意図的に異常を起こして通知が届くことを確認してください。

まずは、直近1年間に自社で何件の障害があり、それぞれ何時間気づかれなかったかを書き出してみてください。件数と時間が並んだ時点で、監視に投資すべきかどうかの判断材料の半分は揃います。

何を監視すべきかがまだ決まっていない、という段階でも構いません。TOMAS TECHはタイの日系工場向けにIT基盤の設計と運用を手がけており、監視対象の棚卸しと「正常とは何か」の定義を一緒に整理するところからのご相談も承っています。導入を前提としないご相談も歓迎ですので、まず自社の障害を数字にしたいという方はお問い合わせからお声がけください。

参考情報

• ジェトロ — 人材不足の現状と対応、今後の最低賃金の動向にも注目 タイ、タイ日系企業のIT人材不足に関する調査
• アスピック — MSPサービスの比較12選 提供内容やメリットは、監視代行サービスの階層構造
• OutageCost.com — Cost of IT Downtime、大企業を対象としたダウンタイム損失の調査
• ビズインフォログ — バンコク都市部でも要注意 タイでは停電よりも瞬断が多い、タイにおける瞬断の頻度
• タイ自由ランド — PCサポートタイランドのコラム第254回は停電対策について、雨季の停電・瞬断とUPSバッテリーの劣化
• KPMG — タイ国 個人データ保護法 PDPA 対応支援、PDPAの対応義務とDPO設置
• One Asia Lawyers — タイにおける個人情報保護法 PDPA の執行事例、PDPA違反時の罰則と執行