コードより先に仕様を書く、Kiro は一文を実行できる Spec に変える
要約
ひとつの文が、目を通して承認できる三つの文書になる。着手前に要件の矛盾を自動推論で確かめ、単体テストが取りこぼす境界を性質ベースのテストで補う。
おすすめ- ソフト名
- Kiro
- バージョン
- 1.0.437
- オープンソース
- 非オープンソース
- OS
- WindowsmacOSLinuxWeb
- 公式サイト
- https://kiro.dev
- 更新日時
- 2026-10-29 22:00
まず何が欲しいのかを AI に書かせ、それからコードを書かせる。仕様が「当て推量」を「実装」に変える。
モデルと一緒にコードを書くと、避けられない問題にぶつかる。話が粗ければ粗いほど、向こうの推測は的外れになる。ブログにコメント機能を足してくれと一言投げれば、まるで雰囲気の違う実装が三つ返ってきて、直しているうちに最初に何が欲しかったのか誰も覚えていない、ということが起きる。Kiro は順序を逆にする。まず要件を、自分が目を通せる仕様として書き出し、それからエージェントに仕様どおりに建てさせる。
Kiro は AWS が作り、運用している。2025 年 7 月の公開を経て、いまは正式提供だ。この話を一文にまとめると、AI コーディングから agentic engineering へ、となる。単なる会話型の補完の道具ではなく、要件、設計、タスク、実装を一本につなぐ流れの仕組みである。

仕様駆動。ひとつの文が三つの文書になる
中核は仕様駆動の開発だ。自然な言葉の記述をひとつ渡すと、順に三つの文書を出す。要件の文書は、要望を利用者の物語と受け入れの基準に分解する。設計の文書は、構成、技術の選択、システムの設計を示す。タスクの文書は、依存の順に並べた作業の一覧になる。既定ではプロジェクト内の仕様ディレクトリに置かれ、コードと一緒にリポジトリへ入れることを公式は勧めている。
要件の書き方には触れておく価値がある。受け入れの基準は EARS の構文で書かれる。形はおおよそ「ある条件が成り立つとき、システムはこうする」というものだ。この記法は航空の安全系統に由来し、曖昧な記述を検証できる言明に追い込むところに値打ちがある。境界の場合が抜け落ちにくくなる。
三つの文書はどれも、確認のために一度止まる。要件を書き換え、技術の方針を却下し、作業の順番を入れ替え、納得してからエージェントに一つずつ実行させる。すべて差分として示され、まとめて受け取ることも一行ずつ見ることもできる。
コードを書く前に、要件が矛盾していないか確かめる
あまり見かけない動きがひとつある。一行も書く前に、自動推論の手段で要件の中の衝突と欠落を調べるのだ。公式の説明は率直で、テストが全部通ることはコードが意図に合っていることを意味しない、だから意図そのものを先に検証する、という。
実装のあとにはもう一段の検証がある。性質ベースのテストで、曖昧さを狙うテストの親戚にあたる。普通の単体テストは具体的な事例をいくつか確かめるが、性質ベースのテストが言明するのは「あらゆる入力で成り立つべき規則」であり、単体テストを通り抜けて本番で崩れる境界を捕まえやすい。
Steering と Hooks。プロジェクトの決まりを固める
新しい会話のたびに「型は厳格に」「テストはソースの隣に」と言い直すのは、なかなか根気を削る。そのために steering のファイルがある。steering ディレクトリに置く Markdown の文書が、構成の判断、コーディングの規約、命名の取り決めといった長く効く知識を担い、Kiro はコードを生むときや変更を見るときに自動で参照する。読み込み方は三つあり、常時、ファイルの条件による照合、手動での指定。AGENTS.md のような一般的な取り決めにも対応する。
エージェントフックは「身につけるべき習慣」を自動の実行に変える。ファイルの保存、作成、削除といった出来事を定義し、起きたら用意しておいた仕事をエージェントに走らせる。部品を保存したらテストのファイルを足す、API の端点を変えたら文書を追わせる、コミットの前に資格情報の漏れを走査する。公式はこれを、手元で走る継続的インテグレーションにたとえる。違いは、判定の論理を設定の文法ではなく自然な言葉で書けることだ。
四つの姿、ひとそろいの設定
Kiro はいま、統合環境、コマンドライン、ウェブ、モバイル、そして Kiro Crew という持続する開発の作業場所を出す。統合環境はオープンソースのエディタの土台の上にあり、いま使っている設定、テーマ、拡張を取り込めるので移る負担は小さい。コマンドラインは bash、zsh、fish と五百を超える一般的な CLI に対応し、画面なしでパイプラインの中に入り、Pull Request を見たり不具合を直したりもする。
ウェブのセッションは隔離されたクラウドのサンドボックスで走り、ノートを閉じても続く。変更は複数のリポジトリにまたがって調整できる。Kiro Crew はオープンソースのプロジェクトで(Apache ライセンス)、自分のマシンで動き、セッションを越えてコンテキストを保つ。性格としては長く伴走する開発の作業場所に近い。

モデルは選ばなくていい
Kiro はモデルを自分で選ばせない。既定の Auto がタスクの複雑さに応じ、品質と遅延と費用をにらんで振り分ける。明示して指定することもでき、Claude Sonnet の系統や、無料の段階で使える Qwen3 Coder Next のような公開の重みのモデルも選べる。有料の段階ではさらに進んだモデルが開く。
計量の単位はクレジットで、プロンプトごとに消費し、小数第二位まで記録される。簡単な依頼なら一つも使わないことがある。統合環境の中では、どのプロンプトにいくらかかったかがその場で見えるので、請求が突然暴れる心配はない。
価格と始め方
無料の段階は長期に有効で、毎月五十クレジットが付き、カードの登録も要らない。主要なモデルも使えるので、まず仕様の流れを一度通して手触りを見るのに向く。有料は月二十ドルで千クレジット、四十ドルで二千、百ドルで五千、二百ドルで一万。足りなければ一つ四セントで足せる。チーム向けと企業向けには、請求の集約、シングルサインオン、利用の一覧、権限の統制が加わる。
サインインは GitHub、Google、AWS Builder ID、AWS IAM Identity Center に対応し、AWS のアカウントは要らない。ここはよく誤解される点だ。デスクトップは Windows、macOS、Linux を覆う。
Kiro が解こうとしているのは、AI がどれだけ速く書くかではなく、書かれたものが本当に欲しかったものかどうかだ。要件をまず、目を通せて版管理に入る仕様として固め、それからエージェントに実装させる。手戻りと押し問答の回数は目に見えて減る。長く保守し続けるプロジェクトなら、この規律は払う価値がある。