コンテンツに移動
デベロッパー

Gemini CLI DevOps 拡張機能を使用して、わずか数分でコードをリリース

2026年5月19日
https://storage.googleapis.com/gweb-cloudblog-publish/images/gemini_cli_devops_final.max-2500x2500.jpg
Karl Weinmeister

Director, Developer Relations

※この投稿は米国時間 2026 年 5 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

Antigravity や Claude Code のような AI コーディング ツールを使うと、実用的なウェブアプリを記録的な速さで構築できます。しかし、デプロイとなると話は別です。これまでの私なら、Dockerfile、IAM バインディング、YAML の設定に午後の残りの時間をすべて費やしていたでしょう。結局は、多くの開発者と同じ近道、つまり、デプロイしないことを選択したはずです。アプリは私のノートパソコンに残り続け、私の仕事がリリースされることはないでしょう。

これは、インナーループ(コードの記述やテストといった高速なローカル サイクル)とアウターループ(コンテナ化、CI / CD パイプライン、本番環境インフラストラクチャ)の間にある典型的な緊張関係です。ほとんどの開発者はどちらか一方では生産性を発揮しますが、もう一方では発揮できません。このギャップがプロジェクトの停滞につながります。

CI / CD 用の Gemini CLI 拡張機能は、このギャップを埋めます。単一のターミナル インターフェースから、迅速なデプロイと完全なパイプライン生成の両方を処理できます。その方法をご紹介しましょう。

Cosmic Guestbook アプリを構築する

このワークフローを実演するには、アプリが必要です。空のディレクトリから開始して、エージェントを使用し、Cosmic Guestbook というまったく新しいプロジェクトを「バイブ コーディング」しましょう。

フルスタック アーキテクチャ(React フロントエンドと Node.js Express バックエンド API)を構築します。これを手動でスキャフォールディングする代わりに、アプリをすぐに作成するようエージェントに依頼します。

読み込んでいます...

エージェントはすぐに、server.js を含む backend/ ディレクトリと、完全にスタイル設定された React アプリを含む frontend/ ディレクトリをスキャフォールディングします。これで、ノートパソコン上で動作する 2 層構造のウェブアプリが完成しました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/guest_book.max-2200x2200.png

拡張機能をインストールする

しかし、ノートパソコン上のコードはリリースされません。このゲストブックをオンラインにするには、選択した環境に CI / CD 拡張機能を導入する必要があります。どのような設定であっても、まず gcloud CLI がインストールされていることを確認し、アプリケーションのデフォルト認証情報を使用して認証します(gcloud auth application-default login)。

次に、使用する開発環境に拡張機能をインストールします。

Gemini CLI の場合

ターミナルで次のコマンドを直接実行します。

読み込んでいます...

Claude Code の場合

マーケットプレイスを追加し、ターミナルからプラグインを直接インストールします。

読み込んでいます...

Antigravity、および npx skills でサポートされているエージェントの場合

拡張機能の MCP サーバーをカスタム MCP として有効にし、スキルをワークスペースに追加します。

読み込んでいます...

仕組み

CI / CD 拡張機能は、これらすべてのエージェント環境で、インテントを安全かつプロダクション レディなインフラストラクチャに変換するよう設計された、強力な 3 層構造システムです。

  1. スキル: google-cicd-deploygoogle-cicd-pipeline-design などの専門的な AI スキルが拡張機能内で定義されています。これらは、AI エージェント(Gemini CLI、Claude Code、Antigravity)に思考方法を指示し、コードの分析、適切な質問、適切なエラー処理を支援します。

  2. CI / CD MCP サーバー: バックグラウンドでは、Go ベースの専用 Model Context Protocol(MCP)サーバーが実行されています。このサーバーは、シークレットのスキャンから Cloud Run サービスのプロビジョニングまで、エージェントが Google Cloud を実際に操作するために必要な一連のツールを提供します。

  3. ローカル ナレッジベース: 最も正確な回答ができるよう、システムには、検証済みのアーキテクチャ パターンを格納した、事前インデックス化済みの検索拡張生成(RAG)データベースが含まれています。これにより、エージェントは信頼できる情報源に基づいて設計上の判断を下すことができます。

選択した AI アシスタントが、これらのツールとパターンをオーケストレートし、一貫性のあるデプロイ ライフサイクルを実現します。

インナーループ

プロトタイプを構築したり、新機能をテストしたりする場合、大規模なマルチ環境 CI / CD パイプラインは必要ありません。必要なのは、Webhook をテストしたり、関係者にデモを見せたりするための公開 URL だけです。これがインナーループです。インナーループは高速である必要があります。

従来のアプローチでは、Dockerfile を手動で記述し、コンテナ レジストリを使って認証を行い、イメージをビルドして push し、最後にデプロイします。CI / CD 拡張機能を使用すると、これが単一の自然言語プロンプト(gemini "Deploy this application to Google Cloud using the google-cicd-deploy skill"(google-cicd-deploy スキルを使用して、このアプリケーションを Google Cloud にデプロイして))に変わります。Claude Code を使用している場合は、claude -p "Deploy this application..." を使用してまったく同じようにプロンプトを入力できます。Antigravity では、デプロイ リクエストを入力するだけです。

このプロンプトを実行すると、AI エージェントがローカルのワークスペースを分析して、最適なデプロイ方法を判断します。

ステップ 1: デプロイ前のセキュリティ スキャン

シークレットの漏洩は、ソフトウェアにおいて最も一般的でコストのかかるセキュリティ障害の一つです。GitGuardian の The State of Secrets Sprawl 2025 レポートによると、1 年間で 2,380 万件の新しい認証情報が公開 GitHub 上にさらされ、2022 年に漏洩したシークレットの 70% が現在もなお有効であることが判明しています。ローカルテスト中にハードコードしたデータベース パスワードを削除し忘れたまま push してしまうなど、このような事態はあっという間に生じます。

この拡張機能は、問題になる前にこれを検出します。コードがマシンから送信される前に、ワークスペース全体に対してシークレット チェックが実行されます。ソース内に Stripe API キーやデータベース認証情報が見つかった場合、エージェントはデプロイを停止して警告を表示します。シークレットが誤ってクラウドに送信されることはありません。

ローカルホストで開発中にデータベース パスワードや Stripe API キーを誤って commit してしまっても、アシスタントがそれを検知してデプロイを阻止します。これこそが、実際の真のシフトレフト セキュリティです。

ステップ 2: アプリケーションの分析とコンテナ化

次に、エージェントは package.json または go.mod をチェックして、使用しているフレームワークを判別し、Google Cloud Storage(静的サイトの場合)と Cloud Run(動的サービスの場合)のどちらを使用するかを自動的に決定します。

Dockerfile がない動的サービスを構築する場合、拡張機能は Google Cloud の Buildpack を利用して、その場でコンテナ化します。

ステップ 3: 明確化とデプロイ

会話エージェントは、求められているアプリの構成をやみくもに推測するわけではありません。Google Cloud 環境に変更を加える前に、アシスタントはフローを一時停止し、分析中に判明した内容に基づいて優先順位付けの質問をします。

Cosmic Guestbook では、サービスを公開するかどうかやリージョンを指定しませんでした。アシスタントは一時停止し、その点について尋ねてきました。

「分析を完了し、Cloud Run への統合デプロイに向けてアプリケーションの準備を整えました。Node.js Buildpack では単一のエントリ ポイントが必要であるため、React フロントエンドを構築し、Express バックエンドがそれを静的に提供できるようにするカスタム ビルド スクリプトを含むルート package.json を作成しました。

また、シークレット スキャンも正常に完了しました。機密性の高い認証情報は検出されませんでした。

Cloud Run のソース デプロイ オプション(Buildpack)を使用してデプロイする前に、デプロイ パラメータをいくつか明確にする必要があります。

  1. リージョン / ロケーション: gcloud のデフォルト設定ではロケーションが指定されません。どの Google Cloud リージョン(例: us-central1europe-west1)にデプロイしますか?

  2. アクセス: このアプリケーションは一般公開しますか、それとも非公開にしますか?

  3. サービス名: cosmic-guestbook というサービス名にすることを提案します。いかがでしょうか?」

このように会話が一時停止することで、高速なインナーループであっても、クラウド アーキテクチャを完全に制御し続けることができます。詳細を確認した後、エージェントはコードをライブ環境に push し、公開 URL を返します。

読み込んでいます...

バックグラウンドでは、デプロイは cloudrun.deploy_to_cloud_run_from_source を使用して自動的に処理されます。

アウターループ

火曜日の午後にプロトタイプを作成するなら、おおざっぱなデプロイ プロンプトで十分ですが、ノートパソコンから本番環境システムを運用することはできません。最終的には、自動テスト、ソース管理の統合、正式な継続的デプロイといったアウターループの厳格さが必要となります。

cloudbuild.yaml ファイルの作成や、必要なインフラストラクチャ(Artifact Registry リポジトリや Developer Connect を介した GitHub 接続など)のプロビジョニングは、非常に面倒でエラーが発生しやすい作業として知られています。google-cicd-pipeline-design スキルを使用すると、AI エージェントがパーソナル プラットフォーム エンジニアリング コンサルタントとして機能します。

YAML をゼロから記述する代わりに、会話をします。エージェントは、テスト戦略とデプロイ先について質問し、必要な Google Cloud インフラストラクチャを自律的にプロビジョニングします。

ステップ 1: アーキテクチャの設計とフィードバック

このプロセスは、会話型インターフェースで直接開始します。

読み込んでいます...

アシスタントはブラック ボックスの中で動作しているわけではありません。ナレッジベースから一般的な CI / CD パターンを取得し、最も関連性の高いナレッジに基づいて、確認用の具体的なプランを YAML で提案します。

ステップ 2: インフラストラクチャのプロビジョニング

プランを承認すると、アシスタントは必要なインフラストラクチャの手順を順番に実行します。たとえば、まずコンテナのレジストリを作成します。

読み込んでいます...

その後、Cloud Build がソースコードを読み取れるよう、Git 接続を設定する場合もあります。

ステップ 3: パイプラインの生成とトリガー

最後に、エージェントはパイプライン ステージ(テスト、構築、デプロイ)を定義する実際の cloudbuild.yaml ファイルを生成します。以下は、リポジトリから生成された構成のスニペットです。初期ビルドステップが強調表示されています。

読み込んでいます...

パイプラインを定義したら、それを自動的に実行する方法が必要です。エージェントは、Cloud Build トリガーを作成して処理を終えます。このトリガーは GitHub リポジトリと Cloud Build を結び付ける役割を果たし、main ブランチへの push が行われるたびに cloudbuild.yaml のステップが自動的に実行されるようにします。

読み込んでいます...

セキュリティと管理

AI を活用したインフラストラクチャ生成は素晴らしいことに思えますが、安全かどうか疑問に思うのはしごく当然です。

この拡張機能は、ローカル アプリケーションのデフォルト認証情報(ADC)の権限の範囲内で厳密に動作します。ユーザーができないことは、エージェントもできません。Model Context Protocol(MCP)を使用しているため、Artifact Registry の作成から Cloud Build トリガーの変更まで、エージェントが行うすべてのアクションは、厳密に型指定された検証可能なツールを介して実行されます。

提案されたパイプラインのステップが気に入らない場合は、エージェントに変更を指示します。インフラストラクチャの「編集長」は常にあなたです。ローカルの ADC と、生成されたパイプラインで使用するサービス アカウントの両方で、最小権限の原則を遵守することを強くおすすめします。

開発と運用の融合

コードを書きたいという思いとコードをリリースしなければならないという現実の間の葛藤が、ついに解消されつつあります。アプリをインターネット上に公開するには、YAML 形式に関する深い専門知識が不可欠だった時代は過ぎ去りました。

会話型 AI は、おおざっぱなインナーループと自動化されたアウターループの両方のボイラープレートを処理することで、開発者が本当に重要なビジネス ロジックに集中できるようにします。

次のステップ

この融合を実際に体験してみたい方は、以下の手順に沿って進めてください。

  1. ツールを入手する: Gemini CLI 用の CI / CD 拡張機能をインストールします。

  2. インナーループをデプロイする: 既存のサイド プロジェクトを使用(または、選択したエージェントに Cosmic Guestbook のような新しいプロジェクトのスキャフォールディングを依頼)し、Google Cloud にデプロイするようプロンプトを入力すると、Cloud Run または Cloud Storage で即座に動作を確認できます。

  3. アウターループを自動化する: 本番環境に移行する準備ができているリポジトリに対して設計コマンドを実行し、エージェントが cloudbuild.yaml を生成してインフラストラクチャをプロビジョニングする様子を確認します。

構成ファイルとの格闘はやめて、リリースを始めましょう。皆様が何を構築したのか、LinkedInXBluesky でぜひ教えてください。

- デベロッパーリレーションズ担当ディレクター、Karl Weinmeister

投稿先