ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

Kiro Powers vs Skills — TerraformエンジニアがIaCの観点で検証した

AWS Kiro Terraform Agent Skills Kiro Powers

はじめに

こんにちは、クラウドインテグレーション事業部の遅れてきたルーキー八木です。

昨今の生成AIのアップデートはまさに指数関数的な進化を見せておりますが、われらがKiroも昨年のリリース以来、凄まじい速さでアップデートをつづけております。

2025年のre:Invent にて、Kiro Powersが登場したのも束の間、2026年に入って早々、Skillsという機能が追加されました。

1月16日に Kiro CLIのバージョンアップに伴い Skills が追加

2月5日にKiro IDEでAgents Skillsがサポート

今回は、特に後者のKiro IDEのAgents Skillsを取り上げ、似たような機能を提供しているKiro Powersとの比較をTerraformを題材に行いたいと思います。

Agents Skills

公式ドキュメントによるとAgents Skills とは「エージェントに新たな機能や専門知識を付与するための、シンプルでオープンなフォーマット」と説明されています。

自分なりに解釈してみると、精度の高いタスクを実行できるように、Agentに対して、ドメイン知識や専用ツールなどを供給する仕組みといった感じでしょうか。

Agent Skillsは2025年10月にAnthropicがClaudeの新機能として発表しましたが、同年12月18日にはオープン・スタンダードとして公開されました。それに伴い、Microsoft、OpenAI、Atlassian、Figma、Cursor、GitHubといった主要プロバイダーが続々と採用し始めているといった状況です。(2026年3月時点) MCPと同じ流れですね。

詳しい説明は公式ドキュメントに譲りますが、Skillsの実体は以下のようなフォルダで構成されており、ベースとなっているのは SKILL.md ファイルです。

skill-name/
├── SKILL.md          # Required: metadata + instructions
├── scripts/          # Optional: executable code
├── references/       # Optional: documentation
├── assets/           # Optional: templates, resources
└── ...               # Any additional files or directories

SKILL.md ファイルには、Agentに付与したいドメイン知識やツールの詳細がMarkdown形式で記述されている他、参照させたいドキュメントやAgentに実行させたいスクリプト等で構成されています。

現在、このフォーマットに則るかたちで、各種ベンダーがGitHub上でAgents Skillsを公開しており、代表的なものに以下のようなSkillsがあります。

Skills名 リポジトリURL 主な用途
aws-agent-skills (Bedrock) aws-agent-skills/bedrock AWS BedrockのRAG構築、モデル推論、カスタムモデル支援
HashiCorp Agent Skills (Terraform全般) hashicorp/agent-skills/terraform Terraformモジュール生成、プロバイダ開発、コードレビュー
skill-creator-skill kdaisukem-wq/skills-4-kiro 新規Agent Skillsの自動生成

今回はこの中でもHashiCorp Agent Skills の内で、Terraform style-guide をKiroにインポートして使ってみたいと思います。

Let's Kiro！

本ブログでわかること

  • Kiro Skills の使い方
  • Kiro を使ったTerraform運用でPowers と Skillsにどんな違いがあるか

注意点

  • LLMの挙動を含む検証結果のため、今回の検証結果とお手元で実施した結果が必ずしも一致するとは限らない点にご留意ください。
  • あくまで全く同一のプロンプトを使って検証した結果の差分について分析していますので、プロンプトの工夫によって結果は異なる点にご注意願います。

導入編

検証環境は次の通りです。

サービス名 Version
Kiro 0.10.6
Terraform v1.14.3
AWS Provider v1.14.3

Kiro Skillsの導入

2026年3月現在でHashicorpが提供しているTerraformのAgent Skillsには以下のようなものがあります。

Skills名 主な用途 活用シーン スキル名
Code Generation HCLの生成と検証 ・新規リソースの定義
・既存コードの修正提案 		terraform-style-guide
terraform-test
azure-verified-modules
terraform-search-import
Module Generation モジュールの作成とリファクタリング 組織標準のテンプレート作成
コードの共通化 		refactor-module
terraform-stacks
Provider Development プロバイダーの開発支援 カスタムプロバイダーの開発
既存プロバイダーの保守 		new-terraform-provider
run-acceptance-tests
provider-actions
provider-resources
provider-test-patterns

まずはterraform-style-guideを導入します。

左メニューのKiroアイコン > AGENT STEERING & Skills > + ボタンをクリック

Agents Skillsの追加

他の機能同様に全てのKiroプロジェクト共通で適用するのであればGlobal、プロジェクト固有の場合は、Workspaceを指定してインポートします。

適用範囲に合わせてimport先を指定

Kiro Powers の導入

Kiro Powers については弊社ブログで解説しておりますので、詳しくはそちらをご覧ください。 本記事ではKiro PowersのDeploy infrastructure with Terraformの導入のみ扱います。

左ペインのKiro Powersアイコンから対象を検索して [+install ]を押下します。

Kiro Powersのインストール

インストール後はさらに [Try power] を押下し有効化する必要あります。 [Try power]を押下するとKiro Powersの各種ツールの使用可否を聞かれるので、すべてOKすると導入完了です。

Kiro Powersをactivate

「Deploy infrastructure with Terraform」ではMCPサーバーを使用するため、裏側でDocker daemonが動いている必要があります。Docker Desktopなどを使ってプロセスを起動しておいてください。

「Deploy infrastructure with Terraform」を適切にactivateされると、以下9つのMCPサーバーが起動しました。

（今回の検証では使ってませんが、GitHubのPower.mdの記述を見ると、HCP Terraform向けなど別用途のMCPサーバーが20個以上あるようです）

Deploy infrastructure with Terraform で使われるMCPサーバー

Powers VS Skills Round 1 - EFS作成

昨今のLLMは爆発的に賢くなっており、Terraformコードで単純なAWSリソースを作る程度では、Powers や Skills の優位性が発揮できなそうです。 そこで普段、筆者が実務で実施しているTerraformのインポート処理をお題に実力を検証してみたいと思います。

シナリオ

  1. EFSを作成する
  2. 作成したEFSをTerraform管理から除外
  3. マネジメントコンソールから作ったEFSをインポート

条件

  • プロンプトは全て共通とする
  • インポート対象となるEFS設定は全て共通とする

今回は比較のため何も導入してない**Plainの状態のKiro(以降は「Kiro Plain」と呼びます)**でも試してみます。 それではまずはじめにEFSの作成から始めていきます。 一言一句違わず以下のプロンプトを共通で用いました。

EFS作成のプロンプト

Kiro Plain - EFS作成

生成されたのは以下のファイルでした。

├── efs.tf　　       # EFS、マウントターゲット、セキュリティグループ、バックアップポリシー
├── main.tf 　       # terraformブロック、providerブロック  
├── outputs.tf　   # リソースID、EFSのDNS名
├── variables.tf　
└── vpc.tf　　    # VPC、プライベートサブネット

作成されたリソースは以下の8つです。

  • VPC
  • プライベートサブネットｘ2
  • EFS
  • マウントターゲットｘ2
  • EFSバックアップポリシー
  • マウントターゲット用セキュリティグループ

Kiro Powers - EFS作成

生成されたのは以下のファイルです。

├── main.tf             # VPC、プライベートサブネット、EFS、マウントターゲット、セキュリティグループ
├── outputs.tf　　# リソースID、EFSのDNS名
├── provider.tf       # Providerブロックのみ
├── variables.tf　　　
└── versions.tf　 # terraformブロックのみ

作成されたリソースは以下の7つです。

  • VPC
  • プライベートサブネットｘ2
  • EFS
  • マウントターゲットｘ2
  • マウントターゲット用セキュリティグループ

Kiro Skills - EFS作成

生成されたのは以下のファイルです。

.
├── README.md　　　　　    # AWSインフラ構成、デプロイ手順、EFSマウントコマンド等が記載
├── locals.tf
├── main.tf　　　　　　　　   # VPC、プライベートサブネット、EFS、マウントターゲット、セキュリティグループ　
├── outputs.tf
├── providers.tf　　　　　　   # providerブロック
├── terraform.tf　　                  # terraform ブロック
├── terraform.tfvars.example   # tfvarsの実装サンプル
└── variables.tf

作成されたリソースは以下の7つです。

  • VPC
  • プライベートサブネットｘ2
  • EFS
  • マウントターゲットｘ2
  • マウントターゲット用セキュリティグループ

コード生成における差分

違いが目立ったのは変数の扱いでした。 全てのパターンで、variables.tfを生成する点は共通ですが、Kiro Skillsの場合は terraform.tfvars で変数を一括管理する方式を取っており、もっとも運用しやすい実装になっていました。

さらに、Kiro Skillsではskill.md のFile Organization で明示的にファイル構成を定義しているだけあって、唯一、locals.tf を生成していました。 VPCのタグ実装を例にとると、Kiro Plain、Kiro Powersはプロジェクト名だけを変数化しているのに対し、Kiro Skillsはプロジェクト名と環境名が変数化されており、開発環境、本番環境の使い分けに適応したより実務的な実装となっていました。

## VPCのタグ実装 - Kiro Plain、Kiro Powers
  tags = {
    Name = "${var.project_name}-vpc"
  }

## VPCのタグ実装 - Kiro Skills
  tags = merge(local.common_tags, {
    Name = "${var.project_name}-${var.environment}-vpc"
  })

locals {
  common_tags = {
    Environment = var.environment
    Project     = var.project_name
  }
}

Powers VS Skills Round 2 - EFSインポート

次に作成したEFSをTerraform管理から外して、別途マネジメントコンソールからマニュアルで作成したEFSをインポートしてみようと思います。

EFSインポートの共通プロンプト

マニュアルで作成するEFSの設定は全てデフォルト値とし、マウントターゲットにはデフォルトセキュリティグループをアタッチしています。 インポートにあたり、Terraformで作成済みのセキュリティグループをそのまま流用したいので、どのような処理になるかもみていきます。

Kiro Plain - インポート編

Kiro Plainによるインポート作業の流れは以下の通りでした。

  1. terraform state rm コマンド を使ったstateファイルからの除外
  2. terraform import コマンドを使ったstateファイルへのインポート
  3. terraform plan による差分確認

基本的にはコマンドを使った手順を示してくれて、手順のコマンドを自分でターミナルで実行していくかたちとなりました。

Kiro Plain時のインポート作業のガイダンス

コマンドのコピペだけだとエラーした場合は、エラーメッセージを入れるとコマンドを修正してくれました。この辺りは純粋にバックエンドのLLM単体で解決できる範疇と思われます。

エラー解決

Kiro Powers - インポート編

Kiro Powersによるインポート作業の流れは以下の通りでした。

  1. terraform state rm コマンド を使ったstateファイルからの除外
  2. 自動生成された import.tf に実際のリソースIDを手入力
  3. 1回目の terraform plan でEFSがインポートではなく、リプレース（インポートしようとするEFSを削除して新規でEFS作成）
  4. creation tokenのエラーを指摘→コードの自動修正
  5. 2回目の terraform plan で意図した通りのインポート成功

terraform state rm で stateファイルから除外するところは一緒ですが、インポートではimportブロックを追加する方法を取っており、最新のベストプラクティスに沿った手順を提案してくれました。

importブロックを使ったインポート作業

と、ここまではよかったのですが、terraform planを実行するとリソースの再作成が発生する結果（破壊的変更）となってしまいました。これは意図せざる挙動です。

EFSの作成はAPIエラーなどによるリソース重複作成を防ぐため、 creation token が必要です。

空のファイルシステムを新しく作成します。このオペレーションでは、Amazon EFS がべき等の作成を保証するために使用するリクエストに作成トークンが必要です (同じ作成トークンを使用してオペレーションを呼び出しても効果はありません)。 [https://docs.aws.amazon.com/ja_jp/efs/latest/ug/API_CreateFileSystem.html:embed:cite]

Terraformでは裏側で自動生成されるため筆者も意識して運用してなかったのですが、今回、最初にEFSを作成したとき、この creation token をコード上で明示的に指定する実装になっていたため、stateファイルから除外したEFSの creation token がTerraformコード上に残ったままでした。

resource "aws_efs_file_system" "main" {
  creation_token = "quickCreated-xxxxxxxxxxxxxxxxxx"  # ←明示的に指定する実装になっていた
  encrypted      = true
  throughput_mode = "elastic"

  lifecycle_policy {
    transition_to_ia = "AFTER_30_DAYS"
  }

  tags = {
    Name = "${var.project_name}-efs"
  }
}

マネジメントコンソールから作成したEFSは当然、異なる creation token をもっているため、そのままインポートしようとすると、creation token の不一致により別リソースとして再作成という挙動になったと思われます。 ただこれに関しても、エラーを指摘すると即座にKiro側で修正してくれ、再作成とならないかたちでインポートを完了できたので、これはコード生成時にプロンプトで明示的に creation token を入れないなどと指示すれば回避可能と思われます。

creation tokenの不一致による破壊的変更の処理

マウントターゲットに適用されるセキュリティグループは既存コードをそのままapplyすれば、デフォルトセキュリティグループが上書きされるので、追加のアクションは不要でした。

terraform applyで既存のセキュリティグループ設定を上書き

Kiro Skills - インポート編

今回は、terraform-search-import というTerraformのインポート作業に特化した専用のSkillsがHashicorp公式からリリースされているためそちらを導入して検証します。

Skillsを使ったインポートの流れは以下の通りとなりました。

  1. terraform state rm コマンド を使ったstateファイルからの除外
  2. terraform import コマンドを使ったstateファイルへのインポート

Kiro Powersと違い、importブロックを使った方法の提案はありませんでした。ただし、コマンド実行も含めてすべての処理をチャットスペース上で指示を与えるだけで完結したので、作業的にはこちらの方がラクに感じました。

チャットスペース上でのstateファイル操作

インポート対象のリソースIDをチャットで渡すのみで、ユーザーはコマンド実行の許可のみ与えればOKでした。よりAgent的な挙動と言えそうです。

チャットスペース上でインポート作業も完結

Kiro Powersで起きた creation_token の不一致によるリソース再作成問題も terraform plan 結果より、問題をKiro側で認識し、自己解決（コード修正）してくれました。 インポートしたマウントターゲットに適用するセキュリティグループは、コード側の設定で上書きするのではなく、わざわざインポート対象のマウントターゲットに適用されているセキュリティグループに合わせてコード側を上書きする、Kiro Powersと逆の挙動になりました。 今回はコード側に定義したセキュリティグループを適用したいので、プロンプトで別途指示を加えました。

インポート後のセキュリティグループの付け替え

import後の差分チェック

まとめ

Kiro Plain のままでも想定より上手く処理できており、コマンドの指示は的確でしたが、リソースIDのコピペや実行はマニュアル作業でした。 Kiro Powers は importブロックを使った最新のベストプラクティスに則っており、実務に近い手順を再現できました。 一方、Kiro Skills は、各コマンドの実行を含めてAgent的にKiroが代行してくれたため、作業負荷はもっとも低く感じました。

Kiro Powersには今回紹介していないHCP Terraformに対応したMCPサーバーがあったり、Kiro SkillsにもHashicorp公式を超える充実度を誇るTerraform特化のAgents SkillsがAWS HeroのAnton Babenko氏によって公開されていますので、本ブログでの検証結果ではまだKiro PowersおよびSkillsの性能の一端でしかありません。

Anton Babenko氏作成のTerraform Agents Skills

これからももっとKiroを使い倒して、Terraform + Kiroの可能性を探っていきたいと思います。