金曜の夜に「営業の◯◯さんがスマホを電車に置き忘れた」と連絡が入る。会社のGmailもドライブも入っている端末です。すぐ止めたい。でも管理コンソールで端末をブロックできるのは特権管理者だけで、その人は出張中で電話が繋がらない——。
似た形で、退職者の端末が数週間そのままになっているケースもよく見ます。総務は退職手続きを終えている。情シス担当は「アカウントは止めた」と思っている。ところが端末側の会社データは消えていない。誰の仕事か決まっていなかったからです。
この詰まり方には共通の原因があります。Google Workspace の端末管理が、長らく「特権管理者かどうか」というほぼ全か無かの権限だったことです。拠点の担当者に任せたいが、特権管理者を渡すと請求先も他人のパスワードもドメイン設定も触れてしまう。だから渡せない。渡せないから1人に集中する。
2026年6月29日から全ドメインへの提供が始まった組織部門（OU）単位の端末管理権限委任は、ここを崩すためのものです。
「全部渡すか、何も渡さないか」をやめる
Google Workspace の管理者権限は、あらかじめ用意された役割をそのまま割り当てるだけでなく、カスタム役割を作り、その適用範囲を特定の組織部門（OU）に限定できます。この仕組み自体は以前からありましたが、モバイル端末管理の権限についても OU 単位でスコープを切れるようになりました（Delegate device management administrator privileges — Google Workspace Admin Help）。
たとえば「大阪支社」という OU を作ってそこに所属する社員を入れておけば、大阪支社の担当者には大阪支社の端末だけを管理する権限を渡せます。本社や他拠点の端末は見えません。人事情報も請求情報も触れません。
やってもらえるのは、その OU の範囲内での次の作業です。
- 端末の一覧と詳細の確認
- 端末の承認・ブロック・削除・データの消去（ワイプ）
- モバイル端末・エンドポイント向けの設定の適用
冒頭の「金曜の夜に止めたい」も「退職者の端末を消したい」も、この範囲に入ります。つまり現場でいちばん時間が惜しい操作は、拠点に渡せるということです。
渡せないものを先に把握しておく
委任を設計するときに事故が起きやすいのは、「任せたつもりが任せられていなかった」パターンです。OU 単位の権限を持つ管理者ができないことは明確に決まっています。次の作業は最上位の組織に対する権限を持つ管理者だけが行えます。
| 作業 | OU単位の管理者 | 最上位組織の管理者 |
|---|---|---|
| 端末の確認・承認・ブロック・削除・ワイプ | できる（担当OU内のみ） | できる |
| 端末向け設定の適用 | できる（担当OU内のみ） | できる |
| 端末レポート・ログイベントの参照 | できない | できる |
| ルールによる端末管理の自動化 | できない | できる |
| ウェブアプリ・モバイルアプリの管理 | できない | できる |
| Apple VPP による iOS アプリ配布 | できない | できる |
| Apple プッシュ証明書の管理 | できない | できる |
この表の下半分は、「日々の対応」ではなく「仕組みの設定」にあたるものです。監査ログを見る、自動化ルールを組む、配布するアプリを決める、iOS 管理の土台となる証明書を更新する。いずれも組織全体に影響します。
実務上いちばん引っかかるのが Apple プッシュ証明書です。これは有効期限があり、切れると iOS 端末の管理が止まります。更新できるのは最上位組織の管理者だけなので、「iOS の管理は拠点に任せた」つもりでも、証明書の更新責任は本社に残ります。ここを渡し忘れたまま担当者が変わると、期限切れで一斉に管理不能になります。
同様に、ログイベントを見られないという制約も設計に効きます。拠点の担当者は「誰の端末をいつワイプしたか」を後から追えません。追跡の責任は本社側に残る、という前提で運用ルールを書く必要があります。
中小企業での現実的な切り分け方
社員数が数十人規模だと「OU を分けるほどの組織じゃない」と感じるかもしれません。それでも、権限を1人に集中させたままにするリスクは残ります。切り分けの入り口は、組織図ではなく「連絡が取れる時間帯」で考えると決めやすくなります。
現実的なのは次の2パターンです。
拠点・事業所で分ける。 本社と別拠点があり、拠点側に総務担当がいる場合。拠点の端末は拠点で止められるようにします。時差や移動を挟まないぶん、初動が確実に速くなります。
役員・機密部門だけを分ける。 拠点はないが、経営陣や人事・経理の端末は別扱いにしたい場合。全社を1人の担当者に任せつつ、役員 OU だけを対象外にするという切り方ができます。委任される側にとっても、触れない範囲が明示されているほうが気が楽です。
どちらの場合も、渡す相手を決める前に「誰が何をやるか」を1枚の紙に書くことをおすすめします。紛失連絡の窓口は誰か、その人が不在のときは誰か、ワイプを実行する判断は誰がするのか。権限を渡しただけでは、判断は誰も引き受けません。
端末管理そのものをまだ始めていない場合は、会社のPC、誰がどう守っていますか — Google Workspaceだけで始めるWindows端末管理から先に読むと順序が整理できます。iOS 側の設定はGoogle エンドポイント管理のiOS設定、管理コンソールの基本操作はGoogle Workspace 管理コンソールの使い方にまとめてあります。
権限を分けることは、責任を薄めることではない
「権限を渡すと統制が緩む」という反応をよく受けますが、この件については逆に働きます。
特権管理者を渡すしかなかった時代は、「渡さない」という選択がそのまま初動の遅れになっていました。端末を止められない時間が数時間から数日続く。その間のリスクは、権限を分散させるリスクよりはるかに大きい。
一方で、OU 単位の権限は触れる範囲が定義されているぶん、後から棚卸ししやすくなります。誰がどの OU に対して何の権限を持っているかは、管理コンソールの役割の一覧で確認できます。特権管理者が3人いる状態より、はるかに説明可能です。
セキュリティ設定全体の見直しをする段階なら、Google Workspace セキュリティ設定チェックリストと突き合わせながら進めると漏れが出にくくなります。
今週やること
管理コンソールで、特権管理者が何人いるかを数えてください。そのうえで「社員のスマホ紛失が今晩起きたら、誰が何分で端末をブロックできるか」を書き出してみる。
その答えが「1人しかいない」「その人が捕まらない可能性がある」なら、カスタム役割を1つ作って、端末管理の権限だけを対象の OU に絞って渡す。まずは1拠点、1担当者から始めれば十分です。渡したあとで、Apple プッシュ証明書の期限だけは本社のカレンダーに登録しておいてください。
情シス専任がいない体制で Google Workspace の権限設計と端末管理を回る形にしたい——そうしたご相談は、グリームハブのIT・Google Workspace 無料相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
