【2026年9月最新】Google Cloud Professional Cloud Network Engineer（PCNE）直前チェックシート

Last updated at 2026-09-15Posted at 2026-09-15

はじめに

2026年9月に Google Cloud の Professional Cloud Network Engineer（PCNE）を受験してきました。
PCNE は 2026年4月24日に試験ガイドが更新され、出題範囲に「クラウドネットワークセキュリティソリューションの構成、実装、管理」が新たに追加されました。

過去の合格体験記やまとめ記事だとこのあたりの最新範囲がカバーされていないことも多いので、今回は新試験ガイドの内容を意識しつつ、本番で迷いやすかったポイントや直前に見直しておきたかった要点を整理しました。
試験直前の知識整理や、会場に向かう電車の中での最終チェックに使ってもらえたら嬉しいです。

Professional Cloud Network Engineer（PCNE）試験は、単にプロダクト名を暗記するだけでは合格できません。実際の現場で求められるような、以下のような設計・運用の判断力が問われます。

ネットワークを一元管理するのか、VPC ごとに自律運用させるのか
ネットワーク空間全体をつなぐのか、特定サービスのみを限定公開するのか
どのルートをどこへアドバタイズ（広報）し、どこから受け取るのか
通信を「観測・分析」したいのか、「インラインで即座に遮断」したいのか
Google Cloud 内で完結するのか、オンプレミスや他クラウドまでまたぐのか

1. VPCの「所有」と「接続」を整理する

1-1. 共有 VPC: ネットワークは中央集権、コンピュートは各チーム

共有 VPC（Shared VPC） は、インフラチームがネットワークを一元管理し、開発チームはプロジェクトを分けてVMやGKEを自律運用したい場合に適した構成です。

ホスト プロジェクト
  └─ 共有 VPC ネットワーク
      ├─ subnet-a
      ├─ subnet-b
      └─ サブネットを利用 ── サービス プロジェクト A（VM / GKE）
                           └─ サービス プロジェクト B（VM / GKE）

ホストプロジェクト（Host Project）: 共有 VPC ネットワーク、サブネット、ルート、ファイアウォールルールなどのネットワークリソースを管理・保持します。
サービスプロジェクト（Service Project）: VMやGKEなどのワークロードを保持し、ホストプロジェクトの共有サブネットを利用します。

サービスプロジェクト上のVMであっても、NICが共有 VPC のサブネットに接続されていれば、そのVPCのルートやファイアウォールルールの対象になります。Cloud NATも、ホストプロジェクト側で対象サブネットに対して構成されていれば利用できます。

よく出るIAMロールは次の2つです。

roles/compute.networkUser: 共有された既存サブネットを利用するための権限
roles/compute.networkAdmin: VPC、サブネット、ルート、Cloud NAT などのネットワークリソースを管理するための権限

1-2. VPC ネットワークピアリング: 独立したVPC同士を直接つなぐ

VPC ネットワークピアリング（VPC Network Peering） は、個別に管理されているVPC間を直接プライベートに接続する場合の基本選択肢です。

推移的ルーティングは提供しない: A ↔ B ↔ C と接続しても、AからCへBを経由して通信することはできません。
重複するサブネット範囲は扱えない: 相互に競合するIPアドレス範囲を持つVPCの接続には向きません。

2つのVPCをシンプルに接続し、各チームがそれぞれのVPCを独立管理したい場合は、ピアリング。

1-3. PSCはネットワーク接続ではなく「サービス接続」

Private Service Connect（PSC） は、ネットワーク空間同士を丸ごと接続するのではなく、特定サービスへのプライベートな接続口をコンシューマーVPC内に作る仕組みです。

VPC ネットワーク ピアリング / NCC ＝ ネットワーク空間同士をつなぐ
PSC                              ＝ 特定サービスへ接続する

PSCエンドポイントでは、クライアントはコンシューマーVPC内の内部IPアドレスに接続し、PSCがサービスプロデューサー側へ通信を転送します。

2. ルーティングとNAT

2-1. ルートの基本: ネクストホップは「次にパケットを渡す相手」

サードパーティ製のファイアウォールアプライアンスなどにトラフィックを集約・中継させる場合、内部パススルーネットワークロードバランサ（Internal Passthrough Network Load Balancer。以下、内部パススルー NLB） を静的ルートのネクストホップとして使う構成があります。

送信元 → カスタム静的ルート → [next hop: 内部パススルー NLB] → NGFW → 宛先

内部パススルー NLB 自体はセキュリティ検査を行いません。負荷分散しながらパケットをアプライアンスへ渡し、実際の検査・許可・拒否は配下のNGFWが担当します。

2-2. Public NAT: プライベートVMのアウトバウンド通信

Cloud NAT には Public NAT と Private NAT があり、インターネット向けSNATに使うのが Public NAT です。

外部IPを持たないVMなどからIPv4インターネット宛てに接続する際、共有外部IPアドレスと送信元ポートを割り当ててSNATします。Cloud NATはプロキシVMやファイアウォールアプライアンスではありません。

接続先外部システムの許可リストに送信元IPを登録したい → 手動 NAT IP アドレス割り当て
VMごとの接続数に偏りがあり、NATポート枯渇が問題 → 動的ポート割り当て

2-3. 限定公開の Google アクセスと PSC

限定公開の Google アクセス（Private Google Access。以下、PGA） は、外部IPを持たないVMからGoogle APIとサービスの外部IPアドレスへアクセスするための機能です。PGAはサブネット単位で有効化します。

Google API向けの代表的なドメインは次の2つです。

private.googleapis.com: 広範なGoogle APIへのアクセスに利用
restricted.googleapis.com: VPC Service ControlsでサポートされるAPIに限定し、データ流出リスクを抑える構成で利用

一方、Google API 用の Private Service Connect エンドポイントを使うと、VPC内の内部IPアドレスを入口としてGoogle APIへアクセスできます。

2-4. プライベートサービスアクセス（PSA）との違い

プライベートサービスアクセス（Private Services Access。以下、PSA） とPSCは名前が似ていますが、仕組みが異なります。

PSA = サービス プロデューサー VPC とのピアリング型接続
PSC = コンシューマー VPC 内にエンドポイントを作る接続

Cloud SQLなど、両方の接続方式が登場するサービスでは「ピアリング型か、エンドポイント型か」で整理すると混同しにくくなります。

3. Network Connectivity Center（NCC）

Network Connectivity Center（NCC） は、多数のVPCやオンプレミス接続をハブとスポークで管理するフルマネージドの接続基盤です。

NCCは「ハブがユーザーパケットを必ず中継する装置」というより、スポーク間でどのルートを交換し、どの接続性を提供するかを管理する仕組みとして理解すると整理しやすくなります。

3-1. メッシュトポロジとスタートポロジ

メッシュトポロジ

同じハブのスポーク間で相互接続性を持たせたい場合に使います。メッシュではデフォルトの単一スポークグループを使い、参加スポーク間でルートを交換します。

スタートポロジ

センタースポークグループとエッジスポークグループに分け、エッジ間を直接接続せず、エッジ↔センターの接続性を提供します。

センターグループのスポーク → センター / エッジのスポークへ到達可能
エッジグループのスポーク → センターグループへ到達可能
異なるエッジスポーク同士 → NCCは直接の接続性を提供しない

Inspection VPCをセンター側に配置する設計は頻出ですが、スタートポロジを選ぶだけで通信が自動的にファイアウォールを通過するわけではありません。
実際に検査装置を通すには、静的ルート、ポリシーベースのルート、内部パススルー NLB などを組み合わせた経路設計が必要です。

3-2. スポークの種類

VPC スポーク: VPCネットワークをNCCハブに接続します。
ハイブリッドスポーク: Cloud VPN、Cloud Interconnect、ルーターアプライアンスを介したハイブリッド接続をNCCへ統合します。
プロデューサー VPC スポーク: PSA経由で提供されるサポート対象のマネージドサービスのプロデューサーVPCを、NCC経由で他のVPCスポークから利用できるようにするために使います。

3-3. エクスポート / インポートの向き

NCCのルートフィルタは、次の向きで覚えます。

export ＝ Spoke → Hub
import ＝ Hub → Spoke

--exclude-export-ranges: VPCスポークなどからハブルートテーブルへエクスポートしたくないCIDRを除外します。複数VPCでGKEのPod CIDRが重複している場合、重複範囲をNCCへ出さない設計で使われます。
--include-import-ranges: ハイブリッドスポークのルーティングVPCが、NCCハブのルートテーブルからインポートしてよいルート範囲を指定します。

--include-import-ranges 自体が「オンプレミスへBGPで何を広報するか」を直接指定するわけではありません。
ハブからハイブリッドスポーク側へ取り込んだルートを、その後どのように対向へ再アドバタイズするかは、Cloud RouterやNCCのサイト間データ転送設定なども関係します。

3-4. CIDRが重複している場合は Private NAT

M&AなどでVPC間のIPアドレス範囲が重複している場合、そのままでは正しくルーティングできません。

Private NAT for NCC spokes を利用すると、NCCに接続されたVPC間のプライベート通信でアドレス変換を行い、重複CIDRを隠して接続できます。

3-5. Private Service Connect 接続の伝播

NCCでは、Private Service Connect 接続の伝播を有効にすると、あるコンシューマーVPCスポーク内のPSCエンドポイントでアクセスできるサービスを、同じNCCハブに接続された別のVPCスポークからも利用できます。

共通サービスVPCにPSCエンドポイントを集約し、各ワークロードVPCに個別エンドポイントを大量作成したくない場合に有効です。

ただし、ハブ側でPSC伝播を有効にし、対象エンドポイントのサブネットがエクスポートフィルタで除外されていないことが前提です。

4. ハイブリッド接続

4-1. HA VPN

HA VPN は、IPsec暗号化とCloud RouterによるBGPを組み合わせた高可用性VPNです。99.99%可用性SLAを満たすには、要件を満たす冗長トポロジで構成する必要があります。

オンプレミス側に物理的に独立した2台のVPN装置がある場合は、Google Cloud側のHA VPNゲートウェイの2つのインターフェースを、それぞれ異なるピア装置へ接続して単一障害点を避けます。

4-2. Cloud Interconnect の種別

Dedicated Interconnect: Googleのコロケーション施設でGoogleネットワークへ直接物理接続する方式。高帯域・低遅延の大規模接続向け。
Partner Interconnect: サービスプロバイダ経由で接続する方式。
- レイヤ2（L2）接続: 自社ルーターとCloud Router間でBGPセッションを確立します。
- レイヤ3（L3）接続: サービスプロバイダ側ルーターがCloud RouterとのBGPを担当します。
Cross-Cloud Interconnect: AWSやAzureなどの他社クラウドとGoogle Cloud間を専用接続する方式。
VLAN アタッチメント: Cloud Interconnect接続上に作成する論理的な接続単位で、Cloud RouterとのBGPセッションに使用します。

4-3. 暗号化方式の使い分け

MACsec: L2（データリンク層）でCloud Interconnectの物理リンクを暗号化します。
Cloud Interconnect を介した HA VPN: Interconnect上にHA VPNのIPsecトンネルを構成し、L3でエンドツーエンド暗号化します。

4-4. Cloud Router と BGP

Cloud Routerはユーザーパケットを転送するルーターアプライアンスではなく、BGPによる経路交換を担うコントロールプレーンです。

アドバタイズの基本優先度（MED）: Cloud Routerが対向へ経路をアドバタイズするときのMEDの基準値です。一般に、比較対象となる経路では小さいMEDが優先されます。
Bidirectional Forwarding Detection（BFD）: BGPピアや転送経路の障害を高速検出し、フェイルオーバー時間を短縮します。
カスタムアドバタイズルート: Cloud Routerから対向BGPピアへ明示的に広報するIPプレフィックスを追加・制御します。
カスタム学習ルート: 対向ルーターを変更できない場合などに、Cloud Routerへ手動設定し「対向から学習したルート」をシミュレートします。
MP-BGP: 1本のBGPセッションでIPv4とIPv6など複数アドレスファミリーの経路を交換します。

動的ルーティングモード

VPCネットワークには、リージョンとグローバルの動的ルーティングモードがあります。

リージョン: 学習した動的ルートの適用範囲をリージョン中心に扱う
グローバル: 他リージョンにも動的ルートを利用させる

ハイブリッド接続先と別リージョンのワークロードも同じ動的経路を使う必要がある場合は、グローバル動的ルーティングモードが重要になります。

最適パス選択モード

Cloud Routerには、VPCネットワーク単位で レガシー（デフォルト）と標準の最適パス選択モードがあります。

レガシー: デフォルト。Googleは、標準モード固有の機能が不要な重要ワークロードではレガシーを推奨しています。
標準: RFC 4271により近く、VPC全体でAS-PATHをより一貫して評価できるため、AS-PATHプリペンドによる経路制御を行いたい場合に有用です。MEDを常に比較するかどうか等も調整できます。

5. Cloud Load Balancing

Google Cloudのロードバランサは、まずL7かL4か、プロキシ型かパススルー型かで整理します。

L7（HTTP/HTTPS） ── アプリケーション ロードバランサ（ALB）
L4（TCP/UDP等）  ── パススルー ネットワーク ロードバランサ / プロキシ ネットワーク ロードバランサ

5-1. アプリケーションロードバランサ（ALB）

HTTP(S)のプロキシ型ロードバランサです。

ホスト / パスベースルーティング
URLリライト、HTTPリダイレクト
重み付きバックエンドサービスによるトラフィック分割・カナリアリリース
Cookieベースのセッションアフィニティ
Cloud CDN / Cloud Armor の適用

5-2. パススルーネットワークロードバランサ

L4のパススルー型ロードバランサです。プロキシとして接続を終端せず、元の送信元IPなどを維持したままバックエンドへパケットを配送します。

特に内部パススルー NLB は、NGFWなどのネットワーク仮想アプライアンスをActive/Activeで配置し、静的ルートのネクストホップとして利用する構成で頻出です。

6. ネットワークエンドポイントグループ（NEG）

ネットワークエンドポイントグループ（Network Endpoint Group。以下、NEG） は、ロードバランサ等から見たバックエンドのエンドポイント集合を表します。

Google Cloud外のバックエンドでは、特に次の2種類を区別します。

インターネット NEG: インターネット経由で到達する外部バックエンド。グローバルインターネットNEGでは、INTERNET_IP_PORT または INTERNET_FQDN_PORT を使います。
ハイブリッド接続 NEG: Cloud VPN、Cloud Interconnect、ルーターアプライアンスVMなどのハイブリッド接続経由で到達する、Google Cloud外の IP:Port エンドポイント。
ネットワークエンドポイントタイプは NON_GCP_PRIVATE_IP_PORT です。

公開インターネット経由の外部オリジン → インターネット NEG
VPN / Interconnect経由のオンプレ・他クラウド → ハイブリッド接続 NEG

バックエンドバケットとバックエンドサービス

バックエンドバケット: Cloud Storageバケットをロードバランサ / Cloud CDN のオリジンとして使う場合
バックエンドサービス: インスタンスグループや各種NEGをバックエンドとして使う場合

Cloud Runは通常、サーバーレス NEG を介してバックエンドサービスに接続します。GKE PodではゾーンNEG（GCE_VM_IP_PORT）がよく使われます。

7. Cloud CDN

Cloud CDNでは、「今後どうキャッシュするか」と「今すでに残っているキャッシュをどうするか」を分けます。

キャッシュモード / Cache-Control変更: 今後のキャッシュ保存・再検証の挙動を変える
キャッシュの無効化（Cache Invalidation）: すでにエッジに残っている古いオブジェクトを指定パスで無効化する

8. Cloud DNS

ハイブリッドDNSは、名前解決クエリの向きで判断します。

Google Cloud → オンプレミスDNS: 転送ゾーン
Cloud DNSの転送クエリはオンプレミス側から見ると 35.199.192.0/19 が送信元になるため、オンプレミス側FW・DNS・戻り経路で考慮します。
オンプレミス → Cloud DNS: 受信サーバーポリシー
VPCに受信サーバーポリシーを適用すると、オンプレミスからCloud DNSへ到達するための受信エントリポイントが作られます。
VPC → 別VPCのCloud DNS: DNS ピアリング（実際に作成するのはピアリングゾーン）
社内と社外で同じFQDNに異なる応答を返す: スプリットホライズン DNS
DNSSEC: DNSキャッシュポイズニングやDNSスプーフィングへの対策

9. GKE ネットワーキング

VPCネイティブクラスタでは、まずIPの出所を整理します。

サブネットのプライマリ IPv4 範囲      → ノードIP
サブネットのセカンダリ IPv4 範囲      → Pod IP
別のセカンダリ IPv4 範囲              → Service IP（ClusterIP）

9-1. IPアドレス枯渇

ノードIP不足: 問題はサブネットのプライマリIPv4範囲です。可能ならプライマリ範囲の拡張を検討し、拡張時はGKEファイアウォールルールや承認済みネットワークへの影響も確認します。
設計上拡張できないほど逼迫している場合は、適切なIPレンジでクラスタを再設計します。
Pod IP不足: Pod用セカンダリ範囲を拡張するか、不連続マルチPod CIDR（discontiguous multi-Pod CIDR） を使って追加のPod IP範囲をクラスタへ追加します。

9-2. `ip-masq-agent` と `nonMasqueradeCIDRs`

宛先が nonMasqueradeCIDRs に含まれる → Podの送信元IPを維持
宛先が nonMasqueradeCIDRs に含まれない → PodトラフィックをノードIPへSNAT（masquerade）

オンプレミス側がPod CIDRを認識できず、ノードIPからの通信だけを許可している場合は、オンプレミス宛てを nonMasqueradeCIDRs に含めない設計を検討します。

9-3. NetworkPolicy

KubernetesのNetworkPolicyはallowベースです。ただし、ポリシーを1つ作っただけでクラスタ全通信が拒否されるわけではありません。

対象Podが、IngressまたはEgressのNetworkPolicyによってその方向で分離（isolated）されると、その方向の通信はポリシーで明示的に許可されたものだけが通ります。

たとえばbackend Podを選択するIngressポリシーでfrontend PodからTCP 8080だけ許可すれば、選択されたbackend Podへのその他のIngressは拒否されます。

9-4. GKE Dataplane V2

GKE Dataplane V2 はeBPFベースで、Service転送やNetworkPolicyの適用を行います。従来のkube-proxy / iptablesに依存せず、ネットワークポリシーのロギングや可視性も提供します。

9-5. コントロールプレーンエンドポイント

現在のGKEコントロールプレーンには、DNS ベースのエンドポイントとIP ベースのエンドポイントがあります。

DNS ベースのエンドポイント: Googleがベストプラクティスとして推奨する方式。固定のDNS名を使い、IAMベースでアクセスを制御しやすい
IP ベースのエンドポイント: 内部エンドポイントと外部エンドポイントを構成できる
- 外部エンドポイントを無効化 → インターネット上のクライアントからIPベースで到達できない
- 承認済みネットワーク → IPベースのエンドポイントへ到達できる送信元範囲を制限

10. セキュリティ

「どのレイヤを守るのか」「観測だけか、実際に遮断するのか」で分けます。

目的・防御レイヤ	選択するサービス
L3/L4 のIP・ポートベース制御	VPC ファイアウォールルール / Cloud NGFW
Webアプリケーションへの攻撃防御（SQLi、XSS、L7 DDoS）	Cloud Armor
内部からインターネットへのWebアウトバウンド制御	Secure Web Proxy（SWP）
Google APIからの意図しないデータ持ち出し防止	VPC Service Controls（VPC SC）
パケットを複製して受動解析	Packet Mirroring
L7まで検査し、脅威をインラインで遮断	Cloud NGFW Enterprise / サードパーティ製NGFW

10-1. Cloud NGFW のティア

Cloud NGFW Essentials: ステートフルインスペクション、セキュアタグ、アドレスグループ、VPC ファイアウォールルール
Cloud NGFW Standard: FQDNオブジェクト、位置情報オブジェクト、脅威インテリジェンス
Cloud NGFW Enterprise: 侵入検知および防止、URLフィルタリング、高度なマルウェアサンドボックス、TLSインスペクション

FQDNベースで宛先を制御したいだけならStandard、HTTP(S)をアプリケーションレイヤで検査してURLや脅威を扱いたいならEnterprise

10-2. Secure Web Proxy

Secure Web Proxy（SWP） は、主にVM等からインターネットへ出るHTTP(S)トラフィックの出口制御に使います。

Cloud NGFWのFQDNオブジェクトがドメイン名ベースの制御であるのに対し、SWPではURLパスを含むWebアクセス制御を行える点が重要です。

10-3. 階層型ファイアウォールポリシー

階層型ファイアウォールポリシー は、組織やフォルダ単位で共通ルールを適用したい場合に使います。

上位階層で明示的に決定されたルールは下位側で勝手に上書きできません。一方、goto_next を使えば、上位ポリシーで判断を確定せず、次のファイアウォールポリシー階層へ評価を委譲できます。

10-4. VPC Service Controls

VPC Service Controls（VPC SC） はネットワークファイアウォールではありません。主目的は、Cloud StorageやBigQueryなどのGoogle Cloudサービスをサービス境界で保護し、API経由のデータ流出リスクを下げることです。

11. 監視・トラブルシューティング

把握したい内容・トラブルの状況	選択するツール
通信が届かない原因調査（構成情報に基づく到達性分析）	Connectivity Tests
リージョン間・ゾーン間の遅延やパケットロスの推移確認	Performance Dashboard
未使用・過剰・シャドウ化されたファイアウォールルールの分析	Firewall Insights
ネットワーク構成上の問題や推奨事項の検出	Network Analyzer
実際の通信メタデータ（5-tuple、バイト数）の調査・分析	VPC Flow Logs / Flow Analyzer
パケットを複製してIDSやDPI装置へ送る	Packet Mirroring

Connectivity Tests の注意点

Connectivity Testsは、まずGoogle Cloudの構成情報から想定される転送経路をシミュレーションします。

ただし、現在は対応する一部のシナリオで Live Data Plane Analysis も実行し、実際にプローブパケットを送信して到達性・遅延・パケットロスを確認します。

したがって、「Connectivity Testsは絶対に実パケットを送らない」と覚えるのは現在の仕様では誤りです。基本は構成分析、対応経路ではライブデータプレーン分析も補助的に使う、と整理します。

また、Packet Mirroring自体がDPIをするわけではありません。パケットを複製してコレクタへ送り、IDSやDPI製品側で解析するための仕組みです。

12. その他

12-1. Network Service Tiers

Premium Tier: Googleのグローバルネットワークを最大限利用し、グローバルな低遅延・高品質通信を重視する構成
Standard Tier: Googleのグローバルネットワーク利用を抑え、よりコストを重視する構成

グローバルユーザー、低遅延、グローバル外部ロードバランシングなどが強調される場合はPremium Tier

12-2. MTU

Maximum Transmission Unit（MTU） は、1パケットで送れる最大サイズです。

Cloud VPNなどのトンネルでは追加ヘッダー分のオーバーヘッドがあるため、大きなパケットで断片化や性能低下が起きる場合があります。MTUやTCP MSSクラッピングの見直しがトラブルシューティング候補になります。

12-3. BGPとルート選択で混同しないこと

次の3つは別レイヤの話です。

最長プレフィックス一致: どの宛先プレフィックスが最も具体的か
Google CloudのVPCルート選択: 静的ルート、動的ルートなど、同一プレフィックス候補の扱い
Cloud RouterのBGP最適パス選択: レガシー / 標準モード、AS-PATH、MEDなど

まとめ

今回は実際に試験を受けてみて、「このあたりを本番前にもう少し詰めておけば迷わなかったな……」と感じたポイントを中心に整理してみました。

2026年4月の改定以降は、従来のルーティングに加えて Cloud NGFW や Secure Web Proxy などのセキュリティ設計も合否を分けるポイントになっています。

この記事が試験直前の振り返りや、皆さんの合格の一助になれば嬉しいです。応援しています！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up