AI new
仕様駆動開発IDE KiroとEARS について調べてみた
はじめに
こんにちは、ヨシです。今回は、Kiro に採用されている EARS という仕様の記法について気になったので調べてみました。 Kiro 自体は実務で利用してはいませんが、Kiro で採用されている考え方を理解することで最近流行っている仕様駆動開発の考え方を学べるとも思っています。
Kiro とは
AWSが開発している Kiro は AI エージェントを使った仕様駆動開発(spec driven development)を行うためのAI IDE (統合開発環境) です。
Kiro には大きく2つの概念があります。それが spec と hook です。
- spec (仕様): アプリケーション開発における機能の開発プロセスを形式化する構造化された成果物
- hook (フック): イベントに応じて、開発者が見落としがちなことや、作業中にバックグラウンドで完了する定型的作業を自動的に行う機能
Kiro はこの2つの概念を利用して、仕様駆動開発を行います。
spec の基盤となる3つの主要ファイル
Kiro の spec によって、プロダクトの要件と技術的な実装詳細とのギャップを埋めることで、開発の反復的作業を削減することができるようになるとのことです。
各仕様の基盤となるのは以下の3つの主要ファイルで、Kiro はインタラクティブにこれらを生成します。
requirements.md: ユーザーストーリーと受け入れ基準を構造化されたEARS表記法で記述design.md: 技術アーキテクチャ、シーケンス図、実装上の考慮事項などtasks.md: 個別かつ追跡可能なタスクを含む詳細な実装計画
例えば、プロジェクトで foo という機能を開発する際には以下のように spec として3つのファイルを後述のワークフローで段階的に定義し、これらのドキュメントを元にAIエージェントによる仕様駆動開発が行われます。
.
└── .kiro
└── specs
└── foo
├── design.md
├── requirements.md
└── tasks.md
ワークフロー
具体的な開発のワークフローは、以下のような開発フェーズを段階的に行っていくというものになります。 これによって、次のステップに進む前に各ステップが適切に完了することを保証できるようになっています。
- 要件フェーズ (Requirements Phase)
requirements.mdファイルを作成/編集 - デザインフェーズ (Design Phase)
design.mdファイルを作成/編集 - 実装計画 (Implementation Planning)
tasks.mdファイルを作成/編集 - 実行フェーズ (Execution Phase) タスクの完了時に進捗状況を追跡して、必要に応じてspecを更新および改良する
EARS とは
概要
Kiro の概要は以上となりますが、今回注目したいのは EARS 記法という要件の記述方法についてです。 要件フェーズで提議する requirements.md ファイルはこの EARS 記法で記述されたユーザーストーリーと受け入れ基準の形式で記述されています。
そもそも EARS とは Easy Approach to Requirements Syntax と呼ばれる記法で、明確でテスト可能な要件を記述するための構造化されたフォーマットを提供します。
具体的には以下のようなフォーマットで、条件やイベントの発生に伴い、システムがどのような振る舞いをするかを明確に記述することができます。
WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]
EARSにより以下のようないくつかのメリットがあります。
- 明確さ (Clarity): 明確な要件は理解しやすい
- テスト可能性 (Testability): 各要件はテストケースに直接変換できる
- 追跡可能性(Traceability): 個々の要件は実装を通じて追跡可能
- 完全性 (Completeness): この形式はすべての状況と行動について考えることを推奨する
詳細
EARSの歴史はロールス・ロイス社のAlistair Marvin氏とその同僚によって、ジェットエンジンの制御システムを開発する中で生まれ、2009年に初めて公開されました。
Alistair Marvin氏本人が書いたドキュメントからEARSのエッセンスをいくつか紹介したいと思います。
EARSによる要件には以下のようなものが必要であると規定されています。
- 0個以上の事前条件(precondition)
- 0個または1個のトリガー(trigger)
- 1個のシステム名(system name)
- 1個以上のシステム応答(system response)
これらの構成要素によって、以下のようなパターンで要件が生成できます。
汎用的な記法:
While <オプショナルな事前条件>, when <オプショナルなトリガー>, the <システム名> shall <システム応答>
ユビキタス要件:
When <トリガー>, the <システム名> shall <システム応答>
状態駆動要件:
While <事前条件>, the <システム名> shall <システム応答>
イベント駆動要件:
When <トリガー>, the <システム名> shall <システム応答>
オプショナルな機能要件:
Where <含まれる機能>, the <システム名> shall <システム応答>
望まない振る舞いの要件
if <トリガー>, then the <システム名> shall <システム応答>
より複雑な要件:
While <事前条件>, When <トリガー>, the <システム名> shall <システム応答>
詳細については、上記のALISTAIR MAVIN 氏によるドキュメントを参照してください。
終わり
Kiro とその中で採用されているEARSについて簡単に調べてみました。仕様駆動開発を行う上でのエッセンスとなる考え方をいくつか知ることができたと思います。Kiro 自体を利用しなくても、GitHub が出している Spec Kit などで仕様駆動開発ができるかと思いますので、次回ではそれを実際に使ってみた記事を出したい思います。
それでは!
参考資料
https://aws.amazon.com/jp/blogs/news/introducing-kiro/
