情シス・社内IT 2026年4月28日

情シスが社内業務システムの停止を全社員より先に把握する仕組み

中堅企業の情シス2名体制で、自社業務システム・SAML SSO・社内Slack・基幹データ連携バッチをMiterlで監視する実例。社員からの問い合わせより先に検知し、ダウンタイムを30%削減した運用を解説します。

社内システム情シス SAML 業務システム Heartbeat

想定するチームと前提条件

従業員400名規模の中堅企業「E社」の情シス部門を想定したシナリオです。情シスの正社員は2名、SaaS（Slack / Salesforce / Workday / Zendesk 等）と自社業務システム（人事・経費精算・社内ポータル）の運用を担当しています。

「社員から問い合わせが来てから初めて気付く」を脱却することが目的でMiterlを導入。1年運用した結果、全社員の業務影響時間が前年比30%削減されました。

情シス特有の3つの監視ニーズ

1. 業務システムの「気付かれない停止」

経費精算システムが落ちていても、月末以外は気付かれにくい。発覚するのは月末月初の駆け込み利用時で、停止から数日〜1週間経過してからになりがちです。

2. SAML SSO / IdP の異常

Okta や Azure AD で SAML設定が壊れると、SSOで連携している全SaaSにログインできなくなります。社員からは「Slackにログインできません」「Salesforceが動きません」と個別に問い合わせが来る前に、IdP側で検知したい。

3. 基幹データ連携バッチの失敗

夜間バッチで人事DBから給与システムへのデータ連携を行っているが、1回失敗すると翌日の業務に影響します。バッチログを見に行くまで気付かないという属人運用を解消する必要がある。

Miterl の「3層構成」社内監視

層1: 業務システムのHTTP監視

社内向けの業務システムは、Miterlの監視拠点（プローブ）から到達できるようにアクセス許可を出す形で監視しています。具体的には Miterl 公開しているプローブIPをファイアウォールでホワイトリスト登録。

システム	監視タイプ	間隔
社内ポータル	HTTP + キーワード（ログイン画面）	5分
経費精算	HTTP（公開ログインURL）	5分
ファイル共有	HTTP（ログイン画面のヘッダー文字列確認）	10分
人事システム	HTTP（社外公開のSSOログイン）	10分

層2: SAML SSO の死活確認

Okta のログイン画面 (https://e-corp.okta.com) に対するキーワード監視を仕込みます。Oktaが落ちている／設定異常の場合、ログイン画面に正常時のキーワード（Sign in to E-Corp）が表示されなくなる、またはエラーHTML が返るため、即座に検知できます。

これに加えて、月1回の自動テストとして社員ID・パスワードを使った疑似ログインバッチも回しており、SAML設定の破損は数分以内に検知できる体制になっています。

層3: 夜間バッチの Heartbeat 監視

人事 → 給与システムの夜間バッチに、成功時のHeartbeat送信を組み込みます。

#!/bin/bash
# /opt/jobs/payroll_sync.sh

set -e
./run_payroll_sync.py
echo "Sync OK at $(date)"

# 成功時のみHeartbeat送信
curl -fsS -m 10 --retry 3 \
  https://miterl.com/heartbeat/$PAYROLL_TOKEN

Miterlは「毎日午前2時までにHeartbeatが来なければDOWN」と設定。失敗時は情シス2名のSlackと、念のため上長のメールにもエスカレーションが飛びます。

通知の出し分け

社員400名へ「障害です」と全員通知してしまうと、却って混乱が広がります。Miterlの Alert Contact 機能を使って通知を出し分けています。

チャンネル	受信内容	受信者
Slack `#it-internal`	全アラート	情シス2名
Slack `#announce-it`	影響範囲が大きいDOWN（全社利用システム）	全社員（情シスが手動投稿の判断）
メール	Critical のみ	情シス上長・CIO

「全社員に流すか」の判断は人間が介在する形にしているため、誤検知で全社チャンネルが荒れる事故は防げています。

夜間メンテナンスのウィンドウ自動設定

毎週日曜深夜の定期メンテナンス時間帯（02:00-04:00）は、cronでメンテナンスWebhookを自動発行することで、監視を抑制しています。

# crontab: 毎週日曜02:00に2時間のメンテ発令
0 2 * * 0 curl -X POST https://miterl.com/api/v1/webhooks/maintenance/$TOKEN/start \
  -d '{"duration_hours": 2, "name": "Sunday maintenance window"}'

この設定で、定期メンテによる誤通知が完全になくなりました。

月次の経営報告

毎月のMiterl稼働率レポートを、CIOへの月次報告に貼り付けて運用しています。

業務システム別の稼働率（経費精算 99.95%、人事システム 99.8% など）
インシデント件数と平均復旧時間
バッチ失敗回数と原因

「経費精算システムが先月99.6%まで落ちました（許容下限99.5%）」という具体的な数字でCIOと会話できるため、システム更改の優先順位が明確になります。