はじめに
「AWS Kiroをインストールしたけど、何から始めればいいか分からない…」
「VibeとSpecの使い分けが分からない。Hookって何？Steeringって何？」
Kiroは多機能なAgentic IDEですが、機能が多すぎて最初は戸惑いがちです。本記事では、Kiroで何ができるのか・各機能をどう使えばいいかを、初心者でも確実に分かるよう段階的に解説します。
2026年6月時点の情報： KiroはPreviewを経て2025年11月に正式GA（一般提供）を達成。Kiro CLI・チームプラン・GitLabサポートなどが追加されています。2026年5月〜6月には新プラン「Kiro Pro Max」追加・CLI v3プレビュー・自動スケジュール実行機能などが追加されました（2026年8月時点で確認できる範囲では、本記事の内容に大きな変更はありません。プラン料金・クレジット数は変更される場合があるため、契約前に必ずKiro公式サイトで最新情報をご確認ください）。
安全設計（承認ゲート）： Kiroはコードの自動生成だけでなく、ファイルの書き換えやターミナルコマンドの実行前に「ユーザーへの承認依頼」を行います。予期せぬスクリプト実行やファイル上書きを防ぐ仕組み（Human-in-the-Loop）が標準組み込みされているため、安心して利用できます。
Kiroのインストール・基本セットアップについては以下を参照してください。
- AWS Kiro完全ガイド
この記事で分かること
- VibeモードとSpecモードの詳細な使い分け
- Steering（プロジェクトルール）の設定方法
- Hook（自動化トリガー）の具体的な設定例
- Skills（カスタムコマンド）の作り方
- Powers（MCPの自動化）の活用法
- Kiro CLIの概要
- 個人利用における注意点・コスト管理
機能カテゴリの全体像
Kiroの機能は大きく6つに分類されます。
■ チャット（対話）
├─ Vibeモード ← 即時実装・質問・解析向け
└─ Specモード ← 要件→設計→実装の体系的開発向け
■ プロジェクトルール管理
└─ Steering ← 常時・条件付きのルールを定義
■ 自動化
└─ Hook ← ファイル操作に反応して自動実行
■ カスタマイズ
└─ Skills ← 独自スラッシュコマンドを登録
■ 拡張性
└─ Powers ← MCPを必要なときだけ自動起動
■ ターミナル
└─ Kiro CLI ← ターミナルからエージェント実行（2025年11月GA追加）【基本】チャットで使う
まずVibeモードから始めよう
Kiroのチャットパネルを開き、新しいセッションを開始する際にVibeモードを選択します。
Claude CodeやChatGPTと同じ感覚で、日本語で指示するだけです。
使用モデルの選択： VibeモードではClaude Sonnet 4.5（信頼性の高い高度なコーディング・推論向け）、Claude Opus 4.8（1Mコンテキスト・自己検証強化で長期プロジェクト向け）、またはAuto（品質・レイテンシ・コストを最適化する複数モデルの自動選択）を選べます。最新のClaude Sonnet 5・Fable 5についてはこちらの解説記事も参考にしてください。
※Kiro上で選択可能なモデルはAWSの提供状況およびバージョン更新によって順次切り替わります。実際の画面表示が本記事と異なる場合は、Kiro内のモデル選択メニューで最新の選択肢をご確認ください。
よく使う指示例：
# ファイル解析・質問
> この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で構築したい2つの開始アプローチ：
- Requirements-First：要件定義から始め、ユーザーストーリーを確認してから設計に進む（デフォルト）
- Design-First：既にアーキテクチャが決まっている場合は設計書から始める
- Quick Plan：承認ゲートなしに要件・設計・タスクの3ファイルを一気に自動生成する高速モード
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 ← 実装チェックリスト生成されたタスクを一つずつ実行していき、チェックボックスで進捗管理できます。
タスクの並列実行（Wave）： Kiroはタスク間の依存関係を自動分析し、独立したタスクを「Wave（波）」にグループ化して並列実行します。複数ファイルにまたがる実装でも実装時間を大幅に短縮できます。
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ポリシーを作って」などのセキュリティ関連のプロンプトを検知すると自動でロードされます。nameとdescriptionの両方が必須です。
descriptionの書き方のコツ：
descriptionの質が自動ロードの精度に直結します。「AWSセキュリティ」のような単語の羅列ではなく、「IAMポリシー作成やS3バケット権限設定について質問されたときに参照するルール」のように、AIがどんな会話文脈でこのルールをロードすべきかを具体的に書き込むと、意図しない場面での誤ロード・逆にロードされないといったズレが減ります。
⑤ グローバルSteeringルール
~/.kiro/steering/ に配置すると、すべてのワークスペースに横断して適用されます。個人の作業スタイルや言語設定など、プロジェクトを問わず守りたいルールに使います。
優先順位： ワークスペース（
.kiro/steering/）の設定がグローバル（~/.kiro/steering/）の設定を上書きします。同じルールが競合した場合はプロジェクト固有の設定が優先されます。
標準Steeringファイルの自動生成
KiroはSteeringセクションで「Generate Steering Docs」ボタンをクリックすると、プロジェクトを解析して以下の3ファイルを自動生成します。
.kiro/steering/
├── product.md ← 製品の目的・ターゲット・主要機能
├── tech.md ← 技術スタック・フレームワーク・バージョン
└── structure.md ← ディレクトリ構造・命名規則既存プロジェクトの解析・ドキュメント化にも活用できます。
【自動化】Hookを設定する
Hookとは
「ファイルを保存するたびにテストが自動で走る」「コードを書いたら自動でドキュメントが更新される」——Hookはこういった繰り返し作業を自動化する仕組みです。
Hookのトリガーイベント一覧
Hookは以下のIDEイベントに反応して起動します。
| トリガーイベント | 説明 |
|---|---|
| ファイルの保存 | 対象ファイルを保存するたびに実行 |
| ファイルの作成 | 新しいファイルが作成されたとき |
| ファイルの削除 | ファイルが削除されたとき |
| ユーザープロンプト送信 | チャットにプロンプトを送信したとき |
| エージェントターン完了 | Kiroの応答が終わったとき |
| ツール呼び出し前後 | 特定のツールが呼び出される前・後 |
| タスク実行前後 | Specのタスクが始まる前・完了した後 |
| 手動トリガー | オンデマンドで任意のタイミングに手動起動 |
Hookの設定方法
KiroのHookセクション（Kiro Panel → Agent Hooks）から「New Hook」を選択します。自然言語での説明から自動生成するか、手動で各フィールドを入力します。コマンドパレット（Cmd/Ctrl + Shift + P → 「Kiro: Open Kiro Hook UI」）からも起動可能です。
設定例1: ファイル保存時にテスト自動実行
トリガー: TypeScriptファイルの保存時
実行内容: 変更ファイルに対応するテストを実行し、失敗があれば内容を報告してください設定例2: 新しいAPIエンドポイント作成時にドキュメント更新
トリガー: src/controllers/ 配下のファイル作成時
実行内容: 作成されたコントローラーのAPIエンドポイントをdocs/api.mdに追記してください設定例3: セキュリティスキャン
トリガー: .env以外のファイル保存時
実行内容: 変更ファイルにAPIキーやパスワードなどの機密情報がハードコードされていないか確認し、
発見した場合は警告を出してください設定はJSONファイルとして .kiro/hooks/ に保存されます。実体は以下のような形式です。
{
"name": "test-on-save",
"trigger": {
"type": "fileSave",
"pattern": "**/*.test.ts"
},
"action": {
"type": "agentPrompt",
"prompt": "変更ファイルに対応するテストを実行し、失敗があれば内容を報告してください"
}
}trigger.pattern に対象ファイルのglobパターン、action.prompt にAIへ実行させたい指示を記述する構造です。UIから作成した場合もこの形式のJSONが自動生成されるため、複数プロジェクトへ同じHookを使い回したい場合はこのファイルをコピーするだけで済みます。
HookはClaude Codeにない機能
Claude CodeやCodex CLIはすべて手動実行です。Kiroのみがファイル操作に反応して自動でAIエージェントをトリガーできます。品質チェックを「やり忘れる」リスクをゼロにできます。
【カスタマイズ】Skillsで独自コマンドを作る
Skillsとは
同じ作業を繰り返すなら、スラッシュコマンドとして登録しておきましょう。一度定義すれば / + コマンド名 で呼び出せます。
Skillsは**オープンスタンダード（Agent Skills Standard）**に準拠した移植可能なパッケージとして設計されており、コミュニティ間での共有・インポートが可能です。
Skillの作成手順
.kiro/skills/ 配下にフォルダを作成し、SKILL.md を置きます。追加のファイルも配置できます。
.kiro/skills/
└── review-pr/
├── SKILL.md ← 必須
├── scripts/ ← オプション：実行スクリプト
├── references/ ← オプション：参照ドキュメント
└── assets/ ← オプション：テンプレートなどSKILL.md の例（PRレビュー用）：
---
name: review-pr
description: プルリクエストのコードレビューを行う。セキュリティ・パフォーマンス・可読性の観点で指摘する。
---
# PRレビュースキル
## レビュー観点
1. セキュリティ脆弱性（SQLインジェクション・XSS・認証漏れ）
2. パフォーマンス問題（N+1クエリ・不要なAPIコール）
3. コーディング規約の遵守
4. テストカバレッジ
5. エラーハンドリング
## 出力形式
- 重大度: 🔴 Critical / 🟡 Warning / 🟢 Info
- 指摘箇所: ファイル名と行番号
- 改善案: 具体的なコード例を提示チャット入力欄で /review-pr と入力するだけでこのスキルが起動します。
SKILL.mdのname フィールド： 小文字・数字・ハイフンのみ（最大64文字）、フォルダ名と一致させる必要があります。descriptionは最大1024文字で、スキルを起動すべき状況を明確に記述します。
グローバルスキルの配置
~/.kiro/skills/ に置けば全プロジェクトで使えます。
~/.kiro/skills/
├── review-pr/ ← どのプロジェクトでも /review-pr が使える
└── analyze-arch/ ← どのプロジェクトでも /analyze-arch が使える【拡張】Powersを活用する
Powersとは
MCP（Model Context Protocol）サーバーを必要なときだけ自動でアクティブ化する仕組みです。使わないMCPをすべてロードするとコンテキストが膨れ上がり、クレジットを無駄消費します。Powersはこれを解決します。
Powerは以下の3要素で構成されます：
- POWER.md — 利用可能なMCPツールと起動タイミングを定義するファイル
- MCPサーバー設定 — ツールと接続詳細
- Steering/Hook（オプション） — IDEイベントやスラッシュコマンドで実行される自動タスク
主なPowersの種類
公式パートナーPowers（2026年6月時点。8月時点でも大きな追加は確認できていません）：
Datadog Powers → アプリ・インフラの監視・調査時に自動起動
Dynatrace Powers → オブザーバビリティ関連の調査時に自動起動
Figma Powers → デザインデータの参照・実装時に自動起動
Neon Powers → Neon PostgreSQLデータベース操作時に自動起動
Netlify Powers → Netlifyデプロイ・設定操作時に自動起動
Postman Powers → API設計・テスト時に自動起動
Supabase Powers → Supabase（BaaS）操作時に自動起動
Stripe Powers → 決済・サブスクリプション開発時に自動起動
AWS Aurora Powers → Amazon Auroraデータベース操作時に自動起動
Strands SDK Powers → AWS Strandsエージェント開発時に自動起動コミュニティPowers：
GitHubのURLからコミュニティ製Powersもインストール可能です。Kiro内またはkiro.devで参照し、「インストール」をクリックするだけで登録できます（JSONファイルやコマンドラインの設定不要）。
AWSのツールではありますが、サードパーティサービス向けのPowersも広く利用可能です。
Powersの動きをイメージする
例えば「GitHub」「PostgreSQL」「AWS API」に接続するPowerを有効化しておくと、以下のようにプロンプトの内容に応じて必要なものだけが自動起動します。
「このPRのレビューをして」 → GitHub Powerが自動起動
「usersテーブルのスキーマを確認して」 → PostgreSQL Powerが自動起動
「S3バケットの権限を一覧して」 → AWS API Powerが自動起動普段はすべてのPowerがスリープ状態で、該当する話題が出たときだけコンテキストに読み込まれる仕組みのため、無関係なMCPツールでコンテキストを圧迫することがありません。.kiro/powers/ 配下には、Power名のフォルダごとに POWER.md（起動条件の定義）とMCPサーバー接続設定が配置されます。
.kiro/powers/
└── github-review/
├── POWER.md ← 起動タイミング・用途の定義
└── mcp.json ← GitHub MCPサーバーの接続設定自作のPowerを作りたい場合も、公式パートナーPowersと同じくこの構成でファイルを用意すれば動作します。
【ターミナル】Kiro CLIを使う
Kiro CLIとは
2025年11月のGA時に追加された、ターミナルからKiroエージェントを操作する機能です。IDEを使わずにコマンドラインでKiroのすべての機能（Spec・Steering・Hook・Skillsなど）を利用できます。
主な用途：
# 機能実装の自動化
kiro "src/api/users.tsにページネーション機能を追加して"
# バグ解析・修正提案
kiro "エラーログを解析して修正案を提示して"
# ワークフロー自動化（CI/CDパイプライン組み込みなど）
kiro "テストを実行してカバレッジレポートを生成して"Kiro CLI 2.0（2026年4月）の主な強化点：
- Windows Terminalの正式サポート
- ヘッドレスモード（UIなしでの自動実行）
- サブエージェントによる複雑タスクの並列委譲
- 組み込みPlanエージェント（複雑タスクを段階的な実装計画に分解）
- マルチセッション管理（インタラクティブなセッション選択UI）
Kiro CLI v3（2026年5月〜 プレビュー）：
- 仕様駆動開発（Spec）とタグベースのエージェント設定を導入
- IDE・Webと同じ統合ハーネスで動作し、一貫した開発体験を提供
- GitLabリポジトリ対応（個人アクセストークンで接続）
- 自動スケジュール機能：GitHubやGitLabリポジトリを指定してタスクを記述するだけで、定期的な作業の自動実行とプルリクエスト生成が可能
インストール：
curl -fsSL https://cli.kiro.dev/install | bash（macOS・Linux・Windows対応）
Claude Codeのスラッシュコマンドとの違いが気になる方は、Claude Codeコマンド一覧【2026年最新】も参考にしてください。
超便利な使い方ベスト3
第1位: AWSハンズオンをSpecモードで一から構築
「こんなAWS構成を作りたい」と伝えるだけで、要件定義→CloudFormationテンプレート作成→デプロイ手順書まで自動生成されます。
> VPC内にパブリック・プライベートサブネットを作り、
EC2（Apacheサーバー）+ RDS MySQL（Multi-AZ）の
基本的なWebアプリ構成をCloudFormationで構築したい要件確認ステップで「SSMによる接続も含めてほしい」「NAT Gatewayも追加して」と追加要求して精度を上げ、そのまま実装まで完結できます。構成図を残しておきたい場合は、AWS構成図をKiroで自動生成する方法も合わせて参照してください。
第2位: Hookで品質チェックを完全自動化
ファイル保存のたびに以下が自動で走る環境を構築しておくと、「テスト書き忘れ」「ドキュメントが古い」問題がなくなります。
保存トリガー → 関連テスト実行
作成トリガー → Javadocコメント自動追加
削除トリガー → 依存関係チェック第3位: Steeringで「いつでも同じクオリティ」を維持
チームのコーディング規約・命名規則・禁止事項をSteeringに書いておけば、誰がKiroを使っても同じ基準でコードが生成されます。
---
inclusion: always
---
# チーム共通ルール
- 日本語でコメント・ドキュメントを記述する
- awsのリソースIDは環境変数から取得すること（ハードコード禁止）
- IAMポリシーは最小権限の原則を守ることこのファイルをGitでコミットしておけば、チーム全員が同じルールでKiroを使えます。
個人利用における注意点
1. クレジット消費を把握する
2026年6月時点のプラン構成（2026年8月時点でも大きな変更は確認できていませんが、最新の料金は公式サイトでご確認ください）：
| プラン | 月額 | クレジット/月 |
|---|---|---|
| Free | 無料 | 50 |
| Pro | $20 | 1,000 |
| Pro+ | $40 | 2,000 |
| Pro Max | $100 | 5,000 |
| Power | $200 | 10,000 |
- 超過分は $0.04/クレジット で追加課金
- 新規登録でソーシャルログインまたはBuilder IDを使用すると、最初の有料プランアップグレード時に$20クレジットが付与される
- クレジットは翌月に繰り越しされない
現在の消費量を確認するには： KiroのステータスバーまたはKiro設定画面（Kiro Panel → Usage）で今月の消費クレジットと残量が確認できます。Kiro CLIを使っている場合は /usage コマンドでも同様の情報を表示できます。予算超過に気づかず追加課金が発生するのを防ぐため、Hookを多用する場合は定期的にチェックする習慣をつけましょう。
クレジットを節約するコツ：
✅ Autoモードは品質・レイテンシ・コストを自動最適化
✅ Claude Sonnet 4.5は高精度な推論が必要なタスク向け
✅ Hooksの自動実行が多いと気づかずクレジットを消費する
→ 頻度が高いHookはAutoモードで実行しコストを抑える2. 機密情報を除外する
.kiroignore ファイルを作成し、Kiroに読み込ませたくないファイルを除外します。
# .kiroignore
.env
.env.*
secrets/
credentials.json
*.pem
*.key3. プロジェクト外ファイルへのアクセスは制限される
KiroはVSCodeで開いたワークスペース内のファイルしか扱えません。参照したいファイルが別のプロジェクトにある場合は、マルチルートワークスペースでフォルダを追加してください。
VSCode: ファイル → ワークスペースにフォルダを追加4. Specモードはアウトプットの確認が必要
Specモードで生成されたRequirementsはAIが推測して書いたものです。特に「受け入れ条件」はビジネス要件を正確に反映していない場合があります。必ず確認・修正してから設計・実装フェーズに進んでください。
5. .kiro/ ディレクトリのGit管理方針を決めておく
チームでKiroを使う場合、.kiro/ 配下のどこまでをGit管理に含めるか最初に決めておくとトラブルを防げます。
steering/・specs/：チームで共有すべきルール・仕様のためGit管理（コミット）を推奨- 個人用の設定・一時キャッシュ：
.gitignoreに追加し、各メンバーの環境差分がリポジトリに混ざらないようにする
steering/・specs/をコミットしておけば、前述のとおりチーム全員が同じルール・同じ仕様の前提でKiroを使えます。
よくある質問（FAQ）
Q1. VibeモードとSpecモード、迷ったらどちらを使えばいい？
迷ったらVibeモードから始めてください。ちょっとした修正や質問はVibeで十分こなせます。「複数ファイルにまたがる新機能開発」「後から仕様のズレに気づきたくない」といった場合にSpecモードへ切り替えるのが基本的な流れです。
Q2. HookとPowers、何が違う？
Hookは「ファイル保存」などIDE内のイベントに反応して自動実行される仕組みです。一方Powersは「Stripe関連のコードを書いている」などプロンプトの内容に応じて必要なMCPツールを自動でロードする仕組みです。Hookは「いつ実行するか」、Powersは「どのツールを使うか」を自動化すると考えると整理しやすいです。
Q3. 無料プランでもSpecモードやHookは使える？
使えます。Free/Pro/Pro+/Pro Max/Powerいずれのプランでも全機能にアクセスできます。プランの違いは主に月間クレジット数（Freeは50クレジット/月）であり、機能自体が制限されるわけではありません。ただしSpecモードやHookの自動実行はクレジット消費が多くなりがちなので、Freeプランでは使用頻度に注意してください。
Q4. Steeringファイルはチームで共有できる？
できます。.kiro/steering/ はプロジェクトのワークスペース内に配置されるファイルなので、Gitでコミットしてリポジトリに含めておけば、チームメンバー全員が同じルールを自動的に適用できます。個人用のルールを共有したくない場合は ~/.kiro/steering/（グローバル）に置き、Git管理対象外にしてください。
まとめ
AWS Kiroの主要機能を整理すると：
| 機能 | 用途 | レベル |
|---|---|---|
| Vibeモード | 質問・修正・即時実装 | 初心者から |
| Specモード | 要件定義から体系的に開発 | 中級者以上 |
| Steering | プロジェクトルールの永続化 | 初心者から（設定一回でOK） |
| Hook | 品質チェックの自動化 | 中級者以上 |
| Skills | 繰り返し作業のコマンド化 | 中級者以上 |
| Powers | MCP自動最適化 | 上級者向け |
| Kiro CLI | ターミナルからエージェント実行 | 中級者以上 |
使い始めのおすすめ順序：
- まずVibeモードで使ってみる
- Steeringに日本語設定と規約を書く
- よく使う作業をSkillsに登録する
- 自動化したい品質チェックをHookに設定する
- 大きな機能開発でSpecモードを試す
- CI/CDへの組み込みや自動化にはKiro CLIを活用する
関連記事：
- AWS Kiro完全ガイド｜Agentic IDEの全貌とは【セットアップ・料金・機能まで】
- AWS Kiro vs Claude Code vs Codex CLI徹底比較
- AWS構成図をKiroで自動生成｜Claude CodeとVSCode draw.io活用を徹底比較
- Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌
- Claude Sonnet 5・Fable 5 完全解説【2026年8月最新】性能・価格・選び方ガイド
タグ: #Kiro #AWSKiro #使い方 #Spec #Vibe #Hook #Steering #Skills #開発効率化 #初心者
コメント