Google Sites ラベル管理で社内ポータルを棚卸しする

Google Workspace の分類ラベル（Classification Labels）は Drive ファイル全般に適用できる管理機能です。Google Sites のファイルも Drive 上に保存されているため、ラベル設計・DLP 連携・Vault 保持ポリシーの設計対象として検討できます（Sites UI でのラベル表示・操作については事前確認を推奨します）。この記事では、社内ポータルの棚卸しを起点に、情シスが押さえておくべき判断軸を整理します。

この記事を読んだほうが良い人

• 社内に Google Sites サイトが 10 件以上あるが、どこに何があるか把握できていない
• 部門ごとに Sites を立ち上げているが、公開範囲やアクセス権のルールがバラバラになっている
• DLP ポリシーを整備したいが、Sites ファイルにどう適用するか設計の起点がない
• Vault の保持ポリシーを Sites にも適用したいが、分類の仕組みが整っていない

社内 Sites が増え続ける構造的な問題

Google Sites の作成障壁は低い。管理コンソールで作成を制限していない組織では、各部門が必要に応じてサイトを立ち上げ、役目を終えたあとも放置されたまま残り続けるケースが多い。

棚卸しをすると、次のような状況が見えてくる。

• 3 年以上更新のないプロジェクト用サイトが残っている
• 「全社向け」のつもりで作ったサイトが、設定ミスで社外公開になっている
• 同じ用途のオンボーディングサイトが複数部門でそれぞれ作成され、どれが正式版か不明
• アクセス権を付与した担当者がすでに退職している

管理コンソールのレポート機能で Sites の一覧は取得できる。ただし「このサイトに機密情報が含まれるか」「現在も利用中か」「誰が管理責任者か」という軸での分類は、何らかのメタデータ設計がないと手動対応になる。ここに Drive 分類ラベルを活用する価値がある。

Google Workspace 分類ラベルとは何か

Google Workspace の分類ラベル（Classification Labels）は、管理者がラベルマネージャーで定義したメタデータを Drive ファイルに付与する仕組みです（Google Workspace 管理コンソールヘルプより）。

ラベルの基本要素は次の通りです。

• ラベル名: 「機密度」「利用状況」など、分類の軸になる名前
• フィールド: 選択式（例：一般公開 / 社内限定 / 部門限定 / 機密）またはテキスト入力
• スコープ: 特定の OU（組織部門）やグループへの配布に限定できる
• 連携先: DLP ポリシー・Vault 保持ルール・管理コンソールのフィルター検索

対応するアプリケーションは Google ドライブ（Docs・Sheets・Slides 等の Drive 内ファイルを含む）・Gmail・Google カレンダー・Chat などで、公式ヘルプに明記されています（Google Workspace Updates 2024年7月より）。

Google Sites のファイルは Drive 上に application/vnd.google-apps.site という MIME タイプで保存されており、Drive ファイルとして存在します。そのため、Drive API や管理コンソールのレポート機能では他の Drive ファイルと同様に扱われます。Sites の編集画面でラベルが直接操作できるかどうかは環境によって差がある場合があるため、導入前に管理コンソールおよび Drive UI での挙動を確認することを推奨します。

情シスがGoogleサイト ラベル機能を活用する場面

Sites を含む Drive ファイル全般のラベル管理を情シス主導で設計することで、社内ポータルの可視化と DLP・Vault 連携のベースを整えられます。特に組織で Sites の作成を制限していない場合、ラベルなしでは機密度や用途の把握が困難になります。ラベル設計を先行させることで、後続の DLP ルール設定が一貫したロジックで組めるようになります。

ラベル設計の方針：機密度×用途マトリクス

Google Sites ラベル管理の設計で最初に決めるべきは「何軸でラベルを設計するか」です。軸が多いほど分類は精緻になりますが、付与の手間も増えて未設定放置のリスクが高まります。

以下は実務で機能しやすい 3 軸構成の設計例です。

軸	選択肢（例）	主な用途
機密度	一般公開 / 社内限定 / 部門限定 / 機密	DLP・共有制限の判断基準
サイト用途	オンボーディング / プロジェクト / 製品情報 / その他	棚卸し・優先度判断
ライフサイクル	運用中 / 更新停止 / 廃止予定	メンテナンス対象の特定

設計時に外せない注意点を 3 つ挙げます。

選択肢は各軸 4 つまでに抑える。選択肢が多いと担当者がどれを選ぶか判断できず、未設定のまま放置されるケースが増えます。迷ったら削る方向で判断します。

ラベル名・選択肢を日本語と英語で揺らさない。「Confidential」と「機密」が別々のラベルとして存在する状態は、DLP ルールの管理コストを増やす原因になります。組織内で表記を統一する運用ルールを先に定めます。

デフォルト値（未設定時の扱い）を方針として決めておく。「未設定 = 社内限定として扱う」のように基準を設けておくと、棚卸し時のヌケモレを判断しやすくなります。

DLP 連携設計フロー（Sites DLP 連携 運用）

Google Workspace の DLP（データ損失防止）ルールは、分類ラベルと組み合わせて次の 2 通りの使い方ができます（Google 公式管理コンソールヘルプより）。

① ラベルを条件にした共有制御: 「機密」ラベルが付いたファイルを社外に共有しようとしたらブロックする、という DLP ルールを設定します。これにより、管理者がリストを手動で確認しなくても、ラベルさえ正しく付いていれば自動で共有制御が働きます。

② DLP によるラベル自動付与: コンテンツスキャンの結果を使って、DLP ルール側からラベルを自動付与する設定も用意されています。例えば「マイナンバー形式の文字列を含む Sites ファイルには自動で『機密』ラベルを付与する」というルールを実装できます。

設計上の重要な順序として、ラベルの定義を DLP ルールよりも先に完成させることが必要です。DLP ルールはラベル名を参照して動作するため、後からラベル名を変更すると既存のルールが意図通りに動かなくなります。「ラベル設計 → DLP 設計 → 運用開始」という順番を崩さないことが、後々のトラブルを防ぐ基本原則です。

Vault 保持ポリシーとの接続

Google Vault では Drive ファイルに保持ルールを設定できます。基本の対象単位は OU（組織部門）またはアカウント単位です。Sites ファイルも Drive 上のファイルとして Vault の対象になるため、棚卸しで「廃止予定」ラベルを付けたサイトを Vault 保持の観点で扱う方針を決めておくと、後から「あのページの内容を確認したい」という要求への対応が整理されます。

実務的な設計方針として「廃止予定ラベルを付けた Sites ファイルは削除前に確認ステップを必ず踏む」というフローを情シスの標準手順として定めることを推奨します。ラベルで可視化し、廃止ワークフロー（オーナーへの確認 → 記録確保 → 削除）をセットで整備することで、ガバナンスとして機能する設計になります。

なお、Sites ファイルが Vault の検索・エクスポート対象として正式にサポートされているかどうかは、公式 Vault ヘルプで事前確認することを推奨します。

社内ポータル棚卸しチェックリスト

以下のチェックリストを棚卸し実施前の確認に活用してください。

現状確認フェーズ

• [ ] 管理コンソールで組織内の Sites 一覧を取得済みか
• [ ] 各 Sites の最終更新日・作成者・アクセス権（社内 / 社外）を確認済みか
• [ ] 社外公開設定になっているサイトを洗い出し済みか
• [ ] オーナーが退職者になっているサイトを特定済みか
• [ ] 同じ用途のサイトが重複していないか確認済みか

ラベル設計フェーズ

• [ ] 機密度ラベルの選択肢を 4 段階以内で定義しているか
• [ ] サイト用途・ライフサイクルラベルの設計が完了しているか
• [ ] ラベルのデフォルト値と未設定時の運用ルールを決めているか
• [ ] ラベル名・選択肢の日本語 / 英語表記を統一しているか
• [ ] ラベル付与の責任者（Sites オーナーが付与するか、情シスが一括管理するか）を明確にしているか

DLP・Vault 連携フェーズ

• [ ] 「機密」ラベルのファイルに対する DLP ブロックルールを設定したか
• [ ] DLP による自動ラベル付与ルール（機密コンテンツ検知）を検討・設定したか
• [ ] 廃止予定サイトの Vault 保持方針を定めているか
• [ ] ラベル名を変更する場合の手順（DLP ルール連動更新を含む）を取り決めているか

まとめ：設計の起点を最初に作ることが全体に波及する

社内ポータルの乱立は「作るコストが低く、廃止のコストも感じない」という構造から生まれます。ラベルはその構造に対して「このサイトは何で、誰が管理し、どう扱うべきか」という情報を付与する仕組みです。

完璧なラベル設計を最初から目指す必要はありません。「機密度」1 軸・選択肢 4 つからスタートして、DLP 連携を 1 本確認する。実態に合わない選択肢は棚卸し後に見直す。その小さなサイクルを回し続けることが、現場で機能するガバナンスへの近道です。

一方で、ラベル設計を後回しにしたまま DLP だけ先に設定しようとすると、分類の粒度が定まらず DLP ルールが複雑化します。設計の順番を意識することが、運用コストを抑えるうえで最も効果的な判断です。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。