TL;DR

　要求工学の仕様記法である EARS (Easy Approach to Requirements Syntax)がLLMとの親和性を期待され、注目を集めている。本稿では、ソフトウエア工学界隈で有名はGherkinとの類似性を示しながら、Gherkinの応用実績から、EARSがどこまでその真価を発揮するかを考察した。ソフト開発の完全自動化を導く可能性を秘めている。

はじめに

　2025はLLMにコード開発が急速に普及し、プログラマの多くがその恩恵に預かる年となりました。自然言語による使用記載によりちょっとしたWebアプリが数時間で稼働できるのは本当に驚きです。ソフトウエア開発プロセスは大転換期を迎えようとしています。自然言語→コード変換だけでなく、コード→仕様抽出も自動化されています。もはや自然言語をプログラム言語の一つとして定義することは大袈裟でもなんでもない状況です。
　こうした流れを受け、エンジニアリングの上流に位置する要求工学では、要求仕様記述方法の一つである、EARS (Easy Approach to Requirements Syntax) 記法 が、ソフトウエア工学の分野で再び脚光を浴びています。自動車や航空機、ロケットなどの要求仕様の厳しいシステムのための記述法なのですが、ソフトウエアテストにおける仕様記法の一つであるBDD記法の一つGherkinによく似ていました。2024年末ごろGherkinレベルのプロンプトでコード生成ができそうだという報告がポツポツと上がってきていましたが、2025年になりGhekinをリッチにしたEARSがにわかに評価されるようになりました。EARSは正に精密なLLMプロンプトそのものであり、これならソフトウエア生成はかなり容易との認識が一気に広がりました。つまり、設計仕様をEARSで適切に記載することはコーディングすることと同義という理解です。と同時に、コード開発だけでなく、ソフトウエアテストも自動生成できるという認識も2025年後半に広がりました。
　本稿では、ソフトウエアテストの自動生成という観点からEARSがBDDやLLMとどう結びついてきたのか、その結果どのような未来が待っていそうかについて語ります。

1.　EARS記法の歴史と背景

EARS（Easy Approach to Requirements Syntax）は、2000年代後半にイギリスの Rolls-Royce で Alistair Mavin らによって提案された要求記法です。航空機エンジン制御など、安全クリティカルなシステムの要求仕様をレビューする中で、「多くの要求文が似た構造を持っているのに、書き方がバラバラで読みづらい」という課題から生まれました。

EARS の狙いは、自然言語で書きたい／書かざるを得ない要求に対して、軽量なルールだけを課して「ほどよく構造化する」ことです。
典型的には、

When <trigger>, the system shall <response>.
While <state>, the system shall <response>.

#### EARS の例（日本語）
When ユーザーが「計測開始」ボタンを押したとき, the system shall 新しい計測を開始する。  
While システムが計測中のあいだ, the system shall 1秒ごとに現在の値を画面に表示する。  
If センサーが故障した場合, the system shall ユーザーにエラーメッセージを表示する。  
When 計測が完了したとき, the system shall 結果をデータベースに保存する。

のようなテンプレートで、条件（When / While / If …）とシステム振る舞い（the system shall …）を常に同じ順番で書くことを徹底します。これにより、曖昧さや抜け漏れを減らしつつ、形式仕様ほどの学習コストなしに、レビューしやすい要求セットを作ることができます。

EARS は 2009 年の国際会議 RE’09 で初めて公表され、その後、航空宇宙・自動車・産業機械などの分野で採用が広がりました。現在では、要求工学のトレーニングや大学教育でも紹介される、典型的な「制約付き自然言語」の手法として位置づけられています。

＃最初の論文で提唱された EARSの代表的な5つパターン

1. Ubiquitous requirement（常時適用型）
   - いつでも成り立つ要求。「条件なしで常にこうしてね」というルール。
   - 例：The system shall 計測結果をログに保存する。
     （システムは常に計測結果をログに保存しなければならない）

2. Event-driven requirement（イベント駆動型）
   - 何かが起きたときにだけ動く要求。「When ... the system shall ...」
   - 例：When ユーザーが「計測開始」ボタンを押したとき, the system shall 新しい計測を開始する。

3. State-driven requirement（状態駆動型）
   - ある状態の間ずっと成り立つ要求。「While ... the system shall ...」
   - 例：While システムが計測中のあいだ, the system shall 1秒ごとに現在値を表示する。

4. Unwanted behaviour requirement（望ましくない事象対応型）
   - エラーや故障など「起きてほしくないこと」が起きたときの要求。「If ... the system shall ...」
   - 例：If センサーが故障した場合, the system shall ユーザーにエラーメッセージを表示する。

5. Optional feature requirement（オプション機能型）
   - 追加機能／オプションが有効なときだけ成り立つ要求。
   - 例：When ログ出力オプションが有効なとき, the system shall 詳細ログも保存する。

2.　Gherkin記法の歴史と背景

　Gherkin は、BDD（Behavior-Driven Development）の実践を支えるために生まれた「振る舞い仕様用 DSL」です。EARSよりも早い2000年代半ばに Dan North が BDD を提唱し、その文脈の中で Aslak Hellesøy が 2008 年頃に公開した自動テストツール 「Cucumber」のためのシナリオ記述言語として整備されました。Cucumber は当初 Ruby 向けの BDD フレームワークとして登場し、受け入れテストを自然言語に近い形で書き、そのまま自動テストとして実行することを目指していました。

Gherkin の目的は、開発者とビジネス側が共有できる「実行可能な仕様(Executable Specification)」を書くためのフォーマットを提供することです。代表的な構文は、

Feature:（機能のまとまり）
Scenario:（具体的な振る舞いの例）
Given / When / Then（前提・操作・期待結果）

といったキーワードで、誰が読んでも「何をしたら、どうなるべきか」が一目で分かるような構造になっています。この形式で書かれたシナリオは Cucumber や SpecFlow などのツールがパースし、対応するステップ定義コードを実行することで、自動テストとして機能します。

　このように、GherkingとCucumberの誕生は、自然言語記述とテストコードを実務レベルでつなぐアーキテクチャを実現した瞬間でした。

登場以降、Gherkin は Web アプリケーションや業務システムの受け入れテストを中心に広く使われるようになり、現在では「BDD = Gherkin で書かれたシナリオを Cucumber で回す」という形が、事実上のデファクトスタンダードの一つになっています。

#### Gherkin の例（日本語）
Feature: 計測機能  
  Scenario: 新しい計測を開始する  
    Given ユーザーが計測画面を開いている  
    When ユーザーが「計測開始」ボタンを押す  
    Then システムは計測を開始し, 1秒ごとに現在の値を表示する

// 上記のGherkinに対応するCriticalスクリプト(TypeScriptベース)
// features/step_definitions/measurement.steps.ts
import { Given, When, Then } from '@cucumber/cucumber';
import { expect } from '@playwright/test';
import type { Page } from 'playwright';

// 例: World で Playwright の Page を共有している前提
interface TestWorld {
  page: Page;
}
type This = TestWorld;

Given('ユーザーが計測画面を開いている', async function (this: This) {
  await this.page.goto('https://example.com/measurement');
  await expect(this.page.getByRole('heading', { name: '計測機能' })).toBeVisible();
});

When('ユーザーが「計測開始」ボタンを押す', async function (this: This) {
  await this.page.getByRole('button', { name: '計測開始' }).click();
});

Then(
  'システムは計測を開始し, 1秒ごとに現在の値を表示する',
  async function (this: This) {
    // 計測開始状態になっていることを確認
    await expect(this.page.getByTestId('status')).toHaveText('計測中');

    // 1秒ごとに値が変化していることをざっくり確認（簡易チェック）
    const firstValue = await this.page.getByTestId('current-value').innerText();
    await this.page.waitForTimeout(1100);
    const secondValue = await this.page.getByTestId('current-value').innerText();

    expect(firstValue).not.toBe(secondValue);
  }
);

3.　テスト自動化の歴史と EARS / Gherkinの位置づけ

　ここではDevOpsという視点から、「テスト自動化の歴史」の中に、EARS（要求記法）と Gherkin(BDD記法）、Cucumber/ Playwright（実行エンジン）がどう並んでいるのかをざっくり整理してみます。

年	EARS（要件定義）	Gherkin/Cucumber(BDD)	世の中の動き
1997	-	-	JUnit（ユニットテストツール）登場自動テスト幕明け
2003	-	TDD（テスト駆動開発）の普及	アジャイルの浸透
2004	-	-	Selenimum（Web ブラウザ自動テストツール） E2Eテストの萌芽
2006	-	Dan North氏がBDDを提唱	-
2008	-	Cucumber 初版リリース (Gherkinの確立)	-
2009	EARS 論文発表 (Alistair Mavin氏ら)	-	-
2010s	自動車・航空業界で普及	Webやアプリ開発でデファクト化	-
2017	-	-	Puppeteer(Google) (高速Web操作)
2020	-	-	Playwright(Microsft)
2025	-	-	PlaywrightMCP -LLMからブラウザ操作
現在	DX・AI開発で再注目	BDDツールの標準	両者+LLMの融合

3.1 スクリプト時代から BDD まで

最初のテスト自動化は、とてもシンプルでした。

xUnit 系（JUnit など）
→ 開発者がコードレベルのテストを書いて実行。
→ 要求仕様書（SRS）とはほぼ別世界で、「テスト = コードの振る舞い確認」という位置づけでした。
Selenium 時代
→ Web アプリの UI 自動テストが一気に広まりましたが、
テスト内容は「ボタンをクリック」「テキストを入力」といった実装寄りの記述が中心で、
要求仕様とのつながりはまだ弱い状態でした。

そこに登場したのが BDD と Cucumber/Gherkin です。

Feature / Scenario / Given-When-Then で「ビジネス的な振る舞い」を書く
それを Cucumber + Selenium などでそのまま自動テストとして実行する

という形で、要求（に近い言葉）とテストコードをつなごうとしたのが、このフェーズです。

3.2 EARS：要求側の「フォーマットを整える」動き

一方で、要求工学側では 2009 年に EARS が登場します。

When <trigger>, the system shall <response>.
While <state>, the system shall <response>.

といったテンプレートで、自然言語の要求をパターン化して書くやり方ですね。

EARS のおかげで、

条件（When / While / If…）
システムの応答（the system shall…）

がきれいに分かれるので、テスト観点としても扱いやすくなります。

ここから、

EARS で要求を書く
→ そこから Gherkin シナリオやテストモデルを作る

という「要求側からテスト自動化へ寄る」試みが、研究と実務の両方で増えてきます。

3.3 Playwright：モダンな実行エンジンとして

CI/CD が当たり前になってくると、

速い
安定している
コンテナで回しやすい

という要件を満たすテスト実行エンジンが求められるようになりました。

そこで登場したのが Playwright です。

TypeScript/JavaScript を中心に、API がモダンで扱いやすい
自動待機やトレースなど、E2E テストに欲しい機能が一通り揃っている

Playwright 自体は BDD 専用ではありませんが、

上で書かれた Gherkin シナリオ を
下で Playwright のコード に落とし込んで実行する

という組み合わせはよく使われます。つまり、Playwright は 「実行エンジン層」 を担う存在、と見ると分かりやすいです。

3.4 三層モデルでざっくり整理すると

歴史の流れを踏まえると、いまの主流アーキテクチャは次の3層に分けて考えられます。

要求層
- SRS / ユーザーストーリー / Use Case
- EARS 記法 など
  → 「何を実現するか」をブレずに書く場所
シナリオ・仕様例示層
- Gherkin / BDD (Feature / Scenario / Given-When-Then)
- EARS から引いたテスト観点、MBT のモデルなど
  → 要求を「具体的な例・振る舞い」として共有する場所
実行エンジン層
- Cucumber + Selenium / Playwright
- Playwright / Cypress / xUnit / pytest / JUnit …
  → シナリオを実際に自動テストとして回す場所

この中で、

EARS は「1 → 2」をスムーズにするための要求フォーマット
Gherkin/Cucumber は「2 → 3」の橋渡し
Playwright は「3」で手堅く回すためのモダンな実行エンジン

という役割分担になっています。この三層を意識して設計しておくと、将来的に「LLM で EARS を整形して Gherkin を自動生成する」「Gherkin から Playwright のコード雛形を出す」といった、自動化の拡張もしやすくなります。

レイヤ	主な役割	代表的な記法 / ツール	LLM がしやすいこと
要求層 Requirements	何を実現すべきかを定義	SRS, User Story, Use Case, EARS	自然文要求の整形・補完 (→ EARS などへ)
シナリオ層 Specification	要求を具体的な例・シナリオに落とす	Gherkin, MBT モデル (状態遷移図等)	EARS からのシナリオ生成、シナリオの自動リファクタ
実行層 Execution	シナリオを自動テストとして実行	Cucumber, Playwright, Cypress 等	シナリオからテストコード雛形を生成
LLM/AIレイヤ	各レイヤ間の変換・ギャップ充填	GPT 系 LLM, テスト生成ツール等	要求 ⇔ シナリオ ⇔ コード ⇔ ログの双方向変換

3.5 PlaywrightMCPの登場：要求仕様→ シナリオ→ テスト生成

　要求仕様 → シナリオ → テスト生成という流れに、自然言語とコードを強力に取り扱えられるLLM が入ってきたことで、要求仕様の管理から仕様遵守の確認までを自動的に管理する道筋が見えてきました。残るピースは生成したコードをデバッグして自動的に完成させる機能でした。そこで登場するのが Playwright MCP です。

　Playwright MCP は、Microsoft Playwright チームが提供する Model Context Protocol(MCP) サーバ で、LLM から Playwright のブラウザ自動化機能を呼び出せるようにする仕組みです。MCP 自体は Anthropic が提唱した「AI 用の USB-C ポート」のような標準プロトコルで、各種ツールサーバを LLM から共通インターフェースで叩けるようにします。

　Playwright MCP のポイントは、スクリーンショットではなくアクセシビリティツリーを LLM に渡すことです。これにより、LLM は「画面の構造」を JSON 的に理解しながら、

画面を探索して要素を特定する
適切なロケーター（getByRole / getByText など）を自動で選ぶ
そこから Playwright テストコードや Page Object を生成する

といったことができます。Microsoft 自身も「Playwright MCP によって、AI エージェントがアプリを探索し、新しいテストケースを提案し、自然言語からテストを生成できる」と公式ブログで述べています。

これを、EARS + Gherkin + LLM の流れの中に置くと、だいたい次のような役割分担になります。

EARS
- 人間が読む要求を、When/While/If … the system shall … というパターンで整理する（要求層）
Gherkin
- その要求を「具体的な振る舞いの例」として Feature / Scenario / Given-When-Then に落とす（シナリオ層）
LLM
- EARS から Gherkin を起こしたり、Gherkin からテストコードの雛形を生成したりする「変換エンジン」
Playwright MCP
- LLM が実際にブラウザを操作し、画面構造を読み取り、Playwright テストを生成・改善するための「手足」（実行層＋観測層）

　従来の E2E 自動化では、「仕様を書く人」「Gherkinを書く人」「Playwrightコードを書く人」「ブラウザを触って確認する人」がバラバラになりがちでした。 EARS・Gherkin・LLM・Playwright MCP を組み合わせると、

上流：EARS / Gherkin で 人間向けの仕様を整える
中流：LLM がそこから テストシナリオ・コードを大量生成
下流：Playwright MCP で 実際にブラウザを動かしながら探索・修正

というループを回せるようになります。Playwright MCP は、このループの「最後の一マイル」、つまり LLM がアプリ本体に触れるための標準化された通路として位置づけると理解しやすいでしょう。

図4: LLM / AI レイヤを含む拡張モデル

4. テスト自動生成新時代の次へ

4.1 究極のシフトレフト

　近い未来、コード設計とテスト設計が同時に行われ、プロンプト生成→ コード生成→ テスト→ デバッグ→ リファクタリングのプロセスが全自動で走る様になるでしょう。これにより、一人のソフトウエアエンジニアが「どう機能をつくるか」だけでなく「作った機能の品質は十分か試験」までを一人で実施することになるでしょう。

4.2 プロンプト工学は要求工学と融合する

　「EARSがリッチなプロンプト」である以上、少なくともEARS相当の記法と要求工学の考え方はプロンプトを記述する上で基本的な位置付けになると予測されます。二つの工学分野は再編され、新しい研究分野として重要な位置を占めるようになると考えられます。
　より巨大な開発規模のPJへこの技術の適用範囲が広がるにつれ、人間が厳密なEARSを記述することが困難になるでしょう。そうなれば、すぐにEARSの生成・デバッグ・更新をLLMに実行させようとするトレンドへの移っていくことが予測されます。エンジニアはEARSを書くのは未来のごく短いフェーズだけで、すぐに書けなくても読めればよいというフェーズに移行すると考えられます。

4.3 開発自動化技術はソフトウエアを超えて汎用技術へと進化

　2025年12月時点のロボティクス技術の進化はめざましく人間の作業を代替するレベルに達しています。ロボティクスをツールとして使うことで、ハードの自動開発もソフトで可能になるとみています。ハードウエア開発までもソフトウエア工学の技術で「システムの開発＋テスト＋リファクタリング」を自動化する様になることと思われます。ロボティクスの技術が進み、製作可能な部品のレベル向上に従って、応用分野は広がり続けるでしょう。

おわりに

　今 LLMの視点から脚光を浴びているEARSを題材に、自動テスト分野では有名なGherkinでのLLMコードの生成の実績を引き合いに出しつつ、2026年に何が起こるかを考察してみました。
　個人的な感想ですが、色々なピースが揃ってきて、EARS（＝プロンプト）がプログラム言語化かしつつあるという印象を得ています。プロンプト工学は、自動車・航空・宇宙・医療といったミッションクリティカルな分野で高い実績を積み上げてきた要求工学の手法が入り込むことで、裏技的な位置付けから膨大な裏付けをもつ信頼性を持った工学へと昇華する可能性を見出しています。
　ほぼ同じ時代に先輩として生まれたそっくりさんであるGherkenが、EARSとLLMと繋げる役割を果たしたことはソフトウエア工学とLLMとの親和性を図らずも示してくれたことにも驚いています。十数年前に見た映画に、ハンドロボットが主人公からの会話指示でサイバースーツの新規バージョン「マークII」を組み立てるシーンがありましたが、そういう時代はあと数年なのかもしれません。

参考文献

Alistair Mavin, “EARS – Alistair Mavin”.
https://alistairmavin.com/ears/
Michael Jastram, “Writing Better Requirements with EARS”. SE-Trends.
https://www.se-trends.de/en/requirements-with-ears/
Hui Liu et al., “EARS2TF: A Tool for Automated Planning Test from Semi-formalized Requirements”. SEKE 2022.
PDF: https://ksiresearch.org/seke/seke22paper/paper179.pdf
Mikael E. Salari et al., “An Empirical Investigation of Requirements Engineering and Testing Utilizing EARS Notation in PLC Programs”.
(MDU publication portal)
https://www.es.mdu.se/publications/7171-An_Empirical_Investigation_of_Requirements_Engineering_and_Testing_Utilizing_EARS_Notation_in_PLC_Programs
Aslak Hellesøy, “BDD Tool Cucumber is 10 Years Old: Q&A with its Founder Aslak Hellesøy”. InfoQ, 2018.
https://www.infoq.com/news/2018/04/cucumber-bdd-ten-years/
Cucumber.io, “History of BDD”.
https://cucumber.io/docs/bdd/history/
Stack Overflow, “Using Cucumber/Gherkin for application code generation”.
https://stackoverflow.com/questions/77126846/using-cucumber-gherkin-for-application-code-generation
303 Software Blog, “BDD & Cucumber Reality Check 2025”.
https://303software.com/behavior-driven-testing-a-cucumber-test-automation-framework
CloudQA, “The Ultimate Guide to GPT Prompts for Test Case Generation in 2025”.
https://cloudqa.io/gpt-prompts-test-case-generation-qa-automation-2025/
QRA Corp, “When Not to Use EARS”.
https://qracorp.com/when-not-to-use-ears/
Conduct of Code Blog, “Easy Approach to Requirements Syntax and the segue to Behavior-Driven Development”.
https://conductofcode.io/post/easy-approach-to-requirements-syntax-and-the-segue-to-behavior-driven-development/
Taciana N. Kudo et al., “A Conceptual Metamodel to Bridging Requirement Patterns to Test Patterns”.
ACM / SoPaMM メタモデル論文.
https://dl.acm.org/doi/10.1145/3350768.3351300
Tahir et al., “Cross-Project Multiclass Classification of EARS-Based Software Requirements”. Systems, MDPI, 2025.
https://www.mdpi.com/2079-8954/13/7/567
testRigor Blog, “SpecFlow is Dead”.
https://testrigor.com/blog/specflow-is-dead/
Tricentis, “Tricentis Acquires SpecFlow to Support Agile Development and .NET Teams”.
https://www.tricentis.com/news/tricentis-acquires-specflow
Jama Software, “Adopting the EARS Notation to Improve Requirements Engineering”.
https://www.jamasoftware.com/requirements-management-guide/writing-requirements/adopting-the-ears-notation-to-improve-requirements-engineering/
Alistair Mavin et al., “Easy Approach to Requirements Syntax (EARS)”.
17th IEEE International Requirements Engineering Conference (RE’09).
DOI ページ: https://doi.org/10.1109/RE.2009.9
Visure Solutions, “Adopting EARS Notation for Requirements Specification”.
https://visuresolutions.com/alm-guide/adopting-ears-notation/
NASA, A. Katis et al., “Realizability Checking of Requirements in FRET” （EARS-CTRL から FRETish への変換事例を含む技術報告）.
PDF: https://ntrs.nasa.gov/api/citations/20220007510/downloads/TechnicalReport__FRET_Realizability_Checking.pdf