要件の曖昧さを構文ルールで排除するEARS記法の基本定義と誕生経緯

要件の曖昧さを構文ルールで排除するEARS記法の基本定義と誕生経緯

ソフトウェア開発やシステム開発のプロジェクトにおいて、要件定義は最も重要な工程のひとつです。しかし、自然言語で記述された要件は書き手によって表現が異なり、読み手の解釈にもばらつきが生じます。こうした曖昧さが原因で手戻りや仕様の誤認が頻発し、プロジェクトの遅延やコスト超過を招くケースは後を絶ちません。EARS記法は、この問題に対して「構文のルール化」というアプローチで立ち向かう手法です。本章では、EARS記法がどのような経緯で生まれ、何を解決するために設計されたのかを解説します。

ロールス・ロイス社が2009年に提案した制御付き自然言語の設計思想

EARS（Easy Approach to Requirements Syntax）は、イギリスのロールス・ロイス社に所属していたアリスター・メイビン氏らによって考案された要件記述のテンプレート手法です。航空エンジンの制御システムという、わずかな仕様の誤認が重大事故に直結する領域で開発されました。メイビン氏らが目指したのは、要件定義の専門家でなくても一貫性のある仕様を書ける仕組みの構築です。

EARS記法の核心は「制御付き自然言語」という考え方にあります。完全な形式言語のように厳密な文法を強いるのではなく、自然言語の読みやすさを維持しながら、キーワードと語順を固定することで曖昧さを排除します。具体的には、When・While・If・Whereといった少数のキーワードと「shall」という義務表現を組み合わせることで、誰が書いても似た構造の要件文が生まれる設計です。この「構文の自由度をあえて絞り込む」という発想が、レビュー効率の向上とトレーサビリティの確保を同時に実現しています。

自由記述の要件定義で発生する曖昧性・検証不能性という2大課題

EARS記法が解決しようとする問題は、大きく分けて「曖昧性」と「検証不能性」の2つです。自由記述で書かれた要件には、文脈に依存した表現や余計な修飾語が混在しやすく、開発者・テスト担当者・発注者の間で解釈のずれが発生します。たとえば「システムは迅速に応答すること」という要件では、「迅速」が1秒なのか5秒なのかが不明であり、テストケースの作成もできません。こうした曖昧な表現は、プロジェクトの後半になってから問題が顕在化し、大規模な手戻りを引き起こす原因になります。

検証不能性とは、記述された要件が正しく実装されたかどうかをテストで確認できない状態を指します。主語が曖昧な文や、条件が省略された文は、何をもって「合格」とするかの基準を設定できません。EARS記法では、構文パターンに従うことで主語・条件・動作が必ず明示される仕組みになっているため、記述した時点でテスト可能な要件が自然に生まれます。この特性こそが、要件品質を構造的に底上げする最大の強みといえます。

When・While・If・Whereの4キーワードで語順を固定する基本原則

EARS記法では、要件文の冒頭に置くキーワードによって要求のタイプが決まります。Whenは特定のイベント発生時、Whileは特定の状態が継続している間、Ifはエラーや例外の発生時、Whereは特定の機能やハードウェアが存在する場合を示します。これらのキーワードを文頭に配置し、続いてシステム名、shallによる義務表現、期待される応答という順序で記述するのが基本ルールです。

語順を固定する最大の利点は、レビュアーが要件文を高速に読み解ける点にあります。どの要件も同じ構造で並ぶため、条件部分と動作部分の区別が一目で判断でき、条件の漏れや矛盾の発見が容易になります。また、キーワードを持たない要件は「常時成立する要求（Ubiquitous型）」として分類されるため、すべての要件がいずれかのパターンに属する体系的な管理が可能です。この一貫性が、大規模プロジェクトでの要件管理を支える土台となっています。

「shall」を軸にした義務表現の統一ルールと主語明示の重要性

EARS記法では、システムが実行すべき動作を記述する際に「shall」という助動詞を統一的に使用します。英語圏の要件定義では「shall」は「〜しなければならない」という義務を表す標準的な表現であり、「should（〜すべき）」や「may（〜してもよい）」との区別を明確にします。日本語で運用する場合は「〜する必要がある」「〜しなければならない」に統一することで同等の効果が得られます。

主語の明示もEARS記法の重要な原則です。自由記述の要件では「ログイン画面を表示する」のように主語が省略されるケースが多く、その動作を実行する主体がフロントエンドなのかバックエンドなのかが不明確になります。EARS記法では「the [システム名] shall [動作]」という構文を守ることで、どのコンポーネントが責任を持つかが必ず記録されます。この主語と義務表現の組み合わせにより、要件の責任範囲が自動的に明確化される仕組みです。

IEEE RE2009で発表された原論文とBIG EARS拡張への発展経緯

EARS記法が学術的に公開されたのは、2009年に開催されたIEEE International Requirements Engineering Conference（RE2009）です。メイビン氏らはこの場で「Easy Approach to Requirements Syntax」と題した論文を発表し、5つの基本構文パターンを提案しました。この論文は要件工学の実務者から高い評価を受け、ロールス・ロイス社内だけでなくインテルをはじめとする複数のグローバル企業で採用が進みました。

翌年のRE2010では「BIG EARS」と題した続編論文が発表されています。BIG EARSでは、複数の要件文書に対してEARSテンプレートを適用する広範な実験が報告され、テンプレートの洗練や既知の制限への対処が行われました。さらに近年では、AWSが開発したエージェント型IDE「Kiro」がEARS記法を仕様駆動開発の中核に採用したことで、AI時代の要件定義手法として再び注目を集めています。2009年の提案から15年以上を経てもなお進化を続けている点が、EARS記法の実用性の高さを証明しています。

開発現場で使い分ける6つの要求パターンとテンプレート構文の全体設計

EARS記法の実用性を支えているのは、5つの基本パターンとその組み合わせであるComplex型ですべての要件を分類できるシンプルな体系です。各パターンにはテンプレート構文が定められており、開発者はパターンを選んでキーワードを埋めるだけで、構造化された要件文を作成できます。本章では各パターンの構文・使い分けの基準・実務での注意点を具体例とともに解説します。

条件なしで常時成立する要求を記述するUbiquitous型の構文と適用例

Ubiquitous型は、EARSの基本パターンのうち最もシンプルな形式です。特定の条件やイベントに依存せず、システムが常に満たすべき要求を記述します。構文は「The [システム名] shall [応答]」であり、When・While・Ifなどのキーワードを一切使用しません。たとえば「制御システムは燃料残量を常時表示する必要がある」や「システムはパスワードを平文で保存してはならない」がこの型に該当します。

Ubiquitous型を適用すべき場面は、セキュリティ要件・パフォーマンス要件・データ保持ルールなど、システムの稼働中に例外なく維持されるべき制約条件です。注意点として、あらゆる要件をUbiquitous型に分類してしまうと、本来は条件付きであるべき要件の条件部分が省略されるリスクがあります。「常に成立する」という判断は慎重に行い、少しでも条件が考えられる場合はEvent-driven型やState-driven型への分類を検討すべきです。

特定のトリガー発生時に動作を定義するEvent-driven型の判断基準

Event-driven型は、特定のイベントやトリガーが発生した際にシステムが実行すべき動作を記述するパターンです。構文は「When [イベント], the [システム名] shall [応答]」となります。たとえば「When 抽出ボタンが押された時、本機はコーヒーの抽出を開始しなければならない」のように、トリガーとなる出来事と期待される動作を1対1で対応させます。

このパターンの判断基準は「一時的な出来事であるかどうか」です。ボタン押下・データ受信・タイマー満了など、発生と終了が明確な事象はEvent-driven型に分類します。一方で「ネットワークに接続している間」のように継続的な状態を条件とする場合はState-driven型を使います。実務でよくある間違いは、状態条件をイベントとして記述してしまうケースです。「When ネットワーク接続中」という記述は、Whenの本来の意味である「〜が起きたとき」と矛盾するため、「While ネットワーク接続中」に修正する必要があります。

システムが特定状態にある間だけ有効なState-driven型の記述ポイント

State-driven型は、システムやその環境が特定の状態にある間に適用される要求を定義します。構文は「While [状態], the [システム名] shall [応答]」です。たとえば「While クリーニングモードの間、本機は抽出ボタンの操作を無効化しなければならない」や「自動車が走行状態にある限り、制御システムはエンジンに燃料を供給する必要がある」がこのパターンに該当します。

State-driven型の記述で最も重要なポイントは、状態の開始条件と終了条件を明確に定義することです。「メンテナンスモード中」という状態を前提にする場合、そのモードに入る条件と抜ける条件が別の要件として定義されていなければ、実装段階で解釈のずれが発生します。また、1つの要件文に複数の状態条件を記述すると可読性が下がるため、状態が2つ以上重なる場合はComplex型（複合型）の使用を検討すべきです。状態の定義が曖昧なまま記述すると、EARS記法の構文に従っていても実質的に検証不能な要件が生まれてしまいます。

エラーや異常系に対処するUnwanted Behavior型で陥りやすい条件漏れ

Unwanted Behavior型は、不測の事態やエラー発生時にシステムが取るべき対応を記述するパターンです。構文は「If [不測の事態], the [システム名] shall [応答]」となります。たとえば「If 水タンクが空であるなら、本機は警告ランプを点滅させなければならない」がこの型の典型例です。フェイルセーフ要件やエラーハンドリングの記述に適しており、安全関連規格との親和性が高い特徴があります。

しかし、このパターンは条件漏れが最も発生しやすい型でもあります。有名な例として、「車両が静止している間、システムはエアバッグを展開してはならない」という要件があります。この記述はエアバッグの誤展開防止を意図していますが、停車中に追突された場合にもエアバッグが展開しなくなるという致命的な問題を含んでいます。Unwanted Behavior型を使う際は、記述した条件が他の正常系要件と矛盾しないかを必ずクロスチェックする必要があります。否定形の要件は特に見落としが起きやすいため、レビュー工程で重点的に確認すべき対象です。

オプション機能と複合条件を扱うOptional型・Complex型の使い分け

Optional型は、特定の機能やハードウェアが搭載されている場合にのみ適用される要件を記述します。構文は「Where [機能/構成], the [システム名] shall [応答]」です。たとえば「自動車がABS装置を持つなら、自動車は横滑りしないように制御する必要がある」のように、オプション装備や拡張機能に紐づく要件に使用します。全車種共通の要件と特定グレード限定の要件を明確に区別できるため、製品ラインナップが多い製造業で特に重宝されます。

Complex型は、基本パターンの構成要素を組み合わせて複合条件を表現する形式です。When（イベント）とWhile（状態）を組み合わせ、「While [状態] かつ When [イベント], the [システム名] shall [応答]」の形式で記述します。自動運転システムを例にすると、「車両が時速60km以上で走行しており、車線維持支援が有効なとき、システムは自動的にハンドルを補正する」のように、時間的条件と状態的条件を同時に指定できます。単一パターンでは表現しきれない複雑な要件を扱う場合にComplex型を選択しますが、1文に条件を詰め込みすぎると可読性が低下するため、条件が3つ以上になる場合は要件を分割することを推奨します。

自由記述やUSDMとの比較で見えるEARS記法の差別化ポイントと適用条件

要件定義の手法はEARS記法だけではありません。自由記述、USDM（Universal Specification Describing Manner）、Gherkin記法など、プロジェクトの特性に応じてさまざまなアプローチが存在します。本章では、これらの手法とEARS記法を多角的に比較し、どのような条件下でEARS記法が最も効果を発揮するかを明確にします。

自由記述・EARS・USDMの3手法を構造化レベルで比較した整理表

要件定義の手法を選択する際に最も重要な判断軸は「構造化の度合い」と「学習コスト」のバランスです。自由記述は制約がないため書きやすい反面、品質が書き手のスキルに依存します。USDMは要求・理由・説明・仕様の4要素で要件を整理する日本発の手法であり、なぜその要件が必要かという根拠まで記録できる点が強みです。EARS記法はその中間に位置し、構文テンプレートによって最低限の品質を担保しつつ、自然言語の柔軟性も維持しています。

このように、EARS記法はテスト可能性の高さと学習コストの低さを両立しています。ただし要件の根拠や背景情報を記録する仕組みは持たないため、USDMの理由・説明に相当する情報が必要な場合は併用を検討すべきです。

Gherkin記法のGiven-When-Thenと構文設計が異なる3つの観点

EARS記法としばしば比較される手法にGherkin記法があります。GherkinはBDD（振る舞い駆動開発）で使われる記法で、「Given [前提条件], When [操作], Then [期待結果]」という3パートで受け入れ条件を記述します。構文にキーワードを使う点はEARS記法と共通していますが、設計思想には明確な違いがあります。

第一に、EARS記法はシステムの「義務」を定義するのに対し、Gherkinはユーザーの「振る舞い」を記述します。第二に、EARS記法は要件定義フェーズで使用することを前提としているのに対し、Gherkinはテストシナリオの記述が主な用途です。第三に、EARS記法はパターン分類によって要件の網羅性を確認できますが、Gherkinにはそうした分類体系がありません。両者は競合ではなく補完関係にあり、EARS記法で定義した要件をGherkin形式のテストシナリオに変換するという運用が実務では効果的です。

非ネイティブでも数時間で習得できる学習コストの低さという競争優位

EARS記法の大きな競争優位のひとつは、学習コストの圧倒的な低さです。使用するキーワードはWhen・While・If・Where・shallの5つが中心であり、英文法の基礎知識があれば構文ルールを理解できます。実際に、非英語圏の企業でも数時間のワークショップでチーム全体がEARS記法を習得したという事例が複数報告されています。

この低い学習ハードルは、発注者やビジネスアナリストなど要件定義の専門家ではないステークホルダーの参加を促進します。従来は技術者だけが記述していた要件を、ビジネス側のメンバーもEARS記法で記述・レビューできるようになることで、技術系と非技術系の間のコミュニケーションギャップが縮小します。形式手法のように高度な数学的知識を必要としない点も、現場への導入障壁を下げる要因です。要件定義に特化した研修を長期間実施する余裕がないプロジェクトほど、EARS記法の即効性が活きてきます。

組込み系・安全規格対応に強くWebアプリ要件にも適用可能な汎用性

EARS記法はもともと航空エンジンの制御システムという組込み系・安全系の領域で生まれた手法ですが、その適用範囲は年々拡大しています。インテルでは2010年に既存の要求エンジニアリング研修にEARS記法を統合し、半導体設計の要件定義に活用しています。自動車業界ではAutomotive SPICE 4.0の要件記述手法としてEARSが推奨される場面も増えています。

近年ではWebアプリケーションの要件定義にもEARS記法が適用されるケースが出てきました。AWSのKiroがEARS記法をToDoアプリやレビュー機能の要件定義に採用したことで、組込み系以外の開発者にも認知が広がっています。Webアプリ向けに適用する場合は、Ubiquitous型をセキュリティ要件に、Event-driven型をユーザー操作への応答に、State-driven型をセッション管理に対応させるといった読み替えが有効です。ドメインを問わず適用できる汎用性が、EARS記法の将来性を支えています。

要件の粒度が粗すぎる場合にEARS記法だけでは補えない限界と補完策

EARS記法は構文テンプレートによって「書き方」を標準化する手法であり、「何を書くか」という要件の中身そのものを保証する仕組みではありません。したがって、要件の粒度が粗すぎる場合や、ビジネス要件からシステム要件への分解が不十分な場合は、EARS記法に従って書いても実装に使える有用な要件にはなりません。記述フォーマットの整備だけでは上流工程の分析不足を補うことはできないのです。

この限界を補う方法は複数あります。まず、USDMの理由・説明要素を併用して要件の背景と根拠を記録する手法です。EARS記法で「何をすべきか」を記述し、USDMの構造で「なぜそうすべきか」を補完すれば、要件の妥当性を第三者が検証しやすくなります。次に、要件分解のプロセス自体をIEEE 29148やISO/IEC 25010といった国際規格に沿って実施し、粒度の基準を明確にする方法があります。EARS記法はあくまで記述フォーマットであるため、上流の分析・分解プロセスとセットで運用することが成功の前提条件です。

レビュー効率と手戻り削減を実現するEARS記法導入の実務メリットと限界

EARS記法を導入する最大の動機は、要件レビューの効率化と手戻りの削減です。しかし、導入効果を正しく評価するためには、メリットだけでなく構造的な限界も理解しておく必要があります。本章では、EARS記法がもたらす具体的な実務メリットを検証するとともに、形式だけでは解決できない課題についても正直に整理します。

レビュー速度が向上する理由は構文パターンによる読解負荷の均一化

EARS記法を導入した現場で最初に実感される効果は、要件レビューの速度向上です。自由記述の要件書では、レビュアーは1件ごとに文章構造を読み解き、主語・条件・動作を頭の中で分解する必要があります。文体や表現が書き手によって異なるため、読解に要する認知負荷が高く、レビューの所要時間が長くなりがちです。特に要件数が数百件を超えるプロジェクトでは、レビュアーの疲労による見落としリスクも無視できません。

EARS記法では、すべての要件が同じ構文パターンに従うため、レビュアーの読解負荷が均一化されます。When・While・Ifといったキーワードが文頭にあることで、条件部分と動作部分の境界が一目で判別でき、「この要件にはどの条件が設定されているか」「条件の漏れはないか」を機械的に確認できます。実際にEARS記法を導入した組織では、レビュー工数の削減や指摘精度の向上が報告されており、構文の標準化がレビュー品質の底上げに直結する好例となっています。

テスト可能な要件が構文に従うだけで自然に生まれる検証可能性の仕組み

EARS記法のもうひとつの大きなメリットは、テスト可能な要件が構文に従うだけで自然に生成される点です。Event-driven型であれば「When [トリガー]」が明示されるため、テストケースでは「そのトリガーを発生させて、期待される応答が返ることを確認する」という検証手順が自動的に導出されます。State-driven型であれば、「While [状態]」を再現した環境でのテスト実行が必要であることが明確です。

ISO/IEC/IEEE 29148では、優れた要件の品質属性として「曖昧でないこと」「完全性」「単一性」「検証可能性」「適合性」が挙げられています。EARS記法の構文テンプレートは、これらの品質属性のうち特に「検証可能性」と「曖昧でないこと」に強い正の影響を与えることが研究で示されています。テスト設計者にとっては、EARS形式で記述された要件を受け取った時点で、テスト戦略の大枠が見えるという実務的な利点があります。

トレーサビリティ向上で上位要件との整合性確認工数を削減できる根拠

トレーサビリティとは、要件がどの上位目標から導出され、どの設計・実装・テストに紐づいているかを追跡できる状態を指します。EARS記法は各要件が独立した1文として完結するため、要件IDとの1対1対応が容易です。自由記述のように1つの段落に複数の要件が混在する状態を避けられるため、要件管理ツールへの登録や変更影響分析の精度が向上します。

Automotive SPICEやISO 26262といった安全規格では、要件のトレーサビリティが監査対象となります。EARS記法で記述された要件は構文パターンが統一されているため、上位要件から下位要件への展開が漏れていないかを機械的にチェックしやすい構造を持っています。ツールによる自動検証との親和性も高く、要件数が数百件を超える大規模プロジェクトでは、整合性確認の工数削減効果が特に顕著です。トレーサビリティの確保は単なる書類作業ではなく、変更管理と品質保証の基盤であるため、EARS記法の構造的な強みが発揮される領域といえます。

形式を守っても内容の妥当性は保証されないというEARS記法の構造的な制約

EARS記法の導入にあたって必ず理解しておくべき制約は、「形式を守ること」と「内容が正しいこと」はまったく別の問題であるという点です。EARS記法はあくまで記述のフォーマットを標準化する手法であり、記述された要件の内容が技術的に正しいか、ビジネス要件と整合しているかまでは保証しません。

たとえば、「When ユーザーがログインした時、システムは全データを削除しなければならない」という要件はEARS記法の構文としては完全に正しいですが、内容としては明らかに不適切です。構文チェックだけでは検出できないこの種の問題を防ぐためには、ドメイン知識を持つレビュアーによる内容レビューが不可欠です。EARS記法は「最低限の品質を構文で担保する」ためのツールであり、内容の妥当性判断は人間の専門知識に委ねる必要があります。この点を誤解すると、形式的に整っているだけで実質的には役に立たない要件書が生産されるリスクがあります。

Automotive SPICE 4.0やISO 29148など品質規格との高い親和性

EARS記法が品質規格との親和性に優れている理由は、規格が求める要件品質属性とEARS記法が自然に生み出す要件の特性が一致しているためです。ISO/IEC/IEEE 29148は要件の品質として「曖昧でないこと」「検証可能であること」「一貫性があること」などを要求していますが、EARS記法の構文テンプレートはこれらの属性を構造的に満たす設計になっています。

Automotive SPICE 4.0では、プロセス評価においてシステム要件の品質が重要な評価項目となっています。EARSのような構造化記法を採用していることは、アセッサーに対して「組織として要件品質の標準化に取り組んでいる」ことの客観的な根拠になります。また、航空宇宙分野のDO-178CやDO-254、医療機器のIEC 62304など、安全性が最重要視される規格でも、EARS記法と同様のアプローチが推奨されるケースが増えています。規格準拠を求められるプロジェクトでは、EARS記法の採用がコンプライアンス対応のコスト削減にも寄与します。

業務システムから安全系まで対応するEARS記法の具体的な書き方と実例集

EARS記法の理論を理解した次のステップは、実際の要件を書いてみることです。しかし、パターンの選択基準や条件の粒度設定は、具体例を見なければ感覚がつかめません。本章では、業務システムから安全系まで幅広いドメインの要件を題材に、EARS記法の実践的な書き方を解説します。

ログイン認証機能を5つの構文パターンで書き分ける実装前の要件例

ひとつの機能を複数のEARSパターンで記述することで、要件の網羅性を高める方法を紹介します。ログイン認証機能を題材に、5つの構文パターンを使い分けた要件例を示します。まず、Ubiquitous型では「システムはパスワードを平文で保存してはならない」と記述します。これは条件を問わず常時適用されるセキュリティ要件です。

Event-driven型では「When ユーザーが正しい認証情報を入力した時、システムはダッシュボード画面を表示しなければならない」と記述します。Unwanted Behavior型では「If 10回連続でログインに失敗した場合、システムは当該アカウントを15分間ロックしなければならない」と定義します。State-driven型では「While アカウントがロック状態の間、システムはログイン試行を受け付けてはならない」と記述し、Optional型では「Where 二要素認証機能が有効な場合、システムはパスワード認証後にワンタイムコードの入力を要求しなければならない」と定義します。このように1つの機能に対して複数のパターンを適用することで、正常系・異常系・状態制約・オプション機能を漏れなくカバーできます。

自動運転システムにおける複合型要件をWhen＋Whileで定義する手順

安全系システムでは、単一の条件だけでは要件を十分に定義できないケースが頻繁に発生します。自動運転システムを例に、Complex型（When＋While）の記述手順を解説します。まず、要件の対象となる動作を特定します。ここでは「車線維持支援のハンドル自動補正」を対象とします。

1. 対象動作を明確にする：「システムは自動的にハンドルを補正する」
2. イベント条件（When）を特定する：「車両が車線境界に接近した時」
3. 状態条件（While）を特定する：「車線維持支援が有効であり、車速が時速60km以上の状態」
4. 複合条件を1文に統合する：「While 車線維持支援が有効かつ車速60km以上で走行中、When 車両が車線境界に接近した時、システムは自動的にハンドルを補正しなければならない」
5. 対応するUnwanted Behavior型を作成する：「If 車線維持支援センサーが故障した場合、システムはドライバーに手動操作への切り替えを警告しなければならない」

このように、Complex型を使う場合は必ず対応する異常系要件もセットで作成することが重要です。安全系では「正常に動作する条件」と「異常時の退避動作」の両方が定義されていなければ、要件として不完全と判断されます。

ECサイトのレビュー機能をユーザーストーリーからEARS形式に変換する方法

Webアプリケーション開発でもEARS記法は有効に活用できます。AWSのKiroでは「商品のレビューシステムを追加する」という1行のプロンプトから、EARS形式のユーザーストーリーを自動生成する機能が搭載されています。ここでは、その変換プロセスを手動で行う手順を解説します。

まず、ユーザーストーリーを整理します。「ユーザーとして、購入した商品にレビューを投稿したい。そうすることで、他のユーザーの購入判断に役立てられる」という形式です。次に、このストーリーをEARS形式に分解します。Event-driven型として「When ユーザーがレビュー送信ボタンを押した時、システムはレビュー内容をデータベースに保存しなければならない」と記述します。Unwanted Behavior型として「If レビュー本文が空の状態で送信された場合、システムはエラーメッセージを表示しなければならない」と定義します。State-driven型として「While ユーザーが未ログイン状態の間、システムはレビュー投稿フォームを非表示にしなければならない」と記述します。曖昧なストーリーを具体的なEARS要件に変換する過程で、考慮漏れに気づける点が最大の利点です。

IoTセンサー異常検知をUnwanted Behavior型で記述する際の条件設計

IoTシステムでは、センサーの故障やネットワーク障害など多様な異常パターンが存在します。Unwanted Behavior型を使ってこれらの異常検知要件を記述する際は、「何を異常とみなすか」の定義が成否を分けます。たとえば温度センサーを監視するシステムであれば、「If 温度センサーが5秒以上応答しない場合、システムはセンサー異常アラートを管理画面に表示しなければならない」と記述します。

条件設計で注意すべきポイントは3つあります。第一に、異常判定の閾値を具体的な数値で定義することです。「長時間応答しない場合」ではテスト不能であり、「5秒以上」のように定量化する必要があります。第二に、異常発生後の復帰条件も合わせて定義することです。「When センサーの応答が正常に回復した時、システムはアラートを自動解除しなければならない」という要件がなければ、アラートが永続的に表示され続ける問題が発生します。第三に、複数のセンサーが同時に異常を検知した場合の優先順位や集約ルールを別途定義することです。個別の異常検知要件だけでは、システム全体の振る舞いを規定できないためです。

要件IDの命名規則とステータス管理で仕様変更に強いファイル運用例

EARS記法で作成した要件を実務で管理するためには、要件IDの命名規則とステータス管理の仕組みが不可欠です。推奨されるファイル命名規則は「EARS-XXX-[機能名].md」の形式です。たとえば認証機能の要件であれば「EARS-001-auth.md」、ファイルアップロード機能であれば「EARS-002-file-upload.md」のように、3桁連番とkebab-caseの機能名を組み合わせます。

各要件ファイルにはステータスフィールドを設け、Draft・Active・Deprecated・Supersededの4段階で管理します。軽微な修正はファイルを直接上書きし、Gitなどのバージョン管理で履歴を追跡します。大幅な変更が必要な場合は新しいEARSファイルを作成し、古いファイルのステータスをDeprecatedに変更したうえで「Supersedes EARS-001」のように関連性を記録します。このような運用ルールを事前に定めておくことで、仕様変更が頻発するアジャイル開発でも要件のトレーサビリティを維持できます。ステータス管理は属人化しやすいため、CI/CDパイプラインにステータス整合性チェックを組み込むことも有効な施策です。

KiroやClaude Codeなど生成AIツールとEARS記法を組み合わせた開発自動化

2025年以降、EARS記法は生成AIツールとの組み合わせによって新たな活用局面を迎えています。特にAWSが開発したエージェント型IDE「Kiro」がEARS記法を仕様駆動開発の中核に据えたことで、要件定義から実装・テストまでの自動化パイプラインにおけるEARS記法の役割が明確になりました。本章では、AI時代におけるEARS記法の活用方法を解説します。

AWSのKiroが採用した仕様駆動開発でEARS記法が中核を担う理由

Kiroは2025年7月にAWSが公開したエージェント型IDEで、仕様駆動開発（Spec-driven Development）を最大の特徴としています。Kiroの開発フローでは、自然言語のプロンプトから要件定義書（requirements.md）、技術設計書（design.md）、タスクリスト（tasks.md）の3つのドキュメントが自動生成されます。この要件定義書の記述形式としてEARS記法が採用されています。

KiroがEARS記法を選んだ理由は、AIエージェントが要件を構造的に解釈しやすい点にあります。自由記述の要件ではAIが条件と動作の境界を誤認するリスクがありますが、EARS記法のようにキーワードで構造が固定されていれば、解析精度が大幅に向上します。さらに、EARS形式の受け入れ基準はテストケースへの変換が容易であるため、要件からテストコードの自動生成までを一気通貫で実行できます。従来のAIコーディングツールが「プロトタイプは作れるが本番品質には届かない」という課題を抱えていたのに対し、Kiroは仕様を起点にすることでこのギャップを埋めようとしています。

自然言語プロンプト1行からユーザーストーリーと受け入れ基準を自動生成する流れ

Kiroの仕様駆動開発では、開発者が「商品にレビュー機能を追加したい」のような1行のプロンプトを入力するだけで、AIエージェントがEARS形式のユーザーストーリーと受け入れ基準を自動生成します。生成されるユーザーストーリーには、レビューの表示・作成・フィルタリング・評価といった複数のユースケースが含まれ、それぞれにEARS記法の受け入れ条件が付与されます。

この自動生成プロセスの最大の利点は、プロンプトに含まれる暗黙の前提が明示化される点です。たとえば「レビュー機能を追加」という指示には、未ログインユーザーの扱い、不適切な投稿のフィルタリング、レビュー編集・削除の権限管理など、多くの暗黙の要件が隠れています。EARS記法のパターン分類に基づいてAIがこれらを展開するため、開発者は生成された要件をレビューするだけで、考慮漏れを効率的に検出できます。ただし、AI生成の要件はドメイン固有のビジネスルールを正確に反映できない場合があるため、人間による最終確認は必須です。

EARS形式の要件からテストコードを自動生成するLLM連携の実践手順

EARS記法で記述された要件は、その構造化された形式を活かしてテストコードの自動生成にも活用できます。生成AIに対して「以下のEARS要求からテストコードを生成してください」と指示し、要件文とテストフレームワークを指定するだけで、正常系・異常系・境界値をカバーするテストケースが出力されます。

たとえば、「If 10回連続でログインに失敗した場合、システムは当該アカウントを15分間ロックしなければならない」というEARS要件をLLMに渡す場合、正常系として「10回連続失敗後にアカウントがロックされること」、境界値として「9回連続失敗ではログイン試行が可能であること」、復帰系として「ロックから15分後に再度ログイン可能になること」といったテストケースが自動導出されます。EARS記法の構文が条件と期待動作を明確に分離しているからこそ、AIが正確にテストの入力条件と期待結果を抽出できるのです。このLLM連携を開発ワークフローに組み込むことで、テスト設計工数の大幅な削減が期待できます。

Claude CodeやCursorでEARS記法をルールファイルに組み込む設定例

KiroだけでなくClaude CodeやCursorといった他のAIコーディングツールでも、EARS記法をプロジェクトのルールファイルに組み込むことで、要件駆動の開発フローを構築できます。Claude Codeであれば、プロジェクトルートに配置するCLAUDE.mdファイルにEARS記法のテンプレートと命名規則を記載します。

具体的には、ルールファイルに「要件定義はEARS記法に従うこと」「各要件はUbiquitous・Event-driven・State-driven・Unwanted Behavior・Optional・Complexのいずれかに分類すること」「要件IDはEARS-XXX形式で付番すること」といったルールを明記します。Cursorの場合は.cursorrulesファイルに同様の指示を記載します。これらの設定により、AIがコード生成時に要件との整合性を自動チェックしたり、新規機能の実装時にEARS形式の要件テンプレートを提案したりする動作が期待できます。ツールの種類に関わらず、EARS記法をルールとして明文化しておくことがAI活用の精度向上に直結します。

AIが生成した要件のレビュー観点と人間が担保すべき品質チェック項目

生成AIがEARS形式で出力した要件は、構文的には整っていても内容に問題を含む場合があります。AIは訓練データに基づいて一般的なパターンを出力するため、プロジェクト固有のビジネスルールや技術制約を反映しきれない場合があるからです。人間がレビューすべき観点を明確にしておくことで、AI活用の効果を最大化しつつリスクを管理できます。

• ビジネス要件との整合性：AI生成の要件が実際のビジネス目標やユーザーニーズと一致しているか
• ドメイン固有の制約：法規制・業界標準・社内ポリシーなどAIが把握しにくい制約が反映されているか
• 要件間の矛盾検出：複数の要件が互いに矛盾する条件を含んでいないか
• 非機能要件の網羅性：パフォーマンス・セキュリティ・可用性などの品質要件が欠落していないか
• パターン分類の適切性：各要件が正しいEARSパターンに分類されているか

AI生成の要件を「下書き」として活用し、ドメイン知識を持つ人間が最終的な妥当性を判断するという役割分担が、現時点では最も効果的な運用モデルです。AIの生成精度は向上し続けていますが、要件の最終責任は人間が負うという原則は変わりません。

既存の要件仕様書をEARS記法へ段階的に移行するための導入ステップと体制整備

EARS記法の有用性を理解していても、既存の要件仕様書をすべて書き換えるのは現実的ではありません。大規模な組織では数千件の要件が自由記述で蓄積されているケースも多く、一斉移行はコストとリスクの両面で合理的ではありません。本章では、段階的な移行計画の立て方と、定着に必要な体制整備の方法を解説します。

パイロットプロジェクトで小規模に検証してから全社展開する移行計画

EARS記法の導入は、いきなり全社展開するのではなく、パイロットプロジェクトで効果を実証してから段階的に拡大するアプローチが推奨されます。パイロットの選定基準は、要件数が50〜100件程度の中規模プロジェクトで、かつステークホルダーの協力が得られやすいチームであることです。大規模すぎるプロジェクトでは変数が多すぎて効果測定が困難になり、小規模すぎると統計的に有意な結果が得られません。

パイロットの実施期間は2〜3か月が目安です。この期間内に「新規要件はEARS記法で記述する」「既存要件のうち変更が発生したものからEARS形式に書き換える」というルールを適用し、レビュー効率や手戻り件数の変化を計測します。パイロット終了後には、効果のあった点と改善が必要な点を整理した報告書を作成し、全社展開の判断材料とします。経営層への説明には、手戻り削減による工数削減効果を金額換算した数値を含めると説得力が増します。

既存の自由記述要件をEARS5構文に分類変換するワークショップの進め方

既存の自由記述要件をEARS記法に変換する作業は、チームでワークショップ形式で実施するのが効果的です。個人作業にすると分類基準にばらつきが生じやすいため、複数人で議論しながら進めることで品質と一貫性を確保できます。ワークショップは1回あたり2〜3時間、変換対象は20〜30件が適切な量です。

ワークショップの進め方は次のとおりです。まず、EARS記法の6パターンを15分程度で復習します。次に、変換対象の要件を1件ずつ取り上げ、「この要件はどのパターンに該当するか」を全員で議論します。分類が決まったら、EARS形式のテンプレートに当てはめて書き直し、元の要件と比較して情報の過不足がないかを確認します。変換の過程で「そもそもこの要件は何を意味しているのかわからない」という事態が発生することも多く、その場合は元の要件自体の見直しが必要です。EARS記法への変換作業は、既存要件の品質監査を兼ねる副次的な効果もあります。

要件管理ツールとEARSテンプレートを連携させる運用フローの構築手順

EARS記法を組織で継続的に運用するためには、要件管理ツールとの連携が不可欠です。Jama Software、Visure Solutions、IBM DOORS、Redmineなどのツールでは、カスタムフィールドやテンプレート機能を活用してEARS形式の入力を強制する設定が可能です。たとえば、要件登録画面にEARSパターンの選択フィールドを追加し、選択したパターンに応じた入力テンプレートが自動表示される仕組みを構築します。

運用フローの構築手順としては、まずツールのカスタムフィールドにEARSパターン（Ubiquitous・Event-driven・State-driven・Unwanted Behavior・Optional・Complex）を選択肢として登録します。次に、各パターンに対応するテンプレート文を用意し、選択時に自動挿入されるように設定します。さらに、要件のステータスフィールド（Draft・Active・Deprecated・Superseded）を追加し、変更履歴が追跡できるようにします。ツール連携が完成したら、テストケースとの紐づけ機能を活用してトレーサビリティマトリクスを自動生成する仕組みも併せて整備すると、要件管理の効率が飛躍的に向上します。

EARSチャンピオンを各チームに配置して一貫性を維持するメンター体制

EARS記法の導入後に最も多い課題は、チーム間での適用品質のばらつきです。研修を受けた直後は意識的にEARS記法を使用していても、日々の業務に追われるうちに自由記述に戻ってしまうケースは少なくありません。この定着の課題を解決するために有効なのが、各チームに「EARSチャンピオン」を配置するメンター体制です。

EARSチャンピオンとは、EARS記法に関する深い理解を持ち、チーム内で書き方の相談やレビューの品質管理を担当するメンバーです。全要件を自分で書くのではなく、他のメンバーが書いた要件のパターン分類が正しいか、構文ルールに従っているかを確認する役割を担います。チャンピオン同士が定期的に情報交換する場を設けることで、組織全体での適用基準の統一が図れます。1チームあたり1〜2名の配置が理想的であり、専任ではなく兼任で十分機能します。チャンピオンの存在は、EARS記法が「一時的な取り組み」ではなく「組織の標準プロセス」として根付くための重要な仕組みです。

導入後3か月で効果測定すべきレビュー指摘率と手戻り件数のKPI設計

EARS記法の導入効果を客観的に評価するためには、定量的なKPIを設定して定期的に計測する必要があります。導入後3か月の時点で測定すべき主要なKPIは、レビュー指摘率（レビューで発見された問題件数÷要件総数）と手戻り件数（要件の曖昧さに起因する設計・実装のやり直し件数）の2つです。

レビュー指摘率は、EARS記法導入前と導入後で比較します。EARS記法が正しく運用されていれば、構文テンプレートによって曖昧な記述が減少するため、レビューでの指摘件数は減少するはずです。ただし、導入直後はパターン選択の誤りや構文ルール違反に対する指摘が増える可能性があるため、指摘内容を「内容の問題」と「形式の問題」に分類して計測することが重要です。手戻り件数については、要件定義フェーズで確定した内容が設計・実装フェーズで変更された回数を追跡します。3か月後の測定結果を踏まえて、運用ルールの調整やテンプレートの改善を行い、6か月後に再測定するサイクルを回すことで、継続的な改善が実現します。

EARS記法の形式だけ守って内容が破綻する典型的な失敗パターンと防止策

EARS記法は強力なツールですが、形式に従っているだけでは質の高い要件にはなりません。構文が正しくても内容に論理的な矛盾や条件の漏れがあれば、開発現場で深刻な問題を引き起こします。本章では、実際に報告されている失敗パターンを取り上げ、それぞれの防止策を具体的に解説します。

停車中の衝突でエアバッグ未展開になるUnwanted Behavior型の条件不足

EARS記法の失敗例として最も有名なのが、エアバッグ制御に関する要件の条件不足です。「While 車両が静止している間、システムはエアバッグを展開してはならない」という要件は、EARS記法のState-driven型とUnwanted Behavior型を組み合わせた構文として形式的には正しいものです。この要件の意図はエアバッグの誤展開防止ですが、記述された条件は本来の意図よりも広い範囲をカバーしてしまっています。

問題は、停車中に他の車両から追突された場合です。この状況では車両は静止していますが、乗員を保護するためにエアバッグを展開する必要があります。しかし上記の要件に従えば、システムはエアバッグを展開できません。この失敗の根本原因は、「静止している」という状態条件だけで制御判断を行っている点にあります。正しくは「While 車両が静止しており、かつ衝突が検知されていない間」のように、複数の条件を組み合わせて記述する必要があります。形式が正しいからといって安心せず、条件が実世界のすべてのシナリオを正しくカバーしているかを検証する姿勢が不可欠です。

「現行通り」という曖昧要求をEARS形式に変換しても意味が残らない問題

要件定義の現場で頻繁に登場する「現行通り」という表現は、EARS記法に変換しても根本的な問題が解消されない典型例です。「現行通り」をEARSの5パターンで無理やり記述すると、たとえば遍在型では「システムは現行通りの動作を継続する必要がある」、契機型では「ユーザーが通常の操作を行った場合、システムは現行通りの応答を行う必要がある」となります。

しかし、これらの記述は「現行通り」の内容が何であるかを具体的に定義していないため、テスト可能な要件にはなっていません。EARS記法のテンプレートに当てはめることで見かけ上は構造化されますが、肝心の「何をもって現行通りとするか」が不明なままです。この問題を解決するためには、EARS形式への変換前に「現行通り」が指す具体的な振る舞いを洗い出す作業が必要です。現行システムの動作を1つずつ観察・記録し、それぞれをEARS形式の個別要件として記述する以外に方法はありません。曖昧な入力からは、どんな記法を使っても曖昧な出力しか得られないという原則を認識しておくことが重要です。

複数のshallを1文に詰め込んで単一責任原則を破壊する過剰記述の弊害

EARS記法では、1つの要件文に1つのshall（義務表現）を記述するのが原則です。しかし、複数の動作を1文にまとめてしまう過剰記述のミスは実務で頻繁に発生します。たとえば「When ユーザーがログインした時、システムはダッシュボードを表示し、最終ログイン日時を更新し、未読通知の件数をバッジに表示しなければならない」という要件は、3つの異なる動作を1文に詰め込んでいます。

この過剰記述がもたらす弊害は複数あります。第一に、テストケースが複雑化します。3つの動作を1つの要件として扱うため、いずれか1つが失敗した場合に「この要件は合格なのか不合格なのか」の判断が曖昧になります。第二に、変更影響の特定が困難になります。通知バッジの仕様が変更された場合に、ログイン後の画面表示全体の要件を修正する必要が生じ、不要な変更リスクが発生します。第三に、トレーサビリティが低下します。1つの要件が複数の設計要素に紐づくため、影響範囲の追跡が複雑化します。対策は単純で、1文1shallの原則を徹底し、上記の例であれば3つの独立した要件に分割して記述します。

Event-driven型でトリガー条件を曖昧にしたままレビューを通過する盲点

Event-driven型はEARSパターンの中で最も使用頻度が高い型ですが、それだけにトリガー条件の曖昧さが見過ごされるケースも多発しています。たとえば「When データが変更された時、システムは通知を送信しなければならない」という要件は一見明確に見えますが、「データ」が何を指すのか、「変更」の範囲はどこまでか、「通知」の送信先は誰かが定義されていません。

この盲点が発生する原因は、レビュアーがEARS記法の構文が正しいかどうかにのみ注意を払い、キーワードの後に続く条件部分の具体性を十分に検証しないことにあります。構文パターンとしては正しいため、形式チェックだけでは検出できません。防止策としては、レビューチェックリストに「Whenの後の条件は、テスト担当者が再現可能なレベルで具体化されているか」「主語・目的語が特定のコンポーネントやデータを明示しているか」といった項目を追加することが有効です。EARS記法の構文チェックとは別に、内容の具体性を評価するレビュー観点を組織として標準化することが、この盲点の解消に不可欠です。

形式遵守と内容妥当性を両立させるダブルチェック体制の具体的な運用例

EARS記法の失敗パターンに共通するのは、「形式は正しいが内容に問題がある」という構造です。この問題を組織的に解決するためには、形式チェックと内容チェックを分離したダブルチェック体制の構築が効果的です。第一段階では、EARSチャンピオンまたは自動チェックツールが構文の正しさを検証します。パターン分類の適切性、shallの使用、主語の明示、1文1shallの原則遵守などが確認項目です。

第二段階では、ドメイン知識を持つレビュアーが内容の妥当性を検証します。ここでの確認項目は、条件が実世界のシナリオを正しくカバーしているか、他の要件との矛盾がないか、テスト担当者が再現可能なレベルで具体化されているか、そして非機能要件（パフォーマンス・セキュリティ等）が漏れていないかです。この2段階のチェックを要件登録フローに組み込むことで、形式だけ整った空虚な要件が下流工程に流出するリスクを大幅に低減できます。レビュー工数は増加しますが、下流での手戻りコストと比較すれば十分に投資対効果が見合う体制です。