3行まとめ
DLP rules and detectorsに対し、Get/Listだけでなく作成、更新、削除までAPIで扱いやすくなった。
Policy APIの利用条件はsuper administratorで、通常のDLP管理権限とは分けて確認する。
API-only launchであり、Mutate supportedや対象アプリ、戻し方を確認してから小さく始める。
新機能の追加として読むだけでなく、強い変更権限をどう統制するかまで合わせて見ると判断しやすくなります。
- Google Workspace Updatesは2026年6月8日、Workspace Policy APIにDLP rules and detectors向けのCreate、Update、Delete機能を追加したと発表した。従来のGet、List中心の確認から、DLPポリシーのライフサイクル管理へ踏み込む更新だ。
- ただし、これはAPI-only launchであり、Admin consoleにない新しいDLP機能が増えたという意味ではない。Cloud Identity Policy APIのドキュメントでは、利用できるのはsuper administratorのみと説明されている。
- 管理者はすぐ本番反映へ進むのではなく、Mutate supportedの対象、Gmail、Drive、Chat、Chrome、ChromeOSごとの条件、Domain-wide delegation、audit-only検証、ログ確認、戻し方を先に決めるべきだ。
Google WorkspaceのDLPは、社外共有やメッセージ送信、ファイル操作などで機密情報をどう扱うかに直結する。今回の更新は、DLPルールや検出器をAPIで変更できる入口が増えたという点で便利だが、同時に「誰が、どの承認を経て、どの範囲を変更できるのか」を曖昧にすると危ない。
この記事では、2026年6月16日時点で確認できるGoogle公式情報をもとに、Workspace Policy APIのDLP mutate endpointsを管理者目線で整理する。2026年6月12日のWorkspace Updates週次まとめで再掲され、管理者向けの外部ブログでも話題化しているため、関心は出ている。ただし、仕様の根拠は公式発表、Cloud Identity Policy APIドキュメント、Supported Policy API settings、Workspace DLP Helpに限定する。
Alphabet Watch JapanはAlphabetおよびGoogle各社と非提携の独立メディアであり、この記事は製品・サービス更新の確認記事だ。投資判断や法務判断の代替ではない。
今回の変更をどう位置づけるか
便利さと権限リスクが同時に増えるため、読み取りAPIの延長ではなく変更管理の仕組みとして扱うのが安全です。
読み取りAPIからライフサイクル管理へ広がった
Workspace Updatesの発表では、Workspace Policy APIにDLP rules and detectors向けのmutate endpointsが加わったと説明されている。既存のGet、Listに加えて、Create、Update、Deleteが使えるようになり、DLPポリシーの初期作成から有効化、無効化までをプログラムで扱いやすくする狙いがある。
APIで触れる範囲は、DLPの運用ライフサイクルに近づいた。ルールを読むだけなら棚卸しや監査の用途にとどまる。作成、更新、削除が入ると、構成管理、レビュー、ロールバック、監査ログまで含めた運用設計が必要になる。
根拠
公式発表では、DLP rules and detectorsについてCreate、Update、Deleteが導入され、既存のread-only capabilitiesであるGet、Listと並ぶ形になったと説明されている。また、この更新はAPI-only launchであり、Admin consoleで現在サポートされている機能をAPIから扱うためのものだと明記されている。
評価基準
導入判断では、APIを呼べるかより先に、次の5点を見る。
- 既存DLPルールと検出器をGet、Listで棚卸しできるか。
- ルール名、検出器名、OU、グループ、状態、アクションの命名規則を決めているか。
- 作成、更新、削除それぞれに承認者とレビュー者を置けるか。
- audit-onlyで試し、Rule log eventsやアラートで確認する段取りがあるか。
- Deleteや誤設定から戻すためのスナップショットと復旧手順があるか。
この5点がないままAPI化すると、手作業のDLP運用より変更速度だけが速くなり、管理しにくくなる。
Workspace Policy APIとCloud Identity Policy APIの呼び名を整理する
今回の発表ではWorkspace Policy APIという呼び方が使われている。一方、開発者向けドキュメントはCloud Identity Policy APIの配下にあり、Policy API overviewやREST referenceもCloud Identityの文脈で掲載されている。
この記事では、読者がドキュメント検索で迷わないように、Workspace Updates上のWorkspace Policy APIと、Google Cloudドキュメント上のCloud Identity Policy APIを同じ確認導線として扱う。Admin consoleの設定をプログラムで確認または変更するAPI、という理解で読めばよい。
確認項目
Cloud Identity Policy API overviewは、Google Admin consoleで管理者が構成するGoogle Workspaceドメインの設定を、プログラムでviewまたはmodifyできるAPIだと説明している。また、mutate endpointsで対応しているかどうかは、Policy API supported settingsのMutate supported列で確認するよう案内している。
注意点
名称の違いを理由に、別々のAPIがあるように扱わない。逆に、Policy API全体で見える設定をすべて変更できるとも書かない。今回の記事で見るのは、DLP rules and detectors向けのmutate対応だ。
API-only launchをどう読むか
API-only launchという表現は、管理者にとって重要だ。新しいDLP判定ロジックや新しいAdmin console画面が増えたというより、既にAdmin consoleで扱えるDLPの一部ライフサイクルを、APIで操作できるようにした更新として読む。
条件
Workspace Updatesは、管理者向けにはPolicy APIを使うにはsuper adminである必要があると案内している。エンドユーザー向けの設定はなく、提供状況はRapid ReleaseとScheduled Release domainsでAvailable now、Availabilityはall Google Workspace customers and Workspace Individual subscribersとされている。
誤解しやすい点
APIのAvailabilityと、自社のDLP機能がどの範囲で使えるかは分けて確認したい。Workspace DLP Helpには、DLPのサポート対象エディションや機能範囲が別途説明されている。APIが利用可能でも、実際に保護したいアプリ、アクション、検出条件が自社の契約やAdmin console設定で使えるかは、管理コンソールと公式ヘルプで確認する必要がある。
mutate前に対象範囲を棚卸しする
DLP以外の設定やMutate supportedがNoの項目まで自動変更できるように扱うと、実装前提を誤りやすくなります。
create、patch、deleteはrules and detectors settingsに絞る
Cloud Identityの「Creating, patching, and deleting policies」ページは、create、patch、delete endpointsのコード例を示している。同ページでは、Create、patch、delete endpointsは現時点でrules and detectors settingsにのみ対応すると説明されている。この記事で扱う中心も、DLP rule、word list detector、regular expression detectorだ。
根拠
Supported Policy API settingsでは、DLP ruleやdetector関連の設定がまとまっており、条件式やアプリ別アクションも整理されている。DLPルールでは、Gmail、Drive、Chat、Chrome、ChromeOSなどのアプリごとに、どのトリガーやmatch source、CEL condition function、actionが使えるかを確認する形になる。
注意点
Policy APIのsupported settingsページには、API controls、Calendar、service status、Generative AI service statusなど、DLP以外の設定も多数並ぶ。ここでMutate supportedがNoの設定まで自動変更できるように書くと誤りになる。DLPの自動化を始める前に、必ず対象設定のMutate supported列と該当セクションを見る。
対応アプリとトリガーを分けて確認する
DLPは単一のスイッチではない。Gmail、Drive、Chat、Chrome、ChromeOSで、検査対象、トリガー、アクションが異なる。API化する前に、まず「どのアプリで、どのイベントを、どの条件で、どのアクションにするか」を分ける。
| アプリ | 代表的な確認対象 | 先に見ること |
|---|---|---|
| Gmail | 送信、受信、本文、件名、ヘッダー、添付ファイル関連の条件 | block、warn、audit、quarantine、footerなど、必要なアクションが対応しているか。 |
| Drive | Drive files、本文、タイトル、ファイル名、拡張子、ファイルタイプ、ラベル、暗号化状態 | My DriveとShared drivesの扱い、外部共有を止める条件、分類ラベルとの関係。 |
| Chat | メッセージ送信、ファイルアップロード、ファイル名やファイルタイプ | メッセージ本文だけでなく添付ファイルも対象にするか。 |
| Chrome | ファイルアップロード、ダウンロード、貼り付け、印刷、URLやカテゴリ | ブラウザ操作に対するblockまたはwarnの条件を明確にする。 |
| ChromeOS | ファイル転送制限、コンテンツ、タイトル、ファイルタイプ、サイズ | 端末ポリシーやChromeOS運用とDLPを混同しない。 |
確認項目
Supported Policy API settingsには、contains、matches_regex_detector、matches_dlp_detector、matches_word_listなどの条件関数が並ぶ。Driveではtitleやfile_name、encryption_state、Gmailではbodyやsubject、all_headersなど、アプリごとに対象が違う。これを見ずに、全アプリで同じDLP条件が使える前提で設計しない。
下振れ
自社が使いたいアプリ、トリガー、アクションがMutate supportedの対象外、または必要な条件式に対応していない場合は、API管理に進まない方がよい。Admin consoleでの手動管理、audit-onlyでの観察、既存DLP運用の整理に戻す。
OU、グループ、ポリシーの見え方を整理する
Policy API overviewは、Admin consoleの見え方とAPIの見え方が異なることを説明している。Admin consoleでは、組織部門やグループに対する最終的なreduced setting valueが表示される。一方、Policy APIは明示的に設定されたsource of truth policiesを返す。
根拠
この違いは、差分確認で効いてくる。Admin console上では「このOUではこの値」と見えていても、APIで取得するのは、どこに明示設定があるかというポリシーの実体だ。親OUから継承しているのか、グループに別設定があるのか、明示設定が複数あるのかを区別する必要がある。
実務上の確認
API化の前には、対象OU、対象グループ、ルールの状態、検出器、アクション、優先順位を一覧にする。Admin consoleの画面キャプチャだけでなく、Get、Listで取得したポリシー名と設定値を保存する。これがないと、patch後に「画面上は変わったが、どの明示ポリシーが変わったのか」が追えない。
権限と実行経路を決める
- 1サービスアカウント
用途をPolicy APIに限定し、認証情報の削除、ローテーション、停止手順を用意する。
- 2Domain-wide delegation
管理者として呼び出すための委任範囲と承認者を確認する。
- 3OAuth scope
cloud-identity.policies scopeを誰が承認し、どの実行環境で使うかを記録する。
- 4super admin承認
通常のDLP管理権限と混同せず、API mutateを許可する責任者を明確にする。
- 5実行ログとDLPログ
変更前後のポリシー名、実行者、発火ログ、アラートを照合する。
super adminで実行できる経路を広げるほど、実行者、承認者、レビュー者を分ける必要があります。
super admin必須を運用リスクとして扱う
Cloud Identity Policy API overviewは、Policy APIを使用できるのはsuper administratorのみと説明している。Workspace Updatesの発表でも、管理者向けの開始条件としてsuper adminが必要だと案内している。
これは便利さよりも先に、権限リスクとして扱うべき点だ。DLPは外部共有、送信、添付、ブラウザ操作、警告、ブロックに影響する。super admin権限でAPIを実行できる経路を広げるなら、実行者、承認者、レビュー者を分けておかないと、事故時の説明が難しくなる。
条件
DLP HelpにはDLPルールの閲覧や管理に関する権限の説明があるが、Policy API mutateの利用条件はそれとは別に見る。通常のDLP管理権限や委任管理者権限があるからAPI mutateもできる、と短絡しない。
運用上の分離
少なくとも次の分離を設計する。
- ルール案を作る担当者。
- 公式設定とMutate supportedを確認する担当者。
- super adminとしてAPI実行を承認する担当者。
- 実行ログとDLPログを照合する担当者。
- 誤設定時に戻す判断をする担当者。
小さな組織でも、同じ人が全役割を持つ場合は、チェックリストと変更記録だけは分けて残す。
Domain-wide delegationとOAuth scopeを確認する
Google Cloudのcreate、patch、delete手順では、サンプル内でhttps://www.googleapis.com/auth/cloud-identity.policiesというPolicy API用のscopeが使われている。管理者メールを指定し、Domain-wide delegationで管理者として呼び出す流れも示されている。
根拠
この構成では、単にAPIキーを持っていればよいわけではない。サービスアカウント、IAM、Domain-wide delegation、OAuth scope、管理者メール、実行環境のログが関係する。DLP変更がCIやスクリプトに乗るほど、認証情報の管理と実行履歴の保全が重要になる。
確認項目
実装前のレビューでは、次をチェックする。
- サービスアカウントの用途がPolicy APIに限定されているか。
- Domain-wide delegationの許可が過剰になっていないか。
cloud-identity.policiesscopeを誰が承認したか。- 実行する管理者メールが共有アカウントになっていないか。
- CIやローカル実行のログに、変更前後のポリシー名と実行者が残るか。
- 認証情報を削除、ローテーション、停止できる手順があるか。
GAM、自前スクリプト、CIの分担を決める
Workspace Updatesは、GAMがPolicy APIをサポートしていることにも触れている。GAMはGoogle Workspace管理者に広く使われるオープンソースツールだが、この記事ではGAMのコマンド手順に深入りしない。重要なのは、どの用途をどの実行経路に任せるかだ。
評価基準
一回限りの棚卸しならGAMや手元のスクリプトで十分な場合がある。継続的にポリシーを反映するなら、Git管理、レビュー、CI、変更ログが必要になる。自社独自の承認、差分検査、監査レポートを入れたいなら、自前スクリプトや社内ツールとの連携も候補になる。
注意点
GAMを使えば統制が不要になるわけではない。super admin権限でDLPを変更できるコマンドが増える分、実行ログ、承認、ロールバック、対象ドメインの確認を強くする必要がある。コマンドの具体的な正確性が必要な場合は、GAM側の最新ドキュメントも別途確認する。
Admin console運用とAPI運用をどう分けるか
APIで作成できることと、ルール設計まで自動化してよいことは別に考えると事故を減らせます。
ルール設計は人間がレビューする
DLPルールは、検出条件とアクションの組み合わせで業務に大きく影響する。例えば、クレジットカード番号らしき文字列を含むファイルの外部共有を止めるのか、ユーザーに警告だけ出すのか、監査ログに残すだけにするのかで、現場の体験は大きく変わる。
APIで作成できるからといって、ルール設計まで完全自動にする必要はない。むしろ、設計はAdmin consoleや設計レビューで人間が確認し、反映だけをAPIに任せる分担から始める方が堅い。
確認項目
レビュー対象は、scope、condition、action、detector、severity、state、対象OUまたはグループ、通知先、例外条件だ。検出器では、word list、regular expression、predefined detectorをどう使い分けるかも見る。
注意点
自動生成されたルールをいきなりACTIVEにしない。まずaudit-only、限定OU、低リスクな検出器、短い検証期間で動作を見る。DLPは「止められる」ことだけでなく、止めすぎないことも品質になる。
Admin consoleとの差分を前提にする
Admin consoleとPolicy APIで見えるものが違う以上、差分確認は運用に組み込む必要がある。APIで作ったルールがAdmin consoleでどう表示されるか、Admin consoleで変更したルールがAPIでどう見えるかを、初期検証で確認しておきたい。
根拠
Policy API overviewは、Admin consoleがreduced setting valueを表示し、APIが明示設定されたsource of truth policiesを提供すると説明している。これは、画面上の最終値とAPI上のポリシー実体を照合しなければならないという意味だ。
評価基準
次の照合ができれば、初期運用としては前に進めやすい。
- 同じルール名をAdmin consoleとAPIで確認できる。
- 同じ検出器名をAPIで取得できる。
- 対象OUまたはグループが一致する。
- stateとactionが意図通りに見える。
- 変更前のスナップショットと変更後の差分が残る。
audit-onlyから本番アクションへ進める
Workspace DLP Helpは、optional actionを付けないルールでテストできることを説明している。該当した場合はRule log eventsに記録される。これは、API自動化の初期段階でも有効な考え方だ。
根拠
DLPの目的は、機密情報の外部共有や送信を制御することだが、最初からブロックすると業務影響が読み切れない。audit-onlyで対象ファイル、対象ユーザー、発火頻度、誤検知を見てから、warningやblockingへ進める方が安全だ。
上振れと下振れ
上振れは、audit-onlyで誤検知が少なく、想定通りのルールだけが発火し、warningやblockへ段階移行できる状態だ。下振れは、正規表現やword listが広すぎる、対象OUが広すぎる、DriveとGmailで同じ検出器を使った結果が違いすぎる、という状態だ。その場合は、API反映ではなく条件設計に戻る。
監査、変更管理、戻し方を先に決める
- 1Get/Listで現状保存
既存ルール、検出器、対象OUやグループ、action、state、API上のポリシー名を残す。
- 2差分レビュー
変更前後の差分と公式ドキュメント上の対象範囲を、実行前に確認する。
- 3audit-only反映
限定OUや低リスクな検出器から始め、想定したログだけが出るかを見る。
- 4ログ確認
Rule log events、Alert Center、Security Investigation Toolで発火状況を追う。
- 5本番アクションへ移行
誤検知や業務影響が許容できる場合に、warningやblockingへ段階的に進める。
- 6ロールバック判断
復元方法を説明できないDeleteや検出器削除は、本番では避ける。
特にDeleteは戻しにくいため、復元方法と依存ルールの確認を先に置くことが重要です。
変更前スナップショットを残す
Create、Update、Deleteのうち、特にDeleteは戻しにくい。削除前にGet、Listで現状を保存し、対象ポリシー名、検出器、OU、グループ、状態、アクション、severity、説明、作成者、最終更新日時を記録する。
確認項目
最低限、次の情報を変更前に残す。
- 既存ルールと検出器の一覧。
- 各ルールが参照する検出器。
- どのOUまたはグループに適用されるか。
- actionがaudit、warn、block、quarantine、label適用などのどれか。
- Admin consoleでの表示とAPIでのポリシー名。
- 変更前後の差分。
Deleteの注意点
検出器を削除すると、複数のルールに影響する可能性がある。ルール単体の削除よりも広い影響確認が必要だ。Deleteを使う前に、依存ルール、影響するアプリ、監査ログ、復元方法を確認する。復元方法を説明できないDeleteは、原則として本番では避ける。
監査ログとアラートで検証する
DLP Helpは、DLP rulesが違反を検出し、incidentやprotective action、alertにつながる流れを説明している。API変更後は、反映に成功したかだけでなく、想定したログやアラートが出るかを見る。
根拠
DLPはルールを作って終わりではない。Rule log events、Alert Center、Security Investigation Toolなど、組織の確認導線と結びついて初めて運用になる。audit-onlyで出るログを見てから、warningやblockingのアクションへ進める。
評価基準
検証では、次を見る。
- 想定したルールだけが発火しているか。
- 発火しないはずの部門やグループで発火していないか。
- 通知先やアラートの優先度が適切か。
- 業務上必要な共有や送信を過剰に止めていないか。
- ログにルール名、検出器、対象ユーザー、対象ファイルまたはメッセージが追える形で残るか。
検出器のライフサイクルを管理する
DLPの自動化で見落としやすいのが、ルールではなく検出器の寿命だ。word listやregular expressionは、最初は小さく始めても、業務に合わせて語句やパターンが増えていく。使われなくなった検出器、広すぎる検出器、似た名前の検出器が増えると、APIでの管理も難しくなる。
確認項目
検出器には、名前、説明、所有者、用途、対象アプリ、参照するルール、更新履歴、廃止基準を持たせる。predefined detectorを使う場合も、likelihood thresholdやminimum match countをどう置くかを決める。
注意点
検出器は複数ルールから参照されることがある。検出器をpatchすると、参照元のルールすべての挙動が変わる可能性がある。ルール変更より広い影響確認が必要だ。
導入判断チェックリスト
Mutate supported、super admin実行経路、Domain-wide delegation、差分レビュー、audit-only検証、戻し方がそろっている。
ルール案はあるが、誤検知、対象アプリ、通知先、Admin consoleとの照合、ログ確認が未確定。
super admin実行、委任管理、削除影響、対象外設定、既存DLP運用のどれかを説明できない。
Goが常に優位という比較ではなく、自社の権限管理、監査、戻し方に応じて段階を選ぶための整理です。
Goにできる条件
対象設定がMutate supportedで、super adminの実行経路、Domain-wide delegation、差分レビュー、audit-only検証、ログ確認、戻し方まで決まっているなら、限定的な本番導入に進める。
評価基準
Goにするなら、まず小さく反映する。全社一括ではなく、限定OU、限定グループ、低リスクな検出器、audit-onlyまたはwarningから始める。変更前スナップショットを保存し、変更後のログ確認まで同じ作業単位に入れる。
次の確認
本番反映の単位を小さくし、ルールごとに所有者を置く。API反映のPRや変更申請には、公式ドキュメントの該当箇所、Mutate supportedの確認、ロールバック手順を添える。
Trialにすべき条件
ルール案はあるが、誤検知、対象アプリ、通知先、Admin consoleとの照合、ログ確認が未確定ならTrialに留める。これは失敗ではなく、DLP自動化では自然な段階だ。
評価基準
Trialでは、audit-only、限定OU、低リスクなword list、短い検証期間を使う。結果を見て、検出器、条件式、action、対象範囲を調整する。
次の確認
Trialの成果は「本番に進む」だけではない。API化しない方がよい設定、Admin consoleで人間が確認すべき設定、そもそもルール化しない方がよい業務例外を見つけることも成果だ。
Waitにすべき条件
super admin実行を許可できない、Domain-wide delegationの管理が未整備、削除影響を説明できない、Mutate supportedの対象外、既存DLP運用が整理されていない。この場合はWaitが妥当だ。
評価基準
Waitにする基準は、技術的に不可能かどうかだけではない。変更権限が強すぎる、監査ログを見ない、戻し方がない、業務影響を説明できないなら、API化は先送りする。
注意点
API対応を理由に、未整理のDLPルールを自動化しない。自動化は、よく設計された運用を速くする。未整理の運用を速くすると、事故も速くなる。
2026年6月の更新としてどう追うか
Workspace UpdatesのDLP mutate endpoints発表を、2026年6月の管理者向け重要トピックとして押さえる。
Google Workspace、Gemini、Android、Google Cloudの更新と並べて、優先度を見直す。
公式情報と読者需要を分けて見て、API自動化の検討タイミングを決める。
DLPは単発ニュースではなく、Workspace管理、監査、セキュリティ運用の更新として継続的に追うテーマです。
今回のDLP mutate endpointsは、Google Workspaceの管理者向け更新として、2026年6月の重要トピックに入る。Google Workspace、Gemini、Android、Google Cloudの更新を横断して追う場合は、サイトの<a href="https://googl-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>も合わせて確認したい。
公式情報と需要シグナルの分け方は、<a href="https://googl-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>の固定ページでも整理している。この記事でも、外部ブログやコミュニティの反応は需要シグナルとして扱い、仕様の根拠は公式発表とGoogle Cloudドキュメントに限定した。
WorkspaceやGoogle製品更新をまとめて読む場合は、<a href="https://googl-watch.blog.mo-gmo.com/category/products-services-solutions/">製品・サービス・ソリューション</a>カテゴリが近い。DLP、監査、保持、法務リスクの文脈では、<a href="https://googl-watch.blog.mo-gmo.com/category/regulation-risk/">規制・リスク</a>カテゴリも補助線になる。
次に読むなら
更新履歴と読者向けメモ
2026年6月16日にWorkspace Updates、Cloud Identity Policy API、Supported Policy API settings、Workspace DLP Helpを確認した。
対象アプリ、対象OU、対象グループ、権限、ログ確認導線をAdmin consoleで確認する。
公式ドキュメントのLast updated、Mutate supported、GAM側の対応状況は運用前に見直す。
公開時点の情報をそのまま手順化せず、実行前に公式ドキュメントと自社設定を照合する前提で使います。
2026年6月16日、Workspace Updates、Cloud Identity Policy API overview、Creating, patching, and deleting policies、Supported Policy API settings、Workspace DLP Helpを確認して公開した。
この記事の実務メモを使う場合は、まず自社のAdmin consoleでDLP対象アプリ、対象OU、対象グループ、権限、ログ確認導線を見てほしい。公式ドキュメントのLast updated、Supported Policy API settingsのMutate supported列、Workspace UpdatesのAvailabilityは変わる可能性がある。
Alphabet Watch Japanのニュースレターでは、Alphabetの公式発表、Google Workspace更新、Gemini関連の管理者向け変更、月次まとめの更新を控えめに通知している。読了後に更新を追いたい場合は、<a href="https://googl-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>を使える。
参照した主な情報源
- Google Workspace Updates「Introducing the Workspace Policy API mutate endpoints for DLP」確認日: 2026年6月16日
https://workspaceupdates.googleblog.com/2026/06/introducing-workspace-policy-api-mutate-endpoints-for-DLP.html
- Google Workspace Updates「Google Workspace Updates Weekly Recap – June 12, 2026」確認日: 2026年6月16日
https://workspaceupdates.googleblog.com/2026/06/weekly-recap-06-12-2026.html
- Google Cloud Documentation「Policy API overview」確認日: 2026年6月16日
https://docs.cloud.google.com/identity/docs/concepts/overview-policies
- Google Cloud Documentation「Creating, patching, and deleting policies」確認日: 2026年6月16日
https://docs.cloud.google.com/identity/docs/how-to/create-patch-delete-policies
- Google Cloud Documentation「Settings available in the API」確認日: 2026年6月16日
https://docs.cloud.google.com/identity/docs/concepts/supported-policy-api-settings
- Google Workspace Help「About DLP」確認日: 2026年6月16日
https://knowledge.workspace.google.com/admin/security/about-dlp