評価・安全性

受け入れ基準とは

この記事の結論

受け入れ基準とは、ある機能を「完成した」と認めてよいかを判定するための、合否がはっきり出る条件の一覧です。
書き方の型としては、前提・操作・結果の3つに分ける Given／When／Then がよく使われます。
AIに実装を頼むときは、基準を先に渡し、完了報告を基準ごとの合否で返してもらうと、確認の抜けが減ります（2026-09-26 時点の整理）。

うけいれきじゅん／Acceptance Criteria

機能を「完成した」と認めてよいかを判定するための、合否がはっきり出る条件の一覧です。

最終更新: 2026-09-26

受け入れ基準とは（意味と読み方）

受け入れ基準（うけいれきじゅん）とは、ある機能を「完成した」と認めてよいかを判定するための、合否がはっきり出る条件の一覧です。英語では Acceptance Criteria と呼ばれます。

名前の「受け入れ」は、作ったものを依頼した側が受け取る場面から来ています。作った人の感覚ではなく、受け取る側が同じ手順で確かめて、同じ判定にたどり着けることが条件です。

一般的には、機能や作業単位ごとに数個ずつ付けます。何を作るかを決める要件定義が上流にあり、受け入れ基準はその要件が満たされたかを1件ずつ判定する物差しにあたります。

受け入れ基準の書き方の型：Given／When／Then

判定がぶれない書き方として広く使われているのが、Given／When／Then の3分割です。Martin Fowler の解説「GivenWhenThen」によると、この型は振る舞い駆動開発（BDD）の一部として Daniel Terhorst-North と Chris Matts が考案しました。

Given（前提）：操作を始める前の状態。例：未ログインの状態で
When（操作）：起こす出来事や操作。例：メール欄を空のまま送信を押すと
Then（結果）：期待する結果。例：送信されず「メールアドレスを入力してください」と表示される

この型をそのまま自動テストにつなげる記法が Gherkin です。Gherkin のリファレンス（Cucumber 公式）は、Given をシステムを既知の状態に置く手順、When を出来事や操作、Then を期待する結果と説明しています。キーワードは70を超える言語に翻訳されています。

AI開発での受け入れ基準の使い方

AIコーディングエージェントに問い合わせフォームを作らせる場面を例にします。依頼文の末尾に、基準を番号付きで置きます。

AC1：3項目すべて入力して送信すると、完了画面に切り替わる
AC2：メール欄に @ がないと送信されず、欄の下に理由が出る
AC3：送信ボタンを2回続けて押しても、送信は1件だけ

そのうえで「完了したら AC1〜AC3 それぞれについて、合否と確かめた方法を1行ずつ書いて」と頼みます。報告が基準の番号で返ってくるので、どれが未確認なのかがすぐ分かります。

基準を先に渡すと、エージェントに基準を確かめるテストを書かせる流れにもつなげやすくなります。一度通った基準は、後の変更で壊れていないかを見る回帰テストの材料としても残せます。

受け入れ基準のよくある誤解

誤解：受け入れ基準とテストケースは同じもの → 実際：基準は「何を満たせば合格か」、テストは「それをどう確かめるか」です。1つの基準を確かめるのに、複数のテストが要ることもあります。
誤解：完成の定義（Definition of Done）と同じ → 実際：スクラムガイド（2020年版）の完成の定義は、プロダクトに求められる品質を満たした状態を表すもので、満たさない項目はリリースもレビューでの提示もできません。一般的には、完成の定義が全項目に共通の品質条件、受け入れ基準が項目ごとの中身の条件、と使い分けます。
誤解：細かく書くほどよい → 実際：実装の手段まで書くと、よりよい作り方を選ぶ余地をなくします。書くのは外から見える振る舞いだけに留めます。
誤解：AIが「完了しました」と言えば満たしている → 実際：完了の報告は判定ではありません。基準ごとに、自分の手元で同じ操作をして確かめます。

受け入れ基準を書くときのコツ

人によって判定が割れる言葉を避ける：「すばやく」「見やすく」は判定が割れます。「一覧が表示されるまで待ち表示が出ない」のように、見て分かる状態に置き換えます。
うまくいかない場合を最低1つ入れる：正しく入力した場合だけの基準は抜けが出やすく、空欄・二重送信・通信切れのどれかを足すと、見落としが表に出ます。
範囲外を明記する：「今回は多言語対応を含まない」と添えると、基準にない作業が紛れ込んだときに気づけます。

出典・参考資料

GivenWhenThen（Martin Fowler, 2013年）：Given／When／Then の由来と各部の意味。
Gherkin リファレンス（Cucumber 公式ドキュメント）：Given・When・Then の各手順の役割と、多言語での記述。
スクラムガイド 2020年版（scrumguides.org）：完成の定義（Definition of Done）の記述。

よくある質問

Q1. 受け入れ基準とは何ですか？
ある機能を「完成した」と認めてよいかを判定するための、合否がはっきり出る条件の一覧です。作った人の感覚ではなく、受け取る側が同じ手順で確かめて同じ判定になることが求められます。

Q2. 受け入れ基準はどう書けばよいですか？
前提・操作・結果に分ける Given／When／Then の型が使いやすい方法です。「未ログインで」「空のまま送信すると」「送信されず理由が表示される」のように、外から見える振る舞いだけを書きます。

Q3. 受け入れ基準と完成の定義（Definition of Done）は何が違いますか？
一般的には、完成の定義はすべての作業に共通する品質の条件、受け入れ基準は機能ごとの中身の条件として使い分けます。両方を満たして初めて、その機能は完成と扱われます。

Q4. AIに実装を頼むとき、受け入れ基準はどう渡せばよいですか？
依頼文の末尾に番号を付けて並べ、完了報告は番号ごとに合否と確かめた方法を書くよう指示します。報告を受けたら、基準ごとに自分でも同じ操作をして確かめます。