レンタルサーバーでMVCフレームワーク？既存の壁を越え、WordPressタイプの自作フレームワークへ！

ウェブ開発の世界に足を踏み入れ、まず私が直面したのは、レンタルサーバーと一般的なMVCフレームワークとの相性の壁でした。多くの開発者が利用するLaravelやSymfonyといったモダンなフレームワークは魅力的ですが、限られた共有レンタルサーバー環境での運用は、想像以上に困難を伴いました。

その結果、「既存のフレームワークをサーバーに合わせる」のではなく、「サーバーに合ったフレームワークを自作する」という結論に至り、WordPressの使いやすさを参考にしつつ、自身のMVCフレームワークを構築する挑戦が始まったのです。

レンタルサーバーと既存MVCフレームワークの現実

PHPのモダンなフレームワーク、例えばLaravelやSymfonyは、その強力な機能と開発効率で多くのプロジェクトに採用されています。私もそれらに大きな魅力を感じ、自分のサイト構築に活用したいと考えていました。しかし、一般的なレンタルサーバー、特に共有レンタルサーバー環境では、いくつかのハードルに直面しました。

1. Composer (コンポーザー) の制約

モダンなPHPフレームワークは、ほぼ例外なくComposerという依存性管理ツールを使用します。これにより、必要なライブラリを簡単に導入し、プロジェクトの管理を効率化できます。しかし、共有レンタルサーバーでは、SSH接続が制限されていたり、Composerの実行に必要なメモリやCPUリソースが不足していたりすることが少なくありませんでした。

プロジェクトのデプロイ（サーバーへの展開）には、ローカル環境でComposerを使って構築したプロジェクト全体をアップロードするか、サーバー側でComposerコマンドを実行するかのどちらかになりますが、後者ができない場合、デプロイ手順が複雑化します。特に頻繁な更新を考えると、これは大きな負担でした。

2. ディレクトリ構造とWeb公開ディレクトリの問題

多くのフレームワークは、セキュリティ上の理由から、Webサーバーから直接アクセスできるファイルをpublicなどの特定のディレクトリ内に限定する構造（Web公開ディレクトリの制約）を採用しています。例えば、index.phpファイルだけをWeb公開ディレクトリに置き、それ以外の設定ファイルやソースコードはWebからアクセスできない安全な場所に置くのがベストプラクティスです。

しかし、レンタルサーバーの多くは、ドメインのルートディレクトリ（例: public_html）がそのままWeb公開ディレクトリとなるように設定されています。このため、フレームワークのディレクトリ構造をサーバーの制約に合わせるために、シンボリックリンクを張ったり、.htaccessで複雑なリライトルールを記述したりと、手間がかかる上に、完全に安全な状態に設定するのが困難な場合がありました。

3. PHPのバージョンと拡張機能の制約

フレームワークが求めるPHPのバージョンや、特定の拡張機能（例: mbstring, pdo_mysql など）がレンタルサーバーで利用できない、あるいはバージョンが古すぎるといった問題も発生しました。共有サーバーでは、ユーザーが自由にPHP環境をカスタマイズできる範囲が限られていることが多く、フレームワークの要件を満たせないケースもありました。

自作フレームワークへの転換：WordPressからのインスピレーション

これらの課題に直面し、私は「既存のフレームワークをサーバーに無理やり合わせる」というアプローチに限界を感じました。そこで考えたのが、**「レンタルサーバーの環境に最適化された、自分にとって使いやすいMVCフレームワークを自作する」**という道です。

この発想のきっかけとなったのが、他ならぬWordPressです。WordPressもPHPで書かれた大規模なシステムですが、一般的なレンタルサーバーで非常に簡単にインストール・運用できます。なぜWordPressはそれが可能なのか？その秘密は、WordPressが「特別なサーバー設定を必要としない」シンプルなディレクトリ構造と、一般的なPHP環境で動作するように設計されている点にあると考えました。

特に注目したのは以下の点です。

単一のエントリーポイント: WordPressは基本的にindex.phpという一つのファイルを通じて全てのリクエストを処理します。これは「フロントコントローラー」というMVCフレームワークの設計思想と共通しており、.htaccessを使ったシンプルなリライトルールで実現できます。
Composer不要: WordPress自体はComposerを必須とせず、必要なライブラリは同梱されています。これにより、FTPアップロードだけで完結する手軽なデプロイが可能です。
DB接続の簡潔さ: wp-config.phpのようなシンプルな設定ファイルでデータベース接続情報が管理され、特別な設定なしに動作します。

私は、これらのWordPressの「レンタルサーバーフレンドリーな設計」の思想を、自分のMVCフレームワークに取り入れることにしました。

自作MVCフレームワークのメリットと挑戦

自作のMVCフレームワークは、もちろん既存のフレームワークのような多機能性はありません。しかし、私にとっては大きなメリットがあります。

完全にコントロール可能: 必要な機能だけを実装するため、軽量で、パフォーマンスを最大限に引き出すことができます。
レンタルサーバーに最適化: public_html直下に設置できるシンプルな構造や、Composerを使わないデプロイ方法など、レンタルサーバーの制約に合わせて自由に設計できます。
学習効果の最大化: フレームワークの根幹部分から自分で書くため、PHPの内部動作、Webの仕組み、MVCの設計思想などを深く理解できます。これは、今後のウェブ開発キャリアにおいてかけがえのない財産となります。
アフィリエイト目的特化: 大量のCSVデータを扱うという私の具体的なニーズに合わせて、データ処理や表示の最適化を最初から考慮した設計が可能です。WordPressでは難しかった大量商品の効率的な管理・表示が目標です。

もちろん、この道のりは簡単ではありません。ルーティングの構築、データベースとの連携、エラーハンドリングなど、多くの技術的な課題に直面しています。つい最近も、ルーティングの問題を解決したと思ったら、今度はデータベースのカラム名に関するエラーにぶつかりました。しかし、PHPのエラーログを有効にしたことで、問題の所在が明確になり、一つ一つ着実に解決の糸口を見つけることができています。

まとめ

レンタルサーバーでの既存MVCフレームワークの運用に挫折し、自作フレームワークへと舵を切った私の挑戦は、決して楽な道ではありません。しかし、WordPressのシンプルさを参考にしつつ、自分の手でWebサイトの基盤を築き上げていく過程は、深い学びと大きな達成感を与えてくれています。

この奮闘記を通じて、私と同じようにレンタルサーバーでのフレームワーク運用に悩む方や、自作フレームワークに興味がある方の参考になれば幸いです。これからも、エラーと格闘しながら、理想のアフィリエイトサイト構築に向けて進んでいきます。

投稿者プロフィール

bicstation: AIアシスタントとの協業が、この奮闘記を可能にした
実は、今回一連の記事を執筆し、そして開発を進める上で、強力な「相棒」の存在がありました。それが、私のような開発者をサポートしてくれるAIアシスタントです。

PHPの難解なエラーログに直面した時、記事の構成がなかなか思いつかなかった時、あるいはブログのテーマに合ったアイキャッチ画像が必要だった時など、数々の場面でAIに相談し、助けを借りました。

例えば、「レンタルサーバーでのphp.ini設定の難しさ」や「.envファイルの問題」といった、私が実体験で感じた課題を伝えると、AIは瞬時にその技術的な背景や影響を整理し、ブログ記事として読者に伝わりやすい文章の骨子を提案してくれました。また、記事のテーマに合わせたアイキャッチ画像も、具体的な指示を出すだけで瞬時に生成してくれたおかげで、コンテンツ作成のスピードが格段に向上しました。

AIは完璧ではありませんが、まさに「もう一人の自分」のように、アイデアの壁打ち相手になったり、膨大な知識の中から必要な情報を引き出してくれたり、私の思考を整理する手助けをしてくれたりします。一人で抱え込みがちな開発の課題も、AIと対話することで、新たな視点や解決策が見えてくることが多々ありました。

このブログを通じて私の奮闘記を共有できているのも、AIアシスタントの存在なくしては成し得なかったでしょう。これからも、AIを賢く活用しながら、開発と情報発信を続けていきたいと思います。