こんにちは。あやおり子です。
今回は、WordPressサイト制作者が、公式サイトを見ながらNext.jsとmicroCMSの組み合わせでブログ作ってみましたので、その記録をまとめました。
- WordPressで仕事をしているが、Next.jsが気になっている人
- microCMSを触ったことがないWeb制作者
- ブログ用途でNext.jsを検討している人
完成品のブログ
完成品のブログはこちらです！
Next.jsの理解に2週間、ブログ作成1週間で、トータル3週間くらいかかりました。
私のスキル
私はWordPressを中心にWebサイト制作をしてきましたが、WordPress以外のCMSを実務で使ったことがありません。
- 新卒から8年間Webサイト制作を行う。
- 複数の会社を経て、現在はWordPress専門のWebサイト制作会社に所属。
- HTML&CSSでサイトのコーディングやWordPressでのテンプレート制作を行う
- WordPressはテーマだけではなく、プラグインを作成することも可能
- Javascriptは調べながらだとある程度できる
- 大学でC言語を軽くやってたため、プログラミング経験が全くないわけではない。
- 数年前にVue.jsを勉強していたが、実務で使う機会なし。
- Web解析士、ITパスポートの資格所有
React.jsでTodoリストを作った経緯はこちらで紹介しています。
制作背景について
どうしてNext.jsとmicroCMSの組み合わせでブログを作ろうとしたかの説明をしていきます。
なぜNext.jsなのか
私は、React.jsの実務経験はありませんが、React.jsでTodoリストを作った後に、ブログ作成に挑戦しています。
詳しくは、下記記事をご覧ください。
その中でも、いろいろ検討した結果、Next.jsを中心に勉強することにしました。
- React.jsを使ったサイトを制作している会社のフロントエンドエンジニアの募集要項を見ると、Next.jsを利用する前提での求人が圧倒的に多いように思ったため（個人的な観測）
- Next.jsはページ遷移の多い大規模なWebサイトや、高速で快適なWebアプリを開発する場合に適しており、WordPressとの差別化をしやすい
- 公式サイトではNext.jsを使ったWebサイトのテンプレートが多数紹介されており、実際に動いているコードを確認しやすく、実務でも応用できそうに思ったため
どうしてmicroCMSなのか
React.jsでTodoリストを作成を勉強した時に、次はAPIを使ってデータの表示をしたいなと考えました。
しかし、PHPのLaravelやCakePHPも勉強していたら、本来のフロントエンドの勉強をするのにかなり遠回りになります。
そこで、以前Vue.jsでLPを作成した時に利用したmicroCMSを利用することにしました。
- WordPressのクラシックエディターに似たUIのため、WordPressユーザーでも使いやすい
- 無料の範囲で十分に使える（検索機能）
- ユーザー権限の管理がしやすい
- 使いすぎて課金される心配がない
- 出力されるAPIの形が綺麗なので、初心者に向いている
- 何よりヘッドレスCMSなので、WordPressよりもセキュリティが高い
また、microCMSで一度作成した記事は、他のフレームワークを動かしたい時にも同じデータを利用できるのではと思い、microCMSをベースにすることにしました。
microCMSのデメリットは、インポート／エクスポートに手間がかかる点がありますが、今回は個人制作かつ新規サイト制作であり、記事数も多くないため大きな問題にはなりませんでした。
なぜブログを作ろうと思ったのか
理由としては、
- WordPressの制作をやってきた経験から、必要なページや機能を一番把握できているから
- ブログの基本的な構造はどのサイトも変わらないので、他のサイトでも流用できるコードを作りやすそうだと思った
などなどあるのですが、
一番の理由は「私が、このブログ以外のブログ欲しかったから」からでした。
このブログはWordPressと市販のテーマ(JIN)で作っており、有料のテーマは装飾多めのコンテンツを作るのに向いていると思っています。
しかし、記事を書くとなったら気合いを入れる必要があり、書くのが億劫になっていることに気付きました。
そこで、本ブログとは別に、自分がふと思ったことを投稿するような、簡易的なブログが別にあったら、もっとブログも気兼ねなく投稿できるだろうなと考えていました。
Youtubeでいう「サブチャンネル」っていうやつですね。
そのタイミングで、私がちょうどReact.jsを学び始めたので、欲しかったブログを作ろうと思いました。
まずはNext.jsとmicroCMSの公式サイトのスタートガイドをやる
まずは、React.jsと同様に、Next.jsのスタートガイドを見て構築していきました。
Next.jsは素のReactと違い、初期設定で使用を固めるべき内容が多いように思いました。
そのため、インストール時に設定した内容やコマンドなどを、READMEにこまめに記載していくことを意識しました。
公式サイトのスタートガイドでは、フォルダ構成やNext.js特有のHTMLタグなど、Next.jsを触るにあたり必要な知識を学ぶことができました。
しかし、参考のコードが省略されて書かれている箇所が多く、そのままコードを写しても動かないこともしばしば。
まぁ、APIを使う前提のフレームワークなので、コードを全て紹介できないのは致し方ないですね。
そこで参考になったのが、microCMS公式の記事でした。
microCMS + Next.jsでJamstackブログを作ってみよう（Next.js 15 ver.）
参考として書いてあるコードが丁寧で、大変理解しやすかったです。
特に、「4. envファイルの作成」に記載されているような、実務で当たり前に使われているけど、初心者は説明しないとやり方がわからないような内容が書かれているのが本当に助かりました。
ブログ制作開始
そして、本題であるブログ制作開始しました。おおよそ1週間くらいで制作しました。
パーツを流用しやすい形に落とし込み、テンプレートとして使える汎用性のあるサイトにすることを目標にしました。
ブログのデザイン
ブログのデザインは、Zenn のサイトデザインをベースに作ることにしました。
Zennは「エンジニアのための情報共有コミュニティ」をコンセプトとしており、情報を読むことに集中できるシンプルなUIが特徴です。
一方、今回作るブログは「思った時にサクッとかけるミニブログ」をコンセプトにしたいと考えており、noteのような雑記寄りの内容が中心にしたいと考えています。
Webデザインでよくある、豊富な装飾や独自性の高いビジュアル表現を求めるような”見た目を作り込んでいる”サイトではなく、テキストだけのシンプルなサイトをイメージしました。
これらから、見た目はZennの構造を参考にしつつ、扱う内容や立ち位置はZennとは異なる方向性にすることにしました。
また、Zennのデザインは実装面でも参考にしやすい点が魅力でした。
- デザインが全体的にシンプル
- コンポーネント構成が直感的
- スライダーのような、実装に時間がかかる可能性がある要素が少ない
Zennは、テキストや画像を最小限に抑えつつ、読みやすく迷子になりにくいサイトであるように思いました。
Next.jsの環境構築〜制作方針決め〜HTMLコーディング
次に、ブログのデザインをもとに、仕様を決めていきました。
Tailwind CSSを採用
ReactのTodoリストでは採用しなかったTailwind CSSを採用。
Tailwind CSSはCSSの各要素を直接クラスとして指定するため、CSS経験者としてはBootstrapよりも覚えやすい印象でした。
かなりマニアックなCSSの要素もクラス化されているので、CSSは最小限で済みました。
公式のドキュメントも優秀。ページ内検索しやすいため、分からない場合はサクッと検索できました。
TypeScriptへの挑戦
そして今回、完全未経験だったTypeScriptへ挑戦しました。
- Next.jsで推奨されているから
- 参考サイトに書かれているコード多くがTypeScriptで記述されているから
- Javascriptの大きな違いが、型を指定するかしないかくらいの違いしかないように思ったため。
- AIを使えばなんとかなるという甘い考え
型の不一致などでTypeScript起因の不具合で何度もエラーが出たのですが、AIを使うことで動く形に収まることができたのがよかった。
サムネイルはカテゴリーごとにアイコンを設ける仕様
Zennでは記事ごとにアイコンを設けられる仕様です。
しかし、毎回アイコンを設定するのが手間だと思い、カテゴリーごとにアイコンを設定する仕様にしました。
具体的には、Google Fonts にあるアイコンの Icon name を、カテゴリーごとに指定する仕様です。
これにより、サムネイルなしでも寂しくならないサイトになるかと思います。
コーディングを進めていく
準備を一通りしていった後、コーディングを進めていきます。
- TOPページ兼記事一覧をコーディング
- カテゴリーページをコーディング
- 記事詳細ページをコーディング
ページャーに対応するためのURLの指定に苦戦
一番苦戦した点は、ページャー機能の作成でした。
Zenn のトップページや記事一覧ページにはページャーがありませんが、このブログでは microCMS の仕様上、記事を一度に100件までしか取得できません。そのため、一覧ページにはページャーを設ける必要がありました。
URLは「ドメイン.com/page/ページ数」という形にしたかったため、最初は
1ページ目 : src/app/page.tsx
2ページ目以降 : src/app/page/[page]/page.tsx
として実装しようと考えました。
しかしこの方法では、1ページ目と2ページ目以降でほぼ同じ処理を重複して書く必要があり、設計として違和感を感じました。
そこで模索した結果、
src/app/[[…page]]/page.tsx
を作成することで、1ページ目と2ページ目以降を同一の実装で扱えることが分かりました。
また、カテゴリー一覧も、URLを「/category/カテゴリー名/page/ページ数」の形にしたかったため、
src/app/category/[id]/[[…page]]/page.tsx
として作成することで実現しました。
Next.jsでは、ローカル環境で動いたものが、FTPでも同様に動くとは限らないんですね。
フォルダ構成の正解が分からず、意図したURLでうまく表示されない状態が続いたため、正解に辿り着くまでに時間がかかりました。
共通化して記述の重複を避ける
今回ブログ作成した目的の一つに「パーツを流用しやすい形に落とし込む」目的もありました。
そのため、microCMS から記事を取得する処理は、個別のページに直接書かず、共通のget 関数としてまとめました。これにより、取得条件やAPI仕様を変更する場合でも、修正箇所を最小限に抑えられるようにしました。
また、取得したデータを整形する処理も、専用の fetch 関数を用意しました。データ加工のロジックを一箇所に集約することで、似たような処理を複数のファイルで持たずに済み、仕様変更時にも影響範囲を把握しやすくなりました。
記事の中身のCSSはプラグインで解決
記事の中のテキストもある程度調整したいけど、CSSに時間をかけるのももどかしいですよね。
そんな悩みを解決してくれたのは、「tailwind TYPOGRAPHY」というプラグインでした。
- npm install -D @tailwindcss/typography でインストール後
- style.cssの冒頭に@plugin “@tailwindcss/typography”;を追加
- 記事コンテンツの囲みタグのクラスに「prose」を指定
これだけで、取り急ぎイイ感じなスタイルを適用することができました。
もちろん、細かいデザイン調整には限界がありますが、CMSの記事のように内容が可変なケースでは、「読める見た目」を素早く整えられる点で、このプラグインは非常に重宝します。
コマンドを設定して開発中に表示がおかしくなっても対応できる仕様にを追加
Next.js では npm run dev を実行すると開発サーバーは起動しますが、ブラウザが自動で開かないため、毎回URLを手動で開く必要がありました。
そこで、package.json の scripts に open http://localhost:3000 を追加し、開発サーバー起動時にブラウザが自動で開くようにしました。
また、& を使ってコマンドを実行している影響で、Ctrl + C でターミナルを停止しても、バックグラウンドでローカルサーバーのプロセスが残ることがありました。その結果、http://localhost:3001 など別ポートでサーバーが起動してしまい、意図しない挙動になることが頻繁に発生しました。
そのたびに手動でプロセスを探して停止していましたが、コンパイル失敗と重なると、正しく表示されない状態が続くことも多く、開発効率が落ちていました。
そこで、.next ディレクトリの削除と、ポート3000で動作しているローカルサーバーの停止をまとめて行う npm run clean コマンドを用意しました。
package.json
{
"scripts": {
"dev": "next dev & open http://localhost:3000",
"clean": "rm -rf '.next' && kill -9 $(lsof -ti:3000)"
},
}これにより、表示がおかしくなった場合でも、一度すべてをリセットしてから再起動できるようになり、開発がかなり楽になりました。
まとめ：ブログを制作して思ったこと
そんなこんなで、ブログが完成しました。
AIのサポートもあり、初めてにしてはかなり順調に制作できたのではないかと思います。
素のHTMLサイトでもNode.js使うフレームワークを作りたくなる気持ちがわかった
たまに、単純なHTMLサイトでもNode.js使うフレームワークを使って、モダンな作り方をしているサイトに対して大袈裟だと感じていました。
しかし今回作り、単純なHTMLサイトでもモダンな作り方をする気持ちがなんとなくわかるような気がしました。
- 基本となるディレクトリ構成が固定されているから、他の人が急に触っても迷子になりにくい
- Node.jsのプラグインが小回りがきいて便利
- HTMLの圧縮など、別途設定なくちゃならないことも自動でやってくれる
- コンポーネント管理や記述の共通化がしやすい
もちろん、素のHTMLのように直感的に修正できないため、コードが分からなくても取り急ぎ修正できないデメリットはあります。
ただし、ある程度構成を把握している人が継続的に管理する前提であれば、フレームワークを使った方が効率的に作れると感じました。
画面を表示するファイル名が常にpage.tsxなので、コンポーネント分割やディレクトリ設計がより大事
Next.jsの仕様として、画面を表示するファイル名が常に「page.tsx」であるため、パスを確認しないと役割がわからないのが分かりにくいように思いました。
なので、タブだけでどのページを開いているのか分からず、page.tsxを4ページ分しか作ってないのに、すぐに行方不明になっていました。
ファイル名だけではページの役割を把握しづらいため、ページ数や分岐が増える場合は、コンポーネント分割やディレクトリ設計をより意識する必要があると感じました。
サイトの作り込みが、必ずしも学習効率の向上に直結するとは限らない
WordPressのようなプラグインがないので、欲しい機能は自分で作り込まなければいけません。
それはある程度想定していましたが、作れば作るほど「次に実装したい機能」が増えていき、すべてを網羅しようとすると、想像以上に時間がかかります。
- パンくずリスト
- metaタグの設定
- サイトマップ
- 人気記事一覧
- 目次自動生成機能
- いいねボタン etc…
もちろん、一部はmicroCMSの公式ブログにやり方が紹介されているのも知っていますが、ブログのコードが正常に動くとは限りません。
また、自分のスキルを大きく超える内容は、AIやGoogleで調べたコードを使うことで動くと思いますが、汎用性のあるサイト制作が中心になってしまい、自分の勉強目的とはかけ離れてしまいます。
もし制作会社だったら、一回動くコードを作ったら他のサイトに活用できる可能性が高いため、時間をかけて実装する価値はあるかと思います。しかし、個人だと今後も流用する機会があるか不明なので、コードをを理解しながら実装するのが億劫になり、「コードを写して終わり」になりやすいように思いました。
闇雲に機能を増やすのではなく、「今の自分の学習目的に合っているか」を意識しながら取捨選択するバランスが重要だと感じました。
フォーマット化している制作会社は、Next.jsを選ぶよね。
WordPressを完全にフォーマット化して制作している会社であれば、Next.jsに切り替えた方が、結果的にお客様の満足度は高くなるのではないかと感じました。
- 表示速度が早い
- セキュリティ高い
- 自由にカスタマイズしやすい
それでもWordPressが採用され続けている理由を考えると、技術的な優劣というより、業務上の都合によるものが大きいように思いました。
- 管理画面をクライアントに渡しやすい
- 非エンジニアでも更新できる
- サーバー・公開フローが説明しやすい
- 「WordPressです」と言うと安心される
もちろん「どうしてもWordPressが良い」というお客様も一定数いますし、現実的には完全に切り替えるのは難しいと思います。
ただ、制作フローが型化されている現場ほど、WordPressを唯一の選択肢として使っているというよりも、数ある制作方法のひとつとして選択しているケースが、年々増えてきているように感じています。
