Microsoft Entra ID の構成設計書の作り方 — 載せるべき項目と、手作業・ツールでの出力方法
最終更新：2026-10-12
Intune の設計書は作っているが、その土台にある Entra ID（旧 Azure AD）の構成は文書になっていない——という組織は少なくありません。ところが監査で問われやすいのは、むしろ ID 基盤の側です。誰が特権ロールを持っているか、どのアプリにどの権限が同意されているか、多要素認証をどう求めているか。Microsoft Entra 管理センターは設定を1画面ずつ確認する作りで、構成全体を1つの文書として出力する機能はありません。この記事では、Entra ID の構成設計書に何を載せるべきかを整理し、作り方の選択肢を比較します。
1. Entra ID の設計書が求められる場面
- 監査・認証の取得と更新：ISMS（ISO 27001）や内部統制の監査では、アクセス制御・特権の管理・認証の強度を文書で示すことが求められます。ID 基盤はその中心です。
- 特権とアプリ権限の棚卸し：特権ロールの割り当てやアプリへの同意は、一度付与されると見直されないまま残りがちです。定期的な点検の起点として、現在の構成の一覧が必要になります。
- 担当者の交代・引き継ぎ：条件付きアクセスの除外対象や、緊急用アカウントの扱いなど、設定の意図は画面を見ても分かりません。引き継ぎでは構成とあわせて「なぜそうしているか」を渡す必要があります。
- 顧客への納品（SIer・MSP）：Microsoft 365 や Intune の導入案件では、Entra ID の構成も成果物の一部として納めることが多く、運用受託では定期的な報告も求められます。
2. 設計書に載せるべき項目
Entra ID の設定は管理センターの多くの画面に分かれています。監査や引き継ぎで説明を求められやすいものを中心に、主な項目を整理すると次のとおりです。
| 分類 | 主な項目 | 載せる理由 |
|---|---|---|
| テナント全体の設定 | 既定のユーザー権限（アプリ登録・ゲスト招待の可否）、セキュリティの既定値、組織情報とカスタム ドメイン、グループの作成可否や命名規則 | 「利用者に何を許しているか」の土台。初期値のまま運用されていることも多く、意図して決めた値かどうかを確かめる材料になる |
| 認証とアクセス制御 | 条件付きアクセス ポリシーと名前付きの場所、認証方法ポリシー、認証強度、セルフサービス パスワード リセット | 多要素認証をどの条件で求めているかは、監査で最も問われやすい項目。ポリシーの除外対象まで載せないと実態を説明できない |
| 特権の管理 | ディレクトリ ロールの割り当て先、PIM（特権の資格と有効化の条件）、管理単位 | 誰が特権を持っているかは棚卸しの中心。GUID ではなくユーザー名・グループ名で読める形にする |
| アプリケーション | アプリ登録（要求する API 権限・資格情報の有効期限）、エンタープライズ アプリ、アプリに同意された権限、アプリへのアクセス割り当て | 過剰な権限や期限切れ間近のシークレットの点検に使う。鍵やシークレットの値そのものは載せない |
| 外部との連携 | 外部コラボレーションの設定、クロステナント アクセス（受信・送信・組織ごとの個別設定） | 社外のユーザー・組織にどこまで入らせているかを示す |
| ID ガバナンス | アクセス レビュー、エンタイトルメント管理（アクセス パッケージ）、ライフサイクル ワークフロー | 権限の付与と見直しが仕組みとして回っていることの証跡になる（いずれも追加ライセンスが前提） |
| オンプレミスとの同期 | Active Directory との同期の構成（同期の範囲・属性の対応） | ハイブリッド構成では、どのアカウントがどこから来ているかの説明に欠かせない |
| ユーザー・グループ・デバイス | 件数と内訳（メンバー／ゲスト、同期／クラウドのみ、参加の種類など）、明細 | 本文は件数のサマリーにとどめ、明細は付録に分けると読みやすい。個人の情報を含むため配布範囲にも注意する |
3. 手作業で作るときにつまずく点
- 画面が分かれていて、出力の手段もまちまち：ユーザーやグループの一覧は CSV でダウンロードできますが、条件付きアクセスやアプリの権限、テナント全体の設定は画面で1つずつ開いて転記することになります。構成全体を1つの文書にまとめる機能はありません。
- ID のままでは読めない：ロールの割り当て先、条件付きアクセスの対象・除外、アプリの権限などは、内部では GUID で管理されています。PowerShell や Graph で取得した値を文書にするには、ユーザー名・グループ名・権限名への名前解決が必要です。
- 変化が速い：ユーザー・グループ・アプリは日々増減し、条件付きアクセスも例外対応で書き換えられます。作った時点で正しくても、数か月で実態とずれていきます。
- 「誰が・いつ変えたか」を後から追えない：Entra ID の監査ログの保存期間は、Entra ID Free で7日、P1／P2 で30日です。それより前の変更は、ログをストレージ等へ転送していない限り確認できません。設計書の更新が数か月おきだと、その間の変更の経緯は残りません。
- 載せてはいけない情報がある：アプリのシークレットや証明書の値、個人のパスワード情報などを転記しないよう、手作業では注意が要ります。
4. 設計書を作る方法を比べる
| 方法 | 概要 | 向き | 注意点 |
|---|---|---|---|
| 手作業（画面・CSV） | 管理センターの画面を開いて Word や Excel に転記する。一覧は CSV で書き出す。 | 小規模なテナントで、一度きり作る場合 | 追加コストはゼロ。ただし網羅性と正確さが作成者に依存し、更新のたびに同じ工数がかかる。 |
| Microsoft365DSC | PowerShell モジュールで Entra ID を含む Microsoft 365 の構成を書き出す。構成の比較や、あるべき状態との差の検出にも使える。 | 構成をコードとして管理したい、技術者がいる組織 | 無償で対象範囲も広い。出力は構成のコード（PowerShell の構成ファイル）が中心で、人が読む設計書には整形が必要。オープンソースのため、動作検証と更新への追従は自己責任になる。 |
| EntraExporter | Microsoft の GitHub で公開されている PowerShell モジュールで、Entra ID の構成をローカルの JSON ファイルに書き出す。Git などで履歴を管理する用途を想定している。 | 構成のバックアップや履歴を技術者が管理する場合 | 無償。出力は JSON のため、監査人や顧客に渡す文書にするには別途の加工が要る。サポートは GitHub の Issues に限られ、サポート窓口は前提にできない。 |
| Graph API・PowerShell で自前実装 | Microsoft Graph から必要な項目を取得し、自前のスクリプトで文書に整形する。 | 自社の書式・項目に合わせて作り込みたい場合 | 最も柔軟だが、GUID の名前解決、ライセンスによって取得できない項目の扱い、API の変更への追従を自分で抱えることになる。 |
| 専用ツール | 構成の取得から文書の生成までを行う製品を使う。 | 設計書を定期的に作り直す・納品する場合 | 導入後の手間が小さい。取得できる範囲、出力の形式（Word・Excel など）、取得したデータをどこで処理するか、費用を確認して選ぶ。 |
どの方法を選ぶ場合でも、設計書は「その時点の構成」を写したものです。作成日を明記して残し、定期的に作り直せる方法を選ぶと、実態とのずれを小さく保てます。
5. 設計書を作るときのポイント
- 本文はサマリー、明細は付録に分ける：ユーザーやグループのメンバーの明細は量が多く、個人の情報も含みます。本文は件数と方針にとどめ、明細は付録として配布範囲を分けられるようにします。
- 秘密の値は載せない：アプリのシークレットや証明書は、値ではなく有効期限などの情報だけを載せます。期限切れの管理にはそれで足ります。
- 名前で読める形にする：ロールの割り当て先や条件付きアクセスの対象は、GUID ではなくユーザー名・グループ名で記載します。
- 変更の記録は監査ログの保存期間内に：「誰が・いつ変えたか」まで残したい場合は、監査ログの保存期間（Free で7日、P1／P2 で30日）より短い間隔で構成を取得し、前回との差分を記録します。
- 設定の意図を書き添える：条件付きアクセスの除外や緊急用アカウントなど、設定値だけでは意図が伝わらない項目には、理由を一言添えておくと引き継ぎで役立ちます。
6. TenantSnap for Microsoft Entra ID の場合
当社の TenantSnap には、Entra ID のテナント構成を取得して「Microsoft Entra ID 構成設計書」を生成する Entra ID 版があります。上で挙げた項目を、次のように扱います。
- 取得する範囲：テナント設定・組織プロファイル、ユーザー・グループ、ディレクトリ ロールと PIM、条件付きアクセス・認証方法・認証強度・SSPR、デバイスの登録設定と LAPS、アプリ登録・エンタープライズ アプリ・アプリへの同意、ID ガバナンス、クロステナント アクセス、オンプレミス同期（Entra Connect クラウド同期）などを取得します。詳しくは「取得できる項目」のガイドをご覧ください。
- 文書の形：Word（.docx）／PDF／Excel（.xlsx）の日本語の設計書として出力します。ユーザーやメンバーの明細は付録にまとめ、付録を出力するかどうかも選べます。ロールの割り当て先などは名前で記載します。
- ライセンスによる違い：PIM やアクセス レビューなど、Entra ID P1／P2／Governance が前提の項目は自動で判定し、取得できない章だけを「取得不可」と表示して、ほかの章は通常どおり出力します。
- 変更の記録：前回取得した構成との差分を Entra の監査ログと突き合わせ、「誰が・いつ」変更したかを付けて記録します。監査ログの保存期間を踏まえ、週に1回以内の間隔での実行をおすすめしています（Entra ID Free のテナントでは保存期間が7日のため、それより短い間隔で実行してください）。
- 機微な情報の扱い：アプリ登録の鍵・シークレットの値は取得せず、有効期限などのメタデータだけを扱います。設計書にも平文を残しません。
- データの扱い：設定の取得では、お客様のテナントの設定を変更しません（Entra ID 版の取得に必要な権限は読み取り専用です。テナントに書き込むのは、管理者が任意で実行する本製品用のアプリ登録の準備だけです）。取得したデータはお使いの端末内で処理し、当社や第三者に送信しません（外部との通信は Microsoft の公式エンドポイントだけです）。
Entra ID 版と Intune 版は同じアプリで動き、ライセンスは製品ごとに別です。14日間の無料トライアルでは、Intune 版・Entra ID 版とも PDF（「評価版」の透かし入り）で出力してお試しいただけます。
7. まとめ
- Entra ID の設計書で特に問われるのは、認証とアクセス制御、特権の割り当て、アプリに与えた権限。除外対象や割り当て先まで、名前で読める形で載せる。
- 管理センターには構成全体を文書として出力する機能はなく、手作業では網羅性と更新の手間が課題になる。
- 作り方は手作業・Microsoft365DSC・EntraExporter・Graph での自前実装・専用ツール。人が読む文書が必要か、定期的に作り直すかで選ぶ。
- 監査ログの保存期間は Free で7日、P1／P2 で30日。変更の経緯まで残すなら、その期間より短い間隔で構成を取得して差分を記録する。
本記事の Microsoft Entra ID・Microsoft Graph・Microsoft365DSC・EntraExporter に関する記述は執筆時点の公式ドキュメント・公開リポジトリに、TenantSnap に関する記述は現行バージョンの実装に基づきます。各サービスの機能・提供条件は変更されることがあります。最新の正確な情報は各公式ドキュメントをご確認ください。