プロジェクト途中でCursorからKIROに乗り換えた際の作業内容(参考画像つき)

記事を書いたきっかけ。

私はAIとの伴走での開発感覚や、Composer1の機能の良さに惚れ込んでいたCursorユーザーだったのですが、AWS re:Inventで始めた使用したKIROが思っていたよりも良さそうだったので乗り換えることにしました。その際にCursorユーザーの目線からの乗り換え解説記事がなさそうだったので残しておくことにしました。

KIROの導入、概要把握

こちらの記事の内容が良いと思いました。

私が感じたCursorとの差分

一言で表現すると
「Cursorに実装レールが追加された」
と言える気がしています。

Cursorを使用していたときは意識して

• cursorルールにコーディングルールを記載
• Askを使って壁打ちして、ドメインに関するドキュメントを指定した場所に作成
• Planを使用して実装計画を立てて
• Agentを使用していざ実装

という流れだったのですが、それらの工程をKIROが自然に誘導してくれる感じがします。

また、MCPサーバーやhooks(コミットの時にテスト流して〜みたいなやつ)も、明示的かつレールに乗る形で利用できるようになります。

最終的な.kiroのディレクトリを先に確認

紆余曲折はありますが、最終的にはこのような形になりました。

.kiro/
├── specs/                  # 機能仕様書
│   ├── system-overview/    # システム全体設計
│   │   ├── requirements.md # 要件定義
│   │   ├── design.md       # 設計書
│   │   └── tasks.md        # タスクリスト
│   └── v2-admin-dashboard/ # V2管理画面(このプロジェクトの主要機能)
│       ├── requirements.md
│       ├── design.md
│       ├── tasks.md
│       └── features/       # 機能別詳細仕様(requirementsから参照)
│
├── steering/               # コーディングルール・ガイド
│   ├── product.md          # プロダクト概要
│   ├── tech.md             # 技術スタック
│   ├── structure.md        # プロジェクト構造（このファイル）
│   ├── backend-coding-rules.md      # バックエンドルール
│   ├── frontend-coding-rules.md     # フロントエンドルール
│
├── hooks/                  # Kiro Hooks（自動化）
│   └── format-lint-check.kiro.hook  # フォーマット・Lintチェック
│
└── settings/               # Kiro設定
    └── mcp.json            # MCP（Model Context Protocol）設定

プロジェクト途中で初めてKIROを使う際の実際の手順

Specモードでプロジェクトのドキュメントの整理

画面全体の構成はCursorとほとんど変わりません。
右で新しいセッションを作るとVibeかSpecかを選択する画面に入るのでSpecをクリックします。
そうすると、あとは自然とKIRO側が
Step A: 要件（Requirements）
Step B: 設計（Design）
Step C: タスク化（Tasks）
と導いてくれます。

Step A: 要件（Requirements）

私は初めての使用だったので、まずは既存のドメイン情報をkiroに伝えたいと考え、

私は今までcursorを使って開発してきましたが、これからkiroを利用して開発してみようと思っています。
現在は.cursorにコーディングルールが存在し、docに簡単なドメイン知識が記載されています。
またAGENTS.mdに毎回しようする情報が記載されています。
これらを利用しつつ、kiroのスペックなどを構築していきたいです。
必要な作業について教えてください

とプロンプトを投げると、

~~~
次のステップ
どの機能をスペック化したいですか？

例えば：

既存の機能を改善したい
新しい機能を追加したい
特定のバグを修正したい
機能を教えていただければ、以下を実施します：

既存スペックの確認（あれば）
新規スペック作成（なければ）
.cursor/rulesのルールを参照しながら、要件定義から始める
どの機能について、スペックを構築したいですか？

または、もし全体的な俯瞰的な要件定義から始めたいのであれば、以下の構成で作成することもできます：

システム全体の目的と背景
主要なユーザーペルソナ
高レベルな機能要件
非機能要件（パフォーマンス、セキュリティ、スケーラビリティなど）
どのアプローチをご希望ですか？

のように次にステップに導いてくれたので、それに従って会話を進めるうちにspecが完成しました。
モデルについては、Composer1の感覚でClaude Haiku 4.5を使いましたが割といい感じでした。

⚠️差分については目のアイコンのfollowをクリックするとCursorと同じような表示になりました。

⚠️初めて実行するコマンドについては、紫の枠で表示されたコマンドをクリックしないと実行されないです。最初は注意が必要です。

↑設定をしないといちいち、このFull Commandをクリックしないといけない。

左下の歯車から設定を開き「Trusted Commands」から*を指定しつつ、削除系は確認をもらうように設定しました。

作成が完了すると.kiro/spec が作成されます。

おばけアイコンを押すと、今使用しているspecが表示されるようになりました。

こんな感じに、Step B: 設計（Design）にしつこく誘導されるので、いい感じになったら進みます。

Step B: 設計（Design）

設計や、私のコーディングの思想については全てcursorルールに記載していたので、それを参考に作成するように伝えました。

既存の.cursor/rulesに、今までの実装の設計や私のコーディングルールなどは全て記載しています。
それを参考に、時間をかけて丁寧に正確に、設計ドキュメントを作成してください。

重い作業なのでclaude4.5にしたのもあるのですが、一発でかなり高い精度の設計書ができました。
私のcursorルールが対応できていなかった修正箇所についても私に確認しながら修正加筆まで対応してくれました。すごい。

Step C: タスク化（Tasks）

そのまま推奨されるプロンプトを実行すると、タスク一覧についても作成されました。
こちらの内容は今までの内容をかなり踏襲しているようだったので、あっさり作成される感じでした。
しかし、既存の実装完了部分についても未完了のタスクのような扱いになっていたので、それらはKIROのtaskStatusツールを使用してタスクの進捗管理をするように追加のプロンプトを投げました。

そうすると、完了したタスクについてはこのようにチェックを入れる形に変更してくれました。こちらについては手動でxを入れる形でもいけます。
開発者が全員KIRO使用なら良さそうな機能だなとは思いましたが、運用については結構考える必要はありそうです。

MCPサーバーの設定

おばけのアイコンを押すと一番下にMCP SERVERが表示されます。何も触ってないので当然空です。

とりあえずCDKのMCPサーバーから追加するようにプロンプトで指示をします。
そうすると以下のようになりました。

.kiro/settings/mcp.json

{
  "mcpServers": {
    "aws-cdk": {
      "command": "uvx",
      "args": ["awslabs.cdk-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

内容についてKIROに解説してもらいましたので貼っておきます↓
1. mcpServers
MCPサーバーの設定を管理するセクション
複数のサーバーを登録できます

2. "aws-cdk"
このサーバーの名前（識別子）
Kiroで「aws-cdk」という名前で呼び出されます

3. "command": "uvx"
サーバーを実行するコマンド
uvxはPythonパッケージマネージャーで、必要なツールを自動ダウンロード・実行します

4. "args": ["awslabs.cdk-mcp-server@latest"]
uvxに渡す引数
awslabs.cdk-mcp-server@latest = AWS CDK開発用のMCPサーバーの最新版をダウンロード・実行

5. "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
環境変数の設定
FASTMCP_LOG_LEVEL": "ERROR" = エラーメッセージのみ表示（詳細ログは非表示）

6. "disabled": false
サーバーの有効/無効を切り替え
false = 有効（使用可能）
true = 無効（使用不可）

7. "autoApprove": []
自動承認するツール名のリスト
現在は空（すべてのツール実行時に確認が必要）

私はとりあえずautoApproveをtrueに変更しました。

同様にContext7も追加しました。プロンプトでお願いするとuvxから取得しようとしてエラーになったので手動で直したりはしました。また速度を気にして固定バージョンに変更するなどしました。

{
  "mcpServers": {
    "aws-cdk": {
      "command": "uvx",
      "args": ["awslabs.cdk-mcp-server@1.0.9"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": ["*"]
    },
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp@1.0.30"],
      "disabled": false,
      "autoApprove": ["*"]
    }
  }
}

作業はこれにて完了です。おばけアイコンのMCPの表示でもきちんと表示されていることが確認できます。

AGENT HOOKSの設定

AGENT HOOKSとはIDEで特定のイベントが発生したときに定義済みのエージェントアクションを実行する自動トリガーです。

おばけのアイコンをクリックしてからAGENTS HOOKSの+ボタンをクリックすると設定画面に入ります。

とりあえずバイブコーディング後にPrettier → ESLint を走らせて欲しいと英語を入力して実行してみると、右側のチャットスペースで生成しはじめました。

After the agent finishes an execution and applies code changes, run npm run format and then npm run lint. 
If either command fails, show the output to the agent and ask it to fix the issues.

しばらくするとcreatedになったことが確認できました。AGENT HOOKSにも項目が追加されたことが確認できます。

.kiro/hooks/format-lint-check.kiro.hookが作成されました。内部的にはこちらを調整することで細かく制御できそうですね。

{
  "enabled": true,
  "name": "Format and Lint After Agent Changes",
  "description": "After the agent finishes an execution and applies code changes, automatically run npm run format and npm run lint. If either command fails, show the output to the agent and ask it to fix the issues.",
  "version": "1",
  "when": {
    "type": "agentExecutionCompleted"
  },
  "then": {
    "type": "runCommand",
    "command": "npm run format && npm run lint",
    "onFailure": {
      "type": "askAgent",
      "prompt": "Format or lint failed. Please review the output above and fix the issues."
    }
  }
}

AGENT STEERINGの設定

STEERING = 操舵
のニュアンスのようです。つまり方向性の指示とか進行方向を合わせるためのガイド的な内容だと思われます。

designとsteeringの差については以下のイメージを持つと良さそうです。

design.md（設計書）の役割

• 「何を作るか」を定義する
• 特定の機能・システムの設計
• プロジェクト固有の仕様
• 具体的な内容
  アーキテクチャ図
  データモデル（型定義、スキーマ）
  API設計（エンドポイント、レスポンス形式）
  コンポーネント構成
  データベースクエリパターン（具体的なSQL）
  Correctness Properties
  デプロイ戦略
  パフォーマンス目標

steering（ステアリング）の役割

• 「どう作るか」を定義する
• プロジェクト全体で共通のルール
• 技術スタック全般に適用される原則
• 変更されにくい普遍的な内容
• 具体的な内容
  コーディング規約（命名規則、スタイル）
  設計原則（YAGNI、責任の分離）
  ベストプラクティス（セキュリティ、パフォーマンス）
  技術スタックの説明
  プロジェクト構造の説明
  開発ワークフロー

最初から既存のAGENTS.mdがAGENT STEERINGとして指定されていました。
こちらについては元々Agents.mdで変更内容から読ませるcursorルールを指定する
という方針をとっていたので、それをkiro風に調整する作業を行いました。

既存のcursorルールに記載の内容はそのままsteeringに転載してください。
Agents.mdもそれに合わせて修正してください。
cursorは一応他の開発者のために残してください。

ほぼほぼコピペと参照先の変更だけ完了しました。画面上では以下のようにきちんと読み込まれていそうです。

しかし、これだけではsteeringについてはほぼcursorの内容をコピーしただけなので調整が不足しています。

まずは、適用範囲を示すinclusionが追加しました。
cursorの

---
description: フロントエンド(Nextjs)開発のための設計・実装ルール
alwaysApply: false
---

のようなものです。

---
inclusion: fileMatch
fileMatchPattern: "frontend/**/*.{ts,tsx,js,jsx}"
---

続きまして、
product：プロダクトの概要、目的、主要な機能
structure：フォルダ構成、命名規則、インポートパターン、アーキテクチャ
tech：使用するフレームワーク、ライブラリ、言語、開発ツール

の3種類のファイルを作成しました。
これらはinclusion: always
で作成することが良さそうなのでそうしました。

.kiro/steering/structure.md

---
inclusion: always
---

# プロジェクト構造

## ルートディレクトリ構成

.
├── .kiro/                  # Kiro設定・Spec
├── frontend/               # V2フロントエンド（Next.js）
├── infra/                  # インフラ（AWS CDK）
├── AGENTS.md               # 開発ガイド
└── README.md               # プロジェクト概要

---

## `.kiro/` - Kiro設定・Spec

Kiro IDEの設定とSpec（仕様書）を管理
~~~

最終的な.kiroのディレクトリ

.kiro/
├── specs/                  # 機能仕様書
│   ├── system-overview/    # システム全体設計
│   │   ├── requirements.md # 要件定義
│   │   ├── design.md       # 設計書
│   │   └── tasks.md        # タスクリスト
│   └── v2-admin-dashboard/ # V2管理画面(このプロジェクトの主要機能)
│       ├── requirements.md
│       ├── design.md
│       ├── tasks.md
│       └── features/       # 機能別詳細仕様(requirementsから参照)
│
├── steering/               # コーディングルール・ガイド
│   ├── product.md          # プロダクト概要
│   ├── tech.md             # 技術スタック
│   ├── structure.md        # プロジェクト構造（このファイル）
│   ├── backend-coding-rules.md      # バックエンドルール
│   ├── frontend-coding-rules.md     # フロントエンドルール
│
├── hooks/                  # Kiro Hooks（自動化）
│   └── format-lint-check.kiro.hook  # フォーマット・Lintチェック
│
└── settings/               # Kiro設定
    └── mcp.json            # MCP（Model Context Protocol）設定

紆余曲折ありましたが、最終的には以上のようになりました。
cursorルールの内容がdesignに反映され、docやAGENTS.mdの内容がrequirementsに反映され、どちらの内容の役割ごとにSteeringに反映させるというような作業となりました。
KIRO自身に.kiroのレビューをお願いしたら100/100とのこと。
本当かどうかはわからないけど一旦よしで。
HOOKはテストやレビューなどのいい感じなのを追加する予定です。他の部分も実装の中でよりよくしていきます。

まとめ

この設定によって、ひとまずはKIROの言う、仕様駆動開発（Spec-driven development）がスタートできる状態にはなったのかなと思います。
実際に機能を作成していますが、Cursorよりも考えることが少ないし、精度が高いのかなと感じています。（プラシーボかもですが)
KIROを初めて使った者の記事なので、誤っている部分があるかもしれませんが、私と似たように他の
コーディングエージェントから乗り換えを検討している人のお役に立てますと幸いです。