バリデーション 9.x Laravel

イントロダクション

Laravelは、アプリケーションの受信データをバリデーションするために複数の異なるアプローチを提供します。すべての受信HTTPリクエストで使用可能なvalidateメソッドを使用するのがもっとも一般的です。しかし、バリデーションに対する他のアプローチについても説明します。

Laravelは、データに適用できる便利で数多くのバリデーションルールを持っており、特定のデータベーステーブルで値が一意であるかどうかをバリデーションする機能も提供します。Laravelのすべてのバリデーション機能に精通できるように、各バリデーションルールを詳しく説明します。

クイックスタート

Laravelの強力なバリデーション機能について学ぶため、フォームをバリデーションし、エラーメッセージをユーザーに表示する完全な例を見てみましょう。この高レベルの概要を読むことで、Laravelを使用して受信リクエストデータをバリデーションする一般的な方法を理解できます。

ルート定義

まず、routes/web.phpファイルに以下のルートを定義してあるとしましょう。

use App\Http\Controllers\PostController;

Route::get('/post/create', [PostController::class, 'create']);
Route::post('/post', [PostController::class, 'store']);

GETのルートは新しいブログポストを作成するフォームをユーザーへ表示し、POSTルートで新しいブログポストをデータベースへ保存します。

コントローラ作成

次に、これらのルートへの受信リクエストを処理する単純なコントローラを見てみましょう。今のところ、storeメソッドは空のままにしておきます。

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * 新ブログポスト作成フォームの表示
     *
     * @return \Illuminate\View\View
     */
    public function create()
    {
        return view('post.create');
    }

    /**
     * 新しいブログポストの保存
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\Response
     */
    public function store(Request $request)
    {
        // ブログポストのバリデーションと保存コード…
    }
}

バリデーションロジック

これで、新しいブログ投稿をバリデーションするロジックをstoreメソッドに入力する準備が整いました。これを行うには、Illuminate\Http\Requestオブジェクトによって提供されるvalidateメソッドを使用します。バリデーションルールにパスすると、コードは正常に実行され続けます。しかし、バリデーションに失敗するとIlluminate\Validation\ValidationException例外が投げられ、適切なエラーレスポンスが自動的にユーザーに返送されます。

伝統的なHTTPリクエスト処理中にバリデーションが失敗した場合、直前のURLへのリダイレクトレスポンスが生成されます。受信リクエストがXHRリクエストの場合、バリデーションエラーメッセージを含むJSONレスポンスが返されます。

validateメソッドをもっとよく理解するため、storeメソッドに取り掛かりましょう。

/**
 * 新ブログポストの保存
 *
 * @param  \Illuminate\Http\Request  $request
 * @return \Illuminate\Http\Response
 */
public function store(Request $request)
{
    $validated = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // ブログポストは有効
}

ご覧のとおり、バリデーションルールはvalidateメソッドへ渡されます。心配いりません。利用可能なすべてのバリデーションルールは文書化されています。この場合でもバリデーションが失敗したとき、適切な応答が自動的に生成されます。バリデーションにパスすると、コントローラは正常に実行を継続します。

もしくは、バリデーションルールを|で区切られた一つの文字列の代わりに、ルールの配列で指定することもできます。

$validatedData = $request->validate([
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

さらに、validateWithBagメソッドを使用して、リクエストをバリデーションした結果のエラーメッセージをnamederrorbag内へ保存できます。

$validatedData = $request->validateWithBag('post', [
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

最初のバリデーション失敗時に停止

最初のバリデーションに失敗したら、残りのバリデーションルールの判定を停止したいことも、ときどきあります。このためには、bailルールを使ってください。

$request->validate([
    'title' => 'bail|required|unique:posts|max:255',
    'body' => 'required',
]);

この例の場合、title属性のuniqueルールに失敗すると、maxルールはチェックされません。ルールは指定した順番にバリデートされます。

ネストした属性の注意点

受信HTTPリクエストに「ネストされた」フィールドデータが含まれている場合は、「ドット」構文を使用してバリデーションルールでこうしたフィールドを指定できます。

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

フィールド名にピリオドそのものが含まれている場合は、そのピリオドをバックスラッシュでエスケープし、「ドット」構文として解釈されることを明示的に防げます。

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'v1\.0' => 'required',
]);

バリデーションエラー表示

では、受信リクエストフィールドが指定したバリデーションルールにパスしない場合はどうなるでしょうか。前述のように、Laravelはユーザーを直前の場所へ自動的にリダイレクトします。さらに、すべてのバリデーションエラーとリクエスト入力は自動的にセッションに一時保持保存されます。

$errors変数は、webミドルウェアグループが提供するIlluminate\View\Middleware\ShareErrorsFromSessionミドルウェアにより、アプリケーションのすべてのビューで共有されます。このミドルウェアが適用されると、ビューで$errors変数は常に定義され、$errors変数が常に使用可能になり、安全・便利に使用できると想定できます。$errors変数はIlluminate\Support\MessageBagのインスタンスです。このオブジェクトの操作の詳細は、ドキュメントを確認してください。

この例では、バリデーションに失敗すると、エラーメッセージをビューで表示できるように、コントローラのcreateメソッドへリダイレクトされることになります。

<!-- /resources/views/post/create.blade.php -->

<h1>Create Post</h1>

@if ($errors->any())
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

<!-- Postフォームの作成 -->

エラーメッセージのカスタマイズ

Laravelの組み込みバリデーションルールは、それぞれエラーメッセージを持っており、アプリケーションのlang/en/validation.phpファイルに格納しています。このファイルに各バリデーションルールの翻訳エントリーがあります。アプリケーションに合うように、これらメッセージを自由に変更・修正してください。

さらに、アプリケーションの言語へメッセージを翻訳するために、このファイルを別の翻訳言語ディレクトリにコピーできます。Laravelのローカリゼーションの詳細については、完全な多言語化ドキュメントをご覧ください。

XHRリクエストとバリデーション

この例では、従来のフォームを使用してデータをアプリケーションに送信しました。ただし、多くのアプリケーションは、JavaScriptを利用したフロントエンドからXHRリクエストを受信します。XHRリクエスト中にvalidateメソッドを使用すると、Laravelはリダイレクト応答を生成しません。代わりに、Laravelはすべてのバリデーションエラーを含むJSONレスポンスを生成します。このJSONレスポンスは、422 HTTPステータスコードとともに送信されます。

`@error`ディレクティブ

@errorBladeディレクティブを使用して、特定の属性にバリデーションエラーメッセージが存在するかどうかを簡単に判断できます。@errorディレクティブ内で、$message変数をエコーしてエラーメッセージを表示ができます。

<!-- /resources/views/post/create.blade.php -->

<label for="title">Post Title</label>

<input id="title"
    type="text"
    name="title"
    class="@error('title') is-invalid @enderror">

@error('title')
    <div class="alert alert-danger">{{ $message }}</div>
@enderror

名前付きエラーバッグを使用している場合は、エラーバッグの名前を @error ディレクティブの第2引数へ渡せます。

<input ... class="@error('title', 'post') is-invalid @enderror">

フォームの再取得

Laravelがバリデーションエラーのためにリダイレクトレスポンスを生成するとき、フレームワークは自動的にセッションへのリクエストのすべての入力を一時保持保存します。これは、直後のリクエスト時、保存しておいた入力に簡単にアクセスし、ユーザーが送信しようとしたフォームを再入力・再表示できるようにします。

直前のリクエストから一時保持保存された入力を取得するには、Illuminate\Http\Requestのインスタンスでoldメソッドを呼び出します。oldメソッドは、直前に一時保持保存した入力データをsessionから取り出します。

$title = $request->old('title');

Laravelはグローバルなoldヘルパも提供しています。Bladeテンプレート内に古い入力を表示している場合は、oldヘルパを使用してフォームを再入力・再表示する方が便利です。指定されたフィールドに古い入力が存在しない場合、nullが返されます。

<input type="text" name="title" value="{{ old('title') }}">

オプションフィールドに対する注意

LaravelはTrimStringsとConvertEmptyStringsToNullミドルウェアをアプリケーションのデフォルトグローバルミドルウェアスタックに含んでいます。これらのミドルウェアはApp\Http\Kernelクラスでリストされています。このため、バリデータがnull値を無効であると判定しないように、オプションフィールドへnullableを付ける必要が頻繁に起きるでしょう。

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
    'publish_at' => 'nullable|date',
]);

上記の例の場合、publish_atフィールドがnullか、有効な日付表現であることを指定しています。ルール定義にnullableが追加されないと、バリデータはnullを無効な日付として判定します。

バリデーションエラーのレスポンス形式

受信HTTPリクエストがJSONレスポンスを期待しており、アプリケーションがIlluminate\Validation\ValidationException例外を投げる場合、Laravelは自動的にエラーメッセージをフォーマットして、422 Unprocessable Entity HTTPレスポンスを返します。

以下に、バリデーションエラーのJSONレスポンスフォーマット例を示します。ネストしたエラーのキーは、「ドット」記法で１次元化されることに注意してください。

{
    "message": "The team name must be a string. (and 4 more errors)",
    "errors": {
        "team_name": [
            "The team name must be a string.",
            "The team name must be at least 1 characters."
        ],
        "authorization.role": [
            "The selected authorization.role is invalid."
        ],
        "users.0.email": [
            "The users.0.email field is required."
        ],
        "users.2.email": [
            "The users.2.email must be a valid email address."
        ]
    }
}

フォームリクエストバリデーション

フォームリクエスト作成

より複雑なバリデーションシナリオの場合は、「フォームリクエスト」を作成することをお勧めします。フォームリクエストは、独自のバリデーションおよび認可ロジックをカプセル化するカスタムリクエストクラスです。フォームリクエストクラスを作成するには、make:request Artisan CLIコマンドを使用します。

php artisan make:request StorePostRequest

生成したフォームリクエストクラスは、app/Http/Requestsディレクトリに配置されます。このディレクトリが存在しない場合は、make:requestコマンドの実行時に作成されます。Laravelにより生成される各フォームリクエストには、authorizeとrulesの2つのメソッドがあります。

ご想像のとおり、authorizeメソッドは、現在認証されているユーザーがリクエストによって表されるアクションを実行できるかどうかを判断し、rulesメソッドはリクエスト中のデータを検証するバリデーションルールを返します。

/**
 * リクエストに適用するバリデーションルールを取得
 *
 * @return array
 */
public function rules()
{
    return [
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ];
}

Note: rulesメソッドの引数で必要な依存関係をタイプヒントにより指定することができます。それらはLaravelサービスコンテナを介して自動的に依存解決されます。

では、どのようにバリデーションルールを実行するのでしょうか？必要なのはコントローラのメソッドで、このリクエストをタイプヒントで指定することです。やって来たフォームリクエストはコントローラメソッドが呼び出される前にバリデーションを行います。つまり、コントローラでバリデーションロジックを取っ散らかす必要はありません。

/**
 * 新ブログポストの保存
 *
 * @param  \App\Http\Requests\StorePostRequest  $request
 * @return Illuminate\Http\Response
 */
public function store(StorePostRequest $request)
{
    // 送信されたリクエストは正しい

    // バリデーション済みデータの取得
    $validated = $request->validated();

    // バリデーション済み入力データの一部を取得
    $validated = $request->safe()->only(['name', 'email']);
    $validated = $request->safe()->except(['name', 'email']);
}

バリデーションが失敗した場合、リダイレクトレスポンスが生成され、ユーザーを直前の場所に送り返します。エラーもセッションに一時保持され、表示できます。リクエストがXHRリクエストの場合、422ステータスコードで、バリデーションエラーのJSON表現を含むHTTPレスポンスがユーザーに返されます。

フォームリクエストへのAfterフックを追加

フォームリクエストに"after"のバリデーションフックを追加する場合は、withValidatorメソッドを使用します。このメソッドは完全に構築されたバリデータを受け取り、バリデーションルールの実際の評価前に、メソッドのいずれでも呼び出せます。

/**
 * バリデータインスタンスの設定
 *
 * @param  \Illuminate\Validation\Validator  $validator
 * @return void
 */
public function withValidator($validator)
{
    $validator->after(function ($validator) {
        if ($this->somethingElseIsInvalid()) {
            $validator->errors()->add('field', 'Something is wrong with this field!');
        }
    });
}

最初のバリデーション失敗属性で停止

リクエストクラスにstopOnFirstFailureプロパティを追加することで、バリデーションの失敗が起きてすぐに、すべての属性のバリデーションを停止する必要があることをバリデータへ指示できます。

/**
 * バリデータが最初のルールの失敗で停止するかを指示
 *
 * @var bool
 */
protected $stopOnFirstFailure = true;

リダイレクト先のカスタマイズ

前述のとおり、フォームリクエストのバリデーションに失敗した場合、ユーザーを元の場所に戻すためのリダイレクトレスポンスが生成されます。しかし、この動作は自由にカスタマイズ可能です。それには、フォームのリクエストで、$redirectプロパティを定義します。

/**
 * バリデーション失敗時に、ユーザーをリダイレクトするURI
 *
 * @var string
 */
protected $redirect = '/dashboard';

または、ユーザーを名前付きルートへリダイレクトする場合は、$redirectRouteプロパティを代わりに定義します。

/**
 * バリデーション失敗時に、ユーザーをリダイレクトするルート
 *
 * @var string
 */
protected $redirectRoute = 'dashboard';

フォームリクエストの認可

フォームリクエストクラスには、authorizeメソッドも含まれています。このメソッド内で、認証済みユーザーが特定のリソースを更新する権限を持っているかどうかを判別できます。たとえば、ユーザーが更新しようとしているブログコメントを実際に所有しているかどうかを判断できます。ほとんどの場合、次の方法で認可ゲートとポリシーを操作します。

use App\Models\Comment;

/**
 * ユーザーがこのリクエストの権限を持っているかを判断する
 *
 * @return bool
 */
public function authorize()
{
    $comment = Comment::find($this->route('comment'));

    return $comment && $this->user()->can('update', $comment);
}

全フォームリクエストはLaravelのベースリクエストクラスを拡張していますので、現在認証済みユーザーへアクセスする、userメソッドが使えます。また、上記例中のrouteメソッドの呼び出しにも、注目してください。たとえば{comment}パラメーターのような、呼び出しているルートで定義してあるURIパラメータにもアクセスできます。

Route::post('/comment/{comment}');

したがって、アプリケーションがルートモデル結合を利用している場合、解決されたモデルをリクエストのプロパティとしてアクセスすることで、コードをさらに簡潔にすることができます。

return $this->user()->can('update', $this->comment);

authorizeメソッドがfalseを返すと、403ステータスコードのHTTPレスポンスを自動的に返し、コントローラメソッドは実行しません。

アプリケーションの別の部分でリクエストの認可ロジックを処理する場合は、authorizeメソッドからtrueを返してください。

/**
 * ユーザーがこのリクエストの権限を持っているかを判断する
 *
 * @return bool
 */
public function authorize()
{
    return true;
}

Note: authorizeメソッドの引数で、必要な依存をタイプヒントにより指定できます。それらはLaravelのサービスコンテナにより、自動的に依存解決されます。

エラーメッセージのカスタマイズ

フォームリクエストにより使用されているメッセージはmessageメソッドをオーバーライドすることによりカスタマイズできます。このメソッドから属性／ルールと対応するエラーメッセージのペアを配列で返してください。

/**
 * 定義済みバリデーションルールのエラーメッセージ取得
 *
 * @return array
 */
public function messages()
{
    return [
        'title.required' => 'A title is required',
        'body.required' => 'A message is required',
    ];
}

バリデーション属性のカスタマイズ

Laravelの組み込みバリデーションルールエラーメッセージの多くは、:attributeプレースホルダーを含んでいます。バリデーションメッセージの:attributeプレースホルダーをカスタム属性名に置き換えたい場合は、attributesメソッドをオーバーライドしてカスタム名を指定します。このメソッドは、属性と名前のペアの配列を返す必要があります。

/**
 * バリデーションエラーのカスタム属性の取得
 *
 * @return array
 */
public function attributes()
{
    return [
        'email' => 'email address',
    ];
}

検証のための入力準備

バリデーションルールを適用する前にリクエストからのデータを準備またはサニタイズする必要がある場合は、prepareForValidationメソッド使用します。

use Illuminate\Support\Str;

/**
 * バリーデーションのためにデータを準備
 *
 * @return void
 */
protected function prepareForValidation()
{
    $this->merge([
        'slug' => Str::slug($this->slug),
    ]);
}

同様に、バリデーションが完了した後にリクエストデータをノーマライズする必要がある場合は、 passedValidation メソッドを使用します。

use Illuminate\Support\Str;

/**
 * Handle a passed validation attempt.
 *
 * @return void
 */
protected function passedValidation()
{
    $this->replace(['name' => 'Taylor']);
}

バリデータの生成

リクエストのvalidateメソッドを使用したくない場合は、Validatorファサードを使用し、バリデータインスタンスを生成する必要があります。このファサードのmakeメソッドで、新しいバリデータインスタンスを生成します。

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;

class PostController extends Controller
{
    /**
     * 新しいブログポストの保存
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        $validator = Validator::make($request->all(), [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ]);

        if ($validator->fails()) {
            return redirect('post/create')
                        ->withErrors($validator)
                        ->withInput();
        }

        // バリデーション済みデータの取得
        $validated = $validator->validated();

        // バリデーション済みデータの一部を取得
        $validated = $validator->safe()->only(['name', 'email']);
        $validated = $validator->safe()->except(['name', 'email']);

        // ブログポストの保存処理…
    }
}

makeメソッドの第１引数は、バリデーションを行うデータです。第２引数はそのデータに適用するバリデーションルールの配列です。

リクエストのバリデーションが失敗したかどうかを判断した後、withErrorsメソッドを使用してエラーメッセージをセッションに一時保持保存できます。この方法を使用すると、リダイレクト後に$errors変数がビューと自動的に共有されるため、メッセージをユーザーへ簡単に表示できます。withErrorsメソッドは、バリデータ、MessageBag、またはPHPのarrayを引数に取ります。

最初のバリデーション失敗時に停止

stopOnFirstFailureメソッドは、バリデーションが失敗したら、すぐにすべての属性のバリデーションを停止する必要があることをバリデータへ指示します。

if ($validator->stopOnFirstFailure()->fails()) {
    // ...
}

自動リダイレクト

バリデータインスタンスを手作業で作成するが、HTTPリクエストのvalidateメソッドによって提供される自動リダイレクトを利用したい場合は、既存のバリデータインスタンスでvalidateメソッドを呼び出すことができます。バリデーションが失敗した場合、ユーザーは自動的にリダイレクトされます。XHRリクエストの場合は、JSONレスポンスが返されます。

Validator::make($request->all(), [
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
])->validate();

validateWithBagメソッドを使用しリクエストのバリデートを行った結果、失敗した場合に、エラーメッセージを名前付きエラーバッグへ保存することもできます。

Validator::make($request->all(), [
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
])->validateWithBag('post');

名前付きエラーバッグ

1つのページに複数のフォームがある場合は、バリデーションエラーを含むMessageBagに名前を付けて、特定のフォームのエラーメッセージを取得可能にできます。これを実現するには、withErrorsの２番目の引数として名前を渡します。

return redirect('register')->withErrors($validator, 'login');

$errors変数を使い、名前を付けたMessageBagインスタンスへアクセスできます。

{{ $errors->login->first('email') }}

エラーメッセージのカスタマイズ

必要に応じて、Laravelが提供するデフォルトのエラーメッセージの代わりにバリデータインスタンスが使用するカスタムエラーメッセージを指定できます。カスタムメッセージを指定する方法はいくつかあります。まず、カスタムメッセージをvalidator::makeメソッドに３番目の引数として渡す方法です。

$validator = Validator::make($input, $rules, $messages = [
    'required' => 'The :attribute field is required.',
]);

この例の、:attributeプレースホルダーは、バリデーション中のフィールドの名前に置き換えられます。バリデーションメッセージには他のプレースホルダーも利用できます。例をご覧ください。

$messages = [
    'same' => 'The :attribute and :other must match.',
    'size' => 'The :attribute must be exactly :size.',
    'between' => 'The :attribute value :input is not between :min - :max.',
    'in' => 'The :attribute must be one of the following types: :values',
];

特定の属性に対するカスタムメッセージ指定

特定の属性に対してのみカスタムエラーメッセージを指定したい場合があります。「ドット」表記を使用してこれを行うことができます。最初に属性の名前を指定し、次にルールを指定します。

$messages = [
    'email.required' => 'We need to know your email address!',
];

カスタム属性値の指定

Laravelの組み込みエラーメッセージの多くには、バリデーション中のフィールドや属性の名前に置き換えられる:attributeプレースホルダーが含まれています。特定のフィールドでこれらのプレースホルダーを置き換える値をカスタマイズするには、カスタム属性表示名の配列を4番目の引数としてValidator::makeメソッドに渡します。

$validator = Validator::make($input, $rules, $messages, [
    'email' => 'email address',
]);

バリデーション後のフック

バリデーションが完了した後に実行するコールバックを添付することもできます。これにより、追加のバリデーションを簡単に実行し、メッセージコレクションにエラーメッセージを追加することもできます。利用するには、バリデータインスタンスでafterメソッドを呼び出します。

$validator = Validator::make(/* ... */);

$validator->after(function ($validator) {
    if ($this->somethingElseIsInvalid()) {
        $validator->errors()->add(
            'field', 'Something is wrong with this field!'
        );
    }
});

if ($validator->fails()) {
    //
}

バリデーション済み入力の利用

フォームのリクエストや手作業で作成したバリデータのインスタンスを使ってリクエストデータをバリデーションした後に、バリデーション済みの受信リクエストデータを取得したいと思われるかもしれません。これには方法がいくつかあります。まず、フォームのリクエストやバリデータインスタンスのvalidatedメソッドを呼び出す方法です。このメソッドは、バリデーション済みデータの配列を返します。

$validated = $request->validated();

$validated = $validator->validated();

他に、フォームリクエストやバリデータのインスタンスに対して、safeメソッドを呼び出すこともできます。このメソッドは、Illuminate\Support\ValidatedInputのインスタンスを返します。このオブジェクトはonly、except、allメソッドを用意しており、バリデーション済みデータのサブセットや配列全体を取得できます。

$validated = $request->safe()->only(['name', 'email']);

$validated = $request->safe()->except(['name', 'email']);

$validated = $request->safe()->all();

さらに、Illuminate\Support\ValidatedInputインスタンスをループで配列のようにアクセスすることもできます。

// バリデーション済みデータをループ
foreach ($request->safe() as $key => $value) {
    //
}

// バリデーション済みデータを配列としてアクセス
$validated = $request->safe();

$email = $validated['email'];

バリデーション済みデータへさらにフィールドを追加したい場合は、mergeメソッドを呼び出します。

$validated = $request->safe()->merge(['name' => 'Taylor Otwell']);

バリデーション済みデータをコレクションインスタンスとして取得したい場合は、collectメソッドを呼び出します。

$collection = $request->safe()->collect();

エラーメッセージの操作

Validatorインスタンスのerrorsメソッドを呼び出すと、エラーメッセージを操作する便利なメソッドを数揃えた、Illuminate\Support\MessageBagインスタンスを受け取ります。自動的に作成され、すべてのビューで使用できる$errors変数も、MessageBagクラスのインスタンスです。

指定フィールドの最初のエラーメッセージ取得

指定したフィールドの最初のエラーメッセージを取得するには、firstメソッドを使います。

$errors = $validator->errors();

echo $errors->first('email');

指定フィールドの全エラーメッセージ取得

指定したフィールドの全エラーメッセージを配列で取得したい場合は、getメソッドを使います。

foreach ($errors->get('email') as $message) {
    //
}

配列形式のフィールドをバリデーションする場合は、*文字を使用し、各配列要素の全メッセージを取得できます。

foreach ($errors->get('attachments.*') as $message) {
    //
}

全フィールドの全エラーメッセージ取得

全フィールドの全メッセージの配列を取得したい場合は、allメソッドを使います。

foreach ($errors->all() as $message) {
    //
}

指定フィールドのメッセージ存在確認

hasメソッドは、指定したフィールドのエラーメッセージが存在しているかを判定するために使います。

if ($errors->has('email')) {
    //
}

言語ファイルでのカスタムメッセージの指定

特定の属性のカスタムメッセージ

アプリケーションのバリデーション言語ファイルでは、特定の属性とルールの組み合わせで使用するエラーメッセージをカスタマイズできます。これを実現するには、アプリケーションのlang/xx/validation.php言語ファイルのcustom配列に、カスタマイズメッセージを追加します。

'custom' => [
    'email' => [
        'required' => 'We need to know your email address!',
        'max' => 'Your email address is too long!'
    ],
],

言語ファイルでの属性の指定

Laravelの組み込みエラーメッセージの多くには、:attributeプレースホルダーが含まれており、バリデーション中のフィールドや属性の名前に置き換えられます。もし、バリデーションメッセージの:attribute部分をカスタム値に置き換えたい場合は、言語ファイルlang/xx/validation.phpのattributes配列でカスタム属性名を指定できます。

'attributes' => [
    'email' => 'email address',
],

言語ファイルでの値の指定

Laravelの組み込みバリデーションルールエラーメッセージの一部には、リクエスト属性の現在の値に置き換えられる:valueプレースホルダーが含まれています。ただし、バリデーションメッセージの:value部分を値のカスタム表現へ置き換えたい場合があるでしょう。たとえば、payment_typeの値がccの場合にクレジットカード番号が必要であることを定義する次のルールについて考えてみます。

Validator::make($request->all(), [
    'credit_card_number' => 'required_if:payment_type,cc'
]);

このバリデーションルールが通らない場合に、次のようなメッセージが表示されるとします。

The credit card number field is required when payment type is cc.

支払タイプの値にccと表示する代わりに、lang/xx/validation.php言語ファイルでvalues配列を定義し、よりユーザーフレンドリーな値表現を指定できます。

'values' => [
    'payment_type' => [
        'cc' => 'credit card'
    ],
],

この値を定義したら、バリデーションルールは次のエラーメッセージを生成します。

The credit card number field is required when payment type is credit card.

使用可能なバリデーションルール

使用可能な全バリデーションルールとその機能の一覧です。

受け入れ条件一致時受け入れアクティブなURL （日付）より後（日付）以降アルファベットアルファベット記号アルファベット数字配列 Ascii 継続終了（日付）より前（日付）以前範囲論理確認現在のパスワード日付同一日付日付形式 Decimal 拒否条件一致時拒否相違桁指定数値桁範囲指定数値寸法(画像ファイル) 別々文字列非開始文字列非終了メールアドレス文字列終了列挙型除外条件一致時フィールド除外条件不一致時フィールド除外存在時フィールド除外不在時フィールド除外存在（データベース）ファイル充満より大きい以上画像（ファイル) 内包配列内整数 IPアドレス JSON より小さい以下小文字 MACアドレス最大値最大桁数 MIMEタイプ MIMEタイプ(ファイル拡張子) 最小値最小桁数非入力条件一致時非入力条件不一致時非入力存在時非入力全不在時非入力倍数値非内包正規表現不一致 NULL許可数値パスワード存在禁止禁止If 禁止Unless 他フィールド禁止正規表現必須指定フィールド値一致時必須指定フィールド値非一致時必須指定フィールド存在時必須全指定フィールド存在時必須指定フィールド非存在時必須全指定フィールド非存在時必須配列かつキー包含必須同一サイズ存在時バリデート実行文字列開始文字列タイムゾーン一意（データベース）大文字 URL ULID UUID

accepted

フィールドが、"yes"、"on"、1、またはtrueであることをバリデートします。これは、「利用規約」の承認または同様のフィールドをバリデーションするのに役立ちます。

accepted_if:他のフィールド,値,...

他のフィールドが指定した値と等しい場合、このフィールドは "yes"、"on"、1、trueであることをバリデートします。これは、"Terms of Service "の了承や似たようなフィールドをバリデートするのに便利です。

active_url

フィールドが、dns_get_record PHP関数により、有効なAかAAAAレコードであることをバリデートします。dns_get_recordへ渡す前に、parse_url PHP関数により指定したURLのホスト名を切り出します。

after:日付

フィールドは、指定された日付以降の値であることをバリデートします。日付を有効なDateTimeインスタンスに変換するため、strtotimePHP関数に渡します。

'start_date' => 'required|date|after:tomorrow'

strtotimeにより評価される日付文字列を渡す代わりに、その日付と比較する他のフィールドを指定することもできます。

'finish_date' => 'required|date|after:start_date'

after_or_equal:日付

フィールドが指定した日付以降であることをバリデートします。詳細はafterルールを参照してください。

alpha

フィールドは、\p{L}、並びに\p{M}に含まれる、Unicodeのアルファベット文字のみであることをバリデートします。

このバリデーションルールをASCII文字（a-zとA-Z）の範囲に限定したい場合は、asciiオプションを指定してください。

'username' => 'alpha:ascii',

alpha_dash

フィールドは、\p{L}、並びに\p{M}、\p{N}に含まれる、Unicodeのアルファベット文字と数字、およびASCIIのダッシュ(-)とASCIIの下線(_)であることをバリデートします。

このバリデーションルールをASCII文字（a-zとA-Z）の範囲に限定したい場合は、asciiオプションを指定してください。

'username' => 'alpha_dash:ascii',

alpha_num

フィールドは、\p{L}、並びに\p{M}、\p{N}に含まれる、Unicodeのアルファベット文字と数字のみであることをバリデートします。

このバリデーションルールをASCII文字（a-zとA-Z）の範囲に限定したい場合は、asciiオプションを指定してください。

'username' => 'alpha_num:ascii',

array

フィールドがPHPの配列タイプであることをバリデートします。

arrayルールに追加の値を指定する場合、入力配列の各キーは、ルールに指定した値のリスト内に存在する必要があります。次の例では、入力配列のadminキーは、arrayルールにした値のリストに含まれていないので、無効です。

use Illuminate\Support\Facades\Validator;

$input = [
    'user' => [
        'name' => 'Taylor Otwell',
        'username' => 'taylorotwell',
        'admin' => true,
    ],
];

Validator::make($input, [
    'user' => 'array:name,username',
]);

一般に、配列に存在を許すキーは、常に指定する必要があります。

ascii

フィールドが全て７ビットのアスキー文字であることをバリデートします。

bail

フィールドでバリデーションにはじめて失敗した時点で、残りのルールのバリデーションを中止します。

bailルールはバリデーションが失敗したときに、特定のフィールドのバリデーションのみを停止するだけで、一方のstopOnFirstFailureメソッドは、ひとつバリデーション失敗が発生したら、すべての属性のバリデーションを停止する必要があることをバリデータに指示します。

if ($validator->stopOnFirstFailure()->fails()) {
    // ...
}

before:日付

フィールドは、指定された日付より前の値であることをバリデートします。日付を有効なDateTimeインスタンスへ変換するために、PHPのstrtotime関数へ渡します。さらに、afterルールと同様に、バリデーション中の別のフィールドの名前をdateの値として指定できます。

before_or_equal:日付

フィールドは、指定された日付より前または同じ値であることをバリデートします。日付を有効なDateTimeインスタンスへ変換するために、PHPのstrtotime関数へ渡します。さらに、afterルールと同様に、バリデーション中の別のフィールドの名前をdateの値として指定できます。

between:min,max

フィールドが指定した最小値以上で、最大値以下のサイズであることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、配列、ファイルが評価されます。

boolean

フィールドが論理値として有効であることをバリデートします。受け入れられる入力は、true、false、1、0、"1"、"0"です。

confirmed

フィールドが、{field}_confirmationフィールドと一致する必要があります。たとえば、バリデーション中のフィールドが「password」の場合、「password_confirmation」フィールドが入力に存在し一致している必要があります。

current_password

フィールドが、認証されているユーザーのパスワードと一致することをバリデートします。ルールの最初のパラメータで、認証ガードを指定できます。

'password' => 'current_password:api'

date

パリデーションされる値はPHP関数のstrtotimeにより、有効で相対日付ではないことをバリデートします。

date_equals:日付

フィールドが、指定した日付と同じことをバリデートします。日付を有効なDateTimeインスタンスに変換するために、PHPのstrtotime関数へ渡します。

date_format:フォーマット,…

バリデーションされる値が、指定するフォーマット定義のどれか一つと一致するかバリデートします。バリデーション時にはdateかdate_formatのどちらかを使用しなくてはならず、両方はできません。このバリデーションはPHPのDateTimeクラスがサポートするフォーマットをすべてサポートしています。

decimal:min,max

フィールドが数値であり、指定された小数点以下の桁数を含んでいることをバリデートします。

// 小数点以下が2桁ピッタリの必要がある(9.99)
'price' => 'decimal:2'

// 小数点以下が２から４桁である必要がある
'price' => 'decimal:2,4'

declined

フィールドが"no"、"off"、0、falseであることをバリデートします。

declined_if:他のフィールド,値,...

他のフィールドが指定した値と等しい場合、このフィールドは"no", "off", 0, or falseであることをバリデートします。

different:フィールド

フィールドが指定されたフィールドと異なった値を指定されていることをバリデートします。

digits:値

フィールドが整数で、値の桁数であることをバリデートします。

digits_between:最小値,最大値

フィールドが整数で、桁数が最小値から最大値の間であることをバリデートします。

dimensions

バリデーション対象のファイルが、パラメータにより指定されたサイズに合致することをバリデートします。

'avatar' => 'dimensions:min_width=100,min_height=200'

使用可能なパラメータは、min_width、max_width、min_height、max_height、width、height、ratioです。

ratio制約は、幅を高さで割ったものとして表す必要があります。これは、3/2のような分数または1.5のようなfloatのいずれかで指定します。

'avatar' => 'dimensions:ratio=3/2'

このルールは多くの引数を要求するので、Rule::dimensionsメソッドを使い、記述的にこのルールを構築してください。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($data, [
    'avatar' => [
        'required',
        Rule::dimensions()->maxWidth(1000)->maxHeight(500)->ratio(3 / 2),
    ],
]);

distinct

配列のバリデーション時、フィールドに重複した値がないことをバリデートします。

'foo.*.id' => 'distinct'

distinctはデフォルトで緩い比較を使用します。厳密な比較を使用するには、検証ルール定義にstrictパラメータを追加することができます。

'foo.*.id' => 'distinct:strict'

バリデーションルールの引数にignore_caseを追加して、大文字と小文字の違いを無視するルールを加えられます。

'foo.*.id' => 'distinct:ignore_case'

doesnt_start_with:foo,bar,...

フィールドの値が指定した値で開始しないことをバリデートします。

doesnt_end_with:foo,bar,...

フィールドの値が指定した値で終了しないことをバリデートします。

email

バリデーション中のフィールドは、電子メールアドレスのフォーマットである必要があります。このバリデーションルールは、egulias/email-validatorパッケージを使用して電子メールアドレスをバリデーションします。デフォルトではRFCValidationバリデータが適用されますが、他のバリデーションスタイルを適用することもできます。

'email' => 'email:rfc,dns'

上記の例では、RFCValidationとDNSCheckValidationバリデーションを適用しています。適用可能なバリデーションスタイルは、次の通りです。

rfc: RFCValidation
strict: NoRFCWarningsValidation
dns: DNSCheckValidation
spoof: SpoofCheckValidation
filter: FilterEmailValidation
filter_unicode: FilterEmailValidation::unicode()

PHPのfilter_var関数を使用するfilterバリデータは、Laravelに付属しており、Laravelバージョン5.8より前のLaravelのデフォルトの電子メールバリデーション動作でした。

Warning!! dnsおよびspoofバリデータには、PHPのintl拡張が必要です。

ends_with:foo,bar,...

フィールドの値が、指定された値で終わることをバリデートします。

enum

Enumルールはクラスベースのルールで、対象のフィールドに有効なenumの値が含まれているかどうかをバリデートします。Enumルールは、コンストラクタの引数に唯一、enumの名前を取ります。

use App\Enums\ServerStatus;
use Illuminate\Validation\Rules\Enum;

$request->validate([
    'status' => [new Enum(ServerStatus::class)],
]);

Warning!! Enumsは、PHP8.1以上のバージョンで使用できます。

exclude

フィルードの値がvalidateとvalidatedメソッドが返すリクエストデータから除外されていることをバリデートします。

exclude_if:他のフィールド,値

他のフィールドが値と等しい場合、validateとvalidatedメソッドが返すリクエストデータから、バリデーション指定下のフィールドが除外されます。

複雑な条件付き除外ロジックが必要な場合は、Rule::excludeIfメソッドが便利です。このメソッドは、論理値かクロージャを引数に取ります。クロージャを指定する場合、そのクロージャは、trueまたはfalseを返し、バリデーション中のフィールドを除外するかしないかを示す必要があります。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($request->all(), [
    'role_id' => Rule::excludeIf($request->user()->is_admin),
]);

Validator::make($request->all(), [
    'role_id' => Rule::excludeIf(fn () => $request->user()->is_admin),
]);

exclude_unless:他のフィールド,値

他のフィールドが値と等しくない場合、validateとvalidatedメソッドが返すリクエストデータから、バリデーション指定下のフィールドが除外されます。もし値がnull（exclude_unless:name,null）の場合は、比較フィールドがnullであるか、比較フィールドがリクエストデータに含まれていない限り、バリデーション指定下のフィールドは除外されます。

exclude_with:他のフィールド

他のフィールドが存在する場合、validateとvalidatedメソッドが返すリクエストデータから、バリデーション指定可のフィールドが除外されます。

exclude_without:他のフィールド

他のフィールドが存在しない場合、validateとvalidatedメソッドが返すリクエストデータから、バリデーション指定下のフィールドが除外されます。

exists:テーブル,カラム

フィールドは、指定のデータベーステーブルに存在する必要があります。

基本的なExistsルールの使用法

'state' => 'exists:states'

columnオプションが指定されていない場合、フィールド名が使用されます。したがって、この場合、ルールは、statesデータベーステーブルに、リクエストのstate属性値と一致するstateカラム値を持つレコードが含まれていることをバリデーションします。

カスタムカラム名の指定

データベーステーブル名の後に配置することで、バリデーションルールで使用するデータベースカラム名を明示的に指定できます。

'state' => 'exists:states,abbreviation'

場合によっては、existsクエリに使用する特定のデータベース接続を指定する必要があります。これは、接続名をテーブル名の前に付けることで実現できます。

'email' => 'exists:connection.staff,email'

テーブル名を直接指定する代わりに、Eloquentモデルを指定することもできます。

'user_id' => 'exists:App\Models\User,id'

バリデーションルールで実行されるクエリをカスタマイズしたい場合は、ルールをスラスラと定義できるRuleクラスを使ってください。下の例では、|文字を区切りとして使用する代わりに、バリデーションルールを配列として指定しています。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

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

Rule::existsメソッドが生成する、existsルールで使用するデータベースカラム名は、existsメソッドの第２引数として明示的に指定できます。

'state' => Rule::exists('states', 'abbreviation'),

file

フィールドがアップロードに成功したファイルであることをバリデートします。

filled

フィールドが存在する場合、空でないことをバリデートします。

gt:field

フィールドが指定したフィールドより大きいことをバリデートします。２つのフィールドは同じタイプでなくてはなりません。文字列、数値、配列、ファイルは、sizeルールと同じ規約により評価します。

gte:field

フィールドが指定したフィールド以上であることをバリデートします。２つのフィールドは同じタイプでなくてはなりません。文字列、数値、配列、ファイルは、sizeルールと同じ規約により評価します。

image

ファイルは画像（jpg、jpeg、png、bmp、gif、svg、webp）である必要があります。

in:foo,bar...

フィールドが指定したリストの中の値に含まれていることをバリデートします。このルールを使用するために配列をimplodeする必要が多くなりますので、ルールを記述的に構築するには、Rule::inメソッドを使ってください。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($data, [
    'zones' => [
        'required',
        Rule::in(['first-zone', 'second-zone']),
    ],
]);

inルールとarrayルールを組み合わせた場合、入力配列の各値は、inルールに指定した値のリスト内に存在しなければなりません。次の例では，入力配列中のLAS空港コードは，inルールへ指定した空港のリストに含まれていないため無効です。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

$input = [
    'airports' => ['NYC', 'LAS'],
];

Validator::make($input, [
    'airports' => [
        'required',
        'array',
    ],
    'airports.*' => Rule::in(['NYC', 'LIT']),
]);

in_array:他のフィールド.*

フィールドが、他のフィールドの値のどれかであることをバリデートします。

integer

フィールドが整数値であることをバリデートします。

Warning!! このバリデーションルールは、入力が「整数」変数タイプであるか確認しません。入力がPHPのFILTER_VALIDATE_INTルールで受け入れられるか検証するだけです。入力を数値として検証する必要がある場合は、このルールをnumericバリデーションルールと組み合わせて使用してください。

ip

フィールドがIPアドレスの形式として正しいことをバリデートします。

ipv4

フィールドがIPv4アドレスの形式として正しいことをバリデートします。

ipv6

フィールドがIPv6アドレスの形式として正しいことをバリデートします。

json

フィールドが有効なJSON文字列であることをバリデートします。

lt:field

フィールドが指定したフィールドより小さいことをバリデートします。２つのフィールドは同じタイプでなくてはなりません。文字列、数値、配列、ファイルは、sizeルールと同じ規約により評価します。

lte:field

フィールドが指定したフィールド以下であることをバリデートします。２つのフィールドは同じタイプでなくてはなりません。文字列、数値、配列、ファイルは、sizeルールと同じ規約により評価します。

lowercase

フィールドが小文字であることをバリデートします。

mac_address

フィールドがMACアドレスとして正しいことをバリデートします。

max:値

フィールドが最大値として指定された値以下であることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、配列、ファイルが評価されます。

max_digits:value

整数フィールドが、最大値桁数以下であることをバリデートします。

mimetypes:text/plain,...

フィールドが指定されたMIMEタイプのどれかであることをバリデートします。

'video' => 'mimetypes:video/avi,video/mpeg,video/quicktime'

アップロードしたファイルのMIMEタイプを判別するために、ファイルの内容が読み取られ、フレームワークはMIMEタイプを推測します。これは、クライアントが提供するMIMEタイプとは異なる場合があります。

mimes:foo,bar,...

フィールドで指定されたファイルが拡張子のリストの中のMIMEタイプのどれかと一致することをバリデートします。

MIMEルールの基本的な使用法

'photo' => 'mimes:jpg,bmp,png'

拡張子を指定するだけでもよいのですが、このルールは実際には、ファイルの内容を読み取ってそのMIMEタイプを推測することにより、ファイルのMIMEタイプをバリデーションします。MIMEタイプとそれに対応する拡張子の完全なリストは、次の場所にあります。

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

min:値

フィールドが最小値として指定された値以上であることをバリデートします。sizeルールと同様の判定方法で、文字列、数値、配列、ファイルが評価されます。

min_digits:value

整数フィールドが、最小値桁数以上であることをバリデートします。

multiple_of:値

フィールドが、値の倍数であることをバリデートします。

missing

フィールドが入力データ中に存在しないことをバリデートします。

missing_if:他のフィールド,値,...

他のフィールドが値のどれかと等しい場合、フィールドが入力データ中に存在しないことをバリデートします。

missing_unless:他のフィールド,値

他のフィールドが値の全てに一致しない場合、フィールドが入力データ中に存在しないことをバリデートします。

missing_with:foo,bar,...

指定したフィールドのどれかが存在する場合のみ、フィールドが入力データ中に存在しないことをバリデートします。

missing_with_all:foo,bar,...

指定したフィールド全てが存在する場合のみ、フィールドが入力データ中に存在しないことをバリデートします。

not_in:foo,bar,...

フィールドが指定された値のリスト中に含まれていないことをバリデートします。Rule::notInメソッドのほうが、ルールの構成が読み書きしやすいでしょう。

use Illuminate\Validation\Rule;

Validator::make($data, [
    'toppings' => [
        'required',
        Rule::notIn(['sprinkles', 'cherries']),
    ],
]);

not_regex:正規表現

フィールドが指定した正規表現と一致しないことをバリデートします。

このルールは、内部でPHPのpreg_match関数を使用します。指定するパターンはpreg_matchが要求するものと同じフォーマットと、有効なデリミタに従う必要があります。一例は、'email' => 'not_regex:/^.+$/i'です。

Warning!! regex／not_regexパターンを使用するとき、特に正規表現に|文字が含まれている場合は、|区切り文字を使用する代わりに配列を使用してバリデーションルールを指定する必要があります。

nullable

フィールドはnullであることを許容します。

numeric

フィールドは数値であることをバリデートします。

password

フィールドは、認証済みユーザーのパスワードと一致する必要があります。

Warning!! このルールはLaravel9で削除するため、current_passwordへ名前を変更しました。代わりに現在のパスワードルールを使用してください。

present

　　　　フィールドが入力データに存在していることをバリデートします。

prohibited

フィールドが存在しないか、または空であることをバリデートします。フィールドが以下の条件のいずれかである場合、「空」であると判定します。

値がnullである。
値が空文字列である。
値が空配列であるか、空のCountableオブジェクトである。
値がパスのないアップロード済みファイルである。

prohibited_if:他のフィールド,値,…

他のフィールドが値のいずれかと等しい場合、フィールドが存在しないか、空であることをバリデートします。フィールドが以下の条件のいずれかである場合、「空」であると判定します。

値がnullである。
値が空文字列である。
値が空配列であるか、空のCountableオブジェクトである。
値がパスのないアップロード済みファイルである。

複雑な条件付き禁止（空か存在してない）ロジックが必要な場合は、Rule::prohibitedIfメソッドを利用してください。このメソッドは、論理値かクロージャを引数に取ります。クロージャを指定する場合、そのクロージャはtrueまたはfalseを返し、バリデーション中のフィールドを禁止するかしないかを示す必要があります。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($request->all(), [
    'role_id' => Rule::prohibitedIf($request->user()->is_admin),
]);

Validator::make($request->all(), [
    'role_id' => Rule::prohibitedIf(fn () => $request->user()->is_admin),
]);

prohibited_unless:他のフィールド,値,…

他のフィールドが値の全てと等しくない場合、フィールドが存在しないか、空であることをバリデートします。フィールドが以下の条件のいずれかである場合、そのフィールドを「空」であると判定します。

値がnullである。
値が空文字列である。
値が空配列であるか、空のCountableオブジェクトである。
値がパスのないアップロード済みファイルである。

prohibits:他のフィールド,…

フィールドが存在し空でない場合、全ての他のフィールドは存在しないか、空であることをバリデートします。フィールドが以下の条件のいずれかである場合、そのフィールドを「空」であると判定します。

値がnullである。
値が空文字列である。
値が空配列であるか、空のCountableオブジェクトである。
値がパスのないアップロード済みファイルである。

regex:正規表現

フィールドが指定された正規表現にマッチすることをバリデートします。

このルールは、内部でPHPのpreg_match関数を使用します。指定するパターンはpreg_matchが要求するものと同じフォーマットと、有効なデリミタに従う必要があります。一例は、'email' => 'regex:/^.+@.+$/i'です。

Warning!! regex／not_regexパターンを使用するとき、特に正規表現に|文字が含まれている場合は、|区切り文字を使用する代わりに、配列でルールを指定する必要があります。

required

フィールドが入力データ中に存在し、かつ空でないことをバリデートします。フィールドが以下の条件のいずれかの場合、そのフィールドを「空」であると判定します。

値がnullである。
値が空文字列である。
値が空の配列か、空のCountableオブジェクトである。
値がパスのないアップロード済みファイルである。

required_if:他のフィールド,値,...

他のフィールドが値のどれかと一致している場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_ifルールのより複雑な条件を作成したい場合は、Rule::requiredIfメソッドを使用できます。このメソッドは、ブール値またはクロージャを受け入れます。クロージャが渡されると、クロージャは「true」または「false」を返し、バリデーション中のフィールドが必要かどうかを示します。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf($request->user()->is_admin),
]);

Validator::make($request->all(), [
    'role_id' => Rule::requiredIf(fn () => $request->user()->is_admin),
]);

required_unless:他のフィールド,値,...

他のフィールドが値のどれとも一致していない場合、このフィールドが存在し、かつ空でないことをバリデートします。これは値がnullでない限り、他のフィールドはリクエストデータに存在しなければならないという意味でもあります。もし値がnull（required_unless:name,null）の場合は、比較フィールドがnullであるか、リクエストデータに比較フィールドが存在しない限り、バリデーション対象下のフィールドは必須です。

required_with:foo,bar,...

指定した他のフィールドが一つでも存在している場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_with_all:foo,bar,...

指定した他のフィールドがすべて存在している場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_without:foo,bar,...

指定した他のフィールドのどれか一つでも存在していない場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_without_all:foo,bar,...

指定した他のフィールドがすべて存在していない場合、このフィールドが存在し、かつ空でないことをバリデートします。

required_array_keys:foo,bar,...

フィールドは配列であり、少なくとも指定したキーを含んでいることをバリデートします。

same:フィールド

フィールドが、指定されたフィールドと同じ値であることをバリデートします。

size:値

フィールドは指定された値と同じサイズであることをバリデートします。文字列の場合、値は文字長です。数値項目の場合、値は整数値（属性にnumericかintegerルールを持っている必要があります）です。配列の場合、値は配列の個数(count)です。ファイルの場合、値はキロバイトのサイズです。

// 文字列長が１２文字ちょうどであることをバリデートする
'title' => 'size:12';

// 指定された整数が１０であることをバリデートする
'seats' => 'integer|size:10';

// 配列にちょうど５要素あることをバリデートする
'tags' => 'array|size:5';

// アップロードしたファイルが５１２キロバイトぴったりであることをバリデートする
'image' => 'file|size:512';

starts_with:foo,bar,...

フィールドが、指定した値のどれかで始まることをバリデートします。

string

フィルードは文字列タイプであることをバリデートします。フィールドがnullであることも許す場合は、そのフィールドにnullableルールも指定してください。

timezone

timezone_identifiers_list PHP関数の値に基づき、フィールドがタイムゾーンとして識別されることをバリデートします。

unique:テーブル,カラム

フィールドが、指定されたデータベーステーブルに存在しないことをバリデートします。

カスタムテーブル／カラム名の指定

テーブル名を直接指定する代わりに、Eloquentモデルを指定することもできます。

'email' => 'unique:App\Models\User,email_address'

columnオプションは、フィールドの対応するデータベースカラムを指定するために使用します。columnオプションが指定されていない場合、バリデーション中のフィールドの名前が使用されます。

'email' => 'unique:users,email_address'

カスタムデータベース接続の指定

場合により、バリデータが行うデータベースクエリのカスタム接続を指定する必要があります。これには、接続名をテーブル名の前に追加します。

'email' => 'unique:connection.users,email_address'

指定されたIDのuniqueルールを無視する

場合により、uniqueのバリデーション中に特定のIDを無視したいことがあります。たとえば、ユーザーの名前、メールアドレス、および場所を含む「プロファイルの更新」画面について考えてみます。メールアドレスが一意であることを確認したいでしょう。しかし、ユーザーが名前フィールドのみを変更し、メールフィールドは変更しない場合、ユーザーは当該電子メールアドレスの所有者であるため、バリデーションエラーが投げられるのは望ましくありません。

バリデータにユーザーIDを無視するように指示するには、ルールをスラスラと定義できるRuleクラスを使います。以下の例の場合、さらにルールを|文字を区切りとして使用する代わりに、バリデーションルールを配列として指定しています。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

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

Warning!! ユーザーがコントロールするリクエストの入力をignoreメソッドへ、決して渡してはいけません。代わりに、Eloquentモデルインスタンスの自動増分IDやUUIDのような、生成されたユニークなIDだけを渡してください。そうしなければ、アプリケーションがSQLインジェクション攻撃に対し、脆弱になります。

モデルキーの値をignoreメソッドに渡す代わりに、モデルインスタンス全体を渡すこともできます。Laravelはモデルからキーを自動的に抽出します:

Rule::unique('users')->ignore($user)

もし、テーブルの主キーとしてid以外のカラム名を使用している場合は、ignoreメソッドを呼び出す時に、カラムの名前を指定してください。

Rule::unique('users')->ignore($user->id, 'user_id')

uniqueルールはデフォルトで、バリデートしようとしている属性名と一致するカラムの同一性をチェックします。しかしながら、uniqueメソッドの第２引数として、異なったカラム名を渡すことも可能です。

Rule::unique('users', 'email_address')->ignore($user->id),

追加のWHERE節を付け加える

whereメソッドを使用してクエリをカスタマイズすることにより、追加のクエリ条件を指定できます。たとえば、account_id列の値が1の検索レコードのみ検索するクエリ条件で絞り込むクエリを追加してみます。

'email' => Rule::unique('users')->where(fn ($query) => $query->where('account_id', 1))

uppercase

フィールドが大文字であることをバリデートします。

url

フィールドが有効なURLであることをバリデートします。

ulid

フィールドが有効なULID（Universally Unique Lexicographically Sortable Identifier）であることをバリデートします。

uuid

フィールドが有効な、RFC 4122（バージョン1、3、4、5）universally unique identifier (UUID)であることをバリデートします。

条件付きでルールを追加する

フィールドが特定値を持つ場合にバリデーションを飛ばす

他のフィールドに指定値が入力されている場合は、バリデーションを飛ばしたい状況がときどき起きるでしょう。exclude_ifバリデーションルールを使ってください。appointment_dateとdoctor_nameフィールドは、has_appointmentフィールドがfalse値の場合バリデートされません。

use Illuminate\Support\Facades\Validator;

$validator = Validator::make($data, [
    'has_appointment' => 'required|boolean',
    'appointment_date' => 'exclude_if:has_appointment,false|required|date',
    'doctor_name' => 'exclude_if:has_appointment,false|required|string',
]);

もしくは逆にexclude_unlessルールを使い、他のフィールドに指定値が入力されていない場合は、バリデーションを行わないことも可能です。

$validator = Validator::make($data, [
    'has_appointment' => 'required|boolean',
    'appointment_date' => 'exclude_unless:has_appointment,true|required|date',
    'doctor_name' => 'exclude_unless:has_appointment,true|required|string',
]);

項目存在時のバリデーション

状況によっては、フィールドがバリデーション対象のデータに存在する場合にのみ、フィールドに対してバリデーションチェックを実行したい場合があります。これをすばやく実行するには、sometimesルールをルールリストに追加します。

$v = Validator::make($data, [
    'email' => 'sometimes|required|email',
]);

上の例ではemailフィールドが、$data配列の中に存在している場合のみバリデーションが実行されます。

Note: フィールドが常に存在しているが、空であることをバリデートする場合は、この追加フィールドに対する注意事項を確認してください。

複雑な条件のバリデーション

ときどきもっと複雑な条件のロジックによりバリデーションルールを追加したい場合もあります。たとえば他のフィールドが１００より大きい場合のみ、指定したフィールドが入力されているかをバリデートしたいときなどです。もしくは２つのフィールドのどちらか一方が存在する場合は、両方共に値を指定する必要がある場合です。こうしたルールを付け加えるのも面倒ではありません。最初にValidatorインスタンスを生成するのは、固定ルールの場合と同じです。

use Illuminate\Support\Facades\Validator;

$validator = Validator::make($request->all(), [
    'email' => 'required|email',
    'games' => 'required|numeric',
]);

私たちのWebアプリケーションがゲームコレクター向けであると仮定しましょう。ゲームコレクターがアプリケーションに登録し、100を超えるゲームを所有している場合は、なぜこれほど多くのゲームを所有しているのかを説明してもらいます。たとえば、ゲームの再販店を経営している場合や、ゲームの収集を楽しんでいる場合などです。この要件を条件付きで追加するには、Validatorインスタンスでsometimesメソッドを使用できます。

$validator->sometimes('reason', 'required|max:500', function ($input) {
    return $input->games >= 100;
});

sometimesメソッドに渡される最初の引数は、条件付きでバリデーションするフィールドの名前です。２番目の引数は、追加するルールのリストです。３番目の引数として渡すクロージャがtrueを返す場合、ルールが追加されます。この方法で、複雑な条件付きバリデーションを簡単に作成できます。複数のフィールドに条件付きバリデーションを一度に追加することもできます。

$validator->sometimes(['reason', 'cost'], 'required', function ($input) {
    return $input->games >= 100;
});

Note: クロージャに渡される$inputパラメーターは、Illuminate\Support\Fluentのインスタンスであり、バリデーション中の入力とファイルへアクセスするために使用できます。

複雑な条件の配列バリデーション

インデックスがわからない、入れ子になった同じ配列の中にある別のフィールドに基づいて、あるフィールドを検証したいことがあります。このような場合には、クロージャへ第２引数を渡してください。第２引数には、配列中のバリデーション対象の現アイテムが渡されます。

$input = [
    'channels' => [
        [
            'type' => 'email',
            'address' => 'abigail@example.com',
        ],
        [
            'type' => 'url',
            'address' => 'https://example.com',
        ],
    ],
];

$validator->sometimes('channels.*.address', 'email', function ($input, $item) {
    return $item->type === 'email';
});

$validator->sometimes('channels.*.address', 'url', function ($input, $item) {
    return $item->type !== 'email';
});

クロージャに渡される$inputパラメータと同様に、$itemパラメータは属性データが配列の場合はIlluminate\Support\Fluentのインスタンス、そうでない場合は文字列になります。

配列のバリデーション

arrayバリデーションルールのドキュメントで説明したように、arrayルールは、許可する配列キーのリストを受け入れます。配列内にその他のキーが存在する場合、バリデーションは失敗します。

use Illuminate\Support\Facades\Validator;

$input = [
    'user' => [
        'name' => 'Taylor Otwell',
        'username' => 'taylorotwell',
        'admin' => true,
    ],
];

Validator::make($input, [
    'user' => 'array:username,locale',
]);

一般的に、配列内に存在することが許される配列キーを常に指定する必要があります。そうしないと、バリデータのvalidateとvalidatedメソッドは他のネストした配列バリデーションルールにより検証されていなくても、配列とそのすべてのキーを含むバリデーション済みデータをすべて返してしまうことになります。

ネストした配列入力のバリデーション

ネストした配列ベースフォームの入力フィールドをバリデーションするのが、面倒である必要はありません。配列内の属性をバリデーションするには、「ドット記法」が使えます。たとえば、HTTPリクエストにphotos[profile]フィールドが含まれている場合、次のように検証します。

use Illuminate\Support\Facades\Validator;

$validator = Validator::make($request->all(), [
    'photos.profile' => 'required|image',
]);

配列の各要素をバリデーションすることもできます。たとえば、特定の配列入力フィールドの各メールが一意であることをバリデーションするには、次のようにします。

$validator = Validator::make($request->all(), [
    'person.*.email' => 'email|unique:users',
    'person.*.first_name' => 'required_with:person.*.last_name',
]);

同様に、言語ファイルのカスタムバリデーションメッセージを指定するときに*文字を使用すると、配列ベースのフィールドに単一のバリデーションメッセージを簡単に使用できます。

'custom' => [
    'person.*.email' => [
        'unique' => 'Each person must have a unique email address',
    ]
],

ネストした配列データへのアクセス

Sometimes you may need to access the value for a given nested array element when assigning validation rules to the attribute. You may accomplish this using the Rule::forEach method. The forEach method accepts a closure that will be invoked for each iteration of the array attribute under validation and will receive the attribute's value and explicit, fully-expanded attribute name. The closure should return an array of rules to assign to the array element:

use App\Rules\HasPermission;
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;

$validator = Validator::make($request->all(), [
    'companies.*.id' => Rule::forEach(function ($value, $attribute) {
        return [
            Rule::exists(Company::class, 'id'),
            new HasPermission('manage-company', $value),
        ];
    }),
]);

エラーメッセージインデックスとポジション

配列のバリデーションを行うとき、失敗した特定項目のインデックスや位置をアプリケーションのエラーメッセージから参照したいことがあります。これを行うには、[カスタムバリデーションメッセージ] (#manual-customizing-the-error-messages)へ、:index（０始点）と:position（１始点）のプレースホルダを使ってください。

use Illuminate\Support\Facades\Validator;

$input = [
    'photos' => [
        [
            'name' => 'BeachVacation.jpg',
            'description' => 'A photo of my beach vacation!',
        ],
        [
            'name' => 'GrandCanyon.jpg',
            'description' => '',
        ],
    ],
];

Validator::validate($input, [
    'photos.*.description' => 'required',
], [
    'photos.*.description.required' => 'Please describe photo #:position.',
]);

上記の例で、バリデーションは失敗し、"Please describe photo #2"がユーザーに表示されます。

ファイルのバリデーション

Laravelでは、アップロードされたファイルを検証するため、mimes、image、min、maxなど様々なバリデーションルールを提供しています。ファイルのバリデーションを行う際に、これらのルールを個別に指定することも可能ですが、便利なようにファイルバリデーションルールビルダも提供しています。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\File;

Validator::validate($input, [
    'attachment' => [
        'required',
        File::types(['mp3', 'wav'])
            ->min(1024)
            ->max(12 * 1024),
    ],
]);

アプリケーションがユーザーからアップロードされた画像を受け取る場合、Fileルールのimageコンストラクタメソッドを使用して、アップロードされるファイルが画像であることを指定することができます。さらに、dimensionsルールを使用して、画像の大きさを制限することもできます。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\File;

Validator::validate($input, [
    'photo' => [
        'required',
        File::image()
            ->min(1024)
            ->max(12 * 1024)
            ->dimensions(Rule::dimensions()->maxWidth(1000)->maxHeight(500)),
    ],
]);

Note: 画像サイズのバリデーションに関するより詳しい情報は、dimensionsルールのドキュメントに記載しています。

ファイルタイプ

typesメソッドを呼び出すときには拡張子を指定するだけですが、このメソッドは実際にファイルの内容を読み込んで、MIMEタイプを推測し、バリデーションします。MIME タイプとそれに対応する拡張子の完全なリストは、次の場所にあります。

https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

パスワードのバリデーション

パスワードが十分なレベルの複雑さがあることを確認するために、LaravelのPasswordルールオブジェクトを使用できます。

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\Password;

$validator = Validator::make($request->all(), [
    'password' => ['required', 'confirmed', Password::min(8)],
]);

Passwordルールオブジェクトを使用すると、文字・数字・記号を最低１文字必要にしたり、文字種を組み合わせたりのように、パスワードの指定をアプリケーションで使用する複雑さの要件に合うよう簡単にカスタマイズできます。

// 最低８文字必要
Password::min(8)

// 最低１文字の文字が必要
Password::min(8)->letters()

// 最低大文字小文字が１文字ずつ必要
Password::min(8)->mixedCase()

// 最低一文字の数字が必要
Password::min(8)->numbers()

// 最低一文字の記号が必要
Password::min(8)->symbols()

さらに、uncompromisedメソッドを使って、公開されているパスワードのデータ漏洩によるパスワード漏洩がないことを確認することもできます。

Password::min(8)->uncompromised()

内部的には、Passwordルールオブジェクトは、k-Anonymityモデルを使用して、ユーザーのプライバシーやセキュリティを犠牲にすることなく、パスワードがhaveibeenpwned.comサービスを介してリークされているかを判断します。

デフォルトでは、データリークに少なくとも1回パスワードが表示されている場合は、侵害されたと見なします。uncompromisedメソッドの最初の引数を使用してこのしきい値をカスタマイズできます。

// 同一のデータリークにおいて、パスワードの出現回数が3回以下であることを確認
Password::min(8)->uncompromised(3);

もちろん、上記の例ですべてのメソッドをチェーン化することができます。

Password::min(8)
    ->letters()
    ->mixedCase()
    ->numbers()
    ->symbols()
    ->uncompromised()

デフォルトパスワードルールの定義

パスワードのデフォルトバリデーションルールをアプリケーションの一箇所で指定できると便利でしょう。クロージャを引数に取るPassword::defaultsメソッドを使用すると、これを簡単に実現できます。defaultsメソッドへ渡すクロージャは、パスワードルールのデフォルト設定を返す必要があります。通常、defaultsルールはアプリケーションのサービスプロバイダの1つのbootメソッド内で呼び出すべきです。

use Illuminate\Validation\Rules\Password;

/**
 * アプリケーションの全サービスの初期処理
 *
 * @return void
 */
public function boot()
{
    Password::defaults(function () {
        $rule = Password::min(8);

        return $this->app->isProduction()
                    ? $rule->mixedCase()->uncompromised()
                    : $rule;
    });
}

そして、バリデーションで特定のパスワードへデフォルトルールを適用したい場合に、引数なしでdefaultsメソッドを呼び出します。

'password' => ['required', Password::defaults()],

時には、デフォルトのパスワードバリデーションルールへ追加ルールを加えたい場合があります。このような場合には、rulesメソッドを使用します。

use App\Rules\ZxcvbnRule;

Password::defaults(function () {
    $rule = Password::min(8)->rules([new ZxcvbnRule]);

    // ...
});

カスタムバリデーションルール

ルールオブジェクトの使用

Laravelは有用な数多くのバリデーションルールを提供しています。ただし、独自のものを指定することもできます。カスタムバリデーションルールを登録する１つの方法は、ルールオブジェクトを使用することです。新しいルールオブジェクトを生成するには、make:ruleArtisanコマンドを使用できます。このコマンドを使用して、文字列が大文字であることを確認するルールを生成してみましょう。Laravelは新しいルールをapp/Rulesディレクトリに配置します。このディレクトリが存在しない場合、Artisanコマンドを実行してルールを作成すると、Laravelがそのディレクトリを作成します。

php artisan make:rule Uppercase --invokable

ルールを作成したら、動作を定義する準備ができました。ルールオブジェクトには、__invokeという１つのメソッドを用意します。このメソッドは、属性名とその値、バリデーションエラーメッセージと、失敗時に呼び出すコールバックを指定します。

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\InvokableRule;

class Uppercase implements InvokableRule
{
    /**
     * バリデーションルールの実行
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @param  \Closure  $fail
     * @return void
     */
    public function __invoke($attribute, $value, $fail)
    {
        if (strtoupper($value) !== $value) {
            $fail('The :attribute must be uppercase.');
        }
    }
}

ルールを定義したら、他のバリデーションルールと一緒に、ルールオブジェクトのインスタンスをバリデータへ渡し、指定します。

use App\Rules\Uppercase;

$request->validate([
    'name' => ['required', 'string', new Uppercase],
]);

バリデーションメッセージの翻訳

$failクロージャへ文字列のエラーメッセージを指定する代わりに、翻訳文字列キーを指定し、Laravelへエラーメッセージの翻訳を指示できます。

if (strtoupper($value) !== $value) {
    $fail('validation.uppercase')->translate();
}

必要に応じ、プレースホルダを置き換えたり、translateメソッドの第１引数と第２引数として使用する言語を指定することもできます。

$fail('validation.location')->translate([
    'value' => $this->value,
], 'fr')

追加データへのアクセス

カスタムバリデーションルールクラスがバリデーション下の他のすべてのデータへアクセスする必要がある場合、そのルールクラスにIlluminate\Contracts\Validation\DataAwareRuleインターフェイスを実装してください。このインターフェイスは、クラスへsetData メソッドの定義を要求します。このメソッドはLaravelにより自動的に（バリデーション処理前に）、バリデーション対象の全データで呼び出されます。

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\DataAwareRule;
use Illuminate\Contracts\Validation\InvokableRule;

class Uppercase implements DataAwareRule, InvokableRule
{
    /**
     * バリデーション下の全データ
     *
     * @var array
     */
    protected $data = [];

    // ...

    /**
     * バリデーション下のデータをセット
     *
     * @param  array  $data
     * @return $this
     */
    public function setData($data)
    {
        $this->data = $data;

        return $this;
    }
}

または、バリデーションルールが、バリデーションを行うバリデータインスタンスへのアクセスを必要とする場合は、ValidatorAwareRuleインターフェイスを実装してください。

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\InvokableRule;
use Illuminate\Contracts\Validation\ValidatorAwareRule;

class Uppercase implements InvokableRule, ValidatorAwareRule
{
    /**
     * バリデータインスタンス
     *
     * @var \Illuminate\Validation\Validator
     */
    protected $validator;

    // ...

    /**
     * 現用バリデータのセット
     *
     * @param  \Illuminate\Validation\Validator  $validator
     * @return $this
     */
    public function setValidator($validator)
    {
        $this->validator = $validator;

        return $this;
    }
}

クロージャの使用

アプリケーション全体でカスタムルールの機能が１回だけ必要な場合は、ルールオブジェクトの代わりにクロージャを使用できます。クロージャは、属性の名前、属性の値、およびバリデーションが失敗した場合に呼び出す必要がある$failコールバックを受け取ります。

use Illuminate\Support\Facades\Validator;

$validator = Validator::make($request->all(), [
    'title' => [
        'required',
        'max:255',
        function ($attribute, $value, $fail) {
            if ($value === 'foo') {
                $fail('The '.$attribute.' is invalid.');
            }
        },
    ],
]);

暗黙のルール

デフォルトでは、バリデーションされる属性が存在しないか、空の文字列が含まれている場合、カスタムルールを含む通常のバリデーションルールは実行されません。たとえば、uniqueルールは空の文字列に対して実行されません。

use Illuminate\Support\Facades\Validator;

$rules = ['name' => 'unique:users,name'];

$input = ['name' => ''];

Validator::make($input, $rules)->passes(); // true

属性が空の場合でもカスタムルールを実行するには、ルールがその属性を必要とすることを示す必要があります。簡単に新しい暗黙のルールオブジェクトを生成するには、make:rule Artisanコマンドに、--implicitオプションを付けて使用します。

php artisan make:rule Uppercase --invokable --implicit

Warning!! 「暗黙の」ルールは、属性が必要であることを暗黙的にします。欠落している属性または空の属性を実際に無効にするかどうかは、あなた次第です。

Laravel 9.x バリデーション

イントロダクション

クイックスタート

ルート定義

コントローラ作成

バリデーションロジック

最初のバリデーション失敗時に停止

ネストした属性の注意点

バリデーションエラー表示

エラーメッセージのカスタマイズ

XHRリクエストとバリデーション

@errorディレクティブ

フォームの再取得

オプションフィールドに対する注意

バリデーションエラーのレスポンス形式

フォームリクエストバリデーション

フォームリクエスト作成

フォームリクエストへのAfterフックを追加

最初のバリデーション失敗属性で停止

リダイレクト先のカスタマイズ

フォームリクエストの認可

エラーメッセージのカスタマイズ

バリデーション属性のカスタマイズ

検証のための入力準備

バリデータの生成

最初のバリデーション失敗時に停止

自動リダイレクト

名前付きエラーバッグ

エラーメッセージのカスタマイズ

特定の属性に対するカスタムメッセージ指定

カスタム属性値の指定

バリデーション後のフック

バリデーション済み入力の利用

エラーメッセージの操作

指定フィールドの最初のエラーメッセージ取得

指定フィールドの全エラーメッセージ取得

全フィールドの全エラーメッセージ取得

指定フィールドのメッセージ存在確認

言語ファイルでのカスタムメッセージの指定

特定の属性のカスタムメッセージ

言語ファイルでの属性の指定

言語ファイルでの値の指定

使用可能なバリデーションルール

accepted

accepted_if:他のフィールド,値,...

active_url

after:日付

after_or_equal:日付

alpha

alpha_dash

alpha_num

array

ascii

bail

before:日付

before_or_equal:日付

between:min,max

boolean

confirmed

current_password

date

date_equals:日付

date_format:フォーマット,…

decimal:min,max

declined

declined_if:他のフィールド,値,...

different:フィールド

digits:値

digits_between:最小値,最大値

dimensions

distinct

doesnt_start_with:foo,bar,...

doesnt_end_with:foo,bar,...

email

ends_with:foo,bar,...

enum

exclude

exclude_if:他のフィールド,値

exclude_unless:他のフィールド,値

exclude_with:他のフィールド

`@error`ディレクティブ