AWS CloudWatachLogsの分析アプリをVibeしました
今回は、AIエディタでログ分析アプリを作ってみた感想回です。
AWSのKiroが9/15に料金体系が変わるということで、無料枠を使い切る&Spec開発を一から試してみようと思い立って作業の合間に進めました
失礼しました。9/15から再課金されているだけでした。
…
いや、要件定義〜タスク作成までがっつり時間取りましたがw
そこはお勉強ということで。

はい、ということで、もりりんです。
社内で運用しているチャットアプリのログ調査が面倒だなーと思っていたところ、AIでつくればいいやん、ブログネタにもなるやん、いいやん!!という不純な動機から始まりました。
開発途中の勢いで書いているので、読みづらいところはご了承ください。
AWS Kiroとは?
AWSが提供しているAI-IDEです。

Kiroの特徴としては、仕様書駆動開発(Spec-Driven)ですね。
今までの開発と同様に要件、仕様、タスクの定義に力を入れましょうということで、準備〜開発工程の導線が整ったエディタです。
もちろん、定義が出揃ったあとは、それに応じて進められるAIエージェントも備えています。
個人的にはUIが直感的で分かりやすくてよかったです。
デフォルトでショートカットを提示してくれるのもGoodです。
ロゴのおばけアイコンも可愛くていい。
こんなロゴをパッと思いつけるようになりたいです…

Kiroで良いところは、タスクをステップごとに選択できるところです。
しかも、サブタスクや途中経過の更新もされ、最終的な確定で親ステップが更新される!
他のIDEやCLI系のAIツールでは同じようにするために、プロンプト/エージェント/ルール等の事前定義をしっかりしないといけないところが、エディタ標準で備わっているのは大きいです。
この機能はマジ神✨✨✨✨✨✨

その反面、他AIエディタに慣れていると、チャットの入力(特にファイル選択のアノテーション)がまだまだ弱いと感じます。
あとは、LLMがClaude 3.7/4 Sonnetしか利用できないことでしょうか。
リリースされて2ヶ月足らずのため、機能アップを気長に待ちましょう。
気になる料金体系ですが、現時点では画像の通りです。

なお、今回は無料枠での利用です。
要件定義〜タスク作成
Kiroは、仕様書駆動(Spec-Driven)ということで、まずは要件定義→デザイン・方針設計→作業タスクの定義を実施します。
ただKiroで利用できるLLMがコスパモデルに当たるため、最初の壁打ちは良いLLMを利用しましょう。
ということで、CursorのGPT-5-Highにお願いしました。(1クレジット消費はありがたい)
弊社では、少人数ですが7月からCursorをチーム契約で運用を開始しました。
新規メンバーには早く慣れて、業務での開発や個人妄想を実現するような使い方をゴリゴリして欲しいですね。
思いつくままに要望を入力し、めっちゃ考えて頑張ってと、まずは提案してと依頼し、モミモミしましょう。
ちなみに僕が入力したものは以下です。
- ローカルで動くログ分析アプリをつくりたい
- データ分析だし、Pythonにしようか
- ライブラリは自由に提案して
- できるだけ、軽く早く動かしたい
- 配布もしたいな
- ログの何を分析したいのかは考えてないから良い案あったら提案して
ログ分析するっていってるのに、どんな風に分析したいのかすら謎という行き当たりばったり感が満載ですねw
でも進めるのです。行けるところまで行ってみましょう。
ということで、叩き台の作文を作ったら、Kiro向けに要件定義をしましょう。
適当に命名したのでaaa.mdという要求ファイルです。

っておい、英語かよ!!ってことで、この後日本語に直してもらい、チャットで叩きまくって、迷走して、叩いてを繰り返して完成しました。
できあがった要件定義書の抜粋はこちら

残りのデザイン、タスクを同じようにしましょう。
迷走した上、あれ?要件足りないやん!と手戻りを繰り返しました。
そして、完成したものが一部抜粋はこちら。


※実行後にキャプチャしたので、チェック済
作成したファイルは以下でした。
- 要件定義 :214行
- デザイン設計:757行
- 作業タスク :284行(19ステップ)
Vibe & Codingの道のり
ここまできたら、KiroにVibe&Codingさせたら、完成や!!
って思っていました。
しかし、ステップ1からつまずくとは…
そう原因は!dev…container…
何を隠そう、9/9時点ではKiroはdev-containerに対応していないのです。
拡張機能のインストールができません。


なのに、dev-containerが起動しない!、インストールコマンドが失敗する!と戦い続けました。
そして、無料枠を無駄に消費するという悲しき事態となりました。

結局、Cursorでコンテナを起動し、Kiroで開発という2つのエディタを利用する面倒な形に落ち着きました。
開発が終わるまでの辛抱だと、自分に言い聞かせて…
ここからはスムーズに進みました。
ただし、Kiroでコンテナを起動していないので、テストの実装で留め、実行はCursorでする変則的な開発方法となります。
UIの実装が始まるステップ6までは、時とばし
〜
〜
〜
して、ようやく見えるところまで実装されました。
👏👏👏
ここで、あーいいやん❤️って思いました。

ただ残念なことに、ここでKiroの無料枠の上限である50回に到達しました。

以降は、Claude Code(Pro契約)に引き継いでもらいます。
そのために、CLAUDE.mdをできるだけSpec駆動と同じになるよう調整しました。
実装はPython-Proなサブエージェントを用意しお任せします。(もちろん事件は起こりますが割愛)
執筆時点の9/11では、9ステップまで進めており、途中でデザイン調整や思いついた機能追加で寄り道中のため完成はまだ先です。
まあ、完成しても本当に使えるかは別の話ですが。
サンプル
ということで、現時点のUIを一部お見せします。
まずは、TOPにあたる部分です。
登録済みのログを検索できる機能ですが、まだ下に続きがあって検索結果のグラフ化も可能です。

テストデータから出力したグラフはこちら。
ただ、現時点では時系列で見るメリットを何も見いだせないですw

他にもありますが、ガワだけの中身がない実装のためデータ投入画面へ。
こちらは完全ローカルで動かす想定のため、ローカルに落としたCSVやJSON等のログファイル取り込むことを想定していました。

ですが、毎回手動でログを取得するの面倒くさいなと思ってしまい、割り込みタスクとしてBoto3でログ抽出する機能を追加しました。
現在はテスト中ですが、追加仕様で保存したCSVを自動で取り込むようにします。
これ以降は、新たなツール(Claude Code)を召喚し、開発を引き継いでもらいました。
私はPro契約なので、Sonnetしか利用できません….
Maxプラン契約したいなー

ただし、ここで誤算だったのは、dev-containerだとホスト側のAWSプロファイルを参照できないってことでした。
Claude Codeに渡したエラーログの回答を見て、「あ!そっか、dev-containerで動いてたんや」と気づいてしまい、アホ丸出しです。
一時的にCloudWatchLogsのみ参照できるIAMを持ったユーザを作り、プロファイルをコンテナに登録して利用することにします。
終わり
現在開発中のため、ここまでとなります。
いかがだったでしょうか。
思ったより無料枠でも、開発できるものですね。
KiroのクレジットをできるだけVibeに消費し、細かい修正やエラー対応はCursorやClaude Codeに対応していくと良さげでした。
今回であれば、dev-container問題に早く気づけていればと切に思いますが、初めて使ってみたので仕方ないですね。
今回だけでも色々勉強になりました。
無料で気づきをくれるサービス提供してくれているベンダーには感謝しかありません。
今後も使い倒します。
なので、無料枠をください🙏
このアプリの完成時に続きの記事を出しますので、時間があればご覧ください。
ではでは、また次の機会に。