Gherkinとは何か
Gherkin（ガーキン）は、システムの振る舞いを「Given（前提）／When（操作）／Then（結果）」という決まった構文で書くための言語です。BDD（Behavior-Driven Development、振る舞い駆動開発）の中核となるツールで、業務担当者が読み書きできる自然言語のまま、そのままテストとして実行できるのが最大の特徴です。
もともとはBDDフレームワーク Cucumber のために設計されましたが、現在は Behave（Python）、SpecFlow（.NET）、Playwright BDD、Cypress Cucumber Preprocessor など、ほぼすべての言語・フレームワークで実行できる事実上の標準になっています。
なぜ Gherkin が必要なのか
従来のテストには次の課題がありました。
- ユニットテスト：関数単位の正しさは検証できるが、業務シナリオ全体の正しさは見えない
- テスト仕様書（Excel）：書いた瞬間から実装と乖離し、メンテされなくなる
- 口頭での受入確認：再現性がなく、リグレッションが検出できない
Gherkin は、仕様書とテストコードを1つのファイルに統合することで、これらすべてを同時に解決します。ビジネスサイドが書いたシナリオが、そのままCIで自動実行され続けるリグレッションテストになります。
Gherkinの基本構文
キーワードの意味と使い分け
Feature（機能）
テスト対象となる機能のまとまりを宣言します。1つのユーザーストーリー、または1つの受入条件群に対応するのが一般的です。直後に2〜3行の説明文を書き、「誰のために、なぜ作るのか」をユーザーストーリー形式で残しておくと、Gherkinファイル単独でも目的が伝わります。
Scenario（シナリオ）
具体的な業務状況を1件記述します。1 Scenario = 1検証可能な事実 が原則で、複数の独立した検証を1つに詰め込みません。
Given（前提条件）
シナリオが始まる時点のシステム状態とデータ状態を書きます。「ユーザーがログインしている」「商品Aが在庫10で登録されている」など、操作の前に整えておくべき世界の状態です。
When（操作・イベント）
テスト対象となる1つのアクションを書きます。ボタンクリック、API呼び出し、タイマー発火など。複数操作になる場合は And で並べます。
Then（期待される結果）
When の結果として観測可能になる事実を書きます。「画面に〜が表示される」「DBに〜が保存される」など、外から検証できる形にします。「処理が成功する」のような曖昧な書き方は避けます。
And / But（接続詞）
同じ種類のステップを複数並べるときに、Given/When/Then の繰り返しを避けるために使います。意味的には直前のキーワードと同じです。
実例：商品検索機能
Feature: 商品検索
店舗マネージャーが在庫を素早く確認できるよう、商品名・コード・カテゴリで在庫を検索できる。
Scenario: キーワードでの正常検索
- Given商品マスタに「やかん」が10件登録されている
- Andユーザーは検索画面を開いている
- When検索ボックスに「やかん」を入力する
- And検索ボタンをクリックする
- Then1秒以内に10件の検索結果が表示される
- And各結果に商品名・在庫数・最終更新日が含まれる
Scenario: 該当なし
- Given商品マスタに「該当無し商品」は登録されていない
- When検索ボックスに「該当無し商品」を入力して検索する
- Then「該当する商品がありません」が表示される
- And検索結果リストは空である
Background でステップを共通化する
Feature 内のすべての Scenario で同じ前提条件が必要なら、Background ブロックに括り出します。
Background:
Given システムがオンラインである
And ユーザー「田中」がログイン済みである
各 Scenario の Given の前に自動で実行されます。テストの可読性が大きく上がる反面、無関係な前提を入れすぎると Scenario 単体で読めなくなるので、本当に共通の前提に留めます。
Scenario Outline でデータ駆動テストにする
同じシナリオで入力値だけ変えてテストしたい場合、Scenario Outline と Examples 表を使います。
Scenario Outline: 文字数バリデーション
Given 検索画面を開いている
When 検索ボックスに「<query>」を入力する
Then 「<message>」が表示される
Examples:
| query | message |
| あ | 検索キーワードは2文字以上で入力してください |
| あい | （正常系のためメッセージなし） |
| 1024文字を超えるクエリ | 検索キーワードは1024文字以下にしてください |
同じシナリオロジックで境界値テストを網羅できます。
Gherkin と EARS の関係
EARS（Easy Approach to Requirements Syntax）と Gherkin は、対立するものではなく補完関係にあります。
- EARS：要件を曖昧さなく記述するための構文。「いつ・どんな条件で・システムが・何をする」を統一フォーマットで書く
- Gherkin：要件をテスト可能な形で表現する構文。Given/When/Then をそのままテストランナーが解釈して実行する
EARS は要件の「言語化」、Gherkin は要件の「実行可能化」と役割が分かれます。実務では EARS で書いた要件を Gherkin に変換するのが効率的です。両者の対応関係は次の通りです。
ユビキタス（常時）
EARS: 商品検索システムは、検索結果を1秒以内に返す。
Gherkin: Background または各 Scenario の Then で「常に成立する」事後条件として表現する。
イベント駆動（〜のとき）
EARS: ユーザーが検索ボタンをクリックしたとき、システムは結果を表示する。
Gherkin: When 句にトリガーを、Then 句に振る舞いをそのまま分割する（最も自然に変換できるパターン）。
状態駆動（〜の間）
EARS: ユーザーがログインしている間、システムは検索履歴を保存する。
Gherkin: 「ログイン状態」を Given に置き、操作を When、保存結果を Then に書く。
オプション機能（〜の場合）
EARS: 多言語対応が有効な場合、システムは選択言語で結果を表示する。
Gherkin: 「機能フラグが有効」を Given に置き、Scenario Outline で複数言語のパターンを表形式で並べる。
望まない振る舞い（異常系）
EARS: 検索クエリが空の場合、システムはエラーメッセージを表示する。
Gherkin: 異常な前提を Given/When に置き、エラー表示と副作用なしを Then で明示する。1異常 = 1 Scenario が原則。
EARS と Gherkin を組み合わせた具体的なワークフローは EARS×Gherkin で要件からデモ／テストまでつなぐワークフロー で詳しく解説しています。
Gherkin を実行する：主要フレームワーク
Cucumber（多言語）
BDDの始祖。Java／JavaScript／Ruby など多言語に対応。最も成熟しているが、ステップ定義のセットアップにやや時間がかかる。
Behave（Python）
Python製の軽量フレームワーク。pytest との併用が容易で、Django／FastAPI のテストでよく使われる。
Playwright BDD
Microsoft の Playwright + Cucumber 統合。UIシナリオを Gherkin で書いて、そのままE2Eテストとして実行できる。近年最も勢いがあり、Beekleでも採用するケースが増えています。
SpecFlow（.NET）
.NET エコシステム標準。エンタープライズ業務システムでよく見ます。
Gherkin を書くときの注意点
1ステップ1事実
「Given ログインして検索画面を開いて商品Aを表示する」のように、1ステップに複数の動作を詰め込みません。再利用性とエラー時の特定可能性が下がります。3ステップに分けます。
具体的な値を書く
「いくつかの商品」「適切な値」のような曖昧な表現は避け、「10件の商品」「1024文字」と具体的に書きます。テストの再現性が要件です。
UI操作の手順ではなく、業務イベントを書く
「Given 検索ボックスをクリックする」「And キーを押す」「And フォーカスを外す」のような UI 手順詳細は書きません。「Given 検索ボックスに『やかん』を入力する」のような業務上の意味のある単位で書きます。手順詳細はステップ定義（実装側）に閉じ込めます。
Scenario タイトルに業務的な意味を込める
「Scenario: テスト1」「Scenario: 正常系」ではなく、「Scenario: キーワードでの正常検索」「Scenario: クエリ空のときのバリデーション」のように、1行読んで業務シナリオが想像できるタイトルにします。
Then は副作用も書く
画面表示だけでなく、DBへの記録・通知メールの送信・ログ出力など、観測可能な副作用も Then に含めます。表に出ない処理は将来のリグレッションで気づかれません。
Gherkin を導入するステップ
Step 1: ユーザーストーリーと EARS で要件を整える
ユーザーストーリー作成ツール でユーザーストーリーを書き、EARS で受入条件と異常系を曖昧さなく言語化します。
Step 2: Gherkin に変換
整えた要件を Gherkin の Feature/Scenario に変換します。生成AIに EARS を入力すれば、ほぼ機械的に Gherkin の下書きが作れます。
Step 3: ステップ定義を実装
エンジニアが Cucumber／Behave／Playwright BDD などでステップを実装します。1ステップは数行のコードに対応します。
Step 4: CIに組み込む
毎回のプッシュ／PRで Gherkin シナリオを自動実行し、リグレッション検知を継続的に行います。同じ Gherkin がデモ・受入確認・テストの3役をこなすのが BDD の真価です。
Gherkin を使う／使わない場面
Gherkin が向く場面
- 業務シナリオが多く、ステークホルダーとの受入確認が頻発する案件
- UIフローが複雑で、E2Eテストが必要な業務システム
- 長期運用が前提で、リグレッション検知の重要度が高いシステム
- ビジネスサイドとエンジニアの距離が遠く、共通言語が必要な体制
Gherkin が過剰になる場面
- 純粋な計算ロジック（ユニットテストの方が早い）
- 使い捨てのプロトタイプ・MVP
- シナリオが1〜2件しかない小規模機能
- UI が頻繁に変わる早期フェーズ（ステップ修正コストが上回る）
まとめ
Gherkin は、ビジネスサイドが理解できる自然言語のまま、そのまま実行可能なテストになる強力な構文です。覚えるべきは Given／When／Then の3キーワードだけ。EARS と組み合わせることで、要件定義からテストまでが1本の線でつながります。
- Given：シナリオの開始時点の状態
- When：トリガーとなる1つのアクション
- Then：観測可能な結果と副作用
業務システム、長期運用システム、ステークホルダーの多いプロジェクトでは特に効果を発揮します。
関連記事 / 関連ツール
- EARS×Gherkin で要件からデモ／テストまでつなぐワークフロー
- EARS（要件記述構文）入門
- ユーザーストーリーの書き方完全ガイド
- スコープ管理（FM法）の使い方
- Story Builder（無料ツール）
BDDで現場と開発を一直線にしたい方へ
Beekleでは、要件定義から Gherkin シナリオ生成、Playwright BDD でのテスト自動化までを一気通貫で支援しています。
参考文献
- Cucumber公式: Gherkin Reference
- Matt Wynne, Aslak Hellesøy The Cucumber Book: Behaviour-Driven Development for Testers and Developers（Pragmatic Bookshelf, 2017）
- Gojko Adzic Specification by Example（Manning, 2011）