# EARS要件構文を例で説明する Canonical: https://specscore.md/ja/articles/ears-requirements/ 最終更新: 2026年11月2日 [EARS](https://alistairmavin.com/ears/)（Easy Approach to Requirements Syntax）は要件記法です。条件、契機、システムの応答を決まった順に置く、英語の文型の小さな集合で、EARS構文とも呼びます。要件とは、システムが満たさなければならない検証可能な義務が一つあることです。[仕様駆動開発](https://specscore.md/ja/spec-driven-development/)（SDD、spec-driven development）は、その義務をコードの前に仕様へ書き、仕様を真実の源として扱うやり方です。製品要求文書（PRD、product requirements document）は、作業をタスクに分ける前に問題と範囲を述べる散文です。[SpecScore](https://specscore.md/)では、要件（REQ）は機能の中の名前付き規則で、受け入れ基準（AC、acceptance criterion）はそれらの規則の一つ以上を指す、任意の抽象的な条件です。[継続的インテグレーション](https://specscore.md/ja/validators/)（CI、continuous integration）は、提案された変更のたびに走る自動検査です。その検査は[コマンドラインインターフェース](https://specscore.md/ja/cli/)（CLI、command-line interface）のコマンド `specscore spec lint` です。[Kiro](https://kiro.dev/)は Amazon Web Services（AWS）のエージェント型統合開発環境（IDE、integrated development environment）で、これらの文型の一つを書きます。記法は2009年、Alistair Mavin と Rolls-Royce の同僚が Institute of Electrical and Electronics Engineers（IEEE）の要求工学会議で初めて発表しました。 ## EARSの由来 当時 Rolls-Royce PLC にいた Alistair Mavin、Philip Wilkinson、Adrian Harwood、Mark Novak は、2009年の 17th IEEE International Requirements Engineering Conference で “Easy Approach to Requirements Syntax (EARS)” を発表しました。文書識別子は [10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9) です。規則は、耐空性規則である Certification Specification for Engines（CS-E）の CS-E 50 からエンジン制御の要件を抜き出す過程で作りました。元の文章は要件、設計上の指針、注記が混ざっていました。 論文は、制約のない自然言語の八つの問題を挙げます。曖昧さ、漠然さ、複雑さ、欠落、重複、冗長さ、不適切な実装、検証不能です。小さな規則集で、そうした要件のすべてを五つの型のどれかに載せようとしました。著者は、この記法は高位の利害関係者要件に向くとし、システムの分解のあらゆる階層を覆うとは主張していません。 [Mavin自身の案内](https://alistairmavin.com/ears/)は、EARSを文章の要件を穏やかに制約する方法だと述べます。節は一つの順に並び、彼はそれを時間論理と呼びます。前提が先、次に契機、次にシステム名と応答です。規則は、前提は零個以上、契機は零個または一個、システム名は一個、応答は一個以上です。2009年の論文はこの形を五つの型に分けます。同じ案内は、キーワードを組み合わせる複合要件にも名前を付けています。 論文の事例では、元の抜粋は36件、書き直した集合は47件でした。平均の長さは36.9語から25.6語に減りました。著者は、その事例では複雑さ、欠落、重複、不適切な実装、検証不能が書き直し後にはなく、曖昧さ、漠然さ、冗長さは減ったが消えなかった、と報告します。限界も挙げます。標本が小さいこと、高位の安全要件だけであること、漠然さの分類に判断が入ることです。この数はその論文の、その一文書についての数です。 ## EARSの文型 キーワードは2009年の論文とMavinの案内にあるものです。論文は、状態について *While* の代わりに同じ意味の *During* を、その方が読みやすいときに使ってよいとしています。例文は型の説明であり、論文からの引用ではありません。Kiroは事象駆動の型を大文字で書きます。元の記法は文頭を大文字にします。例は英語のままです。EARS構文は英語だからです。 ### 常時 `The shall ` 常に有効です。前提も契機もないので、EARSのキーワードはありません。2009年の論文自身の例は、エンジンの過回転を防ぐ制御システムです。 **例:** The checkout system shall keep the order total equal to the sum of its line items. ### 事象駆動 `When , the shall ` 応答が要るのは、システムの境界で契機を検出したときだけで、そのときに限ります。キーワードは *When* です。 **例:** When a shopper submits the checkout form with invalid data, the checkout system shall show a validation error next to the invalid field. ### 状態駆動 `While , the shall ` 応答が要るのは、システムがその状態にある間です。キーワードは *While* です。 **例:** While the cart is empty, the checkout system shall keep the pay button disabled. ### 望ましくない振る舞い `If , then the shall ` 応答は、故障、外乱、逸脱、その他の望ましくない振る舞いを扱います。キーワードは *If* と *then* です。論文はこの型に専用の語を与え、そうした要件が見え続けるようにしました。望ましいか望ましくないかは、視点の問題になることもある、と著者は記しています。 **例:** If the submitted email is not a valid address, then the checkout system shall reject the form. ### 任意機能 `Where , the shall ` 応答が適用されるのは、製品がその機能を含むときだけです。キーワードは *Where* です。 **例:** Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step. ### 複合 `While , when , the shall ` キーワードが二つ以上です。Mavinの案内は節の順を保ちます。前提は *While*、契機は *When*、その後にシステムの応答です。2009年の論文は、ある状態での望ましくない振る舞いに *While* と *If / then* の組み合わせも使います。その組み合わせの例: While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order. **例:** While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order. ## よくある誤り ### 一つの文に複数の義務 論文は複合文を複雑さの問題として分けます。[SpecScoreの要件仕様](https://specscore.md/requirement-specification)も同じことを自身の言葉で言います。各 `REQ` は検証可能な義務をちょうど一つ表さなければなりません。 ### 望ましくない振る舞いを When に隠す *When* は予期する契機のためです。*If / then* は、できれば出会いたくない振る舞いのためです。両方に一つの語を使うと、望ましくない場合が通常の場合に見えます。論文が指摘した欠落の問題です。 ### 実装を書く “The checkout system shall store the flag in Redis” は設計を名指しします。論文はこれを不適切な実装と呼びます。応答は、システムが何を達成しなければならないかを言い、どの部品が行うかは言いません。 ### システム名がない “When the form is submitted, shall show an error” には主語がありません。Mavinの規則はシステム名を一つ要求します。 ### 応答の後に契機 “The checkout system shall show an error when the form is submitted” は契機を末尾に置きます。公表されている順は、前提、契機、応答です。 ### Kiroの一行をEARSの全体とみなす Kiroの機能仕様のページが公表している型は一つ、`WHEN … THE SYSTEM SHALL …` です。常時、*While*、*If / then*、*Where*、複合は、論文とMavinの案内にある記法の一部です。そのKiroのページにはありません。 ## KiroでのEARSの使い方 [Kiroの機能仕様のページ](https://kiro.dev/docs/specs/feature-specs/)は、更新日が2026年8月4日と記され、2026年11月2日に読みました。`requirements.md` がEARSを使うとあります。印字された型は `WHEN [condition/event]` の次に `THE SYSTEM SHALL [expected behavior]` です。ページの例は、WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields. です。 [要件先行のページ](https://kiro.dev/docs/specs/feature-specs/requirements-first/)は、生成された `requirements.md` が、同じ WHEN … THE SYSTEM SHALL … の形で、受け入れ基準付きのユーザーストーリーとシステムの振る舞いを含む、と述べます。登録の例は三文です。有効な登録データはアカウントを作り、既存のメールは “Email already registered” を示し、無効なメール形式は検証エラーを示します。 設計の前に、Analyze Requirements が論理的な不整合、曖昧さ、衝突する制約、抜けを探します。機能仕様のページは、要件を生成したあと、チャットの選択肢かエディタの Continue メニューから選ぶ、と述べます。`design.md` と `tasks.md` は要件のそばに置きます。Quick Spec は、間に承認の停止を置かず、要件、設計、タスクを実行します。 その分析はKiroの中の手順です。機能仕様のページは、自分のCIに足す形式リンターだとは書いていません。他のツールが仕様をどう検査するかは[ツール案内](https://specscore.md/ja/spec-driven-development/tools/)にあります。二つの製品の比較は[SpecScore vs Kiro](https://specscore.md/ja/vs/kiro/)です。 ## 同じ要件をSpecScoreで書く SpecScoreは、文がEARSの型に合うかを検査しません。[specscore-cli](https://github.com/specscore/specscore-cli) リポジトリの `specscore spec lint` は構造を検査します。ヘルプは README、Open Questions の節、見出しレベル、機能への参照、内部リンク、索引の行を挙げます。EARSの文は `REQ` 見出しの下の散文になれます。リンターは英文を採点しません。 [要件仕様](https://specscore.md/requirement-specification)は、各要件を `## Behavior` の中の話題見出しの下、一段下げて置きます。典型は `#### REQ: slug` です。slug は小文字、数字、ハイフンです。識別子は `{feature-path}#req:{slug}` です。仕様は、要件が RFC 2119（Request for Comments 2119）の語を使うべきだとします。MUST、MUST NOT、SHOULD、SHOULD NOT、MAY です。下の対応では、EARSの *shall* を MUST と書きます。 [受け入れ基準](https://specscore.md/acceptance-criteria-specification)は任意です。使うときは `## Acceptance Criteria` の中の `### AC: slug` で、次の行がそれらの識別子を並べた `**Requirements:**` です。受け入れ基準の仕様は、ACが抽象的な条件を述べ、Given/When/Then の手順、具体的な入力、実装の詳細を含んではならない、とします。具体的な流れは、機能の `_tests/` にある[シナリオ](https://specscore.md/scenario-specification)です。[機能仕様](https://specscore.md/feature-specification)は、状態、要約、問題、振る舞い、受け入れ基準、未解決の質問、準拠フッタも要求します。 下のファイルは一つの決済機能です。`show-field-error` が事象駆動の例、`reject-invalid-email` が望ましくない振る舞いの例です。2026年11月2日、`specscore spec lint` はこの木に対し、2026年10月30日に公開された最新版 specscore 0.55.1 と、[dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) に固定された specscore 0.39.1 の両方で、違反0件を報告しました。[形式のリポジトリ](https://github.com/specscore/specscore)がそのワークフローの場所です。 ### spec/features/checkout/README.md ```markdown --- format: https://specscore.md/feature-specification status: Draft --- # Feature: Checkout validation > [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) | **Status:** Draft **Source Ideas:** — ## Summary The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. ## Problem A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them. ## Behavior ### Field validation The checkout system checks the form when the shopper submits it. #### REQ: show-field-error When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field. #### REQ: reject-invalid-email If the submitted email is not a valid address, then the checkout system MUST reject the form. ## Acceptance Criteria ### AC: invalid-submission **Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected. ## Open Questions None at this time. --- *This document follows the https://specscore.md/feature-specification* ``` ### spec/features/README.md — 説明のセルは機能の要約文です。リンターの feature-index-row-sync は、より短い説明を拒否しました。 ```markdown --- format: https://specscore.md/features-index-specification --- # Features | Feature | Status | Description | |---|---|---| | [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. | ## Open Questions None at this time. --- *This document follows the https://specscore.md/features-index-specification* ``` ### spec/README.md — Open Questions の節を外すと oq-section: Open Questions section not found になりました。 ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml — project.host、project.org、project.repo が studio-toolbar の行と照合されます。無いとリンターは studio-toolbar: studio toolbar requires project host/org/repo を報告しました。 ```yaml # SpecScore Repo Config Schema: https://specscore.md/repo-config project: title: Checkout sample host: github.com org: example repo: checkout ``` この例を通すまでに、さらに二つの誤りが出て、どちらも上のファイルで直しています。`**Source Ideas:**` のない機能は `feature-source-ideas-required` で失敗しました。空の値は `—` です。機能索引にはフロントマター `format: https://specscore.md/features-index-specification` も必要でした。 リンターが通ることは、ファイルがこれらの構造規則に合うことを意味します。文が良いEARSであることや、決済製品が存在することは意味しません。この振る舞いの Given/When/Then は、ACの中の別の段落ではなく、`spec/features/checkout/_tests/` のシナリオファイルです。 ## 質問 ### EARSとは何の略ですか Easy Approach to Requirements Syntax です。要件のための文型の集合で、Rolls-Royce の Alistair Mavin、Philip Wilkinson、Adrian Harwood、Mark Novak が2009年の 17th IEEE International Requirements Engineering Conference で発表し、Mavinのサイトで説明しています。 ### Kiroの記法はEARSの全体ですか Kiroの機能仕様のページが定める型は一つです。WHEN … THE SYSTEM SHALL … です。2009年の論文とMavinの案内は、常時の要件、状態の While、望ましくない振る舞いの If/then、任意機能の Where、それらの複合も定義します。 ### SpecScoreはEARS構文を検証しますか しません。`specscore spec lint` はSpecScoreのファイル構造を検証します。EARSの文は `REQ` の散文になれます。リンターは英文を採点しません。 ### Given/When/Then の例はどこに置きますか 機能の `_tests/` にあるシナリオです。受け入れ基準は抽象的な条件のままで、受け入れ基準の仕様では Given/When/Then の手順を含んではなりません。 ## 出典 2026年11月2日に読みました。ページ自身が更新日を印字している場合はそちらです。Kiroの機能仕様のページは2026年8月4日更新とあります。 - [Mavin、Wilkinson、Harwood、Novak — Easy Approach to Requirements Syntax (EARS)、17th IEEE International Requirements Engineering Conference、2009、DOI 10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9) - [Alistair Mavin — EARSの案内](https://alistairmavin.com/ears/) - [Kiroの文書 — 機能仕様とEARS（ページ更新 2026年8月4日）](https://kiro.dev/docs/specs/feature-specs/) - [Kiroの文書 — 要件先行の流れ](https://kiro.dev/docs/specs/feature-specs/requirements-first/) - [specscore/specscore — 要件仕様](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [specscore/specscore — 受け入れ基準の仕様](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — シナリオ仕様](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — 機能仕様](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — dogfoodのCI](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore/specscore](https://github.com/specscore/specscore) ## 関連 - [AIコーディング向けMarkdownのPRDテンプレート](https://specscore.md/ja/articles/feature-spec-template/) - [CIで仕様リンターを使って仕様をリントする](https://specscore.md/ja/articles/lint-specs-in-ci/) - [AIエージェントが検証できる受け入れ基準の書き方](https://specscore.md/ja/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/ja/vs/kiro/) - [仕様駆動開発のツール](https://specscore.md/ja/spec-driven-development/tools/) - [仕様駆動開発](https://specscore.md/ja/spec-driven-development/) - [要件仕様](https://specscore.md/requirement-specification) - [受け入れ基準の仕様](https://specscore.md/acceptance-criteria-specification) - [機能仕様](https://specscore.md/feature-specification) - [バリデータとCI](https://specscore.md/ja/validators/)