人は減っていないのに、IDだけ増え続ける現象
- 山崎行政書士事務所
- 1月24日
- 読了時間: 10分
──「ヘッドカウントは横ばい」なのに、ディレクトリは膨張し続ける“ID増殖”の正体
Entra ID（Microsoft Entra ID）やIdaaSを入れてしばらくすると、現場でよく起きる違和感があります。
正社員数も、業務委託や派遣の人数も、体感ではそんなに増えていない
なのに、ディレクトリ上のID（アカウントやオブジェクト）だけが毎月増えていく
「誰のID？」「何のためのID？」がすぐ答えられない
いつの間にか例外（除外）が増え、運用が重くなる
監査・棚卸しのたびに“怪しいID”が大量に出てくる
この現象は、単なる「削除漏れ」だけでは説明がつきません。ID基盤の世界では、人数が横ばいでもIDが増え続ける“構造”がいくつもあります。
この記事では、
「IDだけ増える」原因のパターン
増え方のどこが危険か（増えて良いID／増えてはいけないID）
どう見える化し、どう止めるか（運用が軽くなる順番）
を、設計フェーズの違和感として整理します。（文中にリンクは置きません）
1. まず前提：「IDが増える」の“ID”は1種類ではない
「IDが増えている」と言っても、Entra IDの中では増える対象が複数あります。
人のID（Human）
Member：社内のユーザー（正社員、契約社員、派遣などを“社内扱い”で入れている場合）
Guest：外部ユーザー（B2B招待など）
人ではないID（Workload / Non-human）
アプリケーション（アプリ登録）
サービス プリンシパル（アプリをテナントに導入した結果できる実体）
マネージドID（Azureリソースに紐づくID）
（組織によっては）古い“サービスアカウント”や共有アカウント
この違いを分けずに「IDが増えた」と騒ぐと、対策がズレます。逆に言えば、どの種類が増えているかを分けた瞬間に、原因の当たりがつきます。
2. 人数が横ばいでも、IDが増える“典型原因”9パターン
「削除漏れ」だけでなく、実務では複数要因が重なって増えます。
パターン1：退職・契約終了の“出口”が弱い（止めても消えない）
退職者は無効化されるが、削除されず残り続ける
委託先は契約終了のトリガーが弱く、放置されやすい
「停止はしたはず」でも、実態はアカウントが残っている
ポイント：入口（作成）は整っても、出口（無効化→削除→棚卸し）が整っていないとIDは増え続けます。
パターン2：「再雇用」「出戻り」「部署横断」で“新規作成”が起きる
人は同じでも、アカウントを作り直してしまうケースです。
退職→再雇用で新ID
出向→復職で新ID
子会社転籍で新ID
学籍・研修アカウント→本番アカウントで新ID
このとき、本人は増えていないのにIDは増えます。
パターン3：UPN/メール/ドメイン変更を“作り直し”で処理してしまう
会社ドメインが変わった
メールアドレス体系が変わった
UPNを揃えたい…という局面で、正しくは「変更」で済むのに、現場では“作り直し”が起きます。
すると、旧IDが残り、新IDが増え、合計が膨らみます。
パターン4：正社員1人に複数ID（一般＋管理者＋緊急）が増えていく
セキュリティ上は「管理者用アカウントを分ける」ことは合理的です。しかし、運用が未整備だと “良い増え方” が “悪い増え方” に変わります。
管理者アカウントが増える
どれが誰の管理者か追えない
使われない管理者IDが残る
いつの間にか例外（MFA除外など）も付く
増えて良いが、台帳と棚卸しが無いと危険化する代表例です。
パターン5：外部（Guest）が“人の数以上”に増える
外部ユーザーは「人数の感覚」と「IDの増え方」がズレやすいです。
外部ベンダが増える
同じ人が複数案件で招待される
取引先の組織変更で同一人物が別メールで再招待される
期限運用がないので、契約終了しても残る
結果、外部の実人数は増えていないのに、Guestは積み上がる。
パターン6：検証・PoC・一時対応の“仮ID”が恒久化する
「検証だから」
「研修だから」
「今日だけ」
「いったん」この“いったん”に期限が付いていないと、仮IDは資産化して残ります。
パターン7：アプリ側の“ローカルアカウント”が生きている
IdaaSやSSOを導入しても、アプリ側にローカルIDが残るケースは多いです。
SSOは入口だけ
権限や利用者登録はアプリ側に残っている
退職時の削除がアプリごとで漏れる
結果、アプリのIDだけ増える
この場合、「ID基盤を入れたのにIDが増える」という違和感になります。
パターン8：Workload ID（サービスプリンシパル等）が自然増する
SaaSを連携するたび、Azureリソースを増やすたび、Workload IDは増えます。
監視・自動化
CI/CD
コネクタ
API連携
マネージドID
これは“正常な増え方”でもあります。ただし、オーナー不明・用途不明・期限不明になると運用負債になります。
パターン9：発行ルートが複数あり、重複が止まらない
人事→AD→Entra ID
現場依頼→情シス手作業
SaaS側で招待→ゲスト作成
アプリ担当が勝手にテストID作成…など、入口が複数あると、同じ人・同じ目的のIDが平気で増えます。
3. “増えること”が問題ではない。問題は「増え方の品質」
ここが一番大事です。
IDが増えること自体は、必ずしも悪ではありません。増えるべきものもあります（管理者分離、Workload IDなど）。
ただし、増え方の品質が悪いと、ID基盤は確実に重くなります。
危険な増え方（赤信号チェック）
次のどれかに当てはまるIDが増えているなら、運用は必ず苦しくなります。
オーナー（責任者）が不明
作成理由が不明
期限がない（仮なのに恒久）
“正社員／委託／外部”の区別が属性で追えない
無効化されていないのに、長期間サインインが無い
特権（管理ロール）が付いているのに棚卸しされていない
条件付きアクセスの評価エンジンから除外されている
どのアプリに割り当てられているか追えない
増えている数より、まずこの品質を見た方が早く解決します。
4. IDが増え続けると、何が重くなるか
「IDが多い」だけなら、まだ困りません。困るのは、増殖が次の運用に直撃するからです。
4-1. 条件付きアクセスが“読めなくなる”
条件付きアクセスは、単なる“ルール集”ではなく評価エンジンです。評価エンジンは、対象（ユーザー/アプリ/デバイス/場所）が揃って初めて意図通りに評価できます。
IDが増え続ける環境では、だいたいこうなります。
想定外のIDが引っかかる
その場しのぎで「ユーザー除外・アプリ除外」が増える
除外が増えるほど評価結果の再現性が落ちる
「なぜ通った／通らない」が説明できない
結果、運用が重くなり、監査も弱くなります。
4-2. 棚卸し（アクセスレビュー）が“終わらない”
IDが多いと、棚卸しの対象も増えます。
使われていないID
期限切れの外部
使われていない管理者ID
どのアプリにも入っていないIDこれらが溜まり続けると、棚卸しは“毎回地獄”になります。
4-3. 「入れない」問い合わせが増える（そして再現しない）
“誰のIDか分からない”“どの分類か分からない”IDが増えると、切り分けが遅くなります。結果、同じ事象でも毎回調査がやり直しになりがちです。
4-4. コストがジワる（ライセンス、運用工数、更新作業）
使っていないIDにライセンスが付く
グループや割り当てが増え続ける
設定変更が怖くなり、改善が止まるこの「ジワジワ」が最後に効きます。
5. まずやるべきは“削除”ではなく「分類と見える化」
「IDが増えた＝削除しよう」は、危険なショートカットです。IDは、消すと業務影響が出ることがあるからです。
最初にやるべきは、分類して見える化です。
5-1. 見える化の基本は「人のID」と「人ではないID」を分ける
最低限、次の4枠に分けると状況が一気に整理されます。
社内（Member）
外部（Guest）
特権（管理者用・緊急用）
Workload（サービスプリンシパル／マネージドID等）
この4枠のどれが増えているかで、打つ手が変わります。
5-2. さらに“出口の弱さ”を炙り出す：アクティブ／休眠／無効化
次に見るべきは「生きているか」です。
直近にサインインがある（アクティブ）
サインインが長期間ない（休眠）
無効化されている（停止済み）
期限が切れている（設計上の失敗）
ログをLog Analyticsに出している組織なら、例えば以下のような“入口クエリの型”で傾向が掴めます（環境により列名は多少異なります）。
// 直近90日でサインインがあるユーザー（概念例）
SigninLogs
| where TimeGenerated > ago(90d)
| summarize Signins=count() by UserPrincipalName, UserType
| order by Signins desc
// 外部ゲストのサインイン状況（概念例）
SigninLogs
| where TimeGenerated > ago(180d)
| summarize Signins=count() by UserPrincipalName, UserType
| where UserType == "Guest"
| order by Signins asc
KQLが書けなくても大丈夫ですが、「見る切り口」を固定することが重要です。“何を見たいか（分類と出口）”が先で、ツールは後です。
6. “IDだけ増える”を止める設計は、結局「入口と出口」の設計
増殖を止める鍵は、派手な機能よりも地味な2つです。
入口：誰が、どのルートで、どんな条件で作るか
出口：いつ、何を根拠に、どう止め、どう消すか
6-1. 入口を1本化する（増殖の最大要因を潰す）
入口が複数あると、重複と例外が増えます。理想はこのどれかに寄せることです。
人のID：人事イベント（Joiner/Mover/Leaver）を起点に自動化
外部ID：招待の権限と手順を絞り、期限・棚卸しを必須にする
管理者ID：発行・管理・棚卸しを標準化する
Workload ID：作成時にオーナーと用途を必須にする
入口を絞るだけで、増殖のスピードは落ちます。
6-2. 出口に“期限”を入れる（仮IDが資産化しない）
増殖の多くは「期限がない一旦」から生まれます。
委託：契約終了日＝期限
ゲスト：プロジェクト終了日＝期限
検証：検証終了日＝期限
緊急：用途終了＝期限（もしくは使用実績の棚卸し）
期限は“削除日”と同義でなくて構いません。まずは「期限が来たら棚卸し必須」にするだけでも、増殖が止まります。
6-3. “増えて良いID”も台帳化する（管理者とWorkloadが燃えないために）
管理者IDやWorkload IDは増えることがあります。問題は、増えた結果「誰のものか分からない」になることです。
最低限、台帳にはこれだけ入れると運用が変わります。
IDの種類（Member/Guest/Admin/Workload）
オーナー（責任者）
用途（何のために存在するか）
対象システム（どこに使うか）
期限／見直し日
例外（評価エンジンから除外しているか等）
「増えて良いIDを、増えても困らない形にする」ことが、運用を軽くします。
6-4. 条件付きアクセスは“評価エンジン”として、分類を入力にする
IDが増える環境で条件付きアクセスが破綻する理由は単純です。
対象が分類されていない
だから例外で回す
例外が増えるほど評価が読めない
解決策は、正社員／委託／外部／特権などの分類が、設定上の入力（グループ・属性）として揃っていることです。分類が揃えば、評価エンジンは再現性を取り戻します。
7. 立て直しの順番（現場で一番効果が出る順）
「いま増殖している」状況でも、全部やり直す必要はありません。効果が出やすい順番があります。
ゲスト（外部）に期限と棚卸しを入れる（増殖が止まりやすい）
休眠IDの洗い出しと“無効化→削除”の方針を決める
管理者IDを台帳化し、棚卸しの対象にする
Workload IDにオーナーと用途を必須化する
条件付きアクセスの除外を棚卸しし、例外を期限付きにする
この順番は、「事故の元になりやすい増殖」から潰す流れです。結果として、運用が軽くなりやすい。
8. まとめ：IDが増えるのは自然。問題は「出口の無さ」と「分類の無さ」
人数が横ばいなのにIDだけ増えるのは、珍しい現象ではありません。よくある原因は次の通りです。
出口（停止・削除・棚卸し）が弱い
再雇用・組織変更・UPN変更が“作り直し”を生む
管理者分離や外部招待が台帳なしで増える
Workload IDが自然増し、オーナー不明で残る
入口（発行ルート）が複数で重複が止まらない
そして、これが放置されると、
条件付きアクセス（評価エンジン）が例外だらけになる
棚卸しが終わらない
「入れない」が増える
監査で説明できない
運用が重くなる
という形で、必ず跳ね返ってきます。
だから最初にやるべきは「削除」ではなく、分類と入口・出口の整備です。
山崎行政書士事務所の技術支援（広告）
「人は増えていないのにIDだけ増える」状態は、ID基盤の運用が重くなる典型的な入口です。特に、外部ゲストの増殖、管理者IDの属人化、Workload IDのオーナー不明化、そして条件付きアクセス（評価エンジン）の例外増殖が重なると、設計者でも“なぜ通る／通らない”を説明できない構成に寄っていきます。
山崎行政書士事務所では、IdaaS × Azure（Microsoft Entra ID）領域で、ID増殖の「原因の切り分け」から「増えても回る運用」への立て直しまで、技術支援が可能です。例えば、
IDの分類（Member/Guest/特権/Workload）と、運用で維持できる属性・命名・台帳の整備
外部ゲストの期限・棚卸し（出口設計）を先に作り、増殖を止める
管理者ID／緊急IDを“増えて良い形”にする（責任境界、棚卸し、例外の期限化）
Workload ID（サービスプリンシパル／マネージドID）のオーナー・用途・権限を棚卸し可能な形へ
条件付きアクセスを“評価エンジン”として再現性のある設計に戻す（除外依存を減らし、例外は期限・台帳化）
IDが増えること自体を止めるのではなく、増えても判断できる・棚卸しできる・止められる形に整えることで、運用は確実に軽くなります。今の違和感は、設計の立て直しに入る合図です。
コメント