2025年11月、Google Workspace 管理コンソールで Google Chat スペースや会話の新規作成を OU（組織単位）またはグループ単位で制限できる機能が Business Plus・Enterprise Standard/Plus などのエディションに展開されました。この記事では、情シス担当者が整備すべき「スペース作成ポリシー」「ライフサイクル定義」「棚卸し運用フロー」の3点を軸に、Google Chat スペース管理の設計を整理します。
この記事を読んだほうが良い人
- Google Chat を導入して1〜2年経ち、スペースが増え続けて管理しきれなくなってきた情シス担当者
- スペースの乱立を防ぎたいが、何をどう制御すればよいか整理できていない方
- ガバナンスの一環として Chat 運用ルールを策定しようとしている方
なぜ Google Chat スペースは増え続けるのか
Google Chat のスペースは、デフォルトではユーザーが自由に作成できます。プロジェクトの立ち上げ・社内イベントの企画・部門横断の議論など、様々な文脈でスペースが生まれます。一方、終わったはずのプロジェクトのスペースは放置されたまま残り続けます。
増殖の構造的な原因は2つあります。
1つは作成の摩擦がゼロであること。管理者の承認なしにスペースを作れるため、必要かどうかを深く考えずに作り始めるユーザーが出てきます。
もう1つは廃棄のトリガーが存在しないこと。プロジェクトが終わっても誰もスペースを閉じません。メンバーが退職しても、スペースはそのまま残ります。結果として、実質的に誰も使っていない休眠スペースが積み重なっていきます。
Google Chat では DM（ダイレクトメッセージ）と異なり、スペースは複数人・複数目的での継続利用を前提に設計されています。そのため「使い終わったら自然消滅」という仕組みがなく、作成者が能動的に管理しない限り残り続けます。
放置されたスペースの問題は可視化しにくい点にあります。管理コンソールのスペース管理ツールで確認しない限り、情シスは総スペース数を把握できません。長期間メッセージがないスペースが相当数積み上がっていても、誰も気づかないまま運用が続くことになります。その結果、情報の検索性が落ち、必要なスペースを探すコストが増え、管理者が全体を把握できる状態でなくなります。
スペース作成ポリシーの設計方法
スペース作成の制御には2つの軸があります。
軸1：誰がスペースを作れるか
2025年11月に展開された機能を使うと、OU またはグループ単位でスペース・会話の新規作成を制限できます（デフォルトはオフ）。対象エディションは Business Plus・Enterprise Standard/Plus・Frontline Standard/Plus などです。
この機能を使った設計パターンは大きく3つあります。それぞれの特徴を整理すると以下のようになります。
| パターン | 作成権限 | 向いている組織 | 注意点 |
|---|---|---|---|
| 全員作成可能 | 全ユーザー | 小規模・フラットな文化の組織 | 棚卸し運用とセットにしないと急増する |
| 申請制 | 承認を得たユーザー | 100名以上・ガバナンス重視 | フローが重いと利用者が DM や他ツールで代替する |
| 管理者のみ | 情シス担当者 | 統制を最優先にする組織 | 現場のスピード感が落ちるリスクがある |
どのパターンを選ぶかは、組織の規模・文化・Chat の利用目的によって変わります。判断の起点になるのは「スペースが増えることで実際に困っているか」という問いです。困っている実感がすでにあるなら、申請制への移行を検討する段階です。
申請制を導入する場合：フォームの設計
申請制を選んだ場合、申請フォームに含める最低限の項目は次の4つです。
- スペースの用途（プロジェクト名または業務目的を簡潔に）
- オーナー（責任者）の氏名・メールアドレス
- 想定利用期間（終了予定日、または「継続的に使用」の選択肢）
- 外部メンバーを含むかどうか（有 / 無）
この4項目があれば、後述のスペース台帳に初期登録でき、ライフサイクル管理の起点になります。Google フォームで作成し、回答をスプレッドシートに自動出力する構成にすると管理コストが下がります。承認者は1名に絞り、回答期限を2営業日以内に設定するのが現実的です。承認ステップを増やすほど、利用者は DM や非公式の手段に流れていきます。
軸2：スペースをどのような設定で作るか（アクセス設定の標準化）
作成時のデフォルトアクセス設定も重要な設計項目です。管理者は新規スペースのデフォルトを「組織内誰でも検索・参加可能」または「招待されたメンバーのみ」のどちらかに設定できます。Business Plus 以上のエディションでは、ターゲットオーディエンスとして最大5グループを指定する設定も利用できます。
用途ごとに統一ルールを設けると、スペースの散逸を防げます。以下のような分類が扱いやすいです。
- 部門共有スペース → 組織内公開
- プロジェクトスペース → 招待制（期間制限あり）
- 機密情報を扱うスペース → 招待制 + 外部共有オフ
スペースのライフサイクルをどう定義するか
スペースに「終わり」を設計するのは情シスの役割です。Google Chat のスペースには利用者が設定できる自動アーカイブ機能はありません。管理者は管理コンソールのスペース管理ツールから最終アクティビティ順に並べ替えて一括削除できます（全エディション対応、2023年10月より利用可能）。
削除を実行する前に、組織としてのライフサイクルポリシー定義が欠かせません。決めておくべき項目は3つです。
1. 非アクティブの定義
「X ヶ月以上メッセージ投稿がなければ非アクティブ」という基準を組織として定めます。3〜6ヶ月を目安にすると、運用上扱いやすく現場にも無理のない設定です。メンバー数が1名以下のスペースは内容に関わらず廃棄候補とする、といった複合条件を加えると精度が上がります。
「期間だけ」を条件にすると、低頻度だが重要なスペース（四半期報告用のスペースなど）が誤って廃棄候補に入るリスクがあります。「最終アクティビティから X ヶ月以上経過した」に加え「オーナーが継続意思を表示したものを除外する」という条件を組み合わせることで、誤廃棄を防げます。
2. 廃棄前の確認プロセス
一方的に削除するのではなく、スペースオーナーへの事前通知を挟みます。以下は通知文の参考例です。
件名：【情シスより】Google Chat スペース「〇〇」の廃棄予定に関するご確認
お世話になっております。情シスです。 Google Chat スペース「〇〇」について、過去 X ヶ月間メッセージの投稿が確認されていないため、廃棄候補として選定しました。
・継続を希望される場合は、〇月〇日（〇）までに本メールへ返信をお願いします。 ・返信がない場合、〇月〇日以降に削除を実施します。 ・削除後はメッセージ履歴を復元できません。必要な情報は事前に保存してください。
ご不明点は情シス担当者（メールアドレス）までご連絡ください。
通知のタイミングは「廃棄予定日の2〜3週間前」が利用者の対応余地を確保しやすいです。
外部ユーザー（他組織のアカウント）がメンバーとして参加しているスペースを削除する場合は、取引先や協力会社との連絡手段が失われないかを事前に確認します。外部連携スペースは廃棄候補から除外するか、オーナーへの確認を必須ステップとするルールを設けておくと安全です。
3. 削除前の保全
削除前に Google Vault（eDiscovery・コンプライアンス保全ツール）のリテンション設定を確認します。特に法的リスクが高い部署のスペースは、Vault で保全してから廃棄します。
Google Vault の保持ルールで保全対象の保持期間を設定できます。法的リスクが高い部署には法的保留（ホールド）も活用できます。たとえば「退職者が作成したスペースは2年間保全する」という保持ルールを設定しておくと、スペースを管理コンソールから削除した後も Vault 上では規定期間データが保持されます。保全と廃棄の手続きが矛盾しないよう、Vault 設定を先に確認してから削除オペレーションに進む順序を社内ルールにしておくことで、コンプライアンス上のリスクを回避できます。
Google Chat スペースガバナンスの棚卸し運用フロー
設計したルールは、定期的な棚卸し運用で維持します。四半期または半期のどちらかを選んで定期実施するのが現実的です。
棚卸し運用フローの骨格は以下の通りです。
- トリガーの設定：四半期または半期の末にカレンダーイベントとリマインダーを設定します。情シスが単独でやるのではなく、各部門リードも棚卸しの参加者として巻き込むと、現場感覚のある判断が得られます
- 非アクティブスペースの抽出：管理コンソールのスペース管理ツールを使い、定義した非アクティブ期間を超えたスペースをリストアップします
- オーナーへの確認：スペースオーナーに継続または廃棄の意思を確認します。Google フォームで回答してもらうと集計がスムーズです
- 廃棄・保全の実行：廃棄対象は Google Vault 確認後に一括削除。継続対象は次のレビュー周期まで保留します
- スペース台帳の更新：スペース名・用途・オーナー・作成日・次回レビュー予定をスプレッドシートで管理します
スペース台帳の構成例
棚卸しの軸になるスペース台帳は、次の列を最低限含める構成にすると管理しやすくなります。
| 列名 | 内容 |
|---|---|
| スペース名 | Chat 上に表示される名称 |
| 用途 | 作成申請時に登録した業務目的 |
| オーナー | 責任者のメールアドレス |
| 作成日 | 申請日または確認日 |
| 最終アクティビティ | 直近のメッセージ投稿日（棚卸し時に更新） |
| 外部メンバー有無 | 有 / 無 |
| Vault 保全対象 | 有 / 無 |
| 次回レビュー予定日 | 継続判断の期限 |
| ステータス | アクティブ / 確認中 / 廃棄予定 / 廃棄済み |
台帳は Chat API を利用した定期自動同期も技術的には可能ですが、手動でも月1回の更新なら情シス1名で十分に管理できます。「自動化してから台帳を作る」という前提条件を置くと、設計が完成するまでスペース管理が一向に始まりません。手動の運用フローが安定してから自動化を検討する方が、早く確実に管理体制を立ち上げられます。
スペース削除時のデータの扱い
スペース削除に際して、利用者への補足が必要な点があります。スペース内で共有した Google ドライブのファイルは、スペース削除後もドライブ上に残ります。一方、スペース内に直接アップロードした添付ファイル（ドライブ経由でないもの）は削除されます。廃棄通知の際は「ドライブ経由でないファイルは削除される」点を明記し、必要な情報を事前にドライブへ移動するよう依頼することが重要です。
ポリシー設計でよくある落とし穴
設計の方向性が固まっても、実際の運用で躓くポイントがあります。よくある3つの落とし穴を事前に把握しておくと、対策を立てやすくなります。
落とし穴1：承認フローを複雑にしすぎる
申請制の導入時に、複数の承認者や多段階のフローを設けると、利用者は「他のツールの方が早い」と判断して代替手段に流れます。承認者は1名に絞り、回答期限を2営業日以内に設定するのが現実的です。承認フローは「軽さ」を優先します。
落とし穴2：既存スペースを一斉に廃棄する
ポリシー策定後の最初の棚卸しで大量削除を実行すると、クレームが集中する可能性があります。最初のサイクルは「通知のみ（廃棄猶予期間あり）」として運用を試し、利用者が通知を受け取ることに慣れてから実際の削除へ移る段階的移行が安全です。
落とし穴3：台帳管理が「自動化前提」になる
「Chat API で自動化してから運用を始める」という前提条件を置くと、設計が完成するまでスペース管理が一向に始まりません。スプレッドシートと手動運用で起動し、繰り返しの手間が大きくなった段階で自動化を検討する順序が正しいです。完璧な仕組みを待つより、動く仕組みで先に回すことがガバナンス設計の鉄則です。
3つのポリシーを連動させる考え方
作成ポリシー・ライフサイクル定義・棚卸し運用の3つは、バラバラに設計しても機能しません。連動させて初めて体制として成立します。
作成時にオーナーを必ず登録させる（作成ポリシー）→ ライフサイクルの節目でオーナーに確認を送る（ライフサイクル定義）→ 確認結果をスペース台帳に反映して次の棚卸しに備える（棚卸し運用）。この連鎖があれば、スペースは「誰かが責任を持つ、終わりが来るもの」として組織に定着します。
一度にすべてを整備しなくてもかまいません。整備のタイムラインの目安として、次のような3サイクル構成が取り組みやすいです。
- 第1サイクル（今季）：スプレッドシートで現在のスペース一覧を把握し、台帳を初期作成する。非アクティブの定義と廃棄通知のテンプレートを決める
- 第2サイクル（翌季）：廃棄通知を初めて送信する。返答のないスペースの一覧を作り、削除の判断を下す（猶予期間付き）
- 第3サイクル（その翌季）：申請制や作成制限の設定を検討する。継続運用のリズムが定着したことを確認してから、制限を強化する
「自由に使える」文化を大切にしつつ、作ったものには責任が伴うという感覚を制度として根付かせる。それがスペース管理の本質です。段階的に整備することで、現場の混乱を最小限に抑えながら管理の基盤を作れます。規模が大きくなるほど、この設計の有無で運用コストの差が広がります。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。