ざっくり一言で
- Kiro：AI IDE に仕様ドリブン開発（SDD）を密結合。仕様の作成・更新・実装・テストまでエージェント＋IDEで一気通貫。
- OpenSpec：リポジトリ内の純 Markdown で仕様・タスク・設計を変更単位で集約。ツール非依存で持ち運べる軽量フレーム。
詳細比較
1) 目的・思想
- Kiro：大きめの機能開発を少ない試行で実装するため、IDE側の Specs とエージェントで反復改善。
- OpenSpec：ツールに依存しないポータブルな仕様資産。変更に関わる情報を一箇所に集約し追跡容易。
2) 運用形態（どこで動く？）
- Kiro：Code OSS ベースの AI IDE（VS Code 系）。MCP で外部データ・APIへ接続。
- OpenSpec：フォルダ＋Markdown のみ。IDE/AI アシスタントは任意。リポジトリで完結。
3) 仕様ファイルの置き場所・書式
- Kiro：IDEの “Specs” 機能で
requirements.md 等を分割管理。要求と設計の成長を前提。
- OpenSpec：
openspec/changes/<feature>/ 配下に proposal / specs / tasks を同梱。
4) ワークフロー（SDDの回し方）
- Kiro：着手→要件/設計/タスクリストをエージェント生成→実装・テストまで IDE 内で誘導（ステアリング＋MCP）。
- OpenSpec：
proposal.mdで目的、specs/*.mdで要件、tasks.mdで分解。合意→実装が素直。
5) ツール／標準との連携
- Kiro：MCP 経由で外部ドキュメントや API・DB を参照。IDE主導の自動化が豊富。
- OpenSpec：特定ツールに非依存。OpenAPI などの既存標準を併用可能（OpenSpec自体は仕様管理の型）。
6) チーム運用（可視性・追跡性）
- Kiro：仕様と実装がIDEで密結合。分割Specの反復進化を想定。
- OpenSpec：変更単位で一箇所に集約するためレビューと差分が明瞭。
7) 強み・弱み（要約）
Kiro
- 強み：IDE統合・MCP・ステアリングで実装まで一気通貫。
- 留意点：運用が Kiro 中心になりやすい（ロックイン傾向）。
OpenSpec
- 強み：道具に依存しない Markdown 運用／変更単位で追跡容易。
- 留意点：IDEレベルの自動化は別途組み合わせが必要。
どっちを選ぶ？（適用シーン）
- Kiro が向く：IDE を開発ハブにして仕様→実装→テストを自動化／外部 Docs・API を参照しながら大きな機能を前進。
- OpenSpec が向く：リポジトリだけで仕様資産を持ち、変更単位の合意→レビュー→実装の履歴をクリアに残したい。