AWSのKiroはどうなのか――Claude Codeと「予約のキャンセル機能」で比べる

「予約をキャンセルできるようにして」と頼んだら

画面にボタンが付き、クリックすると予約が消えました。デモは成功です。その翌日、窓口から「キャンセルしたのに空き枠に戻っていない」と連絡が来ます。実装時の依頼に「枠を戻す」と書いていなければ、ボタンをうまく作れたことと、窓口が必要とした機能の完成は一致しません。

AWSのAI開発ツールKiroを試す理由があるのは、こうした食い違いで困っているときです。Kiroには、機能の要求、技術設計、実装タスクをファイルに残し、その文書から作業を進めるSpecsがあります。「Claudeと比べて使えるか？」という問いには二つの比較が混ざっています。ClaudeはAnthropicのモデル名でもあり、Kiro自身もClaudeモデルを提供しています。リポジトリを読み、編集し、テストする道具として比較する相手はClaude Codeです。^[2][3][4]

以下は2026年11月14日時点の公開仕様を、一つの架空の予約サービスに当てはめた比較です。両製品で実測した勝率や所要時間は示していません。焦点は、作業のどこで人が判断でき、その判断がどんな形で翌日の担当者に残るかです。

Kiroの仕様書を、予約機能ならどう埋めるか

通常のFeature Specでは、要求と受け入れ条件を requirements.md に、構成と実装方針を design.md に、実行できる単位の作業を tasks.md に記録します。最初に要求を整理する流れのほか、既存の設計を出発点にする方法もあります。これらのファイルを作るだけなら、人間でも別のAIでもできます。Kiroを選ぶ意味は、文書の確認からタスク実行までが製品の操作としてつながっている点にあります。^[2]

ここで一番価値があるのは、きれいな三つの文書より、「期限ちょうどに押した場合は？」という一行のコメントかもしれません。画面を見てから決めると、UI、サーバー、テストがそろって修正対象になります。要求の段階なら、窓口担当者が「開始時刻の24時間前ちょうどまでは可」と決め、開発者は比較条件とタイムゾーンを設計に残せます。この判断をするのは、そのサービスの方針を決められる人です。

Claude Codeで同じ依頼を進めると何が違うか

Claude Codeでも、既存の予約処理を読み、編集前に計画を立て、差分を作ってテストを回せます。Plan Modeで既存コードを調べ、計画をレビューする方法は公式に案内されています。プロジェクトの規約をCLAUDE.mdに置いたり、仕様書の更新を完了条件に含めたりすれば、判断をリポジトリに残せます。Claude Codeを選ぶと毎回チャットだけで完結する、という前提では比べられません。^[4][5]

違いが出る場面を二つ考えます。まず「取消ボタンのラベルに誤字がある」。修正対象と確認方法は明らかです。既存の開発環境から該当箇所を探し、差分を一つ確認する流れが短いでしょう。Kiroを使う場合にも、こうした仕事を毎回フルのSpecにする必要はありません。よく分かっている機能向けには、三つの文書を一度に作るQuick Specもあります。^[2]

次は「窓口、会員、決済会社にまたがる取消」。会員画面では取り消せても返金に失敗する場合があり、同じ操作を二度受けることもあります。ケースを担当者と先に眺め、実装後も対応関係を追うなら、Kiroの定型の置き場所が効きます。すでにClaude Codeと既存のチケットで同じ運用が回っているチームでは、新しい文書との二重更新が増えます。移行の損得を決めるのは、どちらのモデルが気の利いた返事をするかより、誰が二つの記録を揃えるのかです。

使い込むほど効く部分と、増える手間

KiroのSteeringには、複数の作業で繰り返し使うプロジェクトの決まりを置けます。たとえば「予約時刻はUTCで保存し、表示時に施設のタイムゾーンへ変換する」という決定です。次の機能がリマインダー配信なら、この一行を再利用できます。「読みやすく書く」のように判断が変わらない抽象的な指示を積み上げるより、以前に実際に迷った選択を残す方が維持しやすくなります。^[6]

Hooksはイベントに応じて処理を起動する仕組みです。予約の変更に関連したテストを回すなど、繰り返しが多く結果を確認できる仕事が候補になります。ただし保存のたびに大きなテスト一式が走れば、待ち時間が増えます。最初は対象を絞り、実行回数と時間を測ると、手動のままがよい作業も見えてきます。Claude CodeにもHooksがあります。フックの有無を比較表の丸印にするより、自分のチームが既存のテストをどこに接続しやすいかを見る方が実用的です。^[7][8]

逆に、運用が変わったのに文書が古いままなら、次の担当者は一貫して古いルールを実装してしまいます。Kiroに慣れるほど使えるという見方には、「判断を共有する人がいて、変更時に文書も手入れする」という条件が付きます。一人で短期間に捨てる試作なら、その手入れに見合う次の担当者や二回目の変更が来ないこともあります。

料金は「一回の質問」より「終わった仕事」で見る

個人向けの公式料金表ではFreeは月50クレジット、Proは月20米ドルで1,000クレジット、Pro+は月40米ドルで2,000クレジットです。Freeの掲載モデルにはClaude Sonnet 4.5とオープンウェイトモデルが含まれます。Proの追加クレジットは1クレジット0.04米ドル。たとえば追加分を250クレジット使う条件なら、追加額は10米ドルです。税・為替を含まない単純計算で、予約機能一件が250クレジット掛かるという見積もりではありません。^[3]

クレジットは「テストに合格した機能一件」の単位ではありません。長い調査、指示のやり直し、選択モデルが違えば同じ予算で終えられる仕事も変わります。すでにClaude Codeを契約している人なら、Kiroを追加する月額と、レビューの時間がどれくらい減るかを分けて考えられます。月末の請求だけだと、安く済んだ理由が効率化なのか、単に使わなかったのか判別できません。

同じ月額でも比べにくいのはなぜか

月初に一つの機能を作り、残りはたまに質問する個人と、毎営業日に既存の仕様を更新するチームでは、同じプランでも見るべき明細が違います。前者では初めてリポジトリを読ませる時間や一度限りの環境設定が大きく見えます。後者では二回目以降に同じ説明を省けるか、何人が別々に同じ調査をしているかが効いてきます。無料枠を使い切った時点で導入の可否を決める前に、何が一度限りで、何が翌月も発生するかをメモしておくと比較しやすくなります。

試した結果を他人に渡すときには、製品名に加え、使った日、モデル、プラン、対象コミットを残します。「Kiroに予約機能を頼んだ」という記録だけでは、翌月同じ依頼をして回答が違ったとき、モデルの違いか、すでにリポジトリに仕様書が入ったからかを切り分けられません。Claude Code側だけに過去半年の開発規約が揃っていた場合も、初期状態からの製品比較と、現実の乗り換え費用の比較では読み方が変わります。

誰が仕様書を読むのかで、価値は変わる

予約を例に、窓口担当者には「取消済みになった後にもう一度押すとどう見えるか」を聞きます。経理担当者には「予約を取り消した時刻と返金が確定した時刻を別に残す必要があるか」を聞きます。同じ文書でも、担当者によって答えられる問いが違います。長い技術設計を全員に回して承認を集めると、それぞれが何を確認したか分からないまま手続きだけが増えます。該当する受け入れ条件を一つ選んで見せる方が、訂正の理由まで記録しやすくなります。

たとえば「返金が確定したら通知する」という要求を読んで、窓口から「取消受付の時点にも一通必要」と指摘されたとします。ここで生まれるのは文章の修正だけではありません。通知が二種類になり、同じメールが二度届かない条件が増え、問い合わせに答えるための履歴も必要になります。こうした連鎖を実装前に見つけた回数は、生成行数には現れません。Kiroの試用記録には、レビューがなければ後工程に残っていた決定を、一件だけでも具体的に書く余地があります。

一方、予約ルールを決める人が常に実装者の隣にいて、同じ画面を見ながら数分で直せる現場なら、意思決定を速くするのは短い対話かもしれません。後日問い合わせが来たときに必要な一行をチケットへ残せば目的は達します。チームの人数だけで「仕様駆動向き」と決めるより、判断した人と次に変更する人の間に何日、いくつの部署、いくつのシステムが挟まるかを見る方が、導入の理由を説明できます。

無料枠で判断するなら、二日目にもう一度開く

同じコミットを二つ用意し、両方に「予約をキャンセルできるようにする」と、同じテスト用データを渡します。モデルをそろえられる場合はそろえ、違えば名前を記録します。人が与える回答もそろえます。採点に使うのは、正常系、期限ちょうど、再送、他人の予約の四ケース。そこに修正回数、レビューに費やした分数、使用量を添えます。これは再現可能な試し方の提案です。

二日目に「窓口担当者は期限後も取り消せる」と一つだけ条件を変えます。前日のチャットを読み返さずに、どこを直すか、どの既存テストが残るか、返金ルールへの影響があるかを説明できるでしょうか。最初の生成が少し遅くても、この変更を別の人が迷わず引き取れれば、仕様に払った時間は回収できます。

判断を後から何度も使う開発なら、Kiroを一機能だけ試す理由があります。 反対に、仕様もテストもすでにチケットとコードで追え、Claude Codeで短い差分を気持ちよく回せているなら、乗り換えを急ぐ材料はありません。「使える」の意味を、最初の返事の賢さから、翌日の変更を引き継げるかまで広げると、自分の仕事に合う答えが出ます。

不具合修正で分かる「変えてはいけない挙動」

新規機能の要求整理とは別に、KiroにはBugfix Specがあります。ここでは観測した不具合、期待する挙動、従来どおり保つ挙動を記録します。予約取消をリリースしたあと「同じ取消リクエストを再送すると、空き枠が二つ増える」という報告が来たとします。新機能の文書を最初から書き直すより、どこが壊れているかを小さく囲む方が、直し過ぎを防げます。^[1]

この例で記録する「現在」は、同じ予約番号を二度取り消すと枠が二つ増えること。「期待」は、二度目を受けても空き枠は一つだけ増えた状態を保つことです。さらに「別々の二件を取り消せば、合計二枠が戻る」と添えます。最後の条件がないと、重複を防ごうとして、正当な二件目まで無視する修正が通るかもしれません。失敗を一つ消すことと、その周囲の仕事を保つことを、レビューで別々に見られる形になります。

Claude Codeでも、この三つをチケットに書いてから修正を依頼できます。過去の不具合で同種の条件を書き忘れることが多かったチームなら、最初から記入欄があることに価値があります。逆に既存の不具合票が同じ問いを含み、テストのリンクまで自動で戻るなら、記録をさらに一面増やす理由は弱くなります。チームの過去のバグを一件だけ選び、二つの流れのどこで見落としに気づけたかを照らすと判断しやすくなります。

採点で迷いやすい三つの場面

第一に「エージェントがたくさん質問した」こと。開始時刻のタイムゾーンを尋ねた質問は、窓口と会員の食い違いを防ぎます。リポジトリに明記されているテストコマンドを人に聞いた質問は、その分だけ作業を戻します。質問の数で一律に減点すると、必要な確認を避けて早く進む製品が有利になります。人だけが答えられた質問か、すでにコードから調べられた質問かを手元に記録します。

第二に「テストが全部通った」こと。生成したテストが、同じエージェントが仮定した振る舞いを確認しているだけなら、実装とテストがそろって期待を外すことがあります。予約の例なら、主催者に確認した期限の境界を独立した固定データにしておきます。修正後にテストを変更して合格した場合には、なぜ期待値を動かしたかもレビューします。これならツールの自己申告に頼らず、利用者にとって大切な挙動を見られます。

第三に「早く終わった」こと。AIが動いていた時間と、人が画面につきっきりだった時間を分けます。設計を書くために五分待っていても、別の仕事を進められたなら負担は小さいかもしれません。反対に五分ごとに確認を求められる運用は、合計時間は短くても集中を切ります。引き継ぐ人が文書を読む時間も含め、どこで手間が減り、別の誰かに移った手間は何かを見ると、長期に使ったときの評価に近づきます。

参考文献・出典

1. [1]Kiro・不具合の現状、期待、維持する挙動を定めるBugfix Specs ↩
2. [2]Kiro・Specsと実行フロー ↩
3. [3]Kiro・プラン別クレジットと利用モデル ↩
4. [4]Anthropic・Claude Code概要 ↩
5. [5]Claude Code・計画から実装までのワークフロー ↩
6. [6]Kiro・Steering ↩
7. [7]Kiro・Hooks ↩
8. [8]Claude Code・Hooks ↩