KiroがGAに達してから8か月、長続きしたアイデアはspecであり、最も長続きしなかったのはIDEだったことが分かってきた。Kiroはエージェント型IDEとして登場し、仕様レベルで作業しエージェントに実装を任せるという触れ込みだった。実際に定着したのは成果物の方だ。コードが存在する前に人間がレビューする、書かれた意図の表明。そして静かに失われた前提は、それが行われる場所がエディタだという想定だった。KiroはGA時点でCLIを出荷し、その後ヘッドレスモードを追加し、興味深い使われ方はターミナルの方に向かっていった。

私は昨年末、AWS Monthly (Dec '25): The Kiro Era BeginsでKiroのGAについて書いた。当時は距離を置くよりも熱意のほうが勝っていた。8か月あれば、その内容のどの部分が持ちこたえたかを言うには十分な時間だ。

実際に何が出荷されたのか

Kiroは2025年7月にプレビューに入り、2025年11月17日にGAに達した。GAは安定版リリースではなく、スコープを広げるリリースだった。specの受け入れ基準からテストケースを導出するプロパティベーステスト、エージェントの変更を巻き戻せるチェックポイント機能、マルチルートワークスペース対応、AWS IAM Identity Centerを通じて一元管理されるチームプラン、そしてエージェントをターミナルに持ち込むKiro CLIだ。

それ以降の軌跡は一貫していて、派手さがない。Kiro CLIは2026年4月にヘッドレスモードを獲得し、エージェントは人間の隣ではなくパイプラインの中で動くようになった。2026年1月のCLIリリースは、エージェントが取得してよいURLの許可リストとブロックリスト、カスタムエージェント用のキーボードショートカット、より良いdiff表示といった内容だった。これはデモを追いかけるロードマップではない。ツールが本番運用に合わせて調整されている姿であり、その調整のされ方が、人々が実際に何をしているのかを物語っている。

specは良いアイデアだった

Kiroの本当の貢献は、仕様をファイルにしたことだ。要件、設計、タスクがリポジトリの中にあり、バージョン管理され、レビュー可能で、diff可能になる。「AIがコードを書く」という触れ込みの隣に置くと小さなことに聞こえるが、私が留保なしに擁護できる唯一の部分でもある。

その理由は、これがレビューの場所を動かすからだ。統治されていないエージェント型コーディングは大きなdiffを生み出し、事後に人間へ評価を求める。これは最悪のタイミングだ。作業はすでに終わっており、著者は自らの推論を記憶していない機械であり、それを却下することは完成しているように見えるものを捨てることを意味する。specをレビューすることはこれを逆転させる。あなたが読んでいるのは意図であり、それを変えるコストが一文で済む時点だ。「いや、そうじゃない」の経済性は、実装の前と後ではまったく異なる。

この性質はAIとは何の関係もない。だからこそ生き残った。これはフィードバックループが短くなった設計レビューであり、実装者がエージェントであろうと契約社員であろうと来週の自分自身であろうと成り立つ。

持ちこたえなかったもの

正直な失敗が3つあり、実務で使った人には早い段階からすべて見えていた。

specはドリフトする

要件と設計は最初にまとめて生成され、実装が「設計は間違っていた」と明らかにしても自動では更新されない。チームが報告するのはまさに予想通りの力学だ。コードは動き、specは動かず、数週間もすればspecはもはや存在しないシステムを説明する文書になってしまう。これはAIの失敗ではなく、ソフトウェアドキュメントにおける最も古い失敗が、文書を書くコストを安くし、それを正しく保つコストは安くしなかったツールによって再び持ち込まれただけだ。書くのは安く、正しく保つのは高くつく。この組み合わせこそが、古びた成果物を生む特定の原因だ。

オーバーヘッドが小さな作業に見合わない

小さなバグ修正で試した人たちの率直な感想は、spec形式のワークフローはナットに対する大ハンマーだというものだ。バリデーションルールを変更するために要件、設計、タスク分割を用意するのは、単にバリデーションルールを変更するよりも悪い。儀式の量が何にも比例しておらず、そしてエンジニアリング作業の大半は小さい。

硬直性は本物だ

spec先行は、始める前に何が欲しいかを知っていることを前提にする。ソフトウェアの多くは、書きながら何が欲しいかを見つけていく人々によって書かれる。探索的な作業にとって、仕様を前倒しすることは規律ではなく、まだ得ていない権威を持つ文書へと形式化された推測にすぎない。spec駆動開発がウォーターフォールの力学を再輸入しているという批判は、完全に正しいわけではないが、完全に間違ってもいない。その差は、チームがspecを契約として扱うか草稿として扱うかにかかっている。

では誰のためのものか

浮かび上がったパターンは、触れ込みよりも狭く、より擁護しやすいものだ。要件が曖昧なとき、関わる人々が分散していて共有理解を前提にできないとき、あるいはトレーサビリティが好ましさではなく義務であるとき、specはそのオーバーヘッドに見合う価値を発揮する。規制対象の文脈では、「これがレビュー済みのspecで、これがそれを実装するdiffだ」というのはオーバーヘッドではない。どのみち構築せねばならなかった監査証跡が、副産物として生成されているにすぎない。

よく理解されたコードベースを持つ小さなチームにとっては、そのオーバーヘッドはほぼコストでしかない。これはKiroへの批判ではない。マーケティングが決して口にしなかったスコープの表明だ。

AI IDEが実際に変えたもの

ここからは私見であり、確信を持って主張しているわけではない。

変わったのはAIがコードを書くという点ではない。それはすでに起きており、実際に有用であり、それについて議論すること自体が退屈なほど当たり前になった。変わったのは、人間によるレビューの単位がdiffから意図へと上流に移動したことだ。Kiroのspecはその実装の一つにすぎない。AGENTS.mdやsteeringファイルも別の実装だ。パターンは同じだ。人間が制約を著し、意図をレビューし、エージェントが実装を生み出す。そして人間が議論を戦わせる成果物が、コードであることをやめる。

2つ目の変化は、IDEが正しい入れ物ではなかったと分かったことだ。Kiro自身のCLIとヘッドレスモードが、どんな批評家よりも雄弁にこの点を証明している。人間が各変更を着地のたびに読んでいないなら、エディタはもはやUIを必要としない何かのためのUIであり、エージェントはあなたの自動化の残りが暮らす場所に属する。IDEはオンランプであって、目的地ではなかった。

結論

GAから8か月、Kiroの持続的な貢献は、仕様をレビュー可能でバージョン管理されたファイルにしたことであり、それは人間の判断を最も安く適用できる地点へと移した。コストは現実的で具体的だ。specは生成するのが安く維持するのが安くないためにドリフトし、儀式は小さな作業や探索的な作業には合わない。曖昧さやトレーサビリティがオーバーヘッドを正当化する場面で使い、そうでない場面ではスキップする。そしてエージェント型IDEの最も有用な出力がCLIだったという事実は、業界がこの先どこへ向かっているかを教えてくれている。

次に読む

CIでエージェントを運用する側の話、ランナー、認証情報、被害範囲についてはercan.cloudのフィールドノートにある。ハブはercanermis.comだ。