Kiroのスペック、フック、ステアリングをITパスポートの知識で学んでみよう
Kiro
AWSがKiroを発表してからCursorやClaude Codeにスペックやフックに似たコンテキストを追加する手法が増えつつあります。
しかしながらKiroの仕様駆動開発はSIerがやっているウォーターフォールモデルとさほど変わりないので、新たにオレオレコンテキストエンジニアリングを発明するよりITパスポートでやるような共通フレームにあてはめて考えたほうがしっくりきます。
そこで今回はITパスポートなどで紹介されているソフトウェアライフサイクルを元に、Kiroの何がどれに該当するのか整理していきたいと思います。
ソフトウェアライフサイクル
ソフトウェアライフサイクルは、一般的に以下のフェーズで構成されます。
各フェーズで作成される文書や成果物も決まっています。
- 企画 (Planning)
- 要件定義 (Requirements Definition)
- 開発 (Development)
- 運用・保守 (Operations & Maintenance)
今までのコーディングエージェントは開発の実装とテストを主にやってくれるものでしたが、Kiroは要件定義と開発の設計からはじめくれるのが画期的でした。
現時点で運用・保守に関する作業をKiroはやってくれませんが、そもそもAWSはデプロイや運用・保守をオンプレとは比べ物にならないほど強力なものにしてシェアを獲得していったので、今後のアップデートでAWSのAIOpsと連携されるか期待したいところです。
企画や契約・合意に必要な資料を生成AIで生成する動きはコーディングエージェント以前からあったと思うので、別にコーディングエージェントに含める必要性もない気がします。
ただ一応Kiroには仕様駆動開発を行えるだけではなく、フックやステアリングと呼ばれる機能があるので、これを使えば企画に必要な構想・計画、運用・保守に必要なデプロイもKiroで自動化できそうな気がします。
何にせよ、Kiroの仕様駆動開発は要件定義と開発の全てを生成AIがやってくれるツールであり、企画や運用・保守の連携については今後ゆっくり考えていけばいいでしょう。
要件定義
システム要件定義・ソフトウェア要件定義では主に機能要件と非機能要件を定義します。
- 機能要件 (Functional Requirements)
ソフトウェアが「何をするか」を定義する、システムの機能や振る舞いに関する要件です。 - 非機能要件 (Non-functional Requirements)
機能以外の、システムの品質や制約に関する要件です。「どのように動くか」を定義します。
これらの要件をまとめた書類のことを要件定義書と言います。
Kiroはrequirements.mdファイルを使用して生成します。
また、非機能要件ではISO/IEC 25010で定義された、ソフトウェア製品品質の8つの特性に着目するとより良いものができます。
- 機能適合性 (Functional Suitability)
- 性能効率性 (Performance Efficiency)
- 互換性 (Compatibility)
- 使用性 (Usability)
- 信頼性 (Reliability)
- セキュリティ (Security)
- 保守性 (Maintainability)
- 移植性 (Portability)
設計
続いては要件定義書をもとに設計書を作成します。
システム設計・ソフトウェア設計では主に方式設計、機能設計、詳細設計の設計図をER図やUMLで作成します。
- 方式設計
システムの骨格となる技術（OS、プログラミング言語など）を設計する - 機能設計、基本設計（外部設計）
ユーザーから見える部分（画面、帳票など）やシステムの構成を設計する - 詳細設計（内部設計、プログラム設計）
AIが見る部分（プログラムの構造、処理の流れなど）を具体的に設計する
Kiroではdesign.mdファイルを使用して生成します。
ER図やUMLはMermaidで作成してくれます。
MermaidではER図の他に、以下のようなUMLを作成することができます。
- クラス図（構造）
- アクティビティ図、フローチャート（振る舞い）
- シーケンス図（相互作用）
また、プログラミング言語によっては構造化手法やオブジェクト指向に関するコードブロックを生成してくれます。
実装
Kiroは設計書に基づいて、プログラミング言語を使用し自動的にコーディングを行ってくれます。
これは通常のコーディングエージェントとさほど変わりなく、タスクをサブタスクに分割したものをtasks.mdファイルとして生成し実行してくれます。
テスト
作成したプログラムが設計通りに、また要件通りに動作するかを検証します。
Kiroは単体テストと統合テストをtasks.mdファイルにタスクとして生成してくれます。
- 単体テスト (Unit Test)
詳細設計通りに動作するか、小さな部品（モジュール）ごとに行うテストです。 - 統合テスト、結合テスト (Integration Test)
機能設計通りに動作するか、部品を組み合わせたときに行うテストです。 - システムテスト (System Test)
要件定義通りに動作するか、システム全体として要件を満たしているかを確認するテストです。 - 受入れテスト、運用テスト (Acceptance Test)
利用者マニュアルを確認しながら、完成したシステムが実際の業務で利用できるか最終判断するテストです。
システムテストと受入れテストをKiroで行うことは難しいですが、利用者マニュアルの作成やテストに必要なデプロイはエージェントフックを使用することで自動化できます。
また、テストにはホワイトボックステストとブラックボックステストがあります。
- ホワイトボックステスト
内部構造を考慮して、ロジックが正しく作られているかをテストします。
単体テスト、統合テストで行います。 - ブラックボックステスト
内部構造を考慮せず、仕様書通りに機能するかをテストします。
統合テスト、システムテスト、受入れテストで行います。
ステアリングルール
Kiroではオレオレコンテキストエンジニアリングを行えるようエージェントステアリングと呼ばれるコンテキストファイル管理機能を搭載しています。
Kiroはプロジェクトの核となるコンテキストを設定するための、3つの基礎ファイルを自動で作成します。
product.mdには製品概要 (Product Overview) を記載できます。
製品の目的、ターゲットユーザー、主要な機能、ビジネス上の目標を定義します。
これにより、Kiroは技術的な意思決定の背景にある「なぜ」を理解し、製品の目標に沿った解決策を提案できるようになります。
tech.mdには技術スタック (Technology Stack) を記載できます。
選択したフレームワーク、ライブラリ、開発ツール、技術的な制約を記述します。
Kiroが実装を提案する際、代替案よりもここで定義されたスタックを優先するようになります。
structure.mdにはプロジェクト構成 (Project Structure) を記載できます。
ファイルの構成、命名規則、インポートのパターン、アーキテクチャに関する決定事項を概説します。
これにより、生成されたコードが既存のコードベースにシームレスに適合するようになります。
これらを使用することで要件定義や開発だけでなく、企画や運用・保守に必要な情報も補完することができます。
Computer AIded Software Engineering
KiroはVS CodeやCursorと何が違うのか記事を書く前まではあまり理解できていませんでしたが、ITパスポートの資料を調べていくうちに思いました。
これは統合CASEツールではないだろうか？
Gemini 2.5 Pro:
### 1. CASEツールとは？【一言で言うと】
**ソフトウェアの開発工程全体（企画、設計、実装、テスト、保守）を、コンピュータ（専用のソフトウェア）を使って支援し、生産性や品質を向上させるためのツールの総称**です。
人間が手作業で行っていた、あるいは行いにくかった作業をコンピュータに肩代わりさせることで、開発をより効率的かつ高品質に進めることを目的とします。
### 2. CASEツールが支援する主な開発工程と機能
CASEツールは、ソフトウェア開発のライフサイクルの様々な段階で活用されます。
#### ① 企画・要件定義フェーズ
* **要求分析支援:** 顧客の要求を整理し、矛盾がないかチェックする。
* **モデリング支援:** 要求を図やモデルで可視化する。
#### ② 設計フェーズ（上流工程）
* **設計情報の管理:** 設計書を一元管理し、変更履歴などを追跡する。
* **ダイアグラム作成支援:**
* **UML**（統一モデリング言語）：クラス図、シーケンス図など
* **DFD**（データフロー図）：データの流れ
* **ER図**（実体関連図）：データベースの構造
などの図を簡単に作成・編集し、図同士の整合性をチェックする。
* **リポジトリ機能:** 設計情報をデータベース（リポジトリ）に格納し、チーム内で共有したり、後工程で利用したりする。
#### ③ 実装（プログラミング）フェーズ（下流工程）
* **ソースコード自動生成:** 設計情報（例：UMLのクラス図）から、プログラムの雛形となるソースコードを自動で生成する。
* **リバースエンジニアリング:** 既存のソースコードを解析して、設計図（UMLなど）を自動生成する。
#### ④ テストフェーズ
* **テストケース自動生成:** 設計情報からテスト項目やテストデータを自動で生成する。
* **テスト実行・管理支援:** テストの実行を自動化し、結果を記録・管理する。
#### ⑤ 運用・保守フェーズ
* **ドキュメント自動生成:** 設計情報やソースコードから、仕様書やマニュアルなどのドキュメントを自動で生成する。
* **影響範囲分析:** ある部分のコードや設計を変更した場合に、どの部分に影響が及ぶかを分析する。
### 3. CASEツールの分類
CASEツールは、支援する工程によって大きく3つに分類されます。
| 分類 | 支援する工程 | 主な機能 | 特徴 |
| :--- | :--- | :--- | :--- |
| **上流CASE (Upper CASE)** | 企画、要件定義、設計 | UMLなどのモデリング支援、設計情報管理 | 開発の初期段階（上流工程）に特化。システムの全体像を固めるのに役立つ。 |
| **下流CASE (Lower CASE)** | 実装、テスト | ソースコード生成、テスト自動化、デバッグ支援 | 開発の後期段階（下流工程）に特化。プログラマやテスターの作業を効率化する。 |
| **統合CASE (Integrated CASE)** | 開発工程全体 | 上流・下流の両方の機能を持ち、連携させる | 上流工程で作成した設計情報が、下流工程のコード生成やテストに一貫して利用できる。理想的だが、高価で複雑になりやすい。 |
### 4. CASEツール導入のメリットとデメリット
#### メリット
* **生産性の向上:** コードやドキュメントの自動生成により、開発時間を短縮できる。
* **品質の向上:** 設計の矛盾チェックや標準化により、人為的なミス（ヒューマンエラー）を減らせる。
* **開発の標準化:** ツールを使うことで、チーム内の設計手法や表記法が統一され、属人化を防ぐ。
* **保守性の向上:** 設計書と実装の一貫性が保たれやすく、仕様変更時の影響範囲の特定も容易になるため、メンテナンスがしやすくなる。
#### デメリット
* **導入・学習コスト:** ツール自体が高価な場合が多く、使い方を習得するための時間とコストがかかる。
* **過剰な設計（Over-engineering）:** ツールに合わせるあまり、必要以上に詳細で複雑な設計をしてしまうことがある。
* **柔軟性の欠如:** ツールの制約により、特定の開発手法や言語しか使えず、柔軟な対応が難しい場合がある。
### 5. 現在のCASEツール
「CASEツール」という言葉は1980年代～90年代に流行しましたが、現在ではその概念がより専門的・複合的なツール群に受け継がれています。
* **IDE（統合開発環境）:** Visual Studio CodeやIntelliJ IDEAなどは、コーディング支援やデバッグ機能を持っており、下流CASEの役割を担っています。
* **UMLモデリングツール:** Astah*, Enterprise Architectなどは、上流CASEの代表例です。
* **CI/CDツール:** Jenkins, GitHub Actionsなどは、ビルドやテストの自動化を担い、下流CASEの役割を発展させたものと言えます。
* **プロジェクト管理ツール:** Jira, Redmine, Backlogなどは、要件やタスクの管理を支援します。
* **ローコード/ノーコード開発プラットフォーム:** これらは究極のCASEツールとも言え、設計から実装、デプロイまでを高度に自動化します。
現在では、一つの巨大な「統合CASEツール」を導入するよりも、Git（バージョン管理）、Jira（タスク管理）、VS Code（IDE）、Jenkins（CI/CD）といった**複数の専門ツールを連携させる（ツールチェーン）**アプローチが主流になっています。しかし、その根底にある「コンピュータの力で開発を支援する」というCASEの思想は、今もなおソフトウェア開発の中心にあり続けています。
今まで実装、テストといった下流CASEでしかできなかったコーディングエージェントに、企画、要件定義、設計といった上流CASEの機能を加え、VS Codeのようなシンプルな使いやすさと、生成AIによって導入・学習コストを下げることで誰でも簡単に導入でき、しかも現時点では無料で使えるという、CursorやClaude Codeでも実現できなかったことを実現できたことが大きな話題を呼んだように思えます。
今後もソフトウェアライフサイクルのような基礎教養を学びつつ、CASE 2.0と呼ぶにふさわしいKiroの動向に注目していきたいところです。
参照
試験要綱Ver.5.4
「ITパスポート試験」シラバス（Ver.6.4）
分野別過去問題 ストラテジ系｜ITパスポート試験ドットコム
分野別過去問題 マネジメント系｜ITパスポート試験ドットコム
主に以下の分類を参照しました。
- 大分類 3：システム戦略
- 中分類 7：システム企画
- 小分類 22：システム化計画
- 小分類 23：要件定義
- 小分類 24：調達計画・実施
- 中分類 7：システム企画
- 大分類 4：開発技術
- 中分類 8：システム開発技術
- 小分類 25：システム開発技術
- 中分類 8：システム開発技術
Discussion