XserverでLaravel 11を動かす際のハマりどころ集

投稿日 2026年6月15日
著者 tanaka
カテゴリー技術ブログ

はじめに

こんにちは、ACMEE 情シスです。今回は、我々が抱えた「Xserverの共有レンタルサーバーでLaravel 11を動かす」というチャレンジについて共有します。共有サーバー特有の制約を乗り越えるための工夫をお伝えします。

SQLiteの古さによる問題

Xserverでは、SQLiteのバージョンが3.7系と古く、Laravel 11が内部で使用する pragma_table_xinfo に対応していません。このため、スキーマの取得でエラーが発生することがありました。

この問題を回避するために、我々は $guarded を使用せずに、$fillable を明示的に定義する方法を採用しました。これにより、エラーを回避しつつ、安全にモデルの属性を管理することができました。

curlの古さによる問題

同様に、curlのバージョンも古く、CURL_SSLVERSION_TLSv1_2 や TLSv1_3 の定数が未定義です。このため、Laravelが依存するGuzzleライブラリが500エラーを返すことがありました。

この問題に対しては、定数を polyfill する共通ファイルを作成し、アプリケーション全体で使用することで対応しました。具体的には以下のように定数を定義しました。

if (!defined('CURL_SSLVERSION_TLSv1_2')) {
    define('CURL_SSLVERSION_TLSv1_2', 6);
}
if (!defined('CURL_SSLVERSION_TLSv1_3')) {
    define('CURL_SSLVERSION_TLSv1_3', 7);
}

環境変数の優先順位の罠

さらに、OS側の環境変数がLaravelの .env ファイルよりも優先されてしまうという問題にも直面しました。これにより、意図しない設定がアプリケーションに影響を与えることがありました。

この問題には、環境変数の設定に注意し、必要に応じて env() を使ったハードコーディングで対処しました。

教訓: アプリ側での対応がカギ

これらの経験から得た教訓は、共有サーバーでは「ミドルウェアをアップデートする」という選択肢がないため、アプリケーション側で問題に寄り添う発想が必要だということです。制約の中でどうアプリケーションを柔軟に対応させるかが、運用の肝となります。

おわりに

共有レンタルサーバーでの開発は制約が多く、時には頭を抱えることもありますが、その分クリエイティブな解決策が求められます。それが、私たち情シスにとっての面白さでもあります。これからも新たなチャレンジを楽しみながら、解決策を模索していきます。次回の記事もお楽しみに！