はじめに
「AWS Kiroをインストールしたけど、何から始めればいいか分からない…」
「VibeとSpecの使い分けが分からない。Hookって何?Steeringって何?」
Kiroは多機能なAgentic IDEですが、機能が多すぎて最初は戸惑いがちです。本記事では、Kiroで何ができるのか・各機能をどう使えばいいかを、初心者でも確実に分かるよう段階的に解説します。
Kiroのインストール・基本セットアップについては以下を参照してください。
- AWS Kiro完全ガイド

この記事で分かること
- VibeモードとSpecモードの詳細な使い分け
- Steering(プロジェクトルール)の設定方法
- Hook(自動化トリガー)の具体的な設定例
- Skills(カスタムコマンド)の作り方
- Powers(MCPの自動化)の活用法
- 個人利用における注意点・コスト管理
機能カテゴリの全体像
Kiroの機能は大きく6つに分類されます。
■ チャット(対話)
├─ Vibeモード ← 即時実装・質問・解析向け
└─ Specモード ← 要件→設計→実装の体系的開発向け
■ プロジェクトルール管理
└─ Steering ← 常時・条件付きのルールを定義
■ 自動化
└─ Hook ← ファイル操作に反応して自動実行
■ カスタマイズ
└─ Skills ← 独自スラッシュコマンドを登録
■ 拡張性
└─ Powers ← MCPを必要なときだけ自動起動【基本】チャットで使う
まずVibeモードから始めよう
Kiroのチャットパネルを開き、新しいセッションを開始する際にVibeモードを選択します。
Claude CodeやChatGPTと同じ感覚で、日本語で指示するだけです。
よく使う指示例:
# ファイル解析・質問
> このSpring Bootアプリの認証ロジックを説明して
# コード修正
> src/main/java/Service.javaのバグを修正して
# 機能追加
> ユーザー一覧APIにページネーションを追加して
# ドキュメント生成
> このクラスのJavadocコメントを追加して
# インフラ
> EC2インスタンスにS3アクセス権限を付与するIAMロールを作成してポイント: 最初にSteeringファイル(後述)で「常に日本語で応答すること」を設定しておくと、毎回指示する必要がなくなります。
【応用】Specモードで仕様駆動開発
Specモードとは
「何を作るか」をAIと一緒に整理してから実装するモードです。以下のようなケースで真価を発揮します。
- 新機能をゼロから作る
- 複数のファイルにまたがる機能開発
- 後から「こんなつもりじゃなかった」を防ぎたい
Specモードの使い方:3ステップ
STEP 1: Specセッションを開始して指示を入力
新しいセッション起動時に「Spec」を選択し、作りたいものを伝えます。
> AWSのEC2上でApacheを動かし、S3に静的コンテンツを配置して
CloudFrontで配信するWebサイト基盤をCloudFormationで構築したいSTEP 2: Requirements(要件)を確認・修正
KiroがEARS記法でユーザーストーリーと受け入れ条件を自動生成します。
# Requirements
## ユーザーストーリー
WHEN ユーザーがWebサイトにアクセスするとき
THEN CloudFront経由でS3の静的コンテンツが配信される
WHEN 管理者がEC2にSSM Session Managerで接続するとき
THEN パブリックIPなしでセキュアにアクセスできる
## 受け入れ条件
- [ ] CloudFormationテンプレートで全リソースが定義されている
- [ ] SSLが有効化されている
- [ ] EC2へのSSH接続はIGW経由ではなくSSM経由のみ許可「この受け入れ条件が足りない」「この条件は不要」など、ここで修正します。実装前に方向性を確認できるのがSpecモード最大のメリットです。
STEP 3: Design → Tasks → 実装
要件を確認したら、そのままDesign(設計書)→ Task list(実装タスク)→ 実装まで進みます。
.kiro/specs/web-infra/
├── requirements.md ← 要件定義
├── design.md ← アーキテクチャ設計
└── tasks.md ← 実装チェックリスト生成されたタスクを一つずつ実行していき、チェックボックスで進捗管理できます。
Specモードの使いどころ
| シチュエーション | Specを使うべきか |
|---|---|
| ちょっとした修正・質問 | ❌ Vibeで十分 |
| 機能1つをゼロから作る(複雑) | ✅ Spec推奨 |
| AWSシステムを一から設計・構築 | ✅ Spec推奨 |
| 既存コードのリファクタリング | ❌ Vibeで十分 |
| チームと設計を共有したい | ✅ Spec推奨 |
【設定】Steeringでプロジェクトルールを定義
Steeringとは
毎回「日本語で答えて」「コメントは右側に書いて」と指示するのは面倒です。Steeringはこれを一度設定するだけで永続的に効かせる機能です。
基本的なSteeringファイルの作成
.kiro/steering/ 配下にMarkdownファイルを作成します。
日本語・コーディング規約の設定(例):
---
inclusion: always
---
# プロジェクトルール
## コミュニケーション
- すべてのやり取りは日本語で行うこと
## コーディング規約
- コメントはコードの右側に記述すること
- AWSリソース名はケバブケース(例: web-server-ec2)で統一すること
- CloudFormationテンプレートはYAML形式で記述することこのファイルを置くだけで、以降のすべてのセッションで自動的に適用されます。
Steeringの4つのinclusionモード活用例
① always(常時)
---
inclusion: always
---コーディング規約・言語設定など、常に守ってほしいルールに使います。
② fileMatch(ファイルパターン一致時)
---
inclusion: fileMatch
fileMatchPattern: "**/*.tf"
---
# Terraformルール
- リソース名はスネークケースで統一
- AWS providerのバージョンは必ず固定することTerraformファイルを操作するときだけ読み込まれます。Spring BootのJavaファイルには適用されません。
③ manual(手動参照)
---
inclusion: manual
---
# トラブルシューティングガイド
(デバッグ手順など長大なガイドを記述)チャット内で #トラブルシューティングガイド と参照したときだけ読み込まれます。常時ロードしてコンテキストを無駄遣いしません。
④ auto(自動マッチング)
---
inclusion: auto
name: aws-security
description: AWSセキュリティのベストプラクティスとIAM設計ガイド
---「IAMポリシーを作って」などのセキュリティ関連のプロンプトを検知すると自動でロードされます。
標準Steeringファイルの自動生成
KiroはSteeringセクションで「Generate Steering Docs」ボタンをクリックすると、プロジェクトを解析して以下の3ファイルを自動生成します。
.kiro/steering/
├── product.md ← 製品の目的・ターゲット・主要機能
├── tech.md ← 技術スタック・フレームワーク・バージョン
└── structure.md ← ディレクトリ構造・命名規則既存プロジェクトの解析・ドキュメント化にも活用できます。
【自動化】Hookを設定する
Hookとは
「ファイルを保存するたびにテストが自動で走る」「コードを書いたら自動でドキュメントが更新される」——Hookはこういった繰り返し作業を自動化する仕組みです。
Hookの設定方法
KiroのHookセクションから「New Hook」を選択し、自然言語で記述します。
設定例1: ファイル保存時にテスト自動実行
トリガー: TypeScriptファイルの保存時
実行内容: 変更ファイルに対応するテストを実行し、失敗があれば内容を報告してください設定例2: 新しいAPIエンドポイント作成時にドキュメント更新
トリガー: src/controllers/ 配下のファイル作成時
実行内容: 作成されたコントローラーのAPIエンドポイントをdocs/api.mdに追記してください設定例3: セキュリティスキャン
トリガー: .env以外のファイル保存時
実行内容: 変更ファイルにAPIキーやパスワードなどの機密情報がハードコードされていないか確認し、
発見した場合は警告を出してください設定はJSONファイルとして .kiro/hooks/ に保存されます。
HookはClaude Codeにない機能
Claude CodeやCodex CLIはすべて手動実行です。Kiroのみがファイル操作に反応して自動でAIエージェントをトリガーできます。品質チェックを「やり忘れる」リスクをゼロにできます。
【カスタマイズ】Skillsで独自コマンドを作る
Skillsとは
同じ作業を繰り返すなら、スラッシュコマンドとして登録しておきましょう。一度定義すれば / + コマンド名 で呼び出せます。
Skillの作成手順
.kiro/skills/ 配下にフォルダを作成し、SKILL.md を置きます。
.kiro/skills/
└── review-pr/
└── SKILL.mdSKILL.md の例(PRレビュー用):
---
name: review-pr
description: プルリクエストのコードレビューを行う。セキュリティ・パフォーマンス・可読性の観点で指摘する。
---
# PRレビュースキル
## レビュー観点
1. セキュリティ脆弱性(SQLインジェクション・XSS・認証漏れ)
2. パフォーマンス問題(N+1クエリ・不要なAPIコール)
3. コーディング規約の遵守
4. テストカバレッジ
5. エラーハンドリング
## 出力形式
- 重大度: 🔴 Critical / 🟡 Warning / 🟢 Info
- 指摘箇所: ファイル名と行番号
- 改善案: 具体的なコード例を提示チャット入力欄で /review-pr と入力するだけでこのスキルが起動します。
グローバルスキルの配置
~/.kiro/skills/ に置けば全プロジェクトで使えます。
~/.kiro/skills/
├── review-pr/ ← どのプロジェクトでも /review-pr が使える
└── analyze-arch/ ← どのプロジェクトでも /analyze-arch が使える【拡張】Powersを活用する
Powersとは
MCP(Model Context Protocol)サーバーを必要なときだけ自動でアクティブ化する仕組みです。使わないMCPをすべてロードするとコンテキストが膨れ上がり、クレジットを無駄消費します。Powersはこれを解決します。
主なPowersの種類
公式AWS Powers(ビルトイン):
AWS CDK Powers → CDK関連の質問で自動起動
Terraform Powers → Terraform操作時に自動起動
Lambda Powers → Lambda関数開発時に自動起動コミュニティPowers:
Azure Powers → Azure関連の開発(GitHub: requix/azure-kiro-powers)
Firebase Powers → Firebase・GCP開発AWSのツールではありますが、Azure・GCP向けのPowersも利用可能です。
超便利な使い方ベスト3
第1位: AWSハンズオンをSpecモードで一から構築
「こんなAWS構成を作りたい」と伝えるだけで、要件定義→CloudFormationテンプレート作成→デプロイ手順書まで自動生成されます。
> VPC内にパブリック・プライベートサブネットを作り、
EC2(Apacheサーバー)+ RDS MySQL(Multi-AZ)の
基本的なWebアプリ構成をCloudFormationで構築したい要件確認ステップで「SSMによる接続も含めてほしい」「NAT Gatewayも追加して」と追加要求して精度を上げ、そのまま実装まで完結できます。
第2位: Hookで品質チェックを完全自動化
ファイル保存のたびに以下が自動で走る環境を構築しておくと、「テスト書き忘れ」「ドキュメントが古い」問題がなくなります。
保存トリガー → 関連テスト実行
作成トリガー → Javadocコメント自動追加
削除トリガー → 依存関係チェック第3位: Steeringで「いつでも同じクオリティ」を維持
チームのコーディング規約・命名規則・禁止事項をSteeringに書いておけば、誰がKiroを使っても同じ基準でコードが生成されます。
---
inclusion: always
---
# チーム共通ルール
- 日本語でコメント・ドキュメントを記述する
- awsのリソースIDは環境変数から取得すること(ハードコード禁止)
- IAMポリシーは最小権限の原則を守ることこのファイルをGitでコミットしておけば、チーム全員が同じルールでKiroを使えます。
個人利用における注意点
1. クレジット消費を把握する
Free(50クレジット/月)でできることは限られています。本格的な利用にはPro($20/月・1,000クレジット)以上が必要です。
クレジットを節約するコツ:
✅ AutoモードはSonnet相当のコストで高品質
✅ 単純な質問・修正はHaikuモードで十分(0.4倍)
✅ Hooksの自動実行が多いと気づかずクレジットを消費する
→ 頻度が高いHookはHaikuモードで実行するよう設定する2. 機密情報を除外する
.kiroignore ファイルを作成し、Kiroに読み込ませたくないファイルを除外します。
# .kiroignore
.env
.env.*
secrets/
credentials.json
*.pem
*.key3. プロジェクト外ファイルへのアクセスは制限される
KiroはVSCodeで開いたワークスペース内のファイルしか扱えません。参照したいファイルが別のプロジェクトにある場合は、マルチルートワークスペースでフォルダを追加してください。
VSCode: ファイル → ワークスペースにフォルダを追加4. Specモードはアウトプットの確認が必要
Specモードで生成されたRequirementsはAIが推測して書いたものです。特に「受け入れ条件」はビジネス要件を正確に反映していない場合があります。必ず確認・修正してから設計・実装フェーズに進んでください。
まとめ
AWS Kiroの主要機能を整理すると:
| 機能 | 用途 | レベル |
|---|---|---|
| Vibeモード | 質問・修正・即時実装 | 初心者から |
| Specモード | 要件定義から体系的に開発 | 中級者以上 |
| Steering | プロジェクトルールの永続化 | 初心者から(設定一回でOK) |
| Hook | 品質チェックの自動化 | 中級者以上 |
| Skills | 繰り返し作業のコマンド化 | 中級者以上 |
| Powers | MCP自動最適化 | 上級者向け |
使い始めのおすすめ順序:
- まずVibeモードで使ってみる
- Steeringに日本語設定と規約を書く
- よく使う作業をSkillsに登録する
- 自動化したい品質チェックをHookに設定する
- 大きな機能開発でSpecモードを試す
関連記事:
- AWS Kiro完全ガイド|Agentic IDEの全貌とは【セットアップ・料金・機能まで】

- AWS Kiro vs Claude Code vs Codex CLI徹底比較

- Claude Code完全ガイド|ターミナルで動くAIコーディングアシスタントの全貌

タグ: #Kiro #AWSKiro #使い方 #Spec #Vibe #Hook #Steering #Skills #開発効率化 #初心者
コメント