なんだかんだKiroのSpecが結構良い件(Cursor Planモードとの比較を添えて)

Last updated at 2025-10-14Posted at 2025-10-14

こんにちは！

AIコーディングエージェント使っていますか？
Cursor, Cline, Windsurf, Devin, Codex, Claude Codeなど多くのAIコーディングエージェントがリリースされており、それぞれIDE内蔵型/CLI型/コンテナ型など型による特性の違いや、同じ型でも微妙に設計思想が違ったりします。

私も色々試しましたが、今はCursorを利用するケースが多いです。
CursorはIDE内蔵型のAIコーディングエージェントであり、「じゃあこれ、よろしく」と言うよりは「一緒にコーディングしたいから力を貸してね」と言うような伴走者のような役割を担ってもらうことが多いです。まあ、この辺はAIコーディングエージェントに何を求めるか、利用するシーンによってもこの選択は変わってくると思います。

Kiroとは

ところでみなさん、今年の7月に登場したKiroをご存知でしょうか？
https://aws.amazon.com/jp/blogs/news/introducing-kiro/

AWSが開発しているAIコーディングエージェント(AWSはAI IDEと言っています)であり、Specをウリにしています。Specとはユーザーの要件を事前にドキュメントとして明確に言語化し、また設計/実装計画も作成するといった機能であり、AIコーディングエージェントを利用する際に起こりがちな意図しない実装を防ぐことができます。
https://kiro.dev/docs/specs/

わかりやすく言うと、ユーザーが要件を入力したら

要件
設計
実装計画

これらをドキュメントとして作成して、ユーザーと合意を得ます。
そして、これらのドキュメントを元に実装を行います。

Kiroが登場する前から、他のAIコーディングエージェントでもこれらのドキュメントを作って、意図しない実装を防ぐというやり方を独自に行なっている人は多くいました。しかし、プロダクトの標準として組み込んで、それを強調したAIコーディングエージェントはKiroが初だったかと思います。

私もKiroがリリースされた時(7月末くらい)にSpecを利用して「おお、これは結構いいな」と思った記憶があります。
しかし、その時すでにCursorでRulesを作り込んで、オレオレSpec的なものを利用していました。なので2,3回使ってから、Cursorに戻ったという経緯があります。

CursorのPlanモード

最近リリースされたCursorの新機能にPlanモードがあります。
https://cursor.com/ja/blog/plan-mode

Plan Mode では、モデルに計画を作成・更新するための新しいツールと、計画をその場で編集できるインタラクティブなエディタを提供します。現在、Cursor の多くの新機能は Agent がまず計画を書くところから始まります。このアプローチにより、生成されるコードの品質が大幅に向上しています。

Agent に計画の作成を指示すると、Cursor はコードベースを調べ、関連ファイルの特定やドキュメントの確認、要件の明確化のための質問を行います。計画が固まったら、ファイルパスやコード参照を含む Markdown ファイルを作成します。To-do の追加・削除を含め、計画は直接編集できます。

どうやら要件の明確化/計画の作成をするらしいです。

(ClineやClaude CodeにもPlanモードがあります)

CursorのPlanモードのドキュメントを読んだ限りでは、KiroのSpecはどちらかというと要件/設計にフォーカスしており、CursorのPlanモードは計画にフォーカスしているような印象を受けました。ただ実装前にしっかりとユーザーと認識合わせしておきましょうという方向性に関しては同じであり、比較してみると面白いものが見えてきそうだなと感じました。

このブログで書くこと

KiroのSpecとCursorのPlanモードを使い比べて比較します。
その結果、KiroのSpecの優位性が見えてきました。

このブログでは比較内容とKiro Specの優位性について共有させていただきます。

なお、本ブログの成果物はGithubにて保存しております。

比較の方法

以下要件のアプリケーション(というよりスクリプト)をKiroのSpec、CursorのPlanモードそれぞれを利用して実装します。

以下の要件を満たすPythonスクリプトを実装してください。

- コマンドライン引数で指定された入力JSONファイルを読み込む
- そのJSONオブジェクトのキーをアルファベット順にソートし、整形（インデント4）して新しいファイルに出力する
- ファイルが見つからない、またはJSON形式が不正な場合のエラーハンドリングも必要

このような要件にした理由としては

シンプル : 1ファイルで完結する（jsonモジュールと標準機能のみ）
適度な複雑さがある: 単純な計算だけでなく、ファイルのI/O、データ構造の操作（ソート）、エラーハンドリング（ファイルが見つからない、JSON形式が不正など）が必要となり、AI-IDEの計画（Spec/Plan）能力を総合的に評価できる

実装プロセス(要件/設計/計画)および最終成果物(スクリプト)を比較します。

なお、どちらも利用するモデルはClaude Sonnet 4とします。

実装

Cursor Planモード

チャットの左下からPlanを指定して、要件を入力します。

すると以下のような計画を記載したマークダウンが生成されました。

json-sort-script.plan.md

# JSON Sort Script Implementation

## 実装内容

`json_sort.py`スクリプトを作成し、以下の機能を実装します：

### 主要機能

- `argparse`を使用してコマンドライン引数を処理
- 入力JSONファイルの読み込み
- JSONオブジェクトのキーをアルファベット順にソート（再帰的に全レベル対応）
- インデント4でフォーマットして出力ファイルに保存

### エラーハンドリング

- ファイルが存在しない場合の`FileNotFoundError`
- JSON形式が不正な場合の`json.JSONDecodeError`
- その他のI/Oエラー

### コマンドライン仕様

`python json_sort.py input.json output.json`

### 実装詳細

- `json.dumps()`の`sort_keys=True`と`indent=4`パラメータを使用
- 再帰的なソート処理で全てのネストレベルに対応
- 適切なエラーメッセージと終了コード

### テスト用サンプル

動作確認用の`sample.json`ファイルも作成します。

実装の仕様/要件が簡潔にまとめられており、最後にTodo形式で実装計画が記載されています。まだKiroのSpecと比較する前ですが、かなり粗い印象です。

チャット画面にもパネルで表示されるので、Buildをクリックします。

するとTodoに従って、実際にスクリプトが作成されます。
これにてスクリプトの作成は完了しました。

どのようなスクリプトになったかは、後述します。

ちなみにこの計画ファイル(json-sort-script.plan.md)はファイルとして作成されない気がします(Cursorにファイル出力してと頼んだらしてくれそうだけど、何もしなかったらファイルとして保存できないような作りになってそう)。

Kiro Spec

Specを選択して、要件を入力します。
(言語設定日本語にしたはずなのに、英語で回答されるのでプロンプトにて日本語で回答するように依頼)

するとまずは要件定義をrequirements.mdとして出力してくれます。

requirement.md

ユーザーストーリーベースで要件を落とし込んでくれています。
正常系/異常系で複数のユーザストーリーがあり、それぞれで受け入れ基準を明確にしています。

今回はここを詰めることはしませんが、最初の段階でここを明確にできると誤った要件で進むことが防ぎやすいです。

次にrequirement.mdをもとに設計ドキュメントを作成します。

design.md

アーキテクチャ/データモデル/エラーハンドリング/テスト戦略
という大枠でかなりきめ細かい設計まで落とし込んでくれています。
(今回の要件に関しては若干冗長感もありますが)

そして実装計画を作成します。

tasks.md

Kiroと比較してもかなり細かい実装計画な気がします。
また要件とのリンクがされているので、実装の抜け漏れがないかの確認もしやすいです。

tasks.mdをエディターで開くと、そこからStart taskをクリックできるので、はじめのタスクだけ実行してみます。

すると空のメソッドとグローバル変数のみを定義した叩き台のようなスクリプトが作成されました。

叩き台コード

#!/usr/bin/env python3
"""
JSONキーソーター
JSONファイルのキーをアルファベット順にソートして整形出力するスクリプト
"""

import sys
import json
from typing import Union, Tuple, Any

# エラーメッセージ定数
ERROR_MESSAGES = {
    'usage': 'Usage: python json_sorter.py <input_file> <output_file>',
    'file_not_found': 'エラー: ファイルが見つかりません: {}',
    'invalid_json': 'エラー: JSON形式が不正です: {}',
    'read_error': 'エラー: ファイル読み込みエラー: {}',
    'write_error': 'エラー: ファイル書き込みエラー: {}',
    'unexpected_error': 'エラー: 予期しないエラーが発生しました: {}'
}

# 成功メッセージ
SUCCESS_MESSAGE = 'JSONファイルのキーソートが完了しました: {}'

# 型定義
JsonType = Union[dict, list, str, int, float, bool, None]
ArgumentsType = Tuple[str, str]


def parse_arguments() -> ArgumentsType:
    """
    コマンドライン引数を解析
    Returns: (input_file_path, output_file_path)
    Raises: SystemExit - 引数が不正な場合
    """
    # TODO: 実装予定
    pass


def read_json_file(file_path: str) -> dict:
    """
    JSONファイルを読み込んでパース
    Args: file_path - 読み込むJSONファイルのパス
    Returns: パース済みJSONオブジェクト
    Raises: FileNotFoundError, json.JSONDecodeError, IOError
    """
    # TODO: 実装予定
    pass


def sort_json_keys(json_obj: JsonType) -> JsonType:
    """
    JSONオブジェクトのキーを再帰的にアルファベット順ソート
    Args: json_obj - ソート対象のJSONオブジェクト
    Returns: キーがソートされたJSONオブジェクト
    """
    # TODO: 実装予定
    pass


def write_sorted_json(json_obj: JsonType, output_path: str) -> None:
    """
    ソート済みJSONを整形してファイルに出力
    Args: 
        json_obj - 出力するJSONオブジェクト
        output_path - 出力ファイルパス
    Raises: IOError, OSError
    """
    # TODO: 実装予定
    pass


def main() -> None:
    """
    メインエントリーポイント
    プログラムの全体的な実行フロー制御
    """
    try:
        # TODO: 各処理ステップの実装予定
        # 1. コマンドライン引数の解析
        # 2. JSONファイルの読み込み
        # 3. キーのソート処理
        # 4. ソート済みJSONの出力
        # 5. 成功メッセージの表示
        pass
    except Exception as e:
        print(ERROR_MESSAGES['unexpected_error'].format(str(e)), file=sys.stderr)
        sys.exit(1)


if __name__ == '__main__':
    main()

1タスクがかなり細かく刻まれているような印象です。
ただその分1タスクにおける成果物が多すぎず、わかりやすく区切られているので人間のチェックがとてもしやすい印象です。

ではこれ以降のタスクを全て実行してもらうようにお願いします。
最終的な成果物は後述します。

比較

それではCursor PlanモードとKiro Specの比較を実装過程(プロセス)と成果物の観点から比較していきます。

プロセス

比較軸	Cursor (Planモード)	Kiro (Specモード)	評価
プロセス構造	計画 → 実装	要件 → 設計 → 計画 → 実装	KiroはV字モデルに近く構造化された開発プロセスであり、Cursorは迅速なプロトタイピング向き。
要件	ユーザー入力のみを基にした簡潔な説明	ユーザー・ストーリーと受け入れ基準を用いて要件を掘り下げて構造化。	Kiroは仕様の抜け漏れを防ぐ点で優れている。
設計	ほとんど設計工程がない（実装コードに直接反映）	アーキテクチャ、コンポーネント、データモデル、エラーハンドリング、テスト戦略まで詳細に設計。	Kiroはコードの品質と保守性に直結する設計を重視。今回の要件ではオーバースペック気味。
計画	ToDoリスト形式の簡潔な計画（粗い）	要件定義 (ユーザー視点) と設計ドキュメント (技術視点) を含む非常に詳細な計画	Kiroは要件の曖昧さを排除し、手戻りを防ぐための準備に時間をかける。
実装のやり方	Buildボタンで一括生成 (高速)	タスクごとに逐次実行（人間のチェックを前提）	Cursorは速度が速いが、生成コードのレビューが大変。Kiroは人間との協調を重視し、品質保証のステップが多い。

冒頭でも言いましたが、やはり

Kiro Spec => 要件/設計にフォーカス
Cursor Planモード => 計画にフォーカス
という認識は概ね正しそうです。

Cursor単体だけで見るとそこまで思いませんでしたが、Kiroと比較してみるとCursorのPlanモードの粗さが際立つ結果となりました。Kiroはやりすぎくらい要件/設計/計画を作り込んでおり、実装までに時間はかかってしまいますが、確実に成果物の質は高くなることが確信できます。

成果物

Cursor Planモード

json_sort.py

Kiro Spec

json_sorter.py

test_json_sorter.py

比較軸	Cursor Planモード	Kiro Spec	評価
構造	main()関数内に処理が集中	機能ごとに関数を分け、main()がそれらを呼び出す(モジュール化)	Kiroは機能分離型であり、テストや変更がしやすい。Cursorは手続き型であり、シンプルで一目で理解しやすい。
引数	argparseを使用	sys.argvの長さをチェックする手動実装	Cursorはargparseを使うことで標準的でヘルプ表示が自動生成される。Kiroはシンプルだが機能は最小限。
ソートロジック	辞書ソートにsorted(obj.items())を使用	辞書ソートにsorted(obj.keys())を使用	本質的なロジックは同じだが、Cursorの書き方の方が簡潔な印象。
エラーハンドリング	main()内の単一のtry...exceptブロックで、ファイルI/Oエラー、JSONエラーなどを一括捕捉	各関数内（read_json_file, write_sorted_json）で、それぞれの責務に応じたエラーを捕捉し、定義済みのメッセージで終了	Kiroの方がエラー発生時の原因特定が容易で、メッセージも統一されている（ERROR_MESSAGESを使用）。
コードの保守性	型ヒントなし	型ヒント (JsonType, ArgumentsTypeなど) を使用	Kiroの方が静的解析や大規模開発において優れている。
ファイル出力の処理	output_path.parent.mkdir(parents=True, exist_ok=True)で親ディレクトリを自動作成する処理が含まれる	なし、親ディレクトリが存在しない場合はエラー	Kiroは親ディレクトリについての考慮なし。
テスト	なし	複数ケースのユニットテストを実装	テストについては要件に直接含んでいないが、Kiroはテストコード込みで実装してくれる。

実装の前工程である要件定義/設計/計画の質は、明らかにKiroの方が高く、それが成果物にも表れているという印象です。ただ全てにおいてKiroが優れているというわけではなく、ソートロジックなどはCursorの方が簡潔であり優れている印象であり、親ディレクトリの考慮もKiroはされていないというのが意外でした。どれだけ要件/設計/計画を細かく作り込んだとしても、やはり考慮しきれない点があるということでしょうか。

総括

Cursor PlanモードとKiro Specの実装プロセスおよび成果物を比較してみて、KiroのSpecの方がより詳細かつ体系的にプロダクト開発を進められるという印象です。Cursor Planモードは最低限の認識合わせ、Kiro Specは徹底した認識合わせという感じでしょうか。ただ、いくら認識合わせを徹底しても抜け漏れが生じるのはAIも人間も同じですね。

AIコーディングエージェントを利用する目的にもよりますが、AIの伴走を期待するのであればKiroはかなり良いツールになりうると思います。ただし、効率性や独立性を求めるのであれば、SpecがウリのKiroは優位性に欠けている印象です。

またKiroのSpecは技術的な独自性ではないため、Specのようなことを他のAIコーディングエージェントでやろうと思えばできてしまいます。AIコーディングエージェントを使いこなしている方はすでにオレオレSpecに該当する仕組みを持っていると思いますが、AI駆動開発に慣れていない方、プロダクト開発に慣れていない方、AIコーディングエージェントの利用経験が乏しい方はKiroからはじめるのはかなり良い選択だと思います。

無料枠もあり、今ならClaude Code 4.5も利用できるので、ぜひKiroでAIコーディングエージェントデビューしてみましょう！

なんか、宣伝みたいになりましたね。。。
以上です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up