はじめに
どーもbarusuです。
12月ですね。世の中は結構寒いらしいんですが、我が家は暖かいところにあるらしく暖房無しで室温28度あります（マジ）。
今年もやってきましたこの時期が。アドベントカレンダー2025です。
今年は我が運用支援チームで持ち回り執筆していきます。よろしゅう。
Cloudnative IRS Advent Calendar 2025 – Adventar
さて本題。今日はGoogle Workspace管理運用のお話です。
「Google Workspaceの設定、正直よく分からないので一度プロの目で全部見てもらえませんか？」
直近半年くらい、上記のようなご相談をいただく機会が増えております。
こういうモヤモヤを一度リセットしたいニーズがあるんでしょうかね。
ウチもそうなんすよ！ってお客様がけっこう潜在的にいらっしゃいそうなので、どういうことやるのか〜とかをご説明します。
なぜ Google Workspace の環境調査が必要なのか
実際に困っているお客様のお話を伺っていると、割と共通しているものがありました。
1. 多機能 = 多項目
Google Workspace の管理コンソールは機能が増えるたびにメニューも設定も増えていきます。
- ディレクトリ
- アプリ
- セキュリティ
- デバイス管理
- Chrome 管理
- Vault …
改めてみるとちょっと多いですねー。
慣れると多く感じないんですけどね。慣れって怖い。
「誰も全体像を説明できないけど、とりあえず動いている」
この状態は、運用の観点でも、監査・セキュリティの観点でも、どこかで必ずボトルネックになりますからね。
ご相談いただいたお客様各社、この要望は特に共通してましたね。ほな全部見るしかないか。
2. 組織部門が細分化されがち
さらによく聞く悩みはこのあたりです。
- 設定箇所が多すぎて、どこから確認していいか分からない
- 組織部門ごとの差異が把握できない
- 前任者が何を意図して例外設定を作ったのか分からない
- 「セキュリティ強化したい」が、どこをどう触っていいか分からない
真面目にやろうとすると、「全部見にいくしかない」のですが、本業の合間にそれをやるのは現実的ではありません。
というか疲れる。AIで解決できないのか？って感じです。ほなやるしかないか。
3. 監査・インシデント対応・設計変更で全体像が必要になる
- ISMS や SOC2 などの認証・監査対応が始まる
- 社外との情報共有ルールをきちんと整えたい
- 過去にヒヤリ・ハット（意図せぬ共有、誤送信など）があった
- M&A・グループ再編で Google Workspace の統合や整理が必要になった
「そういえば、うちの Google Workspace、ちゃんと説明できる人いなくない？」
という現実に直面したお客様から相談されることもありました。
ほな「説明できる人」になるしかないか。
運用支援の環境調査でどこまで分かるのか
まったく分からん状態 → 「8割は把握できている」と言える状態までもっていくことがゴールです。大抵の場合は。
もう少し分解すると、以下のような状態を目指していきます。
1. 今の設定が「地図」として見えるようになる
- 管理コンソールの主要な設定が一覧化される
- 組織部門ごと・アプリごとに「どこがどう違うか」が分かる
- 例外設定がどこに存在しているかが分かる
いきなり完璧な理解を目指すのではなく、
- どこに何があるのか
- 何が標準で、何が例外なのか
が一望できる「地図」を手に入れるイメージです。あくまでもイメージ。
2. リスクと改善ポイントが整理される
環境調査では、単に「今の状態を写し取る」だけではなく以下のような観点で整理していきます。
- セキュリティリスク（意図しない共有、権限過多 など）
- オペレーションリスク（運用ミス・変更漏れにつながるもの）
- 管理の複雑性（例外が多い、ルールが分かりづらい）
- 将来的な拡張性・保守性（今後も運用を続けられる形か）
そのうえで、
- いますぐ直したほうが良いもの（高優先度）
- 次の改善フェーズで検討すべきもの（中優先度）
- そのうちやれば良いもの（低優先度）
に切り分けて整理します。この整理が大変なんですけどね。
3. 成果物（アウトプット）イメージ
環境調査の結果としてまとめる成果物は以下です。必ずこれらを作るわけではないですが、だいたいこのようなものが出来上がります。
- 管理コンソールの主要設定一覧（スプレッドシートなど）
- 組織部門ごとの設定差異リスト
- 想定されるリスクとその根拠
- 推奨設定と、例外パターンの整理
- 今後 3〜6ヶ月で着手すべき改善案のリスト
「なんとなく安心」ではなく『この設定はこういう理由で危ない／こう変えるべき』が言語化された状態まで持っていくのがポイントです。
実例で見る「Before → After」
ここでは、実際にあったケースをイメージしやすい形に抽象化して紹介します。
事例1：組織部門が増えすぎて誰も触れない状態
Before
- 組織変更のたびに新しい組織部門が追加され、古いものが放置
- 部門名もルールがバラバラで、「旧_営業本部」「営業本部_2021」「営業第二」「営業組織（古）」のようなカオス状態
- どの部門が現役で、どの部門が使われていないのか誰も分からない
- 設定変更したくても、どこに影響が出るか読めず、誰も触りたがらない
After
- そもそもの「組織図ベースで組織部門を割る設計」を廃止
- 必要な機能と制限に絞り、組織部門を数パターンに集約
- 設定の基準（標準設定）を定めたうえで、例外のルールを明文化
- 整理した後にまた部門を分ける必要がないよう、例外の発生余地を無くすルールを策定
結果：新しい部門を追加、変更する頻度が激減
事例2：Drive 共有のポリシーが緩く、意図しない社外共有のリスクがあった
Before
- 複数の組織部門で設定制御されている
- 一方で、最上位組織部門（= ルート組織部門）直下に多くのユーザーが所属
- ルート組織部門でドメイン外のユーザーへの共有が原則許可のままになっていた
After
- ルート組織部門のドメイン外共有などの設定を適切な値に変更
- Google Workspaceのユーザー作成処理のプロセスフローを整理
- ルート組織部門直下のユーザーが何も出来ないように設計変更
- アプリ割当一律Offにし、ユーザー作成後に適切な組織部門へ割り当てるオペレーション/SCIM設定 など整備
結果：オペミスの余地を減らし、意図しない社外共有の根本原因をケアできた
HowTo：どうやって環境調査しているのか
何も特別なことはしてません。残念ながらほぼ根性です。
1. （重要）確認スコープは決めない。覚悟を決める
Google Workspace現状調査では、徹底的に設定を確認するため対応スコープや確認範囲を定めることは基本的にありません。
管理コンソール上で確認できる全ての設定値 = スコープ最大範囲 となります。
ただし！
お客様から付与頂ける権限に限りがある場合には以下の領域からピックアップして、スコープを定めます。
- 管理コンソールの主要な領域
- ディレクトリ（ユーザー・グループ・組織部門）
- アプリ（Google サービス、SAML / OIDC 連携）
- セキュリティ（2段階認証、コンテキストアウェアアクセス など）
- デバイス管理（PC / モバイル / Chrome）
- Gmail / Drive / カレンダーなど主要サービスの設定
- 必要に応じて
- Chrome 管理
- Vault
- メールルーティング・ゲートウェイ設定
2. GUI を愚直に全部見る（なぜそんな面倒なことをするのか）
「APIやエクスポートで、一気に情報を出せないんですか？」
よく聞かれます。
できる範囲もありますが、2025/12/01時点の結論としてはGUIを愚直に全部見る工程は避けられません。
理由は以下のとおり。
- 一部の設定は GUI にしか露出していない
- 組織部門ごとの微妙な差異や例外が、画面で見ないと分からない
- 設定項目単体ではなく、「画面の文脈」を含めて意図を読み取る必要がある
最近Chrome MCPが出たので、ここら辺自動化できるかなーと思った時期が私にもありました。
ChatGPT Computer UseとかClaudeとか使いましたけどね…
結局自分で見るのが一番早くて確実でした。しゃーない。
実際の作業としては、
- 組織部門別の設定を全件クリックして値抽出
- 差分の星取り表を作り、差分がある箇所を星でマーク
- 全ての画面をキャプチャしながら、気になるポイントはメモとセットで残す
といった形でドキュメントにしたためていきます。
この調査過程で生まれるドキュメントはあくまでも一時的要素であり、運用フェーズでメンテナンスする想定はありません。
あくまでもメモ用途、説明用途のドキュメントです。でもこれが重要。
メモに取ることでやっと頭に入ることがあるので。
クソ時間かかるんですけど、個人的にはこの工程が一番重要と考えています。
ともあれ、私もいつまでもこのような作業したくないので、自動化/省力化の検証を進めています。
だってクソ時間かかるしスケールしないから。
3. 観点を決めておく（チェックしながら分類していく）
環境調査では、あらかじめ次のような「観点」を決めておきます。
細かい観点は後述します。
- 組織部門別の設定差異
- 意図しない社外共有につながる設定
- オペレーションミスの原因になりそうな設定
- 管理者権限・ロールの設計
- デバイス管理の有無と方針
- 廃止済みサービス・旧仕様の痕跡
この観点ごとに、
- 「問題なし」
- 「要確認（運用とすり合わせ）」
- 「改善を強く推奨」
とフラグをつけながら見ていくことで、最後に課題のリストとして再構成しやすくなるわけです。
課題抽出の観点
ディレクトリ
- そもそも組織構造に合わせる必要はあるのか？
- 組織部門の数は、現実の組織構造に対して過剰ではないか？
- 「過去の組織名」や「用途不明の部門」が放置されていないか？
- 親部門と子部門の設定継承に矛盾がないか？
- 親で禁止、子で許可している項目が乱立していないか？
- 新しい部門を追加するときのルールは決まっているか？
社外共有・情報共有
- ドメイン外共有の許可・禁止のポリシーは決まっているか？
- ポリシーと実際の設定が一致しているか？
- Drive / サイト / カレンダー など、サービスごとの共有ルールに一貫性があるか？
- 「リンクを知っている全員が閲覧可能」の利用パターンが放置されていないか？
管理者権限・ロール
- 特権管理者の人数は妥当か？
- 「なんとなく便利だから」と権限盛りしたロールがないか？
- 一時的に付与した権限が、そのまま恒久化していないか？
デバイス管理
- モバイル / PC / Chrome の管理方針は定まっているか？
- 社給端末と BYOD の扱いが整理されているか？
- ログインや同期を許可しているデバイスの範囲が明確か？
運用・監査
- 設定変更の履歴と理由を残す仕組みがあるか？
- 監査ログ（Audit log）を定期的に確認しているか？
- インシデントやヒヤリ・ハットの経験が、設定やルールに反映されているか？
- 過去の経緯が読み取れるか？
余談：Google Workspace 運用でよくある落とし穴
環境調査でほぼ毎回のように出てくる「あるある」をいくつか挙げておきます。
1. 組織部門分けすぎ問題
- 「細かく分けたほうがきれい」と思って増やし続けた結果、誰も全体を把握できなくなるパターン
- 組織変更のたびに新しい部門を足し、古い部門はそのまま
→ 一見ちゃんとしているように見えて、実は運用も変更も超やりづらい構造になっていることが多いです。
2. Googleのマイナーチェンジに引きずられた「変遷の遺跡」
- 過去の仕様や推奨設定の名残が、そのまま残り続けている
- 新しい機能が追加されたのに、デフォルト値のまま放置されている
→ 「昔はこれがベストプラクティスだった」が、そのまま 2025 年も残っているパターンです。
3. 共有ポリシーの意図しない緩和
- 特定のプロジェクトのために一時的に緩めた共有設定が、そのまま全体に適用されている
- グループポリシーや共有ドライブの権限で、実質フリーパスになっているフォルダがある
4. ドキュメントにしたためる
ここまで確認してきた内容と、逐一取得したメモを元にまとめる作業です。これもまた地味。
参考までにSAMPLEをいくつか貼っておきます。
実際には文字数10000超のクソデカドキュメントが生まれます。しゃーない。
効果について
正直なところ地味で手間のかかる作業ですが、一度ちゃんと棚卸ししておくとその後の運用・改善の考え方の解像度が上がります。
何より、環境調査のプロセスをやりきった人が、自社のGoogle Workspaceについて会話ベースで説明できる「生き字引」になる点が一番インパクト大きいですね。
作成したドキュメントを定期的に更新するコストを払えば、NoteBookLMに調査レポートを投入するだけでも代替できます。
終わりに
Google Workspaceを例に挙げましたが、Google Workspaceに限らずSaaS全般に共通する話でもあります。
よく分からないままSaaSを使い続ける期間が長いほど、後からまとめて払うコストは大きくなりますし。
- そろそろちゃんと棚卸ししたいけど自前でやる余力もノウハウも足りない！
- せっかくやるのならドキュメントだけでなく「生き字引」も欲しい
という状況であれば、環境調査からご一緒する形での運用支援も可能です。お気軽にご相談ください。
色々やることが多い情シス。考えることが多い情シス。カバー範囲広すぎてめっちゃ大変な情シス。
情シスの考えることをちょっとでも減らし、助けになれば幸いです。
そのための運用支援サービスであり、そのためのクラウドネイティブですから。
ではでは。
