見出し画像

/spec new が「で、何を作るの？」と先に聞いてくれるようになった

たつぼん

Kiro CLI 2.15.0 が 7月27日に出ました。

正直、最初にリリースノートを見たときは「地味だな」と思ったんです。目玉は2つだけ。/spec new に説明を入力するステップが増えたのと、Plan モードで承認したプランがそのまま実行されるようになった、それだけ。

でも、社内でExcel業務ツールをKiroで作ってきた立場で読み直すと、この2つはけっこう効くところに手が入っていました。特に1つ目は、この連載の #12「曖昧な要望をKiroで仕様書に変える」で書いた話の、まさに続きです。

今日はこの2つを、業務ツールを作る側の目線で整理しておきます。

変更点1：/spec new が「このspecで何をカバーするか」を先に聞く

これまで /spec new <name> を打つと、Kiro は spec名だけを手がかりに 要件定義を書き始めていました。

つまり /spec new invoice-import と打つと、「invoice-import」という文字列から「請求書のインポート機能なんだろうな」と推測して requirements.md を書き出す。当たることもあるけど、外すこともある。外したら要件定義を丸ごと直すことになります。

2.15.0 では、ここに一段挟まりました。公式ドキュメントの例だとこんな流れです。

> /spec new auth-middleware

Starting spec: "auth-middleware"

What should this spec cover? Describe it in a sentence or two.

> JWT-based auth middleware for Express routes with role-based access control

Spec agent activated. Let me analyze your request and produce requirements...

「このspecは何をカバーすべき？ 1〜2文で説明して」と聞かれる。そしてドキュメントには、エージェントはこの説明を spec名から推測する代わりに ground truth（拠り所）として使う と書かれています。

細かいところですが、このステップの挙動も明記されています。

  • 説明を入力して Enter で先へ進む

  • Esc でこの説明ステップだけキャンセル（Specモード自体は生きたまま）

  • スラッシュコマンドを打つと、それを実行しつつ説明ステップは armed のまま残る

「間違えて /spec new しちゃった、でもSpecモードは抜けたくない」ときに Esc が効く、というのは覚えておくと地味に助かるやつです。

あわせて、/spec new では spec の種類も聞かれます。

  • Build a Feature — 要件・設計・実装タスクをきっちり作る

  • Fix a Bug — 調査、原因分析、修正

  • Quick Spec — 要件の形式化を省いた軽量プラン

業務ツールだと、この3つ目の Quick Spec の存在がありがたい。「マスタの列を1本増やすだけ」みたいな作業に requirements.md から書かせるのは、正直しんどいので。

変更点2：Plan モードは承認したらそのまま走る

もう1つが Plan モードの自動実行です。

これまでは、プランを承認したあとに「実行モードに切り替えますか？ [y/n]」というやり取りが挟まっていました。2.15.0 からは、プランを承認した時点で実行が始まる。手動でモードを切り替える必要がなくなりました。

ここでひとつ注意点というか、確認しておいたほうがいい話があって。公式ドキュメントの Plan agent のページは、まだ更新前の記述のままです。「Ready to exit [plan] agent to start your implementation? [y/n]」という手動確認の手順が、troubleshooting の項目まで含めて残っています（ページ末尾の更新日は 2025年12月19日）。

Changelog とドキュメントで書いてあることが違うときは、日付の新しい Changelog 側が正、と読むのが素直だと思います。ただ、社内展開しているとこういうズレが一番やっかいで、「ドキュメント通りにならないんですけど」という問い合わせに変わって返ってきます。この手のギャップは、気づいた時点で社内のSteeringなり手順書なりに一行書き足しておくのが結局いちばん早い。

なお、Plan エージェント自体が read-only である点は変わっていません。ファイル書き込み、コマンド実行、MCPツールの利用は不可で、読む・調べる・検索するだけ。「プランを立てる間は何も壊さない」という設計は維持されたまま、承認後の受け渡しだけが滑らかになった、という理解でよさそうです。

業務ツールを作る側から見て、何が変わるか

この連載で繰り返し書いてきたのは、Kiroで業務ツールを作るときの詰まりどころは コードを書く工程ではなく、その手前の「何を作るか」を固める工程 にある、ということでした（#12、#13あたりです）。

現場から降ってくる要望は、だいたい「請求のアレ、なんとかならない？」みたいな粒度で来ます。それをそのままAIに渡しても、まともな仕様にはならない。だから人間が一度、日本語で噛み砕いてから渡す必要がある。

今回の /spec new の説明ステップは、その「一度噛み砕く」作業を ツール側が明示的に要求してくる ようになった、という変化だと受け取っています。今までは自主的にやるしかなかったことに、レールが敷かれた。

社内展開の観点でも意味があります。50人に配ったとき、spec駆動のやり方を全員が同じ粒度でできるわけがない。人によっては spec名だけ打ってEnterを連打します。そこに「1〜2文で説明して」というプロンプトが必ず出るなら、少なくとも一度は立ち止まる。ツールの側で下限を引き上げてくれるのは、展開する側としてはありがたい話です。

一方で /spec run <name> は、tasks.md の存在を確認したうえで 全タスクを無人で実行する コマンドです（途中で中断はできます）。入口が親切になった分、出口が自動で走る設計になっているので、ここは以前書いた Permissions の話とセットで考えるべきところだと思っています。何を許可して何を許可しないかを先に決めておかないと、「よく分からないまま全部走った」が起きやすくなる。

使えるようになるまでの条件

いくつか前提があります。

  • どちらも CLI 3.0（v3）向けの機能 です。kiro-cli --v3 で明示的に v3 モードに入る必要があります

  • CLI 3.0 は現時点で early access。既存の 2.x 環境と共存する形なので、いきなり全部が変わるわけではありません

  • spec は .kiro/specs/<name>/ に requirements.md / design.md / tasks.md として保存されます。ここは従来通り

  • そして .kiro/specs/ は IDE と CLI で共有 されます。CLIで書き始めた spec を IDE で続けられる、というのは公式に明記されています。フォーマットも同一

最後の「CLIとIDEでspecが共通」は、社内でIDE派とCLI派が分かれているところだと効きます。うちも人によって環境がバラバラなので、ここが揃っているかどうかは地味に大きい。

まとめ

  • /spec new <name> に「このspecで何を作るか」を1〜2文で書くステップが追加された。エージェントはこれを推測ではなく拠り所として使う

  • Esc で説明ステップだけキャンセルできる。Specモードは生き残る

  • spec の種類は Build a Feature / Fix a Bug / Quick Spec の3つ

  • Plan モードは承認したらそのまま実行へ。ただし公式ドキュメントの Plan agent ページは旧記述のまま残っているので注意

  • どちらも CLI 3.0（v3）の機能。kiro-cli --v3 が必要

  • 入口が親切になった分、/spec run の無人実行は権限設計とセットで考えたい

私の環境はまだ 2.x 中心なので、v3 への移行と実際の挙動は、これから社内で試して別途書きます。特に Quick Spec が実務でどのくらい使えるかは気になっているところです。

〆

新機能が出ると「これでもう人間がやることないですね」みたいな読み方をしたくなるんですが、今回のアップデートはむしろ逆でした。「何を作るのか、あなたの言葉で1〜2文書いてください」と、ツールの側から人間に投げ返してくる変更です。

この連載でずっと言ってきた「AIに全部やらせない」は、サボりたくないという精神論ではなくて、人間が決めるべきところを決めないとAIが機能しない という実務上の事実の話でした。Kiro自身がそういう作りに寄ってきているのは、方向として素直に納得できます。

それでは、また次の記事で。

いいなと思ったら応援しよう！