Google Cloudでデータの持ち出しを防ぐ境界（VPC Service Controls、以下VPC-SC）を作ったものの、新しいプロジェクトを作るたびに境界へ追加するのを忘れる。逆に、開発の途中で通信が拒否され、急いで広い例外を足してしまう。Google Cloudの公式ブログも、広すぎる境界はデータの持ち出しの危険を増やし、厳しすぎる境界は拒否の多さで開発を止める、と書いています。
2026年10月15日（日本時間16日）、Google CloudはVPC-SCの更新を公式ブログでまとめて紹介しました。境界にフォルダを入れられるようになり、拒否された通信に対しては、範囲を絞った修正案が出るようになります。ブログは、この更新が一般提供（GA）で、追加費用はかからないとしています。ただし、リリースノートで機能ごとに確かめると、一般提供になった時期はそれぞれ違い、修正案はプレビューのままです。この記事では、ブログとドキュメントから何が変わったかを整理し、既存の境界を見直す順番を提案します。
何が変わったか
ブログが挙げる更新の提供段階は、リリースノートでは次のとおりです。
| 更新 | 提供段階 | リリースノートの日付 |
|---|---|---|
| 境界のメンバーにフォルダを入れる | 一般提供 | 2026年9月30日 |
| 上り・下りのルールにフォルダと組織を書く | 一般提供 | 2026年9月30日 |
| 上り・下りのルールにPrivate Service Connectのエンドポイントを書く | 一般提供 | 2026年6月30日 |
| VPCからアクセスできるサービスの「サービスのパターン」 | 一般提供 | 2026年8月6日 |
| 拒否の修正案（Violation Analyzer） | プレビュー | 2026年10月8日 |
追加費用については、料金のページにも、VPC-SCの利用に別の料金はかからないと書かれています。内容は次の4つです。
- 境界のメンバーにフォルダを入れられる: フォルダを境界に入れると、その中のプロジェクトと、入れ子のサブフォルダのすべてに、境界のポリシーが及びます。新しく作ったワークロードは、追加の作業なしで保護を受けます。プロジェクトを別のフォルダへ移すと、境界のメンバーも自動で更新されます。ドライランのモードも、フォルダのメンバーに対応しています
- 上り・下りのルールにフォルダと組織を書ける: 内向き（ingress）と外向き（egress）のルールに、Google Cloudのフォルダや組織を直接指定できます。ブログは、1つの階層の指定がその下のプロジェクトの集まりの代わりになり、ルールが短くなり、属性の数が割り当ての上限に収まりやすく、後から作るプロジェクトにも自動で及ぶと説明しています
- Private Service Connectのエンドポイントを条件にできる: Google APIs向けのPrivate Service Connectのエンドポイントを、上り・下りのルールの属性に指定できます。特定の非公開の経路を通るアクセスだけを許可する、といったルールが書けます。ドキュメントは、エンドポイントを
vpc-scのAPIバンドルで作るよう案内しています。あわせて、VPCからアクセスできるサービスの「サービスのパターン」で、非公開のVIPやall-apisバンドルのエンドポイントで使うGoogle APIsのうち、必要なAPIのURLのパターンだけを許可できます - 拒否の修正案が出る（プレビュー）: VPC-SCのViolation Analyzerに、修正案の機能が加わりました。ブログの呼び名は「Guided Violation Remediation」、ドキュメントの呼び名は「remediation suggestions」です。拒否された要求を境界の設定と照らし合わせ、最小権限の考え方で範囲を絞った変更（上りのルール、下りのルール、アクセスレベル、VPCからアクセスできるサービスの更新のいずれか）を提案します
ブログは「この更新は一般提供」と書いていますが、修正案のドキュメントにはプレビューの表示があり、リリースノートも2026年10月8日に「Status: Preview」として載せています。この記事では、機能ごとの表示があるリリースノートとドキュメントに合わせました。
ブログは、提案をドライランで先に確かめられるとも書いています。一方、ドキュメントの手順は、コンソールで「Apply remediation」を押すと境界の設定が更新される流れで、ドライランで確かめる手順は載っていません。また、ブログは拒否された要求の解決にかかる時間が「数日から数分」になるとしています。これはGoogle Cloudの説明で、編集部では計測していません。
なぜ今、境界の作り方を見直すのか
ブログはこの更新を、AIエージェントの利用と結びつけて説明しています。エージェントは利用者の代わりに、あるいは自律して動き、プロジェクトをまたいでデータを要求します。ブログはエージェントを人以外のID（NHI）の一種と位置づけ、既定で安全になるガードレールが要るとしています。
ここからは編集部の整理です。プロジェクトを1つずつ境界に入れる運用では、エージェント用や検証用のプロジェクトが増えるほど、境界の外にあるプロジェクトが生まれやすくなります。フォルダで境界を引けば、「どのフォルダに置くか」が、基本的に「どの境界に入るか」になります。ブログも、準拠の確認は、リソースが階層の正しい場所にあるかを確かめるだけで済むと書いています。ただし、次の節で見るように、プロジェクトを直接指定した境界があると、そちらが優先されます。
既存の境界を見直す順番
ブログは、始め方として4つの手順を示しています。フォルダの基準を決め、ドライランで本番の通信を観察し、Violation Analyzerの提案で拒否を解消し、ドライランのログが意図どおりになってから適用に移る、という流れです。
ドキュメントには、プロジェクトの直接指定からフォルダへ安全に移す手順もあります。境界にフォルダを足し、プロジェクトをそのフォルダへ移し、階層の変更が行き渡るまで直接指定を残し、最後に直接指定を外す、という順番です。行き渡るまでの時間は通常は数分で、もっとかかる場合もあるとされています。
これらの流れに、既存の境界から移るときに確かめる点を、編集部の提案として加えます。
- 境界と対応するフォルダを決める: 本番、検証、AIエージェントの実行用など、守りたい範囲とフォルダの構成が一致しているかを確かめます。フォルダの中の一部のプロジェクトだけを別の境界に入れることはできます。プロジェクトを直接指定した境界が、フォルダから受け継いだ境界より優先されるためです。ただ、例外が増えるほど、フォルダで引く利点は薄れます。先にプロジェクトの置き場所を整理します
- 既存の境界のドライランの設定にフォルダを足す:
gcloud access-context-manager perimeters dry-run updateでフォルダを足し、どの通信が拒否される見込みかをログで見ます。プロジェクト単位の境界を残したまま、別の境界をフォルダで作ってドライランにする方法は、この記事では勧めません。ドキュメントの優先順位の説明からは、適用中の境界にプロジェクトを直接入れていると、ドライランでもその割り当てが優先されると読めるためです（編集部は実機では確かめていません）。どの境界が効いているかは、gcloud access-context-manager lookup-configured-perimeterで確かめられます - 上り・下りのルールを階層の指定に置き換える: プロジェクトを列挙しているルールを、フォルダや組織の指定にまとめます。ただし、フォルダに後から作るプロジェクトにも自動で許可が及ぶ点は、利点であると同時に、許可の範囲が広がる点でもあります。ドキュメントは、フォルダや組織を指定すると、その直下にある、境界では保護できないリソースにもアクセスが許可されると注意しています。どのフォルダを指定してよいかを、ルールごとに決めます
- 修正案は、そのまま適用せず読む: 修正案はプレビューです。ドキュメントの制限によると、監査ログで呼び出し元が伏せられていると
ANY_USER_ACCOUNTのような汎用のIDになる場合があり、メソッドの細かい指定に対応していないと*になる場合があります。提案を採るかどうかは、その通信が業務上必要かで判断します。修正案が使えるのは組織のレベルのコンソールだけで、サービスのパターンには対応しておらず、ログの保持期間（既定で30日）より古い拒否は分析できません - 適用の後も、プロジェクトの移動を見張る: フォルダの境界では、プロジェクトの移動がそのまま境界の出入りになります。ドキュメントも、階層の移動はResource Managerの管理者と調整するよう勧めています。移動の権限を持つ人を絞り、移動の記録を確かめる運用を決めておきます
ドキュメントで確かめた制限と上限
ブログには書かれていない点のうち、2026年11月6日にドキュメントで確かめられたものです。
- 境界が重なったとき: 1つのリソースを保護する通常の境界は、適用で1つ、ドライランで1つです。複数の境界に関わるときは、階層のいちばん低い割り当てが効きます。適用とドライランは別々に判定します
- プロジェクトの除外: フォルダの境界から外すには、サービスを制限せず、すべての上り・下りを許可する別の境界に、そのプロジェクトを入れます
- 境界のブリッジ: フォルダは入れられず、プロジェクトだけです
- サービスのパターン:
allowed_service_patternsを設定した境界では、フォルダのメンバーは使えません。元のプロジェクトかVPCネットワークを直接入れます - 既知の問題: VPCネットワークのプロジェクトをドライランの境界に直接入れると、上のフォルダから受け継いだ適用中の保護が外れます
- スコープ付きのポリシー: 境界にフォルダを入れるには、アクセスポリシーのスコープが、そのフォルダかその上位である必要があります
- 上限の値: 上り・下りのルールの属性は、境界の適用とドライランの設定ごとに6,000です。保護するリソースは、アクセスポリシー全体で40,000です。上限のページに、フォルダの数だけを数える項目はありません
組織のポリシーやIAMの条件との組み合わせの注意は、確かめていません。本番の境界を変える前に、ドキュメントの最新の記載を確認してください。
Google CloudでAIエージェントに渡す権限の考え方は、IAM HelperをAIエージェントに入れる前に読む4つの点で扱いました。Gemini Enterpriseから社内の画面をつなぐときの認証と境界の考え方は、Gemini EnterpriseのMCP Apps 社内画面をつなぐ前にも参考になります。
確認した範囲
2026年11月6日に、Google Cloud公式ブログの「Introducing new scalable perimeter options with VPC Service Controls」（公開日の情報は2026年10月15日、ページの表示は10月16日）、VPC-SCのリリースノート、フォルダ、修正案、上り・下りのルール、上限、料金の各ページを開いて確認しました（資料調査）。VPC-SCの境界を作っての検証はしていません。ドライランの優先順位の読み方はドキュメントの記述からの解釈で、実機では確かめていません。移行の順番と確認点は、編集部の提案です。
Google Cloudの境界の設計、AIエージェントを動かすプロジェクトの構成の見直しは、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Introducing new scalable perimeter options with VPC Service Controls（Google Cloud Blog、2026年10月15日）
- VPC Service Controls release notes（Google Cloud）
- Folder support in service perimeters（Google Cloud）
- Configure folders in service perimeters（Google Cloud）
- Resolve access denials with remediation suggestions（Google Cloud）
- Ingress and egress rules（Google Cloud）
- Quotas and limits（Google Cloud）
- VPC Service Controls pricing（Google Cloud）
