CLOUD SECURITY LAB

Kiro vs Claude Code, Terraformのパートナーとしてどちらが良いか？

—

by

cslab
in

「AIと共にTerraformを使う」という言葉は、今や一般的になりました。

しかし、どのAIと使うかが結果を分けます。

AWSが育てた新鋭Kiroと、

世界中の開発者が選んだ汎用強者Claude Code。

Terraformのパートナーとしては、どちらがより適しているでしょうか？

>

この記事で扱う内容

  • KiroとClaude Codeの根本的な哲学の違い（Spec-driven vs Prompt-native）
  • それぞれのTerraform統合方式（Kiro Powers vs MCP Server）
  • AWSネイティブ統合 vs マルチクラウド/ベンダー中立のトレードオフ
  • 実践シナリオ別選択ガイド
  • AIベースのIaC作成時によく陥る落とし穴

なぜ今、この比較が重要なのか

わずか1～2年前まで、Terraformの作成は、Registryドキュメントを開き、公式モジュールのREADMEを調べ、古いブログ記事のバージョン互換性を検証するという骨の折れる作業でした。しかし、2025年後半に入ると、状況は一変しました。

AWSはKiroというAIベースのIDEを正式リリースし、re:Invent 2025ではHashiCorpと提携してTerraform Powerを発表しました。同時期に、AnthropicのClaude CodeはHashiCorpの公式Terraform MCP Serverと連携し、単なるコード補完を超えて、Registry APIとリアルタイムで対話するエージェントへと進化しました。

つまり、「AIでTerraformを書く」という選択肢が二つに分かれた時代が到来したのです。どちらが自分のチームに適しているかを判断できないと、初期の生産性は向上しても、長期的に見ればメンテナンスコストが増大する可能性があります。

Kiro — AWSが直接設計した「スペック駆動型」IDE

Kiroのアイデンティティ

Kiroは2025年夏にAWSが発表したエージェンティックAI IDE（+CLI）です。最大の特徴はSpec-driven Development、つまりコードを記述する前に要件（Requirements）→設計（Design）→タスク（Tasks）の3段階のスペックを自動生成し、ユーザーのレビューを経てから実行するという点です。要件はEARS表記法という公式の表記法で記述されます。

簡単に言えば、Vibe coding（感覚でコーディング）の利点を維持しつつ、複雑なプロジェクトでAIが勝手に暴走する問題をスペックという囲いで防ぐ構造です。

KiroのTerraform統合方式 — 「Powers」

KiroはPowersという独自の拡張メカニズムを持っています。Powerは、MCPサーバー、ステアリングファイル（ガイドライン）、フック（自動化タスク）を一つのバンドルにまとめたものです。HashiCorpが直接ローンチパートナーとして参加したTerraform Powerをインストールすると、「Terraform」、「infrastructure」といった単語が会話に登場したときにのみ自動的にアクティブ化されます。

この構造の利点は明確です：

  • トークン/コンテキストの節約：必要なときにのみ専門知識がロードされる
  • AWSエコシステムとの深い統合：AWS Cost Optimization Hub、Cost Explorer、IAM、Bedrock、MCPサーバーとのネイティブ連携
  • 一貫したガバナンス：Steeringファイルに「LambdaはARM64 Gravitonを使用、S3はIntelligent-Tieringをデフォルト」といった組織ルールを永続的に保存

Kiroが輝く瞬間

AWS環境でレガシーモダナイゼーションプロジェクトを進める際、Kiroは既存のコードベースを分析し、CloudFormation/CDK/Terraformの中から組織の好みに合わせてIaCを生成します。内部的にEKS/ECS MCP、Cost MCP、Diagram MCPなどをオーケストレーションするため、「AWSのみを使用するチーム」にとってはスイスアーミーナイフのような存在です。

Claude Code — ベンダー中立、柔軟な汎用強者

Claude Codeのアイデンティティ

Claude CodeはAnthropicのClaudeモデルをベースにしたエージェンティックコーディングツールです。ターミナルCLIを中心に、VS Code/JetBrainsプラグイン、GitHub Actions、Slack統合までサポートします。Kiroが「スペックを先に」を掲げるのに対し、Claude Codeは

「自然言語対話を通じた柔軟な探索」

に近いアプローチです。

最近ではSkillsという機能が追加され、特定のドメインのベストプラクティス（Terraform、HCP Terraformなど）をClaudeが自動的にロードし、それに従うように設定できます。KiroのPowersと機能的には似ていますが、設計はより開放的です。

Claude CodeのTerraform統合方式 — 「MCP Server + Skills」

HashiCorpが公式にメンテナンスしているTerraform MCP ServerをClaude Codeに接続すると、ClaudeはTerraform Registry APIと直接対話します。設定は簡単です：

# Claude CodeにTerraform MCP Serverを登録
claude mcp add terraform -s user -t stdio 
  -- docker run -i --rm hashicorp/terraform-mcp-server

HCP Terraform（旧Terraform Cloud）を使用している場合は、トークンを一緒に渡すことができます：

claude mcp add terraform -s user -t stdio 
  -e TFE_TOKEN=your-token-here 
  -- docker run -i --rm hashicorp/terraform-mcp-server

このように設定しておけば、次の対話でClaudeはProviderの最新バージョンとスキーマをリアルタイムで照会しながらコードを作成します。学習データのカットオフに縛られて消滅したリソース引数を使ったり、すでに非推奨となった構文を乱用したりする問題が大幅に減少します。

簡単なプロンプト例

Using the latest AWS provider, generate a Terraform module named `vpc_subnet`
that creates a VPC with a configurable CIDR, a variable number of public and
private subnets, NAT gateways per AZ, route tables, and outputs the VPC ID
and subnet IDs. Use official HashiCorp modules where possible.

ClaudeはMCPを介してRegistryから公式のterraform-aws-modules/vpc/awsモジュールの最新の使用法を確認し、それに基づいてスキャフォールドを生成します。さらに、セキュリティ検査（Checkov、tfsec）やGitHub Actionsのような他のMCPとも簡単に結合できるため、多重ツールオーケストレーションに強いです。

Claude Codeが輝く瞬間

  • マルチクラウド（AWS + Azure + GCP）またはハイブリッドクラウド環境
  • 既存のVS Code/JetBrains/ターミナル中心のワークフローを維持したいチーム
  • GitHub ActionsにClaude Codeを組み込み、「週次Providerアップデート自動検出」のようなエージェンティックワークフローを実行したいチーム

⚖️ 正面比較表
項目 Kiro Claude Code
開発主体 AWS Anthropic
核心哲学 Spec-driven (EARS表記法) Prompt-native + Skills
基本インターフェース 独立IDE + CLI ターミナルCLI + VS Code/JetBrainsプラグイン
Terraform統合 Terraform Power (HashiCorp公式バンドル) Terraform MCP Server + Terraform Skill
クラウド親和性 AWSネイティブ (EKS/ECS/Cost MCPなど内蔵) ベンダー中立 (AWS/Azure/GCP均等対応)
ガバナンス保存方式 Steeringファイル (永続ルール) AGENTS.md, Skillファイル
自動化フック Hooks (fmt/lint/scan自動実行) GitHub Actionsベースのエージェンティックワークフロー
学習曲線 スペック段階に慣れる必要あり 一般的なチャットに近く、導入が容易
オフライン/エアギャップ 制限あり 制限あり (MCPはDockerでローカル実行可能)

—

同じ作業、異なるアプローチ — 「ECS Fargate + ECR」デプロイシナリオ

Kiroでのフロー

  1. チャットウィンドウで自然言語でリクエスト → Requirements.mdがEARS表記で自動生成
  2. レビュー後承認するとDesign.mdが生成（HashiCorp公式モジュール使用などが反映）
  3. Tasks.mdに分割されたタスクを一つずつ、または一括で実行
  4. Hookがterraform fmt、tfsec、checkovを自動実行
"terraform-infra 디렉터리에 멀티 아키텍처 Docker 이미지를 빌드해 
ECR에 푸시하고, ECS Fargate로 프론트/백엔드 2티어를 배포하는 스펙을 만들어줘.
kreuzwerker/docker와 aws provider를 사용하고, 백엔드는 Task Role로
Secrets Manager에서 OpenAI API 키를 읽게 해줘."

Claude Codeでのフロー

  1. .mcp.jsonにTerraform MCP + AWS Diagram MCPを登録
  2. 自然言語プロンプト → ClaudeがRegistryを照会しながら直接HCLを作成
  3. 必要に応じてterraform planの実行結果をClaudeにフィードバック → 繰り返し修正
  4. GitHub ActionsワークフローにClaude Codeを組み込み、PRベースのレビューを自動化

どちらの方法も素晴らしい結果をもたらします。違いは、「構造化された成果物（spec/requirements/tasks）を組織に残したいか」 vs 「迅速な対話と反復で最短経路を進みたいか」です。

⚠️ 注意事項 / よくある間違い

1. AIが作成したIaCをそのままapplyしないこと

特にKiroのVibeモードを試用した事例では、「Hello Worldコンテナを一つデプロイして」というリクエストが、月額150～200ドルのプロダクション級EKSクラスターに変貌したという逸話が報告されています。AIの「親切なデフォルト値」は、請求書にとって致命的となる可能性があります。

2. MCPサーバーはLocal-onlyを原則とすること

HashiCorp Terraform MCP Serverは、公式ドキュメントで

「信頼できないMCPクライアントやLLMとは絶対に一緒に使わないこと」

と警告しています。信頼できないリモートMCPエンドポイントにTerraformの状態やTFEトークンを公開すると、その瞬間にインフラのキーが盗まれます。

3. Steering/Skillファイルにクレデンシャルを入れないこと

AIがルールを永続的に記憶できるのは利点ですが、同時にパスワードやAPIキーをうっかり入れてしまうと、コンテキストに一生ついて回ることになります。Secrets Manager/SSM Parameter Storeの参照のみを記録してください。

4. AI依存とエンジニアリング能力のバランス

「Claudeが作成したVPCがなぜうまく動いているのか分からない」という状態は、災いの種です。AIはforce-multiplierであり、アーキテクチャ理解の代替品ではありません。特にジュニアエンジニアは、スペック/生成コードを注意深くレビューし、学習ループに乗せることが必須です。

✅ まとめ / 結び

結論から申し上げると、どちらか一方が絶対的に優れているわけではありません。選択基準は単純です：

  • 組織全体がAWSに依存しており、スペックベースで成果物を残したい場合 → Kiro
  • マルチクラウド/ハイブリッド環境であるか、既存のVS Code・GitHub Actionsワークフローを維持したい場合 → Claude Code
  • セキュリティ・ガバナンスルールを組織レベルで強制したい場合 → KiroのSteering + Hookの組み合わせが有利
  • エージェンティック自動化（週次Providerアップデート検出など）をCIに組み込みたい場合 → Claude Code + GitHub Actions

私は個人的に、これら二つのツールを排他的な選択ではなく、補完的なツールとして使っています。設計とスペックの草案はKiroに任せ、実際のモジュールリファクタリング・マルチクラウドブリッジ・CI自動化はClaude Codeに任せる、といった具合です。

結局のところ、AIが変えたのはTerraformそのものではなく、「エンジニアがどこに時間を費やすか」です。構文の暗記やバージョンチェックはAIに任せ、私たちはアーキテクチャの判断とコスト・セキュリティレビューに集中すればよいのです。それが2026年のIaCエンジニアの新しい働き方です。

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です