【アップデート】Google Cloud Compute Engine向け組織ポリシーのマネージド制約がGAしました

はじめに

こんにちは。
クラウド事業本部コンサルティング部の渡邉です。

2026年3月4日にGoogle Cloudの組織ポリシーで利用できるCompute Engine向けマネージド制約がGAになったとアップデートがありました。

https://docs.cloud.google.com/release-notes#March_04_2026

これまでのCompute Engineの組織ポリシーは、一部マネージド制約のポリシーがPreviewで利用可能でしたが、基本はcompute.disableSerialPortAccessやcompute.vmExternalIpAccessといったいわゆるレガシー制約が使われてきました。今回GAとなったマネージド制約はこれらのレガシー制約を置き換える新しい仕組みになります。Policy SimulatorやDry RunといったPolicy Intelligenceツールとの統合が可能な点が大きな特徴で、ポリシーの本番適用前に影響範囲を安全に確認できることが強みです。

今回は、マネージド制約の概要とレガシー制約との違い、そして実際にマネージド制約を設定してDry Runで確認するまでの流れを試してみたいと思います。

マネージド制約とは

マネージド制約は、Google Cloud の組織ポリシーで利用できる制約の新しい形式です。従来のレガシー制約（Legacy Managed Constraints）と同様にGoogleが管理する制約ですが、以下の点で強化されています。

マネージド制約はconstraints/compute.managed.*という命名規則で、レガシー制約のconstraints/compute.*と区別されます。
Google Cloudの活用が進んでいる中での組織ポリシーの設定変更は、影響範囲がかなり広いため、不安になると思います。マネージド制約を利用することで、設定を変更する前に事前にDry Runで影響調査ができる点はかなり魅力的かと思います。

Compute Engine向けマネージド制約一覧

今回GAとなった現状利用することのできるマネージド制約は以下の通りです。

レガシー制約からマネージド制約へ移行するメリット

1. Dry Runで事前に影響を確認できる

マネージド制約はDry Runモードに対応しています。Dry Runモードでは、ポリシーに違反するアクションをブロックせずに監査ログに記録します。これにより、本番環境に影響を与えることなく、30日間にわたってポリシーの影響を確認できます。
従来のレガシー制約では、このようなDry Runでの組織ポリシーの影響確認を行うことはできなかったので、マネージド制約に移行するだけでも既存の環境に与える影響を小さくすることができると思います。

2. Policy Simulatorで既存リソースへの影響をテストできる

Policy Simulatorを使うと、ポリシーを適用する前に既存のリソース構成に対してどのような違反が発生するかをシミュレーションできます。例えば、外部IPアドレスを持つVMがいくつあるかを事前に把握できます。

3. タグベースの条件付きルールで柔軟な例外設定

マネージド制約では、タグを使った条件付きルールがサポートされています。特定のタグが付与されたVMだけをポリシーの適用対象から除外することが可能です。これにより、「基本的には全VMに制約を適用するが、特定の用途のVMだけ例外にする」といった柔軟な運用ができます。

4. メタデータレベルでの評価

レガシー制約ではプロジェクトレベルでの評価が中心でしたが、マネージド制約ではVM、プロジェクト、ゾーンの各レベルのメタデータを評価できます。これにより、メタデータでシリアルポートアクセスを個別に有効化しているVMを正確に検出できます。

5. 移行手順

公式ドキュメントでは、以下の手順で移行することを推奨しています。

1. 既存のレガシー制約に変わる、新しいマネージド制約を特定する
2. Policy Simulatorとドライランを使用して、既存環境への影響を確認する
3. 既存のレガシー制約と、新しいマネージド制約を並行して設定する
4. 既存のレガシー制約を削除する

https://docs.cloud.google.com/compute/docs/access/managed-constraints#migration_from_legacy_constraints

実際にマネージド制約を設定してみる

ここからは、実際にcompute.managed.vmExternalIpAccessを使ってVMの外部IPアドレスを制限し、Dry Runで影響を確認してみます。

前提条件

• 組織ポリシー管理者のIAMロール（roles/orgpolicy.policyAdmin）が付与されていること
• 対象の組織またはプロジェクトへのアクセス権があること

ステップ1: Dry Runモードでポリシーを設定する

まず、Dry Runモードでポリシーを設定します。
Google Cloudコンソールで「組織のポリシー」ページに移動し、組織のポリシーからフィルタでcompute.managed.vmExternalIpAccessと入力し、該当の組織ポリシーをフィルタリングしてクリックします。

【ポリシーを管理】をクリックします。

• ポリシーのソース：【親のポリシーをオーバライドする】
• ルール：適用済み

にします。

【ポリシーを設定】をクリックし、【ドライランポリシーを設定】をクリックします。

ドライランポリシーの変更を設定しますか？の問いに、【ドライランポリシーを設定】をクリックします。

ドライランのタブでステータスが【適用済み】になっていることが確認できます。

実施中のタブだとステータスが【未適用】になっていることが確認できます。

この状態はまだ、組織ポリシーが有効化になっていないため、実際のVMに外部IPは付与することができる状態です。

ステップ2: Dry Runの結果を確認する

Dry Runモードでは、ポリシーに違反するアクションが監査ログに記録されます。
試しに外部IPが付与されたCompute Engineを作成してみました。
Cloud Loggingで以下のフィルタを使って確認できます。

resource.type="audited_resource"
protoPayload.metadata.constraint="constraints/compute.managed.vmExternalIpAccess"
protoPayload.metadata.dryRunResult="DENIED"

以下のログが Google Cloud の組織ポリシー（Dry Run）違反 に関する監査ログです。
VMインスタンス作成時に、外部IPアドレスの割り当てがポリシーに違反したことを記録しています。

{
  "insertId": "**********",
  "logName": "projects/****/logs/cloudaudit.googleapis.com%2Fpolicy",
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "metadata": {
      "@type": "type.googleapis.com/google.cloud.audit.OrgPolicyDryRunAuditMetadata",
      "constraint": "constraints/compute.managed.vmExternalIpAccess",
      "dryRunResult": "DENIED",
      "liveResult": "ALLOWED",
      "resourceType": "compute.googleapis.com/Instance"
    },
    "methodName": "compute.beta.InstancesService.Insert",
    "resourceName": "projects/****/zones/asia-northeast1-b/instances/****",
    "serviceName": "compute.googleapis.com",
    "status": {
      "code": 7,
      "message": "POLICY_VIOLATED"
    }
  },
  "receiveTimestamp": "****-**-**T**:**:**.******Z",
  "resource": {
    "labels": {
      "method": "compute.beta.InstancesService.Insert",
      "project_id": "****",
      "service": "compute.googleapis.com"
    },
    "type": "audited_resource"
  },
  "severity": "WARNING",
  "timestamp": "****-**-**T**:**:**.******Z"
}

ステップ3: Policy Simulatorで既存リソースへの影響を確認する

Google Cloudコンソールから、Policy Simulatorを使って既存リソースへの影響を確認します。
先ほどと同じように以下の手順でポリシーにアクセスし、【変更をテスト】でPolicy Simulatorを実行させることができます。

1. Google Cloudコンソールで「組織のポリシー」ページに移動
2. compute.managed.vmExternalIpAccess を検索して選択
3. 「ポリシーを管理」をクリック
4. 「ルールを追加」で enforce: true を設定
5. 「変更をテスト」をクリックしてPolicy Simulatorを実行

Policy Simulatorが既存のリソースを評価し、違反が発生するリソースの一覧を表示します。

シミュレーションの一覧を確認した場合は、こちらから確認することができます。

組織のポリシーから【シミュレーションの履歴】をクリック

シミュレーションが完了すると、【シミュレーションの日付】がクリック可能になっていますので、クリックします。

設定したい組織ポリシーに違反しているリソースの一覧を確認することができます。
先ほど作成した外部IPアドレスが付与されているCompute Engineがリストに表示されています。

ステップ5: 本番ポリシーを適用する

Dry RunとPolicy Simulatorで影響を十分に確認したら、本番ポリシーを適用します。
Compute Engineの外部IPアドレスを削除したのち、ドライランに設定している組織ポリシーを設定していきます。

【ドライラン】タブから、【ポリシーを設定】をクリックします。

ポリシーを設定する最終確認が行われますので、【確認】をクリックします。

実施中のタブだとステータスが【適用済み】になっていることが確認できます。

ドライランのタブだとステータスが【未設定】になっていることが確認できます。

これでポリシーの適用作業は完了です。

この状態で、先ほど作成したCompute Engineに外部IPアドレスを設定してみると、設定したポリシー（compute.managed.vmExternalIpAccess）により外部IPアドレスが付与できなくなっていることが確認できました。

番外編: タグベースの例外を設定する

特定のCompute Engineだけ外部IPアドレスを許可したい場合は、タグを使った条件付きルールを設定します。

組織リソースへ移動し、【IAMと管理】->【タグ】をクリックします。
タグキー部分の【作成】をクリックします。

• タグキー：allow-external-ip
• タグキーの説明：外部IPアドレスの付与を許可するタグ
• タグの値：true

を設定して【タグキーを作成】をクリックします。

続いて、Compute Engineに作成したタグを付与します。

次に、設定したポリシー（compute.managed.vmExternalIpAccess）のルールに【条件を追加】していきます。

条件の編集で以下の情報を入力していきます。

• タイトル: 外部IPアドレス例外許可
• 説明: 外部IPアドレス例外許可
• 条件作成ツール
  • 条件タイプ: タグ を選択
  • オペレータ: 値がある を選択
  • 値のパス：タグキーとタグ値を指定

保存をクリックします。
条件エディタで確認すると以下の条件式になります。

resource.matchTag("**********/allow-external-ip", "true")

次に、【デフォルトのルール】を追加します。

• 再度 【ルールの追加】 をクリック
• 条件なしで 適用:オンを設定

【ポリシーの設定】をクリックして適用させていきます。
この設定により、allow-external-ip: trueタグが付与されたVMは外部IPアドレスの使用が許可され、それ以外のVMは制限されます。

例外条件により、タグが付与されているCompute Engineには外部IPアドレスが付与できるようになりました。

Compute Engineからタグを削除すると、外部IPアドレスは付与できなくなりました。

まとめ

今回は、2026年3月4日にGAされた組織ポリシーのCompute Engine向けマネージド制約の機能について解説と検証を行ってみました。
マネージド制約が利用できるようになったことで組織のセキュリティガバナンスをより安全かつ柔軟に強化できるようになりました。

特に重要なポイントは以下の3点です。

• Dry Run + Policy Simulator により、本番適用前に影響範囲を安全に確認できる
• タグベースの条件付きルール で、画一的なブロックではなく柔軟な例外設定が可能
• レガシー制約からの移行 が推奨されており、より精緻なメタデータレベルの評価が利用できる

既存のレガシー制約を利用している組織では、段階的にマネージド制約へ移行していくことを検討してみてはいかがでしょうか。

この記事が誰かの助けになれば幸いです。

以上、クラウド事業本部コンサルティング部の渡邉でした！