2026.1.19

Kiro で行うちょっと進んだ AI 駆動開発(2)

はじめに

前回は、現在の AI 駆動開発を取り巻く状況と Kiro の紹介でした。

今回は Kiro の Spec モードについて紹介していきます。

Kiro Spec モードとは

Kiro の Spec Mode は直接的には Kiro で行うちょっと進んだ AI 駆動開発(1)で触れた「LLMの有限コンテキストウィンドウ」問題と、「長いやり取りをしていると、古いやり取りや前提事項を忘れてしまう」という問題への Kiro の回答です。

Kiro Spec Modeでは具体的には、やりたいことや、前提となる資料を与えてあげると、Kiroはそれを元に要求仕様(requirement)を作成します。開発者はこれをレビューし、修正、承認することで軌道修正を行います。

次に Kiro はその要求仕様を元に設計(design)を行います。要求仕様が、実現するべき機能の一覧に分けられます。開発者がこれを承認すると、最後に Kiro は設計を実現するためのタスク(tasks)を用意します。こうして、すべてを一度に作り込もうとするのではなく、小さなタスクに小分けすることで、短いコンテキストウィンドウの中でも十分にタスクをこなすことができます。

また、要件、設計、タスクの各項目には番号が振られていて、そこから一つ前の工程へのトレースバックが可能なように項目へのリンクが記載されます。ソフトウェア開発手法などをきっちり学んだ方であれば、機能、設計、要件の管理手法として推奨されているトレーサビリティマトリクスの手法が取り入れられていることがわかります。これらは、Kiroに対して何か1つ項目を修正を行ってほしい場合に、またゼロからすべての要求仕様を読み込んで、機能一覧を作成し直して、と、ならないように修正や考慮の範囲を限定すると、これまたLLMの有限なコンテキストウィンドウを上手に利用する方法になります。

このタスク分けは、AI駆動開発でなく、通常のシステム開発プロジェクトでも利用されている手法です。AI駆動開発を既存のシステム開発手法にうまく乗せることで、AIとの単なる会話ではなかなかできなかった複雑な開発や大きい開発が可能になります。

また、この副次的な効果としてプロジェクトとしてよくありがちな「動くプログラムはあるけど、ドキュメントが存在しないので全体を把握したり、一部を変更することによる影響の予測が困難」という問題の回答にもなります。要求、設計のドキュメントが残っている為、どの要求がどんな設計で実装されているのかがあとから見てもわかりやすいのです。

実際にやってみよう

Amazon S3 の設定を変更する小さなシェルスクリプトを作る例を元に実際にどんな感じなのか見てみましょう。

事前調査結果と下書きした要件から、ちゃんとした要件を作成

事前に、どうすれば実現できそうかを Kiro の Vibe モード(LLMに質問し、回答を得るモード) で、必要な情報を下調べしました。結果、S3バケットのライフサイクル設定中の項目の一つである “TransitionDefaultMinimumObjectSize” を “all_storage_classes_128K” とすれば良いという調査結果になりました。その際の会話を入力ファイルとして、PutBucketLifecycleConfiguration.ini に保存しておきました。やるべきことはわかったので、これをAWSアカウント全体に実行するようにするような要件とします。

# TransitionDefaultMinimumObjectSize を "all_storage_classes_128K" に設定する ShellScript ツールの作成

## 目的とやりたいこと

バケットのライフサイクル移行の際に、大量にある小さなファイルが移行されてしまい、元が取れなくなってしまうことを防ぐために、アカウントすべての S3 バケットを調査し、

 "TransitionDefaultMinimumObjectSize": "all_storage_classes_128K"

となっていないバケットについて、 "TransitionDefaultMinimumObjectSize": "all_storage_classes_128K"　を設定するプログラムを作りたいです。

## 事前調査

事前調査として、PutBucketLifecycleConfiguration.ini にある質問と回答を得ています。

## 作業環境

H:\workspaces\PutBucketLifecycleConfiguration フォルダを使ってください。

## 使用する言語について

できれば日本語でお願いします。

こんな感じでプロンプト（Kiro に対する指示) を用意します。

Kiro エディタのチャットパネルを新しく開くと、モードの選択が表示されるので、Specモード を選択して、プロンプトを投入します。

すると、 Kiro がこんな感じでむにゃむにゃ考えて、requirements.md を作成してくれます。

requirements.md を確認してみると、

概要説明(Introduction) 、複数の要件(Requirements)とそれに対応する受け入れ基準(Acceptance Criteria)が作成されています。

要件の中には、ユーザーストーリー(User Story)として、この要件は誰が、どのように使うためにあるのかという様ななぜこの要件が作られたかの理由に繋がる記述があります。この「なぜ」は後日このツールを改修しようとした人がいた場合にもとの開発意図を正しく理解するのに役立ちますね。

デフォルトでは、英語で作成されるので、日本語訳版をKiroにお願いして作ってもらいました。

おお、いいですね！　やりたいことを正しく理解してくれているようです。

間違っている部分や、追加の要件がある場合にはこの段階で Kiro に遠慮なく伝えて修正してもらいます。

要件を元に設計ドキュメントを作成

内容が問題なく、修正や追加要望がなければ、チャットパネルの「Move to design phase」ボタンを押します。

するとまたしても Kiro がむにゃむにゃ考えて、設計ドキュメント(design.md) を作ってくれます。

システムの構成図や、処理フローなども作ってくれます。

この図が地味に嬉しいですね。簡単な図があることで理解が格段に進みます。こんな単純な図でも作成するとなれば、数十分かかるでしょうし、何度も修正する羽目になる可能性があるとなると、「全部確定してからでいいや」と怠けてしまって結局理解がいまいち進まない… なんということもありますし。この図は作成された design.md を機能拡張の Markdown Preview Mermaid Support を利用してプレビュー表示しています。