Gemini Cloud Assist MCP

Gemini Cloud Assist MCPサーバーは、MCPクライアントとGoogle Cloud Gemini Cloud Assist APIを接続するツールで、ユーザーが自然言語でGoogle Cloud環境の問題を理解、管理、およびトラブルシューティングできるようにします。

クラウドプラットフォーム開発者ツール #クラウドサービス #トラブルシューティング #リソース管理 #AIアシスタント .TypeScript

スコア : 2.5ポイント

ダウンロード数 : 7.0K

更新時間 : 2025-10-09

サイトを開く

Gemini Cloud Assist MCPサーバーとは？

これは、AIアシスタント（Gemini CLI、Claudeなど）をGoogle Cloudプラットフォームに接続するインテリジェントなコネクタです。自然言語での会話を通じて、クラウドリソースの状態を直接照会し、問題をトラブルシューティングし、パフォーマンスを分析でき、複雑なコマンドラインやコンソール操作を覚える必要はありません。

Gemini Cloud Assistの使い方は？

サポートされているAIクライアントでMCPサーバーを設定し、アシスタントとチャットするようにクラウド環境に関する質問をすればOKです。システムが自動的に質問をクラウドプラットフォームの照会に変換し、理解しやすい形式で結果を返します。

適用シナリオ

開発者、運用エンジニア、クラウド管理者など、Google Cloudと頻繁にやり取りする必要のあるユーザーに適しています。特に、迅速な障害調査、リソース状態の確認、パフォーマンス分析などの日常の運用タスクに最適です。

主要機能

インテリジェントな問題調査

自動化された調査を作成して実行し、クラウド環境の複雑な問題を深く分析し、根本原因を自動的に特定します。

リソース検索と分析

自然言語を使用してGoogle Cloudリソースを検索および分析し、迅速に状態とパフォーマンス情報を取得します。

反復的な分析

調査中に新しい観察情報を追加し、分析結果を継続的に最適化し、より正確な問題診断を行います。

サービス横断的な統合

GKE、Compute Engine、Cloud StorageなどのさまざまなGoogle Cloudサービスの統一照会をサポートします。

利点

自然言語インタラクション：複雑なコマンドを覚える必要がなく、会話形式でクラウドリソースを管理できます。

迅速な障害調査：自動化された問題分析により、問題解決時間を大幅に短縮します。

統一照会インターフェイス：単一のエントリポイントから複数のクラウドサービスの状態を照会できます。

インテリジェントな推奨：分析結果に基づいて具体的な修復提案と操作ガイドを提供します。

セキュリティ認証：標準のGoogle Cloud認証を使用し、アクセスの安全性を保証します。

制限

Google Cloud環境に依存：Google Cloudプラットフォームのサービスのみをサポートします。

権限の設定が必要：適切なIAMロールとAPIの有効化を事前に設定する必要があります。

ネットワーク要件：クラウドAPIにアクセスするために安定したネットワーク接続が必要です。

学習曲線：初回の設定にはMCPクライアントの設定を理解する必要があります。

使い方

環境の準備

Node.js v20+、Git、Google Cloud SDKがインストールされていることを確認し、有効なGoogle Cloudプロジェクトを持っていることを確認してください。

認証

gcloudコマンドラインツールを使用してユーザーログインとアプリケーションのデフォルトクレデンシャルの設定を完了します。

MCPクライアントの設定

お好みのAIクライアントにGemini Cloud Assist MCPサーバーの設定を追加します。

使用開始

クライアントを再起動し、自然言語でGoogle Cloudリソースの照会と管理を開始します。

使用例

GKEクラスターのリソース不足のトラブルシューティング

GKEクラスターでpodがpending状態になった場合、迅速にリソースのボトルネック問題を診断します。

クラウドストレージの容量問題の分析

GKEノードのephemeral storageが枯渇してpodがクラッシュする問題を診断します。

リソースリストの照会

GKEノードプール、仮想マシンインスタンスグループなどのリソースの詳細なリストと状態を迅速に取得します。

よくある質問

このサービスを使用するにはどのような権限が必要ですか？

どのAIクライアントがサポートされていますか？

データの安全性はどのように保障されていますか？

調査分析の結果は正確ですか？

設定問題が発生した場合はどうすればいいですか？

🚀 Gemini Cloud Assist MCP server

このサーバーは、Model Context Protocol (MCP) クライアント（Gemini CLI など）を Gemini Cloud Assist APIs に接続します。これにより、ローカルコマンドラインから直接自然言語を使用して、Google Cloud環境の理解、管理、トラブルシューティングを行うことができます。

⚠️ 重要注意

「Google Cloud Platform利用規約」（https://cloud.google.com/terms/ で入手可能）および「データ処理とセキュリティ条項」（https://cloud.google.com/terms/data-processing-terms で入手可能）は、Gemini Cloud Assist MCP Serverソフトウェアのいずれのコンポーネントにも適用されません。

Gemini Cloud Assistの詳細については、Google Cloudドキュメントの Gemini Cloud Assistの概要を参照してください。

🚀 クイックスタート

始める前に、以下のものが設定されていることを確認してください。

Node.js（v20以上）
Git
Google Cloud SDK がインストールされ、構成されていること
Google Cloudプロジェクト
ユーザーアカウントに以下の IAMロール があること：
- roles/serviceusage.serviceUsageAdmin：Cloud Assist APIを有効にするために必要です。
- roles/geminicloudassist.user：Cloud Assist APIにリクエストを送信するために必要です。

ステップ1：Google Cloudに認証する

Gemini Cloud Assist MCPサーバーは、ローカルのApplication Default Credentials (ADC) を使用してGoogle Cloudに安全に認証します。ADCを設定するには、以下の gcloud コマンドを実行します。

# ユーザーアカウントをgcloud CLIに認証する
gcloud auth login

# サーバー用にApplication Default Credentialsを設定する
# これにより、MCPサーバーがあなたの代わりに安全にGoogle Cloud API呼び出しを行うことができます
gcloud auth application-default login

ステップ2：MCPクライアントを構成する

以下は、使用する標準的な構成スニペットです。これは、クライアントに npx を使用してMCPサーバーの最新バージョンをダウンロードして実行するように指示します。MCP構成を任意のMCPクライアントに貼り付けてください。最高の体験を得るために、Gemini CLI の使用をお勧めします。

MCP設定

"mcpServers" : {
   "GeminiCloudAssist": {
     "command": "npx",
     "args": ["-y", "@google-cloud/gemini-cloud-assist-mcp@latest"],
     "timeout": 600000
   }
}

✨ 主な機能

調査の作成と実行：Cloud Assistの調査を作成して実行し、複雑な問題の根本原因を見つけます。
調査の詳細化と反復：調査結果の詳細を取得し、観察結果を追加して分析を洗練させます。
Google Cloudリソースの検索と分析：Cloudリソースとアプリケーションの状態とパフォーマンスをすばやく確認します。

📦 インストール

MCPクライアントの設定手順

Gemini CLI

オプション1（推奨）：拡張機能としてのインストール

MCPサーバーを Gemini CLI拡張機能としてインストールします。

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

以下のコマンドを実行して、インストールが成功したことを確認します。

gemini extensions list

オプション2：グローバルインストール

MCP設定を ~/.gemini/settings.json に追加します。これにより、すべてのGemini CLIセッションでMCPツールにアクセスできるようになります。

オプション3：プロジェクトレベルのインストール

MCP設定を /path/to/project/.gemini/settings.json ファイルに追加します。これにより、このプロジェクトフォルダ内で作成されたGemini CLIセッションでのみMCPツールにアクセスできるようになります。

Cursor

Claude Desktop

Claude Desktopアプリケーションを起動します。
設定 > 開発者に移動します。
設定を編集ボタンをクリックして、claude_desktop_config.json ファイルを開きます。
MCP設定を claude_desktop_config.json ファイルに追加します。
ファイルを保存し、Claude Desktopを再起動します。

Claude Code

claude mcp add GeminiCloudAssist npx -y @google-cloud/gemini-cloud-assist-mcp@latest

詳細な手順については、Anthropicのドキュメントの詳細な手順を参照してください。

Cline

MCP設定を使用して cline_mcp_settings.json を更新します。詳細な手順については、Clineのウェブサイトの詳細な手順を参照してください。

🔧 技術詳細

MCPツール

create_investigation：新しいGemini Cloud Assistの調査を作成します。
run_investigation：作成した既存のGemini Cloud Assistの調査を実行します。
add_observation：既存の調査に新しい観察結果を追加して、分析を洗練させます。
fetch_investigation：調査の詳細を取得するか、プロジェクト内の調査を一覧表示します。
search_and_analyze_gcp_resources：自然言語クエリを使用して特定のCloudリソースを検索します。

💻 使用例

基本的な使用法

このセクションでは、Gemini CLIを使用してCloud Assist MCPサーバーで実行できるタスクの例を示します。例として、プロンプトと応答が含まれています。

調査の作成と実行

Using 1 MCP server (Ctrl+T to view descriptions)

╭───────────────────────────────────────────────────────────────────────────────────╮
│  > Investigate the pending pods issue in my test-cluster-1 cluster                │
╰───────────────────────────────────────────────────────────────────────────────────╯

✦ I can help with that. I'll start an investigation into the pending pods issue in
  your test-cluster-1 cluster. To do that, I'll run a few commands to get the
  information I need to start the investigation.
 ╭──────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  Shell gcloud config get-value project (Getting the configured GCP project.)   |
 ...                                                                                |
 ...                                                                                |
 ╰──────────────────────────────────────────────────────────────────────────────────╯

✦ I'll now create an investigation into the pending pods issue in your test-cluster-1 GKE cluster.
 ╭──────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  create_investigation (gemini-cloud-assist-mcp MCP Server) create_investigati… │
 │                                                                                  │
 │    ## Gemini Cloud Assist Investigation                                          │
 │                                                                                  │
 │    **Name**: [Gemini CLI] Pending pods in test-cluster-1 GKE cluster             │
 ...                                                                                |
 ...                                                                                |
 ╰──────────────────────────────────────────────────────────────────────────────────╯

✦ I've created the investigation. Now I'll run it to analyze the issue.
 ╭──────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  run_investigation (gemini-cloud-assist-mcp MCP Server) run_investigation (ge… │
 ...                                                                                |
 ...                                                                                |
 ╰──────────────────────────────────────────────────────────────────────────────────╯

✦ The investigation is complete. Here's what I found:

  The main problem is that your GKE cluster `test-cluster-1` is out of resources. It
  has only one node, and that node is full. This is causing new pods to get stuck in
  a "pending" state because there's no room for them.

  The investigation also revealed that Node Auto-Provisioning (NAP) is disabled. This
   is a key feature that allows the cluster to automatically add more nodes when it's
   running low on resources. Because NAP is disabled, the cluster can't scale up to
  meet the demand.

  I have two recommendations to fix this:
   1. Enable Node Auto-Provisioning for the test-cluster-1 cluster. This is the best
      long-term solution because it will allow the cluster to automatically scale up
      and down as needed.
   2. Manually add more nodes to the cluster. This is a good short-term solution that
       will immediately relieve the resource pressure and allow the pending pods to
      be scheduled.

  I recommend that you start by enabling Node Auto-Provisioning. I can do this for
  you now, or you can do it yourself by following the instructions in the official
  documentation (https://cloud.google.com/kubernetes-engine/docs/how-to/node-auto-pro
  visioning#enable).

  What would you like to do?

調査の詳細化と反復

✦ The investigation is complete. Here's a summary of the findings:

  Primary Cause:

   * Ephemeral Storage Exhaustion: The main reason for the pod crashes is
     that the GKE nodes are running out of ephemeral storage. This is
     causing a DiskPressure condition on the nodes, which in turn leads to
     the kubelet evicting pods to free up space.

 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │  > Do you know which pod is consuming all the storage space?                      │
 ╰───────────────────────────────────────────────────────────────────────────────────╯

✦ That's a great question. The investigation points to the emptyDir volume
  in the gke-001-deployment pods. I can check the storage usage
  inside one of the running pods to confirm this.

  First, I'll list the pods to find one that is currently running.
 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  Shell kubectl get pods -n gke-001-namespace (This command will list..          │
 ...                                                                                 |
 ...                                                                                 |
 ╰───────────────────────────────────────────────────────────────────────────────────╯


✦ That's unexpected. The /data directory in that pod is only using 4.0K,
  which is negligible. This contradicts the hypothesis that the emptyDir
  volume is the primary consumer of ephemeral storage.

  This means something else on the node is consuming the storage. It could
  be logs, or another process running on the node that isn't immediately
  obvious.

  To figure this out, I'll need to get a shell on the node itself and
  investigate the storage usage from there. I'll start by getting an
  interactive shell on the node
  gke-001-cluster-gke-001-node-pool-001.
 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  Shell gcloud compute ssh gke-001-cluster-gke-001-node-pool-001…                │
 ...                                                                                 |
 ...                                                                                 |
 │    ERROR: (gcloud.compute.ssh) [/usr/local/bin/ssh] exited                        │
 │    with return code [255].                                                        |
 ╰───────────────────────────────────────────────────────────────────────────────────╯

✦ It seems I can't directly SSH into the node. This is likely due to
  firewall rules or the node not having an external IP address.

  However, I can still investigate the node's storage. I'll add an
  observation to the investigation, noting that the emptyDir volume is not
  the cause of the storage issue, and then re-run the investigation. This
  will allow Gemini to analyze the node's logs and other signals to
  pinpoint the true source of the storage consumption.
 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  add_observation (gemini-cloud-assist MCP Server) {"observation":"Fu…           │
 │                                                                                   │
 │    ## Gemini Cloud Assist Investigation                                           │
 │                                                                                   │
 │    **Name**: [Gemini CLI] GKE pods crashing due to ephemeral storage issues       │
 ...                                                                                 |
 ...                                                                                 |
 ╰───────────────────────────────────────────────────────────────────────────────────╯

✦ I've added the new information to the investigation. Now I'll re-run the
  analysis. This will take the new observation into account and should help
  us identify the real source of the storage consumption.
 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  run_investigation (gemini-cloud-assist MCP Server) {"investigationI…           │
 │                                                                                   │
 ...                                                                                 |
 ...                                                                                 |
 ╰───────────────────────────────────────────────────────────────────────────────────╯


✦ The new investigation results are in.

  Key Findings:

   * `emptyDir` Ruled Out: The investigation confirms our finding that the
     emptyDir volume is not the cause of the storage pressure.
   * Container Logs are the Likely Culprit: The analysis strongly suggests
     that the ephemeral storage is being consumed by container logs. The
     kubelet is failing to reopen log files due to "no space left on
     device," which is a clear indicator of this issue.
   * Another Deployment is Implicated: The investigation also points to
     another deployment, gke-002-deployment, as a potential source of the
     problem. The logs mention that this deployment is "configured to fill
     up disk."

Cloudリソースの検索と分析

 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │  > Give me an overview of my GKE node pools. For each one, show me its            │
 │    cluster and MIGs                                                               │
 ╰───────────────────────────────────────────────────────────────────────────────────╯

 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  search_and_analyze_gcp_resources (gemini-cloud-assist-mcp MCP Server) s…       │
 │                                                                                   │
 │    Based on the output of the `container.googleapis.com` API                      │
 │    calls, here is an overview of your GKE node pools, including                   │
 │    their associated clusters and Managed Instance Groups (MIGs):                  │
 │                                                                                   │
 │    *   **Cluster: `cluster-1` (Zone: `us-central1-a`)**                           │
 │        *   **Node Pool:** `default-pool`                                          │
 │            *   **Machine Type:** `custom-1-3840`                                  │
 │            *   **Initial Node Count:** 3                                          │
 │            *   **Autoscaling:** Enabled (min: 1, max: 5)                          │
 │            *   **MIGs:**  `gke-cluster-1-default-pool-001-grp`                    │
 │                                                                                   │
 │    *   **Cluster: `anthos-cluster-1` (Zone: `us-central1-c`)**                    |
 │        *   **Node Pool:** `default-pool`                                          │
 │            *   **Machine Type:** `e2-standard-2`                                  │
 │            *   **Initial Node Count:** 3                                          │
 │            *   **Autoscaling:** Enabled (min: 2, max: 3)                          │
 │            *   **MIGs:** `gke-anthos-cluster-default-pool-001-grp`                |
 │                                                                                   │
 │    *   **Cluster: `cluster-2` (Zone: `us-central1-c`)**                           │
 │        *   **Node Pool:** `default-pool-1`                                        │
 │            *   **Machine Type:** `e2-micro`                                       │
 │            *   **Initial Node Count:** 3                                          │
 │            *   **Autoscaling:** Enabled (max: 5)                                  │
 │            *   **MIGs:**  `gke-cluster-2-default-pool-001-grp`                    │
 ╰───────────────────────────────────────────────────────────────────────────────────╯
✦ OK. Here's an overview of your GKE node pools, their clusters, and MIGs. Is
  there anything else I can help you with?
 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │  > Tell me details about each MIG                                                 │
 ╰───────────────────────────────────────────────────────────────────────────────────╯

 ╭───────────────────────────────────────────────────────────────────────────────────╮
 │ ✔  search_and_analyze_gcp_resources (gemini-cloud-assist-mcp MCP Server) s…       │
 │                                                                                   │
 │    I found the following details for the requested Managed                        │
 │    Instance Groups (MIGs):                                                        │
 │                                                                                   │
 │    *   **gke-cluster-1-default-pool-001-grp**:                                    │
 │        *   **Region/Zone**: us-central1-a                                         │
 │        *   **Creation Timestamp**: 2024-03-25T13:57:25.588-07:00                  │
 │        *   **Current Actions**: 2 instances with no current                       │
 │    action                                                                         │
 │        *   **Target Size**: 2                                                     │
 │        *   **Status**: Stable                                                     │
 │        *   **Instance Template**:                                                 │
 │    `gke-cluster-1-default-pool-001`                                               │
 │        *   **Update Policy**: Opportunistic, minimal action                       │
 │    REPLACE, max surge 1, max unavailable 1                                        │
 │                                                                                   │
 │    *   **gke-anthos-cluster-default-pool-001-grp**:                               │
 │        *   **Region/Zone**: us-central1-c                                         │
 │        *   **Creation Timestamp**: 2024-04-03T09:09:32.058-07:00                  │
 │        *   **Current Actions**: 2 instances with no current                       │
 │    action                                                                         │
 │        *   **Target Size**: 2                                                     │
 │        *   **Status**: Stable                                                     │
 │        *   **Instance Template**:                                                 │
 │    `gke-anthos-cluster-default-pool-001`                                          │
 │        *   **Update Policy**: Opportunistic, minimal action                       │
 │    REPLACE, max surge 1, max unavailable 1                                        │
 │        *   **Named Ports**: http (port 3337)                                      │
 │                                                                                   │
 │    *   **gke-cluster-2-default-pool-001-grp**:                                    │
 │        *   **Region/Zone**: us-central1-c                                         │
 │        *   **Creation Timestamp**: 2024-11-13T21:46:01.072-08:00                  │
 │        *   **Current Actions**: 5 instances with no current                       │
 │    action                                                                         │
 │        *   **Target Size**: 5                                                     │
 │        *   **Status**: Stable                                                     │
 │        *   **Instance Template**:                                                 │
 │    `gke-cluster-2-default-pool-001`                                               │
 │        *   **Update Policy**: Opportunistic, minimal action                       │
 │    REPLACE, max surge 1, max unavailable 1                                        │
 │                                                                                   │
 │    These details were retrieved by calling the Compute Engine                     │
 │    API's `instanceGroupManagers.get` and                                          │
 │    `instanceGroupManagers.aggregatedList` methods.                                │
 ╰───────────────────────────────────────────────────────────────────────────────────╯
✦ Here are the details for each MIG. Let me know if you need anything else.