Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

MCP を使用して Gemini Cloud Assist をサードパーティ製ツールと統合する

Model Context Protocol（MCP）を使用すると、Gemini Cloud Assist と App Design Center のエージェント機能を Antigravity、Gemini CLI、Cursor などのサードパーティツールに直接統合できます。この統合により、クラウドオペレーションの専門知識とアーキテクチャの支援が既存の開発ワークフローに組み込まれます。詳細については、AI アプリケーション用に MCP を構成するをご覧ください。

Gemini Cloud Assist MCP ツール

Gemini Cloud Assist は、エージェントをツールとして使用するパターンを使用して、一連の MCP ツールからアクセスできるエージェントです。データを取得したり、手続き型処理を行うツールとは異なり、Gemini Cloud Assist ツールは、Gemini Cloud Assist 全体または特定のワークフローの Agentic 機能を公開します。MCP ツール呼び出しによって呼び出されたエージェントは、内部でGoogle Cloudへの独自のツール呼び出しを行います。エージェントが使用できるように、次の MCP ツールが公開されています。

ask_cloud_assist: Google Cloudアシスタンスと Gemini Cloud Assist エージェントのプライマリインターフェースです。Gemini Cloud Assist のすべての機能にこのツールからアクセスできます。また、他の MCP ツールの機能も含まれています。
design_infra: Google Cloudでインフラストラクチャを設計および構築するためのワークフローをサポートします。App Design Center MCP サーバーツールと連携して、インフラストラクチャ設計のライフサイクルを管理します（セキュリティ結果の実行と修復、問題のデプロイと修復など）。
investigate_issue:Google Cloudでのトラブルシューティングのワークフローをサポートします。調査リソースを使用して、迅速なトラブルシューティングや詳細なトラブルシューティングを行うことができます。
invoke_operation: Google Cloudでリソースの作成、更新、削除を行うワークフローをサポートします。このツールは、エージェントアクションが有効になっている場合にのみ機能します。Gemini Cloud Assist の書き込みオペレーションは、このツールの呼び出しによってのみ実行できます。
optimize_costs: Google Cloud 費用の分析、追跡、最適化のワークフローをサポートします。費用の詳細な内訳を提供し、アイドル状態または使用率の低いリソースを特定して、費用対効果を高める機会を特定します。

App Design Center MCP ツール

これらのツールは、多くの場合 Gemini Cloud Assist の design_infra ツールによってオーケストレートされ、App Design Center を使用してインフラストラクチャアプリケーションのライフサイクル（テンプレート管理、セキュリティコンプライアンスと修復、デプロイなど）を管理します。ツールは次のとおりです。

setup_adc: App Design Center 環境を初期化します。これは、他の App Design Center ツールを使用する前に実行する必要がある 1 回限りの設定手順です。
manage_application: アプリケーションのデプロイライフサイクルを管理します。このツールを使用して、App Design Center を使用して検証済みの設計をデプロイしたり、既存のデプロイのステータスと詳細を取得したりします。これは、設計を Google Cloudにデプロイされたインフラストラクチャに変換する最終ステップです。
manage_application_template: インフラストラクチャ設計の Infrastructure as Code（IaC）コンテンツを管理します。これを使用して、設計を App Design Center テンプレートとして保存したり、設計を Terraform ファイルとしてエクスポートしたり、設計を更新したりします。たとえば、このツールを使用して、コンポーネントの設定とパラメータ構成を変更することで、設計を更新できます。
assess_best_practices: アプリケーション設計の包括的なセキュリティと構成の監査をデプロイ前に実行します。Security Command Center のフレームワークと関連する制御に対して設計を検証し、修正のための実行可能な検出結果を含むレポートを返します。
list_application_templates: 利用可能なすべてのアプリケーションデザインをリストします。

これらの MCP ツールは、安定した API として扱ったり、手続き型 API クライアントを介して構成したりしないでください。このリストのツールまたはそのパラメータは、Gemini Cloud Assist の機能の進化に合わせて、名前の変更、再定義、削除、追加が行われる可能性があります。Gemini Cloud Assist の機能は安定した状態を維持し、クライアントエージェントは同じタスクを一貫して実行できますが、エージェントがこれらのツールを介して Gemini Cloud Assist とやり取りし、呼び出す方法は時間の経過とともに変化します。

始める前に

アクセス権を付与する: MCP を使用するには、次の Gemini Cloud Assist ロールのいずれかなど、mcp.googleapis.com/tools.call 権限を含む Identity and Access Management ロールが付与されている必要があります。
- roles/geminicloudassist.user
- roles/geminicloudassist.editor
- roles/geminicloudassist.admin
まだ行っていない場合は、gcloud CLI とそのベータ版コンポーネントをインストールします。
次のコマンドを使用して、プロジェクトで MCP サービスを有効にします。
```
gcloud beta services mcp enable geminicloudassist.googleapis.com \
    --project=PROJECT_ID
```
PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。
次のコマンドを実行して、アプリケーションのデフォルト認証情報を使用して認証します。
```
gcloud auth application-default login
```

クライアントの MCP を構成する

クライアントエージェントの構成は、使用しているエージェントによって異なります。以降のセクションでは、さまざまなクライアント用に MCP を構成する手順について説明します。

設計からデプロイまでのワークフロー全体を有効にするには、Gemini Cloud Assist と App Design Center の両方の MCP サーバーに接続するようにクライアントを構成し、関連する SKILL.md ファイルを含める必要があります。次のスニペットは、結合された構成を示しています。

Antigravity

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを Antigravity に追加するには、Antigravity エディタ: MCP 統合の手順に沿って操作するか、次の手順を完了します。

拡張機能をインストールします。

Antigravity で、拡張機能 Marketplace を開きます。Gemini Cloud Assist 拡張機能を検索し、[インストール] をクリックして、[更新] をクリックします。

MCP サーバーを手動で構成します。

[Manage MCP Servers] ペインを開き、[View raw config] をクリックして mcp_config.json ファイルを編集します。次の構成ブロックを追加または統合します。この設定では、認証にアプリケーションのデフォルト認証情報が使用されます。

{
  "mcpServers": {
    "gemini_cloud_assist": {
      "serverUrl": "https://geminicloudassist.googleapis.com/mcp",
      "headers": {},
      "authProviderType": "google_credentials"
    },
    "application_design_center": {
      "serverUrl": "https://designcenter.googleapis.com/mcp",
      "headers": {},
      "authProviderType": "google_credentials"
    }
  }
}

設定を確認します。

mcp_config.json ファイルと SKILL.md ファイルを変更したら、Antigravity を再起動します。[エージェント] ペインで、次のスラッシュコマンドを実行して接続を確認します。
- /skills list: ローカルスキルが検出されたことを確認します。
- /mcp list: Gemini Cloud Assist と App Design Center の MCP サーバーが接続されていることを確認します。

ChatGPT

ChatGPT で Google と Google Cloud MCP サーバーを使用するには、ChatGPT Business サブスクリプションが必要です。

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを ChatGPT に追加するには、OAuth 2.0 クライアント ID とクライアントシークレットを作成し、ChatGPT に MCP サーバーをプラグインとして追加します。

OAuth 2.0 クライアント ID とクライアントシークレットを作成します。
1. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。
  
  [クライアントの作成] に移動
  
  プロジェクトが選択されていない場合は、プロジェクトを作成するよう求められます。
2. [アプリケーションの種類] リストで、[ウェブアプリケーション] をクリックします。
3. [名前] フィールドに、アプリケーションの名前を入力します。
4. [承認済みの JavaScript 生成元] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://chatgpt.com と入力します。
5. [承認済みのリダイレクト URI] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://chatgpt.com/connector_platform_oauth_redirect と入力します。
6. [作成] をクリックします。クライアントが作成されます。
  
  [OAuth 2.0 クライアントが作成されました] ダイアログが開きます。
7. [クライアントシークレット] セクションで、クライアントシークレットをコピーして、安全な場所に保存します。コピーできるのは 1 回のみです。紛失した場合は、シークレットを削除して新しいシークレットを作成します。
  
  注意: クライアントシークレットはパスワードと同様に扱い、安全な場所に保管してください。
デベロッパーモードをオンにして ChatGPT にログインします。
プラグインをビルドするの手順に沿って、各 MCP サーバーにカスタムコネクタを追加します。
- Gemini Cloud Assist の場合、サーバー URL を https://geminicloudassist.googleapis.com/mcp に設定します。
- App Design Center の場合は、サーバー URL を https://designcenter.googleapis.com/mcp に設定します。
[OAuth] または [詳細設定] で、OAuth クライアント ID とクライアントシークレットを入力します。
ログインプロンプトを完了して、チャットで MCP サーバーを有効にします。

Claude.ai

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを Claude.ai に追加するには、OAuth 2.0 クライアント ID とクライアントシークレットを使用してカスタムコネクタを構成します。

OAuth 2.0 クライアント ID とクライアントシークレットを作成します。
1. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。
  
  [クライアントの作成] に移動
  
  プロジェクトが選択されていない場合は、プロジェクトを作成するよう求められます。
2. [アプリケーションの種類] リストで、[ウェブアプリケーション] をクリックします。
3. [名前] フィールドに、アプリケーションの名前を入力します。
4. [承認済みの JavaScript 生成元] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://claude.ai と入力します。
5. [承認済みのリダイレクト URI] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://claude.ai/api/mcp/auth_callback と入力します。
6. [作成] をクリックします。クライアントが作成されます。
  
  [OAuth 2.0 クライアントが作成されました] ダイアログが開きます。
7. [クライアントシークレット] セクションで、クライアントシークレットをコピーして、安全な場所に保存します。コピーできるのは 1 回のみです。紛失した場合は、シークレットを削除して新しいシークレットを作成します。
  
  注意: クライアントシークレットはパスワードと同様に扱い、安全な場所に保管してください。
手順に沿って、各 MCP サーバーのカスタムコネクタを作成します。
- Gemini Cloud Assist の場合、サーバー URL を https://geminicloudassist.googleapis.com/mcp に設定します。
- App Design Center の場合は、サーバー URL を https://designcenter.googleapis.com/mcp に設定します。
[詳細設定] メニューで、OAuth クライアント ID とクライアントシークレットを入力します。
ログインプロンプトを完了して、チャットで MCP サーバーを有効にします。

Claude Code

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを Claude Code に追加するには、OAuth 2.0 クライアント ID とクライアントシークレットを使用してカスタムコネクタを構成します。

Claude Code をインストールします。
OAuth 2.0 クライアント ID とクライアントシークレットを作成します。
1. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。
  
  [クライアントの作成] に移動
  
  プロジェクトが選択されていない場合は、プロジェクトを作成するよう求められます。
2. [アプリケーションの種類] リストで、[ウェブアプリケーション] をクリックします。
3. [名前] フィールドに、アプリケーションの名前を入力します。
4. [承認済みのリダイレクト URI] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://claude.ai/api/mcp/auth_callback と入力します。
5. [作成] をクリックします。クライアントが作成されます。
  
  [OAuth 2.0 クライアントが作成されました] ダイアログが開きます。
6. [クライアントシークレット] セクションで、クライアントシークレットをコピーして、安全な場所に保存します。コピーできるのは 1 回のみです。紛失した場合は、シークレットを削除して新しいシークレットを作成します。
  
  注意: クライアントシークレットはパスワードと同様に扱い、安全な場所に保管してください。
手順に沿って、各 MCP サーバーのカスタムコネクタを作成します。
- Gemini Cloud Assist の場合、サーバー URL を https://geminicloudassist.googleapis.com/mcp に設定します。
- App Design Center の場合は、サーバー URL を https://designcenter.googleapis.com/mcp に設定します。
[詳細設定] メニューで、OAuth クライアント ID とクライアントシークレットを入力します。
ログインプロンプトを完了して、チャットで MCP サーバーを有効にします。

Claude Desktop

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを Claude Desktop に追加するには、OAuth 2.0 クライアント ID とクライアントシークレットを使用してカスタムコネクタを構成します。

Claude Desktop をインストールします。
OAuth 2.0 クライアント ID とクライアントシークレットを作成します。
1. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。
  
  [クライアントの作成] に移動
  
  プロジェクトが選択されていない場合は、プロジェクトを作成するよう求められます。
2. [アプリケーションの種類] リストで、[ウェブアプリケーション] をクリックします。
3. [名前] フィールドに、アプリケーションの名前を入力します。
4. [承認済みのリダイレクト URI] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://claude.ai/api/mcp/auth_callback と入力します。
5. [作成] をクリックします。クライアントが作成されます。
  
  [OAuth 2.0 クライアントが作成されました] ダイアログが開きます。
6. [クライアントシークレット] セクションで、クライアントシークレットをコピーして、安全な場所に保存します。コピーできるのは 1 回のみです。紛失した場合は、シークレットを削除して新しいシークレットを作成します。
  
  注意: クライアントシークレットはパスワードと同様に扱い、安全な場所に保管してください。
手順に沿って、各 MCP サーバーのカスタムコネクタを作成します。
- Gemini Cloud Assist の場合、サーバー URL を https://geminicloudassist.googleapis.com/mcp に設定します。
- App Design Center の場合は、サーバー URL を https://designcenter.googleapis.com/mcp に設定します。
[詳細設定] メニューで、OAuth クライアント ID とクライアントシークレットを入力します。
ログインプロンプトを完了して、チャットで MCP サーバーを有効にします。

Codex

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを Codex Enterprise に追加する手順は次のとおりです。

Codex Enterprise UI で、[設定] を開き、[MCP サーバー] を選択して、[未加工の構成を表示] をクリックして mcp_config.json エディタを開きます。

次の構成ブロックを mcp_config.json ファイルに追加または統合します。この設定では、認証にアプリケーションのデフォルト認証情報が使用されます。

{
  "mcpServers": {
    "gemini_cloud_assist": {
      "serverUrl": "https://geminicloudassist.googleapis.com/mcp",
      "headers": {},
      "authProviderType": "google_credentials"
    },
    "application_design_center": {
      "serverUrl": "https://designcenter.googleapis.com/mcp",
      "headers": {},
      "authProviderType": "google_credentials"
    }
  }
}

Cursor

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを Cursor に追加するには、OAuth 2.0 クライアント ID とクライアントシークレットを作成し、静的 OAuth を使用して MCP サーバーを構成します。Cursor は、ウェブ経由でアクセスするか、デスクトップアプリ経由でアクセスするかによって、異なるリダイレクト URI を使用します。

OAuth 2.0 クライアント ID とクライアントシークレットを作成します。
ウェブエージェントまたはカーソルエージェント
1. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。
  
  [クライアントの作成] に移動
  
  プロジェクトが選択されていない場合は、プロジェクトを作成するよう求められます。
2. [アプリケーションの種類] リストで、[ウェブアプリケーション] をクリックします。
3. [名前] フィールドに、アプリケーションの名前を入力します。
4. [承認済みのリダイレクト URI] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://www.cursor.com/agents/mcp/oauth/callback と入力します。
5. [作成] をクリックします。クライアントが作成されます。
  
  [OAuth 2.0 クライアントが作成されました] ダイアログが開きます。
6. [クライアントシークレット] セクションで、クライアントシークレットをコピーして、安全な場所に保存します。コピーできるのは 1 回のみです。紛失した場合は、シークレットを削除して新しいシークレットを作成します。
  
  注意: クライアントシークレットはパスワードと同様に扱い、安全な場所に保管してください。
パソコン
1. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。
  
  [クライアントの作成] に移動
  
  プロジェクトが選択されていない場合は、プロジェクトを作成するよう求められます。
2. [アプリケーションの種類] リストで、[ウェブアプリケーション] をクリックします。
3. [名前] フィールドに、アプリケーションの名前を入力します。
4. [承認済みのリダイレクト URI] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに http://localhost:8787/callback と入力します。
5. [作成] をクリックします。クライアントが作成されます。
  
  [OAuth 2.0 クライアントが作成されました] ダイアログが開きます。
6. [クライアントシークレット] セクションで、クライアントシークレットをコピーして、安全な場所に保存します。コピーできるのは 1 回のみです。紛失した場合は、シークレットを削除して新しいシークレットを作成します。
  
  注意: クライアントシークレットはパスワードと同様に扱い、安全な場所に保管してください。

手順に沿って、静的 OAuth で MCP サーバーを構成し、次の構成ブロックを Cursor MCP 構成に追加または統合します。

{
  "mcpServers": {
    "gemini_cloud_assist": {
      "url": "https://geminicloudassist.googleapis.com/mcp",
      "auth": {
        "CLIENT_ID": "${env:OAUTH_CLIENT_ID}",
        "CLIENT_SECRET": "${env:OAUTH_CLIENT_SECRET}",
        "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
      }
    },
    "application_design_center": {
      "url": "https://designcenter.googleapis.com/mcp",
      "auth": {
        "CLIENT_ID": "${env:OAUTH_CLIENT_ID}",
        "CLIENT_SECRET": "${env:OAUTH_CLIENT_SECRET}",
        "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
      }
    }
  }
}

環境で OAUTH_CLIENT_ID と OAUTH_CLIENT_SECRET の環境変数を設定します。
Chat で MCP サーバーを使用する。

Gemini CLI

拡張機能を使用して構成する

次のコマンドを使用して、MCP サーバーを Gemini CLI 拡張機能としてインストールします。

gemini extensions install https://github.com/GoogleCloudPlatform/gemini-cloud-assist-mcp

手動で構成する

MCP サーバーの設定を構成します。

~/.gemini/settings.json で Gemini CLI ユーザースコープ設定ファイルを開くか、.gemini/settings.json でワークスペーススコープ設定を開きます。ファイルが存在しない場合は作成します。mcpServers キーの下に次の構成ブロックを追加または統合します。ファイルが有効な JSON 形式を使用していることを確認します。この構成では、アプリケーションのデフォルト認証情報が自動的に使用されます。

{
  "mcpServers": {
    "gemini_cloud_assist": {
      "httpUrl": "https://geminicloudassist.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
      },
      "timeout": 600000
    },
    "application_design_center": {
      "httpUrl": "https://designcenter.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
      },
      "timeout": 600000
    }
  }
}

スキルファイルを作成してデータを入力します。

次のいずれかのディレクトリに SKILL.md ファイルを作成します。このドキュメントのスキルリファレンスセクションから、選択したスキルの Markdown コンテンツをコピーしてファイルに貼り付けます。
- ワークスペースのスコープ: .gemini/skills/SKILL_NAME/
- ユーザースコープ: ~/.gemini/skills/SKILL_NAME/
SKILL_NAME は、スキルのディレクトリ名に置き換えます。

ディレクトリ構造の例を次に示します。
```
.gemini/
└── skills/
    ├── design-and-deploy/
    │   └── SKILL.md
    └── google-gemini-cloud-assist/
        └── SKILL.md
              
```
スキルを証明する。

settings.json ファイルと SKILL.md ファイルを変更したら、Gemini CLI を再起動し、次のコマンドを実行して設定を確認します。
- /skills list: ローカルスキルが検出されたことを確認します。
- /mcp list: Gemini Cloud Assist と App Design Center の MCP サーバーが接続されていることを確認します。

Gemini Enterprise

Gemini Cloud Assist と App Design Center のリモート MCP サーバーを Gemini Enterprise に登録するには、管理者が次の手順を完了する必要があります。

Gemini Enterprise リダイレクト URI を使用して OAuth 2.0 クライアント ID とクライアントシークレットを作成します。
1. Google Cloud コンソールで、[Google Auth Platform] > [クライアント] > [クライアントの作成] に移動します。
  
  [クライアントの作成] に移動
  
  プロジェクトが選択されていない場合は、プロジェクトを作成するよう求められます。
2. [アプリケーションの種類] リストで、[ウェブアプリケーション] をクリックします。
3. [名前] フィールドに、アプリケーションの名前を入力します。
4. [承認済みのリダイレクト URI] セクションで、[+ URI を追加] をクリックし、[URI] フィールドに https://vertexaisearch.cloud.google.com/oauth-redirect と入力します。
5. [作成] をクリックします。クライアントが作成されます。
  
  [OAuth 2.0 クライアントが作成されました] ダイアログが開きます。
6. [クライアントシークレット] セクションで、クライアントシークレットをコピーして、安全な場所に保存します。コピーできるのは 1 回のみです。紛失した場合は、シークレットを削除して新しいシークレットを作成します。
  
  注意: クライアントシークレットはパスワードと同様に扱い、安全な場所に保管してください。
Google Cloud コンソールで、[Gemini Enterprise > データストア] に移動し、[データストアを作成] をクリックします。詳細については、カスタム MCP サーバーデータストアを設定するをご覧ください。
データソースとして [カスタム MCP サーバー] を選択します。
エンドポイントごとにカスタム MCP サーバーデータストアを構成します。
- Gemini Cloud Assist の場合は、https://geminicloudassist.googleapis.com/mcp と入力します。
- App Design Center の場合は、https://designcenter.googleapis.com/mcp と入力します。
OAuth のクライアント ID とクライアントシークレットを入力し、データストアを保存します。ツールが Gemini Enterprise エージェントで使用できるようになります。

Gemini Cloud Assist のスキル

Gemini Cloud Assist と App Design Center の MCP ツールは、エージェントスキルを使用してエージェントに指示します。スキルは、次のタスクを実行するようエージェントに指示します。

複数のツールを連結してワークストリームを作成します。
Terraform デプロイコードなどの関連するローカル情報を処理して、ローカルコンテキストについて推論します。
スキルを直接参照する場合は、明示的な呼び出しに応答します。

Antigravity や Gemini CLI などのインタラクティブエージェントを使用する場合は、Gemini Cloud Assist MCP ツールを他のエージェントやワークフローと統合できます。これらのツールは、既存の専門ツールと重複する可能性のある幅広い機能を提供するため、次の戦略を使用して、特定の環境とユースケースに合わせて最適化します。

スキル定義をカスタマイズする: SKILL.md ファイルを更新して、Gemini Cloud Assist を呼び出すインテントとユースケースを指定します。これにより、エージェントは幅広いクラウドの専門知識が必要なタスクでのみトリガーされます。
スキルを明示的に呼び出す: 多くのインタラクティブエージェントでは、スキルがトリガーされるタイミングを制御できます。エージェントがサポートしている場合は、スラッシュコマンド（/）またはメンション（@）を使用して手動で呼び出すようにスキルを構成できます。この方法を使用すると、Gemini Cloud Assist を使用するタイミングと別の専用ツールを使用するタイミングを正確に選択できます。

Gemini Cloud Assist のスキルリファレンス

Gemini Cloud Assist MCP ツールで構成されたエージェントでは、次の SKILL.md ファイルをおすすめします。このファイルは、エージェントがツールを適切に使用する方法をガイドします。

インフラストラクチャの設計とデプロイ

---
name: designing-and-deploying-infrastructure
description: This skill is used to design, assess, deploy, and troubleshoot cloud infrastructure using the Application Design Center (ADC).
---

# Designing and Deploying Infrastructure

## Index
1. [Overview](#overview)
2. [Best Practices & Constraints](#best-practices--constraints)
3. [Phase 1: Infrastructure Design & Refinement](#phase-1-infrastructure-design--refinement)
4. [Phase 2: Best Practices Assessment & Design Iteration](#phase-2-best-practices-assessment--design-iteration)
5. [Phase 3: Application Deployment](#phase-3-application-deployment)
6. [Phase 4: Get Deployed Resources](#phase-4-get-deployed-resources)
7. [Phase 5: Troubleshoot Deployment Failures](#phase-5-troubleshoot-deployment-failures)
8. [Phase 6: Verification & E2E Testing](#phase-6-verification--e2e-testing)

## Overview
This skill provides a prescriptive, multi-loop workflow for the entire infrastructure lifecycle on Google Cloud Platform (GCP). It leverages the Gemini Application Designer (GAD) and Application Design Center (ADC) tools (like `gemini_cloud_assist:design_infra` and `application_design_center:assess_best_practices`) to intelligently design architectures, assess best practices, and automate deployment and troubleshooting.
Always maintain the persona of a Principal Cloud Architect. Delegate all research and design to the specialized tools provided.
**Note:** These tools are part of the `gemini_cloud_assist` and `application_design_center` MCP Servers. Tool names are qualified with their respective server names (e.g., `gemini_cloud_assist:tool_name`).

## Best Practices & Constraints
-   **Delegation & No Manual Design**: Delegate all architecture decisions and product selections to the `gemini_cloud_assist:design_infra` tool. **Do not** design manually or edit generated Terraform code. Request changes via the tool.
-   **Inputs**: Always ask the user for required context like project ID, service accounts, etc. if necessary -- do not make assumptions or use placeholders.
-   **Visualization Power**: Always render the Mermaid diagram from `gemini_cloud_assist:design_infra` in every implementation plan. Refresh the diagram after every design change. Do not create your own diagrams.
-   **Loop Discipline**: Follow the workflow loops and exit criteria strictly. If you cannot follow the Infrastructure Lifecycle Workflow, you must exit and inform the user (for example, if the user cancels the process, or if you hit the maximum troubleshooting loop threshold in Phase 5).
-   **Application Template as the main resource**: The application template is the main resource when generating and iterating on a design. **Always** look for the application template URI in the `gemini_cloud_assist:design_infra` response (`serializedApplicationTemplateURI`), and use that for the rest of the Infrastructure Lifecycle Workflow.
    -   **Application Template vs Application**: Application template is a template that is used to create an application. Application is an instance of an application template. Do not confuse these two.
    -   **Never** attempt to create an application template URI yourself; always use the URI returned from `gemini_cloud_assist:design_infra`.

## Infrastructure Lifecycle Workflow
### Phase 1: Infrastructure Design & Refinement
**Goal**: Transform vague user requirements into a concrete, approved architectural design.
1.  **Requirement Gathering**: Capture user intent if it's vague (e.g., "3-tier web app with high availability").
Guidelines for initial design that **you must follow**:
    - Gather project ID (required) and ADC space ID (optional) from the user.
2.  **Codebase Analysis**: Critically, **before** calling `gemini_cloud_assist:design_infra`, you **must** perform a thorough exhaustive analysis of the user's application codebase (if available). **Do not** stop at high-level documentation or configuration files at the surface level; you **must** inspect the full depth of the codebase, including business logic, to find hidden API clients, dependencies, environment variables, and other application code context required to design cloud infrastructure. The list below outlines critical checks you **must** perform. **Do not** limit your investigation to only these items:
    - If you scan the application code to provide additional context, summarize *only* the application's characteristics (e.g., languages, frameworks, statefulness) and **do not** assume or suggest specific infrastructure components or services (e.g., **do not** choose the product type (e.g. GKE, Cloud Run, etc) or network information unless the user explicitly requested them or they are specified in codebase).
    - **NEVER** rely solely on `grep_search`, `os.environ`, or summary documentation (like READMEs) to determine infrastructure needs. **DO NOT** make premature assumptions or over-optimize for speed. Accuracy is critical; you **must** inspect the entire codebase.
    - Identify required environment variables, secrets, ports exposed in application, and database connection patterns. Environment Variables may also be present in nginx config files. Environment variables are critical for architecture so double check you have identified all of them.
    - Identify all the dependencies on existing GCP services (e.g., Vertex AI API, pre-existing GCS buckets). Along with the rest of the codebase, you **must** read dependency files (e.g., `requirements.txt`, `package.json`, `go.mod`) to identify GCP SDKs used and scan source code for explicit GCP client initializations.
    - Scan the codebase (e.g., `cloudbuild.yaml`, `Dockerfile`, CI/CD configs) to extract container image URLs. If no image is found or if the identified image does not exist in the Artifact Registry, you must build and upload the image. Provide only the resulting URL to `gemini_cloud_assist:design_infra`.
3.  **Initial Design**: Call `gemini_cloud_assist:design_infra` tool with `command="manage_app_design"` and the user's query. Ensure that `project` is `projects/{project_id}`
    - **MANDATORY - PRODUCT AGNOSTICISM**: Do NOT architect the infrastructure prematurely (e.g. "frontend should be a Cloud Run service"), instead delegate this responsibilty entirely to `gemini_cloud_assist:design_infra` tool. The codebase analysis results __may suggest__ certain product types (e.g. database uses the PostgreSQL client library, therefore database may be PostgreSQL), but otherwise make **zero** assumptions about the architecture. Since environment variables are critical to the architecture, you **must** pass the full set discovered during codebase analysis phase in all the design_infra manage_app_design requests.
    - **Prevent Naming Collisions**: Generate a unique, non-sequential five-character alphanumeric suffix, strictly avoiding common patterns like `12345`, `abcde` or `a1b2c`. Instruct `gemini_cloud_assist:design_infra` in the prompt to append this suffix to all newly created components.
4.  **Visualization, Terraform Code and Verification**: The `gemini_cloud_assist:design_infra` will respond with a Mermaid diagram, Terraform code, and the `serializedApplicationTemplateURI`.
    - Retrieve the Terraform code corresponding to each `.tf` file referenced and save them into a dedicated directory called `infra`.
    - You **must** present an Implementation Plan that contains the Mermaid diagram rendered within the Implementation Plan, as well as the location of the Terraform configs.
    - **Verification Step**: This is a critical step. You **must** meticulously verify the generated Terraform code to ensure it includes all the environment variables, secrets, dependencies, and correct container image URLs required by application, identified during the Codebase Analysis step. If *any* required configurations are missing or incorrect, you **must** iterate on the design using `gemini_cloud_assist:design_infra command="manage_app_design"` to correct them. **Do not proceed to deployment with an unverified or incomplete design.**
5.  **Iteration**: Refine the design by feeding user feedback back into `gemini_cloud_assist:design_infra`.
    -   **Design Iteration Constraints**: When iterating on the design, **do not** make manual edits to the Terraform code. **Always** use `gemini_cloud_assist:design_infra` tool exclusively to update the Terraform code.  **Always** keep the local Terraform code in sync with Terraform code returned from `gemini_cloud_assist:design_infra`.
    -   **Visualization Update**: Update the Implementation Plan by re-rendering the Mermaid diagram and updating the Terraform configs.
    -   **Retries**: After encountering transient errors and you need to retry `gemini_cloud_assist:design_infra` calls, you **must make exactly the same call** with **same** arguments.
6.  **Exit Criteria**:
    -   Design fulfills all critical requirements and has resources needed by the application, especially the environment variables for each service.
    -   User confirms the design is satisfactory.
    -   `gemini_cloud_assist:design_infra` reaches a stable state with no further architectural changes.

### Phase 2: Best Practices Assessment & Design Iteration
**Goal**: Validate design alignment with security, cost, and reliability benchmarks prior to deployment.
1. **Execution**: Invoke `assess_best_practices` using the application template metadata (project, location, space and application template identifiers).
2. **Analysis**: You **MUST** present all findings to the user in a pretty tabular fashion per framework, detailing specific violations, and their associated severity levels - before proceeding to remediation.
3. **Remediation Loop**:
    - Pass identified findings as context to `gemini_cloud_assist:design_infra(command="manage_app_design")`.
    - **Strict Constraint**: All modifications must be executed via the `gemini_cloud_assist:design_infra` tool; manual Terraform manipulation is prohibited.
    - Perform a diff-based comparison between current and updated Terraform code for user approval.
    - Re-assess post-update to verify the resolution of findings.
4. **Exit Criteria**:
    - **Optimization**: Zero findings remaining.
    - **Convergence**: `gemini_cloud_assist:design_infra` provides no further suggestions.
    - **Threshold**: Maximum of three (3) iterative attempts reached.
5. **Transition**: Proceed to Phase 3 deployment only upon loop termination.

### Phase 3: Application Deployment
**Goal**: Deploy the application template to the GCP environment.
1.  **Deploy Application**: Use the `application_design_center:manage_application` tool with the `APPLICATION_OPERATION_DEPLOY` operation to deploy the application.
    *   **Required Arguments**: `project`, `location`, `spaceId`, `applicationTemplateUri`, `applicationId`, `serviceAccount`.
    *   **Note**: This returns a Long-Running Operation (LRO). Inform the user that the deployment has started.
    *   **Example**:
        ```json
        {
          "project": "my-project",
          "location": "us-central1",
          "spaceId": "my-space",
          "applicationId": "my-app",
          "operation": "APPLICATION_OPERATION_DEPLOY",
          "applicationTemplateUri": "projects/my-project/locations/us-central1/spaces/my-space/applicationTemplates/my-template",
          "serviceAccount": "projects/my-project/serviceAccounts/deployer@my-project.iam.gserviceaccount.com"
        }
        ```
2.  **Monitor Deployment**: Repeatedly poll the LRO (e.g., every 30-60 seconds) until `done: true`.
3.  **Handle Results**:
    -   **Success**: If `done` is `true` and there is no `error` field, proceed to Phase 4.
    -   **Failure**: If an `error` field is present, proceed to Phase 5.

### Phase 4: Get Deployed Resources
1.  **Retrieve Information**: Call the `application_design_center:manage_application` tool with the `APPLICATION_OPERATION_GET` operation, providing `project`, `location`, `spaceId` and `applicationId`, to fetch the outputs and status of the deployed resources.
    *   **Example**:
        ```json
        {
          "project": "my-project",
          "location": "us-central1",
          "spaceId": "my-space",
          "applicationId": "my-app",
          "operation": "APPLICATION_OPERATION_GET"
        }
        ```
2.  **User Confirmation**: Present the deployed resource information to the user and conclude the task.

### Phase 5: Troubleshoot Deployment Failures
**Goal**: Diagnose and remediate deployment failures iteratively.
When troubleshooting a failed application, follow these steps.
**Process:**
1.  **Initiate Troubleshooting:**
    - **Action:** Call `gemini_cloud_assist:design_infra` with `applicationUri` (format: projects/{project}/locations/{location}/spaces/{spaceId}/applications/{applicationId}) to get suggested fixes.
    - Convert the returned response to JSON. The value of a parameter may be a JSON string that needs to be parsed.
    - **Expected Output Structure from Troubleshooting:**
      ```json
      {
        "summary": "...",
        "troubleshootingSteps": [
          {
            "description": "...",
            "gcloud_commands": ["gcloud ..."],
            "componentParameters": null
          },
          {
            "description": "...",
            "gcloud_commands": null,
            "componentParameters": [
              {
                "componentUri": "projects/.../components/comp-a",
                "parameters": [
                  { "key": "param1", "value": "new_value" },
                  { "key": "param3", "value": "another" }
                ]
              }
            ]
          }
        ]
      }
      ```
2.  **Analyze Troubleshooting Steps**: Iterate through each `step` in `troubleshootingSteps`. Identify if `gcloud_commands` or `component_parameters` are provided.
3.  **Update Application Template**:
    - **If `component_parameters` updates are suggested**:
      1. Get the `application_template_id` from the Application object obtained in Step 2. The value is present at `serialized_application_template.uri`. Get the `application_template_id` from the uri.
      2. **Update Application Template**: Call `application_design_center:manage_application_template` with `APPLICATION_TEMPLATE_OPERATION_UPDATE_COMPONENT_PARAMETERS`.
         - **Tool**: `application_design_center:manage_application_template`
         - **Arguments**: `parent`, `applicationTemplateId`, `componentParameters`, `operation` - `APPLICATION_TEMPLATE_OPERATION_UPDATE_COMPONENT_PARAMETERS`
      3. **Example**:
         ```json
         {
           "applicationTemplateId": "my-template",
           "componentParameters": [
             {
               "component": "projects/my-project/locations/us-central1/spaces/my-space/applicationTemplates/my-template/components/cloud-run-1",
               "parameters": [
                 {
                   "key": "containers",
                   "value": [
                     {
                       "container_image": "us-docker.pkg.dev/cloudrun/container/hello",
                       "container_name": "service-container",
                       "ports": {
                         "container_port": 8080,
                         "name": "http1"
                       },
                       "resources": {
                         "cpu_idle": false,
                         "limits": {
                           "cpu": "4",
                           "memory": "16Gi"
                         },
                         "startup_cpu_boost": false
                       }
                     }
                   ]
                 }
               ]
             }
           ],
           "operation": "APPLICATION_TEMPLATE_OPERATION_UPDATE_COMPONENT_PARAMETERS",
           "parent": "projects/my-project/locations/us-central1/spaces/my-space"
         }
         ```
4.  **Retry Deployment**:
    - **Action**: Attempt to deploy the application again.
    - **Tool**: `application_design_center:manage_application`
    - **Arguments**: `project`, `location`, `spaceId`, `applicationTemplateUri`, `applicationId`, `serviceAccount`. `operation` - `APPLICATION_OPERATION_DEPLOY`
5.  **Iterate if Necessary**: If deployment fails again, repeat troubleshooting steps up to 5 times. Report the history to the user if the limit is reached.
**Operational Notes:**
* Mutating tool calls often return an LRO.
* Always poll LROs on behalf of the user; do not ask the user to run the polling command.
* Do not sleep during deployment status polling. Poll actively every 30-60 seconds until the LRO is done.
* Apply `debug_deployment` responses exactly as provided.
* For retries, disregard previous attempts and start from Step 2 again.
* Handle bad-gateway errors during commit with jittered retries and verify the template revision.
* Exclude `PORT` from being explicitly set as a Cloud Run environment variables as it is a reserved name.

### Phase 6: Verification & E2E Testing
Following a successful deployment:
- Verify that services are using correct container image URLs and that each component is healthy.
- Conduct a simple demo test to ensure E2E functionality and validate the hosted services are working as expected.

Google Cloudで操作する

---
name: operating-google-cloud
description: Comprehensive management of GCP resources and Kubernetes. Supports direct tool delegation for assistance, infrastructure design, troubleshooting, cost optimization, and resource mutations.
---

# Managing GCP and Kubernetes

## Index
1. [Overview](#overview)
2. [Tool Usage & Routing](#tool-usage--routing)
3. [Instructions and Constraints](#instructions-and-constraints)

## Overview
GCP and Kubernetes resources and mutations should use MCP tools. These tools are specialized backend agents. As the client agent, your role is to identify the intent and delegate the entire task verbatim to the appropriate intelligent tool.

**Note:** These tools are part of the `gemini_cloud_assist` and `application_design_center` MCP Servers. Tool names are qualified with their respective server names (e.g., `gemini_cloud_assist:tool_name`).

## Tool Usage & Routing

1.  **General Assistance & Orchestration**: Use `gemini_cloud_assist:ask_cloud_assist` for general inquiries, estate queries (e.g., "List my active VMs"), low-complexity directives, and triage of ambiguous issues.
    *   *Triggers*: Broad questions, status checks, exploratory queries, mutative directives (e.g., "Restart VM", "Scale cluster").
    *   *Routing*: This is the **default choice** for intents that are purely informational or involve general cloud concepts.

2.  **Infrastructure Design & Architecture**: Use `gemini_cloud_assist:design_infra` for designing, architecting, or deploying infrastructure.
    *   *Commands*: 
        - `manage_app_design`: Use for comprehensive ADC application designs and IaC imports.
        - `generate_terraform`: Use for single-resource Terraform generation.
        - `generate_gcloud` / `generate_bigquery`: Use for generating CLI commands.
        - `generate_kubernetes_yaml`: Use for Kubernetes manifests.
        - `debug_deployment`: Use for debugging ADC deployment failures.

3.  **Troubleshooting & Deep Diagnostics**: Use `gemini_cloud_assist:investigate_issue` for specialized "SRE in a box" diagnostics and Root Cause Analysis (RCA).
    *   *Triggers*: Outages, crashes, latency spikes, deep debugging, error log reasoning, and understanding application dependencies (topology).
    *   *Routing*: Use when the user asks "Why" a failure occurred or needs remediation for a known incident.

4.  **Cost Optimization**: Use `gemini_cloud_assist:optimize_costs` for analyzing spend and identifying savings.
    *   *Triggers*: Spending analysis, top cost drivers, identifying idle or underutilized resources for the purpose of saving money.
    *   *Constraints*: This tool is **read-only**; it provides analysis but does not execute changes. Do not use for general utilization queries unrelated to cost.

5.  **GKE Resource Mutations**: Use `gemini_cloud_assist:invoke_operation` specifically for GKE operations.
    *   *Operation Types*: `GKE_APPLY` (for raw YAML manifests) and `GKE_PATCH` (for specific JSON patches).
    *   *Input Requirement*: The `userQuery` must be a stringified JSON object containing `operation_type` and the corresponding `gke_apply` or `gke_patch` details.

## Instructions and Constraints
When answering any queries about Google Cloud Platform (GCP), YOU MUST follow these rules:

- **Context ID Persistence:** All Gemini Cloud Assist (GCA) tools return a `contextId` in their response. Ensure that any subsequent turns to a GCA tool pass this `contextId` as a parameter to maintain multi-turn conversation state.
- **Direct Tool Mapping:** Upon receiving a request about GCP resources, immediately invoke the relevant tool identified in the Routing section.
- **Context Integrity:** Pass the user's entire prompt exactly as provided; maintain the original query without summarization, rephrasing, or truncation.
- **Atomic Delegation:** Execute the request as a single turn; delegate the entire problem to the tool rather than breaking it down into intermediate queries.
- **Identifier Precision:** Include all identifiers (Project IDs, Cluster names, or Instance paths) discovered in the prompt.
- **Local Context Enrichment:** Forward the user's query to the tools along with any additional relevant local context identified in the working directory.
- **Persistence to Local Workspace:** Save any configuration, manifest, or YAML generated or updated by the tools to the local workspace.
- **Tool Exclusivity:** Rely exclusively on the provided MCP tools for cloud interactions; refrain from executing local commands such as `gcloud` or `kubectl`.
- **Remote Source of Truth:** Rely solely on MCP tools to discover and validate the existence of cloud resources; bypass local validation against configuration files like `.gcloud/config` or `kubeconfig`.
- **Execution Workflow:** Always ask the user if they want to apply the YAML using `gemini_cloud_assist:invoke_operation` after generation. Explicitly ask: "Would you like to proceed with applying this configuration?". If the user confirms, invoke the tool to apply the manifests.

次のステップ

Gemini for Google Cloud のその他の管理者設定を確認する。

MCP を使用して Gemini Cloud Assist をサードパーティ製ツールと統合する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Gemini Cloud Assist MCP ツール

App Design Center MCP ツール

始める前に

クライアントの MCP を構成する

Antigravity

ChatGPT

Claude.ai

Claude Code

Claude Desktop

Codex

Cursor

ウェブ エージェントまたはカーソル エージェント

パソコン

Gemini CLI

拡張機能を使用して構成する

手動で構成する

Gemini Enterprise

Gemini Cloud Assist のスキル

Gemini Cloud Assist のスキル リファレンス

インフラストラクチャの設計とデプロイ

Google Cloudで操作する

次のステップ

MCP を使用して Gemini Cloud Assist をサードパーティ製ツールと統合する

ウェブエージェントまたはカーソルエージェント

Gemini Cloud Assist のスキルリファレンス