アノテーション、Google Cloud が大好きな村上です。
「VMインスタンスを作りたいけど、gcloud コマンドのオプションが多くて覚えられない…」そんな経験はありませんか？ Cloud Shell にプリインストールされた AI エージェント Gemini CLI を使えば、そんな悩みは過去のものになるかもしれません。この記事では、VM インスタンスの作成からスペック変更、削除までの一連の操作を、すべて日本語の自然言語だけで行えるのかを検証します。この記事を読めば、未来のインフラ操作を体験できるはずです。

Gemini CLI とは？

Google によると、とてもいろいろなことができる AI エージェントです。
GoogleがオープンソースのAIエージェント「Gemini CLI」を発表

現在プレビュー中のGemini CLIは、コード理解やファイル操作からコマンド実行、動的なトラブルシューティングまで、強力なAI機能を提供します。コマンドラインエクスペリエンスを根本的に向上させ、自然言語によるコード記述、問題デバッグ、ワークフローの効率化を実現します。

その AI エージェントが、Cloud Shell にプリインストールされたと社内の slack に書きこまれていたのを見たのが本記事執筆のきっかけです。
Cloud Shell 上で Gemini CLI が利用できるってことは、Google Cloud のインフラ構築も自然言語の対話方式でできるということなんでしょう。百聞は一見に如かず、早速使ってみましょう。Cloud Shellを開き、gemini コマンドを実行すると、専用のプロンプトが起動します。

準備：Gemini CLIに賢く働いてもらうためのひと工夫

さっそく Gemini CLI を試してみようとしたところ、ホームディレクトリではなく専用のディレクトリを作成してくださいというメッセージが表示されました。そこで、Gemini CLI に効率よく働いてもらうため、以下の2つの準備を行いました。

1. 専用ディレクトリの作成: Gemini CLI は、カレントディレクトリにある GEMINI.md というファイルを読み込み、対話のコンテキストとして利用します。今回は gemini-cli というディレクトリを作成し、そこで作業します。

2. コンテキストファイル(GEMINI.md)の設置: このファイルにプロジェクトの概要やペルソナを記述すると、Gemini がそれを理解して回答の精度を上げてくれます。今回は「Google Cloudのソリューションアーキテクト」として振る舞うよう簡単なペルソナを設定しました。（このファイルは必須ではなく、今回は詳細を割愛します。）

GEMINI.md

GEMINI.md - プロジェクト設定ファイル

プロジェクト概要

このプロジェクトは、Google Cloud 上でスケーラブルなウェブアプリケーションを構築することを目的としています。主な要件は以下の通りです：

• 高可用性：システムは 99.99% の稼働率を維持すること。
• スケーラビリティ：トラフィックの増加に応じて自動的にスケールすること。
• セキュリティ：データの暗号化と適切なアクセス制御を実施すること。

使用する技術スタック

• コンピューティング：Google Kubernetes Engine (GKE)
• ストレージ：Cloud SQL（MySQL）
• キャッシュ：Cloud Memorystore（Redis）
• 監視：Cloud Monitoring と Cloud Logging
• CI/CD：Cloud Build と Cloud Deploy

コーディング規約

• 言語：Python 3.9
• フレームワーク：Flask
• コードスタイル：PEP 8 に準拠すること
• 型ヒント：すべての関数に型ヒントを追加すること

アーキテクチャパターン

• マイクロサービス：各機能は独立したマイクロサービスとして実装し、GKE 上で管理すること。
• API 設計：RESTful API を採用し、OpenAPI 仕様書を作成すること。
• データベース設計：正規化を行い、必要に応じてインデックスを追加すること。

セキュリティポリシー

• 認証：OAuth 2.0 を使用し、Google Identity Platform と統合すること。
• アクセス制御：最小権限の原則に従い、IAM ロールを適切に設定すること。
• データ暗号化：保存データと転送データの両方を暗号化すること。

デプロイメント戦略

• 環境：開発、ステージング、本番の 3 環境を用意すること。
• デプロイ手順：GitHub Actions を使用して、Cloud Build と連携し、CI/CD パイプラインを構築すること。
• ロールバック：デプロイ後の問題発生時には、Cloud Run のリビジョン機能を使用して迅速にロールバックすること。

モニタリングとロギング

• 監視：Cloud Monitoring を使用して、システムのパフォーマンスと稼働状況を監視すること。
• ロギング：Cloud Logging を使用して、アプリケーションとインフラのログを収集し、分析すること。
• アラート：重要なメトリクスに対してアラートを設定し、問題発生時に通知を受け取ること。

テスト戦略

• 単体テスト：pytest を使用して、各モジュールの単体テストを作成すること。
• 統合テスト：Postman を使用して、API の統合テストを実施すること。
• パフォーマンステスト：Cloud Load Testing を使用して、システムの負荷テストを行うこと。

ドキュメント

• コードコメント：関数やクラスには適切なコメントを追加し、コードの可読性を高めること。
• README：プロジェクトの概要、セットアップ手順、使用方法を記載した README を作成すること。
• API ドキュメント：OpenAPI 仕様書を作成し、API の詳細を文書化すること。

その他の注意点

• バックアップ：Cloud SQL の定期的なバックアップを設定し、データの保護を行うこと。
• コスト管理：Google Cloud の料金を定期的に確認し、コスト最適化を図ること。
• コンプライアンス：業界標準のセキュリティ基準や法規制を遵守すること。

Step 1: Geminiと対話してVMインスタンスを作成する

では、gemini-cli ディレクトリに移動してから、VMインスタンスの作成をお願いしてみます。gcloud コマンドを正確に知らなくても、やりたいことをそのまま伝えるのがポイントです。

Google Cloud の東京リージョンにおいて、汎用インスタンスタイプで小さいインスタンスサイズを選び VM インスタンスを作成してください。

すると、Geminiは私の意図を正確に理解し、一般的な用途で費用対効果の高い e2-small または e2-micro を提案してくれました。

インスタンスタイプの変更先は e2-small、e2-micro のどちらでも良かったので、とりあえず、e2-micro を選択してみました。

次に、Gemini からインスタンス名について、gemini-instance という名前で良いかとの確認がありました。
今回は、お試しということもあり Gemini から提案があったインスタンス名をそのまま採用します。

ここで、Yes, allow once と指定すると、記載されている gcloud コマンドが実行されます。

指定したマシンタイプで VN インスタンス gemini-instance が作成されました。Google Cloud コンソール上でもインスタンスを確認します。

確かに、コンソール上においてもインスタンスタイプ e2-micro で gemini-instance が作成されていることを確認できました。

Step 2: 対話を続けてVMインスタンスのスペックを変更する

インスタンスの作成後、気の利く執事のように、「SSH 接続でもいかがでしょう？」と提案されました。あまりに優秀なので、ここからは彼（Gemini CLI）を「セバスチャン」と呼ぶことにします。今回はインスタンスのスペックアップを試してみます。
次に、作成したインスタンスのスペックを変更してみます。ここでも、対話を続ける形でお願いしてみます。

マシンタイプをもう少し大きなタイプに変更をしたいです。今のインスタンスクラスより大きいインスタンスクラスを3つ提示して、それぞれの特徴を教えてください。`

セバスチャン（Gemini CLI）の 3 つの提案から e2-medium を選択しました。注目すべきは、ここからの流れです。Gemini は VM インスタンスのスペック変更にはインスタンスの停止が必要であることを理解しており、「停止 → マシンタイプ変更 → 起動」という 3 つの gcloud コマンドを自動的に提案してくれました。これは人間が手作業で行うと忘れがちな手順であり、AI が文脈を理解して一連の操作を組み立ててくれる、良い例だと思います。

ここも Yes, allow once を選択します。この後も、インスタンス停止前の確認、マシンタイプの再確認と全て Yes! として Gemini CLI に作業を実施してもらいまいました。

すべての処理が完了した後、コンソールでマシンの構成を確認すると、マシンタイプが正しくe2-mediumに変更されていました。

Step 3: VMインスタンスを削除する

最後に、後片付けとしてインスタンスの削除をお願いします。

gemini-instance を削除してください。

最後の Yes を実行して VM インスタンスの削除を実行します。

Google Cloud コンソールにおいても、VM インスタンス gemini-instance が削除されていることを確認できました。
ありがとう、セバスチャン...

まとめ

今回の検証を通して、VMインスタンスのライフサイクル管理（作成・変更・削除）が、すべてGeminiとの自然言語での対話のみで完結できることを確認できました。

gcloud コマンドの詳細な構文を覚えていなくても、やりたいことを伝えるだけで Gemini が適切なコマンドを提案してくれるのは、学習コストの削減や作業効率の向上に大きく貢献すると感じます。特に、複数の手順が必要なスペック変更のような操作を、文脈を理解した上で自動的に組み立ててくれる点には感心しました。

この記事が、AI エージェントの理解の一助となれば幸いです。

参考

• GoogleがオープンソースのAIエージェント「Gemini CLI」を発表
• VM インスタンスのライフサイクルを管理する  |  Google Distributed Cloud Hosted Appliance  |  Google Cloud