公開2026.09.04更新2026.09.27 Google Cloud

VPC Service Controlsとは？サービス境界の作り方・restricted VIPの設定・運用で詰まる点を実装者目線で解説

VPC Service Controls（VPC SC）は、Google Cloudのリソースの周囲に論理的な境界を引き、境界の外へデータが出ていく通信をAPIレベルで拒否する仕組みです。IAMの権限設計をどれだけ丁寧にやっても、正しい権限を持つ認証情報が漏れた瞬間にデータは外へ出ていきます。VPC SCが担うのはその一手前、つまり「誰が」ではなく「どこからどこへ」を止める層になります。

設定そのものは数コマンドで終わるのに、事故なく本番へ入れるまでの道のりが長いのがこの機能の特徴です。この記事では、サービス境界の構成要素と上限値、ドライランから適用までの手順、restricted.googleapis.comを通すためのDNS・ルートの実設定値、運用で必ず踏む地雷までを実装者が判断できる粒度で整理します。

まとめ：VPC SCはデータ持ち出しを止める境界であり、IAMの代わりではない

役割：制限付きサービスへのAPIリクエストを境界で判定し、条件を満たさないものを拒否します。IAMが「誰が何をできるか」を決めるのに対し、VPC SCは「どこからどこへデータを動かせるか」を決める層です。
料金：VPC SC自体の利用に個別の課金はありません（公式の料金ページ・2026年9月時点）。コストは設計と運用の工数に寄ります。
構成要素：保護対象プロジェクト、制限付きサービス、VPCでアクセス可能なサービス、上り（ingress）・下り（egress）ルール、アクセスレベル、境界ブリッジの6点で組み立てます。
手順：アクセスポリシーの確認 → ドライランで境界作成 → 違反ログの棚卸し → 適用モードへ切り替え。ドライランを飛ばした導入は本番停止に直結します。
実設定：境界内からGoogle APIへ届かせるには、restricted.googleapis.com（199.36.153.4/30）へのDNS・ルート・ファイアウォールの3点セットが必要です。
詰まる点：境界の作成・更新は反映まで30分ほどかかる場合があり、その間はError 403が出ます。障害と誤認しない運用の合意が先に必要になります。
採用判断：機微データを扱う本番プロジェクトが分離でき、CI/CDの実行主体を洗い出せる組織なら採用すべきです。構成が未整理なら先に整理とIAM棚卸しを優先してください。

境界設計をどこまで作り込むかは、扱うデータの性質と運用体制で決まります。設計から構築・運用まで含めて相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応できます。

VPC Service Controlsとは何か：IAMやファイアウォールとの役割の違い

IAMは誰がを制御し、VPC SCはどこからどこへの持ち出しを制御する

IAMは、あるプリンシパルがどのリソースにどの操作を許されるかを判定します。設計が正しければ不要な権限は渡りません。しかし現実には、サービスアカウントキーの流出、CI設定の取り違え、退職者アカウントの残存といった経路で「正しい権限を持つ主体」が意図しない場所で使われます。この状態ではIAMは通してしまいます。

VPC SCは同じリクエストを別の軸で見ます。判定材料はリクエストの発信元（VPCネットワーク、IPレンジ、デバイス情報、ID）と宛先リソースの所属で、境界の外から境界内の制限付きサービスを叩く通信は、上り・下りのルール条件を満たさない限り通りません。公式ドキュメントは、IAMが詳細なIDベースの制御であるのに対し、VPC SCは境界全体での下り（外向き）データの制御を含むコンテキストベースの境界セキュリティだと位置付けています（2026年7月19日 UTC更新）。

両者は置き換えの関係ではなく、直列に並ぶ2枚の関門です。権限設計が甘いままVPC SCを入れても境界内部での権限逸脱は止まらず、IAMだけでは権限ごと持ち出される事故を止められません。

ファイアウォールやCloud Armorとの守る層の違いを整理する

Google Cloudには通信を止める仕組みが複数あり、守る層が違います。VPCファイアウォールはVMのネットワークインターフェースに対するL3/L4の制御で、Google APIのエンドポイントに対する制御ではありません。Cloud Armorはロードバランサーの前段で外から来る攻撃を弾くL7の防御で、向きが外向きではなく内向きです。VPC SCが見るのは、Google APIへのリクエストが境界を越えるかどうかという第3の軸になります。

仕組み	判定する層	主に止めるもの
IAM	ID・権限	権限のない操作
VPCファイアウォール	L3・L4（VM）	VMへの不要な通信
Cloud Armor	L7（LB前段）	外部からの攻撃
VPC SC	API（境界）	境界外へのデータ持ち出し

この整理を先に共有しておくと社内の議論が噛み合います。「ファイアウォールを絞ってあるからデータ持ち出しは防げている」という主張は、Google APIがインターネット経由のエンドポイントである以上成り立ちません。

サービス境界の構成要素と上限値：どこまで指定できるのかを整理する

制限付きサービスとVPCでアクセス可能なサービスの指定範囲の違い

サービス境界の中心にある設定は2つです。1つ目のrestricted services（制限付きサービス）は、境界で保護するGoogle Cloudサービスの一覧を指定します。ここにstorage.googleapis.comやbigquery.googleapis.comを入れると、それらへのAPIリクエストは境界のルール条件を満たさない限り境界を通過しません。Cloud StorageのバケットやBigQueryのデータセットが保護対象の典型で、持ち出しリスクが集中する場所から順に入れていきます。

2つ目のVPC accessible services（VPCでアクセス可能なサービス）は向きが逆で、境界内のネットワークエンドポイントから呼び出せるサービスを指定した集合に絞る設定です。境界内のVMが外部プロジェクトのAPIを叩いてデータを送り出す経路を閉じる用途になります。前者だけでは内側から外側への呼び出しが自由なままなので、持ち出し対策としては両方を組み合わせてください。

上り（ingress）と下り（egress）のルールで例外を穴あけする

境界を作った直後は、境界の外にいる正当な利用者もすべて拒否されます。そこで例外を定義するのが上り・下りのルールです。上りルールは境界の外から内へのアクセスを、下りルールは内から外へのアクセスを、それぞれクライアント属性（ID、デバイスデータ、ネットワーク送信元）と宛先の組み合わせで許可します。

ルールにはfromブロックとtoブロックがあり、fromでは発信元のIDやプロジェクト、toでは対象リソースとメソッドを指定します。注意したいのは属性の数え方です。公式ドキュメントによると、ingress・egressルールの各フィールドのエントリは1つずつ属性としてカウントされ、同じリソースを2つのルールに書けば2属性として数えられます。安易に例外を積むと上限に当たるため、ルールは主体単位でまとめる設計が効きます。

アクセスレベル（Access Levels）は、IPレンジやデバイス条件をアクセスポリシー配下で名前を付けて再利用する仕組みです。社内拠点のIPや管理端末の条件をアクセスレベルとして定義し、複数の境界の上りルールから参照させておくと、拠点追加のたびに全境界を触る手間がなくなります。

境界ブリッジと上限値：境界は10,000・保護リソースは40,000

プロジェクトは1つのサービス境界にしか含められません。組織全体に対するアクセスポリシーは1つで、フォルダとプロジェクトには複数スコープのアクセスポリシーを設定できます。共有VPCを使う場合はホストプロジェクトを境界に含める必要があり、この制約を忘れると通信が通りません。

境界をまたいだ通信を許したい場合の選択肢がperimeter bridge（境界ブリッジ）です。ブリッジは境界の分離を弱める方向の設定なので、まず下りルールで足りないかを検討してから使ってください。上限値は公式のクォータページ（2026年9月3日 UTC更新）に整理されています。

項目	上限値
境界あたりの属性数	6,000
ポリシーあたりの境界数	10,000
保護対象リソース数	40,000
VPCネットワーク数	500
組織レベルのポリシー	1
フォルダ・プロジェクト単位	50

各境界は適用（enforced）とドライラン（dry run）の2構成を持ち、属性の上限は構成ごとに個別に適用されます。数千規模の属性に達する設計は運用が破綻しやすいため、上限に近づいてきたら境界の分割を先に考えるほうが健全です。

導入手順：ドライランで境界を作り、違反ログを確認してから適用する

アクセスポリシーを確認し、Access Context Managerを作る

最初にやるのは既存のアクセスポリシーの確認です。組織スコープのポリシーは1つしか持てないため、すでに誰かが作っていればそれを使い、存在しない場合だけ新規作成します。境界はアクセスポリシー配下のリソースなので、ここを取り違えると後から作り直しになります。

gcloud access-context-manager policies list --organization=ORG_ID
gcloud access-context-manager policies create --organization=ORG_ID --title="corp-policy"

作成したポリシーIDは以降のコマンドで使い回すため、gcloud configのaccess_context_manager/policy に設定しておくと指定漏れを防げます。組織の管理権限が必要な操作なので、権限を持つ担当と作業窓を先に決めておいてください。

ドライランモードで境界を作成し、違反ログをCloud Loggingで読む

境界はドライランで作ります。ドライランモードでは、ポリシーに違反するリクエストは拒否されず、ログにのみ記録されます。つまり本番を止めずに「適用したら何が壊れるか」を先に観測できるわけです。

gcloud access-context-manager perimeters dry-run create prod_perimeter
    --perimeter-title="prod perimeter"
    --perimeter-type=regular
    --perimeter-resources=projects/PROJECT_NUMBER
    --perimeter-restricted-services=storage.googleapis.com,bigquery.googleapis.com

観測はCloud Loggingで行います。監査ログの違反エントリから、どのプリンシパルがどのサービスを境界外から呼んだのかを拾い、正当な通信か持ち出しかを1件ずつ判定していきます。ここで出てくるのは想定外の主体ばかりで、監視SaaS、データ連携ツール、開発者の手元端末、バックアップジョブなどが並ぶはずです。

正当な通信には上り・下りルールかアクセスレベルで例外を与え、不要なものは呼び出し元を止めます。この棚卸しを終えないまま適用へ進むと、業務が止まってから原因を探す羽目になります。ドライランは短くとも業務の1サイクル、月次バッチがあるなら1か月は回してください。

適用モードへ切り替える判断基準と、切り戻し手順を先に決めておく

適用へ進む条件は明確です。ドライランの違反ログが、意図的に拒否したい通信だけになっていること。この状態を数日連続で確認できたら、ドライラン構成を適用構成へ昇格させます。未判定の違反が残っているうちは、日程が来ていても切り替えてはいけません。

切り戻しの手順も先に用意します。境界を削除すると、その境界に関連付けられているセキュリティ制御が対象プロジェクトに適用されなくなり、メンバープロジェクトや関連リソースへのその他の影響はないと公式ドキュメントは明記しています（2026年5月9日 UTC更新）。ただし削除は防御を全部外す操作なので、制限付きサービスを1つ外す、例外ルールを足すといった段階的な戻し方を優先してください。

境界をgcloudの手作業で管理し続けると、変更の履歴が追えなくなります。Terraformで境界とアクセスレベルをコード管理し、レビューを通してから適用する運用に寄せるのが実務的です。ただしアクセスポリシーは組織で1つという制約があるため、複数チームが同じポリシー配下の境界を別々のstateで管理すると衝突します。

restricted VIPとDNS・ルート設定：境界内から通信を通す実設定

Cloud DNS・ルート・ファイアウォールに入れる実設定値の一覧

境界を作っても、境界内のCompute EngineのVMやワークロードがGoogle APIへ到達できなければ何も動きません。ここで使うのがrestricted VIPと呼ばれる専用エンドポイント、restricted.googleapis.comです。通常のgoogleapis.comではなくこちらへ向けることで、VPC SCがサポートしないGoogle APIへのアクセスを拒否できます。

必要な設定は3点セットです。公式の手順（2026年5月9日 UTC更新）にある値は次のとおりで、IPv4のrestricted VIPは 199.36.153.4/30、IPv6は 2600:2d00:0002:1000::/64 です。

設定対象	入れる値
Cloud DNS ゾーン	googleapis.com の限定公開
CNAMEレコード	*.googleapis.com を向ける
Aレコード	199.36.153.4 から .7
カスタムルート	宛先 199.36.153.4/30
ネクストホップ	default-internet-gateway
ファイアウォール	TCP 443 の下り許可

ルートのネクストホップがdefault-internet-gatewayである点は毎回引っかかるところで、名前に反して通信はインターネットへ出ずGoogleのネットワーク内で折り返します。外部IPを持たないVMからでも到達できるのはこの経路のためです。

private.googleapis.comとの使い分けをどこで決めるか

Private Google Accessのエンドポイントには private.googleapis.com もあり、こちらは 199.36.153.8/30 を使います。両者の差はVPC SCとの相性です。restricted VIPはVPC SCがサポートするサービスに限って通すため、サポート外のAPIを経由した抜け道を作りません。private VIPはほぼすべてのGoogle APIへ到達できる代わりに、境界の外へ出る経路も残ります。

判断は単純で、データ持ち出しを止めることが目的なら restricted を選びます。境界の対象外だがどうしても使いたいAPIがある場合は、そのワークロードを境界の外の別プロジェクトへ寄せ、そこだけ private VIP を使う構成に分けてください。同じVPCで両方を混在させると、DNSの解決順で意図しない経路に流れる事故が起きます。

運用で詰まる点：反映まで30分・403の切り分け・CI/CDの境界越え

反映に30分かかる前提でError 403の発生原因を切り分ける

境界の作成・更新は即時には効きません。公式ドキュメントは反映に30分ほどかかる場合があるとし、その間に Error 403: Request is prohibited by organization’s policy. が発生する可能性を明記しています。ここを知らずに変更直後の疎通試験をすると、設定が間違っていると誤解して余計な変更を重ねることになります。

切り分けの順序を決めておくと迷いません。まず変更からの経過時間を見て、30分未満なら待ちます。次にドライランで同じ通信が違反として記録されているかを確認します。記録があれば境界の判定によるもので、無ければ経路（DNS・ルート・ファイアウォール）かIAMの問題です。403のメッセージがorganization’s policyに言及しているかどうかも、VPC SC由来か通常の権限不足かを見分ける手がかりになります。

CI/CDやマネージドサービスが境界を越えられずに失敗する事故

実務でいちばん多い停止要因はこれです。CI/CDのランナーが境界外にいると、ビルド成果物のアップロードやデプロイのAPI呼び出しが拒否されます。外部SaaSからのデータ連携、BIツールからのクエリ、監視エージェントのメトリクス送信も同じ理由で落ちるはずです。マネージドサービス側がGoogleの内部プロジェクトからリソースへアクセスする構成では、その主体を上りルールで許可する必要も出てきます。

対処の型は3つです。実行主体を境界内へ移す、上りルールでサービスアカウントを名指しで許可する、その処理を境界外の別プロジェクトへ分離する。どれを選ぶかはデータの流れで決めます。境界内のデータを外へ出す処理なら、例外を作るより処理自体を作り替えるほうが安全です。

VPC SCが対応していないサービスとメタデータ経由の抜け道に注意

すべてのGoogle Cloudサービスが制限付きサービスとして指定できるわけではありません。対応状況は公式のサポート対象プロダクト一覧で管理され、サービスごとに制限事項も併記されています。境界を設計する前に、使っているサービスが対応済みかを必ず突き合わせてください。未対応のサービスに機微データを置いている場合、そのデータは境界の保護外にあります。

もう1点、公式ドキュメントはVPC SCがメタデータへのアクセスも管理するとしつつ、ポリシーのチェックを経ずにメタデータのコピーやアクセスができる場合もあると述べています（2026年7月19日 UTC更新）。境界があれば情報が一切漏れないと考えるのは危険で、監査ログの監視やDLPによる検知と組み合わせる前提で設計してください。

採用条件と見送る場面：VPC SCを入れるべき組織はどこで分かれるか

VPC SCを採用すべき組織の条件と、先に整えるべき前提を挙げる

次の3つがそろっている組織は採用すべきです。第一に、個人情報や取引データなど持ち出されたら実害が出るデータが特定のプロジェクトに集まっていること。第二に、そのプロジェクトが本番専用として分離され、開発や検証のリソースが混在していないこと。第三に、そのデータへアクセスする主体（人・サービスアカウント・外部ツール）を一覧化できること。

1つでも欠けると、ドライランの違反ログが判定不能な通信で埋まり、棚卸しが終わりません。前提として先に整えるべきは、プロジェクト構成の整理とIAMの棚卸しです。監査要件で期限が決まっている場合は、対象データを1プロジェクトへ寄せてそこだけ境界で囲む形から始めると、範囲を絞って前に進められます。

VPC SCを見送る・後回しにする場面と代わりに打つべき対策手段

見送るべき場面も明確です。1つのプロジェクトに開発・検証・本番が同居している段階、プロジェクト数が数個で担当者も1〜2名という規模、そしてGoogle Cloud上に持ち出されて困るデータがまだ無い段階。ここでVPC SCを入れても、例外ルールの塊ができて運用が止まるだけで、防御としては機能しません。

代わりに打つべき手を優先順に挙げると、サービスアカウントキーの棚卸しと廃止（Workload Identityへの移行）、組織のポリシーによる外部IP付与や公開バケットの禁止、監査ログの保管と異常検知、そしてプロジェクト分割になります。これらはVPC SCの前提としても効くため、後で境界を入れるときの工数を確実に減らす施策です。構成整理から境界設計まで含めて任せたい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応できます。