IT資産管理でいうエージェントは、管理対象の端末などに導入し、機器やソフトウェアの情報を収集・報告するプログラムです。導入方式を考える際は、「インストールが必要か」だけでなく、どこから何を観測し、いつ管理側へ届くかを確認します。
情報が届いていないことと、機器が存在しないことは別です。この記事では、エージェント方式とエージェントレス方式の違い、対象に合う方式の考え方、未報告端末を確認する順番を整理します。
エージェント方式とエージェントレス方式の違い
エージェント方式では、端末内のプログラムが情報を集め、管理先へ報告します。エージェントレス方式では、対象に専用プログラムを置かず、別の収集側から利用可能な通信方式で問い合わせる構成が考えられます。
「エージェントレス」は、収集を行う仕組みまで不要になるという意味ではありません。たとえばGLPIの公式説明では、GLPI Agentを入れた収集側から、WindowsへWinRM、LinuxへSSHで問い合わせる方式を紹介しています。ネットワーク機器の情報収集にはSNMPを使う例もあります。GLPIのリモートインベントリーの説明
以下は方式の違いを説明する概念図です。実際の接続方向、通信の暗号化、待受ポートなどは製品と設定により異なります。
エージェント方式
[対象端末内で収集]
↓ 情報を報告
[管理側で受領・表示]
エージェントレス方式の例
[別の収集端末]
↓ 対象へ問い合わせ
[対象機器が情報を応答]
↓ 収集結果を管理側へ渡す
[管理側で受領・表示]
WinRMはWindowsのリモート管理、SSHはリモート接続、SNMPはネットワーク機器等の管理で使われる通信方式です。名前だけで収集できる項目が決まるわけではなく、機器やOSの対応、設定、権限を確認します。
方式は、対象機器と接続条件ごとに考える
一つの方式ですべてを管理しようとする前に、対象を「端末内へ導入できるか」「収集側から接続できるか」で分けます。次の表は方式を決めるための問いであり、特定構成の推奨表ではありません。
| 対象の状況 | 先に確認すること |
|---|---|
| 社内で使う会社管理PC | 導入・更新の配布方法、必要な取得項目、管理先への通信 |
| 社外で使う貸与PC | 社外からの報告経路、未接続期間、再接続後の反映 |
| 専用ソフトを入れられないサーバー | リモート取得の可否、許可される接続元と権限 |
| スイッチやプリンター | 対応する収集方式と、実際に取得可能な項目 |
| 電源を切って保管する予備機 | 自動収集の対象外になる期間と、別途確認する方法 |
GLPIの説明でも、収集側から対象のネットワークへ到達できることや資格情報などが前提に挙げられています。実際の導入では、製品の公式資料にある必要権限を確認し、社内の接続・権限管理と合わせて判断します。
エージェントを入れれば必ず社外端末を把握できる、エージェントレスなら端末負荷がない、といった一律の説明は避けましょう。端末の動作、通信経路、収集処理の影響を、対象環境で確かめる必要があります。
導入前に、収集する情報と更新時刻を確認する
製品名だけでなく、利用する機能名、OS、端末の所有・登録形態を特定します。同じ製品でも、それらの条件で収集範囲や周期が異なる場合があります。
具体例として、Microsoft Intuneの「Discovered apps」は、OSや会社所有・個人所有などの条件別に収集範囲を説明しています。また、レポートの更新周期と例外を示し、別機能の「App inventory」と区別しています。したがって「Intuneならすべて同じ間隔」とは扱えません。MicrosoftのDiscovered appsの説明
確認する項目は、次のように収集から表示までを分けると整理できます。
- 端末で収集したいもの:機器識別子、OS、ソフトウェアなど、実際に必要な項目。
- 収集が動く条件:電源、ユーザー状態、スケジュール、必要な権限。
- 管理側へ届く条件:接続経路、通信の許可、報告タイミング。
- 画面の時刻の意味:端末の収集時刻か、管理側の受信時刻か、画面の集計時刻か。
最後に受信した時刻だけでは、情報自体がいつ観測されたかを説明できないことがあります。試用時に一つ情報を変え、どの時刻がどう変わるかを確認しておくと、運用時に古い情報を見分けやすくなります。
小さく導入し、収集できない条件も試す
最初は、対象範囲と許可を決めた試験端末で、導入、情報の反映、更新、停止・削除まで確認します。正常に報告できる端末だけで評価せず、日常運用で起こる接続条件も含めましょう。
以下は、社外で利用するPCを想定した試験案です。実測結果ではありません。
- 接続中に、既知の機器情報が管理画面へ反映されることを確かめる。
- 通信できない状態では、最終報告時刻や状態がどう表示されるかを確認する。
- 接続を戻し、情報が更新される条件とタイミングを確認する。
- 収集設定を変更した場合、意図した項目だけを扱えているかを確かめる。
- 試験終了後、不要な設定や試験用の権限を戻す。
CPU使用率や通信量などの影響を評価する場合は、収集前後の条件をそろえて記録します。「動いた」という確認と、「通常業務へ影響しない」という評価は分けてください。
未報告端末は、観測・通信・表示を順に切り分ける
管理画面に新しい情報が出ないときは、まず最後に確認できた時点を見ます。すぐ再インストールするのではなく、どこまで動作が確認できているかを整理します。
| 確認する場所 | 調べる問い |
|---|---|
| 対象の存在と状態 | 電源は入っているか、持出し・保管・修理中ではないか |
| 収集処理 | 対象のOS・設定で収集が動いた記録はあるか |
| 通信と認証 | 管理先または対象への経路が通るか、資格情報に変更はないか |
| 受領と識別 | 管理側が受け取ったか、別レコードとして扱われていないか |
| 画面と集計 | 表示の対象範囲・更新条件・フィルターは合っているか |
これは切り分けの例です。ログを参照する際も、製品ごとの公式手順と組織の権限範囲に従います。取得できない端末を、台帳から自動で消して問題を見えなくする運用にはしないようにしましょう。
収集後に残る確認も、担当へ引き継ぐ
自動収集した情報を業務で使うには、未報告の確認担当、例外端末の管理方法、機能やOSの変更時に再確認する範囲まで決めておきます。所有者や契約、保管品の現物確認など、収集結果だけで確定できない事項も別に扱います。
方式を決める際は、導入可能かだけでなく「見えていない対象をどう発見し、誰が補うか」まで確認してください。作業の引き継ぎには運用手順書の作り方、管理体制の相談にはインフラ・クラウド技術支援をご確認ください。