はじめに
こんにちは、Racing & Lottery開発部(RLD)でアプリケーションエンジニアを務めるJuliusです。本記事では、Laravelを使用した、Webアプリケーションの多言語対応システムを実装した際の私たちの経験を共有したいと思います。
国際化されたアプリケーションを構築する際は、適切なローカライゼーション戦略を選択することが非常に重要です。それは、ユーザーエクスペリエンスだけでなく、開発効率、保守コスト、セキュリティ上の考慮事項にも影響を及ぼすからです。私たちのサービスは、デスクトップとモバイルどちらのインターフェースにおいても、日本語や英語など、複数の言語をサポートする必要がありました。
実装の過程で、主に以下の2つのアプローチを検討しました。
・Laravelの標準的な変数ベースのローカライゼーション
・完全なHTMLファイルを言語ごとに分離するテンプレートベースのアプローチ
2つの戦略の内容、そのトレードオフ、多言語コンテンツを扱う際の重要なセキュリティ上の考慮事項について、私たちが学んだことをご紹介します。
言語検出戦略
多言語アプリケーションにおける最初の課題の一つは、ユーザーに対して表示する言語を決定することです。私たちは、複数のフォールバック層を持つ優先順位ベースの検出メカニズムを実装しました。
優先順位：
- URLパラメータ - ?locale=enによる明示的なユーザー設定
- Cookie - 前回のセッションから保持されたユーザー設定
- Accept-Languageヘッダー - ブラウザの言語設定
- デフォルト設定 - アプリケーションのデフォルト（通常は日本語）
言語検出フロー
コード実装
セキュリティ上の考慮事項
- 入力検証：インジェクション攻撃を防ぐため、常にlocale値を許可されたホワイトリスト（enum）に対して検証する
- Cookieセキュリティ：locale Cookieが適切にスコープされ、検証なしでユーザー制御データを含まないようにする
- パストラバーサル：検証なしでファイルパスに生のlocale値を使用しない - enumまたは厳密なホワイトリストを使用する
テンプレートベースのローカライゼーションアーキテクチャ
テンプレートベースのアプローチでは、各言語ごとに個別のビューファイルを維持します。システムは、フォールバック階層を使用して、ユーザーのロケールに基づいて適切なテンプレートを自動的にロードします。
ビューディレクトリ構造
ビュー解決とフォールバック階層
モバイルデバイスの場合：
デスクトップの場合：
コード実装
セキュリティノート：ロケール値にenumを使用することで、ディレクトリトラバーサル攻撃を防ぎます。生のユーザー入力をファイルパスに連結しないでください。
Laravelの標準ローカライゼーションアプローチ
Laravelの組み込みローカライゼーションは、翻訳文字列がHTML構造とは別に保存される変数ベースのシステムを使用します：
参照: https://laravel.com/docs/12.x/localization
翻訳ファイル
ビューでの使用方法
比較：テンプレートベース vs 変数ベースのローカライゼーション
|
側面 |
テンプレートベース（個別のHTMLファイル） |
変数ベース（Laravel標準） |
|
HTML最適化 |
容易 - 各言語が独自のHTML構造を持つ |
困難 - 単一の構造がすべての言語に適合する必要がある |
|
メンテナンスファイル |
言語数で乗算される |
単一のビューファイルセット |
|
フォールバック動作 |
デフォルト言語テンプレートにフォールバック（グレースフル） |
変数ごとのフォールバック（言語が混在する可能性） |
|
デザイナーワークフロー |
デザイナーが独立して完全なページを作成可能 |
デザイナーは開発者と協力して構造/コンテンツを分離する必要がある |
|
QAコスト |
すべての言語バージョンを徹底的にテストする必要がある |
一部の言語の組み合わせをスキップする可能性 |
|
セキュリティリスク |
低 - 言語ごとの静的コンテンツ |
高 - XSSを防ぐためにすべての翻訳文字列をサニタイズする必要がある |
|
コンテンツ長の柔軟性 |
高 - 各言語が異なるレイアウトを持つことができる |
低 - 最も長い翻訳に対応する必要がある |
|
翻訳の欠落 |
デフォルト言語ページを表示（完全なUX） |
翻訳キーまたは混在コンテンツを表示（壊れたUX） |
多言語アプリケーションにおけるセキュリティ上の考慮事項
1. クロスサイトスクリプティング（XSS）の防止
変数ベースのローカライゼーションでは、ユーザー生成コンテンツが言語ファイルに保存されている場合、翻訳文字列がXSS攻撃のベクターになる可能性があります：
2. ロケール検証とセキュリティフロー
コード実装サンプル
3. コンテンツセキュリティポリシー（CSP）
多言語コンテンツを提供する場合、CSPヘッダーが適切に設定されていることを確認してください：
4. 文字エンコーディング
エンコーディングベースの攻撃を防ぐため、常に適切な文字セットを設定してください：
所感と学んだこと
このローカライゼーションシステムの実装から、いくつかの貴重な教訓を学びました：
- グレースフルデグラデーション：フォールバック階層により、特定の言語テンプレートが欠落している場合でも、ユーザーは常に完全で機能的なページを見ることができます。
- チームコラボレーション：テンプレートベースのアプローチにより、デザインチームが独立して作業できるようになり、開発速度が大幅に向上しました。
- メンテナンスのトレードオフ：より多くのファイルを維持していますが、明確な分離により、変更が特定の言語/デバイスの組み合わせに分離されるため、実際には更新が容易になります。
- パフォーマンスの考慮事項：ビューパス解決は最小限のオーバーヘッドを追加し、Laravelのビューキャッシュにより、本番環境でのパフォーマンスへの影響は軽減されます。
セキュリティファースト：最初からロケール入力を検証することで、潜在的な脆弱性を防ぎました。enumの使用は、型安全性とセキュリティにとって重要でした。
結論
Webアプリケーションの多言語対応を構築するには、ユーザーエクスペリエンス、開発ワークフロー、保守コスト、セキュリティなど、多くの要素を慎重に検討する必要があります。
Laravelの標準的なローカライゼーションは多くのユースケースで優れていますが、私たちは、ユーザーに提供する複雑なコンテンツが豊富なアプリケーションを扱う際に、テンプレートベースのアプローチが独自の利点を提供すると判断しました。
本記事が、他のチームがローカライゼーション戦略を検討する際の参考になれば幸いです。
すべてのアプリケーションには独自の要件があります。しかし、トレードオフを理解することで、安全で保守可能なコードを維持しながら、正しい判断が可能となり、ユーザーに適切なサービスを提供できるようになります。
※掲載内容は2025年12月25日時点のものです。
私たちと一緒に働きませんか？
コマース＆マーケティングカンパニーでは、新たなサービス開発から日々の運用・改善まで、一緒に働く仲間を募集中！エンジニアやプロダクトマネージャーなど、幅広い職種で募集しています。ご応募をお待ちしております。
