LASSIC Media らしくメディア
GLPIでIT資産管理基盤を外注構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- GLPIはIT資産管理とITSM（ITサービスマネジメント）を1つの基盤で扱えるオープンソースソフトウェアです。
- オンプレ（セルフホスト）構築では、SaaS型ITSMと比べてデータの保管場所やライセンス費用の考え方が変わります。
- エージェントによる自動インベントリ、ヘルプデスクのチケット運用、外注/内製の判断軸を整理します。
目次
GLPIとは何か IT資産管理とITSMを1基盤で扱うOSS
GLPI（Gestionnaire Libre de Parc Informatique）とは、IT資産管理（IT Asset Management）とITSM（ITサービスマネジメント）機能を1つのソフトウェアで提供するオープンソースのプラットフォームを指します*1。コンピュータやネットワーク機器のインベントリ管理と、ヘルプデスクのチケット対応を同じデータベース上でつなげられる点が特徴です。
GLPIはGNU General Public License Version 3（GPL-3.0）で公開されているオープンソースソフトウェアで、ソースコードはGitHub上のglpi-project/glpiリポジトリで管理されています*2。IT事業部がライセンス費用を払わずに導入できる一方、構築・保守・セキュリティ対応は利用者側の責任範囲になります。
ITSM（ITサービスマネジメント）とは、ITサービスの企画・提供・運用・改善を、利用者視点のプロセスとして体系的に管理する考え方を指します。GLPIはこのITSMの中核であるITIL（IT Infrastructure Library、ITサービスマネジメントの実践知をまとめたフレームワーク）準拠のインシデント管理・リクエスト管理を、資産管理機能と統合した形で提供しています*1。
GLPIで管理できるIT資産の範囲
GLPIのAssets（資産）モジュールは、自動インベントリまたは手動登録によって取得したIT資産を一元管理する機能です*3。対象範囲はハードウェアからソフトウェアまで広く及びます。
管理対象にはコンピュータ、モニタ、ネットワーク機器、周辺機器、プリンタ、電話、ラック、エンクロージャ、PDU（電源分配装置）、ケーブル、SIMなどのハードウェア資産が含まれます*3。加えて、インストール済みソフトウェアの棚卸し、トナーカートリッジなどの消耗品管理も同じモジュールで扱えます。
資産ごとに登録から廃棄までのライフサイクルを追跡できる点も特徴です。仮想化環境ではホストと仮想マシンの関係性も管理対象となり、物理・仮想の両方を横断したインベントリを1つの画面で確認できます*1。
ヘルプデスク機能 ITIL準拠のインシデント・リクエスト管理
GLPIのヘルプデスク機能は、ITILが定義するインシデント管理と要求実現（Request Fulfillment）を区別して扱う設計になっています*4。この区別を理解しておくと、チケット運用の設計がしやすくなります。
インシデント管理は、計画外のサービス停止や品質低下を早期に検知し、通常のサービス状態へ復旧させることを目的とするプラクティスです*4。一方、要求実現（サービスリクエスト管理）は、パスワードリセットのような事前承認済みの低リスクな標準手順に基づく要求を処理する仕組みを指します*4。両者は「計画外の中断」か「計画された要求対応」かという点で性質が異なります。
GLPIはこの2種類のチケットを分けて登録・追跡でき、さらに問題管理（Problem Management）や契約管理、ナレッジベース機能も同じプラットフォームに含みます*2。ヘルプデスクとIT資産管理が同一データベース上でつながっているため、あるインシデントがどの資産に紐づくかをチケット画面から直接確認できる点が、資産管理とチケット管理を別システムで運用する構成との違いになります。
エージェントによる自動インベントリの仕組み
GLPIはバージョン10以降、ネイティブの動的インベントリ機能をコア機能として搭載しています*5。GLPI Agentと呼ばれるエージェントソフトウェアを各端末に配布し、ハードウェア・ソフトウェアの情報を自動収集してGLPIサーバーへ送信する構成です*5。
GLPI Agentは、GLPIサーバーのREST API（front/inventory.php）に対して、OCS InventoryやFusionInventory形式に加えてJSON形式でもインベントリデータを送信できます*5。従来利用されていたFusionInventoryエージェントとの互換性を保ちながら、コンピュータだけでなく電話・アプリケーション・ラックなど多様な資産種別を1つの収集プロトコルで扱える点が拡張されています*5。
自動インベントリを導入すると、手作業での台帳更新に依存せず、端末の増減やソフトウェアの追加・削除を定期的に反映できます。ただし、エージェントの配布先端末数が増えるほど、通信スケジュールの設計やGLPIサーバー側の処理負荷を見込んだ構成検討が必要になります。
セルフホストGLPIとSaaS型ITSMの違い
ServiceNowなどのSaaS型ITSMは、ベンダーが管理するクラウド環境上でサービスが提供され、利用者はブラウザから利用するだけで済む構成です。これに対しセルフホストGLPIは、自社または委託先のサーバー上にソフトウェアを構築し、運用まで自社の管理範囲に置く構成になります。
この違いは、データの保管場所（データ主権）とコスト構造の両方に影響します。セルフホストではデータを社内ネットワーク内に保持できる一方、サーバー構築・OSやミドルウェアの保守・セキュリティパッチ適用は利用者側の責任です。SaaS型はこれらの保守をベンダーに委ねられますが、契約期間中の利用料が継続的に発生します。
下記の比較表に、判断材料となる観点を整理します。
| 観点 | セルフホストGLPI | SaaS型ITSM |
|---|---|---|
| ソフトウェア費用 | GPL-3.0のOSSのためライセンス費用なし*2 | 利用ユーザー数・機能に応じた継続課金 |
| データの保管場所 | 自社インフラ内で保持可能 | ベンダーのクラウド環境に保管 |
| 構築・保守の担い手 | 自社または委託先が担う | ベンダーが担う |
| カスタマイズ自由度 | ソースコードレベルでの改修が可能 | ベンダー提供の設定範囲内に限定 |
| 導入スピード | サーバー構築・設定を要するため時間を要する | 契約後の初期設定のみで稼働可能 |
オンプレ構築で必要になる要件と工数
GLPIをオンプレでセルフホストするには、Webサーバー（ApacheやNginxなど）、MariaDB 10.6以上またはMySQL 8.0以上、PHP 8.2以上を用意する必要があります*2。必須のPHPエクステンションにはdom・fileinfo・filter・curl・gd・intl・mbstring・mysqliなどが含まれます*2。
構築作業には、これらのミドルウェアのバージョン整合性を取る工程、GLPI本体のインストールと初期設定、資産分類やチケットのワークフロー設計、GLPI Agentの配布・稼働確認までが含まれます。IT資産管理とヘルプデスクの両方を運用に乗せる設計では、部門ごとの権限設定やカテゴリ設計も必要になり、単純なソフトウェアインストールでは完結しません。
この作業を内製で行うには、Linuxサーバー運用・データベース管理・PHPアプリケーションの保守という3領域の知識が必要です。加えてGLPI固有の資産分類・ワークフロー設計の知見も求められるため、専任の担当者を確保できない情シス部門では、要件定義から構築までの工数を見込んだ計画が欠かせません。
運用フェーズで発生する作業と落とし穴
構築後の運用フェーズでは、GLPI本体・ミドルウェア・OSのセキュリティパッチ適用が継続的な作業になります。オープンソースソフトウェアは脆弱性情報の追跡と適用判断を利用者側で行う必要があり、パッチ適用を怠るとサーバーが既知の脆弱性に晒された状態が続くリスクがあります。
GLPI Agentの配布端末数が増えると、通信スケジュールの調整やサーバー側のデータ処理負荷も無視できなくなります。端末の増減が多い組織では、エージェントのバージョン管理と配布手順を運用ルールとして明文化しておく必要があります。
また、資産分類やチケットカテゴリの設計を最初に固めずに運用を始めると、後から分類をやり直す手間が発生しやすくなります。ITSMの設計は「入力してから直す」よりも「入力前に整える」方が修正コストを抑えられる領域です。
外注と内製の判断軸
GLPIを外注構築するか内製するかを判断する軸は、「構築・保守に割ける専任リソースが社内にあるか」という点に集約されます。前述の通り、サーバー運用・データベース管理・PHP保守・GLPI固有設計という複数領域の知識が同時に必要なため、情シス部門の兼務担当者だけで完結させるには負荷が大きくなりがちです。
専門パートナーに構築を委託した場合、要件定義からミドルウェア選定、資産分類・ワークフロー設計、GLPI Agentの配布設計までを一括して進められます。内製で進める場合は、担当者がこれらの領域を並行して学習しながら構築する形になり、本来のヘルプデスク業務に充てる時間が圧迫されやすい点が違いです。
オープンソースゆえにライセンス費用は抑えられますが、構築・保守にかかる人的コストをどう確保するかが実質的な総コストを左右します。自社のIT資産規模や情シス体制を踏まえ、構築だけを外部に委託し運用は内製する、あるいは構築・運用の両方を委託するといった段階的な選択も検討に値します。
まとめ：GLPI導入で押さえるべき3つの判断軸
本稿ではGLPIによるIT資産管理・ITSM基盤のオンプレ構築について、機能範囲・SaaS型ITSMとの違い・構築運用の要件を整理しました。要点を3つに集約すると次の通りです。
第一に、GLPIはIT資産管理とITIL準拠のヘルプデスク機能を1基盤で扱えるオープンソースソフトウェアです。第二に、セルフホスト構築ではデータ主権とライセンス費用の面でメリットがある一方、構築・保守は自社の責任範囲になります。第三に、専任リソースの有無が外注・内製を分ける判断軸となります。
よくある質問
GLPIとServiceNowはどちらを選べばよいですか。
データを自社で保持したいか、構築・保守の人的リソースを確保できるかで判断します。GLPIはGPL-3.0のオープンソースでライセンス費用がかからない一方、構築・保守は自社の責任範囲です*2。ServiceNowのようなSaaS型はベンダーが保守を担う分、継続的な利用料が発生します。
GLPIの導入にはどの程度のサーバー環境が必要ですか。
Webサーバー、MariaDB 10.6以上またはMySQL 8.0以上、PHP 8.2以上が必要です*2。加えてdom・curl・gd・intl・mbstringなど複数のPHPエクステンションを有効にする必要があります*2。
GLPI Agentを導入するとどのような情報が自動収集されますか。
コンピュータやネットワーク機器のハードウェア情報、インストール済みソフトウェアなどが自動収集され、GLPIサーバーのREST APIへ送信されます*5。従来のFusionInventoryエージェントとも互換性があります*5。
GLPIのヘルプデスク機能はインシデントとリクエストを分けて管理できますか。
分けて管理できます。ITILの定義では、計画外のサービス停止に対応するインシデント管理と、パスワードリセットのような事前承認済みの要求に対応する要求実現は別のプラクティスとして扱われます*4。GLPIはこの区別に沿ってチケットを登録・追跡できます。
GLPIの構築を外注する場合、どこまでを委託できますか。
要件定義、サーバー・ミドルウェアの構築、資産分類・ワークフロー設計、GLPI Agentの配布設計まで一括で委託できます。構築後の運用保守を継続して委託するか、内製に切り替えるかは、社内の専任リソースの有無に応じて選択できます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：GLPI Project「Smart IT Service Management, Helpdesk & Asset Tracking」（https://www.glpi-project.org/en/）
- *2 出典：GitHub「glpi-project/glpi」（https://github.com/glpi-project/glpi）
- *3 出典：GLPI Help Center「Assets」（https://help.glpi-project.org/documentation/modules/assets）
- *4 出典：Axelos「ITIL in 2000 words: Service desk, incident and service request management」（https://www.axelos.com/resource-hub/white-paper/itil-2000-words-incident-service-desk-request-management）
- *5 出典：GLPI Project「Discover native GLPI inventory」（https://www.glpi-project.org/en/discover-native-glpi-inventory/）
