構成設計書の活用方法 — 作って終わりにしない5つの場面

1. セキュリティ監査・認証審査 — 「説明できる状態」の証拠として

ISMS（ISO 27001）や取引先のセキュリティ調査では、「端末管理・ID 管理をどのような方針で行っているか」「その方針が実際に適用されているか」を示す資料が求められます。管理センターの画面を監査人と一緒に眺める方法もありますが、時間がかかるうえ、その場で見えた断片しか示せません。

• 使いどころ：監査の事前提出資料・審査当日の閲覧資料として、設定の一覧と割り当て状況をそのまま提示します。「この統制は設定で担保している」という主張に、対応する章のページを添えられます。
• 使う人：情報システム担当（被監査側）と監査人・審査員。
• ポイント：監査で効くのは「その時点の構成が記録されていること」です。日付入りの設計書を定期的に残しておけば、「いつの時点でどうだったか」を遡って示せます。

設計書には組織の内部情報（ポリシーの詳細・グループ名など）が含まれます。社外の監査人へ渡す際は、含まれる情報の範囲と取り扱い（返却・破棄）を事前に取り決めておくと安全です。

2. 引き継ぎ・属人化対策 — 「頭の中」を文書にする

Intune の設定は担当者の頭の中にだけ全体像がある、という状態になりがちです。担当者の異動・退職・長期休暇のたびに「この設定は何のためにあるのか」が失われていきます。

• 使いどころ：引き継ぎ資料の土台として。設定の「現状」は設計書がすべて持っているので、引き継ぐ人は「なぜそうしているか（設計意図）」と「触るときの注意」だけを書き足せば済みます。ゼロから引き継ぎ資料を書くのに比べ、書く量が大きく減ります。
• 使う人：前任者と後任者。ヘルプデスクへの一次情報としても機能します。
• ポイント：設計意図は Intune のポリシー説明欄に書いておく習慣にすると、誰が設計書を作っても意図ごと引き継がれます。説明欄が空の設定は「意図が失われかけている設定」のリストとして、そのまま棚卸しの入口になります（詳しくは関連記事「Intune 構成の棚卸し」をご覧ください）。

3. 変更管理・トラブル調査 — 「あの日どうだったか」に答える

「先週から一部の端末で挙動が変わった。設定を誰か変えたのか？」——この問いに答えられるかどうかは、変更前の状態が記録されているかで決まります。管理センターは常に「現在の構成」しか見せてくれません。

• 使いどころ：障害・問い合わせ調査の起点として、疑わしい時期の前後の設計書（または差分レポート）を突き合わせ、変わった設定を特定します。変更管理のプロセスがある組織では、変更実施後の「実施結果の証跡」としても使えます。
• 使う人：情報システム担当・運用ベンダー。インシデント報告書の添付資料にもなります。
• ポイント：この使い方は「定期的に記録が残っていること」が前提です。事件が起きてから作った設計書には「事件前」が写っていません。だからこそ、設計書は一度きりの成果物ではなく定期的なスナップショットとして残す価値があります。

なお「誰が・いつ変えたか」まで追うには監査ログが必要ですが、Intune の監査ログは約30日で消えます。証跡の保全は別途仕込んでおく必要があります（関連記事で詳しく解説しています）。

4. 環境の標準化 — 複数環境の「ズレ」を見つける

検証環境と本番環境、国内拠点と海外拠点、あるいは SIer・MSP が預かる複数の顧客テナント。「同じはず」の環境が実際には少しずつズレている、というのはよくあることです。ズレは設定の適用漏れやセキュリティ水準の差として表面化します。

• 使いどころ：各環境の設計書を同じ形式で作り、章立てを揃えて突き合わせます。形式が揃っていれば、差分の確認は「同じ章の同じ表を見比べる」作業になります。
• 使う人：複数環境を運用する情報システム部門、複数の顧客テナントを預かる SIer・MSP。標準構成（ゴールデン構成）からの逸脱チェックを納品物にすることもできます。
• ポイント：手作業ではここが最も苦しい使い方です。1環境ぶんの設計書づくりに数日かかる方法では、比較のたびに数日×環境数のコストが発生します。ここは自動化の効果が最も大きい場面です。

5. 非技術者への説明 — 経営層・取引先・情報共有

「うちの端末管理はどうなっているのか」という経営層からの問い、取引先からのセキュリティチェックシート、社内の他部門への説明。相手は Intune の画面を見ても分かりませんが、体系立った文書なら「管理が行き届いているか」は伝わります。

• 使いどころ：説明資料の裏付けとして。要約スライドの後ろに設計書を控えさせておき、「詳細はこの文書のとおり」と示せる状態を作ります。チェックシートの回答根拠としても、該当章を引用できます。
• 使う人：情報システム部門の管理職・経営層への報告者。
• ポイント：この用途では「整った文書であること」自体が信頼の材料になります。画面キャプチャの寄せ集めと、目次・章立てのある文書とでは、同じ内容でも伝わり方が変わります。

6. 棚に眠らせないために — 「最新である」ことが価値の源泉

ここまでの5つの場面には共通点があります。どれも「設計書が現状と一致している」ことが前提だという点です。半年前の設計書は、監査でも引き継ぎでも調査でも「まず現状と照合する」という余計な工程を生み、やがて誰にも信用されなくなります。

• 更新の仕組みを先に決める：「変更したら設計書も直す」という運用ルールは、忙しくなると最初に破られます。定期的に自動で作り直される仕組みにしておくのが現実的です。
• 版を残す：最新版で上書きせず、日付入りで残します。場面1（監査）と場面3（調査）は過去の版があってはじめて成立します。
• 作る手間を限りなくゼロに：更新が続くかどうかは、結局「1回作るのにかかる手間」で決まります。手作業で数日かかる方法は、どれほど立派な初版ができても更新が続きません。

7. TenantSnap を使う場合

当社の TenantSnap は、この「使われ続ける設計書」に必要な要素を自動化しています。テナントの設定を変更しない設計（構成の取得のみ）で、取得したデータを当社や第三者に送信しません。

• 監査・説明資料に：既定で全37章＋付録の体系立った設計書（Word／PDF／Excel）を、ワンクリックの自動処理で生成します。管理者パスワードなどの機微フィールドは保存時に自動でマスクされます。
• 引き継ぎに：Intune の説明欄に書いた設計意図は「運用メモ」として設計書に前面表示され、未記入の設定は巻末に一覧化されます。
• 変更管理に：定期実行で日付入りのスナップショットが自動で溜まり、差分レポートで「何が・どう変わったか」を変更者（UPN）付きで確認できます。監査ログのアーカイブにも対応しています。
• 標準化に：テナント間比較で2つの環境の構成を突き合わせられます。複数テナントの設計書の一括生成（MSP）にも対応しています。

• 設計書サンプル（PDF）を見る
• 定期実行・無人実行の設定（ガイド）
• 関連記事：手作業の設計書づくりはなぜ続かないのか
• 関連記事：Intune 構成の棚卸し
• 関連記事：Intune の監査ログは約30日で消える

8. まとめ

• 設計書の価値は「作ること」ではなく「使われること」。監査・引き継ぎ・変更管理・標準化・説明の5つが主戦場。
• 5つの場面すべてが「設計書が最新である」ことを前提にしている。更新が続かない設計書は、どの場面でも役に立たない。
• 更新を続ける鍵は運用ルールではなく仕組み。作る手間を自動化でゼロに近づけ、日付入りの版を残す。