Zenn
Closed6

AWS発vibe-coding特化型IDE「Kiro」を触ってみる

AI
IDE
Vibe Coding
Kiro
foxytanukifoxytanuki

AWSのリリース記事。
https://aws.amazon.com/jp/blogs/news/introducing-kiro/

Kiro は Vibe Coding “も” 得意ですが、それをはるかに超えています。Kiro の強みは、スペック (spec) やフック (hook) などの機能を使って、これらのプロトタイプをプロダクションシステムに移行することです。

とあるように、Claude Codeに代表されるオートパイロット型AIエージェントをサポートする機能を通して、AIエージェントの強みを活かし、弱みを補うような仕組みが作られている模様。

自分はClaude Codeを使う中で以下のような工夫をしていたので、もっとやりやすくなるのではないかと期待。

  • 事前に定義した仕様の質が出力の質に大きく影響するので、仕様は細かく書く
  • ToDoを適切な粒度でリスト化し、チェックボックスで進捗を記録する

また、

  • 作業終了後などに任意の行動を頼んでもたまに実行してくれない不安定さ

も感じており、それがhooksによって安定すれば嬉しいところ。

foxytanukifoxytanuki

公式Docsななめ読み #1

開発フロー

プロジェクトのコンテキストと要件を定義

Steering Files は、プロジェクトのコンテキストや要件を書くところらしい。Claude Codeでいう CLAUDE.md か。

機能の要件と設計、タスクを定義

Specs は、

  • 要件
  • 設計
  • タスク

を書く領域。

Specを元に、 tasks.md というファイルが生成され、それを元にAI Agentが作業をしていくらしい。

MCPも使える。

良さそう...

UI

VSCode forkらしく、インターフェースはCursorやVSCode+Clineのような馴染みのあるレイアウト。

Index

コードベースのIndexもするらしい。ここはCursorと一緒。

コンセプト

実際に記事を見たほうが早い。 要件→設計→実装と3フェーズに分けてagentと対話するフローが想定されているっぽい。
https://kiro.dev/docs/specs/concepts/index

ベストプラクティス

仕様のアップデートの仕方、仕様をチームで共有の仕方、仕様をいくつ保持できるか？などが書かれている。ここは実際に使い始めてから見たほうがいい気がしたので後で見返す。

https://kiro.dev/docs/specs/best-practices/index

foxytanukifoxytanuki

公式Docsななめ読み #2

Chat

https://kiro.dev/docs/chat/index

コンテキスト管理

Cursorだと @file のようにファイルを指定するが、KIROでは #file と、#が接頭辞(?)。

https://kiro.dev/docs/chat/index

オートパイロット

[追記] 実際に使ってみたら定期的に確認作業があって、これがAutopilotなのか、Supervisedがデフォルトになっているのか分からず混乱しています
[追記2] デフォルトは確かにAutopilotモードでした。でも、mvとかrmみたいな影響度の高いコマンドは確認を取るみたいです。賢い！

Autopilot Mode と Supervised Mode がある。その名の通り、Autopilotが最初から最後まで自動でやってくれるモードで、Supervisedが人間の承認がいるモード。
Autopilotがデフォルト。
Claude CodeではAutopilotはBypassing Permissionモードとしてオプションを付けて実行する必要があり、Supervisedがデフォルトなので、真逆の設定。

Vibe vs Spec

Kiroを開くと、VIbeかSpecどちらで始めるか問われる。

  • Vibe
    • 質問や概要の把握、簡単な修正、状況を見て柔軟に実装したい場合などに使うモード。
  • Spec
    • 複雑なタスク向きで、仕様を固めてから取り組みたい場合などに使うモード。

ターミナルへのアクセス

npm install, git status などAgentによるコマンドの実行も可能。

https://kiro.dev/docs/chat/terminal/index#trusted-commands

Hooks

https://kiro.dev/docs/hooks/index

ファイル保存後、ファイル新規作成後、ファイル削除後、などのイベントの後に発火することの出来るアクション定義。
パッと思いつくのはファイル保存後にlintを走らせる、とか？

ご丁寧にベストプラクティスや例も用意されている。

Steering

https://kiro.dev/docs/steering/index

Claude Codeでいう CLAUDE.md 。CursorでいうProject Rules。 ライブラリやパターンなどの慣例を書く。

ファイルがトピックによって細分化されている。

  • product.md：製品の目的、ターゲットユーザー、主要機能、ビジネス目標を定義。技術的な意思決定の背景や方向性を理解させ、製品目標に沿った提案を促進。
  • tech.md：使用しているフレームワーク、ライブラリ、開発ツール、技術的制約を記録。提案や実装はこのスタックを優先。
  • structure.md：ファイル構成、命名規則、インポートパターン、アーキテクチャの決定を示し、コードの一貫性と統合を支援

（↑ここだけAIで翻訳した）

カスタムでSteering Filesの作成も可能。例えば api-standards.md など。

foxytanukifoxytanuki

公式Docsななめ読み #3

MCPは割愛。

Language Support

  • TypeScript and JavaScript
  • Java
  • Python

https://kiro.dev/docs/guides/languages-and-frameworks/index

Typescript and JavaScript

https://kiro.dev/docs/guides/languages-and-frameworks/typescript-javascript-guide/index#suggested-extensions

ESLintとPrettierが推奨らしい。Biome派だけど、まあ多分大丈夫でしょう（optimistic)。
SteeringやHooksの書き方例まで乗ってるので、各々の開発言語のドキュメントを一度見ておくと良さそう。

VSCodeからの移行

Kiro立ち上げ時に移行しますか？と言われて天邪鬼な自分は拒否してしまったが、数秒後に移行しておけばよかったと後悔した。そんな捻くれ者にも優しく手を差し伸べてくれる。

https://kiro.dev/docs/guides/migrating-from-vscode/index

foxytanukifoxytanuki

実践: ccnotify

Claude CodeのStop Hooksを簡単につくれる補助CLIツールを作ることにする。
Specモードで以下の文言を投げてみた。

文言

Claude CodeのStop Hooksを簡単につくれる補助CLIツール。

技術スタック:

  • TypeScript

  • Biome

  • pnpm

  • commander.js

機能要件:

  • ccnotify でヘルプ

  • ccnotify discord <webhook_url> でdiscordに通知するStop Hookを作成。現在いるディレクトリの .claude/settings.json を編集or作成。

  • ccnotify ntfy <topic_name> でntfyに通知するStop Hookを作成。現在いるディレクトリの .claude/settings.json を編集or作成

  • --global or -g オプションで、 ~/.claude/settings.json を編集する

  • commandは別途shスクリプトを用意するか直接記載。shスクリプトの場所はsettings.jsonと同じ階層。

Stop Hookの例:


{   "hooks": {     "Stop": [       {         "matcher": "",         "hooks": [           {             "type": "command",             "command": "<実行させたいコマンド>"           }         ]       }     ]   } }

ntfy用通知の例:


# ntfy.sh

#!/bin/bash

# デフォルトのトピック名を定義

DEFAULT_TOPIC_NAME="your-topic-name-D615CCC1-8C83-450C-9DF9-8044F234A296"

# 設定（環境変数が設定されていればそれを使用、なければデフォルトを使用）

TOPIC_NAME="${NTFY_TOPIC:-$DEFAULT_TOPIC_NAME}"

# transcript_pathを取得

TRANSCRIPT=$(jq -r .transcript_path)

# 最新のアシスタントメッセージを取得

LATEST_MSG=$(tail -1 "$TRANSCRIPT" | jq -r '.message.content[0].text // empty')

# 最新のユーザーメッセージを取得

USER_MSG=""

while IFS= read -r line; do

  TYPE=$(echo "$line" | jq -r '.type // empty')

  if [ "$TYPE" = "user" ]; then

    ROLE=$(echo "$line" | jq -r '.message.role // empty')

    if [ "$ROLE" = "user" ]; then

      CONTENT=$(echo "$line" | jq -r '.message.content // empty')

      # contentが文字列で、[で始まらない場合のみ採用

      if [ -n "$CONTENT" ] && [ "${CONTENT:0:1}" != "[" ]; then

        USER_MSG="$CONTENT"

        break

      fi

    fi

  fi

done < <(tac "$TRANSCRIPT")

# メッセージが空でない場合のみ送信

if [ -n "$LATEST_MSG" ]; then

  echo "$LATEST_MSG" | sed 's/^/ /' | head -c 500 | \

  curl -H "Title: ${USER_MSG:0:100}" -d @- "ntfy.sh/${TOPIC_NAME}"

fi

要件が requirements.md にまとめられ、右下に "Move to design phase" というボタンが出てきた。要件を編集したい場合はチャットで依頼し、要件が問題ない場合は設計フェーズに進むということなのだろう。何かケチを付けてみたかったが、パッと見問題なさそうだったので設計に進む。

次は design.md が生成された。ここでアーキテクチャとインターフェースを確認するということらしい。これもまた問題なさそうなので、右下の "Move to implemention plan" に進む。

次に tasks.md が生成された。タスクが順序立てて細分化されている。おまけに、ただのチェックボックスではなく "Start Task" というボタンまでついてる。独自IDEならではの手の込んだ機能。

ここで、「Discordよりntfyの方を先に実装してほしい。 ntfy.sh を参考にできるので。」と伝えると、すぐに更新してくれた。変更が気に入らなければRevert出来る。

ここで次に進んでと言ってしまったが、先ほど触れた task.md の "Start Task" ボタンを押すのが正解らしい。


進み始めた...！

10分も立たないうちにプロジェクトの雛形が完成した。
ちなみに自動で全部やってくれるのかと思いきや、mkdir時には確認が取られた。

foxytanukifoxytanuki

作りきった。
人間の介入タイミングは多いけど、ポチポチしてるだけで質の高いツールができてしまった

このスクラップは1ヶ月前にクローズされました