トップ > Spec Kit > Kiro CLIでGitHub Spec Kitの仕様駆動開発を実践する

Kiro CLIでGitHub Spec Kitの仕様駆動開発を実践する

Spec Kit Kiro CLI
記事タイトルとURLをコピーする

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

先日公開した「GitHub Spec Kitで始める仕様駆動開発」の記事では、Spec Kitの基本的なワークフローを紹介しました。

blog.serverworks.co.jp

Kiro CLI（旧 Amazon Q Developer CLI）については、2025年11月21日時点では、カスタム引数を持つスラッシュコマンドをサポートしていないため、Spec Kitとの統合には対応していません。

この記事の中では上記のように「Kiro CLIについては、Spec Kitとの統合には対応していない...」と記載しましたが、Kiro CLIの「Steering」機能を活用することで、Spec Kitとの統合に近い形を再現できたので本ブログで紹介いたします。

Steeringとは

Steering は、Kiro CLIに対して永続的な指示を与えるための仕組みです。プロジェクトの.kiro/steering/ディレクトリにMarkdownファイルを配置することで、Kiroの振る舞いをカスタマイズできます。

例えば、「このプロジェクトではTypeScriptを使う」「テストは必ずJestで書く」といったルールを定義しておけば、毎回プロンプトで指示しなくても、AIがそのルールに従ってコードを生成してくれます。

この仕組みを活用して、Spec Kitの各コマンドをトリガーワードとして定義することで、Kiro CLIでもSpec Kitの仕様駆動開発のワークフローを実現できます。

環境構築

Kiro CLIのインストール

MacOSであればHomebrewからインストールすることもできます。

brew install kiro-cli

公式なインストール手順はKiro公式ドキュメントを参照してください。

Spec Kitの初期化

まだSpec Kitを導入していない場合は、以下のコマンドで初期化します。

# 新規プロジェクトの場合
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai q

# 既存プロジェクトの場合
uvx --from git+https://github.com/github/spec-kit.git specify init --here --ai q

AIエージェントには「q（Amazon Q Developer CLI）」を選択します。Kiro CLIはAmazon Q Developer CLIの後継であり、生成されるテンプレートファイルとの互換性があります。

Steeringファイルの作成

ここからが本題です。Spec Kitのワークフローを定義したSteeringファイルを作成します。

プロジェクトのルートに.kiro/steering/ディレクトリを作成し、speckit-workflow.mdというファイルを配置します。

mkdir -p .kiro/steering

以下の内容でspeckit-workflow.mdを作成してください。

---
inclusion: always
---

# SpecKit Workflow Integration

## 概要
このプロジェクトは GitHub Spec Kit による Spec-Driven Development を使用しています。

## 基本原則
常に `.specify/memory/constitution.md` の原則に従ってください。

## ワークフロー

1. Constitution    ─ プロジェクトの基本原則を定義
2. Specify         ─ 機能仕様を作成（what と why）
3. [Clarify]       ← オプション：仕様の曖昧さを解消
4. Plan            ─ 技術計画を作成（how）
5. Tasks           ─ 実行可能なタスクに分解
6. [Analyze]       ← オプション：実装前の最終検証
7. Implement       ─ タスクを実装

※ [Checklist] はオプション。任意のタイミングで実行可能
  （主に Plan 後、ドメイン固有の品質検証に使用）

---

## トリガーワードとアクション

各トリガーワードが実行されたら、対応する `.amazonq/prompts/` のコマンドファイルを読み込み、その詳細なワークフローに従ってください。

| トリガー | 詳細ワークフロー |
|---------|-----------------|
| constitution | `.amazonq/prompts/speckit.constitution.md` |
| specify | `.amazonq/prompts/speckit.specify.md` |
| clarify | `.amazonq/prompts/speckit.clarify.md` |
| plan | `.amazonq/prompts/speckit.plan.md` |
| tasks | `.amazonq/prompts/speckit.tasks.md` |
| analyze | `.amazonq/prompts/speckit.analyze.md` |
| implement | `.amazonq/prompts/speckit.implement.md` |
| checklist | `.amazonq/prompts/speckit.checklist.md` |

---

## 注意事項

- すべての操作で `.specify/memory/constitution.md` の原則を最優先で遵守してください
- clarify は plan の前に実行することで手戻りを減らせます
- analyze は implement の直前に実行し、最終的な整合性を確認します

実際に使ってみる

ステップ1：Kiro CLIを起動する

プロジェクトのルートディレクトリで、Kiro CLIを起動します。

kiro-cli

Steeringファイルが正しく配置されていれば、KiroはSpec Kitのワークフローを理解した状態で起動します。

ステップ2：モデルを選択する

Kiro CLIのデフォルトはAutoモードで、タスクの複雑さに応じて最適なモデルが自動選択されます。しかし、Spec Kitのワークフローでは、仕様書の作成や技術計画の策定など、複雑な推論が必要なタスクが多いため、/modelコマンドでClaude Opus 4.5を選択することをお勧めします。

> /model

※この先のステップ7、実装フェーズ（implement）では仕様書やタスクリストが既に明確に定義されているため、Autoモードでも問題ありません。

ステップ3：Constitutionを作成する

最初に、プロジェクトの基本原則を定義します。「constitution」というトリガーワードを使って指示します。

> constitution このプロジェクトはTypeScriptで開発します。
> テストはVitestで書き、カバレッジ80%以上を目標とします。
> アクセシビリティを重視し、WCAG 2.1 AAに準拠します。

Kiroは、.specify/memory/constitution.mdを、指定された原則で更新します。

ステップ4：仕様書を作成する

次に、「specify」トリガーワードで機能の仕様書を作成します。

> specify todoリストアプリを作成したい。
> タスクの追加・編集・削除ができる。
> タスクには期限を設定でき、期限切れのタスクは色が変わる。
> 完了したタスクはチェックを入れて完了状態にできる。

Kiroは自動的に以下の処理を行います。

  1. .specify/memory/constitution.mdを読み込んで原則を確認
  2. .specify/scripts/bash/create-new-feature.shを実行してGitブランチとディレクトリを作成
  3. specs/001-todo-list/spec.mdに仕様書を生成

ステップ5：技術計画を作成する

仕様が固まったら、「plan」トリガーワードで技術計画を作成します。

> plan フロントエンドはReactとTypeScriptを使用する。
> 状態管理にはZustandを使用。
> データはブラウザのlocalStorageに保存する。

Kiroは、specs/001-todo-list/plan.mdに技術計画を、data-model.mdにデータモデルを生成します。

ステップ6：タスクに分解する

「tasks」トリガーワードで、実装タスクに分解します。

> tasks

引数なしで実行すると、Kiroは現在の仕様書と技術計画を読み込み、specs/001-todo-list/tasks.mdにタスクリストを生成します。

ステップ7：実装を開始する

最後に、「implement」トリガーワードで実装を開始します。

> implement

Kiroは、タスクリストに従って順番にコードを生成していきます。

※ステップ2でモデルを変更しましたが、コード実装フェーズでは、仕様書やタスクリストが既に明確に定義されているため、モデルは Auto に設定しても問題ありません。Autoモードではタスクの複雑さに応じて最適なモデルが自動選択されるため、コスト効率が良くなります。

オプション機能の活用

仕様の曖昧さを解消する（clarify）

仕様書を作成した後、「clarify」トリガーワードで曖昧な点を明確にできます。

> clarify

品質チェックリストを生成する（checklist）

「checklist」トリガーワードにドメインを指定して、品質チェックリストを生成できます。

> checklist ux

UXに関するチェックリストがspecs/001-todo-list/checklists/ux.mdに生成されます。

利用可能なドメインの例

  • ux - ユーザー体験
  • security - セキュリティ
  • testing - テスト
  • performance - パフォーマンス
  • accessibility - アクセシビリティ
  • api - API設計

一貫性を検証する（analyze）

実装前に「analyze」トリガーワードで、仕様書・技術計画・タスクリスト間の一貫性を検証できます。

> analyze

他のAIエージェントとの併用

Steeringファイルを追加しても、既存の.specifyディレクトリの構造には影響しません。Claude CodeやGitHub Copilotなど、他のAIエージェントと併用することも可能です。

成果物

以下のようなタスク管理ツールが完成しました。

まとめ

現時点でKiro CLIはSpec Kitとの統合には対応していませんが、Steering 機能を活用することで、Spec Kitの仕様駆動開発のワークフローを再現できます。

Kiro CLIはAWSサービスとの連携に強みがあるため、AWS環境での開発においては相性が良いと考えられます。

Spec KitをKiro CLIで使ってみたかったいう方は、ぜひ今回紹介した手法を試してみてください。

参考リンク

針生 泰有(執筆記事の一覧)

サーバーワークスで生成AIの活用推進を担当