[セッションレポート] Cloud Run のゼロトラストセキュリティ 2026年最新版の解説 #GoogleCloudNext

はじめに

こんにちは。すらぼです。
Google Cloud Next' 26 のセッション "Architect zero-trust security with Cloud Run" に参加してきました。
Cloud Run 上でのゼロトラストセキュリティについて、新機能の紹介と NTT docomo, NTT データの実践事例が紹介されたセッションです。

---

全体像：セッションの構成

セッションではまず、従来の境界型セキュリティ（外側だけを硬い殻で守る M&M チョコレートのようなモデル）と、ゼロトラストの違いが説明されていました。
従来の境界型セキュリティでは、「中に入るのは難しくても、中に入るとほぼ無防備」といった課題がありました。この課題を、ゼロトラストによって解決します。

ゼロトラストの基本原則として、以下の3つが挙げられています。

1. すべてのトラフィックを脅威と見なす: 内部ネットワークであっても外部であっても、常に検証する。
2. 最小権限アクセスの徹底: システム内のすべてのIDに対して、必要最小限の権限のみを付与する。
3. 継続的な監視: 一度の認証で終わりではなく、常に監視し続ける。

この原則を踏まえて、セッションでは以下の3つのテーマが取り上げられていました。

1. IAP（Identity-Aware Proxy）の Cloud Run 直接統合 で、認証まわりの設定がシンプルに。
2. AI エージェント向けの認証基盤 として、MCP サーバーの保護機能が強化。
3. Service Bindings による、サービス間通信の簡素化。

---

1. ゼロトラストを支える Cloud Run の基本機能

Cloud Run には、設計段階からゼロトラストを支える機能が組み込まれています。

• アイデンティティと認可: 人間、アプリケーション、AIエージェントのすべてに対して、ロールベースアクセス制御（RBAC）が適用されます。また、近日中に12,000以上のサービス・ジョブ・ワークロードに対して SPIFFE ベースの一意のID割り当てが提供される予定とのことです。
• 暗号化とワークロード分離: データは保存中・転送中の双方で常に暗号化されています。コンテナは2層のサンドボックスで隔離されており、VPC統合によりトラフィックをプライベートネットワーク内に限定することも可能です。BYOK（Bring Your Own Key）による独自の暗号化キーもサポートされています。
• 監視と検出: 組み込みのモニタリング機能に加え、悪意のあるバイナリを検知するランタイム保護機能も提供されています。

これらの標準機能を組み合わせることで、 Cloud Run 上で簡単に Zero-trust を実現できます。

2. Identity-Aware Proxy (IAP) の直接統合

また、先日のアップデートで、 IAP が Cloud Run に直接統合されました。

これまで IAP を利用するには外部 HTTPS ロードバランサーの構築が必要でしたが、Cloud Run のコンソールからワンクリックで有効化できるようになりました。

• コストと手間の削減: ロードバランサーの構築費用や複雑な設定が不要に。
• 柔軟な認証: 社内ユーザーだけでなく、外部ユーザーや独自のIDプロバイダー（IdP）との連携もサポートされています。Workforce Identity Federation による外部 IdP 連携にも対応しています。

GA リリースではプレビュー版から大幅に改善され、組織レベル・プロジェクトレベルのどちらでも IAP を利用できるようになっています。

デモでは、Cloud Run にデプロイしたアプリに対して IAP を有効化し、Google SSO でのログインが必要になるまでの流れが実演されていました。ボタンひとつで設定できる手軽さが印象的でした。

3. AIエージェント（MCPサーバー）の保護

AI エージェントが Cloud Run 上のツールを利用する際のセキュリティ機能も紹介されていました。

• Agent Identity: Cloud Run 上の各エージェントに一意の SPIFFE ID を割り当て、強力なID基盤を提供します。
• OAuth for MCP servers: Cloud Run 上の MCP（Model Context Protocol）サーバーに対し、IAP を用いた OAuth 認証を組み込めます。
• Authz with Agent Gateway: エージェントの egress 経路にカスタム認可ポリシーを適用し、エージェント間の不要な通信を制限できます。
• On-behalf-of user: Agent Identity Auth Manager により、ユーザーのトークンが利用できない場面でも、Auth Management Control を通じてエージェントがユーザーの代理として安全に操作を実行できます。

デモでは、MCP サーバーを Cloud Run にデプロイして IAP + OAuth で保護し、Gemini CLI から接続するまでの流れが紹介されていました。gcloud run deploy のフラグ2つで MCP サーバーの保護が完了するのは便利そうです。

4. サービス間通信の簡素化「Service Bindings」

サービス間通信をシンプルにする新しい仕組みとして「Service Bindings」が紹介されていました。従来の Cloud Service Mesh は高度な L7 トラフィック管理を提供する一方で、サイドカーの管理やリソース設定など運用コストが高く、GKE/GCE を含むマルチランタイム環境向けです。Service Bindings は Cloud Run 同士の通信にフォーカスした軽量な選択肢という位置付けです。

• メッシュ不要の通信: サービスメッシュを構築することなく、自動的な OIDC トークンの生成や TLS 暗号化による通信が可能です。
• リージョン限定のルーティング: トラフィックを特定のリージョンや VPC 内に限定し、ホスト名による内部ルーティングを設定できます。
• 可観測性の向上: 通信の成功率、レイテンシー、スループットなどの指標が標準で収集されます。

5. NTTデータの実践事例：データの民主化

セッションの後半では、NTT docomo, NTT データによる実践事例が紹介されていました。従来はデータ利用の申請から承認までに時間がかかり、回答が届く頃にはタスク自体が変わっていることもあったとのことです。分析者を増やすのではなく、誰もが自分で質問に答えられる環境を作ることを目標に、「データの民主化」と「ゼロトラスト」の両立に取り組んだ事例です。

導入成果

• 5,300 MAU（内部ユーザー）
• 450k hour の Toil 削減
• 163 Apps が Cloud Run 上で稼働

ゼロトラスト基盤の3本柱

1. Anyone, anytime: 外部ID（External identities）を IAP で制御し、マルチテナントに対応。
2. Security and reliability: コンテナのサンドボックス化とオートスケールによる耐障害性のあるゼロトラスト基盤。
3. Supply chain security: CI/CD パイプラインでのシフトレフトスキャンにより、サプライチェーンのリスクを排除。

マルチエージェント基盤

既存の163アプリを書き換えずに MCP サーバーとして利用し、エージェントが安全に情報をやり取りできる環境を構築したとのことです。「すべてのエージェントがすべてのエージェントと通信できる」状態はリスクが大きいため、コーディネーターエージェントが「見るべきものだけを見る」よう明示的に制限するアーキテクチャが採用されていました。

今後は Cloud Run 上の MCP サーバーをサブエージェントとして呼び出す構成や、Cloud NGFW によるアウトバウンド制御も計画されているとのことです。

---

まとめ

Cloud Run でのゼロトラストセキュリティについてのセッションでした。
直近のアップデートにより、IAP の直接統合や Service Bindings によって、セキュリティまわりの設定がかなりシンプルになっている印象です。特に IA 活用がさらに加速して、Cloud Run に MCP サーバーのデプロイを行う場合、セキュリティやトラッキングは非常に重要な要素の1つとなります。それを、Cloud Run の強力な機能がカバーしてくれるとなると、非常に頼もしく感じました。

また、セッション中に印象に残ったのは、「セキュリティは後付けするものではなく、システムを成長させるための基盤である」というメッセージです。NTT データの事例でも、ゼロトラストを最初から設計に組み込むことで、163 のアプリを安全に運用しつつデータの民主化を実現していたのが具体的な裏付けになっていました。

この記事がお役に立てば幸いです。以上、すらぼでした！