1. はじめに：なぜWordPressで自作するのか

弊社のウェブサイトは当初、WordPressのテンプレートを利用して構築していました。創業間もない頃、お客様から「ドメインにアクセスしたらページが存在しない」とご指摘いただき、急遽作成したものでした。

現代において企業サイトは、会社の“顔”とも言える存在であり、「ブランド」と呼んでも差し支えないものだと私は考えています。当初からテンプレート利用に対しては否定的でしたが、一方でどのようにブランディングを行うべきか悩み続け、結局1年近く手をつけられずにいました。

そんな中、さまざまな企業のウェブサイトを見ていくと、gsap.js によるアニメーションや three.js を使った3D表現など、私が想像していなかった多様な表現技法が存在することを知りました。

このようなブランディングとデザインを伴うウェブ制作を外注すると、金額が高額になりがちで、加えて多くの制作会社の事例を見る限り、完成までに時間もかかることが分かりました。そこで、「常に更新し続けることを前提に、自社で内製していく」方針に切り替えることにしました。

2. 技術選定の背景：ノーコード vs コーディング

当初はノーコードツールの「Studio」も選択肢にありましたが、three.js のような高度なコーディングが必要なデザインには対応が難しいことが分かり、候補から除外しました。

また、近年注目されている「Headless CMS」も検討しましたが、フロントエンドとバックエンドをわざわざ分離する必要性を感じなかったため、最終的にオープンソースでドキュメントも充実している WordPress に立ち返り、テンプレートを自作するという方針に決定しました。

ただし、WordPressのテンプレートはサーバーに手動でアップロードする必要があり、毎回の変更に際してパフォーマンスチェックなどの作業が発生するため煩雑だと感じていました。そこで、GitHub Actions を活用して、テンプレートの自動デプロイとパフォーマンス評価を実現するCI/CD環境を構築することにしました。

3.CI/CD環境の構築：GitHub Actions活用例

テンプレートの開発には「Local by Flywheel」を用いてローカル環境を構築し、その上でGit管理を行いました。

CI/CDの全体フローは以下の通りです。

1. 開発者がローカル環境（Local by Flywheel）でテーマやプラグインの改修を行う
2. GitHubへプッシュし、mainブランチへマージ
3. GitHub Actionsを用いて自動テストおよびデプロイを実施

この仕組みにより、以下のような運用が可能となりました。

• ローカル環境での動作確認とテストの徹底
• 本番環境への迅速かつ確実な反映
• 本番環境を pagespeed.dev で自動評価
• 変更の差分管理とコードレビュー体制の強化

弊社では、main ブランチを本番用、feature ブランチで機能開発とレビューを行い、Pull Request を通じて品質を担保しています。トラブル時のロールバックも Git による管理のおかげで容易です。

4. 結果：パフォーマンスと更新性の向上

main ブランチにマージするだけで自動的にデプロイされるようになったことで、これまで毎回行っていたFTPによる手動アップロード作業が不要になり、開発効率が大幅に向上しました。非常に快適な運用が実現できています。

また、これは副次的な効果ではありますが、WordPressのデフォルトテーマを使用していた頃と比べて、トップページの PageSpeed Insights（pagespeed.dev） スコアが大きく向上しました。

デザインや内容が大きく異なるため、厳密な比較はできませんが、自作テーマと構築環境の最適化によってパフォーマンスが向上したことは、非常に嬉しい成果でした。(モバイルは向上の余地が多分にあります)

6. まとめ：企業サイト内製のすすめ

片手間ではありましたが、5月の1ヶ月間でデザイン、テンプレートの自作、gsap.js や three.js の学習などに取り組むことができ、非常に多くの学びを得られました。

現在の弊社ウェブサイトは、「ひとまず公開してもよい」と判断した状態のものであり、この記事を書いている時点でも細かい修正をいくつか加えているため、初期リリース時の状態とは異なる部分があります。

今後もこの開発環境を活かし、企業サイトとしてより良いものに改善していく予定です。