こんにちは、DX開発事業部の山中です。Google Cloud Next ’26 に現地参加していました！

この記事は Google Cloud Next ’26「Accelerate CI/CD with coding agents」（BRK3-020）のセッションレポートです。Google Cloud の Developer Connect チームから、コーディングエージェント上で自然言語から CI/CD パイプラインを設計・デプロイできる CI/CD Extension が発表されました。Gemini CLI と Claude Code の両方で動き、しかもオープンソース、という内容です。

登壇者は Engineering Manager の Haroon Choudhry さんと、Technical Lead の Yashwanth Ganashakran さんでした。

こんな方におすすめ

  • Google Cloud で CI/CD（Cloud Build / Cloud Deploy）を構築しているエンジニア
  • Gemini CLI / Claude Code をコーディング以外でも活用したい方
  • IAM・サービスアカウント・Developer Connect の手作業設定に疲れている方

「コードは AI、デプロイは手作業」のギャップ

冒頭、Haroon さんから DORA レポートの数字が共有されました。

  • 開発者の 90% が日常的に AI を使用
  • それでも、59% の開発者がデプロイで問題に直面
  • CI/CD で AI を使えている組織は 27% にとどまる

AI 利用率 90% に対して、デプロイで 59% がつまずく現状のスライド

CI/CD パイプラインの設計は単なるスクリプト生成ではなく、断片化された複雑なエコシステムをナビゲートする作業だから、というのが Haroon さんの説明でした。Cloud Build YAML を書きながら IAM を整え、Developer Connect を繋ぎ直すフローを手で組むことが多い現場感とも一致します。

CI/CD Extension の中身

Extension は4つのコンポーネントで構成されています。

コンポーネント 役割
Skills デプロイ・パイプライン設計・リリースオーケストレーション・Terraform の定義済みワークフロー
ローカル MCP サーバー ユーザー認証情報で動き、Google Cloud CI/CD ツールを操作する窓口
ローカルナレッジベース CI/CD ベストプラクティス・デプロイパターン・公式ドキュメントをパッケージ化
Evals リリースごとに OSS / 自社プロジェクトで包括的な評価を実施

ハーネスアグノスティックな設計で、「これはオープンソースです」と紹介された瞬間、会場から拍手が起こりました。

Google CI/CD Extension の発表スライド

3つのデモが見せたもの

Yashwanth さんが3つのデモを通しで進められました。要点を表にまとめます。

デモ エージェント プロンプト 自動でやってくれたこと
1. Cloud Run デプロイ Claude Code 「Deploy this application」 アプリ判別（Python Flask）→ Buildpacks 提案 → シークレットスキャン → リージョン/可視性確認 → デプロイ
2. マルチステージ設計 Gemini CLI 「マルチステージ + 自動ロールバックのパイプラインを設計」 Plan 生成 → Dockerfile / staging.yaml / production.yaml / cloudbuild.yaml 生成 → require_approval: true → ロールバックルール → Artifact Registry / 最小権限サービスアカウント / Developer Connect 既存接続再利用 / push-to-main トリガー
3. Terraform 化 Gemini CLI デモ2と同じ + 「Generate Terraform」 Terraform スキル追加 → main.tf に YAML 版と同じガバナンスを反映

特に印象に残ったのは、デモ2で Gemini が 「コンサルタント役 → 実装役」の二段階で動いたことでした。目的・主要ファイル・実装ステップが書かれた Plan を生成して承認を求めるフェーズがあり、計画段階で人が介入できる作りです。

Gemini が生成した計画書（Objective / Key Files & Context / Implementation Steps）

「ブラインドな本番デプロイをするのではなく、ガバナンスゲートを理解して、それを自動化する」

という Haroon さんのコメントが、Extension の設計思想を端的に表していました。

エンタープライズが直面する3つの壁

Haroon さんによる現状整理も実装者として頷くものでした。

  • ツールチェーンの断片化: 32% の組織が複数 CI/CD プラットフォームを併用、41% が DevSecOps 統合に苦戦
  • 接続の煩雑さ: IaC を本番に繋ぐプロセスが手作業で、汎用 AI エージェント利用時のデプロイは 5回中3回が失敗
  • セキュリティ: 過去1年でシークレット漏洩が 34% 増加、IAM 過剰付与やゲートのバイパスも起きがち

Securing the Pipeline — 34% YoY increase in exposed secrets のスライド

AI コード生成量が増えれば、レビューが追いつかずに通るケースも増えます。AI エージェントはコードジェネレーターからインテグレーションオーケストレーターにシフトすべき、というのが Haroon さんの主張でした。

An Agentic Approach to CI/CD — Orchestrator / Code vs. Cloud / Supervised Drafter のスライド

まとめ

CI/CD Extension は、コーディングエージェントの守備範囲を「コード生成」から「本番デプロイの一連のフロー」に広げる拡張機能でした。Gemini CLI / Claude Code の両方で動き、オープンソースで公開されています。

Gemini が生成した最終サマリ（Pipeline Architecture / Key Files Created / Configured Resources）

印象に残ったのは、ガバナンス・IAM・シークレットスキャンといった「ちゃんとやろうとすると面倒くさい部分」が、Extension の中にデフォルトで畳み込まれているところでした。require_approval: true を本番に設定する、ロールバックルールを書く、最小権限のサービスアカウントを切る、Developer Connect の既存接続を再利用する、といった設計判断が、エージェントの内部知識として持ち込まれている形です。

「自分のチームに展開するときにこの Extension を入れておけば、ジュニアメンバーが書いた YAML でもセキュアな最低ラインは守れる」という使い方がイメージしやすいと感じました。クライアント案件で Google Cloud への CI/CD 導入を提案する際も、最初の素案をエージェントに作らせてレビュー・調整するワークフローが現実的に成立しそうです。

「コードはエージェントが書く、デプロイは人がやる」から「設計・実装・デプロイのすべてをエージェントとの会話で進める」フェーズへ。その最初の一歩がオープンソースで踏み出された、というのが個人的な受け止めでした。

参考リンク