Google Workspace MDM（モバイルデバイス管理）は Android・iOS・Windows デバイスへのポリシーを一元配布できる一方で、設定変更がデバイスの挙動に即座に影響するため、変更のたびに情シス側のガバナンスが問われます。この記事では、GWS MDM 変更管理の承認フロー設計・GAS による変更履歴の自動記録・ロールバック判断の軸を整理します。
この記事を読んだほうが良い人
- Google Workspace MDM で Android・iOS・Windows デバイスを管理している情シス担当者
- MDM 設定変更の承認フローが整備されておらず「誰がいつ何を変えたか」が追えない状況にある方
- 誤設定が発生した際に迅速なロールバック手順を用意できていないと感じている方
- GAS を活用した変更履歴の自動記録を検討している方
GWS MDM 変更管理の必要性
デバイスポリシーの役割と影響範囲
GWS MDM のデバイスポリシーは、デバイスのセキュリティレベルからネットワーク接続まで広範な動作を制御します。主に以下のような設定が含まれます。
- セキュリティポリシー: 画面ロックの複雑さ要件、PIN の最小桁数、失敗回数によるデータ消去トリガー
- ネットワーク設定: 企業 Wi-Fi の SSID と認証情報、VPN 接続の強制適用
- アプリ管理: 必須アプリの強制インストール・削除、プライベートアプリの配布
- Windows カスタム設定: OMA-URI（Open Mobile Alliance Uniform Resource Identifier）経由でのレジストリおよび CSP（Configuration Service Provider）設定の配布
これらの設定は組織単位（OU）ごとに適用されるため、1 つのポリシー変更が数十台から数百台のデバイスに即座に反映されます。変更後に業務が止まるリスクが常に伴うのが、MDM 運用の現実です。
「変更記録がない」状態の危険性
インシデントが起きたとき、最初に問われるのは「直近でどこかを変えたか」という点です。GWS 管理コンソールの管理ログには管理者のアクションが記録されますが、「どのポリシーをなぜ変えたのか」「変更前の設定値は何か」という文脈情報は残りません。変更の意図・対象 OU・影響台数・ロールバック手順を事前に記録する体制があるかどうかが、インシデント対応の速度を決定的に左右します。
なお、GWS 管理コンソール側には変更前後のポリシー設定値を自動保存する機能がありません。Android・iOS デバイスへのポリシー反映状況を一覧確認するビューも提供されていないため、変更後の展開確認は別途の運用で補う必要があります。
変更管理フローの設計
変更管理フロー構築で最初に決めるべきは、影響度によるカテゴリ分類です。すべての変更に同じ承認コストをかけていては現場が回らず、かといって「軽微だから」とすべてを素通しにすると重大インシデントにつながります。
以下の 3 段階分類を判断の起点として使います。
| カテゴリ | 例 | 承認者 | 展開前テスト |
|---|---|---|---|
| 高影響 | 画面ロック要件の強化・データ消去ポリシー追加・強制アプリ配布 | 情シスマネージャー + 対象部門責任者 | テスト OU で最低 24 時間 |
| 中影響 | Wi-Fi 設定の更新・既存アプリのバージョン更新・通知設定変更 | 情シス担当者 2 名 | テスト OU で最低 2 時間 |
| 低影響 | 説明テキストの修正・ラベルの更新・ログ設定の微調整 | 担当者 1 名（自己承認） | 不要 |
高影響カテゴリでは、テスト OU での事前検証を省略しないことが鉄則です。「週次メンテナンスウィンドウに合わせて実施」のような時間帯の制約も、この段階で定義しておきます。
変更記録に必要な 7 項目
変更申請書（スプレッドシートでも Notion でも構いません）には最低限以下を記録します。
- 変更日時（計画値と実際の実施日時）
- 実施者氏名とレビュアー名
- 変更内容の概要（「画面ロックの PIN 最小桁数を 4 → 6 に変更」のような具体的な粒度）
- 対象 OU とデバイスグループ（影響台数の概算）
- 変更前の設定値（ロールバック時に参照する最重要項目）
- ロールバック手順の要約
- ステータス（計画済み / 実施済み / ロールバック済み）
この 7 項目が事前に記録されているかどうかが、ロールバック判断の速度に直結します。特に「変更前の設定値」が残っていない場合、ロールバック先が分からずに原因調査から始めなければならないという最悪のパターンに陥ります。
GAS で変更履歴をスプレッドシートに記録する
変更記録をスプレッドシートに手動入力する運用は担当者の負担が高く、記録漏れが発生しやすい点も課題です。Google Apps Script（GAS）を活用すると、変更申請フォームからの記録作業を自動化できます。
以下は、Google Form と連動した GAS で変更ログをスプレッドシートに書き込む基本実装です。Google Form で「MDM 変更申請フォーム」を作成し、フォームの質問として「変更カテゴリ」「実施者名」「対象 OU」「変更内容（概要）」「変更前の設定値」「ロールバック手順」の 6 項目を用意します。回答が送信されるたびにこの関数が実行されます。
// GAS: MDM 変更履歴の自動ログ記録
// トリガー: Google Form の送信時（フォーム連動スプレッドシートの onFormSubmit）
function onFormSubmit(e) {
const sheet = SpreadsheetApp.getActiveSpreadsheet()
.getSheetByName('変更ログ');
const responses = e.namedValues;
const changeCategory = responses['変更カテゴリ'][0];
const changedBy = responses['実施者名'][0];
const targetOU = responses['対象OU'][0];
const summary = responses['変更内容（概要）'][0];
const beforeValue = responses['変更前の設定値'][0];
const rollbackPlan = responses['ロールバック手順'][0];
const now = new Date();
sheet.appendRow([
now,
changeCategory,
changedBy,
targetOU,
summary,
beforeValue,
rollbackPlan,
'実施済み' // ステータス初期値
]);
// 高影響変更の場合は Slack 通知
// Webhook URL はスクリプトプロパティで管理し、コードに直書きしない
if (changeCategory === '高影響') {
const webhookUrl = PropertiesService.getScriptProperties()
.getProperty('SLACK_WEBHOOK_URL');
if (webhookUrl) {
const payload = {
text: `⚠️ MDM 高影響変更が記録されました\n` +
`実施者: ${changedBy}\n` +
`対象 OU: ${targetOU}\n` +
`変更内容: ${summary}`
};
UrlFetchApp.fetch(webhookUrl, {
method: 'post',
contentType: 'application/json',
payload: JSON.stringify(payload)
});
}
}
}
「高影響」変更が記録されたときだけ Slack 通知を飛ばすことで、担当者が即座に認識できる体制を作れます。スプレッドシートのヘッダ行は手動で タイムスタンプ / 変更カテゴリ / 実施者 / 対象 OU / 変更内容 / 変更前の値 / ロールバック手順 / ステータス の 8 列を設定します。Slack 通知は後から追加する形で、まず Form とスプレッドシートだけで動かし始めるのが現実的です。
ロールバック判断の優先度マトリクス
問題が発生したとき、ロールバックするかどうかの判断を素早く下せるかが運用品質を決めます。「業務影響度」と「ロールバックの難易度」の 2 軸で判断します。
以下のマトリクスを判断の出発点として活用します。
| ロールバック容易（設定を戻すだけ） | ロールバック困難（デバイス再登録等が必要） | |
|---|---|---|
| 業務影響：高（業務停止・データアクセス不可） | 即時ロールバック（30 分以内に着手） | 即時ロールバック + 代替手順を並行検討 |
| 業務影響：中（一部機能制限・不便あり） | 当日中にロールバック | 原因分析を先行し翌営業日までに判断 |
| 業務影響：低（軽微な表示崩れ等） | 次回メンテナンスウィンドウで対応 | 原因分析のみ・ロールバックは任意 |
「即時ロールバック」と判断した場合の初動は、変更ログの「変更前の設定値」と「ロールバック手順」の欄を見れば 30 秒で着手できる状態が理想です。これが 7 項目記録の必要性に直結します。
一点注意があります。ロールバックを「設定を元の値に戻すだけ」と楽観視しがちですが、Windows デバイスへの設定配布では反映に数分〜十数分かかることがあります。全台への反映確認が完了するまでを「ロールバック完了」と定義し、その間のモニタリング体制も計画に含めます。
変更管理体制の導入前チェックリスト
MDM 変更管理の体制を整備する前に、以下の観点を確認します。
台帳・記録体制
- 変更申請書（スプレッドシートまたはツール）の場所が全担当者に周知されているか
- 変更前の設定値を記録する欄が申請書に含まれているか
- 変更履歴の保存期間（最低 1 年を推奨）が決まっているか
承認フロー
- 変更カテゴリ別の承認者が明確に定義されているか
- 承認者が不在の場合の代理承認ルールがあるか
- 緊急変更（インシデント対応で即日実施が必要な変更）の例外フローが決まっているか
テスト環境
- テスト専用の OU が設定されているか（または実機テスト用デバイスが確保されているか）
- テスト OU への適用 → 確認 → 本番 OU への展開という手順が標準化されているか
ロールバック体制
- 各変更について「ロールバック手順」を変更前に記録する習慣があるか
- ロールバックの意思決定者（誰が「戻す」を判断するか）が決まっているか
- 深夜・休日の緊急ロールバック対応者の連絡先が整備されているか
すべてが整っている情シス組織は多くありません。まずは「変更前の設定値を記録する」1 点から始めるだけでも、インシデント対応の速度は大きく変わります。
まとめ
GWS MDM の変更管理で重要なのは、「設定できるかどうか」より「変えたときに何が起きるか・元に戻せるか」の設計です。
変更カテゴリの 3 段階分類で承認コストを適正化し、7 項目の変更記録を毎回取り、ロールバック判断マトリクスで即断できる体制を組み合わせることで、誰がいつ何を変えたかを追跡しながら問題発生時に 30 分以内で復旧着手できる運用基盤が整います。
GAS による変更フォームの自動記録は、担当者の記録負担を最小化しながら精度を高める実用的な手段です。Slack 通知は後から追加する形で、まずフォームとスプレッドシートだけで始めても十分に機能します。次の一手は、自組織の変更申請書テンプレートに「変更前の設定値」欄と「ロールバック手順」欄を追加することです。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。