Laravelのバリデーションで指定できる内容をざっくりまとめ直しました。

Laravelのバリデーションの設定内容がアルファベット順で見づらかったので、ざっくり書きました。
使われそうな順で書きました。(一部関連性が高いものは近接させています)
カテゴリ分けをし直しました。より見やすくなったと思います。

想定している環境

• Laravel5.1以降

Base

Ver	用語	使用例	説明
5.1	sometimes	sometimes	フィールドが存在する場合のみ以降のバリデーション判定をする
5.2	bail	bail	バリデーションに失敗したら残りのバリデーションルールの判定をしない

5.2以降は配列の値のバリデーションが可能になっている。

存在チェック系

Ver	用語	使用例	説明
5.1	required	required	入力必須(フィールドも存在している必要ある)
5.2	present	present	フィールドが存在しているかどうか(中身は確認しない)
5.3	nullable	nullable	nullableな内容を許容する(フィールドは存在してなくていいよ)
5.2	filled	filled	フィールドが存在する場合は必須(存在していないなら許可)
5.1	in	in:foo,bar	指定されたリストの中の値に含まれているかどうか(例だとfooかbarが値ならOK)
5.1	not_in	not_in:foo,bar	inの含まれない版
5.2	in_array	in_array:別のフィールド	フィールドの中身が別のフィールドの値のどれかであるかどうか

required,present、nullable,filledを利用することで、リクエスト時のフィールドの前提を記述することができます。

用語	フィールドは無くても良い	中身を確認しない	null許可
required	×	×	×
present	×	◯	確認しない
nullable	◯	x	◯
filled	◯	×	×

ここでいうと、requiredとfilledは単体で使うものの、presentとnullableはどちらかのみ使うこともあれば、一緒に使うこともある。
(リクエストのフィールドが存在していることはチェックしたいけど、nullが入ってきてもいいよという場合にはpresentとnullableの両方を利用する)

型チェック関連

論理値系

Ver	用語	使用例	説明
5.1	boolean	boolean	論理値かどうか(文字列の1や0も含む)
5.1	accepted	accepted	yes,on, 1, trueのどれかであるかどうか

文字列判定系

Ver	用語	使用例	説明
5.1	string	string	文字列であるかどうか
5.1	alpha	alpha	中身が全部英字かどうか*1
5.1	alpha_dash	alpha_dash	英字または-または_であるかどうか*1
5.1	alpha_num	alpha_num	英数字であるかどうか*1
5.1	email	email	メールアドレスの形式であるかどうか*2
5.1	url	url	URLの形式であるかどうか(filter_var)
5.1	active_url	active_url	URLが有効かどうか(checkdnsrr)
5.1	ip	ip	ipアドレスの形式かどうか
5.1	json	json	json文字列であるかどうか
5.1	timezone	timezone	タイムゾーンの文字列であるかどうか(timezone_identifiers_list)
5.1	regex	regex:正規表現	正規表現にマッチするかどうか。正規表現にパイプが含まれるときはパイプ不可
5.7	uuid	uuid	フィールドがUUIDの形式にマッチしているかどうか
5.7	starts_with	ends_with:pk_test_,pk_live_	対象の文字列で始まってるかどうか
5.8	ends_with	ends_with:laravel.com,example.com	対象の文字列で終わっているかどうか

*1 ここ最近のバージョンだと、Unicodeの文字が当てはまるようになっており日本語もこの判定ではtrueになってしまいます。別途extendしないとパスワード判定などに使えなくなっているので注意。
*2 5.8からはオプションが指定可能で、rfc strict dns spoof filterが指定できます。5.7まではfilterオプションがデフォルトで利用されています。

日付判定系

Ver	用語	使用例	説明
5.1	date	date	日付かどうか(strtotime)
5.1	date_format	date_format:"Y-m-d"	日付フォーマットが一致しているかどうか。dateと一緒には使えない
5.1	after	after:tomorrow after:start_date	対象の日付以降かどうか(strtotime)。他のフィールドとも比較可能
5.1	before	before:today	↑の日付以前ばーじょん

afterとかbeforeは期間指定とかするときに役立ちそうだよね

数値判定系

Ver	用語	使用例	説明
5.1	integer	integer	整数かどうか
5.1	numeric	numeric	数値かどうか(is_numeric)
5.1	digits	digits:2	数値であり、値の桁数であるかどうか(例では2桁)
5.1	digits_between	digits_between:1,5	数値であり、桁数が最小値から最大値の間かどうか(例だと1~5桁)

配列判定系

Ver	用語	使用例	説明
5.1	array	array	配列かどうか
5.2	distinct	distinct	対象が配列のときに重複がないかどうか

大きさ判定系

Ver	用語	使用例	説明
5.1	size	size:20	指定された値であるかどうか。文字列の場合は文字長で数値なら整数値、ファイルならキロバイトのサイズ。
5.1	min	min:1	指定された値以上かどうか。文字にも数値にもファイルにも使える
5.1	max	max:5	指定された値以下かどうか。文字にも数値にもファイルにも使える
5.1	between	between:1,5	最小値から最大値の間のサイズかどうか。文字にも数値にもファイルにも使える

比較判定系

比較判定系のバリデーションはすでにマージされていて、今後Laravelに入る予定です。←入りました。
minやmaxなどと異なる点は、比較判定系は同じ型であることが要求され、フィールド名を指定することも可能である点です。

Ver	用語	使用例	説明
5.6.21	gt	gt:数値またはフィールド名	対象の数値より大きいかどうか(>)
5.6.21	gte	gte:数値またはフィールド名	対象の数値以上かどうか(>=)
5.6.21	lt	lt:数値またはフィールド名	対象の数値より小さいかどうか(<)
5.6.21	lte	lte:数値またはフィールド名	対象の数値以下かどうか(<=)

ファイル判定系

Ver	用語	使用例	説明
5.2	file	file	ファイルであるかどうか
5.1	image	image	ファイルが画像かどうか(jpg,png,bmp,gif,svg,webp(5.8~))
5.2	dimensions	dimensions:パラメータ	バリデーションする画像がパラメータに指定されたサイズに一致するか(min_width,max_width,min_height,max_height,width,height,raito)
5.1	mimes	mimes:jpg,png	ファイルが指定された拡張子かどうか

dimensionsは5.4からルールの指定をコードでやることも可能。
(Rule::dimensions()->maxWidth(1000)->maxHeight(500)->ratio(3 / 2))

同値チェック

Ver	用語	使用例	説明
5.1	confirmed	confirmed	フィールド名_confirmationフィールドと同値であるかどうか
5.1	same	same:フィールド名	指定したフィールドと同じ値であるかどうか
5.1	different	different:フィールド名	指定フィールドと値が異なるかどうか

その他で、簡単に説明出来ない系

exists

existsは一番把握しにくいと思います。とりあえず、カラムに値が存在するかどうかを判定します。例をたくさん出します。

例1: exists:states
上記の場合は、statesテーブルのフィールド名カラムにフィールドの値が存在することを確認します。なので、"state" => "exists:states"という指定の場合はstatesテーブルのstateカラムということになります。

例2: exists:states,abbreviation
上記の場合は、statesテーブルのabbreviationカラムにフィールドの値が存在することを確認します。

例3: exists:staff,email,account_id,1
staffテーブルのaccount_idが1であるレコードのemailカラムにフィールドの値が存在することを確認します。(つまりwhereです)
1の部分は!を使って条件否定も出来たり、NULLやNOT_NULLの指定も可能です。

例4: Ruleクラス(Existsクラス)を利用した書き方(5.3以降)

例3のようになってくると、コード化しておいたほうがわかりやすいのでこちらを使うほうが良いでしょう。

use Illuminate\Validation\Rule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::exists('staff')->where(function ($query) {
            $query->where('account_id', 1);
        }),
    ],
]);

unique

uniqueは一意であることを確認します。existsとほとんど変わりません。

よくある例は、"email" => "unique:users,email_address"みたいな感じですね。
なお、バリデータは基本的にデフォルトのデータベース接続を行うのでもしも指定したい場合はunique:connection名.usersのようにするみたいです。

existsと違う点は第３パラメータ以降です。existsでは第３パラメータ以降はwhereだったのですが、uniqueの場合は違います。
uniqueの場合、第３パラメータには除外したいIDを指定します。これがある理由は、自身の情報を更新している際にuniqueチェックが入ってしまうとエラーになってしまうからです。
(email以外のフィールドを更新しているのに、emailもformに渡された結果、validationの際にuniqueチェックで失敗する)

また、第４引数には第３引数を適用するカラム名を指定できます。デフォルトではidが指定されています。

この第３、４パラメータを除いて、whereを書くには以下のようにする必要があります。

'email' => 'unique:users,email,NULL,id,account_id,1'

訳:usersテーブルでidカラムがnullの物を除き、account_idが1の物でemailカラムがフィールドの値に存在しないことを確認します。(select count(id) from users where id is not null and account_id = 1 and email = ?みたいな感じだと思われ)

また、5.3以降ではRuleクラス(Uniqueクラス)を利用した書き方も出来ます。

use Illuminate\Validation\Rule;

Validator::make($data, [
    'email' => [
        'required',
        Rule::unique('users')->ignore($user->id),
    ],
]);

required_ifとrequired_unless

例1：required_if:state,0
例2：required_if:flag,1,2

flagフィールドに1または2を持っている場合に、このフィールドが入力されているかを確認します。(例2)unlessの場合は持っていない場合に確認します。

required_withとrequired_with_all

例: required_with:foo,bar

fooまたはbarフィールドが存在している場合だけ、このフィールドが入力されているかを確認します。with_allは指定されているフィールド全てが存在している場合です。

required_withoutとrequired_without_all

上記のrequired_with,with_allの逆バージョンです。存在しない時に入力チェックが走ります。

参考