目次
1.はじめに
2.前提事項
3.Claude CodeでのSkillの作成と設定
4.Gemini CLIでのSkillの設定
5.Agent Skillsの実行
6.おわりに
1.はじめに
Agent Skills とは Anthropic によって開発された AI エージェントの能力を拡張する機能です。
Agent Skills の設定ファイルに作業手順や目的に応じたルールを定義しておくことで、AI に指示を出した際、その指示の内容から AI が Agent Skills を使うべきか自動判定し、必要な場合 Agent Skills を使った処理を実行します。(設定ファイルの構文情報は Agent Skills の What are skills? を参照)
Gemini CLI でいうところの Custom commands や gemini.md のようなコンテキストファイルと似た機能のように感じますが、Agent Skills は Custom Commands のようにユーザーが明示的にコマンド指定する必要がなく、また、gemini.md であれば、その内容が常時 AI に参照されますが、Agent Skills の場合、指示の中で必要な時だけ参照されるものとなります。
Agent Skills は2025年12月にオープンスタンダード化し、本ブログ執筆時点では、Gemini CLI でもプレビュー版で使用できるようになりました。
簡単な Agent Skills の説明は以上です。
本ブログでは Claude Code で skill-creator を使い Agent Skills の Skill を作成。
その Skill を Claude Code と Gemini CLI に設定し、それぞれ実行してみた結果を紹介します。
(Claude Code と Gemini CLI で使う Skill の内容は同じとします。 Skill の機能としては、AWS アカウント内のリソース使用実態有無を調査するものとします)
2.前提事項
動作環境や利用モデル等については以下の通りです。
動作環境
- macOS:Sequoia 15.7.3
- Node.js のバージョン(
node --version):24.11.1 - Claude Code のバージョン(
claude --version):2.1.4 - Gemini CLI のバージョン(
gemini --version):0.24.0-preview.0
利用モデル
- Claude Code の利用モデル:Sonnet 4.5
- Gemini CLI の利用モデル:Gemini 3 を含んだ Auto モード
事前準備
- Claude Code と Gemini CLI に MCP を設定:AWS API MCP Server と AWS Knowledge MCP Server
- AWS 認証情報を ~/.aws/credentials に設定済み(ReadOnlyAccess 権限付与)
Agent Skillsのファイル構成方針
- Agent Skills の設定ファイルについて、特定プロジェクトのルートディレクトリに作成します。Claude Code については plugin 経由の自動作成、Gemini CLI については.gemini/skills/ディレクトリを手動作成し、そこにClaude Code で作った Skill のフォルダと設定ファイルをコピーし格納します。
3.Claude CodeでのSkillの作成と設定
Claude Code では Anthropic が公開している skill-creator という plugin を使用します。
.claude/skillsディレクトリに自作したマークダウンファイルを直接配置する方法もありますが、この plugin を活用すれば Claude Code との対話で Skill の構文に沿ったマークダウンファイルが自動作成されます。(ここで作成した設定ファイルの内容をコピーし Gemini CLI でも使用します)
では Skill の作成に進みます。
Claude Code を立ち上げます。

plugin をインストールします。
❯ /plugin marketplace add anthropics/skills ⎿ Successfully added marketplace: anthropic-agent-skills ❯ /plugin install example-skills@anthropic-agent-skills ⎿ ✓ Installed example-skills. Restart Claude Code to load new plugins.
/skillsコマンドを実行し、Plugin skills (plugin) の中に skill-creator が存在していることを確認しました。
❯ /skills ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Skills 16 skills Plugin skills (plugin) 〜〜省略〜〜 skill-creator · ~64 tokens webapp-testing · ~59 tokens
続いて、この skill-creater を使って Skill の設定ファイルを作っていきます。
以下を実行しました。
引数設定が適切でなかったのですが、そこは AI が調整してくれました。
その後のやりとりは長いため所々省略としてますが、Skill の設定ファイル作成のためのヒアリングと設定ファイル作成を実行しています。
❯ /skill-creator name--name aws-unused-resource-searcher --description "AWS アカウント内のリソース利用状況を分析し、一定期間アクティビティが確認されない EC2、EBS、NAT Gateway、ALB、NLB などの未使用リソース候補を検出する。CloudWatch メトリクスおよび AWS API 情報を用いて、削除可能性を一覧で出力する。" ⏺ skill-creator スキルが読み込まれました。提供された引数の形式が想定と少し異なっていますが、内容は理解できました。 〜〜省略〜〜 AWS未使用リソース検出スキルを作成していきましょう。スキル作成プロセスに従って進めます。 Step 1: 具体例の理解 まず、このスキルの具体的な使用例を確認させてください。 〜〜省略〜〜 ⏺ Step 2: 再利用可能なコンテンツの計画 このスキルで必要なリソースを分析しました: SKILL.md: - メインワークフロー(リソース一覧取得 → メトリクス分析 → 未使用判定 → レポート出力) - 各リソースタイプの分析手順の概要 references/: - metrics.md: 各リソースタイプ(EC2, EBS, NAT Gateway, ALB, NLB)のCloudWatchメトリクス名と未使用判定基準の詳細 〜〜省略〜〜 ⏺ Step 3: スキルの初期化 init_skill.pyスクリプトを実行して、スキルの構造を作成します。まず、スクリプトの場所を確認します。 〜〜省略〜〜 ⏺ Step 4: スキルの編集 まず、生成されたSKILL.mdを確認します。 〜〜省略〜〜 ⏺ SKILL.mdの編集が完了しました。次に、references/metrics.mdを作成します。 〜〜省略〜〜 ⏺ スキルの編集が完了しました。最終的なディレクトリ構造を確認します。 〜〜省略〜〜
.claude/skills/フォルダに /aws-unused-resource-searcher/SKILL.md と /aws-unused-resource-searcher/references/metrics.md が作成されました。
ディレクトリ構造は以下です。
QAX案件/
└── .claude/
└── skills/ # 各種 Agent Skills の定義を格納するディレクトリ
└── aws-unused-resource-searcher/ # AWS未使用リソース検出 Skill の定義ディレクトリ
├── SKILL.md # AWS未使用リソース検出 Skill のメイン定義ファイル(EC2、EBS、NAT Gateway、ALB、NLBの未使用リソースを検出)
└── references/ # Skill で使用するリファレンスドキュメントを格納するディレクトリ
└── metrics.md # CloudWatchメトリクスと未使用リソース判定基準の詳細仕様ドキュメント
作成された SKILL.md と metrics.md の内容を見ていきます。
まず SKILL.md の内容としては、
- この Skill の目的(AWS アカウント内の未使用リソース候補を検出する)
- どんな前提で動くのか(東京リージョン固定、CloudWatch メトリクスを使用、削除候補を探す)
- 実行時の流れ(リソース一覧取得 → メトリクス分析 → 未使用判定 → レポート出力)
- 最終的にどんな形式の結果を返すのか
が定義されています。詳細は以下です。
---
name: aws-unused-resource-searcher
description: AWSアカウント内のリソース利用状況を分析し、一定期間アクティビティが確認されない未使用リソース候補(EC2、EBS、NAT Gateway、ALB、NLB)を検出する。CloudWatchメトリクスとAWS API情報を用いて、削除可能性を一覧で出力する。ユーザーがAWSの未使用リソースチェック、コスト削減機会の発見、リソース利用率の分析、または未使用インフラのクリーンアップを依頼した際に使用する。
---
# AWS 未使用リソース検出
## 概要
AWSアカウント内のリソース利用パターンを分析し、設定可能な分析期間(デフォルト:5日間)において、顕著なアクティビティが見られないEC2、EBS、NAT Gateway、ALB、NLBリソースを特定します。このスキルは、利用実態のないリソースを削除候補とすべき技術検証用アカウント向けに設計されています。
## 前提条件
- mcp.jsonにAWS API MCP Serverが設定されていること
- EC2、EBS、ELB、CloudWatchへの読み取り権限を持つ適切なAWS認証情報
## メインワークフロー
1. **分析パラメータの確認**
- 分析期間(デフォルト:5日間)
- 対象リソースタイプ(デフォルト:全サポート対象)
- 対象リージョン:東京(ap-northeast-1)固定
2. **リソースインベントリの取得**
- AWS API MCPツールを使用して、対象タイプの全リソースを一覧取得
- リソースメタデータ(ID、タイプ、状態、タグなど)を収集
3. **CloudWatchメトリクスの分析**
- 各リソースについて、分析期間中の関連CloudWatchメトリクスを取得
- 使用状況統計(平均、最大、合計)を計算
- 詳細なメトリクス名と閾値は [metrics.md](references/metrics.md) を参照
4. **未使用リソースの特定**
- リソース固有の基準を適用して、未使用かどうかを判定
- すべての基準が未使用を示す場合、削除候補としてフラグ付け
- リソースタイプと信頼度レベルで分類
5. **レポート生成**
- 以下のカラムを持つマークダウンテーブルで出力:
- リソースタイプ
- リソースID
- ステータス/状態
- 主要メトリクスサマリー
- 削除候補(Yes/No)
- 可読性向上のためリソースタイプごとにグループ化
- 最後にサマリー統計を含める
## リソースタイプ
### EC2インスタンス
**未使用判定基準:**
- CPUUtilization 平均 < 5% かつ 最大 < 10%
- NetworkIn + NetworkOut 合計 < 100 MB(期間内)
- インスタンス状態が "stopped" または上記基準を満たす
**CloudWatchメトリクス:**
- CPUUtilization
- NetworkIn
- NetworkOut
### EBSボリューム
**未使用判定基準:**
- ボリュームがインスタンスにアタッチされていない
- または(アタッチされている場合):VolumeReadOps + VolumeWriteOps = 0(期間内)
**CloudWatchメトリクス:**
- VolumeReadOps
- VolumeWriteOps
### NATゲートウェイ
**未使用判定基準:**
- BytesInFromSource + BytesInFromDestination 合計 < 1 MB(期間内)
- ActiveConnectionCount 最大 = 0
**CloudWatchメトリクス:**
- BytesInFromSource
- BytesInFromDestination
- ActiveConnectionCount
### Application Load Balancer(ALB)
**未使用判定基準:**
- ActiveConnectionCount 最大 = 0
- ProcessedBytes 合計 < 1 MB(期間内)
- TargetConnectionErrorCount = 0(接続試行なし)
**CloudWatchメトリクス:**
- ActiveConnectionCount
- ProcessedBytes
- TargetConnectionErrorCount
- RequestCount
### Network Load Balancer(NLB)
**未使用判定基準:**
- ActiveFlowCount 最大 = 0
- ProcessedBytes 合計 < 1 MB(期間内)
**CloudWatchメトリクス:**
- ActiveFlowCount
- ProcessedBytes
- NewFlowCount
## 出力フォーマット例
markdown
## AWS 未使用リソース分析レポート
**分析期間:** 2026-01-06 から 2026-01-11(5日間)
**リージョン:** ap-northeast-1(東京)
### EC2インスタンス
| リソースID | 状態 | 平均CPU (%) | ネットワークI/O (MB) | 削除候補 |
|-------------|-------|-------------|---------------------|---------|
| i-abc123 | stopped | N/A | N/A | Yes |
| i-def456 | running | 2.1 | 15 | Yes |
### EBSボリューム
| リソースID | アタッチ先 | 読み書き操作数 | 削除候補 |
|-------------|-----------|--------------|---------|
| vol-xyz789 | None | 0 | Yes |
### サマリー
- 分析対象リソース総数: 15
- 削除候補: 3
## 詳細メトリクスリファレンス
各リソースタイプのCloudWatchメトリクス、閾値、判定ロジックの包括的な詳細は、[metrics.md](references/metrics.md) を参照してください。
続いて、metrics.md の内容は、
- どの CloudWatch メトリクスを見るか
- どの数値を超えたら(下回ったら)「未使用」と判断するか
- MCP(AWS API MCP Server)での取得イメージ
といった判定ロジックの詳細仕様が定義されています。
# CloudWatchメトリクスと未使用リソース判定基準
このドキュメントでは、サポート対象の各AWSリソースタイプに対するCloudWatchメトリクス、閾値、未使用リソース判定ロジックの詳細仕様を提供します。
## 一般的な分析アプローチ
各リソースについて:
1. 指定された分析期間(デフォルト:5日間)のCloudWatchメトリクスを取得
2. 関連する統計値を計算:平均、最大、合計(メトリクスに応じて適切なもの)
3. リソース固有の閾値を適用して、未使用かどうかを判定
4. 該当リソースタイプのすべての基準が満たされた場合、削除候補としてマーク
## EC2インスタンス
### CloudWatchメトリクス
| メトリクス名 | 名前空間 | 統計 | 単位 | 説明 |
|-------------|---------|------|------|------|
| CPUUtilization | AWS/EC2 | Average, Maximum | Percent | CPU使用率 |
| NetworkIn | AWS/EC2 | Sum | Bytes | 受信ネットワークトラフィック |
| NetworkOut | AWS/EC2 | Sum | Bytes | 送信ネットワークトラフィック |
### 未使用判定基準
EC2インスタンスは、以下のいずれかの条件を満たす場合に未使用と判定されます:
**条件1:停止中のインスタンス**
- インスタンス状態が "stopped"
**条件2:低アクティビティ(実行中のインスタンス)**
- CPUUtilization 平均 < 5% **かつ**
- CPUUtilization 最大 < 10% **かつ**
- (NetworkIn + NetworkOut) 合計 < 100 MB(分析期間内)
### MCPツール使用例
# EC2インスタンス一覧を取得
AWS MCPツールを使用: ec2:DescribeInstances
# CPUメトリクスを取得
AWS MCPツールを使用: cloudwatch:GetMetricStatistics
パラメータ:
- Namespace: AWS/EC2
- MetricName: CPUUtilization
- Dimensions: [{"Name": "InstanceId", "Value": "i-xxxxx"}]
- StartTime: <5日前>
- EndTime: <現在>
- Period: 3600 (1時間)
- Statistics: ["Average", "Maximum"]
# ネットワークメトリクスを取得(NetworkInとNetworkOutで繰り返し)
AWS MCPツールを使用: cloudwatch:GetMetricStatistics
パラメータ:
- Namespace: AWS/EC2
- MetricName: NetworkIn
- Dimensions: [{"Name": "InstanceId", "Value": "i-xxxxx"}]
- Period: 3600
- Statistics: ["Sum"]
## EBSボリューム
### CloudWatchメトリクス
| メトリクス名 | 名前空間 | 統計 | 単位 | 説明 |
|-------------|---------|------|------|------|
| VolumeReadOps | AWS/EBS | Sum | Count | 読み取り操作回数 |
| VolumeWriteOps | AWS/EBS | Sum | Count | 書き込み操作回数 |
### 未使用判定基準
EBSボリュームは、以下のいずれかの条件を満たす場合に未使用と判定されます:
**条件1:未アタッチのボリューム**
- ボリューム状態が "available"(どのインスタンスにもアタッチされていない)
**条件2:I/Oアクティビティなし(アタッチ済みボリューム)**
- ボリュームがアタッチされている **かつ**
- VolumeReadOps 合計 = 0(分析期間内)**かつ**
- VolumeWriteOps 合計 = 0(分析期間内)
### MCPツール使用例
# EBSボリューム一覧を取得
AWS MCPツールを使用: ec2:DescribeVolumes
# アタッチ状態を確認
DescribeVolumesレスポンスの "Attachments" フィールドを確認
# I/Oメトリクスを取得(アタッチされている場合)
AWS MCPツールを使用: cloudwatch:GetMetricStatistics
パラメータ:
- Namespace: AWS/EBS
- MetricName: VolumeReadOps (または VolumeWriteOps)
- Dimensions: [{"Name": "VolumeId", "Value": "vol-xxxxx"}]
- Period: 3600
- Statistics: ["Sum"]
## NATゲートウェイ
### CloudWatchメトリクス
| メトリクス名 | 名前空間 | 統計 | 単位 | 説明 |
|-------------|---------|------|------|------|
| BytesInFromSource | AWS/NATGateway | Sum | Bytes | クライアントから受信したバイト数 |
| BytesInFromDestination | AWS/NATGateway | Sum | Bytes | 宛先から受信したバイト数 |
| ActiveConnectionCount | AWS/NATGateway | Maximum | Count | アクティブな同時接続数 |
### 未使用判定基準
NATゲートウェイは、以下のすべての条件を満たす場合に未使用と判定されます:
- (BytesInFromSource + BytesInFromDestination) 合計 < 1 MB(分析期間内)**かつ**
- ActiveConnectionCount 最大 = 0(分析期間内)
### MCPツール使用例
# NATゲートウェイ一覧を取得
AWS MCPツールを使用: ec2:DescribeNatGateways
# メトリクスを取得
AWS MCPツールを使用: cloudwatch:GetMetricStatistics
パラメータ:
- Namespace: AWS/NATGateway
- MetricName: BytesInFromSource (他のメトリクスでも繰り返し)
- Dimensions: [{"Name": "NatGatewayId", "Value": "nat-xxxxx"}]
- Period: 3600
- Statistics: ["Sum"] または ["Maximum"](メトリクスに応じて)
## Application Load Balancer(ALB)
### CloudWatchメトリクス
| メトリクス名 | 名前空間 | 統計 | 単位 | 説明 |
|-------------|---------|------|------|------|
| ActiveConnectionCount | AWS/ApplicationELB | Maximum | Count | アクティブな同時接続数 |
| ProcessedBytes | AWS/ApplicationELB | Sum | Bytes | 処理された合計バイト数 |
| RequestCount | AWS/ApplicationELB | Sum | Count | リクエスト数 |
| TargetConnectionErrorCount | AWS/ApplicationELB | Sum | Count | ターゲットへの接続失敗数 |
### 未使用判定基準
ALBは、以下のすべての条件を満たす場合に未使用と判定されます:
- ActiveConnectionCount 最大 = 0(分析期間内)**かつ**
- ProcessedBytes 合計 < 1 MB(分析期間内)**かつ**
- RequestCount 合計 = 0(分析期間内)
### MCPツール使用例
# ALB一覧を取得
AWS MCPツールを使用: elbv2:DescribeLoadBalancers
フィルター: Type = "application"
# メトリクスを取得
AWS MCPツールを使用: cloudwatch:GetMetricStatistics
パラメータ:
- Namespace: AWS/ApplicationELB
- MetricName: ActiveConnectionCount (他のメトリクスでも繰り返し)
- Dimensions: [{"Name": "LoadBalancer", "Value": "app/my-alb/xxxxx"}]
- Period: 3600
- Statistics: ["Maximum"] または ["Sum"](メトリクスに応じて)
## Network Load Balancer(NLB)
### CloudWatchメトリクス
| メトリクス名 | 名前空間 | 統計 | 単位 | 説明 |
|-------------|---------|------|------|------|
| ActiveFlowCount | AWS/NetworkELB | Maximum | Count | アクティブな同時フロー数 |
| ProcessedBytes | AWS/NetworkELB | Sum | Bytes | 処理された合計バイト数 |
| NewFlowCount | AWS/NetworkELB | Sum | Count | 新規に確立されたフロー数 |
### 未使用判定基準
NLBは、以下のすべての条件を満たす場合に未使用と判定されます:
- ActiveFlowCount 最大 = 0(分析期間内)**かつ**
- ProcessedBytes 合計 < 1 MB(分析期間内)
### MCPツール使用例
# NLB一覧を取得
AWS MCPツールを使用: elbv2:DescribeLoadBalancers
フィルター: Type = "network"
# メトリクスを取得
AWS MCPツールを使用: cloudwatch:GetMetricStatistics
パラメータ:
- Namespace: AWS/NetworkELB
- MetricName: ActiveFlowCount (他のメトリクスでも繰り返し)
- Dimensions: [{"Name": "LoadBalancer", "Value": "net/my-nlb/xxxxx"}]
- Period: 3600
- Statistics: ["Maximum"] または ["Sum"](メトリクスに応じて)
## 重要な注意事項
### 期間の選択
- CloudWatchメトリクスの期間(Period)には3600秒(1時間)を使用
- これにより、API呼び出しを適切に保ちながら十分な粒度を提供
- 5日間の分析期間では、メトリクスごとに120データポイントになる
### 欠損データの扱い
- CloudWatchがメトリクスのデータポイントを返さない場合、以下の可能性があります:
- リソースが最近作成された(分析期間内)
- CloudWatchメトリクスが公開されていない(問題の可能性)
- リソースが本当にゼロアクティビティ
- このような場合、欠損データは保守的に扱う:他の証拠が支持する場合のみ削除候補としてマーク(例:停止中のインスタンス、未アタッチのボリューム)
### リージョンに関する考慮事項
- 対象リージョンは東京リージョン(ap-northeast-1)固定
- すべてのAPI呼び出しでリージョンとして ap-northeast-1 を指定
続いて Claude Code で/skillsコマンドを実行してみます。
設定ファイルを用意できたので、一覧に表示されるはずです。

Project skills として作成した aws-unused-resource-searcher が表示されています。
以上で Skill の作成と Claude Code での利用設定ができました。
続いて Gemini CLI の設定に進みます。
4.Gemini CLIでのSkillの設定
本ブログ執筆時点では、Gemini CLI の安定版は Agent Skills に対応していません。
試しに見てみます。安定版の最新バージョンをインストールします。
$ npm install -g @google/gemini-cli@latest 〜〜省略〜〜 $ gemini --version 0.23.0
Gemini CLI を立ち上げ、/settingsコマンドを実行します。
Gemini CLI の Agent Skills のドキュメントより/settingsコマンドで Agent Skills 機能を有効化する必要があるのですが、Agent Skills の項目がありませんでした。
※1/14に0.24.0(安定版)がリリースされました。0.24.0では設定項目にAgent Skillsが表示されます。

Gemini CLI を閉じ、プレビュー版をインストールします。
$ npm install -g @google/gemini-cli@preview 〜〜省略〜〜 $ gemini --version 0.24.0-preview.0
再度 Gemini CLI を立ち上げ、/settingsコマンドを実行したところ、Agent Skills が見つかりました。
デフォルトだと Agent Skills は false になっているので有効化します。

Agent Skills を選択、エンターボタン押下で false から true とし、エスケープボタン押下で設定から抜けます。

/quitコマンドで一度 Gemini CLI を閉じます。

再度 Gemini CLI を立ち上げます。

/skills と入力すると skills に関するコマンドオプションが出力されました。
list List available agent skills. Usage: /skills list [nodesc] disable Disable a skill by name. Usage: /skills disable <name> enable Enable a disabled skill by name. Usage: /skills enable <name> reload Reload the list of discovered skills. Usage: /skills reload
試しに list を実行してみます。
現時点では Agent Skills を有効化しただけで、稼働に必要な設定をしていません。

No skills available と出力されています。
list コマンドで Skill が表示されるよう設定ファイルの設定に進みます。
Gemini CLI の設定ファイルについてはフォルダを手動作成し、そこに Claude Code の plugin(skill-creator)で作成されたフォルダ、マークダウンファイルをコピーし格納しました。
ディレクトリ構造は以下です。(差分は .claude と .gemini のみです)
DEF案件/
└── .gemini/
└── skills/ # 各種 Agent Skills の定義を格納するディレクトリ
└── aws-unused-resource-searcher/ # AWS未使用リソース検出 Skill の定義ディレクトリ
├── SKILL.md # AWS未使用リソース検出 Skill のメイン定義ファイル(EC2、EBS、NAT Gateway、ALB、NLBの未使用リソースを検出)
└── references/ # Skill で使用するリファレンスドキュメントを格納するディレクトリ
└── metrics.md # CloudWatchメトリクスと未使用リソース判定基準の詳細仕様ドキュメント
Gemini CLI を立ち上げて、/skills listコマンドを実行します。

以下の通り利用可能 Skill が出力されました。
> /skills list
Available Agent Skills:
- aws-unused-resource-searcher
AWSアカウント内のリソース利用状況を分析し、一定期間アクティビティが確認されない未使用リソース候補(EC2、EBS、NAT Gateway、ALB、NLB)を検出する。CloudWatchメトリクスとAWS
API情報を用いて、削除可能性を一覧で出力する。ユーザーがAWSの未使用リソースチェック、コスト削減機会の発見、リソース利用率の分析、または未使用インフラのクリーンアップを依頼した際に使用する。
これで Claude Code と Gemini CLI への Agent Skills の設定ができました。
続いて実際に作成した Skill を実行してみます。
5.Agent Skillsの実行
今回作成した Skill は AWS アカウント内の不要リソース有無調査の機能を定義したものなので、あらかじめAWSリソースを作成しておきます。
以下のリソースを作成しました。
- NAT Gateway を1つ
- ALB を1つ
- EC2 を2つ(EBS は計3つ)


これらのリソースですが、Skill の設定後、Skill の利用検証のために新規作成したものとなります。
そのため AWS アカウント内での残存期間が短く、つまり新規リソースであるため、これから使用されるリソース群と AI に判定され、全て削除外と評価されるかもしれませんが、どのように評価されるか、Skill を動かしてみます。
Claude Code と Gemini CLI に入力するプロンプトは以下です。
不要リソース調査をしてください
AI による Skill 使用判定は SKILL.md の description の内容に依拠します。
今回作成した SKILL.md では 「〜ユーザーがAWSの未使用リソースチェック〜を依頼した際に使用する。」と定義しているので、上記プロンプトの文言で Skill を使用してくれるはずです。
Claude CodeでSkillを実行
Claude Code を立ち上げました。

プロンプトを入力、実行するとさっそく今回作成した Skill の使用を選定してくれました。
使用を許可します。

Skill 使用中の挙動は以下です。
内容が長いため省略してますが、定義した内容に沿って処理を実行してくれています。
❯ 不要リソース調査をしてください
⏺ AWSの不要リソース調査を実行します。
⏺ Skill(aws-unused-resource-searcher)
⎿ Successfully loaded skill
⏺ AWS未使用リソース調査を開始します。分析期間5日間、対象リージョンは東京(ap-northeast-1)で実行します。
⏺ Bash(aws ec2 describe-instances --region ap-northeast-1 --output json)
⎿ {
"Reservations": [
{
… +328 lines (ctrl+o to expand)
⏺ EC2インスタンスを2つ検出しました。次にEBSボリュームを取得します。
⏺ Bash(aws ec2 describe-volumes --region ap-northeast-1 --output json)
⎿ {
"Volumes": [
{
… +103 lines (ctrl+o to expand)
〜〜省略〜〜
⏺ リソース情報を取得しました。次にCloudWatchメトリクスを分析します。
⏺ Bash(aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization --dimensions
Name=InstanceId,Value=i-096fce3e15b01b2db --start-time 2026-0…)
〜〜省略〜〜
⏺ CloudWatchメトリクスの分析が完了しました。次に未使用リソースを特定してレポートを生成します。
リソース調査完了後、調査結果のレポートを出力しています。
⏺ AWS 未使用リソース分析レポート
分析期間: 2026-01-06 から 2026-01-11(5日間)
リージョン: ap-northeast-1(東京)
分析実施日: 2026-01-11
---
⚠️ 重要な注意事項
検出されたすべてのリソースは 2026-01-11 に作成されており、分析期間(5日間)に対して 1日未満のデータ しか存在しません。そのため、この分析結果は限定的であり、より正確な判定には数日間のデータ収集が必要です。
---
EC2インスタンス
リソースID: i-096fce3e15b01b2db
名前: om-prd-skill-test2-01
状態: running
平均CPU (%): 32.5
最大CPU (%): 72.1
ネットワークI/O (MB): 94.0
削除候補: No
────────────────────────────────────────
リソースID: i-072d5365acaea1f10
名前: om-prd-skill-test-01
状態: running
平均CPU (%): 50.2
最大CPU (%): 77.1
ネットワークI/O (MB): 88.2
削除候補: No
判定基準: CPU平均 < 5% かつ 最大 < 10% かつ ネットワークI/O < 100 MB
結果: すべてのEC2インスタンスがアクティブに使用されています。
---
EBSボリューム
リソースID: vol-01c775d75c583c482
名前: om-prd-skill-test2-01-data
アタッチ先: i-096fce3e15b01b2db
読み取り操作数: 58
書き込み操作数: 0
削除候補: No
────────────────────────────────────────
リソースID: vol-0bb1625c0c732d3f5
名前: om-prd-skill-test-01-root
アタッチ先: i-072d5365acaea1f10
読み取り操作数: 183,474
書き込み操作数: 52,248
削除候補: No
────────────────────────────────────────
リソースID: vol-0480a82d94732d3da
名前: om-prd-skill-test2-01-root
アタッチ先: i-096fce3e15b01b2db
読み取り操作数: 183,439
書き込み操作数: 44,963
削除候補: No
判定基準: アタッチなし または 読み取り操作数 + 書き込み操作数 = 0
結果: すべてのEBSボリュームがアクティブに使用されています。
---
NAT Gateway
リソースID: nat-0f08b15f7e84df58f
名前: main-nat-gw
状態: available
BytesInFromSource (MB): 1.3
BytesInFromDestination (MB): 91.6
合計トラフィック (MB): 92.9
最大アクティブ接続数: 19
削除候補: No
判定基準: 合計トラフィック < 1 MB かつ 最大アクティブ接続数 = 0
結果: NAT Gatewayはアクティブに使用されています。
---
Application Load Balancer (ALB)
┌──────────────────┬────────┬──────────────┬───────────────────┬──────────────────────┬──────────┐
│ リソース名 │ 状態 │ リクエスト数 │ 処理バイト数 (MB) │ 最大アクティブ接続数 │ 削除候補 │
├──────────────────┼────────┼──────────────┼───────────────────┼──────────────────────┼──────────┤
│ om-prd-skill-alb │ active │ 0 │ 0 │ 0 │ Yes │
└──────────────────┴────────┴──────────────┴───────────────────┴──────────────────────┴──────────┘
判定基準: リクエスト数 = 0 かつ 処理バイト数 < 1 MB かつ 最大アクティブ接続数 = 0
結果: ALBは分析期間中、トラフィックが全く発生していません。削除候補として検討してください。
---
Network Load Balancer (NLB)
検出されたNLBはありません。
---
サマリー
┌──────────────────────┬─────┐
│ 項目 │ 値 │
├──────────────────────┼─────┤
│ 分析対象リソース総数 │ 7 │
├──────────────────────┼─────┤
│ EC2インスタンス │ 2 │
├──────────────────────┼─────┤
│ EBSボリューム │ 3 │
├──────────────────────┼─────┤
│ NAT Gateway │ 1 │
├──────────────────────┼─────┤
│ ALB │ 1 │
├──────────────────────┼─────┤
│ NLB │ 0 │
├──────────────────────┼─────┤
│ 削除候補リソース数 │ 1 │
└──────────────────────┴─────┘
---
削除候補リソース詳細
1. ALB: om-prd-skill-alb
- 理由: 分析期間中、リクエスト数が0で、トラフィックが全く発生していません
- 推奨アクション: 使用予定がない場合は削除を検討
- 注意: 作成後1日未満のため、アプリケーションの設定中の可能性があります
---
推奨事項
1. ALBの確認: om-prd-skill-alb が実際に使用される予定があるか確認してください。設定中の場合は数日後に再度分析することを推奨します。
2. 継続的なモニタリング: すべてのリソースが本日作成されたばかりのため、5〜7日後に再度分析を実施することで、より正確な使用状況を把握できます。
3. コスト最適化: 現在アクティブなリソース(EC2、NAT Gateway)については、必要性を定期的に見直すことでコスト削減の機会を特定できます。
⏺ AWS未使用リソース調査が完了しました。
主な発見:
- 分析対象リソース総数: 7
- 削除候補: 1件(ALB: om-prd-skill-alb)
重要な注意点:
すべてのリソースが本日(2026-01-11)作成されたばかりのため、5日間の分析期間に対して1日未満のデータしか存在しません。より正確な判定には、5〜7日後に再度分析を実施することを推奨します。
削除候補リソース:
- om-prd-skill-alb: リクエスト数が0で、トラフィックが全く発生していません。ただし、作成直後のため設定中の可能性があります。
EC2インスタンス、EBSボリューム、NAT Gatewayはすべてアクティブに使用されており、削除の必要はありません。
CloudWatch メトリクスと AWS API から EC2、EBS、NAT Gateway、ALB のリソース利用実態を分析した結果、ALB の削除を提案する内容となりました。
続いて Gemini CLI でも実行してみます。
Gemini CLIでSkillを実行
Gemini CLI を立ち上げました。

プロンプトを実行します。
Claude Code 同様、設定した Skill の使用を選定してくれています。

実行中の挙動は以下です。
内容が長いため省略してますが、定義した内容に沿って処理を実行してくれています。
> 不要リソース調査をしてください ✦ I'll activate the aws-unused-resource-searcher skill to perform a detailed investigation of unused AWS resources. ✓ Activate Skill "aws-unused-resource-searcher": AWSアカウント内のリソース利用状況を分析し、一定期間アクティビティが確認されない未使用リソース候補 〜〜省略〜〜 ✦ リソースの一覧を取得できました。次に、過去5日間(2026-01-06から2026-01-11)のCloudWatchメトリクスを分析して、各リソースの使用状況を確認します。まず、EC2 インスタンスのCPU使用率とネットワークトラフィックを確認します。 〜〜省略〜〜 ✦ メトリクスが得られませんでした。インスタンスのアタッチ時間が本日(2026-01-11)の08:22頃であることから、これらは起動したばかりのリソースである可能性があり ます。分析期間を直近の1時間に変更し、より細かい粒度(1分間隔)でアクティビティを確認します。併せて、EBS、NAT Gateway、ALBのメトリクスも確認します。 〜〜省略〜〜 ✦ EC2インスタンスとNAT Gatewayには一定のアクティビティが確認されましたが、ALB(om-prd-skill-alb)についてはリクエスト数が0となっており、未使用の可能性があります。より確実に判定 するため、ALBの接続数と処理バイト数、および残りのEBSボリュームのアクティビティを確認します。 〜〜省略〜〜 ✦ 調査の結果、ALB(om-prd-skill-alb)にアクティビティが確認されず、削除候補として特定されました。その他のリソース(EC2、EBS、NAT Gateway)については、本日起動されたばかりではありますが、一定の使用状況が確認されています。
リソース調査完了後、調査結果のレポートが出力されました。
内容としては Claude Code のものとほぼ同じで ALB の削除提案をしています。
AWS 未使用リソース分析レポート 分析期間: 2026-01-06 から 2026-01-11(5日間) リージョン: ap-northeast-1(東京) EC2インスタンス ※本日(08:22頃)起動されたリソースのため、直近1時間のアクティビティに基づき判定しています。 ┌─────────────────────┬─────────┬─────────────┬─────────────┬──────────┐ │ リソースID │ 状態 │ 平均CPU (%) │ 最大CPU (%) │ 削除候補 │ ├─────────────────────┼─────────┼─────────────┼─────────────┼──────────┤ │ i-096fce3e15b01b2db │ running │ 38.3% │ 91.1% │ No │ │ i-072d5365acaea1f10 │ running │ 27.4% │ 77.1% │ No │ └─────────────────────┴─────────┴─────────────┴─────────────┴──────────┘ EBSボリューム ┌───────────────────────┬─────────────────────┬──────────────────────┬──────────┐ │ リソースID │ アタッチ先 │ 読み取り操作数 (Sum) │ 削除候補 │ ├───────────────────────┼─────────────────────┼──────────────────────┼──────────┤ │ vol-01c775d75c583c482 │ i-096fce3e15b01b2db │ 59 │ No │ │ vol-0bb1625c0c732d3f5 │ i-072d5365acaea1f10 │ 284,814 │ No │ │ vol-0480a82d94732d3da │ i-096fce3e15b01b2db │ 390,195 │ No │ └───────────────────────┴─────────────────────┴──────────────────────┴──────────┘ NATゲートウェイ ┌───────────────────────┬───────────┬──────────────────────┬──────────┐ │ リソースID │ 状態 │ 最大アクティブ接続数 │ 削除候補 │ ├───────────────────────┼───────────┼──────────────────────┼──────────┤ │ nat-0f08b15f7e84df58f │ available │ 19 │ No │ └───────────────────────┴───────────┴──────────────────────┴──────────┘ Application Load Balancer (ALB) ┌──────────────────┬──────────────────┬──────────────┬──────────────┬──────────┐ │ リソースID │ 名前 │ リクエスト数 │ 処理バイト数 │ 削除候補 │ ├──────────────────┼──────────────────┼──────────────┼──────────────┼──────────┤ │ om-prd-skill-alb │ om-prd-skill-alb │ 0 │ 0 │ Yes │ └──────────────────┴──────────────────┴──────────────┴──────────────┴──────────┘ サマリー - 分析対象リソース総数: 7 - 削除候補: 1 (ALB: om-prd-skill-alb) EC2インスタンスおよびそれに関連するEBS、NAT Gatewayは活発に動作していますが、ALBについてはトラフィックが一切発生していないため、構成の見直しまたは削除を検討することをお勧めします。
6.おわりに
Claude Code と Gemini CLI で Agent Skills を実装し、実際に動作させてみました。
使用体験として、ユーザーが特定のコマンドや Skill 名を指定することなく、自然言語のプロンプトだけで最適な Skill を自動判定し、実行する仕組みがシームレスで良いと感じました。
まだ歴の浅い機能なので、今後のアップデートを注視しつつ Agent Skills 活用の可能性を探っていこうと思います。
本ブログが AI ツール活用の一助となれば幸いです。