たとえば、社内の端末台帳を開くと、パソコンの機種もスマートフォンの管理番号もきれいに並んでいる。ところが「これは今も使っていますか」と聞かれると、担当者に確認し直すことになる。台帳はあるのに、調べる仕事は残ったままです。
一度まとめた情報を、日々の変化にどう追いつかせるか。端末管理には、業務を仕組み化するときのこの問題がよく表れます。
ここでは、端末管理システムの設計・実装を題材に、Windowsに常駐するエージェントの自動報告と、人が確かめる情報を組み合わせて、台帳を更新し続ける方法を紹介します。端末内のプログラムから、受信するサーバー、管理画面までを一つの仕組みとして考えます。以下の場面や端末名は説明用の架空例です。
Windowsの「サービス」に常駐するエージェントが自動報告する
パソコンの機種やOS、メモリ、ストレージの情報を調べ、管理表へ転記する。この作業は、端末自身が取得できる情報を扱っています。
題材にした仕組みでは、情報収集用のエージェントをWindowsの「サービス」として登録し、バックグラウンドで動かします。 エージェントとは、各端末の中で情報を集め、サーバーへ報告するプログラムです。決めた間隔で自動報告するため、利用者が毎回アプリを開いて送信ボタンを押す操作を業務に組み込む必要がありません。
Windowsサービスは、自動起動を設定すればPCの起動に合わせて動き、利用者のサインイン操作に依存せず実行できます。起動・停止などはWindowsの「サービス」管理画面で扱います。この動作の基本は、MicrosoftのWindowsサービスの解説でも確認できます。
常駐させる目的は、必要な報告を繰り返し実行できるようにすることです。情報の変わり方に合わせて収集・送信間隔を決め、PCやネットワークにかける負荷も調整します。電源が切れている間や通信できない間の扱いは、後述する「報告が届かない端末の確認」につなげます。
端末内のプログラムと、台帳を更新するサーバーをつなぐ
技術的には、C#/.NET製のエージェント、報告を受け付けるAPI、台帳を保存するデータベース、ブラウザーの管理画面という役割分担です。APIは、端末からの報告を受け取るサーバー側の窓口に当たります。
| 役割 | 処理すること |
|---|---|
| Windowsの常駐エージェント | 機種・OS・メモリ・ストレージなどを収集し、端末の識別子とともに報告する |
| 受信APIとデータベース | 識別子で端末を対応付け、台帳の情報を更新する。通常の報告では受信日時と履歴も保存する |
| ブラウザーの管理画面 | 複数の端末を一覧で確認し、情報が古い端末や人の確認が必要な端末を探す |
通信は端末側からサーバーへ開始します。定期報告は「ハートビート」と呼び、題材の仕組みでは、その応答で設定変更やエージェント更新などの指示を受け取る構成も採っています。端末に外部からの接続を待ち受ける専用ポートを設けず、報告の通信を使って管理側の指示を届ける方法です。指示を受け取る時点は、報告の間隔や端末の通信状態によって変わります。
台帳情報の更新、エージェント自身のプログラム更新、WindowsのOS更新は、それぞれ別の処理として扱います。
ただし、端末から取得できる情報だけでは「誰が使うことになっているか」「予備機として保管しているか」まで確定できません。機械から得る情報と、貸出しや返却の際に担当者が更新する情報を決めておく必要があります。
常駐エージェント自身の更新と、止まったときの復旧まで設計する
エージェントを各PCへ入れると、そのプログラムも保守する対象になります。収集項目を増やしたとき、送信先を変えたとき、不具合を直したときに、配布済みの端末へどう反映するか。ここまで含めて導入方法を決めます。
たとえば、初回導入はインストーラーで行い、その後の更新はエージェントが更新用パッケージを取得する構成が考えられます。動いているサービスのファイルを差し替えるため、更新専用の別プロセスに「サービス停止→ファイル差し替え→再起動」を担当させる。これは題材のエージェント設計でも採っている役割分担です。
更新を配っただけでは、各端末で新しい版が動いたかは分かりません。次の報告に含まれるエージェントのバージョンと受信日時を確かめ、更新できた端末、まだ通信していない端末、確認が必要な端末を見分ける設計にします。
導入時には、次のような技術上の条件も詰めます。
- 報告に失敗したとき：送信のタイムアウト、再試行の間隔、エラーを残すログ、次に報告できたかの確認方法を決める。
- サービスが止まったとき：異常終了時の再起動条件と、現地で確認・復旧する手順を用意する。Windowsの復旧設定と、プログラム側の終了処理を合わせて検証する。
- 端末へ入れる権限と通信：サービスを登録する権限、実行時に必要な権限、HTTPSでの送信とAPI認証、社内プロキシなどの通信条件を確認する。
- エージェントを更新するとき：配布物の署名・整合性を確かめる方法、適用する端末の範囲、失敗時に戻す版と手順を決める。
たとえば.NETで実装する場合も、Windowsサービスの復旧設定だけで期待どおりに再起動するとは限りません。例外が起きた際の終了方法まで組み合わせる必要があり、Microsoftの実装例でもこの点が説明されています。少数の端末で停止・通信失敗・更新を試し、報告が再開するところまで確かめます。
スマホには、その場で報告できる入口をつくる
すべての端末を同じ方法で自動収集しようとすると、準備や運用が重くなる場合があります。所在や困りごとを確認したいなら、人が短く報告できる仕組みも選択肢になります。
たとえば、端末に付けたQRコードを、手元のスマートフォンなどで読み取る。その端末の報告画面が開き、「確認済み」「場所変更」「要対応」などを選んで送信する、という流れです。題材のシステムにも、この報告経路があります。
報告画面が端末と結び付いていれば、毎回管理番号を探して入力する手間を省けます。「要対応」なら状況を書き添え、管理する側が確認につなげます。スマホの内部情報を自動で調べる機能とは別に、現物や利用状況を人が確かめた記録を集める方法です。
手動報告を残すなら、報告するタイミングも業務の中に置きます。貸出し・返却のときに行うのか、定期的な所在確認で行うのか。「気付いた人が入力する」だけでは、更新が続くかどうかもその人次第になってしまいます。
同じ台帳で見るために、確認方法と時点を残す
Windows PCの自動収集と、スマホなどについての手動報告。入口が違っても、管理する側が確認する場所をそろえれば、複数の表や報告メッセージを探し回る手間を減らせます。
その際、単に「更新済み」と表示すると、何が確かめられたのか分からなくなります。自動収集で情報を受け取ったことと、人が現物を見たことは、それぞれ分かるようにしておきたいところです。
次の表は、確認方法と時点から次の行動を考えるための架空例です。実際の管理画面を再現したものではありません。
| 端末 | 届いている情報 | 次に確認すること |
|---|---|---|
| PC-A | 今朝、自動収集の情報を受信 | 機種や容量は確認できる。貸出先が変わった場合は担当者の記録も確認する |
| PC-B | 自動収集の最終受信は10日前 | 予備機として保管中か、電源・通信・収集処理に問題があるかを確認する |
| タブレット-C | 今日、担当者が「確認済み」と報告 | 所在確認の記録として扱う。OSなどの詳細が必要なら別途調べる |
| スマホ-D | 昨日、「見当たらない」と報告 | 管理担当者が貸出し・返却の記録と実物の所在を確認する |
PC-Bから情報が来ない理由は、この表だけでは分かりません。電源を切って保管している可能性もあります。何日届かなければ確認するかは、毎日使うPCと予備機で変わります。
また、スマホ-Dには新しい報告が届いていますが、端末が見つかったわけではありません。報告が新しいことと、問題が解決していることは別です。 日時と報告内容を一緒に読み、誰が次に確かめるかを決めます。
これから同様の仕組みを設計するなら、登録日、情報の受信日時、現物を確認した日時の意味も分けておきます。台帳の行を編集しただけで「現物も確認済み」と読める表示になると、また電話で聞き直すことになります。
一覧の先に、確認する担当者を決める
一元管理の価値は、一覧を開いた後の仕事までつながるときに表れます。「要対応」の報告を誰が見るのか。しばらく情報の届かない端末を、どのタイミングで確認するのか。貸出しや返却があったら、誰が台帳を直すのか。
ここが決まっていないと、画面に情報が集まっても、報告する側には「送った後どうなったか」が見えません。新しい報告を受け取ることと、対応を終えることを分け、担当者が結果をどこに残すかも決めておきます。
集める項目も、管理の目的から選びます。所在確認が目的なら管理番号・保管場所・確認結果、入替えの検討なら機種やOSなど、必要な情報は異なります。閲覧や変更ができる担当者を決め、現場には必要な確認を頼める形にします。
記録の更新元や履歴の考え方は、在庫・生産・会計システムをつなぐデータ設計にも共通します。端末管理で特に考えたいのは、日常のどの動作から情報が届くようにするかです。
まず、一つの確認業務で試す
改善計画では、このような仕組みを考えるとき、すでに使っている台帳や管理ツールで足りる部分を確かめることから始めます。既存ツールの設定や報告手順の変更で済むなら、その方法を選べます。自動収集や報告画面を追加するのは、足りない部分が分かってからです。
最初の対象は、たとえば一部署の貸出端末。次の順で、必要な範囲を整理できます。
- 「何が分からず、誰に聞き直しているか」を一つ選ぶ。
- 必要な項目ごとに、自動取得か人の報告か、更新するきっかけを決める。
- 未報告や困りごとが見つかったときの担当者と確認手順を決める。
- 少数の端末で試し、確認にかかった時間、未確認の端末、報告の負担を確かめる。
自動収集する端末が増えても、確認や転記の手間が別の人へ移っただけなら、手順を見直す余地があります。試す段階から、管理する側と報告する側の両方を確かめます。
常駐エージェントから管理画面まで、設計・開発を相談する
改善計画の業務システムの開発・連携では、Windowsサービスとして動く常駐エージェントから、受信API・データベース・管理画面まで、つながった仕組みとして設計・開発する支援を行います。収集する情報や報告の間隔、既存システムとの連携に加え、インストール、エージェントの更新、ログによる調査、復旧の手順まで、対象環境に合わせて対応範囲を決めます。
利用者が報告する画面と管理担当者の確認手順も、技術の構成と一緒に考えます。端末管理を題材にした今回の考え方は、備品の所在確認や日々の点検にも応用を検討できます。
費用は、対象業務の診断、必要な開発・導入、その後の保守・改善に分けて検討します。料金・ご依頼の進め方には、それぞれの参考予算と想定範囲を掲載しています。端末管理の具体的な費用は、対象台数だけでなく、収集する情報、既存ツールとの連携、運用体制を確認して個別にお見積りします。
初回相談は1時間無料です。「台帳はあるけれど、結局担当者に聞き直している」といった場面からお聞かせください。詳しい資料調査や設計は、範囲と費用を合意してから進めます。
本記事は、2026年9月21日時点で確認した端末管理システムの設計・実装をもとに、他の業務でも検討できる考え方を整理したものです。