Intune 構成のエクスポート/バックアップ — 標準機能でどこまでできるか、4つの方法を比較

最終更新：2026-08-02

ポリシーを大きく変更する前に現状を控えておきたい。誤って消してしまったポリシーを元に戻したい。監査や引き継ぎに備えて設定一式を手元に残しておきたい——Intune の構成をエクスポート/バックアップしたい動機はさまざまです。ところが Intune には「テナント構成をまるごとバックアップして、あとで復元する」という標準機能がありません。この記事では、まず標準機能でできる範囲を正確に押さえたうえで、それを補う方法を目的別に比較します。

1. 何のためのエクスポートか — 目的で答えが変わる

最初に押さえたいのは、「エクスポート」と一口に言っても目的が2系統ある、という点です。どちらが目的かで、選ぶべき手段が変わります。

復元のため（バックアップ）：誤削除・誤変更からの復旧や、別テナントへの複製が目的。機械が読み戻せる形式（JSON など）で、設定を忠実に保存する必要があります。
記録のため（ドキュメント）：監査対応・引き継ぎ・変更管理が目的。人が読んで理解できる形式で、「いつ時点でどうだったか」を残す必要があります。

この2つは要件が異なるため、1つの手段で両方を完全に満たすのは難しいのが実情です。以降の比較でも、この区別を軸にします。

2. 標準機能でできること・できないこと

Intune 管理センターの標準機能で構成を取り出す手段は、現時点では次のとおりです。

設定カタログ形式のポリシーの JSON エクスポート/インポート：構成プロファイルのうち「設定カタログ」形式で作られたポリシーは、1本ずつ JSON ファイルにエクスポートでき、その JSON から新しいポリシーとして再作成（インポート）できます。誤削除への備えや、類似ポリシーの複製に使えます。
- 対象は設定カタログ形式のみです。テンプレート形式の構成プロファイルや、コンプライアンスポリシー・アプリ保護ポリシーなど他の種類のポリシーには、同様の UI エクスポートがありません。
- インポートは「同じ設定値を持つ新しいポリシーの作成」であり、割り当て（どのグループに適用するか）は引き継がれません。復元後に割り当てを設定し直す必要があります。
ポリシーの複製（Duplicate）：既存ポリシーのコピーを同一テナント内に作れます。こちらも割り当てはコピーされません。
一覧の CSV エクスポート：ポリシー一覧やレポート画面の「エクスポート」は、一覧表を CSV で保存するものです。ポリシー名や種別の棚卸しには使えますが、中の設定値までは含まれません。

つまり標準機能には「テナント構成をまるごと保存して、あとで復元する」手段はありません。設定カタログの JSON エクスポートも1ポリシー単位の手作業なので、テナント全体を定期的に控える用途には現実的ではありません。

3. 4つの方法を比較する

標準機能の不足を補う選択肢を、目的（復元/記録）と維持の手間で比較します。

方法	概要	向き	注意点
標準機能（設定カタログの JSON）	重要ポリシーを変更する前に、対象を1本ずつ JSON でエクスポートして保管する。	復元（個別）	追加コストゼロで今日から始められる。ただし対象は設定カタログ形式のみ・1本ずつ手作業・割り当ては含まれない。網羅的なバックアップにはならない。
Graph API で自前スクリプト	Microsoft Graph で構成を取得するスクリプトを書き、定期実行して JSON を蓄積する。	復元・記録の両方（作り込み次第）	最も柔軟だが、開発・実行基盤・API 変更への追従を自前で維持することになる。API の版（v1.0／beta）によって返る項目に差があり、取りこぼしに気づきにくい（当社の実測でも、割り当てフィルターなど v1.0 では返らない項目が相当数ありました）。作った人への属人化にも注意。
コミュニティ製のスクリプト/モジュール	Graph 経由で構成の一括バックアップ/復元を行う、コミュニティで公開されている PowerShell モジュール等（IntuneBackupAndRestore など）を使う。	復元（一括）	無償で網羅性も高い。一方でコミュニティ製ゆえ、自組織での動作検証・更新への追従・サポートは自己責任になる。組織のソフトウェア導入基準（OSS 利用ポリシー）の確認も必要。
専用ツール	構成の取得・保存・文書化を自動化する製品を導入する。	記録（＋定点の構成保存）	仕込んだ後の手間が最小で、人が読める文書や差分として出力されるものが多い。ツールの選定・費用と、そのツールが「復元」まで担うのか「記録」に特化しているのかの見極めが前提。

どの方法でも共通して重要なのは「自動で続くこと」です。大きな変更の前だけ手動で控える運用は、いちばん必要だった変更のときに限って抜けるものです。

4. 「復元用の JSON」は監査・引き継ぎには使えない

見落とされがちなのが、復元用のエクスポート（JSON）と記録用のドキュメントは役割が別、という点です。JSON はポリシーを機械的に再作成するには適していますが、監査人や引き継ぎ相手に「JSON を読んでください」とは言えません。逆に、人が読むために整形された設計書から、ポリシーを機械的に復元することもできません。

復元に備えるなら：JSON 系の手段（標準機能・スクリプト・コミュニティ製モジュール）で、設定を忠実に保存する。
監査・引き継ぎ・変更管理に備えるなら：人が読める形式で、日付入りの記録を定期的に残す。構成設計書の活用場面は関連記事で詳しく整理しています。
両方に備えるなら：手段の併用が現実解。目的が別なので、無理に1つへ寄せないほうが運用は安定します。

5. TenantSnap のアプローチ — 「記録」に特化

当社の TenantSnap は、この整理でいう「記録」側に特化したツールです。テナントの設定を変更しない設計（構成の取得のみ）のため、Intune へ書き戻す復元（リストア）機能はありません。復元用途には、前述の標準機能やコミュニティ製モジュールを併用してください。

取得のたびにテナント構成のスナップショット（JSON）を日付付きで保存し、そこから人が読める構成設計書（Word／PDF／Excel）を自動生成します。「機械が読める控え」と「人が読める記録」が同時に手に入ります。
定期実行（Windows タスクスケジューラ連携）で、日付入りのスナップショットと設計書が自動で蓄積されます。「大きな変更の前だけ手動で控える」運用の抜けがなくなります。
前回との差分レポートで「何が・どう変わったか」を変更者（UPN）付きで確認できます。誤変更に気づく早期警報としても機能します。
スナップショット・設計書はすべてお使いの端末（またはお客様が指定した保存先）に保存され、取得したデータを当社や第三者に送信しません。

Graph API の版による取りこぼし（v1.0 では返らない項目）については、当社側で beta からの補完を実装・保守しています。自前スクリプトで同じことをする場合に必要な「API 差分の追従」を、製品の責務として引き受けている形です。

6. まとめ

Intune にテナント全体のバックアップ/リストア機能はない。標準でできるのは、設定カタログ形式のポリシーを1本ずつ JSON でエクスポート/インポートすること（割り当ては含まれない）まで。
エクスポートの目的は「復元」と「記録」の2系統。要件が異なるため、選ぶ手段も変わる。
復元なら JSON 系（標準機能・自前スクリプト・コミュニティ製モジュール）、記録なら人が読める日付入りのドキュメント。両方に備えるなら併用が現実解。
どの手段でも「自動で続く」ことが肝心。手動運用は、いちばん必要なときに限って抜ける。

本記事の Intune の機能に関する記述は執筆時点の Microsoft 公式ドキュメント・管理センターの提供状況に、TenantSnap に関する記述は現行バージョンの実装に基づきます。Intune の機能・画面構成は Microsoft により変更されることがあります。最新の正確な情報は Microsoft の公式ドキュメントをご確認ください。