【前編】Kiro使ってみた
Kiroについて
2025年7月14日に公開された「Kiro」、Amazon Q DeveloperやGemini-CLI、Claude Codeのようにプロンプトからコード作成をしてくれますが、このKiroは、プロンプトから要件定義書/設計書/データフロー図 etc...などのプログラム開発に必要な文書に起こし、それらを基にコーディングしてくれるという新しいAI IDEのようです。
人気過ぎてしばらくダウンロードできなかったのですが、WaitListの順番がやっと回ってきたようなので、試しに使ってみたいと思います。
https://aws.amazon.com/jp/blogs/news/introducing-kiro/ インストールについてはインストーラに従うだけなので、割愛します。利用には、以下のアカウントでサインインを行う必要があります。
- Googleアカウント
- GitHubアカウント
- AWS Builder ID
- AWS IAM Identity Center
起動すると、VSCodeのような画面が表示されます。
アイコンのオバケがかわいいですね。
1.フォルダを開き、プロジェクトを開始する。
左上のフォルダのボタンをクリックし、「フォルダーを開く」から、プロジェクトとして利用するフォルダを選択します。
すると画面の右側にもサイドバーが出てきて、チャットを入力できるようになります。
ここからSpecというものを作成し、開発を行ってくれるらしいです。
2.【要件定義】作ってほしいものをお願いしてみる。
今作業している横にUbuntuをいれた古いノートPCがあるので、ssh接続してリソース状況を取得し、モニタリングする仕組みを作ってもらいます。
以下のプロンプトを実行してみます。
このPCから、LinuxPCにsshで接続し、リソース状況を取得し、モニタリングする仕組みを作ってほしいです。
応答が返ってきました。
WindowsPCからLinuxPCにSSH接続してリソース状況を監視する仕組みですね。これは新しい機能なので、新しいspecを作成しましょう。
まず、この機能の要件を整理して要件書を作成します。
Created
requirements.md
SSH接続によるLinuxサーバーリソース監視システムの要件書を作成しました。この要件書では以下の主要機能を定義しています：
CPU、メモリ、ディスク使用率の監視
複数サーバーの同時監視
自動更新機能
SSH接続設定の管理
履歴データの記録と表示
閾値を超えた場合の警告機能
要件書の内容は適切でしょうか？もしよろしければ、次に設計書の作成に進みます。
requirements.mdを開くとチャットで返ってきた内容よりもだいぶ詳細に記載されていることが確認できました。
User Storyとそれを解決するための機能が記載されています。
画面右下のMove to design phaseをクリックすると次の段階に進みます。
3.【設計】利用する言語や、画面の構成
まず、この機能を実装するために必要な技術調査を行います：
Searched workspace
Node.jsでSSH接続を行うライブラリを調査
技術調査に基づいて、以下の技術スタックを使用することを決定しました：
SSH接続: ssh2 ライブラリ（Node.js用の成熟したSSHクライアント）
UI: Electron または Web ベースのダッシュボード
データ保存: SQLite（軽量で設定不要）
グラフ表示: Chart.js
設定管理: JSON設定ファイル
Created
design.md
SSH Resource Monitorの設計書を作成しました。この設計では以下の主要な特徴があります：
アーキテクチャ:
Node.js + Express サーバー
WebベースのダッシュボードUI
SQLiteによるデータ永続化
WebSocketによるリアルタイム通信
主要コンポーネント:
SSH Manager: 複数サーバーへの接続管理
Resource Collector: Linuxコマンドによるリソース情報取得
Data Storage: 履歴データの保存と管理
Alert Manager: 閾値監視とアラート機能
Web API: フロントエンドとの通信
セキュリティ対策:
認証情報の暗号化保存
SSH接続のセキュリティ確保
Web APIの適切な保護
設計書の内容は適切でしょうか？もしよろしければ、次に実装タスクリストの作成に進みます。
技術スタックの選定もしてくれました。
design.mdには、ssh接続のためのリモートコマンドや、SQLiteのテーブル定義、エラー処理方法、テスト内容、セキュリティ項目が記載されていました。
では、次に進めてみましょう。
4.【タスクリスト】作業の洗い出し
デザインフェーズまでで決定した項目を実現するためのタスクをリストで作成してくれました。
設計が承認されましたので、実装タスクリストを作成します。
Created
tasks.md
SSH Resource Monitorの実装タスクリストを作成しました。このタスクリストは以下の段階的なアプローチで構成されています：
段階1-3: 基盤構築
プロジェクト初期化とTypeScript設定
データモデルとインターフェース定義
SSH接続管理システム
段階4-6: コア機能実装
リソース情報収集（CPU、メモリ、ディスク）
データ永続化システム
アラートシステム
段階7-9: サーバー機能
自動更新システム
Web API サーバー
WebSocketリアルタイム通信
段階10-12: UI と設定
Webダッシュボード
設定管理システム
エラーハンドリングとロギング
段階13-14: 品質保証と完成
テストスイート
統合とデプロイメント準備
各タスクは具体的な実装内容と対応する要件を明記しており、段階的に機能を構築できるよう設計されています。
タスクリストの内容は適切でしょうか？
何をすべきかが簡潔に記載されています。
画面右下のFinelize task listを押して進めてみましょう。
完璧です！SSH Resource Monitorの仕様書作成が完了しました。
作成された仕様書：
要件書 (requirements.md): 7つの主要要件とそれぞれの受け入れ基準
設計書 (design.md): アーキテクチャ、コンポーネント設計、データモデル、セキュリティ考慮事項
タスクリスト (tasks.md): 14の主要タスクと詳細なサブタスク
これで仕様書の作成フェーズは完了です。実装を開始するには、tasks.mdファイルを開いて、各タスクの横にある「Start task」ボタンをクリックして個別のタスクを実行できます。
最初のタスク「プロジェクト基盤とコア構造の設定」から始めることをお勧めします。
マークダウンテキスト内にStart Taskボタンが用意されています。
これ、順番バラバラに実行できるんでしょうか。
一旦おすすめされている通り最初から進めてみましょう。
Start Taskボタンを押すと、右のチャット欄にタスク内容が入力され、作業が開始されました。
ソフトウェアやライブラリが必要な場面では、ユーザーが応答する必要があるようです。
途中、エラーを出しつつ何度かビルドに挑んでくれているときに気づきましたが、発行するコマンドについて、Reject/Trust/Runを選択可能でした。
このあたりは、Amazon Q Developer同様に信頼し、次同じコマンドを自動で実行できるようにするか、都度ユーザーが確認したうえで実行するか選べるようになっていますね。
Taskの1つ目が終わったようです。
タスク 1 が完了しました!
最初のタスク「プロジェクト基盤とコア構造の設定」を無事に実装することができました。達成したことは以下の通りです。
✅ 完了したサブタスク：
Node.js プロジェクトの初期化と package.json の作成
必要な依存関係をすべて含む包括的な package.json の作成
SSH、データベース、ウェブサーバー、テストライブラリの追加
開発環境と本番環境向けの適切なスクリプトの設定
TypeScript の設定とビルド環境
～～中略～～
✅ 検証:
✅ 依存関係が正常にインストールされました
✅ TypeScriptのコンパイルがエラーなく実行されました
✅ テスト環境が正常に動作しました
✅ プロジェクト構造が適切に構成されています
✅ すべてのプレースホルダファイルは有効なTypeScriptモジュールです
これで、実装計画の次のタスクを実行するためのプロジェクト基盤が整いました。この構造は設計書の要件に準拠しており、SSHリソース監視システムを構築するための強固な基盤となります。
その後も、以下の流れでそれぞれのタスクを実装してもらおうとしましたが、半日ほどで7割弱が完成し、利用上限に達してしまいました。
続きは明日やってみます。
（各項目を実装し、ユニットテストを実施を繰り返していましたが、テストで結構時間が掛かっていました。）
npmでサーバーを起動し、ブラウザからローカルホストに接続すると、以下のように画面が表示されました。
Comments