Kiroが見せるSpec駆動開発の可能性と課題

7月末にAWS認定 Solution Architect Professional（SAP）の再認定を合格してからというものの、若干燃え尽きておりました。勉強大変でした ... 。ここ最近、Amazon Q Developer CLIやKiroを活用して、個人で作ったサーバレスアプリケーションのコード修正を行っていました。

そこで感じたKiroにおけるSpec駆動開発体験の魅力や、現状のKiroにおける課題感などをこの場でご共有します。

生成AIが出力する文字数調査が、KiroによるSpec駆動開発のきっかけでした
Kiroはまだまだ発展途上
とにかくKiroはかわいい
まとめ

生成AIが出力する文字数調査が、KiroによるSpec駆動開発のきっかけでした

私がKiroによるSpec駆動開発を行う際の題材にしたのが、生成AIが出力する文字数の調査です。私が実装したアプリケーションは生成AIに「1500文字以内で出力して！」を念を押しているにもかかわらず、生成AIはそのルールを守ってくれません。文字数を超過するとSlackとの連携でエラーが出るため、文字数制限は守らないといけません。

そこで、Kiroにお願いするわけです。

要件定義フェーズの重厚長大感よ

Kiroにお願いして作成してくれた要件定義書はこちらです。SlackにPostする際の3,000文字制限を守るために、出力文字数のログ出力とPrefillを利用する要件定義書を作成してもらいました。

# 要件定義書

## 概要

このアプリケーションは現在、SlackにメッセージをPostする際に以下のエラーが発生しています：
- `invalid_blocks`: Slackブロックのスキーマ検証エラー
- `must be less than 3001 characters`: テキストが3000文字制限を超過

プロンプトで1500文字制限を指定しているにも関わらずこのエラーが発生するため、まず現状を正確に把握し、その後適切な対策を実装する必要があります。

この要件定義書なのですが、Vibeリクエストを経てKiroに依頼した結果、最終的に要件が8つもできました。簡潔に、出力された要件を下表で紹介します。

要件No.	要件内容
1	開発者として、LLMが生成する要約の実際の文字数を把握したい。そうすることで、プロンプトの文字制限指示が守られているかを確認できる。
2	開発者として、最終的なSlackブロック内のテキストの文字数を把握したい。そうすることで、3000文字制限超過の直接的な原因を特定できる。
3	開発者として、文字数カウント方法の違いを把握したい。そうすることで、LLMとシステム間の文字数認識の差を特定できる。
4	開発者として、エラー発生時の詳細情報を取得したい。そうすることで、Slack APIエラーの具体的な原因を特定できる。
5	ユーザーとして、LLMが生成する要約が確実に2000文字以内になることを期待する。そうすることで、Slack APIエラーを根本的に防止しつつ、より詳細な要約を得ることができる。
6	開発者として、○○モードでも文字数制限が守られることを確認したい。そうすることで、すべてのモードで一貫した動作を保証できる。
7	ユーザーとして、システムプロンプトでも文字数制限が守られない場合に、確実に2000文字以内の要約を得たい。そうすることで、どのような状況でもSlack APIエラーを防止できる。
8	開発者として、Prefill機能を使用してLLMの応答をより確実に制御したい。そうすることで、文字数制限の遵守率をさらに向上させることができる。

KiroちゃんはNo. 7 の2000文字以内への再要約や、No.8 のPrefil機能を提案してくれませんでした。ですので、私からVibeリクエストで依頼しました。 Kiroちゃんは律儀にちゃんと要件定義書を作ってくれるのですが、重厚長大な要件定義書を作る傾向にあるのではないかと。 特に次に紹介するタスク一覧が注目に値します。

Kiroが作るタスクリストがこれまたすごい

次にタスク一覧です。要件定義の次は設計ドキュメントなのですが、設計ドキュメントは今回は記載されることがわかりやすい題材なので、Kiroが作ったタスク一覧をご紹介します。これがまたすごい。

タスクNo.	タスク名	私の所感 ( ´ー`)。о
1	文字カウント関数の実装	「OK」
2	LLM応答の文字数ログ出力機能の実装	「いいね」
3	Slackブロック要素の文字数内訳ログ機能の実装	「よさそう」
4	言語別文字数計算の実装	「ここまで必要か？」
5	特殊文字・エスケープ文字の影響調査機能の実装	「これいります？」
6	Slack APIエラー詳細ログ機能の実装	「わかる」
7	現状把握のためのテストケース作成	「テストも実装してくるんだ。ありがとう。」
8	システムプロンプト関数の実装	「はい」
9	Claude Bedrock API呼び出しの更新	「そうだよね」
10	Claude用文字数調整システムプロンプト関数の実装	「うん」
11	Claude用文字数調整処理の実装	「いいよいいよ」
12	Claude用統合要約生成フローの実装	「もっともっと」
12.1	Claude用Prefill機能の実装	「おねがい！」
12.2	Prefill効果測定機能の実装	うーん、なにこれ？効果測定すんの？
13	Claude用三段階制御アプローチの検証テスト	「ほーん、へー？んー？なんぞれこれ？」
14	Nova Bedrock API呼び出しの更新	「よろしく」
15	Nova用文字数調整機能の実装	「そうだよね」
16	SQSハンドラーの統合更新（後回し）	「お、おぅ...」
17	○○モードのシステムプロンプト統合	「ありがとうありがとう」
18	システムプロンプト効果の検証テスト	「他のテストと何が違うんだ？？」

う、うん、すごいねー ... このタスクリスト全部読むの大変ですね！？ Kiroちゃん ... ちゃんとステアリングドキュメントを整備しないと重厚長大なタスク作ってしまうのかな ... ちなみに、このタスクすべてを実装する前に無料利用枠を全部使ってしまって、タスク全部終わってませーん！オワタ＼(^o^)／

実際にKiroにコーディングしてもらってデプロイした結果

いくつかのVibeリクエストを経てコードの修正を施してはおりますが、ちゃんとデプロイして動作するものが作れています。もちろんログ出力機能も実装されており、出力内容自体は ... すばらしいです。まずはLLMレスポンスの文字数カウントです。素晴らしい ... 全角や半角なども出力されています。

次に日本語における文字種別の分析です。ひらがな、カタカナ、漢字などが分析できています。Kiroやりおる ... しかしいるのかなこれ ...

記号なども出力できています ... すごいのは分かるがここまでいるのか ...

エンコーディングの影響も出力されています。うーん、ほんと出力は素晴らしいのは分かるけど ... いるのかこのログ

Kiroはまだまだ発展途上

Spec駆動開発を体験してみた感想としてはまず第一に、Specドキュメントが設計における成果物になりえます。また、Specドキュメントは生成AIで利用するコンテキストでもあります。この証跡のようなドキュメントが残ることは、チーム開発に向いていると思います。SpecドキュメントをPRレビューのタイミングなどで参照することで、エンジニアがKiroにどのような設計方針を与えていたのかを確認できるのです。

しかしながら、Kiro自身はまだ発展途上であると思います。リリースしたばかりなのでそれはそうなのですが、理由を以下に記載します。

課題 1：Specの見直し工程に多くのVibeリクエストを消費する

Specドキュメントが正であると考えると、できるだけSpecドキュメントを精緻化することが望ましいと思います。このSpecドキュメントを精緻化するためにKiroへのリクエストが多く消費します。実際に1つのSpecドキュメントを精緻化するためにVibeリクエストを10回から20回程実行することがありました。9/15（月）にクレジット消費に変更されるアナウンスがありましたが、Vibeリクエストによるクレジット消費は変わらず多く発生するのではないかなと思います。

kiro.dev

Specを精緻化するだけでもかなりのVibeリクエストを消費することから、Proプランで完遂できるSpec駆動開発はせいぜい1~3Spec程度なのではないかと思いました。（実際に利用したところ、ボーナス含めた当初の無料枠であるVibeの150リクエスト数では1つのSpecの完遂すらできませんでした。また、これだけリクエスト（クレジット）消費量が多いと、Hook機能を試すのもためらいがちになります。HookでもVibeリクエストを消費するとマニュアルに記載があったためです。

課題2：Specの内容を精緻化するノウハウがエンジニアに必要

ここまでの私のSpec駆動開発の実践内容をご覧頂いたのならお分かり頂けたかなと思いますが、Kiro自身にSpecの内容を精緻化してもらうのは一苦労です。かなり重厚長大なプランを練ってくれるので、「いや、そこはもう少し簡単でいいんだよ ...」というような相談をKiroとしたほうがいいです。あまりに重厚長大な要件定義書や設計ドキュメント、そしてタスクリストが出来上がると読む側も一苦労です。

課題3：KiroがTerminalの結果を読み取れない

これは致命的でした ... KiroがTerminalで実行した結果を受け取れない状況でずっとハングアップしているのです。なんとか直そうとKiro自信に問い詰めましたが、現時点では改善されません。以下の画像をご覧ください ... 「申し訳ありません！コマンドの出力が見えないため、状況を把握するのに苦労していました。」と言っているんですよ ... Kiroちゃん、それはないでしょ ...

なぜコマンド出力が見えないのですか？とKiroちゃんに問い詰めたところ、開き直りました ...

なんか「understood」って言った後まったく応答を返してくれなかったので文句も言いました。Kiroちゃんに。

TTYは機能しているんだけど ... なんでだろう ... Kiroちゃん勘弁してぇ

最終的に折れる私。AIエージェントに「中断してください」なんて言いたくないですよ。

課題4：MCPサーバーに接続できない問題解消！

私の環境特有の現象なのかもしれませんが、~~AWS API MCP Serverに接続できなくて困っています。~~Kiroちゃんをより賢くしたいのに ...

（2025年9月22日）MCPサーバーに接続できました！どうやら、接続に時間がかかっているらしく、タイムアウト設定を変更したら繋がりました！

設定例は以下の通りです。

{
  "mcpServers": {
    "aws-api-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-api-mcp-server@latest"],
      "timeout": 180000,  // 180秒に設定
      "env": {
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

とにかくKiroはかわいい

いろいろと言わせて頂いていますが、Kiroはかわいい。これだけは間違いないです。他のAIコーディングIDEと異なりキャラクターがいます。おばけのような見た目で、想像力をかきたてられますね。走っている姿もかわいい。

まとめ

KiroによるSpec駆動開発は、AIエージェントを活用した開発体験の未来であることには変わりないと思うのですが、AIエージェントを使いこなすドライバーの知識力や提案力が試される感覚もありました。なんといいますが、どちらかというとSpec駆動開発は優秀なエンジニアがアシスタントを付けるような印象で新人エンジニアにこれを使いこなせるのかなぁとは思いました。

Amazon Q Developerのようにルールファイルを作成して、Kiroちゃんの行動を抑制するためのルールを定義できないのかなぁと妄想が膨らみます。また、カスタムエージェント（利用するMCPサーバのプロファイル）ができるようになって欲しい。

私はAmazon Q DeveloperとKiroの2本立てでこれからも使い続けると思います。Kiroの進化に期待したいですね。以上です。