developersIO
Kiro IDEでHashiCorp Agent Skills・HashiCorp Agent Skills + Terraform MCPサーバー・Terraform Powerの3パターンを比較してみた

Kiro IDEでHashiCorp Agent Skills・HashiCorp Agent Skills + Terraform MCPサーバー・Terraform Powerの3パターンを比較してみた

TerraformKiroModel Context Protocol (MCP)
FacebookHatena blogX
2026.03.12

Kiro IDEでは、Terraformのコード生成を支援する仕組みとしてKiro Powers（Terraform Power）とAgent Skills（terraform-style-guide）の両方を利用できます。

https://dev.classmethod.jp/articles/hashicorp-terraform-power/

https://dev.classmethod.jp/articles/kiro-hashicorp-agent-skills/

これらはどちらもHashiCorpが提供するTerraform向けの知識パッケージですが、仕組みが異なります。

今回は、同じプロンプトを使って以下の3パターンでコード生成を行い、コンテキストの読み込み状況と生成されるコードの違いを比較しました。

  1. Agent Skills のみ（terraform-style-guide）
  2. Agent Skills + MCPサーバー（terraform-style-guide + terraform-mcp-server）
  3. Terraform Power（MCPサーバー + ステアリングファイル）

3つの構成パターン

パターン1: Agent Skills のみ

Agent Skillsのterraform-style-guideのみを有効にした構成です。

https://github.com/hashicorp/agent-skills/tree/main/terraform/code-generation/skills/terraform-style-guide

エージェントがTerraform関連のタスクだと判断すると、SKILL.mdの内容が読み込まれます。

MCPサーバーが含まれないため、MCPツール経由でTerraformレジストリにアクセスすることはできません。

https://dev.classmethod.jp/articles/kiro-hashicorp-agent-skills/

パターン2: Agent Skills + MCPサーバー

Agent Skillsのterraform-style-guideを有効にし、さらにterraform-mcp-serverを手動で設定した構成です。

Skillsのスタイルガイドによる指示と、MCPサーバーによるレジストリへのアクセスを組み合わせます。

MCPサーバーは以下のようにmcp.jsonに手動で追加します。

{
  "mcpServers": {
    "terraform": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "hashicorp/terraform-mcp-server"
      ],
      "disabled": false
    }
  }
}

パターン3: Terraform Power

Terraform Powerを有効にした構成です。

https://github.com/kirodotdev/powers/tree/main/terraform

Powerを起動すると、以下がコンテキストに読み込まれます。

  • POWER.md（エントリポイント）
  • ステアリングファイル（code-style.md、terraform-best-practices.md、mcp-usage.md、getting-started.md）
  • MCPサーバーのツール定義（terraform-mcp-server）

https://dev.classmethod.jp/articles/hashicorp-terraform-power/

コンテキストの読み込み

3つのパターンで、エージェントに読み込まれるコンテキストが異なります。

読み込まれるコンテンツ

コンテンツ Skills のみ Skills + MCP Power
SKILL.md（スタイルガイド） ○ ○ -
POWER.md - - ○
code-style.md - - ○
terraform-best-practices.md - - ○
mcp-usage.md - - ○
getting-started.md - - ○
MCPツール定義 - ○ ○

Skills のみの場合、SKILL.md 1ファイルのみが読み込まれるため、コンテキスト消費量は最も少なくなります。

PowerとSkills + MCPにはどちらもMCPツール定義が含まれます。MCPツール定義は、ツールを実際に呼び出すかどうかに関わらず、エージェントがMCPツールが利用可能かどうかを判断するためにコンテキストに読み込まれます。

Powerにはさらに、MCPツールの使い方を指示するステアリングファイル（mcp-usage.md）が含まれるため、MCPツールをより適切に活用できます。

コンテキスト消費量の比較

各パターンのContext Usageを比較すると、Skills のみの場合（15%）に対し、MCPサーバーを含む構成ではSkills + MCP（21%）、Power（58%）と大きく増加します。

MCPサーバーを含む構成では、MCPツール定義の読み込みに加え、ツール呼び出しのレスポンスもコンテキストに蓄積されます。Kiro Powers公式ブログでも「5つのMCPサーバーに接続するだけで50,000以上のトークンを消費する可能性がある」と言及されています。

Skills + MCPとPowerは同じterraform-mcp-serverを使用していますが、Context Usageに大きな差があります。Powerではステアリングファイルの読み込みに加え、mcp-usage.mdの指示によりProviderの確認だけでなくモジュールの検索も行います。実際にKiroのログを確認すると、PowerではMCPツールの呼び出し回数が多く、そのレスポンスがコンテキストに蓄積されることでUsageが増加しています。

https://aws.amazon.com/jp/blogs/news/introducing-powers/

ただし、Powerの場合はキーワードに反応して動的に起動・停止するため、Terraform関連以外のタスクではステアリングファイルもMCPツール定義もコンテキストに読み込まれません。一方、Skills + MCPの場合、mcp.jsonに手動設定したMCPサーバーは常時接続されているため、Terraform以外のタスクでもMCPツール定義がコンテキストを消費します。

実際に、新規セッション開始直後（プロンプト入力前）のContext Usageを確認すると、Powerでは0%ですが、Skills + MCPではMCPツール定義の読み込みにより約1%のコンテキストを消費しています。MCPサーバーのツール定義はセッション開始時に自動的に読み込まれるためです。

スクリーンショット_2026_03_12_16_28.png

スクリーンショット_2026_03_12_16_25.png

検証

検証条件

3つのパターンで同じプロンプトを使用してコードを生成しました。

使用モデルはClaude Opus 4.6です。

AWS VPCを作成するterraformコードを作って

各パターンの有効化状態は以下の通りです。

パターン Agent Skills Terraform Power MCPサーバー（手動）
Skills のみ 有効 無効 無効
Skills + MCP 有効 無効 有効
Power 無効 有効 -

各パターンで3回ずつ実行し、消費クレジットはその最小値と最大値を記載しています。LLMの非決定性により、実行ごとに生成コードやMCPツールの呼び出し回数が変わるため、この範囲外の値になることもあります。また、Context UsageやコンテキストのサイズはPowersやAgent Skillsの更新によって変動する可能性があります。本記事の値は検証時点（2026年3月）のものです。

パターン1: Agent Skills のみ

スクリーンショット_2026_03_11_17_34.png

  • 消費クレジット: 1.57〜1.80
  • Context Usage: 15%

6ファイル（main.tf、variables.tf、outputs.tf、providers.tf、terraform.tf、locals.tf）が生成されました。スタイルガイドの指示通り、用途ごとにファイルが分割されています。

terraform.tfを見ると、Terraformバージョンは>= 1.7、AWS Providerバージョンは~> 5.0が指定されています。

terraform {
  required_version = ">= 1.7"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

SKILL.mdのサンプルコードに記載されているバージョン（>= 1.7、~> 5.0）がそのまま使用されています。MCPサーバーがないため、レジストリから最新バージョンを取得して上書きすることはできません。

タグ付けは、providerブロックのdefault_tagsで共通タグ（ManagedBy、Project）を設定しています。

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      ManagedBy = "Terraform"
      Project   = var.project_name
    }
  }
}

各リソースではmerge(local.common_tags, {...})で環境タグとリソース固有のタグを付与しています。

tags = merge(local.common_tags, {
  Name = "${var.project_name}-${var.environment}-vpc"
})

パターン2: Agent Skills + MCPサーバー

スクリーンショット_2026_03_11_17_44.png

  • 消費クレジット: 2.62〜2.91
  • Context Usage: 21%

SKILL.mdの指示に加え、MCPサーバー経由でTerraformレジストリからProvider情報を取得してコードが生成されています。SKILL.mdにはMCPツールの利用指示は含まれていませんが、MCPツールが利用可能な状態であればエージェントが自律的に呼び出すことがあります。

5ファイル（main.tf、variables.tf、outputs.tf、providers.tf、terraform.tf）が生成されました。パターン1と同様にスタイルガイドに沿ったファイル分割がされています。

AWS Providerバージョンは~> 6.0が指定されています。MCPサーバー経由でレジストリから最新バージョンを取得できるため、パターン1の~> 5.0と比べて新しいバージョンが使用されています。

terraform {
  required_version = ">= 1.7"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

パターン1と同様に、タグ付けはdefault_tagsとcommon_tagsのmergeを使用しています。

パターン3: Terraform Power

スクリーンショット_2026_03_12_10_48.png

  • 消費クレジット: 2.58〜3.15
  • Context Usage: 58%

検証時、上記のプロンプトだけではTerraform Powerがアクティベートされませんでした。そのため、明示的にTerraform Powerを使う旨を指示してコードを生成しました。パターン1・2とはプロンプトが異なるため、この点はコード生成結果の比較に影響する可能性があります。

MCPサーバー経由でTerraformレジストリからProvider情報を取得し、コードが生成されています。

生成されたコードは以下のリポジトリに格納しています。

https://github.com/msato0731/terraform-sample/tree/main/kiro-aws-vpc

3ファイル（main.tf、variables.tf、outputs.tf）が生成されました。パターン1・2とは異なり、terraformブロックやproviderブロックもmain.tfに含まれており、ファイル分割はされていません。

AWS Providerバージョンは~> 6.36が指定されています。MCPサーバー経由でレジストリから最新バージョンを取得できるため、パターン1の~> 5.0と比べて新しいバージョンが使用されています。パターン2の~> 6.0と比べても、より具体的なマイナーバージョンが指定されています。

terraform {
  required_version = ">= 1.5.7"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.36"
    }
  }
}

パターン1・2では直接リソース定義（aws_vpc、aws_subnetなど）を使用していますが、パターン3ではterraform-aws-modules/vpc/awsモジュール（v6.6.0）を使用しています。MCPサーバー経由でレジストリからモジュール情報を取得し、モジュールベースのコードが生成されています。

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "6.6.0"

  name = var.name
  cidr = var.cidr

  azs             = local.azs
  public_subnets  = [for k, v in local.azs : cidrsubnet(var.cidr, 8, k)]
  private_subnets = [for k, v in local.azs : cidrsubnet(var.cidr, 8, k + 10)]
  # ...
}

タグ付けはvar.tagsをモジュールに渡す形式で、SKILL.mdのサンプルにあるようなdefault_tagsやcommon_tagsのmergeは使用していません。

比較結果

Providerバージョン

パターン AWS Providerバージョン
Skills のみ ~> 5.0
Skills + MCP ~> 6.0
Power ~> 6.36

Skills のみの場合、SKILL.mdのサンプルコードに記載されたバージョンがそのまま使用される傾向があります。

PowerとSkills + MCPはMCPサーバー経由でレジストリからProviderの最新バージョンを取得できるため、サンプルコードのバージョンではなく検証時点の最新バージョンが使用されています。

ファイル構成

ファイル Skills のみ Skills + MCP Power
main.tf ○ ○ ○
variables.tf ○ ○ ○
outputs.tf ○ ○ ○
providers.tf ○ ○ -
terraform.tf ○ ○ -
locals.tf ○ - -
data.tf - - -

タグ付け

パターン タグ付け方法
Skills のみ default_tags + common_tagsのmerge
Skills + MCP default_tags + common_tagsのmerge
Power var.tagsをモジュールに渡す

SKILL.mdのサンプルコードにdefault_tagsとmerge(local.common_tags, ...)のパターンが含まれているため、パターン1・2ではこの形式が採用されています。Powerのステアリングファイルには該当するサンプルがないため、パターン3ではシンプルな形式になっています。

考察

指示内容による生成コードの違い

生成されたコードの違いのうち、SKILL.mdやPowerのステアリングファイルの指示内容に起因する部分を整理します。NAT Gatewayの有無やCIDR値の違いなど、LLMの非決定性に起因する差異は除外しています。

ファイル構成の指示

SKILL.mdでは、ファイル構成が明示的に定義されています。

ファイル 用途
terraform.tf Terraform and provider version requirements
providers.tf Provider configurations
main.tf Primary resources and data sources
variables.tf Input variable declarations
outputs.tf Output value declarations
locals.tf Local value declarations

パターン1・2ではこの構成に沿い、terraform.tfやproviders.tfが個別ファイルとして生成されています。

一方、Powerのterraform-best-practices.mdでは以下の構成が定義されています。

module/
├── main.tf          # Resources
├── variables.tf     # Inputs
├── outputs.tf       # Outputs
├── versions.tf      # Version constraints
└── README.md        # Docs

providers.tfやlocals.tfはcode-style.mdでRecommended Filesとして挙げられていますが、基本構成には含まれていません。「Add new resources to the main.tf file」という指示もあり、パターン3ではterraformブロックやproviderブロックもmain.tfにまとめて生成されています。

バージョンのサンプルコード

SKILL.mdには以下のサンプルコードが含まれており、パターン1ではMCPサーバーがないため、このサンプルのバージョン（>= 1.7、~> 5.0）がそのまま使用されています。

# SKILL.mdのサンプルコード
terraform {
  required_version = ">= 1.7"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

パターン2・3はMCPサーバー経由で最新バージョンを取得するため、サンプルコードのバージョンはそのまま使用されません。

タグ付けパターン

SKILL.mdにはdefault_tagsとcommon_tagsを組み合わせるタグ付けのサンプルコードが含まれています。

# SKILL.mdのサンプルコード
provider "aws" {
  default_tags {
    tags = {
      ManagedBy = "Terraform"
      Project   = var.project_name
    }
  }
}

tags = merge(local.common_tags, {
  Name = "${var.project_name}-${var.environment}-vpc"
})

パターン1・2はこのパターンに沿ってタグ付けしています。Powerのステアリングファイルにはdefault_tagsのサンプルコードが含まれていないため、パターン3ではモジュールのtagsパラメータに変数を渡すシンプルな形式になっています。

モジュールの利用

SKILL.mdのサンプルコードでは直接リソース定義（resource "aws_vpc" "main"）を使用しています。パターン1・2もこれに倣い、aws_vpcやaws_subnetを直接定義しています。

Powerのterraform-best-practices.mdでは、モジュールの利用例が記載されています。

# terraform-best-practices.mdのサンプルコード
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.0"

  name = "my-vpc"
  cidr = "10.0.0.0/16"
}

さらにmcp-usage.mdでは「Identify available modules and their requirements」と指示されており、パターン3ではVPCモジュールを使用したコードが生成されています。

MCPサーバーの事前参照

SKILL.mdにはMCPツールの利用に関する指示は含まれていません。

Powerのmcp-usage.mdではコード生成前に必ずMCPサーバーを参照するよう指示されています。

ALWAYS consult the MCP server before generating Terraform code to:

  1. Retrieve latest provider documentation and constraints
  2. Identify available modules and their requirements

この指示により、パターン3ではコード生成前にレジストリからProviderやモジュールの最新情報を取得しています。より具体的なバージョン指定（~> 6.36）やモジュールの活用はこの指示に起因しています。

MCPサーバーの有無による影響

MCPサーバーは、Terraformレジストリへの構造化されたアクセス手段を提供します。MCPサーバーがある構成（PowerおよびSkills + MCP）では、レジストリからProviderの最新バージョンやモジュール情報を確実に取得できます。

Skills のみの場合はMCPサーバーがないため、SKILL.mdのサンプルコードに記載されたバージョンがそのまま使用される傾向があります。

Powerのステアリングファイルの価値

Skills + MCPパターンはMCPツールを利用できますが、Powerが持つ以下のステアリングファイルは含まれません。

  • mcp-usage.md — MCPツールの使い方指示（「コード生成前に必ずMCPサーバーを参照する」など）
  • terraform-best-practices.md — Terraformのベストプラクティス
  • getting-started.md — 初期セットアップガイド

なお、SKILL.mdにMCPツールの使い方を指示として記述すれば、エージェントはそれに従ってMCPツールを呼び出します。つまり、Skills + MCPパターンでもSKILL.mdをカスタマイズすることで、Powerのmcp-usage.mdと同等のことは実現可能です。

ただし、現状のHashiCorp公式terraform-style-guideにはMCP利用指示が含まれていないため、自分でカスタマイズする必要があります。Powerはこれらがセットで提供されるため、設定なしですぐに使える点がパッケージとしての価値です。

3パターンの使い分け

パターン 適したケース
Skills のみ コンテキスト消費を最小限にしたい場合。コードスタイルの統一が主な目的で、最新バージョンの追従は手動で行える場合
Skills + MCP Skillsのポータビリティを活かしつつ、MCPツールも使いたい場合。ただし、MCPツールの使い方指示は自分で用意する必要がある
Power Terraformの本番コードを生成する場合。MCPツールによる最新情報の取得とベストプラクティスの適用を自動で行いたい場合

おわりに

同じプロンプトでも、SKILL.mdやステアリングファイルのサンプルコード・指示内容によって、ファイル構成、タグ付けパターン、モジュールの利用有無など、生成されるコードに明確な違いが出ることがわかりました。

一方で、Context Usageは15%（Skills のみ）から58%（Power）まで大きく異なります。Powerはステアリングファイルの読み込みやMCPツールの積極的な呼び出しにより多くのコンテキストを消費しますが、その分モジュールの活用や最新バージョンの取得など、より実践的なコードが生成されます。

コンテキスト消費量と生成コードの品質のトレードオフを理解した上で、用途に応じて使い分けることが重要です。

この記事をシェアする

FacebookHatena blogX

関連記事

[新機能] パッケージ化された専門的な開発スキルを動的に利用できるKiro powersがリリースされました #AWSreInvent
Ruon - Ryuhei Takagaki
2025.12.08
[Kiro powers]HashiCorp Terraform Powerがリリースされました
佐藤雅樹
2025.12.06
Claude Codeを使ったタスクの協働デモ - AWS技術調査からIaC実装まで
川原征大
2025.06.23
注目の記事
Terraform MCP Server (HashiCorp社) 使ってみた
あかいけ
2025.05.20