Kiro vs Claude Code:Spec駆動開発・並列実行・コストを本気で検証してみた

はじめに

AWSのAI駆動開発IDE「Kiro」は、要件→設計→タスクの3段階を経てから実装に入る「Spec駆動開発」を売りにしている。一方Claude Codeは、要件を伝えればすぐに実装に着手する「Vibe Coding」的な使われ方が主流だ。

この2つを、以下4つの観点で実際に手を動かして比較した。

• ①生産性: Spec駆動とVibe型、同じ機能を作らせて何が違うか
• ②並列実行: 「独立したタスク」と「依存関係の強いタスク」で、並列実行の効果はどう変わるか
• ③コスト: Kiroのクレジット制とClaude Codeの従量課金制、実際の出費はどう違うか
• ④CI導入: 両者のheadless(非対話)実行を、同一タスクで比較する

結論を先に言うと、複雑なタスクではKiroの方がコストが高く付いた一方、軽量なタスクではKiroの方が大幅に安かった。さらに並列実行については、Kiroは独立タスクで確実に速く・安くなったのに対し、Claude CodeのSubagents並列は逆に遅く・高くなったという、対照的な結果が出た。詳細を見ていく。

検証の前提と制約

• 基準タスク: 「JWT認証付きTODO CRUD API」(ユーザー登録/ログイン、TODOの作成・一覧・更新・削除、他ユーザーのTODOへのアクセス拒否、正常系・異常系のテスト)を基本の基準タスクとして使用。テーマ④は軽量タスク(calculator.jsの2バグ修正、8テスト)を使用
• テストは各ツール・各実行が自律的に設計しており、テスト件数や網羅範囲は実行ごとに異なる。同一のテストスイートで採点したものではないため、パス率・件数の比較は目安として捉えてほしい
• Claude Code側の所要時間は、外部スクリプトで計測した壁時計時間(wall_duration_sec)を採用する。 Subagentsを並列起動するタスクでは、Claude自身が返す自己申告の所要時間(duration_ms)が、ツール実行の非同期待ち時間を含まず実態より大幅に短く出ることが分かったため。単一エージェントのタスクでは自己申告値と壁時計時間はほぼ一致しており、この乖離はSubagents並列時に特有の現象である
• Kiro側のモデル選択は「Auto」(Kiroが自動選択するモード)を使用しており、Claude Code側で明示的に選んだSonnetとは選定方法が異なる
• クレジットの$換算は、Kiro Proプラン($19/月、1000クレジット付与 → 1クレジット$0.019)を基準にしている

テーマ①: Spec駆動 vs Vibe型の生産性比較

同じ要件(JWT認証付きTODO CRUD API)を、Kiro(Spec mode)とClaude Code(Vibe型、指示なしで即実装)にそれぞれ実装させた。

	Kiro(Spec駆動)	Claude Code(Sonnet, Vibe型)
コスト	33.02クレジット(≒$0.627)	$0.394
所要時間	(計測データなし)	169.7秒
テスト結果	78/78パス	15/15パス
成果物	コード + requirements.md / design.md / tasks.md	コードのみ
DB実装	(Spec上の指定に準拠)	PostgreSQL想定のスキーマ・マイグレーション込み(テストはDBモック)

コストはKiroの方が約1.6倍高くなった。(Kiro側の所要時間は今回計測できていないため比較していない。)テスト件数はKiroが78件、Claude Codeが15件と大きな差があり、Kiroの方がテスト網羅性を厚く作り込んだ結果、コストも増えたと考えられる。両者ともテストは全件パスしている。

Claude Code側は、要件通りPostgreSQL想定のスキーマ・マイグレーションファイルを含めて実装しており、以前の検証で見られた「指定と異なるDBを使う」という要件からの逸脱は今回は見られなかった。

この時点で言えること: 今回の実行では、Kiroは「テスト網羅性の高さ」と「仕様書という成果物」を得る代わりに、コストが1.6倍程度高く付いた。同じコストで比較すると、Claude Codeの方が効率よく最小限の実装を仕上げた形になる。

テーマ②: 並列タスク実行の検証

「独立性の高いタスク(Pattern A)」と「依存関係の強いタスク(Pattern B)」を用意し、それぞれ並列実行と逐次実行を比較した。KiroはIDE上のSpec機能(Run all Tasks)、Claude CodeはSubagents機能を使っている。

検証セットアップ:2種類のタスク構造

**Pattern A(独立性の高いタスク)**は、「ユーザー登録」「TODO作成」「TODO一覧取得」「TODO更新」「TODO削除」という5つの機能で構成した。共有するのはDBスキーマ定義のみで、各機能はファイル単位で完全に分離されており、相互参照は一切ない。理論上は5並列で走らせてもボトルネックが生じない設計になっている。

**Pattern B(依存性の高いタスク)**は、「DBスキーマ設計 → ユーザーモデル実装 → 認証ミドルウェア実装 → 各エンドポイント実装(ミドルウェアに依存) → 統合テスト」という直列の依存チェーンで構成した。各ステップが前ステップの型・関数シグネチャに依存しているため、理論上は並列化できる余地がほとんどない設計になっている。

「Run all Tasks」とは、Kiro IDEの機能で、Specから生成されたタスク一覧を一括実行するモードを指す。タスク間の依存関係をKiro自身が解析し、依存のないタスクは自動的に並列実行し、依存のあるタスクは順序を守って実行する。人間が1つずつ「Run task」ボタンをクリックして進める「逐次実行」との対比としてこの記事では使っている。

Kiro側の結果

パターン	逐次実行	並列実行	時間の倍率	逐次クレジット	並列クレジット
A: 独立タスク	198秒	136秒	1.46倍高速化	2.94	1.66
B: 依存タスク	156秒	144秒	1.08倍高速化(僅差)	2.11	1.82

Kiroの並列実行は、独立タスクでは時間・コストの両方で明確に有利(1.46倍速く、クレジット消費も約56%に削減)だった。依存タスクでは時間の差はわずかだったが、コストはこちらも並列の方がやや低く済んでいる(2.11→1.82クレジット)。少なくとも今回の計測では、Kiroの並列実行が逐次実行より不利になる場面は見られなかった。

Claude Code側の結果

パターン	逐次実行(壁時計)	並列実行(壁時計、Subagents)	倍率	逐次コスト	並列コスト
A: 独立タスク	296秒	309秒	1.04倍低速化	$0.653	$1.012
B: 依存タスク	225秒	445秒	1.98倍低速化	$0.516	$1.006

Claude CodeのSubagents並列は、Kiroとは対照的に両パターンとも逐次実行より遅く、かつ高コストという結果になった。特にPattern B(依存タスク)では約2倍の時間がかかっている。Subagentsを並列起動すると、各エージェントが個別にツール実行を行うためのオーバーヘッド(通信・調整・待機)が発生し、それが並列化による処理時間短縮の効果を上回ったと考えられる。コスト面でも、複数のSubagentがそれぞれコンテキストを持つ分、単純に消費トークンが増える。

対照的な結果をどう見るか

同じ「並列実行」という機能でも、KiroとClaude Codeで真逆の結果が出たことは、この検証で最も興味深い発見だ。

• Kiro: 並列実行(Run all Tasks)は、タスクの独立性が高いほど時間・コストの両面で有利。依存タスクでも不利にはならない
• Claude Code: Subagentsによる並列委任は、今回計測した範囲では常に不利(遅く、高コスト)だった

これは機能の優劣というより、アーキテクチャの違いによるものと考えられる。Kiroの並列実行はIDE内のタスクランナーとして最適化されている一方、Claude CodeのSubagentsは「独立したコンテキストを持つ子エージェントに委任する」という汎用的な仕組みであり、委任・調整のオーバーヘッドが相対的に大きい。Claude Codeで並列化のメリットを得るには、委任するタスクの粒度・独立性を慎重に見極める必要がありそうだ。

具体的にどんな場面でどちらが有利になるかを整理すると、以下のようになる。

• Kiroが有利になりそうな場面: 「複数のCRUDエンドポイントを一括生成したい」「複数のReactコンポーネントを並行して雛形生成したい」といった、タスクの独立性を設計段階で保証できる場面。今回の基準タスクで言えば、「登録・作成・一覧・更新・削除」を1つのSpecから一気に作らせるようなケースがこれにあたる。
• Claude Codeが有利になりそうな場面: 「認証基盤の構築」のような、依存関係の強い一連の処理を素早く仕上げたい場面では、無理にSubagentsで並列委任せず単一エージェントに任せた方がよい。逆にSubagentsが活きるのは、「セキュリティ・パフォーマンス・QAなど複数の専門的観点で深くレビューさせたい」といった、独立した専門知識を要する検討を並行して行わせたい場面だ(コスト増を許容できる場合に限る)。

言い換えると、「並列に投げて時間を削減したい」ならタスクの独立性を事前に設計できるKiroが向いており、「1つのエージェントにじっくり考えさせたい、あるいは独立した専門的な検討を並行させたい」ならClaude Codeが向いている、という使い分けになる。

テーマ③: コスト比較(クレジット vs トークン)

テーマ①と同じ基準タスクのコストを、Kiro・Claude Codeで比較する。

	Kiro(Spec, Autoモデル)	Claude Code(Sonnet, 実行1)	Claude Code(Sonnet, 実行2)
コスト	33.02クレジット(≒$0.627)	$0.394	$0.363
テスト結果	78/78パス	15/15パス	21/21パス

Kiroは Claude Codeの2回の実行と比べて、約1.6〜1.7倍高いコストになった。 これはテーマ①でも触れた通り、Kiroがテストをより厚く作り込んだ(78件)ことが主因と見られる。同程度のテスト網羅性で揃えれば差は縮まる可能性があるが、少なくとも「Spec駆動によって自動生成される検証の手厚さ」自体が、コスト増の一因になっていることは分かる。

なおKiro側は「Auto」モードでの実行であり、Claude Code側のようにモデルを明示指定していない点は留保しておきたい。

テーマ④: CI導入検証(headless実行の比較)

Headless実行とは

Headless実行とは、GUIや対話的なやり取りを介さず、コマンド一発でAIエージェントを最後まで自動実行させることを指す。IDE上でのやり取りは人間が途中で確認・入力する前提だが、CI/CDパイプライン(GitHub Actions等)に組み込むには、この「無人で完走できる」ことが必須条件になる。

今回の検証では、同一の軽量タスク(calculator.jsの2バグ修正、8テスト)を、KiroとClaude Codeそれぞれのheadlessコマンドに投げ、以下を計測した。

• CI環境で無人のまま成功できるか(exit codeで判定)
• 無人実行時の所要時間・コストの実測値
• セットアップ(認証・必要プラン)の手軽さ

これによって、「実際にCI/CDパイプラインへ組み込めるかどうか」「組み込んだ場合のランニングコストはどの程度か」が分かる。

KiroにはIDEとは別に、ターミナルエージェント「kiro-cli」が提供されている。--no-interactiveフラグでheadless実行が可能で、認証は環境変数KIRO_API_KEYによるAPIキー方式(Pro以上のプランが必要)。

export KIRO_API_KEY=<your-key>
kiro-cli chat --no-interactive --trust-all-tools "タスク内容"

項目	Kiro CLI headless	Claude Code headless(同一タスク)
所要時間	41秒(ログのend_timeが一部欠落しており推定値)	19.45秒
コスト	0.56クレジット(≒$0.011)	$0.0515
テスト結果	(exit code 0、正常終了)	8/8パス

所要時間はClaude Codeの方が約2.1倍速く、一方でコストはKiro CLIの方が約4.9倍安価だった。テーマ③(複雑なタスク)ではKiroの方がコストが高かったのに対し、テーマ④(軽量タスク)ではKiroの方が大幅に安いという、真逆の傾向が確認できた。

これはテーマ①・③の結果と合わせて読むと一貫性がある。タスクの複雑さ・テスト網羅性の作り込みが増えるほどKiroのコストは(相対的に)膨らみやすく、逆に軽量なタスクではクレジット制の効率の良さが際立つ、という構造がありそうだ。CI/CDパイプラインで想定される用途(小さな自動チェック・軽微な修正タスクを高頻度で回す)はまさにこの「軽量タスク」の領域に当たるため、CI用途に限れば、コスト面はKiro CLIに分があると言えそうだ。

CI導入における注意点

kiro-cliの利用にはPro以上のプランが必要で、無償プランでは利用できない。一方Claude Codeはnpm install一発の単一パッケージでclaude -p --output-format jsonによるheadless実行が完結し、所要時間・コスト・トークン数まで構造化データとして返ってくる(今回の全ての計測もこの仕組みを使って自動化した)。セットアップの容易さという点ではClaude Codeに分があるが、CI統合そのものは両者とも十分に実現可能という結論になる。

全体まとめ

テーマ	主な発見
①生産性	所要時間は互角。Kiroはテスト網羅性が高い分、コストは約1.6倍高い
②並列実行	Kiroの並列実行は独立タスクで1.46倍高速化・低コスト化。Claude CodeのSubagents並列は逆に最大2倍近く低速化・高コスト化
③コスト	複雑なタスクではKiroの方が約1.6〜1.7倍コストが高い
④CI導入	軽量タスクではKiro CLIが約4.9倍安価。所要時間はClaude Codeが約2.1倍速い

ビジネス視点での考察

コストの優劣は「タスクの性質」で入れ替わる

今回の検証で一貫して見えたのは、タスクの複雑さ・テスト網羅性によって、どちらが安いかが逆転するという構造だ。複雑な機能実装(テーマ①・③)ではKiroの方がコストが高く、軽量な修正タスク(テーマ④)ではKiroの方が大幅に安い。これは「Kiroは高い/安い」という単純な結論ではなく、用途によって最適なツールが変わるということを意味する。まとまった機能を一度に作らせるならClaude Code、CI上で軽微なチェック・修正を高頻度に回すならKiro CLI、という使い分けが、少なくとも今回のデータからは支持される。

並列実行の「効きやすさ」はアーキテクチャで決まる

テーマ②の結果は、並列実行機能を持つツールを導入・運用する際の重要な教訓を含んでいる。同じ「並列実行」という言葉でも、実装アーキテクチャによって効果は大きく異なる。 Kiroのタスクランナー型の並列実行は今回、独立タスクで確実に速度・コストの両面で有利だった一方、Claude CodeのSubagentsによる並列委任は、委任・調整のオーバーヘッドが大きく、今回計測した範囲では常に不利だった。

これは「Claude CodeのSubagentsが劣っている」という単純な話ではなく、Subagentsは『独立した専門性を持つエージェントに深く考えさせる』ことに向いた仕組みであり、『単純作業を並列にこなして時間を削減する』用途には必ずしも向いていない、という使い分けの問題だと捉えるべきだろう。組織としては、並列実行機能を導入する際、「機能名が同じだから同じ効果が出る」と期待せず、実際のアーキテクチャと自分たちのタスク特性に照らして検証する必要がある。

「仕様書という成果物」の対価をどう評価するか

Kiroが生成するrequirements.md/design.md/tasks.mdや、より手厚いテストスイートは、テーマ①・③で見た通り、追加コストとして表れていた。監査・引き継ぎ・後任者へのオンボーディングや、高いテスト網羅性を重視する組織にとって、この追加コストは投資として正当化できるかもしれない。逆に、スピード重視でとにかく動くものを最小コストで得たいチームであれば、Claude Codeの方が今回のデータでは効率的だった。「同じコストで何を得られるか」ではなく「欲しい成果物にどれだけの追加コストを払う価値があるか」という発想でツールを選ぶのが実務的だろう。

まとめ

Kiro・Claude Codeという2つのAI駆動開発ツールを、Spec駆動 vs Vibe型・並列実行・コスト・CI導入の4軸で検証した。最大の発見は、タスクの複雑さによってコストの優劣が逆転することと、並列実行の効果がツールのアーキテクチャによって正反対の方向に出たことだ。複雑なタスクではKiroの方がコストが高く、軽量なタスクではKiroの方が大幅に安い。並列実行はKiroでは有利に働いたが、Claude CodeのSubagentsでは不利に働いた。

コストにも並列実行の効果にも単純な優劣がつかない以上、ツール選定は「どんな成果物を得たいか」「タスクの複雑さ・頻度はどの程度か」「並列化したいタスクの構造がそれぞれのアーキテクチャに合っているか」という、より踏み込んだ観点で判断する必要がある。

なお本検証には、テスト件数の不一致・Kiro側のモデル選択(Auto)・クレジット単価の換算が特定プラン前提であることなど、いくつかの制約がある。数字は参考値として捉え、実際の導入判断の際は自組織のタスクで再検証することを推奨する。