10月21日、Robina Mirbaharが「Building Production-Ready Open-Weights AI Agents with Gemma, Google ADK, and Cloud Run GPUs」と題した記事を公開した。ラップトップで動く「Hello World」チャットボットではなく、グラウンディング・サーバーレスGPUスケーリング・セキュリティ・CI/CD評価という本番投入の4つの壁すべてに正面から答える実装ガイドだ。

AIエージェントのチュートリアルの大半は、ラップトップ上で動く「Hello World」相当のチャットボットで終わる。企業のエンジニアリングチームが実際にオープンウェイトモデルを本番投入しようとしたとき、まったく別の壁にぶつかる。Mirbaharはその問題を正直に認めた上で、CloudGuardという実働プロジェクトを軸に、エンタープライズ対応に必要な4つの課題すべてに答えるリファレンス実装を公開している。コードはcloudguard-gemma-agent GitHubリポジトリで公開されており、Google Cloud Shell上でそのまま動かすことができる。

本番投入で必ず直面する4つの壁

記事が最初に整理しているのが、オープンウェイトモデルを実運用に持ち込む際に必ず直面する4つの問いだ。

1. グラウンディング：Cloud FirestoreなどのライブデータにGemmaを接続し、幻覚（ハルシネーション）を防ぐにはどうするか
2. サーバーレスGPUスケーリング：アイドル時にはゼロスケールし、無駄なGPUコストを発生させないようにするにはどうするか（Cloud Run + vLLM + Cloud Storage FUSE）
3. セキュリティとガバナンス：APIキーの漏洩、プロンプトインジェクション、本番サービスへの誤操作を防ぐにはどうするか
4. テストと最適化：CI/CDでエージェントのツール呼び出しをユニットテストし、QLoRAファインチューニングで小型モデルを大型モデル相当の精度に引き上げるにはどうするか

アーキテクチャの核心：ローカルとクラウドを切り替える設計

エンジニア的に最も刺さるのが、**.env一枚でローカルOllamaとCloud Run vLLMを切り替える設計**だ。Google ADK（Agent Development Kit）はGoogleが提供するエージェントオーケストレーションフレームワークで、そのLiteLlm統合を使うことで、エージェントのオーケストレーションコードを一行も変えずに、開発中はローカルのlocalhost:11434を参照し、本番では自前ホスティングのvLLMエンドポイントに向け直せる。vLLMはオープンソースの高速LLM推論サーバーで、OpenAI互換APIを提供する。

# Gemma Inference Backend Mode: "local_ollama" | "cloud_run_vllm"
GEMMA_BACKEND_MODE="local_ollama"

# Local Prototyping via Ollama
OLLAMA_API_BASE="http://localhost:11434"
GEMMA_MODEL_NAME="ollama_chat/gemma3:27b"

# Production Cloud Run GPU vLLM Endpoint
GEMMA_VLLM_ENDPOINT_URL="https://gemma-vllm-service-xyz-uc.a.run.app/v1"
GEMMA_VLLM_MODEL_ID="google/gemma-3-27b-it"

build_adk_root_agent()は環境変数を読み取り、LiteLlmオブジェクトのエンドポイントを動的に切り替える。クラウドGPUに触れる前にローカルで全テストを完結させられる点は、コスト管理の観点で実用的だ。

Cloud Firestoreとのツール接続

孤立したLLMは社内インシデントデータもGPUコスト情報も知らない。Google ADKはPythonの型ヒントとdocstringを自動でJSON Schemaのツール定義に変換し、Gemmaのファンクションコーリングに渡す。

Mirbaharが強調しているのは、コンパクトなオープンウェイトモデル（Gemma 4B / 12B / 27B）は、docstringのArgs:セクションと具体的なフォーマット例（'INC-YYYY-NNNN'のような形式）に強く依存するという点だ。「Pythonのdocstringをファーストクラスのプロンプトエンジニアリングとして扱う」というルールを明文化している。

実装されたツールは4本：

• get_service_incident(incident_id: str)：特定インシデントの重大度・症状・GPU種別・時間あたりUSDバーンレート・是正ランブックを取得
• list_active_alerts(environment: str)：production / staging / all でフィルタリングしたオープンインシデント一覧
• check_gpu_quota_and_cost(region: str)：NVIDIA L4およびRTX PRO 6000のクォータ、使用量、月次FinOpsバジェット消化率を確認
• mitigate_runaway_workload(...)：暴走したステージングワークロードを是正

全ツールはCloud Firestoreをバックエンドとしつつ、USE_LOCAL_MOCK_DB="true"でローカルJSONスキーマに差し替えられるため、クラウドリソースをプロビジョニングする前にテストスイート全体を検証できる。

アイドル時ゼロコストの実現メカニズム

サーバーレスGPU構成の要は、Cloud Runの**min-instances=0設定**だ。リクエストが来ない時間帯はコンテナインスタンスを完全にゼロにスケールダウンし、GPU課金が発生しない。リクエストが来た時点でコールドスタートが走るが、ここで課題になるのがモデルウェイトのロード時間だ。

この問題を解消するのが**Cloud Storage FUSE**によるゼロダウンロードストリーミングだ。Cloud Storage FUSEはGoogle Cloud StorageバケットをPOSIXファイルシステムとしてマウントするオープンソースのFUSEアダプターで、コンテナ起動時にモデルウェイトをローカルに丸ごとダウンロードするのではなく、推論に必要なテンソルのチャンクだけをオンデマンドで読み込む。Gemma 27Bのような大型モデルでもコールドスタートのボトルネックを大幅に緩和でき、ダウンロード完了を待たずに推論を開始できる。vLLMはCloud Run上でNVIDIA L4またはRTX PRO 6000 GPUを使って推論を処理し、Cloud Storage FUSEがストレージとの橋渡しを担う構成だ。

FinOpsの具体的な数字

記事では抽象論ではなく、具体的な数字が並んでいる。GPU管理の文脈で示されているのは：

• 暴走したML一括ジョブで発生する節約額：**$36.12/時間**
• ファインチューニング後の比較：Gemma 27B（54 GB VRAM）に対して、Gemma 4B + QLoRAは8.9 GB VRAM、推論レイテンシ約51ms（NVIDIA L4 1枚）
• QLoRAによる効果：2.8倍の高速化、6倍のGPUメモリ削減（Gemma 27B比）、ツール呼び出し精度はGemma 27Bと同等（スコア1.00）

なお、6倍のメモリ削減はGemma 27B（54 GB）とGemma 4B+QLoRA（8.9 GB）の比較値であり、同一モデルへのQLoRA適用で削減できるという意味ではない点に注意が必要だ。

セキュリティとCI/CD評価

ガバナンス層として、**Model Armor**（before_model_callback）がモデルに到達する前にGCP APIキー（AIza...などのパターン）を自動で伏字化する。Model ArmorはGoogle Cloudが提供するLLMセキュリティサービスで、プロンプトインジェクション検出や機密情報フィルタリングをAPIレベルで実装できる。RBACベースのツールポリシー（before_tool_callback）により、production環境への自動スケーリングや終了操作はsre-incident-commanderのエスカレーションなしに実行不可となっている。

CI/CDゲートとしては**ADK Eval（scripts/run_eval.py）を使い、ツール軌跡の精度（tool_trajectory_avg_score）と応答ファクチュアリティ**（response_match_score）を各ビルドで自動スコアリングする。ADK EvalはGoogle ADKに付属するエージェント評価フレームワークで、ツール呼び出しの順序・引数・応答内容を定量的に検証できる。「感覚的なチェック」ではなく、定量的なリリースゲートをパイプラインに組み込む構成だ。

6段階の本番ライフサイクル

記事全体は以下の6ステージで構成されている：

1. Build：Google ADKエージェントのスキャフォールディング（ローカルOllamaでの開発）
2. Connect：Cloud Firestoreを使ったPythonファンクションコーリングツールの実装
3. Scale：Cloud Run Serverless GPU（NVIDIA L4 / RTX PRO 6000）へのvLLMデプロイと、Cloud Storage FUSEによるウェイトのゼロダウンロードストリーミング、min-instances=0によるアイドル時ゼロコスト化
4. Govern：Model ArmorとRBACによる多層防御
5. Optimize：ADK EvalとOpenTelemetry（Google Cloud Trace）によるCI/CD自動評価
6. Specialize：Vertex AI上でのQLoRAファインチューニング（Gemma 4B → 27B相当の精度）

QLoRAはQuantized LoRA（Low-Rank Adaptation）の略で、モデルウェイトを量子化した状態でアダプター層のみをファインチューニングする手法だ。フルファインチューニングと比べてVRAM消費を大幅に抑えながら、特定タスクへの適応精度を高められる。

詳細はBuilding Production-Ready Open-Weights AI Agents with Gemma, Google ADK, and Cloud Run GPUsを参照していただきたい。