はじめに
GLPIを運用するうえで最も重要な概念のひとつが「エンティティ（Entity）」です。エンティティは、組織・部門・拠点などの管理単位を定義する仕組みで、GLPI全体のデータ構造や権限範囲を決める骨格となります。
この記事では、エンティティの基本的な考え方から、中小企業での標準的な設計例、運用時のポイントまでを解説します。
GLPI のエンティティとは？
GLPIのエンティティは、簡単に言えば「GLPI におけるデータの区切り」です。多くの場合、組織の部門や地理的に離れた拠点とよく似た使われ方をします。
| 構成パターン | 概要 | 活用例 |
|---|---|---|
| 単一エンティティ構成 | 1つのエンティティで全資産を管理 | 小規模企業、部署が少ない環境 |
| 階層エンティティ構成 | 親エンティティの下に複数の子エンティティを作成 | 複数拠点・複数部門を持つ中堅〜大規模企業 |
ユーザーに付与する権限の境界として機能したり、通知設定や地理的な場所といった細かな設定を管理したりすることができます。
エンティティ構造を設計する目的
GLPI の初期状態ではルートエンティティという単一のエンティティが存在し、すべてのユーザーはこのエンティティに属しています。
エンティティを分けて設計する主な目的は次の3点にあります。
- データ範囲の分離
部門や拠点ごとに閲覧できる資産を制限し、不要な情報を見せないようにする。 - 運用責任の分担
各部門に権限を委譲し、部門ごとの管理を可能にする。 - 集約・分析を容易にする
全社レベルでは親エンティティで統計やレポートをまとめて確認できる。
利用者に必要最小限の権限を付与し、閲覧範囲を絞る「最小権限の原則（Principle of Least Privilege: PoLP）」を実装するためにエンティティが使われます。
設計例：中小企業での標準的な構成
中小企業（社員数50〜200名）でよく採用される構成例を紹介します。
パターンA：部門単位で分ける
ルートエンティティとなる「会社」の配下に、組織構造の部署を子エンティティとして作成する方式です。
会社（親エンティティ）
├── 営業部
├── 総務部
└── 情報システム部このパターンでは次のような要件があるときに有効です。
- 部署ごとに資産を管理している
- 部署ごとに管理を委任したい
各部門の担当者に管理権限を付与し、部門で使用している資産の管理を委任することができます。また、部門に資産管理を委任しながらも、全体を統括するユーザーを親エンティティに属させて、各部署の管理権限を持たせることで、全社横断的に管理することができます。
パターンB：拠点単位で分ける
ルートエンティティとなる「会社」の配下に、各拠点の子エンティティを作成する方式です。
会社（親エンティティ）
├── 東京本社
├── 大阪支社
└── 名古屋営業所このパターンでは次のような要件があるときに有効です。
- 物理的に拠点が分かれており、ネットワークや担当者が独立している
- 拠点ごとの棚卸しや契約を可視化したい
各拠点にある資産を可視化したり、その拠点内で資産を管理する場合に有効です。パターンAと同様に、各拠点に管理を委任することもでき、全体を管理するユーザーを作成することもできます。
パターンC：ハイブリッド構成
パターンAとパターンBを組み合わせることもできます。拠点が複数あり、その拠点内でいくつかの部門があるといった場合に、柔軟な権限設定ができます。
会社
├── 本社（親）
│ ├── 営業部
│ ├── 総務部
│ └── 情報システム部
└── 大阪支社
├── 営業部
└── 情報システム部このパターンでは次のような要件があるときに有効です。
- 拠点と部門のそれぞれで権限と閲覧範囲を制限したい
- 拠点ごとに管理を委任したい
拠点や部門が多くあり、管理対象の資産も多数ある大規模な企業では、こうした構成で柔軟に管理することができます。
エンティティとプロファイルの関係
このようにエンティティは「データの範囲」を区切る機能を持っています。区切られた範囲で、ユーザーがどのような操作を行えるかはプロファイルで定義します。
| 要素 | 役割 | 例 |
|---|---|---|
| エンティティ | どの範囲のデータを扱うか | 営業部のみ・全社・拠点単位など |
| プロファイル | 何ができるか（権限） | 管理者・編集者・閲覧者など |
この2つを組み合わせることで、「営業部の管理者は自部署の資産を編集できるが、他部署は閲覧のみ」、「同じ営業部でも他拠点の営業部の資産は閲覧できない」といった柔軟なアクセス制御が可能になります。
よくあるつまずきと回避策
柔軟な権限管理と運用を可能にするエンティティですが、事前に十分な設計を行っていなければ運用や管理がかえって煩雑になってしまいます。
| よくある課題 | 対処方法 |
|---|---|
| エンティティを細かく分けすぎて管理が煩雑に | 拠点や部署が明確に独立していない場合や小規模な企業では「ルートエンティティ」で十分 |
| 部署を後から追加したい | 「親エンティティの下に子エンティティを追加」すれば運用継続可能 |
| 他部門のデータが見えない／見せたくない | プロファイルとエンティティの関係を整理し、権限を再設定 |
| 親エンティティでの集計が正しく出ない | 階層の設計を明確にし、継承設定を確認 |
また、ユーザーに付与された権限（プロファイル）をエンティティに再帰的に適用するのか、ということも十分に考慮しておく必要があります。適切にプロファイルが付与されていなければ、データや資産が正しく参照できない、といったトラブルにつながります。
再帰的なプロファイル
ユーザーに設定されているプロファイルが再帰的に設定されている場合、所属するエンティティの子エンティティにも権限が継承されます。以下のユーザーの場合、ルートエンティティに Admin 権限が再帰的に設定されています。
ルートエンティティに子エンティティが作成された場合、該当のユーザーは子エンティティの Admin 権限が自動的に付与されます。
その一方で、プロファイルを非再帰的に適用した場合、ユーザーはそのエンティティにだけ権限を持ちます。その場合、ユーザーは親エンティティに Admin 権限を持っていますが、子エンティティには Admin 権限が付与されません。
運用設計のポイント
エンティティは便利に使える一方で、権限の付与の仕方を考慮すると運用設計が難しくなる傾向があります。以下の4点を考慮して運用設計することをおすすめします。
- 最初に管理単位を明確にする
部署・拠点など、実際の管理体制に合わせて階層構造を設計します。 - 「最小限から始める」設計を意識する
最初は1階層構成（デフォルトの状態）で始め、必要に応じて階層を増やす方が運用が安定します。 - 命名規則を統一する
「本社」「東京本社」「Tokyo」など表記が混在しないよう、統一ルールを設けるとスムーズです。 - 親エンティティを「全社統括」として扱う
全体集計やレポートを行う際に役立ちます。
まとめ：エンティティ設計はGLPI運用の第一歩
エンティティはGLPIの管理範囲と運用効率を決める重要な要素です。構成を複雑にするよりも、「誰が」「どの範囲を」「どのように管理するか」を整理し、できるだけシンプルに保つことをおすすめします。
まずは最小限の構成で運用を始め、実際の運用で得た知見をもとに階層を拡張していきましょう。エンティティ設計をしっかり固めることで、GLPIのすべての機能を最大限に活かせるようになります。
GLPI の操作性や機能を体験できる無料のデモ環境を公開しています。
メールアドレスを登録するだけで、すぐにお試しいただけます。
※メールはデモ環境のご案内のみに使用します。営業目的の連絡は行いません。