はじめに
クラウドのセキュリティ運用では、「誰に、どこまでの権限を、どのくらいの期間与えるか」という管理と、「データがどこに置かれ、誰がアクセスしうるか」という統制の2つが軸になります。2026年9月7日〜9月13日の期間は、この両方に関わるアップデートが集中しました。特権アクセス管理（PAM）に対する Access Approval / Access Transparency の一般提供（GA）対応、ヨーロッパ各国の主権データ境界（データ主権に対応した管理の枠組み）の対応製品拡大、そして AI から権限管理を扱うための MCP サーバーの提供が発表されています。
本記事では、この期間に公開された Google Cloud セキュリティカテゴリのリリースノート18件について、内容が重複する項目を整理したうえで主要トピックを解説します。なお、製品ごとに個別公開されるセキュリティ速報（Security Bulletin）は本記事の対象外です。特権アクセス管理（Privileged Access Manager）、データ主権（Assured Workloads / Sovereign Controls by Partners）、設定情報管理（Parameter Manager）、境界セキュリティ（VPC Service Controls）、権限分析（Policy Intelligence / Identity and Access Management）、セキュリティオペレーション（Google SecOps）まで、リリース日の昇順で取り上げます。
とりわけ Identity and Access Management（IAM）リモート MCP サーバーの一般提供（GA）と、Google SecOps の chronicle.readonly OAuth スコープから書き込み権限が削除される非推奨の告知（2027年1月25日に有効）は、自社環境への影響を確認しておきたい内容です。経営層はガバナンスとデータ主権の観点から、IT・セキュリティ担当者は適用判断と移行計画の観点から読み進めていただくと役立ちます。
| 対象期間 |
2026年9月7日〜2026年9月13日 |
| 対象製品 |
Google Cloud |
| 対象カテゴリ |
セキュリティ |
| アップデート件数 |
18件（重複する内容を整理し、10トピックとして解説） |
今回のアップデート一覧
アップデート詳細
1. Access Approval / Access Transparency — Privileged Access Manager への対応が一般提供（GA）に
Access Approval（Google のサポート担当者などがお客様データへアクセスする際に、明示的な承認を必須にする仕組み）と Access Transparency（そうしたアクセスの記録をログとして受け取る仕組み）の両方のリリースノートで、Privileged Access Manager（PAM）が対応サービスとして一般提供（GA）になったことが告知されました（2026年9月7日）。つまり、PAM に対する Google 側担当者のアクセスについて、承認と記録を正式サポートの状態で利用できるようになった、という位置づけです。なお PAM 製品自体は 2024年9月16日に一般提供（GA）となっています。同じ内容が2つの製品のリリースノートに掲載されているため、本記事では1つのトピックとして扱います。
🔍 何が変わったのか
- Access Approval および Access Transparency のリリースノートに、対応サービスとしての Privileged Access Manager が一般提供（GA）である旨が掲載されました
- Access Approval の公式ドキュメント「Supported services」の対応サービス一覧には、Privileged Access Manager が launch stage GA として掲載されています
- Access Transparency の「Supported services」（Access Transparency ログを書き出すサービスの一覧）にも、Privileged Access Manager が GA として掲載されています
- Privileged Access Manager は、「特権の一時的・期限付きの昇格を、承認ワークフローを伴って管理する」機能です。誰が昇格を申請できるか、どのロールを、どのくらいの期間付与するかを定義する entitlement（エンタイトルメント）と、申請が有効化されたときに期限付きで付与される grant（グラント）が中心的な概念です
💼 こんな場面で活用できます（ユースケース）
権限管理と内部統制を担う IT 部門・セキュリティ担当者、および監査対応の担当者が対象です。障害対応やメンテナンスのために管理者権限を一時的に必要とする運用では、恒常的に強い権限を配っておくのではなく、必要なときだけ期限付きで昇格させる運用が求められます。Privileged Access Manager がその申請・承認・失効を担い、Access Approval と Access Transparency が「Google 側からのアクセス」に対する承認と記録を担う、という役割分担で整理すると理解しやすくなります。
✨ 導入メリット
- 一時的・期限付きの権限昇格を仕組みとして扱えるため、常時付与された強い権限（standing privileges）を減らす設計を進めやすくなります
- PAM へのアクセス承認・記録が一般提供（GA）として対応済みと明示されたため、本番環境の統制設計に組み込む検討がしやすくなります
- 承認と記録が残る運用にすることで、監査対応時の説明材料を揃えやすく、属人化の解消にも寄与します
📚 公式ソース
2. Sovereign Controls by Partners — フランス・イタリア・ドイツの各データ境界が3製品に対応
Sovereign Controls by Partners（現地パートナーと連携して、国ごとのデータ主権要件に対応する枠組み）で、France Data Boundary by S3NS、Italy Data Boundary by PSN、Germany Data Boundary by T-Systems の3つのデータ境界が、いずれも AlloyDB for PostgreSQL、Apigee、Eventarc をサポート対象製品として掲載しました（2026年9月8日）。3件のリリースノートは対象製品が共通のため、本記事では1つのトピックにまとめています。
🔍 何が変わったのか
- France Data Boundary by S3NS、Italy Data Boundary by PSN、Germany Data Boundary by T-Systems の各データ境界で、AlloyDB for PostgreSQL / Apigee / Eventarc がサポート対象製品として掲載されました
- 公式ドキュメント（France Data Boundary by S3NS）では、データ境界のフォルダに対して適用される統制として、リソースの作成先リージョンを制限する組織のポリシー制約 gcp.resourceLocations の設定、および対象サービスに対する 顧客管理の暗号鍵（CMEK） の要求が挙げられています
- サポート対象製品は、製品名・API エンドポイント・制限事項を並べた表として掲載されており、表に掲載のない製品は対象外という位置づけです
💼 こんな場面で活用できます（ユースケース）
フランス・イタリア・ドイツに拠点や顧客を持ち、各国のデータ主権要件に沿った運用を求められる企業の IT 部門・法務／コンプライアンス担当者が対象です。現地パートナーが統制を担う枠組みの中で、利用できる Google Cloud 製品の範囲が広がるため、国ごとに別構成を維持する負担を減らす方向で検討できます。
✨ 導入メリット
- 各国のデータ境界で共通して3製品が対象になったため、国をまたぐシステムでも構成をそろえやすくなります
- データの所在地と暗号鍵の統制を前提とした設計の中で、標準的な製品を選びやすくなります
- グローバル展開におけるデジタル変革の検討材料として、対応可能な地域・構成の見通しが立てやすくなります
📚 公式ソース
3. Policy Intelligence / IAM — Policy Assist REST API が Preview で登場
Policy Intelligenceと Identity and Access Managementの両方のリリースノートで、Policy Assist REST API が Preview として提供開始されたことが告知されました（2026年9月9日）。Gemini の支援による IAM ロールの提案を、画面操作ではなくプログラムから取得できます。
🔍 何が変わったのか
- Policy Assist は、個々のプリンシパル（ユーザーやサービスアカウントなどの権限付与対象）に対して、AI の支援で IAM ロールの候補を提案する機能です
- その提案をプログラムから取得できる REST API が Preview で提供されました。公式ドキュメントでは、Policy Assist REST API の recommendIamRoles メソッドにより、自然言語のプロンプトからロール提案を得られると案内されています
- Google Cloud コンソールのロール選択（role picker）でも、必要な権限を言葉で説明して「Suggest roles」を実行することでロール候補を得られます。コンソール利用時は追加の API 有効化は不要で、REST API を使う場合は Policy Assist API の有効化が必要と記載されています
- 公式ドキュメントに記載された制限として、カスタムロールは提案できないこと、複数のプリンシパルに対して同時に提案できないこと、Google Workspace 製品向けのロールは対象外であることが挙げられています。また、提案されたロールは適用前に検証することが強調されています
💼 こんな場面で活用できます（ユースケース）
権限設計を担う IT 部門・クラウド管理者が対象です。Google Cloud には多数の事前定義ロールがあり、「この作業をさせたい」という要件から適切なロールを探す作業には知識と時間が必要です。API 経由で提案を取得できるようになると、社内の権限申請ワークフローや内製ツールの中に、ロール候補の提示を組み込むといった使い方が検討できます。
✨ 導入メリット
- ロール選定の初期検討を効率化でき、権限付与までのリードタイム短縮に寄与します
- 過剰な権限を避けた設計を検討しやすくなり、最小権限の運用に近づけられます
- 権限設計のノウハウが特定担当者に偏りにくくなり、属人化の解消に役立ちます
📚 公式ソース
4. Policy Intelligence — Policy Assist リモート MCP サーバーが Preview で提供
Policy Assist リモート MCP サーバーが Preview で利用可能になりました（2026年9月9日）。MCPは、AI アプリケーションやエージェントを外部のツール・データへ接続するための標準的な仕組みです。これにより、外部の AI エージェントやアプリケーションから IAM ロールの提案を受け取れるようになります。
🔍 何が変わったのか
- 外部の AI アプリケーション（公式ドキュメントでは Gemini CLI、ChatGPT、Claude、独自アプリケーションが挙げられています）から、IAM のロール提案機能を利用できるようになりました
- 提供されるツールとして recommend_iam_roles が案内されています。サービスの管理に必要なロール、特定の作業に必要なロール、CLI コマンドの実行に必要なロールなど、さまざまな観点での問い合わせに対応すると記載されています
- 前提条件として、policyassist.googleapis.com の有効化、MCP Tool User（roles/mcp.toolUser）ロール、カスタムロールに関する提案には IAM Viewer（roles/iam.viewer）ロールが挙げられています
- 認証は OAuth 2.0 を使用し、API キーは利用できないと明記されています
- 本機能は Preview 段階であり、一般提供前（Pre-GA）の規約が適用され、サポートが限定される旨が記載されています
💼 こんな場面で活用できます（ユースケース）
AI エージェントを活用した運用を進めている IT 部門・プラットフォームチームが対象です。たとえば開発者が「この作業をするために必要なロールは何か」を AI アシスタントに尋ね、その場で候補を得るといった使い方が想定できます。権限に関する問い合わせが管理者へ集中する状況を緩和する方向で検討できます。
✨ 導入メリット
- 権限に関する相談を対話的に進められ、問い合わせ対応の負荷軽減につながります
- 既存の AI アプリケーションから利用できるため、新たな専用ツールを用意せずに検証を始められます
- 権限設計の検討スピードが上がり、プロジェクト立ち上げの初速向上に寄与します
📚 公式ソース
5. Identity and Access Management — IAM リモート MCP サーバーが一般提供（GA）
Identity and Access Management（IAM）リモート MCP サーバーが一般提供（GA）になりました（2026年9月10日）。AI アプリケーションから接続することで、カスタムロールと拒否ポリシーをリソース横断で点検・管理できます。2026年9月1日に一般提供となった Policy Analyzer MCP サーバーに続き、権限管理を AI から扱うための選択肢が広がった形です。
🔍 何が変わったのか
- AI アプリケーションから IAM リモート MCP サーバーへ接続し、カスタムロールと拒否ポリシーをリソース横断で点検・管理できるようになりました
- カスタムロールについては、一覧取得・取得・作成・更新・削除・復元といった操作に対応するツールが案内されています
- 拒否ポリシーについては、一覧取得・取得・作成・更新・削除に加え、適用状況を確認するための状態取得が案内されています
- 利用にあたっては、必要な API の有効化、OAuth 2.0 による認証の構成、および IAM リソースを管理できる適切なロールの付与が前提として記載されています
💼 こんな場面で活用できます（ユースケース）
権限管理・ガバナンスを担う IT 部門やセキュリティ担当者が対象です。組織が大きくなるほど、独自に作ったカスタムロールや、特定の操作を明示的に禁止する拒否ポリシーが各所に散らばり、全体像の把握が難しくなります。AI アプリケーション経由で横断的に照会・整理できれば、棚卸しやレビューの作業を対話的に進められます。
✨ 導入メリット
- カスタムロールや拒否ポリシーの棚卸しを効率化でき、権限レビューの工数削減に寄与します
- 一般提供（GA）となったため、本番環境の運用フローへの組み込みを検討しやすくなります
- 権限の全体像を把握しやすくなることで、ガバナンス強化と意思決定スピードの向上につながります
📚 公式ソース
6. Google SecOps / SecOps SIEM — chronicle.readonly OAuth スコープから書き込み権限を削除（非推奨）
Google SecOps および Google SecOps SIEM（ログを集約して脅威を検知する仕組み）で、chronicle.readonly OAuth スコープからの書き込み権限の削除が非推奨として告知されました（2026年9月11日）。2027年1月25日に有効となる変更で、既存のワークフローに影響しうる内容のため、以下に整理します。同じ内容が2つの製品のリリースノートに掲載されているため、1つのトピックとしてまとめています。
🔍 何が変わったのか
- 2027年1月25日をもって、chronicle.readonly OAuth スコープから書き込み権限が削除され、このスコープは読み取り操作に厳密に限定されます
- 公式リリースノートでは、書き込み操作を行っているワークフローは chronicle OAuth スコープを使用するように更新することが案内されています
💼 こんな場面で確認が必要です（ユースケース）
Google SecOps の API を使って、外部システムとの連携や自動化のスクリプトを構築している SecOps エンジニア・開発担当者が対象です。たとえば、検知結果を取得して社内システムへ反映するだけでなく、ケースの更新やデータの登録といった書き込み操作を行っている連携がある場合、そのスクリプトやサービスアカウントが要求しているスコープの棚卸しが確認の出発点になります。
✨ 使えるようになる機能
- 本告知は非推奨に関する内容であり、公式リリースノートでハイライトされた新機能はありません
- chronicle.readonly スコープは、読み取り操作については引き続き利用できると明記されています
⚠️ 使えなくなる機能 / 変更点
- 2027年1月25日から、chronicle.readonly スコープでの書き込み操作ができなくなります
- 書き込み操作を継続するには、chronicle OAuth スコープへの切り替えが必要と案内されています
- 公式リリースノートに、上記以外の廃止項目・既知の不具合・CVE 情報の記載はありません
🤔 判断観点
- 影響範囲の特定: 自社で Google SecOps の API を呼び出している連携・スクリプト・サービスアカウントを洗い出し、chronicle.readonly スコープを要求しているものがどれかを確認する観点があります
- 書き込み操作の有無: 洗い出した対象のうち、実際に書き込み操作を行っているものがあるかを切り分ける観点があります。読み取りのみであれば、今回の変更による影響は案内されていません
- 期限までの猶予: 有効日は2027年1月25日と示されています。年度計画や既存の開発スケジュールのどこに移行作業を組み込むかを検討する観点があります
- 検証推奨事項: chronicle スコープへ切り替えた場合に、権限の範囲が想定どおりか（必要以上に広い権限にならないか）を検証環境で確認する観点があります
- ロールアウト戦略: 影響のある連携が複数ある場合、重要度の高い連携から段階的に切り替えるか、一括で切り替えるかを検討する観点があります
- ドキュメントの継続確認: 有効日までに追加の案内が出る可能性を踏まえ、Google SecOps 専用リリースノートを定期的に確認する観点があります
📚 公式ソース
7. Assured Workloads — EU Data Boundary with Access Justifications が3製品に対応
Assured Workloads（規制要件に対応した構成を、フォルダ単位のコントロールパッケージとして適用する仕組み）で、EU Data Boundary with Access Justifications が新たに AlloyDB for PostgreSQL、Apigee、Eventarc をサポート対象製品として掲載しました（2026年9月8日）。
🔍 何が変わったのか
- EU Data Boundary with Access Justifications のサポート対象製品として、AlloyDB for PostgreSQL、Apigee、Eventarcが追加されました
- 公式ドキュメントでは、このコントロールパッケージについて、データの所在地を EU 内のリージョンに限定する設定、暗号鍵のアクセス理由を扱う Key Access Justifications、担当者のアクセスを記録する Access Transparency が含まれると案内されています
- サポート対象製品は、製品名・API エンドポイント・製品固有の制限を並べた表の形式で掲載されています。表に掲載がない製品は「サポート対象ではない」という位置づけです
💼 こんな場面で活用できます（ユースケース）
EU 圏での事業展開にあたり、データの所在地や運用担当者のアクセス統制を求められる企業の IT 部門・コンプライアンス担当者が対象です。これまで対象製品の制約からアーキテクチャを組み替えていたケースでも、データベース（AlloyDB for PostgreSQL）、API 基盤（Apigee）、イベント連携（Eventarc）が対象に加わることで、標準的な構成のまま要件を満たせる可能性が広がります。
✨ 導入メリット
- 規制要件に対応した環境で採用できる製品の選択肢が広がり、設計の自由度が高まります
- 要件対応のための独自実装や回避策を減らせるため、開発・運用コストの抑制につながります
- コントロールパッケージとして統制を適用できるため、監査時に構成の根拠を示しやすくなります
📚 公式ソース
8. Secret Manager（Parameter Manager）— タグによる整理と条件付きアクセス制御に対応
Parameter Manager（アプリケーションの設定値＝パラメータを一元管理する機能）で、タグを使ってパラメータをグループ化・整理し、IAM ポリシーによる条件付きのアクセス制御を行えるようになりました（2026年9月8日）。
🔍 何が変わったのか
- タグを使って、パラメータをグループ化・整理できるようになりました
- 公式ドキュメントでは、タグを使って「リソースが特定のタグを持つかどうかに基づいて、ポリシーを条件付きで許可または拒否できる」と案内されています
- タグの管理には、Tag Viewer（閲覧）、Tag Administrator（タグ定義の作成・変更）、Tag User（リソースへの付け外し）、および Parameter Manager Admin といったロールが挙げられています
- 注意点として、条件付きのロールバインディングを適用している場合、リソースに付与されたタグを変更・削除するとアクセス権が失われる可能性があることが明記されています。また、タグ定義は付与の前に作成しておく必要があり、継承されたタグは直接切り離せず上書きで対応する点も記載されています
💼 こんな場面で活用できます（ユースケース）
複数の環境（開発・検証・本番）や複数チームでアプリケーション設定を管理している開発チーム・プラットフォーム担当者が対象です。たとえば「本番環境向けのパラメータには、運用チームのみがアクセスできる」といった制御を、パラメータを1件ずつ指定するのではなく、タグという共通の属性を条件として表現できます。環境やシステムが増えても、アクセス制御の記述が膨らみにくくなります。
✨ 導入メリット
- パラメータを属性で束ねて管理でき、設定管理の見通しがよくなります
- 条件付きアクセス制御によって、最小権限の設計を保ちやすくなり セキュリティ強化に寄与します
- 個別のポリシー記述を減らせるため、権限設定の運用負荷を抑えられます
📚 公式ソース
9. VPC Service Controls — Observability API との統合が一般提供（GA）
VPC Service Controlsで、Observability API との統合が一般提供（GA）としてサポートされました（2026年9月8日）。VPC Service Controls は、対応する製品・API が増えるほど、境界の内側でカバーできる範囲が広がります。
🔍 何が変わったのか
- Observability API が、VPC Service Controls の統合対象として一般提供（GA）でサポートされました
- 対応状況は、公式の「Supported products and limitations」に掲載されている Observability API の表で確認できます
💼 こんな場面で活用できます（ユースケース）
サービス境界を設計・運用するセキュリティ担当者・クラウド管理者が対象です。監視やオブザーバビリティに関わるデータも、機微な情報を含みうるという前提で統制対象に含めたいケースがあります。Observability API が境界の対象になることで、境界の設計から外れる例外を減らす方向で検討できます。
✨ 導入メリット
- 境界の対象範囲が広がることで、例外的な扱いを減らし、統制の一貫性を保ちやすくなります
- 一般提供（GA）としてのサポートのため、本番環境の境界設計に組み込む検討がしやすくなります
- データ持ち出しリスクの低減につながり、ガバナンス強化に寄与します
📚 公式ソース
10. Google SecOps Marketplace — 4つの統合が更新
Google SecOps Marketplace（セキュリティオペレーション基盤と各種製品をつなぐ「統合」を提供するマーケットプレース）で、4件の統合アップデートが公開されました（2026年9月9日）。いずれも既存の統合に対する更新です。
�� 何が変わったのか
| 統合 / バージョン |
更新内容 |
Trend Vision One
バージョン 12.0 |
Isolate Endpoint と Unisolate Endpoint の各アクションで、Description パラメータが必須になりました（エンドポイントの隔離・隔離解除の操作です） |
Google Chronicle
バージョン 95.0 |
統合部分において、OAuth 2.0 / JWT 認証のログ記録、検証時の診断情報、エラーメッセージが改善されました |
Google Chronicle
バージョン 95.0 |
新しいアクション Is Value In Data Table Async が追加されました |
Microsoft 365 Defender
バージョン 31.0 |
Microsoft 365 Defender - Incidents Connector で、アラート追跡のロジックが更新され、アラートオブジェクトのメタデータが抽出されるようになり、ページネーションとタイムアウト処理の仕組みが改善されました |
💼 こんな場面で活用できます（ユースケース）
SOC（セキュリティ監視チーム）やインシデント対応の自動化を担う SecOps エンジニアが対象です。エンドポイントの隔離は影響の大きい操作のため、実行理由（Description）を必須にすることで、後から「なぜこの端末を隔離したのか」を追跡しやすくなります。また Microsoft 365 Defender のインシデント連携では、大量のアラートを取り込む際のページネーションやタイムアウトの扱いが改善されています。
✨ 導入メリット
- 影響の大きい操作に理由が残る運用となり、対応履歴の説明性が高まります
- 認証まわりのログ・診断情報の改善により、連携トラブル時の原因切り分けがしやすくなります
- アラート取り込みの安定性向上は、監視の取りこぼしを抑える運用品質の向上に寄与します
📚 公式ソース
まとめ
2026年9月7日〜9月13日のセキュリティカテゴリは、特権アクセス管理・データ主権・権限分析の AI 活用という3つの軸で動きがありました。とりわけ IAM リモート MCP サーバーの一般提供（GA）と Policy Assist（REST API / MCP サーバー、いずれも Preview）は、「誰に何を許可しているか」を扱う作業を AI アプリケーションから進められるようにするもので、権限レビューや棚卸しの進め方に影響しうるアップデートです。
また、EU Data Boundary with Access Justifications と フランス・イタリア・ドイツの各データ境界が、そろって AlloyDB for PostgreSQL / Apigee / Eventarc に対応した点は、欧州でのシステム構築における設計の選択肢を広げます。一方で、chronicle.readonly OAuth スコープからの書き込み権限の削除のように、既存の連携の棚卸しが必要になりうる変更もあります。公式ドキュメントをもとに、自社の利用状況に応じた確認と計画づくりを進めていただければと思います。
関連 XIMIX 記事
Google Cloud アップデート情報をシリーズでご覧になりたい方は、アップデート情報一覧から過去の記事もご確認いただけます。
XIMIX からのご案内
XIMIX（サイミクス）は NI+C が運営する Google Cloud プレミアパートナーサービスです。Google Cloud / Google Workspace の導入・活用支援、セキュリティ強化、データ活用などをご支援しています。本記事で取り上げた Privileged Access Manager や Policy Intelligence、Identity and Access Management、Google SecOps などの活用にご関心がありましたら、お気軽にご相談ください。
お問い合わせはこちら
参考資料