基本 - バリデーション（Validation） - 《Laravel 11.x ドキュメント》日本語

はじめに
検証クイックスタート
フォームリクエスト検証
バリデーターの手動作成
検証された入力の操作
エラーメッセージの操作
言語ファイルでのメッセージの指定
言語ファイルでの属性の指定
言語ファイルでの値の指定
利用可能な検証ルール
Conditionally Adding Rules
Validating Arrays
- Validating Nested Array Input
  - Accessing Nested Array Data
- Error Message Indexes and Positions
Validating Files
- File Sizes
- File Types
Validating Passwords
- Defining Default Password Rules
Custom Validation Rules

はじめに

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']);

 <a name="quick-creating-the-controller"></a>
### コントローラーの作成
次に、これらのルートへの受信リクエストを処理するシンプルなコントローラーを見てみましょう。`````store`````メソッドは今のところ空のままにしておきます:  
``````php
<?php
namespace App\Http\Controllers;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\View\View;
class PostController extends Controller
{
   /**
     * Show the form to create a new blog post.
   */
   public function create(): View
   {
   return view('post.create');
   }
   /**
     * Store a new blog post.
   */
   public function store(Request $request): RedirectResponse
   {
   // Validate and store the blog post...
   $post = /** ... */
   return to_route('post.show', ['post' => $post->id]);
   }
}
`

検証ロジックの記述

新しいブログ投稿を検証するロジックでstoreメソッドを埋める準備が整いました。これを行うために、validateメソッドをIlluminate\Http\Requestオブジェクトから使用します。検証ルールが通過すると、コードは通常通り実行され続けます。ただし、検証が失敗した場合、Illuminate\Validation\ValidationException例外がスローされ、適切なエラー応答が自動的にユーザーに返されます。

従来のHTTPリクエスト中に検証が失敗した場合、前のURLへのリダイレクト応答が生成されます。受信リクエストがXHRリクエストである場合、検証エラーメッセージを含むJSON応答が返されます。


``````php
/**
 * Store a new blog post.
 */
public function store(Request $request): RedirectResponse
{
   $validated = $request->validate([
   'title' => 'required|unique:posts|max:255',
   'body' => 'required',
   ]);
   // The blog post is valid...
   return redirect('/posts');
}
`

ご覧のとおり、検証ルールはvalidateメソッドに渡されます。心配しないでください - 利用可能なすべての検証ルールは文書化されています。再度、検証が失敗した場合、適切な応答が自動的に生成されます。検証が通過した場合、コントローラーは通常通り実行を続けます。

また、検証ルールは単一の|区切り文字列の代わりにルールの配列として指定することもできます:

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

さらに、validateWithBagメソッドを使用してリクエストを検証し、名前付きエラーバッグ内にエラーメッセージを保存することもできます:

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

最初の検証失敗で停止する

時には、最初の検証失敗後に属性の検証ルールの実行を停止したい場合があります。そのためには、bailルールを属性に割り当てます:

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

この例では、uniqueルールがtitle属性で失敗した場合、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は自動的にユーザーを前の場所にリダイレクトします。さらに、すべての検証エラーとリクエスト入力は自動的にセッションにフラッシュされます。


したがって、私たちの例では、検証が失敗した場合、ユーザーはコントローラーの`````create`````メソッドにリダイレクトされ、ビューにエラーメッセージを表示できるようになります:  
``````blade
<!-- /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
<!-- Create Post Form -->
`

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

Laravelの組み込み検証ルールには、それぞれアプリケーションのlang/en/validation.phpファイルにあるエラーメッセージがあります。アプリケーションにlangディレクトリがない場合、lang:publish Artisanコマンドを使用してLaravelに作成させることができます。


さらに、このファイルを別の言語ディレクトリにコピーして、アプリケーションの言語に対するメッセージを翻訳することができます。Laravelのローカリゼーションについて詳しく学ぶには、完全な[ローカリゼーション文書](https://laravel.com/docs/localization)を確認してください。  
デフォルトでは、Laravelアプリケーションのスケルトンには`````lang`````ディレクトリは含まれていません。Laravelの言語ファイルをカスタマイズしたい場合は、`````lang:publish````` Artisanコマンドを使用して公開できます。  
 <a name="quick-xhr-requests-and-validation"></a>
#### XHRリクエストと検証
この例では、アプリケーションにデータを送信するために従来のフォームを使用しました。しかし、多くのアプリケーションは、JavaScriptを使用したフロントエンドからXHRリクエストを受信します。XHRリクエスト中に`````validate`````メソッドを使用すると、Laravelはリダイレクト応答を生成しません。代わりに、Laravelは[検証エラーを含むJSON応答](#validation-error-response-format)を生成します。このJSON応答は、422 HTTPステータスコードで送信されます。  
 <a name="the-at-error-directive"></a>
#### @errorディレクティブ
特定の属性に対して検証エラーメッセージが存在するかどうかを迅速に判断するために、`````@error````` [Blade](/read/laravel-11-x/3aaaf25bb396ee8c.md)ディレクティブを使用できます。`````@error`````ディレクティブ内で、`````$message`````変数をエコーしてエラーメッセージを表示できます:  
``````blade
<!-- /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ディレクティブにエラーバッグの名前を第二引数として渡すことができます:

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

フォームの再入力

Laravelが検証エラーによりリダイレクト応答を生成すると、フレームワークは自動的にリクエストのすべての入力をセッションにフラッシュします。これは、次のリクエスト中に入力に便利にアクセスし、ユーザーが送信しようとしたフォームを再入力できるようにするためです。

前のリクエストからフラッシュされた入力を取得するには、oldメソッドをIlluminate\Http\Requestのインスタンスで呼び出します。oldメソッドは、セッションから以前にフラッシュされた入力データを取得します:

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

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

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

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

デフォルトでは、LaravelはTrimStringsおよびConvertEmptyStringsToNullミドルウェアをアプリケーションのグローバルミドルウェアスタックに含めています。このため、検証者がnull値を無効と見なさないように、「オプション」リクエストフィールドにnullableとしてマークする必要があることがよくあります。例えば:

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

この例では、publish_atフィールドがnullまたは有効な日付表現である可能性があることを指定しています。nullable修飾子がルール定義に追加されない場合、検証者はnullを無効な日付と見なします。

検証エラー応答フォーマット

アプリケーションがIlluminate\Validation\ValidationException例外をスローし、受信HTTPリクエストがJSON応答を期待している場合、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メソッドはリクエストのデータに適用されるべき検証ルールを返します:

/**
 * Get the validation rules that apply to the request.
 *
 * @return array<string, \Illuminate\Contracts\Validation\ValidationRule|array<mixed>|string>
 */
public function rules(): array
{
   return [
   'title' => 'required|unique:posts|max:255',
   'body' => 'required',
   ];
}


では、検証ルールはどのように評価されるのでしょうか？コントローラーメソッドでリクエストを型ヒントするだけで済みます。受信フォームリクエストは、コントローラーメソッドが呼び出される前に検証されるため、コントローラーを検証ロジックで混雑させる必要はありません:  
``````php
/**
 * Store a new blog post.
 */
public function store(StorePostRequest $request): RedirectResponse
{
   // The incoming request is valid...
   // Retrieve the validated input data...
   $validated = $request->validated();
   // Retrieve a portion of the validated input data...
   $validated = $request->safe()->only(['name', 'email']);
   $validated = $request->safe()->except(['name', 'email']);
   // Store the blog post...
   return redirect('/posts');
}
`

検証が失敗した場合、ユーザーを前の場所に戻すためのリダイレクト応答が生成されます。エラーもセッションにフラッシュされ、表示可能になります。リクエストがXHRリクエストであった場合、検証エラーのJSON表現を含むHTTP応答がユーザーに返されます。

Inertiaを使用したLaravelフロントエンドにリアルタイムのフォームリクエスト検証を追加する必要がありますか？Laravel Precognitionをチェックしてください。

追加の検証の実行

時には、初期の検証が完了した後に追加の検証を実行する必要があります。これを行うには、フォームリクエストのafterメソッドを使用します。


``````php
use Illuminate\Validation\Validator;
/**
 * Get the "after" validation callables for the request.
 */
public function after(): array
{
   return [
   function (Validator $validator) {
   if ($this->somethingElseIsInvalid()) {
   $validator->errors()->add(
   'field',
   'Something is wrong with this field!'
   );
   }
   }
   ];
}
`

前述のように、afterメソッドはコールバックの配列も受け入れます。これは、あなたの「検証後」ロジックが呼び出し可能なクラスにカプセル化されている場合に特に便利で、これらのクラスはinvokeメソッドを介してIlluminate\Validation\Validatorインスタンスを受け取ります:

use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;
use Illuminate\Validation\Validator;
/**
 * Get the "after" validation callables for the request.
 */
public function after(): array
{
   return [
   new ValidateUserStatus,
   new ValidateShippingTime,
   function (Validator $validator) {
   //
   }
   ];
}

最初の検証失敗で停止する

リクエストクラスにstopOnFirstFailureプロパティを追加することで、検証者に単一の検証失敗が発生した時点で、すべての属性の検証を停止するように通知できます:

/**
 * Indicates if the validator should stop on the first rule failure.
 *
 * @var bool
 */
protected $stopOnFirstFailure = true;

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

前述のように、フォームリクエストの検証が失敗した場合、ユーザーを前の場所に戻すためのリダイレクト応答が生成されます。ただし、この動作をカスタマイズすることもできます。そのためには、フォームリクエストに$redirectプロパティを定義します:

/**
 * The URI that users should be redirected to if validation fails.
 *
 * @var string
 */
protected $redirect = '/dashboard';

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

/**
 * The route that users should be redirected to if validation fails.
 *
 * @var string
 */
protected $redirectRoute = 'dashboard';

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

フォームリクエストクラスにはauthorizeメソッドも含まれています。このメソッド内で、認証されたユーザーが特定のリソースを更新する権限を実際に持っているかどうかを判断できます。たとえば、ユーザーが更新しようとしているブログコメントを実際に所有しているかどうかを判断できます。おそらく、このメソッド内で認可ゲートとポリシーと対話することになります:

use App\Models\Comment;
/**
 * Determine if the user is authorized to make this request.
 */
public function authorize(): bool
{
   $comment = Comment::find($this->route('comment'));
   return $comment && $this->user()->can('update', $comment);
}

すべてのフォームリクエストは基本のLaravelリクエストクラスを拡張しているため、userメソッドを使用して現在認証されているユーザーにアクセスできます。また、上記の例でrouteメソッドを呼び出していることに注意してください。このメソッドは、呼び出されているルートで定義されたURIパラメータにアクセスすることを許可します。たとえば、以下の例の{comment}パラメータ:

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

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

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


リクエストの認可ロジックをアプリケーションの別の部分で処理する予定がある場合は、`````authorize`````メソッドを完全に削除するか、単に`````true`````を返すことができます:  
``````php
/**
 * Determine if the user is authorized to make this request.
 */
public function authorize(): bool
{
   return true;
}
`


 <a name="customizing-the-error-messages"></a>
### エラーメッセージのカスタマイズ
フォームリクエストによって使用されるエラーメッセージをカスタマイズするには、`````messages`````メソッドをオーバーライドします。このメソッドは、属性/ルールのペアとそれに対応するエラーメッセージの配列を返す必要があります:  
``````php
/**
 * Get the error messages for the defined validation rules.
 *
 * @return array<string, string>
 */
public function messages(): array
{
   return [
   'title.required' => 'A title is required',
   'body.required' => 'A message is required',
   ];
}
`

検証属性のカスタマイズ

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

/**
 * Get custom attributes for validator errors.
 *
 * @return array<string, string>
 */
public function attributes(): array
{
   return [
   'email' => 'email address',
   ];
}

検証のための入力の準備

リクエストからのデータを検証ルールを適用する前に準備またはサニタイズする必要がある場合は、prepareForValidationメソッドを使用できます:

use Illuminate\Support\Str;
/**
 * Prepare the data for validation.
 */
protected function prepareForValidation(): void
{
   $this->merge([
   'slug' => Str::slug($this->slug),
   ]);
}

同様に、検証が完了した後にリクエストデータを正規化する必要がある場合は、passedValidationメソッドを使用できます:

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

バリデーターの手動作成

リクエストでvalidateメソッドを使用したくない場合は、Validator ファサードを使用してバリデーターインスタンスを手動で作成できます。ファサードのmakeメソッドは、新しいバリデーターインスタンスを生成します:

<?php
namespace App\Http\Controllers;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Validator;
class PostController extends Controller
{
   /**
     * Store a new blog post.
   */
   public function store(Request $request): RedirectResponse
   {
   $validator = Validator::make($request->all(), [
   'title' => 'required|unique:posts|max:255',
   'body' => 'required',
   ]);
   if ($validator->fails()) {
   return redirect('/post/create')
   ->withErrors($validator)
   ->withInput();
   }
   // Retrieve the validated input...
   $validated = $validator->validated();
   // Retrieve a portion of the validated input...
   $validated = $validator->safe()->only(['name', 'email']);
   $validated = $validator->safe()->except(['name', 'email']);
   // Store the blog post...
   return redirect('/posts');
   }
}


リクエストの検証が失敗したかどうかを判断した後、`````withErrors`````メソッドを使用してエラーメッセージをセッションにフラッシュできます。このメソッドを使用すると、`````$errors`````変数はリダイレクト後に自動的にビューと共有され、ユーザーに簡単に表示できます。`````withErrors`````メソッドは、バリデーター、`````MessageBag`````、またはPHPの`````array`````を受け入れます。
#### 最初の検証失敗で停止する
`````stopOnFirstFailure`````メソッドは、単一の検証失敗が発生した時点で、すべての属性の検証を停止するようにバリデーターに通知します:  
``````php
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');

名前付きエラーバッグ

単一のページに複数のフォームがある場合、検証エラーを含むMessageBagに名前を付けて、特定のフォームのエラーメッセージを取得できるようにすることがあります。これを実現するには、withErrorsに第二引数として名前を渡します:

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

その後、MessageBag変数から名前付き$errorsインスタンスにアクセスできます:

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

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

必要に応じて、バリデーターインスタンスが使用すべきカスタムエラーメッセージを提供できます。カスタムメッセージを指定する方法はいくつかあります。まず、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プレースホルダーが含まれています。特定のフィールドのこれらのプレースホルダーを置き換えるために使用される値をカスタマイズするには、Validator::makeメソッドの第四引数としてカスタム属性の配列を渡すことができます:

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

追加の検証の実行

時には、初期の検証が完了した後に追加の検証を実行する必要があります。これを行うには、バリデーターのafterメソッドを使用します。afterメソッドは、検証が完了した後に呼び出されるクロージャまたはコールバックの配列を受け入れます。指定されたコールバックはIlluminate\Validation\Validatorインスタンスを受け取り、必要に応じて追加のエラーメッセージを発生させることができます:

use Illuminate\Support\Facades\Validator;
$validator = Validator::make(/* ... */);
$validator->after(function ($validator) {
   if ($this->somethingElseIsInvalid()) {
   $validator->errors()->add(
   'field', 'Something is wrong with this field!'
   );
   }
});
if ($validator->fails()) {
   // ...
}

前述のように、afterメソッドもコールバックの配列を受け入れます。これは、あなたの「検証後」ロジックが呼び出し可能なクラスにカプセル化されている場合に特に便利で、これらのクラスはIlluminate\Validation\Validatorメソッドを介してinvokeインスタンスを受け取ります:

use App\Validation\ValidateShippingTime;
use App\Validation\ValidateUserStatus;
$validator->after([
   new ValidateUserStatus,
   new ValidateShippingTime,
   function ($validator) {
   // ...
   },
]);

検証された入力の操作

フォームリクエストまたは手動で作成されたバリデーターインスタンスを使用して受信リクエストデータを検証した後、実際に検証を受けた受信リクエストデータを取得したい場合があります。これはいくつかの方法で実現できます。まず、フォームリクエストまたはバリデーターインスタンスで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インスタンスは配列のように反復処理およびアクセスできます:

// Validated data may be iterated...
foreach ($request->safe() as $key => $value) {
   // ...
}
// Validated data may be accessed as an array...
$validated = $request->safe();
$email = $validated['email'];

検証されたデータに追加のフィールドを追加したい場合は、mergeメソッドを呼び出すことができます:

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

検証されたデータをコレクションインスタンスとして取得したい場合は、collectメソッドを呼び出すことができます:

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

エラーメッセージの操作

 <a name="retrieving-the-first-error-message-for-a-field"></a>
#### フィールドの最初のエラーメッセージを取得する
特定のフィールドの最初のエラーメッセージを取得するには、`````first`````メソッドを使用します:  
``````php
$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) {
   // ...
}

フィールドにエラーメッセージが存在するかどうかを判断する


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

言語ファイルでのメッセージの指定


さらに、このファイルを別の言語ディレクトリにコピーして、アプリケーションの言語に対するメッセージを翻訳することができます。Laravelのローカリゼーションについて詳しく学ぶには、完全な[ローカリゼーション文書](https://laravel.com/docs/localization)を確認してください。  
デフォルトでは、Laravelアプリケーションのスケルトンには`````lang`````ディレクトリは含まれていません。Laravelの言語ファイルをカスタマイズしたい場合は、`````lang:publish````` Artisanコマンドを使用して公開できます。  
 <a name="custom-messages-for-specific-attributes"></a>
#### 特定の属性に対するカスタムメッセージ
アプリケーションの検証言語ファイル内で、指定された属性とルールの組み合わせに使用されるエラーメッセージをカスタマイズできます。これを行うには、アプリケーションの`````custom`````配列にメッセージのカスタマイズを追加します。`````lang/xx/validation.php`````言語ファイル:  
``````php
'custom' => [
   'email' => [
   'required' => 'We need to know your email address!',
   'max' => 'Your email address is too long!'
   ],
],
`

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

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

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

デフォルトでは、Laravelアプリケーションのスケルトンにはlangディレクトリは含まれていません。Laravelの言語ファイルをカスタマイズしたい場合は、lang:publish Artisanコマンドを使用して公開できます。

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

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.

利用可能な検証ルール

以下は、すべての利用可能な検証ルールとその機能のリストです：

Accepted Accepted If Active URL After (Date) After Or Equal (Date) Alpha Alpha Dash Alpha Numeric Array Ascii Bail Before (Date) Before Or Equal (Date) Between Boolean Confirmed Contains Current Password Date Date Equals Date Format Decimal Declined Declined If Different Digits Digits Between Dimensions (Image Files) Distinct Doesnt Start With Doesnt End With Email Ends With Enum Exclude Exclude If Exclude Unless Exclude With Exclude Without Exists (Database) Extensions File Filled Greater Than Greater Than Or Equal Hex Color Image (File) In In Array Integer IP Address JSON Less Than Less Than Or Equal List Lowercase MAC Address Max Max Digits MIME Types MIME Type By File Extension Min Min Digits Missing Missing If Missing Unless Missing With Missing With All Multiple Of Not In Not Regex Nullable Numeric Present Present If Present Unless Present With Present With All Prohibited Prohibited If Prohibited Unless Prohibits Regular Expression Required Required If Required If Accepted Required If Declined Required Unless Required With Required With All Required Without Required Without All Required Array Keys Same Size Sometimes Starts With String Timezone Unique (Database) Uppercase URL ULID UUID

accepted

検証対象のフィールドは、"yes"、"on"、1、"1"、true、または"true"でなければなりません。これは、「利用規約」の受け入れや同様のフィールドの検証に役立ちます。

accepted_if:anotherfield,value,…

検証対象のフィールドは、別の検証対象のフィールドが指定された値に等しい場合、"yes"、"on"、1、"1"、true、または"true"でなければなりません。これは、「利用規約」の受け入れや同様のフィールドの検証に役立ちます。

active_url

検証対象のフィールドは、dns_get_record PHP関数に従って有効なAまたはAAAAレコードを持っている必要があります。提供されたURLのホスト名は、parse_url PHP関数を使用して抽出され、dns_get_recordに渡されます。

after:date

検証対象のフィールドは、指定された日付の後の値でなければなりません。日付は、strtotime PHP関数に渡され、有効なDateTimeインスタンスに変換されます：

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

日付を評価するために日付文字列を渡す代わりに、比較するための別のフィールドを指定できます：

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

after_or_equal:date

検証対象のフィールドは、指定された日付の後または等しい値でなければなりません。詳細については、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でなければなりません。


``````php
use Illuminate\Support\Facades\Validator;
$input = [
   'user' => [
   'name' => 'Taylor Otwell',
   'username' => 'taylorotwell',
   'admin' => true,
   ],
];
Validator::make($input, [
   'user' => 'array:name,username',
]);
`

一般的に、配列内に存在することが許可される配列キーを常に指定する必要があります。

ascii

検証対象のフィールドは、完全に7ビットASCII文字でなければなりません。

bail

最初の検証失敗後にフィールドの検証ルールの実行を停止します。


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

before:date

検証対象のフィールドは、指定された日付の前の値でなければなりません。日付は、PHP strtotime関数に渡され、有効なDateTimeインスタンスに変換されます。さらに、afterルールのように、検証対象の別のフィールドの名前をdateの値として指定できます。

before_or_equal:date

検証対象のフィールドは、指定された日付の前または等しい値でなければなりません。日付は、PHP strtotime関数に渡され、有効なDateTimeインスタンスに変換されます。さらに、afterルールのように、検証対象の別のフィールドの名前をdateの値として指定できます。

between:min,max

検証対象のフィールドは、指定されたminとmax（両方を含む）の間のサイズでなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同様の方法で評価されます。

boolean

検証対象のフィールドは、ブール値にキャストできる必要があります。受け入れられる入力は、true、false、1、0、"1"、および"0"です。

confirmed

検証対象のフィールドは、{field}_confirmationの一致するフィールドを持っている必要があります。たとえば、検証対象のフィールドがpasswordの場合、一致するpassword_confirmationフィールドが入力に存在する必要があります。

contains:foo,bar,…

検証対象のフィールドは、指定されたすべてのパラメータ値を含む配列でなければなりません。

current_password

検証対象のフィールドは、認証されたユーザーのパスワードと一致する必要があります。ルールの最初のパラメータを使用して認証ガードを指定できます：

'password' => 'current_password:api'

date

検証対象のフィールドは、strtotime PHP関数に従って有効な非相対日付でなければなりません。

date_equals:date

検証対象のフィールドは、指定された日付と等しくなければなりません。日付は、PHP strtotime関数に渡され、有効なDateTimeインスタンスに変換されます。

date_format:format,…

検証対象のフィールドは、指定されたフォーマットのいずれかに一致する必要があります。フィールドを検証する際には、dateまたはdate_formatのいずれかを使用する必要があり、両方を使用してはいけません。この検証ルールは、PHPのDateTimeクラスがサポートするすべてのフォーマットをサポートしています。

decimal:min,max

検証対象のフィールドは数値であり、指定された小数点以下の桁数を含む必要があります：

// Must have exactly two decimal places (9.99)...
'price' => 'decimal:2'
// Must have between 2 and 4 decimal places...
'price' => 'decimal:2,4'

declined

検証対象のフィールドは、"no"、"off"、0、"0"、false、または"false"でなければなりません。

declined_if:anotherfield,value,…

検証対象のフィールドは、別の検証対象のフィールドが指定された値に等しい場合、"no"、"off"、0、"0"、false、または"false"でなければなりません。

different:field

検証対象のフィールドは、fieldとは異なる値でなければなりません。

digits:value

検証対象の整数は、valueの正確な長さを持っていなければなりません。

digits_between:min,max

整数の検証は、指定されたminとmaxの間の長さを持っていなければなりません。

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のような浮動小数点数として指定できます：

'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()


 `````dns`````および`````spoof`````バリデーターは、PHP `````intl`````拡張機能を必要とします。  
 <a name="rule-ends-with"></a>
#### ends_with:foo,bar,...
検証対象のフィールドは、指定された値のいずれかで終わっていなければなりません。  
 <a name="rule-enum"></a>
#### enum
`````Enum`````ルールは、検証対象のフィールドが有効な列挙型の値を含むかどうかを検証するクラスベースのルールです。`````Enum`````ルールは、列挙型の名前を唯一のコンストラクタ引数として受け取ります。プリミティブ値を検証する場合、バックエンド列挙型を`````Enum`````ルールに提供する必要があります：  
``````php
use App\Enums\ServerStatus;
use Illuminate\Validation\Rule;
$request->validate([
   'status' => [Rule::enum(ServerStatus::class)],
]);
`


``````php
Rule::enum(ServerStatus::class)
   ->only([ServerStatus::Pending, ServerStatus::Active]);
Rule::enum(ServerStatus::class)
   ->except([ServerStatus::Pending, ServerStatus::Active]);
`


``````php
use Illuminate\Support\Facades\Auth;
use Illuminate\Validation\Rule;
Rule::enum(ServerStatus::class)
   ->when(
   Auth::user()->isAdmin(),
   fn ($rule) => $rule->only(...),
   fn ($rule) => $rule->only(...),
   );
`

exclude

検証対象のフィールドは、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。

exclude_if:anotherfield,value

検証対象のフィールドは、anotherfieldフィールドがvalueに等しい場合、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:anotherfield,value

検証対象のフィールドは、anotherfieldフィールドがvalueに等しくない限り、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。valueがnull（exclude_unless:name,null）の場合、検証対象のフィールドは、比較フィールドがnullであるか、比較フィールドがリクエストデータから欠落している限り除外されます。

exclude_with:anotherfield

検証対象のフィールドは、anotherfieldフィールドが存在する場合、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。

exclude_without:anotherfield

検証対象のフィールドは、anotherfieldフィールドが存在しない場合、validateおよびvalidatedメソッドによって返されるリクエストデータから除外されます。

exists:table,column

検証対象のフィールドは、指定されたデータベーステーブルに存在しなければなりません。

Basic Usage of Exists Rule

'state' => 'exists:states'

 <a name="specifying-a-custom-column-name"></a>
#### Specifying a Custom Column Name
検証ルールによって使用されるデータベース列名を明示的に指定するには、データベーステーブル名の後に配置します：  
``````php
'state' => 'exists:states,abbreviation'
`

時折、existsクエリに使用する特定のデータベース接続を指定する必要があります。これを行うには、接続名をテーブル名の前に追加します：

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

テーブル名を直接指定する代わりに、テーブル名を決定するために使用されるEloquentモデルを指定できます：

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

検証ルールによって実行されるクエリをカスタマイズしたい場合は、Ruleクラスを使用してルールを流暢に定義できます。この例では、|文字を使用して検証ルールを区切るのではなく、検証ルールを配列として指定します：

use Illuminate\Database\Query\Builder;
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($data, [
   'email' => [
   'required',
   Rule::exists('staff')->where(function (Builder $query) {
   return $query->where('account_id', 1);
   }),
   ],
]);


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

extensions:foo,bar,…

検証対象のファイルは、リストされた拡張子のいずれかに対応するユーザー指定の拡張子を持っている必要があります：

'photo' => ['required', 'extensions:jpg,png'],

ファイルをユーザー指定の拡張子だけで検証することは決して行わないでください。このルールは、通常、mimesまたはmimetypesルールと組み合わせて使用されるべきです。

file

検証対象のフィールドは、正常にアップロードされたファイルでなければなりません。

filled

検証対象のフィールドは、存在する場合は空であってはなりません。

gt:field

検証対象のフィールドは、指定されたfieldまたはvalueより大きくなければなりません。2つのフィールドは同じタイプでなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同様の規則を使用して評価されます。

gte:field

検証対象のフィールドは、指定されたfieldまたはvalueより大きいか等しくなければなりません。2つのフィールドは同じタイプでなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同様の規則を使用して評価されます。

hex_color

検証対象のフィールドは、16進数形式の有効な色値を含む必要があります。

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']),
   ],
]);


``````php
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:anotherfield.*

検証対象のフィールドは、anotherfieldの値に存在しなければなりません。

integer

検証対象のフィールドは整数でなければなりません。

この検証ルールは、入力が「整数」変数型であることを確認するものではなく、PHPのFILTER_VALIDATE_INTルールによって受け入れられる型であることを確認するものです。入力を数値として検証する必要がある場合は、このルールをnumeric検証ルールと組み合わせて使用してください。

ip

検証対象のフィールドはIPアドレスでなければなりません。

ipv4

検証対象のフィールドはIPv4アドレスでなければなりません。

ipv6

検証対象のフィールドはIPv6アドレスでなければなりません。

json

検証対象のフィールドは、有効なJSON文字列でなければなりません。

lt:field

検証対象のフィールドは、指定されたfieldより小さくなければなりません。2つのフィールドは同じタイプでなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同様の規則を使用して評価されます。

lte:field

検証対象のフィールドは、指定されたfield以下でなければなりません。2つのフィールドは同じタイプでなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同様の規則を使用して評価されます。

lowercase

検証対象のフィールドは小文字でなければなりません。

list

検証対象のフィールドは、リストである配列でなければなりません。配列は、キーが0からcount($array) - 1までの連続した数字で構成されている場合、リストと見なされます。

mac_address

検証対象のフィールドはMACアドレスでなければなりません。

max:value

検証対象のフィールドは、最大value以下でなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同様の方法で評価されます。

max_digits:value

検証対象の整数は、最大長さがvalueでなければなりません。

mimetypes:text/plain,…

検証対象のファイルは、指定されたMIMEタイプのいずれかに一致しなければなりません：

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

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

mimes:foo,bar,…

検証対象のファイルは、リストされた拡張子のいずれかに対応するMIMEタイプを持っている必要があります：

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

拡張子を指定するだけで済みますが、このルールは実際にはファイルの内容を読み取ってMIMEタイプを推測することによってファイルのMIMEタイプを検証します。MIMEタイプとそれに対応する拡張子の完全なリストは、次の場所で見つけることができます：

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

MIME Types and Extensions

この検証ルールは、MIMEタイプとユーザーがファイルに割り当てた拡張子の一致を確認しません。たとえば、mimes:png検証ルールは、有効なPNGコンテンツを含むファイルを有効なPNG画像と見なしますが、ファイル名がphoto.txtであってもです。ファイルのユーザー指定の拡張子を検証したい場合は、extensionsルールを使用できます。

min:value

検証対象のフィールドは、最小valueを持っていなければなりません。文字列、数値、配列、およびファイルは、sizeルールと同様の方法で評価されます。

min_digits:value

検証対象の整数は、最小長さがvalueでなければなりません。

multiple_of:value

検証対象のフィールドはvalueの倍数でなければなりません。

missing

検証対象のフィールドは、入力データに存在してはなりません。

missing_if:anotherfield,value,…

検証対象のフィールドは、anotherfieldフィールドが任意のvalueに等しい場合、存在してはなりません。

missing_unless:anotherfield,value

検証対象のフィールドは、anotherfieldフィールドが任意のvalueに等しくない限り、存在してはなりません。

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:pattern

検証対象のフィールドは、指定された正規表現に一致してはいけません。

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

regex / not_regex パターンを使用する場合、特に正規表現に | 文字が含まれている場合は、| デリミタを使用するのではなく、配列を使用して検証ルールを指定する必要があるかもしれません。

nullable

検証対象のフィールドは null である可能性があります。

numeric

検証対象のフィールドは numeric でなければなりません。

present

検証対象のフィールドは、入力データに存在しなければなりません。

present_if:anotherfield,value,…

検証対象のフィールドは、anotherfield フィールドが任意の value に等しい場合に存在しなければなりません。

present_unless:anotherfield,value

検証対象のフィールドは、anotherfield フィールドが任意の value に等しくない限り存在しなければなりません。

present_with:foo,bar,…

検証対象のフィールドは、他の指定されたフィールドのいずれかが存在する場合にのみ存在しなければなりません。

present_with_all:foo,bar,…

検証対象のフィールドは、他の指定されたフィールドがすべて存在する場合にのみ存在しなければなりません。

prohibited

検証対象のフィールドは欠落しているか空でなければなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です:

値が null です。
値が空の文字列です。
値が空の配列または空の Countable オブジェクトです。
値が空のパスを持つアップロードされたファイルです。

prohibited_if:anotherfield,value,…

検証対象のフィールドは、anotherfield フィールドが任意の value に等しい場合に欠落しているか空でなければなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です:

値が 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:anotherfield,value,…

検証対象のフィールドは、anotherfield フィールドが任意の value に等しくない限り欠落しているか空でなければなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です:

値が null です。
値が空の文字列です。
値が空の配列または空の Countable オブジェクトです。
値が空のパスを持つアップロードされたファイルです。

prohibits:anotherfield,…

検証対象のフィールドが欠落していないか空でない場合、anotherfield のすべてのフィールドは欠落しているか空でなければなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です:

値が null です。
値が空の文字列です。
値が空の配列または空の Countable オブジェクトです。
値が空のパスを持つアップロードされたファイルです。

regex:pattern

検証対象のフィールドは、指定された正規表現に一致しなければなりません。

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

regex / not_regex パターンを使用する場合、特に正規表現に | 文字が含まれている場合は、| デリミタを使用するのではなく、配列を使用してルールを指定する必要があるかもしれません。

required

検証対象のフィールドは、入力データに存在し、空であってはなりません。フィールドが「空」であるとは、次のいずれかの基準を満たす場合です:

値が null です。
値が空の文字列です。
値が空の配列または空の Countable オブジェクトです。
値がパスのないアップロードされたファイルです。

required_if:anotherfield,value,…

検証対象のフィールドは、anotherfield フィールドが任意の value に等しい場合に存在し、空であってはなりません。

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_if_accepted:anotherfield,…

検証対象のフィールドは、anotherfield フィールドが "yes"、"on"、1、"1"、true、または "true" に等しい場合に存在し、空であってはなりません。

required_if_declined:anotherfield,…

検証対象のフィールドは、anotherfield フィールドが "no"、"off"、0、"0"、false、または "false" に等しい場合に存在し、空であってはなりません。

required_unless:anotherfield,value,…

検証対象のフィールドは、anotherfield フィールドが任意の value に等しくない限り存在し、空であってはなりません。これはまた、anotherfield がリクエストデータに存在しなければならないことを意味します、value が null でない限り。value が 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:field

指定された field は、検証対象のフィールドと一致しなければなりません。

size:value

検証対象のフィールドは、指定された value に一致するサイズを持たなければなりません。文字列データの場合、value は文字数に対応します。数値データの場合、value は指定された整数値に対応します（属性は numeric または integer ルールも持たなければなりません）。配列の場合、size は配列の count に対応します。ファイルの場合、size はキロバイト単位のファイルサイズに対応します。いくつかの例を見てみましょう:

// Validate that a string is exactly 12 characters long...
'title' => 'size:12';
// Validate that a provided integer equals 10...
'seats' => 'integer|size:10';
// Validate that an array has exactly 5 elements...
'tags' => 'array|size:5';
// Validate that an uploaded file is exactly 512 kilobytes...
'image' => 'file|size:512';

starts_with:foo,bar,…

検証対象のフィールドは、指定された値のいずれかで始まらなければなりません。

string

検証対象のフィールドは文字列でなければなりません。フィールドが null であることも許可したい場合は、nullable ルールをフィールドに割り当てる必要があります。

timezone

検証対象のフィールドは、DateTimeZone::listIdentifiers メソッドに従った有効なタイムゾーン識別子でなければなりません。

DateTimeZone::listIdentifiers メソッドに受け入れられる引数もこの検証ルールに提供できます:

'timezone' => 'required|timezone:all';
'timezone' => 'required|timezone:Africa';
'timezone' => 'required|timezone:per_country,US';

unique:table,column

検証対象のフィールドは、指定されたデータベーステーブル内に存在してはいけません。

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

テーブル名を直接指定する代わりに、テーブル名を決定するために使用されるEloquentモデルを指定できます：

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

column オプションを使用して、フィールドの対応するデータベースカラムを指定できます。column オプションが指定されていない場合、検証対象のフィールドの名前が使用されます。

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

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

時折、バリデーターによって行われるデータベースクエリのためにカスタム接続を設定する必要があるかもしれません。これを実現するために、接続名をテーブル名の前に追加できます:

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

特定のIDを無視するユニークルールの強制:

時には、ユニークバリデーション中に特定のIDを無視したい場合があります。例えば、ユーザーの名前、メールアドレス、場所を含む「プロフィール更新」画面を考えてみてください。メールアドレスがユニークであることを確認したいと思うでしょう。しかし、ユーザーが名前フィールドだけを変更し、メールフィールドを変更しない場合、ユーザーがすでにそのメールアドレスの所有者であるため、バリデーションエラーが発生しないようにしたいと思います。

バリデーターにユーザーのIDを無視するよう指示するために、Rule クラスを使用してルールを流暢に定義します。この例では、| 文字を使用してルールを区切るのではなく、検証ルールを配列として指定します:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
Validator::make($data, [
   'email' => [
   'required',
   Rule::unique('users')->ignore($user->id),
   ],
]);

ユーザーが制御するリクエスト入力を ignore メソッドに渡すことは決してしないでください。代わりに、オートインクリメントIDやEloquentモデルインスタンスからのUUIDなど、システム生成のユニークIDのみを渡すべきです。そうしないと、アプリケーションはSQLインジェクション攻撃に対して脆弱になります。

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

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

テーブルが id 以外の主キーのカラム名を使用している場合、ignore メソッドを呼び出す際にカラム名を指定できます:

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

デフォルトでは、unique ルールは、検証されている属性の名前に一致するカラムのユニーク性をチェックします。ただし、unique メソッドの第2引数として異なるカラム名を渡すことができます:

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

追加のWHERE句の追加:

where メソッドを使用してクエリをカスタマイズすることで、追加のクエリ条件を指定できます。例えば、account_id カラムの値が 1 であるレコードのみを検索するクエリ条件を追加してみましょう:

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

uppercase

検証対象のフィールドは大文字でなければなりません。

url

検証対象のフィールドは有効なURLでなければなりません。

有効と見なされるURLプロトコルを指定したい場合は、プロトコルを検証ルールのパラメータとして渡すことができます:

'url' => 'url:http,https',
'game' => 'url:minecraft,steam',

ulid

検証対象のフィールドは有効な Universally Unique Lexicographically Sortable Identifier (ULID) でなければなりません。

uuid

検証対象のフィールドは有効なRFC 4122 (バージョン1、3、4、または5) のユニバーサルユニーク識別子 (UUID) でなければなりません。

Conditionally Adding Rules

Skipping Validation When Fields Have Certain Values

特定のフィールドが他のフィールドに特定の値を持つ場合、そのフィールドを検証しないことを望むことがあります。これは 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',
]);

Validating When Present

特定の状況では、フィールドが検証されるデータに存在する場合にのみ、検証チェックを実行したいことがあります。これを迅速に実現するには、sometimes ルールをルールリストに追加します:

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

上記の例では、email フィールドは $data 配列に存在する場合にのみ検証されます。

常に存在する必要があるが空である可能性のあるフィールドを検証しようとしている場合は、オプションフィールドに関するこのノートを確認してください。

Complex Conditional Validation

時には、より複雑な条件ロジックに基づいて検証ルールを追加したいことがあります。例えば、あるフィールドが100より大きい場合にのみ、特定のフィールドを必要とすることがあるかもしれません。また、他のフィールドが存在する場合にのみ、2つのフィールドが特定の値を持つ必要があるかもしれません。これらの検証ルールを追加するのは面倒ではありません。まず、変更されない 静的ルール を持つ Validator インスタンスを作成します:

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

私たちのウェブアプリケーションがゲームコレクター向けであると仮定しましょう。ゲームコレクターが私たちのアプリケーションに登録し、100以上のゲームを所有している場合、なぜそんなに多くのゲームを所有しているのか説明してもらいたいと思います。例えば、ゲームの再販ショップを運営しているか、単にゲームを集めるのが好きな場合です。この要件を条件付きで追加するために、sometimes メソッドを Validator インスタンスで使用できます。

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

sometimes メソッドに渡される最初の引数は、条件付きで検証しているフィールドの名前です。2番目の引数は、追加したいルールのリストです。3番目の引数として渡されたクロージャが true を返す場合、ルールが追加されます。このメソッドを使用すると、複雑な条件付き検証を簡単に構築できます。複数のフィールドに対して条件付き検証を一度に追加することもできます:

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

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

Complex Conditional Array Validation

時には、同じネストされた配列内の別のフィールドに基づいてフィールドを検証したいことがありますが、そのインデックスがわからない場合があります。このような状況では、クロージャに2番目の引数を受け取ることを許可し、検証中の配列の現在の個々のアイテムを受け取ることができます:

$input = [
   'channels' => [
   [
   'type' => 'email',
   'address' => '',
   ],
   [
   'type' => 'url',
   'address' => 'https://example.com',
   ],
   ],
];
$validator->sometimes('channels.*.address', 'email', function (Fluent $input, Fluent $item) {
   return $item->type === 'email';
});
$validator->sometimes('channels.*.address', 'url', function (Fluent $input, Fluent $item) {
   return $item->type !== 'email';
});

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

Validating Arrays

array 検証ルールのドキュメントで説明されているように、array ルールは許可される配列キーのリストを受け入れます。配列内に追加のキーが存在する場合、検証は失敗します:

use Illuminate\Support\Facades\Validator;
$input = [
   'user' => [
   'name' => 'Taylor Otwell',
   'username' => 'taylorotwell',
   'admin' => true,
   ],
];
Validator::make($input, [
   'user' => 'array:name,username',
]);

一般的に、配列内に存在することが許可される配列キーを常に指定するべきです。そうしないと、バリデーターの validate および validated メソッドは、他のネストされた配列検証ルールによって検証されなかったキーを含む、検証されたデータのすべてを返します。

Validating Nested Array Input

ネストされた配列に基づくフォーム入力フィールドの検証は面倒ではありません。「ドット表記」を使用して、配列内の属性を検証できます。例えば、受信した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',
   ]
],

Accessing Nested Array Data

時には、属性に検証ルールを割り当てる際に、特定のネストされた配列要素の値にアクセスする必要があるかもしれません。これは Rule::forEach メソッドを使用して実現できます。forEach メソッドは、検証中の配列属性の各反復に対して呼び出され、属性の値と明示的で完全に展開された属性名を受け取ります。クロージャは、配列要素に割り当てるルールの配列を返す必要があります:

use App\Rules\HasPermission;
use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rule;
$validator = Validator::make($request->all(), [
   'companies.*.id' => Rule::forEach(function (string|null $value, string $attribute) {
   return [
   Rule::exists(Company::class, 'id'),
   new HasPermission('manage-company', $value),
   ];
   }),
]);

Error Message Indexes and Positions

配列を検証する際、アプリケーションによって表示されるエラーメッセージ内で、検証に失敗した特定のアイテムのインデックスまたは位置を参照したいことがあります。これを実現するために、:index および :position (1 から始まる) プレースホルダーをカスタム検証メッセージに含めることができます:

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.',
]);

上記の例では、検証が失敗し、ユーザーには「写真 #2 を説明してください。」というエラーが表示されます。

必要に応じて、second-index、second-position、third-index、third-position などを介して、さらに深くネストされたインデックスや位置を参照することができます。

'photos.*.attributes.*.string' => 'Invalid attribute for photo #:second-position.',

Validating Files

Laravelは、mimes、image、min、max などのアップロードされたファイルを検証するために使用できるさまざまな検証ルールを提供します。ファイルを検証する際にこれらのルールを個別に指定することは自由ですが、Laravelは便利な流暢なファイル検証ルールビルダーも提供しています:

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\Rule;
use Illuminate\Validation\Rules\File;
Validator::validate($input, [
   'photo' => [
   'required',
   File::image()
   ->min(1024)
   ->max(12 * 1024)
   ->dimensions(Rule::dimensions()->maxWidth(1000)->maxHeight(500)),
   ],
]);

画像の寸法を検証する方法についての詳細は、寸法ルールのドキュメントで見つけることができます。

File Sizes

便利のために、最小および最大ファイルサイズは、ファイルサイズ単位を示すサフィックスを持つ文字列として指定できます。kb、mb、gb、tb サフィックスがサポートされています:

File::image()
   ->min('1kb')
   ->max('10mb')

File Types

types メソッドを呼び出す際に拡張子を指定するだけで済みますが、このメソッドは実際にはファイルの内容を読み取り、そのMIMEタイプを推測することによってファイルのMIMEタイプを検証します。MIMEタイプとそれに対応する拡張子の完全なリストは、次の場所で見つけることができます:

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

Validating Passwords

パスワードが適切な複雑さのレベルを持つことを保証するために、Laravelの Password ルールオブジェクトを使用できます:

use Illuminate\Support\Facades\Validator;
use Illuminate\Validation\Rules\Password;
$validator = Validator::make($request->all(), [
   'password' => ['required', 'confirmed', Password::min(8)],
]);

Password ルールオブジェクトを使用すると、パスワードに少なくとも1つの文字、数字、記号、または混合大文字を要求するなど、アプリケーションのパスワード複雑さ要件を簡単にカスタマイズできます:

// Require at least 8 characters...
Password::min(8)
// Require at least one letter...
Password::min(8)->letters()
// Require at least one uppercase and one lowercase letter...
Password::min(8)->mixedCase()
// Require at least one number...
Password::min(8)->numbers()
// Require at least one symbol...
Password::min(8)->symbols()

さらに、uncompromised メソッドを使用して、パスワードが公開されたパスワードデータ侵害漏洩で危険にさらされていないことを確認できます:

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

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

デフォルトでは、パスワードがデータ漏洩で少なくとも1回出現した場合、それは危険にさらされていると見なされます。この閾値は、uncompromised メソッドの最初の引数を使用してカスタマイズできます:

// Ensure the password appears less than 3 times in the same data leak...
Password::min(8)->uncompromised(3);

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

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

Defining Default Password Rules

アプリケーションの単一の場所でパスワードのデフォルト検証ルールを指定することは便利です。これは、Password::defaults メソッドを使用して簡単に実現できます。このメソッドはクロージャを受け入れます。defaults メソッドに渡されるクロージャは、パスワードルールのデフォルト構成を返す必要があります。通常、defaults ルールは、アプリケーションのサービスプロバイダーの boot メソッド内で呼び出されるべきです:

use Illuminate\Validation\Rules\Password;
/**
 * Bootstrap any application services.
 */
public function boot(): void
{
   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]);
   // ...
});

Custom Validation Rules

Using Rule Objects

Laravelはさまざまな便利な検証ルールを提供していますが、自分自身のルールを指定したい場合もあるかもしれません。カスタム検証ルールを登録する方法の1つは、ルールオブジェクトを使用することです。新しいルールオブジェクトを生成するには、make:rule Artisan コマンドを使用できます。このコマンドを使用して、文字列が大文字であることを確認するルールを生成します。Laravelは新しいルールを app/Rules ディレクトリに配置します。このディレクトリが存在しない場合、Laravelはルールを作成するためにArtisanコマンドを実行するときにそれを作成します:

php artisan make:rule Uppercase

ルールが作成されたら、その動作を定義する準備が整いました。ルールオブジェクトには1つのメソッドがあります: validate。このメソッドは、属性名、その値、および失敗時に検証エラーメッセージで呼び出されるコールバックを受け取ります:

<?php
namespace App\Rules;
use Closure;
use Illuminate\Contracts\Validation\ValidationRule;
class Uppercase implements ValidationRule
{
   /**
     * Run the validation rule.
   */
   public function validate(string $attribute, mixed $value, Closure $fail): void
   {
   if (strtoupper($value) !== $value) {
   $fail('The :attribute must be uppercase.');
   }
   }
}

ルールが定義されたら、他の検証ルールとともにルールオブジェクトのインスタンスを渡すことで、バリデーターにアタッチできます:

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

Translating Validation Messages

$fail クロージャに文字通りのエラーメッセージを提供する代わりに、翻訳文字列キーを提供し、Laravelにエラーメッセージを翻訳するよう指示することもできます:

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

必要に応じて、translate メソッドの最初と第二の引数としてプレースホルダーの置換と好ましい言語を提供できます:

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

Accessing Additional Data

カスタム検証ルールクラスが検証中の他のすべてのデータにアクセスする必要がある場合、ルールクラスは Illuminate\Contracts\Validation\DataAwareRule インターフェースを実装できます。このインターフェースは、クラスが setData メソッドを定義することを要求します。このメソッドは、検証が進む前にLaravelによって自動的に呼び出され、検証中のすべてのデータを受け取ります:

<?php
namespace App\Rules;
use Illuminate\Contracts\Validation\DataAwareRule;
use Illuminate\Contracts\Validation\ValidationRule;
class Uppercase implements DataAwareRule, ValidationRule
{
   /**
     * All of the data under validation.
   *
     * @var array<string, mixed>
   */
   protected $data = [];
   // ...
   /**
     * Set the data under validation.
   *
     * @param  array<string, mixed>  $data
   */
   public function setData(array $data): static
   {
   $this->data = $data;
   return $this;
   }
}

または、検証ルールが検証を実行しているバリデーターインスタンスにアクセスする必要がある場合は、ValidatorAwareRule インターフェースを実装できます:

<?php
namespace App\Rules;
use Illuminate\Contracts\Validation\ValidationRule;
use Illuminate\Contracts\Validation\ValidatorAwareRule;
use Illuminate\Validation\Validator;
class Uppercase implements ValidationRule, ValidatorAwareRule
{
   /**
     * The validator instance.
   *
     * @var \Illuminate\Validation\Validator
   */
   protected $validator;
   // ...
   /**
     * Set the current validator.
   */
   public function setValidator(Validator $validator): static
   {
   $this->validator = $validator;
   return $this;
   }
}

Using Closures

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

use Illuminate\Support\Facades\Validator;
use Closure;
$validator = Validator::make($request->all(), [
   'title' => [
   'required',
   'max:255',
   function (string $attribute, mixed $value, Closure $fail) {
   if ($value === 'foo') {
   $fail("The {$attribute} is invalid.");
   }
   },
   ],
]);

Implicit Rules

デフォルトでは、検証されている属性が存在しないか空の文字列を含む場合、通常の検証ルール（カスタムルールを含む）は実行されません。例えば、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 --implicit

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