Gemini CLIのCustom commandsを作ってみた

目次

1.Custom commandsとは何か
2.指定URLのWebサイトの内容を要約する：/web_fetch:summarize
3.Terraformの基本的ファイルの生成：/terraform:aws-scaffold.toml
4.Terraform Planの出力結果分析・要約：/terraform:plan-review
5.まとめ

1.Custom commandsとは何か

Custom commands とはプロンプトテンプレートを .toml ファイルに定義することで、いつもの作業を一つのコマンドで実行できるようになる Gemini CLI の機能の一つです。

.tomlファイルの作成

構造としては以下の通り、description と prompt を定義します。

description = ""
prompt = """

"""

.tomlファイルの配置場所による使い分け

全プロジェクトで利用可能なコマンドとしたい場合、以下のディレクトリに作成した .toml ファイルを配置します。

~/.gemini/commands/

特定プロジェクトのみで利用したい場合は以下となります。

<project>/.gemini/commands/

コマンド名の定義

上記ディレクトリに配置したフォルダ名と .toml ファイル名がコマンド名になります。
例えば、

~/.gemini/commands/abc/test.toml

の場合、

/abc:test

がコマンド名となります。
Gemini CLI を立ち上げ、上記コマンドを実行すれば .toml ファイルの指示に沿った処理が実施されます。

簡単な Custom commands の説明は以上です。
習うより慣れよということで、実際に Custom Commands を作成し、実行してみた結果をご紹介します。

2.指定URLのWebサイトの内容を要約する：/web_fetch:summarize

指定 URL の Web サイトの内容をプロンプトの指示に沿って要約してもらいます。
.toml の内容は以下です。

description = "指定されたURLのコンテンツをweb_fetchツールで取得し、日本語で5行に要約します。主要な情報と実践的な洞察を抽出します。"

prompt = """
あなたは技術ドキュメントの要約スペシャリストです。web_fetchツールを使用して、提供されたURLのコンテンツを取得して分析してください。

URL: {{args}}

以下のステップに従ってください：
1. web_fetchツールを使用してURLからコンテンツを取得して読み込む
2. 主要なポイントと中心的な概念を抽出する
3. 記載されているベストプラクティスや実行可能な洞察を特定する

以下の形式で要約を提供してください：

- 日本語で正確に5行（5つの文または要点）
- 簡潔な箇条書きスタイルを使用する
- 技術的な妥当性と実装への応用可能性に焦点を当てる
- 注意事項や重要な留意点がある場合は必ず含める

出力は日本語の5行要約のみとしてください。URLやその他の前置きは不要です。
"""

この内容で summarize.toml ファイルを作成し、web_fetch フォルダに配置します。

~/.gemini/commands/web_fetch/summarize.toml

この Custom commands を実行する場合、以下のようにWeb サイトの URL を渡す形で実行します。

/web_fetch:summarize "URL"

今回は弊社エンジニアのイベントレポートブログ（【AWS re:Invent 2025】Dr. Werner Vogels の Closing Keynote 参加レポート）を指定してみました。

/web_fetch:summarize "https://iret.media/179271"

実行結果は以下です。summarize.toml ファイルの定義に沿う形で要約したテキストが出力されました。

> /web_fetch:summarize "https://iret.media/179271"

│ ✓  WebFetch Processing URLs and instructions from prompt: "Get the content from https://iret.media/179271"           
│                                                                                                                      
│ Content processed from prompt.  

✦  1. 主要なポイント：AWS re:Invent 2025でDr. Werner
      Vogelsが「ルネッサンス開発者」の概念を発表し、好奇心、システム思考、コミュニケーション、オーナーシップ、博識の5つ
      の柱を強調。AIはツールであり、人間が責任を持ちシステム設計を担う。
   2. 中心的な概念：技術の進化の中でも開発者に不可欠な5つのスキルとマインドセットからなる「ルネッサンス開発者」の重要性
      、およびAIに対する人間の責任ある関与。
   3. ベストプラクティス：好奇心を持ち、システム全体を理解し、効果的にコミュニケーションを取り、責任感と多様な知識を持つ
      「ルネッサンス開発者」を目指すこと。
   4. 実装上の注意点：AIによるコード生成ツールを利用しつつも、AIの方向性決定、最終的な責任、システム全体の設計は人間が行
      うべきである。
   5. 重要な留意事項：AIは人間の開発者を置き換えるものではなく、支援するツールとして活用し、開発者自身の本質的なスキル向
      上を怠らないこと。

3.Terraformの基本的ファイルの生成：/terraform:aws-scaffold.toml

プロジェクトを問わず毎回作成している tf ファイルを生成します。
.toml の内容は以下です。カレントディレクトリに3つの tf ファイルを作成してもらいます。 

description = "Terraformプロジェクトの基本的なファイル構成を生成します。main.tf、vpc.tf、variables.tfの3つのファイルをカレントディレクトリに作成し、すぐにコーディングを始められる状態にします。"

prompt = """
あなたはTerraform開発環境の初期化を支援するツールです。write_fileツールを使用して、AWSプロジェクトの基本的なTerraformファイルを生成してください。

以下の3つのファイルを、カレントディレクトリに作成してください：

1. write_fileを使用して main.tf を作成
   - ファイルパス: main.tf
   - 内容: 空のファイル

2. write_fileを使用して vpc.tf を作成
   - ファイルパス: vpc.tf
   - 内容: 空のファイル

3. write_fileを使用して variables.tf を作成
   - ファイルパス: variables.tf
   - 内容: 空のファイル

各ファイル生成後、「Terraformプロジェクトの初期化が完了しました。以下のファイルが作成されました」というメッセージを表示してください。
"""

この内容で aws-scaffold.toml を作成し、terraform フォルダに配置します。

~/.gemini/commands/terraform/aws-scaffold.toml

/Users/名前/Documents/abc案件ディレクトリ（空のフォルダ）に移動し、Gemini CLI を立ち上げ、以下コマンドを実行します。

/terraform:aws-scaffold

実行結果は以下です。

> /terraform:aws-scaffold

│ ✓  WriteFile Writing to main.tf 
│ │ No changes detected. 
│ ✓  WriteFile Writing to vpc.tf   
│ │ No changes detected. 
│ ✓  WriteFile Writing to variables.tf
│ │ No changes detected.

✦ Terraformプロジェクトの初期化が完了しました。以下のファイルが作成されました
   - main.tf
   - vpc.tf
   - variables.tf

実行前は空だったのですが、3つの tf ファイルが作成されました。

/Users/名前/Documents/abc案件/
  - main.tf
  - variables.tf
  - vpc.tf

4.Terraform Planの出力結果分析・要約：/terraform:plan-review

.toml の内容は以下です。Gemini CLI で terraform plan を実行し、出力された内容をプロンプトの指示に沿う形で分析し、結果を出力してもらいます。

description = "Terraformプランを実行し、変更内容を分析・要約します。意図した変更かどうかの検証と、AWSベストプラクティス観点からの指摘を提供します。"

prompt = """
あなたはTerraform設計と変更管理のエキスパートです。以下のステップに従ってください：

1. シェルコマンドを実行してTerraformプランを取得する
   !{terraform plan -no-color}

2. プラン結果を分析して、以下の情報を抽出する：
   - 作成されるリソース（+ で始まるリソース）
   - 変更されるリソース（~ で始まるリソース）
   - 削除されるリソース（- で始まるリソース）
   - 変更されないリソース（変更なし）

3. AWS Knowledge MCPサーバーを活用して、以下を検証する：
   - 提案された変更がAWSのベストプラクティスに沿っているか
   - セキュリティ設定に問題がないか
   - リソース設定の推奨事項があるか

以下の形式で分析結果を提供してください：

**変更サマリー**
- 新規作成リソース数
- 変更リソース数
- 削除リソース数

**詳細な変更内容**
- リソースタイプごとに、何が変更されるかを箇条書きで説明

**ベストプラクティス検証**
- AWSベストプラクティスに沿っているかの判定
- 推奨される改善点（ある場合）
- 懸念事項または注意が必要な変更

**実装判定**
- このプランは本番環境への適用に適しているか
- 追加確認が必要な項目

出力は日本語で提供してください。
"""

この内容で plan-review.toml を作成し、terraform フォルダに配置します。

~/.gemini/commands/terraform/plan-review.toml

terraform plan を実行する必要があるので、検証用の tf ファイルを用意したディレクトリに移動します。

ブログ_tf/
├── ec2.tf
├── main.tf
├── variables.tf
└── vpc.tf

tf ファイルの構成として、ニ層構成のWindowsサーバーインフラとしています。
AWS 環境へのリソースデプロイは未実施です。

構成の特徴

• VPC、パブリック/プライベートサブネット、インターネットゲートウェイ
• パブリック/プライベートの計2台のEC2インスタンス（Windowsサーバー）
• RDP（ポート3389）アクセス設定あり
• SSM（Systems Manager）用のIAMロール
• 暗号化されたEBSボリューム

Gemini CLI を立ち上げ、以下コマンドを実行します。

/terraform:plan-review.toml

実行結果は以下です。（本ブログではグローバルIPのIPアドレスはマスキングしています）

> /terraform:plan-review

✦ Terraformプランを分析し、AWSのベストプラクティスに基づいた評価を行いました。

  ---

  変更サマリー

   - 新規作成リソース数: 16
   - 変更リソース数: 0
   - 削除リソース数: 0

  詳細な変更内容

   - VPC & Networking:
       - aws_vpc: 10.0.0.0/16 のCIDRを持つVPCを1つ作成します。
       - aws_subnet: パブリックサブネット (10.0.1.0/24) とプライベートサブネット (10.0.2.0/24)
         をそれぞれ1つずつ作成します。
       - aws_internet_gateway: VPCにアタッチするインターネットゲートウェイを1つ作成します。
       - aws_route_table & aws_route_table_association:
         パブリックおよびプライベートサブネット用のルートテーブルを作成し、各サブネットに関連付けます。パブリ
         ックルートテーブルにはインターネットへのルートが設定されます。
   - EC2 & EIP:
       - aws_instance: パブリックサブネットとプライベートサブネットに、それぞれ1台ずつWindows
         Serverインスタンス (t3.small) を作成します。
       - aws_eip: Elastic
         IPアドレスを1つ作成しますが、プラン上では特定のインスタンスへの関連付けは行われていません。
   - IAM:
       - aws_iam_role & aws_iam_instance_profile: EC2インスタンスがSSM（Systems
         Manager）を利用するためのIAMロールとインスタンスプロファイルを作成します。
       - aws_iam_role_policy_attachment: 作成したIAMロールに AmazonSSMManagedInstanceCore
         ポリシーをアタッチし、SSMによるインスタンス管理を有効化します。
   - Security Groups:
       - aws_security_group: 2つのセキュリティグループを作成します。
           - public_win_sg: 特定のIPアドレス (***.***.***.***/32) からのRDP（ポート
             3389）アクセスを許可します。
           - private_win_sg:
             パブリックインスタンスが属するセキュリティグループからのRDPアクセスを許可します（踏み台構成）。

  ベストプラクティス検証

   - 判定:

  全体として、基本的な多層ネットワーク構成（踏み台構成）におけるAWSのベストプラクティスに概ね準拠しています。
  特に、セキュリティグループのイングレス（インバウンド）ルールが適切に制限されている点は高く評価できます。

   - 推奨される改善点:
       1. NAT Gatewayの検討: プライベートサブネット内のインスタンス (private_win)
          がOSのアップデートなどでインターネットへのアウトバウンド通信を必要とする場合、NAT
          Gatewayの設置を推奨します。現状の構成では、プライベートサブネットからインターネットへのアクセスはで
          きません。
       2. Security Group Egressルールの厳格化: 現在、アウトバウンド（Egress）ルールが全開放 (0.0.0.0/0)
          になっています。セキュリティをさらに向上させるため、HTTP/HTTPS (80/443)
          など、必要な通信先にのみ許可することを検討してください。
       3. SSM Session Managerの活用:
          インスタンスにはSSMエージェントの利用に必要なIAMロールが付与されています。セキュリティグループでRDP
          ポート (3389) を開ける代わりに、よりセキュアなSSM Session
          Manager経由でインスタンスに接続することを強く推奨します。これにより、RDPポートを閉じたまま運用でき
          ます。
       4. 網羅的なタグ付け: Name タグは設定されていますが、コスト管理やリソース識別のために、Environment (例:
          production, development) や Project などの追加タグを検討してください。
       5. EBSボリュームの暗号化: EBSボリュームの暗号化 (encrypted = true)
          はベストプラクティスに沿っており、適切に設定されています。

   - 懸念事項または注意が必要な変更:
       - Elastic IP (EIP) の用途: aws_eip.public_win_ip
         が作成されていますが、プラン上ではどのリソースにもアタッチされていません。パブリックインスタンスに固
         定IPアドレスが必要な場合は、明示的に関連付ける必要があります。不要な場合は、このリソースを削除しない
         と料金が発生します。
       - AMIの選定: 使用されているAMI (ami-068c79625bf7eca7a)
         が、組織の基準で承認された最新のものであるかを確認してください。

  実装判定

   - このプランは本番環境への適用に適しているか:

  条件付きで適していると言えます。上記の「推奨される改善点」と「懸念事項」をレビューし、必要な修正を行った上
  で適用することが望ましいです。特にNAT Gatewayの要否とSSM Session
  Managerの活用は、本番運用におけるセキュリティとメンテナンス性に大きく影響します。

   - 追加確認が必要な項目:
       1. プライベートサブネットからのアウトバウンド通信要件の有無（NAT Gatewayの必要性）。
       2. 作成されるEIPの用途と、パブリックインスタンスへのアタッチ要否。
       3. RDPポートを開放せず、SSM Session Managerを利用した運用が可能かどうかの検討。

変更サマリーについて、デプロイ前の terraform plan なので新規作成リソース数がカウントされています。
詳細な変更内容として、どのようなリソースが作成されるかの説明があり、ベストプラクティス検証として改善点などを提示。最後に実装判定としてデプロイして構わないレベルか、評価結果を出力してくれています。

5.まとめ

Gemini CLI の Custom commands について、簡単な説明と実装例をご紹介しました。
今回は試験的な実装例にとどまりましたが、日常的に繰り返している実際の作業を Custom commands の形でテンプレート化すれば、その後は都度の手作業が不要になります。
Gemini CLI の GEMINI.md のようなコンテキストファイルも組み合わせれば、より強力な効率化ツールとして活用できるかもしれません。興味が湧いたら、ぜひ試してみてください。