Intune の構成設計書を手作業で作り続けるのは、なぜ大変なのか

1. 設計書が求められる場面

Intune の構成設計書（パラメータシート・環境定義書と呼ばれることもあります）が必要になる典型的な場面は、次の4つです。

• 監査・コンプライアンス対応：ISMS（ISO 27001）や内部統制の監査で、デバイス管理の設定状況を文書で示す必要があるとき。
• 引き継ぎ・体制変更：担当者の異動・退職で、頭の中にしかない設定の意図と経緯を次の担当者へ渡すとき。
• 障害・問い合わせ対応：「いつからこの挙動なのか」「何を変えたら直るのか」を調べる起点として、当時の構成を確認したいとき。
• 顧客への納品（SIer・MSP）：構築や運用受託の成果物として、顧客テナントの構成書類を納めるとき。

共通するのは、「管理センターにログインして見ればわかる」では通用しない相手（監査人・後任者・顧客）に対して、その時点の構成を切り出して渡す必要がある、という点です。

2. 手作業で作る場合、実際に何をするのか

Intune 管理センターには構成全体のエクスポート機能がないため、手作業での設計書づくりは概ね次の流れになります。

1. 管理センターの各ブレード（デバイス構成、コンプライアンス、アプリ、条件付きアクセス、登録設定…）を順に開く。
2. ポリシーごとに設定画面を開き、設定値を Word や Excel に転記する（またはスクリーンショットを貼る）。
3. 割り当て先のグループ・フィルターを確認し、対応関係を書き写す。
4. 文書としての体裁（目次・章立て・表）を整える。

所要時間はテナントの規模と文書に求める粒度によって大きく変わりますが、ポリシー数が数十を超える環境で設定値まで書き起こすなら、日単位の作業になるのが実感に近いはずです。設定カタログのポリシーは1つで数十〜数百の設定項目を含むことがあり、これを画面から漏れなく転記するのは相当な集中力を要します。

Graph API や PowerShell で設定を取得するスクリプトを書く方法もあります。エクスポート自体は自動化できますが、取得結果は JSON であり、「監査人や顧客に渡せる文書」にするには結局、整形・和訳・体裁づくりの工程が残ります。スクリプトのメンテナンス（API の変更追従）も継続的な負担になります。

3. 手作業の設計書が構造的に抱える3つの課題

手作業の設計書づくりの本当の課題は、初回の工数よりも、その後にあります。

• 完成した瞬間から古くなっていく：Intune の構成は日々変わります。設計書の更新が変更のたびに行われることは稀で、実態と文書の乖離は時間とともに広がります。乖離した設計書は「参考程度」の扱いになり、いざという場面で使えません。
• 作った人しか全体を知らない（属人化）：どのブレードを見て、どの粒度で書いたかは作成者の判断です。更新も同じ人に依存しがちで、その人の異動・退職と同時に「もう誰も全体を把握していない」状態になります。
• 網羅性を担保しにくい：管理センターの画面構成は頻繁に変わり、新しい設定領域も増え続けます。「全部書いたつもり」の設計書に条件付きアクセスや割り当てフィルターが抜けていた、という類の漏れは、レビューでも見つけにくいものです。

4. 運用プロセスで対処する方法

これらの課題への正攻法は、変更管理プロセスを整えることです。変更申請と承認のフローを定め、変更のたびに設計書の該当箇所を更新し、四半期ごとに棚卸しでズレを補正する。この運用が回っている組織は実際にあり、回るのであればそれが確実な方法です。

一方で、この運用の維持には相応の規律とリソースが要ります。設計書の更新が「変更作業に付随する事務」として扱われると、繁忙期に真っ先に省略され、気づいたときには乖離が戻せない規模になっている——という経過をたどりがちです。専任の管理者を置きにくい規模の組織や、複数の顧客テナントを少人数で見る MSP では、プロセスだけで維持しきるのは現実には難しい、というのが率直なところだと思います。

5. 自動生成という選択肢

もう1つの選択肢は、設計書そのものをテナントから自動生成することです。この方式の本質的な利点は、初回の工数削減よりも「いつでも作り直せる」ことにあります。実態と文書の乖離という手作業の最大の課題が、「必要になったらその場で最新版を出力する」ことで構造的に解消されるためです。

自動生成ツールを検討する際に確認したい要件は、次の4点です。

• 網羅性：主要なブレードを漏れなくカバーしているか。設定カタログの設定値詳細まで出るか。
• 文書としての体裁：JSON やそのままの英語キーの羅列ではなく、監査人・顧客にそのまま渡せる章立て・日本語の文書になるか。
• 変更の追跡：時点間の差分が取れるか。「誰が・いつ変えたか」まで追えるか。
• データの扱い：テナントの構成情報という機微なデータを、どこで処理し、どこへ送るのか。テナントの設定を変更しないか。

6. TenantSnap の場合

手前味噌になりますが、当社の TenantSnap はまさにこの用途のためのデスクトップアプリです。上の4要件に対しては次のように設計しています。

• 網羅性：既定で全37章＋付録の構成設計書を出力します（第1部 共通設定〜第7部 変更履歴。Linux・Windows 365 は任意で追加でき、章番号は出力する部に応じて自動で振り直されます）。設定カタログはポリシーごとの設定値詳細まで掲載します。
• 体裁：Word／PDF／Excel の日本語の文書として出力します。初回設定のあとは、取得から生成までワンクリックの自動処理で完了します（所要時間はテナントの規模により、数分〜数十分かかることがあります）。
• 変更の追跡：前回取得分との差分を Intune の監査ログと突合し、変更者（UPN）付きで変更履歴の章に自動記録します。
• データの扱い：テナントの設定を変更せず（Intune／Entra ID の取得に使う権限は読み取り専用です）、取得したデータはお使いの端末内で処理します。当社や第三者に送信することはありません（通信先は Microsoft の公式エンドポイントのみです）。

実際にどんな文書が出力されるかは、検証環境のサンプルをそのままダウンロードして確認できます。

• 設計書サンプル（PDF）を見る
• 取得できる項目の一覧（ガイド）
• セキュリティとデータの取り扱い（ガイド）

手作業の設計書づくりに時間を取られている方、更新が止まった設計書に心当たりのある方は、まず14日間の無料トライアルでご自身のテナントの設計書を出力してみてください。「この作業は自動化できる」という感覚が、最初の1回でつかめるはずです。