GKE の Agent Sandbox を使用した自動コード評価

1. はじめに

この Codelab では、Hackathon Judge アプリケーションを Google Kubernetes Engine（GKE）にデプロイし、Kubernetes-sigs Agent Sandbox を使用してエージェント ワークロードを安全かつ確実に実行します。

このプラットフォームは、LLM エージェントを使用してハッカソン プロジェクトの審査、テスト、採点のプロセスを自動化するように設計されています。審査では信頼できない参加者のコード送信を評価する必要があるため、コード インジェクション、権限昇格、リソースの不正使用を防ぐには、安全な実行サンドボックスが不可欠です。

演習内容

• ターゲットの Google Cloud サービスをプロビジョニングし、ターゲット API を確立します。
• GKE Autopilot を初期化し、Agent Sandbox CRD、クラスタ構成、Sandbox Router をインストールします。
• サンドボックス ゲートウェイ、サンドボックス クレーム テンプレート、サンドボックス WarmPool をデプロイします。
• REST バックエンド API、ADK 審査ワーカー エージェント、React フロントエンド UI をデプロイします。
• 外部ロードバランス ルーティングを接続し、プラットフォームにアクセスして安全なサンドボックス化された審査ワークフローを実行します。

必要なもの

• ウェブブラウザ（Chrome など）。
• 課金を有効にした Google Cloud プロジェクト

この Codelab で作成するリソースの合計ランタイム料金は 5 ドル未満です。

2. 問題: 信頼できないコードを安全に評価する

ハッカソンは、参加者がプロジェクト（多くの場合、ソースコードを含む）を構築して提出し、評価を受ける、ペースの速いイノベーション イベントです。これらの送信を手動で判断するには、時間とリソースが大量に必要になります。AI エージェントを使用して採点を自動化することは有望なソリューションですが、重大なセキュリティ上の課題が生じます。バグ、悪意のあるコード、リソースを大量に消費する可能性のある参加者提供のコードを安全に実行するにはどうすればよいでしょうか？

信頼できないコードをインフラストラクチャで直接実行すると、次のようなリスクが生じます。

• コード インジェクション: 悪意のあるスクリプトがセンシティブ データにアクセスしたり、センシティブ データを変更したりする可能性があります。
• 権限昇格: コードが他のシステムやネットワーク リソースへの不正アクセスを試みる可能性があります。
• リソースの不正使用: コードの記述が不適切であったり、サービス拒否攻撃が行われたりすると、CPU、メモリ、ネットワーク帯域幅が過剰に消費され、他のオペレーションに影響する可能性があります。

AI を使用してハッカソンの審査を自動化するには、システムや他の提出物から完全に分離された環境で提出されたコードを実行する方法が必要です。

3. ソリューション: GKE Agent Sandbox

GKE Agent Sandbox は、まさにこの課題に対応するために設計された機能です。GKE 上で分離されたステートフルな単一レプリカ ワークロードの管理に役立ちます。また、信頼できないコードを安全かつ効率的に実行する必要がある AI エージェント ランタイムなどのユースケース向けに最適化されています。

エージェント サンドボックスの主なメリットは次のとおりです。

• カーネルレベルの分離: gVisor などのテクノロジーを使用して、信頼できないコードをカーネルレベルで厳格に分離し、コードがホストシステムや他のコンテナにアクセスできないようにします。
• 1 秒未満のプロビジョニング: サンドボックス環境の高速プロビジョニング（通常は 1 秒未満）を提供します。これは、オンデマンドのコード評価に不可欠です。
• クラウドネイティブな拡張性: Kubernetes のパワーと GKE のマネージド インフラストラクチャを活用します。

Agent Sandbox を使用すると、ハッカソンの各提出用にオンデマンドの隔離された環境を作成できます。AI 判定エージェントは、プラットフォーム全体の完全性を損なうことなく、この安全なサンドボックス内でテストの実行、コードのコンパイル、その他の評価手順の実行を Agent Sandbox に指示できます。これにより、ハッカソンの採点を自動化するためのスケーラブルで安全かつ効率的な方法が提供されます。

4. 始める前に

Cloud Shell の起動

下のボタンをクリックして Google Cloud Shell を起動します。これには、必要なデベロッパーとクラウドのコマンドライン ユーティリティが事前に構成されています。

Cloud Shell を起動する

API を有効にする

Cloud Shell で次のコマンドを実行して、プラットフォームの実行に必要なすべてのターゲット Google Cloud API を有効にします。

gcloud services enable \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  pubsub.googleapis.com \
  aiplatform.googleapis.com \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com

これらの API を有効にする理由: 不正アクセスや請求を防ぐため、Google Cloud サービスはデフォルトで無効になっています。これらの特定の API を有効にすると、コンテナ オーケストレーション（GKE）、安全なコンテナ ストレージ（Artifact Registry）、サーバーレス ビルド パッケージング（Cloud Build）、信頼性の高いメッセージ キュー（Pub/Sub）、AI モデル サービス（Vertex AI）、プロジェクト構成（Cloud Resource Manager と IAM）、サーバーレス データ分析（BigQuery）、データベース レベルの AI バインディング（BigQuery Connection）が有効になります。

5. インフラストラクチャを設定する

このステップでは、コード リポジトリのクローンを作成し、自動設定スクリプトを実行して、ターゲット クラウド アーキテクチャとベースライン クラスタ コンポーネントをデプロイします。

リポジトリのクローンを作成する

すべてのアプリケーション サービス、設定スクリプト、Kubernetes マニフェスト宣言を含むリポジトリのクローンを作成します。

git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos
git sparse-checkout set codelabs/ai-toolkit-lab-2/hackathon-judge
cd codelabs/ai-toolkit-lab-2/hackathon-judge

デプロイ スクリプトを実行する

クラウド リソース、データベース モデル、ベースライン Kubernetes クラスタ ポリシーの基本的な設定は、deploy.sh スクリプトによって自動化されます。

スクリプトを実行します。

./deploy.sh

インタラクティブ シェルのプロンプトに従って、アクティブなプロジェクト ID やターゲット リージョンなどの構成を指定します。このスクリプトは、ローカル .env 構成を自動的に生成し、リソースをバインドし、コンテナ イメージをコンパイルし、GKE ベースライン インフラストラクチャを登録します。

スクリプトによって実行されるターゲット オペレーションは次のとおりです。

1. 環境構成の設定

このスクリプトは、GKE、Pub/Sub、BigQuery、プロジェクトの変数パラメータを保存する .env 構成ファイルを作成します。このファイルをソースにすると、後続の Kubernetes マニフェスト定義がすべて動的に入力されます。

この環境ファイルを構成する理由: .env ファイルは構成パラメータを一元化し、後続の手順で手動で適用する GKE マニフェストが同一のリージョン設定、プロジェクト名、リソースを使用するようにします。これにより、環境構成とソースコードが厳密に分離されます。

2. Google Cloud CLI とターゲット プロジェクトの構成

スクリプトは、gcloud、bq、kubectl、envsubst ユーティリティがインストールされていることを確認し、認証状態を確認して、アクティブな構成ターゲットをアクティブな Google Cloud プロジェクトにロックします。

アクティブなプロジェクトをターゲットにする理由: アクティブなターゲット プロジェクトを設定すると、CLI コマンドがアカウント内の他のプロジェクトに影響を与えないようにし、事前認証チェックを実行して、無効な認証情報が原因で設定コマンドがデプロイ中に失敗しないようにします。

3. ターゲットの Google Cloud APIs を有効にする

このスクリプトは、べき等チェックを実行して、ターゲットの Google Cloud サービス API（GKE、Artifact Registry、Cloud Build、Pub/Sub、Vertex AI、BigQuery、IAM）を確認して有効にします。

Google Cloud APIs を有効にする理由: マネージド クラウド サービスは、エンドポイントに到達可能になる前、またはリソースを作成する前に有効にする必要があります。これらを最初に有効にすると、リージョン GCP API ゲートウェイが後続のリソース プロビジョニング コマンドを処理できるようになります。

4. Artifact Registry Docker リポジトリのプロビジョニング

このスクリプトは、選択したターゲットの場所に hackathon-judge-repo という名前の Docker コンテナ リポジトリをプロビジョニングします。

Artifact Registry リポジトリを作成する理由: GKE クラスタは、アプリケーション イメージを迅速に pull するために、同じリージョン ネットワーク内のプライベート コンテナ レジストリへの安全なアクセスを必要とします。Artifact Registry は、Docker コンテナ イメージのカタログ作成、スキャン、保存を行うための安全なプライベート ホストを提供します。

5. GKE Autopilot クラスタのプロビジョニング

このスクリプトは、hackathon-judge-cluster という名前の Google Kubernetes Engine（GKE）Autopilot クラスタをプロビジョニングします。

GKE Autopilot クラスタをデプロイする理由: GKE Autopilot は、ノードのプロビジョニング、スケーリング、ヘルス モニタリング、ホスト OS のセキュリティ アップグレードを自動的に管理します。本番環境グレードのコンテナ プラットフォームを提供し、永続サービスをオーケストレートし、安全なワーカー サンドボックスをオンデマンドで動的にスケジュールします。

6. Pub/Sub トピックとサブスクリプションの構成

このスクリプトは、対応するワーカーと API のサブスクリプションとともに、メッセージ トピック（judging-tasks と judging-results）をプロビジョニングします。

Pub/Sub トピックとサブスクリプションをデプロイする理由: コードの送信の評価は遅く、リソースを大量に消費します。メッセージ キュー アーキテクチャを使用すると、同期ユーザー向け API がワーカーノードから切り離されます。API バックエンドはジョブを judging-tasks トピックに push し、ワーカー エージェントはタスクが利用可能になると pull します。これにより、API のブロックを防ぎ、自動再試行機能を提供します。

7. BigQuery データセット、テーブル、AI 接続の構成

このスクリプトは、hackathon_judge データセットを作成し、構造化 SQL データベース スキーマを適用し、シードレコードを読み込み、必要な AI ロールとストレージ ロールを BigQuery ML 接続サービス アカウントに付与します。

8. Cloud Build を使用してコンテナ ビルドをトリガーする

このスクリプトは cloudbuild.yaml 定義をトリガーして、React UI、Go REST サーバー、Python ADK ワーカー、FastAPI サンドボックスをコンパイルし、アクティブなリポジトリの Git commit SHA でタグ付けされた分離コンテナ イメージにパッケージ化して、Artifact Registry に保存します。

9. Agent Sandbox カスタム リソース定義（CRD）の登録

このスクリプトは、最新の Kubernetes-sigs Agent Sandbox カスタム リソース定義（manifest.yaml と extensions.yaml）をダウンロードして登録し、GKE のコア機能を拡張します。

Agent Sandbox インフラストラクチャをインストールする理由: 標準の Kubernetes クラスタには、保護されたオンデマンド サンドボックスの割り当てのサポートがありません。Agent Sandbox CRD を登録すると、GKE のコントロール プレーンが拡張され、Kubernetes がカスタム リソース（SandboxTemplates や SandboxClaims など）を使用して安全なサンドボックス化されたマイクロ コンテナをネイティブにオーケストレートできるようになります。

10. Namespace、サービス アカウント、Workload Identity の構成

このスクリプトは、hackathon-judge Namespace をプロビジョニングし、Kubernetes サービス アカウント（KSA）を登録し、Workload Identity マッピングを確立して、GKE Pod にターゲット Google Cloud 権限を付与します。

11. サンドボックス ルーターのデプロイ

スクリプトは k8s/sandbox_router.yaml マニフェストを適用し、サンドボックス ルーターのデプロイとサービスを開始して、正常な状態になるまで待機します。

サンドボックス ルーターをデプロイする理由: サンドボックス ルーターは、内部コントロール プレーンの中央ゲートウェイです。ADK 審査ワーカー エージェントが呼び出して安全なサンドボックスの要求、アクセス、解放を行うシンプルな API を公開し、ルーティング マッピングを管理して、クラスタレベルの Pod 割り当てをアプリケーション ロジックから抽象化します。

6. Agent Sandbox Gateway、Claim、WarmPool を構成する

このステップでは、特殊な Sandbox ネットワーク ゲートウェイを手動で構成し、Sandbox クレーム テンプレートを登録して、Sandbox WarmPool をデプロイし、超低レイテンシのサンドボックスを有効にします。

ソース環境変数

環境変数を必要とするテンプレートを適用する前に、setup-env.sh スクリプトをソースして、必要なすべての変数を解析してシェルにエクスポートします。

source ./setup-env.sh

サンドボックス ゲートウェイを適用する

サンドボックス トラフィックのルーティング用に特別に構成されたゲートウェイをデプロイします。

kubectl apply -f k8s/sandbox-gateway.yaml

サンドボックス ゲートウェイをデプロイする理由: サンドボックス ゲートウェイは、サンドボックス ルーティング専用の安全で高性能な上り（内向き）コントローラとして機能します。サンドボックス ネットワークを分離し、安全なローカル ターゲットを提供します。これにより、ワーカー エージェントはエンドポイントを外部に公開することなく、要求されたサンドボックスと通信できます。

サンドボックス申請テンプレートを適用する

envsubst を使用して、アクティブな環境変数でサンドボックス テンプレート定義を入力し、適用します。

source ./setup-env.sh
envsubst < k8s/sandbox-claim-template.yaml | kubectl apply -f -

サンドボックス クレーム テンプレートをデプロイする理由: サンドボックス クレーム テンプレートは、環境を定義するブループリント構成として機能します。実行するコンテナ イメージ（デベロッパー ツールが事前にパッケージ化されている）、環境パラメータ（GCP プロジェクト ID）、ポート、リソース上限（CPU/メモリのターゲット）を指定します。これにより、これらのコンテナ インスタンスが gVisor（gvisor ランタイム）を利用して実行されるように GKE が構成され、信頼できない参加者のコードがカーネル仮想化分離の追加レイヤで実行されることが保証されます。

サンドボックス WarmPool を適用する

Sandbox WarmPool を適用して、実行中のサンドボックスを事前に初期化します。

kubectl apply -f k8s/sandbox-warmpool.yaml

ウォームプールのスタンバイ インスタンスが正常に起動したことを確認します。

kubectl get pods -n hackathon-judge -l app=sandbox

事前ウォーミングのレイテンシ: GKE がサンドボックス化されたコンテナ イメージを pull して、事前ウォーミングされたレプリカをスピンアップするまでに 1 分ほどかかることがあります。このコマンドを watch フラグ -w を使用して実行するか、5 つのレプリカすべてが Running 状態になるまで繰り返してから、デプロイ手順に進みます。

Sandbox WarmPool をデプロイする理由: プロビジョニング、スケジューリング、イメージの pull、新しいコンテナ Pod のオンデマンド起動には、かなりの起動オーバーヘッド（30 秒以上のコールド スタート時間）が発生します。Sandbox WarmPool は、アクティブで事前にウォームアップされたサンドボックス Pod のスタンバイ プールを維持します（デフォルトでは 5 つのレプリカ）。ワーカー エージェントが評価環境をリクエストすると、Sandbox Router は実行中の事前ウォーミングされた Pod を直ちに割り当て、起動遅延を 1 秒未満に短縮します。

7. アプリケーション コンポーネントをデプロイする

安全なサンドボックス インフラストラクチャが完全にアクティブになったので、中央のバックエンド API、ワーカー エージェント、React ウェブ インターフェース、上り（内向き）Gateway マッピングをデプロイします。

バックエンドをデプロイする

オーケストレーター REST API バックエンドをデプロイします。

source ./setup-env.sh
envsubst < k8s/backend.yaml | kubectl apply -f -

エージェントをデプロイする

ADK 判定ワーカー エージェントをデプロイします。

source ./setup-env.sh
envsubst < k8s/agent.yaml | kubectl apply -f -

フロントエンドをデプロイする

インタラクティブなウェブ ユーザー インターフェースをデプロイします。

source ./setup-env.sh
envsubst < k8s/frontend.yaml | kubectl apply -f -

外部ゲートウェイとルーティングを構成する

外部クライアント トラフィックをマッピングするメインの Gateway と Ingress HTTP ルートをデプロイします。

kubectl apply -f k8s/gateway.yaml

外部 Ingress ゲートウェイをデプロイする理由: 外部ゲートウェイは、Kubernetes Gateway API を使用してサービスを公開します。ロードバランスされたパブリック IP アドレスをプロビジョニングし、パスルールに基づいてルートをマッピングします。/api/* の API リクエストを Go バックエンドに転送し、他のすべてのクライアント ウェブ トラフィック（/）を React フロントエンドにマッピングして、パブリック クラスタ アクセスを保護します。

ロールアウトを確認する

シェル実行をブロックし、3 つのコア サービス Deployment すべてが正常なロールアウト ステータスになるまで待機します。

kubectl rollout status deployment/backend -n hackathon-judge --timeout=300s
kubectl rollout status deployment/agent -n hackathon-judge --timeout=300s
kubectl rollout status deployment/frontend -n hackathon-judge --timeout=300s

8. アプリケーションの確認と使用

UI へのアクセス

新しくプロビジョニングされたメイン ロードバランサ ゲートウェイの外部パブリック IP アドレスを取得します。

ロードバランサのプロビジョニングを待機する: Google Cloud のグローバル外部ロードバランサは、IP リソースの割り当て、グローバル転送ルールの設定、グローバル ルーティング パスの構成に 2 ～ 5 分かかります。ADDRESS 列が空の場合や が表示されている場合は、数分待ってからもう一度クエリを実行します。

プロビジョニングのステータスをリアルタイムで確認するには、watch フラグ（-w）を指定してコマンドを実行し、ADDRESS フィールドにパブリック IP アドレスが入力されるまで待ちます。

kubectl get gateway -n hackathon-judge hackathon-judge-gateway -w

プロビジョニングが正常に完了すると、次のような出力が表示されます。

NAME                      CLASS    ADDRESS          PROGRAMMED   AGE
hackathon-judge-gateway   gke-l7   34.120.120.120   True         3m

ADDRESS 列に有効なパブリック IP アドレスが表示され、PROGRAMMED のステータスが True になったら、Ctrl+C を押して監視を停止します。

Gateway ステータスを取得する理由: Gateway API はパブリック Ingress を処理します。Gateway のステータスを確認すると、Google Cloud の外部グローバル ロードバランサによってクラスタに割り当てられたパブリック ロードバランス外部 IP アドレスが返されます。これは、プラットフォームのパブリック アドレスを表します。

ブラウザで割り当てられたパブリック IP アドレスを開き、ハッカソン審査員ダッシュボードを読み込みます。

タスクを送信する

• フロントエンド UI を使用してダッシュボードに移動し、ハッカソンを選択します。

• 任意のプロジェクトで Run Agent をクリックすると、エージェントがルーブリックに照らしてプロジェクト全体を評価します。

Watch Sandbox のキックオフ

hackathon-judge Namespace 内のアクティブな Pod をモニタリングして、実行を判定するためにサンドボックス Pod が動的に要求され、プロビジョニングされることを確認します。

kubectl get pods -n hackathon-judge -w

設計による WarmPool の補充: ワーカー エージェントがプールから事前ウォーミングされたサンドボックス Pod を要求すると、リストに新しいサンドボックス Pod が起動します（Pending -> ContainerCreating -> Running に移行）。これは設計によるものです。GKE Agent Sandbox コントローラは、プールサイズを積極的にモニタリングし、アクティブな事前ウォームアップされたサンドボックス コンテナの正確な目標数（デフォルトでは 3）を維持するようにプログラムされています。スタンバイ コンテナが要求されると、コントローラはすぐに新しい事前ウォーミングされた Pod をスケジュールして置き換えます。これにより、プラットフォームは常に次の評価タスクに備え、起動時間は 1 秒未満になります。

ワーカー エージェント Pod のログを確認して、ADK の段階的な判定評価ロジックを確認します。

kubectl logs -l app=agent -n hackathon-judge

エージェントログを検査する理由: ワーカー エージェントログを検査すると、評価パイプラインの詳細な内部ステップがリアルタイムで表示されます。ADK エージェントがタスクを取得し、サンドボックス コンテナをリクエストし、コンパイル ターゲットを実行し、Gemini でレポートを分析し、スコアカードを公開する様子をトレースできます。

9. （省略可）仕組み

Agent Sandbox のアーキテクチャ

BigQuery AI 関数は、テキストベースの提出物や README の主張を評価するのに優れていますが、エンジニアリング プロジェクトを評価するには、コードのコンパイル、サードパーティ ライブラリのインストール、実際のテストスイートの実行が必要です。

未加工のユーザーコードを実行すると、ホストの侵害、コンテナのブレイクアウト、リソースへの不正アクセスなど、重大なセキュリティ リスクが生じます。GKE Agent Sandbox フレームワークは、gVisor（runsc）仮想化を使用して分離されたサンドボックス ワークロードをオーケストレートすることで、これらのリスクを軽減します。

システム インタラクション フロー

下の図は、安全なサンドボックス化された審査の実行中に、イベント ドリブン システムのさまざまな要素がどのように通信するかを示しています。

エンゲージメント ツールとコンポーネントの連携の仕組み

• React フロントエンド UI: ユーザーが基準モデルを構成し、チームを登録し、プロジェクト URL を送信し、最終的なグレーディング スコアカード（ファイル全体の不一致やエンジニアリング コメントを含む）を確認できるインタラクティブなインターフェースを公開します。
• Go REST バックエンド API: グローバル API エンドポイントを管理します。プロジェクト構成を BigQuery に保存し、判定ジョブを Pub/Sub に push して、重い計算実行パイプラインを分離します。
• Google Pub/Sub: タスク メッセージをキューに安全に保持し、API とアクティブなワーカー インスタンス間の通信を非同期でオーケストレートするメッセージ指向のブローカー。
• Python ADK ワーカー（スーパーバイザー エージェント）: Pub/Sub からタスクを pull するバックグラウンド ワーカー。Google Agent Development Kit（ADK）を活用して、評価をオーケストレートするように指示された上位レベルのスーパーバイザー エージェントを起動します。スーパーバイザーは、主要なツールである evaluate_repository を呼び出して、詳細な未加工コマンドのテストを委任します。
• Sandbox Router & Gateway（GKE Control Plane）: 標準の Sandbox カスタム リソース定義（SandboxClaims、SandboxTemplates）を登録する内部制御ゲートウェイ。GKE ネットワークを調整して Pod を割り当てて保護し、接続ストリームをワーカー クライアントに返します。
• Sandbox WarmPool: GKE コンテナの起動時間が長くなる（30 秒以上のコールド スタート）のを避けるため、WarmPool はアクティブなスタンバイ Pod を維持します。サンドボックスが要求されると、Router は 1 秒未満でマッピングし、リリース時にリサイクルのスケジュールを設定します。
• gVisor（runsc）分離: 安全なサンドボックス境界として機能するユーザー空間の仮想カーネル。コンテナ空間から GKE ノードカーネルへのシステムコールをインターセプトし、危険な未加工コマンド（システム スクリプトやパッケージ設定など）が絶対仮想化分離の下で実行されるようにします。
• FastAPI Sandbox Runtime: サンドボックス コンテナ内で実行される軽量の Python API サーバー。外部のワーカーツールがファイルを操作してシェルタスクをトリガーできるようにする安全なエンドポイント（/execute、/upload、/download）を公開します。
• Gemini CLI（@google/gemini-cli）: サンドボックス内にインストールされた自律型エージェント スクリプト。デベロッパー環境のランタイム フラグ（--yolo）でトリガーされると、厳密な採点指示シート（prompt.md）と基準定義（criteria.md）を使用して、次の処理を行います。
  • コードベースの階層を動的に分析します（tree や ripgrep などのツールを使用）。
  • 要件を自動的にインストールする（npm install、pip install、go build などのコマンドを使用）。
  • 実際の開発テスト（npm test や pytest など）を実行して、機能を確認します。
  • Vertex AI モデル（コンテナの Workload Identity バインディング認証情報経由）を呼び出して、ファイル ロジックの評価、README とのクレームの相互チェック、ゴースト機能の検出、品質問題のロギングを行い、構造化されたスコアカード レポートを evaluation.json に書き込みます。
• 標準の開発環境: ノード、npm、yarn、pnpm、python、pip、uv、go、gh、git、tree、ripgrep、playwright をサンドボックス コンテナ イメージにバンドルし、自律型サブエージェントに完全なテスト ワークスペースを提供します。

Workload Identity のセキュリティの動作: インフラストラクチャの設定時に、サンドボックス GKE サービス アカウント（hackathon-judge-sandbox-sa）に標準の roles/aiplatform.user IAM 権限が付与されていることに注目してください。サンドボックス Pod 内の Gemini CLI が Vertex AI にモデル レスポンスをリクエストすると、GKE の Workload Identity がバックグラウンドで鍵の生成と認証情報のチェックを自動化します。コンテナは静的 API キーやハードコードされたクラウド認証情報を保存しないため、最上位のセキュリティ ガイドラインが自動的に維持されます。

10. クリーンアップ

Google Cloud アカウントに継続的に課金されないようにするには、この Codelab で作成したリソースを削除します。

./destroy.sh

リソースをクリーンアップする理由: Google Cloud では、リソース使用率モデルに基づいて課金されます。GKE Autopilot クラスタ、ネットワーク ロードバランサ、永続ディスクなどのアクティブなリソースは、アイドル状態でも継続的に料金が発生します。この手順を実行すると、クラスタ Namespace が削除されて Kubernetes オブジェクトがクリアされ、GKE Autopilot クラスタホスト自体が削除されて、基盤となるすべての課金が直ちに終了します。

11. 完了

おめでとうございます！これで、GKE 上の Agent Sandbox を使用して Hackathon Judge アプリケーションが正常にデプロイされました。

分離されたコンテナ化されたセキュリティ制約の下で、信頼できないコードベースの送信をテストして評価できる、安全で最新のイベント ドリブン AI プラットフォームを実装しました。

学習した内容

• GKE インフラストラクチャ: GKE Autopilot と、Pub/Sub や BigQuery などのサポート対象の Google Cloud サービスをプロビジョニングする方法。
• エージェント サンドボックスの構成: カスタム リソース定義、SandboxTemplate、SandboxClaim、高パフォーマンスの Sandbox WarmPool を構成する方法。
• マイクロサービスのデプロイ: Workload Identity バインディングを構成し、マルチコンポーネント マイクロサービス アーキテクチャ（Frontend React、REST Go、Worker ADK Agent、Isolated Sandbox）をデプロイする方法。
• 安全なサンドボックス化: gVisor 仮想化コンテナを利用して、信頼できないサードパーティのコマンドを GKE ノードで安全に実行する方法。

次のステップ

• Agent Sandbox のドキュメントを確認する。
• GKE Autopilot の機能の詳細を確認する。
• Agent Platform のドキュメントをご覧ください。

リファレンス ドキュメント

• Kubernetes Gateway API 仕様
• gVisor サンドボックス ランタイム