DeNAが達成した端末管理の完全自動化 ─ 稼働率100%と棚卸し業務からの解放

はじめに

こんにちは。DeNA IT本部 IT戦略部 エンプロイーエクスペリエンスグループの秋葉です。

私たちは、DeNAグループ全体で稼働する5,000台超（Windows/Mac含む）のPCやOSの運用・管理を担っています。この膨大な資産をいかに効率的に、かつセキュアに管理し続けるかは、私たちの重要なミッションの1つです。

本記事は、2025年9月に公開した

「5,000台のPC管理を自動化! 稼働率最適化とコスト削減」

の続編であり、完結編となります。

前回の施策により「ほぼ全て」の可視化には成功したものの、どうしても手動対応が残ってしまう「1%の壁」がありました。

今回の最終章では、その壁を突破するために導入した「自動遮断」の仕組みを紹介します。1年以上にわたるプロジェクトの集大成として、ついに悲願の稼働率100%を達成した成果と、究極の端末管理の全貌をお届けします。

前提

本取り組みは前回と同様で以下のような環境で実施しました。

PC環境

OS：Windows / Mac

台数：約5,000台（Windows：約2,500台、Mac：約2,500台）

対象PC

DeNAが貸与する全てのPC

働き方

オフィス／拠点勤務とリモートワークのハイブリッド

資産管理ツール（台帳）

ServiceNow

ソフトウェア稼働率を計測するためのデータ

全PCに共通してインストールされているEDRのチェックイン日時

Windows PCとWindows専用MDMのチェックイン日時

Mac PCとMac専用MDMのチェックイン日時

稼働率99%の先にある「1%の壁」とは

前回の取り組みにより、PC稼働率は88%から約99%まで向上しました。

しかし、残されたわずか1%を埋める作業は、想像以上に泥臭い「モグラ叩き」の連続でした。

この1%には、従来のシステム的な通知だけでは解決できない課題が隠れていました。

「1%」の正体（既存の仕組みでは拾いきれないパターン）

これまではSlackによる自動通知を行ってきましたが、以下の層にはどうしても声が届きませんでした。

チャネルのミスマッチ

外部委託先などでメールの利用を主としており、Slackの通知を見ていない

状況の未把握

長期休暇や勤務状況によっては、通知を受け取れる状態にない

「1%」の正体（遮断に対する「心理的障壁」と「手動ルーティン」）

仕組みとしてはServiceNowのFlowDesignerを活用していましたが、最終的な「遮断」のフェーズには大きな課題がありました。

「遮断」への恐怖心

アカウントや通信を止める行為は、従業員の業務を完全にストップさせる重い決断です。「もし連絡をくれていたのに、見落として止めてしまったら…」という不安から、実行前には必ず担当者の目による入念な最終チェックが必要でした。

終わりのないモグラ叩き

5,000台規模の資産があると、毎日どこかでログ停止から45日を迎える端末が発生します。これまでは、45日経過から翌週までに対応がない場合に「遮断」という条件を入れていたり、特定の曜日を決めて対象端末をまとめて「遮断」していましたが、翌週には新たな対象が出てきます。それをまた警告して手動で「遮断」していく…まさに「モグラ叩き」のような状態でした。

この「人の判断を介したルーティン作業」が残っている限り、管理工数は減らず、稼働率100%の維持も不可能である。そう痛感したことが、今回の「完全自動化」への舵切りのきっかけとなりました。

稼働率100%の定義

「稼働率100%」という言葉は、単なるスローガンではありません。私たちは、物理的な仕組みによってこの数字を担保しています。

稼働率の再定義

直近45日以内に通信実績があるPCを「正常PC」と定義し、使用されているPCに占める正常PCの割合を稼働率としています。

45日としている理由は、EDR製品の仕様上、それ以上の通信がないと管理コンソールから確認できなくなるためです。

今回の完結編における稼働率100%の定義は、以下の通り非常にシンプルです。

指標： 通信ログが45日を超過した端末は、「自動遮断」される。

結論： 理論上、ネットワーク内に「通信ログが45日を超過して放置されている端末」が1台も存在しない状態になる。＝ 稼働率100%が実現される。

これにより、ServiceNow上で「使用中」ステータスとなっている全てのPCが、確実にアクティブであることを保証します。

アーキテクチャの刷新

究極の自動化を実現するために、私たちは「通知フローを強化する」のではなく、仕組みの責任範囲そのものを再設計しました。

従来は、ServiceNowのFlowDesignerを中心としたワークフロー型の実装でした。

通知や条件分岐には十分対応できていましたが

遮断という不可逆なアクション

属性やステータスに応じたきめ細やかな例外処理

データ異常時のフェールセーフ

といった「判断を伴う制御ロジック」を実装するには限界がありました。

＜自動化前のフロー＞

今回の目的は単なる通知強化ではありません。

“人の最終判断” をシステムに委譲することです。

そのため、判定ロジックの中枢をTypeScriptによる外部バッチへ移行しました。

＜自動化後のフロー＞

これにより

判定条件をコードとして明示化

全処理をログとして完全追跡可能に

フェールセーフを多層実装

将来的なロジック拡張にも柔軟に対応

が可能になりました。その結果、自動化は

「人の最終確認を前提とする仕組み」から「人が介入しなくても完結する仕組み」へと進化しました。

ServiceNowは引き続きSingle Source of Truthとして機能し、外部ロジックがそのデータを参照して実行を担います。

自動遮断のロジック

それでは、遮断のロジックをアーキテクチャ図に沿って、それぞれの役割を説明します。

ログ取得と正規化（API / TypeScript）

Windows専用MDM、Mac専用MDM、共通EDRから、チェックイン日時をAPI経由で取得します。

各製品ごとに形式の異なるログを、端末単位で正規化し、「最終通信日時」として統一します。

この段階ではまだ遮断判断は行いません。

あくまで、信頼できる入力データを整える層です。

SSOTへの集約（ServiceNow）

取得・正規化されたログはServiceNowへ集約されます。

ServiceNowは判定ロジックを持たず、Single Source of Truthとして全端末の状態を保持する基盤です。

ここには通信ログに加え、人事情報も連携されています。

長期不在者は通知処理の対象から自動的に除外され、「状況の未把握」による不要なエスカレーションを防いでいます。

後続の通知・遮断処理は、この統合データのみを参照して実行されます。

図：ServiceNowに最終連携日時として値がセットされている

通知処理（TypeScript）

ServiceNowに集約されたデータを基に、45日超過に近づいた端末を抽出します。

30日経過から40日未満：端末利用者へ通信が取れていない旨が通知される

40日経過時から45日未満：遮断日が記載され、通知先に上長も追加される

45日経過時点：遮断された旨が通知される

　　通知は単なるリマインドではありません。遮断までのカウントダウンを明示する「予告」として機能します。

　　Slackとメールの両建てで実行し、チャネル依存を排除しています。

図：社員に通知されるSlackおよびメールの内容

遮断／復旧処理（TypeScript）

45日を超過した端末に対して以下の処理が自動実行されます。

VPNが遮断され社内ネットワークへのアクセスが不可

クライアント証明書が失効し社内Wi-Fiへの接続が不可

IdPのアカウントがサスペンドされ社内リソースへの接続が不可

　　ここに人の最終承認プロセスは存在しません。条件を満たした瞬間にコードが実行されます。

　　復旧は、チェックインが再確認された時点で自動的に行われます。

　　また、強制力を持つ仕組みである以上、フェールセーフも考慮された設計です。

フェールセーフの例：

復旧サポート中の端末や返却予定の端末は、期日付きで遮断対象から一時除外可能

ServiceNowのログに異常（ログが空、未来日など）が検知された場合、遮断処理は自動スキップされてアラートが上がる 等

状態共有と可視化

「遮断予備軍」「遮断された人」「復旧された人」といった各フェーズで、関係者へリアルタイムに通知を行います。

さらにServiceNow上のダッシュボードで、資産の稼働状況を常時可視化しています。

図：ServiceNowのダッシュボードでリアルタイムに資産状況を把握している

成果として得たのは「信じられるデータ」

1年以上にわたるプロジェクトの結果、得られた成果は数字以上の価値がありました。

「今、何台動いているか」が100%見える化

これまでの「台帳上はこうなっているが、実態はおそらくこうだろう」という不安は消え去りました。

稼働率100%を担保したことで、「今現在、社内で実際に使用されているPCの正確な台数」が常に把握できるようになりました。

ライセンス更新の劇的な効率化

使用台数のデータ精度が100%になったことで、ソフトウェアのライセンス更新時の確認作業が非常に楽になりました。

正確な稼働台数に基づき、過不足のない発注が即座にできるようになったことは、コスト管理・運用の両面で大きなメリットです。

棚卸しの消滅

かつては、実態不明な端末の特定や確認作業に1回あたり50時間以上を要していた定期棚卸し業務は、現在は一切実施しておりません。

24時間365日、システムがリアルタイムで資産の所在と正常稼働を確認し続けてくれるため、わざわざ「棚卸し期間」を設ける必要がなくなったのです。

「急がば回れ」の文化醸成

驚くべきことに、自動遮断導入から3ヶ月以上が経過しましたが、実際の遮断実績は10件以内とごくわずかです。

1年以上かけて従業員と向き合い続けたことで、「警告が来たら自分で対応する」という自律的な文化が定着しました。

最後に

本プロジェクトを通じて、真の効率化とは、はじめから「テクノロジーで無理やり解決すること」ではないと実感しました。

1年という長い時間をかけてユーザーと対話し、例外を一つひとつ丁寧に潰していったこと。その積み重ねこそが、強固な自動化を実現する唯一の近道でした。今後はこの「100%」の状態を維持しながら、さらなる端末管理の強化へとステップを進めていきます。