Node.js 入力検証ライブラリ：実装スタイルとアーキテクチャの深層比較

Node.js 生態系において、ユーザー入力や外部データの検証はセキュリティと安定性の要です。express-validator、is-my-json-valid、joi、validator はそれぞれ異なる哲学に基づいて設計されており、単に「検証する」という目的は同じでも、コードの書き方、保守性、そして適用できる場面が大きく異なります。本稿では、これら 4 つのライブラリを実際のエンジニアリング視点で比較し、どの状況でどれを選ぶべきかを明確にします。

🛠️ 検証アプローチ：文字列、スキーマ、そしてミドルウェア

ライブラリ選定で最も重要なのは、「何を検証したいか」と「どこで検証したいか」です。

validator は、個々の文字列値を検証する関数の集合です。

• スキーマ定義はありません。
• 単一の値に対して true/false または変換結果を返します。
• 最も軽量ですが、オブジェクト全体の構造検証は手动で行う必要があります。

// validator: 単一文字列の検証
const validator = require('validator');

const email = 'user@example.com';
if (!validator.isEmail(email)) {
  throw new Error('Invalid email');
}

joi は、オブジェクト全体のスキーマを定義して検証します。

• データ構造そのものを記述します。
• ネストされたオブジェクトや配列の検証に強力です。
• Express に依存しないため、ドメイン層での利用に適しています。

// joi: オブジェクトスキーマの検証
const Joi = require('joi');

const schema = Joi.object({
  email: Joi.string().email().required(),
  age: Joi.number().min(18)
});

const { error } = schema.validate({ email: 'user@example.com', age: 20 });
if (error) throw error;

express-validator は、Express ミドルウェアとして動作します。

• validator ライブラリをベースにしています。
• リクエストオブジェクト (req) から直接値を読み取り、検証します。
• 検証失敗時に自動的にエラーを次のハンドラーへ渡します。

// express-validator: ミドルウェアチェーンによる検証
const { check, validationResult } = require('express-validator');

app.post('/register', [
  check('email').isEmail(),
  check('password').isLength({ min: 6 })
], (req, res) => {
  const errors = validationResult(req);
  if (!errors.isEmpty()) return res.status(400).json({ errors: errors.array() });
  // 処理続行
});

is-my-json-valid は、JSON Schema 仕様に基づいて検証します。

• 外部定義された JSON Schema をそのまま利用できます。
• 検証ロジックとデータ定義を完全に分離できます。
• 主に設定ファイルや外部 API との連携で使用されます。

// is-my-json-valid: JSON Schema による検証
const validator = require('is-my-json-valid');

const schema = {
  type: 'object',
  properties: {
    email: { type: 'string', format: 'email' }
  },
  required: ['email']
};

const validate = validator(schema);
if (!validate({ email: 'user@example.com' })) {
  console.error(validate.errors);
}

🔗 統合と依存関係：フレームワークへの結びつき

プロジェクトのアーキテクチャによって、ライブラリがフレームワークに縛られることは大きな制約になります。

express-validator は Express に強く依存しています。

• Express アプリ以外（例：Koa、Fastify、純粋な CLI ツール）では使用できません。
• ミドルウェアスタックの一部として動作するため、ライフサイクル管理が容易です。
• BFF（Backend For Frontend）パターンを採用しているフロントエンドチームには親和性が高いです。

joi と validator はフレームワーク独立です。

• any runtime (Node.js, Browser) で動作します。
• 検証ロジックをサービス層やユーティリティ層に閉じ込めたい場合に適しています。
• テストが容易で、フレームワークのバージョンアップに影響されにくいです。

is-my-json-valid もフレームワーク独立ですが、仕様に依存します。

• JSON Schema という標準仕様に基づくため、他言語との共有が容易です。
• ただし、JSON Schema 自体の学習コストと、仕様のバージョン（Draft 4 中心）に注意が必要です。

⚠️ エラーハンドリングとフィードバック

検証失敗時にどう扱うかも、ユーザー体験とデバッグのしやすさに直結します。

express-validator は、エラーを構造化して提供します。

• validationResult 関数で簡単にエラー配列を取得できます。
• Express のエラーハンドリングミドルウェアと統合しやすいです。

// express-validator: 構造化されたエラー取得
const errors = validationResult(req);
// errors.array() で統一された形式でエラー一覧を取得可能

joi は、詳細なエラーオブジェクトを返します。

• どのフィールドが、なぜ失敗したかが明確です。
• エラーメッセージのカスタマイズ機能も豊富です。

// joi: 詳細なエラー情報
const { error } = schema.validate(data);
// error.details 配列に各フィールドの失敗理由が含まれる

validator は、真偽値または変換結果のみを返します。

• エラーメッセージは自分で用意する必要があります。
• 単純な分岐には適していますが、複雑なエラー収集には向いていません。

// validator: 真偽値による判定
if (!validator.isURL(url)) {
  // 自分でエラーメッセージを定義する必要がある
  throw new Error('Invalid URL provided');
}

is-my-json-valid は、検証関数にエラー配列が付与されます。

• JSON Schema のエラー形式に従います。
• 仕様に基づいているため、エラー内容は一貫していますが、可读性はライブラリによります。

// is-my-json-valid: errors 配列による確認
if (!validate(data)) {
  // validate.errors にスキーマ違反の詳細が入る
  console.log(validate.errors);
}

📅 保守性と将来性

ライブラリのメンテナンス状況は、長期プロジェクトにおいてリスク管理の重要な要素です。

validator と express-validator は活発に維持されています。

• 多くのプロジェクトで標準的に採用されており、コミュニティサポートが厚いです。
• Express エコシステムの一部として安定しています。

joi も広く使われており安定しています。

• 以前は Hapi フレームワークに同梱されていましたが、現在は独立しています。
• 機能豊富ですが、その分バンドルサイズが大きくなる傾向があります。

is-my-json-valid は注意が必要です。

• 更新頻度が低く、JSON Schema Draft 4 に準拠しています。
• 最新の JSON Schema 機能を使いたい場合や、パフォーマンスが重要な場合は、ajv などのより現代的な替代品の評価を推奨します。
• 既存の Draft 4 資産がある場合を除き、新規プロジェクトでの採用は慎重になるべきです。

📊 比較サマリー

💡 最終的な推奨事項

プロジェクトの要件に応じて、以下のように選定するのが賢明です。

1. Express API を構築している場合： express-validator が最適です。リクエストライフサイクルに自然に統合され、ボイラープレートコードを減らせます。

2. 複雑なビジネスロジックの検証が必要な場合： joi を選択してください。スキーマ定義によりコードが自己文書化され、ドメイン層の独立性を保てます。

3. 軽量なスクリプトや単一値のチェックの場合： validator 十分です。依存関係を最小限に抑えたい場合に適しています。

4. JSON Schema 準拠が必須の場合： is-my-json-valid は利用可能ですが、新規プロジェクトでは ajv などのよりパフォーマンスが高く維持されているライブラリを比較検討することを強く推奨します。

入力検証はアプリケーションの防衛線です。単に機能するものを選ぶだけでなく、チームのスキルセット、アーキテクチャの方向性、そして将来の保守性を考慮して選定しましょう。