Spec-first · Bedrock · Steering Documents · Amazon Q後継
2025年12月の障害事例: KiroがAWS本番環境で「削除して再作成」を実行し13時間の障害が発生。本番環境のDB・インフラへの削除権限は絶対に与えないこと。
approval_policy: "on-request" 以上を必須設定にするKiro GA
初回GA: AWS Kiro CLIが正式パブリックリリース。Amazon Q DeveloperのEOS（2027-04-30）に向けた移行先として位置づけられている。
Spec-firstワークフロー: Requirements（要件）→ Design（設計）→ Tasks（タスク）の3段階仕様書から実装を追跡する独自ワークフローが特徴。
Bedrock統合: Claude 3.7 Sonnet / Claude 3 Opus / Amazon Titan / Llama 3 / Mistral Large の5モデルをBedrockを通じて選択可能。
VS Code拡張: Kiro Extension for VS Codeが同時リリース。Spec-firstフローをIDE内で完結できる。
⚠️ 重大
KiroエージェントがAWS本番環境で「削除して再作成」オペレーションを実行し、13時間のサービス障害が発生。
根本原因: エージェントに本番DB・インフラの削除権限が与えられていた。承認ポリシーが適切に設定されていなかった。
対策: permissions.allow_production: false を設定し、本番環境へのエージェントアクセスを明示的にブロックする。IAMロールは最小権限原則を徹底する。
この事例はKiro固有の問題ではなく、本番アクセス権限を持つあらゆるAIエージェントに共通するリスクとして認識すべき。
Kiro Preview
AWS re:Invent 2025でKiro CLIが初回プレビュー公開。Spec-firstアプローチとBedrock統合が初めて発表される。Amazon Q Developerのエージェント機能の後継として位置づけられた。
コミュニティの反応: Spec-firstの構造的アプローチが好評を博した一方、セキュリティ設定のデフォルトが甘いという指摘も多かった（後の本番事故の伏線）。
// .kiro/settings.json { "model": "anthropic.claude-3-7-sonnet", "provider": "bedrock", "region": "us-east-1", "permissions": { "allow_production": false, // 本番環境アクセスを禁止 "allow_delete": false, // 削除操作を禁止 "approval_policy": "on-request" // 全操作で承認要求 }, "spec_required": true // Spec未定義なら実装拒否 }
| モデルID | コスト比 | 推奨用途 |
|---|---|---|
anthropic.claude-3-7-sonnet | 1.0x | 複雑な実装・アーキテクチャ分析 |
anthropic.claude-3-opus | 3.0x | 高品質レビュー・設計 |
amazon.titan-text-premier | 0.3x | ルーティング・軽量タスク |
meta.llama3-70b-instruct | 0.4x | コスト重視タスク |
mistral.mistral-large | 0.6x | コード生成・補完 |
| ステップ | ファイル | 内容 |
|---|---|---|
| 1. Requirements | .kiro/specs/*/requirements.md | ユーザーストーリー・受け入れ基準 |
| 2. Design | .kiro/specs/*/design.md | アーキテクチャ・データモデル・インターフェース |
| 3. Tasks | .kiro/specs/*/tasks.md | 実装チェックリスト（順序付き） |
| 4. Implement | コードベース | Kiroがタスクリストを追跡しながら実装 |
Specをコードと同じGitリポジトリで管理することで仕様とコードのドリフトを防ぐ。Kiroを使いながらSpecを書かないチームはコストだけ払って恩恵を受けていない。
.kiro/steering/ product.md # プロダクト概要・目標 architecture.md # システム設計・制約 tech.md # 技術スタック・コーディング規約
Steering DocumentsはSpec-firstフロー内で自動参照される。CLAUDE.mdのRouter設計と同様に、必要な情報へのポインタとして管理する。
KiroのHooksはYAMLベースでfile_saveトリガーのみ対応。Claude Codeの5種類（PreToolUse/PostToolUse/Stop/Notification/SubagentStop）と比べると機能が大幅に限られる。
# .kiro/hooks/lint-on-save.yaml name: lint-on-save trigger: file_save command: npm run lint --fix {{file_path}}
YAMLベースで定義。専用の.kiro/hooks/ディレクトリで管理。Claude CodeのPostToolUse Hookに近い概念だが、トリガー種類が少ない。
# .kiro/agents/security-reviewer.yaml name: security-reviewer model: claude-opus-4-7 system_prompt: | Security expert. Focus on OWASP Top 10. Provide specific, actionable findings only. tools: [read_file, search_code] permissions: allow_write: false # レビューエージェントは読み取り専用に
Claude CodeのManaged Agents（Dreaming / Outcomes / Multiagent Orchestration）に相当する機能はKiroに存在しない。
| 機能 | Kiroでの代替 |
|---|---|
| Dreaming（記憶精製） | Steering Docsに学習・ルールを手動で蓄積 |
| Outcomes（評価ループ） | Spec/Tasksのチェックリストで進捗を追跡 |
| Multiagent Orchestration | 複数Subagentを.kiro/agents/に定義して手動管理 |
Kiroの強みはSpec-firstによる仕様の明確化。マルチエージェント制御よりも「仕様書を書いて確実に実装を追跡させる」スタイルが向いている。
Claude CodeのRoutines（cron）やCodexのAutomations（cron + webhook）に相当する定期実行機能はKiroに実装されていない。
| 用途 | 代替手段 |
|---|---|
| 定期コードレビュー | GitHub Actionsのcronジョブでkiroコマンドを呼び出す |
| 定期ドキュメント更新 | AWS Lambda + EventBridgeでkiro CLIを定期実行 |
| 完了通知 | HooksのPostToolUseでAmazon SNS/SQSに通知 |
外部cronを使う場合は、実行ユーザーのIAMロールに最小権限を設定することを必ず確認すること。