バイブコーディングからの卒業：Kiro による仕様駆動開発

Kiro の概要

Kiro は VS Code をベースにフォークされているため、Visual Studio Code（VS Code）とよく似ています。Amazon はこれを基盤として機能を追加しました。エージェント型コーディング機能で大規模言語モデル（LLM）を利用するため、サブスクリプション形式のサービスとなっています。

Spec モードと仕様駆動開発

• Spec モード：Spec モード（仕様駆動開発）と呼ばれる Kiro 独自の機能です。
• 従来のバイブコーディング：多くの開発者は、コーディングエージェントにプロンプトを与え、コーディングやデバッグを支援させるバイブコーディングに慣れています。
• 仕様駆動開発：要件、設計、タスク計画、最後にコーディングという順序でソフトウェアを構築する別のアプローチです。実際のコーディングを始める前に、要件と設計を構造化します。

エージェントステアリング機能

• エージェントステアリング：ソフトウェアの記述方法について、開発者がコーディングアシスタントを誘導できる機能です。
• 製品概要の Markdown ファイル：開発者は、製品概要、ワークフロー、ユースケースなどを記述した Markdown ファイルを提供できます。これにより、要件と設計を製品概要に沿ったものにできます。
• プロジェクト構造の定義：コーディング開始前に、Markdown ファイルでプロジェクト構造を定義できます。これには、エンタープライズ標準や、プロジェクトファイルとテストファイルの具体的な構成方法も含まれます。
• 命名規則：Markdown ファイルで命名規則を指定し、作成されるファイルが正しい規則に従うようにできます。

技術スタックの定義

• 技術スタックの定義：エージェントステアリングの 3 つ目の例は、プロジェクトの技術スタックを定義することです。
• フロントエンド：React などのフレームワークを指定します。
• バックエンド：バックエンド用のフレームワークや技術を指定します。
• 依存関係：Markdown ファイルでプロジェクトの依存関係を定義します。

コーディング規約

• コーディング規約：組織のコーディング規約を事前に定義し、コーディングアシスタントが規約に従うようにします。

agents README のサポート

• agents README のサポート：Kiro の最新リリースでは、エージェント向け Markdown ファイルのオープン標準である `agents.readme` がサポートされました。
• 相互運用性：Kiro でエージェント用 README ファイルを定義し、Cursor など他のコーディングアシスタントでも利用することで、エージェント向け Markdown 標準に準拠できます。

エージェントフック

• エージェントフック：Webhook と同様に、ファイルの保存や更新など、特定のイベントが発生したときにワークフローを起動します。
• セキュリティ標準：
• 例：コードにハードコードされた認証情報やセキュリティ脆弱性が含まれないよう、セキュリティ標準を定義します。
• 保存時のセキュリティスキャン：セキュリティレビュー用のエージェントフックを定義し、API キー、秘密鍵、IP アドレスなどをスキャンして自動的に修正します。
• デモ：
• 既存コード：IP アドレスがハードコードされた簡単な例です。
• エージェントフックの作成：ファイル保存時にセキュリティスキャンを実行するエージェントフックを定義します。
• 結果：セキュリティスキャンはハードコードされた IP アドレスを高リスクと判定し、環境変数を使用するよう修正します。環境変数がない場合は localhost をデフォルト値にします。
• シフトレフトセキュリティ：CI/CD の段階ではなく、ファイル保存時にセキュリティスキャンを実行することで、開発プロセスの早い段階にセキュリティチェックを移します。

エージェントフックのその他の用途

• Figma デザインとの比較：
• 連携：ファイル保存時に、実装した要素と Figma の UX デザインを比較するエージェントフックを使用します。
• Figma 向け MCP：Figma 向け MCP と連携し、コードが定義済みデザインに沿っていることを確認します。
• 例：Figma デザインを Angular で実装するようシステムに指示し、Figma デザインから直接コードを生成します。

MCP サーバー連携（Figma からコードへ）

• 例：Figma 向け MCP と連携し、Figma デザインから Angular コードを生成するようシステムに指示します。
• 結果：システムは Figma デザインから直接コードを生成し、そのデザインに基づくサイトを作成します。

MCP サーバー連携（最新ドキュメント）

• 連携：MCP サーバーを使用し、AWS ドキュメントやナレッジベースなどの最新ドキュメントを参照します。
• 例：AWS ドキュメントと連携し、ローカルで記述したコードを AWS Lambda で実行できるかシステムに確認させます。
• 結果：システムは Lambda にデプロイした際のコードの問題を特定するだけでなく、ファイル転送に S3 署名付き URL を使用するなどの変更を提案する移行計画も作成します。

Kiro における仕様駆動開発

• 仕様駆動開発：アジャイル開発の誕生以来、最も優れた進歩であると強調されています。
• アジャイルの課題：要件の変化や、プロジェクトマネージャー、ビジネスアナリスト、ユーザー間の意思疎通の行き違いにより、ユーザーが指定したものと実際に構築されるものが異なることがよくあります。
• 適応型アプローチ：Kiro の仕様駆動開発は、開発プロセス全体を通じて動的に適応することで、こうした課題を受け入れます。

実際のユースケースによるデモ

• ユーザー要件：500 MB のファイルを 100 MB ずつ 5 つに分割する、ファイル分割用アプリケーションの構築を希望しました。
• [ 1 ] 暗黙の要件：
• グラフィカルユーザーインターフェイス（GUI）
• ファイル入力用のドラッグ＆ドロップ機能
• 分割方法の設定オプション（5 分割、10 MB ごとの分割など）
• 個別ファイル、および分割した全ファイルをまとめた ZIP ファイルのダウンロード機能
• [ 2 ] 開発時間：
• 従来の見積もり：2 週間
• Kiro による開発：6 時間（10 分に早送りした動画で実演）
• [ 3 ] 動画によるデモ：
• 左上にリアルタイムのタイマーを表示し、Kiro を使用した 6 時間の開発プロセスを 10 分間にまとめた動画です。

初期要件と設計

• ユーザー入力：プロダクトオーナーが、大きなファイルを小さなチャンクに分割するアプリケーションの初期要件を入力します。
• Kiro の応答：Kiro は 1 分以内に、受け入れ基準を伴う 7 つのユーザー要件を生成します。
• ユーザーのフィードバック：プロダクトオーナーが要件をレビューして承認します。

設計の調整

• 初期設計：Kiro はコマンドラインインターフェイス（CLI）を想定して初期設計を作成します。
• ユーザーによる修正：プロダクトオーナーは、CLI ではなくグラフィカルユーザーインターフェイス（GUI）を求めます。
• リアルタイム更新：Kiro はリアルタイムで設計を調整し、GUI とバックエンド API を追加します。

反復的な設計プロセス

• To-Do ファイル：追加の質問や要件が発生するたびに、To-Do ファイルで追跡します。
• [ 1 ] プロダクトオーナーが、フロントエンドからバックエンドへファイルを送信する仕組みについて質問します。
• 設計の更新：アップロードの仕組みを文書化するよう設計を更新します。
• [ 2 ] 新しい要件：プロダクトオーナーが、最大 1 TB のファイルをサポートする要件を追加します。
• 設計の更新：1 TB のファイルを処理できるよう設計を更新します。
• [ 3 ] プロダクトオーナーが、分割前にバックエンドでファイルサイズを把握する方法について質問します。
• 設計の更新：この質問に答えられるよう、設計に詳細を追加します。

タスク計画

• タスク計画の作成：要件と設計が確定した後、プロジェクトを個別のタスク（タスク 1～10）に分解したタスク計画を作成します。
• 所要時間：初期要件からタスク計画までの全プロセスは 20 分未満で完了します。

タスク計画とコーディング

• タスクのトレーサビリティ：各タスクから要件を追跡できるため、要件、設計、タスク計画に至るエンドツーエンドのトレーサビリティが確保されます。
• 単体テスト：Kiro はコーディングと並行して単体テストを生成します。すべての単体テストに合格するまで、タスクは完了と見なされません。
• デバッグ：Kiro は単体テストの失敗を自動的にデバッグして修正します。
• エラー処理と最適化：Kiro はタスクの一部として、エラー処理、検証、パフォーマンス最適化に対応します。

テストとバグ修正

• 初回テスト：アプリケーションを初めてテストすると、青い文字が読みにくいなどの UX の問題が見つかります。
• バグの特定：ファイルのアップロード中にエラーが発生し、ログメッセージから特定されます。
• エージェント支援によるデバッグ：エラーコードをエージェントにコピー＆ペーストし、バグの修正を試みます。
• アップロードの成功：バグが修正され、大きなファイルのアップロードに成功します。
• 分割とダウンロード：アプリケーションはファイルを正常に分割し、個別のチャンクと ZIP ファイルをダウンロードできるようにします。

UX の改善

• 色の変更：読みやすさを向上させるため、青い文字をシアンに変更します。
• ボタンの外観：ボタンのグレーを、より適切な色に変更します。
• 大容量ファイルのアップロード：大きなファイルを処理できることを確認するため、2 GB のファイルでアプリケーションをテストします。

テストの自動化

• 手動テスト：当初は、複数ファイルの分割や UX の問題確認などを手動でテストしていました。
• 自動化：Kiro は Mermaid 図を使用して設計とドキュメントを作成し、Playwright でテストを自動化します。
• クロスブラウザテスト：Firefox、Chrome、Safari、モバイル端末で自動テストを実行します。
• エンドツーエンドのフロー：要件からソフトウェア構築、自動化された実環境での検証まで、IDE 内で完結するエンドツーエンドのフローを示します。

まとめ

• このプロセスは、要件と設計からコーディング、単体テスト、UX の改善まで、Kiro が仕様駆動開発に対応し、従来の手法よりも大幅に短い期間で完了できることを示しています。

まとめとアジャイル開発の未来

• アジャイルチームの規模：経験豊富なエンジニア 1 名と、ドメインまたは業務の専門家 1 名が IDE で共同作業します。
• 所要時間の比較：アジャイルチーム全体では 2 週間と見積もられた要件定義から自動テストまでの全プロセスが、6 時間で完了しました。
• 仕様駆動開発：このセッションでは、Kiro による仕様駆動開発で実現できることの一端を紹介しました。