
誰しも一度はホームページを作成したことがあるのではないでしょうか?
その時、多くの人は提供しているプラットフォームの多さからWordpressを採用する必要が多いのではないかと思います。私もその一人です。
サイトを作成・運用していると、「~したい」の欲求に増えていく一方、既存テーマできる自由度が少なくため、できないことへのフラストレーションが溜まっていきます。探せばその機能を持ったテーマはなにかしら出てきますが、テーマを切り替えるとこれまで作ってきたデザインが破綻し作り直したり、使えていた機能が使えなくなったりと、不便な点が多いです。機能が欲しいからといってテーマを変えることは想定されていないのです。
今回、法人を設立したことで、コーポレートサイトを作る必要性が出てきました。あまりここにお金を掛けるつもりはないので、ドメインとセットで極力安いサービスを探した結果、XServerを採用することにしました。500GBで990円、仕事柄上でAzureやAWSに触れることが多いですが、比較にならない安さですね。本筋ではないですが、ここで取得したドメインをGoogle Workspaceに紐づけて独自ドメインのメールアドレスも取得しました。ここを実作業で操作できる機会はなかったので、これだけでも十分価値があります。
契約してから、VPSではないのと管理者権限がないことに気づきました。そのため、カスタマイズには選択肢が絞られた状態で検討しなければなりません。
まずは、王道として、WordPressのテーマの自作やカスタマイズを頑張ってみるものも、費用対効果の薄いWordPressやPHPのレガシーさから疲労が溜まっていきます。数十時間、WordPressに向き合っていても固有のロジックや仕様に邪魔され、それを回避するためのソース&設計が汚くなっていきます。Gutenburgの罪は重いです。1つ直せば他がおかしくなり、整合を取れません。
これはある程度、どの言語でも同じかもしれませんが、HTMLとCSSとjavascriptとPHP、4つの言語が混在し複数にファイルを跨っているので、Chat GPTに聞いても意味のない複雑なコードを生成しがちで非常に効率が悪いです。
しかし、WordPressの機能に触れる時間を多かったことで、当たり前ですが、セキュリティはXServer側で担保されていたり、Wordpress側でプラグインによる機能拡張が容易なことに改めて気付けました。WordPressではAPI機能が標準で提供されており、カスタムフィールドを駆使して自由に項目を追加、画面上でCRUD操作ができます。
例えば、「Advanced Custom Fields」と「Custom Post Type UI」の2つのプラグインを追加すればもうそれだけでAPIサーバが完成します。早いしこれは便利で、最大の収穫でした。

記載はたったこれだけで、REST APIを有効化すればよいだけで済みます。もちろん、functions.phpを更新で直接更新してもいいのですが、WordPressに詳しくなくてもGUIで操作できるのがよいです。

WordPressのスペシャリストなるつもりで挑みましたが、前述のした通り、あまりにも次に活かせない技術かつ効率が悪いので、夢は早々に諦め、WordPressはCMSとAPIサーバのヘッドレスサーバとして活用することにしました。
フロントは、流行りのReact + Next.js + Vite、UIコンポーネントはGoogleでも採用されているマテリアルUIを採用しました。これまで実務で利用してこなかったのですが、コーディングしやすい言語でした。パーツ単位でプログラミングができるのであとから見てもかなりわかりやすい記述ができます。

仮想DOMという仕組みで実現しているので、ファイルを保存すればリアルタイムで変化が反映されます。F5すら押す必要はありません。毎回サーバにアップロードし実機確認するプロセスをとっていたのですが、それすら不要です。
ある程度、見た目・レスポンシブデザインに対応した高品質なモジュールも簡単に導入できるため、UIの検討コストが大幅に減りました。
最初はこんなUIぐらい自分で書けると高を括っていましたが、不具合を避けるにはCSSを極力自分で書かないことがレイアウトが汚くならないコツなんですね。このコーポレートサイトもサイズ調整と色指定ぐらいで、CSSはほとんど自分で書いていません。脳はモジュールをどう上手に使うかの検討にリソースを割くことができます。これが流行る理由も納得です。直近では、Reactは脆弱性も報告されましたが、ビルドした静的コンテンツからAPIをコールしているので影響はありません。
ただし、マイナスポイントもあり、SPA(シングルページアプリケーション)なのでSEOは弱いです。クローリングボットから見るとAPIの呼び出し前の状態のHTMLを参照されてしまうので、記事が読み込まれないです。なにも考慮せずに作ってしまうと、いくら記事を書いても検索結果にこの記事が出ることはないです。例えば、以下のようにAPIが呼び出せずに403になってしまうので、中身が何もない状態となり、検索結果に出てこないです。

ビルド時にクローリング用の静的コンテンツを書き出し、実際にサイトにアクセスする時にAPIの内容を上書きすることで、Google Search Consoleに表示されるようにしました。

ロゴデザインだったり、フォントを探したり、アニメーションを作ったりとAdobe関連のソフトの学習時間もかなり含まれていますが、150時間ぐらいで実装できました。消して書いてを繰り返し、生成AIに頼りながら作りました。MUIを参照しているおかげでかなりクオリティの高いものができたと思います。今後はこの技術を活かして、なにかのアプリケーションにできたらと思います。
サイト下部にあるGalleryとかいらないのですが、いつか誰かにウェブサイトの制作依頼があった時に、技術の幅があるアピールとして実装しました。全然事業と関係ない写真ですが、サイトの賑やかしにはなりました?
