📘 EARS記法とは？
EARS (Easy Approach to Requirements Syntax) は、要求仕様を自然言語で一貫して表現するための記法です。
複雑になりがちな要件定義を、テンプレートに沿って書くことで、曖昧さを減らし、読みやすく理解しやすい仕様書 を作ることができます。
基本的には、「いつ／どんな状態／どんな条件のときに、システムはどう振る舞うべきか」 を整理する形式です。
📑 EARS記法の5つの形式
EARSには、Webアプリ向け要件を整理する際に便利な5つの形式があります。
- 常時適用型 (Ubiquitous)：常に成立する要求
- イベント駆動型 (Event-driven)：ある出来事が起こったときの要求
- 状態依存型 (State-driven)：ある状態にある間の要求
- オプション機能型 (Optional feature)：特定の機能や条件がある場合のみ成立する要求
- 複合型 (Complex)：複数の条件を組み合わせた要求
以下で、形式ごとの書き方とWebアプリ向けの具体例を紹介します。
1. 常時適用型 (Ubiquitous)
常に成立する要求
形式
<システム> は <応答> しなければならない。
例
タスク管理アプリは、メイン画面にすべてのタスクを常に表示しなければならない。
2. イベント駆動型 (Event-driven)
ある出来事が起こったときの要求
形式
<トリガー> のとき、<システム> は <応答> しなければならない。
例
ユーザが「タスク追加」ボタンを押したとき、アプリは新しいタスク入力フォームを表示しなければならない。
3. 状態依存型 (State-driven)
ある状態にある間の要求
形式
<状態> の間、<システム> は <応答> しなければならない。
例
ユーザがカレンダービューを開いている間、アプリは日付に関連するタスクをハイライト表示しなければならない。
4. オプション機能型 (Optional feature)
特定の機能や条件がある場合のみ成立する要求
形式
<機能／条件> がある場合、<システム> は <応答> しなければならない。
例
タスクの優先度設定が有効になっている場合、アプリは高優先度タスクを自動で上部に表示しなければならない。
5. 複合型 (Complex)
複数の条件を組み合わせた要求
形式
<状態> の間、<トリガー> のとき、<システム> は <応答> しなければならない。
例
ユーザがタスク編集モードにいる間、保存ボタンを押したとき、アプリは変更内容をデータベースに保存しなければならない。
🤖 LLMとEARSの活用
LLM（大規模言語モデル）を使うと、Webアプリ向けのEARS記法から直接要件整理やコード生成の支援が可能です。
活用例
- 曖昧な要求をEARS形式に変換
「ユーザがタスクを編集できるようにしてほしい」
↓ LLMに変換
「ユーザが編集ボタンを押したとき、アプリはタスク編集フォームを表示しなければならない。」
- EARS形式からコード生成
要求：「ユーザが編集ボタンを押したとき、アプリはタスク編集フォームを表示しなければならない。」
↓ LLM
showEditTaskForm(taskId); // 擬似コード例
- 要件レビュー・修正
- 曖昧表現（「すぐに」「適切に」など）を検出
- EARS形式に従って明確化を提案
- 大量ユースケースの自動生成
- タスク管理アプリやWebアプリの要件をまとめて入力
- EARS形式の一覧やコードスケルトンを自動生成
📌 まとめ
EARS記法は、Webアプリの要件を整理するための軽量で明確な形式です。
LLMと組み合わせることで、
- 曖昧な要求を整理
- 一貫性チェック
- コード化まで支援
といった開発効率化が可能になります 🚀
要件定義から実装までAIでつなぐ、新しいWebアプリ開発スタイルに最適です。