LASSIC Media らしくメディア
IT資産管理システムの開発を外注する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・運用を受託
この記事のポイント
- IT資産管理システムは、ハードウェア台帳・ソフトウェア/ライセンス管理(SAM)・自動インベントリ収集を核に、脆弱性/パッチ管理やEOL・保守期限まで一元化する仕組みです。国際規格ISO/IEC 19770-1は2017年版でハード・ソフト・クラウドを含むITAM規格へ発展しています。
- 開発の動機はライセンスコンプライアンス(監査対応)とセキュリティ(脆弱性の可視化)の2つに大別できます。Windows 10は2025年10月14日にサポートが終了し、EOL資産の把握が実務課題になりました。
- パッケージ(ITAM/SaaS)かスクラッチかは、多様なOS/クラウドのインベントリ収集・既存セキュリティ/CMDB連携・大規模台数のスケールで判断します。外注先にはこの3点の実装力を確認します。
目次
IT資産管理システムとは、ハード・ソフト・ライセンスを一元化する仕組み
IT資産管理システム(ITAM)とは、社内で保有・利用するIT資産の情報を一元的に管理する仕組みを指します。中核となる管理対象は、PCやサーバーなどを記録するハードウェア資産台帳、OSやアプリケーションを扱うソフトウェア/ライセンス管理(SAM。Software Asset Management)、そして各端末から構成情報を集める自動インベントリ収集の3つです。国際規格のISO/IEC 19770-1は、2006年にソフトウェア資産管理(SAM)の規格として登場し、2017年版ではハードウェア・ソフトウェア・クラウドまでを対象とするIT資産管理(ITAM)の規格へと発展しました*2。
システム化する機能は、図のように「収集」「台帳」「活用」の3層で整理すると全体像をつかみやすくなります。収集層が各端末や機器から情報を自動で集め、台帳層がそれを名寄せして統合データベースに蓄えます。そのうえで活用層が、ライセンス、セキュリティ、コストといった目的別の分析へつなげる流れです。
活用層の代表格が、ソフトウェア使用状況とコンプライアンス管理、脆弱性/パッチ管理連携、PC操作ログや外部持ち出しの管理、EOL(End of Life。サポート終了)・リース・保守期限の管理、そしてクラウド/SaaS利用管理です。どこまでを自社の要件に含めるかで、開発規模もパッケージ選定の可否も変わってきます。
資産を台帳で管理する考え方は、公的なガイドラインにも示されています。IPA(独立行政法人情報処理推進機構)の「中小企業の情報セキュリティ対策ガイドライン」では、情報資産ごとに機密性・完全性・可用性を評価する情報資産管理台帳の枠組みが、付録のサンプルとして提供されています*1。IT資産管理システムは、こうした台帳運用を自動化・継続化する基盤と位置づけられるでしょう。
固定資産管理・MDM・CMDBとの違いと連携範囲を整理する
IT資産管理システムの要件を固める前に、隣接する仕組みとの違いを押さえておくと混同を避けられます。名前が似た領域であっても、目的とデータの持ち方が異なるためです。
固定資産管理システムとの違い——会計目的か、運用目的か
固定資産管理システムは、取得価額・減価償却・除却といった会計・税務の処理を主目的とします。一方でIT資産管理システムが見るのは、台数・構成・インストール済みソフト・ライセンスの過不足・セキュリティ状態です。同じ「資産」という言葉を使っても、管理の切り口はまったく別物と考えるとよいでしょう。両者を連携させる場合は、資産IDやリース・保守契約の情報を突合し、会計上の資産と現物の構成情報を対応づけます。
MDM/EMM・CMDBとの違いと補完関係
MDM/EMM(モバイルデバイス管理/エンタープライズモビリティ管理)は、スマートフォンやタブレットの構成配布・遠隔ロックが中心です。IT資産管理システムはPC・サーバー・ネットワーク機器・SaaSまで広く棚卸しするため、両者はデバイス情報を相互に補完する関係になります。またCMDB(構成管理データベース。ITILの構成アイテムを管理する仕組み)は、サービス運用の観点で構成要素の関係を管理します。IT資産管理が扱うライセンスやライフサイクルの情報とCMDBの構成情報を連携させ、構成アイテムと資産の実体を一致させる設計が実務では重要です。
開発の動機は「ライセンスコンプライアンス」と「セキュリティ」の2つ
IT資産管理システムを新規開発・刷新する動機は、大きく2つの軸に分かれます。要件定義では、どちらを主目的に置くかで優先すべき機能が変わってきます。
動機1：ライセンスコンプライアンス（監査対応）
1つ目がソフトウェアライセンスのコンプライアンスです。ソフトウェアメーカーによるライセンス監査は契約に基づく義務として実施され、国際的に認められた独立監査人が確認する仕組みになっています*5。マイクロソフトは、こうした監査をコンプライアンス違反リスクの低減と知的財産権の保護を目的に位置づけています*5。日常的なソフトウェア資産管理(SAM)は、こうした監査とは目的が異なり、利用者のリスク最小化と最適化を狙うものです*5。台帳で利用実態を把握できれば、監査での追徴リスクと、使われていないライセンスの無駄な費用を同時に抑えられます。
動機2：セキュリティ（脆弱性の可視化とEOL管理）
2つ目がセキュリティです。脆弱性対策情報データベースJVN iPediaには、脆弱性対策情報が四半期ごとに継続的に登録され続けています*4。どの端末にどのソフトのどのバージョンが入っているかを台帳で把握できなければ、公表された脆弱性への影響範囲を判断できず、パッチ適用の優先度も決められません。さらにEOL管理も欠かせない観点です。Windows 10は2025年10月14日にサポートが終了し、以降はセキュリティ更新プログラムが提供されなくなりました*3。サポートの切れた資産を放置すると更新の届かない状態が続くため、EOLを迎える資産を早期に洗い出す仕組みが求められます。
パッケージ（ITAM/SaaS）とスクラッチ開発の判断軸
IT資産管理は、市販のITAMツールやSaaSが数多く提供されている領域です。そのため「まずパッケージで足りるか、スクラッチ開発が必要か」の見極めが、外注検討の出発点になります。判断軸は、導入スピードとコスト、カスタマイズ性、収集の対応範囲、既存システム連携、保守の5点に整理できます。
| 判断軸 | パッケージ（ITAM/SaaS） | スクラッチ開発 |
|---|---|---|
| 導入スピード | 短期間で稼働。標準機能をそのまま利用 | 要件定義から設計・実装が必要で長め |
| 費用構造 | 初期費用は抑えやすく月額・年額が中心 | 初期開発費が大きく、保守費が継続 |
| 収集の対応範囲 | 対応OS・機器は製品の仕様に依存 | 自社の混在環境に合わせて自由に設計 |
| 既存システム連携 | APIの範囲内。独自帳票・突合は制約あり | CMDBやセキュリティ製品と深く連携可能 |
| 保守・新OS対応 | ベンダーが更新を提供 | 新OSや仕様変更へ自社で追随が必要 |
標準的な棚卸しとライセンス管理が中心で、対応OSも製品仕様の範囲に収まるなら、パッケージやSaaSの導入が現実的です。一方、多数のクラウド環境や独自機器を含む混在構成、既存のCMDB・セキュリティ基盤との密な連携、社内固有の承認フローや帳票が要件に含まれる場合は、スクラッチ開発、あるいはパッケージを土台とした個別開発の検討余地が出てきます。すべてを作り込むのではなく、パッケージの収集エンジンを活かしつつ連携・分析部分を開発する折衷案も選択肢になるでしょう。
外注先に確認すべき3点——インベントリ収集・連携・スケール
開発を外部に委託する場合、成果物の品質を左右するのは技術的な実装力です。とりわけ次の3点は、契約前に具体的な実績と方式を確認しておきたい項目になります。
1. 多様なOS・クラウドのインベントリ収集
実際の社内環境は、Windows・macOS・Linuxのクライアント、各種サーバー、ネットワーク機器、さらにAWSやAzureのクラウド資産やSaaS利用まで混在しているのが通常です。これらをどの方式で収集するかが設計の肝になります。端末に常駐させるエージェント方式、常駐させないエージェントレス方式、クラウドやSaaSのAPIから取得する方式のいずれに対応できるかを確認します。収集できない領域が残ると台帳の網羅性が損なわれるため、対象範囲を明確にすり合わせておくことが大切です。
2. 既存のセキュリティ製品・CMDBとの連携
IT資産管理システムは単独で完結せず、周辺システムとの連携で価値が高まります。EDRや脆弱性スキャナ、ID基盤、CMDB、ITSMツールとAPIで連携できるか、そして異なるシステム間で同じ資産を正しく突合できるかを見極めます。ホスト名やシリアル番号の表記ゆれを吸収する名寄せの精度が、連携の実用性を大きく左右する要素です。委託先がこうした突合ロジックの実装経験を持つかどうかは、重要な確認ポイントです。
3. 大規模台数へのスケール
数千台から数万台規模になると、収集頻度やデータベース設計、収集時のネットワーク負荷が課題になります。全台を同時に収集するとネットワークやサーバーへ負荷が集中するため、収集タイミングの分散やデータ量の設計が欠かせません。加えて、拠点や組織階層ごとに閲覧・操作権限を分ける設計が必要かどうかも、要件として整理しておくとよいでしょう。想定する台数の上限を提示し、その規模での稼働実績を確認しておくと、発注後の不安を抑えられます。
内製と外注の分かれ目——収集エージェントと連携の工数で判断する
パッケージ製品を導入して標準機能の範囲で運用するのであれば、設定・チューニングを情報システム部門が内製で担える場合もあります。判断が分かれるのは、収集エージェントの独自開発や、多環境からの収集、既存システムとの大規模な連携が絡む場合です。
これらの領域は、対応OSごとの収集モジュール、API連携、名寄せロジック、大量データを扱うデータベース設計といった複数分野の知識を必要とします。既存の運用担当者が通常業務と並行して設計・開発まで担うのは負荷が大きく、専門パートナーへの委託が現実的な選択になりやすい領域です。委託する場合は、要件定義から収集基盤の設計・開発、既存システム連携、運用保守までを一貫して依頼できるかどうかが、元請（プライムベンダー）を選ぶ際の分かれ目になります。
LASSIC IT事業部は、システム開発・運用を元請（プライムベンダー）として受託しています。IT資産管理システムの要件定義から収集基盤の設計、既存のセキュリティ製品・CMDBとの連携、大規模台数を見据えた基盤構築までを支援する体制を整えています。移行対象の台数や連携先の数によって必要な工数は変わってくるため、現状の構成を整理したうえで内製・外注の切り分けを検討することが実務的でしょう。
まとめ：IT資産管理システムの開発を外注する3つの判断軸
本稿では、IT資産管理システムの開発を外注する際の考え方を、公的情報をもとに整理してきました。要点は3つに集約できます。第一に、IT資産管理システムはハードウェア台帳・ソフトウェア/ライセンス管理・自動インベントリ収集を核とし、ISO/IEC 19770-1は2017年版でハード・ソフト・クラウドを含むITAM規格へ発展しています*2。第二に、開発の動機はライセンスコンプライアンスとセキュリティの2軸に分かれ、Windows 10のサポート終了に代表されるEOL管理も重要度を増しました*3。第三に、外注先には多様なOS/クラウドのインベントリ収集・既存セキュリティ/CMDB連携・大規模台数のスケールという3点の実装力を確認することが、成否を分けます。
よくある質問
パッケージのIT資産管理ツールがあるのに、なぜスクラッチ開発を検討するのですか。
多数のクラウド環境や独自機器を含む混在構成、既存のCMDB・セキュリティ基盤との密な連携、社内固有の承認フローや帳票が要件に含まれる場合、パッケージの標準機能では収まりきらないことがあります。こうしたケースでは、スクラッチ開発やパッケージを土台とした個別開発が選択肢になります。まずは要件を洗い出し、パッケージで足りる範囲を切り分けることが出発点です。
固定資産管理システムとIT資産管理システムは統合できますか。
両者は目的が異なり、固定資産管理は会計・税務の処理を、IT資産管理は構成やライセンス、セキュリティ状態の把握を主目的とします。完全に一体化するより、資産IDやリース・保守契約の情報で突合し、会計上の資産と現物の構成情報を対応づける連携が実務的です。連携の範囲は、どの情報を両システムで共有したいかによって設計します。
クラウドやSaaSの利用状況も管理できますか。
クラウドやSaaSのAPIから利用状況を取得する方式に対応していれば、管理対象に含められます。ISO/IEC 19770-1も2017年版でクラウドを含む環境を対象範囲に加えています*2。ただし取得できる項目はサービスごとに異なるため、どのSaaSのどの情報を収集したいかを要件として具体化し、外注先の対応可否を確認しておくことが大切です。
開発を外注する際、既存のセキュリティ製品との連携はどこまで依頼できますか。
EDRや脆弱性スキャナ、ID基盤などとAPI連携できる委託先であれば、脆弱性の影響範囲を台帳と突き合わせる仕組みまで依頼できます。公表される脆弱性は継続的に増えており、JVN iPediaにも四半期ごとに登録が続いています*4。連携の可否は製品のAPI仕様と名寄せの精度に左右されるため、対象製品を提示して実装経験を確認しましょう。
大規模な台数でも自動インベントリ収集は問題なく動きますか。
数千台から数万台規模では、収集頻度やデータベース設計、ネットワーク負荷の設計が品質を左右します。全台を同時に収集すると負荷が集中するため、収集タイミングの分散やデータ量の見積もりが欠かせない要素です。想定する台数の上限を外注先に提示し、その規模での稼働実績や設計方針を確認しておくと、稼働後のトラブルを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA「中小企業の情報セキュリティ対策ガイドライン」（第4.0版・2026年3月27日公開）（https://www.ipa.go.jp/security/guide/sme/about.html）
- *2 出典：ITAM Standards「ISO/IEC 19770-1」（ISO/IEC 19770-1:2017 IT Asset Management）（https://itamstandards.org/iso-iec-19770-1/）
- *3 出典：Microsoft「Windows 10 のサポート終了」（Microsoft Lifecycle）（https://learn.microsoft.com/ja-jp/lifecycle/announcements/windows-10-end-of-support）
- *4 出典：IPA「脆弱性対策情報データベースJVN iPediaの登録状況」（https://www.ipa.go.jp/security/reports/vuln/jvn/index.html）
- *5 出典：マイクロソフト「ライセンス監査 FAQ」（マイクロソフト ボリューム ライセンス）（https://www.microsoft.com/ja-jp/licensing/learn-more/compliance-verification-faq）
